&author.jht; &author.vl;
&person.gd;LDAP updates

# Backup Domain Control

Before you continue reading this section, please make sure that you are comfortable with configuring a Samba domain controller as described in Domain Control.

## Features and Benefits

This is one of the most difficult chapters to summarize. 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. In the event that you should have a persistent concern that is not addressed in this book, 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 can act as a Backup Domain Controller (BDC) to another Samba Primary Domain Controller (PDC). A Samba-3 PDC can operate with an LDAP account backend. The LDAP backend can be either a common master LDAP server or a slave server. The use of a slave LDAP server has the benefit that when the master is down, clients may still be able to log onto the network. This effectively gives Samba a high degree of scalability and is an effective solution for large organizations. If you use an LDAP slave server for a PDC, you will need to ensure the master's continued availability &smbmdash; if the slave finds its master down at the wrong time, you will have stability and operational problems.

SAM backend LDAP
PDC
BDC
LDAP slave
scalability

While it is possible to run a Samba-3 BDC with a non-LDAP backend, that backend must allow some form of "two-way" propagation of changes from the BDC to the master. At this time only LDAP delivers the capability to propagate identity database changes from the BDC to the PDC. The BDC can use a slave LDAP server, while it is preferable for the PDC to use as its primary an LDAP master server.

two-way propagation
replication SAM
non-LDAP backend
propagate

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 the SAM that contains the updated (changed) trust account password with resulting breakage of the domain trust.

non-LDAP backend
SAM backend non-LDAP
domain member server
BDC
PDC
trust account password
domain trust

Considering the number of comments and questions raised concerning how to configure a BDC, let's consider each possible option and look at the pros and cons for each possible solution. The Domain Backend Account Distribution Options table below lists possible design configurations for a PDC/BDC infrastructure.

net rpc
SAM backend ldapsam
SAM backend tdbsam
replication SAM

Domain Backend Account Distribution Options

PDC Backend | BDC Backend | Notes/Discussion
--- | --- | ---
Master LDAP Server | Slave LDAP Server | The optimal solution that provides high integrity. The SAM will be replicated to a common master LDAP server.
Single Central LDAP Server | Single Central LDAP Server | A workable solution without failover ability. This is a usable solution, but not optimal.
tdbsam | tdbsam + `net rpc vampire` | Does not work with Samba-3.0; Samba does not implement the server-side protocols required.
tdbsam | tdbsam + `rsync` | Do not use this configuration. Does not work because the TDB files are live and data may not have been flushed to disk. Furthermore, this will cause domain trust breakdown.
smbpasswd file | smbpasswd file | Do not use this configuration. Not an elegant solution due to the delays in synchronization and also suffers from the issue of domain trust breakdown.

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

domain controller
logon requests
LanMan
Netlogon

network logon service When MS Windows NT3.10 was first released, it supported a 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 complex array of services that are implemented over an intricate spectrum of technologies.

Windows NT3.10

### 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 that the username and password the user entered are valid. If the information entered does not match account information that has been stored in the domain control database (the SAM, or Security Account Manager database), a set of error codes is returned to the workstation that has made the authentication request.

domain controller
authentication server
username
password
SAM
Security Account Manager SAM
domain control database SAM

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

account information
machine accounts database
profile
network access profile
desktop profile

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 `%SystemRoot%\System32\config` directory. This normally translates to the path `C:\WinNT\System32\config`. These are the files that are involved in replication of the SAM database where BDCs are present on the network.

replication SAM
%SystemRoot%\System32\config
C:\WinNT\System32\config
BDC
SAM

There are two situations in which it is desirable to install BDCs:

- On the local network that the PDC 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.

  PDC
  BDC

- At each remote site, to reduce wide-area network traffic and to add stability to remote network operations. The design of the network, and the strategic placement of BDCs, together with an implementation that localizes as much of network to client interchange as possible, will help to minimize wide-area network bandwidth needs (and thus costs).

  network wide-area

The interoperation of a PDC and its BDCs in a true Windows NT4 environment is worth mentioning here. 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 synchronization. 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.

PDC
SAM
user account database
BDC
trigger

Samba-3 cannot participate in true SAM replication and is therefore not able to employ precisely the same protocols used by MS Windows NT4. A Samba-3 BDC will not create SAM update delta files. It will not interoperate with a PDC (NT4 or Samba) to synchronize the SAM from delta files that are held by BDCs.

SAM replication
SAM delta file
PDC
BDC

Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 cannot function correctly as a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows NT4 can function as a BDC to its own type of PDC.

PDC
BDC

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

SAM
BDC
domain security

In the event that the NT4 PDC should need to be taken out of service, or if it dies, one of the NT4 BDCs can be promoted to a PDC. If this happens while the original NT4 PDC is online, it is automatically demoted to an NT4 BDC. This is an important aspect of domain controller management. The tool that is used to effect a promotion or a demotion is the Server Manager for Domains. It should be noted that Samba-3 BDCs cannot be promoted in this manner because reconfiguration of Samba requires changes to the &smb.conf; file. It is easy enough to manuall change the &smb.conf; file and then restart relevant Samba network services.

PDC
promoted
demoted
reconfiguration

#### Example PDC Configuration

Beginning with 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 section of the &smb.conf; have to be set. Refer to the Minimal smb.conf for a PDC in Use with a BDC &smbmdash; LDAP Server on PDC section for an example of the minimum required settings.

domain logon
PDC

Minimal smb.conf for a PDC in Use with a BDC &smbmdash; LDAP Server on PDC

&example.workgroup; ldapsam://localhost:389 yes yes dc=quenya,dc=org ou=Users ou=Groups ou=Computers ou=Idmap cn=sambadmin,dc=quenya,dc=org

Several other things like a and a share also need to be set along with settings for the profile path, the user's home drive, and so on. This is not covered in this chapter; for more information please refer to Domain Control. Refer to the Domain Control chapter for specific recommendations for PDC configuration. Alternately, fully documented working example network configurations using OpenLDAP and Samba as available in the book Samba-3 by Example that may be obtained from local and on-line book stores.

profile path
home drive

### LDAP Configuration Notes

When configuring a master and a slave LDAP server, it is advisable to use the master LDAP server for the PDC and slave LDAP servers for the BDCs. It is not essential to use slave LDAP servers; however, many administrators will want to do so in order to provide redundant services. Of course, one or more BDCs may use any slave LDAP server. Then again, it is entirely possible to use a single LDAP server for the entire network.

LDAP master
LDAP slave
BDC

When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure this in the `/etc/openldap/slapd.conf` file. It must be noted that the DN of a server certificate must use the CN attribute to name the server, and the CN must carry the servers' fully qualified domain name. Additional alias names and wildcards may be present in the subjectAltName certificate extension. More details on server certificate names are in RFC2830.

LDAP master
LDAP server
CN
DN
RFC2830

It does not really fit within the scope of this document, but a working LDAP installation is basic to LDAP-enabled Samba operation. When using an OpenLDAP server with Transport Layer Security (TLS), the machine name in `/etc/ssl/certs/slapd.pem` must be the same as in `/etc/openldap/sldap.conf`. The Red Hat Linux startup script creates the `slapd.pem` file with hostname localhost.localdomain. It is impossible to access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the certificate is re-created with a correct hostname.

LDAP
BDC
OpenLDAP
transport layer security TLS
/etc/ssl/certs/slapd.pem
slapd.pem
Red Hat Linux

Do not install a Samba PDC so that is uses an LDAP slave server. Joining client machines to the domain will fail in this configuration because the change to the machine account in the LDAP tree must take place on the master LDAP server. This is not replicated rapidly enough to the slave server that the PDC queries. It therefore gives an error message on the client machine about not being able to set up account credentials. The machine account is created on the LDAP server, but the password fields will be empty. Unfortunately, some sites are unable to avoid such configurations, and these sites should review the parameter, intended to slow down Samba sufficiently for the replication to catch up. This is a kludge, and one that the administrator must manually duplicate in any scripts (such as the ) that they use.

PDC
OpenLDAP
machine account
credentials
replication
duplicate

Possible PDC/BDC plus LDAP configurations include:

- PDC+BDC -> One Central LDAP Server.

- PDC -> LDAP master server, BDC -> LDAP slave server.

- PDC -> LDAP master, with secondary slave LDAP server.

  BDC -> LDAP master, with secondary slave LDAP server.

- PDC -> LDAP master, with secondary slave LDAP server.

  BDC -> LDAP slave server, with secondary master LDAP server.

In order to have a fallback configuration (secondary) LDAP server, you would specify the secondary LDAP server in the &smb.conf; file as shown in the Multiple LDAP Servers in &smb.conf; example.

Multiple LDAP Servers in &smb.conf;

ldapsam:"ldap://master.quenya.org ldap://slave.quenya.org"

### 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 cannot be an Active Directory server. This means that Samba-3 also cannot act as a BDC to an Active Directory domain controller.

MS Windows 2000
Active Directory
directory
replicated
BDC
domain controller

### What Qualifies a Domain Controller on the Network?

Every machine that is a domain controller for the domain MIDEARTH has to register the NetBIOS group name MIDEARTH<1C> with the WINS server and/or by broadcast on the local network. The PDC also registers the unique NetBIOS name MIDEARTH<1B> with the WINS server. The name type <1B> name is normally reserved for the Domain Master Browser (DMB), a role that has nothing to do with anything related to authentication, but the Microsoft domain implementation requires the DMB to be on the same machine as the PDC.

DMB
PDC
WINS
NetBIOS

Where a WINS server is not used, broadcast name registrations alone must suffice. Refer to Network Browsing,Discussion for more information regarding TCP/IP network protocols and how SMB/CIFS names are handled.

broadcast
name registration
SMB/CIFS

### How Does a Workstation find its Domain Controller?

There are two different mechanisms to locate a domain controller: one method is used when NetBIOS over TCP/IP is enabled and the other when it has been disabled in the TCP/IP network configuration.

locate domain controller
NetBIOS

Where NetBIOS over TCP/IP is disabled, all name resolution involves the use of DNS, broadcast messaging over UDP, as well as Active Directory communication technologies. In this type of environment all machines require appropriate DNS entries. More information may be found in DNS and Active Directory.

DNS
broadcast messaging

#### NetBIOS Over TCP/IP Enabled

An MS Windows NT4/200x/XP Professional workstation in the domain MIDEARTH that wants a local user to be authenticated has to find the domain controller for MIDEARTH. It does this by doing a NetBIOS name query for the group name MIDEARTH<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.

Windows NT4/200x/XP
domain controller
logon requests
credentials validation

#### NetBIOS Over TCP/IP Disabled

An MS Windows NT4/200x/XP Professional workstation in the realm `quenya.org` that has a need to affect user logon authentication will locate the domain controller by re-querying DNS servers for the `_ldap._tcp.pdc._msdcs.quenya.org` record. More information regarding this subject may be found in DNS and Active Directory.

realm
logon authentication
DNS
_ldap._tcp.pdc._msdcs.quenya.org

## Backup Domain Controller Configuration

The creation of a BDC requires some steps to prepare the Samba server before &smbd; is executed for the first time. These steps are as follows:

BDC

- The domain SID has to be the same on the PDC and the BDC. In Samba versions pre-2.2.5, the domain SID was stored in the file `private/MACHINE.SID`. For all versions of Samba released since 2.2.5 the domain SID is stored in the file `private/secrets.tdb`. This file is unique to each server and cannot be copied from a PDC to a BDC; the BDC will generate a new SID at startup. It will overwrite the PDC domain SID with the newly created BDC SID. There is a procedure that will allow the BDC to aquire the domain SID. This is described here.

  SID
  PDC
  BDC
  private/secrets.tdb
  private/MACHINE.SID
  domain SID

  To retrieve the domain SID from the PDC or an existing BDC and store it in the `secrets.tdb`, execute:

  domain SID
  PDC
  BDC
  secrets.tdb
  net rpc getsid

      &rootprompt;net rpc getsid

- Specification of the is obligatory. This also requires the LDAP administration password to be set in the `secrets.tdb` using the `smbpasswd -w mysecret`.

  secrets.tdb
  smbpasswd
  LDAP administration password

- The parameter and the parameter must be specified in the &smb.conf; file.

- 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. Alternately, the PDC is set up as an NIS master server and the BDC as an 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 also work.

  replication SAM
  user database
  synchronized
  NIS

- The Samba password database must be replicated from the PDC to the BDC. Although it is possible to synchronize 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. The use of rsync is inherently flawed by the fact that the data will be replicated at timed intervals. There is no guarantee that the BDC will be operating at all times with correct and current machine and user account information. This means that this method runs the risk of users being inconvenienced by discontinuity of access to network services due to inconsistent security data. It must be born in mind that Windows workstations update (change) the machine trust account password at regular intervals &smbmdash; administrators are not normally aware that this is happening or when it takes place.

  password database
  replicated
  PDC
  BDC
  smbpasswd
  rsync
  ssh
  LDAP

  The use of LDAP for both the POSIX (UNIX user and group) accounts and for the SambaSAMAccount data automatically ensures that all account change information will be written to the shared directory. This eliminates the need for any special action to synchronize account information because LDAP will meet that requirement.

  POSIX
  LDAP
  SambaSAMAccount
  synchronize

- The 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 using a `cron` job that will replicate the directory structure in this share using a tool like `rsync`. The use of `rsync` for replication of the netlogon data is not critical to network security and is one that can be manually managed given that the administrator will make all changes to the netlogon share as part of a conscious move.

  netlogon share
  replicate
  PDC
  BDC
  cron
  rsync

### Example Configuration

Finally, the BDC has to be capable of being found by the workstations. This can be done by configuring the Samba &smb.conf; file section as shown in Minimal Setup for Being a BDC.

Minimal Setup for Being a BDC

&example.workgroup; ldapsam:ldap://slave-ldap.quenya.org no yes dc=abmas,dc=biz ou=Users ou=Groups ou=Computers ou=Idmap cn=sambadmin,dc=quenya,dc=org ldap:ldap://master-ldap.quenya.org 10000-20000 10000-20000

Fully documented working example network configurations using OpenLDAP and Samba as available in the book Samba-3 by Example that may be obtained from local and on-line book stores.

This configuration causes the BDC to register only the name MIDEARTH<1C> with the WINS server. This is not a problem, as the name MIDEARTH<1C> is a NetBIOS group name that is meant to be registered by more than one machine. The parameter no forces the BDC not to register MIDEARTH<1B>, which is a unique NetBIOS name that is reserved for the PDC.

BDC
NetBIOS
group
PDC

The idmap backend will redirect the `winbindd` utility to use the LDAP database to store all mappings for Windows SIDs to UIDs and GIDs for UNIX accounts in a repository that is shared. The BDC will however depend on local resolution of UIDs and GIDs via NSS and the `nss_ldap` utility.

idmap backend
winbindd
redirect
winbindd
LDAP database
UID
GID
SID
nss_ldap

Samba-3 has introduced a new ID mapping facility. One of the features of this facility is that it allows greater flexibility in how user and group IDs are handled in respect to NT domain user and group SIDs. One of the new facilities provides for explicitly ensuring that UNIX/Linux UID and GID values will be consistent on the PDC, all BDCs, and all domain member servers. The parameter that controls this is called idmap backend. Please refer to the man page for &smb.conf; for more information regarding its behavior.

Server Type Domain Member
ID mapping
domain member server
idmap backend

The use of the ldap:ldap://master.quenya.org option on a BDC only makes sense where ldapsam is used on a PDC. The purpose of an LDAP-based idmap backend is also to allow a domain member (without its own passdb backend) to use winbindd to resolve Windows network users and groups to common UID/GIDs. In other words, this option is generally intended for use on BDCs and on domain member servers.

BDC
winbindd
domain member servers

## Common Errors

Domain control was a new area for Samba, but there are now many examples that we may refer to. Updated information will be published as they become available and may be found in later Samba releases or from the Samba Web site; refer in particular to the `WHATSNEW.txt` in the Samba release tarball. The book, Samba-3 by Example documents well tested and proven configuration examples. You can obtain a copy of this book for the Samba web site.

domain control

### Machine Accounts Keep Expiring

This problem will occur when the passdb (SAM) files are copied from a central server but the local BDC is acting as a PDC. This results in the application of Local Machine Trust Account password updates to the local SAM. Such updates are not copied back to the central server. The newer machine account password is then overwritten when the SAM is recopied from the PDC. The result is that the domain member machine on startup will find that its passwords do 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.

Machine Trust Accounts
passdb
SAM
Local Machine Trust Account

The solution is to use a more robust passdb backend, such as the ldapsam backend, setting up a 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?

No. The native NT4 SAM replication protocols have not yet been fully implemented.

replication SAM
SAM

Can I get the benefits of a BDC with Samba? Yes, but only to a Samba PDC.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.

BDC
PDC
logon requests

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

replication SAM
smbpasswd
SAM

As the smbpasswd file contains plaintext 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.

plaintext password
ssh
rsync

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 broken domain. This method is not recommended. Try using LDAP instead.

machine trust accounts
LDAP

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

pdb_ldap
LDAP