Ldap operation failed: unable to retrieve user bind DN

Vault
1

Trying to setup vault with ldap (Active Directory) and getting the “ldap operation failed: unable to retrieve user bind DN” error after trying

vault login -method=ldap username=user1

After searching here and Googling I’ve checked all my config and then performed these ldapsearch queries:

ldapsearch -x -H ldap://dc01.abc.local -D “user1@abc.local” -W -b “cn=Users,dc=abc,dc=local”

ldapsearch -x -LLL -E pr=200/noprompt -h dc01.abc.local -D “ldaps.account@abc.local” -W -b “dc=abc,dc=local” “(sAMAccountName=user1)” dn memberOf sAMAccountName dn: CN=user1,OU=Groups,OU=Users,DC=abc,DC=local memberOf: CN=Linux,OU=Groups,DC=abc,DC=local sAMAccountName: user1

Both work fine and return results from ad/ldap.

I’ve turned on trace logging and also see this in the logs after trying to login:

[DEBUG] auth.ldap.auth_ldap_5ecfdbb7: error getting user bind DN: error="LDAP bind (service) failed: LDAP Result Code 49 “Invalid Credentials”: 80090308: LdapErr: DSID-0C090453, comment: AcceptSecurityContext error, data 52e, v3839

Have double checked the credentials of the binddn account I’m using and tried a different account together with various client accounts and same result. I’ve even tried creating a new server from scratch as a test and get the exact same error. We use many other services to bind against AD such as Confluence, Duo and a few others all with no issues.

Here is the ldap config file:

vault write auth/ldap/config \
    url="ldaps://dc01.abc.local" \
    userattr="sAMAccountName" \
    userdn="OU=Users,DC=abc,DC=local" \
    discoverdn=true \
    groupdn="CN=Linux,OU=Groups,DC=abc,DC=local" \
    groupfilter="(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={{.UserDN}}))" \
    binddn="cn=ldaps.account,cn=Service Accounts,dc=abc,dc=local" \
    bindpass='*************' \
    groupattr="memberOf" \
    certificate=@ldapcert.pem \
    insecure_tls=false \
    starttls=true

There must be something I’m missing, any assistance would be appreciated.

Environment:

  • Ubuntu Server 20.04
  • Vault Server Version 1.5.0
  • Vault CLI Version v1.5.0
2

Hello,

Can you verify the binddn value which is : binddn="cn=ldaps.account,cn=Service Accounts,dc=abc,dc=local" is correct and the entry actually exists in LDAP.
At first glance, it seems that the space in cn=Service Accounts might be causing trouble.

Martin

3

Thanks Martin, I tried a different account located in the built-in Users OU of AD and get the same issue. So the entry is now cn=Users

If run a ldapsearch command using this other account to query ldaps.account it returns the correct values and knows about it as show here:

ldapsearch -x -LLL -E pr=200/noprompt -h dc01.abc.local -D “ldapconnect@abc.local” -W -b “dc=abc,dc=local” “(sAMAccountName=ldaps.account)” dn memberOf sAMAccountName dn: CN=ldaps.account,OU=Service Accounts,DC=abc,DC=local memberOf: CN=Domain Users,OU=Service Accounts,DC=abc,DC=local sAMAccountName: ldaps.account

dn: CN=ldaps account,OU=Service Accounts,DC=abc,DC=local
sAMAccountName: ldaps.account

Thanks for your help anyway.

4

That’s your issue. Your vault bind says “cn=ldaps.account” but the entry says “cn=ldaps account”. Not the CN uses space while the sAMAccountName uses period.

5

Thanks for your help @sbutler I thought that may have been it, however I’ve tried changing that with variations, and no luck.

I decided to spin up and new test AD Domain controller in case it was something in our AD system and I’m still getting the exact errors, this is getting frustrating. I’ve tried two different built from scratch linux vault servers and a new AD server.

Created a standard ldap user for the bind named ldap in the Users OU.
Here is my test ldap config:

vault write auth/ldap/config
url=“ldap://dc01test.abc.local:389”
userattr=“sAMAccountName”
userdn=“OU=Users,DC=abc,DC=local”
discoverdn=true
groupdn=“CN=Linux,OU=Groups,DC=abc,DC=local”
groupfilter=“(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={{.UserDN}}))”
binddn=“cn=ldap,dc=abc,dc=local”
bindpass=‘*******’
groupattr=“memberOf”
insecure_tls=true
starttls=false

Login attempt result:

vault login -method=ldap username=user1
Password (will be hidden): 
Error authenticating: Error making API request.

URL: PUT https://vault.abc.local:8200/v1/auth/ldap/login/user1
Code: 400. Errors:

* ldap operation failed: unable to retrieve user bind DN

Here is the ldapsearch util test:

ldapsearch -x -LLL -E pr=200/noprompt -h dc01test.abc.local -D "ldap" -W -b "dc=abc,dc=local" "(sAMAccountName=user1)" dn memberOf sAMAccountName dn: CN=user1,OU=Groups,OU=Users,DC=abc,DC=local memberOf: CN=Linux,OU=Groups,DC=abc,DC=local sAMAccountName: user1
Enter LDAP Password: 
dn: CN=user1 test,CN=Users,DC=abc,DC=local
memberOf: CN=Linux,OU=Groups,DC=abc,DC=local
sAMAccountName: user1

# refldap://ForestDnsZones.abc.local/DC=ForestDnsZones,DC=abc,DC=local

# refldap://DomainDnsZones.abc.local/DC=DomainDnsZones,DC=abc,DC=local

# refldap://abc.local/CN=Configuration,DC=abc,DC=local

# pagedresults: cookie=

Here is the log details:

[DEBUG] auth.ldap.auth_ldap_2b098e5d: error getting user bind DN: error="LDAP bind (service) failed: LDAP Result Code 49 "Invalid Credentials": 80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v4563

Any ideas before I really go mad?
Thanks

6

Hello,

It seems like your binddn user is named user1 test or user1 (judging by the ldapsearch, i might be wrong though). The usual user attribute (userattr) is set to sAMAccountName in Vault. This attribute is used to match the AD object to the user that is trying to log in, for example: martin is trying to login in Vault, object with attribute sAMAccountName set to martin should exist.
According to your LDAP config binddn=“cn=ldap,dc=abc,dc=local” Vault will be searching for object with attribute sAMAccountName = ldap in the path dc=abc,dc=local for binding. Does it exists ? Is it in the correct path specified in binddn ?

Also, what i usually do is to execute vault read auth/ldap/config to verify that the configuration i wrote is in effect. There are some gotchas with the " and '.

Martin