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)

diff --git a/docs/docbook/manpages/smb.conf.5.sgml b/docs/docbook/manpages/smb.conf.5.sgml
index 9a2ea4fbde87530ecb0151b2d1f4e2e07887ee0a..713d4a012ee141cf71c776b83cfe1378c15d4849 100644 (file)
--- a/docs/docbook/manpages/smb.conf.5.sgml
+++ b/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,24 +6883,27 @@ 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
+               <para><anchor id="SECURITYEQUALSDOMAIN"/><emphasis>SECURITY = DOMAIN
+
                </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>This mode will only work correctly if <citerefentry><refentrytitle>net</refentrytitle>
+               <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 
+               mode Samba will try to validate the username/password by passing
+               it to a Windows NT Primary or Backup Domain Controller, in exactly 
+               the same way that a Windows NT Server would do.</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 a valid UNIX user must still 
+               exist as well as the account on the Domain Controller to allow 
+               Samba to have a valid UNIX account to map file access to.</para>
+
+               <para><emphasis>Note</emphasis> that from the client's point 
+               of view <command>security = domain</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 
@@ -6910,27 +6921,42 @@ print5|My Printer 5
                server</parameter></link> parameter and the <link 
                linkend="ENCRYPTPASSWORDS"><parameter>encrypted passwords</parameter>
                </link> parameter.</para>
-               
-               <para><anchor id="SECURITYEQUALSDOMAIN"/><emphasis>SECURITY = DOMAIN
+
+               <para><anchor id="SECURITYEQUALSSERVER"/><emphasis>SECURITY = SERVER
                </emphasis></para>
 
-               <para>This mode will only work correctly if <citerefentry><refentrytitle>smbpasswd</refentrytitle>
-               <manvolnum>8</manvolnum></citerefentry> has been used to add this 
-               machine into a Windows NT Domain. It expects the <link 
+               <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>. In this 
-               mode Samba will try to validate the username/password by passing
-               it to a Windows NT Primary or Backup Domain Controller, in exactly 
-               the same way that a Windows NT Server would do.</para>
+               </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> that a valid UNIX user must still 
-               exist as well as the account on the Domain Controller to allow 
-               Samba to have a valid UNIX account to map file access to.</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 = domain</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 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 
@@ -6941,14 +6967,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>
 
@@ -6956,9 +6974,10 @@ print5|My Printer 5
                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>
 

diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
index 7653e3d1c03af776e23d1f8c61b75ba92895d700..e3bee32db01218cc2abfc81e8b1070e073c77863 100644 (file)
--- a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
+++ b/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>