From 20967627378194121bc48bf387838b8bd7682478 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Tue, 18 Mar 2003 16:48:14 +0000 Subject: Regenerate (This used to be commit 25db62e3101dbcae8e9daee3cb16430297afa223) --- docs/htmldocs/Samba-Developers-Guide.html | 953 +++++++++++++++--------------- 1 file changed, 476 insertions(+), 477 deletions(-) (limited to 'docs/htmldocs/Samba-Developers-Guide.html') diff --git a/docs/htmldocs/Samba-Developers-Guide.html b/docs/htmldocs/Samba-Developers-Guide.html index 5d9702e49e..22cbcec3ee 100644 --- a/docs/htmldocs/Samba-Developers-Guide.html +++ b/docs/htmldocs/Samba-Developers-Guide.html @@ -5,7 +5,7 @@ >SAMBA Developers GuideSAMBA Developers GuideSAMBA Developers Guide

1.1. NETBIOS

1.1. NETBIOS

NetBIOS runs over the following tranports: TCP/IP; NetBEUI and IPX/SPX. Samba only uses NetBIOS over TCP/IP. For details on the TCP/IP NetBIOS @@ -904,8 +904,8 @@ CLASS="SECT1" CLASS="SECT1" >1.2. BROADCAST NetBIOS1.2. BROADCAST NetBIOS

Clients can claim names, and therefore offer services on successfully claimed @@ -927,14 +927,14 @@ CLASS="SECT1" CLASS="SECT1" >1.3. NBNS NetBIOS1.3. NBNS NetBIOS

rfc1001.txt describes, amongst other things, the implementation and use of, a 'NetBIOS Name Service'. NT/AS offers 'Windows Internet Name Service' which is fully rfc1001/2 compliant, but has had to take specific action with certain NetBIOS names in order to make it useful. (for example, it -deals with the registration of <1c> <1d> <1e> names all in different ways. +deals with the registration of <1c> <1d> <1e> names all in different ways. I recommend the reading of the Microsoft WINS Server Help files for full details).

2.1. Introduction2.1. Introduction

This document gives a general overview of how Samba works internally. The Samba Team has tried to come up with a model which is @@ -1022,8 +1022,8 @@ CLASS="SECT1" CLASS="SECT1" >2.2. Multithreading and Samba2.2. Multithreading and Samba

People sometimes tout threads as a uniformly good thing. They are very nice in their place but are quite inappropriate for smbd. nmbd is @@ -1048,8 +1048,8 @@ CLASS="SECT1" CLASS="SECT1" >2.3. Threading smbd2.3. Threading smbd

A few problems that would arise from a threaded smbd are:

2.4. Threading nmbd2.4. Threading nmbd

This would be ideal, but gets sunk by portability requirements.

2.5. nbmd Design2.5. nbmd Design

Originally Andrew used recursion to simulate a multi-threaded environment, which use the stack enormously and made for really @@ -1173,22 +1173,22 @@ CLASS="SECT1" CLASS="SECT1" >3.1. New Output Syntax3.1. New Output Syntax

The syntax of a debugging log file is represented as:

  >debugfile< :== { >debugmsg< }
+>  >debugfile< :== { >debugmsg< }
 
-  >debugmsg<  :== >debughdr< '\n' >debugtext<
+  >debugmsg<  :== >debughdr< '\n' >debugtext<
 
-  >debughdr<  :== '[' TIME ',' LEVEL ']' FILE ':' [FUNCTION] '(' LINE ')'
+  >debughdr<  :== '[' TIME ',' LEVEL ']' FILE ':' [FUNCTION] '(' LINE ')'
 
-  >debugtext< :== { >debugline< }
+  >debugtext< :== { >debugline< }
 
-  >debugline< :== TEXT '\n'

TEXT is a string of characters excluding the newline character.

3.2. The DEBUG() Macro3.2. The DEBUG() Macro

Use of the DEBUG() macro is unchanged. DEBUG() takes two parameters. The first is the message level, the second is the body of a function @@ -1338,8 +1338,8 @@ CLASS="SECT1" CLASS="SECT1" >3.3. The DEBUGADD() Macro3.3. The DEBUGADD() Macro

In addition to the kludgey solution to the broken line problem described above, there is a clean solution. The DEBUGADD() macro never @@ -1369,8 +1369,8 @@ CLASS="SECT1" CLASS="SECT1" >3.4. The DEBUGLVL() Macro3.4. The DEBUGLVL() Macro

One of the problems with the DEBUG() macro was that DEBUG() lines tended to get a bit long. Consider this example from @@ -1437,16 +1437,16 @@ CLASS="SECT1" CLASS="SECT1" >3.5. New Functions3.5. New Functions

3.5.1. dbgtext()

3.5.1. dbgtext()

This function prints debug message text to the debug file (and possibly to syslog) via the format buffer. The function uses a @@ -1463,8 +1463,8 @@ CLASS="SECT2" CLASS="SECT2" >3.5.2. dbghdr()3.5.2. dbghdr()

This is the function that writes a debug message header. Headers are not processed via the format buffer. Also note that @@ -1480,8 +1480,8 @@ CLASS="SECT2" CLASS="SECT2" >3.5.3. format_debug_text()3.5.3. format_debug_text()

This is a static function in debug.c. It stores the output text for the body of the message in a buffer until it encounters a @@ -1726,8 +1726,8 @@ CLASS="SECT1" CLASS="SECT1" >5.1. Character Handling5.1. Character Handling

This section describes character set handling in Samba, as implemented in Samba 3.0 and above

5.2. The new functions5.2. The new functions

The new system works like this:

5.3. Macros in byteorder.h5.3. Macros in byteorder.h

This section describes the macros defined in byteorder.h. These macros are used extensively in the Samba code.

5.3.1. CVAL(buf,pos)5.3.1. CVAL(buf,pos)

returns the byte at offset pos within buffer buf as an unsigned character.

5.3.2. PVAL(buf,pos)5.3.2. PVAL(buf,pos)

returns the value of CVAL(buf,pos) cast to type unsigned integer.

5.3.3. SCVAL(buf,pos,val)5.3.3. SCVAL(buf,pos,val)

sets the byte at offset pos within buffer buf to value val.

5.3.4. SVAL(buf,pos)5.3.4. SVAL(buf,pos)

returns the value of the unsigned short (16 bit) little-endian integer at offset pos within buffer buf. An integer of this type is sometimes @@ -1913,8 +1913,8 @@ CLASS="SECT2" CLASS="SECT2" >5.3.5. IVAL(buf,pos)5.3.5. IVAL(buf,pos)

returns the value of the unsigned 32 bit little-endian integer at offset pos within buffer buf.

5.3.6. SVALS(buf,pos)5.3.6. SVALS(buf,pos)

returns the value of the signed short (16 bit) little-endian integer at offset pos within buffer buf.

5.3.7. IVALS(buf,pos)5.3.7. IVALS(buf,pos)

returns the value of the signed 32 bit little-endian integer at offset pos within buffer buf.

5.3.8. SSVAL(buf,pos,val)5.3.8. SSVAL(buf,pos,val)

sets the unsigned short (16 bit) little-endian integer at offset pos within buffer buf to value val.

5.3.9. SIVAL(buf,pos,val)5.3.9. SIVAL(buf,pos,val)

sets the unsigned 32 bit little-endian integer at offset pos within buffer buf to the value val.

5.3.10. SSVALS(buf,pos,val)5.3.10. SSVALS(buf,pos,val)

sets the short (16 bit) signed little-endian integer at offset pos within buffer buf to the value val.

5.3.11. SIVALS(buf,pos,val)5.3.11. SIVALS(buf,pos,val)

sets the signed 32 bit little-endian integer at offset pos withing buffer buf to the value val.

5.3.12. RSVAL(buf,pos)5.3.12. RSVAL(buf,pos)

returns the value of the unsigned short (16 bit) big-endian integer at offset pos within buffer buf.

5.3.13. RIVAL(buf,pos)5.3.13. RIVAL(buf,pos)

returns the value of the unsigned 32 bit big-endian integer at offset pos within buffer buf.

5.3.14. RSSVAL(buf,pos,val)5.3.14. RSSVAL(buf,pos,val)

sets the value of the unsigned short (16 bit) big-endian integer at offset pos within buffer buf to value val. @@ -2034,8 +2034,8 @@ CLASS="SECT2" CLASS="SECT2" >5.3.15. RSIVAL(buf,pos,val)5.3.15. RSIVAL(buf,pos,val)

sets the value of the unsigned 32 bit big-endian integer at offset pos within buffer buf to value val.

5.4. LAN Manager Samba API5.4. LAN Manager Samba API

This section describes the functions need to make a LAN Manager RPC call. This information had been obtained by examining the Samba code and the LAN @@ -2069,8 +2069,8 @@ CLASS="SECT2" CLASS="SECT2" >5.4.1. Parameters5.4.1. Parameters

The parameters are as follows:

5.4.2. Return value5.4.2. Return value

The returned parameters (pointed to by rparam), in their order of appearance are:

5.5. Code character table5.5. Code character table

Certain data structures are described by means of ASCIIz strings containing code characters. These are the code characters:

6.1. Lexical Analysis6.1. Lexical Analysis

Basically, the file is processed on a line by line basis. There are four types of lines that are recognized by the lexical analyzer @@ -2340,8 +2340,8 @@ CLASS="SECT2" CLASS="SECT2" >6.1.1. Handling of Whitespace6.1.1. Handling of Whitespace

Whitespace is defined as all characters recognized by the isspace() function (see ctype(3C)) except for the newline character ('\n') @@ -2377,8 +2377,8 @@ CLASS="SECT2" CLASS="SECT2" >6.1.2. Handling of Line Continuation6.1.2. Handling of Line Continuation

Long section header and parameter lines may be extended across multiple lines by use of the backslash character ('\\'). Line @@ -2417,8 +2417,8 @@ CLASS="SECT2" CLASS="SECT2" >6.1.3. Line Continuation Quirks6.1.3. Line Continuation Quirks

Note the following example:

6.2. Syntax6.2. Syntax

The syntax of the smb.conf file is as follows:

  <file>            :==  { <section> } EOF
-  <section>         :==  <section header> { <parameter line> }
-  <section header>  :==  '[' NAME ']'
-  <parameter line>  :==  NAME '=' VALUE NL
<file> :== { <section> } EOF + <section> :== <section header> { <parameter line> } + <section header> :== '[' NAME ']' + <parameter line> :== NAME '=' VALUE NL

Basically, this means that

6.2.1. About params.c6.2.1. About params.c

The parsing of the config file is a bit unusual if you are used to lex, yacc, bison, etc. Both lexical analysis (scanning) and parsing @@ -2547,12 +2547,12 @@ CLASS="SECT1" CLASS="SECT1" >7.1. Introduction7.1. Introduction

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 +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 @@ -2564,8 +2564,8 @@ CLASS="SECT1" CLASS="SECT1" >7.2. Usernames7.2. Usernames

The SMB protocol has only a loose username concept. Early SMB protocols (such as CORE and COREPLUS) have no username concept at @@ -2610,8 +2610,8 @@ CLASS="SECT1" CLASS="SECT1" >7.3. File Ownership7.3. 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 @@ -2637,8 +2637,8 @@ CLASS="SECT1" CLASS="SECT1" >7.4. Passwords7.4. Passwords

Many SMB clients uppercase passwords before sending them. I have no idea why they do this. Interestingly WfWg uppercases the password only @@ -2668,8 +2668,8 @@ CLASS="SECT1" CLASS="SECT1" >7.5. Locking7.5. Locking

Since samba 2.2, samba supports other types of locking as well. This section is outdated.

7.6. Deny Modes7.6. 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, @@ -2731,8 +2731,8 @@ CLASS="SECT1" CLASS="SECT1" >7.7. Trapdoor UIDs7.7. 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 @@ -2750,8 +2750,8 @@ CLASS="SECT1" CLASS="SECT1" >7.8. Port numbers7.8. Port numbers

There is a convention that clients on sockets use high "unprivilaged" port numbers (>1000) and connect to servers on low "privilaged" port @@ -2782,8 +2782,8 @@ CLASS="SECT1" CLASS="SECT1" >7.9. Protocol Complexity7.9. 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, @@ -2900,14 +2900,14 @@ example, if I'm using a csh style shell:

strace -f -p 3872 >& strace.outstrace -f -p 3872 >& strace.out

or with a sh style shell:

strace -f -p 3872 > strace.out 2>&1strace -f -p 3872 > strace.out 2>&1

Note the "-f" option. This is only available on some systems, and @@ -2963,8 +2963,8 @@ CLASS="SECT1" CLASS="SECT1" >9.1. Introduction9.1. Introduction

This document contains information to provide an NT workstation with login services, without the need for an NT server. It is the sgml version of 9.1.1. Sources9.1.1. Sources

9.1.2. Credits9.1.2. Credits

9.2. Notes and Structures9.2. Notes and Structures

9.2.1. Notes

9.2.1. Notes

    9.2.2. Enumerations9.2.2. Enumerations

    9.2.2.1. MSRPC Header type

    9.2.2.1. MSRPC Header type

    command number in the msrpc packet header

    9.2.2.2. MSRPC Packet info9.2.2.2. MSRPC Packet info

    The meaning of these flags is undocumented

    9.2.3. Structures9.2.3. Structures

    9.2.3.1. VOID *

    9.2.3.1. VOID *

    sizeof VOID* is 32 bits.

    9.2.3.2. char9.2.3.2. char

    sizeof char is 8 bits.

    9.2.3.3. UTIME9.2.3.3. UTIME

    UTIME is 32 bits, indicating time in seconds since 01jan1970. documented in cifs6.txt (section 3.5 page, page 30).

9.2.3.4. NTTIME9.2.3.4. NTTIME

NTTIME is 64 bits. documented in cifs6.txt (section 3.5 page, page 30).

9.2.3.5. DOM_SID (domain SID structure)9.2.3.5. DOM_SID (domain SID structure)

9.2.3.6. STR (string)9.2.3.6. STR (string)

STR (string) is a char[] : a null-terminated string of ascii characters.

9.2.3.7. UNIHDR (unicode string header)9.2.3.7. UNIHDR (unicode string header)

9.2.3.8. UNIHDR2 (unicode string header plus buffer pointer)9.2.3.8. UNIHDR2 (unicode string header plus buffer pointer)

9.2.3.9. UNISTR (unicode string)9.2.3.9. UNISTR (unicode string)

9.2.3.10. NAME (length-indicated unicode string)9.2.3.10. NAME (length-indicated unicode string)

9.2.3.11. UNISTR2 (aligned unicode string)9.2.3.11. UNISTR2 (aligned unicode string)

9.2.3.12. OBJ_ATTR (object attributes)9.2.3.12. OBJ_ATTR (object attributes)

9.2.3.13. POL_HND (LSA policy handle)9.2.3.13. POL_HND (LSA policy handle)

9.2.3.14. DOM_SID2 (domain SID structure, SIDS stored in unicode)9.2.3.14. DOM_SID2 (domain SID structure, SIDS stored in unicode)

9.2.3.15. DOM_RID (domain RID structure)9.2.3.15. DOM_RID (domain RID structure)

9.2.3.16. LOG_INFO (server, account, client structure)9.2.3.16. LOG_INFO (server, account, client structure)

9.2.3.17. CLNT_SRV (server, client names structure)9.2.3.17. CLNT_SRV (server, client names structure)

9.2.3.18. CREDS (credentials + time stamp)9.2.3.18. CREDS (credentials + time stamp)

9.2.3.19. CLNT_INFO2 (server, client structure, client credentials)9.2.3.19. CLNT_INFO2 (server, client structure, client credentials)

9.2.3.20. CLNT_INFO (server, account, client structure, client credentials)9.2.3.20. CLNT_INFO (server, account, client structure, client credentials)

9.2.3.21. ID_INFO_1 (id info structure, auth level 1)9.2.3.21. ID_INFO_1 (id info structure, auth level 1)

9.2.3.22. SAM_INFO (sam logon/logoff id info structure)9.2.3.22. SAM_INFO (sam logon/logoff id info structure)

9.2.3.23. GID (group id info)9.2.3.23. GID (group id info)

9.2.3.24. DOM_REF (domain reference info)9.2.3.24. DOM_REF (domain reference info)

9.2.3.25. DOM_INFO (domain info, levels 3 and 5 are the same))9.2.3.25. DOM_INFO (domain info, levels 3 and 5 are the same))

9.2.3.26. USER_INFO (user logon info)9.2.3.26. USER_INFO (user logon info)

9.2.3.27. SH_INFO_1_PTR (pointers to level 1 share info strings)9.2.3.27. SH_INFO_1_PTR (pointers to level 1 share info strings)

9.2.3.28. SH_INFO_1_STR (level 1 share info strings)9.2.3.28. SH_INFO_1_STR (level 1 share info strings)

9.2.3.29. SHARE_INFO_1_CTR9.2.3.29. SHARE_INFO_1_CTR

share container with 0 entries:

9.2.3.30. SERVER_INFO_1019.2.3.30. SERVER_INFO_101

9.3. MSRPC over Transact Named Pipe9.3. MSRPC over Transact Named Pipe

For details on the SMB Transact Named Pipe, see cifs6.txt

9.3.1. MSRPC Pipes9.3.1. MSRPC Pipes

The MSRPC is conducted over an SMB Transact Pipe with a name of 9.3.2. Header9.3.2. Header

[section to be rewritten, following receipt of work by Duncan Stansfield]

9.3.2.1. RPC_Packet for request, response, bind and bind acknowledgement9.3.2.1. RPC_Packet for request, response, bind and bind acknowledgement

9.3.2.2. Interface identification9.3.2.2. Interface identification

the interfaces are numbered. as yet I haven't seen more than one interface used on the same pipe name srvsvc

9.3.2.3. RPC_Iface RW9.3.2.3. RPC_Iface RW

9.3.2.4. RPC_ReqBind RW9.3.2.4. RPC_ReqBind RW

the remainder of the packet after the header if "type" was Bind in the response header, "type" should be BindAck

9.3.2.5. RPC_Address RW9.3.2.5. RPC_Address RW

9.3.2.6. RPC_ResBind RW9.3.2.6. RPC_ResBind RW

the response to place after the header in the reply packet

9.3.2.7. RPC_ReqNorm RW9.3.2.7. RPC_ReqNorm RW

the remainder of the packet after the header for every other other request

9.3.2.8. RPC_ResNorm RW9.3.2.8. RPC_ResNorm RW

9.3.3. Tail9.3.3. Tail

The end of each of the NTLSA and NETLOGON named pipes ends with:

9.3.4. RPC Bind / Bind Ack9.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 @@ -5736,8 +5736,8 @@ CLASS="SECT2" CLASS="SECT2" >9.3.5. NTLSA Transact Named Pipe9.3.5. NTLSA Transact Named Pipe

The sequence of actions taken on this pipe are:

9.3.6. LSA Open Policy9.3.6. LSA Open Policy

9.3.6.1. Request9.3.6.1. Request

9.3.6.2. Response9.3.6.2. Response

9.3.7. LSA Query Info Policy9.3.7. LSA Query Info Policy

9.3.7.1. Request9.3.7.1. Request

9.3.7.2. Response9.3.7.2. Response

9.3.8. LSA Enumerate Trusted Domains9.3.8. LSA Enumerate Trusted Domains

9.3.8.1. Request

9.3.8.1. Request

no extra data

9.3.8.2. Response9.3.8.2. Response

9.3.9. LSA Open Secret9.3.9. LSA Open Secret

9.3.9.1. Request

9.3.9.1. Request

no extra data

9.3.9.2. Response9.3.9.2. Response

9.3.10. LSA Close9.3.10. LSA Close

9.3.10.1. Request

9.3.10.1. Request

9.3.10.2. Response9.3.10.2. Response

9.3.11. LSA Lookup SIDS9.3.11. LSA Lookup SIDS

9.3.11.1. Request9.3.11.1. Request

9.3.11.2. Response9.3.11.2. Response

9.3.12. LSA Lookup Names9.3.12. LSA Lookup Names

9.3.12.1. Request9.3.12.1. Request

9.3.12.2. Response9.3.12.2. Response

9.4. NETLOGON rpc Transact Named Pipe9.4. NETLOGON rpc Transact Named Pipe

The sequence of actions taken on this pipe are:

9.4.1. LSA Request Challenge9.4.1. LSA Request Challenge

9.4.1.1. Request9.4.1.1. Request

9.4.1.2. Response9.4.1.2. Response

9.4.2. LSA Authenticate 29.4.2. LSA Authenticate 2

9.4.2.1. Request9.4.2.1. Request

9.4.2.2. Response9.4.2.2. Response

9.4.3. LSA Server Password Set9.4.3. LSA Server Password Set

9.4.3.1. Request9.4.3.1. Request

9.4.3.2. Response9.4.3.2. Response

9.4.4. LSA SAM Logon9.4.4. LSA SAM Logon

9.4.4.1. Request9.4.4.1. Request

9.4.4.2. Response9.4.4.2. Response

9.4.5. LSA SAM Logoff9.4.5. LSA SAM Logoff

9.4.5.1. Request9.4.5.1. Request

9.4.5.2. Response9.4.5.2. Response

9.5. \\MAILSLOT\NET\NTLOGON9.5. \\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 + should be sent. the target NetBIOS name is REQUEST_NAME<20>, where REQUEST_NAME is the name of the machine that sent the request.

9.5.1. Query for PDC9.5.1. Query for PDC

9.5.1.1. Request9.5.1.1. Request

9.5.1.2. Response9.5.1.2. Response

9.5.2. SAM Logon9.5.2. SAM Logon

9.5.2.1. Request9.5.2.1. Request

9.5.2.2. Response9.5.2.2. Response

9.6. SRVSVC Transact Named Pipe9.6. SRVSVC Transact Named Pipe

Defines for this pipe, identifying the query are:

9.6.1. Net Share Enum9.6.1. Net Share Enum

9.6.1.1. Request9.6.1.1. Request

9.6.1.2. Response9.6.1.2. Response

9.6.2. Net Server Get Info9.6.2. Net Server Get Info

9.6.2.1. Request9.6.2.1. Request

9.6.2.2. Response9.6.2.2. Response

9.7. Cryptographic side of NT Domain Authentication9.7. Cryptographic side of NT Domain Authentication

9.7.1. Definitions

9.7.1. Definitions

9.7.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))

9.7.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'

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)

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)
9.7.3. Comments9.7.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 @@ -7733,8 +7748,8 @@ CLASS="SECT1" CLASS="SECT1" >9.8. SIDs and RIDs9.8. SIDs and RIDs

SIDs and RIDs are well documented elsewhere.

9.8.1. Well-known SIDs9.8.1. Well-known SIDs

9.8.1.1. Universal well-known SIDs

9.8.1.1. Universal well-known SIDs

9.8.1.2. NT well-known SIDs9.8.1.2. NT well-known SIDs

9.8.2. Well-known RIDS9.8.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 @@ -7938,8 +7953,8 @@ CLASS="SECT3" CLASS="SECT3" >9.8.2.1. Well-known RID users9.8.2.1. Well-known RID users

Groupname: 9.8.2.2. Well-known RID groups9.8.2.2. Well-known RID groups

Groupname: 9.8.2.3. Well-known RID aliases9.8.2.3. Well-known RID aliases

Groupname: 10.1. Abstract10.1. Abstract

The purpose of this document is to provide some insight into Samba's printing functionality and also to describe the semantics @@ -8156,13 +8171,13 @@ CLASS="SECT1" CLASS="SECT1" >10.2. Printing Interface to Various Back ends10.2. Printing Interface to Various Back ends

Samba uses a table of function pointers to seven functions. The -function prototypes are defined in the printifprintif structure declared in 10.3. Print Queue TDB's10.3. Print Queue TDB's

Samba provides periodic caching of the output from the "lpq command" for performance reasons. This cache time is configurable in seconds. @@ -8274,7 +8289,7 @@ struct printjob { for the UNIX job id returned from the "lpq command" and a Windows job ID (32-bit bounded by PRINT_MAX_JOBID). When a print job is returned by the "lpq command" that does not match an existing job in the queue's -TDB, a 32-bit job ID above the <*vance doesn't know what word is missing here*> is generating by adding UNIX_JOB_START to +TDB, a 32-bit job ID above the <*vance doesn't know what word is missing here*> is generating by adding UNIX_JOB_START to the id reported by lpq.

In order to match a 32-bit Windows jobid onto a 16-bit lanman print job @@ -8294,14 +8309,12 @@ TYPE="1" >

Check to see if another smbd is currently in the process of updating the queue contents by checking the pid - stored in LOCK/LOCK/printer_nameprinter_name. If so, then do not update the TDB.

10.4. ChangeID and Client Caching of Printer Information10.4. ChangeID and Client Caching of Printer Information

[To be filled in later]

10.5. Windows NT/2K Printer Change Notify10.5. Windows NT/2K Printer Change Notify

When working with Windows NT+ clients, it is possible for a print server to use RPC to send asynchronous change notification @@ -8455,7 +8468,7 @@ C: Send a RFFPCN request with the previously obtained to monitor, or (b) a PRINTER_NOTIFY_OPTIONS structure containing the event information to monitor. The windows spooler has only been observed to use (b). -S: The <* another missing word*> opens a new TCP session to the client (thus requiring +S: The <* another missing word*> opens a new TCP session to the client (thus requiring all print clients to be CIFS servers as well) and sends a ReplyOpenPrinter() request to the client. C: The client responds with a printer handle that can be used to @@ -8533,9 +8546,9 @@ information

A A SPOOL_NOTIFY_INFOSPOOL_NOTIFY_INFO contains:

The The SPOOL_NOTIFY_INFO_DATASPOOL_NOTIFY_INFO_DATA entries contain:

11.1. WINS Failover11.1. WINS Failover

The current Samba codebase possesses the capability to use groups of WINS servers that share a common namespace for NetBIOS name registration and @@ -8620,7 +8633,7 @@ resolution. The formal parameter syntax is

	WINS_SERVER_PARAM 	= SERVER [ SEPARATOR SERVER_LIST ]
-	WINS_SERVER_PARAM 	= "wins server"
+	WINS_SERVER_PARAM 	= "wins server"
 	SERVER 			= ADDR[:TAG]
 	ADDR 			= ip_addr | fqdn
 	TAG 			= string
@@ -8637,7 +8650,7 @@ CLASS="PROGRAMLISTING"
 >
In the event that no TAG is defined in for a SERVER in the list, smbd assigns a default
-TAG of "*".  A TAG is used to group servers of a shared NetBIOS namespace together.  Upon
+TAG of "*".  A TAG is used to group servers of a shared NetBIOS namespace together.  Upon
 startup, nmbd will attempt to register the netbios name value with one server in each
 tagged group.
Using this configuration, nmbd would attempt to register the server's NetBIOS name 
-with one WINS server in each group.  Because the "eth0" group has two servers, the 
+with one WINS server in each group.  Because the "eth0" group has two servers, the 
 second server would only be used when a registration (or resolution) request to 
 the first server in that group timed out.
12.1. Security in the 'new SAM'12.1. Security in the 'new SAM'
One of the biggest problems with passdb is it's implementation of
 'security'.  Access control is on a 'are you root at the moment' basis,
@@ -8752,8 +8765,8 @@ CLASS="SECT1"
 CLASS="SECT1"
 >12.2. Standalone from UNIX12.2. Standalone from UNIX
One of the primary tenants of the 'new SAM' is that it would not attempt
 to deal with 'what unix id for that'.  This would be left to the 'SMS'
@@ -8771,8 +8784,8 @@ CLASS="SECT1"
 CLASS="SECT1"
 >12.3. Handles and Races in the new SAM12.3. Handles and Races in the new SAM
One of the things that the 'new SAM' work has tried to face is both
 compatibility with existing code, and a closer alignment to the SAMR
@@ -8814,16 +8827,16 @@ CLASS="SECT1"
 CLASS="SECT1"
 >12.4. Layers12.4. Layers
12.4.1. Application
12.4.1. Application
This is where smbd, samtest and whatever end-user replacement we have
 for pdbedit sits.  They use only the SAM interface, and do not get
@@ -8835,8 +8848,8 @@ CLASS="SECT2"
 CLASS="SECT2"
 >12.4.2. SAM Interface12.4.2. SAM Interface
This level 'owns' the various handle structures, the get/set routines on
 those structures and provides the public interface.  The application
@@ -8855,8 +8868,8 @@ CLASS="SECT2"
 CLASS="SECT2"
 >12.4.3. SAM Modules12.4.3. SAM Modules
These do not communicate with the application directly, only by setting
 values in the handles, and receiving requests from the interface.  These
@@ -8873,16 +8886,16 @@ CLASS="SECT1"
 CLASS="SECT1"
 >12.5. SAM Modules12.5. SAM Modules
12.5.1. Special Module: sam_passdb
12.5.1. Special Module: sam_passdb
In order for there to be a smooth transition, kai is writing a module
 that reads existing passdb backends, and translates them into SAM
@@ -8896,8 +8909,8 @@ CLASS="SECT2"
 CLASS="SECT2"
 >12.5.2. sam_ads12.5.2. sam_ads
This is the first of the SAM modules to be committed to the tree -
 mainly because I needed to coordinate work with metze (who authored most
@@ -8918,8 +8931,8 @@ CLASS="SECT1"
 CLASS="SECT1"
 >12.6. Memory Management12.6. Memory Management
 
 The 'new SAM' development effort also concerned itself with getting a
@@ -8974,8 +8987,8 @@ CLASS="SECT1"
 CLASS="SECT1"
 >12.7. Testing12.7. Testing
Testing is vital in any piece of software, and Samba is certainly no
 exception. In designing this new subsystem, we have taken care to ensure
@@ -8994,9 +9007,9 @@ it particularly valuable.
Example useage:
$$ bin/samtest13.1. Introduction13.1. Introduction
With the development of LanManager and Windows NT 
 	compatible password encryption for Samba, it is now able 
@@ -9051,8 +9064,8 @@ CLASS="SECT1"
 CLASS="SECT1"
 >13.2. How does it work?13.2. How does it work?
LanManager encryption is somewhat similar to UNIX 
 	password encryption. The server uses a file containing a 
@@ -9116,11 +9129,11 @@ CLASS="SECT1"
 CLASS="SECT1"
 >13.3. >The smbpasswd file>The smbpasswd file
In order for Samba to participate in the above protocol 
 	it must be able to look up the 16 byte hashed values given a user name.
@@ -9151,28 +9164,24 @@ CLASS="FILENAME"
 	 file use the following command:
$ $ cat /etc/passwd | mksmbpasswd.sh
-	> /usr/local/samba/private/smbpasswd
If you are running on a system that uses NIS, use
$ $ ypcat passwd | mksmbpasswd.sh
-	> /usr/local/samba/private/smbpasswd
The 
username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
-	[Account type]:LCT-<last-change-time>:Long name
+	[Account type]:LCT-<last-change-time>:Long name
 	
Although only the Although only the usernameusername, 
-	uid, uid, 	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,
-	[Account type] and Account type] and 	last-change-time	last-change-time sections are significant 
 	and are looked at in the Samba code.
To set a user to have no password (not recommended), edit the file
 	using vi, and replace the first 11 characters with the ascii text
-	"NO PASSWORD""NO PASSWORD" (minus the quotes).
For example, to clear the password for user bob, his smbpasswd file 
@@ -9333,8 +9332,8 @@ CLASS="SECT1"
 CLASS="SECT1"
 >14.1. About14.1. About
This document describes how to make use the new RPC Pluggable Modules features
 of Samba 3.0.  This architecture was added to increase the maintainability of
@@ -9348,13 +9347,13 @@ CLASS="SECT1"
 CLASS="SECT1"
 >14.2. General Overview14.2. General Overview
When an RPC call is sent to smbd, smbd tries to load a shared library by the
 name librpc_<pipename>.solibrpc_<pipename>.so to handle the call if
 it doesn't know how to handle the call internally.  For instance, LSA calls
 are handled by ..
 These shared libraries should be located in the <sambaroot>/lib/rpc<sambaroot>/lib/rpc.  smbd then attempts to call the rpc_pipe_init function within
 the shared library.