• FW: kinit failing when AD user joining using smaercard PIN on ubunt

    From Ken Hornstein@21:1/5 to Vikram Yadav on Wed Mar 3 08:05:02 2021
    Copy: kerberos@mit.edu

    PFA the latest logs.

    I'm able to enter the PIN then this log is generated. Please let us
    know what is the next step?

    [...]
    kinit: KDC reply did not match expectations while getting initial credentials

    Huh, JUST when you think you've seen every Kerberos error, you get a new
    one.

    So, I am kinda surprised your KDC certificate doesn't contain even an id-kp-serverAuth EKU. I wonder who created the server certificate? Was
    this just a test realm that was deployed internally?

    So, I am wondering ... is your realm name blrdhcdev.com or BLRDHCDEV.COM?
    (Case matters). Because in the kinit command you use the lower-case form
    but some of the log messages that implies that it's the upper-case form.
    I suspect you're getting tripped up by the code in get_in_tkt.c:verify_as_reply() that compares various fields in the request against the reply, so if your request is using the lower-case realm but
    the reply is with an upper-case realm, that could cause this error. If
    you put a bunch of config file entries in your krb5.conf based on
    the lower-case realm, those should all be in upper case.

    (In general, Kerberos realms are upper-case. The only person I know who deployed a lower-case realm said that if he had to do it all over again,
    he wouldn't because too much code assumes an upper-case realm).

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vikram Yadav@21:1/5 to Vikram Yadav on Wed Mar 3 17:27:28 2021
    Copy: kerberos@mit.edu

    PFA the latest logs.

    I'm able to enter the PIN then this log is generated. Please let us
    know what is the next step?

    Regards,
    Vikram

    On Wed, 3 Mar 2021 at 16:20, Vikram Yadav <vikrampal@gmail.com> wrote:

    Hello Ken,

    Thanks for your kind response!

    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.

    What should we do now?

    Regards,
    Vikram

    -----Original Message-----
    From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
    Sent: Tuesday, March 2, 2021 7:59 PM
    To: Pal, Vikram
    Cc: kerberos@mit.edu; Agrawal, Rajeev; Shastry, Shashiraja;
    Rajagopalan, SrinivasaRagavan; Venkatesh, Ramanujam
    Subject: Re: kinit failing when AD user joining using smaercard PIN on
    ubuntu 20.04


    [EXTERNAL EMAIL]

    PFA the Kerberos logs got while running kinit command. Could you
    please help us understand as to where we ae going here & what should we
    do to make it work?

    Well, you COULD have included them as text rather than a picture :-)
    But, fine. I see you get a PIN prompt, but I'm not clear if you
    actually had the chance to enter in a PIN or not. Also, I see this:

    PKINIT no anchor CA in file /etc/ssl/ca-pem/root//blrdhcdev.cer

    And that file extension makes me think the certificate there is in DER format, not PEM. But I think your REAL problem is down below:

    PKINIT client config accepts KDC dNSName SAN BLRDHCDEV.COM PKINIT
    client found dNSName SAN in KDC cert: blrdhcdev-ad.blrdhcdev.com
    PKINIT client found no acceptable SAN in KDC cert

    You can read about the PKINIT client configuration here:

    https://web.mit.edu/kerberos/krb5-1.17/doc/admin/pkinit.html

    The key section is down where it says "Configuring the clients".
    It looks like you have

    pkinit_kdc_hostname = BLRDHCDEV.COM

    But it really should be

    pkinit_kdc_hostname = blrdhcdev-ad.blrdhcdev.com

    (and you need one of those for each of your AD server hostnames).

    This is the configuration that tells the client that it can trust the
    KDC certificate. If you don't have the KDC certificate with the
    special extensions that say, "This certificate is valid for your
    realm", then your client needs to be configured to say, "This set of certificates is valid for a KDC certificate". And you need to
    explicitly list every dNSName in your client. That's what pkinit_kdc_hostname does.

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vikram Yadav@21:1/5 to Vikram Yadav on Wed Mar 3 17:37:42 2021
    Copy: kerberos@mit.edu

    I updated pkinit_eku_checking = none & got this error. Please let me
    know what's going on and what's the remedy?

    Regards,
    Vikram

    On Wed, 3 Mar 2021 at 17:27, Vikram Yadav <vikrampal@gmail.com> wrote:

    PFA the latest logs.

    I'm able to enter the PIN then this log is generated. Please let us
    know what is the next step?

    Regards,
    Vikram

    On Wed, 3 Mar 2021 at 16:20, Vikram Yadav <vikrampal@gmail.com> wrote:

    Hello Ken,

    Thanks for your kind response!

    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.

    What should we do now?

    Regards,
    Vikram

    -----Original Message-----
    From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
    Sent: Tuesday, March 2, 2021 7:59 PM
    To: Pal, Vikram
    Cc: kerberos@mit.edu; Agrawal, Rajeev; Shastry, Shashiraja;
    Rajagopalan, SrinivasaRagavan; Venkatesh, Ramanujam
    Subject: Re: kinit failing when AD user joining using smaercard PIN on ubuntu 20.04


    [EXTERNAL EMAIL]

    PFA the Kerberos logs got while running kinit command. Could you
    please help us understand as to where we ae going here & what should we >do to make it work?

    Well, you COULD have included them as text rather than a picture :-)
    But, fine. I see you get a PIN prompt, but I'm not clear if you
    actually had the chance to enter in a PIN or not. Also, I see this:

    PKINIT no anchor CA in file /etc/ssl/ca-pem/root//blrdhcdev.cer

    And that file extension makes me think the certificate there is in DER format, not PEM. But I think your REAL problem is down below:

    PKINIT client config accepts KDC dNSName SAN BLRDHCDEV.COM PKINIT
    client found dNSName SAN in KDC cert: blrdhcdev-ad.blrdhcdev.com
    PKINIT client found no acceptable SAN in KDC cert

    You can read about the PKINIT client configuration here:

    https://web.mit.edu/kerberos/krb5-1.17/doc/admin/pkinit.html

    The key section is down where it says "Configuring the clients".
    It looks like you have

    pkinit_kdc_hostname = BLRDHCDEV.COM

    But it really should be

    pkinit_kdc_hostname = blrdhcdev-ad.blrdhcdev.com

    (and you need one of those for each of your AD server hostnames).

    This is the configuration that tells the client that it can trust the
    KDC certificate. If you don't have the KDC certificate with the
    special extensions that say, "This certificate is valid for your
    realm", then your client needs to be configured to say, "This set of certificates is valid for a KDC certificate". And you need to
    explicitly list every dNSName in your client. That's what pkinit_kdc_hostname does.

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vikram Yadav@21:1/5 to Ken Hornstein on Thu Mar 4 15:26:11 2021
    Copy: kerberos@mit.edu

    Hello Ken,

    kinit is successful now. Thank you so much for your kind help!

    Regards,
    Vikram

    On Wed, 3 Mar 2021 at 18:35, Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:

    PFA the latest logs.

    I'm able to enter the PIN then this log is generated. Please let us
    know what is the next step?

    [...]
    kinit: KDC reply did not match expectations while getting initial credentials

    Huh, JUST when you think you've seen every Kerberos error, you get a new
    one.

    So, I am kinda surprised your KDC certificate doesn't contain even an id-kp-serverAuth EKU. I wonder who created the server certificate? Was
    this just a test realm that was deployed internally?

    So, I am wondering ... is your realm name blrdhcdev.com or BLRDHCDEV.COM? (Case matters). Because in the kinit command you use the lower-case form
    but some of the log messages that implies that it's the upper-case form.
    I suspect you're getting tripped up by the code in get_in_tkt.c:verify_as_reply() that compares various fields in the request against the reply, so if your request is using the lower-case realm but
    the reply is with an upper-case realm, that could cause this error. If
    you put a bunch of config file entries in your krb5.conf based on
    the lower-case realm, those should all be in upper case.

    (In general, Kerberos realms are upper-case. The only person I know who deployed a lower-case realm said that if he had to do it all over again,
    he wouldn't because too much code assumes an upper-case realm).

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)