Merge the Kerberos and LDAP authentication backends

[Freddo3000]

Is your feature request related to a problem? Please describe.
Looking at https://developer.hashicorp.com/vault/docs/auth/kerberos the Kerberos authentication backend is very similar to the regular LDAP backend. Maintaining two sets of rules that do more or less the same things are redundant and leaves the risk of possibly updating one set of rules but missing the other.

Describe the solution you'd like
I'd like the Kerberos authentication method to be merged into the LDAP authentication method such that a keytab can be used when authenticating with the LDAP backend. This could be configured for example under auth/ldap/config/kerberos separately from the regular ldap config.

Describe alternatives you've considered
Use terraform to mirror the LDAP and Kerberos configuration.

Explain any additional use-cases
This could reduce the maintenance burden having to maintain one less authentication method.

Additional context
N/A

[dosubot]

Hi @Freddo3000! I'm Dosu and I'm helping the HashiCorp, an IBM Company team.

You're right that there's significant overlap — the Kerberos auth method already delegates group resolution and policy mapping to LDAP under the hood. It exposes its own LDAP configuration at auth/kerberos/config/ldap using the same parameters (groupfilter, groupdn, groupattr, binddn, userdn, userattr, etc.) and the same group-to-policy mapping model as the standalone LDAP auth method [1] [2]. So effectively, administrators must configure and maintain two parallel sets of LDAP settings and group/policy mappings, which is the pain point you're describing.

I didn't find any existing GitHub issues requesting this consolidation, so this appears to be a new feature request. A few considerations that might be useful for thinking through the design:

• Plugin architecture: Kerberos and LDAP are registered as separate credential backends in Vault's plugin registry [3], and the Kerberos implementation lives in the external vault-plugin-auth-kerberos repository [4]. Merging them would require rethinking how Kerberos SPNEGO authentication is surfaced — either as a sub-feature of the LDAP plugin or as a shared library both plugins consume.

• Your proposed approach of adding a auth/ldap/config/kerberos endpoint to the LDAP auth method is interesting. An alternative could be a shared LDAP group/policy backend that both auth methods reference, avoiding the need to fully merge the plugins while still eliminating duplicate group/policy configurations.

• Related issue: The closest existing request is about allowing multiple aliases for the same entity/mount, motivated by multi-realm Kerberos setups — not consolidation, but related to the Kerberos identity model.

This is a thoughtful suggestion and I can see how it would reduce operational overhead. My thoughts here are just brainstorming — any design direction would ultimately be up to the product and engineering teams.

Tagging @heatherezell to flag this for product and engineering review.

Written by @dosu, approved by heatherezell

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.