John, and the Samba community,
Thanks for all your previous help.
We are writing to clarify a couple of questions that arose from our
reading of Samba 3 Official Documentation - Chapter 6: Backup
Domain Control (see the quoted paragraphs below).
Question 1 / Scenario 1:
Trust Domain Account Relationships
Houston:
PDC (functioning as centralized domain SAM)
|
Trust Domain Account Relationship
|
Denver:
BDC (acting as PDC for local SAM)
CLIENTS (periodically updating machine account information to local SAM)
In this scenario, we interpret the documention to be stating that since
the local
SAM in Denver isn't sending its update information to the Houston PDC;
when
the Houston PDC rsyncs with the Denver BDC, the Denver BDC's SAM will
be overwritten with old machine account data and the result will be a
broken
trust. The suggested improvement is to use a LDAP database rather than
SAM.
Is this a correct interpretation?
Question 2 / Scenario 2:
PDC-BDC Fail Over
Our local network domain has no Trust Domain Relationships configured.
However, the above scenario does raise the question of the best way to
handle
our domain in the event of a fail over:
San Jose:
PDC (acting as PDC for local SAM)
|
rsync (PDC SAM rsyncs to BDC SAM)
|
BDC (acting as fail over BDC for the local domain)
We have been running various fail-over scenairos in our lab for the last
month. Our only password backend option is tdbsam (no LDAP backend
approved).
When we disconnected the PDC from the network, the BDC continued to
authenticate users, allow logons, run longon scripts, etc.
We were pleased to discover that tests to create/update/add/delete
various
user and machine accounts produced an error message and didn't allow
changes
on the BDC's (read only) SAM (no rsync overwrite issues).
The remaining questions: are client systems also locked out of the BDC's
SAM
for updating their own machine account information until there is a PDC
present
on the domain again?
Worst Case Scenario:
Since rsync goes PDC->BDC, if there was a major hardware failure on the
PDC
and the BDC's role was changed to PDC until the original failed system
was
repaired, would the new PDC's SAM then allow account updates?
- and -
woud it be a best practice to configure the old PDC to a BDC after it is
repaired
then bring in back online and rsync with the current PDC?
-------------------------------------------------->From Samba 3 Official Documentation - Chapter 6: Backup Domain Control
--------------------------------------------------
Features and Benefits
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.
Machine Accounts Keep Expiring
This problem will occur when the passdb (SAM) files are copied
from a central server but the local Backup Domain Controller 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 over written when the SAM is re-copied from the PDC. The
result is that the Domain Member machine on start up 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.
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.
--------------------------------------------------
Larry Liu
Robert Inerbickler
Sun Microsystems
