summaryrefslogtreecommitdiff
path: root/docs/textdocs
diff options
context:
space:
mode:
Diffstat (limited to 'docs/textdocs')
-rw-r--r--docs/textdocs/cifsntdomain.txt213
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
+