diff options
Diffstat (limited to 'docs/docbook/projdoc/Samba-BDC-HOWTO.sgml')
| -rw-r--r-- | docs/docbook/projdoc/Samba-BDC-HOWTO.sgml | 250 |
1 files changed, 0 insertions, 250 deletions
diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml deleted file mode 100644 index 2f3b568471..0000000000 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml +++ /dev/null @@ -1,250 +0,0 @@ -<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> |