From krb5-bugs-incoming-bounces@PCH.mit.edu Sat Mar 17 21:36:38 2018 Return-Path: Received: from PCH.mit.edu (PCH.MIT.EDU [18.7.21.50]) by krbdev.mit.edu (Postfix) with ESMTPS id ECA584DC7C; Sat, 17 Mar 2018 21:36:37 -0400 (EDT) Received: from PCH.MIT.EDU (localhost.localdomain [127.0.0.1]) by PCH.mit.edu (8.13.8/8.12.8) with ESMTP id w2I1abwA004061; Sat, 17 Mar 2018 21:36:37 -0400 Received: from mailhub-dmz-1.mit.edu (MAILHUB-DMZ-1.MIT.EDU [18.9.21.41]) by PCH.mit.edu (8.13.8/8.12.8) with ESMTP id w2HNdpiW024538 for ; Sat, 17 Mar 2018 19:39:51 -0400 Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id w2HNdTMh010683 for ; Sat, 17 Mar 2018 19:39:51 -0400 X-Auditid: 1209190d-92dff70000002fdd-58-5aada74543ca Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.4.212]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 10.E3.12253.547ADAA5; Sat, 17 Mar 2018 19:39:50 -0400 (EDT) X-Content-Analysis: v=2.1 cv=bPfrW6KZ c=1 sm=1 tr=0 a=n+6dpZyqN8Ukwn9TnfXj7Q==:117 a=n+6dpZyqN8Ukwn9TnfXj7Q==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=v2DPQv5-lfwA:10 a=fjoRLJOTmXcg-lDCezEA:9 a=QEXdDO2ut3YA:10 Received: from [24.190.185.144] ([24.190.185.144:54220] helo=k9.internal.bright-prospects.com) by mta2.srv.hcvlny.cv.net (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id 42/40-03148-547ADAA5; Sat, 17 Mar 2018 19:39:49 -0400 Received: from [192.168.15.187] (unknown [192.168.15.187]) by k9.internal.bright-prospects.com (Postfix) with ESMTP id E5755801FE; Sat, 17 Mar 2018 19:39:48 -0400 (EDT) From: Richard Basch Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: kinit -kt KDB: Cannot find/read stored master key Message-ID: <67EAB55A-4DA5-4679-86D8-ECEC2E42D0DB@alum.mit.edu> Date: Sat, 17 Mar 2018 19:39:48 -0400 To: krb5-bugs@mit.edu, krbdev@mit.edu X-Mailer: Apple Mail (2.3273) Authentication-Results: symauth.service.identifier X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRWlGSWpSXmKPExsWy/BzLFV235WujDDY2alg0PDzO7sDo0XTm KHMAYxSXTUpqTmZZapG+XQJXxpNfB9gLNnBUrN+Z18D4lq2LkZNDSEBRormlm7WLkYNDQsBE 4vYqjy5GLqDwUSaJiScamUEcCYGvjBJPD95mhcj0M0m87vvBBuGsYZT4OPMWI8goNgENiTXn 54ONZRZQl/gz7xIzhK0tsWzha2aQFbwC+hK9z8HKhQWsJSZ0zWABsXkF7CXefvgHZrMIqEr0 TVwJViMCNKbx/QYmEFtCQFbi1myIkYwCRhK7z71incAoMAvJtllIts1C2LaAkXkVo2xKbpVu bmJmTnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGYEAKcUry7mD8d9frEKMAB6MSD++B4rVRQqyJ ZcWVuYcYJTmYlER5725eEyXEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhFc4H6icNyWxsiq1KB8m Jc3BoiTO626iHSUkkJ5YkpqdmlqQWgSTZeJgP8Qow8GhJMFbuAyoW7AoNT21Ii0zpwRZDSeI 4AJZwwO05uhSkDXFBYm5xZnpEEWnGHU5brx43cYsxJKXn5cqJc5bAjJNAKQoozQPbhgsuVxi lJUS5mVkYGAQ4gG6BhgIqPKvGMWBASDMWwoyhSczrwRu0yugI5iAjvBZugbkiJJEhJRUA+Ms IwEd91L2P2bfs6YlBehMUuAX/5x5KKzAWmdN9IHiV7ZrVlyYviN3O7+95e/t+36xBfM6bTO9 cyX9g6umpi/v5GMRWVumt27M4S59ma3LnHx/TcKNZ9fFFDWSnu3b21v54qbyu8NiantOLN3x 9aHJy7P/a56H+K64WXcjplkz79HaBKFpHKxKLMUZiYZazEXFiQBpGN3oKQMAAA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by PCH.mit.edu id w2HNdpiW024538 X-Mailman-Approved-At: Sat, 17 Mar 2018 21:36:36 -0400 X-Beenthere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu Content-Length: 1001 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.