Bug 7113 - "LookupAccountName" fails under Windows 2000
"LookupAccountName" fails under Windows 2000
Status: ASSIGNED
Product: Samba 4.0
Classification: Unclassified
Component: DCE-RPCs and pipes
unspecified
x86 FreeBSD
: P3 normal
: ---
Assigned To: Andrew Bartlett
samba4-qa@samba.org
http://gitweb.samba.org/samba.git/?p=...
:
Depends on: 11892
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-08 03:39 UTC by Christoph Theis
Modified: 2016-05-03 20:44 UTC (History)
2 users (show)

See Also:


Attachments
Networkcapture against Samba (27.61 KB, application/octet-stream)
2010-02-08 03:42 UTC, Christoph Theis
no flags Details
Networkcapture agains AD (24.59 KB, application/octet-stream)
2010-02-08 03:42 UTC, Christoph Theis
no flags Details
Networkcapture against Samba (corrected) (15.32 KB, application/octet-stream)
2010-02-15 07:39 UTC, Christoph Theis
no flags Details
Networkcapture agains AD (corrected) (16.48 KB, application/octet-stream)
2010-02-15 07:40 UTC, Christoph Theis
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Theis 2010-02-08 03:39:48 UTC
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.
Comment 1 Christoph Theis 2010-02-08 03:42:02 UTC
Created attachment 5294 [details]
Networkcapture against Samba
Comment 2 Christoph Theis 2010-02-08 03:42:38 UTC
Created attachment 5295 [details]
Networkcapture agains AD
Comment 3 Matthias Dieter Wallnöfer 2010-02-14 04:59:56 UTC
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
Comment 4 Christoph Theis 2010-02-15 07:38:01 UTC
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


Comment 5 Christoph Theis 2010-02-15 07:39:49 UTC
Created attachment 5351 [details]
Networkcapture against Samba (corrected)

The first 2 captures were just wrong.
Comment 6 Christoph Theis 2010-02-15 07:40:30 UTC
Created attachment 5352 [details]
Networkcapture agains AD (corrected)

The first 2 captures were just wrong
Comment 7 Matthias Dieter Wallnöfer 2010-02-17 12:51:25 UTC
Metze, would you like to see what's wrong here?
Comment 8 Andrew Bartlett 2010-02-22 05:18:26 UTC
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.

Comment 9 Andrew Tridgell 2010-03-03 15:41:59 UTC
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
Comment 10 Matthias Dieter Wallnöfer 2010-03-04 12:05:58 UTC
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.
Comment 11 Christoph Theis 2010-03-04 12:54:53 UTC
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

Comment 12 Andrew Tridgell 2010-03-04 17:04:54 UTC
Andrew and I have now reproduced the problem, and we are working on a fix.

Thanks very much for your patience!

Cheers, Tridge
Comment 13 Matthias Dieter Wallnöfer 2010-03-05 08:27:11 UTC
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")
Comment 14 Matthias Dieter Wallnöfer 2010-03-28 13:27:50 UTC
abartlet & tridge: please don't forget to get this patch into "master".
Comment 15 Matthias Dieter Wallnöfer 2010-05-30 05:44:26 UTC
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".
Comment 16 Andrew Bartlett 2010-05-30 06:09:46 UTC
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. 
Comment 17 Matthias Dieter Wallnöfer 2010-09-09 11:29:08 UTC
metze is working on a definite fix while merging s3 and s4's DCE/RPC server implementations.
Comment 18 Matthias Dieter Wallnöfer 2014-01-09 17:28:03 UTC
Metze, this could have been fixed I guess?
Comment 19 Stefan Metzmacher 2014-01-09 17:44:13 UTC
(In reply to comment #18)
> Metze, this could have been fixed I guess?

Not yet...