Accessing resources across domains
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
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.
.gif "Kerberos authentication process")
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.
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).
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.
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.
Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for the user to gain access to FileServer1.
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, see Set permissions on a shared resource.
For information about setting authentication restrictions for multiple forests, see Accessing resources across forests.