Remove more obsolete documents

4 files changed, 0 insertions, 1868 deletions

diff --git a/docs/textdocs/Passwords.txt b/docs/textdocs/Passwords.txt
deleted file mode 100644
index 25d4c816f05..00000000000
--- 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 6cc1d69258d..00000000000
--- 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 c3d7643cbcb..00000000000
--- 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 643b8957c9f..00000000000
--- 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
-
-