Bug 10217 - winbind idmap_ad pulls group sIDHistory attribute as a valid group SID
Summary: winbind idmap_ad pulls group sIDHistory attribute as a valid group SID
Status: NEW
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.6.9
Hardware: All Linux
: P5 normal
Target Milestone: ---
Assignee: Michael Adam
QA Contact: Samba QA Contact
Depends on:
Reported: 2013-10-18 13:41 UTC by Matt Rogers
Modified: 2020-02-10 19:04 UTC (History)
5 users (show)

See Also:

patch to ignore sidhistory SID (1.46 KB, patch)
2013-10-18 13:41 UTC, Matt Rogers
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Rogers 2013-10-18 13:41:02 UTC
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 

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
Comment 1 Volker Lendecke 2013-10-18 13:46:40 UTC
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.
Comment 2 Björn Jacke 2020-02-10 19:04:14 UTC