This is the multi-page printable view of this section. Click here to print.
Kerberos provides a strong cryptographic authentication against the devices which lets the client & servers to communicate in a more secured manner. It addresses network security problems.
Your system must have one or more Kerberos Key Distribution Centers (KDC) installed and configured. The KDCs must be accessible from every node in your Vertica Analytic Database cluster.
The KDC must support Kerberos 5 using GSS-API. For details, see the MIT Kerberos Distribution Page.
Vertica uses service principals for system-level operations. These principals identify the Vertica service and are used as follows:
Kerberized Vertica clients request access to this service when they authenticate to the database.
System processes like the Tuple Mover use this identity when they authenticate to external services such as Hadoop.
Create principals and keys as follows:
Start the Kerberos 5 database administration utility (kadmin or kadmin.local) to create Vertica principals on a Linux KDC.
Use kadmin if you are accessing the KDC on a remote server. If you have access to the Kerberos administrator password, you can use kadmin on any machine where the Kerberos 5 client package is installed. When you start kadmin, the utility prompts you for the Kerberos administrator's password. You might need root privileges on the client to run kadmin.
Use kadmin.local if:
The KDC is on the machine that you are logging in to.
You have root privileges on that server.
kadmin.local does not require the administrators login credentials.
For more information about the kadmin and kadmin.local commands, see the kadmin documentation.
Create one service principal for Vertica on each node. The host name must match the value supplied by the operating system. The following example creates the service principal vertica for the node named v_vmart_node0001.example.com:
$ sudo /usr/kerberos/sbin/kadmin.local
kadmin.local add_principal vertica/v_vmart_node0001.example.com
Repeat the ktadd command once per principal. You can create separate keytabs for each principal user or add them all to a single keytab file (such as krb5.keytab). If you are using a single file, see the documentation for the -glob option in the MIT Kerberos documentation.
You must have a user principal for each Vertica Analytic Database user that uses Kerberos Authentication. For example:
$ sudo /usr/kerberos/sbin/kadmin.local
kadmin.local add_principal [options] VerticaUser1
Copy each keytab file to the /etc folder on the corresponding cluster node. Use the same path and file name on all nodes.
On each node, make the keytab file readable by the file owner who is running the database process (typically, the Linux dbadmin user). For example, you can change ownership of the files to dbadmin as follows:
$ sudo chown dbadmin *.keytab
After you create a keytab file, you can use the klist command to view keys stored in the file:
$ sudo /usr/kerberos/bin/klist -ke -t
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ------------------- --------------------------------------------------------------------------
4 08/15/2017 7:35:41 vertica/v_vmart_node0001.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
4 08/15/2017 7:35:41 vertica/v_vmart_node0001.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
On Vertica run the following to ensure the Kerberos parameters are set correctly:
=> select parameter_name, current_value from configuration_parameters where parameter_name like 'Ker%';
parameter_name | current_value
-----------------------+---------------------------------------------------------------------
KerberosHostname | v_vmart_node0001.example.com
KerberosKeytabFile | /etc/krb5.keytab
KerberosRealm | EXAMPLE.COM
KerberosTicketDuration | 0
KerberosServiceName | vertica
(5 rows)
Ensure that all clients use the gss authentication method.
From Vertica:
=> CREATE USER bob;
CREATE USER
=> CREATE AUTHENTICATION v_kerberos method 'gss' host '0.0.0.0/0';
CREATE AUTHENTICATION
=> ALTER AUTHENTICATION v_kerberos enable;
ALTER AUTHENTICATION
=> GRANT AUTHENTICATION v_kerberos to bob;
GRANT AUTHENTICATION
From the operating system command line:
$ kinit bob
$ vsql -U bob -k vertica -K v_vmart_node0001.example.com -h v_vmart_node0001 -c "select client_authentication_name,
authentication_method from sessions;"
client_authentication_name | authentication_method--
----------------------------+-----------------------
v_kerberos | GSS-Kerberos
(1 row)
On Vertica, run KERBEROS_CONFIG_CHECK to verify the Kerberos configuration. KERBEROS_CONFIG_CHECK verifies the following:
The existence of the kinit and kb5.conf files.
Whether the keytab file exists and is set
The Kerberos configuration parameters set in the database:
KerberosServiceName
KerberosHostname
KerberosRealm
Vertica Principal
That Kerberos can read the Vertica keys
That Kerberos can get the tickets for the Vertica principal
That Vertica can initialize the keys with kinit
Each client and Vertica Analytic Database server in the Kerberos realm must have a valid, identically configured Kerberos configuration (krb5.conf) file. Without this file, the client does not know how to reach the KDC.
If you use Microsoft Active Directory, you do not need to perform this step. Refer to the Kerberos documentation for your platform for more information about the Kerberos configuration file on Active Directory.
At a minimum, you must configure the following sections in the krb5.conf file.
libdefaults]—Settings used by the Kerberos 5 libraryrealms]—Realm-specific contact information and settingsdomain_realm]—Maps server hostnames to Kerberos realmsSee the Kerberos documentation for information about other sections in this configuration file.
You must update the /etc/krb5.conf file to reflect your site's Kerberos configuration. The simplest way to enforce consistency among all clients and servers in the Kerberos realm is to copy the /etc/krb5.conf file from the KDC. Then, place this file in the /etc directory on each Vertica cluster node.
Follow these steps to inform Vertica about the principal name and keytab location.
For information about the parameters that you are setting in this procedure, see Kerberos parameters.
Log in to the database as an administrator (typically dbadmin).
Set the KerberosKeyTabFile configuration parameter to point to the location of the keytab file:
=> ALTER DATABASE DEFAULT SET PARAMETER KerberosKeytabFile = '/etc/krb5.keytab';
The keytab file must be in the same location (/etc/krb5.keytab in this example) on all nodes.
Set the service name for the Vertica principal; for example, vertica:
=> ALTER DATABASE DEFAULT SET PARAMETER KerberosServiceName = 'vertica';
Provide the realm portion of the principal, for example, EXAMPLE.COM:
=> ALTER DATABASE DEFAULT SET PARAMETER KerberosRealm = 'EXAMPLE.COM'
To make sure that all clients use the gss authentication method, run the following statements:
=> CREATE AUTHENTICATION <method_name> METHOD 'gss' HOST '0.0.0.0/0';
=> GRANT AUTHENTICATION <method_name> TO Public;
For more information, see Implementing Client Authentication.
Active Directory stores information about members of the Windows domain, including users and hosts.
Vertica uses the Kerberos protocol to access this information in order to authenticate Windows users to the Vertica database. The Kerberos protocol uses principals to identify users and keytab files to store their cryptographic information. You need to install the keytab files into Vertica to enable the Vertica database to cryptographically authenticate windows users.
This procedure describes:
Creating a Vertica service principal.
Exporting the keytab files for these principals
Installing the keytab files in the Vertica database. This allows Vertica to authenticate Windows users and grant them access to the Vertica database.
Create a Windows account (principal) for the Vertica service and one Vertica host for each node/host in the cluster. This procedure creates Windows accounts for host verticanode01 and service vertica running on this node.
When you create these accounts, select the following:
User cannot change password
Password never expires
If you are using external tables on HDFS that are secured by Kerberos authentication, you must enable Delegation. To do so, access the Active Directory Users and Computers dialog, right-click the Windows account (principal) for the Vertica service, and select Delegation. Trust this user for delegation to any service.
Run the following command to create the keytab for the host verticanode01.dc.com node/host:
$ ktpass -out ./host.verticanode01.dc.com.keytab -princ host/verticanode01.dc.com@DC.COM -mapuser verticanode01
-mapop set -pass secret -ptype KRB5_NT_SRV_HST
Run the following command to create the keytab for the vertica service:
$ ktpass -out ./vertica.verticanode01dc.com.keytab -princ vertica/verticanode01.dc.com@DC.COM -mapuser vertica
-mapop set -pass secret -ptype KRB5_NT_PRINCIPAL
For more information about keytab files, see Technet.Microsoft.com.
Run the following commands to verify that the service principal name is mapped correctly. You must run these commands for each node in your cluster:
$ setspn -L vertica
Registered ServicePrincipalNamefor CN=vertica,CN=Users,DC=dc,DC=com
vertica/verticanode01.dc.com
$ setspn -L verticanode01
Registered ServicePrincipalNamefor CN=verticanode01,CN=Users,DC=dc,DC=com
host/verticanode01.dc.com
Copy the keytabs you created above, vertica.verticanode01.dc.com.keytab and host.verticanode01.dc.com.keytab, to the Linux host verticanode01.dc.com.
Combine the keytab files into a single keytab:
[release@vertica krbTest]$ /usr/kerberos/sbin/ktutil
ktutil: rkt host.verticanode01.dc.com.keytab
ktutil: rkt vertica.verticanode01.dc.com.keytab
ktutil: list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 3 host/verticanode01.dc.com@DC.COM
2 16 vertica/verticanode01.dc.com@DC.COM
ktutil: wkt verticanode01.dc.com.keytab
ktutil: exit
This creates a single keytab file that contains the server principal for authentication.
Copy the new keytab file to the catalog directory. For example:
$ cp verticanode01.dc.com.keytab /home/dbadmin/VMart/v_vmart_nodennnn_catalog
Test the keytab file's ability to retrieve a ticket to ensure it works from the Vertica node:
$ kinit vertica/verticanode01.dc.com -k -t verticanode01.dc.com.keytab
$ klist
Ticket cache: KFILE:/tmp/krb_ccache_1003
Default principal: vertica/verticanode01.dc.com@DC.COM
Valid starting Expires Service principal
04/08/2017 13:35:25 04/08/2017 23:35:25 krbtgt/DC.COM@DC.COM
renew until 04/15/2017 14:35:25
When the ticket expires or not automatically retrieved you need to manually run the kinit command. See Get the Kerberos ticket and authenticate Vertica.
Set the right permissions and ownership on the keytab files:
$ chmod 600 verticanode01.dc.com.keytab
$ chown dbadmin:verticadba verticanode01.dc.com.keytab
Set the following Kerberos parameters using ALTER DATABASE to inform Vertica about the Kerberos principal:
KerberosKeytabFile=<CATALOGDIR>/verticanode01.dc.com.keytab
KerberosRealm=DC.COM
KerberosServiceName=vertica
KerberosTicketDuration = 0
KerberosHostname=verticanode01.dc.com
Restart the Vertica server.
Test your Kerberos setup as follows to ensure that all clients use the gss authentication method.
From Vertica:
=> CREATE USER windowsuser1;
CREATE USER
=> CREATE AUTHENTICATION v_kerberos method 'gss' host '0.0.0.0/0';
CREATE AUTHENTICATION
=> ALTER AUTHENTICATION v_kerberos enable;
ALTER AUTHENTICATION
=> GRANT AUTHENTICATION v_kerberos to windowsuser1;
GRANT AUTHENTICATION
From the operating system command line:
$ kinit windowsuser1
$ vsql -U windowsuser1 -k vertica -K verticanode01.dc.com -h verticanode01.dc.com -c "select client_authentication_name,
authentication_method from sessions;"
client_authentication_name | authentication_method--
----------------------------+-----------------------
v_kerberos | GSS-Kerberos
(1 row)
Run KERBEROS_CONFIG_CHECK to verify the Kerberos configuration. KERBEROS_CONFIG_CHECK verifies the following:
The existence of the kinit and kb5.conf files.
Whether the keytab file exists and is set
The Kerberos configuration parameters set in the database:
KerberosServiceName
KerberosHostname
KerberosRealm
Vertica Principal
That Kerberos can read the Vertica keys
That Kerberos can get the tickets for the Vertica principal
That Vertica can initialize the keys with kinit
If your organization uses Kerberos as part of the login process, Kerberos tickets are automatically retrieved upon login. Otherwise, you need to run kinit to retrieve the Kerberos ticket.
The following example shows how to retrieve the ticket and authenticate Vertica Analytic Database with the KDC using the kinit command. EXAMPLE.COM is the realm name. You must use the realm name with your username to retrieve a Kerberos ticket. See Specify KDC information and configure realms.
$ kinit
Password for principal_user@EXAMPLE.COM: kpasswd
You are prompted for the password of the principal user name created when you created the principals and keytabs (see Create the Vertica principals and keytabs on Linux KDC).
The Kerberos ticket gets cached for a pre-determined length of time. See Ticket Management in the Kerberos documentation for more information on setting expiration parameters.
Upon expiration, you need to run the kinit command again to retrieve another Kerberos ticket.