Vault 1.13.2 custom policy is not working as previous vault version i.e. Vault 1.13.0

[ackishore]

Hello,

We have deployed latest vault image in our production environment which is Vault 1.13.2 but we are facing issue with permission with LDAP users while access different tabs after login. Below is our internal custom policy for ldap users

{"path":{"acn/*":{"capabilities":["create","read","update","delete","list"]},"auth/*":{"capabilities":["create","read","update","delete","list"]},"archive/*":{"capabilities":["create","read","update","delete","list"]},"aws/*":{"capabilities":["create","read","update","delete","list"]},"sys/*":{"capabilities":["create","read","update","delete","list"]}}}

Same policy is being used in Vault 1.13.0 but there all users are able to login and view secrets/access/policies

But in 1.13.2, when LDAP user tries to access "Access" then below error comes up

---------------------------------------------------------------------------------------------------------------------
Ember Data Request GET /v1/sys/auth returned a 403 Payload (application/json) [object Object]
1 error occurred: * permission denied
---------------------------------------------------------------------------------------------------------------------

when he/she tries to access "Policies" tab then below error pops-up

---------------------------------------------------------------------------------------------------------------------
Ember Data Request GET /v1/sys/policies/acl returned a 403 Payload (application/json) [object Object]

1 error occurred: * permission denied
---------------------------------------------------------------------------------------------------------------------

Also in "Secrets" tab we have archive,cubbyhole and secret directories created but only cubbyhole is visible.

I tried below solution and added path - sys/auth* in our custom policy but still same error
#6876

Has something changes in new Image "Vault 1.13.2" compared to 1.13.0? Please help me out here.

(@cipherboy: edited for formatting)

[maxb]

Below is our internal custom policy for ldap users

{"path":{"acn/*":{"capabilities":["create","read","update","delete","list"]},"auth/*":{"capabilities":["create","read","update","delete","list"]},"archive/*":{"capabilities":["create","read","update","delete","list"]},"aws/*":{"capabilities":["create","read","update","delete","list"]},"sys/*":{"capabilities":["create","read","update","delete","list"]}}}

This all-in-one-line policy is pretty hard to read. Personally, I suggest you switch to representing policies in HCL, rather than JSON - it aids readability, and readability is important for security controls.

You say that is your policy for ldap users ... is it truly your intention to give every LDAP user in your organization administrator-level access to do pretty much anything in Vault?!

Same policy is being used in Vault 1.13.0 but there all users are able to login and view secrets/access/policies

But in 1.13.2, when LDAP user tries to access "Access" then below error comes up

I strongly suspect that if you look at the policies that are active (read auth/token/lookup-self) you'll discover your policy is no longer associated with the current token.

I think you're seeing the defect that was introduced in 1.13.2 detailed in #20416

[ackishore]

@maxb Thanks a lot, yeah it was not policy related issue. I went through #20416 and found the max page size configuration in Access>Auth methods>ldap>configure and made it -1 and it started working.
However same configuration option is not available in 1.13.0 as I checked.

While going through the discussion, mostly are saying it's a bug. But I'm not sure what this function(max_page_size) does!
Also how it's relevant to access issue pop-up(no LDAP groups found in groupDN) which I was getting after login.

Anyway thanks again, this workaround will work for now. Not closing this topic as I might get more answers on same from community members. If no activity happens, I'll close it.

[maxb]

But I'm not sure what this function(max_page_size) does!

It informs the LDAP server to provide the list of groups that a user is in, in multiple chunks (pages) - it exists mainly to work around wrongheaded defaults in Active Directory, which refuses to return more than 1000 groups in one response... but is quite happy to serve up multiple searches for the same large set of groups, sliced into pages of 1000 each.

mostly are saying it's a bug.

Yes, the defect in Vault is that it sets the value to zero on upgrade to 1.13.2, and zero is an invalid value per the LDAP spec.

As a result, the LDAP server says "no" and Vault goes "I guess the user isn't in any groups, then".

[ackishore]

Thank you for the explanation @maxb !!!! :)

[cipherboy]

Since #20453 has merged for Vault 1.13.3, fixing #20416, which is now out, I'm going to go ahead and close this. Feel free to re-open this if that didn't solve the problem :-)