Console terminology: In the Maverics Console, the combination of applications,
policies, headers, and connector bindings is managed through User Flows. In
YAML, these elements are configured directly within each app’s configuration block
under
apps[].policies[].What Is LDAP Provider Mode?
Many enterprise applications — especially legacy and commercial off-the-shelf (COTS) products — depend on LDAP for authentication and directory lookups. These applications perform LDAP bind operations to validate user credentials and LDAP search operations to retrieve user attributes like group memberships, email addresses, and display names. The Maverics Orchestrator’s LDAP Provider mode creates a virtual LDAP directory that presents a standard LDAP interface to these applications while sourcing identity data from modern cloud identity providers such as Azure AD, Okta, or PingFederate. Applications continue using their existing LDAP configuration — the Orchestrator handles the translation between LDAP protocol operations and cloud IdP APIs. The most common deployment pattern pairs LDAP Provider with HTTP Proxy mode in a facade architecture, where the Orchestrator handles both the browser-facing authentication (via HTTP Proxy) and the application’s backend LDAP operations (via LDAP Provider). See Step 6 for details on this pattern.Prerequisites
- A running Maverics Orchestrator — If you have not installed the Orchestrator yet, follow the Quick Start guide or see the installation reference.
- An identity provider account — You need credentials for an identity provider such as Azure AD, Okta, or PingFederate. This IdP will serve as the upstream source of identity data that the Orchestrator translates into LDAP responses.
- A target LDAP-dependent application — An application that authenticates users via LDAP bind operations or retrieves user attributes via LDAP search queries.
- Service Extension development capability (Go) — Unlike other Orchestrator modes, the LDAP Provider requires Go-based Service Extensions for its core operations. There is no declarative-only configuration path. You will need to write Service Extensions that handle LDAP bind authentication and search queries. See Service Extensions reference.
- Knowledge of your application’s LDAP expectations — You must know the bind DN format your application uses, the search base DN, the LDAP attributes it expects in search results (e.g.,
cn,sAMAccountName,memberOf), and the bind method (simple bind or SASL/NTLM).
Configure LDAP Provider Mode
Create an Orchestrator Deployment
In the Maverics Console, all configuration lives within a Deployment — a managed Orchestrator instance with its own configuration, storage provider, and signing keys. Before you can configure the LDAP Provider, you need a Deployment to hold the configuration.
- Console UI
- Configuration
- Log in to the Maverics Console.
- Navigate to Deployments in the sidebar and click Create.
-
Enter a name for your deployment (e.g.,
LDAP Provider). -
Select a deployment provider. The Console supports several options:
- Evaluation — Strata-managed storage, no infrastructure needed. Best for getting started.
- AWS S3, Azure Blob Storage, or Google Cloud Storage — customer-managed cloud storage for production.
- GitHub or GitLab — deploy bundles to a Git repository.
- Download Only — manual bundle download for air-gapped environments.
- Click Create.
Enable the LDAP Provider
The LDAP Provider must be enabled and configured at the deployment level. This sets up the virtual LDAP directory server that LDAP-dependent applications will connect to.
- Console UI
- Configuration
- Open your deployment and click the gear icon in the sidebar to open Deployment Settings.
- Find the LDAP Provider section.
- Toggle Enable to on.
- Select the Protocol:
ldap://(unencrypted) orldaps://(TLS-encrypted). Useldaps://for production deployments. - Set the URI — the address and port the LDAP Provider listens on (e.g.,
ldaps://0.0.0.0:636for TLS on the standard LDAPS port, orldap://0.0.0.0:389for unencrypted). - If using
ldaps://, provide the TLS Certificate file path and TLS Key File path. - Click Save.
The LDAP Provider Deployment Settings fields are documented in detail in the LDAP Provider reference. Use the Console UI tab there for field-by-field descriptions.
Connect your identity provider
An identity provider (IdP) is the service that manages your user accounts — Azure AD, Okta, Google Workspace, or an on-premises directory. Connecting the Orchestrator to your IdP tells it where to source identity data for LDAP responses.The Orchestrator uses Identity Fabric connectors to communicate with your IdP. The connector provides the upstream identity data that your Service Extensions (configured in the next steps) will translate into LDAP responses.You will need your IdP’s client ID, client secret, and discovery URL. These credentials allow the Orchestrator to query the IdP for user authentication and attribute data.
- Console UI
- Configuration
- Navigate to Identity Fabric in the sidebar and click Create.
- Select your identity provider from the list. Choose a provider-specific option (such as Okta (OIDC), Microsoft Entra ID (OIDC), or Auth0 (OIDC)) or select Generic OIDC Configuration for any OIDC-compliant provider. SAML and LDAP connector options are also available.
- Fill in the connector form:
| Field | Required | Description |
|---|---|---|
| Name | Yes | A friendly name for your identity provider (e.g., upstream-idp). |
| OIDC Well Known URL | Yes | Your IdP’s OIDC discovery endpoint (e.g., https://your-idp.example.com/.well-known/openid-configuration). |
| OAuth Client ID | Yes | The client ID from the application you registered in your IdP for Maverics. |
| Client Authentication Method | Yes | Select OAuth Client Secret (default) or OAuth JWT Client Authentication. |
| OAuth Client Secret | Yes | The client secret from your IdP. For production, use a secret provider. |
| Redirect URLs | Yes | The callback URL where your IdP redirects after authentication. |
| Scopes | No | Space-separated OIDC scopes (e.g., openid profile email). |
- Click Save.
Protocol translation: The Orchestrator’s mode (LDAP Provider) determines what protocol your application speaks. The connector determines what protocol your IdP speaks. These are independent — you can connect an OIDC-only or SAML-only IdP and the Orchestrator (through your Service Extensions) will translate identity data into LDAP responses for your application. See the Identity Fabric overview for all connector types.
Write the authentication Service Extension
The authentication Service Extension handles LDAP bind operations. When an LDAP-dependent application sends a bind request (DN + password), this Service Extension validates the credentials against your upstream identity provider and returns success or failure.This step is unique to the LDAP Provider — other Orchestrator modes handle authentication declaratively. The LDAP Provider requires a Go Service Extension because LDAP bind semantics vary widely across applications, and the translation from LDAP bind to cloud IdP authentication (typically via OIDC Resource Owner Password Credentials grant or a direct API call) requires custom logic.Your authentication Service Extension should:
- Receive the bind DN and password from the LDAP client
- Parse the bind DN to extract the username or identifier
- Translate the credentials into an authentication request against the upstream IdP (e.g., ROPC grant, SCIM API, or direct API call)
- Return success or failure to the LDAP client
simple.go
- Console UI
- Configuration
- Open your deployment and click the gear icon to open Deployment Settings.
- In the LDAP Provider section, find the Authentication area.
- Toggle Enable Simple Auth to on.
- Under Authentication Service Extension, select your compiled Service Extension from the dropdown.
- Click Save.
Write the search Service Extension
The search Service Extension handles LDAP search operations. When an LDAP-dependent application sends a search request (base DN, scope, filter, requested attributes), this Service Extension translates the query into lookups against your upstream identity sources and returns matching entries in LDAP format.Your search Service Extension should:
- Receive the search parameters (base DN, scope, filter, requested attributes) from the LDAP client
- Parse the LDAP filter to determine what the application is looking for
- Query the upstream identity source (cloud IdP API, database, etc.) for matching users or groups
- Map the upstream attributes into the LDAP attribute names the application expects (e.g.,
cn,sAMAccountName,memberOf,mail) - Return the matching entries in LDAP format
search.go
- Console UI
- Configuration
- Open your deployment and click the gear icon to open Deployment Settings.
- In the LDAP Provider section, find the Search area.
- Under Search Service Extension, select your compiled Service Extension from the dropdown.
- Click Save.
Configure the facade pattern (optional)
The most common LDAP Provider deployment pairs it with HTTP Proxy mode in a facade (or “sandwich”) pattern. In this architecture, the application sits between two Orchestrator roles:See the LDAP Provider reference — Pairing with HTTP Proxy for the complete architecture diagram, credential delivery methods, and shared cache requirements.
- HTTP Proxy handles browser-facing authentication — intercepting HTTP requests, redirecting users to a cloud IdP for modern authentication (MFA, conditional access), and injecting identity headers or stuffing login forms
- LDAP Provider handles the application’s backend LDAP operations — authenticating bind requests and serving search results from the same cloud IdP
- Configure an HTTP Proxy application for the web tier — follow the HTTP Proxy Auth guide to set up reverse proxy authentication with header injection or form-stuffing.
- Configure the LDAP Provider (this guide) for the backend tier — the same Orchestrator instance or a separate one handles the application’s LDAP bind and search requests.
- Add a shared cache if running separate Orchestrator instances — when the HTTP Proxy and LDAP Provider run as separate Orchestrator instances (the most common facade deployment), they need a shared cache so that one-time credentials generated by the proxy Orchestrator can be validated by the LDAP Provider Orchestrator.
The facade can be deployed as a single Orchestrator running both HTTP Proxy and LDAP Provider modes, two separate Orchestrator instances, or groups of Orchestrators for high-availability deployments. When both modes run on a single Orchestrator instance, the local in-memory cache is sufficient.
Publish and test
With the LDAP Provider enabled, identity connector configured, and Service Extensions in place, you are ready to publish and test the virtual LDAP directory.Test the LDAP connection:Point your LDAP client application at the Orchestrator’s LDAP endpoint and verify the full flow:
- Console UI
- Configuration
- At the bottom of the deployment Settings page, click Publish Preview in the sticky footer bar.
- In the Deployment Manager dialog, review the configuration diff to verify your changes.
- Optionally add a revision note describing what changed (e.g., “Initial LDAP Provider setup”).
- Click Publish to deploy the configuration bundle to your storage provider.
- The Orchestrator detects the new bundle on its next poll cycle and applies the configuration automatically.
- Test connectivity — Use an LDAP client tool (such as
ldapsearchor Apache Directory Studio) to connect to the Orchestrator’s LDAP URI and verify the connection is accepted.
- Test bind authentication — Attempt a bind operation with valid credentials to verify the authentication Service Extension is working.
- Test search — After a successful bind, perform a search to verify the search Service Extension returns the expected attributes.
- Test with your application — Point your LDAP-dependent application at the Orchestrator’s LDAP endpoint and walk through a full authentication and data retrieval flow.
Success! Your Maverics Orchestrator is acting as a virtual LDAP directory —
authenticating LDAP bind requests against your cloud identity provider and
serving directory data to your LDAP-dependent application. The application
continues using its existing LDAP configuration while the actual identity
data comes from your modern cloud IdP.
What’s Next
LDAP Provider Reference
Complete configuration reference for LDAP Provider mode — authentication methods, search handling, Root DSE, and SASL/NTLM
Add SSO to Web Apps
Deploy the Orchestrator as a reverse proxy — pair with LDAP Provider for the facade pattern
Service Extensions
Write Go-based Service Extensions for custom authentication, search, and credential handling logic
Identity Fabric
Connect upstream identity providers to the Orchestrator — Azure AD, Okta, PingFederate, and more