Options for finding group membership within a Microsoft Active Directory forest
Locating and finding group membership with the Microsoft Active Directory forest is necessary for authenticating users. There are several ways to approach finding group membership within the Microsoft Active Directory forest.
The following figure depicts an example of group membership with the Microsoft Active Directory forest. This figure is used to explain ways to find group membership.
Figure 1. Finding group membership.. An illustration of ways to find group membership.
- Option 1 does not use nested groups, and the following steps describe the process of locating group membership using a hypothetical organizational structure.
- Create a global group of NA employees.
- Create a global group of EU employees.
- Map the Java EE role to NA employees + EU employees. This mapping can become unmanageable if there are too many sub domains
- Enable referrals.
In WebSphere Application Server v6.1, use federated repositories, specifically:
- Use a federated realm.
- Add the Microsoft Active Directory top-level domain controller to the repository. Do not add sub-domain controllers. Doing this results in multiple matches when searches for user IDs occur. The multiple matches cause user logins to fail.
- Select "Support referrals to other LDAP servers" = "follow".
- Option 2 uses universal groups.
- Put individual users into the universal group, Employees.
Requirements:
- The Windows 2003 Native domain functional levels is required.
- Userids must be directly contained within universal groups.
- Map Java EE role to Employees.
- Connect to any global catalog in the forest.
Tip: This option reduces the amount of directory lookup traffic. WAS does not have to follow all the referrals across the directory tree. That is, each domain controller can fully resolve the group information locally.
- Option 3 uses nested groups.
- Create the universal group, Employees.
- Create NA Employees and EU Employees as global groups and make them members in the Employees universal group.
Requirements: Windows Native Domain functional levels.
- Map Java JEE role to "Employees".
- Enable referrals.
For WAS v6.1, use federated repositories, specifically:
- Use a federated realm.
- Add the Active Directory top-level domain controller to the repository. Do not add sub-domain controllers, as this will result in multiple matches when searches for userids occur, and logins will fail.
- Select "Support referrals to other LDAP servers" = "follow".
- Enable nested groups.
Tip: This option offers the optimal approach when using WAS Versions 6.1 or later. Before WAS version 6.1, referrals were not officially supported.
Summary
The following table summarizes how to find group membership within a Microsoft Active Directory forest.
Group Membership Map Java EE Roles To Bind to Which LDAP Enable Supported in WAS Version Comments Global Groups Collection of global groups Top domain controller using port 389/636 Referrals
- Federated repositories in WAS
Universal groups Universal groups Any Global catalog, using port 3268
All
Global groups in universal groups Universal groups Top domain controller using port 389/636 referrals, nesting
- Federated repositories in WAS
Cannot use Windows mixed domain functional level
Configure to use objectCategory attribute
A federated repository uses the objectCategory attribute by default for Active Directory user search filters. We can ensure that the federated repository is configured to use the objectCategory attribute. For example, the federated repositories configuration file, wimconfig.xml, should be as shown in the following example:<supportedLDAPEntryType name="user" searchFilter="(objectCategory=user)"...> <supportedLDAPEntryType name="Group" searchFilter="(objectCategory=Group)"...>Configure the user filter and group filter (advanced properties) like the following example:
User Filter: (&(sAMAccountName=%v)(objectCategory=user)) Group Filter: (&cn=%v)(objectCategory=group)Follow the following instructions from the administrative console to complete the search filter with the objectCategory attribute.
- Click Security > Global Security.
- Under Available realm definitions, select Federated repositories, and then Configure. In a multiple security domain environment, click Security domains > domain_name. Under Security Attributes, expand User Realm, and click Customize for this domain. Select the Realm type as Federated repositories and then click Configure.
- Under Related items, click Manage repositories.
- Select Forest > LDAP entity types > PersonAccount. Under General Properties, find the Search filter box.
- Fill in the search filter.
(objectCategory=user)
When we select any of these scenarios to use, consult the appropriate Microsoft Active Directory information to completely understand any implications the scenarios might have on your configuation planning.
Related:
Authentication using Microsoft Active Directory Groups spanning domains with Microsoft Active Directory Options for finding group membership within a Microsoft Active Directory forest Locating user group memberships in a LDAP registry Authenticating users with LDAP registries in a Microsoft Active Directory forest