Creating Domains and Domain Controllers

When you set up a Windows NT Server, you are given a choice of either creating a new domain or joining an existing domain. If you are setting up the first Windows NT Server in your organization, you choose the former option, then specify the name of the domain. The server then becomes a primary domain controller (PDC) for the domain you create. A PDC holds the master directory database for a domain. Other Windows NT Servers can be installed in the domain and designated as backup domain controllers (BDCs). Any changes that administrators make to accounts are recorded in the PDC and then replicated to BDCs. BDCs can be located at remote sites to provide localized account information. They can also be promoted to a PDC if the primary PDC goes down.

Note that Windows NT Server computers can be installed in domains as member servers, which means that they are neither a PDC nor a BDC. They provide services to users but do not hold a copy of the directory database.

---

Note:  Domains were originally intended to accommodate the departmental nature of local area networks. In addition, domains help break up large networks into smaller groups of resources that are easier for users to browse. Over the past few years, however, organizations have grown out of their departmental LANs and require networks that meet the communication and networking needs of the entire organization. To meet these needs, Microsoft introduced Windows NT Server Directory Services in 1997.

Directory Services expands on the two-level domain model with a hierarchical directory tree model that simplifies security management and better serves large global organizations. Directory Services is covered further at the end of this chapter.

---

Trust Relationships

Because each domain has its own set of user accounts, splitting enterprise networks into domains provides a way to put up a form of security barrier. Users in one domain cannot access resources in another domain unless trust relationships are specifically established by administrators of the domains. Even after that is done, the administrator in one domain must grant permissions for users in one domain to access resources in another. All the forethought and activity associated with trust relationships and interdomain permissions strengthens the security of the network.

In a trust relationship, a trusting domain enables another domain (the trusted domain) to access its resources. Technically, the domain controller trusts that the other domain controller has properly validated users so those users can be allowed to access resources in the trusting domain. Also once a trust relationship is established, a list of users from the trusted domain can be accessed from the trusting domain so those users can be granted permissions to objects in the trusting domain.

Look at the left side of figure 12.3. Domain A trusts domain B and allows domain B users to access its resources (based on permissions). In this case, domain A is the trusting domain and domain B is the trusted domain. A two-way trust relationship extends this relationship in two directions as shown on the right side of figure 12.3.

Figure 12.3  Trust relationships enable users in one domain to access resources in another. A one-way trust relationship is shown on the left and a two-way trust relationship is shown on the right.

Administrators set up trust relationships as follows:

•  The administrator in the trusting domain designates which domains it will trust. This designation is done in the Windows NT User Manager for Domains utility.

•  The administrator in the trusted domain uses the same utility to complete the relationship by specifying the name of a trusting domain and typing a required password.

A two-way relationship is set up by going through these same steps in reverse. The trusted domain permits a trust relationship, and the administrators in the trusting domain are required to enter a password in order to complete the relationship.

User Accounts, Groups, Rights, and Permissions

Windows NT security is based on the concepts of user accounts, groups, rights and permissions:

•  User accounts. Every user requires a user account unless they log on as a guest.

•  Groups. Groups make management easier. Administrators create groups and add user accounts to groups, then assign rights and permissions to groups.

•  Rights. Rights relate to “doing things” like being able to log on from the network or manage user accounts and other resources.

•  Permissions. Permissions relate to “accessing things” like directories, files, and printers.

Each of these are discussed in more detail in the following sections.

User Accounts

A user account is created by an administrator using a utility called the User Manager. A name is assigned to each account, along with other identification information. Windows NT then assigns a unique security identifier (SID) to the account. The SID is unique for every user account and is never reused.

In addition, every time a user logs on, a security access token is created for that logon session that contains the user’s SID and the SID of any groups the user belongs to. Think of an access token as a security badge that you might pin on yourself while visiting a secure facility. The badge displays IDs that define the facilities you are allowed to access. A doorman at each facility checks your IDs against a list of allowed IDs and grants you access if there is a match.

If a user starts a program, the program is given a copy of the user’s access token which identifies that the program is running for the user. Any time the user (or the user’s program) tries to access an object such as a file, the security subsystem looks in the object’s access control list to see if the user’s SID is listed. If it is, then the user is allowed to access the object based on the permissions defined in the access control list for that user’s SID.