[cifs-protocol] RE: LSA LookupSids 3

[John Dunning]

Hello Andrew,

We have concluded our investigation regarding this issue. The reason that you see the RPC Fault is that you are using SMB to send the LookupSid3 message. TCP/IP MUST be used as the transport for LookupSid3 messages. This is also why you are getting PIPE_DISCONNECTED after this failure. The requirement to use TCP/IP is documented in the [MS-LSAT] document section 2.1. However there is also a Windows Behavior that needs to be added to explain why you see this with Windows 2008.

The original text for a portion of that section reads as follows:

2.1     Transport

                RPC clients for this protocol MUST use RPC over SMB for the LsarOpenPolicy2, LsarOpenPolicy, LsarClose, LsarGetUserName, LsarLookupNames, LsarLookupNames2, LsarLookupNames3, LsarLookupSids, and LsarLookupSids2 methods. RPC clients MUST use RPC over TCP/IP for the LsarLookupNames4 and LsarLookupSids3 methods. If an unsupported RPC protocol sequence is used, the server MUST return an error value of RPC_S_PROTSEQ_NOT_SUPPORTED, as specified in [MS-ERREF].

This will be modified in a future release of the [MS-LSAT] document to something similar to the following:

1)            In section 2.1
       Remove the sentence "If an unsupported RPC protocol sequence is used, the server MUST return an error value of RPC_S_PROTSEQ_NOT_SUPPORTED, as specified in [MS-ERREF]." Add a link to the following Windows Behavior.

2)            Add the following Windows Behavior  to appendix B, linked with section 2.1.
If the client uses an unsupported RPC protocol sequence then the RPC server implementations in Windows 2000, Windows XP and Windows Server 2003 returns RPC_S_PROTSEQ_NOT_SUPPORTED. Windows Vista and Windows Server 2008 throws an RPC exception with status code as ERROR_ACCESS_DENIED.

Please let me know if this fully answers this issue.


John Dunning
Escalation Engineer Microsoft Corporation
US-CSS DSC PROTOCOL TEAM
Email: johndun at microsoft.com
Tele: (469)775-7008

We're hiring

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Friday, August 29, 2008 5:00 PM
To: John Dunning
Cc: Interoperability Documentation Help; pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: LSA LookupSids 3

On Fri, 2008-08-29 at 13:32 -0700, John Dunning wrote:
> Hello Andrew,
>    I have reviewed the network capture and it clearly shows what you
> are describing. The reason that the msprc fault occurred in Frame 1695
> is that there is no Authverifier information in the
> LSARPC:LsarLookupSids3 Request in Frame 1694. Looking at a successful
> LSARPC:LsarLookupSids3 Request in a different capture I see that the
> Authverifier field is present. This field contains the
> RPC_C_AUTHN_NETLOGON and the RPC_C_AUTHN_LEVEL_INTEGRITY information.
> I am theorizing that the Authverifier field is missing in your trace
> because there was not a RPC Bind exchange prior to this request.

Well, you have the full trace - see the RPC bind in packet 22

> My source code investigation indicates that if the  Authverifier field
> is present that the server will behave as described in MS-LSAT
> 3.1.4.9. When the Authverifier field is absent then it will lead to an
> msrpc Fault of access denied.

We have connected with level 'connect', which does not have an authentication verifier.  All previous packets (prepared similarly) are processed.  Why is this call different?

> Is it the intention of your test to determine what would happen when a
> LSARPC:LsarLookupSids3 Request is made when there is no Authverifier
> information present?

The intention of this test is to run over all the calls, and test each one.  We were expecting an error code of NT_STATUS_RPC_PROTSEQ_NOT_SUPPORTED or NT_STATUS_ACCESS_DENIED.  Getting an RPC fault was most unexpected.  Perhaps there is there a way certain calls are marked in the IDL as to cause this behaviour?

> Thanks
> John
>
> PS: I looked into your question about running your test suites. I
> found out that some of the Interop folks have an instance of your
> Samba 4 running as a DC and that some of the SMBTorture tests have
> been run against it. More information in this area should be
> forthcoming.

That part is easy - do they have smbtorture running against Windows servers, or your tests running against Samba?

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.