Decrypt integrity check failed

[Marcus Watts]

"Richard E. Silverman" <res at qoxp.net> writes:
...
> Check the key version number:
> 
> # klist -k /etc/krb5.keytab
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
>   14 host/foo.bar.com at BAR.COM
> 
> $ kvno host/foo.bar.com at BAR.COM
> host/foo.bar.com at BAR.COM: kvno = 14
> 
> Make sure they match.  If they don't, re-extact the key:
> 
> # kadmin
> Password for you/admin at BAR.COM:
> kadmin: ktadd -k /etc/krb5.keytab host/foo.bar.com at BAR.COM

Couple of things.

There is another way to check out whether a keytab works: kinit.
This is good because it's not impossible to get a keytab that *appears*
to have the same kvno but doesn't work.  (for instance, delete the
principal, then recreate it.)

For instance:

	spam# klist -ekt /etc/krb5.keytab
	Keytab name: FILE:/etc/krb5.keytab
	KVNO Timestamp         Principal
	---- ----------------- --------------------------------------------------------
	   3 08/19/04 03:56:25 imap/spam.ifs.umich.edu at UMICH.EDU (Triple DES cbc mode with HMAC/sha1) 
	   3 08/19/04 03:56:25 imap/spam.ifs.umich.edu at UMICH.EDU (DES cbc mode with CRC-32) 
	   3 03/22/06 04:01:29 pop/spam.ifs.umich.edu at UMICH.EDU (Triple DES cbc mode with HMAC/sha1) 
	   3 03/22/06 04:01:29 pop/spam.ifs.umich.edu at UMICH.EDU (DES cbc mode with CRC-32) 
	spam# 
tells me I have 2 principals, each with 2 encryption types,
(and when those keytab entries were written, if you care.)
	spam# kinit -k -t /etc/krb5.keytab imap/spam.ifs.umich.edu
	spam# klist -5fea
	Ticket cache: FILE:/tmp/krb5cc_25131_eVt6pe
	Default principal: imap/spam.ifs.umich.edu at UMICH.EDU

	Valid starting     Expires            Service principal
	07/11/06 00:45:16  07/12/06 00:45:16  krbtgt/UMICH.EDU at UMICH.EDU
		Flags: FPI, Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1 
		Addresses: (none)
	spam# 
tells me that I have a keytab entry that actually works for
imap/spam.ifs.umich.edu at UMICH.EDU, also it looks likely that I
used 3des to get that key (plus some other information of no particular
consequence here.)

Another clue that's sometimes useful is log file entries, in this case,
in krb5kdc's log:
	Jul 11 00:45:16 AS_REQ (7 etypes {18 17 16 23 1 3 2}) 141.211.1.36: ISSUE: authtime 1152593116, etypes {rep=16 tkt=16 ses=16}, imap/spam.ifs.umich.edu at UMICH.EDU for krbtgt/UMICH.EDU at UMICH.EDU
For instance, that can tell you which principal you were actually trying to authenticate
as.

Secondly, in this case, since it appears that "jonr" is trying to
set up replication, it's important to be very careful about configuration
files.  Specifically, you probably don't want krb5.conf entries (or DNS
entries) that point to slaves until you have replication working to those slaves.
If you're somehow trying to get a ticket from a slave that has an old
copy of the database, there's definitely opportunity for confusion.

				-Marcus