[39232] in Kerberos
Re: help with OTP
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Apr 26 01:32:40 2023
Message-ID: <7586f99f-1c5e-f8c9-e128-eb457508556b@mit.edu>
Date: Wed, 26 Apr 2023 01:27:47 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>,
Matt Zagrabelny <mzagrabe@d.umn.edu>
Cc: kerberos <kerberos@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <202304260001.33Q01xYH024064@hedwig.cmf.nrl.navy.mil>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
On 4/25/23 20:01, Ken Hornstein via Kerberos wrote:
> First, there's about 500x ways for PKINIT to go wrong, and when it does
> go wrong 99% of the time you fall back to a password so it's hard to
> figure out exactly what failed.
Assuming the kadmin client and KDC are running 1.12 or later, you can
create WELLKNOWN/ANONYMOUS with the -nokey option (instead of -randkey)
to disable the password fallback. Or you can "kadmin.local purgekeys
-all WELLKNOWN/ANONYMOUS" to remove the principal's long-term keys once
it already exists. If this is done you should get PKINIT error messages
from kinit -n if the KDC offered PKINIT and the client couldn't make it
work, like this:
$ kinit -n
kinit: Pre-authentication failed: No pkinit_anchors supplied while
getting initial credentials
(The PKINIT doc page still says to create WELLKNOWN/ANONYMOUS with
-randkey, even though it talks about the -nokey option for client
principals. I will work on documentation updates based on this thread.)
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
