Windows Server Guides

Trusts Configured Manually

Trust relationships of any other type, or between any other domains not included in the preceding definition, must be configured manually using the Active Directory Domains and Trusts MMC snap-in, shown in Figure 6-3. Trusts configured manually may be either one- or two-way, depending on business requirements. Recall from previous chapters that users can authenticate in the opposite direction of a trust link. So if domain A trusts domain B, users from domain B can authenticate to domain A, and their ability to access specific resources at that point becomes a function of assigning appropriate permissions. Table 6-1 shows the trust types available in Windows Server 2008.

Before configuring trust relationships, you have to do a little planning in regard to how users in trusted domains will resolve and interact with resources in trusting

FIGURE 6-3

Active Directory Domains and Trusts MMC snap-in

FIGURE 6-3

Active Directory Domains and Trusts MMC snap-in

|=IP Active Directory Domains and Trusts
File Action View Help
iE Oä Bi
^ Active Directory Domains and Trusts [TORDCOl.flexecom.local ]	Name | Type	Actions
SSEi	There are no items to show in this view.	More Actions ►

Trust Type Summary

Trust Type	Transitive?	Can Establish With
External trust	No	Windows NT 4.0 domains Windows 2000 Windows Server 2003 domains Windows Server 2008 domains
Realm trust	Configurable	Can be configured with any Kerberos realm that uses Kerberos version 5 or above
Forest trust	Transitive for any two forests	Windows Server 2003 or 2008 forests running at Windows Server 2003 or 2008 functional levels
Shortcut trust	Yes	Can be configured between any two-child domains within AD forest to shorten LDAP referrals and reduce the extent and complexity of the authentication process

domains, and a few other considerations. It may not be possible to implement portions of your planning work until after trusts have been defined, but this should have no impact on planning of the following elements:

■ DNS resolution You will have to configure DNS servers in each of the two domains to resolve the names of their counterparts. You should not rely on NetBIOS name resolution because several domains in different forests may have the same NetBIOS name. For example, a Sales third-level domain will have the same NetBIOS name by default, and this is consistent with Microsoft recommendations. In Windows Server 2008, you can use conditional forwarding or even stub zones to speed up DNS resolution between two deeply nested domains. You can also install another DNS server and use it for either delegation or zone transfers for both domains. There are quite a few options to consider when choosing what is best in a specific situation.

■ Trust password for secure channel (SC) setup You have to communicate with administrators on the other end and negotiate the best password policy to apply to the security channel password. By default, Windows Server 2008 will not let you use weak passwords for a trust setup. Since this password is used on both ends of the secure channel, it must satisfy password policy requirements in both domains. Before a trust relationship can be used, it must be defined in both domains. (Windows Server 2008 can configure both ends of the trust from the same wizard, if administrative credentials to the destination domain are known.)

■ Global groups You have to define global groups (and universal groups, if necessary), which will be used to assign permissions to resources located in the external domain. Alternatively, you can use existing groups. If there is no plan to migrate users between domains (if that is not why you are setting up the relationship), security groups should be created in the domain where administrative functions will be performed (in other words, defining a security group in domain A that is used to assign permissions in domain B gives administrators in domain A control over group membership, and therefore, control over resource access in domain B). Otherwise, if you plan domain consolidation down the road, groups should be created in the domain that will remain after consolidation. This will help to avoid SID filtering complications.

■ Resource access permissions You should define (or choose existing) local groups in the trusting domain where you will add your global groups with users from the trusted domain. Then you should ensure that these local groups have access to resources as required.

■ Plan policy settings By assigning "allow log on locally," "deny log on locally," "access this computer from the network," and "deny access to this computer from the network" user rights using a group policy or local computer policy, you can further restrict or enable users from the trusted domain to access resources in the trusting domain.

■ Authentication type When you configure an external trust relationship in Windows Server 2008, where both domains are running at the Windows Server 2008 functional level or higher, two authentication types are available: domain-wide (standard option) and selective. When you select the domain-wide option, it all comes down to assigning groups enough permissions to access specific resources. If selective authentication is chosen, the default behavior of the trust does not allow authentication across the trust link. To allow access to a resource, you must also grant Allowed To Authenticate permission to the group in question on the server where the resource is located. This was described in earlier chapters. Figure 6-4 shows this setting.

FIGURE 6-4

Allowed to

Authenticate right

General | Operating System | Member Of | Delegation J Password Replication Location | Managed By | Object Security j Dial-in | Attribute Editor

Group or user names:

Everyone	M.
tf, SELF
- .Authenticated Users
■3» SYSTEM	_
■J, Domain Admins [FLEXECO MXDomain Admins)
' .i Cert Publishers (FLEXECO MVCert Publishers)
■' Enterprise Admins [FLEXECOMNEnterprise Admins)	Permissions for Authenticated Users Allow Remove Deny Permissions for Authenticated Users Allow Remove Deny Full control Read Write Create all child objects Delete all child objects .Allowed to authenticate 5 zi For special permissions or advanced settings, click Advanced. Leam about access cgntjd and Ejg§gMgagn5 Advanced For special permissions or advanced settings, click Advanced. Leam about access cgntjd and Ejg§gMgagn5 OK Cancel Apply ■ Help' After giving all of these considerations a bit of thought, you can now proceed with setting up trust links. Use the Active Directory Domains and Trusts console shown in earlier Figure 6-3. Expand the domain tree to a point where you see the domain you would like to set up a trust relationship for, right-click it, choose Properties, and then switch to the Trusts tab (shown in Figure 6-5). Note that this page has two sections, one for outgoing trusts and one for incoming trusts. Regardless of the trust direction, each trust relationship must be defined on each end of the relationship. The outgoing trust list contains all domains trusted by your domain, and the incoming trust list contains all domains trusting your domain. FIGURE 6-5 Managing domain trusts using Active Directory Domains and Trusts console

0 0