Bug 1518 - Samba, SID History, possible Bug in XP / Handling of Domain Trusts
Samba, SID History, possible Bug in XP / Handling of Domain Trusts
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
x86 Linux
: P3 critical
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2004-07-12 09:58 UTC by Sven Thomsen
Modified: 2004-08-10 06:25 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Sven Thomsen 2004-07-12 09:59:43 UTC
ADDOMNEW:	AD Domain, fully trusted with NTDOMOLD 
NTDOMOLD:	NT Domain, fully trusted with ADDOMNEW 
DCNEW:		Domain Controller for ADDOMNEW, W2K SP1 
DCOLD:		Domain Controller fpr NTDOMOLD, NT4 SP6a 
FS1:		Samba 3.0.4 Fileserver, security=ads, Memberserver in ADDOMNEW 
CL1:		Windows XP SP1, Client in ADDOMNEW 
User1:		Has account ADDOMNEW/user1 and NTDOMOLD/user1. Let NEWSIDUSER1 
be the SID of user1 in ADDOMNEW and OLDSIDUSER1 the SID of user1 in NTDOMOLD. 
ADDOMNEW/user1 has OLDSIDUSER1 in SID History. 
User1 logs onto CL1 with Account ADDOMNEW/user1. User1 tries to access share 
on FS1.  
On connect to share CL1 does NOT send NEWSIDUSER1 but sends OLDSIDUSER1. 
Samba/Winbind tries to resolve OLDSIDUSER1 in ADDOMNEW and fails.  
When wbinfo is specifically asked to resolve OLDSIDUSER1 it correctly points 
to NTDOMOLD/user1. Resolving NEWSIDUSER1 points correctly to ADDOMNEW/user1. 
First of all, this looks like a bug in Windows XP to me. It seems to use SIDs 
located in the account`s SID History for connects to shares.   
How can samba work around this bug?  
I don't know if it's related to Domain-Trust-Handling or just additionally 
searching the AD: "Search account with this SID in SID History". 
Feel free to contact me if you need further tests. I can apply patches to this 
test-scenario and attach the results to this report.
Comment 1 Sven Thomsen 2004-07-13 00:08:58 UTC
Some wbinfo output: 
wbinfo -S S-1-5-21-XXXX-YYYY-ZZZZ-1111 
Could not convert sid S-1-5-21-XXXX-YYYY-ZZZZ-1111 to uid 
[2004/07/13 09:02:01, 1] nsswitch/winbindd_sid.c:winbindd_sid_to_uid(200) 
  Could not get uid for sid S-1-5-21-XXXX-YYYY-ZZZZ-1111 
wbinfo -s S-1-5-21-XXXX-YYYY-ZZZZ-1111 
ADDOMNEW+user1 1 
wbinfo -n NTDOMOLD+user1 
S-1-5-21-XXXX-YYYY-ZZZZ-1111 (The _same_ SID as above) 
Comment 2 Volker Lendecke 2004-07-13 00:27:30 UTC
Is it possible that the SID you mention has accidently ended up as a GID in your
idmap? You could try 'wbinfo -Y ' with that SID. If this is the case, shutdown
winbind, do a 'net idmap dump', remove that SID, 'net idmap restore' and do a
wbinfo -S again.

Comment 3 Sven Thomsen 2004-07-13 00:58:17 UTC
> You could try 'wbinfo -Y ' with that SID 
wbinfo -Y S-1-5-21-XXXX-YYYY-ZZZZ-1111 
Could not convert sid S-1-5-21-XXXX-YYYY-ZZZZ-1111 to gid 
Some other wbinfo experiments: 
- shutdown smbd, nmbd and winbindd 
- clear idmap 
- restart smbd, nmbd and winbindd 
id NTDOMOLD+user1 
uid=30000(NTDOMOLD+user1) gid=30000(ADDOMNEW+group1) groups=30000
id ADDOMNEW+user1 
uid=30000(NTDOMOLD+user1) gid=30000(ADDOMNEW+group1) groups=30000
Comment 4 Sven Thomsen 2004-07-13 01:44:25 UTC
- stop winbind 
- delete winbinds id cache 
- start winbind 
> net idmap dump winbindd_idmap.tdb 
USER HWM 30000 
GROUP HWM 30000 
On linux client: 
smbclient //FS1/share1 -U user1 -W ADDOMNEW 
[2004/07/13 10:39:14, 1] libads/ads_ldap.c:ads_sid_to_dn(198) 
  ads_sid_to_dn (sid=S-1-5-21-XXXX-YYYY-ZZZZ-1111 Not found): (count=0) 
The SID above is the SID of user1 in NTDOMOLD, not ADDOMNEW 
net idmap dump winbindd_idmap.tdb  | grep UID 
UID 30000 S-1-5-21-AAAA-BBBB-CCCC-2222 
This is the SID of user1 in ADDOMNEW 
Comment 5 Sven Thomsen 2004-07-13 06:55:07 UTC
Another wbinfo log: 
Step 1: > wbinfo -n ADDOMNEW+user1 
S-1-5-21-AAAA-BBBB-CCCC-2222 User (1) 
This is the correct SID for user1 in ADDOMNEW 
Step 2:> wbinfo -r ADDOMNEW+user1 
Step 3: > wbinfo -n ADDOMNEW+user1 
S-1-5-21-XXXX-YYYY-ZZZZ-1111 User (1) 
This is the wrong SID (user1 in NTDOMOLD) 
Step 4: > wbinfo -n ADDOMNEW+user1 
S-1-5-21-AAAA-BBBB-CCCC-2222 User (1) 
This is again the right SID 
Depending on time between step 3 and step 4, the results vary, but in the end, 
I'll always get the right SID again. 
Winbind related statements in smb.conf: 
winbind separator = + 
winbind uid = 30000-40000 
winbind gid = 30000-40000 
winbind enum users = no 
winbind enum groups = no 
winbind cache time = 0 
template homedir = /tmp 
template shell = /bin/false 
Comment 6 Sven Thomsen 2004-08-10 06:25:46 UTC
OK, this was a problem with ngroups<=32 in linux kernel 2.4-series. 
Upgrading to a distribution with kernel >= 2.6.4 did solve this problem.