Most organisations manage user identity on LDAP or Active Directory. Each time a new application is added, the same question recurs: how does this application connect to the directory, authenticate the user, read group membership, and make access decisions? When every application handles this independently, the identity architecture fragments rapidly.
Per-application LDAP integration accumulates operational debt. Each application carries its own service account, connection string, search filter, timeout settings and certificate validation configuration. When the directory schema changes, an OU is moved, a service account password is rotated or a domain migration occurs, that change ripples across every application individually.
Security risk grows as well. Plain LDAP exposes passwords in transit. Service account credentials are stored in application configuration files. Group-based authorisation logic is spread across individual application codebases, so authentication and access policy are enforced by different systems under different rules.
Audit and visibility suffer too. Which application connected to the directory using which service account, which user was authenticated, which group was queried, which access was denied — this information is buried in individual application logs and never reaches a centralised identity audit stream. SOC and compliance teams end up correlating scattered logs instead of reviewing a coherent identity trail.
TR7 LDAP/AD Bind resolves this at the access platform level: direct-bind and search-bind methods, LDAPS secure transport, group membership queries, bind restriction filters, multi-server failover and AAM conditional access policy converge in a single architecture.
TR7 AAM treats LDAP/AD connectivity not merely as password verification but as a full flow — user search, group query, secure transport and access policy generation.
Direct-bind converts the username to a bind principal using UPN, NetBIOS, UID, CN or a custom pattern. Search-bind locates the user DN via a service account first, then validates the user's own password against that DN.
In search-bind mode, group lookup can be enabled and the user's group memberships are added to the AAM session. This data drives application access, MFA enforcement and backend-level authorisation decisions.
TR7 establishes TLS-protected connections over LDAPS. Certificate validation behaviour and self-signed certificate policy are configurable, aligning directory connection security with organisational standards.
Multiple LDAP/AD servers can be defined in a single configuration. Connections are distributed using round-robin, weighted or failover methods; when the primary directory server becomes unavailable, an alternative is used automatically.
LDAP/AD Bind connects enterprise directory authentication to the AAM flow through bind templates, search filters, group membership, secure transport and multi-server management.
In direct-bind mode the username is converted to a bind principal using one of five templates: UPN, NetBIOS, UID, CN or a custom pattern. UPN and NetBIOS are common in Active Directory environments; UID and CN are typically used with OpenLDAP or POSIX directories. A custom pattern such as uid={{username}},ou=people,dc=company,dc=com supports organisation-specific structures. This flexibility makes it straightforward to connect different directory schemas to a single AAM authentication flow.
In search-bind mode TR7 first connects to the directory using a service account and retrieves the user's DN. Once found, the user's own DN and password are used for the bind operation. This model suits environments where users are spread across multiple OUs, where the DN cannot be derived directly from the username, or where a more controlled search filter is required. The service account and search base DN are managed centrally.
The search-bind filter can evaluate userPrincipalName, sAMAccountName and cn together in automatic mode. In custom mode the operator defines their own LDAP filter — for example (sAMAccountName={{username}}) for a narrower search. This approach accommodates different directory schemas and username formats. Filters should be defined as precisely as possible to avoid unintended user matches.
Even when a user's password is correct, not every directory user should reach every application. A bind restriction filter ensures that only users meeting a specific OU, group or attribute condition pass through the authentication flow. For example, only members of the VPN Users group may be admitted to a particular backend. This filter evaluates identity verification and access scope in the same step.
When ldapEnableGroupSearch is enabled, TR7 queries the user's group memberships using the user DN. ldapGroupSearchBase and ldapGroupFilter determine which directory branch to search and what filter to apply. The resulting group list is added to the AAM session. Conditional access flows can use this information to grant or deny application access, require MFA, or apply backend-level permissions.
When LDAPS is in use, the LDAP connection is protected by TLS and typically runs on port 636. Server certificate validation behaviour is configurable through sslValidateCertificate and sslAllowSelfSigned. Plain LDAP should not be used in production. Securing the directory connection is a baseline requirement for protecting sensitive data such as user passwords and service account credentials in transit.
LDAP connection and operation timeout values are configurable. If a connection cannot be established or a directory server responds slowly, the AAM flow does not wait indefinitely. Slow domain controller behaviour during peak hours or network segment latency can be managed through these settings. Timeout values should be planned in conjunction with user experience requirements and failover behaviour.
TR7 can pull users from a specified search base and transfer attribute values such as mail and phone number to the AAM local user profile. Fields such as queryMailField and queryPhoneField can be adjusted to match the organisation's schema. This feature assists with user list and contact information management. In a cluster environment, user list retrieval is limited to the primary node only.
Multiple LDAP/AD servers can be defined in the hosts array. lbMethod can be set to round-robin, weighted or failover. In failover mode, when the primary server becomes unavailable, traffic switches to an alternative. Connection pooling and circuit breaker behaviour reduce the impact of persistently failing servers on the overall flow.
The network namespace used to reach the LDAP server is configurable. This is relevant for domain controllers in isolated segments or tenant-specific directory structures. Access management traffic travels through the correct routing table and network isolation layer. Multi-tenant and segmented data centre architectures benefit from the finer network control this provides.
LDAP/AD Bind is operated with attention to connection lifecycle, filter safety, connection cleanup, search-bind behaviour, cluster constraints and attribute selection.
When LDAP settings are updated, connection information is rebuilt and the authentication flow operates with the new configuration. Connection details are derived from protocol, host, port, TLS and timeout parameters. Applying setting changes within a central lifecycle ensures configuration consistency across the platform.
Special characters in user input are escaped before being inserted into LDAP filters. Backslash, asterisk, parentheses and null characters are escaped following LDAP rules to reduce the risk of injection. This behaviour is particularly important in configurations that use custom filters.
After each LDAP operation the client is destroyed and event listeners are removed. This approach prevents zombie connections and unnecessary memory retention. Long-lived keep-alive behaviour is used only in specific modes such as user list retrieval.
The automatic search-bind filter evaluates userPrincipalName, sAMAccountName and cn together. In custom filter mode the operator defines their own LDAP expression. Custom filters are powerful but must be designed carefully — an overly broad filter can lead to unintended user matches.
The next-generation LDAP backend pool manages LDAP client connections using a pool model. When LDAPS is selected, TLS options are included in the connection setup. Custom DNS lookup time and connection timeout values become significant in slow or segmented networks.
User list retrieval is restricted to run only on the primary node in a cluster environment. This prevents the same list from being fetched concurrently by multiple nodes and avoids unnecessary load on the directory server. The authentication bind flow continues to operate across all cluster nodes according to the configured connection model.
The ldapAttributes array controls which directory fields are returned. Default fields can include dn, cn, userPrincipalName, displayName, mail and phone number. Additional attributes such as department, employeeID or custom fields can be added to the list based on organisational requirements.
In a large enterprise, employees access applications through AAM using their existing AD credentials. Group memberships are carried into AAM policy; finance, HR and IT groups can be directed to different applications or MFA flows. When the AD password policy changes, individual applications do not need to be updated.
In an environment with two domain controllers across two data centres, TR7 can connect using failover mode. When the primary directory server becomes unreachable, traffic switches to the alternate automatically. The user authentication flow is not tied to a single domain controller.
A particular backend can be opened exclusively to members of the VPN Users group. Even when a bind succeeds, users who do not pass the bindRestrictionFilter are rejected. This ensures password verification and application access authorisation are not treated as the same thing.
Organisations using OpenLDAP instead of Active Directory can authenticate users with UID or CN bind templates. Mail, phone and custom attribute mappings from posixAccount-based directories can be brought into the AAM profile. Connecting legacy LDAP directories to a modern access flow is possible over LDAPS for secure transport.
LDAP/AD connectivity, group-based policy, LDAPS secure transport and centralised audit on a single platform. Let us walk you through a live setup on your own environment.