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/b4426...@opayq.com/fwd.bgwk92jj1...@opayq.com
>
> This email is Masked using Blur - it was sent from mit.edu to
> b4426...@opayq.com (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/). 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/scakerb01.lereta@totalflood.com
[13734] 1575929629.413138: Getting initial credentials for
host/scakerb01.lereta@totalflood.com
[13734] 1575929629.413497: Setting initial creds service to
host/scakerb02.lereta@totalflood.com
[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/scakerb01.lereta@totalflood.com 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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
