diff options
| -rw-r--r-- | docs/textdocs/Passwords.txt | 46 | ||||
| -rw-r--r-- | docs/textdocs/Tracing.txt | 93 | ||||
| -rw-r--r-- | docs/textdocs/UNIX-SMB.txt | 231 | ||||
| -rw-r--r-- | docs/textdocs/cifsntdomain.txt | 1498 |
4 files changed, 0 insertions, 1868 deletions
diff --git a/docs/textdocs/Passwords.txt b/docs/textdocs/Passwords.txt deleted file mode 100644 index 25d4c816f0..0000000000 --- a/docs/textdocs/Passwords.txt +++ /dev/null @@ -1,46 +0,0 @@ -Contributor: Unknown -Date: Updated April 19th 1999. -Status: Current - -Subject: NOTE ABOUT PASSWORDS -============================================================================= - -Unix systems use a wide variety of methods for checking the validity -of a password. This is primarily controlled with the Makefile defines -mentioned in the Makefile. - -Also note that some clients (notably WfWg) uppercase the password -before sending it. The server tries the password as it receives it and -also after lowercasing it. - -The Samba server can also be configured to try different -upper/lowercase combinations. This is controlled by the [global] -parameter "password level". A level of N means to try all combinations -up to N uppercase characters in the password. A high value can chew a -fair bit of CPU time and can lower the security of your system. Do not -use this options unless you really need it - the time taken for -password checking can become so high that clients time out. - -If you do use the "password level" option then you might like to use --DUFC_CRYPT in your Makefile. On some machine this makes password -checking _much_ faster. This is also useful if you use the @group -syntax in the user= option. - -If your site uses AFS (the Andrew File System), you can use the AFS section -in the Makefile. This will first attempt to authenticate a username and -password to AFS. If that succeeds, then the associated AFS rights will be -granted. Otherwise, the password checking routine falls back to whatever -Unix password checking method you are using. Note that the AFS code is -only written and tested for AFS 3.3 and later. - - -SECURITY = SERVER or DOMAIN -=========================== - -Samba can use a remote server to do its username/password -validation. This allows you to have one central machine (for example a -NT box) control the passwords for the Unix box. - -See the section on "security =" in smb.conf(5) for details. - - diff --git a/docs/textdocs/Tracing.txt b/docs/textdocs/Tracing.txt deleted file mode 100644 index 6cc1d69258..0000000000 --- a/docs/textdocs/Tracing.txt +++ /dev/null @@ -1,93 +0,0 @@ -Contributor: Andrew Tridgell <samba@samba.org> -Date: Old -Status: Questionable - -Subject: How to trace samba system calls for debugging purposes -============================================================================= - -This file describes how to do a system call trace on Samba to work out -what its doing wrong. This is not for the faint of heart, but if you -are reading this then you are probably desperate. - -Actually its not as bad as the the above makes it sound, just don't -expect the output to be very pretty :-) - -Ok, down to business. One of the big advantages of unix systems is -that they nearly all come with a system trace utility that allows you -to monitor all system calls that a program is making. This is -extremely using for debugging and also helps when trying to work out -why something is slower than you expect. You can use system tracing -without any special compilation options. - -The system trace utility is called different things on different -systems. On Linux systems its called strace. Under SunOS 4 its called -trace. Under SVR4 style systems (including solaris) its called -truss. Under many BSD systems its called ktrace. - -The first thing you should do is read the man page for your native -system call tracer. In the discussion below I'll assume its called -strace as strace is the only portable system tracer (its available for -free for many unix types) and its also got some of the nicest -features. - -Next, try using strace on some simple commands. For example, "strace -ls" or "strace echo hello". - -You'll notice that it produces a LOT of output. It is showing you the -arguments to every system call that the program makes and the -result. Very little happens in a program without a system call so you -get lots of output. You'll also find that it produces a lot of -"preamble" stuff showing the loading of shared libraries etc. Ignore -this (unless its going wrong!) - -For example, the only line that really matters in the "strace echo -hello" output is: - -write(1, "hello\n", 6) = 6 - -all the rest is just setting up to run the program. - -Ok, now you're famialiar with strace. To use it on Samba you need to -strace the running smbd daemon. The way I tend ot use it is to first -login from my Windows PC to the Samba server, then use smbstatus to -find which process ID that client is attached to, then as root I do -"strace -p PID" to attach to that process. I normally redirect the -stderr output from this command to a file for later perusal. For -example, if I'm using a csh style shell: - - strace -f -p 3872 >& strace.out - -or with a sh style shell: - - strace -f -p 3872 > strace.out 2>&1 - -Note the "-f" option. This is only available on some systems, and -allows you to trace not just the current process, but any children it -forks. This is great for finding printing problems caused by the -"print command" being wrong. - -Once you are attached you then can do whatever it is on the client -that is causing problems and you will capture all the system calls -that smbd makes. - -So how do you interpret the results? Generally I search through the -output for strings that I know will appear when the problem -happens. For example, if I am having touble with permissions on a file -I would search for that files name in the strace output and look at -the surrounding lines. Another trick is to match up file descriptor -numbers and "follow" what happens to an open file until it is closed. - -Beyond this you will have to use your initiative. To give you an idea -of wehat you are looking for here is a piece of strace output that -shows that /dev/null is not world writeable, which causes printing to -fail with Samba: - -[pid 28268] open("/dev/null", O_RDWR) = -1 EACCES (Permission denied) -[pid 28268] open("/dev/null", O_WRONLY) = -1 EACCES (Permission denied) - -the process is trying to first open /dev/null read-write then -read-only. Both fail. This means /dev/null has incorrect permissions. - -Have fun! - -(please send updates/fixes to this file to samba@samba.org) diff --git a/docs/textdocs/UNIX-SMB.txt b/docs/textdocs/UNIX-SMB.txt deleted file mode 100644 index c3d7643cbc..0000000000 --- a/docs/textdocs/UNIX-SMB.txt +++ /dev/null @@ -1,231 +0,0 @@ -Contributor: Andrew Tridgell <samba@samba.org> -Date: April 1995 - -Subject: Discussion of NetBIOS in a Unix World -============================================================================ - -This is a short document that describes some of the issues that -confront a SMB implementation on unix, and how Samba copes with -them. They may help people who are looking at unix<->PC -interoperability. - -It was written to help out a person who was writing a paper on unix to -PC connectivity. - - -Usernames -========= - -The SMB protocol has only a loose username concept. Early SMB -protocols (such as CORE and COREPLUS) have no username concept at -all. Even in later protocols clients often attempt operations -(particularly printer operations) without first validating a username -on the server. - -Unix security is based around username/password pairs. A unix box -should not allow clients to do any substantive operation without some -sort of validation. - -The problem mostly manifests itself when the unix server is in "share -level" security mode. This is the default mode as the alternative -"user level" security mode usually forces a client to connect to the -server as the same user for each connected share, which is -inconvenient in many sites. - -In "share level" security the client normally gives a username in the -"session setup" protocol, but does not supply an accompanying -password. The client then connects to resources using the "tree -connect" protocol, and supplies a password. The problem is that the -user on the PC types the username and the password in different -contexts, unaware that they need to go together to give access to the -server. The username is normally the one the user typed in when they -"logged onto" the PC (this assumes Windows for Workgroups). The -password is the one they chose when connecting to the disk or printer. - -The user often chooses a totally different username for their login as -for the drive connection. Often they also want to access different -drives as different usernames. The unix server needs some way of -divining the correct username to combine with each password. - -Samba tries to avoid this problem using several methods. These succeed -in the vast majority of cases. The methods include username maps, the -service%user syntax, the saving of session setup usernames for later -validation and the derivation of the username from the service name -(either directly or via the user= option). - -File Ownership -============== - -The commonly used SMB protocols have no way of saying "you can't do -that because you don't own the file". They have, in fact, no concept -of file ownership at all. - -This brings up all sorts of interesting problems. For example, when -you copy a file to a unix drive, and the file is world writeable but -owned by another user the file will transfer correctly but will -receive the wrong date. This is because the utime() call under unix -only succeeds for the owner of the file, or root, even if the file is -world writeable. For security reasons Samba does all file operations -as the validated user, not root, so the utime() fails. This can stuff -up shared development diectories as programs like "make" will not get -file time comparisons right. - -There are several possible solutions to this problem, including -username mapping, and forcing a specific username for particular -shares. - -Passwords -========= - -Many SMB clients uppercase passwords before sending them. I have no -idea why they do this. Interestingly WfWg uppercases the password only -if the server is running a protocol greater than COREPLUS, so -obviously it isn't just the data entry routines that are to blame. - -Unix passwords are case sensitive. So if users use mixed case -passwords they are in trouble. - -Samba can try to cope with this by either using the "password level" -option which causes Samba to try the offered password with up to the -specified number of case changes, or by using the "password server" -option which allows Samba to do its validation via another machine -(typically a WinNT server). - -Samba supports the password encryption method used by SMB -clients. Note that the use of password encryption in Microsoft -networking leads to password hashes that are "plain text equivalent". -This means that it is *VERY* important to ensure that the Samba -smbpasswd file containing these password hashes is only readable -by the root user. See the documentation ENCRYPTION.txt for more -details. - - -Locking -======= - -The locking calls available under a DOS/Windows environment are much -richer than those available in unix. This means a unix server (like -Samba) choosing to use the standard fcntl() based unix locking calls -to implement SMB locking has to improvise a bit. - -One major problem is that dos locks can be in a 32 bit (unsigned) -range. Unix locking calls are 32 bits, but are signed, giving only a 31 -bit range. Unfortunately OLE2 clients use the top bit to select a -locking range used for OLE semaphores. - -To work around this problem Samba compresses the 32 bit range into 31 -bits by appropriate bit shifting. This seems to work but is not -ideal. In a future version a separate SMB lockd may be added to cope -with the problem. - -It also doesn't help that many unix lockd daemons are very buggy and -crash at the slightest provocation. They normally go mostly unused in -a unix environment because few unix programs use byte range -locking. The stress of huge numbers of lock requests from dos/windows -clients can kill the daemon on some systems. - -The second major problem is the "opportunistic locking" requested by -some clients. If a client requests opportunistic locking then it is -asking the server to notify it if anyone else tries to do something on -the same file, at which time the client will say if it is willing to -give up its lock. Unix has no simple way of implementing -opportunistic locking, and currently Samba has no support for it. - -Deny Modes -========== - -When a SMB client opens a file it asks for a particular "deny mode" to -be placed on the file. These modes (DENY_NONE, DENY_READ, DENY_WRITE, -DENY_ALL, DENY_FCB and DENY_DOS) specify what actions should be -allowed by anyone else who tries to use the file at the same time. If -DENY_READ is placed on the file, for example, then any attempt to open -the file for reading should fail. - -Unix has no equivalent notion. To implement this Samba uses either lock -files based on the files inode and placed in a separate lock -directory or a shared memory implementation. The lock file method -is clumsy and consumes processing and file resources, -the shared memory implementation is vastly prefered and is turned on -by default for those systems that support it. - -Trapdoor UIDs -============= - -A SMB session can run with several uids on the one socket. This -happens when a user connects to two shares with different -usernames. To cope with this the unix server needs to switch uids -within the one process. On some unixes (such as SCO) this is not -possible. This means that on those unixes the client is restricted to -a single uid. - -Note that you can also get the "trapdoor uid" message for other -reasons. Please see the FAQ for details. - -Port numbers -============ - -There is a convention that clients on sockets use high "unprivilaged" -port numbers (>1000) and connect to servers on low "privilaged" port -numbers. This is enforced in Unix as non-root users can't open a -socket for listening on port numbers less than 1000. - -Most PC based SMB clients (such as WfWg and WinNT) don't follow this -convention completely. The main culprit is the netbios nameserving on -udp port 137. Name query requests come from a source port of 137. This -is a problem when you combine it with the common firewalling technique -of not allowing incoming packets on low port numbers. This means that -these clients can't query a netbios nameserver on the other side of a -low port based firewall. - -The problem is more severe with netbios node status queries. I've -found that WfWg, Win95 and WinNT3.5 all respond to netbios node status -queries on port 137 no matter what the source port was in the -request. This works between machines that are both using port 137, but -it means it's not possible for a unix user to do a node status request -to any of these OSes unless they are running as root. The answer comes -back, but it goes to port 137 which the unix user can't listen -on. Interestingly WinNT3.1 got this right - it sends node status -responses back to the source port in the request. - - -Protocol Complexity -=================== - -There are many "protocol levels" in the SMB protocol. It seems that -each time new functionality was added to a Microsoft operating system, -they added the equivalent functions in a new protocol level of the SMB -protocol to "externalise" the new capabilities. - -This means the protocol is very "rich", offering many ways of doing -each file operation. This means SMB servers need to be complex and -large. It also means it is very difficult to make them bug free. It is -not just Samba that suffers from this problem, other servers such as -WinNT don't support every variation of every call and it has almost -certainly been a headache for MS developers to support the myriad of -SMB calls that are available. - -There are about 65 "top level" operations in the SMB protocol (things -like SMBread and SMBwrite). Some of these include hundreds of -sub-functions (SMBtrans has at least 120 sub-functions, like -DosPrintQAdd and NetSessionEnum). All of them take several options -that can change the way they work. Many take dozens of possible -"information levels" that change the structures that need to be -returned. Samba supports all but 2 of the "top level" functions. It -supports only 8 (so far) of the SMBtrans sub-functions. Even NT -doesn't support them all. - -Samba currently supports up to the "NT LM 0.12" protocol, which is the -one preferred by Win95 and WinNT3.5. Luckily this protocol level has a -"capabilities" field which specifies which super-duper new-fangled -options the server suports. This helps to make the implementation of -this protocol level much easier. - -There is also a problem with the SMB specications. SMB is a X/Open -spec, but the X/Open book is far from ideal, and fails to cover many -important issues, leaving much to the imagination. Microsoft recently -renamed the SMB protocol CIFS (Common Internet File System) and have -published new specifications. These are far superior to the old -X/Open documents but there are still undocumented calls and features. -This specification is actively being worked on by a CIFS developers -mailing list hosted by Microsft. - diff --git a/docs/textdocs/cifsntdomain.txt b/docs/textdocs/cifsntdomain.txt deleted file mode 100644 index 643b8957c9..0000000000 --- a/docs/textdocs/cifsntdomain.txt +++ /dev/null @@ -1,1498 +0,0 @@ -NT Domain Authentication ------------------------- - -Authors: - Luke Kenneth Casson Leighton (lkcl@switchboard.net) --------- - 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.024 (01Nov97) --------- - -Distribution: Unlimited and encouraged, for the purposes of implementation -------------- and comments. Feedback welcomed by the authors. - -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 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 - which the authors accept no liability (see above). Please - contact your vendor if you have any problems. - -Sources: - Packet Traces from Netmonitor (Service Pack 1 and above) --------- - Paul Ashton and Luke Leighton's other "NT Domain" doc. - - CIFS documentation - cifs6.txt - - CIFS documentation - cifsrap2.txt - -Original: http://mailhost.cb1.com/~lkcl/cifsntdomain.txt. ---------- (Controlled copy maintained by lkcl@switchboard.net) - -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 - - -Contents: ---------- - - 1) Introduction - - 2) Structures and notes - - 2.1) Notes - 2.3) Enumerations - 2.3) Structures - - 3) Transact Named Pipe Header/Tail - - 3.1) MSRPC Pipes - 3.2) Header - 3.3) Tail - - 4) NTLSA Transact Named Pipe - - 4.1) LSA Open Policy - 4.2) LSA Query Info Policy - 4.3) LSA Enumerate Trusted Domains - 4.4) LSA Open Secret - 4.5) LSA Close - 4.6) LSA Lookup SIDS - 4.7) LSA Lookup Names - - 5) NETLOGON rpc Transact Named Pipe - - 5.1) LSA Request Challenge - 5.2) LSA Authenticate 2 - 5.3) LSA Server Password Set - 5.4) LSA SAM Logon - 5.5) LSA SAM Logoff - - 6) \\MAILSLOT\NET\NTLOGON - - 6.1) Query for PDC - 6.2) SAM Logon - - 7) SRVSVC Transact Named Pipe - - 7.1) Net Share Enum - 7.2) Net Server Get Info - - -Appendix: ---------- - - A1) Cryptographic side of NT Domain Authentication - - A1.1) Definitions - A1.2) Protocol - A1.3) Comments - - A2) SIDs and RIDs - - A2.1) Well-known SIDs - - A2.1.1) Universal well-known SIDs - A2.1.2) NT well-known SIDs - - A2.2) Well-known RIDS - - A2.2.1) Well-known RID users - A2.2.2) Well-known RID groups - A2.2.3) Well-known RID aliases - - - -1) Introduction ---------------- - - -This document contains information to provide an NT workstation with login -services, without the need for an NT server. - -It should be possible to select a domain instead of a workgroup (in the NT -workstation's TCP/IP settings) and after the obligatory reboot, type in a -username, password, select a domain and successfully log in. I would -appreciate any feedback on your experiences with this process, and any -comments, corrections and additions to this document. - - -The packets described here can be easily derived from (and are probably -better understood using) Netmon.exe. You will need to use the version -of Netmon that matches your system, in order to correctly decode the -NETLOGON, lsarpc and srvsvc Transact pipes. This document is derived from -NT Service Pack 1 and its corresponding version of Netmon. It is intended -that an annotated packet trace be produced, which will likely be more -instructive than this document. - -Also needed, to fully implement NT Domain Login Services, is the -document describing the cryptographic part of the NT authentication. -This document is available from comp.protocols.smb; from the ntsecurity.net -digest and from the samba digest, amongst other sources. - -A copy is available from: - -http://ntbugtraq.rc.on.ca/SCRIPTS/WA.EXE?A2=ind9708&L=ntbugtraq&O=A&P=2935 -http://mailhost.cb1.com/~lkcl/crypt.html - - -A c-code implementation, provided by Linus Nordberg <linus@incolumitas.se> -of this protocol is available from: - -http://samba.org/cgi-bin/mfs/01/digest/1997/97aug/0391.html -http://mailhost.cb1.com/~lkcl/crypt.txt - - -Also used to provide debugging information is the Check Build version of -NT workstation, and enabling full debugging in NETLOGON. This is -achieved by setting the following REG_SZ registry key to 0x1ffffff: - -HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters - -- Incorrect direct editing of the registry can cause your machine to fail. - Then again, so can incorrect implementation of this protocol. - See "Liability:" above. - - -Bear in mind that each packet over-the-wire will have its origin in an -API call. Therefore, there are likely to be structures, enumerations -and defines that are usefully documented elsewhere. - - -This document is by no means complete or authoritative. Missing sections -include, but are not limited to: - -- the meaning (and use by NT) of SIDs and RIDs. - -- mappings of RIDs to usernames (and vice-versa). - -- what a User ID is and what a Group ID is. - -- the exact meaning/definition of various magic constants or enumerations. - -- the reply error code and use of that error code when a workstation - becomes a member of a domain (to be described later). Failure to - return this error code will make the workstation report that it is - already a member of the domain. - -- the cryptographic side of the NetrServerPasswordSet command, which would - allow the workstation to change its password. This password is used to - generate the long-term session key. [It is possible to reject this - command, and keep the default workstation password]. - - -2) Notes and Structures ------------------------ - - -2.1) Notes ----------- - -- In the SMB Transact pipes, some "Structures", described here, appear to be - 4-byte aligned with the SMB header, at their start. Exactly which - "Structures" need aligning is not precisely known or documented. - -- In the UDP NTLOGON Mailslots, some "Structures", described here, appear to be - 2-byte aligned with the start of the mailslot, at their start. - -- Domain SID is of the format S-revision-version-auth1-auth2...authN. - e.g S-1-5-123-456-789-123-456. the 5 could be a sub-revision. - -- any undocumented buffer pointers must be non-zero if the string buffer it - refers to contains characters. exactly what value they should be is unknown. - 0x0000 0002 seems to do the trick to indicate that the buffer exists. a - NULL buffer pointer indicates that the string buffer is of zero length. - If the buffer pointer is NULL, then it is suspected that the structure it - refers to is NOT put into (or taken out of) the SMB data stream. This is - empirically derived from, for example, the LSA SAM Logon response packet, - where if the buffer pointer is NULL, the user information is not inserted - into the data stream. Exactly what happens with an array of buffer pointers - is not known, although an educated guess can be made. - -- an array of structures (a container) appears to have a count and a pointer. - if the count is zero, the pointer is also zero. no further data is put - into or taken out of the SMB data stream. if the count is non-zero, then - the pointer is also non-zero. immediately following the pointer is the - count again, followed by an array of container sub-structures. the count - 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.3) Structures ---------------- - -- sizeof VOID* is 32 bits. - -- sizeof char is 8 bits. - -- UTIME is 32 bits, indicating time in seconds since 01jan1970. documented - in cifs6.txt (section 3.5 page, page 30). - -- NTTIME is 64 bits. documented in cifs6.txt (section 3.5 page, page 30). - -- DOM_SID (domain SID structure) : - - UINT32 num of sub-authorities in domain SID - UINT8 SID revision number - UINT8 num of sub-authorities in domain SID - UINT8[6] 6 bytes for domain SID - Identifier Authority. - UINT16[n_subauths] domain SID sub-authorities - - Note: the domain SID is documented elsewhere. - -- STR (string) : - - char[] null-terminated string of ascii characters. - -- UNIHDR (unicode string header) : - - UINT16 length of unicode string - UINT16 max length of unicode string - UINT32 4 - undocumented. - -- UNIHDR2 (unicode string header plus buffer pointer) : - - UNIHDR unicode string header - VOID* undocumented buffer pointer - -- UNISTR (unicode string) : - - UINT16[] null-terminated string of unicode characters. - -- NAME (length-indicated unicode string) : - - UINT32 length of unicode string - UINT16[] null-terminated string of unicode characters. - -- UNISTR2 (aligned unicode string) : - - UINT8[] padding to get unicode string 4-byte aligned - with the start of the SMB header. - UINT32 max length of unicode string - UINT32 0 - undocumented - 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 - -- DOM_SID2 (domain SID structure, SIDS stored in unicode) : - - UINT32 5 - SID type - UINT32 0 - undocumented - UNIHDR2 domain SID unicode string header - UNISTR domain SID unicode string - - Note: there is a conflict between the unicode string header and the - unicode string itself as to which to use to indicate string - length. this will need to be resolved. - - Note: the SID type indicates, for example, an alias; a well-known group etc. - this is documented somewhere. - -- DOM_RID (domain RID structure) : - - UINT32 5 - well-known SID. 1 - user SID (see ShowACLs) - UINT32 5 - undocumented - UINT32 domain RID - UINT32 0 - domain index out of above reference domains - - -- LOG_INFO (server, account, client structure) : - - Note: logon server name starts with two '\' characters and is upper case. - - Note: account name is the logon client name from the LSA Request Challenge, - with a $ on the end of it, in upper case. - - VOID* undocumented buffer pointer - UNISTR2 logon server unicode string - UNISTR2 account name unicode string - UINT16 sec_chan - security channel type - UNISTR2 logon client machine unicode string - -- CLNT_SRV (server, client names structure) : - - Note: logon server name starts with two '\' characters and is upper case. - - VOID* undocumented buffer pointer - UNISTR2 logon server unicode string - VOID* undocumented buffer pointer - UNISTR2 logon client machine unicode string - -- CREDS (credentials + time stamp) - - char[8] credentials - UTIME time stamp - -- CLNT_INFO2 (server, client structure, client credentials) : - - Note: whenever this structure appears in a request, you must take a copy - of the client-calculated credentials received, because they will be - used in subsequent credential checks. the presumed intention is to - maintain an authenticated request/response trail. - - CLNT_SRV client and server names - UINT8[] ???? padding, for 4-byte alignment with SMB header. - VOID* pointer to client credentials. - CREDS client-calculated credentials + client time - -- CLNT_INFO (server, account, client structure, client credentials) : - - Note: whenever this structure appears in a request, you must take a copy - of the client-calculated credentials received, because they will be - used in subsequent credential checks. the presumed intention is to - maintain an authenticated request/response trail. - - LOG_INFO logon account info - CREDS client-calculated credentials + client time - -- ID_INFO_1 (id info structure, auth level 1) : - - VOID* ptr_id_info_1 - UNIHDR domain name unicode header - UINT32 param control - UINT64 logon ID - UNIHDR user name unicode header - UNIHDR workgroup name unicode header - char[16] arc4 LM OWF Password - char[16] arc4 NT OWF Password - UNISTR2 domain name unicode string - UNISTR2 user name unicode string - UNISTR2 workstation name unicode string - -- SAM_INFO (sam logon/logoff id info structure) : - - Note: presumably, the return credentials is supposedly for the server to - verify that the credential chain hasn't been compromised. - - CLNT_INFO2 client identification/authentication info - VOID* pointer to return credentials. - CRED return credentials - ignored. - UINT16 logon level - UINT16 switch value - - switch (switch_value) - case 1: - { - ID_INFO_1 id_info_1; - } - -- GID (group id info) : - - UINT32 group id - UINT32 user attributes (only used by NT 3.1 and 3.51) - -- DOM_REF (domain reference info) : - - VOID* undocumented buffer pointer. - UINT32 num referenced domains? - VOID* undocumented domain name buffer pointer. - UINT32 32 - max number of entries - UINT32 4 - num referenced domains? - - UNIHDR2 domain name unicode string header - UNIHDR2[num_ref_doms-1] referenced domain unicode string headers - - UNISTR domain name unicode string - DOM_SID[num_ref_doms] referenced domain SIDs - -- DOM_INFO (domain info, levels 3 and 5 are the same)) : - - UINT8[] ??? padding to get 4-byte alignment with start of SMB header - UINT16 domain name string length * 2 - UINT16 domain name string length * 2 - VOID* undocumented domain name string buffer pointer - VOID* undocumented domain SID string buffer pointer - UNISTR2 domain name (unicode string) - DOM_SID domain SID - -- USER_INFO (user logon info) : - - Note: it would be nice to know what the 16 byte user session key is for. - - NTTIME logon time - NTTIME logoff time - NTTIME kickoff time - NTTIME password last set time - NTTIME password can change time - NTTIME password must change time - - UNIHDR username unicode string header - UNIHDR user's full name unicode string header - UNIHDR logon script unicode string header - UNIHDR profile path unicode string header - UNIHDR home directory unicode string header - UNIHDR home directory drive unicode string header - - UINT16 logon count - UINT16 bad password count - - UINT32 User ID - UINT32 Group ID - UINT32 num groups - VOID* undocumented buffer pointer to groups. - - UINT32 user flags - char[16] user session key - - UNIHDR logon server unicode string header - UNIHDR logon domain unicode string header - VOID* undocumented logon domain id pointer - char[40] 40 undocumented padding bytes. future expansion? - - UINT32 0 - num_other_sids? - VOID* NULL - undocumented pointer to other domain SIDs. - - UNISTR2 username unicode string - UNISTR2 user's full name unicode string - UNISTR2 logon script unicode string - UNISTR2 profile path unicode string - UNISTR2 home directory unicode string - UNISTR2 home directory drive unicode string - - UINT32 num groups - GID[num_groups] group info - - UNISTR2 logon server unicode string - UNISTR2 logon domain unicode string - - DOM_SID domain SID - DOM_SID[num_sids] other domain SIDs? - -- SH_INFO_1_PTR (pointers to level 1 share info strings): - -Note: see cifsrap2.txt section5, page 10. - - 0 for shi1_type indicates a Disk. - 1 for shi1_type indicates a Print Queue. - 2 for shi1_type indicates a Device. - 3 for shi1_type indicates an IPC pipe. - 0x8000 0000 (top bit set in shi1_type) indicates a hidden share. - - VOID* shi1_netname - pointer to net name - UINT32 shi1_type - type of share. 0 - undocumented. - VOID* shi1_remark - pointer to comment. - -- SH_INFO_1_STR (level 1 share info strings) : - - UNISTR2 shi1_netname - unicode string of net name - UNISTR2 shi1_remark - unicode string of comment. - -- SHARE_INFO_1_CTR : - - share container with 0 entries: - - UINT32 0 - EntriesRead - UINT32 0 - Buffer - - share container with > 0 entries: - - UINT32 EntriesRead - UINT32 non-zero - Buffer - UINT32 EntriesRead - - SH_INFO_1_PTR[EntriesRead] share entry pointers - SH_INFO_1_STR[EntriesRead] share entry strings - - UINT8[] padding to get unicode string 4-byte - aligned with start of the SMB header. - UINT32 EntriesRead - UINT32 0 - padding - -- SERVER_INFO_101 : - -Note: see cifs6.txt section 6.4 - the fields described therein will be - of assistance here. for example, the type listed below is the - same as fServerType, which is described in 6.4.1. - - SV_TYPE_WORKSTATION 0x00000001 All workstations - SV_TYPE_SERVER 0x00000002 All servers - SV_TYPE_SQLSERVER 0x00000004 Any server running with SQL - server - SV_TYPE_DOMAIN_CTRL 0x00000008 Primary domain controller - SV_TYPE_DOMAIN_BAKCTRL 0x00000010 Backup domain controller - SV_TYPE_TIME_SOURCE 0x00000020 Server running the timesource - service - SV_TYPE_AFP 0x00000040 Apple File Protocol servers - SV_TYPE_NOVELL 0x00000080 Novell servers - SV_TYPE_DOMAIN_MEMBER 0x00000100 Domain Member - SV_TYPE_PRINTQ_SERVER 0x00000200 Server sharing print queue - SV_TYPE_DIALIN_SERVER 0x00000400 Server running dialin service. - SV_TYPE_XENIX_SERVER 0x00000800 Xenix server - SV_TYPE_NT 0x00001000 NT server - SV_TYPE_WFW 0x00002000 Server running Windows for - - SV_TYPE_SERVER_NT 0x00008000 Windows NT non DC server - SV_TYPE_POTENTIAL_BROWSER 0x00010000 Server that can run the browser - service - SV_TYPE_BACKUP_BROWSER 0x00020000 Backup browser server - SV_TYPE_MASTER_BROWSER 0x00040000 Master browser server - SV_TYPE_DOMAIN_MASTER 0x00080000 Domain Master Browser server - SV_TYPE_LOCAL_LIST_ONLY 0x40000000 Enumerate only entries marked - "local" - SV_TYPE_DOMAIN_ENUM 0x80000000 Enumerate Domains. The pszServer - and pszDomain parameters must be - NULL. - - UINT32 500 - platform_id - VOID* pointer to name - UINT32 5 - major version - UINT32 4 - minor version - UINT32 type (SV_TYPE_... bit field) - VOID* pointer to comment - - UNISTR2 sv101_name - unicode string of server name - UNISTR2 sv_101_comment - unicode string of server comment. - - UINT8[] padding to get unicode string 4-byte - aligned with start of the SMB header. - - - -3) MSRPC over Transact Named Pipe ---------------------------------- - -For details on the SMB Transact Named Pipe, see cifs6.txt - - -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 either -0x0026 to indicate an RPC, or 0x0001 to indicate Set Named Pipe Handle -state. The second UINT16 parameter must be the file handle for the pipe, -obtained above. - -The Data section for an API Command of 0x0026 (RPC pipe) in the Trans -Request is the RPC Header, followed by the RPC Data. The Data section for -an API Command of 0x0001 (Set Named Pipe Handle state) is two bytes. The -only value seen for these two bytes is 0x00 0x43. - - -MSRPC Responses are sent as response data inside standard SMB Trans -responses, with the MSRPC Header, MSRPC Data and MSRPC tail. - - -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. - - -First, an SMBtconX connection is made to the IPC$ share. The connection -must be made using encrypted passwords, not clear-text. Then, an SMBopenX -is made on the pipe. Then, a Set Named Pipe Handle State must be sent, -after which the pipe is ready to accept API commands. Lastly, and SMBclose -is sent. - - -To be resolved: - - lkcl/01nov97 there appear to be two additional bytes after the null- - terminated \PIPE\ name for the RPC pipe. Values seen so far are - listed below: - - initial SMBopenX request: RPC API command 0x26 params: - - "\\PIPE\\lsarpc" 0x65 0x63; 0x72 0x70; 0x44 0x65; - "\\PIPE\\srvsvc" 0x73 0x76; 0x4E 0x00; 0x5C 0x43; - - -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 - (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 -0C UINT32 call identifier. matches 12th UINT32 of incoming RPC data. -10 UINT32 allocation hint - data size (bytes) minus header and tail. -14 UINT16 0 - presentation context identifier -16 UINT8 0 - cancel count -17 UINT8 in replies: 0 - reserved; in requests: opnum - see #defines. -18 ...... start of data (goes on for allocation_hint bytes) - - -RPC_Packet for request, response, bind and bind acknowledgement. -{ - - 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) -RPC_Iface 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 -RPC_ReqBind 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[] # 4-byte alignment padding, against SMB header - - * abstractint USE RPC_Iface # num and vers. of interface client is using - * transferint USE RPC_Iface # num and vers. of interface to use for replies -} - - -RPC_Address 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 -RPC_ResBind RW -{ - UINT16 maxtsize # same as request - UINT16 maxrsize # same as request - UINT32 assocgid # zero - - * secondaddr USE RPC_Address # the address string, as described earlier - - UINT8[] # 4-byte alignment padding, against SMB header - - 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 RPC_Iface # the transfer syntax from the request -} - - -# the remainder of the packet after the header for every other other -# request -RPC_ReqNorm 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 -RPC_ResNorm 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: - - ...... end of data - UINT32 return code - - - -3.4 RPC Bind / Bind Ack ------------------------ - -RPC Binds are the process of associating an RPC pipe (e.g \PIPE\lsarpc) -with a "transfer syntax" (see RPC_Iface structure). The purpose for doing -this is unknown. - -Note: The RPC_ResBind SMB Transact request is sent with two uint16 setup - parameters. The first is 0x0026; the second is the file handle - returned by the SMBopenX Transact response. - -Note: The RPC_ResBind members maxtsize, maxrsize and assocgid are the - same in the response as the same members in the RPC_ReqBind. The - RPC_ResBind member transfersyntax is the same in the response as - the - -Note: The RPC_ResBind response member secondaddr contains the name - of what is presumed to be the service behind the RPC pipe. The - mapping identified so far is: - - initial SMBopenX request: RPC_ResBind response: - - "\\PIPE\\srvsvc" "\\PIPE\\ntsvcs" - "\\PIPE\\samr" "\\PIPE\\lsass" - "\\PIPE\\lsarpc" "\\PIPE\\lsass" - "\\PIPE\\wkssvc" "\\PIPE\\wksvcs" - "\\PIPE\\NETLOGON" "\\PIPE\\NETLOGON" - -Note: The RPC_Packet fraglength member in both the Bind Request and Bind - Acknowledgment must contain the length of the entire RPC data, - including the RPC_Packet header. - -Request: - - RPC_Packet - RPC_ReqBind - -Response: - - RPC_Packet - RPC_ResBind - - - -4) NTLSA Transact Named Pipe ----------------------------- - -The sequence of actions taken on this pipe are: - -- Establish a connection to the IPC$ share (SMBtconX). use encrypted passwords. -- Open an RPC Pipe with the name "\\PIPE\\lsarpc". Store the file handle. -- Using the file handle, send a Set Named Pipe Handle state to 0x4300. -- Send an LSA Open Policy request. Store the Policy Handle. -- Using the Policy Handle, send LSA Query Info Policy requests, etc. -- Using the Policy Handle, send an LSA Close. -- Close the IPC$ share. - - -Defines for this pipe, identifying the query are: - -- LSA Open Policy: 0x2c -- LSA Query Info Policy: 0x07 -- LSA Enumerate Trusted Domains: 0x0d -- LSA Open Secret: 0xff -- LSA Lookup SIDs: 0xfe -- LSA Lookup Names: 0xfd -- LSA Close: 0x00 - - -4.1) LSA Open Policy --------------------- - -Note: The policy handle can be anything you like. - -Request: - - VOID* buffer pointer - UNISTR2 server name - unicode string starting with two '\'s - OBJ_ATTR object attributes - UINT32 1 - desired access - -Response: - - POL_HND LSA policy handle - - return 0 - indicates success - - -4.2) LSA Query Info Policy --------------------------- - -Note: The info class in response must be the same as that in the request. - -Request: - - POL_HND LSA policy handle - UINT16 info class (also a policy handle?) - -Response: - - VOID* undocumented buffer pointer - UINT16 info class (same as info class in request). - - switch (info class) - case 3: - case 5: - { - DOM_INFO domain info, levels 3 and 5 (are the same). - } - - return 0 - indicates success - - -4.3) LSA Enumerate Trusted Domains ----------------------------------- - -Request: - - no extra data - -Response: - - UINT32 0 - enumeration context - UINT32 0 - entries read - UINT32 0 - trust information - - return 0x8000 001a - "no trusted domains" success code - - -4.4) LSA Open Secret --------------------- - -Request: - - no extra data - -Response: - - UINT32 0 - undocumented - UINT32 0 - undocumented - UINT32 0 - undocumented - UINT32 0 - undocumented - UINT32 0 - undocumented - - return 0x0C00 0034 - "no such secret" success code - - -4.5) LSA Close --------------- - -Request: - - POL_HND policy handle to be closed - -Response: - - POL_HND 0s - closed policy handle (all zeros) - - return 0 - indicates success - - -4.6) LSA Lookup SIDS --------------------- - -Note: num_entries in response must be same as num_entries in request. - -Request: - - POL_HND LSA policy handle - UINT32 num_entries - VOID* undocumented domain SID buffer pointer - VOID* undocumented domain name buffer pointer - VOID*[num_entries] undocumented domain SID pointers to be looked up. - DOM_SID[num_entries] domain SIDs to be looked up. - char[16] completely undocumented 16 bytes. - -Response: - - DOM_REF domain reference response - - UINT32 num_entries (listed above) - VOID* undocumented buffer pointer - - UINT32 num_entries (listed above) - DOM_SID2[num_entries] domain SIDs (from Request, listed above). - - UINT32 num_entries (listed above) - - return 0 - indicates success - - -4.7) LSA Lookup Names ---------------------- - -Note: num_entries in response must be same as num_entries in request. - -Request: - - POL_HND LSA policy handle - UINT32 num_entries - UINT32 num_entries - VOID* undocumented domain SID buffer pointer - VOID* undocumented domain name buffer pointer - NAME[num_entries] names to be looked up. - char[] undocumented bytes - falsely translated SID structure? - -Response: - - DOM_REF domain reference response - - UINT32 num_entries (listed above) - VOID* undocumented buffer pointer - - UINT32 num_entries (listed above) - DOM_RID[num_entries] domain SIDs (from Request, listed above). - - UINT32 num_entries (listed above) - - return 0 - indicates success - - - -5) NETLOGON rpc Transact Named Pipe ------------------------------------ - -The sequence of actions taken on this pipe are: - -- Establish a connection to the IPC$ share (SMBtconX). use encrypted passwords. -- Open an RPC Pipe with the name "\\PIPE\\NETLOGON". Store the file handle. -- Using the file handle, send a Set Named Pipe Handle state to 0x4300. -- Create Client Challenge. Send LSA Request Challenge. Store Server Challenge. -- Calculate Session Key. Send an LSA Auth 2 Challenge. Store Auth2 Challenge. -- Calc/Verify Client Creds. Send LSA Srv PW Set. Calc/Verify Server Creds. -- Calc/Verify Client Creds. Send LSA SAM Logon . Calc/Verify Server Creds. -- Calc/Verify Client Creds. Send LSA SAM Logoff. Calc/Verify Server Creds. -- Close the IPC$ share. - - -Defines for this pipe, identifying the query are: - -- LSA Request Challenge: 0x04 -- LSA Server Password Set: 0x06 -- LSA SAM Logon: 0x02 -- LSA SAM Logoff: 0x03 -- LSA Auth 2: 0x0f -- LSA Logon Control: 0x0e - - -5.1) LSA Request Challenge --------------------------- - -Note: logon server name starts with two '\' characters and is upper case. - -Note: logon client is the machine, not the user. - -Note: the initial LanManager password hash, against which the challenge - is issued, is the machine name itself (lower case). there will be - calls issued (LSA Server Password Set) which will change this, later. - refusing these calls allows you to always deal with the same password - (i.e the LM# of the machine name in lower case). - -Request: - - VOID* undocumented buffer pointer - UNISTR2 logon server unicode string - UNISTR2 logon client unicode string - char[8] client challenge - -Response: - - char[8] server challenge - - return 0 - indicates success - - - -5.2) LSA Authenticate 2 ------------------------ - -Note: in between request and response, calculate the client credentials, - and check them against the client-calculated credentials (this - process uses the previously received client credentials). - -Note: neg_flags in the response is the same as that in the request. - -Note: you must take a copy of the client-calculated credentials received - here, because they will be used in subsequent authentication packets. - -Request: - - LOG_INFO client identification info - - char[8] client-calculated credentials - UINT8[] padding to 4-byte align with start of SMB header. - UINT32 neg_flags - negotiated flags (usual value is 0x0000 01ff) - -Response: - - char[8] server credentials. - UINT32 neg_flags - same as neg_flags in request. - - return 0 - indicates success. failure value unknown. - - -5.3) LSA Server Password Set ----------------------------- - -Note: the new password is suspected to be a DES encryption using the old - password to generate the key. - -Note: in between request and response, calculate the client credentials, - and check them against the client-calculated credentials (this - process uses the previously received client credentials). - -Note: the server credentials are constructed from the client-calculated - credentials and the client time + 1 second. - -Note: you must take a copy of the client-calculated credentials received - here, because they will be used in subsequent authentication packets. - -Request: - - CLNT_INFO client identification/authentication info - char[] new password - undocumented. - -Response: - - CREDS server credentials. server time stamp appears to be ignored. - - return 0 - indicates success; 0xC000 006a indicates failure - - -5.4) LSA SAM Logon ------------------- - -Note: valid_user is True iff the username and password hash are valid for - the requested domain. - -Request: - - SAM_INFO sam_id structure - -Response: - - VOID* undocumented buffer pointer - CREDS server credentials. server time stamp appears to be ignored. - - if (valid_user) - { - UINT16 3 - switch value indicating USER_INFO structure. - VOID* non-zero - pointer to USER_INFO structure - USER_INFO user logon information - - UINT32 1 - Authoritative response; 0 - Non-Auth? - - return 0 - indicates success - } - else - { - UINT16 0 - switch value. value to indicate no user presumed. - VOID* 0x0000 0000 - indicates no USER_INFO structure. - - UINT32 1 - Authoritative response; 0 - Non-Auth? - - return 0xC000 0064 - NT_STATUS_NO_SUCH_USER. - } - - -5.5) LSA SAM Logoff --------------------- - -Note: presumably, the SAM_INFO structure is validated, and a (currently - undocumented) error code returned if the Logoff is invalid. - -Request: - - SAM_INFO sam_id structure - -Response: - - VOID* undocumented buffer pointer - CREDS server credentials. server time stamp appears to be ignored. - - return 0 - indicates success. undocumented failure indication. - - -6) \\MAILSLOT\NET\NTLOGON -------------------------- - -Note: mailslots will contain a response mailslot, to which the response - should be sent. the target NetBIOS name is REQUEST_NAME<20>, where - REQUEST_NAME is the name of the machine that sent the request. - - -6.1) Query for PDC ------------------- - -Note: NTversion, LMNTtoken, LM20token in response are the same as those - given in the request. - -Request: - - UINT16 0x0007 - Query for PDC - STR machine name - STR response mailslot - UINT8[] padding to 2-byte align with start of mailslot. - UNISTR machine name - UINT32 NTversion - UINT16 LMNTtoken - UINT16 LM20token - -Response: - - UINT16 0x000A - Respose to Query for PDC - STR machine name (in uppercase) - UINT8[] padding to 2-byte align with start of mailslot. - UNISTR machine name - UNISTR domain name - UINT32 NTversion (same as received in request) - UINT16 LMNTtoken (same as received in request) - UINT16 LM20token (same as received in request) - - -6.2) SAM Logon --------------- - -Note: machine name in response is preceded by two '\' characters. - -Note: NTversion, LMNTtoken, LM20token in response are the same as those - given in the request. - -Note: user name in the response is presumably the same as that in the request. - -Request: - - UINT16 0x0012 - SAM Logon - UINT16 request count - UNISTR machine name - UNISTR user name - STR response mailslot - UINT32 alloweable account - UINT32 domain SID size - char[sid_size] domain SID, of sid_size bytes. - UINT8[] ???? padding to 4? 2? -byte align with start of mailslot. - UINT32 NTversion - UINT16 LMNTtoken - UINT16 LM20token - -Response: - - UINT16 0x0013 - Response to SAM Logon - UNISTR machine name - UNISTR user name - workstation trust account - UNISTR domain name - UINT32 NTversion - UINT16 LMNTtoken - UINT16 LM20token - - - -7) SRVSVC Transact Named Pipe ------------------------------ - - -Defines for this pipe, identifying the query are: - -- Net Share Enum : 0x0f -- Net Server Get Info : 0x15 - - -7.1) Net Share Enum ------------------- - -Note: share level and switch value in the response are presumably the - same as those in the request. - -Note: cifsrap2.txt (section 5) may be of limited assistance here. - -Request: - - VOID* pointer (to server name?) - UNISTR2 server name - - UINT8[] padding to get unicode string 4-byte aligned - with the start of the SMB header. - - UINT32 share level - UINT32 switch value - - VOID* pointer to SHARE_INFO_1_CTR - SHARE_INFO_1_CTR share info with 0 entries - - UINT32 preferred maximum length (0xffff ffff) - -Response: - - UINT32 share level - UINT32 switch value - - VOID* pointer to SHARE_INFO_1_CTR - SHARE_INFO_1_CTR share info (only added if share info ptr is non-zero) - - return 0 - indicates success - - -7.2) Net Server Get Info ------------------- - -Note: level is the same value as in the request. - -Request: - - UNISTR2 server name - UINT32 switch level - -Response: - - UINT32 switch level - VOID* pointer to SERVER_INFO_101 - - SERVER_INFO_101 server info (only added if server info ptr is non-zero) - - return 0 - indicates success - - - -Appendix --------- - -A1) Cryptographic side of NT Domain Authentication --------------------------------------------------- - - -A1.1) Definitions ------------------ - -Add(A1,A2): Intel byte ordered addition of corresponding 4 byte words -in arrays A1 and A2 - -E(K,D): DES ECB encryption of 8 byte data D using 7 byte key K - -lmowf(): Lan man hash - -ntowf(): NT hash - -PW: md4(machine_password) == md4(lsadump $machine.acc) == -pwdump(machine$) (initially) == md4(lmowf(unicode(machine))) - -ARC4(K,Lk,D,Ld): ARC4 encryption of data D of length Ld with key K of -length Lk - -v[m..n(,l)]: subset of v from bytes m to n, optionally padded with -zeroes to length l - -Cred(K,D): E(K[7..7,7],E(K[0..6],D)) computes a credential - -Time(): 4 byte current time - -Cc,Cs: 8 byte client and server challenges Rc,Rs: 8 byte client and -server credentials - - -A1.2) Protocol --------------- - -C->S ReqChal,Cc S->C Cs - -C & S compute session key Ks = E(PW[9..15],E(PW[0..6],Add(Cc,Cs))) - -C: Rc = Cred(Ks,Cc) C->S Authenticate,Rc S: Rs = Cred(Ks,Cs), -assert(Rc == Cred(Ks,Cc)) S->C Rs C: assert(Rs == Cred(Ks,Cs)) - -On joining the domain the client will optionally attempt to change its -password and the domain controller may refuse to update it depending -on registry settings. This will also occur weekly afterwards. - -C: Tc = Time(), Rc' = Cred(Ks,Rc+Tc) C->S ServerPasswordSet,Rc',Tc, -arc4(Ks[0..7,16],lmowf(randompassword()) C: Rc = Cred(Ks,Rc+Tc+1) S: -assert(Rc' == Cred(Ks,Rc+Tc)), Ts = Time() S: Rs' = Cred(Ks,Rs+Tc+1) -S->C Rs',Ts C: assert(Rs' == Cred(Ks,Rs+Tc+1)) S: Rs = Rs' - -User: U with password P wishes to login to the domain (incidental data -such as workstation and domain omitted) - -C: Tc = Time(), Rc' = Cred(Ks,Rc+Tc) C->S NetLogonSamLogon,Rc',Tc,U, -arc4(Ks[0..7,16],16,ntowf(P),16), arc4(Ks[0..7,16],16,lmowf(P),16) S: -assert(Rc' == Cred(Ks,Rc+Tc)) assert(passwords match those in SAM) S: -Ts = Time() - -S->C Cred(Ks,Cred(Ks,Rc+Tc+1)),userinfo(logon script,UID,SIDs,etc) C: -assert(Rs == Cred(Ks,Cred(Rc+Tc+1)) C: Rc = Cred(Ks,Rc+Tc+1) - - -A1.3) Comments --------------- - -On first joining the domain the session key could be computed by -anyone listening in on the network as the machine password has a well -known value. Until the machine is rebooted it will use this session -key to encrypt NT and LM one way functions of passwords which are -password equivalents. Any user who logs in before the machine has been -rebooted a second time will have their password equivalent exposed. Of -course the new machine password is exposed at this time anyway. - -None of the returned user info such as logon script, profile path and -SIDs *appear* to be protected by anything other than the TCP checksum. - -The server time stamps appear to be ignored. - -The client sends a ReturnAuthenticator in the SamLogon request which I -can't find a use for. However its time is used as the timestamp -returned by the server. - -The password OWFs should NOT be sent over the network reversibly -encrypted. They should be sent using ARC4(Ks,md4(owf)) with the server -computing the same function using the owf values in the SAM. - - -A2) SIDs and RIDs ------------------ - -SIDs and RIDs are well documented elsewhere. - -A SID is an NT Security ID (see DOM_SID structure). They are of the form: - - S-revision-NN-SubAuth1-SubAuth2-SubAuth3... - S-revision-0xNNNNNNNNNNNN-SubAuth1-SubAuth2-SubAuth3... - -currently, the SID revision is 1. -The Sub-Authorities are known as Relative IDs (RIDs). - - -A2.1) Well-known SIDs ---------------------- - - -A2.1.1) Universal well-known SIDs ---------------------------------- - - Null SID S-1-0-0 - World S-1-1-0 - Local S-1-2-0 - Creator Owner ID S-1-3-0 - Creator Group ID S-1-3-1 - Creator Owner Server ID S-1-3-2 - Creator Group Server ID S-1-3-3 - - (Non-unique IDs) S-1-4 - - -A2.1.2) NT well-known SIDs --------------------------- - - NT Authority S-1-5 - Dialup S-1-5-1 - - Network S-1-5-2 - Batch S-1-5-3 - Interactive S-1-5-4 - Service S-1-5-6 - AnonymousLogon S-1-5-7 (aka null logon session) - Proxy S-1-5-8 - ServerLogon S-1-5-8 (aka domain controller account) - - (Logon IDs) S-1-5-5-X-Y - - (NT non-unique IDs) S-1-5-0x15-... - - (Built-in domain) s-1-5-0x20 - - - -A2.2) Well-known RIDS ---------------------- - -A RID is a sub-authority value, as part of either a SID, or in the case -of Group RIDs, part of the DOM_GID structure, in the USER_INFO_1 -structure, in the LSA SAM Logon response. - - -A2.2.1) Well-known RID users ----------------------------- - - DOMAIN_USER_RID_ADMIN 0x0000 01F4 - DOMAIN_USER_RID_GUEST 0x0000 01F5 - - - -A2.2.2) Well-known RID groups ----------------------------- - - DOMAIN_GROUP_RID_ADMINS 0x0000 0200 - DOMAIN_GROUP_RID_USERS 0x0000 0201 - DOMAIN_GROUP_RID_GUESTS 0x0000 0202 - - - -A2.2.3) Well-known RID aliases ------------------------------- - - DOMAIN_ALIAS_RID_ADMINS 0x0000 0220 - DOMAIN_ALIAS_RID_USERS 0x0000 0221 - DOMAIN_ALIAS_RID_GUESTS 0x0000 0222 - DOMAIN_ALIAS_RID_POWER_USERS 0x0000 0223 - - DOMAIN_ALIAS_RID_ACCOUNT_OPS 0x0000 0224 - DOMAIN_ALIAS_RID_SYSTEM_OPS 0x0000 0225 - DOMAIN_ALIAS_RID_PRINT_OPS 0x0000 0226 - DOMAIN_ALIAS_RID_BACKUP_OPS 0x0000 0227 - - DOMAIN_ALIAS_RID_REPLICATOR 0x0000 0228 - - |