5:01 a.m.
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?
5:43 a.m.
On Tue, Oct 24, 2017 at 10:01:30AM -0000, rdratlos(a)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-9999
What'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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
7:28 a.m.
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
7:51 a.m.
On Tue, Oct 24, 2017 at 12:28:53PM -0000, rdratlos(a)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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
3:49 p.m.
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
3:17 a.m.
On Tue, Oct 24, 2017 at 08:49:05PM -0000, rdratlos(a)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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
2374
days inactive
2375
days old
sssd-users@lists.fedorahosted.org
5 comments
2 participants
participants (2)
-
rdratlos＠yahoo.co.uk -
Sumit Bose