LDAP Authentication enables a Conjur to use an existing LDAP directory service to authenticate users.
With LDAP Authentication, users log into a Conjur with the same login credentials that they use for their corporate accounts. There is no need to manage a password in multiple places. The password exists in a single location.
When LDAP authentication is enabled in a Conjur:
All Web interface users must use LDAP credentials. LDAP authentication becomes the one and only way to authenticate to the web interface. Every a Conjur UI user must have an LDAP account.
CLI and API users may choose which authentication type to use. A a Conjur appliance may have several authentication methods enabled simultaneously. API and CLI users can individually choose which authentication they want to use from all enabled authentication methods. If LDAP authentication is enabled, CLI and API users can optionally use that method. See Configure Developer Environment to Use LDAP Authentication. The default authentication method for the CLI and API is the a Conjur authenticator, using passwords maintained in a Conjur.
For general information about a Conjur authentication and configuring multiple authentication methods, see Configure Authentication Type.
LDAP authentication does not eliminate the requirement to add user accounts into a Conjur. For each LDAP user that needs access to a Conjur, there must be a corresponding user account declared in a Conjur policy. a Conjur user accounts are required to manage the RBAC authorization model on a Conjur resources. The a Conjur authorization model permits users (or more typically, groups of users) to access and update a Conjur resources.
With LDAP authentication, the corporate LDAP directory handles authentication, while a Conjur is responsible for authorization. We recommend using the a Conjur LDAP Sync service to create and maintain corresponding user accounts in a Conjur.
LDAP authentication does not automatically incorporate subsequent changes made in the LDAP directory. To ensure that a disabled account can no longer access a Conjur, see Disabled user accounts.
How it works
LDAP authentication is a built-in a Conjur service (
authn-ldap) that authenticates users to a Conjur using their LDAP credentials. The LDAP authenticator uses configuration settings to connect to an LDAP server and bind against a directory using an LDAP username and password.
When the LDAP authenticator receives an authentication request, it attempts to perform an LDAP bind operation with the given credentials. If the request succeeds, it responds as an authorization (authn) service, with an API key or a signed bearer token.
authn-ldap service is used either to login via basic
GET /api/authn-ldap/users/login) or to authenticate by
posting the password or API key, obtaining a bearer token (
/api/authn-ldap/users/:user/authenticate). These functions are the same as those used by the
as the default a Conjur authenticator (authn). The difference is that
authn-ldap uses LDAP credentials rather than
a a Conjur password.
Configuration settings provide the LDAP Server connection and filter information. The method of configuration differs depending on the a Conjur version. See Configure the LDAP connection and filter information for more information.
One of the required configuration settings for LDAP authentication is the
filter_template is a template string used to translate a a Conjur user ID into an LDAP bind expression. The template must include the expression
%s which represents the a Conjur username provided by the authenticator.
At a minimum, the value of
filter_template can be the following, which matches a a Conjur user name to a user name in the LDAP Directory.:
If you use LDAP Sync, we recommend adding the
user_filter from the LDAP Sync configuration into the template, as follows:
Here is an example:
The reason to copy the
user_filter from LDAP Sync is to make the authenticator filter at least as specific as the users that were synced, and make it more specific using the unique identifier for the user. This eliminates the possibility that a user in another branch of the directory has the same identifier as another a Conjur user ID. (In that case, the authentication would attempt to bind to the wrong user, but the password would not match.)
filter_template does not need to include exclusions for disabled users. LDAP Servers reject requests to bind from disabled users. If the exclusion is already included in a
user_filter that you are copying, it does no harm to leave it.
LDAP servers support strong search capabilities for filtering user accounts. a Conjur passes the
filter_template that you configure to the LDAP server to implement as a search string. If you verify that a search string works on your LDAP Server, it is valid in the
Ultimately, the contents of the
filter_template should support your organization's security policies and comply with the requirements of your particular LDAP server implementation.
Remember that the a Conjur UI includes an LDAP Sync wizard that connects to an LDAP Directory and lets you experiment with
In this section: