Sunday, August 24, 2014

Security Corner: What is a Kerberos Keytab and why should you use it?


Active Directory provides a Kerberos environment.  We have written extensively about Kerberos capabilities in this blog.  We also have explained that Centrify provides tight integration with Microsoft's Kerberos AD implementation by way of their MIT-Kerberos libraries and tools.  The advantage of using Centrify's tool set is that the tools are extensively tested against Microsoft's implementation.

A Kerberos key table (or "keytab") file is "is a file containing pairs of Kerberos principals and encrypted keys (these are derived from the Kerberos password)."(1).

Kerberos keytab files can help overcome two major issues:
  • The security requirement of not having plain-text passwords in scripts or helper files.
  • The increasing IT Infrastructure requirement for automation.  The proliferation elastic computing by way of private and public clouds requires that IT adds or reduces capacity on demand in a secure way.

Kerberos Keytabs 101

  • In a Kerberos environment, each system has at least one keytab table stored on disk.  The keytab table lists the service principals and provides at least one key for each of those service principals (/etc/krb5.keytab by default).  Remember that principals typically follow the "service@host/REALM" format.
  • End-users also have Kerberos files, but they are temporary (by default 10 hours), they are stored as a Kerberos cache file (by default /tmp/krb5cc_<uid of the user>), they list any user principals.
  • When working with a Centrified system, the location of the Centrify-enabled Kerberos tools is /etc/centrifydc/kerberos/bin.  
  • Quick primer on basic Kerberos tools:
    • kinit: is used to obtain a kerberos ticket-granting-ticket
    • klist: is used to list the cached tickets.
    • kdestroy: destroys kerberos tickets
  • The Centrify Kerberos tools documentation is publicly available here.
  • Keytabs are Sensitive/Confidential information: A Security Procedure needs to be established for the handling of keytabs, because whoever has the keytab can authenticate as the principal used to create it.  As a tip, this process should be viewed with the same sensitivity as the handling of private keys.

Using Kerberos Tools

Kerberos tools are great for troubleshooting purposes.
  1. Testing end-to-end AD connectivity and account availability with kinit (e.g. accunt jerry.seinfeld)
    # /usr/share/centrifydc/kerberos/bin/kinit jerry.seinfeld
    Password for jerry.seinfeld@CORP.CONTOSO.COM:

    You are prompted for the user's password.  The benefit of this test that it bypasses the NSS, PAM and authorization modules.  This means that any user in AD can be tested with kinit.
  2. Listing the contents of a keytab or cache file with klist
    1. For systems
      # /usr/share/centrifydc/kerberos/bin/klist -kt krb5.keytab
      Keytab name: FILE:krb5.keytab
      KVNO Timestamp         Principal
      ---- ----------------- ----------------------------------
      3 05/17/14 22:22:55 host/cen1@CORP.CONTOSO.COM

      Note: By default, during a system join (with adjoin) Centrify will automatically register service principals for  http ftp cifs nfs, this parameter is controlled by the adclient.krb5.service.principals directive of the centrifydc.conf file.
    2. For users (user root)
      Ticket cache: FILE:/tmp/krb5cc_0
      Default principal: jerry.seinfeld@CORP.CONTOSO.COM

      Valid starting     Expires            Service principal
      08/24/14 14:07:02  08/25/14 00:07:04  krbtgt/CORP.CONTOSO.COM@CORP.CONTOSO.COM
      renew until 08/25/14 14:07:02
      Notice that this is a Kerberos Ticket Granting Ticket (krbtgt).

Ticket-Granting-Tickets vs. Service Tickets

Depending on how the application is using the keytab, it's possible that it will request a ticket-granting ticket (TGT), or a service ticket.  Generally, a TGT is given upon a session log-in;  a service ticket is requested when a user attempts to access a service on the network.  The key here is that a principal without a servicePrincipalName (SPN) can't be used to request a service ticket.  This changes how the AD principal is created.

The example above shows how to request a TGT.  This example, shows how to test a keytab for a service ticket:
First, we check if the account has a servicePrincipalName (e.g. db2inst1)
$ adquery user -A db2inst1

Second, we attempt to get a service ticket (the keytab is db2inst1.keytab)
$ /usr/share/centrifydc/kerberos/bin/kinit -S db2inst1/engcen5.centrifyimage.vms -kt db2inst1.keytab db2inst1
[db2inst1@engcen5 ~]$ /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_1004
Default principal: db2inst1@CENTRIFYIMAGE.VMS

Valid starting     Expires            Service principal
11/24/14 11:24:46  11/24/14 21:24:47  db2inst1/engcen5.centrifyimage.vms@CENTRIFYIMAGE.VMS
        renew until 11/25/14 11:24:46
Notice that this is not a KRBTGT, but a service ticket.

Using Centrify Tools for Kerberos-related operations

adinfo (with the C option) can be used to review the system service principals, and encryption level. Remember that the latter is set by the domain controller functional level.
$ adinfo -C
Computer Account Diagnostics
  Joined as: cen1
  Trusted for Delegation: false
  Use DES Key Only: false
  Key Version: 6
  Service Principal Names: nfs/

Supported Encryption Type(s): RC4-HMAC

Operating System Version: 6.1:6.5 (Final)


adkeytab, is arguably one the most powerful command line tools provided by Centrify.  When used in tandem with scripts and the Kerberos tools it can help to increase security and provide flexibility in automation scenarios.  It has the ability to provision, deprovision and modify server and user principals.  Aside from adedit, adkeytab contains the largest command reference.

adkeytab  -  create  and manage Kerberos key tables (*.keytab files)and coordinate changes with the  Kerberos  key  distribution center(KDC) provided by Active Directory.

I will try to highlight some benefits of using adkeytab:
  • It can be used to create or adopt AD principals:  adkeytab can create the user in AD for you, or in a separation of duties scenario, the UNIX/Linux admin can adopt the account provided he has the appropriate rights to modify the AD account.
  • It randomizes the AD account's password:  The major issue with service accounts it that they are considered a shared account since at least one person (the creator or the user) knows the password.  With adkeytab it's possible to randomize the password of the AD account, effectively minimizing the need for aggressive password rotation.
  • Can be fully automated:  adkeytab can be used with your scripts to perform operations.  This helps with elastic or private clouds.
  • It's Kerberized!  what that means is that you can use a keytab to use adkeytab - this is great for automation.
  • Syntax can be tricky - there are so many options that it can be overwhelming for beginners; my tips are to use the long for options (e.g. --adopt) and verbose output.
  • Fixes stale AD computer accounts:  It can be used to reset the machine computer account.  Just elevate to use the adkeytab command with the -C (--change-password).  The output below uses the local system's computer account (--machine) in AD to reset the computer's password in AD.
$ dzdo adkeytab --change-password --machine -V
Attempting bind to centrifyimage.vms site:Demo-Site server:dc.centrifyimage.vms: ccache:FILE:/etc/krb5.ccache
Bind successful to server dc.centrifyimage.vms
Searching for AD Object: filter = (samAccountName=engcen5$), root = DC=centrifyimage,DC=vms
AD Object found: CN=engcen5,OU=UNIX-Servers,OU=Unix,DC=centrifyimage,DC=vms
Key Version = 21
Changing account 'engcen5' password with machine credentials.
Searching for AD Object: filter = (samAccountName=engcen5$), root = DC=centrifyimage,DC=vms
AD Object found: CN=engcen5,OU=UNIX-Servers,OU=Unix,DC=centrifyimage,DC=vms
Key Version = 22
Success: Change Password: Default Key Tab

The posts below, cover scenarios that use Kerberos key table files:

(1) Source: Indiana University IT,

No comments:

Post a Comment