[15899] in Kerberos-V5-bugs
[krbdev.mit.edu #8651] kinit -kt KDB: Cannot find/read stored master
daemon@ATHENA.MIT.EDU (Richard Basch via RT)
Sat Mar 17 21:36:45 2018
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Richard Basch via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-8651@krbdev.mit.edu>
Message-ID: <rt-8651-48300.8.56364802517398@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #8651'":;
Date: Sat, 17 Mar 2018 21:36:38 -0400 (EDT)
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
Content-Type: multipart/mixed; boundary="===============0225855158451680158=="
Errors-To: krb5-bugs-bounces@mit.edu
--===============0225855158451680158==
I have found automated jobs that are executed on a KDC using "kinit -kt KDB:" may sometimes fail with:
kinit: Cannot find/read stored master key while setting up KDB key tab for realm XXX
However,if the script is retried, it invariably works. I suspect there is a transient locking condition which may sporadically cause a failure. The k5stash file path is local and the “ctime” has not changed anytime within the intervals of the run.
FYI - KDB: offers a great way to authenticate using a Kerberos-internal principal (e.g. kadmin/admin) to prove it is the KDC infrastructure, without having to create secondary files which can be copied out-of-band or for which their distribution cannot be deterministically sync’d with respect to Kerberos iprop propagation. For most use-cases, I prefer keytabs but to prove Kerberos infrastructure identity, I prefer not to create extra keytabs and to rotate the keys aggressively to mitigate impact from any unauthorized extraction of Kerberos’ keys.
--===============0225855158451680158==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
--===============0225855158451680158==--
