Things You Should Not Forget About Using Security Groups Across Forests
Extracted from Accessing resources across forests. (Combine it, if needed, with Group Scope information from TechNet).
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.