Created attachment 9304 [details]
patch to ignore sidhistory SID
When lookup_usergroups pulls in group SIDs from AD, the tokenGroup search will include SIDs that are contained in the sIDHistory attribute if they exist on any of the user's groups. This results in a duplicate mapping of the group (one is outside of the domain and mapped to the default, the other is mapped to the idmap_ad range.)
There is no winbind/samba/linux use for the sIDHistory entries, so they should be ignored completely.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Migrate a group from DOM X to DOM Y, so on DOM Y the group has a sIDHistory attribute filled in with the old SID from DOM X.
2. Assign POSIX attributes on the group on DOM Y as well as a user. Add the user to the migrated group.
3. For winbind joined to DOM Y use a similar config:
idmap config *:backend = tdb
idmap config *:range = 20000-29999
idmap config EXAMPLE : backend = ad
idmap config EXAMPLE : default = yes
idmap config EXAMPLE : range = 10000-19999
idmap config EXAMPLE : schema_mode = rfc2307
winbind enum users = no
winbind enum groups = no
winbind use default domain = yes
winbind nested groups = no
allow trusted domains = no
4. An example of 'id' for the user that is a member of the group containing sIDHistory:
# id stringer
uid=10008(stringer) gid=10001(domain users) groups=10001(domain users),20000,10052(migrationgroupdl)
Notice the '20000' entry that does not have an associated group name. This is the sIDHistory SID mapped to the tdb range. 10052(migrationgroupdl) is the actual group.
Attached is a patch that adds a check to lookup_usergroups to filter out the sIDHistory based on domain. A small change was needed to dom_sid_compare_domain to work for a full SID+RID as well, otherwise it would start out by incorrectly comparing the RID.
I've made this workaround work only for allow trusted domains = no to be safe and only apply in situations with a single domain, since it could possibly interfere with cross-domain group membership (but I have not verified that)
Example logs displaying the issue ->
var/log/samba/log.winbindd: wcache_tdc_add_domain: Adding domain BUILTIN (), SID S-1-5-32, flags = 0x0, attributes = 0x0, type = 0x0
var/log/samba/log.winbindd: wcache_tdc_add_domain: Adding domain SYSTEM (), SID S-1-5-21-1521524393-142954872-3215667214, flags = 0x0, attributes = 0x0, type = 0x0
var/log/samba/log.winbindd: wcache_tdc_add_domain: Adding domain AD (AD.COMP.ORG), SID S-1-5-21-431646955-28907400-1360554963, flags = 0x0, attributes = 0x0, type = 0x0
[2013/10/08 09:05:40.241534, 5] libads/ldap_utils.c:80(ads_do_search_retry_internal)
Search for (objectclass=*) in <<SID=0105000000000005150000001774981D8817B901D36B18512B700200>> gave 1 replies
[2013/10/08 09:05:40.241670, 10] libads/ldap.c:2683(ads_pull_sids)
pulling SID: S-1-5-21-1736538217-197823045-112381533-11361 <--- old, unknown domain (sIDHistory)
[2013/10/08 09:05:40.241748, 10] libads/ldap.c:2683(ads_pull_sids)
pulling SID: S-1-5-32-545
[2013/10/08 09:05:40.241813, 10] libads/ldap.c:2683(ads_pull_sids)
pulling SID: S-1-5-21-431646955-28907400-1360554963-118465
[2013/10/08 09:05:40.241905, 10] libads/ldap.c:2683(ads_pull_sids)
pulling SID: S-1-5-21-431646955-28907400-1360554963-1953
[2013/10/08 09:05:40.241973, 10] libads/ldap.c:2683(ads_pull_sids)
pulling SID: S-1-5-21-431646955-28907400-1360554963-33283
One problem: We can't tell whether a SID is from a legitimately trusted domain that might be not available temporarily and a domain that has been migrated into sidHistory when they come in via an nt token (kerberos pac or netsamlogon call). When asking explicitly, we might have a chance to look at the ldap attributes, but for just another sid in the auxiliary sid list in the token we can't tell.
Can you get Simo Sorce, colleague of yours to comment here? He's done quite a bit in this area.