Upgrading Vault Breaks LDAP

Vault
1

Last night I tried upgrading from 1.3.2 to 1.7.0 by simply replacing the binary file. Vault started fine, however, we saw the below error after upgrade:

[root@isipl5jmp01 bin]# vault login -method ldap username=
Password (will be hidden):
Error authenticating: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/auth/ldap/login/
Code: 400. Errors:

  • ldap operation failed: failed to bind as user

LDAP works fine on 1.3.2, so why does it not work for 1.7.0?

2

auth config below:

[root@vault ~]# vault read auth/ldap/config --format=json
{
“request_id”: “8982079c-e1cd-a398-8670-0fc29012bd42”,
“lease_id”: “”,
“lease_duration”: 0,
“renewable”: false,
“data”: {
“binddn”: “CN=vault_svc,OU=Service Accounts,OU=AHCA,DC=FLAHCA,DC=LOCAL”,
“case_sensitive_names”: false,
“certificate”: “”,
“deny_null_bind”: true,
“discoverdn”: false,
“groupattr”: “memberOf”,
“groupdn”: “OU=Accenture,OU=AHCA,DC=FLAHCA,DC=LOCAL”,
“groupfilter”: “(\u0026(objectClass=person)(sAMAccountName={{.Username}}))”,
“insecure_tls”: false,
“starttls”: false,
“tls_max_version”: “tls12”,
“tls_min_version”: “tls12”,
“token_bound_cidrs”: ,
“token_explicit_max_ttl”: 0,
“token_max_ttl”: 0,
“token_no_default_policy”: false,
“token_num_uses”: 0,
“token_period”: 0,
“token_policies”: ,
“token_ttl”: 0,
“token_type”: “default”,
“upndomain”: “flahca”,
“url”: “ldap://ip_redacted:389,ldap://ip_redacted:389”,
“use_pre111_group_cn_behavior”: false,
“use_token_groups”: false,
“userattr”: “samaccountname”,
“userdn”: “OU=Accenture,OU=AHCA,DC=FLAHCA,DC=LOCAL”
},
“warnings”: null
}

3

Hi @tyler.yosick,

Looks like there were some bug fixes for LDAP auth per the release notes. I’m not sure if any of them would change behavior. It’s also been a while since I’ve used LDAP auth so I’m a little rusty on what to look for these days.

However, I’d look at a few things based on your config:

  1. Looks like you’re using a bind account - make sure the password is correct
  2. Depending what you’re attempting to do with the groupfilter you may want to review the recommended defaults and see if your setting needs any adjustment
  3. Looks like you’re using unencrypted LDAP connections, you might need to use encrypted (port 636)
  4. Is the UPN domain correct? Are your user’s UPNs formatted as ${username}@flahca or ${username}@flahca.local?

Hopefully this helps a bit.

4

Hi Jeff-

Thanks for the reply. Answers to your questions inline below:

  1. Looks like you’re using a bind account - make sure the password is correct
    -I wonder if it needs to be re-entered after an upgrade? Not 100% sure.

  2. Depending what you’re attempting to do with the groupfilter you may want to review the recommended defaults and see if your setting needs any adjustment
    -The particular error I received seemed to indicate it was an issue with the bind user.

  3. Looks like you’re using unencrypted LDAP connections, you might need to use encrypted (port 636)
    -I’m not sure what this involves to get set up or how it would help my current issue.

  4. Is the UPN domain correct? Are your user’s UPNs formatted as ${username}@flahca or ${username}@flahca.local ?
    -Yes. The user’s UPN’s are formatted as ${username}@flahca.local.

5

  1. I don’t believe the password needs to be updated after an upgrade, but it may be worth re-applying or resetting just to rule that out

  2. Fair, but might be something to look at as you progress

  3. Certain activities within Active Directory require leveraging an encrypted connection. I know changing password does, but I don’t recall if authentication requires it offhand. This, of course, assumes you’re using AD. This guide might be helpful to set up LDAPS or to verify it’s already configured.

  4. Per your config, the “upndomain”: “flahca” parameter may need to be updated to “upndomain”: “flahca.local”.

1 Like
6

@twmcelroy any thoughts here? :slight_smile:

7

This doesn’t look right … mine is (I should mention that we allow access via a AD group so not everyone has access so hence the membership check).

(|(memberUid={{.Username}})(member={{.UserDN}})(uniqueMember={{.UserDN}}))

Are you users this far up in the tree? we’re just off of the 2nd branch so:

"DC=FLAHCA,DC=LOCAL”
8

@aram thats a fair call out, however, the question is why does my LDAP configuration work on version 1.3.2, but not newer versions?

9

You are bringing me back to vault :slight_smile:
I found this MR that might have impacted this auth/ldap: Add username to alias.metadata.name by jasonodonnell · Pull Request #13669 · hashicorp/vault (github.com) which refers to Support for a LDAP user search filter. Documentation, tests and UI included by ixe013 · Pull Request #11000 · hashicorp/vault (github.com)

I’d read through those. Unfortunately I haven’t gotten to work with Vault in too long so I don’t have any recent uses of Vault with LDAP