Regression 1.13.2: "no LDAP groups found in groupDN"

[lukasertl]

This is a regression after upgrading 1.13.1 to 1.13.2.

We have LDAP authentication configured against AD, using this groupfilter:

"(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={{.UserDN}}))

Login still works, but we get an error in the Web UI:

"no LDAP groups found in groupDN [...] only policies from locally-defined groups available". The token then won't get any LDAP-related policies attached.

Downgrading to 1.13.1 fixes the issue.

[bovy89]

Same issue after upgrading to 1.12.6. Temporary workaround: max_page_size=-1

[scaronni]

Same issue here, fixed by disabling pagination (-1) against FreeIPA / Redhat Identity.

[krocans]

Same issue Symas OpenLDAP

[ltcarbonell]

We appreciate you notifying us of this issue. You can find more information about the issue and the proposed fix at #20453. Meanwhile, as a temporary solution, you can manually set the max_page_size configuration option instead of relying on the default behavior.

[runtman]

I'm back in by setting the max_page_size to -1, cheers.

[Q-efx]

We appreciate you notifying us of this issue. You can find more information about the issue and the proposed fix at #20453. Meanwhile, as a temporary solution, you can manually set the max_page_size configuration option instead of relying on the default behavior.

Where do you set this parameter Exactly, as a workaround?

[lukasertl]

I used this command:

vault write auth/ldap/config max_page_size=-1

[mgob]

I used this command:

vault write auth/ldap/config max_page_size=-1

This works great for me as well, same issue as others, 1.13.2

[davama]

Glad there’s a pr for this.

vault write auth/ldap/config max_page_size=-1

Worked great!
Using v1.13.2 with symas openldap

[liquidspikes]

We ran into this as well using Active Directory. Definitely a bad bug

[digiserg]

I have the same issue and the workaround paging does not work for me.

[Cajga]

Well, we run into this as well with Red Hat Directory Server as a backend.

As all of our policies are bind to LDAP/external groups and as we followed the best practice to revoke the root token this basically closed us out from our Vault cluster!!!

Now we can test our recovery token procedure (I hope enough people will have their part of the recovery key as well as the gpg keys to decrypt it...)

UPDATE: our recovery token procedure worked and setting the max_page_size=-1 helped

[digiserg]

As all of our policies are bind to LDAP/external groups and as we followed the best practice to revoke the root token this basically closed us out from our Vault cluster!!!

Why not just rollback? I use auto-unseal keys, I just needed to roll back to 1.13.1 and it all came back just fine.

[zerkms]

@Cajga you can always generate a new root token using unseal tokens: https://developer.hashicorp.com/vault/tutorials/operations/generate-root

[AndrewSav]

Now we can test our recovery token procedure (I hope enough people will have their part of the recovery key as well as the gpg keys to decrypt it...)

I just rolled back...