// , It looks like avoiding advanced AD synchronization features was an intentional (and perhaps wise) design decision on the part of the Vault developers, according to this:
"We don't create group aliases automatically. We're thinking of putting in a config option for this, but I had a little asterisk on that slide a little while back and the reason is because if you have 100 groups, but you only care about three of them in a Vault and they automatically populate, now you have 100 groups in a Vault, most of which you don't want. So, we're probably going to have a way to toggle that, but for right now, if you're trying to play around with it, you have to actually create the group aliases first and then once it's created there and it sees that alias exists, it'll start doing the mapping for you. So, just a little trade-off."
We could create group aliases as needed, I suppose. What I'm thinking about now, is a revocation scenario:
1. An AD group is created in AD
2. Some kind of synchronization or triggering tool triggers an update in Vault, depending on whether the AD group matches some kind of pattern, e.g. it starts with SEC-*.
3. That trigger-er then updates Vault by attaching a Vault Policy to an LDAP role corresponding to that AD group.
4. An AD user Jim is added to an AD group.
5. The user Jim logs in to Vault with his AD credentials, using the LDAP authentication method.
6. Ho ho, Merry Christmas, he gets a token.
7. But, oh no, Jim's been hacked!
8. So he now gets removed from the AD group until InfoSec can find out what's going on.
9. In the mean time, although he can't log in again, Jim's token is still valid.
There are 4 options to deal with this that I can think of right now:
1. I just accept the risk, because it's not too bad as long as tokens are short lived, or even only allow a few uses. And I can add a section to the runbook that says to manually delete any such tokens for revocation.
2. Make the triggering system automatically send token revocation API calls to Vault for a user if it notices that user's removal from one of its watched AD groups.
3. Limit LDAP authorizations to capabilities that are less problematic in the event of a compromised token, like ["list"] and ["create"] access without ["read"] access, and such.
4. Something else
Less reasonable options:
Write an AD synchronization plugin
Stop using AD at all
SEAL THE VAULT