Authentication using Microsoft Active Directory
Many installations use the Microsoft Active Directory as their primary component for managing user authentication and user data. One portion of the Microsoft Active Directory provides a LDAP service. WebSphere Application Server supports LDAP and, therefore, WAS supports the Microsoft Active Directory.
While the Microsoft Active Directory is fully LDAP-compliant, it exposes LDAP information in ways that can make it difficult to obtain directory information for WAS.
WAS operates in a way that assumes that a single LDAP directory contains all the information necessary to operate. With complex Microsoft Active Directory configurations, this is not the case. WAS - Microsoft Active Directory installations must handle unique challenges because of the way data is spread throughout the domain controllers in a forest.
Microsoft Active Directory installations frequently incorporate the use of a forest. As such, security questions pertaining to user ID uniqueness, reliably obtaining user group information, and group membership spread across forests become important.
The following figure highlights a typical Microsoft Active Directory installation environment.
Figure 1. Microsoft Active Directory forests . An illustration of Microsoft Active Directory forests.
This figure illustrates two forests of one or more trees. A tree can contain one or more domains where the domain is the single atomic unit that forms the basis for the constructed environment. Each domain is made up of the primary domain components of the distinguished name (DN), for example, dc=acme, dc=com. A forest can extend trust to other forests (This trust is based on Kerberos.).
Microsoft Active Directory configurations with WAS
There can be a variety of Microsoft Active Directory configurations for WAS, which include:
- Simple configuration
- Typical configuration
- Less typical configurations
- Rare configurations
The simplest configuration consists of a stand-alone LDAP registry representing a single domain. This configuration represents the closest fit between WAS and the Microsoft Active Directory. In this configuration, Microsoft Active Directory is supported through the WAS stand-alone LDAP user registry implementation. Alternatively, we can access this single Microsoft Active Directory domain through a federated repositories registry, which contains a single LDAP repository.
Beyond the simple single domain Microsoft Active Directory configuration, a typical Microsoft Active Directory configuration consists of a single tree in a forest where each branch of the tree is a domain. An example of this configuration, which consists of a single tree of four domains (A, B, C, D), is shown in the following example:
Figure 2. Typical forest configuration . Typical forest configuration.
Configurations, such as this configuration, frequently have domains that are organized by geography or organizational unit. The WAS registry configuration necessary to use this "single tree"Microsoft Active Directory implementation needs to use the federated repositories. This configuration contains an LDAP registry to map entries from multiple individual user repositories into a single virtual repository. These configurations create a federated user repository with a single named realm and an LDAP subtree within the single repository. The root of the repository is mapped to a base entry within the federated repository, which is the starting point within the hierarchical namespace of the virtual realm. LDAP searches in this configuration proceed with binding to the top domain object and following LDAP referrals.
The stand-alone LDAP registry in WAS does not support LDAP referrals and cannot be used in a WAS - Microsoft Active Directory configuration.
Less typical WAS - Microsoft Active Directory configurations evolve from mergers of organizations units in a larger enterprise. Where a single forest of domains once served the enterprise, the merger of several new organizational units can add trees to the forest or even add more than a single forest to the environment. In this environment, the WAS LDAP configuration requires more careful design. We must use the federated repositories registry in such an environment with separate LDAP repositories mapped to the top of each tree in the forest. Again, if a Microsoft Active Directory tree exists under the top-level domain, LDAP referrals must be enabled for the LDAP registry. The forest resulting from a merger can look like the following figure:
Figure 3. Less typical configurations . Less typical configurations that depict the merger of trees
Rare configurations consist of Microsoft Active Directory domains configured where there is a combination of a user forest and a group forest. Users are imported as ForeignSecurityPrincipals objects in the group forest. The groups contain the distinguished names (DN) of the ForeignSecurityPrincipals objects as members.
In this form of configuration, direct group lookups do not occur. Lookups are relegated to a static group query across multiple registries. This configuration requires a custom user registry. However, WAS registries do not support this type of configuration. See the following figure.
Figure 4. Resource model forest . An illustration of a resource model forest.
Use a Microsoft Active Directory forest as LDAP - user filter
Authenticating a user across multiple repositories, or across a distributed LDAP, such as a Microsoft Active Directory forest configuration can be challenging. In any search of the whole registry, authentication fails if there is more than one match at run time because ambiguous matches result. In multiple Microsoft Active Directory domain environment, the WAS administrator must consider that the default unique ID in the Microsoft Active Directory is the sAMAccountName attribute of a user. User IDs are guaranteed to be unique within a single domain, but it is not possible to guarantee that a given user ID is unique across a tree or a forest. See the topic, "Authenticating users with LDAP registries in a Microsoft Active Directory forest"to understand how to search for user IDs within a Microsoft Active Directory forest using the sAMAccountName attribute of a user.
Before selecting any of these scenarios, consult appropriate Microsoft Active Directory information to completely understand any implications the scenarios might have on the configuration planning.
Related: