Chapter 6. Backup Domain Control

Chapter 6. Backup Domain Control
Prev	Part II. Server Configuration Basics	Next

John H. Terpstra

Samba Team

<jht@samba.org>

Volker Lendecke

Samba Team

<Volker.Lendecke@SerNet.DE>

Table of Contents

Features And Benefits

Essential Background Information

MS Windows NT4 Style Domain Control
Active Directory Domain Control
What qualifies a Domain Controller on the network?
How does a Workstation find its domain controller?

Backup Domain Controller Configuration

Example Configuration

Common Errors

Machine Accounts keep expiring, what can I do?
Can Samba be a Backup Domain Controller to an NT4 PDC?
How do I replicate the smbpasswd file?
Can I do this all with LDAP?

-Before you continue reading in this section, please make sure that you are comfortable -with configuring a Samba Domain Controller as described in the -Domain Control chapter. -

Features And Benefits

-This is one of the most difficult chapters to summarise. It does not matter what we say here -for someone will still draw conclusions and / or approach the Samba-Team with expectations -that are either not yet capable of being delivered, or that can be achieved far more -effectively using a totally different approach. Since this HOWTO is already so large and -extensive, we have taken the decision to provide sufficient (but not comprehensive) -information regarding Backup Domain Control. In the event that you should have a persistent -concern that is not addressed in this HOWTO document then please email -John H Terpstra clearly setting out your requirements -and / or question and we will do our best to provide a solution. -

-Samba-3 is capable of acting as a Backup Domain Controller to another Samba Primary Domain -Controller. A Samba-3 PDC can operate with an LDAP Account backend. The Samba-3 BDC can -operate with a slave LDAP server for the Account backend. This effectively gives samba a high -degree of scalability. This is a very sweet (nice) solution for large organisations. -

-While it is possible to run a Samba-3 BDC with non-LDAP backend, the administrator will -need to figure out precisely what is the best way to replicate (copy / distribute) the -user and machine Accounts backend. -

-The use of a non-LDAP backend SAM database is particularly problematic because Domain member -servers and workstations periodically change the machine trust account password. The new -password is then stored only locally. This means that in the absence of a centrally stored -accounts database (such as that provided with an LDAP based solution) if Samba-3 is running -as a BDC, the BDC instance of the Domain member trust account password will not reach the -PDC (master) copy of the SAM. If the PDC SAM is then replicated to BDCs this results in -overwriting of the SAM that contains the updated (changed) trust account password with resulting -breakage of the domain trust. -

-Considering the number of comments and questions raised concerning how to configure a BDC -lets consider each possible option and look at the pro's and con's for each theoretical solution: -

Backup Domain Backend Account Distribution Options

- Solution: Passwd Backend is LDAP based, BDCs use a slave LDAP server -
- Arguments For: This is a neat and manageable solution. The LDAP based SAM (ldapsam) - is constantly kept up to date. -
- Arguments Against: Complexity -
- Passdb Backend is tdbsam based, BDCs use cron based "net rpc vampire" to - suck down the Accounts database from the PDC -
- Arguments For: It would be a nice solution -
- Arguments Against: It does not work because Samba-3 does not support the required - protocols. This may become a later feature but is not available today. -
- Make use of rsync to replicate (pull down) copies of the essential account files -
- Arguments For: It is a simple solution, easy to set up as a scheduled job -
- Arguments Against: This will over-write the locally changed machine trust account - passwords. This is a broken and flawed solution. Do NOT do this. -
- Operate with an entirely local accounts database (not recommended) -
- Arguments For: Simple, easy to maintain -
- Arguments Against: All machine trust accounts and user accounts will be locally - maintained. Domain users will NOT be able to roam from office to office. This is - a broken and flawed solution. Do NOT do this. -

Essential Background Information

-A Domain Controller is a machine that is able to answer logon requests from network -workstations. Microsoft LanManager and IBM LanServer were two early products that -provided this capability. The technology has become known as the LanMan Netlogon service. -

-When MS Windows NT3.10 was first released, it supported an new style of Domain Control -and with it a new form of the network logon service that has extended functionality. -This service became known as the NT NetLogon Service. The nature of this service has -changed with the evolution of MS Windows NT and today provides a very complex array of -services that are implemented over a complex spectrum of technologies. -

MS Windows NT4 Style Domain Control

-Whenever a user logs into a Windows NT4 / 200x / XP Professional Workstation, -the workstation connects to a Domain Controller (authentication server) to validate -the username and password that the user entered are valid. If the information entered -does not validate against the account information that has been stored in the Domain -Control database (the SAM, or Security Account Manager database) then a set of error -codes is returned to the workstation that has made the authentication request. -

-When the username / password pair has been validated, the Domain Controller -(authentication server) will respond with full enumeration of the account information -that has been stored regarding that user in the User and Machine Accounts database -for that Domain. This information contains a complete network access profile for -the user but excludes any information that is particular to the user's desktop profile, -or for that matter it excludes all desktop profiles for groups that the user may -belong to. It does include password time limits, password uniqueness controls, -network access time limits, account validity information, machine names from which the -user may access the network, and much more. All this information was stored in the SAM -in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0). -

-The account information (user and machine) on Domain Controllers is stored in two files, -one containing the Security information and the other the SAM. These are stored in files -by the same name in the C:\WinNT\System32\config directory. These -are the files that are involved in replication of the SAM database where Backup Domain -Controllers are present on the network. -

-There are two situations in which it is desirable to install Backup Domain Controllers: -

- On the local network that the Primary Domain Controller is on, if there are many - workstations and/or where the PDC is generally very busy. In this case the BDCs - will pick up network logon requests and help to add robustness to network services. -
- At each remote site, to reduce wide area network traffic and to add stability to - remote network operations. The design of the network, the strategic placement of - Backup Domain Controllers, together with an implementation that localises as much - of network to client interchange as possible will help to minimise wide area network - bandwidth needs (and thus costs). -

-The PDC contains the master copy of the SAM. In the event that an administrator makes a -change to the user account database while physically present on the local network that -has the PDC, the change will likely be made directly to the PDC instance of the master -copy of the SAM. In the event that this update may be performed in a branch office the -change will likely be stored in a delta file on the local BDC. The BDC will then send -a trigger to the PDC to commence the process of SAM synchronisation. The PDC will then -request the delta from the BDC and apply it to the master SAM. The PDC will then contact -all the BDCs in the Domain and trigger them to obtain the update and then apply that to -their own copy of the SAM. -

-Thus the BDC is said to hold a read-only of the SAM from which -it is able to process network logon requests and to authenticate users. The BDC can -continue to provide this service, particularly while, for example, the wide area -network link to the PDC is down. Thus a BDC plays a very important role in both -maintenance of Domain security as well as in network integrity. -

-In the event that the PDC should need to be taken out of service, or if it dies, then -one of the BDCs can be promoted to a PDC. If this happens while the original PDC is on -line then it is automatically demoted to a BDC. This is an important aspect of Domain -Controller management. The tool that is used to affect a promotion or a demotion is the -Server Manager for Domains. -

Example PDC Configuration

-Since version 2.2 Samba officially supports domain logons for all current Windows Clients, -including Windows NT4, 2003 and XP Professional. For samba to be enabled as a PDC some -parameters in the [global]-section of the smb.conf have to be set: -

-	workgroup = SAMBA
-	domain master = yes
-	domain logons = yes
-

-Several other things like a [homes] and a [netlogon] share also need to be set along with -settings for the profile path, the users home drive, etc.. This will not be covered in this -chapter, for more information please refer to the chapter on Domain Control. -

Active Directory Domain Control

-As of the release of MS Windows 2000 and Active Directory, this information is now stored -in a directory that can be replicated and for which partial or full administrative control -can be delegated. Samba-3 is NOT able to be a Domain Controller within an Active Directory -tree, and it can not be an Active Directory server. This means that Samba-3 also can NOT -act as a Backup Domain Controller to an Active Directory Domain Controller. -

What qualifies a Domain Controller on the network?

-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> name 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. -

How does a Workstation find its domain controller?

-An MS Windows NT4 / 200x / XP Professional 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 domain controller -authenticate each other. After that the workstation sends the user's credentials (name and -password) to the local Domain Controller, for validation. -

Backup Domain Controller Configuration

-Several things have to be done: -

- 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.
- To retrieve the domain SID from the PDC or an existing BDC and store it in the - secrets.tdb, execute: -
```
-	root# net rpc getsid
-	
```
- 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. NIS is by no means - the only method to synchronize passwords. An LDAP solution would work - as well. -
- The Samba password database has to be replicated from the PDC to the BDC. - As said above, though possible to synchronise the smbpasswd - file with rsync and ssh, this method is broken and flawed, and is - therefore not recommended. A better solution is to set up slave LDAP - servers for each BDC and a master LDAP server for the PDC. -
- 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. -

Example Configuration

-Finally, the BDC has to be found by the workstations. This can be done by setting: -

-	workgroup = SAMBA
-	domain master = no
-	domain logons = yes
-

-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. -

Common Errors

-As this is a rather new area for Samba there are not many examples that we may refer to. Keep -watching for updates to this section. -

Machine Accounts keep expiring, what can I do?

-This problem will occur when occur when the passdb (SAM) files are copied from a central -server but the local Backup Domain Controllers. Local machine trust account password updates -are not copied back to the central server. The newer machine account password is then over -written when the SAM is copied from the PDC. The result is that the Domain member machine -on start up will find that it's passwords does not match the one now in the database and -since the startup security check will now fail, this machine will not allow logon attempts -to proceed and the account expiry error will be reported. -

-The solution: use a more robust passdb backend, such as the ldapsam backend, setting up -an slave LDAP server for each BDC, and a master LDAP server for the PDC. -

Can Samba be a Backup Domain Controller to an NT4 PDC?

-With version 2.2, no. The native NT4 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. -

-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. -

-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. -

How do I replicate the smbpasswd file?

-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. -

-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. -

-As said a few times before, use of this method is broken and flawed. Machine trust -accounts will go out of sync, resulting in a very broken domain. This method is -not recommended. Try using LDAP instead. -

Can I do this all with LDAP?

-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). -

Prev	Up	Next
Chapter 5. Domain Control	Home	Chapter 7. Domain Membership