The Redhat systems administration documentation includes this comment:
Red Hat only supports running Samba as a server with the winbindd
service to provide domain users and groups to the local system. Due to
certain limitations, such as missing Windows access control list (ACL)
support and NT LAN Manager (NTLM) fallback, SSSD is not supported.
I'm struggling to understand what this even means. ACLs are filesystem
metadata, and AFAIK SSSD doesn't do filesystems, it does authentication.
It makes sense to talk about Samba support for Windows ACLs because
Samba serves up files, so can keep track of associated metadata. What
are they talking about here?
I have no problem using extended POSIX ACLs on my sssd-based linux
systems because the underlying filesystems (local or NFS remote) support
extended POSIX ACLs and I don't recall doing anything at all to alert
sssd to the fact that I'm going to use extended POSIX ACLs.
Elaborating, with proposed explanation:
Here are the files of a former user who was removed from AD:
root@helios:/home/hgj258/Crystal/JanssenPreF# ls -l
-rw-r--r--+ 1 196740954 domain users 1775277 Aug 28 2018 4mms.pdb
-rw-r--r--+ 1 196740954 domain users 6178772 Aug 28 2018 4mms_phases.mtz
drwxr-xr-x+ 3 196740954 domain users 4096 Aug 29 2018 CCP4i
drwxr-xr-x+ 4 196740954 domain users 4096 Jan 18 2019 Coot
Normally sssd fills in the AD UserName (?) attribute, but since that's
no longer available, it's showing the mapped UID, 196740954. That means
this UID is stored in the inode of the file, along with any ACLs.
Does the Redhat statement above "sssd is missing Windows ACL support"
mean that in addition to doing authentication, sssd is somehow
involved in the authorization process and can't read Windows ACLs out of
the file metadata? The only case I can think of where this would be
applicable (since no linux filesystems I'm aware of support Windows
ACLs) is if you are mounting a Samba or Windows filesystem using the
cifs mount type -- is that what they're talking about?