Search code examples
postgresqlkerberoskeytab

Kerberos authentication. Keytab and ticket


I've got several question about Kerberos, how it work.

  1. Does every service, for example Postgres, which uses Kerberos authentication, must have keytab, generated by KDC? Or maybe kerberos authentication on service can be without keytab file?
  2. How does keytab determine, that new principal of user was added? I mean, I've generated keytab for Postgres and send it on service of Postgres and match the keytab file in postgresql.conf. Then I created role Born (for instance) in Postgres database and add it principal in KDC kadmin. After that, from another computer I can connect (after kinit Born) to Postgres service. But I've made keytab before adding new principal Born. How keytab of Postgres manage to find Born? How info about new added user from kadmin store to keytab Postgres on another server?

Solution

  • Does every service, for example Postgres, which uses Kerberos authentication, must have keytab, generated by KDC? Or maybe kerberos authentication on service can be without keytab file?

    Yes, every service must have its own Kerberos identity, and must know the keys for it. The keys might not necessarily be stored in a keytab file (e.g. Windows AD machines use a password), but they usually are.

    Postgres works with KErberos only using keytabs. But there are some that don't nead keytabs.

    All services have their own Kerberos principal and their own key (the KS if you're looking at the Wikipedia diagram), it's just not always stored in the specific form of a keytab.

    Services that are hosted on a Windows Server system often don't use a keytab because they use Kerberos through Windows SSPI, which uses either the service user account's password, or the "machine password" stored in LSASS, and derives KS from that password (exactly like how users derive their keys from password during kinit).

    However, it is fundamentally the same thing, whether the key is derived from a password or not. The service still has its own identity and its own Kerberos keys. (It also means clients might have a keytab and use it with kinit instead of a password, too.)

    How does keytab determine, that new principal of user was added?

    It doesn't. The server's keytab does not care about users at all; it identifies the server itself. Its purpose is a bit like the server's TLS certificate and private key (even though the mechanism is entirely different).

    Additionally, it is not the job of Kerberos to care about Postgres users. The mapping of Kerberos principals to Postgres roles happens after Kerberos authentication has been done.

    In other words, Postgres doesn't receive a role name from Kerberos directly, it only receives a Kerberos principal name and has to map it to a Postgres role by its own means. It is completely valid for Kerberos authentication succeed but for the role mapping (i.e. authorization) to fail.