|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Mon, 9 Dec 2019 10:31:19 -0800 From: Benjamin Kaduk <kaduk@mit.edu> To: "Stephen Carville (Kerberos List)" <b44261a2@opayq.com> Message-ID: <20191209183119.GI13890@kduck.mit.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <ed3b1f90-bd01-2797-43ae-1215395aeff3@opayq.com> Cc: kerberos@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kerberos-bounces@mit.edu 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 Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |