Understanding Domain Functional Level When you set a functional level for a domain, the level of functionality applies only to that domain. This means that other domains in the forest can have a different func- tional level. As shown in Table 30-1, there are several domain functional levels. Changing a func- tional level changes the operating systems that are supported for domain controllers. For example, in Windows 2000 native functional level, the domain can have domain controllers running Microsoft Windows 2000 Server, Microsoft Windows Server 2003, or Windows Server 2008. Note You cannot use the Windows 2000 mixed domain functional level with Windows Server 2008 domain controllers. If your domain is operating at this level and you want to install a domain controller running Windows Server 2008, you’ll fi rst need to raise the domain functional level to Windows 2000 native or higher. Although you can raise the domain functional level, you can never lower it. This means that if you raise the domain functional level to Windows Server 2008, you can confi gure only Windows Server 2008 domain controllers in the domain. Table 30-1 Domain Functional Levels Domain Functional Level Supported Domain Controllers Windows 2000 mixed Windows Server 2003 Windows 2000 Server Windows NT 4.0 backup domain controller (BDC) Windows 2000 native Windows Server 2008 Windows Server 2003 Windows 2000 Server Windows Server 2003 Windows Server 2008 Windows Server 2003 Windows Server 2008 Windows Server 2008 Domains operating in Windows 2000 native mode can use group nesting, group type conversion, universal groups, and migration of security principals. Domains operating in this mode aren’t able to use easy domain controller renaming, update logon time stamps, or Kerberos key distribution center (KDC) key version numbers. Domains in Windows Server 2003 mode can use many improved Active Directory fea- tures, including group nesting, group type conversion, universal groups, easy domain controller renaming, update logon time stamps, migration of security principals, and Kerberos KDC key version numbers. Applications can use constrained delegation to take advantage of the secure delegation of user credentials through the Kerberos Note You cannot use the Windows 2000 mixed domain functional level with Windows Server 2008 domain controllers. If your domain is operating at this level and you want to install a domain controller running Windows Server 2008, you’ll fi rst need to raise the domain functional level to Windows 2000 native or higher. Although you can raise the domain functional level, you can never lower it. This means that if you raise the domain functional level to Windows Server 2008, you can confi gure only Windows Server 2008 domain controllers in the domain. Design Considerations for Compatibility 1017 Chapter 30 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. authentication protocol. You can also redirect the Users and Computers containers to defi ne a new well-known location for user and computer accounts. Windows 2008 domain functional level adds the following features above those avail- able with Windows Server 2003:  Distributed File System Replication for Sysvol, which provides more robust and granular replication of Sysvol.  Advanced Encryption Services (AES) support for the Kerberos protocol, allowing user accounts to use AES 128-bit or AES 256-bit encryption.  Last interactive logon information, which displays the time of the last successful interactive logon for a user, the number of failed logon attempts since last logon, and the time of the last failed logon.  Fine-grained password policies, which make it possible for password and account lockout policy to be specifi ed for user and global security groups in a domain. Understanding Forest Functional Level Forest functional level is a bit simpler, as shown in Table 30-2. When you raise the forest functional level to Windows Server 2008, all domains using the Windows 2000 native domain functional level or higher are automatically raised to the Windows Server 2008 domain functional level. As with the domain functional level, after you raise the forest functional level, you cannot lower it. Table 30-2 Forest Functional Levels Forest Functional Level Supported Domain Controllers Windows 2000 Windows Server 2008 Windows Server 2003 Windows 2000 Server Windows Server 2003 Windows Server 2008 Windows Server 2003 Windows Server 2008 Windows Server 2008 Forests operating in Windows 2000 mode can’t use many Active Directory features, including extended two-way trusts between forests, domain rename, domain restruc- ture using renaming, and global catalog replication enhancements. Windows Server 2003 forest functional level adds the following features:  Linked-value replication to improve the replication of changes to group memberships  Extended two-way trusts between forests  Domain rename and domain restructure using renaming  More effi cient generation of complex replication topologies by the KCC Chapter 30 1018 Chapter 30 Designing and Managing the Domain Environment Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. With the original release of the operating system, Windows Server 2008 forest func- tional level does not add any specifi c features. Raising the Domain or Forest Functional Level You can raise the domain or forest functional level using Active Directory Domains And Trusts. To raise the domain functional level, follow these steps: 1. Click Start, choose Administrative Tools, and then select Active Directory Domains And Trusts. 2. In the console tree, right-click the domain you want to work with, and then select Raise Domain Functional Level. The current domain name and functional level appear in the Raise Domain Functional Level dialog box. 3. To change the domain functionality, select the new domain functional level using the selection list provided, and then click Raise. CAUTION ! You can’t reverse this action. After you raise the functional level, there’s no going back, so you should consider the implications carefully before you do this. 4. When you click OK, the new domain functional level is replicated to each domain controller in the domain. This operation can take some several minutes or longer in a large organization. You can raise the forest level functionality by completing the following steps: 1. Click Start, choose Administrative Tools, and then select Active Directory Domains And Trusts. 2. Right-click the Active Directory Domains And Trusts node in the console tree, and then select Raise Forest Functional Level. The current forest name and functional level appear in the Raise Forest Functional Level dialog box. 3. To change the forest functionality, select the new forest functional level using the selection list provided, and then click Raise. CAUTION ! You can’t reverse this action. After you raise the functional level, there’s no going back, so you should consider the implications carefully before you do this. CU O ! CAUTION ! Design Considerations for Compatibility 1019 Chapter 30 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 4. When you click OK, the new forest functional level is replicated to each domain controller in each domain in the forest. This operation can take several minutes or longer in a large organization. As a planning option, you can determine the steps you need to take to raise the forest functional level by clicking Save As in the Raise Forest Functional Level dialog box. When you click Save As, a Save As dialog box appears, allowing you to select a save location for a log fi le. The log fi le details show the following information:  The forest root domain and the current forest functional level.  The domains and the domain controllers in those domains that are running ver- sions of Windows earlier than Windows Server 2008. These are the servers that need to be upgraded.  The domain functional level of each domain for which the functional level must be raised. As long as the domain functional level of all domains is set to at least Windows 2000 native, you can raise the forest functional level—doing so raises the domain functional level in all the domains to Windows Server 2008 and sets the forest functional level to Windows Server 2008 as well. Design Considerations for Active Directory Authentication and Trusts Authentication and trusts are integral parts of Active Directory. Before you implement any Active Directory design or try to modify your existing Active Directory infrastruc- ture, you should have a fi rm understanding of how both authentication and trusts work in an Active Directory environment. Universal Groups and Authentication 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 when- ever a user accesses resources on the network. Understanding Security Tokens and Universal Group Membership Caching To generate the security token, Active Directory checks the domain local and global group memberships for the user. All the supported domain functional levels in Windows Server 2008 support a special type of group called a universal group. Uni- versal groups can contain user and group accounts from any domain in the forest. As 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. Chapter 30 1020 Chapter 30 Designing and Managing the Domain Environment Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Because of problems authenticating users when global catalog servers are not available, Windows Server 2003 introduced a technique for caching universal group member- ship. In a domain with domain controllers running either Windows Server 2003 or Windows Server 2008, universal group membership caching can be enabled. After you enable caching, the cache is where domain controllers store universal group member- ship 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 indefi nitely 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, Windows Server 2008, or both domain controllers don’t necessarily have to have global catalog servers confi gured as well. This gives you additional options when con- fi guring 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 suffi x. The names of the current domain and the root domain are set as the default UPN suffi x. You can specify an alter- nate UPN suffi x to use to simplify logon or provide additional logon security. This name is used only within the forest and does not have to be a valid DNS name. For example, if the UPN suffi x for a domain is it.seattle.cpandl.local, you could use an alternate UPN suffi x to simplify this to cpandl.local. This would allow the user Williams to log on using williams@cpandl.local rather than williams@it.seattle.cpandl.local. You can add or remove UPN suffi xes for an Active Directory forest and all domains within that forest by completing the following steps: 1. Start Active Directory Domains And Trusts from the Administrative Tools menu. 2. Right-click the Active Directory Domains And Trusts node and then click Properties. 3. To add a UPN suffi x, type the alternate suffi x in the box provided and then click Add. 4. To remove a UPN suffi x, click the suffi x to remove in the list provided and then click Remove. 5. Click OK. Enabling Universal Group Membership Caching In a domain with domain controllers running Windows Server 2003, Windows Server 2008, or both, you use the Active Directory Sites And Services tool to confi gure universal group membership caching. You enable caching on a per-site basis. Start SIDE OUT The user principal name (UPN) suffi x can be changed Every user account has a user principal name (UPN) which consists of the user logon name combined with the at symbol (@) and a UPN suffi x. The names of the current domain and the root domain are set as the default UPN suffi x. You can specify an alter- nate UPN suffi x to use to simplify logon or provide additional logon security. This name is used only within the forest and does not have to be a valid DNS name. For example, if the UPN suffi x for a domain is it.seattle.cpandl.local, you could use an alternate UPN suffi x to simplify this to cpandl.local. This would allow the user Williams to log on using williams@cpandl.local rather than williams@it.seattle.cpandl.local. You can add or remove UPN suffi xes for an Active Directory forest and all domains within that forest by completing the following steps: 1. Start Active Directory Domains And Trusts from the Administrative Tools menu. 2. Right-click the Active Directory Domains And Trusts node and then click Properties. 3. To add a UPN suffi x, type the alternate suffi x in the box provided and then click Add. 4. To remove a UPN suffi x, click the suffi x to remove in the list provided and then click Remove. 5. Click OK. Design Considerations for Active Directory Authentication and Trusts 1021 Chapter 30 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Active Directory Sites And Services by clicking Start, Programs or All Programs, Admin- istrative Tools, and Active Directory Sites And Services. Expand and then select the site in which you want to enable universal group membership caching, as shown in the fol- lowing screen: In the right pane, right-click NTDS Site Settings, and then select Properties. This dis- plays the NTDS Site Settings Properties dialog box as shown in the following screen: To enable universal group membership caching for the site, select the Enable Universal Group Membership Caching check box and continue as follows:  If the directory has multiple sites, you can replicate existing universal group membership information from a specifi c site’s cache by selecting the site in the Refresh Cache From list. With this option, universal group membership informa- tion 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 fi nished confi guring universal group membership caching, click OK. Chapter 30 1022 Chapter 30 Designing and Managing the Domain Environment Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. NTLM and Kerberos Authentication Windows NT 4.0 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 verifi ed. 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 net- work resources. Typically, non-interactive 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: 1. 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. 2. The server generates a 16-byte random number, called a challenge, and sends it to the client. 3. 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. 4. 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 authentica- tion protocol, and NTLM authentication is maintained only for backward compatibility with older clients. Whenever a client running Windows 2000 or later tries to authen- ticate 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. Design Considerations for Active Directory Authentication and Trusts 1023 Chapter 30 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 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 Establishing the Initial Authentication 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 30-4. Kerberos Client Kerberos Server Validates by successful decryption then checks time stamp. Sends a session key and service ticket. Sends authentication message. 1 2 4 Validates by successful decryption then checks time stamp. Caches key and ticket. 3 Figure 30-4 The Kerberos authentication process. The details of the initial authentication of a user in the domain are as follows: 1. 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. 2. 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 fi ve 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 fi ve minutes off the current time, the authentication fails. Five minutes is the default value; the allowable time difference can be confi gured through domain security policy, using the Kerberos policy Maximum Tolerance For Computer Clock Synchronization. Chapter 30 1024 Chapter 30 Designing and Managing the Domain Environment Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 3. 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. 4. 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 fi ve 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. Accessing Resources After Authentication 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 30-5. The details of an access request for a network resource are as follows: 1. 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. 2. 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. 3. 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 fi rst 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. 4. 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. Design Considerations for Active Directory Authentication and Trusts 1025 Chapter 30 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Kerberos Client Kerberos Server Validates by successful decryption then checks time stamp. Sends a session ticket with two session keys. Sends session ticket request. 2 4a Caches both keys. The next time the user needs to access the resource, the session ticket in cache can be used. 3 Grants or denies access. Sends session ticket to the network resource. 6 5 Print Server (network resource) Validates by successful decryption of its key, then decrypts user access token with session key. Checks level of access. 4b 1 Figure 30-5 The Kerberos authentication process. 5. 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. 6. 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. Authentication and Trusts Across Domain Boundaries 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 30-6 shows a one-way trust in which one domain is the Chapter 30 1026 Chapter 30 Designing and Managing the Domain Environment Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... Kerberos in Windows 2000 limits the types of clients that can be used In this scenario, only clients running Windows 2000 or later can be used With Windows Server 2003 and Windows Server 2008, you can use both NTLM and Kerberos for authentication, which allows older clients to be used, as well as clients running Windows 2000 or later In addition, with Windows Server 2003 and Windows Server 2008, you... that they are delegated only for specific purposes This kind of delegation is based on service principal names Thus, unlike Windows 2000, in which the front-end server can access any network service on the client’s behalf, with Windows Server 2003 and Windows Server 2008, a front-end server can only access network resources for which delegation has been granted Configuring Delegated Authentication To use... this option to use the Windows Server 2008 level of authentication, which allows the service to make requests only for specified services You can then specify whether the client must authenticate using Kerberos only or can use any authentication protocol When you are using the Windows Server 2008 level of authentication, you must next specify the services to which the front-end server can present a client’s... Main-Site\corpserver26 @ USN @ USN 678321 @ Time 2008- 03-15 12:42:32 681525 @ Time 2008- 03-15 12:42:35 In this example, if CorpServer31 was the previous role owner and the domain controller you are examining has an equal or larger USN for CorpServer31, the domain controller is up to date However, if CorpServer31 was the previous role owner and the domain controller you are examining has a lower USN for CorpServer31,... asking for access to the back-end server The KDC grants the session ticket request and sends the client a session ticket with a PROXIABLE flag set The client can then send this ticket to the front-end server, and the front-end server in turn uses this ticket to access information on the back-end server In this configuration, the client needs to know the name of the back-end server, which in some cases is... ticket that the front-end server will be able to use to access the back-end servers The KDC grants the session ticket request, and sends it to the client The client can then send the ticket to the front-end server, which then uses the session ticket to make a network resource request on behalf of the client The front-end server then gets a session ticket to access the back-end server using the client’s... external trust Nontransitive A L H One-way shortcut trust E B F C D G M I J O N K Figure 30-9 A one-way external trust that crosses forest boundaries but is nontransitive Chapter 30 Like Windows Server 2003, Windows Server 2008 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... 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 Chapter 30 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 2008 domain Shortcut,... 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... the output lists each role owner by its fully qualified domain name: Schema master Domain naming master PDC RID pool manager Infrastructure master CorpServer26.cpandl.com CorpServer26.cpandl.com CorpServer32.tech.cpandl.com CorpServer32.tech.cpandl.com CorpServer41.tech.cpandl.com netdom query fsmo /d:DomainName where DomainName is the name of the domain, such as eng.cpandl.com Please purchase PDF Split-Merge . Controllers Windows 2000 Windows Server 2008 Windows Server 2003 Windows 2000 Server Windows Server 2003 Windows Server 2008 Windows Server 2003 Windows Server 2008. 2008 Windows Server 2003 Windows 2000 Server Windows Server 2003 Windows Server 2008 Windows Server 2003 Windows Server 2008 Windows Server 2008 Domains