Trusts

A trust is a relationship established between domains that enables users in one domain to be authenticated by a domain controller in the other domain. Trust relationships in Windows NT are different than in Windows 2000 and Windows Server 2003 operating systems.

Trusts in Windows NT
In Windows NT 4.0 and earlier, trusts are limited to two domains and the trust relationship is one-way and nontransitive. In the following figure, the nontransitive, one-way trust is shown by the straight arrow pointing to the trusted domain.

Trusts in Windows Server 2003 and Windows 2000 Server operating systems
All trusts in a Windows 2000 and Windows Server 2003 forest are transitive, two-way trusts. Therefore, both domains in a trust relationship are trusted. As shown in the following figure, this means that if Domain A trusts Domain B and Domain B trusts Domain C, then users from Domain C can access resources in Domain A (when assigned the proper permissions). Only members of the Domain Admins group can manage trust relationships.

Trust protocols
A domain controller running Windows Server 2003 authenticates users and applications using one of two protocols: Kerberos V5 or NTLM. The Kerberos V5 protocol is the default protocol for computers running Windows 2000, Windows XP Professional, or Windows Server 2003. If any computer involved in a transaction does not support Kerberos V5, the NTLM protocol will be used. With the Kerberos V5 protocol, the client requests a ticket from a domain controller in its account domain to the server in the trusting domain. This ticket is issued by an intermediary trusted by the client and the server. The client presents this trusted ticket to the server in the trusting domain for authentication. For more information, see Kerberos V5 authentication. When a client tries to access resources on a server in another domain using NTLM authentication, the server containing the resource must contact a domain controller in the client account domain to verify the account credentials.

Trusted domain objects

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time a trust is established a unique TDO is created and stored (in the System container) in its domain. Attributes such as a trust transitivity, type, and the reciprocal domain names are represented in a TDO. Forest trust TDOs store additional attributes to identify all of the trusted namespaces from its partner forest. These attributes include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces. For more information about domain trusts, see "Domain Trust" at the Microsoft Windows Resource Kits Web site. For more information about trust relationships, see "Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site.

Trust types
Communication between domains occurs through trusts. Trusts are authentication pipelines that must be present in order for users in one domain to access resources in another domain. Two default trusts are created when using the Active Directory Installation Wizard. There are four other types of trusts that can be created using the New Trust Wizard or the Netdom commandline tool.

Default trusts
By default, two-way, transitive trusts are automatically created when a new domain is added to a domain tree or forest root domain using the Active Directory Installation Wizard. The two default trust types are defined in the following table. Trust Transitivity Direction type Parent and Transitive child Description

Treeroot

Transitive

By default, when a new child domain is added to an existing domain tree, a new parent and child trust is established. Authentication requests made from subordinate domains flow Two-way upward through their parent to the trusting domain. For information about creating a new child domain, see Create a new child domain. By default, when a new domain tree is created in an existing Two-way forest, a new tree-root trust is established. For information about creating a new domain tree, see Create a new domain tree.

Other trusts

Four other types of trusts can be created using the New Trust Wizard or the Netdom commandline tool: external, realm, forest, and shortcut trusts. These trusts are defined in the following table. Trust type Transitivity Direction One-way or two-way Description Use external trusts to provide access to resources located on a Windows NT 4.0 domain or a domain located in a separate forest that is not joined by a forest trust. For more information, see When to create an external trust. Use realm trusts to form a trust relationship between a non-Windows Kerberos realm and a Windows Server 2003 domain. For more information, see When to create a realm trust. Use forest trusts to share resources between forests. If a forest trust is a two-way trust, authentication requests made in either forest can reach the other forest. For more information, see When to create a forest trust. Use shortcut trusts to improve user logon times between two domains within a Windows Server 2003 forest. This is useful when two domains are separated by two domain trees. For more information, see When to create a shortcut trust.

External Nontransitive

Realm

Transitive or nontransitive

One-way or two-way

Forest

Transitive

One-way or two-way

Shortcut Transitive

One-way or two-way

When creating external, shortcut, realm, or forest trusts, you have the option to create each side of the trust separately or both sides of a trust simultaneously. If you choose to create each side of the trust separately, then you will need to run the New Trust Wizard twice--once for each domain. When creating trusts using the method, you will need to supply the same trust password for each domain. As a security best practice, all trust passwords should be strong passwords. For more information, see Strong passwords. If you choose to create both sides of the trust simultaneously, you will need to run the New Trust Wizard once. When you choose this option, a strong trust password is automatically generated for you. You will need the appropriate administrative credentials for each domain between which you will be creating a trust. Netdom.exe can also be used to create trusts
Trust direction
The trust type and its assigned direction will impact the trust path used for authentication. A trust path is a series of trust relationships that authentication requests must follow between domains. Before a user can access a resource in another domain, the security system on domain controllers running Windows Server 2003 must determine whether the trusting domain (the domain containing the resource the user is trying to access) has a

trust relationship with the trusted domain (the user's logon domain). To determine this, the security system computes the trust path between a domain controller in the trusting domain and a domain controller in the trusted domain. In the following figure, trust paths are indicated by arrows showing the direction of the trust (this is a oneway trust):

All domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain.

One-way trust
A one-way trust is a unidirectional authentication path created between two domains. This means that in a oneway trust between Domain A and Domain B, users in Domain A (trusted domain) can access resources in Domain B (trusting domain). However, users in Domain B cannot access resources in Domain A. Some one-way trusts can be a nontransitive trust or a transitive trust depending on the type of trust being created. For more information about trust types, see Trust types.

Two-way trust
All domain trusts in a Windows Server 2003 forest are two-way, transitive trusts. When a new child domain is created, a two-way, transitive trust is automatically created between the new child domain and the parent domain. In a two-way trust, both domains that are involved in a trust relationship trust each other. This means that authentication requests can be passed between the two domains in both directions. Some two-way relationships can be nontransitive or transitive depending on the type of trust being created. For more information, see Trust types. A Windows Server 2003 domain can establish a one-way or two-way trust with: Windows Server 2003 domains in the same forest Windows Server 2003 domains in a different forest Windows NT 4.0 domains Kerberos V5 realms

y y y y

Trust transitivity
Transitivity determines whether a trust can be extended outside of the two domains with which it was formed. A transitive trust can be used to extend trust relationships with other domains and a nontransitive trust can be used to deny trust relationships with other domains.

Transitive trusts
Each time you create a new domain in a forest, a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. If child domains are added to the new domain, the trust path

flows upward through the domain hierarchy extending the initial trust path created between the new domain and its parent domain. Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive trusts between all domains in the domain tree. Authentication requests follow these trust paths, so accounts from any domain in the forest can be authenticated at any other domain in the forest. With a single logon process, accounts with the proper permissions can access resources in any domain in the forest. For more information, see Authentication protocols overview.

The diagram displays that all domains in the Domain A tree and all domains in the Domain 1 tree have transitive trust relationships by default. As a result, users in the Domain A tree can access resources in domains in the Domain 1 tree and users in the Domain 1 tree can access resources in the Domain A tree, when the proper permissions are assigned at the resource. In addition to the default transitive trusts established in a Windows Server 2003 forest, using the New Trust Wizard, you can manually create the following transitive trusts. Shortcut trust. A transitive trust between a domain in the same domain tree or forest used to shorten the trust path in a large and complex domain tree or forest. Forest trust. A transitive trust between a forest root domain and a second forest root domain. Realm trust. A transitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos V5 authentication. For more information about trust types, see Trust types.

y y

Nontransitive trust
A nontransitive trust is restricted by the two domains in the trust relationship and does not flow to any other domains in the forest. A nontransitive trust can be a two-way trust or a one-way trust. Nontransitive trusts are one-way by default, although you can also create a two-way relationship by creating two one-way trusts. In summary, nontransitive domain trusts are the only form of trust relationship possible between: A Windows Server 2003 domain and a Windows NT domain A Windows Server 2003 domain in one forest and a domain in another forest (when not joined by a forest trust) Using the New Trust Wizard, you manually create the following nontransitive trusts: External trust. A nontransitive trust created between a Windows Server 2003 domain and a Windows NT domain or a Windows 2000 domain or Windows Server 2003 domain in another forest.

y y

When you upgrade a Windows NT domain to a Windows Server 2003 domain, all existing Windows NT trusts are preserved intact. All trust relationships between Windows Server 2003 domains and Windows NT domains are nontransitive. Realm trust. A nontransitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos V5 authentication.

When to create an external trust

You can create an external trust to form a one-way or two-way, nontransitive trust with domains outside of your forest. External trusts are sometimes necessary when users need access to resources located in a Windows NT 4.0 domain or in a domain located within a separate forest that is not joined by a forest trust, as shown in the figure.

When a trust is established between a domain in a particular forest and a domain outside of that forest, security principals from the external domain can access resources in the internal domain. Active Directory creates a foreign security principal object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Domain local groups can have members from domains outside of the forest. Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users and Computers by enabling advanced features. For information about enabling advanced features, see To view advanced features. In domains with the functional level set to Windows 2000 mixed, it is recommended that you delete external trusts from a domain controller running Windows Server 2003. External trusts to Windows NT 4.0 or 3.51 domains can be deleted by authorized administrators on the domain controllers running Windows NT 4.0 or 3.51. However, only the trusted side of the relationship can be deleted on the domain controllers running Windows NT 4.0 or 3.51. The trusting side of the relationship (created in the Windows Server 2003 domain) is not deleted, and although it will not be operational, the trust will continue to display in Active Directory Domains and Trusts. To remove the trust completely, you will need to delete the trust from a domain controller running Windows Server 2003 in the trusting domain. If an external trust is inadvertently deleted from a domain controller running Windows NT 4.0 or 3.51, you will need to recreate the trust from any domain controller running Windows Server 2003 in the trusting domain. For more information about how to create an external trust, see Create an external trust.

Securing external trusts

To improve the security of Active Directory forests, domain controllers running Windows Server 2003 and Windows 2000 Service Pack 4 (or higher) enable security identifier (SID) filter quarantining on all new outgoing external trusts by default. By applying SID filter quarantining to outgoing external trusts, you prevent malicious users who have domain administrator level access in the trusted domain from granting, to themselves or other user accounts in their domain, elevated user rights to the trusting domain. When a malicious user can grant unauthorized user rights to another user it is known as an elevation of privilege attack. For more information about SID filtering and how to further mitigate an elevation of privilege attack, see MS02-001: Forged SID could result in elevated privileges in Windows 2000 (http://go.microsoft.com/fwlink/?LinkId=102075).

How SID filter quarantining works

When security principals are created in a domain, the domain SID is included in the security principal's SID to identify the domain in which it was created. The domain SID is an important characteristic of a security principal because the Windows security subsystem uses it to verify the security principal's authenticity. In a similar fashion, outgoing external trusts created from the trusting domain use SID filter quarantining to verify that incoming authentication requests made from security principals in the trusted domain contain SIDs of security principals from the trusted domain only. This is done by comparing the SIDs of the incoming security principal to the domain SID of the trusted domain. If any of the security principal SIDs include a domain SID other than the one from the trusted domain, the trust removes the offending SID. SID filtering ensures that any misuse of the SID history attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of the trusting forest. The SID history attribute can be useful to domain administrators when they migrate user and group accounts from one domain to another. Domain administrators can add SIDs from an old user or group account to the SID history attribute of the new, migrated account. By doing this, domain administrators give the new account the same level of access to resources as the old account. If domain administrators could not use the SID history attribute in this way, they would have to track down and reapply permissions for the new account on each network resource that the old account had access to.

Understanding the threat

If not for SID filtering on outgoing external trusts, a malicious user with administrative credentials residing in the trusted domain could sniff network authentication requests from the trusting domain to obtain the SID information of a user who has full access to resources in the trusting domain, such as a domain administrator. After obtaining the domain administrators SID from the trusting domain, a malicious user with administrative credentials can add that SID to a user account's SID history attribute in the trusted domain and attempt to gain full access to the trusting domain and the resources within that domain. In this scenario, a malicious user who has domain administrator credentials in the trusted domain is a threat to the entire trusting forest. SID filtering neutralizes the threat of malicious users in the trusted domain from using the SID history attribute to gain elevated privileges.

Impact of SID filter quarantining

SID filter quarantining on external trusts can affect your existing Active Directory infrastructure in the following two areas: SID history data that contains SIDs from any domain other than the trusted domain will be removed from authentication requests made from the trusted domain. This will result in access being denied to resources that have the user's old SID.

Universal group access control strategy between forests will require changes.

When SID filter quarantining is enabled, users who use SID history data for authorization to resources in the trusting domain no longer have access to those resources. If you typically assign universal groups from a trusted forest to access control lists (ACLs) on shared resources in the trusting domain, SID filter quarantining will have a major impact on your access control strategy. Because universal groups must adhere to the same SID filter quarantining guidelines as other security principal objects (that is, the universal group object SID must also contain the domain SID), you should verify that any universal groups that are assigned to shared resources in the trusting domain were created in the trusted domain. If the universal group in the trusted forest was not created in the trusted domain, even though it may contain users from the trusted domain as members, authentication requests made from members of that universal group will be filtered and discarded. Therefore, before assigning access to resources in the trusting domain for users in the trusted domain, you should confirm that the universal group containing the trusted domain users was created in the trusted domain.

Disabling SID Filter quarantining

Although it is not recommended, you can disable SID filter quarantining for an external trust by using the Netdom.exe tool. You should consider disabling SID filter quarantining only in the following situations: You have the same level of trust for all administrators who have physical access to domain controllers in the trusted domain as the administrators in the trusting domain. You have a strict requirement to assign universal groups to resources in the trusting domain that were not created in the trusted domain. Users have been migrated to the trusted domain with their SID histories preserved, and you want to grant them access to resources in the trusting domain based on the SID history attribute. Only domain administrators can disable SID filtering. To disable SID filter quarantining for the trusting domain, type the following syntax at a command-prompt: Netdom trustTrustingDomainName/domain:TrustedDomainName/quarantine:No /userD:domainadministratorAcct/passwordD:domainadminpwd To enable SID filter quarantining, set the /quarantine: command-line option to Yes. For more information about Netdom.exe, see Active Directory support tools. You can enable or disable SID filter quarantining only from the trusting side of the trust. If the trust is a two-way trust, you can also disable SID filter quarantining in the trusted domain by using the domain administrator's credentials for the trusted domain and reversing the TrustingDomainName and TrustedDomainName values in the command-line syntax. Notes To further secure your forest, you should consider enabling SID filter quarantining on all existing external trusts that were created by domain controllers running Windows 2000 Service Pack 3 (or earlier). You can do this by using Netdom.exe to enable SID filtering on existing external trusts, or by recreating these external trusts from a domain controller running Windows Server 2003 or Windows 2000 Service Pack 4 (or later).

You cannot turn off the default behavior that enables SID filter quarantining for newly created external trusts. External trusts created from domain controllers running Windows 2000 Service Pack 3 (or earlier) do not enforce SID filter quarantining by default. Domain controllers running Windows NT Server 4.0 do not take part in the trust creation process when existing domain controllers in the same domain are running Windows 2000 or Windows Server 2003. You can enable or disable SID filter quarantining only for trusts that extend beyond forest boundaries such as external and forest trusts. For more information about SID filtering and forest trusts, see Forest trusts.

Allowing SID history to traverse forest trusts If you are migrating users from one domain to another in different forests, you may want to allow the migrated users to access resources in their original forest by using their migrated (SID history) credentials. The default SID filtering that is applied to forest trusts prevents user-resource-access requests from traversing the trusts with the credentials of the original domain. If you want to make it possible for users to use the credentials that were migrated from their original domain, you can allow SID history to traverse forest trusts by using the netdom command. Only domain administrators or enterprise administrators can modify SID filtering settings. To allow SID history credentials to traverse a trust relationship between two forests, type a command using the following syntax at a command prompt, and then press ENTER: Netdom trustTrustingDomainName/domain:TrustedDomainName/enablesidhistory:Yes /usero:domainadministratorAcct/passwordo:domainadminpwd To re-enable the default SID filtering setting across forest trusts, set the /enablesidhistory: command-line option to No.

When to create a shortcut trust

Shortcut trusts are one-way or two-way, transitive trusts that can be used when administrators need to optimize the authentication process. Authentication requests must first travel a trust path between domain trees, and in a complex forest this can take time, which can be reduced with shortcut trusts. A trust path is the series of domain trust relationships that must be traversed in order to pass authentication requests between any two domains. For more information about trust paths, see Trust direction. Shortcut trusts are necessary when many users in a domain regularly log on to other domains in a forest. For example, using the following figure as an example, you could form a shortcut trust between domain B and domain D or domain A and domain 1 and so on.

Shortcut trusts effectively shorten the path traveled for authentication's made between domains located in two separate trees. For more information about how to create a shortcut trust, see Create a shortcut trust.

Using one-way trusts

A one-way, shortcut trust established between two domains located in separate domain trees can reduce the time needed to fulfill authentication requests, but in only one direction. For example, when a one-way, shortcut trust is established between domain A and domain B, authentication requests made in domain A to domain B can utilize the new one-way trust path. However, authentication requests made in domain B to domain A will still need to travel the longer trust path.

Using two-way trusts

A two-way, shortcut trust established between two domains located in separate domain trees will reduce the time needed to fulfill authentication requests originating in either domain. For example, when a two-way trust is established between domain A and domain B, authentication requests made from either domain to the other can utilize the new, two-way trust path.

When to create a realm trust

A realm trust can be established between any non-Windows Kerberos V5 realm and a Windows Server 2003 domain. This trust relationship allows cross-platform interoperability with security services based on other Kerberos V5 versions such as UNIX and MIT implementations. Realm trusts can switch from nontransitive to transitive and back. Realm trusts can also be either one-way or two-way.

When to create a forest trust

A forest trust can only be created between a forest root domain in one Windows Server 2003 forest and a forest root domain in another Windows Server 2003 forest. Creating a forest trust between two Windows Server 2003 forests provides a one-way or two-way, transitive trust relationship between every domain residing within each forest. Forest trusts are useful for Application Service Providers, companies undergoing mergers or acquisitions, collaborative business extranets, and companies seeking a solution for administrative autonomy. For more information about creating forest trusts, see Checklist: Creating a forest trust.

Note You should not enable SID filter quarantining on forest trusts, that is, by using the netdom command with the /quarantine:yes option. However, if you have migrated users from one Windows Server 2003 forest to another and the migrated users need access to resources in the former domain, you can relax the default SID filtering that is applied to a forest trust by using the netdom command with the /enablesidhistory:yes option. Using that command on a forest trust reduces the level of SID filtering on the forest trust. So, ensure that you trust the administrators of the trusted domain, as well as their security practices.

Using one-way forest trusts

A one-way, forest trust between two forests allows members of the trusted forest to utilize resources located in the trusting forest. However, the trust operates in only one direction. For example, when a one-way, forest trust is created between forest A (the trusted forest) and forest B (the trusting forest), members of forest A can access resources located in forest B, but members of forest B cannot access resources located in forest A using the same trust.

Using two-way forest trusts

A two-way, forest trust between two forests allows members from either forest to utilize resources located in the other forest; domains in each respective forest trust domains in the other forest implicitly. For example, when a two-way, forest trust is established between forest A and forest B, members of forest A can access resources located in forest B, and members of forest B can access resources in forest A, using the same trust

Forest trusts

In a Windows Server 2003 forest, you can link two disjoined Windows Server 2003 forests together to form a oneway or two-way, transitive trust relationships. A two-way, forest trust is used to form a transitive trust relationship between every domain in both forests. Forest trusts can provide the following benefits: Simplified management of resources across two Windows Server 2003 forests by reducing the number of external trusts necessary to share resources. Complete two-way trust relationships with every domain in each forest. Use of user principal name (UPN) authentication across two forests. Use of both the Kerberos V5 and NTLM authentication protocols to improve the trustworthiness of authorization data transferred between forests. Flexibility of administration. Administrative tasks can be unique to each forest.

y y y

Forest trusts can only be created between two forests and cannot be implicitly extended to a third forest. This means that if a forest trust is created between forest 1 and forest 2, and a forest trust is also created between forest 2 and forest 3, forest 1 will not have an implicit trust with forest 3. For more information about the requirements needed for a forest trust, see When to create a forest trust. Notes In a Windows 2000 forest, if users in one forest need to access resources in another forest, an administrator can create an external trust relationship between the two domains. External trusts can be one-way or two-way and are nontransitive, and therefore, limit the ability for trust paths to extend to other domains. For more information about external trusts, see Trust types. All trusts in Windows Server 2003 Active Directory use security identifier (SID) filtering to some degree. External trusts are quarantined by default, which prevents any domain SIDs other than those of the quarantined trusted domain from traversing the trust relationship. SID filtering is used to prevent attacks from malicious users who might try to grant elevated user rights to another user account. SID filtering on forest trusts does not prevent migrations to domains within the same forest from using SID history and will not affect your universal group access control strategy. For more information about SID filtering, see When to create an external trust.

Managing a multiple forest environment

Forest trusts help you to manage a segmented Active Directory infrastructure within your organization by providing support for accessing resources and other objects across multiple forests. For more information about accessing resources across multiple forests, see Accessing resources across forests. Because each forest is administered separately, adding additional forests to your organization increases your organization's management needs. For more information, see Creating a new forest. Reasons to create multiple forests in your organization include: To secure data within each forest. Sensitive data can be protected so that only users within that forest can access it.

To isolate directory replication within each forest. Schema changes, configuration changes, and the addition of new domains to a forest only have forest-wide impact within that forest, not on a trusting forest.

Delegating forest-wide administrative control

Active Directory data that is stored in the schema and configuration containers is replicated to every domain controller in the forest. Since changes to the schema and configuration containers will affect all domains in the forest, administrative control for forest-wide changes should be entrusted to highly trained or experienced administrators. All domain data contained in the forest root domain should also be regarded as highly sensitive data. The following groups provide forest-wide administrative control in each forest: Enterprise Admins Domain Admins (in the forest root domain) Schema Admins

y y y

Since membership in any of these groups can affect forest-wide behavior, add users with caution. As a security best practice, avoid adding users from another forest to any of these forest-wide administrative groups. For more information about these groups, see Default groups.

Synchronizing data across forests

You can synchronize global address lists (GALs) and objects across forests using Microsoft Metadirectory Services (MMS) or another supported synchronization tool. Common data types that need synchronization across forests include: GALs (Exchange) Public folders Directory objects

y y y

Synchronizing this data across forests will help end users view address lists and other data the same way as they do when viewing this information within their own forest.

Accessing resources across domains

Since two or more Active Directory domains within the same forest are implicitly connected by two-way, transitive trusts, authentication requests made from one domain to another are successfully routed in order to provide a seamless coexistence of resources across domains. Users can only gain access to resources in other domains after first being authenticated in their own domain. Domain controllers running Windows 2000 or Windows Server 2003 authenticate users and applications using one of two authentication protocols: Kerberos V5 or NTLM. For more information about Kerberos authentication, see Kerberos V5 authentication. For more information about NTLM authentication, see NTLM authentication. For more information about the Active Directory authentication process, see Access control in Active Directory. Once authenticated, the user can attempt to gain access to resources from any domain in the forest using the Active Directory authorization process. For more information about the Active Directory authorization process, see Security information for Active Directory.

To access a shared resource in another domain using Kerberos, a user's workstation first requests a ticket from a domain controller in its account domain to the server (hosting the resource) in the trusting domain. This ticket is then issued by an intermediary trusted by the workstation and the server. The workstation presents this trusted ticket to the server in the trusting domain for authentication. The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when a computer running Windows 2000 Professional, Windows 2000 Server, Windows XP Professional, or a member of the Windows Server 2003 family attempts to access resources from a server located in another domain.

1.

User1 logs on to Workstation1 using credentials from the child1.microsoft.com domain. As part of this process, the authenticating domain controller issues User1 a ticket-granting ticket (TGT). This ticket is required to be authenticated to resources. The user then attempts to access a shared resource (\\fileserver1\share) on a file server located in the child2 domain.

2.

Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 service principal name (SPN).

3.

ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the forest contain this SPN. The global catalog sends the requested information back to ChildDC1.

4. 5.

ChildDC1 sends the referral to Workstation1. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ChildDC2) in the Child2 domain. ForestRootDC1 sends the referral to Workstation 1.

6.

Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for the user to gain access to FileServer1.

7.

Now that Workstation1 has a service ticket, it sends the service ticket to FileServer1, which reads the user's security credentials and constructs an access token accordingly.

Each domain has its own set of security policies that do not cross from one domain to another. For more information, see Domains.

Planning your access control strategy for multiple domains

It is recommended that you carefully plan the most efficient access control strategy for your organization's resource needs. Your design and implementation of security groups throughout each domain in a single forest will be an important factor to consider during your planning. For information about planning an access control strategy for multiple forests, see Accessing resources across forests. It is important to understand the following security group concepts before you begin the planning process: Security groups. User rights can be applied to groups in Active Directory while permissions can be assigned to security groups on member servers hosting a resource. For more information, see Group types. Group nesting. The ability to nest security groups is dependent on group scopes and domain functionality. For more information, see Nesting groups. Group scope. Group scope helps determine the domain-wide and forest-wide access boundaries of security groups. For more information, see Group scope. Domain functionality. The domain functional level of the trusting and trusted domains can affect group functionality such as group nesting. For more information, see Domain and forest functionality. Once you have gained a thorough understanding of security group concepts, determine the resource needs of each department and geographical division to assist you with the planning effort.

Best practices for controlling access to shared resources across domains

By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other domains. Consider the following best practices: Organize domain users based on administrative needs, such as their locations or departments, and then create a global group, and add the appropriate user accounts as members. For example, add all employee user accounts in the Sales department to the Sales Department global group, and add all employee user accounts in the Accounting Department to the Accounting Department global group. Create a domain local group, and add all global groups from the other domains that need the same access to a resource in your domain. For example, employees in the Sales Department and Accounting Department global groups located in DomainA use similar print resources located in DomainB. To make future administration changes more

flexible, create a domain local group called Print Resources in DomainB, and add as members both the Sales Department and Accounting Department global groups in DomainA. Assign the required permissions on the shared resource to the domain local group. For example, assign permissions to the Print Resources domain local group located in DomainB so that its members, including the Sales Department and Accounting Department groups from DomainA, can access the printer located in DomainB.

Selective authentication between domains in an external trust

Using Active Directory Domains and Trusts, you can determine the scope of authentication between two domains that are joined by an external trust. You can set selective authentication differently for outgoing and incoming external trusts. With selective trusts, administrators can make flexible access control decisions between external domains. For more information about how to set selective authentication, see Select the scope of authentication for users. If you use domain-wide authentication on the incoming external trust, users in the second domain would have the same level of access to resources in the local domain as users who belong to the local domain. For example, if DomainA has an incoming external trust from DomainB and domain-wide authentication is used, any user from DomainB would be able to access any resource in DomainA (assuming that they have the required permissions). If you set selective authentication on an incoming external trust, you need to manually assign permissions on each resource to which you want users in the second domain to have access. To do this, set a control access right Allowed to authenticate on an object for that particular user or group from the external domain. When a user authenticates across a trust with the Selective authentication option enabled, an Other Organizationsecurity ID (SID) is added to the user's authorization data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is authenticated, if the Other Organization SID is not already present, then the server adds the This Organization SID. Only one of these special SIDs can be present in an authenticated user's context. For more detailed information about how selective authentication works, see Security Considerations for Trusts. Administrators in each domain can add objects from one domain to access control lists (ACLs) on shared resources in the other domain. You can use the ACL editor to add or remove objects residing in one domain to ACLs on resources in the other domain. For more information about how to set permissions on resources

Accessing resources across forests

When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests. For more information about routing authentication requests across forests, see Routing name suffixes across forests. Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource computer must be resolved to a location in the other forest. An SPN can be one of the following: Domain Name System (DNS) name of a host DNS name of a domain Distinguished name of a service connection point object

y y y

When a workstation in one forest attempts to access data on the resource computer in another forest, Kerberos contacts the domain controller for a service ticket to the SPN of the resource computer. Once the domain controller queries the global catalog and identifies that the SPN is not in the same forest as the domain controller, the domain controller sends a referral for its parent domain back to the workstation. At that point, the workstation queries the

parent domain for the service ticket and follows the referral chain until it gets to the domain where the resource is located. The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when computers running Windows 2000 Professional, Windows XP Professional, Windows 2000 Server, or a member of the Windows Server 2003 family attempt to access resources from a computer located in another forest.

1.

User1 logs on to Workstation1 using credentials from the child.microsoft.com domain. The user then attempts to access a shared resource on FileServer1 located in the msn.com forest.

2.

Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 SPN.

3.

ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the microsoft.com forest contain this SPN. Since a global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match. Once a match is found, the global catalog provides a routing hint back to ChildDC1.

4. 5.

ChildDC1 sends a referral for its parent domain back to Workstation1. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of the msn.com forest.

6.

Workstation1 contacts ForestRootDC2 in the msn.com forest for a service ticket to the requested service.

7.

ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to ForestRootDC2.

8. 9.

ForestRootDC2 then sends the referral to child.msn.com back to Workstation1. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to FileServer1.

10. Now that workstation1 has a service ticket, it sends the server service ticket to FileServer1, which reads User1's security credentials and constructs an access token accordingly. When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in a TDO. Trusted namespaces include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO objects are replicated to the global catalog. For more information about TDOs, see Trusts.

Routing hints
Routing hints are only used when all traditional authentication channels (local domain controller and then global catalog) have failed to produce a location of a SPN. Routing hints help direct authentication requests toward the destination forest. When an SPN cannot be located in the domain from where the network logon request originated or from the global catalog database, the global catalog checks the forest trust TDO for trusted name suffixes located in the other forest that might match the suffix in the SPN. If a match is found, the forest root domain returns a routing hint back to the original source computer so that it can continue the SPN location process in the other forest. Notes Routing hints can only reference trusted name suffixes that are listed in the TDO for its forest trust. They do not verify the name suffix before sending the hint back to the original source computer. Accessing NetBIOS names and Kerberos delegation across forest trusts is not supported. NTLM is fully supported and cannot be disabled.

Planning your access control strategy for multiple forests

It is recommended that you carefully plan the most efficient access control strategy for your organization's resource needs. Your design and implementation of security groups throughout each forest will be an important factor to consider during your planning. For information about planning an access control strategy for multiple domains, see Accessing resources across domains. It is important to understand the following security group concepts before you begin the planning process: Security groups. User rights can be applied to groups in Active Directory while permissions can be assigned to security groups on member servers hosting a resource. For more information, see Group types. Group nesting. The ability to nest security groups is dependent on groups scopes and domain functionality. For more information, see Nesting groups. Group scope. Group scope helps determine the domain-wide and forest-wide access boundaries of security groups. For more information, see Group scope.

Domain functionality. The domain functional level of the trusting and trusted domains can affect group functionality such as group nesting. For more information, see Domain and forest functionality.

Once you have gained a thorough understanding of security group concepts, determine the resource needs of each department and geographical division to assist you with the planning effort.

Best practices for using security groups across forests

By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other forests. Consider the following best practices: To represent the sets of users who need access to the same types of resources, create role-based global groups in every domain and forest that contains these users. For example, users in the Sales Department in ForestA require access to an order-entry application that is a resource in ForestB. Account Department users in ForestA require access to the same application, but these users are in a different domain. In ForestA, create the global group SalesOrder and add users in the Sales Department to the group. Create the global group AccountsOrder and add users in the Accounting Department to that group. To group the users from one forest who require similar access to the same resources in a different forest, create universal groups that correspond to the global group roles. For example, in ForestA, create a universal group called SalesAccountsOrders and add the global groups SalesOrder and AccountsOrder to the group.

Note Universal groups are not available as security groups in Windows 2000 Server mixed-mode domains or in Windows Server 2003 domains that have a domain functional level of Windows 2000 mixed. They are available as distribution groups.

To assign permissions to resources that are to be accessed by users from a different forest, create resource-based domain local groups in every domain and use these groups to assign permissions on the resources in that domain. For example, in ForestB, create a domain local group called OrderEntryApp. Add this group to the access control list (ACL) that allows access to the order entry application, and assign appropriate permissions. To implement access to a resource across a forest, add universal groups from trusted forests to the domain local groups in the trusting forests. For example, add the SalesAccountsOrders universal group from ForestA to the OrderEntryApp domain local group in ForestB.

When a new user account needs access to a resource in a different forest, add the account to the respective global group in the domain of the user. When a new resource needs to be shared across forests, add the appropriate domain local group to the ACL for that resource. In this way, access is enabled across forests for resources on the basis of group membership. For more information, see Set permissions on a shared resource.

Selective authentication between forests

Using Active Directory Domains and Trusts, you can determine the scope of authentication between two forests that are joined by a forest trust. You can set selective authentication differently for outgoing and incoming forest trusts. With selective trusts, administrators can make flexible forest-wide access control decisions. For more information about how to set selective authentication, see Select the scope of authentication for users.

If you use forest-wide authentication on an incoming forest trust, users from the outside forest have the same level of access to resources in the local forest as users who belong to the local forest. For example, if ForestA has an incoming forest trust from ForestB and forest-wide authentication is used, users from ForestB would be able to access any resource in ForestA (assuming they have the required permissions). If you decide to set selective authentication on an incoming forest trust, you need to manually assign permissions on each computer in the domain as well as the resources to which you want users in the second forest to have access. To do this, set a control access right Allowed to authenticate on the computer object that hosts the resource in Active Directory Users and Computers in the second forest. Then, allow user or group access to the particular resources you want to share. When a user authenticates across a trust with the Selective authentication option enabled, an Other Organization security ID (SID) is added to the user's authorization data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is authenticated, then the server to which he authenticates adds the This Organization SID if the Other Organization SID is not already present. Only one of these special SIDs can be present in an authenticated user's context. For more detailed information about how selective authentication works, see Security Considerations for Trusts. Administrators in each forest can add objects from one forest to access control lists (ACLs) on shared resources in the other forest. You can use the ACL editor to add or remove objects residing in one forest to ACLs on resources in another forest. For more information about how to set permissions on resources

Routing name suffixes across forests

Name suffix routing is a mechanism used to manage how authentication requests are routed across Windows Server 2003 forests that are joined together by forest trusts. To simplify administration of authentication requests, when a forest trust is initially created, all unique name suffixes are routed by default. A unique name suffix is a name suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or DNS forest or domain tree name, that is not subordinate to any other name suffix. For example, the DNS forest name microsoft.com is a unique name suffix within the microsoft.com forest. Forests can contain multiple unique name suffixes, and all children of unique name suffixes are routed implicitly. In Active Directory Domains and Trusts, name suffixes appear with an asterisk (*) at the beginning because of this. For example, if your forest uses *.microsoft.com as a unique name suffix, then authentication requests for all children of microsoft.com (*.child.microsoft.com) will be routed because the child domains are part of the microsoft.com name suffix. If a forest trust exists between two forests, then name suffixes that do not exist in one forest can be used to route authentication requests to a second forest. When a new child name suffix (*.child.widgets.com) is added to a unique name suffix (*.widgets.com), the child name suffix will inherit the routing configuration of the unique name suffix to which it belongs. Any new unique name suffixes that are created after a forest trust has been established will be visible in the forest trust Properties dialog box after you verify the trust. However, routing for those new unique name suffixes will be disabled by default. For more information about how to verify a trust, see Verify a trust. When a duplicate name suffix is detected, the routing for the newest name suffix will be disabled by default. For more information about how to route name suffixes, see Enable or disable an existing name suffix from routing. Administrators can use the forest trust Properties dialog box to manually prevent authentication requests for specific name suffixes from being routed to a forest. Notes Do not add the @ sign to the UPN suffix or a user name. When authentication requests are routed to a trusted forest, all characters before the first @ symbol are interpreted as the user name and everything after the first @ symbol as the UPN suffix.

The Local Security Authority (LSA) will block routing to any UPN suffix that is not a valid DNS name. For example, adding an @ symbol to a UPN suffix will cause it to automatically be disabled.

Collision detection
When two Windows Server 2003 forests are linked by a forest trust, there is a possibility that unique name suffixes existing in one forest might collide with unique name suffixes located in the second forest. Collision detection guarantees that each name suffix will only be routed to a single forest. Active Directory Domains and Trusts will detect a name suffix conflict when: The same Domain Name System (DNS) name is already in use. The same NetBIOS name is already in use. A domain security ID (SID) conflicts with another name suffix SID.

y y y

When a name suffix in a forest conflicts with a new forest trust partner or when a name suffix in an existing forest trust conflicts with a new forest trust partner, the name will be disabled in the new trust. For example, a conflict will occur if one forest is named widgets.com and the second forest is named sales.widgets.com. Despite the name suffix conflict, routing will still work for any other unique name suffixes in the second forest. For another example, assume that the msn.com forest needs to establish a two-way, forest trust with the widgets.com forest. Both msn.com and widgets.com have identical UPN suffixes of microsoft.com. During the creation of the two-way, forest trust, the New Trust Wizard will detect and display the conflict between the two UPN name suffixes and then create the forest trust. If Active Directory Domains and Trusts detects a name suffix conflict with a trust partner domain, access to that domain from outside the forest may be denied. However, access to the conflicted domain from within its forest will function normally. For example, if the domain widgets.com exists in both the msn.com and microsoft.com forests, users within the msn.com forest will be able to access resources in widgets.com domain that resides in the msn.com forest. However, users in the msn.com forest will be denied access to resources in the widgets.com domain located in the microsoft.com forest. Conflicts will be listed in Active Directory Domains and Trusts, in the forest trust Properties dialog box, on the Name Suffix Routing tab. If a name suffix conflict is detected during the creation of the forest trust, then the New Trust Wizard will prompt you to save a log file of the conflicts. You can also save a log file after a trust has been created. For more information about how to save this log file, see Change the routing status of a name suffix. If a NetBIOS or domain SID conflict exists, Active Directory Domains and Trusts identifies the name suffixes routing status as enabled or disabled with exceptions, as appropriate. The details about where the conflict exists are listed in the log file. You can also use the Netdom command-line tool to list all routed names and to enable and disable routing for NetBIOS names and SIDs. For example, a forest named microsoft.com has a forest trust with widgets.com and you also need to add a forest trust to msn.com. Both widgets.com and msn.com have child domains with the NetBIOS name of SALES (and DNS names of USsales.widgets.com and sales.msn.com). After you create the new trust to msn.com, routing to the SALES domain name in msn.com will be disabled. If you need to use the name SALES to route to the msn.com forest but don't need to use it to the widgets.com forest, you can use Netdom to disable SALES in widgets.com, and then enable it in msn.com