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 node/host:

    $ ktpass -out ./ -princ host/ -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 ./ -princ vertica/ -mapuser vertica
     -mapop set -pass secret  -ptype KRB5_NT_PRINCIPAL

    For more information about keytab files, see

  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
    $ setspn -L verticanode01
        Registered ServicePrincipalNamefor CN=verticanode01,CN=Users,DC=dc,DC=com
  6. Copy the keytabs you created above, and, to the Linux host

  7. Combine the keytab files into a single keytab:

    [release@vertica krbTest]$ /usr/kerberos/sbin/ktutil
    ktutil:  rkt
    ktutil:  rkt
    ktutil:  list
    slot KVNO Principal
    ---- ---- ---------------------------------------------------------------------
      1    3  host/
      2   16  vertica/
    ktutil:  wkt
    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 /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/ -k -t
    $ klist
    Ticket cache: KFILE:/tmp/krb_ccache_1003
    Default principal: vertica/
    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
    $ chown dbadmin:verticadba
  11. Set the following Kerberos parameters using ALTER DATABASE to inform Vertica about the Kerberos principal:

    KerberosTicketDuration = 0
  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 AUTHENTICATION v_kerberos method 'gss' host '';
    => ALTER AUTHENTICATION v_kerberos enable;
    => GRANT AUTHENTICATION v_kerberos to windowsuser1;

    From the operating system command line:

    $ kinit windowsuser1
    $ vsql -U windowsuser1 -k vertica -K -h -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