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 if the slave finds its master down at the wrong time,
you will have stability and operational problems.
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.
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.
The Domain Backend Account Distribution Options table below lists
possible design configurations for a PDC/BDC infrastructure.
Table5.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 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.
|
|