Automating Kerberos TGT Acquisition: Secure kinit Password Handling for AD Domain Join Automation


3 views

When automating Active Directory domain joins for RHEL servers, the manual kinit process becomes a bottleneck. The standard command kinit aduser@REALM.COM requires interactive password entry, which breaks automation workflows in Puppet/Chef/Ansible environments.

The enterprise-standard approach uses keytab files containing encrypted service principals:

# Generate keytab on AD controller
ktpass -princ aduser@REALM.COM -mapuser DOMAIN\aduser -crypto AES256-SHA1 -pass * -ptype KRB5_NT_PRINCIPAL -out /path/to/keytab

# Automated kinit with keytab
kinit -kt /etc/krb5.keytab aduser@REALM.COM

For environments where keytabs aren't feasible, consider an expect wrapper (note security implications):

#!/usr/bin/expect -f
set password [get_env_or_vault "KRB_PASS"]
spawn kinit aduser@REALM.COM
expect "Password for aduser@REALM.COM:" 
send "$password\r"
interact

Here's a secure Puppet manifest snippet using the keytab method:

class profile::ad_join {
  file { '/etc/krb5.keytab':
    ensure   => present,
    content  => file('secret_module/ad_join.keytab'),
    mode     => '0600',
    owner    => 'root',
    group    => 'root',
    replace  => true,
  }

  exec { 'obtain_kerberos_ticket':
    command     => '/usr/bin/kinit -kt /etc/krb5.keytab aduser@REALM.COM',
    refreshonly => true,
    subscribe   => File['/etc/krb5.keytab'],
  }
}
  • Always set keytab file permissions to 0600
  • Rotate keytabs through your Puppet secrets management
  • Never store plaintext passwords in manifests
  • Consider using Vault for credential management

Verify your TGT with:

klist -e
# Check encryption types match AD policies
KRB5_TRACE=/dev/stdout kinit -kt /path/to/keytab aduser@REALM.COM

When automating Active Directory domain joining for RHEL servers, the kinit password prompt becomes a major roadblock. Manual operation requires interactive password entry:

kinit aduser@REALM.COM
Password for aduser@REALM.COM: 

The enterprise solution is using Kerberos keytabs - encrypted files containing service principal credentials. Generate one on your AD controller:

ktpass -princ host/server.example.com@REALM.COM -mapuser DOMAIN\\service-account 
-pass MyP@ssw0rd -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL 
-out c:\temp\linuxserver.keytab

Then securely transfer this to your RHEL server and configure krb5.conf:

[libdefaults]
 default_realm = REALM.COM
 default_tkt_enctypes = aes256-cts-hmac-sha1-96
 default_tgs_enctypes = aes256-cts-hmac-sha1-96
 
[realms]
 REALM.COM = {
  kdc = dc1.realm.com
  admin_server = dc1.realm.com
 }

Here's a Puppet manifest snippet for automated TGT renewal:

class kerberos::authentication (
  String $keytab_path = '/etc/krb5.keytab',
  String $principal   = 'host/${::fqdn}@REALM.COM',
) {
  exec { 'kinit-renewal':
    command     => "/usr/bin/kinit -kt ${keytab_path} ${principal}",
    refreshonly => true,
    tries       => 3,
    try_sleep   => 5,
  }

  # Set up cron for ticket renewal
  cron { 'kerberos-ticket-renewal':
    command => "/usr/bin/kinit -kt ${keytab_path} ${principal}",
    user    => 'root',
    minute  => '*/15',
  }
}

While possible with Expect, this method stores passwords insecurely:

#!/usr/bin/expect -f
set password "MyP@ssw0rd"
spawn kinit aduser@REALM.COM
expect "Password for aduser@REALM.COM:"
send "$password\r"
interact
  • Verify keytab contents: klist -kte /etc/krb5.keytab
  • Check ticket cache: klist
  • Test authentication: kvno host/server.example.com@REALM.COM
  • Enable debug: KRB5_TRACE=/dev/stdout kinit -kt keytab principal

Always ensure keytabs have:

  • Minimum required privileges
  • Restrictive file permissions (600)
  • Regular rotation policies
  • Secure distribution mechanisms