Dear all,
I would like to use SSSD's dmap_sss backend (1.15.3) for winbindd (Version 4.6.7) to let SSSD map UIDs/GIDs and SIDs on a file server in an samba based AD environment. I've followed the limited instructions of the man page but from the logs it seems that winbindd does directly communicate with the AD server.
The major settings in smb.conf are: [global] workgroup = MYDOMAIN realm = MYDOMAIN.COM security = ads
...
winbind use default domain = yes winbind nss info = rfc2307 # Default idmap config for local BUILTIN accounts and groups idmap config * : range = 10000-19999 # idmap config for MYDOMAIN idmap config MYDOMAIN:backend = sss idmap config MYDOMAIN:schema_mode = rfc2307 idmap config MYDOMAIN:range = 500-9999
What's wrong here? Could someone please provide me with a working example?
On Tue, Oct 24, 2017 at 10:01:30AM -0000, rdratlos@yahoo.co.uk wrote:
Dear all,
I would like to use SSSD's dmap_sss backend (1.15.3) for winbindd (Version 4.6.7) to let SSSD map UIDs/GIDs and SIDs on a file server in an samba based AD environment. I've followed the limited instructions of the man page but from the logs it seems that winbindd does directly communicate with the AD server.
The major settings in smb.conf are: [global] workgroup = MYDOMAIN realm = MYDOMAIN.COM security = ads
... winbind use default domain = yes winbind nss info = rfc2307 # Default idmap config for local BUILTIN accounts and groups idmap config * : range = 10000-19999 # idmap config for MYDOMAIN idmap config MYDOMAIN:backend = sss idmap config MYDOMAIN:schema_mode = rfc2307 idmap config MYDOMAIN:range = 500-9999What's wrong here? Could someone please provide me with a working example?
I think there is nothing wrong. SSSD's idmap plugin just provides the mapping form SID to UID/GID and back. All other data will be read by winbind from AD. This is to make sure that UIDs and GIDs are consistent for Samba components which might ask winbind directly for IDs and other applications which will use the system's nss interfaces.
HTH
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Hi Sumit,
understood. The configuration seems to be correct.
This is to make sure that UIDs and GIDs are consistent for Samba components which might ask winbind directly for IDs and other applications which will use the system's nss interfaces.
This is exactly the reason, why I want winbind to use the idmap_sss backend.
I have seen that the mapping is cached by at least three caches (windbind: gencache, winbindd_cache; sssd: sss cache). Are there any timeout recommendations for sssd and winbindd caches for the mapping to work properly?
Also, is there an easy way to log sss_idmap backend interworking with winbind?
I had following wrong entry in the the caches for a long time (with several reboots, restarts of winbind d and sssd):
wbind -i rdratlos (from windbindd with sss_idmap) rdratlos:*:10000:10006:Thomas Xyz:/home/MYDOMAIN/rdratlos:/bin/false
getent passwd rdratlos (from sssd) rdratlos@mydomain.com:*:1000:513:Thomas Xyz:/home/MYDOMAIN/rdratlos:/bin/bash
Only a combination of sss_cache -E net cache flush systemctl restart winbindd seemed to have fixed this to:
wbind -i rdratlos (from windbindd with sss_idmap) rdratlos:*:1000:513:Thomas Xyz:/home/MYDOMAIN/rdratlos:/bin/false
Best regards
Thomas
On Tue, Oct 24, 2017 at 12:28:53PM -0000, rdratlos@yahoo.co.uk wrote:
Hi Sumit,
understood. The configuration seems to be correct.
This is to make sure that UIDs and GIDs are consistent for Samba components which might ask winbind directly for IDs and other applications which will use the system's nss interfaces.
This is exactly the reason, why I want winbind to use the idmap_sss backend.
I have seen that the mapping is cached by at least three caches (windbind: gencache, winbindd_cache; sssd: sss cache). Are there any timeout recommendations for sssd and winbindd caches for the mapping to work properly?
If you start with empty caches on the winbind side the results should stay the same because changes in the mapping should be very rare. Please note the by default 'idmap cache time' is 1 week because of the rare changes, see man smb.conf for more details.
Also, is there an easy way to log sss_idmap backend interworking with winbind?
Not an easy we but SSSD will add log messages like:
(Tue Oct 24 13:41:22 2017) [sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[1000] egid[1000] pid[1234].
if debug_level=9. With the help of the pid you can identify which request comes from winbind.
I had following wrong entry in the the caches for a long time (with several reboots, restarts of winbind d and sssd):
wbind -i rdratlos (from windbindd with sss_idmap) rdratlos:*:10000:10006:Thomas Xyz:/home/MYDOMAIN/rdratlos:/bin/false
getent passwd rdratlos (from sssd) rdratlos@mydomain.com:*:1000:513:Thomas Xyz:/home/MYDOMAIN/rdratlos:/bin/bash
Only a combination of sss_cache -E
I would expect that the above one is not needed because 'getent passwd rdratlos' already returned the expected results.
bye, Sumit
net cache flush systemctl restart winbindd seemed to have fixed this to:
wbind -i rdratlos (from windbindd with sss_idmap) rdratlos:*:1000:513:Thomas Xyz:/home/MYDOMAIN/rdratlos:/bin/false
Best regards
Thomas
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Tue, Oct 24, 2017 at 12:28:53PM -0000, rdratlos(a)yahoo.co.uk wrote:
If you start with empty caches on the winbind side the results should stay the same because changes in the mapping should be very rare. Please note the by default 'idmap cache time' is 1 week because of the rare changes, see man smb.conf for more details.
In general I would agree. But winbindd does not follow this principle. If sssd is not running, winbindd will directly contact the AD domain controller and request the UID/SID infomration. As the id mapping setting in smb.conf has been optimized for use of the sss_idmap backend, wbinfo will return the wrong UID and GID as shown in the post before:
wbinfo -i rdratlos (from windbindd with sss_idmap) rdratlos:*:10000:10006:Thomas Xyz:/home/MYDOMAIN/rdratlos:/bin/false
For sure, the long running gencache might prevent this, but we ran into this situation when upgrading sssd (-> 1.15.3) and samba (4.7.0) in parallel. The samba debug log showed following error:
Failed to register idmap module. The module was compiled against SMB_IDMAP_INTERFACE_VERSION 5, current SMB_IDMAP_INTERFACE_VERSION is 6. Please recompile against the current version of samba!
Even after rolling back Samba to version 4.6.7 winbindd's long running cache kept the wrong IDs and prevented some users from connecting the file shares. The required information to solve this problem can only be retrieved from low-level debug logs.
BR
Thomas
On Tue, Oct 24, 2017 at 08:49:05PM -0000, rdratlos@yahoo.co.uk wrote:
On Tue, Oct 24, 2017 at 12:28:53PM -0000, rdratlos(a)yahoo.co.uk wrote:
If you start with empty caches on the winbind side the results should stay the same because changes in the mapping should be very rare. Please note the by default 'idmap cache time' is 1 week because of the rare changes, see man smb.conf for more details.
In general I would agree. But winbindd does not follow this principle. If sssd is not running, winbindd will directly contact the AD domain controller and request the UID/SID infomration. As the id mapping setting in smb.conf has been optimized for use of the sss_idmap backend, wbinfo will return the wrong UID and GID as shown in the post before:
I see, maybe this can be prevented on the start script level so that winbindd is only started if SSSD is running? Additionally the winbindd cache can be flushed here so that winbind always starts with an empty cache. But this might have an effect on performance at least during startup which might not be acceptable.
wbinfo -i rdratlos (from windbindd with sss_idmap) rdratlos:*:10000:10006:Thomas Xyz:/home/MYDOMAIN/rdratlos:/bin/false
For sure, the long running gencache might prevent this, but we ran into this situation when upgrading sssd (-> 1.15.3) and samba (4.7.0) in parallel. The samba debug log showed following error:
Failed to register idmap module. The module was compiled against SMB_IDMAP_INTERFACE_VERSION 5, current SMB_IDMAP_INTERFACE_VERSION is 6. Please recompile against the current version of samba!
Even after rolling back Samba to version 4.6.7 winbindd's long running cache kept the wrong IDs and prevented some users from connecting the file shares. The required information to solve this problem can only be retrieved from low-level debug logs.
Currently I would expect that reducing 'idmap cache time' to something like 1 minute would have a bad effect on performance because winbindd has to talk more often to SSSD via the socket interface. We are working on adding SID lookups to SSSD's memory cache as well. When this is done looking up the mapping would be much faster because it will happen in winbindd's own memory. When this is done lowering 'idmap cache time' might be a reasonable way to fast recover from different mappings.
bye, Sumit
BR
Thomas _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
rdratlos＠yahoo.co.uk -
Sumit Bose