I have a FreeBSD (virtual) machine running Samba 4 alpha 11 which acts as a AD and another (virtual) machine running Windows 2000 which is a domain member. When a program on the W2k machine calls LookupAccountName to translate an user name to the SID this translates roughly to the following steps: - Setup a SMB session with the credentials of the service account - Call bind to create an unsecure channel - Call lsa_OpenPolicy2 to obtain a policy handle - Call bind again to create a secure channel - Call lsa_QueryInfoPolicy to obtain domain info The last call fails because Samba finds the policy handle but the SID stored with the handle (the SID of the system account) does not match the SID of the lsa_QueryInfoPolicy call (S-1-5-7 aka Anonymous). I don't know what a correct behaviour would be: That the handle does not have any SID stored with it because it was obtained via an unauthenticated call or if the credentials of the bind calls shall be used to secure the channel only and the lsa_QueryInfoPolicy call shall have the credentials from the session setup. Windows XP uses a different API for this call. I'll attach to network captures, one against Samba, another (in another domain) against AD.
Created attachment 5294 [details] Networkcapture against Samba
Created attachment 5295 [details] Networkcapture agains AD
Hi Christoph! (In reply to comment #0) > I have a FreeBSD (virtual) machine running Samba 4 alpha 11 which acts > as a AD and another (virtual) machine running Windows 2000 which is a > domain member. When a program on the W2k machine calls > LookupAccountName to translate an user name to the SID this translates > roughly to the following steps: Okay, here the first question: what does "LookupAccountName" exactly mean for you: LookupNames2 from the LSA pipe? > - Setup a SMB session with the credentials of the service account > - Call bind to create an unsecure channel > - Call lsa_OpenPolicy2 to obtain a policy handle > - Call bind again to create a secure channel > - Call lsa_QueryInfoPolicy to obtain domain info Until here all okay. > The last call fails because Samba finds the policy handle but the SID > stored with the handle (the SID of the system account) does not match > the SID of the lsa_QueryInfoPolicy call (S-1-5-7 aka Anonymous). Well, you speak something about "fails": I don't see any operation failing in your capture against s4 (e.g. one that would yield NT_STATUS_UNSUCCESSFUL). I controlled also the inputs and outputs of "lsa_QueryInfoPolicy" and "lsa_LookupNames2" and didn't notice abnormalities. Also the two captures seem to be a bit different: eg. the AD one contains "OpenDomain" calls which the s4 one doesn't contain at all. Plus in the s4 one there are listed quite some TCP/ICMP lines which are missing in the AD one (did you apply some save filtering?). To sum up: please provide another pair of captures (as equal as possible regarding the operations) and then comment with references to the interesting lines: e.g. "at line 7 in the s4 capture the client performs a certain LSA call and receives back a wrong answer but in the AD capture at line 9 there is written the correct one". This will help us to fix the problem as fast as possible - otherwise we are a bit lost. Matthias
Hi Matthias! (In reply to comment #3) > Hi Christoph! > > (In reply to comment #0) > > I have a FreeBSD (virtual) machine running Samba 4 alpha 11 which acts > > as a AD and another (virtual) machine running Windows 2000 which is a > > domain member. When a program on the W2k machine calls > > LookupAccountName to translate an user name to the SID this translates > > roughly to the following steps: > > Okay, here the first question: what does "LookupAccountName" exactly mean for > you: LookupNames2 from the LSA pipe? I mean the API function LookupAccountName to convert an user name to the SID: http://msdn.microsoft.com/en-us/library/aa379159(VS.85).aspx In the core it calls lsa_lookupNames2but but before there are calls to lsa_OpenPolicy2 and lsa_QueryInfoPolicy. > > > - Setup a SMB session with the credentials of the service account > > - Call bind to create an unsecure channel > > - Call lsa_OpenPolicy2 to obtain a policy handle > > - Call bind again to create a secure channel > > - Call lsa_QueryInfoPolicy to obtain domain info > > Until here all okay. > > > The last call fails because Samba finds the policy handle but the SID > > stored with the handle (the SID of the system account) does not match > > the SID of the lsa_QueryInfoPolicy call (S-1-5-7 aka Anonymous). > > Well, you speak something about "fails": I don't see any operation failing in > your capture against s4 (e.g. one that would yield NT_STATUS_UNSUCCESSFUL). I > controlled also the inputs and outputs of "lsa_QueryInfoPolicy" and > "lsa_LookupNames2" and didn't notice abnormalities. Oh sh..t. Whatever could go wrong when I made the captures went wrong :( I attach 2 new captures, they shall be as equal as possible (the S4 capture has some DUP ACK packets so the packet numbers are not the same). To sum up (it is just my interpretation of the traffic, don't rely on it): - In packets 21-32 (S4) / 16-23 (AD) a bind call without security is made and a policy handle obtained via lsa_OpenPoicy2. - In packets 33-44 (S4) / 24-35 (AD) a second bind call with the same Assoc Group as returned from the first call, but this time with security, is made and policy info queried with the handle obtained before. For S4 you see the error in packet 44 while the call is successful for AD (packet 35). - AD capture continues with the call to lsa_LookupNames2 - S4 capture does not continue and tries to close the policy handle and receives a second fault in packet 50. I hope I did a better job with the captures this time. Christoph
Created attachment 5351 [details] Networkcapture against Samba (corrected) The first 2 captures were just wrong.
Created attachment 5352 [details] Networkcapture agains AD (corrected) The first 2 captures were just wrong
Metze, would you like to see what's wrong here?
I think the issue is that the client is expecting the schannel bind to sort of upgrade the existing bind, or at least be able to get to the old handles somehow. We have to be very careful here, not to create a security hole.
Hi Christoph! Thanks for the bug report! Can you tell me what the user steps are to reproduce this? I have some guesses as to what causes it (your report was excellent for that, thanks!), but I'd like to reproduce myself if possible. Is this a standard windows tool? If so, what version and how to use it? If this is not a standard tool, then can you send us an example prog that reproduces it? If you can't, then perhaps we can write a test ourselves, but it would take longer, and we'd be less certain we've fixed your issue. Cheers, Tridge
tridge, I found out a case where it does happen: premise: Windows 2000 client joined to a s4 domain Open the machine management console (icon "my computer", right click, option "Manage") and choose the local user/group manager. There you should double click on the "Administrators" group symbol. You notice: - s4 displays something similar to this: "rpc_server/handles.c: Attempt to use invalid sid" - in the group property dialog you see the entry of the "domain admins" group unresolved - you see only the SID I really don't know if it's reproducible with a WinXP client too.
Hi! (In reply to comment #9) > Can you tell me what the user steps are to reproduce this? I have some guesses > as to what causes it (your report was excellent for that, thanks!), but I'd > like > to reproduce myself if possible. > > Is this a standard windows tool? If so, what version and how to use it? > > If this is not a standard tool, then can you send us an example prog that > reproduces it? This was part of the software the company I'm working for is developing. I can write a sample program that will do the same thing, calling LookupAccountName for "Administrator" but it will take a bit of time because the next couple of days I'm on a business trip. Maybe in a quiet hour in the hotel room ... Matthias got some way to reproduce it with windows tools, from the error message it looks like it is the same. @Matthias: at least for the software I was using Win XP used a different approach for LookupAccountName. So from this point of view may have a low priority. But the underlying problem, Windows trying to secure a channel with diffent credentials than those used to open the channel (at least that is my interpretation of what happens) may occur in other functions, too. Christoph
Andrew and I have now reproduced the problem, and we are working on a fix. Thanks very much for your patience! Cheers, Tridge
So, Christoph - for you a short status update: abartlet and tridge generated an experimental patch which fixes the problem but has some side effects - therefore it isn't yet in the official GIT tree. So if you need this feature now it's suggested to checkout a s4 copy and apply this patch manually: http://gitweb.samba.org/samba.git/?p=tridge/samba.git;a=commitdiff;h=2dc19e2878371264606575d3fc09176776be7729 If you click on "raw" in GITWEB you get it formatted as a textfile and you are able to save it onto your computer using the webbrowser save function. Applicable it is using the "git am" command or similarly using "git apply"/"patch" if you delete the header (until "diff")
abartlet & tridge: please don't forget to get this patch into "master".
I managed to write a patch while not breaking existing functionality (see the URL). Therefore this should be working now and no additional patching should be required anymore. I'm glad to mark this as "FIXED".
I strongly believe that the patch is not correct, and will need to be reverted. I'm reopening this bug so we can look into the possible correctness, and consider what options we have to solve this.
metze is working on a definite fix while merging s3 and s4's DCE/RPC server implementations.
Metze, this could have been fixed I guess?
(In reply to comment #18) > Metze, this could have been fixed I guess? Not yet...
Metze, I big thank-you for the hard work on the fix which will probably make it into the upcoming Samba 4.10 release. This issue has been a show-stopper for years, so I am even more impressed that we finally managed to produce this definitive solution. Matthias
(In reply to Matthias Dieter Wallnöfer from comment #20) I looked at the capture again and it seems that this is actually not fixed. And it was wrong to add it to commit e61f9406de17a037106ce5f81feb85a8b477a986 and others before. The realm problem is that Windows 2000 seems to rely on SCHANNEL not using S-1-5-7, but instead the token of the machine account.
(In reply to Stefan Metzmacher from comment #21) In newer Windows versions this should work better and the client would use LookupNames4 or LookupSids3 over schannel. I'll close this as WONTFIX