Minor doco updates - with a slightly bigger change to the

'security=server/domain' text, to try and explain the difference better, and
why you should always use the latter.

Also update the BDC-HOWTO to have some relation to current reality.

Andrew Bartlett
(This used to be commit 7fd0c9bd74a8513a0cbf67bb516c6c2642380c7f)

docs/docbook/manpages/smb.conf.5.sgml

@@ -2879,6 +2879,10 @@ df $1 | tail -1 | awk '{print $2" "$4}'
 		Privileges will be those of the <link linkend="GUESTACCOUNT"><parameter>
 		guest account</parameter></link>.</para>
 
+	        <para>This paramater nullifies the benifits of setting
+	        <link linkend="RESTRICTANONYMOUS"><parameter>restrict
+	        anonymous</parameter></link> = 2</para>
+
 		<para>See the section below on <link linkend="SECURITY"><parameter>
 		security</parameter></link> for more information about this option.
 		</para>
@@ -5392,9 +5396,13 @@ df $1 | tail -1 | awk '{print $2" "$4}'
 		<listitem><para>Some version of NT 4.x allow non-guest 
 		users with a bad passowrd. When this option is enabled, samba will not 
 		use a broken NT 4.x server as password server, but instead complain
-		to the logs and exit.
+		to the logs and exit.  
 		</para>
 
+	        <para>Disabling this option prevents Samba from making
+	        this check, which involves deliberatly attempting a
+	        bad logon to the remote server.</para>
+
 		<para>Default: <command>paranoid server security = yes</command></para>
 
 		</listitem>
@@ -6851,7 +6859,7 @@ print5|My Printer 5
 		<para><anchor id="SECURITYEQUALSUSER"/><emphasis>SECURITY = USER
 		</emphasis></para>
 
-		<para>This is the default security setting in Samba 2.2. 
+		<para>This is the default security setting in Samba 3.0. 
 		With user-level security a client must first "log-on" with a 
 		valid username and password (which can be mapped using the <link
 		linkend="USERNAMEMAP"><parameter>username map</parameter></link> 
@@ -6875,47 +6883,12 @@ print5|My Printer 5
 		<para>See also the section <link linkend="VALIDATIONSECT">
 		NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
 
-		<para><anchor id="SECURITYEQUALSSERVER"/><emphasis>SECURITY = SERVER
-		</emphasis></para>
-
-		<para>In this mode Samba will try to validate the username/password 
-		by passing it to another SMB server, such as an NT box. If this 
-		fails it will revert to <command>security = user</command>, but note 
-		that if encrypted passwords have been negotiated then Samba cannot 
-		revert back to checking the UNIX password file, it must have a valid 
-		<filename>smbpasswd</filename> file to check users against. See the 
-		documentation file in the <filename>docs/</filename> directory 
-		<filename>ENCRYPTION.txt</filename> for details on how to set this 
-		up.</para>
-
-		<para><emphasis>Note</emphasis> that from the client's point of 
-		view <command>security = server</command> is the same as <command>
-		security = user</command>.  It only affects how the server deals 
-		with the authentication, it does not in any way affect what the 
-		client sees.</para>
-
-		<para><emphasis>Note</emphasis> that the name of the resource being 
-		requested is <emphasis>not</emphasis> sent to the server until after 
-		the server has successfully authenticated the client. This is why 
-		guest shares don't work in user level security without allowing 
-		the server to automatically map unknown users into the <link
-		linkend="GUESTACCOUNT"><parameter>guest account</parameter></link>. 
-		See the <link linkend="MAPTOGUEST"><parameter>map to guest</parameter>
-		</link> parameter for details on doing this.</para>
-
-		<para>See also the section <link linkend="VALIDATIONSECT">
-		NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
-		<para>See also the <link linkend="PASSWORDSERVER"><parameter>password 
-		server</parameter></link> parameter and the <link 
-		linkend="ENCRYPTPASSWORDS"><parameter>encrypted passwords</parameter>
-		</link> parameter.</para>
-		
 		<para><anchor id="SECURITYEQUALSDOMAIN"/><emphasis>SECURITY = DOMAIN
+
 		</emphasis></para>
 
-		<para>This mode will only work correctly if <citerefentry><refentrytitle>smbpasswd</refentrytitle>
+	        <para>This mode will only work correctly if <citerefentry><refentrytitle>net</refentrytitle>
-		<manvolnum>8</manvolnum></citerefentry> has been used to add this 
+		<manvolnum>8</manvolnum></citerefentry> has been used to add this
 		machine into a Windows NT Domain. It expects the <link 
 		linkend="ENCRYPTPASSWORDS"><parameter>encrypted passwords</parameter>
 		</link> parameter to be set to <constant>yes</constant>. In this 
@@ -6941,14 +6914,6 @@ print5|My Printer 5
 		See the <link linkend="MAPTOGUEST"><parameter>map to guest</parameter>
 		</link> parameter for details on doing this.</para>
 
-		<para><emphasis>BUG:</emphasis> There is currently a bug in the 
-		implementation of <command>security = domain</command> with respect 
-		to multi-byte character set usernames. The communication with a 
-		Domain Controller must be done in UNICODE and Samba currently 
-		does not widen multi-byte user names to UNICODE correctly, thus 
-		a multi-byte username will not be recognized correctly at the 
-		Domain Controller. This issue will be addressed in a future release.</para>
-
 		<para>See also the section <link linkend="VALIDATIONSECT">
 		NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
 
@@ -6957,8 +6922,62 @@ print5|My Printer 5
 		linkend="ENCRYPTPASSWORDS"><parameter>encrypted passwords</parameter>
 		</link> parameter.</para>
 
+		<para><anchor id="SECURITYEQUALSSERVER"/><emphasis>SECURITY = SERVER
+		</emphasis></para>
+
+		<para>In this mode Samba will try to validate the username/password 
+		by passing it to another SMB server, such as an NT box. If this 
+		fails it will revert to <command>security =
+		user</command>. It expects the <link
+		linkend="ENCRYPTPASSWORDS"><parameter>encrypted passwords</parameter>
+		</link> parameter to be set to
+		<constant>yes</constant>, unless the remote server
+		does not support them.  However note
+		that if encrypted passwords have been negotiated then Samba cannot 
+		revert back to checking the UNIX password file, it must have a valid 
+		<filename>smbpasswd</filename> file to check users against. See the 
+		documentation file in the <filename>docs/</filename> directory 
+		<filename>ENCRYPTION.txt</filename> for details on how to set this 
+		up.</para>
+
+		<para><emphasis>Note</emphasis> this mode of operation
+		has significant pitfalls, due to the fact that is
+		activly initiates a man-in-the-middle attack on the
+		remote SMB server.  In particular, this mode of
+		operation can cause significant resource consuption on
+		the PDC, as it must maintain an active connection for
+		the duration of the user's session.  Furthermore, if
+		this connection is lost, there is no way to
+		reestablish it, and futher authenticaions to the Samba
+		server may fail.  (From a single client, till it
+		disconnects). </para>
+
+		<para><emphasis>Note</emphasis> that from the client's point of 
+		view <command>security = server</command> is the same as <command>
+		security = user</command>.  It only affects how the server deals 
+		with the authentication, it does not in any way affect what the 
+		client sees.</para>
+
+		<para><emphasis>Note</emphasis> that the name of the resource being 
+		requested is <emphasis>not</emphasis> sent to the server until after 
+		the server has successfully authenticated the client. This is why 
+		guest shares don't work in user level security without allowing 
+		the server to automatically map unknown users into the <link
+		linkend="GUESTACCOUNT"><parameter>guest account</parameter></link>. 
+		See the <link linkend="MAPTOGUEST"><parameter>map to guest</parameter>
+		</link> parameter for details on doing this.</para>
+
+		<para>See also the section <link linkend="VALIDATIONSECT">
+		NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
+
+		<para>See also the <link linkend="PASSWORDSERVER"><parameter>password 
+		server</parameter></link> parameter and the <link 
+		linkend="ENCRYPTPASSWORDS"><parameter>encrypted passwords</parameter>
+		</link> parameter.</para>
+		
 		<para>Default: <command>security = USER</command></para>
 		<para>Example: <command>security = DOMAIN</command></para>
+
 		</listitem>
 		</varlistentry>
 

docs/docbook/projdoc/Samba-BDC-HOWTO.sgml

@@ -128,7 +128,7 @@ the password change is done.
 
 
 <sect1>
-<title>Can Samba be a Backup Domain Controller?</title>
+<title>Can Samba be a Backup Domain Controller to an NT PDC?</title>
 
 <para>
 With version 2.2, no. The native NT SAM replication protocols have
@@ -137,6 +137,12 @@ understanding and implementing the protocols, but this work has not
 been finished for version 2.2.
 </para>
 
+<para>
+With version 3.0, the work on both the replication protocols and a
+suitable storage mechanism has progressed, and some form of NT4 BDC
+support is expected soon.
+</para>
+
 <para>
 Can I get the benefits of a BDC with Samba?  Yes. The main reason for
 implementing a BDC is availability. If the PDC is a Samba machine,
@@ -178,7 +184,8 @@ whenever changes are made, or the PDC is set up as a NIS master
 server and the BDC as a NIS slave server. To set up the BDC as a
 mere NIS client would not be enough, as the BDC would not be able to
 access its user database in case of a PDC failure.
-</para></listitem>
+</para>
+</listitem>
 
 <listitem><para>
 The Samba password database in the file private/smbpasswd has to be
@@ -236,5 +243,15 @@ password.
 
 
 </sect2>
+<sect2>
+<title>Can I do this all with LDAP?</title>
+<para>The simple answer is YES.  Samba's pdb_ldap code supports
+binding to a replica LDAP server, and will also follow referrals and
+rebind to the master if it ever needs to make a modification to the
+database.  (Normally BDCs are read only, so this will not occur
+often).
+</para>
+</sect2>
+
 </sect1>
 </chapter>