Postgres gssapi windows

PostgreSQL also supports mapping client principals to user names by just stripping 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. For security reasons, it is recommended to use a separate keytab just for the PostgreSQL server rather than allowing the server to read the system keytab file.

Make sure that your server keytab file is readable and preferably only readable, not writable by the PostgreSQL server account. See also Section The keytab file is generated using the Kerberos software; see the Kerberos documentation for details. The following example shows doing this using the kadmin tool of MIT-compatible Kerberos 5 implementations:. If set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping Section Allows mapping from client principals to database user names.

See Section The first step in setting up a Windows Active Directory is to create a regular user account. The password can be anything but shouldn't expire and it needs to be unique in the environment.

In this instance, we'll use pg1postgres. Once the user account exists, we have to create a mapping between that user account and the service principal and create a keytab file. These steps can be combined using the Windows ktpass command, like so:. This should create a pg1. Lastly, in the Windows system, go into the User account, under Properties for the pg1postgres user, on the 'Account' tab, be sure to check the box that says "This account supports Kerberos AES bit encryption.

On both the client and servers, the krb5-user package should be installed. In an Active Directory environment, that's likely all that will be required since the rest of the information is available in DNS. In postgresql. For instance, here is what things look like without a mapping:. Note that in Kerberos, a user is always logging into a server and we have to specify what that server is- in this case "-h pg1.

This portion needs to be done as user root. The Kerberos utility uses kadmin to authenticate to the server, it is always better to add an administrator to the KDC database:.

Now that everything is running, run this command that will create the KDC daemon that the client can query at will use a service startup script if you want, perhaps it does not matter much for development though :.

Using kadmin.