5.1 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 ^[1] clearly setting out your requirements and/or question and we will do our best to provide a solution.

^[1] mailto:[e-mail]

Samba-3 is capable of acting 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 availablity - if the slave finds it's master down at the wrong time, you will have stability and operational problems.

While it is possible to run a Samba-3 BDC with non-LDAP backend, that backend must allow some form of 'two way' propogration, of changes from the BDC to the master. Only LDAP is capable of this at this stage.

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.

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. Table 5.1 lists possible design configurations for a PDC/BDC infrastructure.

Table 5.1. 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 fail-over ability. This is a useable solution, but not optimal.
tdbsam	tdbsam + net rpc vampire	Does not work with Samba-3.0.0; may be implemented in a later release. The downside of this solution is that an external process will control account database integrity. This solution may appeal to sites that wish to avoid the complexity of LDAP. The net rpc vampire is used to synchronize domain accounts from the PDC to the BDC.
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. Use rsync to synchronize the TDB database files from the PDC to the BDC.
smbpasswd file	smbpasswd file	Do not use this configuration. Not an elegant solution due to the delays in synchronization. Use rsync to synchronize the TDB database files from the PDC to the BDC. Can be made to work using a cron job to synchronize data from the PDC to the BDC.