Why does Vault permit LDAP group mappings to non-existent policies?


While troubleshooting an issue with SSH certificates I came to the realization that Vault allows LDAP group mappings to non-existent policies and will not complain (that I can see).

For example, if I have the following five policies:

❯ vault policy list

and the following five LDAP groups:

❯ vault list auth/ldap/groups

with this mapping for group3:

❯ vault read auth/ldap/groups/group3
Key         Value
---         -----
policies    [policy5 policy6]

LDAP user toto which belongs to LDAP group3 will obtain a token with the following policies attached:

❯ vault token lookup
Key                 Value
---                 -----
accessor            xxxxxx
creation_time       1594039225
creation_ttl        12h
display_name        ldap-toto
entity_id           xxxxxx
expire_time         2020-07-06T20:40:25.038947746-04:00
explicit_max_ttl    0s
id                  xxxxxx
issue_time          2020-07-06T08:40:25.038963419-04:00
meta                map[username:toto]
num_uses            0
orphan              true
path                auth/ldap/login/toto
policies            [default policy5 policy6]
renewable           true
ttl                 5h41m50s
type                service

even though policy6 does not exist.

Is this by design?


(This is on Vault 1.4.1)


I have been able to reproduce it on my environment, the policy6 in your case has no policy statements in it, so it provides no additional permissions to the issued token.

I can confirm the same behaviour for the other auth methods.

Kind regards,

Thanks for confirming @martinhristov90.

Do you think this is a bug, or more of an intended behavior? From my point of view it does make it a bit harder to troubleshoot policy issues as you cannot simply use the listed token capabilities as a “guarantee” that the expected policy has actually been applied.

However, perhaps there was a deliberate design decision to allow this behavior for some reason.

I just trying to figure out which of those two scenarios it is.


It’s a deliberate decision. Not requiring policies to be defined before they’re used facilitates some deployments - at least that’s what I was told when I asked about this some time ago.

Thanks @ncabatoff. I suspected there might be some reason why it was done that way but wanted to make sure.