Environment: 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. Scenario: User1 logs onto CL1 with Account ADDOMNEW/user1. User1 tries to access share on FS1. Bug: 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. Speculation: 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.
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)
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. Volker
> 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 (ADDOMNEW+group1) id ADDOMNEW+user1 uid=30000(NTDOMOLD+user1) gid=30000(ADDOMNEW+group1) groups=30000 (ADDOMNEW+group1)
"Linux-Only"-Test: - 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
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 30001 30002 ... ... 30032 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
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.