How to Provide Kerberos Authentication to Greenplum Clients with Microsoft Active Directory
Article ID: 295476
Updated On:
Products
Issue/Introduction
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.
Environment
Resolution
The Greenplum master should already be set up to authenticate with Microsoft Active Directory.
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.
[libdefaults]
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
[realms]
EMEA.LOCAL = {
kdc =####.emea.local
admin_server = ####.emea.local
}
[domain_realm]
.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.
set KRB5CCNAME=%USERPROFILE%\krb5cache kinit "c:\Program Files (x86)\Greenplum\greenplum-clients-4.3.7.3-build-2\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.
Keytabs
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 [email protected] -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 [email protected]:your_password_visible_here Done! 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 [email protected] (18:AES256 CTS mode with HMAC SHA1-96) 4 13/04/16 19:14 [email protected] (17:AES128 CTS mode with HMAC SHA1-96) 4 13/04/16 19:14 [email protected] (16:DES3 CBC mode with SHA1-KD) 4 13/04/16 19:14 [email protected] (23:RC4 with HMAC)
You can then use a keytab with the following:
kinit -kt dev1.keytab dev1 or 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 --- VERSION: 1.0.0.1 DATABASE: warehouse HOST: prod1.emea.local PORT: 5432 GPLOAD: INPUT: - SOURCE: PORT_RANGE: [18080,18080] FILE: - /Users/dev1/Downloads/test.csv - FORMAT: csv - DELIMITER: ',' - QUOTE: '"' - ERROR_LIMIT: 25 - ERROR_TABLE: public.test_errors OUTPUT: - TABLE: public.test - MODE: INSERT 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
Troubleshooting
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.
set KRB5CCNAME=%USERPROFILE%\krb5cache kinit
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.
Additional Information
- Pivotal Greenplum Database (GPDB) 4.3.x
- Operating System (OS)- Red Hat Enterprise Linux (RHEL) 6.x
Feedback
