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.
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).
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
This normally translates to the path
are the files that are involved in replication of the SAM database where BDCs are present
on the network.
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.
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).
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.
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.
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.
The BDC is said to hold a
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.
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.
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 LDAP Server on PDC
section for an example of the minimum required settings.
Example5.1.Minimal smb.conf for a PDC in Use with a BDC LDAP Server on PDC
workgroup = MIDEARTH
passdb backend = ldapsam://localhost:389
domain master = yes
domain logons = yes
ldap suffix = dc=quenya,dc=org
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=sambadmin,dc=quenya,dc=org
Several other things like a
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
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
by Example” that may be obtained from local and on-line book stores.