20.6. GSSAPI Authentication
GSSAPI is an industry-standard protocol for secure authentication defined in RFC 2743.Postgres Pro supportsGSSAPI withKerberos authentication according to RFC 1964.GSSAPI provides automatic authentication (single sign-on) for systems that support it. The authentication itself is secure, but the data sent over the database connection will be sent unencrypted unlessSSL is used. GSSAPI support has to be enabled whenPostgres Pro is built. WhenGSSAPI usesKerberos, it uses a standard principal in the format Client principals can be mapped to differentPostgres Pro database user names with Postgres Pro also supports a parameter to strip the realm from the principal. This method is supported for backwards compatibility and is strongly discouraged as it is then impossible to distinguish different users with the same user name but coming from different realms. To enable this, set Make sure that your server keytab file is readable (and preferably only readable, not writable) by thePostgres Pro server account. (See alsoSection 18.1.) The location of the key file is specified by thekrb_server_keyfile configuration parameter. The default is 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: 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 The following configuration options are supported forGSSAPI: If set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping (Section 20.2). This is discouraged and is primarily available for backwards compatibility, as it is not secure in multi-realm environments unless Allows for mapping between system and database user names. SeeSection 20.2 for details. For a GSSAPI/Kerberos principal, such as Sets the realm to match user principal names against. If this parameter is set, only users of that realm will be accepted. If it is not set, users of any realm can connect, subject to whatever user name mapping is done.servicename/hostname@realmkrbsrvname connection parameter. (See alsoSection 35.1.2.) The installation default can be changed from the defaultpostgres at build time using./configure --with-krb-srvnam=whatever. In most environments, this parameter never needs to be changed. Some Kerberos implementations might require a different service name, such as Microsoft Active Directory which requires the service name to be in upper case (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.pg_ident.conf. For example,pgusername@realm could be mapped to justpgusername. Alternatively, you can use the fullusername@realm principal as the role name inPostgres Pro without any mapping.include_realm to 0. For simple single-realm installations, doing that combined with setting thekrb_realm parameter (which checks that the principal's realm matches exactly what is in thekrb_realm parameter) is still secure; but this is a less capable approach compared to specifying an explicit mapping inpg_ident.conf./usr/local/pgsql/etc/krb5.keytab (or whatever directory was specified assysconfdir at build time). For security reasons, it is recommended to use a separate keytab just for thePostgres Pro server rather than opening up permissions on the system keytab file.kadmin%ank -randkey postgres/server.my.domain.orgkadmin%ktadd -k krb5.keytab postgres/server.my.domain.orgfred, principalfred@EXAMPLE.COM would be able to connect. To also allow principalfred/users.example.com@EXAMPLE.COM, use a user name map, as described inSection 20.2.include_realmkrb_realm is also used. It is recommended to leaveinclude_realm set to the default (1) and to provide an explicit mapping inpg_ident.conf to convert principal names toPostgres Pro user names.mapusername@EXAMPLE.COM (or, less commonly,username/hostbased@EXAMPLE.COM), the user name used for mapping isusername@EXAMPLE.COM (orusername/hostbased@EXAMPLE.COM, respectively), unlessinclude_realm has been set to 0, in which caseusername (orusername/hostbased) is what is seen as the system user name when mapping.krb_realm