Configure and verify an LDAP connection

Separate directory authentication from account management

LDAP means Lightweight Directory Access Protocol. It provides operations for accessing directory entries, including searches and authentication through a bind operation. A Lexoh LDAP integration uses the configured directory connection as part of operator sign-in; confirm the controls available in your installation before configuration.

Directory authentication, creation of a Lexoh account, group-to-role mapping and browser single sign-on are separate capabilities. Define which system owns each task. An LDAP connection alone does not establish automatic synchronization, account creation, multifactor authentication or permission assignment.

Identify the responsible directory and Lexoh administrators, the intended users and a designated test account. Record the current configuration and an approved recovery procedure before changing authentication settings.

Match the endpoint, port and TLS mode

Obtain the endpoint from the directory administrator. Check whether the Lexoh field expects a hostname or a complete URI; use the documented format. The connection originates from the application’s hosting environment, so verify name resolution, routing and firewall access there.

Transport Layer Security (TLS) protects a connection when correctly configured. LDAPS starts TLS when the connection is established; StartTLS upgrades an LDAP connection. Confirm the mode actually supported by both the directory and the installed Lexoh connector. Selecting a port alone does not enable or verify encryption.

Certificate verification

Validate the server identity against the configured endpoint, the certificate’s validity and the trusted chain from the application environment. Keep verification enabled. An IP address needs an appropriate certificate identity match; changing a hostname to an IP can introduce a certificate mismatch.

Protocol and endpoint references: OpenLDAP TLS guide. Microsoft directory ports.

Distinguish the search base from the bind identity

A distinguished name (DN) identifies an entry in the directory tree. The search base is the entry where a search starts; the search scope determines which surrounding entries are considered. A bind identity is used to authenticate a connection. These values serve different purposes and need not be the same.

For illustration, ou=People,dc=example,dc=com is a possible search base. The parts ou, dc and cn commonly mean organizational unit, domain component and common name; uid denotes a user identifier attribute. Actual entries and naming rules come from your directory, not from the website or email domain alone.

Copy the required DN from an authorized directory view and confirm that the designated user is inside the selected search scope. DN strings and search filters have different escaping rules. Do not add escapes to a user’s password as a general troubleshooting step; report a handling problem to the administrator without sharing the secret.

Syntax references: RFC 4514 — distinguished names. RFC 4515 — search filters.

Verify each stage of the sign-in flow

The sequence below describes a common search-and-bind arrangement, not a confirmed internal implementation of every Lexoh deployment. Other arrangements can use a directly supplied bind identity or a different authentication mechanism. Confirm the installed connector’s design.

1. The application establishes the intended directory connection and required transport protection.
2. If a lookup is required, the configured search identity locates the intended entry using the agreed base, scope and identifier attribute. Confirm that the lookup selects exactly the expected user.
3. The directory evaluates the configured authentication operation. A successful network connection or search is not evidence of a successful user authentication.
4. The application resolves the authenticated identity to its account and evaluates the applicable account state, roles and restrictions before the operator uses a feature.
5. Test the resulting application session and permitted actions. Later directory changes may have different effects on new sign-ins and existing sessions; verify the supported revocation process.

Define identity and group mappings explicitly

User identity

Confirm the accepted sign-in format and the searched attribute, such as uid, sAMAccountName or userPrincipalName where appropriate. Do not assume these attributes have identical values. Check how a directory identity is linked to an existing Lexoh record and how renamed users or duplicate display names are handled.

Search account

If a separate bind or service account is required, give it only the approved directory-read scope. Record its owner and credential-rotation procedure. This account is distinct from the operator whose sign-in is being evaluated.

Group-to-role mapping

Where mapping is supported, review the exact source groups, target roles and rule precedence. Test absent membership, multiple memberships and nested groups as applicable. A directory group name does not by itself establish a Lexoh permission.

Provisioning and removal

Confirm whether accounts are created manually, at first sign-in or by a separate synchronization process. Record update timing and failure behavior. Test what happens after removal from an authorized group or disabling the directory user, including any remaining local sign-in route and existing sessions.

Use examples only after verifying the directory

Active Directory Domain Services

Obtain the approved domain-controller endpoint, transport mode and search settings from the directory team. A user principal name, short account name and full distinguished name are different identity formats. Use the one accepted by the configured flow.

OpenLDAP

An illustrative setup might use ldap.example.com, TCP 636 with TLS on connection, and ou=People,dc=example,dc=com as a search base. These are sample values, not a working Lexoh configuration. Confirm the actual certificate name, directory entries, schema and user-matching attribute.

Microsoft Entra Domain Services

Microsoft Entra Domain Services can provide a managed LDAP endpoint. Microsoft Entra ID and Domain Services are distinct services; a tenant name ending in onmicrosoft.com is not sufficient evidence of a usable LDAP endpoint. Follow the managed domain’s configured secure-LDAP endpoint, DNS, certificate and network requirements.

Microsoft service and setup references: Compare Microsoft identity services. Configure secure LDAP for Domain Services.

Test without losing administrative access

1. Keep a separately verified, authorized recovery path available. Record the original configuration and planned rollback; do not sign out of the only working administrator session before testing.
2. Save the approved endpoint, transport and mapping settings, then reopen the configuration to verify the stored non-secret values. Use a supported connection test if available and record which stages it actually checks.
3. Use a separate browser session and the designated test identity to verify sign-in, the correct account association and a required action. Check an excluded action and out-of-scope record with approved test data.
4. Coordinate invalid-credential and disabled-account tests with the directory administrator to avoid unintended lockouts. Verify the denied outcomes and the relevant logs, rather than treating the absence of a visible error as proof.
5. Check a role or group change with both an existing session and a new sign-in. Record propagation timing and the supported revocation procedure. Coordinate any equipment command test with site operations.
6. Record the application and directory versions, time, non-secret configuration references, expected results and observed results. Resolve failures or restore the approved prior configuration before wider rollout.

Locate the failing connection stage

Connection refused or timeout

Check resolution, routing, the selected TCP port, service availability and firewall rules from the application environment. A successful ping or open TCP port alone does not verify TLS, LDAP search or authentication.

Certificate or TLS failure

Review endpoint identity, certificate dates, chain trust and matching transport modes. Correct the certificate, trust configuration or endpoint with the responsible administrator. Keep verification enabled during testing; bypassing it would leave the intended security check untested.

User not found or ambiguous result

Review search base, scope, identifier attribute, filter and search-account permissions. Confirm the expected entry with authorized directory tools. Investigate multiple matches before granting access.

Authentication rejected

Check the accepted identity format, user state, lockout and expiry policies and the selected authentication method. Inspect the relevant directory result without repeatedly retrying credentials or changing passwords in the wrong system.

Sign-in works but permissions are wrong

Inspect the linked Lexoh account, role assignment, record scope and any group mapping or synchronization rules. Compare existing and new sessions. Avoid granting unrestricted access simply to bypass an unexplained denial.

Maintain the connection and its recovery procedure

Assign owners for certificate renewal, search-account credentials, network access and directory mappings. Limit connectivity to the application’s required sources and protect any stored secrets through the deployment’s supported controls.

Review changes to directory structure, user attributes, groups and authentication policies before rollout. Retest sign-in and permission boundaries after a relevant change, and keep a dated record of results. General LDAP references describe the protocol; the installed Lexoh connector still needs configuration-specific verification.

Security reference reviewed September 30, 2026: RFC 4513 — authentication and security mechanisms.