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):

samba/samba-winbind 3.6.9-151.el6_4.1 
RHEL6.4

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.

Additional info:

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

lookup_usergroups results:

[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