Any way to set up "LDAP TOTP self-signup" but using "OIDC auth"?

Vault
1

I have a couple of vault instances that support both LDAP (for easier headless) and OIDC based logins for the same pool of users.

I’d like to restrict the use of LDAP auth to requiring TOTP.

The ideal way to do this would be to say “Hey, in order to continue using LDAP auth at all, you have to set up a TOTP for your ldap login.”

I could do this with a custom onboarding application, but is there any way to build something like this with just policies - something where we define a policy rule that says that oidc user mapping to ‘fred’ is able to modify ldap auth for userid ‘fred’ - but with one of the ‘generated’ policy grants so it’s 1:1 automatic.

I think this would make onboarding very easy/procedural if something like this could be formed. (Note, I am NOT trying to add TOTP to the OIDC based login, that’s already handled by the SSO provider.)

Any ideas/suggestions?

2

Are you looking to give your OIDC user logins a way to modify the LDAP user (e.g. in ActiveDirectory or OpenLDAP)?

Or do you want your OIDC user to be able to configure Vault for MFA/TOTP?

3

The first one. Essentially, I’d like to turn on/enable the MFA support in Vault. I’m not looking to do anything to the actual userid in the directory, just to be able to configure the MFA support in vault itself. ( Secure authentication with MFA Login and Time-Based One Time Passwords | Vault | HashiCorp Developer )

The OIDC based logins will have full access, but I’d like the LDAP logins to not work until the user has set up that TOTP support. (Most will never do that setup, which is fine, this is a ‘for developers on headless devices’ functionality.)

(Side note, wish vault’s OIDC support had better headless capability with copy paste, but a ‘Token’ based login does work for that.)

4

This is an interesting use case, I don’t have an environment to test this out in right now but if the LDAP and OIDC usernames are the same, could you make use of templating in the policy {{identity.entity.name}} for example? Assuming Bob and Alice have the same username for both OIDC and LDAP, that should match?

Trying to … vibe policy (think I just made up a new term)? … my way into some example policies, but dont have a way to test that they are valid or hallucinations.

Outside of that, you would need to either provide the accessor IDs, or allow people to look them up which might start to get a wee permissive.

I will ask some of my teammates if they have some ideas, I might be able to carve out a day or two in the next couple of weeks to try and set this up, but I could also fail spectacularly at it!

What Claude came up with (FWIW)

# Allow paul from OIDC to enable TOTP for LDAP user paul

# Grant read access to auth methods to obtain accessor IDs
# Or provide the accessor ID directly to the user
path "sys/auth" {
  capabilities = ["read", "list"]
}

# Grant read access to LDAP auth method configuration
# This allows verification of user existence before TOTP operations
path "auth/ldap/*" {
  capabilities = ["read"]
}

# Allow access to write TOTP generation to user's LDAP user
path "auth/ldap/users/{{identity.entity.name}}/totp" {
  capabilities = ["create", "read", "update"]
}

# Allow reading TOTP validation on user's LDAP user 
path "auth/ldap/users/{{identity.entity.name}}/totp/generate" {
  capabilities = ["read", "update"]
}

# Allow access to TOTP admin-generate endpoint
path "auth/ldap/users/{{identity.entity.name}}/totp/admin-generate" {
  capabilities = ["read", "update"]
}

# Allow access to read the TOTP key/ID
path "auth/ldap/users/{{identity.entity.name}}/totp/key" {
  capabilities = ["read"]
}