Kinit Error Messages

Password incorrect while getting initial credentials

Example

kinit -kt /etc/security/keytabs/spark.headless.keytab ambari-qa@EXAMPLE.COM
kinit: Password incorrect while getting initial credentials

Cause

This will occur when the keytab file is out of sync with the KDC. Meaning that the password stored in the KDC for the principal is different than the one embedded in the keytab file.

One way to verify this is the case is to compare the key version numbers (KVNO) in the KDC and the keytab file.

The key version number in the keytab file can be found by listing the contents of the keytab file using the klist utility:

klist -kte /etc/security/keytabs/smokeuser.headless.keytab

Keytab name: FILE:/etc/security/keytabs/smokeuser.headless.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
1 09/24/15 12:39:17 ambari-qa@EXAMPLE.COM (arcfour-hmac)
1 09/24/15 12:39:17 ambari-qa@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
1 09/24/15 12:39:17 ambari-qa@EXAMPLE.COM (des-cbc-md5)
1 09/24/15 12:39:17 ambari-qa@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
1 09/24/15 12:39:17 ambari-qa@EXAMPLE.COM (des3-cbc-sha1)

Note: The KVNO for each of the keytabs in this keytab file is 1.  This is seen in the first column of the kay table.

The key version number in the KDC can be found by getting the information about the principal using the kadmin or kadmin.local utilities:

kadmin.local -q 'get_principal ambari-qa@EXAMPLE.COM'

Authenticating as principal root/admin@EXAMPLE.COM with password.
Principal: ambari-qa@EXAMPLE.COM
Expiration date: [never]
Last password change: Thu Sep 24 12:39:16 UTC 2015
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Thu Sep 24 12:39:16 UTC 2015 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 6
Key: vno 1, aes256-cts-hmac-sha1-96, no salt
Key: vno 1, aes128-cts-hmac-sha1-96, no salt
Key: vno 1, des3-cbc-sha1, no salt
Key: vno 1, arcfour-hmac, no salt
Key: vno 1, des-hmac-sha1, no salt
Key: vno 1, des-cbc-md5, no salt
MKey: vno 1
Attributes:
Policy: [none]

Note: The KVNO (or vno) for each of the keys is 1. This is seen in the list of Key entries within the principal details

In this example, the keytab file matches the KDC. In the event a password mismatch occurs, it will be likely that the KVNO values do not match.  

This situation can occur for various reasons.  The most-likely case is that a user manually generated keytab file using either the kadmin or kadmin.local utility.  in the case of the kadmin utility, this password is automatically changed when creating a keytab file and there is no way to change this behavior.  In the case of the kadmin.local utility, the default behavior is to change the password upon creating a the keytab file; however by specifying the -norandkey option when doing so, the password will remain untouched. 

Solution

The only way to fix this issue is to regenerate the keytab file and distribute to the necessary hosts. The can be done manually using the kadmin or kadmin.local utilities or it can be done via Ambari by clicking on the "Regenerate Keytabs" button on the Kerberos administration page.