[38874] in Kerberos
Re: Fwd: FW: kinit failing when AD user joining using smaercard PIN
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Wed Mar 3 14:58:15 2021
Message-ID: <202103031143.123Bh7iE002030@hedwig.cmf.nrl.navy.mil>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Vikram Yadav <vikrampal@gmail.com>
In-Reply-To: <CALZLQ=a8_t7=RY7PMez_b5Xh7VkJ5G=qrEpr6V2JPB5qXkjMEw@mail.gmail.com>
MIME-Version: 1.0
Date: Wed, 03 Mar 2021 06:44:30 -0500
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>I rectified the pkinit_kdc_hostname = blrdhcdev-ad.blrdhcdev.com
>tested again but it throws error regarding "no acceptable EKU in KDC
>cert"
>
>I read the link you sent in the below mail, it says setting
>pkinit_eku_checking is not necessary.
Well, hm, I am not the expert on how AD realms and their certificates
are normally created. I was under the impression that normally the
correct EKU is placed in the certificate, but maybe that didn't happen
in this case. You COULD get a copy of the KDC certificate (just the
public portion, of course) and examine it with the openssl command-line
tools if you want to verify that.
Anyway, you should be able to solve this with the pkinit_eku_checking
client configuration option (it goes in the same section as
pkinit_kdc_hostname). There are three possible values for this
entry: kpKDC (the default), kpServerAuth, and none. So since kpKDC
doesn't work for you, I'd try kpServerAuth. "none" is always an
option, but is not recommended. With the PKI deployments I work
with, we have to use kpServerAuth (in theory we can get a certificate
with the correct EKU and the id-pkinit-san, but sadly there is a bug
in the generated encoding they produce so it doesn't work).
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
