Winbindd IDMAP SID-to-UNIX-IDs problem

[Burgess, Adam]

IDMAP cache somehow ends up with an unmapped SID2UID entry (i.e value = -1) and the SID2GID entry expires.  At this stage winbindd returns unmapped for a SID-to-UNIX-IDs request.  This results in smbd giving incorrect group memberships and incorrect resource access, until the SID2UID entry expires. This is surely a bug?

Samba version is 3.6.6 as bundled with our current Solaris 10 patch revision (the platform).  Using only Kerberos PAC SIDs for membership and basic LDAP based IDMAP backend.

Reproduction steps:


1.       Pick a valid UNIX GID that should be mapped to a SID

2.       Get SID for this GID (e.g. wbinfo -G <GID>)

3.       Delete or set low expiry value for SID2GID entry for this SID (e.g. net cache del IDMAP/SID2GID/<SID>)

4.       Now request SID2UID lookup for this SID, which should be unmapped (e.g. wbinfo -S <SID>)

5.       Now do SID-to-UNIX-IDs lookup to mimic smbd IDMAP lookup of Kerberos PAC SIDs (e.g. wbinfo --sids-to-unix-ids=<SID>)



The result is that the SID is unmapped.



Winbindd IDMAP will not consider the state of having an unmapped SID2UID and an expired or non-existent SID2GID as reason to query IDMAP backend for a SID2GID.



In our environment this is causing considerable problems as we have a maximum setting for IDMAP negative entries in order to prevent them expiring at all (this is required because we have user in a large number of AD groups i.e. >400) and only a few required for UNIX (<= Solaris limit of 16).  When negative entries expire connections take a very long time as a result of the numerous negative IDMAP queries.  This means that we are more likely to hit the problem than with the default cache time values.



        idmap cache time = 36000

        idmap negative cache time = 2147483647



It is not clear which smbd function might be causing the SID2UID lookup (for group SID value) in the first place but then that's seem to me to be not the crucial issue as it may just happen via a wbinfo invocation as above directly anyway.



Does anyone know if this is a bug and if so if it has been addressed in versions beyond 3.6.6 (I have tested very quickly with 3.6.12 too but it seems to me no different)?



Thanks,



Adam