diff options
Diffstat (limited to 'docs/textdocs')
| -rw-r--r-- | docs/textdocs/cifsntdomain.txt | 213 |
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 + |