SSSD_KRB5_LOCALAUTH_(8)

💅 sssd_krb5_localauth_plugin — the Kerberos local auth glow-up

okay bestie, so this page is from the SSSD Manual pages collection, and the star of the show is sssd_krb5_localauth_plugin — the Kerberos local authorization plugin. yes it's a long name, no we're not shortening it, it's iconic like that. 🎀

---

✨ NAME ✨

sssd_krb5_localauth_plugin — Kerberos local authorization plugin, periodt.

---

🦋 DESCRIPTION 🦋

so libkrb5 uses the Kerberos local authorization plugin sssd_krb5_localauth_plugin for two whole jobs, and honestly it ate both:

• finding the local name for a given Kerberos principal 👑
• checking whether a given local name and a given Kerberos principal actually relate to each other 🔥

SSSD is the one handling the local names for users from a remote source, and it can read the Kerberos user principal name from that remote source too. with all that info, SSSD can handle those mappings we just talked about so easily — even when the local name and the Kerberos principal differ considerably. like, wildly different. doesn't matter. slay. ✨

and there's more: with that remote-source info, SSSD can also help prevent unexpected or unwanted mappings in the case where the user part of the Kerberos principal accidentally corresponds to a local name of a different user. 😭 because by default, libkrb5 might just strip the realm part off the Kerberos principal to get the local name — which would lowkey lead to wrong mappings in exactly that case. not the vibe. 💀

---

🎀 CONFIGURATION 🎀

the Kerberos local authorization plugin has to be enabled explicitly in the Kerberos configuration — check krb5.conf(5) for that, iykyk. SSSD will create a config snippet, with content like for example this:

[plugins]
 localauth = {
  disable = an2ln
  module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so
 }

and it drops that automatically in SSSD's public Kerberos configuration snippet directory. if that directory is included in the local Kerberos configuration, the plugin gets enabled automatically. automatic glow-up, no cap. 🦋

this configuration snippet also disables the an2ln module provided by MIT Kerberos — but only if SSSD is configured to use the AD or IPA provider. in those environments sssd_krb5_localauth_plugin can reliably map the system user names to Kerberos principals. fr fr. a fallback to an2ln might cause issues in environments where users have the privilege to create Kerberos principals on their own — which might collide with names of other users used in the system. 🚨 other modules provided by MIT Kerberos, e.g. k5login, are not affected. they're fine. they're chilling. 💜

⚠️ note bestie: if using auth_provider = krb5 then sssd_krb5_localauth_plugin is not used, so all the text above is just not applicable. read the room. 😭

---

🌈 SEE ALSO 🌈

the whole friend group, obviously — go say hi:

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8), sss_rpcidmapd(5)

---

💖 AUTHORS 💖

The SSSD upstream — https://github.com/SSSD/sssd/ 🫶

---

and that's the whole page, bestie! brought to you by SSSD, dated 06/09/2026, filed under SSSD_KRB5_LOCALAUTH_(8). go forth and map those principals correctly 💅✨🌸