documented LSA Open Policy Query.

(This used to be commit f5c24c8d9c397d5a7a3f9d0f5dbfd204485f2662)

1 files changed, 192 insertions, 21 deletions

diff --git a/docs/textdocs/cifsntdomain.txt b/docs/textdocs/cifsntdomain.txt
index a72b172393..f0e1bab566 100644
--- a/docs/textdocs/cifsntdomain.txt
+++ b/docs/textdocs/cifsntdomain.txt
@@ -1,15 +1,15 @@
-!==
-!== cifsntdomain.txt for Samba release 1.9.18alpha5 26 Oct 1997
-!==
 NT Domain Authentication
 ------------------------
 
 Authors:	- Luke Kenneth Casson Leighton (lkcl@switchboard.net)
---------	  Copyright (C) 1997 Luke Kenneth Casson Leighton
-		- Paul Ashton                  (paul@argo.demon.co.uk)
+--------	- Paul Ashton                  (paul@argo.demon.co.uk)
+		- Duncan Stansfield            (duncans@sco.com)
+
+		  Copyright (C) 1997 Luke Kenneth Casson Leighton
 		  Copyright (C) 1997 Paul Ashton
+		  Copyright (C) 1997 Duncan Stansfield
 
-Version:	0.019 (25oct97)
+Version:	0.020 (26oct97)
 --------
 
 Distribution:	Unlimited and encouraged, for the purposes of implementation
@@ -18,9 +18,9 @@ Distribution:	Unlimited and encouraged, for the purposes of implementation
 Liability:	Absolutely none accepted implicitly or explicitly, direct
 ----------	or consequentially, for use, abuse, misuse, lack of use,
 		misunderstandings, mistakes, omissions, mis-information for
-		anything in or not in, related to or pertaining to this
-		document or anything else that a lawyer can think of or not
-		think of.
+		anything in or not in, related to or not related to, or
+		pertaining to this document, or anything else that a lawyer
+		can think of or not think of.
 
 Warning:	Please bear in mind that an incorrect implementation of this
 --------	protocol can cause NT workstation to fail irrevocably, for
@@ -39,6 +39,7 @@ Credits:	- Paul Ashton: loads of work with Net Monitor;
 --------	  understanding the NT authentication system;
 		  reference implementation of the NT domain support on which
 		  this document is originally based.
+		- Duncan Stansfield: low-level analysis of MSRPC Pipes.
 		- Linus Nordberg: producing c-code from Paul's crypto spec.
 		- Windows Sourcer development team
 
@@ -51,12 +52,14 @@ Contents:
    2) Structures and notes
 
       2.1) Notes
-      2.2) Structures
+      2.3) Enumerations
+      2.3) Structures
 
    3) Transact Named Pipe Header/Tail
 
-      3.1) Header
-      3.2) Tail
+      3.1) MSRPC Pipes
+      3.2) Header
+      3.3) Tail
 
    4) NTLSA Transact Named Pipe
 
@@ -225,8 +228,29 @@ include, but are not limited to:
   appears a third time after the last sub-structure.
 
   
+2.2) Enumerations
+-----------------
+
+- MSRPC Header type.  command number in the msrpc packet header
+
+    MSRPC_Request:   0x00
+    MSRPC_Response:  0x02
+    MSRPC_Bind:      0x0B
+    MSRPC_BindAck:   0x0C
+
+- MSRPC Packet info.  the meaning of these flags is undocumented
+
+    FirstFrag:     0x01 
+    LastFrag:      0x02 
+    NotaFrag:      0x04  
+    RecRespond:    0x08  
+    NoMultiplex:   0x10  
+    NotForIdemp:   0x20  
+    NotforBcast:   0x40  
+    NoUuid:        0x80 
 
-2.2) Structures
+
+2.3) Structures
 ---------------
 
 - sizeof VOID* is 32 bits.
@@ -281,6 +305,15 @@ include, but are not limited to:
         UINT32             length of unicode string
         UINT16[]           string of uncode characters.
 
+- OBJ_ATTR (object attributes) :
+
+        UINT32             0x18 - length (in bytes) including the length field.
+        VOID*              0 - root directory (pointer)
+        VOID*              0 - object name (pointer)
+        UINT32             0 - attributes (undocumented)
+        VOID*              0 - security descriptior (pointer)
+        UINT32             0 - security quality of service
+        
 - POL_HND (LSA policy handle) :
 
     char[20]           policy handle
@@ -559,21 +592,52 @@ Note:	see cifs6.txt section 6.4 - the fields described therein will be
 
 
 
-3) Transact Named Pipe Header/Tail
-----------------------------------
+3) MSRPC over Transact Named Pipe
+---------------------------------
+
+For details on the SMB Transact Named Pipe, see cifs6.txt
 
-Interesting note: if you set packed data representation to 0x0100 0000 then
-all 4-byte and 2-byte word ordering is turned around.
 
-3.1) Header
+3.1) MSRPC Pipes
+----------------
+
+The MSRPC is conducted over an SMB Transact Pipe with a name of "\PIPE\".
+You must first obtain a 16 bit file handle, by sending a SMBopenX with the
+pipe name "\PIPE\srvsvc" for example.  You can then perform an SMB Trans,
+and must carry out an SMBclose on the file handle once you are finished.
+
+Trans Requests must be sent with two setup UINT16s, no UINT16 params (none
+known about), and UINT8 data parameters sufficient to contain the MSRPC
+header, and MSRPC data.  The first UINT16 setup parameter must be 0x26.  The
+second UINT16 parameter must be the file handle for the pipe, obtained above.
+
+MSRPC Responses are sent as response data inside standard SMB Trans
+responses, with the MSRPC Header, MSRPC Data and MSRPC tail.
+
+[section on MSRPC Bind and BindAck to be added once they are understood].
+
+It is suspected that the Trans Requests will need to be at least 2-byte
+aligned (probably 4-byte).  This is standard practice for SMBs.  It is also
+independent of the observed 4-byte alignments with the start of the MSRPC
+header, including the 4-byte alignment between the MSRPC header and the
+MSRPC data.
+
+
+3.2) Header
 -----------
 
+[section to be rewritten, following receipt of work by Duncan Stansfield]
+
+
+Interesting note: if you set packed data representation to 0x0100 0000
+then all 4-byte and 2-byte word ordering is turned around!
+
 The start of each of the NTLSA and NETLOGON named pipes begins with:
 
 00  UINT8         5 - RPC major version
 01  UINT8         0 - RPC minor version
 02  UINT8         2 - RPC response packet
-03  UINT8         3 - first frag + last frag
+03  UINT8         3 - (FirstFrag bit-wise or with LastFrag)
 04  UINT32        0x1000 0000 - packed data representation
 08  UINT16        fragment length - data size (bytes) inc header and tail.
 0A  UINT16        0 - authentication length 
@@ -585,7 +649,111 @@ The start of each of the NTLSA and NETLOGON named pipes begins with:
 18  ......        start of data (goes on for allocation_hint bytes)
 
 
-3.2 Tail
+MsrpcPacket for both request and response
+{
+  
+  UINT8 versionmaj        # reply same as request (0x05)
+  UINT8 versionmin        # reply same as request (0x00)
+  UINT8 type              # one of the MSRPC_Type enums
+  UINT8 flags             # reply same as request (0x00 for Bind, 0x03 for Request)
+  UINT32 representation   # reply same as request (0x00000010)
+  UINT16 fraglength       # the length of the data section of the SMB trans packet
+  UINT16 authlength       
+  UINT32 callid           # call identifier. (e.g. 0x00149594)
+
+  * stub USE TvPacket     # the remainder of the packet depending on the "type"
+}
+
+
+# the interfaces are numbered. as yet I haven't seen more than one interface
+# used on the same pipe name
+# srvsvc
+#   abstract (0x4B324FC8, 0x01D31670, 0x475A7812, 0x88E16EBF, 0x00000003)
+#   transfer (0x8A885D04, 0x11C91CEB, 0x0008E89F, 0x6048102B, 0x00000002)
+Msrpcface RW
+{
+  UINT8 byte[16]    # 16 bytes of number
+  UINT32 version    # the interface number
+}
+
+
+# the remainder of the packet after the header if "type" was Bind
+# in the response header, "type" should be BindAck
+MsrpcReqBind RW
+{
+  UINT16 maxtsize       # maximum transmission fragment size (0x1630)
+  UINT16 maxrsize       # max receive fragment size (0x1630)
+  UINT32 assocgid       # associated group id (0x0)
+  UINT32 numelements    # the number of elements (0x1)
+  UINT16 contextid      # presentation context identifier (0x0)
+  UINT8 numsyntaxes     # the number of syntaxes (has always been 1?)(0x1)
+  UINT8 padding         # 0 - 1 byte of padding
+
+  * abstractint USE MsrpcIface # num and vers. of interface client is using
+  * transferint USE MsrpcIface # num and vers. of interface to use for replies
+}
+
+
+# this seems to be the same string name depending on the name of the pipe,
+# but is more likely to be linked to the interface name
+# "srvsvc", "\\PIPE\\ntsvcs"
+# "samr", "\\PIPE\\lsass"
+# "wkssvc", "\\PIPE\\wksvcs"
+# "NETLOGON", "\\PIPE\\NETLOGON"
+MsrpcAddress RW
+{
+  UINT16 length        # length of the string including null terminator
+  * port USE string    # the string above in single byte, null terminated form
+}
+
+
+# the response to place after the header in the reply packet
+MsrpcResBind RW
+{
+  UINT16 maxtsize                   # same as request
+  UINT16 maxrsize                   # same as request
+  UINT32 assocgid                   # zero
+
+  * secondaddr USE MsrpcAddress     # the address string, as described earlier
+
+  UINT8 padding                     # 0 - one byte padding
+
+  UINT8 numresults                  # the number of results (0x01)
+
+  UINT8[]                           # 4-byte alignment padding, against SMB header
+  UINT16 result                     # result (0x00 = accept)
+  UINT16 reason                     # reason (0x00 = no reason specified)
+
+  * transfersyntax USE MsrpcIface   # the transfer syntax from the request
+}
+
+
+# the remainder of the packet after the header for every other other
+# request
+MsrpcReqNorm RW
+{
+  UINT32 allochint         # the size of the stub data in bytes
+  UINT16 prescontext       # presentation context identifier (0x0)
+  UINT16 opnum             # operation number (0x15)
+
+  * stub USE TvPacket      # a packet dependent on the pipe name
+                           # (probably the interface) and the op number)
+}
+
+
+# response to a request
+MsrpcResNorm RW
+{
+  UINT32 allochint         # size of the stub data in bytes
+  UINT16 prescontext       # presentation context identifier (same as request)
+  UINT8 cancelcount        # cancel count? (0x0)
+  UINT8 reserved           # 0 - one byte padding
+
+  * stub USE TvPacket      # the remainder of the reply
+}
+
+
+3.3 Tail
 --------
 
 The end of each of the NTLSA and NETLOGON named pipes ends with:
@@ -616,7 +784,9 @@ Note:	The policy handle can be anything you like.
 
 Request:
 
-    no extra data.
+    UNISTR2   server name - unicode string starting with two '\'s
+    OBJ_ATTR  object attributes
+    UINT32    1 - desired access
 
 Response:
 
@@ -1240,3 +1410,4 @@ A2.2.3) Well-known RID aliases
 
 	DOMAIN_ALIAS_RID_REPLICATOR    0x0000 0228
 
+