Pivotal Knowledge Base


How to provide Kerberos authentication to Greenplum clients with Microsoft Active Directory


Product Version

Pivotal Greenplum (GPDB)




This article provides an example of how to provide Kerberos authentication to the Greenplum clients, gpload and psql. It is a practical walkthrough for the Greenplum documentation on the subject that can be accessed here.  


The Greenplum master should already be set up to authenticate with Microsoft Active Directory. You can refer to the article here on how to set this up.

Windows Client Setup

The Greenplum clients comply with MIT Kerberos and not Microsoft Active Directory directly. Because of this, you will need to install the MIT Kerberos Windows client version on the server's running the Greenplum clients.

At this time, this is MIT Kerberos for Windows 4.0.1 (for krb5) available here

In this exercise, automatic startup of this service was not enabled, as the tickets that it has do not work with Greenplum. It would be better to take control of the tickets by manually running a kinit.

Take a copy of your /etc/krb5.conf from your Greenplum master and place it in it's default location - C:\ProgramData\MIT\Kerberos5\krb5.ini. The default_ccache_name was omitted from [libdefaults], as KRB5CCNAME is a file, not a directory and should be unique to each login on the server. Also, remove [logging] as it does not appear to work.

 debug = true
 default_etypes = aes256-cts-hmac-sha1-96
 default_realm = EMEA.LOCAL
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

  kdc =bocdc.emea.local
  admin_server = bocdc.emea.local

 .emea.local = EMEA.LOCAL
 emea.local = EMEA.LOCAL

So no default_ccache_name is used and have each user set their own private KRB5CCNAME, either in their own local user environment or within a session. 


"c:\Program Files (x86)\Greenplum\greenplum-clients-\greenplum_clients_path.bat"

The Greenplum psql client should now work. If you get warnings indicating that "Console code page differs from Windows code page", you can run the Windows utility chcp to correct that.

psql -h prod1.emea.local warehouse
psql (8.2.15)
WARNING: Console code page (850) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.

warehouse=# \q

chcp 1252
Active code page: 1252

psql -h prod1.emea.local warehouse
psql (8.2.15)
Type "help" for help.


You can remove the need to enter a password or having to code it in a script by using a Kerberos keytab instead.

The Windows ktpass utility can generate a keytab. While this utility expects a user account to have a Service Principal Name, it does not appear to be required. You can specify it as a parameter to ktpass and ignore the warning that it cannot be set. The Java JRE keytab utility ktab does not require one. 

ktpass -out dev1.keytab -princ dev1@EMEA.LOCAL -mapUser dev1 -pass your_secret_password -crypto all -ptype KRB5_NT_PRINCIPAL

It works despite the warning message "Unable to set SPN mapping data".

The JAVA JRE utility ktab can be run by all end users and does not require administrative permissions.   If you require AES256-CTS-HMAC-SHA1-96 encryption, you will need to download the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK/JRE" from Oracle. Also be aware that when it prompts for a password, the password will be visible on screen. 

C:\Users\dev1>"\Program Files\Java\jre1.8.0_77\bin"\ktab -a dev1
Password for dev1@EMEA.LOCAL:your_password_visible_here
Service key for dev1 is saved in C:\Users\dev1\krb5.keytab

C:\Users\dev1>"\Program Files\Java\jre1.8.0_77\bin"\ktab -l -e -t
Keytab name: C:\Users\dev1\krb5.keytab
KVNO Timestamp Principal
---- -------------- ------------------------------------------------------
4 13/04/16 19:14 dev1@EMEA.LOCAL (18:AES256 CTS mode with HMAC SHA1-96)
4 13/04/16 19:14 dev1@EMEA.LOCAL (17:AES128 CTS mode with HMAC SHA1-96)
4 13/04/16 19:14 dev1@EMEA.LOCAL (16:DES3 CBC mode with SHA1-KD)
4 13/04/16 19:14 dev1@EMEA.LOCAL (23:RC4 with HMAC)

You can then use a keytab with the following:

kinit -kt dev1.keytab dev1
kinit -kt %USERPROFILE%\krb5.keytab dev1

gpload example

This is an example of a Windows desktop logged in as the user dev1 to the AD domain.

You can then omit the USER: from the gpload .yaml control file.

type test.yaml
DATABASE: warehouse
HOST: prod1.emea.local
PORT: 5432

PORT_RANGE: [18080,18080]
- /Users/dev1/Downloads/test.csv
- FORMAT: csv
- QUOTE: '"'
- ERROR_TABLE: public.test_errors
- TABLE: public.test


kinit -kt %USERPROFILE%\krb5.keytab dev1

gpload.py -f test.yaml
2016-04-10 16:54:12|INFO|gpload session started 2016-04-10 16:54:12
2016-04-10 16:54:12|INFO|started gpfdist -p 18080 -P 18080 -f "/Users/dev1/Downloads/test.csv" -t 30
2016-04-10 16:54:13|INFO|running time: 0.23 seconds
2016-04-10 16:54:13|INFO|rows Inserted = 3
2016-04-10 16:54:13|INFO|rows Updated = 0
2016-04-10 16:54:13|INFO|data formatting errors = 0
2016-04-10 16:54:13|INFO|gpload succeeded


In case of the error message shown below:

Credentials cache I/O operation failed XXX
(Kerberos error 193)
krb5_cc_default() failed

The solution could be:

Kerberos cannot find your cache file.


In case of the error message shown below:

kinit: Generic preauthentication failure while getting initial credentials

The solution could be:

kinit -k -t cannot find the keytab.  Confirm the full path and filename for the kerberos keytab.


Powered by Zendesk