Chapter 6. Understanding Authentication and Trusts
Authentication and trusts are integral parts of Active Directory. Before you implement any Active Directory design or try to modify existing Active Directory infrastructure, you should have a firm understanding of how both authentication and trusts work in an Active Directory environment.
When a user logs on to a domain, Active Directory looks up information about the groups of which the user is a member to generate a security token for the user. The security token is needed as part of the normal authentication process and is used whenever a user accesses resources on the network.
To generate the security token, Active Directory checks the domain local and global group memberships for the user. All the supported domain functional levels support a special type of group called a universal group. Universal groups can contain user and group accounts from any domain in the forest. Because global catalog servers are the only servers in a domain with forestwide domain data, the global catalog is essential for logon.
Because of problems authenticating users when global catalog servers are not available, Windows Server can be configured to cache universal group membership. Once enabled, the cache is where domain controllers store universal group membership information that they have previously looked up. Domain controllers can then use this cache for authentication the next time the user logs on to the domain. The cache is maintained indefinitely and updated periodically to ensure that it’s current. By default, domain controllers check the consistency of the cache every eight hours.
Thanks to universal group membership caching, remote sites don’t necessarily have to have global catalog servers configured as well. This gives you additional options when configuring the Active Directory forest.
The assignment of security tokens is only part of the logon process. The logon process also includes authentication and the assignment of a User Principal Name (UPN) to the user.
Every user account has a User Principal Name (UPN), which consists of the User Logon Name combined with the at symbol (@) and a UPN suffix. The names of the current domain and the root domain are set as the default UPN suffix. You can specify an alternate UPN suffix to use to simplify logon or provide additional logon security.
The UPN suffix is used only within the forest and does not have to be a valid DNS name. For example, if the UPN suffix for a domain is it.seattle.imaginedlands.local, you could use an alternate UPN suffix to simplify this to imaginedlands.local. This would allow the user Williams to log on using williams@imaginedlands.local rather than williams@it.seattle.imaginedlands.local.
You can add or remove UPN suffixes for an Active Directory forest and all domains within that forest by completing the following steps:
120. Start Active Directory Domains And Trusts from the Administrative Tools menu.
121. Right-click the Active Directory Domains And Trusts node, and then click Properties.
122. To add a UPN suffix, in the box provided type the alternate suffix and then click Add.
123. To remove a UPN suffix, in the list provided click the suffix to remove and then click Remove.
124. Click OK.
In a domain with domain controllers, you use the Active Directory Sites And Services tool to configure universal group membership caching. You enable caching on a per-site basis. Start Active Directory Sites And Services by choosing the related option from the Tools menu in Server Manager. Expand and then select the site in which you want to enable universal group membership caching.
In the right pane, right-click NTDS Site Settings and then select Properties. This displays the NTDS Site Settings Properties dialog box.
To enable universal group membership caching for the site, select the Enable Universal Group Membership Caching check box and continue as follows:
When you are finished configuring universal group membership caching, click OK.
Windows operating systems use either NT LAN Manager (NTLM) or Kerberos for authentication. However, in the default configuration when the domain or forest are operating at Windows Server 2012 R2 functional level or higher, NTLM authentication is disabled by default and only Kerberos authentication is enabled. Although allowing only Kerberos for authentication is certainly substantially more secure, some older applications require NTLM for authentication and won’t work properly if NTLM authentication is disabled. To resolve this problem, you would need to enable NTLM for authentication.
With NTLM, an encrypted challenge/response is used to authenticate a user without sending the user’s password over the network. The system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials. It does this by sending a one-way hash of the user’s password that can be verified.
NTLM authentication has interactive and noninteractive authentication processes. Interactive NTLM authentication over a network typically involves a client system from which a user is requesting authentication and a domain controller on which the user’s password is stored. As the user accesses other resources on the network, noninteractive authentication might take place as well to permit an already logged-on user to access network resources. Typically, noninteractive authentication involves a client, a server, and a domain controller that manages the authentication.
To see how NTLM authentication works, consider the situation that arises when a user tries to access a resource on the network and the user is prompted for a user name and password. Assuming the resource is on a server that is not also a domain controller, the authentication process is similar to the following:
125. When prompted, the user provides a domain name, user name, and password. The client computer generates a cryptographic hash of the user’s password, discards the actual password, and then sends the user name to the server as unencrypted text.
126. The server generates a 16-byte random number, called a challenge, and sends it to the client.
127. The client encrypts the challenge with the hash of the user’s password and returns the result, called a response, to the server. The server then sends the domain controller the user name, the challenge sent to the client, and the response from the client.
128. The domain controller uses the user name to retrieve the hash of the user’s password from the Security Accounts Manager (SAM) database. The domain controller uses this password hash to encrypt the challenge and then compares the encrypted challenge it computed to the response computed by the client. If they are identical, the authentication is successful.
Active Directory uses Kerberos as the default authentication protocol, and NTLM authentication is maintained only for backward compatibility with legacy clients. Whenever a current client tries to authenticate with Active Directory, the client tries to use Kerberos.
Kerberos has a number of advantages over NTLM authentication, including the use of mutual authentication. Mutual authentication in Kerberos allows for two-way authentication so that not only can a server authenticate a client, but also a client can authenticate a server. Thus, mutual authentication ensures that not only is an authorized client trying to access the network but also that an authorized server is the one responding to the client request.
Kerberos uses the following three main components:
In order to act as KDCs, all domain controllers run the Kerberos Key Distribution Center service. With Kerberos authentication, a user password is never sent over the network. Instead, Kerberos authentication uses a shared-secret authentication model. In most cases the client and the server use the user’s password as the shared secret. With this technique, authentication works as shown in the next figure.
The details of the initial authentication of a user in the domain are as follows:
129. When a user logs on to the network, the client sends the KDC server a message containing the user name, the domain name, and a request for access to the network. In the message is a packet of information that has been encrypted using the shared-secret information (the user’s password), which includes a time stamp.
130. When the KDC server receives the message, the server reads the user name and then checks the directory database for its copy of the shared-secret information (the user’s password). The KDC server then decrypts the secret part of the message and checks the message time stamp. As long as the message time stamp is within five minutes of the current time on the server, the server can authenticate the user. If the decryption fails or the message time stamp is more than five minutes off the current time, the authentication fails. Five minutes is the default value; the allowable time difference can be configured through domain security policy using the Kerberos policy Maximum Tolerance For Computer Clock Synchronization.
131. After the user is authenticated, the KDC server sends the client a message that is encrypted with the shared-secret information (the user’s password). The message includes a session key that the client will use when communicating with the KDC server from now on and a session ticket that grants the user access to the domain controller. The ticket is encrypted with the KDC server’s key, which makes it valid only for that domain controller.
132. When the client receives the message, the client decrypts the message and checks the message time stamp. As long as the message time stamp is within five minutes of the current time on the server, the client can then authenticate the server and assume that the server is valid. The client then caches the session key so that it can be used for all future connections with the KDC server. The session key is valid until it expires or the user logs off. The session ticket is cached as well, but it isn’t decrypted.
After initial authentication, the user is granted access to the domain. The only resource to which the user has been granted access is the domain controller. When the user wants to access another resource on the network, the client must request access through the KDC. An overview of the process for authenticating access to network resources is shown in the figure that follows.
The details of an access request for a network resource are as follows:
133. When a user tries to access a resource on the network, the client sends the KDC server a session ticket request. The message contains the user’s name, the session ticket the client was previously granted, the name of the network resource the client is trying to access, and a time stamp that is encrypted with the session key.
134. When the KDC server receives the message, the server decrypts the session ticket using its key. It then extracts the original session key from the session ticket and uses it to decrypt the time stamp, which is then validated. The validation process is designed to ensure that the client is using the correct session key and that the time stamp is valid.
135. If all is acceptable, the KDC server sends a session ticket to the client. The session ticket includes two copies of a session key that the client will use to access the requested resource. The first copy of the session key is encrypted using the client’s session key. The second copy of the session key contains the user’s access information and is encrypted with the resource’s secret key, which is known only by the KDC server and the network resource.
136. The client caches the session ticket and then sends the session ticket to the network resource to gain access. This request also contains an encrypted time stamp.
137. The network resource decrypts the second session key in the session ticket, using the secret key it shares with the KDC server. If this is successful, the network resource has validated that the session ticket came from a trusted KDC. It then decrypts the user’s access information, using the session key, and checks the user’s access permissions. The time stamp sent from the client is also decrypted and validated by the network resource.
138. If the authentication and authorization are successful (meaning that the client has the appropriate access permissions), the user is granted the type of access to the network resource that the particular permissions allow. The next time the user needs to access the resource, the session ticket in cache is used—as long as it hasn’t expired. Using a cached session ticket allows the client to send a request directly to the network resource. If the ticket has expired, however, the client must start over and get a new ticket.
Active Directory uses Kerberos security for server-to-server authentication and the establishment of trusts, while allowing legacy clients and servers on the network to use NTLM if necessary. The next figure shows a one-way trust in which one domain is the trusted domain and the other domain is the trusting domain. Typically, you implement one-way trusts when you have separate account and resource domains. The establishment of the trust allows users in the account domain to access resources in the resource domain.
With Active Directory, trusts are automatically configured between all the domains in a forest and are implemented as two-way, transitive trusts. As a result, if the domains in the previous example are domains in the same forest, users in domain A can automatically access resources in domain B and users in domain B can automatically access resources in domain A. Because the trusts are automatically established between all domains in the forest, no setup is involved and there are many more design options for implementing Active Directory domains.
As trusts join parent and child domains in the same domain tree and join the roots of domain trees, the structure of trusts in a forest can be referred to as a trust tree. When a user tries to access a resource in another domain, the trust tree is used and the user’s request has to pass through one domain controller for each domain between the user and the resource. This type of authentication takes place across domain boundaries. Authentication across domain boundaries also applies when a user with an account in one domain visits another domain in the forest and tries to log on to the network from that domain.
Consider the example shown next. If a user from domain G visits domain K and tries to log on to the network, the user’s computer must be able to connect to a domain controller in domain K. Here, the user’s computer sends the initial logon request to the domain K domain controller. When the domain controller receives the logon request, it determines that the user is located in domain G. The domain controller refers the request to a domain controller in the next domain in its trust tree, which in this case is domain J. A domain controller in domain J refers the request to domain I. A domain controller in domain I refers the request to domain H. This process continues through domains A, E, and F until the request finally gets to domain G.
You can avoid this rather lengthy referral process if you establish an explicit trust between domain G and domain K. Technically, explicit trusts are one-way transitive trusts, but you can establish a two-way explicit trust by creating two one-way trusts. Thus, unlike standard trusts within the trust tree, which are inherently two-way and transitive, explicit trusts can be made to be two-way if desired. Because they can be used to establish authentication shortcuts between domains, explicit trusts are also referred to as shortcut trusts. In this example it was decided to create two one-way trusts: one from domain G to domain K and one from domain K to domain G. With these shortcut trusts in place, users in domain G could visit domain K and be rapidly authenticated and users in domain K could visit domain G and be rapidly authenticated.
If you examine the figure closely, you’ll see that several other shortcut trusts were added to the forest as well. Shortcut trusts were established between B and E and between E and I. Establishing the shortcut trusts in both directions allows for easy access to resources and rapid authentication in several combinations, such as the following:
The trusts work similarly for users in domain E. Users in domain E have direct access to both domain B and domain I. Imagine that domain B is sales.tvpress.com, domain E is mf.tvpress.com, and domain I is cs.imaginedlands.com, and you might be able to better picture how the shortcut trusts allow users to cut across trees in the Active Directory forest. I hope that you can also imagine how much planning should go into deciding your domain structure, especially when it comes to access to resources and authentication.
You can establish authentication and trusts across forest boundaries as well. One-way external trusts, such as the one depicted in the next figure, are nontransitive. This means that if, as in the example, a trust is established between domain H and domain L only, a user in any domain in forest 1 could access a resource in domain L but not in any other domain in forest 2. The reason for this limitation is that the trust doesn’t continue past domain L and it does not matter that a two-way transitive trust does exist between domain L and domain M or that a two-way trust also exists between domain L and domain O.
Windows Server supports cross-forest transitive trusts, also referred to simply as forest trusts. With this type of trust, you can establish a one-way or two-way transitive trust between forests to share resources and to authenticate users. With a two-way trust, you enable cross-forest authentication and cross-forest authorization.
As discussed earlier in this chapter in the section entitled “Navigating Authentication Options,” Kerberos is the default authentication protocol but NTLM can also be used (when permitted and enabled). This allows current clients and servers as well as older clients and servers to be authenticated. After you establish a two-way cross-forest trust, users get all the benefits of Active Directory regardless of where they sign on to the network. With cross-forest authentication, you ensure secure access to resources when the user account is in one forest and the computer account is in another forest and when the user in one forest needs access to network resources in another trusted forest. As part of cross-forest authorization, administrators can select users and global groups from trusted forests for inclusion in local groups. This ensures the integrity of the forest security boundary while allowing trust between forests.
When you connect two or more forests using cross-forest trusts, the implementation is referred to as a federated forest design. The federated forest design is most useful when you need to join two separate Active Directory structures—for example, when two companies merge, when one company acquires another, or when an organization has a major restructuring. Consider the case in which two companies merge and, rather than migrate their separate Active Directory structures into a single directory tree, the staff decides to link the two forests using cross-forest trusts. As long as the trusts are two-way, users in forest 1 can access resources in forest 2 and users in forest 2 can access resources in forest 1.
Having separate forests with cross-forest trusts between them is also useful when you want a division or group within the organization to have more autonomy but still have a link to the other divisions or groups. For example, if you are setting up a division that you intend to spin off once it is up and running, you likely will want that division to be in a separate forest with cross-forest trusts between your primary forest and the new forest.
By placing the division or group in a separate forest, you ensure strict security and give that division or group ownership of the Active Directory structure. If users in the forest were to need access to resources in another forest, you could establish a one-way cross-forest trust between the forests. This would allow users in the secured forest to gain access to resources in the second forest, but it would not allow users in the second forest to gain access to the secure forest.
Organizations that contain groups or divisions with high security requirements could use this approach. For example, consider the next figure.
In this situation the users in the organization’s Engineering department need access to resources in other departments, but for security reasons they should be isolated from the rest of the organization. Here, the organization has implemented two forests: a main organizational forest and a separate Engineering forest. Using a one-way, cross-forest trust from the main forest to the Engineering department forest, the organization allows Engineering users to access other resources, but it ensures that the Engineering department is secure and isolated.
You can examine existing trusts using Active Directory Domains And Trusts. Start Active Directory Domains And Trusts by choosing the related option from the Tools menu in Server Manager.
To examine the existing trusts for a domain, right-click the domain entry and then select Properties. Then, in the domain’s Properties dialog box, click the Trusts tab. The Trusts tab is divided into two panels:
To view the details of a particular trust, select it and then click Properties.
The Properties dialog box contains the following information:
There are two default trust types: Tree Root and Parent And Child. When a new domain tree is added to the forest, the default trust that is established automatically is a tree-root trust. When a new domain is a subdomain of a root domain, the default trust that is established automatically is a parent and child trust. Other trust types that might appear include the following:
When setting up trusts, don’t forget about the role of DNS in the trusts. The domain controllers in the domains must have access to DNS information about the domain controllers in the other domains. This DNS information can be transferred to the domain’s DNS server as a secondary zone, or conditional forwarding can be configured.
All trusts, regardless of type, are established in the same way. For all trusts, there are two sides: an incoming trust and an outgoing trust. To configure both sides of the trust, keep the following in mind:
To establish a trust, follow these steps:
139. In Active Directory Domains And Trusts, right-click the domain for which you want to establish a one-way incoming trust, a one-way outgoing trust, or a two-way trust, and then choose Properties. For a cross-forest trust, this must be the forest root domain in one of the participating forests.
140. In the domain Properties dialog box, click the Trusts tab and then click the New Trust button. This starts the New Trust Wizard. Click Next to skip the welcome page.
141. On the Trust Name page, specify the domain name of the other domain. For a cross-forest trust, this must be the name of the forest root domain in the other forest.
142. When you click Next, the wizard tries to establish a connection to the other domain. The options on the next page depend on whether you are connecting to a Windows domain, a Windows forest, or a non-Windows forest:
If the domain is determined to be a Windows forest, you have the option of creating an external trust that is nontransitive or a forest trust that is transitive. Choose either External Trust or Forest Trust and then click Next.
If the domain is determined to be a Windows domain, it’s assumed that you are creating a shortcut trust and the wizard goes directly to the Direction Of Trust page.
If the domain is determined to be a non-Windows domain, you have the option of creating a realm trust with a Kerberos version 5 realm. Select Realm Trust and then, on the Transitivity Of Trust page, select either Nontransitive or Transitive and then click Next.
143. On the Direction Of Trust page, choose the direction of the trust and then click Next. The following options are available:
Two-Way Users in the domain initially selected and in the designated domain can access resources in either domain or realm.
One-Way: Incoming Users in the domain initially selected will be able to access resources in the designated domain. Users in the designated domain will not be able to access resources in the domain initially selected.
One-Way: Outgoing Users in the designated domain will be able to access resources in the domain initially selected. Users in the domain initially selected will not be able to access resources in the designated domain.
144. For shortcut or forest trusts, the next page you see is the Sides Of Trust page. To begin using a trust, you must create both sides of the trust. You have the option of setting the sides of the trust for This Domain Only or for Both This Domain And The Specified Domain:
If you are creating only one side of the trust, select This Domain Only and then click Next.
If you are setting both sides of the trust or the administrator from the other domain is at your desk, select Both This Domain And The Specified Domain and then click Next. When prompted, type (or let the other administrator type) the name and password of an appropriate account in the other domain or forest, and then click OK.
145. On the Trust Password page, type and then confirm the initial password you want to use for the trust. The password is arbitrary but must follow the strong security rules, meaning that it must have at least eight characters, contain a combination of uppercase and lowercase characters, and contain either numerals or special characters.
TIP The trust password you use must be the same for both the domain initially selected and the specified domain, so be sure to write down the password so that you can use it when configuring the other side of the trust. After you create the trust, Active Directory periodically updates the password, using an automatic password reset. This helps safeguard the integrity of the trust.
146. For domain or realm trusts, click Next twice to begin the trust creation process.
147. For forest trusts, you can set the outgoing trust authentication level as either Domain-Wide Authentication or Selective Authentication. With domain-wide authentication, users in the trusted domain can be authenticated to use all the resources in the trusting domain (and any trusted domains). This means that authentication is automatic for all users. With Selective Authentication, only the users or groups to which you explicitly grant permission can access resources in the trusting domain. This means that authentication is not automatic and you will need to grant individual access to each server that you want to make available to users in the trusting domain. Click Next twice.
148. After the trust is created, you are given the opportunity to verify the trust.
By default, Windows validates all incoming trusts automatically. If the credentials used to establish the trust are no longer valid, the trust fails verification. If you want to revalidate a trust by providing new credentials or to specify that incoming trusts should not be validated, follow these steps:
149. In Active Directory Domains And Trusts, right-click the trusted domain for which you want to verify the incoming trust and then select Properties.
150. In the domain’s Properties dialog box, click the Trusts tab, and then click Validate and select one of the following options:
If you want to stop validation of the incoming trust, select No, Do Not Validate The Incoming Trust.
If you want to revalidate the incoming trust, select Yes, Validate The Incoming Trust and then type the user account and password for an administrator account in the other (trusting) domain.
151. Click OK. For a two-way trust, repeat this procedure for the other (trusting) domain.
You might want to revalidate trusts or specify that incoming trusts should not be validated for the following reasons:
The delegation of authentication is often a requirement when a network service is distributed across several servers, such as when the organization uses web-based application services with front-end and back-end servers. In this environment, a client connects to the front-end servers and the user’s credentials might need to be passed to back-end servers to ensure that the user gets access only to information to which the user has been granted access.
Delegated authentication is provided through Kerberos using either proxy tickets or forwarded tickets:
You also can use constrained delegation. Constrained delegation allows you to configure accounts so that they are delegated only for specific purposes. This kind of delegation is based on service principal names, and a front-end server can access only network resources for which delegation has been granted.
Prior to Windows Server 2012, delegation only worked within the same domain and front-end servers needed to be configured with the services that were to be impersonated. Beginning with Windows Server 2012, delegation works across domains and forests and back-end servers can authorize front-end service accounts that can impersonate users against their resources. Administrators can configure back-end server accounts with the accounts that are permitted for impersonation using New-ADComputer, Set-ADComputer, New-ADServiceAccount, and set-ADServiceAccount.
The user account as well as the service or computer account acting on the user’s behalf must be configured to support delegated authentication.
For the user account, you must ensure that the account option Account Is Sensitive And Cannot Be Delegated is not selected, which by default it isn’t. If you want to check this option, use Active Directory Users And Computers. Double-click the user’s account entry in Active Directory Users And Computers and then click the Account tab. You’ll find the Account Is Sensitive And Cannot Be Delegated check box under Account Options. Scroll through the list until you find it.
For the service acting on the user’s behalf, you must first determine if the service is running under a normal user account or under a special identity, such as LocalSystem. If the service runs under a normal user account, check the account in Active Directory Users And Computers and ensure that the Account Is Sensitive And Cannot Be Delegated check box is not selected. If the service runs under a special identity, you need to configure delegation for the computer account of the front-end server.
In Active Directory Users And Computers, double-click the computer account to display its Properties dialog box, and then click the Delegation tab.
You have the following options for configuring a computer for delegation:
You must next specify the services to which the front-end server can present a client’s delegated credentials. To do this, you need to know the name of the computers running the services and the types of services you are authorizing. Click Add to display the Add Services dialog box, and then click Users Or Computers to display the Select Users Or Computers dialog box.
In the Select Users Or Computers dialog box, type the name of the computer providing the service, such as CORPSERVER99, and then click Check Names. If multiple matches are found, select the name or names you want to use and then click OK. If no matches are found, either you entered an incorrect name or you’re working with an incorrect location. Modify the name and try again, or click Locations to select a new location. To add computers, type a semicolon (;) and then repeat this process. When you click OK, the Add Services dialog box is updated with a list of available services on the selected computer or computers.
Use the Add Services dialog box to select the services for which you are authorizing delegated authentication. You can use Shift+click or Ctrl+click to select multiple services. After you select the appropriate services, click OK. The selected services are added to the Services To Which This Account Can Present Delegated Credentials list. Click OK to close the computer’s Properties dialog box and save the delegation changes.