When namespaces change, changes are reflected instantly in a stand-alone namespace.

DNS RRs

RRs are the most basic part of the Domain name system and have a number of basic elements to them: type, Time to Live (TTL), class, and possibly some data specific to the type of record. These records were described in Chapter 4, “Configuring the Base System,” in the section “DNS Record Type and DNS Resolution.”

Caching Nameserver

A caching nameserver will build a local cache of resolved domain names and use this list to serve other hosts on your network. A large number of DNS requests are the same, and this will increase the speed of resolution and decrease the amount of traffic you send upward to another nameserver provided by named. A sample listing showing how a primary or master nameserver is set up is shown below, which is in the named.conf file (normally in /etc or /etc/named.d).

zone “mydomain.com” IN {

type master;

file “mydomain.com.xone”;

allow-update [ none; ];

};

There is a control utility called rndc that allows you to administer the named daemon. The configuration file for rndc is /etc/rndc.conf, and additionally, you need to specify authentication keys in both /etc/rndc.conf and /etc/named.conf, which must match. You need to generate HMAC-MD5 keys for both the configu-ration files using the following command:

dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name>

The default port used by rndc to connect to is 953. Once the command is set up, the rndc command can be used with the following options shown in Table 8.1.

Table 8.1. rndc Options

The Underscore Character

While it is legitimate to use the underscore character in NetBIOS names, the inclusion of this character in a host name is problematic in environments that use older DNS standards in which its use is prohibited. (The underscore character is allowed in domain names, however, so its use is legitimate in SRV records.) Support for UTF-8 guarantees that the underscore character can be used safely in Microsoft environments. In fact, the underscore is a reserved character that is used extensively in Microsoft DNS to identify SRV records as per RFC 2782. However, third-party standard DNS servers such as older UNIX BIND DNS servers, might not recognize host records that use the underscore. Consequently, host names, especially those used by Internet-facing servers, should not use the underscore character as a best practice. If you are upgrading a Windows NT 4 environment to Windows Server 2003, you might wish to consider changing the NetBIOS and host names of computers whose names include the underscore character before performing the upgrade.

DFS Namespaces

A DFS namespace is a virtual shared folder that contains shared folders from multiple servers. This allows users to access shared folders using the Universal Naming Convention (UNC) path \\[Domain]\[Namespace] instead of remembering the name of each server to which to connect. This also allows multiple servers to host a copy of the same shared folder. To create a DFS namespace, first add the File Services role in Server Manager and then add the Distributed File System Role Services, as shown in Figure 7.15.

DFS Configuration and Application

You can configure DFS using the Namespaces and Replication tools located under DFS Management in Server Manager. When adding a DFS namespace, you will be asked whether you would like to use a domain-based namespace or stand-alone namespace. A domain-based namespace can be replicated to multiple servers for DFS availability if the host server fails. Domain-based namespaces are limited to 5,000 DFS folders. Stand-alone namespaces can support up to 50,000 DFS folders; however, the namespace is not replicated to other servers unless you are using a failover cluster and have configured replication on the cluster.

In the following Sidebar, we will walk through the steps required to create a DFS namespace.

Configuring & Implementing…

Configuring a DFS Namespace

In this exercise, we will create a DFS namespace. Be sure to add the DFS Role Services to the File Services role on your server before continuing.

In Server Manager, navigate to Roles | File Services | DFS Management | Namespaces.

Click on the New Namespace hyperlink to launch the New Namespace Wizard.

When asked for the server that will host the namespace, type in the name of your server and click Next.

On the Namespace Name and Settings page, type in the name you would like to call the namespace. The name you type in will appear as a virtual shared folder within which all the DFS shares (shared folders under one virtual namespace that really exist on multiple servers) are shown. In Figure 7.16, we use the name Shared. You can also create a different DFS namespace for each business unit within your organization (e.g., HR, Finance, IT, etc.).

Be sure to click the Edit Settings button and set the appropriate Share Permissions, then click Next.

On the Namespace Type page, it is preferable to select Domain-based namespace. This will allow users to type in \\[domain] \[namespace] (e.g., \\2k8.local\Shared) instead of remembering a specific server name. Click Next to continue, then Create to complete the wizard.

Now users can browse to \\[domain] and see the namespace you just created as a virtual shared folder. Although it is currently empty, in the next exercise we will add a shared folder to the \\[domain]\Shared namespace.

Creating and Configuring Targets

A DFS target is simply a shared folder that is located on one or more servers. You can increase the availability of a shared folder by hosting it on multiple servers (i.e., specifying multiple targets for the same shared folder) and replicating the data between servers using DFS replication. Placing identical shares on multiple DFS servers is also a good idea from a server maintenance perspective. It allows you to take a file server down for maintenance without the users even knowing that the server was offline.

Earlier in this chapter, we used the Share and Storage Management tool to create a shared folder, and during this process we were given the option to configure DFS for that share as well. In the following Sidebar, we take a look at using the DFS Management | Namespaces tool to add a shared folder to our namespace.

Configuring & Implementing…

Adding Shared Folders to a DFS Namespace

In this exercise, we will add a shared folder to the \\[domain]\Shared DFS namespace.

In Server Manager, navigate to Roles | File Services | DFS Management | Namespaces and select the namespace we created in the previous exercise.

Click on the New Folder hyperlink to launch the New Folder dialog. Type in the name of the shared folder and click on the Add button to point this folder to one or more locations of this shared folder (targets) on one or more servers. In Figure 7.17, we created the Finance folder and pointed it to a shared folder that is replicated on two different servers.

Now users can connect to \\[domain]\[namespace] (e.g., \\2k8.local\Shared) and access the Finance share through DFS. If one of the targets (locations for a copy of the share) is offline, DFS will automatically point the user to one of the alternative locations.

DFS Replication

DFS replication is one of the best features for creating fault tolerance in case one of your servers or sites goes offline. You can use DFS replication to:

Replicate/synchronize a folder or folders among multiple servers in a single location

Replicate/synchronize a folder or folders with a remote location to create an off-site backup for business continuity in case a disaster such as fire, flood, hurricane, or theft interferes with business or destroys data in your office

Create a Branch Office Box (BOB) at branch office locations to speed up local file access (also known as caching) with a share that replicates with the head office

DFS replication is different from FRS in versions of Windows Server prior to 2003 R2. The primary difference is a major improvement in the efficiency of replication by copying only the “differences” or changes to a file instead of the FRS method of copying entire files, even if only a small portion has been changed. DFS replication makes this possible by using a technology called Remote Differential Compression (RDC). Windows Server 2008 also supports FRS for backward compatibility in a mixed environment where it is necessary to replicate with Windows Server 2000 or 2003 R1 servers.

To create a new DFS Replication group, use the New Replication Group hyperlink in Server Manager | Roles | Files Services | DFS Management | Replication.

Configuring & Implementing…

DFS Replication and DFS Namespace

DFS does not require you to set up a DFS namespace to use DFS replication. You can use DFS replication and DFS namespaces independently of each other.

Defense in the Perimeter Network

A perimeter network can be created in a variety of ways in a network environment. Perimeters may be as simple as a single bastion host creating the barrier between the internal network and the internet to a more complex deployment of screened subnets with multiple firewall layers for protection. Regardless of how your perimeter network is deployed, in order to stage a proper defense against mail service attacks, there must be an SMTP presence existing in the company's perimeter network, which is maintained separately from the mail servers that are housing user data and performing internal routing.

Mail traffic should not be allowed to flow from the Internet directly into your internal network, and your internal Exchange servers should not be transmitting data to the Internet. In order to reduce exposure whenever possible, Exchange servers should be placed on the internal network. The one exception to this is the Exchange 2007/Exchange 2010 Edge servers.

Edge servers are a server role that exists in both Exchange 2007 and Exchange 2010, which are intended to be deployed in a perimeter network. By deploying Exchange Edge servers into a screened subnet in your perimeter network, they can be used as smart hosts for forwarding Internet-bound e-mail traffic by the Exchange servers on the internal network. Utilizing Exchange Edge servers allows for minimal surface exposure to the Internet, and since Edge servers are designed to be Internet facing, they are an SMTP deployment which is secured by default.

Exchange Server 2003 does not contain a server role that was intended for deployment into the perimeter network. So the question becomes, in the case of an Exchange 2003 architecture, do we still need to deploy perimeter components? The short answer is Yes. Assuming Internet traffic is part of the infrastructure requirements, you should still take steps to screen your internal network from direct Internet mail connectivity.

In order to accomplish this screening, many administrators choose to deploy SMTP appliances, such as Cisco's Ironport (www.ironport.com), CipherTrust's Ironmail (www.ciphertrust.com/products/ironmail), or Symantec's Brightmail Traffic Shaper appliance (www.symantec.com/business/brightmail-traffic-shaper). These devices are built to handle SMTP traffic to/from the Internet and will typically have many built-in defense mechanisms that allow the system to cope with a wide range of attacks, as well as manage spam influx efficiently. Even in situations where Exchange 2007 is the e-mail product of choice, often times the administrator will make the decision not to use the Exchange Edge role as their Internet facing SMTP server and instead choose to deploy an SMTP appliance.

Regardless of which messaging product is selected, it is critical to implement this first line of defense. Whichever device is deployed as the Internet facing SMTP service for the environment, it is important to deploy it as securely as possible, including protection against viruses, Trojans, worms, and spam. SMTP Auth attacks can be defended against by ensuring not to utilize authenticated connections into the SMTP server, while mail relay attempts can be deterred by properly configuring the system not to allow it. If mail relay is a requirement, then IP address–based filtering is an additional protective measure that can be deployed. IP address filtering adds administrative overhead, but allows the administrator to narrow the scope of which machines are able to submit an e-mail message for routing.

Note

In recent years, a group of partners, including Microsoft, have been focusing on making it possible to attempt to predict the legitimacy of a mail message based on its originating source. They have come together to create a resource referred to as the Sender ID Framework. This Sender ID Framework is used to validate if the source messaging server is an authorized transmitter for the domain namespace by checking DNS for valid SPF records.

Spoofing is one of the most difficult attacks to identify and combat; however, the source IP address in a mail message is one of few items that attackers cannot manipulate. In order to obtain connectivity to the Internet, they must play by the rules of transfer control protocol (TCP)/IP, which does not allow them to manipulate the source IP address. This allows the usage of the source address as a means to verify authenticity. Some vendors have chosen to use the predictable source IP in order to track trends over time. By analyzing the sending habits of different public IP addresses and storing the data in a centrally accessible database, the vendor's customers are able to configure their devices to make a determination as to whether a source IP address should be trusted, or if it is a prime candidate to expect spam from.

Defense on the Internal Network

The thought in many administrative groups within an organization is that as long as the environment is protected from attacks that exist outside the walls of the internal architecture, there is little need to protect against what may originate from within. In reality, each component along the interconnected pieces of the mail flow architecture can create a weak point.

As we will discuss in the following sections, it is just as important to defend on the internal network as it is in the perimeter network.

Supporting Services

Remember that Exchange services depend on infrastructure services such as AD and DNS in order to function properly. Even though we will not discuss in detail on how to protect against attack in these components, it is critical to understand that they should be deployed in a secured configuration and monitored as well. For additional information on how to defend AD and DNS against unwanted attacks, please refer to Chapter 2, “Active Directory – Escalation of Privilege.”

If a company wants to engage in public Internet-based e-mail traffic, which originates from their own namespace being hosted on premise, then when they are building their infrastructure they must account for a public Internet facing SMTP service. Internet facing SMTP services are responsible for sending/receiving e-mail messages to and from other mail servers on the Internet, which makes them targets for many of the different mail service attacks.

Flat versus Hierarchical

The NetBIOS construction is a flat naming system. This means that only one computer can have a particular name, which must be unique on that network (or on any network to which that network is attached). Examples of a flat naming structure are SERVER1, SERVER2, and SERVER3. Under such a flat system, if Company A, connected to the Internet, had a server called SERVER1, then no other company connected to the Internet could have a server called SERVER1 or data packets would not be properly delivered to either computer. Clearly, this becomes a constraint very quickly, especially because all companies cannot possibly check with one another before naming a computer and bringing it online.

The hierarchical system, used by DNS, is a more flexible system that still guarantees a unique name. In this framework, the naming system is called the domain namespace and is structured similarly to a directory tree on a disk drive. In this system, the domain namespace begins at the root, which is unnamed and is identified by “.” As it expands, there are more and more branches to the tree and each node creates a unique name. An organization can choose to create a private domain namespace and it does not have to be unique as long as it does not interact with public networks such as the Internet.

Naming Conventions

If you’re like most people, the first time you encounter some of the naming conventions in the computer world you can become quite confused. It seems there are names for everything but none of the names are quite the same. Let’s take a moment to go through some of these to help answer any questions you might have.

Computer name A computer name is just that, the name you give your computer. In many companies this name is assigned, although in some companies users can choose their computers’ names. On a Windows XP/2000/Server 2003 computer, you can find your computer’s name by right-clicking on My Computer and selecting Properties. (Alternately, you can select System from Control Panel to access the System Properties dialog box.)Then click the Computer Name tab to display (or change) your computer name. If you’re on a network, this name must be unique. If you’re not on a network, this name can be just about anything you choose. You can configure alternate names on the Computer Name tab by clicking More and entering your particular data. However, changing this information on a computer already connected to the network can cause the computer to lose connectivity due to naming conflicts. Most companies use a naming scheme to ensure all computer names are unique.

NetBIOS name In a Windows-based computer, the name you see listed on the Computer Name tab of the My Computer properties is the NetBIOS name. This name can be up to 15 characters long (in Microsoft operating systems) and is used to identify the computer on the network. When NetBIOS name resolution occurs, the computer name (NetBIOS name) is mapped to an IP address.

Host name This term originates in the mainframe and UNIX world. It was originally used in the same way a computer name is used in Windows. Technically, a host is any device with an IP address that is not a router and that is attached to the network. Host names are used in DNS and are resolved to IP addresses. Although host names are resolved to IP addresses as are NetBIOS names, the resolution process is different—do not confuse these two types of names. NetBIOS names must be resolved via an LMHOSTS file or via a NetBIOS name server, which in Windows is implemented as Windows Internet Naming System or WINS. Host names must be resolved via host name resolution, which is accomplished via a HOSTS file or via DNS servers, requesters, and resolvers (you’ll learn more about this later in this chapter).

A host name can be up to 255 characters long and can contain alphanumeric characters and the hyphen symbol (-).A period is used as the delimiter between segments in a DNS name, so it cannot be part of the name. Blank and space characters are not permitted. The first character, until recently, had to be an alpha character. That limitation has been removed and names can now begin with an alpha or numeric character. The last character cannot be a hyphen (-) or period (.). Case is not relevant, thus there is no difference between the names SERVER, SERver, and server.

Note

Some Microsoft documentation incorrectly states that the dot (.) character can be used in host names. This is incorrect and will result in errors. The dot character is interpreted as a delimiter and can be used in Fully Qualified Domain Names (FQDN). For more information, see Microsoft Knowledge Base article 122900.

By default, a computer’s host name is set to the computer name (also known as the NetBIOS name), but a different host name can be assigned to the computer. To see the computer’s host name, you can use the command line by choosing Start | Run and typing cmd. In the command prompt window, type hostname, then press Enter. The computer’s host name is displayed. To compare it to the computer’s NetBIOS name, use the command line again and type net name and press Enter. The computer’s NetBIOS name is displayed (along with the logged on user’s account name). To close the command prompt window, type exit and press Enter. Type the word exit to close the command prompt session.

DNS name A DNS name can be a series of labels, each separated by a dot (.) to distinguish branches or nodes of the name within a hierarchy. An example of a DNS name is rosie.security.az.somecompany.com.When displayed in this manner, the name is called a Fully Qualified Domain Name (FQDN) because the entire path is shown. The left-most segment of a DNS name is the specific host name of the device; the remaining segments are the domain name (left to right from lowest to highest level domain).

Nickname A nickname is an alternate name given a host name. It is often a shorter version of the FQDN. For instance, the computer named rosie.security.az.somecompany.com might also be called rosie1. As long as this nickname is unique on that node, the nickname can be used to map to the FQDN, which is then used to map to the IP address. In this case, rosie is the actual host name and rosie1 is the nickname. However, if another host is named rosie, it cannot also be called rosie1. Another host can be named rosie if it is on a different node, however. For instance, rosie.security.fl.somecompany.com is not the same name because it follows a different path. However, it cannot use the nickname rosie1. But it can use the nickname rosie2.You’ll learn more on this topic throughout this chapter.

Alias An alias is a any name used in place of another name. In DNS, an alias is called the Canonical Name (CNAME).A server named server1.somecompany.com might have an alias of dc1.somecompany.net, for example. You’ll learn more about this later in this chapter, and we’ll discuss how and why aliases are used.

NetBIOS Name Resolution Review

It is important to understand how NetBIOS names are resolved to IP addresses in order to understand the similarities and differences between NetBIOS and DNS naming conventions. We’ll review NetBIOS name resolution briefly here.

A NetBIOS name can be 16 characters long, but in Windows, the sixteenth character is reserved for various NetBIOS functions. If a name is not 15 characters long, it is padded with spaces (in binary format, with 0 s) so that all names are always 15 characters plus the sixteenth function character. The sixteenth character is used by Microsoft networking to define functions installed on the named device, such as Workstation Service, File Server Service, Master Browser Service, and so on. Several of the more common NetBIOS suffixes are shown here. The name type is shown with the hexadecimal (hex or h) suffix. They’re shown in hex format because some of the characters are not printable.

Note

For more information on how Microsoft uses the sixteenth character of the NetBIOS name to define various functions, see Microsoft Knowledge Base article 163409. Additional related articles are 119495 and 154608.

A NetBIOS name is either a unique name (belongs exclusively to one device) or a group name (belongs to a group and is nonexclusive).When a NetBIOS process needs to communicate across the network, it does so by specifying a unique name. When it needs to communicate with multiple processes on multiple computers, it does so using the group name.

A NetBIOS name must be resolved to an IP address on a network using TCP/IP in order for communications to occur. Thus, there must be a mechanism that translates or resolves the NetBIOS name to a specific IP address. This can be accomplished in several ways, but one that is commonly used in Windows is the NetBIOS over TCP (NetBT) interface at the session layer. NetBT either will send a broadcast containing a NetBIOS name query across the network or it will send a NetBIOS name query to a specific NetBIOS Name Server. In Windows, this function is provided (with a few proprietary modifications) by WINS. The process of resolving a NetBIOS name specified by an application using the NetBIOS API, then, is to broadcast or query for name-to-IP resolution. Prior to the implementation of WINS, NetBIOS name resolution was also accomplished using a file called the LMHOSTS file. Like the HOSTS file for host names, the LMHOSTS file is a flat text file that contains the mappings of specific NetBIOS names to IP addresses. LM stands for LAN Manager, which was the name used by IBM for networking functions in early PCs. LMHOSTS files can still be used for NetBIOS name resolution, though that function is most often handled by the WINS service on the Microsoft platform.

NetBIOS and Winsock Interface Name Resolution

The two most common ways applications running on a Windows-based platform can access the TCP/IP stack and communicate across a network are using the NetBIOS programming interface and the Windows Sockets programming interface. Both are application programming interfaces (APIs), providing a set of functions and commands that can be used by software developers when writing programs that need to perform network functions. The NetBIOS API provides applications written to the NetBIOS interface access to other computers across a network via the computer name (also called the NetBIOS name). It requires a session layer interface to access the TCP/IP protocol stack. This is accomplished via NetBIOS over TCP, also known as NetBT. NetBIOS provides name management, name resolution, delivery of datagrams (via UDP), and delivery of NetBIOS messages (via TCP).

By contrast, the Windows Sockets interface (Winsock) is another way Windows-based applications can communicate across the network. It allows applications written to the Winsock API to connect to remote computers via the IP address (in this case, it’s called a destination socket, which contains the IP address), not the computer name. Thus, the Winsock API is independent from any specific naming convention since it reties solely on the IP address.

Test Day Tip

An application will be designed to run using either the NetBIOS interface via NetBIOS over TCP or the Windows Sockets interface, which runs directly over TCP.

Default Trusts

When the Active Directory Installation Wizard is used to create a new domain within an existing forest, two default trusts are created: a parent and child trust, and the tree-root trust. Four additional types of trusts can be created using the New Trust Wizard or the command-line utility netdom. The default trust relationships inside a Windows 2000, Windows Server 2003, and Windows Server 2008 forest are transitive, two-way trusts.

A parent and child trust is a transitive, two-way trust relationship. It allows authentication requests made in the child domain to be validated in the parent domain. Because the trusts are transitive, these requests pass upward from child to parent until they reach the root of the domain namespace. This relationship will allow any user in the domain to have access to any resource in the domain if the user has the proper permissions granted.

An additional transitive, two-way trust is created to simplify the navigation: the tree-root trust. This is especially needed in large organizations that might have multiple levels of child domains. The tree-root trust is a trust that is created between any child domain and the root domain. This provides a shortcut to the root. This trust relationship is also automatically created when a new domain is created.

Forest Trusts

A forest trust can only be created between the root domains in two forests. Both forests must be Windows Server 2003 or Windows Server 2008 forests. These trusts can be one- or two-way trusts. They are considered transitive trusts because the child domains inside the forest can authenticate themselves across the forest to access resources in the other forest.

Warning

Although the trust relationship is considered transitive, this applies only to the child domains within forests. The transitive nature of the trust exists only within the two forests explicitly joined by a forest trust. The transitivity does not extend to a third forest unless you create another explicit trust (see Figure 2.27).

Forest trusts help to manage the Active Directory infrastructure. They do this by simplifying the management of resources between two forests by reducing the required number of external trusts. Instead of needing multiple external trusts, a two-way forest trust between the two root domains will allow full access between all the affected domains. Additionally, the administrator can take advantage of both the Kerberos and NTLM authentication protocols to transfer authorization data between forests.

Forest trusts can provide complete two-way trusts with every domain within the two forests. This is useful if you have created multiple forests to secure data within the forest or to help isolate directory replication within each forest.

External Trusts

You use an external trust when you need to create a trust between domains outside of your forest. These trusts can be one- or two-way trusts. They are always nontransitive in nature. This means you have created an explicit trust between the two domains, and domains outside this trust are not affected. You can create an external trust to access resources in a domain in a different forest that is not already covered by a forest trust (see Figure 2.28).

After the trust has been established between a domain in a forest and a domain outside the forest, the security principals from the domain outside the forests will be able to access the resources in the domain inside the forest. Security principals can be the users, groups, computers, or services from the external domain. They are account holders that are each assigned a SID automatically to control access to the resources in the domain.

The Active Directory in the domain inside the forest will then create foreign security principal objects representing each security principal from the trusted external domain. You can use these foreign security principals in the domain local groups. This means that the domain local groups can have members from the trusted external domain. You use these groups to control access to the resources of the domain.

The foreign security principals are seen in Active Directory Users and Computers. Because the Active Directory automatically creates them, you should not attempt to modify them.

Shortcut Trusts

Shortcut trusts are transitive in nature and can be either one-way or two-way. These are explicit trusts that you create when the need exists to optimize (“shortcut”) the authentication process. Without shortcut trusts in place, authentication travels up and down the domain tree using the default parent and child trusts, or by using the tree-root trusts. In large, complex organizations that use multiple trees, this path can become a bottleneck when authenticating users. To optimize access, the network administrator can create an explicit shortcut trust directly to the target domain (see Figure 2.29).

You use these trusts when user accounts in one domain need regular access to the resources in another domain. Shortcut trusts can be either one- or two-way. You should establish one-way shortcut trusts when the users in one domain need access to resources in the other domain, but those in the second domain do not need access to resources in the first domain. You should create two-way trusts when the users in both domains need access to the resources in the other domain. The shortcut trust will effectively shorten the authentication path, especially if the domains belong to two separate trees in the forest.

SID Filtering

One security concern when using trusts is a malicious user who has administrative credentials in the trusted domain sniffing the trusting domain to obtain the credentials of an administrator account. With the credentials of the trusting domain administrator, the malicious user could add his SID to allow full access to the trusting domain's resources. This type of threat is called an elevation of privilege attack

The security mechanism used by Windows Server 2003 and Windows Server 2008 to counter an elevation of privilege attack is SID filtering. SID filtering is used to verify that an authentication request coming in from the trusted domain only contains the domain SIDs of the trusted domain. It does this by using the SIDHistory attribute on a security principal.

SID filtering uses the domain SID to verify each security principal. If a security principal includes a domain SID other than one from trusted domains, the SID filtering process removes the SID in question. This is done to protect the integrity of the trusting domain. This will prevent the malicious user from being able to elevate his or her privileges or those of other users.

There are some potential problems associated with SID filtering. It is possible for a user whose SID contains SID information from a domain that is not trusted to be denied access to the resources in the trusting domain. This is can be a problem when universal groups are used. Universal groups should be verified to contain only users that belong to the trusted domain.

You can disable SID filtering if there is a high level of trust for all administrators in the affected domains, there are strict requirements to verify all universal group memberships, and any migrated users have their SIDHistories preserved. To disable SID filtering, use the netdom command.

Relative ID Master

The relative ID master is responsible for allocating sequences of numbers (called relative IDs, or RIDs) that are used in creating new security principles in the domain. Security principles are user, group, and computer accounts. These numbers are issued to all domain controllers in the domain. When an object is created, a number that uniquely identifies the object is assigned to it. This number consists of two parts: a domain security ID (or computer SID if a local user or group account is being created) and an RID. Together, the domain SID and RID combine to form the object’s unique SID. The domain security ID is the same for all objects in that domain. The RID is unique to each object. Instead of using the name of a user, computer, or group, Windows uses the SID to identify and reference security principles. To avoid potential conflicts of domain controllers issuing the same number to an object, only one RID master exists in a domain. This controls the allocation of RID numbers to each domain controller. The domain controller can then assign the RIDs to objects when they are created.

PDC Emulator

The primary domain Controller (PDC) emulator is designed to act like a Windows NT PDC when the domain is in Windows 2000 mixed mode. This is necessary if Windows NT backup domain controllers (BDCs) still exist on the network. Clients earlier than Windows 2000 also use the PDC emulator for processing password changes, though installation of the AD client software on these systems enables them to change their password on any domain controller in the domain to which they authenticate. The PDC emulator also synchronizes the time on all domain controllers the domain. For replication accuracy, it is critical for all domain controllers to have synchronized time.

Even if you do not have any servers running as BDCs on the network, the PDC emulator still serves a critical purpose in each domain. The PDC emulator receives preferred replication of all password changes performed on other domain controllers within the domain. When a password is changed on a domain controller, it is sent to the PDC emulator. If a user changes his or her password on one domain controller, and then attempts to log on to another, the second domain controller may still have old password information. Because this domain controller considers it a bad password, it forwards the authentication request to the PDC emulator to determine whether the password is actually valid. In addition, the PDC emulator initiates urgent replication so that the password change can propagate as soon as possible. Urgent replication is also used for other security-sensitive replication traffic, such as account lockouts.

This operations master is by far the most critical at the domain level. Because of this, you should ensure that it is carefully placed on your network and housed on a high-availability, high-capacity server.

Infrastructure Master

The infrastructure master is in charge of updating changes that are made to group memberships. When a user moves to a different domain and his or her group membership changes, it may take time for these changes to be reflected in the group. To remedy this, the infrastructure master is used to update such changes in its domain. The domain controller in the infrastructure master role compares its data to the Global Catalog, which is a subset of directory information for all domains in the forest and contains information on groups. The Global Catalog stores information on universal group memberships, in which users from any domain can be added and allowed access to any domain, and maps the memberships users have to specific groups. When changes occur to group membership, the infrastructure master updates its group-to-user references and replicates these changes to other domain controllers in the domain.

TEST DAY TIP

FSMO roles are an important part of a domain controller’s function on a network. FSMO roles that are unique to a forest affect all domains within that forest. FSMO roles that are unique to a domain apply only to that domain. There is only one schema master and one domain naming master in a forest. There is only one RID master, PDC emulator, and infrastructure master in a domain.

Default Trusts

When the Active Directory Installation Wizard is used to create a new domain within an existing forest, two default trusts are created: a parent and child trust, and the tree-root trust. Four additional types of trusts can be created using the New Trust Wizard or the command-line utility netdom. The default trust relationships inside a Windows 2000 and Windows Server 2003 forest are transitive, two-way trusts.

A parent and child trust is a transitive, two-way trust relationship. It allows authentication requests made in the child domain to be validated in the parent domain. Because the trusts are transitive, these requests pass upwards from child to parent until they reach the root of the domain namespace. This relationship will allow any user in the domain to have access to any resource in the domain if the user has the proper permissions granted.

An additional transitive, two-way trust is created to simplify the navigation, the tree-root trust. This is especially needed in large organizations that might have multiple levels of child domains. The tree-root trust is a trust that is created between any child domain and the root domain. This provides a shortcut to the root. This trust relationship is also automatically created when a new domain tree is created.

Shortcut Trust

Shortcut trusts are transitive in nature and can either be one-way or two-way. These are explicit trusts that you create when the need exists to optimize (“shortcut”) the authentication process. Without shortcut trusts in place, authentication travels up and down the domain tree using the default parent and child trusts, or by using the tree-root trusts. In large complex organizations that use multiple trees, this path can become a bottleneck when authenticating users. To optimize access, the network administrator can create an explicit shortcut trust directly to the target domain (see Figure 5.5).

These trusts are used when user accounts in one domain need regular access to the resources in another domain. Shortcut trusts can be either one- or two-way.

One way shortcut trusts should be established when the users in one domain need access to resources in the other domain, but those in the second domain do not need access to resources in the first domain.

Two-way trusts should be created when the users in both domains need access to the resources in the other domain. The shortcut trust will effectively shorten the authentication path, especially if the domains belong to two separate trees in the forest.

Realm Trust

Realm trusts are explicit trusts that are created to join a Windows Server 2003 domain to a non-Windows Kerberos v5 realm. This allows you the flexibility of creating a trust for your non-Windows networks to interoperate with the security services based on other Kerberos v5 implementations, such as with UNIX. This extension of security can be switched from one-way or two-way trusts and from transitive to non-transitive.

External Trust

An external trust is used when you need to create a trust between domains outside of your forest. These trusts can be one- or two-way trusts. They are always non-transitive in nature. This means that you have created an explicit trust between the two domains, and domains outside this trust are not affected. You can create an external trust to access resources in a domain in a different forest that is not already covered by a forest trust (see Figure 5.6).

Exam Warning

You will always need to create an external trust when connecting to a Windows NT 4.0 or earlier domain. These domains are not eligible to participate in Active Directory. These trusts must be one-way trusts. If you have worked with Windows NT 4.0, you will remember that the only trusts allowed were non-transitive one-way trusts.

After the trust has been established between a domain in a forest and a domain outside the forest, the security principals from the domain outside the forests will be able to access the resources in the domain inside the forest. Security principals can be the users, groups, computers, or services from the external domain. They are account holders that are each assigned a security identifier (SID) automatically to control access to the resources in the domain.

The Active Directory in the domain inside the forest will then create foreign security principal objects representing each security principal from the trusted external domain. You can use these foreign security principals in the domain local groups. This means that the domain local groups can have members from the trusted external domain. You use these groups to control access to the resources of the domain.

The foreign security principals are seen in Active Directory Users and Computers. Since the Active Directory automatically creates them, you should not attempt to modify them.

Forest Trust

A forest trust can only be created between the root domains in two forests. Both forests must be Windows Server 2003 forests. These trusts can be one- or two-way trusts. They are considered transitive trusts because the child domains inside the forest can authenticate themselves across the forest to access resources in the other forest.

Exam Warning

Although the trust relationship is considered transitive, this only applies to the child domains within forests. The transitive nature of the trust exists only within the two forests explicitly joined by a forest trust. The transitivity does not extend to a third forest unless you create another explicit trust (see Figure 5.4).

Forest trusts help manage the Active Directory infrastructure. They do this by simplifying the management of resources between two forests by reducing the required number of external trusts. Instead of needing multiple external trusts, a two-way forest trust between the two root domains will allow full access between all the affected domains. Additionally, the administrator can take advantage of both the Kerberos and NTLM authentication protocols to transfer authorization data between forests.

Forest trusts can provide complete two-way trusts with every domain within the two forests. This is useful if you have created multiple forests to secure data within the forest or to help isolate directory replication within each forest.