Vault’s LDAP authentication backend is actually a powerful, albeit sometimes finicky, way to manage user access based on your existing Active Directory structure.
Let’s see it in action. Imagine we have a user, alice.wonderland, in Active Directory. Vault can be configured to authenticate this user based on their AD credentials.
{
"auth": {
"ldap": {
"bind_dn": "cn=vault-binder,ou=service accounts,dc=example,dc=com",
"bind_dn_password": "supersecretpassword",
"user_base_dn": "ou=users,dc=example,dc=com",
"user_filter": "(sAMAccountName={{.Username}})",
"group_base_dn": "ou=groups,dc=example,dc=com",
"group_filter": "(memberOf={{.GroupDN}})",
"group_attribute": "memberOf"
}
}
}
When alice.wonderland tries to log in, Vault uses the bind_dn and bind_dn_password to query Active Directory. The user_base_dn tells Vault where to look for users, and user_filter specifies how to find the specific user (in this case, matching the sAMAccountName attribute to the username provided). If the user is found, Vault can then optionally check group memberships using group_base_dn and group_filter to assign policies.
The primary problem this solves is the overhead of managing separate user credentials for Vault. By leveraging Active Directory, you centralize user management and enforce existing security policies. The internal mechanism involves Vault acting as an LDAP client. It establishes a connection to your AD domain controller, performs searches based on the configured DNs and filters, and then uses the results to authenticate the user and determine their group memberships for policy association.
The user_filter and group_filter are your primary tools for tailoring how Vault maps AD objects to Vault entities. For instance, (sAMAccountName={{.Username}}) is common for matching the login name, but you could also use (mail={{.Username}}) if you want users to log in with their email addresses. For groups, (memberOf={{.GroupDN}}) is standard, but you might use (cn={{.GroupName}}) if your group names are stored in the cn attribute and you’re not using the full DN in the filter.
A common point of confusion is the group_attribute. While memberOf is the default and most frequent attribute on a user object that lists the groups they belong to, some AD configurations might store group membership differently, perhaps on the group object itself. If you’re finding that group memberships aren’t being correctly applied, double-checking which attribute AD actually uses to represent a user’s group affiliations is key. Vault will attempt to read this attribute from the user object, so if it’s not memberOf, you’ll need to specify the correct attribute here.
Once configured, the login process is straightforward. A user would execute vault login -method=ldap username=alice.wonderland. Vault then prompts for the password, which is passed securely to AD via the bind DN.
The next challenge is usually managing the dynamic creation and revocation of Vault tokens based on these AD group memberships.