Decrypt integrity check failed while getting initial ticket

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Decrypt integrity check failed while getting initial ticket

Stephen Carville (Kerberos List)
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.

Any suggestions?

BTW, while trying to fix it, I noticed that every time I use ktadd to
add a key to krb5.keytab the KVNO increments.  Is that normal?

--
Stephen
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Decrypt integrity check failed while getting initial ticket

Benjamin Kaduk-2
Answering only the unimportant part for lack of insight on the other one...

On Mon, Dec 09, 2019 at 10:04:17AM -0800, 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.
>
> Any suggestions?
>
> BTW, while trying to fix it, I noticed that every time I use ktadd to
> add a key to krb5.keytab the KVNO increments.  Is that normal?

Yes, that is normal.  Otherwise any administrator with "extract keytab"
permissions could ~silently fetch the currently in-use keys for a service
and start decrypting or forging traffic; requiring a kvno increment (and
new random key) makes the operation more noticeable and prevents the
exfiltration of the live, in-use, key material.

-Ben
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Decrypt integrity check failed while getting initial ticket

Greg Hudson
In reply to this post by Stephen Carville (Kerberos List)
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.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Decrypt integrity check failed while getting initial ticket

Stephen Carville (Kerberos List)
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/b44261a2@.../FWD.bgwk92jj1grb@...
>
> This email is Masked using Blur - it was sent from mit.edu to [hidden email] (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/[hidden email]
[13734] 1575929629.413138: Getting initial credentials for
host/[hidden email]
[13734] 1575929629.413497: Setting initial creds service to
host/[hidden email]
[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/[hidden email] 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos