Samba Administration Guide - 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:

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.

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

net rpc getsid
```
Specification of the ldap admin dn is obligatory. This also requires the LDAP administration password to be set in the secrets.tdb using the smbpasswd -w mysecret .
The ldap suffix parameter and the ldap idmap suffix 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.
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 administrators are not normally aware that this is happening or when it takes place.

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