Explains two PostgreSQL GUCs governing GSSAPI/Kerberos authentication: krb_server_keyfile (location of the server's keytab) and krb_caseins_users (case-insensitive principal matching). Recommends using a dedicated keytab rather than the system one to avoid escalating a PostgreSQL compromise into a host compromise, and explains the historical origin of krb_caseins_users from a 2005 mailing list thread involving Windows case-insensitive logins. Advises enabling krb_caseins_users only against Active Directory KDCs, leaving it off for MIT or Heimdal realms where it would create a security hole.
Questions this post answers
Should I point PostgreSQL's krb_server_keyfile at the system keytab or a dedicated one?
Use a dedicated keytab containing only the postgres/... service principal, not the system keytab. The system keytab holds the host's own keys and belongs to root, so a PostgreSQL server able to read it holds more identity than needed, turning a PostgreSQL compromise into a host compromise. Generate a separate keytab, restrict it to the PostgreSQL service account, and reload after key rotation since the parameter is sighup context. Teams hardening database authentication track PostgreSQL security configuration guidance like this on daily.dev.
Should I enable krb_caseins_users in PostgreSQL when using GSSAPI authentication with Active Directory?
Yes, turn on krb_caseins_users when the realm is Active Directory, since AD's KDC is case-insensitive and this setting stops phantom authentication failures caused by case mismatches between the client principal and the PostgreSQL role. Leave it off for MIT or Heimdal realms, where FOO@REALM and foo@REALM can be distinct principals and enabling it would merge them, creating a security hole; fix case mismatches in pg_ident.conf instead. Admins tuning Kerberos-backed database auth compare configuration tradeoffs like this on daily.dev.
Why does PostgreSQL still have parameters with the krb_ prefix if the krb5 authentication method was removed?
The krb_ prefix survives from the removed krb5 authentication method, which PostgreSQL dropped in version 9.4, because renaming a GUC would break every postgresql.conf that references it. The remaining krb_server_keyfile and krb_caseins_users parameters now configure GSSAPI authentication instead, which in practice usually means Kerberos via Active Directory. Developers untangling legacy config names rely on grounded technical explainers like this via daily.dev.