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.

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:

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:

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.

In a workgroup, machines were able to make themselves members by setting their workgroup value name; there was no central control or a selection committee on who could join. This is very different from a domain. Since you now have a central administration point and database, you have to be granted permission to join the domain because not everyone can be in a domain.

Unlike a workgroup, a domain is considered a corporate concept and so the "home user" versions of Windows do not support the ability to join a domain. They may access resources in a domain but are not considered part of the domain. (In fact if your workgroup account has the same name and password as a domain account then you can access resources in the domain without having to manually supply credentials!)

The table below shows the common operation systems and their domain compatibility:

Notice that only the NT-based operating systems can operate in a domain (except for XP Home Edition). It is not just the workstation brands of Windows but also the server versions, which can operate as members of a domain. They do not have to be domain controllers to be in a domain, they can also take advantage of the central account database and are known as "member servers".

Once your client operating system is capable of being in a domain it has to be joined to the domain by an Administrator of the domain (an Administrator is like a super-user with the ability to modify the accounts database). Normal domain users cannot add computers (although this changes with the Active Directory). The computer actually has an account in the domain, just like a user, and this account can be created in advance by joining the domain via the Server Manager application or by specifying an Administrator's credentials when performing the domain-joining action, which results in the computer's account being created on demand.

The exact method of joining a domain varies slightly between the operating systems (and these are discussed later in Chapter 2) but the result will be a notification of the successful join and a prompt to restart your computer.

Once a computer is a member of the domain upon startup the user will be prompted to enter the secure-attention sequence (or Ctrl+Alt+Del as it is commonly known) which then allows the account and password to be specified.

In the logon screen shown, we see more than just one domain listed as an option to log on to. This is because of various trust relationships in place and an option to log on using the local SAM database, which we can use if we do not wish to use a domain account.

Of course, in any corporate environment, users would not have any local accounts and would have to use the domain options.Notice the format of the domain names, CHILD1, CHILD2, and SAVILLTECH. With the domain implementations prior to the Active Directory all domain names were NetBIOS names having a maximum length of 16 characters. NetBIOS stands for Network Basic Input/Output System, which separates the details of the network from an application by enabling the application to specify a destination for a request. NetBIOS is network independent and while originally running over NetBEUI, it was modified to also run over TCP/IP.

Since NetBIOS names can be up to 16 characters the maximum length for a domain name is actually 15 characters as the final character is used to specify the type of resource; for example <1C> is used to specify that the resource is a domain controller. A full list of the NetBIOS suffixes can be found in Knowledge Base article Q163409 that can be accessed via http://support.microsoft.com.

When you create a domain during the installation of Windows NT Server, you must enter a domain name of 15 characters or less and while some other characters are allowed you should stick to using characters A-Z, 1-9, and the hyphen character. Other legal characters are ! @ # $ % ^ & ( ) - _ ' { } . ~ although these can cause complications.

We know the domain controllers have a NetBIOS resource entry of type 1C but how will the clients actually find the domain controllers? There are three methods. The order in which they are used depends on the configuration of the client, and the options enabled on your network and clients:

The actual order in which a WINS request or broadcast occurs depends on the configuration node type of the client and this will be explored further in future chapters. For now, we just need to understand that the methods of finding a domain controller vary but are all based around NetBIOS domain names.

So far, everything we have discussed has been around the domain model used for Windows NT 4 and it was a massive improvement over the workgroup model: but it still had some significant limitations of its own, which had to be addressed:

There were other problems but these were the main factors in the requirement to create multiple domains (for example, if you needed more than 25,000 users or required a separate group to have control over their resources).

Once you have more than one domain you have multiple account databases. How do you enable users defined in one account database to have access to resources that are stored on computers that belong to a different domain? You just have to trust them.

We defined a domain as a set of machines that share a common account database and because of this common database, a domain also acts as a security boundary. Any machine not in the domain does not use our domains account database and thus cannot be granted access to our resources. Likewise, accounts in our domain cannot be granted access to resources in other domains.

Due to some of the limitations discussed above, multiple domains were a necessity in many corporate environments, but since the domains were still within one organization, a method was required to allow users in one domain to be granted access to resources in another domain. The domain that held the resources had to trust the domain containing the accounts (i.e. accept that the users had been properly authorized and were indeed entitled to an account).

This is exactly how inter-domain authorization was technically implemented: a trust relationship was created where one domain would trust another domain; the domain holding the resources would be the trusting domain (it is trusting the domain with the accounts) while the domain holding the accounts would be the trusted domain. This trust was an administrator-created communication channel to allow inter-domain authorization.

If both the domains involved need to trust each other (allowing users from either domain to be assigned access to resources in either domain), then a bi-directional trust would be created, which is actually two unidirectional trusts.

To create a trust an Administrator in the trusted domain would create a trust relationship with a password and then an Administrator in the trusting domain would complete the relationship by specifying the password set by the trusted domain Administrator. This ensured trust relationships were managed and could not be created without input from Administrators from both domains.

Another side effect of the trust relationship is any user who resides in a domain that is trusted by another domain would be able to sit down at a workstation that belongs to the trusting domain and log on to their local domain. At the main logon screen, the domain list would include the domain of which the workstation is a member and all domains its local domain trusts. As in the example shown in the figure that follows, if a user sits down at a workstation belonging to Domain A, the drop-down domain list would show Domain A and Domain B (although workstations that belong to Domain B would not list Domain A as a drop-down option since Domain A does not trust Domain B).

In this example, Domain A trusts Domain B so accounts in Domain B can be granted access to resources in Domain A.

One final important point about trust relationships is the relationship is not transitive, this means that if Domain A trusts Domain B and Domain B trusts Domain C, Domain A does not automatically trust Domain C; this relationship would have to be manually created. This is shown in the following figure.

You have to manually create every single trust relationship between all domains that require access to resources. In large environments, this could be extremely messy especially if there was no central IT strategy.

Because of trust relationships, a number of models arose that could describe nearly all environments. These models were based around the type of trust relationships and how they were assigned. Once you analyze your NT 4 environment, it will most likely fit one of the following models.

Single Domain Model

In a single domain model there is a single domain containing the accounts and the resources. This is the simplest model and is suitable for most environments that are not geographically spread and have less than 25,000 users. In a single domain model, the domain administrators can administer all of the network servers.

Single Master Domain Model

A single master domain is suitable when the number of accounts required is supported by a single domain, but resource management needs to be broken up by organization. In a single master domain model, the central IT department still centrally manages the accounts in the main domain (which is the 'master domain' or the 'account domain'). Resources such as printers and file shares are located in resource domains that trust the account domain; this means the users in the account domain can be granted access to resources in the resource domains.

Multiple Master Domain Model

The multiple master domain model is very similar to the single master domain model, except there were too many accounts to be stored in one domain and so multiple account domains were required. All of the account domains have a two-way trust between them. The resource domains also trust each of the account domains.

The exact implementation varies; accounts may be split equally between domain controllers, or different account domains in different geographical regions may be present, overcoming the replication limitations of Windows NT 4 domain implementations.

One IT group can still centralize administration of the account domains or various regions can each have control of their own account domain. Like the single master domain model, the resource domain's management can be delegated to various organizational areas to give them full control of their own resources.

Complete Trust Model

No company plans for the complete trust model. Every domain has its own accounts and resources and every domain has a bi-directional trust to every other domain. This means any account in any domain can be assigned access to any resource in any domain. There is no central management or control.

Complete trust domain models typically occur as all departments have their own IT department and create their own domains for accounts and resources, but then find that access to resources in other domains is required and so trust relationships are created as required, eventually spanning all domains.

This is the hardest environment to transfer to the Active Directory due to its lack of central control. This is, however, a requirement for a successful Active Directory implementation.