Configuring an LDAP (Active Directory) service as an OpenEdge domain’s point of user account authentication requires obtaining information about the directory service and then translating that information into a set of STS configuration properties.

It helps if you have some familiarity with directory services, particularly regarding with their organization, the stored object’s attribute names, and how to search for user accounts and other objects. The following provides some of that information and may shorten the time needed to successfully authenticate users to an LDAP service.

There is always a core set of information that you will need to obtain to configure and test user authentication via an LDAP service. Because each LDAP directory service’s hierarchical tree of objects (including user account objects) is customized for each deployment site, you must obtain information from the LDAP service administrator. All of the core information will be applied to properties (sts.ldap.xxxx) used by the STS’s LDAP authentication process. For example:

  • The LDAP directory service’s URL, including the hostname, port and base-dn information:
    sts.ldap.context.providerUrl=ldap://host[:port][/base-dn]
  • The DN (Distinguished Name) of an existing LDAP user account that may be used to search for an locate the user account being authenticated:
    sts.ldap.context.userDn=ldap-user-dn
sts.ldap.context.password=ldap-user-password
  • The information needed to build the LDAP search query used to locate the LDAP account of the user being authenticated. The search query requires the location (DN) of where to begin the search and the LDAP user account attribute name that contains the user-id of the user being authenticated:
    sts.ldap.user.searchBase=search-base-dn
sts.ldap.user.searchFilter=(attr-name={0})
    Note: Common attr-name values may be uid for UNIX LDAP servers or sAMAccountName for Windows Active Directory. Your LDAP administrator can access the attribute names for user accounts.
  • The STS LDAP user authentication requires that the LDAP user account (DN) be a member of at least one LDAP group object. So you must supply the staring location of where to begin an LDAP search, the group object’s attribute name holding the authenticated user’s DN, and the group object’s DN field name holding the group (Role) name:
    sts.ldap.group.searchBase=search-base-dn
sts.ldap.group.searchFilter=(group-attr-name={0})
sts.ldap.group.roleAttribute=cn

An example configuration may look like:

sts.ldap.context.providerUrl=ldap://ldap.acme.com:389
sts.ldap.context.userDn=uid=admin,ou=system
sts.ldap.context.password=secret
sts.ldap.user.searchBase=ou=users,o=acme,dc=acme,dc=com
sts.ldap.user.searchFilter=(uid={0})
sts.ldap.user.searchSubtree=true
sts.ldap.group.searchBase=ou=groups,o=acme,dc=acme,dc=com
sts.ldap.group.searchFilter=(uniqueMember={0})
sts.ldap.group.roleAttribute=cn

Debugging an STS LDAP authentication involves enabling logging in the STS’s logging configuration file logging.xml and adding the entry:

 <logger name=”org.springframework.security.ldap” level=”TRACE” />

Use LDAP searchFilter to locate a user entry in the directory

LDAP authentication uses a search filter to locate a user entry in the directory.

Syntax

sts.ldap.group.searchFilter=(uniqueMember={0})

Where

  • {0} is a Spring Security placeholder. At runtime, PAS for OpenEdge replaces {0} with the user ID provided during authentication.
  • ( ) follow LDAP filter syntax that defines the search condition to apply to directory entries.

Examples by directory type

Directory type Search filter Behavior
Generic LDAP (uid={0}) Matches user where uid equals login ID.
Active Directory (sAMAccountName={0}) Matches Windows login name
Alternative AD (userPrincipalName={0}) Matches full login (user@domain)

Runtime examples

If a user logs in as:

user1

And the filter is: 

(sAMAccountName={0})

The executed LDAP query becomes: 

(sAMAccountName=user1)

Result:The directory returns the matching user DN for authentication.

Configure group-to-role mapping

LDAP can assign application roles based on group membership

How it works:

  1. PAS for OpenEdge retrieves the authenticated user's Distinguished Name (DN).
  2. A group search runs to find groups containing that DN.
  3. Roles are extracted from group attributes.
  4. Roles are added to the CLIENT-PRINCIPAL object.

Example configuration


								groupSearchBase=ou=groups,dc=example,dc=com
								groupSearchFilter=(member={0})
								roleAttribute=cn

Where:

Setting Purpose
groupSearchFilter Finds groups containing the user DN
{0} Substituted with user DN (not username)
roleAttribute Extracts role name from group entry
Example

If user DN is:

cn=user1,ou=users,dc=example,dc=com

Search filter becomes:

(member=cn=user1,ou=users,dc=example,dc=com)

Multiple group membership

If user belongs to multiple groups, each group contributes a role. The roles appear in the CLIENT-PRINCIPAL. 

CLIENT-PRINCIPAL:ROLES
Result

Authorization logic in ABL can evaluate roles directly.

Configure LDAP using Active Directory

This example uses realistic Active Directory values.

Directory configuration


							provider.url=ldap://ad.example.com:389
							provider.userDn=cn=ldapbind,cn=Users,dc=example,dc=com
							provider.password=Password1!

User search


							userSearchBase=dc=example,dc=com
							userSearchFilter=(sAMAccountName={0})

Alternative

userSearchFilter=(userPrincipalName={0})

Group-to-role mapping


							groupSearchBase=dc=example,dc=com
							groupSearchFilter=(member={0})
							roleAttribute=cn

Example

Object Example
User DN cn=user1,cn=Users,dc=example,dc=com
Group DN cn=Admins,cn=Users,dc=example,dc=com

Active Directory considerations

  • Default login attribute
    • sAMAccountName
  • Alternative
    • UserPrincipalName (user@domain)
  • For large environments
    • Use Global Catalog port 3268
  • Ensure referral handling is configured if multi-domain

Result:

Configuration matches real enterprise AD deployments.