Docbook XML conversion: projdoc

(This used to be commit f7c9df751459da2d4a996d5f0135334fb3f87f69)

1 files changed, 250 insertions, 0 deletions

diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml
new file mode 100644
index 0000000000..2f3b568471
--- /dev/null
+++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml
@@ -0,0 +1,250 @@
+<chapter id="samba-bdc">
+
+<chapterinfo>
+	&author.vl;
+	<pubdate> (26 Apr 2001) </pubdate>
+</chapterinfo>
+
+<title>
+Samba Backup Domain Controller to Samba Domain Control
+</title>
+
+<sect1>
+<title>Prerequisite Reading</title>
+
+<para>
+Before you continue reading in this chapter, 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>
+What is a Domain Controller? It is a machine that is able to answer
+logon requests from workstations in a Windows NT Domain. Whenever a
+user logs into a Windows NT Workstation, the workstation connects to a
+Domain Controller and asks him whether the username and password the
+user typed in is correct.  The Domain Controller replies with a lot of
+information about the user, for example the place where the users
+profile is stored, the users full name of the user. All this
+information is stored in the NT user database, the so-called SAM.
+</para>
+
+<para>
+There are two kinds of Domain Controller in a NT 4 compatible Domain:
+A Primary Domain Controller (PDC) and one or more Backup Domain
+Controllers (BDC). The PDC contains the master copy of the
+SAM. Whenever the SAM has to change, for example when a user changes
+his password, this change has to be done on the PDC. A Backup Domain
+Controller is a machine that maintains a read-only copy of the
+SAM. This way it is able to reply to logon requests and authenticate
+users in case the PDC is not available. During this time no changes to
+the SAM are possible. Whenever changes to the SAM are done on the PDC,
+all BDC receive the changes from the PDC.
+</para>
+
+<para>
+Since version 2.2 Samba officially supports domain logons for all
+current Windows Clients, including Windows 2000 and XP. This text
+assumes the domain to be named SAMBA. To be able to act as a PDC, some
+parameters in the [global]-section of the smb.conf have to be set:
+</para>
+
+<para><programlisting>
+	workgroup = SAMBA
+	domain master = yes
+	domain logons = yes
+</programlisting></para>
+
+<para>
+Several other things like a [homes] and a [netlogon] share also may be
+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>
+<title>What qualifies a Domain Controller on the network?</title>
+
+<para>
+Every machine that is a Domain Controller for the domain SAMBA has to
+register the NetBIOS group name SAMBA#1c with the WINS server and/or
+by broadcast on the local network. The PDC also registers the unique
+NetBIOS name SAMBA#1b with the WINS server. The name type #1b is
+normally reserved for the domain master browser, a role that has
+nothing to do with anything related to authentication, but the
+Microsoft Domain implementation requires the domain master browser to
+be on the same machine as the PDC.
+</para>
+
+
+<sect2>
+<title>How does a Workstation find its domain controller?</title>
+
+<para>
+A NT workstation in the domain SAMBA that wants a local user to be
+authenticated has to find the domain controller for SAMBA. It does
+this by doing a NetBIOS name query for the group name SAMBA#1c. It
+assumes that each of the machines it gets back from the queries is a
+domain controller and can answer logon requests. To not open security
+holes both the workstation and the selected (TODO: How is the DC
+chosen) domain controller authenticate each other. After that the
+workstation sends the user's credentials (his name and password) to
+the domain controller, asking for approval.
+</para>
+
+</sect2>
+
+
+<sect2>
+<title>When is the PDC needed?</title>
+
+<para>
+Whenever a user wants to change his password, this has to be done on
+the PDC. To find the PDC, the workstation does a NetBIOS name query
+for SAMBA#1b, assuming this machine maintains the master copy of the
+SAM. The workstation contacts the PDC, both mutually authenticate and
+the password change is done.
+</para>
+
+</sect2>
+
+</sect1>
+
+
+<sect1>
+<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
+not yet been fully implemented. The Samba Team is working on
+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,
+a second Samba machine can be set up to
+service logon requests whenever the PDC is down.
+</para>
+
+</sect1>
+
+
+<sect1>
+<title>How do I set up a Samba BDC?</title>
+
+<para>
+Several things have to be done:
+</para>
+
+<itemizedlist>
+
+<listitem><para>
+The domain SID has to be the same on the PDC and the BDC. This used to
+be stored in the file private/MACHINE.SID. This file is not created
+anymore since Samba 2.2.5 or even earlier. Nowadays the domain SID is
+stored in the file private/secrets.tdb. Simply copying the secrets.tdb
+from the PDC to the BDC does not work, as the BDC would
+generate a new SID for itself and override the domain SID with this
+new BDC SID.</para>
+
+<para>
+To retrieve the domain SID from the PDC or an existing BDC and store it in the
+secrets.tdb, execute 'net rpc getsid' on the BDC.
+</para></listitem>
+
+<listitem><para>
+The Unix user database has to be synchronized from the PDC to the
+BDC. This means that both the /etc/passwd and /etc/group have to be
+replicated from the PDC to the BDC. This can be done manually
+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>
+
+<listitem><para>
+The Samba password database in the file private/smbpasswd has to be
+replicated from the PDC to the BDC. This is a bit tricky, see the
+next section.
+</para></listitem>
+
+<listitem><para>
+Any netlogon share has to be replicated from the PDC to the
+BDC. This can be done manually whenever login scripts are changed,
+or it can be done automatically together with the smbpasswd
+synchronization.
+</para></listitem>
+
+</itemizedlist>
+
+<para>
+Finally, the BDC has to be found by the workstations. This can be done
+by setting
+</para>
+
+<para><programlisting>
+	workgroup = samba
+	domain master = no
+	domain logons = yes
+</programlisting></para>
+
+<para>
+in the [global]-section of the smb.conf of the BDC. This makes the BDC
+only register the name SAMBA#1c with the WINS server. This is no
+problem as the name SAMBA#1c is a NetBIOS group name that is meant to
+be registered by more than one machine. The parameter 'domain master =
+no' forces the BDC not to register SAMBA#1b which as a unique NetBIOS
+name is reserved for the Primary Domain Controller.
+</para>
+
+<sect2>
+<title>How do I replicate the smbpasswd file?</title>
+
+<para>
+Replication of the smbpasswd file is sensitive. It has to be done
+whenever changes to the SAM are made. Every user's password change is
+done in the smbpasswd file and has to be replicated to the BDC. So
+replicating the smbpasswd file very often is necessary.
+</para>
+
+<para>
+As the smbpasswd file contains plain text password equivalents, it
+must not be sent unencrypted over the wire. The best way to set up
+smbpasswd replication from the PDC to the BDC is to use the utility
+rsync. rsync can use ssh as a transport. ssh itself can be set up to
+accept *only* rsync transfer without requiring the user to type a
+password.
+</para>
+
+
+</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>