The Importance of a Domain - Who's SAM? (Page 2 of 11 )
We stated in the last section that domains were introduced with LAN Manager, but what exactly is a domain? In its simplest form, you can think of a domain as a set of computers that share a common authentication (account) database that facilitates simpler and more secure communication between them.
This is a very different concept from that of a workgroup where each computer had its own user database. There is now one central account database used by all the machines in the domain for authentication purposes (although all machines other than domain controllers have a local authentication database as well, which is generally unused since when they log on they select to authenticate against the domains database).
As shown in the figure above, with a domain, notice there is one account database held on a central server and all the machines that are members of the domain will authenticate against that server. This database is known as the Security Accounts Manager database or SAM for short. This SAM format database was utilized by domains up to and including Windows NT 4 and is still used as the local account database for non-domain controllers. As we will see, with Windows 2000 domain controllers a brand new format was created.
Within the SAM database, each user will have one account that can be used to log on to any machine that is part of that domain; there is no need to maintain multiple accounts on each machine. The domain also provides a centralized point for network administration; all management of the accounts and other domain-related information can be performed on the server holding the domains SAM database (or any machine that has the administration tools installed with sufficient permission to connect to the domain controller). Finally, because all the computers share a single accounts database granting access to resources is far simpler.
I have referred to the SAM account database as the information replicated between the Primary Domain Controller ( PDC) and the Backup Domain Controller ( BDC). Actually, there is a second database replicated, the Local Security Authority (LSA) database, containing the secrets used for domain controller computer account passwords, account policy settings and trust relationships. From a practical point of view, it is not necessary to concern ourselves with the fact there are two databases; the PDC replicates its database to the BDCs. In essence, each BDC has a copy of the PDCs database, which we will discuss more in detail later.
Domain Controllers
In the previous figure a single server, the PDC, contains the account database holding all the information about the accounts in the domain and this server is known as a domain controller. In this figure, the server is actually labeled PDC, which stands for Primary Domain Controller.
Domains before the release of the Active Directory used a single-master model where only one server held a writable copy of the account database. However, only a single copy of the database is very poor from a fault tolerance and load balancing perspective. Backups alone cannot resolve this since most backups (depending on the backup schedule) are typically taken at 24-hour intervals which would mean up to 24 hours of changes could be lost in the event of a server failure and the amount of down time that would be caused by having to build a new server and restore the backup.
To counter this problem there are actually two types of domain controllers in a domain:
- Primary Domain Controller (PDC): The PDC holds the writable copy of the domain's account database. All modifications to domain information are performed by the Primary Domain Controller, which updates the database. There can only be one PDC in each domain.
- Backup Domain Controller (BDC): The BDC holds a read-only copy of the domain's account database. A BDC can authenticate user logons providing local balancing and in the event of a PDC failure can be manually promoted to the PDC role. There can be multiple BDCs in each domain.
These domain controller roles are set at installation of the operating system, and it is not possible to convert a normal server to a domain controller using the standard functionality provided with Windows NT (although several third-party vendors wrote some tools that could change the role of a server with mixed levels of success). During installation of Windows NT Server, the role of the server can be a Primary Domain Controller, a Backup Domain Controller, or Stand Alone.
As stated, in the event of the Primary Domain Controller being unavailable (if it has crashed and is not available for an unacceptable amount of time) a Backup Domain Controller can be promoted to the PDC role. The best practice is, if possible, to promote a BDC to the PDC role while the PDC is still available; this causes an up-to-date copy of the SAM to be copied to the BDC and the current PDC demoted to a BDC role.
If the PDC is in an unstartable state when a BDC is promoted, and is therefore unavailable, the PDC will still think it's the PDC. When it eventually restarts, it will detect a PDC already running for the domain and stop its NETLOGON service to avoid any possibility of corruption or lost data. The Administrator would then manually demote the old PDC to a BDC role.
The Backup Domain Controllers update their databases periodically after being notified by the Primary Domain Controller of changes. By default, the PDC would check for changes every five minutes and notify up to ten BDCs at a time (although these numbers could be modified via the registry). The notified BDCs would then wait a random amount of time before contacting the PDC and asking for replication. Using this method keeps all the databases synchronized.
There are various types of replication, full, partial and urgent/immediate. A full replication is used when a new BDC is added and when the number of changes since the last replication is greater than the size of the PDC's change log file,
%systemroot%Netlogon.chg. By default, this file is configured to a maximum size of 65,536 bytes, which normally holds 2000 changes although this can be changed via a registry change. Once the file reaches the maximum size it starts overwriting the oldest entry.
A partial replication just replicates changes since the last replication and urgent replication occurs when any of the following occur:
- An account is locked out
- A modification is made to the account lockout or domain password policy
- A machine account password changes
- A modification is made to an LSA secret
Administrators can also force a replication using the various tools available to them such as Server Manager, "net accounts /sync", and nltest, which is a resource kit utility.
The replication was at an object level. This means that if any attribute of an object was changed the whole object, and not just the change resulting in higher network usage, was replicated.
Next: Joining a Domain >>
More IIS Articles
More By PACKT Publishing
|
 This article is taken from chapter one of the book Windows Server 2003 Active Directory Design and Implementation: Creating, Migrating, and Merging Networks by John Savill (PACKT Publishing, 2005; ISBN: 1904811086). Check it out at your favorite bookstore. Buy this book now.
|
|
