Authentication and trusts are integral parts of Active Directory. Before you implement any Active Directory design or try to modify your 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. When a domain is operating in Windows 2000 native functional level or higher, an additional type of group is also available, called a universal group. As universal groups can contain user and group accounts from any domain in the forest, and global catalog servers are the only servers in a domain with forest-wide domain data, the global catalog is essential for logon in any domain operating at the Windows 2000 native functional level or higher.
Because of problems authenticating users when global catalog servers are not available, Windows Server 2003 introduces a technique for caching universal group membership. In a domain with domain controllers running Windows Server 2003, universal group membership caching can be enabled. Once caching is enabled, the cache is where domain controllers store universal group membership information that they have previously looked up. Domain controllers use the cache for the next time the user logs on to the domain. The cache is maintained indefinitely and updated periodically to ensure that it is current. By default, domain controllers check the consistency of the cache every eight hours.
Thanks to universal group membership caching, remote sites running Windows Server 2003 domain controllers 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.
In a domain with domain controllers running Windows Server 2003, 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 clicking Start, Programs or All Programs, Administrative Tools, and Active Directory Sites And Services. Expand the site in which you want to enable universal group membership caching, as shown in the following screen:
In the right pane, right-click NTDS Site Settings, and then select Properties. This displays the NTDS Site Settings Properties dialog box as shown in the following screen:
To enable universal group membership caching for the site, select Enable Universal Group Membership Caching and continue as follows:
If the directory has multiple sites, you can replicate existing universal group membership information from a specific site's cache by selecting the site on the Refresh Cache From List. With this option, universal group membership information doesn't need to be generated and then replicated; it is simply replicated from the other site's cache.
If the directory has only one site or you'd rather get the information from a global catalog server in the nearest site, accept the default setting <Default>. With this option, universal group membership information is generated and then replicated.
When you are finished configuring universal group membership caching, click OK.
Windows NT 4 uses a form of authentication known as NT LAN Manager (NTLM). 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 non-interactive 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, non-interactive authentication may 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 occurs when a user tries to access a resource on the network and she is prompted for her user name and password. Assuming the resource is on a server that is not also a domain controller, the authentication process would be similar to the following:
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, then sends the user name to the server as unencrypted text.
The server generates a 16-byte random number, called a challenge, and sends it to the client.
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.
The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager (SAM) database. The domain controller uses this password hash to encrypt the challenge then compares the encrypted challenge it computed to the response computed by the client. If they are identical, the authentication is successful.
Starting with Windows 2000, Active Directory uses Kerberos as the default authentication protocol, and NTLM authentication is only maintained for backward compatibility with older clients. Whenever a client running Windows 2000 or later 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 a client can also 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:
A client that needs access to resources
A server that manages access to resources and ensures that only authenticated users can gain access to resources
A Key Distribution Center (KDC) that acts as a central clearinghouse
All domain controllers run the Kerberos Key Distribution Center service to act as KDCs. 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 Figure 33-4.
The details of the initial authentication of a user in the domain are as follows:
When a user logs on to the network, the client sends the KDC server a message containing the user name, 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.
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 then 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.
Once 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.
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 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 Figure 33-5.
The details of an access request for a network resource are as follows:
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.
When the KDC server receives the message, the server decrypts the session ticket using its key. Afterward, it 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.
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 known only by the KDC server and the network resource.
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.
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.
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 older clients and servers on the network to use NTLM if necessary. Figure 33-6 shows a one-way trust in which one domain is the trusted domain and the other domain is the trusting domain. In Windows NT 4, you typically implemented one-way trusts when you had separate account and resource domains. The establishment of the trust allowed 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, 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.
Note
The physical limitation on the number of objects that necessitated having separate account and resource domains in Windows NT 4 no longer applies. Active Directory domains can have millions of objects, a fact that changes the fundamental reason for creating additional 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 in Figure 33-7. 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.
This rather lengthy referral process could be avoided if you established an explicit trust between domain G and domain K as shown in Figure 33-8. Technically, explicit trusts are one-way transitive trusts, but you can establish a two-way explicit trust by creating two oneway 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. As they can be used to establish authentication shortcuts between domains, they 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 add to the forest as well. Shortcut trusts have been 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:
Using the B to E shortcut trust, users in domain B can rapidly access resources in domain E.
Using the B to E and E to I shortcut trusts, users in domain B can also rapidly access resources in domain I.
Using the B to E shortcut trust, users in domain B can visit domain E and be rapidly authenticated.
Using the B to E and E to I shortcut trusts, users in domain B can visit domain I and be rapidly authenticated.
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.cohovineyard.com, domain E is mf.cohovineyard.com, and domain I is cs.cohowinery.com, and you may be able to better picture how the shortcut trusts allow users to cut across trees in the Active Directory forest. Hopefully, you can also imagine how much planning should go into deciding your domain structure, especially when it comes to access to resources and authentication.
Authentication and trusts can be established across forest boundaries as well. As discussed in Chapter 32, while you are upgrading your network to implement Active Directory, you can establish external trusts to Windows NT domains to ensure that Windows NT domains continue to be available to users.
One-way external trusts, such as the one depicted in Figure 33-9, 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.
New in Windows Server 2003 is the addition of the cross-forest transitive trust also referred to simply as a forest trust. 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, as shown Figure 33-10, you enable cross-forest authentication and cross-forest authorization. Before you can use cross-forest trusts, all domain controllers in all domains of both forests must be upgraded to Windows Server 2003 and the forest must be running at the Windows Server 2003 functional level.
As discussed in the section "NTLM and Kerberos Authentication" earlier in this chapter, Kerberos is the default authentication protocol, but NTLM can also be used. This allows current clients and servers as well as older clients and servers to be authenticated. Once 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. 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 needed 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 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 Figure 33-11.
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 ensures that the Engineering department is secure and isolated.
You can examine existing trusts using Active Directory Domains And Trusts. Click Start, choose Programs or All Programs as appropriate, choose Administrative Tools, and then select Active Directory Domains And Trusts. As shown in the following screen, you see a list of available domains:
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 Trust tab as shown in the following screen. The Trust tab is organized into two panels:
Domains Trusted By This Domain (Outgoing Trusts) Lists the domains that this domain trusts (the trusted domains).
Domains That Trust This Domain (Incoming Trusts) Lists the domains that trust this domain (the trusting domains).
To view the details of a particular trust, select it, and then click Properties. The following screen shows the trust's Properties dialog box:
The Properties dialog box contains the following information:
This Domain The domain you are working with.
Other Domain The domain with which the trust is established.
Trust Type The type of trust. By default, two-way transitive trusts are created automatically when a new domain is added to a new domain tree within the forest or a subdomain of a root domain. 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 may appear include the following:
External, which is a one-way or two-way nontransitive trust used to provide access to resources in a Windows NT 4.0 domain or to a domain in a separate forest that is not joined by a forest trust
Forest, which is a one-way or two-way transitive trust used to share resources between forests
Realm, which is a transitive or nontransitive trust that can be established as one way or two way between a non-Windows Kerberos realm and a Windows Server 2003 domain
Shortcut, which is a one-way or two-way transitive trust used to speed up authentication and resource access between domain trees
Direction Of Trust The direction of the trust. All default trusts are established as two-way trusts. This means that users in the domain you are working with can authenticate in the other domain and users from the other domain can authenticate in the domain you are working with.
Transitivity Of Trust The transitivity of the trust. All default trusts are transitive, which means that users from indirectly trusted domains can authenticate in the other domain.
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:
For domain trusts, you need to use two accounts: one that is a member of the Domain Admins group in the first domain and one that is a member of the Domain Admins group in the second domain. If you don't have appropriate accounts in both domains, you can establish one side of the trust and allow another administrator in the other domain to establish the other side of the trust.
For forest trusts, you will need to use two accounts: one that is a member of the Enterprise Admins group in the first forest and one that is a member of the Enterprise Admins group in the second forest. If you don't have appropriate accounts in both forests, you can establish one side of the two-way trust and allow another administrator in the other forest to establish the other side of the trust.
For realm trusts, you will need to establish the trust separately for the Windows domain and for the Kerberos realm. If you don't have appropriate administrative access to both the Windows domain and the Kerberos realm, you can establish one side of the trust and allow another administrator to establish the other side of the trust.
To establish a trust, follow these steps:
Click Start, choose Programs or All Programs as appropriate, choose Administrative Tools, and then select Active Directory Domains And Trusts.
Right-click the domain for which you want to establish a one-way incoming, one-way outgoing, or two-way trust. For a cross-forest trust, this must be the forest root domain in one of the participating forests.
In the domain Properties dialog box, select the Trust tab, and then click the New Trust button. This starts the New Trust Wizard. Click Next to skip the welcome page.
On the Trust Name page, specify the domain name of the other domain, as shown in Figure 33-12. For a cross-forest trust, this must be the name of the forest root domain in the other forest.
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 is 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.
On the Direction Of Trust page, shown in Figure 33-13, choose the direction of 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.
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.
On the Trust Password page, shown in Figure 33-14, 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 upper case and lowercase characters, and contain either numerals or special characters.
Tip
You may need the password
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. Once the trust is created, Active Directory will periodically update the password, using an automatic password reset. This helps safeguard the integrity of the trust.
For domain or realm trusts, click Next twice to begin the trust creation process.
For forest trusts, you can set the outgoing trust authentication level as either DomainWide 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.
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 will fail 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:
Click Start, choose Programs or All Programs as appropriate, choose Administrative Tools, and then select Active Directory Domains And Trusts.
Right-click the trusted domain whose incoming trust you want to verify, and then select Properties.
In the domain's Properties dialog box, select the Trust 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.
Click OK. For a two-way trust, repeat this procedure for the other (trusting) domain.
You may want to revalidate trusts or specify that incoming trusts should not be validated for the following reasons:
If clients are unable to access resources in a domain outside the forest, the external trust between the domains may have failed. In this case, you should verify the trust for the trusted domain. Note that a PDC emulator must be available to reset and verify the external trust.
If clients cannot connect to a domain controller running Windows 2000, check the service pack level on the domain controller. The Windows 2000 domain controller should be running Service Pack 3 or later. If it isn't, upgrade it.
If clients or servers get trust errors within an Active Directory forest, there could be several causes. The time on the clients or servers trying to authenticate may be more than five minutes off, which is the default maximum time difference allowed for Kerberos authentication. In this case, synchronize the time on the clients and servers. The problem could also be that the domain controller may be down or the trust relationship could be broken. For the latter case, you can run NETDOM to verify or reset the trust.
If clients are experiencing trust errors connecting to a Windows NT 4 domain, the automatic password reset for the trust may not have reached the PDC emulator. You can run NETDOM to verify or reset the trust. If this doesn't resolve the problem, see Knowledge Base article 317178 for more information.
After upgrading a Windows NT 4 domain that has existing trusts with one or more Active Directory domains, you need to delete and recreate all the previously existing trusts. These trusts are not automatically upgraded from Windows NT 4 trusts. If this doesn't resolve the problem, see Knowledge Base article 275221 for more information.