WAS v8.5 > Secure applications > Authenticate users > Use Microsoft Active Directory for authentication

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 Platform Enterprise Edition (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.

    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.

  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.

Finding group membership.. The following table identifies group membership levels supported in 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 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 dmgr console to complete the search filter with the objectCategory attribute.

1. Click Security > Global Security.

2. 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.

3. Under Related items, click Manage repositories.

4. Select Forest > LDAP entity types > PersonAccount. Under General Properties, find the Search filter box.
5. Fill in the search filter.
   (objectCategory=user)

When you 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 concepts:

Authentication using Microsoft Active Directory
Groups spanning domains with Microsoft Active Directory
Options for finding group membership within a Microsoft Active Directory forest

Related

Locating user group memberships in a LDAP registry
Authenticate users with LDAP registries in a Microsoft Active Directory forest

+

Search Tips   |   Advanced Search