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 Version 6.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.
- Option 3 uses nested groups.
Tip: This option offers the optimal approach when
using WebSphere Application
Server Versions 6.1 or later. Before WebSphere Application Server version 6.1,
referrals were not officially supported.
Summary
The following table summarizes how
to find group membership within a Microsoft Active
Directory forest.
Table 1. 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 WebSphere Application
Server Version |
Comments |
Global Groups |
Collection of global groups |
Top domain controller using port 389/636 |
Referrals |
- Federated repositories in WebSphere Application
Server
|
|
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 WebSphere Application
Server
|
Cannot use Windows mixed
domain functional level |
Configuring to use objectCategory attribute
A
federated repository uses the
objectCategory attribute
by default for Active Directory user search filters. You 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)
Avoid trouble: 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.
gotcha