On Wed, Jan 09, 2019 at 11:28:24PM -0000, Carwyn Edwards wrote:
We've just been bitten by the Samba 4.8 rebase in CentOS/RHEL
7.6, specifically this bit from the RHEL 7.6 release notes:
"The smbd service no longer queries user and group information from Active Directory
domain controllers and NT4 primary domain controllers directly. Installations with the
security parameter set to ads or domain now require that the winbindd service is
running."
Which stems from the Samba 4.8 release notes:
"Domain member setups require winbindd - Setups with "security = domain"
or "security = ads" require a
running 'winbindd' now. The fallback that smbd directly contacts domain
controllers is gone."
The RHEL 7 Systems Administration Guide now states:
"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, the
System Security Services Daemon (SSSD) is not supported."
Now in RHEL 7.5 we were managing to use SSSD with Samba, the only real glitch (we think)
was that SIDs rather than names showing up in the share ACLs. Unfortunately Red Hat
support are sticking to the above like glue so far.
My question to this list is, given the changes to Samba from 4.8, is there a way to get
RHEL 7.6 winbind (for Samba) to use SSSD for the lookups that works?
I noticed that the package sssd-winbind-idmap that ships in RHEL 7.6 contains the library
/usr/lib64/samba/idmap/sss.so which from the idmap_sss man page states:
"The idmap_sss module provides a way to call SSSD to map UIDs/GIDs and SIDs."
With a config example:
[global]
...
idmap config * : backend = sss
(There an open bugzilla and pagure bug about this example being wrong as sss is read
only).
There's also the following file in the package sssd-client
/usr/lib64/cifs-utils/cifs_idmap_sss.so
Which is controlled via the alternatives system.
I'm not entirely sure how these differ yet but I get the impression that the
intention somewhere is to re-enable Samba to Winbind to SSSD lookups? Am I on the right
track? Could this be made to work with the versions in RHEL 7.6 if so?
Yes, you are right.
I updated the idmap_sss man page in a very recent commit
https://pagure.io/SSSD/sssd/c/ea7ada6c0629df45348f699e30acc44194550801?br....
With idmap_sss you can make sure that winbind will use the same ID
mapping as SSSD so that there is no need to change the ownership of
files or directories.
Besides the idmap configuration in smb.conf you have to make sure that
the system is joined the AD with the 'net ads join' command which is
also used by realmd in the default RHEL/CentOS settings. This is needed
because winbind expects some extra data added to some internal libraries
to be able to work properly.
If you have SSSD's version of libwbclient installed please remove the
sssd-libwbclient package and install Samba's libwbclient package if it
is missing (but I guess it is already present as a dependency of
winbind).
There is also a nice summary by Erinn earlier on this list
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahost...
which describes some current pitfalls. In this posting the idmap
'backend = ad' is used. As long as you are not using SSSD's id-mapping
(ldap_id_mapping = false) or overrides 'backend = ad' will work as well
because both winbind and SSSD will use the IDs stored in AD.
/usr/lib64/cifs-utils/cifs_idmap_sss.so is a helper for the cifs.ko
kernel module which uses an upcall to let the user-space map SIDs to
POSIX IDs and back. It is needed on clients where you want to mount
CIFS/SMB shares into the file-system. Winbind is not needed for this
use-case.
HTH
bye,
Sumit
>
> The alternative we're facing is to reset ownership on many millions of files as a
side effect of swapping from sssd to winbind and many open questions as to whether winbind
will handle our active directory (University context, messy). We'd tuned SSSD to
finally work well for us here.
>
> Carwyn
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...