Re: Decrypt integrity check failed while getting initial ticket

On 12/9/19 1:56 PM, Greg Hudson [Masked] wrote:
> Lereta Email Checkpoint: External email. Please make sure you trust this source before clicking links or opening attachments.
> 
> **********************************************************************
> 
> 
> --------------------------Blur---------------------------
> Preview: On 12/9/19 1:04 PM, Stephen Carville (Kerberos List) wrote: > --> SPAM? CLICK to BLOCK: https://dnt.abine.com/#/block_email/[email protected]/[email protected]
> 
> This email is Masked using Blur - it was sent from mit.edu to [email protected] (your reply stays Masked). To protect your privacy, do not forward this message, or add new recipients like CCs or BCCs (https://www.abine.com/faq.html#caniaddcc).
> 
> Thanks for being a Blur customer! If you haven't yet, [ Try DeleteMe at a discount: https://joindeleteme.com/?utm_campaign=blur-offer&utm_source=masked-email-header ]
> -------------------------By Abine--------------------------
> 
> On 12/9/19 1:04 PM, Stephen Carville (Kerberos List) wrote:
>> Recently I migrated the kerberos master and one slave to another
>> location using tool called "Zerto".  Perhaps coincidentally, replication
>> broke with the above error message. I checked that DNS A and PTR records
>> for all the servers are correct.  I can get a ticket using kinit (kinit
>> -k host/<hostname>). I finally recreated the keytab file
>> (/etc/krb5.keytab) and propagated it to the other three servers.  Still
>> no replication.
> 
> I suggest running "KRB5_TRACE=/dev/stdout kprop ..." to get a better
> idea of what ticket it's trying to get.  It should be doing something
> similar to "kinit -k host/hostname", but if you've just migrated hosts,
> there could be a difference in the canonical hostname as it appears to
> libkrb5.
> 

That helped... Thank you.

The trace revealed that the master server was checking one of the slave 
servers. Since it was not updated with the new keys, the authentication 
failed.

-------------------------------------------------
[13734] 1575929629.412353: Initializing MEMORY:_kproptkt with default 
princ host/[email protected]
[13734] 1575929629.413138: Getting initial credentials for 
host/[email protected]
[13734] 1575929629.413497: Setting initial creds service to 
host/[email protected]
[13734] 1575929629.413565: Sending request (228 bytes) to TOTALFLOOD.COM
[13734] 1575929629.413809: Resolving hostname kdc01.lereta.net
[13734] 1575929629.414318: Sending initial UDP request to dgram 
10.222.75.29:88
[13734] 1575929629.415194: Received answer from dgram 10.222.75.29:88
[13734] 1575929629.415261: Response was not from master KDC
[13734] 1575929629.415349: Processing preauth types: 19
[13734] 1575929629.415380: Selected etype info: etype aes256-cts, salt 
"(null)", params ""
[13734] 1575929629.415391: Produced preauth for next request: (empty)
[13734] 1575929629.415403: Salt derived from principal: 
TOTALFLOOD.COMhostscakerb01.lereta.net
[13734] 1575929629.415413: Getting AS key, salt 
"TOTALFLOOD.COMhostscakerb01.lereta.net", params ""
[13734] 1575929629.415596: Retrieving 
host/[email protected] from FILE:/etc/krb5.keytab (vno 
0, enctype aes256-cts) with result: 0/Success
[13734] 1575929629.415629: AS key obtained from gak_fct: aes256-cts/6FC7
/usr/sbin/kprop: Decrypt integrity check failed while getting initial ticket
-------------------------------------------------

I had the realm defined thusly:

[realms]
  TOTALFLOOD.COM = {
   kdc = kdc01.lereta.net

   admin_server = master-kdc.lereta.net
   master_kdc = master-kdc.lereta.net
  }

kdc01.lereta.net is a CNAME record for scakerb02.lereta.net

master-kdc.lereta.net is a CNAME record for scakerb01.lereta.net

I changed the kdc line to "kdc = scakerb01.lereta.net" and the 
propagation succeeded.

I then changed it back and all is good again.

--
Stephen
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos