AD/LDAP Connector
Auth0 integrates with Active Directory (AD) using Lightweight Directory Access Protocol (LDAP) through an Active Directory/LDAP Connector that you install on your network.
The AD/LDAP Connector is designed for scenarios where your company controls the AD/LDAP server. The connector should not be installed on your customer's servers.
For B2B scenarios where you want to allow your customer's users to access your applications using their enterprise credentials, connect to your customer's federation service (for example, their own Auth0 service, ADFS, or any SAML identity provider) using one of the available enterprise connections.
If you install an AD/LDAP connector on your customer's servers and it is connected directly to your Auth0 domain, you will have to handle the passwords of your customer's users directly. Auth0 strongly recommends against these types of deployments and does not support them.
The AD/LDAP Connector (1), is a bridge between your Active Directory/LDAP (2) and the Auth0 Service (3). This bridge is necessary because AD/LDAP is typically restricted to your internal network, and Auth0 is a cloud service running in a completely different context.
When a user authenticates with Auth0, they are redirected to the AD/LDAP Connector which validates the user against your AD service and then sends the results of the validation back to Auth0. The AD/LDAP Connector supports authentication based LDAP, Kerberos, and client certificates.
To learn more, see Configure AD/LDAP Connector Authentication with Kerberos and Configure AD/LDAP Connector Authenticator with Client Certificates.
Caches
The AD/LDAP Connector caches user profiles and credentials (Auth0 stores a hash of the user's password) to ensure optimal uptime and performance, and updates the data each time a user logs in. The cache is only used when the connector is down or unreachable. The cached data is always stored unless you disable caching credentials in the Dashboard. Values in the cache are case-sensitive, which means that login attempts will only succeed if users provide the exact username that was cached.
High-availability and load balancing
For high-availability and load balancing, you can install multiple instances of the connector. All connections are outbound from the connector to the Auth0 Server, so changes to your firewall are generally unnecessary.
Each instance of the high-availability cluster will be always up and running and connected to Auth0. Auth0 will send login transactions and other requests to any of the available connectors. If one of the instances fails because of a network or a hardware issue, Auth0 will redirect the login transactions to the other connector. Having a highly available deployment also allows you to update the connector with zero downtime.
OpenLDAP directories
The Connector comes by default highly optimized for Active Directory. To configure it any other LDAP directories (such as OpenLDAP) you will have to customize these settings in the config.json file:
"LDAP_USER_BY_NAME": "(cn={0})",
"LDAP_SEARCH_QUERY": "(&(objectClass=person)(cn={0}))",
"LDAP_SEARCH_ALL_QUERY": "(objectClass=person)",Was this helpful?
In some cases, instead of cn it might be better to use uid.
OpenDJ example
With the OpenDJ Control Panel you can retrieve the list of attributes for each user. This list can help you decide which attribute will be used as the username when authenticating with Auth0.
In this example John's cn is johndoe and the mail field is set to johndoe@contoso.com. If your organization wants users to authenticate using their username (cn) you can set the LDAP_USER_BY_NAME setting to (cn={0}), but if users should authenticate using their email address you should set it to (mail={0}).