Setting Up Trust Relationships
In this exercise we use the Active Directory Domains and Trusts MMC snap-in. Access domain properties and switch to the Trusts tab. To set up a new trust, click the New Trust button. This will launch the New Trust Wizard, which will take you through a few steps. You will need to provide the following information in order to complete this wizard:
■ Trust Name Supply the DNS name of the external domain. This should be an external forest root domain (if you are setting up a forest trust), the DNS name of a domain or a Kerberos realm, or in the worst-case scenario, the NetBIOS name of the domain.
■ Trust Type Choices will depend on the domain and its relation to other domains in its own forest. Choices may be Realm, Forest, Shortcut, and External. In some cases, the wizard will detect the only possible type for a given domain and will skip this page.
■ Transitivity of Trust Here you select whether your trust should be transitive. This information is only asked in the few cases when you are configuring a trust type that can technically be either non-transitive or transitive.
■ Direction of Trust Choose one-way outgoing, one-way incoming, or two-way.
■ Sides of Trust This screen allows you to select in which domains the wizard should attempt to configure trust relationships. As mentioned earlier, you need to configure trust on both ends. If it is a one-way, outgoing trust in the trusting domain, it should be configured as a one-way, incoming trust in the trusted domain. If you select "This domain only," you will need to create a common password to be used later on for configuring the other side of the relationship. Should you choose "Both this and the specified domain," you will be prompted for account credentials that have appropriate administrative access in the external domain.
■ Trust Authentication Level The wizard offers to configure whether this should be a domain-wide (or forest-wide, as applicable) authentication level or selective authentication. You will not be able to configure trust with selective authentication unless both forests are running at the Windows Server 2003 forest functional level or higher.
■ Trust Selections Complete The wizard will display a summary of your trust settings and ask you to confirm the newly configured trust. (This might be a good idea if you configured trust on both sides as part of the same process, or if you are setting up the second side of the trust; otherwise, the wizard will certainly fail to confirm the new trust relationship.)
Once the trust relationship has been configured, you can access trust properties through the same property page (shown in Figure 6-5). You can also view the properties of each trust on the incoming or outgoing list, and for those trusts that you created manually, you can change the scope of authentication (domain-wide or selective). For some types of trusts (such as realm trusts, where you have to select trust transitivity), you can also change transitivity. As shown in Figure 6-6, trust properties can be used to validate a trust relationship after it has been created on both ends. This is also a valuable troubleshooting tool. Last but not least, if the trust relationship
FIGURE 6-6
Trust properties
is no longer needed, you can use the property page to remove it by selecting the trust and clicking the Remove button. You will be prompted whether this trust should be removed from the external domain as well, in which case you will have to provide an administrative username and password for the external domain.
The built-in group called Incoming Forest Trust Builders allows for granting rights to external root domain administrators to configure trust relationships with your domain, without giving administrative authority in your domain.
As usual with UI-based administration tools in Windows Server 2008, there is a command-line alternative for the Active Directory Domains and Trusts console: the Netdom.exe tool, provided as part of Support Tools.
It has the same functionality as the console and more, also allowing you to reset secure channel passwords without having to redo the trust. The following listing shows a portion of the Netdom.exe trust /help command, which demonstrates just how flexible this tool is.
C:\Users\Administrator> netdom trust The syntax of this command is:
NETDOM TRUST trusting domain name /Domain:trusted domain name [/UserD:user] [/PasswordD:[password | *]] [UserO:user] [/PasswordO:[password | *]] [/Verify] [/RESEt] [/PasswordT:new realm trust password] [/Add] [/REMove] [/Twoway] [/REAlm] [/Kerberos] [/Transitive[:{yes | no}]]
[/OneSide:{trusted | trusting}] [/Force] [/Quarantine[:{yes | no}]] [/NameSuffixes:trust name [/ToggleSuffix:#]] [/EnableSIDHistory[:{yes | no}]] [/ForestTRANsitive[:{yes | no}]] [/CrossORGanization[:{yes | no}]] [/AddTLN:TopLevelName] [/AddTLNEX:TopLevelNameExclusion] [/RemoveTLN:TopLevelName] [/RemoveTLNEX:TopLevelNameExclusion] [/SecurePasswordPrompt] NETDOM TRUST Manages or verifies the trust relationship between domains
All of this is good, but so far, we have still not reviewed what practical implications these trust relationships have for users of the system. Two main functionalities come to mind: remote resource access, and local authentication (console logon) in the trusting domain.
■ Remote resource access Providing that proper access permissions have been configured (this includes the Allowed To Authenticate right if selective authentication is used), remote resources can be accessed similarly to local resource access—using UNC names, such as \ \Servername\sharename. These resources can be searched for in Active Directory (if they have been published). In addition to this, users must have the "Access this computer from network" right and NTFS permissions, if this resource is a file or folder located on the NTFS file system. If name resolution works as it is supposed to, remote network resource access is really no different from local network resource access.
■ Local logon in the trusting domain After you configure the trust relationship from domain A to domain B, users with accounts in domain B can be allowed to log on locally on machines in domain A. To do this, administrators in the trusting domain need to grant the "Allow to log on locally" right, and users from the trusted domain need to choose their home domain at the ctrl-alt-del logon screen, or use the UPN or <NetBIOS domain>\<username> format during the logon process. As demonstrated in Figure 6-7, a pre-Windows 2000 username is required for each account, but the UPN logon name and associated suffix can also be defined in user account properties.
t h Note that you may not be able to use NetBIOS domains from the
(j o b automatically created domain list on the ctrl-alt-del logon screen if your enterprise has forest trusts, and one or more domain names are duplicated between two or more forests.
Post a comment