none
AD certificate name mapping authentication problem RRS feed

  • Question

  • Hi, I'm facing a problem with active directory authentication with a certificate that is mapped to multiple accounts.

    environment:

    2012 R2 DCs (single domain)

    smartcard name hint enabled

    Windows 10 Pro 1903


    What I've done:

    I generated a certificate for smartcard logon on a internal windows pki (without a UPN (User Principal Name) and loaded it onto a smartcard (following this guide: blogs.technet.microsoft.com/askds/2009/08/10/mapping-one-smartcard-certificate-to-multiple-accounts/ ). Then I mapped the certificate to multiple accounts in active directory (normal user account and a privileged admin account).

    Almost everything works fine. I can login with a single smartcard certificate to multiple accounts and RDP into other machines.

    The problem I'm facing:

    When I try to access a network share which I don't have permission for with my normal user account (e.g. administrative share \\machine\c$) I get a prompt to authenticate with my admin account. When I enter the smartcard pin and proper name hint and continue I get an error saying that the username is unknown. A packet capture with wireshark shows the error "KDC_ERR_C_PRINCIPAL_UNKNOWN" which means that the certificate I'm using doesn't have a UPN (User Principal Name) (according to blogs.technet.microsoft.com/askds/2012/07/27/kerberos-errors-in-network-captures/ ) which is true. But the first guide stated that I shouldn't include a UPN in the certificate.

    error in eventviewer -> SMBClient:

    Smb2DiagReasonISC.

    Error: The specified account doesn't exist.

    Securitystatus: 0xC0000064
    Username: @@BPJNllADRB3fzyEqvQyo-M4TX2AC
    Logon-ID: 0x1AD097
    Servername: \machine
    Prinzipalname: cifs/machine

    Logging directly into the privileged admin account I can access the administrative share just fine.


    Any help is appreciated.
    Thanks in advance




    • Edited by daBasti Wednesday, November 13, 2019 12:52 PM
    Wednesday, November 13, 2019 12:27 PM

Answers

  • Finally solved it.

    @Kiki Shi : I've tested this with a fresh install of Server 2019 and a completly new AD Domain + PKI and the same problem accurs.

    Solution:

    Include the UPN in the certificate. Make sure the UPN is the user that should be able to access a share like \\machine\c$. When your logged in as a different user that doesn't have permission to connect to that share and then try to connect to \\machine\c$ and then get an authentication prompt the user from the UPN is the only one that's able to connect. Even when you specify a different account in the name hint it will ignore it and use the useraccount that you specified as the UPN when you issued the certificate.

    Then disable the UPN mapping on all KDCs so that it ignores the UPN from the certificate ( https://support.microsoft.com/en-us/help/4043463/how-to-disable-the-subject-alternative-name-for-upn-mapping only on the KDCs, Client registry key isn't needed).

    This will allow you again to do a 1:n mapping instead of a 1:1.




    • Edited by daBasti Monday, November 18, 2019 7:06 PM
    • Marked as answer by daBasti Tuesday, November 19, 2019 8:06 PM
    Monday, November 18, 2019 6:54 PM

All replies

  • Hi

    If you're getting KDC_ERR_C_PRINCIPAL_UNKNOWN, that means the name "mysite.mydomain.com" is different from how the AD recognizes your machine so it's unable to provide a valid kerberos ticket.

    More details you could refer to the following link:

    https://stackoverflow.com/questions/7387156/unable-to-get-windows-authentication-to-work-through-local-iis

    Note: This is a third-party link and we do not have any guarantees on this website. This is just for your convenience. And Microsoft does not make any guarantees about the content.

    For further help, I suggest you submit a new case on Directory Services Forum directly as they will be more professional on your issue.

    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us.

    Thanks for your understanding and cooperating.

    Hope can help you. Have a nice day!

    Best Regards

    Kiki


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 14, 2019 9:15 AM
  • Hi,

    Was your issue solved?

    If the reply helped you, please remember to mark it as an answer.

    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,

    Kiki Shi


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, November 15, 2019 3:23 AM
  • Finally solved it.

    @Kiki Shi : I've tested this with a fresh install of Server 2019 and a completly new AD Domain + PKI and the same problem accurs.

    Solution:

    Include the UPN in the certificate. Make sure the UPN is the user that should be able to access a share like \\machine\c$. When your logged in as a different user that doesn't have permission to connect to that share and then try to connect to \\machine\c$ and then get an authentication prompt the user from the UPN is the only one that's able to connect. Even when you specify a different account in the name hint it will ignore it and use the useraccount that you specified as the UPN when you issued the certificate.

    Then disable the UPN mapping on all KDCs so that it ignores the UPN from the certificate ( https://support.microsoft.com/en-us/help/4043463/how-to-disable-the-subject-alternative-name-for-upn-mapping only on the KDCs, Client registry key isn't needed).

    This will allow you again to do a 1:n mapping instead of a 1:1.




    • Edited by daBasti Monday, November 18, 2019 7:06 PM
    • Marked as answer by daBasti Tuesday, November 19, 2019 8:06 PM
    Monday, November 18, 2019 6:54 PM
  • Hi,

    I am very glad to hear that this problem has been solved. Thank you for sharing. We are very grateful for your time and effort.

    Please mark a helpful reply as answer, this behavior can let other forum user get useful information.

    Thanks.

    Have a nice day!

    Best regards,

    Kiki


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Tuesday, November 19, 2019 1:23 AM