Skip to main content
The Active Directory connector integrates the Maverics Orchestrator with on-premises Microsoft Active Directory environments — providing LDAP-based authentication and attribute lookup for SSO with AD-connected applications.
Console terminology: In the Maverics Console, this section is called Identity Fabric. The YAML configuration uses the connectors key to define identity provider integrations.

Overview

The Active Directory connector (type: activedirectory) uses the LDAP protocol internally to communicate with AD domain controllers. It shares the same configuration field set as the LDAP connector with defaults and conventions optimized for Active Directory environments. The key difference is the type value, which determines internal handling specific to Active Directory.

Use Cases

  • On-premises AD SSO migration — Modernize authentication for applications that currently rely on AD domain credentials, Kerberos, or NTLM
  • Hybrid AD/cloud identity — Combine Active Directory authentication with cloud identity providers using the Continuity connector for failover
  • Attribute lookup from AD — Retrieve AD user attributes (display name, group memberships, email) for header injection into legacy applications

Configuration

Console UI documentation is coming soon. This section will walk you through configuring this component using the Maverics Console’s visual interface, including step-by-step screenshots and field descriptions.
Active Directory configuration screen in Maverics Console

Configuration Reference

The Active Directory connector uses the same field set as the LDAP connector. All fields documented on the LDAP connector page apply to type: activedirectory.
KeyTypeRequiredDescription
namestringYesUnique connector identifier referenced by app policies and attribute providers
typestringYesMust be activedirectory
urlstring[]YesAD domain controller URLs — supports ldap:// (port 389) and ldaps:// (port 636); multiple URLs enable domain controller failover
serviceAccountUsernamestringYesBind DN for the service account (e.g., cn=svc-maverics,ou=Service Accounts,dc=corp,dc=example,dc=com)
serviceAccountPasswordstringYesService account password — use secret reference syntax <namespace.key>
baseDNstringYesBase DN for LDAP searches (e.g., dc=corp,dc=example,dc=com)
usernameSearchKeystringNoLDAP attribute used for username lookup — use sAMAccountName for AD environments
userRDNKeystringNoRelative Distinguished Name key for user entries
enableAuthenticationbooleanNoEnable LDAP bind authentication for end users
loginUrlstringNoURL for the LDAP login form
authenticationSearchScopestringNoLDAP search scope for authentication queries
userAttributesstring[]NoAD attributes to retrieve during searches (e.g., ["sAMAccountName", "mail", "displayName", "memberOf"])
objectClassesstring[]NoObject classes for the LDAP search filter
attributeMappingmapNoMap Orchestrator attribute names to AD attribute names (e.g., email: "mail")
attributeDelimiterstringNoDelimiter for multi-valued attributes (default: ",")
groupBaseDNstringNoBase DN for group searches
groupSearchFilterstringNoLDAP filter for group membership queries
customLogin.templateFilestringNoPath to a custom HTML login form template
tlsstringNoNamed TLS profile for AD connection
healthCheckobjectNoHealth check monitoring configuration (see Identity Fabric Configuration Reference)
For the complete connector field reference including health check details, see Identity Fabric Configuration Reference.
The activedirectory connector type uses the LDAP protocol internally. It shares the same configuration fields as the LDAP connector. The key difference is the type value, which determines internal handling specific to Active Directory environments.

AD-Specific Notes

  • Use sAMAccountName as the usernameSearchKey — In Active Directory environments, users typically log in with their sAMAccountName (e.g., jsmith), not the uid attribute used by generic LDAP directories.
  • Multiple url entries support domain controller failover — List multiple domain controller URLs to ensure authentication continues if a DC becomes unavailable. The Orchestrator will try each URL in order.
  • For LDAPS, ensure the TLS profile includes AD’s root CA — Active Directory Certificate Services (AD CS) often uses an internal CA. The TLS profile referenced by the tls field must include this CA certificate via caFile.
  • Common AD attributessAMAccountName (login name), mail (email), displayName (full name), memberOf (group memberships), department, title, manager.

Troubleshooting

  • Service account permissions — The service account must have read access to the baseDN subtree. In AD, this typically means the account needs “Read all properties” permission on user objects in the target OU.
  • LDAPS certificate trust — AD domain controllers use certificates issued by AD CS. Export the root CA certificate and include it in the TLS profile. Without it, LDAPS connections will fail with certificate verification errors.
  • Distinguished Name format — AD uses a specific DN format with OUs (e.g., cn=svc-maverics,ou=Service Accounts,dc=corp,dc=example,dc=com). Verify the exact DN using dsquery or Active Directory Users and Computers.
  • Group membership depth — The memberOf attribute only shows direct group memberships, not nested groups. For nested group resolution, consider using a group search filter or a Service Extension.