Windows Server 2008 Inside Out- P22

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:50

0
46
lượt xem
9
download

Windows Server 2008 Inside Out- P22

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo tài liệu 'windows server 2008 inside out- p22', công nghệ thông tin, quản trị mạng phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:
Lưu

Nội dung Text: Windows Server 2008 Inside Out- P22

  1. Design Considerations for Compatibility 1017 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 first 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 configure 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. Chapter 30 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
  2. 1018 Chapter 30 Designing and Managing the Domain Environment authentication protocol. You can also redirect the Users and Computers containers to define 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 specified 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 Chapter 30 Extended two-way trusts between forests Domain rename and domain restructure using renaming More efficient generation of complex replication topologies by the KCC
  3. Design Considerations for Compatibility 1019 With the original release of the operating system, Windows Server 2008 forest func- tional level does not add any specific 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. C U O 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, Chapter 30 so you should consider the implications carefully before you do this.
  4. 1020 Chapter 30 Designing and Managing the Domain Environment 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 file. 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 firm 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- Chapter 30 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.
  5. Design Considerations for Active Directory Authentication and Trusts 1021 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 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, Windows Server 2008, or both domain controllers don’t necessarily have to have global catalog servers configured as well. This gives you additional options when con- figuring 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. SIDE OUT The user principal name (UPN) suffix 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 suffix. The names of the current domain and the root domain are set as the default UPN suffix. You can specify an alter- nate UPN suffix 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 suffix for a domain is it.seattle.cpandl.local, you could use an alternate UPN suffix 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 suffixes 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 suffix, type the alternate suffix in the box provided and then click Add. 4. To remove a UPN suffix, click the suffix to remove in the list provided and then click Remove. 5. Click OK. Chapter 30 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 configure universal group membership caching. You enable caching on a per-site basis. Start
  6. 1022 Chapter 30 Designing and Managing the Domain Environment 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 specific 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 Chapter 30 catalog server in the nearest site, accept the default setting . With this option, universal group membership information is generated and then replicated. When you are finished configuring universal group membership caching, click OK.
  7. Design Considerations for Active Directory Authentication and Trusts 1023 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 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 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. Chapter 30 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.
  8. 1024 Chapter 30 Designing and Managing the Domain Environment 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 Kerberos Client 1 Server Sends authentication message. 4 3 Sends a session key Validates by and service ticket. 2 Validates by successful decryption successful then checks time decryption then stamp. Caches key checks time stamp. and ticket. 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 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 Chapter 30 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.
  9. Design Considerations for Active Directory Authentication and Trusts 1025 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 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. 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 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. 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 Chapter 30 stamp.
  10. 1026 Chapter 30 Designing and Managing the Domain Environment Kerberos Kerberos Client 1 Server Sends session ticket request. 4a 3 Sends a session ticket with two session keys. 2 Validates by successful Caches both keys. decryption then The next time the checks time stamp. user needs to access the resource, the session ticket in Print Server cache can be used. (network resource) 4b Sends session ticket to the network resource. 5 6 Grants or denies access. Validates by successful decryption of its key, then decrypts user access token with session key. Checks level of access. 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 Chapter 30 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
  11. Design Considerations for Active Directory Authentication and Trusts 1027 trusted domain and the other domain is the trusting domain. In Windows NT 4.0, 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. Direction of trust Domain A Domain B Direction of access Trusted domain Trusting domain (account domain) (resource domain) Figure 30-6 One-way trust with a trusted domain and a trusting domain. Two-Way Transitive Trusts 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 shown in Figure 30-6 were Windows domains, 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 implement- ing Active Directory domains. Note The physical limitation on the number of objects that necessitated having separate account and resource domains in Windows NT 4.0 no longer applies. Active Directory domains can have millions of objects, a fact that changes the fundamental reason for creating additional domains. Chapter 30 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
  12. 1028 Chapter 30 Designing and Managing the Domain Environment 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 30-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 control- ler 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. Two-way transitive trust A H B E I C F J D G K Figure 30-7 A forest with many domains. Shortcut Trusts This rather lengthy referral process could be avoided if you established an explicit trust between domain G and domain K as shown in Figure 30-8. 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 Chapter 30 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
  13. Design Considerations for Active Directory Authentication and Trusts 1029 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 rap- idly authenticated. Using the B to E and E to I shortcut trusts, users in domain B can visit domain I and be rapidly authenticated. Two-way transitive trust A H One-way shortcut trust B E I C F J D G K Figure 30-8 A forest with several shortcut trusts. 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, Chapter 30 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.
  14. 1030 Chapter 30 Designing and Managing the Domain Environment Authentication and Trusts Across Forest Boundaries You can establish authentication and trusts across forest boundaries as well. As dis- cussed in Chapter 29, “Active Directory Architecture,” 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 30-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. Forest 1 Forest 2 Two-way One-way transitive trust external trust Nontransitive A H L One-way shortcut trust B E I M O C F J N D G K Figure 30-9 A one-way external trust that crosses forest boundaries but is nontransitive. 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 to share resources and to authen- Chapter 30 ticate users. With a two-way trust, as shown Figure 30-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 or higher, and the forest must be running at the Windows Server 2003 or higher functional level.
  15. Design Considerations for Active Directory Authentication and Trusts 1031 As discussed in “NTLM and Kerberos Authentication” on page 1023, 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. 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. Forest 1 Forest 2 Two-way transitive trust Two-way trust Cross-forest, transitive A H L One-way shortcut trust B E I M O C F J N D G K Figure 30-10 A two-way transitive 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 com- panies 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- Chapter 30 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
  16. 1032 Chapter 30 Designing and Managing the Domain Environment 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 30-11. Main Organizational Forest Engineering Forest Two-way transitive trust One-way trust Cross-forest, transitive A H L One-way shortcut trust B E I M O C F J N D G K Figure 30-11 A one-way transitive trust between forests. 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. Chapter 30
  17. Design Considerations for Active Directory Authentication and Trusts 1033 Examining Domain and Forest Trusts 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 Trusts 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). Chapter 30
  18. 1034 Chapter 30 Designing and Managing the Domain Environment To view the details of a particular trust, select it, and then click Properties. The follow- ing 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 for- est 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 sepa- rate 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 Chapter 30 as one way or two way between a non-Windows Kerberos realm and a Windows Server 2008 domain Shortcut, which is a one-way or two-way transitive trust used to speed up authentication and resource access between domain trees
  19. Design Considerations for Active Directory Authentication and Trusts 1035 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 authenti- cate 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. Establishing External, Shortcut, Realm, and Cross-Forest Trusts 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 Enter- prise 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: 1. Click Start, choose Programs or All Programs as appropriate, choose Administrative Tools, and then select Active Directory Domains And Trusts. 2. Right-click the domain for which you want to establish a one-way incoming, one- way outgoing, or 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. 3. 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 Chapter 30 page. 4. On the Trust Name page, specify the domain name of the other domain, as shown in Figure 30-12. For a cross-forest trust, this must be the name of the forest root domain in the other forest.
  20. 1036 Chapter 30 Designing and Managing the Domain Environment Figure 30-12 Specify the name of the other domain. 5. 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 transi- tive. 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 Direc- tion 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 Non- transitive or Transitive, and then click Next. 6. On the Direction Of Trust page, shown in Figure 30-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. Chapter 30
Đồng bộ tài khoản