Groups spanning domains with Microsoft Active Directory

The domains and forests functional levels of the Microsoft Active Directory control which configurations are available for use. How we configure Microsoft Active Directory affects how group membership is determined within WebSphere Application Server. Using groups to configure your Microsoft Active Directory installation with the product allows flexible management.

A breakdown follows of applicable functional levels that apply to a Microsoft Active Directory installation with the product.

• Domain Functional Levels
  • Native
    • Supported by Windows Server 2008 and Windows Server 2008 R2
    • Default in Windows 2008

  We must use native domain functional levels to support group nesting, and universal groups. Forest functional levels do not directly affect group membership. The Windows 2008 operating system is the exception.

• Forest Functional Levels
  • Windows Server 2008 or Windows Server 2008 R2
    • All domains operate at the Windows Server 2008 domain functional level.

      If the forest functional level is set to Windows Server 2008, then that also makes the domain functional level for all domains to be Windows Server 2008 Native level, which adds to the group nesting and Universal groups features to Microsoft Active Directory.

Microsoft Active Directory groups

In a domain, Microsoft Active Directory provides support for different types of groups and group scopes. Groups in Microsoft Active Directory are containers with other objects within them as members. Those objects can be user objects, other group objects, which is group nesting, and other objects types, such as computers. The group type determines the type of task managed with the group. The group scope determines whether the group can have members from multiple domains or a single domain. In summary:

• Groups are typically a collection of user accounts.
• Members receive permission given to groups.

• Users can be members of multiple groups.
• Groups can be members of other groups, which are nested groups.

In WAS, security roles of the individual, which map to application permissions or authorizations, must be bound to either users or groups at application deployment time. From an administrative point of view, it is preferable to assign permissions once for a group instead of assigning permissions repeatedly for each user account. Then the ability to act in a given role is under the control of the directory administrator, instead of the WebSphere administrator. Because the job of the directory administrator is to create and delete users, change group memberships for users, and other tasks, this approach is generally the correct division of responsibilities.

Group types determine how the group is used. The Microsoft Active Directory group types are:

• Security groups: Microsoft Active Directory uses security groups for granting permissions to gain access to resources.
• Distribution groups: Distribution groups are used by Windows-based applications as lists for nonsecurity-related functions. Distribution groups are used for sending email messages to groups of users. We cannot grant Windows permissions to distribution groups.

Although WAS can use either type of group, security groups are typically bound to WAS security roles.

Group scopes describe which type of objects can be arranged together within a group. Group nesting describes when one group is a member of other groups. The Microsoft Active Directory group scopes are:

• Domain local group:
  • Windows usage: Members of this group can come from any domain, but can access Windows resources only in the local domain. Use this scope to grant permissions to domain resources located in the same domain in which we created the domain local group. Domain local groups can exist in all mixed, native, and interim functional level of domains and forests.
  • Restriction: We cannot define group nesting in a domain local group. A domain local group cannot be a member of another domain local group or any other group in the same domain.
  • WebSphere usage: Users are not typically placed in domain - local groups due to these restrictions. WAS security roles are not typically bound to domain local groups.

• Global Group:
  • Windows usage: Members of this group originate from a local domain, but can access Windows resources in any domain. The global group is used to organize users who share similar Windows network access requirements. We can add members only from the domain in which the global group is created. Use this group to assign permissions to gain access to Windows resources located in any domain in the domain, tree, or forest.

    We can group users with similar function under global scope and give permission to access a Windows resource, such as a printer or shared folder and files, that is available in local or another domain in the same forest. Use global groups to grant permission to gain access to Windows resources located in any domain in a single forest as their memberships are limited. We can add user accounts and global groups only from the domain in which global group is created.

    Nesting is possible for global groups within other groups as we can add a global group into another global group from any domain. Members of a global group can be members of a domain - local group. Global groups exist in all mixed, native, and interim functional levels of domains and forests.

  WAS usage: Global groups are visible on every domain controller, but memberships are only visible for local users. That is, we can see your group memberships only if you query your home domain controller. A global group should contain groups of users. Global groups are intended to be included in universal groups.

• Universal Group:
  • Windows usage: Members in this group can come from any domain and access Windows resources in multiple domains. Universal group memberships are not limited like global groups. All domain user accounts and groups can be members of a universal group.
  • Restrictions:
    • Universal groups are available when the domain is at a Windows mixed functional level.
    • It can be expensive to replicate this data across the forest. Group definitions and deletions are relatively rare compared to the equivalent user actions, and nested group membership changes are typically rare compared to memberships of users within groups,

      Consult appropriate Microsoft Active Directory information concerning any implications of replicating data across forests.

  • WebSphere usage:
    • Universal Groups and their memberships are visible on every domain controller in the forest.
    • Universal groups are also visible when using the Global Catalog. To be useful, all user objects must be directly in the universal group,

  Universal group guidelines

  1. Assign permissions to universal groups for Windows resources in any domain in the network.

  2. Use universal groups only when their membership is static. Changes in membership can cause excessive network traffic between domain controllers. embership of universal groups can be replicated to many domain controllers.

  3. Add global groups from several domains to a universal group.

  4. Assign permissions for access to a Windows resource to the universal group and for use by WAS group membership resolution across multiple domains.

  5. Use a universal group in the same way as a domain local group to assign resource permissions.

When we select any of these scenarios, consult the appropriate Microsoft Active Directory information to completely understand any implications the scenarios might have on your configuation planning.

Related:

Microsoft Active Directory Global Catalog

Options for finding group membership within a Microsoft Active Directory forest

Authentication using Microsoft Active Directory

Locating user group memberships in a LDAP registry

Authenticating users with LDAP registries in a Microsoft Active Directory forest