PostgreSQL Reference Manual - Volume 3 - Server Administration Guide by The PostgreSQL Global Development Group Paperback (6"x9"), 204 pages ISBN 0954612043 RRP £13.95 ($24.95) Sales of this book support the PostgreSQL project! Get a printed copy>>>

PostgreSQL Reference Manual Volume 3 Buy the book here! >>> support free documentation

7.2.3 Kerberos authentication

Kerberos is an industry-standard secure authentication system suitable for distributed computing over a public network. A description of the Kerberos system is far beyond the scope of this document; in full generality it can be quite complex (yet powerful). The Kerberos FAQ or MIT Kerberos page can be good starting points for exploration. Several sources for Kerberos distributions exist. Kerberos provides secure authentication but does not encrypt queries or data passed over the network; for that use SSL.

PostgreSQL supports Kerberos version 5. Kerberos support has to be enabled when PostgreSQL is built; see section 1 Installation Instructions for more information.

PostgreSQL operates like a normal Kerberos service. The name of the service principal is servicename/hostname@realm.

servicename can be set on the server side using the krb_srvname configuration parameter, and on the client side using the krbsrvname connection parameter. (See also Volume 2: Database Connection Control Functions.) The installation default can be changed from the default postgres at build time using ./configure --with-krb-srvnam=whatever. In most environments, this parameter never needs to be changed. However, to support multiple PostgreSQL installations on the same host it is necessary. Some Kerberos implementations may also require a different service name, such as Microsoft Active Directory which requires the service name to be in uppercase (POSTGRES).

hostname is the fully qualified host name of the server machine. The service principal's realm is the preferred realm of the server machine.

Client principals must have their PostgreSQL database user name as their first component, for example pgusername/otherstuff@realm. At present the realm of the client is not checked by PostgreSQL; so if you have cross-realm authentication enabled, then any principal in any realm that can communicate with yours will be accepted.

Make sure that your server keytab file is readable (and preferably only readable) by the PostgreSQL server account. (See also section 3.1 The PostgreSQL User Account.) The location of the key file is specified by the krb_server_keyfile configuration parameter. The default is ‘/usr/local/pgsql/etc/krb5.keytab’ (or whichever directory was specified as sysconfdir at build time).

The keytab file is generated by the Kerberos software; see the Kerberos documentation for details. The following example is for MIT-compatible Kerberos 5 implementations:

kadmin% ank -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org

When connecting to the database make sure you have a ticket for a principal matching the requested database user name. For example, for database user name fred, both principal fred@EXAMPLE.COM and fred/users.example.com@EXAMPLE.COM could be used to authenticate to the database server.

If you use mod_auth_kerb and mod_perl on your Apache web server, you can use AuthType KerberosV5SaveCredentials with a mod_perl script. This gives secure database access over the web, no extra passwords required.