Merge of new edits from HEAD.

(This used to be commit 9990dd7ef8a8b4b412edfab8f94d65a3b0b3525b)

9 files changed, 983 insertions, 963 deletions

diff --git a/docs/docbook/projdoc/ADS-HOWTO.xml b/docs/docbook/projdoc/ADS-HOWTO.xml
deleted file mode 100644
index c89a0e4f87..0000000000
--- a/docs/docbook/projdoc/ADS-HOWTO.xml
+++ /dev/null
@@ -1,167 +0,0 @@
-<chapter id="ADS">
-
-<chapterinfo>
-	&author.tridge;
-	&author.jelmer;
-	<pubdate>2002/2003</pubdate>
-</chapterinfo>
-
-<title>Samba as a ADS domain member</title>
-
-<para>
-This is a rough guide to setting up Samba 3.0 with kerberos authentication against a
-Windows2000 KDC. 
-</para> 
-
-<sect1>
-<title>Setup your <filename>smb.conf</filename></title>
-
-<para>You must use at least the following 3 options in smb.conf:</para>
-
-<para><programlisting>
-	realm = YOUR.KERBEROS.REALM
-	security = ADS
-	encrypt passwords = yes
-</programlisting></para>
-
-<para>
-In case samba can't figure out your ads server using your realm name, use the 
-<command>ads server</command> option in <filename>smb.conf</filename>:
-<programlisting>
-	ads server = your.kerberos.server
-</programlisting>
-</para>
-
-<note><para>You do *not* need a smbpasswd file, and older clients will
-  be authenticated as if <command>security = domain</command>,
-  although it won't do any harm
-  and allows you to have local users not in the domain.
-  I expect that the above required options will change soon when we get better
-  active directory integration.</para></note>
-
-</sect1>
-  
-<sect1>
-<title>Setup your <filename>/etc/krb5.conf</filename></title>
-
-<para>Note: you will need the krb5 workstation, devel, and libs installed</para>
-
-<para>The minimal configuration for <filename>krb5.conf</filename> is:</para>
-
-<para><programlisting>
-	[realms]
-	    YOUR.KERBEROS.REALM = {
-		kdc = your.kerberos.server
-	    }
-</programlisting></para>
-
-<para>Test your config by doing a <userinput>kinit
-<replaceable>USERNAME</replaceable>@<replaceable>REALM</replaceable></userinput> and
-making sure that your password is accepted by the Win2000 KDC.
-</para>
-
-<note><para>The realm must be uppercase or you will get "Cannot find KDC for requested
-realm while getting initial credentials" error </para></note>
-
-<note><para>Time between the two servers must be synchronized.  You will get a
-"kinit(v5): Clock skew too great while getting initial credentials" if the time
-difference is more than five minutes. </para></note>
-
-<para>
-You also must ensure that you can do a reverse DNS lookup on the IP
-address of your KDC. Also, the name that this reverse lookup maps to
-must either be the netbios name of the KDC (ie. the hostname with no
-domain attached) or it can alternatively be the netbios name
-followed by the realm. 
-</para>
-
-<para>
-The easiest way to ensure you get this right is to add a 
-<filename>/etc/hosts</filename> entry mapping the IP address of your KDC to 
-its netbios name. If you don't get this right then you will get a 
-"local error" when you try to join the realm.
-</para>
-
-<para>
-If all you want is kerberos support in &smbclient; then you can skip
-straight to <link linkend="ads-test-smbclient">Test with &smbclient;</link> now. 
-<link linkend="ads-create-machine-account">Creating a computer account</link> 
-and <link linkend="ads-test-server">testing your servers</link>
-is only needed if you want kerberos support for &smbd; and &winbindd;.
-</para>
-
-</sect1>
-
-<sect1 id="ads-create-machine-account">
-<title>Create the computer account</title>
-
-<para>
-As a user that has write permission on the Samba private directory
-(usually root) run:
-<programlisting>
-	<userinput>net join -U Administrator%password</userinput>
-</programlisting>
-</para>
-
-<sect2>
-<title>Possible errors</title>
-
-<para>
-<variablelist>
-	<varlistentry><term>"ADS support not compiled in"</term>
-	<listitem><para>Samba must be reconfigured (remove config.cache) and recompiled
-	(make clean all install) after the kerberos libs and headers are installed.
-	</para></listitem></varlistentry>
-
-	<varlistentry><term>net join prompts for user name</term>
-	<listitem><para>You need to login to the domain using <userinput>kinit
-	<replaceable>USERNAME</replaceable>@<replaceable>REALM</replaceable></userinput>.
-	<replaceable>USERNAME</replaceable> must be a user who has rights to add a machine
-	to the domain.  </para></listitem></varlistentry>
-</variablelist>
-</para>
-
-</sect2>
-
-</sect1>
-
-<sect1 id="ads-test-server">
-<title>Test your server setup</title>
-
-<para>
-If the join was successful, you will see a new computer account with the
-NetBIOS name of your Samba server in Active Directory (in the "Computers"
-folder under Users and Computers.
-</para>
-
-<para>
-On a Windows 2000 client try <userinput>net use * \\server\share</userinput>. You should
-be logged in with kerberos without needing to know a password. If
-this fails then run <userinput>klist tickets</userinput>. Did you get a ticket for the
-server? Does it have an encoding type of DES-CBC-MD5 ? 
-</para>
-
-</sect1>
-
-<sect1 id="ads-test-smbclient">
-<title>Testing with &smbclient;</title>
-
-<para>
-On your Samba server try to login to a Win2000 server or your Samba
-server using &smbclient; and kerberos. Use &smbclient; as usual, but
-specify the <parameter>-k</parameter> option to choose kerberos authentication.
-</para>
-
-</sect1>
-
-<sect1>
-<title>Notes</title>
-
-<para>You must change administrator password at least once after DC 
-install, to create the right encoding types</para>
-
-<para>w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in
-   their defaults DNS setup. Maybe fixed in service packs?</para>
-</sect1>
-
-</chapter>
diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.xml b/docs/docbook/projdoc/DOMAIN_MEMBER.xml
index a5921e8ce3..6a3ef28b55 100644
--- a/docs/docbook/projdoc/DOMAIN_MEMBER.xml
+++ b/docs/docbook/projdoc/DOMAIN_MEMBER.xml
@@ -3,159 +3,343 @@
 <chapterinfo>
 	&author.jeremy;
 	&author.jerry;
-	<pubdate>16 Apr 2001</pubdate>
+	&author.jht;
 </chapterinfo>
 
-
-<title>Samba as a NT4 or Win2k domain member</title>
+<title>Domain Membership</title>
 
 <sect1>
+<title>Domain Member Server</title>
+
+<para>
+This mode of server operation involves the samba machine being made a member
+of a domain security context. This means by definition that all user authentication
+will be done from a centrally defined authentication regime. The authentication
+regime may come from an NT3/4 style (old domain technology) server, or it may be
+provided from an Active Directory server (ADS) running on MS Windows 2000 or later.
+</para>
+
+<para><emphasis>
+Of course it should be clear that the authentication back end itself could be from any
+distributed directory architecture server that is supported by Samba. This can be
+LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory Server, etc.
+</emphasis></para>
+
+<para>
+Please refer to the section on Howto configure Samba as a Primary Domain Controller
+and for more information regarding how to create a domain machine account for a
+domain member server as well as for information regarding how to enable the samba
+domain member machine to join the domain and to be fully trusted by it.
+</para>
 
-	<title>Joining an NT Domain with Samba 3.0</title>
-	<para><emphasis>Assumptions:</emphasis>
-	<programlisting>
-		NetBIOS name: SERV1
-		Win2K/NT domain name: DOM
-		Domain's PDC NetBIOS name: DOMPDC
-		Domain's BDC NetBIOS names: DOMBDC1 and DOMBDC2
-	</programlisting>
-	</para>
-
-	<para>First, you must edit your &smb.conf; file to tell Samba it should
-	now use domain security.</para>
-	
-	<para>Change (or add) your <ulink url="smb.conf.5.html#SECURITY">
-	<parameter>security =</parameter></ulink> line in the [global] section 
-	of your &smb.conf; to read:</para>
-
-	<para><command>security = domain</command></para>
-
-	<para>Next change the <ulink url="smb.conf.5.html#WORKGROUP"><parameter>
-	workgroup =</parameter></ulink> line in the [global] section to read: </para>
-
-	<para><command>workgroup = DOM</command></para>
-
-	<para>as this is the name of the domain we are joining. </para>
-
-	<para>You must also have the parameter <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">
-	<parameter>encrypt passwords</parameter></ulink> set to <constant>yes
-	</constant> in order for your users to authenticate to the NT PDC.</para>
-
-	<para>Finally, add (or modify) a <ulink url="smb.conf.5.html#PASSWORDSERVER">
-	<parameter>password server =</parameter></ulink> line in the [global]
-	section to read: </para>
-
-	<para><command>password server = DOMPDC DOMBDC1 DOMBDC2</command></para>
-
-	<para>These are the primary and backup domain controllers Samba 
-	will attempt to contact in order to authenticate users. Samba will 
-	try to contact each of these servers in order, so you may want to 
-	rearrange this list in order to spread out the authentication load 
-	among domain controllers.</para>
-
-	<para>Alternatively, if you want smbd to automatically determine 
-	the list of Domain controllers to use for authentication, you may 
-	set this line to be :</para>
-
-	<para><command>password server = *</command></para>
-
-	<para>This method, allows Samba to use exactly the same
-        mechanism that NT does. This 
-	method either broadcasts or uses a WINS database in order to
-	find domain controllers to authenticate against.</para>
-
-	<para>In order to actually join the domain, you must run this
-        command:</para>
-
-	<para><prompt>root# </prompt><userinput>net join -S DOMPDC
-	-U<replaceable>Administrator%password</replaceable></userinput></para>
-
-	<para>
-	If the <userinput>-S DOMPDC</userinput> argument is not given then
-	the domain name will be obtained from smb.conf.
-	</para>
-
-	<para>as we are joining the domain DOM and the PDC for that domain 
-	(the only machine that has write access to the domain SAM database) 
-	is DOMPDC. The <replaceable>Administrator%password</replaceable> is 
-	the login name and password for an account which has the necessary 
-	privilege to add machines to the domain.  If this is successful 
-	you will see the message:</para>
-
-	<para><computeroutput>Joined domain DOM.</computeroutput>
-	or <computeroutput>Joined 'SERV1' to realm 'MYREALM'</computeroutput>
-	</para>
-
-	<para>in your terminal window. See the <ulink url="net.8.html">
-	net(8)</ulink> man page for more details.</para>
-	
-	<para>This process joins the server to the domain
-	without having to create the machine trust account on the PDC
-	beforehand.</para>
-
-	<para>This command goes through the machine account password 
-	change protocol, then writes the new (random) machine account 
-	password for this Samba server into a file in the same directory 
-	in which an smbpasswd file would be stored - normally :</para>
-
-	<para><filename>/usr/local/samba/private/secrets.tdb</filename></para>
-
-	<para>This file is created and owned by root and is not 
-	readable by any other user. It is the key to the domain-level 
-	security for your system, and should be treated as carefully 
-	as a shadow password file.</para>
-
-	<para>Finally, restart your Samba daemons and get ready for 
-	clients to begin using domain security!</para>
 </sect1>
 
 <sect1>
-	<title>Why is this better than security = server?</title>
-
-	<para>Currently, domain security in Samba doesn't free you from 
-	having to create local Unix users to represent the users attaching 
-	to your server. This means that if domain user <constant>DOM\fred
-	</constant> attaches to your domain security Samba server, there needs 
-	to be a local Unix user fred to represent that user in the Unix 
-	filesystem. This is very similar to the older Samba security mode 
-	<ulink url="smb.conf.5.html#SECURITYEQUALSSERVER">security = server</ulink>, 
-	where Samba would pass through the authentication request to a Windows 
-	NT server in the same way as a Windows 95 or Windows 98 server would.
-	</para>
-	
-	<para>Please refer to the <ulink url="winbind.html">Winbind 
-	paper</ulink> for information on a system to automatically
-	assign UNIX uids and gids to Windows NT Domain users and groups.
-	</para>
-
-	<para>The advantage to domain-level security is that the 
-	authentication in domain-level security is passed down the authenticated 
-	RPC channel in exactly the same way that an NT server would do it. This 
-	means Samba servers now participate in domain trust relationships in 
-	exactly the same way NT servers do (i.e., you can add Samba servers into 
-	a resource domain and have the authentication passed on from a resource
-	domain PDC to an account domain PDC).</para>
-
-	<para>In addition, with <command>security = server</command> every Samba 
-	daemon on a server has to keep a connection open to the 
-	authenticating server for as long as that daemon lasts. This can drain 
-	the connection resources on a Microsoft NT server and cause it to run 
-	out of available connections. With <command>security = domain</command>, 
-	however, the Samba daemons connect to the PDC/BDC only for as long 
-	as is necessary to authenticate the user, and then drop the connection, 
-	thus conserving PDC connection resources.</para>
-
-	<para>And finally, acting in the same manner as an NT server 
-	authenticating to a PDC means that as part of the authentication 
-	reply, the Samba server gets the user identification information such 
-	as the user SID, the list of NT groups the user belongs to, etc. </para>
-
-	<note><para> Much of the text of this document 
-	was first published in the Web magazine <ulink url="http://www.linuxworld.com"> 	
-	LinuxWorld</ulink> as the article <ulink
-	url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html">Doing 
-	the NIS/NT Samba</ulink>.</para></note>
+<title>Joining an NT4 type Domain with Samba-3</title>
+<para><emphasis>Assumptions:</emphasis>
+<programlisting>
+	NetBIOS name: SERV1
+	Win2K/NT domain name: DOM
+	Domain's PDC NetBIOS name: DOMPDC
+	Domain's BDC NetBIOS names: DOMBDC1 and DOMBDC2
+</programlisting>
+</para>
+
+<para>First, you must edit your &smb.conf; file to tell Samba it should
+now use domain security.</para>
+
+<para>Change (or add) your <ulink url="smb.conf.5.html#SECURITY">
+<parameter>security =</parameter></ulink> line in the [global] section 
+of your &smb.conf; to read:</para>
+
+<para><command>security = domain</command></para>
+
+<para>Next change the <ulink url="smb.conf.5.html#WORKGROUP"><parameter>
+workgroup =</parameter></ulink> line in the [global] section to read: </para>
+
+<para><command>workgroup = DOM</command></para>
+
+<para>as this is the name of the domain we are joining. </para>
+
+<para>You must also have the parameter <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">
+<parameter>encrypt passwords</parameter></ulink> set to <constant>yes
+</constant> in order for your users to authenticate to the NT PDC.</para>
+
+<para>Finally, add (or modify) a <ulink url="smb.conf.5.html#PASSWORDSERVER">
+<parameter>password server =</parameter></ulink> line in the [global]
+section to read: </para>
+
+<para><command>password server = DOMPDC DOMBDC1 DOMBDC2</command></para>
+
+<para>These are the primary and backup domain controllers Samba 
+will attempt to contact in order to authenticate users. Samba will 
+try to contact each of these servers in order, so you may want to 
+rearrange this list in order to spread out the authentication load 
+among domain controllers.</para>
+
+<para>Alternatively, if you want smbd to automatically determine 
+the list of Domain controllers to use for authentication, you may 
+set this line to be :</para>
+
+<para><command>password server = *</command></para>
+
+<para>This method, allows Samba to use exactly the same
+mechanism that NT does. This 
+method either broadcasts or uses a WINS database in order to
+find domain controllers to authenticate against.</para>
+
+<para>In order to actually join the domain, you must run this
+command:</para>
+
+<para><prompt>root# </prompt><userinput>net join -S DOMPDC
+-U<replaceable>Administrator%password</replaceable></userinput></para>
+
+<para>
+If the <userinput>-S DOMPDC</userinput> argument is not given then
+the domain name will be obtained from smb.conf.
+</para>
+
+<para>as we are joining the domain DOM and the PDC for that domain 
+(the only machine that has write access to the domain SAM database) 
+is DOMPDC. The <replaceable>Administrator%password</replaceable> is 
+the login name and password for an account which has the necessary 
+privilege to add machines to the domain.  If this is successful 
+you will see the message:</para>
+
+<para><computeroutput>Joined domain DOM.</computeroutput>
+or <computeroutput>Joined 'SERV1' to realm 'MYREALM'</computeroutput>
+</para>
+
+<para>in your terminal window. See the <ulink url="net.8.html">
+net(8)</ulink> man page for more details.</para>
+
+<para>This process joins the server to the domain
+without having to create the machine trust account on the PDC
+beforehand.</para>
+
+<para>This command goes through the machine account password 
+change protocol, then writes the new (random) machine account 
+password for this Samba server into a file in the same directory 
+in which an smbpasswd file would be stored - normally :</para>
+
+<para><filename>/usr/local/samba/private/secrets.tdb</filename></para>
+
+<para>This file is created and owned by root and is not 
+readable by any other user. It is the key to the domain-level 
+security for your system, and should be treated as carefully 
+as a shadow password file.</para>
+
+<para>Finally, restart your Samba daemons and get ready for 
+clients to begin using domain security!</para>
+
+<sect2>
+<title>Why is this better than security = server?</title>
+
+<para>Currently, domain security in Samba doesn't free you from 
+having to create local Unix users to represent the users attaching 
+to your server. This means that if domain user <constant>DOM\fred
+</constant> attaches to your domain security Samba server, there needs 
+to be a local Unix user fred to represent that user in the Unix 
+filesystem. This is very similar to the older Samba security mode 
+<ulink url="smb.conf.5.html#SECURITYEQUALSSERVER">security = server</ulink>, 
+where Samba would pass through the authentication request to a Windows 
+NT server in the same way as a Windows 95 or Windows 98 server would.
+</para>
+
+<para>Please refer to the <ulink url="winbind.html">Winbind 
+paper</ulink> for information on a system to automatically
+assign UNIX uids and gids to Windows NT Domain users and groups.
+</para>
+
+<para>The advantage to domain-level security is that the 
+authentication in domain-level security is passed down the authenticated 
+RPC channel in exactly the same way that an NT server would do it. This 
+means Samba servers now participate in domain trust relationships in 
+exactly the same way NT servers do (i.e., you can add Samba servers into 
+a resource domain and have the authentication passed on from a resource
+domain PDC to an account domain PDC).</para>
+
+<para>In addition, with <command>security = server</command> every Samba 
+daemon on a server has to keep a connection open to the 
+authenticating server for as long as that daemon lasts. This can drain 
+the connection resources on a Microsoft NT server and cause it to run 
+out of available connections. With <command>security = domain</command>, 
+however, the Samba daemons connect to the PDC/BDC only for as long 
+as is necessary to authenticate the user, and then drop the connection, 
+thus conserving PDC connection resources.</para>
+
+<para>And finally, acting in the same manner as an NT server 
+authenticating to a PDC means that as part of the authentication 
+reply, the Samba server gets the user identification information such 
+as the user SID, the list of NT groups the user belongs to, etc. </para>
+
+<note><para> Much of the text of this document 
+was first published in the Web magazine <ulink url="http://www.linuxworld.com"> 	
+LinuxWorld</ulink> as the article <ulink
+url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html">Doing 
+the NIS/NT Samba</ulink>.</para></note>
+</sect2>
 
 </sect1>
 
+<sect1>
+<title>Samba ADS Domain Membership</title>
+
+<para>
+This is a rough guide to setting up Samba 3.0 with kerberos authentication against a
+Windows2000 KDC. 
+</para> 
+
+<sect2>
+<title>Setup your <filename>smb.conf</filename></title>
+
+<para>You must use at least the following 3 options in smb.conf:</para>
+
+<para><programlisting>
+	realm = YOUR.KERBEROS.REALM
+	security = ADS
+	encrypt passwords = yes
+</programlisting></para>
+
+<para>
+In case samba can't figure out your ads server using your realm name, use the 
+<command>ads server</command> option in <filename>smb.conf</filename>:
+<programlisting>
+	ads server = your.kerberos.server
+</programlisting>
+</para>
+
+<note><para>You do *not* need a smbpasswd file, and older clients will
+  be authenticated as if <command>security = domain</command>,
+  although it won't do any harm
+  and allows you to have local users not in the domain.
+  I expect that the above required options will change soon when we get better
+  active directory integration.</para></note>
+
+</sect2>
+  
+<sect2>
+<title>Setup your <filename>/etc/krb5.conf</filename></title>
+
+<para>Note: you will need the krb5 workstation, devel, and libs installed</para>
+
+<para>The minimal configuration for <filename>krb5.conf</filename> is:</para>
+
+<para><programlisting>
+	[realms]
+	    YOUR.KERBEROS.REALM = {
+		kdc = your.kerberos.server
+	    }
+</programlisting></para>
+
+<para>Test your config by doing a <userinput>kinit
+<replaceable>USERNAME</replaceable>@<replaceable>REALM</replaceable></userinput> and
+making sure that your password is accepted by the Win2000 KDC.
+</para>
+
+<note><para>The realm must be uppercase or you will get "Cannot find KDC for requested
+realm while getting initial credentials" error </para></note>
+
+<note><para>Time between the two servers must be synchronized.  You will get a
+"kinit(v5): Clock skew too great while getting initial credentials" if the time
+difference is more than five minutes. </para></note>
+
+<para>
+You also must ensure that you can do a reverse DNS lookup on the IP
+address of your KDC. Also, the name that this reverse lookup maps to
+must either be the netbios name of the KDC (ie. the hostname with no
+domain attached) or it can alternatively be the netbios name
+followed by the realm. 
+</para>
+
+<para>
+The easiest way to ensure you get this right is to add a 
+<filename>/etc/hosts</filename> entry mapping the IP address of your KDC to 
+its netbios name. If you don't get this right then you will get a 
+"local error" when you try to join the realm.
+</para>
+
+<para>
+If all you want is kerberos support in &smbclient; then you can skip
+straight to <link linkend="ads-test-smbclient">Test with &smbclient;</link> now. 
+<link linkend="ads-create-machine-account">Creating a computer account</link> 
+and <link linkend="ads-test-server">testing your servers</link>
+is only needed if you want kerberos support for &smbd; and &winbindd;.
+</para>
+
+</sect2>
+
+<sect2 id="ads-create-machine-account">
+<title>Create the computer account</title>
+
+<para>
+As a user that has write permission on the Samba private directory
+(usually root) run:
+<programlisting>
+	<userinput>net join -U Administrator%password</userinput>
+</programlisting>
+</para>
+
+<sect3>
+<title>Possible errors</title>
+
+<para>
+<variablelist>
+	<varlistentry><term>"ADS support not compiled in"</term>
+	<listitem><para>Samba must be reconfigured (remove config.cache) and recompiled
+	(make clean all install) after the kerberos libs and headers are installed.
+	</para></listitem></varlistentry>
+
+	<varlistentry><term>net join prompts for user name</term>
+	<listitem><para>You need to login to the domain using <userinput>kinit
+	<replaceable>USERNAME</replaceable>@<replaceable>REALM</replaceable></userinput>.
+	<replaceable>USERNAME</replaceable> must be a user who has rights to add a machine
+	to the domain.  </para></listitem></varlistentry>
+</variablelist>
+</para>
+
+</sect3>
+
+</sect2>
+
+<sect2 id="ads-test-server">
+<title>Test your server setup</title>
+
+<para>
+If the join was successful, you will see a new computer account with the
+NetBIOS name of your Samba server in Active Directory (in the "Computers"
+folder under Users and Computers.
+</para>
+
+<para>
+On a Windows 2000 client try <userinput>net use * \\server\share</userinput>. You should
+be logged in with kerberos without needing to know a password. If
+this fails then run <userinput>klist tickets</userinput>. Did you get a ticket for the
+server? Does it have an encoding type of DES-CBC-MD5 ? 
+</para>
+
+</sect2>
+
+<sect2 id="ads-test-smbclient">
+<title>Testing with &smbclient;</title>
+
+<para>
+On your Samba server try to login to a Win2000 server or your Samba
+server using &smbclient; and kerberos. Use &smbclient; as usual, but
+specify the <parameter>-k</parameter> option to choose kerberos authentication.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Notes</title>
+
+<para>You must change administrator password at least once after DC 
+install, to create the right encoding types</para>
+
+<para>w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in
+   their defaults DNS setup. Maybe fixed in service packs?</para>
+</sect2>
+
+</sect1>
 </chapter>
diff --git a/docs/docbook/projdoc/Other-Clients.xml b/docs/docbook/projdoc/Other-Clients.xml
index 068b9c0b32..b9f4cf3a93 100644
--- a/docs/docbook/projdoc/Other-Clients.xml
+++ b/docs/docbook/projdoc/Other-Clients.xml
@@ -310,7 +310,7 @@ likely occur if it is not.
 </para>
 
 <para> 
-In order to server profiles successfully to Windows 2000 SP2 
+In order to serve profiles successfully to Windows 2000 SP2 
 clients (when not operating as a PDC), Samba must have 
 <command>nt acl support = no</command>
 added to the file share which houses the roaming profiles.
diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml
index 2f3b568471..cf5684feca 100644
--- a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml
+++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml
@@ -5,24 +5,15 @@
 	<pubdate> (26 Apr 2001) </pubdate>
 </chapterinfo>
 
-<title>
-Samba Backup Domain Controller to Samba Domain Control
-</title>
-
-<sect1>
-<title>Prerequisite Reading</title>
+<title>Backup Domain Control</title>
 
 <para>
-Before you continue reading in this chapter, please make sure
+Before you continue reading in this section, please make sure
 that you are comfortable with configuring a Samba PDC
 as described in the <ulink url="Samba-PDC-HOWTO.html">Samba-PDC-HOWTO</ulink>.
 </para>
 
-
-</sect1>
-
 <sect1>
-
 <title>Background</title>
 
 <para>
@@ -68,10 +59,7 @@ set along with settings for the profile path, the users home drive and
 others. This will not be covered in this document.
 </para>
 
-</sect1>
-
-
-<sect1>
+<sect2>
 <title>What qualifies a Domain Controller on the network?</title>
 
 <para>
@@ -85,6 +73,7 @@ Microsoft Domain implementation requires the domain master browser to
 be on the same machine as the PDC.
 </para>
 
+</sect2>
 
 <sect2>
 <title>How does a Workstation find its domain controller?</title>
@@ -236,6 +225,7 @@ password.
 
 
 </sect2>
+
 <sect2>
 <title>Can I do this all with LDAP?</title>
 <para>The simple answer is YES.  Samba's pdb_ldap code supports
diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml
index 0189b59f2e..9bbcb134b4 100644
--- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml
+++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml
@@ -14,13 +14,7 @@
 	<pubdate> (26 Apr 2001) </pubdate>
 </chapterinfo>
 
-<title>
-Samba as an NT4 or Win2k Primary Domain Controller
-</title>
-
-
-<sect1>
-<title>Prerequisite Reading</title>
+<title>Domain Control</title>
 
 <para>
 Before you continue reading in this chapter, please make sure 
@@ -30,16 +24,61 @@ encryption in Samba.  Theses two topics are covered in the
 &smb.conf; manpage.
 </para>
 
-
-</sect1>
-
-
-
 <sect1>
 <title>
 Background
 </title>
 
+<sect2>
+<title>Domain Controller</title>
+
+<para>
+Over the years public perceptions of what Domain Control really is has taken on an
+almost mystical nature. Before we branch into a brief overview of what Domain Control
+is the following types of controller are known:
+</para>
+
+<sect3>
+<title>Domain Controller Types</title>
+
+<simplelist>
+	<member>Primary Domain Controller</member>
+	<member>Backup Domain Controller</member>
+	<member>ADS Domain Controller</member>
+</simplelist>
+
+<para>
+The <emphasis>Primary Domain Controller</emphasis> or PDC plays an important role in the MS 
+Windows NT3 and NT4 Domain Control architecture, but not in the manner that so many
+expect. The PDC seeds the Domain Control database (a part of the Windows registry) and
+it plays a key part in synchronisation of the domain authentication database. 
+</para>
+
+<para>
+New to Samba-3.0.0 is the ability to use a back-end file that holds the same type of data as
+the NT4 style SAM (Security Account Manager) database (one of the registry files).
+The samba-3.0.0 SAM can be specified via the smb.conf file parameter "passwd backend" and
+valid options include <emphasis> smbpasswd tdbsam ldapsam nisplussam plugin unixsam</emphasis>.
+The smbpasswd, tdbsam and ldapsam options can have a "_nua" suffix to indicate that No Unix
+Accounts need to be created. In other words, the Samba SAM will be independant of Unix/Linux
+system accounts, provided a uid range is defined from which SAM accounts can be created.
+</para>
+
+<para>
+The <emphasis>Backup Domain Controller</emphasis> or BDC plays a key role in servicing network
+authentication requests. The BDC is biased to answer logon requests so that on a network segment
+that has a BDC and a PDC the BDC will be most likely to service network logon requests. The PDC will
+answer network logon requests when the BDC is too busy (high load). A BDC can be promoted to
+a PDC. If the PDC is on line at the time that the BDC is promoted to PDC the previous PDC is
+automatically demoted to a BDC.
+</para>
+
+<para>
+At this time Samba is NOT capable of acting as an <emphasis>ADS Domain Controller</emphasis>.
+</para>
+</sect3>
+</sect2>
+
 <para>
 This article outlines the steps necessary for configuring Samba as a PDC.
 It is necessary to have a working Samba server prior to implementing the
@@ -140,22 +179,19 @@ steps.
 </orderedlist>
 
 <para>
-There are other minor details such as user profiles, system
-policies, etc...  However, these are not necessarily specific
-to a Samba PDC as much as they are related to Windows NT networking
-concepts.
+There are other minor details such as user profiles, system policies, etc... 
+However, these are not necessarily specific to a Samba PDC as much as they are
+related to Windows NT networking concepts.
 </para>
 
 </sect1>
 
-
 <sect1>
-<title>Configuring the Samba Domain Controller</title>
+<title>Configuring Samba NT4 Style Domain Control</title>
 
 <para>
-The first step in creating a working Samba PDC is to 
-understand the parameters necessary in smb.conf. Here we
-attempt to explain the parameters that are covered in
+The first step in creating a working Samba PDC is to understand the parameters necessary
+in &smb.conf;. Here we attempt to explain the parameters that are covered in
 the &smb.conf; man page.
 </para>
 
@@ -164,54 +200,53 @@ Here is an example &smb.conf; for acting as a PDC:
 </para>
 
 <para><programlisting>
-[global]
-    ; Basic server settings
-    <ulink url="smb.conf.5.html#NETBIOSNAME">netbios name</ulink> = <replaceable>POGO</replaceable>
-    <ulink url="smb.conf.5.html#WORKGROUP">workgroup</ulink> = <replaceable>NARNIA</replaceable>
-
-    ; User and Machine Account Backends
-    ; Choices are: tdbsam, tdbsam_nua, smbpasswd, smbpasswd_nua, ldapsam, ldapsam_nua, ...
-    ;              mysqlsam, xmlsam, guest
-    <ulink url="smb.conf.5.html#PASSDBBACKEND">passdb backend</ulink> = ldapsam, guest
-
-    ; we should act as the domain and local master browser
-    <ulink url="smb.conf.5.html#OSLEVEL">os level</ulink> = 64
-    <ulink url="smb.conf.5.html#PERFERREDMASTER">preferred master</ulink> = yes
-    <ulink url="smb.conf.5.html#DOMAINMASTER">domain master</ulink> = yes
-    <ulink url="smb.conf.5.html#LOCALMASTER">local master</ulink> = yes
-    
-    ; security settings (must user security = user)
-    <ulink url="smb.conf.5.html#SECURITYEQUALSUSER">security</ulink> = user
-    
-    ; encrypted passwords are a requirement for a PDC
-    <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords</ulink> = yes
-    
-    ; support domain logons
-    <ulink url="smb.conf.5.html#DOMAINLOGONS">domain logons</ulink> = yes
-    
-    ; where to store user profiles?
-    <ulink url="smb.conf.5.html#LOGONPATH">logon path</ulink> = \\%N\profiles\%u
-    
-    ; where is a user's home directory and where should it be mounted at?
-    <ulink url="smb.conf.5.html#LOGONDRIVE">logon drive</ulink> = H:
-    <ulink url="smb.conf.5.html#LOGONHOME">logon home</ulink> = \\homeserver\%u
-    
-    ; specify a generic logon script for all users
-    ; this is a relative **DOS** path to the [netlogon] share
-    <ulink url="smb.conf.5.html#LOGONSCRIPT">logon script</ulink> = logon.cmd
-
-; necessary share for domain controller
-[netlogon]
-    <ulink url="smb.conf.5.html#PATH">path</ulink> = /usr/local/samba/lib/netlogon
-    <ulink url="smb.conf.5.html#READONLY">read only</ulink> = yes
-    <ulink url="smb.conf.5.html#WRITELIST">write list</ulink> = <replaceable>ntadmin</replaceable>
-    
-; share for storing user profiles
-[profiles]
-    <ulink url="smb.conf.5.html#PATH">path</ulink> = /export/smb/ntprofile
-    <ulink url="smb.conf.5.html#READONLY">read only</ulink> = no
-    <ulink url="smb.conf.5.html#CREATEMASK">create mask</ulink> = 0600
-    <ulink url="smb.conf.5.html#DIRECTORYMASK">directory mask</ulink> = 0700
+	[global]
+	    ; Basic server settings
+	    <ulink url="smb.conf.5.html#NETBIOSNAME">netbios name</ulink> = <replaceable>POGO</replaceable>
+	    <ulink url="smb.conf.5.html#WORKGROUP">workgroup</ulink> = <replaceable>NARNIA</replaceable>
+
+	    ; User and Machine Account Backends
+	    ; Choices are: tdbsam, smbpasswd, ldapsam, mysqlsam, xmlsam, guest
+	    <ulink url="smb.conf.5.html#PASSDBBACKEND">passdb backend</ulink> = ldapsam, guest
+
+	    ; we should act as the domain and local master browser
+	    <ulink url="smb.conf.5.html#OSLEVEL">os level</ulink> = 64
+	    <ulink url="smb.conf.5.html#PERFERREDMASTER">preferred master</ulink> = yes
+	    <ulink url="smb.conf.5.html#DOMAINMASTER">domain master</ulink> = yes
+	    <ulink url="smb.conf.5.html#LOCALMASTER">local master</ulink> = yes
+	    
+	    ; security settings (must user security = user)
+	    <ulink url="smb.conf.5.html#SECURITYEQUALSUSER">security</ulink> = user
+	    
+	    ; encrypted passwords are a requirement for a PDC
+	    <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords</ulink> = yes
+	    
+	    ; support domain logons
+	    <ulink url="smb.conf.5.html#DOMAINLOGONS">domain logons</ulink> = yes
+	    
+	    ; where to store user profiles?
+	    <ulink url="smb.conf.5.html#LOGONPATH">logon path</ulink> = \\%N\profiles\%u
+	    
+	    ; where is a user's home directory and where should it be mounted at?
+	    <ulink url="smb.conf.5.html#LOGONDRIVE">logon drive</ulink> = H:
+	    <ulink url="smb.conf.5.html#LOGONHOME">logon home</ulink> = \\homeserver\%u
+	    
+	    ; specify a generic logon script for all users
+	    ; this is a relative **DOS** path to the [netlogon] share
+	    <ulink url="smb.conf.5.html#LOGONSCRIPT">logon script</ulink> = logon.cmd
+
+	; necessary share for domain controller
+	[netlogon]
+	    <ulink url="smb.conf.5.html#PATH">path</ulink> = /usr/local/samba/lib/netlogon
+	    <ulink url="smb.conf.5.html#READONLY">read only</ulink> = yes
+	    <ulink url="smb.conf.5.html#WRITELIST">write list</ulink> = <replaceable>ntadmin</replaceable>
+	    
+	; share for storing user profiles
+	[profiles]
+	    <ulink url="smb.conf.5.html#PATH">path</ulink> = /export/smb/ntprofile
+	    <ulink url="smb.conf.5.html#READONLY">read only</ulink> = no
+	    <ulink url="smb.conf.5.html#CREATEMASK">create mask</ulink> = 0600
+	    <ulink url="smb.conf.5.html#DIRECTORYMASK">directory mask</ulink> = 0700
 </programlisting></para>
 
 <note><para>
@@ -257,10 +292,7 @@ between Windows NT groups and Unix groups (this is really quite
 complicated to explain in a short space).
 </para>
 
-</sect1>
-
-
-<sect1>
+<sect2>
 <title>Creating Machine Trust Accounts and Joining Clients to the Domain</title>
 
 <para>
@@ -281,8 +313,13 @@ because it does not possess a machine trust account, and thus has no
 shared secret with the domain controller.
 </para>
 
-<para>A Windows PDC stores each machine trust account in the Windows
-Registry. A Samba-3 PDC also has to store machine trust account information
+<para>A Windows NT4 PDC stores each machine trust account in the Windows
+Registry. The introduction of MS Windows 2000 saw the introduction of Active Directory,
+the new repository for machine trust accounts.
+</para>
+
+<para>
+A Samba-3 PDC also has to store machine trust account information
 in a suitable backend data store. With Samba-3 there can be multiple back-ends
 for this including:
 </para>
@@ -297,13 +334,6 @@ for this including:
 	</para></listitem>
 
 	<listitem><para>
-	<emphasis>smbpasswd_nua</emphasis> - This file is independant of the
-	system wide user accounts. The use of this back-end option requires
-	specification of the "non unix account range" option also. It is called
-	smbpasswd and will be located in the <filename>private</filename> directory.
-	</para></listitem>
-
-	<listitem><para>
 	<emphasis>tdbsam</emphasis> - a binary database backend that will be
 	stored in the <emphasis>private</emphasis> directory in a file called
 	<emphasis>passwd.tdb</emphasis>. The key benefit of this binary format
@@ -312,22 +342,9 @@ for this including:
 	</para></listitem>
 
 	<listitem><para>
-	<emphasis>tdbsam_nua</emphasis> like the smbpasswd_nua option above, this
-	file allows the creation of arbitrary user and machine accounts without
-	requiring that account to be added to the system (/etc/passwd) file. It
-	too requires the specification of the "non unix account range" option
-	in the [globals] section of the &smb.conf; file.
-	</para></listitem>
-
-	<listitem><para>
 	<emphasis>ldapsam</emphasis> - An LDAP based back-end. Permits the
 	LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com
 	</para></listitem>
-
-	<listitem><para>
-	<emphasis>ldapsam_nua</emphasis> - LDAP based back-end with no unix
-	account requirement, like smbpasswd_nua and tdbsam_nua above.
-	</para></listitem>
 </itemizedlist>
 
 <para>Read the chapter about the <link linkend="passdb">User Database</link> 
@@ -346,9 +363,8 @@ as follows:
 
 <itemizedlist>
     <listitem><para>A Samba account, stored in the same location as user
-    LanMan and NT password hashes (currently
-    <filename>smbpasswd</filename>). The Samba account 
-    possesses and uses only the NT password hash.</para></listitem>
+    LanMan and NT password hashes (currently <filename>smbpasswd</filename>).
+    The Samba account possesses and uses only the NT password hash.</para></listitem>
 
     <listitem><para>A corresponding Unix account, typically stored in
     <filename>/etc/passwd</filename>. (Future releases will alleviate the need to
@@ -373,7 +389,7 @@ There are two ways to create machine trust accounts:
 
 </itemizedlist>
 
-<sect2>
+<sect3>
 <title>Manual Creation of Machine Trust Accounts</title>
 
 <para>
@@ -452,10 +468,10 @@ the corresponding Unix account.
 	information to such clients.  You have been warned!
 	</para>
 </warning>
-</sect2>
+</sect3>
 
 
-<sect2>
+<sect3>
 <title>"On-the-Fly" Creation of Machine Trust Accounts</title>
 
 <para>
@@ -482,10 +498,10 @@ be created manually.
    add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u 
 </programlisting></para>
 
-</sect2>
+</sect3>
 
 
-<sect2><title>Joining the Client to the Domain</title>
+<sect3><title>Joining the Client to the Domain</title>
 
 <para>
 The procedure for joining a client to the domain varies with the
@@ -535,122 +551,17 @@ version of Windows.
 </para></listitem>
 </itemizedlist>
 
+</sect3>
 </sect2>
 </sect1>
 
 <sect1>
-<title>Common Problems and Errors</title>
-
-<sect2>
-<title>I cannot include a '$' in a machine name</title>
-<para>
-A 'machine name' in (typically) <filename>/etc/passwd</filename> 	
-of the machine name with a '$' appended. FreeBSD (and other BSD 
-systems?) won't create a user with a '$' in their name.
-</para>
-
-<para>
-The problem is only in the program used to make the entry. Once made, it works perfectly.
-Create a user without the '$' using <command>vipw</command> to edit the entry, adding
-the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID!
-</para>
-</sect2>
-
-<sect2>
-<title>I get told "You already have a connection to the Domain...." 
-or "Cannot join domain, the credentials supplied conflict with an 
-existing set.." when creating a machine trust account.</title>
-
-<para>
-This happens if you try to create a machine trust account from the 
-machine itself and already have a connection (e.g. mapped drive) 
-to a share (or IPC$) on the Samba PDC.  The following command
-will remove all network drive connections:
-</para>
+<title>Samba ADS Domain Control</title>
 
 <para>
-<prompt>C:\WINNT\></prompt> <command>net use * /d</command>
+Not yet Freddie!
 </para>
 
-<para>
-Further, if the machine is already a 'member of a workgroup' that 
-is the same name as the domain you are joining (bad idea) you will 
-get this message.  Change the workgroup name to something else, it 
-does not matter what, reboot, and try again.
-</para>
-</sect2>
-
-<sect2>
-<title>The system can not log you on (C000019B)....</title>
-
-<para>I joined the domain successfully but after upgrading 
-to a newer version of the Samba code I get the message, "The system 
-can not log you on (C000019B), Please try again or consult your 
-system administrator" when attempting to logon.
-</para>
-
-<para>
-This occurs when the domain SID stored in the secrets.tdb database
-is changed. The most common cause of a change in domain SID is when
-the domain name and/or the server name (netbios name) is changed.
-The only way to correct the problem is to restore the original domain 
-SID or remove the domain client from the domain and rejoin. The domain
-SID may be reset using either the net or rpcclient utilities.
-</para>
-
-<para>
-The reset or change the domain SID you can use the net command as follows:
-
-<programlisting>
-	net getlocalsid 'OLDNAME'
-	net setlocalsid 'SID'
-</programlisting>
-</para>
-
-</sect2>
-
-<sect2>
-<title>The machine trust account for this computer either does not 
-exist or is not accessible.</title>
-
-<para>
-When I try to join the domain I get the message "The machine account 
-for this computer either does not exist or is not accessible". What's 
-wrong?
-</para>
-
-<para>
-This problem is caused by the PDC not having a suitable machine trust account. 
-If you are using the <parameter>add machine script</parameter> method to create 
-accounts then this would indicate that it has not worked. Ensure the domain 
-admin user system is working.
-</para>
-
-<para>
-Alternatively if you are creating account entries manually then they 
-have not been created correctly. Make sure that you have the entry 
-correct for the machine trust account in smbpasswd file on the Samba PDC. 
-If you added the account using an editor rather than using the smbpasswd 
-utility, make sure that the account name is the machine NetBIOS name 
-with a '$' appended to it ( i.e. computer_name$ ). There must be an entry 
-in both /etc/passwd and the smbpasswd file. Some people have reported 
-that inconsistent subnet masks between the Samba server and the NT 
-client have caused this problem.   Make sure that these are consistent 
-for both client and server.
-</para>
-</sect2>
-
-<sect2>
-<title>When I attempt to login to a Samba Domain from a NT4/W2K workstation,
-I get a message about my account being disabled.</title>
-
-<para>
-At first be ensure to enable the useraccounts with <command>smbpasswd -e 
-%user%</command>, this is normally done, when you create an account.
-</para>
-
-</sect2>
-
 </sect1>
 
 <sect1>
@@ -767,11 +678,10 @@ worthwhile to look at how a Windows 9x/ME client performs a logon:
 
 
 <sect2>
-<title>Configuration Instructions:	Network Logons</title>
+<title>Configuring Network Logon Capability</title>
 
 <para>
-The main difference between a PDC and a Windows 9x logon 
-server configuration is that
+The main difference between a PDC and a Windows 9x logon server configuration is that
 </para>
 
 <itemizedlist>
@@ -787,8 +697,7 @@ Windows 9x/ME clients do not possess machine trust accounts.
 </itemizedlist>
 
 <para>
-Therefore, a Samba PDC will also act as a Windows 9x logon 
-server.
+Therefore, a Samba PDC will also act as a Windows 9x logon server.
 </para>
 
 
@@ -839,4 +748,118 @@ for its domain.
 
 </sect2>
 </sect1>
+
+<sect1>
+<title>Common Problems and Errors</title>
+
+<sect2>
+<title>I cannot include a '$' in a machine name</title>
+<para>
+A 'machine name' in (typically) <filename>/etc/passwd</filename> 	
+of the machine name with a '$' appended. FreeBSD (and other BSD 
+systems?) won't create a user with a '$' in their name.
+</para>
+
+<para>
+The problem is only in the program used to make the entry. Once made, it works perfectly.
+Create a user without the '$' using <command>vipw</command> to edit the entry, adding
+the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID!
+</para>
+</sect2>
+
+<sect2>
+<title>I get told "You already have a connection to the Domain...." 
+or "Cannot join domain, the credentials supplied conflict with an 
+existing set.." when creating a machine trust account.</title>
+
+<para>
+This happens if you try to create a machine trust account from the 
+machine itself and already have a connection (e.g. mapped drive) 
+to a share (or IPC$) on the Samba PDC.  The following command
+will remove all network drive connections:
+</para>
+
+<para>
+<prompt>C:\WINNT\></prompt> <command>net use * /d</command>
+</para>
+
+<para>
+Further, if the machine is already a 'member of a workgroup' that 
+is the same name as the domain you are joining (bad idea) you will 
+get this message.  Change the workgroup name to something else, it 
+does not matter what, reboot, and try again.
+</para>
+</sect2>
+
+<sect2>
+<title>The system can not log you on (C000019B)....</title>
+
+<para>I joined the domain successfully but after upgrading 
+to a newer version of the Samba code I get the message, "The system 
+can not log you on (C000019B), Please try again or consult your 
+system administrator" when attempting to logon.
+</para>
+
+<para>
+This occurs when the domain SID stored in the secrets.tdb database
+is changed. The most common cause of a change in domain SID is when
+the domain name and/or the server name (netbios name) is changed.
+The only way to correct the problem is to restore the original domain 
+SID or remove the domain client from the domain and rejoin. The domain
+SID may be reset using either the net or rpcclient utilities.
+</para>
+
+<para>
+The reset or change the domain SID you can use the net command as follows:
+
+<programlisting>
+	net getlocalsid 'OLDNAME'
+	net setlocalsid 'SID'
+</programlisting>
+</para>
+
+</sect2>
+
+<sect2>
+<title>The machine trust account for this computer either does not 
+exist or is not accessible.</title>
+
+<para>
+When I try to join the domain I get the message "The machine account 
+for this computer either does not exist or is not accessible". What's 
+wrong?
+</para>
+
+<para>
+This problem is caused by the PDC not having a suitable machine trust account. 
+If you are using the <parameter>add machine script</parameter> method to create 
+accounts then this would indicate that it has not worked. Ensure the domain 
+admin user system is working.
+</para>
+
+<para>
+Alternatively if you are creating account entries manually then they 
+have not been created correctly. Make sure that you have the entry 
+correct for the machine trust account in smbpasswd file on the Samba PDC. 
+If you added the account using an editor rather than using the smbpasswd 
+utility, make sure that the account name is the machine NetBIOS name 
+with a '$' appended to it ( i.e. computer_name$ ). There must be an entry 
+in both /etc/passwd and the smbpasswd file. Some people have reported 
+that inconsistent subnet masks between the Samba server and the NT 
+client have caused this problem.   Make sure that these are consistent 
+for both client and server.
+</para>
+</sect2>
+
+<sect2>
+<title>When I attempt to login to a Samba Domain from a NT4/W2K workstation,
+I get a message about my account being disabled.</title>
+
+<para>
+At first be ensure to enable the useraccounts with <command>smbpasswd -e 
+%user%</command>, this is normally done, when you create an account.
+</para>
+
+</sect2>
+</sect1>
 </chapter>
diff --git a/docs/docbook/projdoc/ServerType.xml b/docs/docbook/projdoc/ServerType.xml
index 7229a50201..2a745733a6 100644
--- a/docs/docbook/projdoc/ServerType.xml
+++ b/docs/docbook/projdoc/ServerType.xml
@@ -1,16 +1,31 @@
 <chapter id="ServerType">
 <chapterinfo>
+	&author.tridge;
+	&author.jelmer;
 	&author.jht;
 </chapterinfo>
 
-<title>Nomenclature of Server Types</title>
+<title>Server Types and Security Modes</title>
+
+<para>
+This chapter provides information regarding the types of server that Samba may be
+configured to be. A Microsoft network administrator who wishes to migrate to or to
+use Samba will want to know what within a Samba context, terms familiar to MS Windows
+adminstrator mean.
+</para>
+
+<para>
+The chapter also provides an overview of the security modes of which Samba is capable
+and how these relate to MS Windows servers and clients.
+</para>
+
+<sect1>
+<title>Server Types</title>
 
 <para>Adminstrators of Microsoft networks often refer to there being three
 different type of servers:</para>
 
 <itemizedlist>
-	<listitem><para>Stand Alone Server</para></listitem>
-	<listitem><para>Domain Member Server</para></listitem>
 	<listitem><para>Domain Controller</para>
 		<itemizedlist>
 			<listitem><para>Primary Domain Controller</para></listitem>
@@ -18,126 +33,423 @@ different type of servers:</para>
 			<listitem><para>ADS Domain Controller</para></listitem>
 		</itemizedlist>
 	</listitem>
+	<listitem><para>Domain Member Server</para>
+		<itemizedlist>
+			<listitem><para>Active Directory Member Server</para></listitem>
+			<listitem><para>NT4 Style Domain Member Server</para></listitem>
+		</itemizedlist>
+	</listitem>
+	<listitem><para>Stand Alone Server</para></listitem>
 </itemizedlist>
 
-<para>A network administrator who is familiar with these terms and who
-wishes to migrate to or use Samba will want to know what these terms mean
-within a Samba context.</para>
+<para>
+The chapters covering Domain Control, Backup Domain Control and Domain Membership provide
+pertinent information regarding Samba-3 configuration for each of these server roles.
+The reader is strongly encouraged to become intimately familiar with the information 
+presented.
+</para>
+
+</sect1>
 
 <sect1>
-<title>Stand Alone Server</title>
+<title>Samba Security Modes</title>
+
+<para>
+In this section the function and purpose of Samba's <emphasis>security</emphasis>
+modes are described. An acurate understanding of how Samba implements each security
+mode as well as how to configure MS Windows clients for each mode will significantly
+reduce user complaints and administrator heartache.
+</para>
 
 <para>
-The term <emphasis>stand alone server</emphasis> means that the server
-will provide local authentication and access control for all resources
-that are available from it. In general this means that there will be a
-local user database. In more technical terms, it means that resources
-on the machine will either be made available in either SHARE mode or in
-USER mode. SHARE mode and USER mode security are documented under
-discussions regarding "security mode". The smb.conf configuration parameters
-that control security mode are: "security = user" and "security = share".
+A SMB server tells the client at startup what <emphasis>security level</emphasis>
+it is running. There are two options <emphasis>share level</emphasis> and
+<emphasis>user level</emphasis>. Which of these two the client receives affects
+the way the client then tries to authenticate itself. It does not directly affect
+(to any great extent) the way the Samba server does security. This may sound strange,
+but it fits in with the client/server approach of SMB. In SMB everything is initiated
+and controlled by the client, and the server can only tell the client what is
+available and whether an action is allowed.
 </para>
 
+<sect2>
+<title>User Level Security</title>
+
 <para>
-No special action is needed other than to create user accounts. Stand-alone
-servers do NOT provide network logon services, meaning that machines that
-use this server do NOT perform a domain logon but instead make use only of
-the MS Windows logon which is local to the MS Windows workstation/server.
+We will describe<emphasis>user level</emphasis> security first, as its simpler.
+In <emphasis>user level</emphasis> security the client will send a
+<emphasis>session setup</emphasis> command directly after the protocol negotiation.
+This contains a username and password. The server can either accept or reject that
+username/password combination. Note that at this stage the server has no idea what
+share the client will eventually try to connect to, so it can't base the
+<emphasis>accept/reject</emphasis> on anything other than:
 </para>
 
+<orderedlist>
+<listitem><para>The username/password</para></listitem>
+<listitem><para>The name of the client machine</para></listitem>
+</orderedlist>
+
 <para>
-Samba tends to blur the distinction a little in respect of what is
-a stand alone server. This is because the authentication database may be
-local or on a remote server, even if from the samba protocol perspective
-the samba server is NOT a member of a domain security context.
+If the server accepts the username/password then the client expects to be able to
+mount shares (using a <emphasis>tree connection</emphasis>) without specifying a
+password. It expects that all access rights will be as the username/password
+specified in the <emphasis>session setup</emphasis>.
 </para>
 
 <para>
-Through the use of PAM (Pluggable Authentication Modules) and nsswitch
-(the name service switcher) the source of authentication may reside on 
-another server. We would be inclined to call this the authentication server.
-This means that the samba server may use the local Unix/Linux system
-password database (/etc/passwd or /etc/shadow), may use a local smbpasswd
-file (/etc/samba/smbpasswd or /usr/local/samba/lib/private/smbpasswd), or
-may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB
-server for authentication.
+It is also possible for a client to send multiple <emphasis>session setup</emphasis>
+requests. When the server responds it gives the client a <emphasis>uid</emphasis> to use
+as an authentication tag for that username/password. The client can maintain multiple
+authentication contexts in this way (WinDD is an example of an application that does this).
 </para>
 
-</sect1>
+<sect3>
+<title>Example Configuration</title>
 
-<sect1>
-<title>Domain Member Server</title>
+<para>
+The &smb.conf; parameter that sets <emphasis>User Level Security</emphasis> is:
+</para>
+
+<para><programlisting>
+	security = user
+</programlisting></para>
 
 <para>
-This mode of server operation involves the samba machine being made a member
-of a domain security context. This means by definition that all user authentication
-will be done from a centrally defined authentication regime. The authentication
-regime may come from an NT3/4 style (old domain technology) server, or it may be
-provided from an Active Directory server (ADS) running on MS Windows 2000 or later.
+This is the default setting since samba-2.2.x.
 </para>
 
-<para><emphasis>
-Of course it should be clear that the authentication back end itself could be from any
-distributed directory architecture server that is supported by Samba. This can be
-LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory Server, etc.
-</emphasis></para>
+</sect3>
+
+</sect2>
+<sect2>
+<title>Share Level Security</title>
 
 <para>
-Please refer to the section on Howto configure Samba as a Primary Domain Controller
-and for more information regarding how to create a domain machine account for a
-domain member server as well as for information regarding how to enable the samba
-domain member machine to join the domain and to be fully trusted by it.
+Ok, now for share level security. In share level security the client authenticates
+itself separately for each share. It will send a password along with each 
+<emphasis>tree connection</emphasis> (share mount). It does not explicitly send a
+username with this operation. The client is expecting a password to be associated
+with each share, independent of the user. This means that samba has to work out what
+username the client probably wants to use. It is never explicitly sent the username.
+Some commercial SMB servers such as NT actually associate passwords directly with
+shares in share level security, but samba always uses the unix authentication scheme
+where it is a username/password pair that is authenticated, not a share/password pair.
 </para>
 
-</sect1>
+<para>
+To gain understanding of the MS Windows networking parallels to this, one should think
+in terms of MS Windows 9x/Me where one can create a shared folder that provides read-only
+or full access, with or without a password.
+</para>
 
-<sect1>
-<title>Domain Controller</title>
+<para>
+Many clients send a <emphasis>session setup</emphasis> even if the server is in share
+level security. They normally send a valid username but no password. Samba records
+this username in a list of <emphasis>possible usernames</emphasis>. When the client
+then does a <emphasis>tree connection</emphasis> it also adds to this list the name
+of the share they try to connect to (useful for home directories) and any users
+listed in the <command>user =</command> &smb.conf; line. The password is then checked
+in turn against these <emphasis>possible usernames</emphasis>. If a match is found
+then the client is authenticated as that user.
+</para>
+
+<sect3>
+<title>Example Configuration</title>
 
 <para>
-Over the years public perceptions of what Domain Control really is has taken on an
-almost mystical nature. Before we branch into a brief overview of what Domain Control
-is the following types of controller are known:
+The &smb.conf; parameter that sets <emphasis>Share Level Security</emphasis> is:
 </para>
 
+<para><programlisting>
+	security = share
+</programlisting></para>
+
+<para>
+Plese note that there are reports that recent MS Widows clients do not like to work
+with share mode security servers. You are strongly discouraged from use of this parameter.
+</para>
+
+</sect3>
+</sect2>
+
 <sect2>
-<title>Domain Controller Types</title>
+<title>Server Level Security</title>
+
+<para>
+Now to review <emphasis>server level</emphasis> security. In server level security the samba
+server reports to the client that it is in user level security. The client then does a 
+<emphasis>session setup</emphasis> as described earlier. The samba server takes the
+username/password that the client sends and attempts to login to the
+<emphasis>password server</emphasis> by sending exactly the same username/password that
+it got from the client. If that server is in user level security and accepts the password
+then samba accepts the clients connection. This allows the samba server to use another SMB
+server as the <emphasis>password server</emphasis>.
+</para>
+
+<para>
+You should also note that at the very start of all this, where the server tells the client
+what security level it is in, it also tells the client if it supports encryption. If it
+does then it supplies the client with a random cryptkey. The client will then send all
+passwords in encrypted form. Samba supports this type of encryption by default.
+</para>
+
+<para>
+The parameter <emphasis>security = server</emphasis> means that Samba reports to clients that
+it is running in <emphasis>user mode</emphasis> but actually passes off all authentication
+requests to another <emphasis>user mode</emphasis> server. This requires an additional
+parameter <emphasis>password server</emphasis> that points to the real authentication server.
+That real authentication server can be another Samba server or can be a Windows NT server,
+the later natively capable of encrypted password support.
+</para>
+
+<note><para>
+When Samba is running in <emphasis>server level</emphasis> security it is essential that
+the parameter <emphasis>password server</emphasis> is set to the precise netbios machine
+name of the target authentication server. Samba can NOT determine this from NetBIOS name
+lookups because the choice of the target authentication server arbitrary and can not
+be determined from a domain name. In essence a samba server that is in
+<emphasis>server level</emphasis> security is operating in what used to be known as
+workgroup mode.
+</para></note>
 
-<simplelist>
-	<member>Primary Domain Controller</member>
-	<member>Backup Domain Controller</member>
-	<member>ADS Domain Controller</member>
-</simplelist>
+<note><para>
+<emphasis>Server level</emphasis> security is incompatible with what is known as
+<emphasis>schannel</emphasis> or <emphasis>sign and seal</emphasis> protocols. This means that
+if you want to use <emphasis>server</emphasis> level security you must disable the use of
+<emphasis>sign and seal</emphasis> on all machines on your network.
+</para></note>
+
+<sect3>
+<title>Example Configuration - Using MS Windows NT as an authentication server</title>
 
 <para>
-The <emphasis>Primary Domain Controller</emphasis> or PDC plays an important role in the MS 
-Windows NT3 and NT4 Domain Control architecture, but not in the manner that so many
-expect. The PDC seeds the Domain Control database (a part of the Windows registry) and
-it plays a key part in synchronisation of the domain authentication database. 
+This method involves the additions of the following parameters in the &smb.conf; file:
 </para>
 
+<para><programlisting>
+        encrypt passwords = Yes
+        security = server
+        password server = "NetBIOS_name_of_a_DC"
+</programlisting></para>
+
+
 <para>
-New to Samba-3.0.0 is the ability to use a back-end file that holds the same type of data as
-the NT4 style SAM (Security Account Manager) database (one of the registry files).
-The samba-3.0.0 SAM can be specified via the smb.conf file parameter "passwd backend" and
-valid options include <emphasis> smbpasswd tdbsam ldapsam nisplussam plugin unixsam</emphasis>.
-The smbpasswd, tdbsam and ldapsam options can have a "_nua" suffix to indicate that No Unix
-Accounts need to be created. In other words, the Samba SAM will be independant of Unix/Linux
-system accounts, provided a uid range is defined from which SAM accounts can be created.
+There are two ways of identifying whether or not a username and password pair was valid
+or not. One uses the reply information provided as part of the authentication messaging
+process, the other uses just an error code.
 </para>
 
 <para>
-The <emphasis>Backup Domain Controller</emphasis> or BDC plays a key role in servicing network
-authentication requests. The BDC is biased to answer logon requests so that on a network segment
-that has a BDC and a PDC the BDC will be most likely to service network logon requests. The PDC will
-answer network logon requests when the BDC is too busy (high load). A BDC can be promoted to
-a PDC. If the PDC is on line at the time that the BDC is promoted to PDC the previous PDC is
-automatically demoted to a BDC.
+The down-side of this mode of configuration is the fact that for security reasons Samba
+will send the password server a bogus username and a bogus password and if the remote
+server fails to reject the username and password pair then an alternative mode of
+identification of validation is used. Where a site uses password lock out after a
+certain number of failed authentication attempts this will result in user lockouts.
 </para>
 
 <para>
-At this time Samba is NOT capable of acting as an <emphasis>ADS Domain Controller</emphasis>.
+Use of this mode of authentication does require there to be a standard Unix account
+for the user, this account can be blocked to prevent logons by other than MS Windows clients.
 </para>
+
+</sect3>
 </sect2>
+
+<sect2>
+<title>Domain Level Security</title>
+
+<para>
+When samba is operating in <emphasis>security = domain</emphasis> mode this means that
+the Samba server has a domain security trust account (a machine account) and will cause
+all authentication requests to be passed through to the domain controllers.
+</para>
+
+<sect3>
+<title>Example Configuration - Samba as a Domain Member Server</title>
+
+<para>
+This method involves addition of the following parameters in the &smb.conf; file:
+</para>
+
+<para><programlisting>
+        encrypt passwords = Yes
+        security = domain
+        workgroup = "name_of_NT_domain"
+        password server = *
+</programlisting></para>
+
+<para>
+The use of the "*" argument to <command>password server</command> will cause samba to locate the
+domain controller in a way analogous to the way this is done within MS Windows NT.
+This is the default behaviour.
+</para>
+
+<para>
+In order for this method to work the Samba server needs to join the MS Windows NT
+security domain. This is done as follows:
+</para>
+
+<itemizedlist>
+        <listitem><para>On the MS Windows NT domain controller using
+        the Server Manager add a machine account for the Samba server.
+        </para></listitem>
+
+        <listitem><para>Next, on the Linux system execute:</para>
+	<para><programlisting>
+        <command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command> (samba 2.x)
+
+        <command>net join -U administrator%password</command>   (samba-3)
+	</programlisting>
+        </para>
+	</listitem>
+</itemizedlist>
+
+<para>
+Use of this mode of authentication does require there to be a standard Unix account
+for the user in order to assign a uid once the account has been authenticated by
+the remote Windows DC.  This account can be blocked to prevent logons by clients other than
+MS Windows through things such as setting an invalid shell in the
+<filename>/etc/passwd</filename> entry.
+</para>
+
+<para>
+An alternative to assigning UIDs to Windows users on a Samba member server is
+presented in the <link linkend="winbind">Winbind Overview</link> chapter
+in this HOWTO collection.
+</para>
+
+</sect3>
+</sect2>
+
+<sect2>
+<title>ADS Level Security</title>
+
+<para>
+Samba-2.2.x could join and Active Directory domain so long as the Active Directory domain
+controller is configured for mixed mode operation, and is running NetBIOS over TCP/IP. MS
+Windows 2000 and later can be configured to run without NEtBIOS over TCP/IP, instead it
+can run SMB natively over TCP/IP.
+</para>
+
+<para>
+The ability to natively join an Active Directory domain requires the use of Kerberos
+based authentication. The Kerberos protocols have been extended by Microsoft so that
+a plain MIT Kerberos, or a Heimdal client is not sufficient. Samba-3 now has the ability
+to be a native Active Directory member server.
+</para>
+
+<sect3>
+<title>Example Configuration</title>
+
+<para>
+<programlisting>
+	realm = your.kerberos.realm
+	security = ADS
+	encrypt passwords = Yes
+
+The following parameter may be required:
+
+	ads server = your.kerberos.server
+</programlisting>
+</para>
+
+<para>
+Please refer to the Domain Membership section, Active Directory Membership for more information
+regarding this configuration option.
+</para>
+
+</sect3>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Seamless Windows Network Integration</title>
+
+<para>
+MS Windows clients may use encrypted passwords as part of a challenege/response
+authentication model (a.k.a. NTLMv1) or alone, or clear text strings for simple
+password based authentication. It should be realized that with the SMB protocol
+the password is passed over the network either in plain text or encrypted, but
+not both in the same authentication request.
+</para>
+
+<para>
+When encrypted passwords are used a password that has been entered by the user
+is encrypted in two ways:
+</para>
+
+<itemizedlist>
+        <listitem><para>An MD4 hash of the UNICODE of the password
+        string.  This is known as the NT hash.
+        </para></listitem>
+
+        <listitem><para>The password is converted to upper case,
+        and then padded or trucated to 14 bytes.  This string is
+        then appended with 5 bytes of NULL characters and split to
+        form two 56 bit DES keys to encrypt a "magic" 8 byte value.
+        The resulting 16 bytes for the LanMan hash.
+        </para></listitem>
+</itemizedlist>
+
+<para>
+MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x and version 4.0
+pre-service pack 3 will use either mode of password authentication. All
+versions of MS Windows that follow these versions no longer support plain
+text passwords by default.
+</para>
+
+<para>
+MS Windows clients have a habit of dropping network mappings that have been idle
+for 10 minutes or longer. When the user attempts to use the mapped drive
+connection that has been dropped, the client re-establishes the connection using
+a cached copy of the password.
+</para>
+
+<para>
+When Microsoft changed the default password mode, support was dropped for caching
+of the plain text password. This means that when the registry parameter is changed
+to re-enable use of plain text passwords it appears to work, but when a dropped
+service connection mapping attempts to revalidate it will fail if the remote
+authentication server does not support encrypted passwords.  This means that it
+is definitely not a good idea to re-enable plain text password support in such clients.
+</para>
+
+<para>
+The following parameters can be used to work around the issue of Windows 9x client
+upper casing usernames and password before transmitting them to the SMB server
+when using clear text authentication.
+</para>
+
+<para><programlisting>
+        <ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable>
+        <ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable>
+</programlisting></para>
+
+<para>
+By default Samba will lower case the username before attempting to lookup the user
+in the database of local system accounts.  Because UNIX usernames conventionally
+only contain lower case character, the <parameter>username level</parameter> parameter
+is rarely needed.
+</para>
+
+<para>
+However, passwords on UNIX systems often make use of mixed case characters.
+This means that in order for a user on a Windows 9x client to connect to a Samba
+server using clear text authentication, the <parameter>password level</parameter>
+must be set to the maximum number of upper case letter which <emphasis>could</emphasis>
+appear is a password.  Note that the server OS uses the traditional DES version
+of crypt(), a <parameter>password level</parameter> of 8 will result in case
+insensitive passwords as seen from Windows users.  This will also result in longer
+login times as Samba has to compute the permutations of the password string and
+try them one by one until a match is located (or all combinations fail).
+</para>
+
+<para>
+The best option to adopt is to enable support for encrypted passwords where ever
+Samba is used. Most attempts to apply the registry change to re-enable plain text
+passwords will eventually lead to user complaints and unhappiness.
+</para>
+
 </sect1>
 </chapter>
diff --git a/docs/docbook/projdoc/samba-doc.xml b/docs/docbook/projdoc/samba-doc.xml
index 8d910eaf0d..bf120d3c68 100644
--- a/docs/docbook/projdoc/samba-doc.xml
+++ b/docs/docbook/projdoc/samba-doc.xml
@@ -79,11 +79,10 @@ section carefully.
 </para>
 </partintro>
 &ServerType;
-&SECURITY-LEVEL;
 &Samba-PDC-HOWTO;
 &Samba-BDC-HOWTO;
-&ADS-HOWTO;
 &DOMAIN-MEMBER;
+&StandAloneServer;
 </part>
 
 <part id="optional">
diff --git a/docs/docbook/projdoc/securing-samba.xml b/docs/docbook/projdoc/securing-samba.xml
index d320767a77..204fceeb4a 100644
--- a/docs/docbook/projdoc/securing-samba.xml
+++ b/docs/docbook/projdoc/securing-samba.xml
@@ -52,6 +52,25 @@ as the client sends its first packet. The refusal will be marked as a
 </sect1>
 
 <sect1>
+<title>User based protection</title>
+
+<para>
+If you want to restrict access to your server to valid users only then the following
+method may be of use. In the smb.conf [globals] section put:
+</para>
+
+<para><programlisting>
+	valid users = @smbusers, jacko
+</programlisting></para>
+
+<para>
+What this does is, it restricts all server access to either the user <emphasis>jacko</emphasis>
+or to members of the system group <emphasis>smbusers</emphasis>.
+</para>
+
+</sect1>
+
+<sect1>
 
 <title>Using interface protection</title>
 
diff --git a/docs/docbook/projdoc/security_level.xml b/docs/docbook/projdoc/security_level.xml
deleted file mode 100644
index 528c87c52c..0000000000
--- a/docs/docbook/projdoc/security_level.xml
+++ /dev/null
@@ -1,340 +0,0 @@
-<chapter id="securitylevels">
-<chapterinfo>
-	&author.tridge;
-	&author.jelmer;
-</chapterinfo>
-<title>Samba as Stand-Alone Server</title>
-
-<para>
-In this section the function and purpose of Samba's <emphasis>security</emphasis>
-modes are described.
-</para>
-
-<sect1>
-<title>User and Share security level</title>
-
-<para>
-A SMB server tells the client at startup what "security level" it is
-running. There are two options "share level" and "user level". Which
-of these two the client receives affects the way the client then tries
-to authenticate itself. It does not directly affect (to any great
-extent) the way the Samba server does security. I know this is
-strange, but it fits in with the client/server approach of SMB. In SMB
-everything is initiated and controlled by the client, and the server
-can only tell the client what is available and whether an action is
-allowed. 
-</para>
-
-<sect2>
-<title>User Level Security</title>
-
-<para>
-I'll describe user level security first, as its simpler. In user level
-security the client will send a "session setup" command directly after
-the protocol negotiation. This contains a username and password. The
-server can either accept or reject that username/password
-combination. Note that at this stage the server has no idea what
-share the client will eventually try to connect to, so it can't base
-the "accept/reject" on anything other than:
-</para>
-
-<orderedlist>
-<listitem><para>the username/password</para></listitem>
-<listitem><para>the machine that the client is coming from</para></listitem>
-</orderedlist>
-
-<para>
-If the server accepts the username/password then the client expects to
-be able to mount any share (using a "tree connection") without
-specifying a password. It expects that all access rights will be as
-the username/password specified in the "session setup". 
-</para>
-
-<para>
-It is also possible for a client to send multiple "session setup"
-requests. When the server responds it gives the client a "uid" to use
-as an authentication tag for that username/password. The client can
-maintain multiple authentication contexts in this way (WinDD is an
-example of an application that does this)
-</para>
-
-</sect2>
-
-<sect2>
-<title>Share Level Security</title>
-
-<para>
-Ok, now for share level security. In share level security the client
-authenticates itself separately for each share. It will send a
-password along with each "tree connection" (share mount). It does not
-explicitly send a username with this operation. The client is
-expecting a password to be associated with each share, independent of
-the user. This means that samba has to work out what username the
-client probably wants to use. It is never explicitly sent the
-username. Some commercial SMB servers such as NT actually associate
-passwords directly with shares in share level security, but samba
-always uses the unix authentication scheme where it is a
-username/password that is authenticated, not a "share/password".
-</para>
-
-<para>
-Many clients send a "session setup" even if the server is in share
-level security. They normally send a valid username but no
-password. Samba records this username in a list of "possible
-usernames". When the client then does a "tree connection" it also adds
-to this list the name of the share they try to connect to (useful for
-home directories) and any users listed in the <command>user =</command> &smb.conf;
-line. The password is then checked in turn against these "possible
-usernames". If a match is found then the client is authenticated as
-that user.
-</para>
-
-</sect2>
-
-<sect2>
-<title>Server Level Security</title>
-
-<para>
-Finally "server level" security. In server level security the samba
-server reports to the client that it is in user level security. The
-client then does a "session setup" as described earlier. The samba
-server takes the username/password that the client sends and attempts
-to login to the "password server" by sending exactly the same
-username/password that it got from the client. If that server is in
-user level security and accepts the password then samba accepts the
-clients connection. This allows the samba server to use another SMB
-server as the "password server". 
-</para>
-
-<para>
-You should also note that at the very start of all this, where the
-server tells the client what security level it is in, it also tells
-the client if it supports encryption. If it does then it supplies the
-client with a random "cryptkey". The client will then send all
-passwords in encrypted form. You have to compile samba with encryption
-enabled to support this feature, and you have to maintain a separate
-smbpasswd file with SMB style encrypted passwords. It is
-cryptographically impossible to translate from unix style encryption
-to SMB style encryption, although there are some fairly simple management
-schemes by which the two could be kept in sync.
-</para>
-
-<para>
-"security = server" means that Samba reports to clients that
-it is running in "user mode" but actually passes off all authentication
-requests to another "user mode" server. This requires an additional
-parameter "password server =" that points to the real authentication server.
-That real authentication server can be another Samba server or can be a
-Windows NT server, the later natively capable of encrypted password support.
-</para>
-
-<note><para>
-<emphasis>Server</emphasis> level security is incompatible with what is known 
-as <emphasis>schannel</emphasis> or "sign and seal" protocols. This means that
-if you want to use <emphasis>server</emphasis> level security you must disable
-the use of "sign and seal" on all machines on your network.
-</para></note>
-
-<sect3>
-<title>Configuring Samba for Seemless Windows Network Integration</title>
-
-<para>
-MS Windows clients may use encrypted passwords as part of a challenege/response
-authentication model (a.k.a. NTLMv1) or alone, or clear text strings for simple
-password based authentication. It should be realized that with the SMB protocol
-the password is passed over the network either in plain text or encrypted, but
-not both in the same authentication request.
-</para>
-
-<para>
-When encrypted passwords are used a password that has been entered by the user
-is encrypted in two ways:
-</para>
-
-<itemizedlist>
-	<listitem><para>An MD4 hash of the UNICODE of the password
-	string.  This is known as the NT hash.
-	</para></listitem>
-
-	<listitem><para>The password is converted to upper case,
-	and then padded or trucated to 14 bytes.  This string is 
-	then appended with 5 bytes of NULL characters and split to
-	form two 56 bit DES keys to encrypt a "magic" 8 byte value.
-	The resulting 16 bytes for the LanMan hash.
-	</para></listitem>	
-</itemizedlist>
-
-<para>
-MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x and version 4.0
-pre-service pack 3 will use either mode of password authentication. All
-versions of MS Windows that follow these versions no longer support plain
-text passwords by default.
-</para>
-
-<para>
-MS Windows clients have a habit of dropping network mappings that have been idle
-for 10 minutes or longer. When the user attempts to use the mapped drive
-connection that has been dropped, the client re-establishes the connection using
-a cached copy of the password.
-</para>
-
-<para>
-When Microsoft changed the default password mode, support was dropped for caching
-of the plain text password. This means that when the registry parameter is changed
-to re-enable use of plain text passwords it appears to work, but when a dropped
-service connection mapping attempts to revalidate it will fail if the remote
-authentication server does not support encrypted passwords.  This means that it
-is definitely not a good idea to re-enable plain text password support in such clients.
-</para>
-
-<para>
-The following parameters can be used to work around the issue of Windows 9x client
-upper casing usernames and password before transmitting them to the SMB server
-when using clear text authentication.
-</para>
-
-<para><programlisting>
-	<ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable>
-	<ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable>
-</programlisting></para>
-
-<para>
-By default Samba will lower case the username before attempting to lookup the user
-in the database of local system accounts.  Because UNIX usernames conventionally
-only contain lower case character, the <parameter>username level</parameter> parameter
-is rarely needed.
-</para>
-
-<para>
-However, passwords on UNIX systems often make use of mixed case characters. 
-This means that in order for a user on a Windows 9x client to connect to a Samba
-server using clear text authentication, the <parameter>password level</parameter>
-must be set to the maximum number of upper case letter which <emphasis>could</emphasis>
-appear is a password.  Note that the server OS uses the traditional DES version
-of crypt(), a <parameter>password level</parameter> of 8 will result in case
-insensitive passwords as seen from Windows users.  This will also result in longer
-login times as Samba has to compute the permutations of the password string and 
-try them one by one until a match is located (or all combinations fail).
-</para>
-
-<para>
-The best option to adopt is to enable support for encrypted passwords 
-where ever Samba is used. There are three configuration possibilities 
-for support of encrypted passwords:
-</para>
-
-</sect3>
-<sect3>
-<title>Use MS Windows NT as an authentication server</title>
-
-<para>
-This method involves the additions of the following parameters in the &smb.conf; file:
-</para>
-
-<para><programlisting>
-	encrypt passwords = Yes
-	security = server
-	password server = "NetBIOS_name_of_PDC"
-</programlisting></para>
-
-
-<para>
-There are two ways of identifying whether or not a username and 
-password pair was valid or not. One uses the reply information provided 
-as part of the authentication messaging process, the other uses 
-just an error code.
-</para>
-
-<para>
-The down-side of this mode of configuration is the fact that 
-for security reasons Samba will send the password server a bogus 
-username and a bogus password and if the remote server fails to 
-reject the username and password pair then an alternative mode 
-of identification of validation is used. Where a site uses password 
-lock out after a certain number of failed authentication attempts 
-this will result in user lockouts.
-</para>
-
-<para>
-Use of this mode of authentication does require there to be 
-a standard Unix account for the user, this account can be blocked 
-to prevent logons by other than MS Windows clients.
-</para>
-
-</sect3>
-</sect2>
-
-<sect2>
-<title>Domain Level Security</title>
-
-<para>
-When samba is operating in <emphasis>security = domain</emphasis> mode this means that
-the Samba server has a domain security trust account (a machine account) and will cause
-all authentication requests to be passed through to the domain controllers.
-</para>
-
-<sect3>
-<title>Samba as a member of an MS Windows NT security domain</title>
-
-<para>
-This method involves addition of the following parameters in the &smb.conf; file:
-</para>
-
-<para><programlisting>
-	encrypt passwords = Yes
-	security = domain
-	workgroup = "name of NT domain"
-	password server = *
-</programlisting></para>
-
-<para>
-The use of the "*" argument to <command>password server</command> will cause samba to locate the
-domain controller in a way analogous to the way this is done within MS Windows NT.
-This is the default behaviour.
-</para>
-
-<para>
-In order for this method to work the Samba server needs to join the 
-MS Windows NT security domain. This is done as follows:
-</para>
-
-<itemizedlist>
-	<listitem><para>On the MS Windows NT domain controller using 
-	the Server Manager add a machine account for the Samba server.
-	</para></listitem>
-	
-	<listitem><para>Next, on the Linux system execute: 
-	<command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command> (samba 2.x)
-
-	<command>net join -U administrator%password</command>   (samba-3)
-	</para></listitem>
-</itemizedlist>
-
-<para>
-Use of this mode of authentication does require there to be a standard Unix account
-for the user in order to assign a uid once the account has been authenticated by
-the remote Windows DC.  This account can be blocked to prevent logons by clients other than
-MS Windows through things such as setting an invalid shell in the
-<filename>/etc/passwd</filename> entry. 
-</para>
-
-<para>
-An alternative to assigning UIDs to Windows users on a Samba member server is
-presented in the <link linkend="winbind">Winbind Overview</link> chapter
-in this HOWTO collection.
-</para>
-
-</sect3>
-</sect2>
-
-<sect2>
-<title>ADS Level Security</title>
-
-<para>
-For information about the configuration option please refer to the entire section entitled
-<emphasis>Samba as an ADS Domain Member.</emphasis>
-</para>
-
-</sect2>
-</sect1>
-</chapter>