Creating the principals and keytab on active directory

Active Directory stores information about members of the Windows domain, including users and hosts.

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.

  1. 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

  2. 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.

  3. 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

  4. 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.

  5. 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

  6. Copy the keytabs you created above, vertica.verticanode01.dc.com.keytab and host.verticanode01.dc.com.keytab, to the Linux host verticanode01.dc.com.

  7. 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.

  8. Copy the new keytab file to the catalog directory. For example:

    $ cp verticanode01.dc.com.keytab /home/dbadmin/VMart/v_vmart_nodennnn_catalog

  9. 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.

  10. Set the right permissions and ownership on the keytab files:

    $ chmod 600 verticanode01.dc.com.keytab
$ chown dbadmin:verticadba verticanode01.dc.com.keytab

  11. Set the following Kerberos configuration 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

  12. Restart the Vertica server.

  13. 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)

  14. 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