Log in

No account? Create an account
Previous Entry Share Next Entry
How does SSSD interact with tools like kinit?

Many SSSD users know that SSSD supports fail over from one server to another for authentication with services like su or ssh and even autodiscovers the Kerberos servers using DNS records.

But occasionally users would ask - OK, so SSSD lets me log in with another server but I also need to use kinit manually. Does kinit use the same server SSSD used? If so, how does kinit know which KDC SSSD uses?

The SSSD actually has a plugin that is able to tell what KDC or kadmin server to use for a particular realm. When SSSD discovers a Kerberos server, it puts the IP address of that server into a file stored under the /var/lib/sss/pubconf directory. The file that stores the KDC is called kdcinfo.$REALM and the kpasswd file is called kpasswd.$REALM. When SSSD switches to another Kerberos server during a fail over operation, a new IP address is generated in these files. Also, if SSSD goes offline completely, these files are removed, so that tools using libkrb5 only rely on other means of configuration, such as the krb5.conf file.

As noted above, the kdcinfo files are only refreshed during SSSD operation, like user login. This poses a disadvantage for systems that don't perform many operations using the PAM stack, because the server that SSSD discovered might go offline without SSSD triggering a fail over operation. For these environments, it's better to disable the kdcinfo files altogether by setting the krb5_use_kdcinfo option to False and relying on krb5.conf completely. We plan on improving the kdcinfo plugin in future upstream versions so that it plays better with these kind of setups.

The SSSD kdcinfo plugin even has a man page!

  • 1

Authentification since twice domains (REALM)


May I contact you because I have a problem with SSSD authentication.
I see you have enormously topic that speaks of SSSD ...
Let me explain my model:

I have 4 servers:

- SRV1.leslandes.local / WS 2012 R2 / AD DNS +
- CLIENT.leslandes.local / CentOS6 / SSSD
- SRV4.essonne.local / WS 2012 R2 / AD DNS +

CLIENT.leslandes.local, leslandes.local is in the field, and domain users can connect via SSSD it works perfectly, example:

[root@CLIENT sssd]# id agautier
uid=10003(agautier) gid=10000(g_leslandes) groupes=10000(g_leslandes)

I hope that the users of two areas (leslandes.local and essonne.local) can connect to the client machine.

I activity given the forwaders DNS and AD point level trust relationship.

Have you a idea ?

Thank you,


  • 1