We have a 3rd party CA that have issued the domain controller certificates used for smart card logon. Windows 2008 R2 DC. Smart card logon does not work and DC logs the following errors in system event log: Event ID 16944, Information: The certificate that is used for authentication does not have an issuance policy descriptor corresponding to OID xyz in the Active Directory database. This certificate will not be associated with a corresponding security identifier (SID), and the user may be denied access to some resources if you have resources whose access is restricted based on this issuance policy. The error is 3221226021. Event ID 19, Error: This event indicates an attempt was made to use smartcard logon, but the KDC is unable to use the PKINIT protocol because it is missing a suitable certificate. Event ID 29, Warning: The Key Distribution Center (KDC) cannot find a suitable certificate to use for smart card logons, or the KDC certificate could not be verified. Smart card logon may not function correctly if this problem is not resolved. To correct this problem, either verify the existing KDC certificate using certutil.exe or enroll for a new KDC certificate. Event ID 29 tells pretty straight on that it cant use the domain controller cert properly. Certutil -DCinfo verify results in: The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614) ------------------------------------ Revocation check skipped -- no revocation information available. There is only one CDP location in the DC cert, when doing a copy/paste into Internet Explorer the CRL can be downloaded and has a valid date. We have followed these guides.. Guidelines for enabling smart card logon with third-party certification authorities http://support.microsoft.com/kb/281245 Requirements for Domain Controller Certificates from a Third-Party CA http://support.microsoft.com/kb/291010 Suggestions are most welcome. Best regards, Danielwww.twitter.com/danielullmark

You need to make sure the CRL is reachable by the DC computer account! Are you using any proxies when downloading the CRL as a user? You can skip the other errors until the revocation issue has been resolved /Hasain

Thanks, we´re investegating the CRL issue.www.twitter.com/danielullmark

Hi, The problem seems to be related to the intermediate CA that has issued the DC certificates. intermediate CA is missing a CDP location with the CRL download location. The use of registry key "UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors" is a way to enable functional smart card logon.www.twitter.com/danielullmark

Hello, If you use third party certs for smart card logon does it mandatory to use DC's certs also from the same third party CA? Or it could be also from internal CA for example? Regards, Gediminas

The DC cert can be issued by any CA but make sure that it is trusted in the NTAuth store in AD. /Hasain

Thanks a lot, and user cert (apart from beeing trusted in domain) must have EKU Smart Card Logon (1.3.6.1.4.1.311.20.2.2) and must have exact UPN, but I don't understand this: You must correct the UPN in the smartcard user’s Active Directory user account or re-issue the smartcard certificate so that the UPN value in the SubjAltName field the matches the UPN in smartcard users’ Active Directory user account. We recommend that the smart card UPN match the userPrincipalName user account attribute for third-party CAs. However, if the UPN in the certificate is the “implict UPN” of the account (format samAccountName@domain_FQDN), the UPN does not have to match the userPrincipalName property explicitly. Regards, Gediminas

A UPN can be implicitly or explicitly defined. An implicit UPN is of the form UserName@DNSDomainName.com. An implicit UPN is always associated with the user's account, even if an explicit UPN is not defined. An explicit UPN is of the form Name@Suffix, where both the name and suffix strings are explicitly defined by the administrator. In other words you always have an implicit UPN additionally, you can have other explicit UPN defined for the same account. The UPN in the user certificate should match any of the user UPNs as defined above. /Hasain

Thank You Hasain, now it's clear. Regards, Gediminas,

Note that the 16944 event is informative only and is referring to an external issuance policy OID that is present on your smartcard certs but not in AD. As the event indicates, you would need further configuration steps to be able to use that OID for things like Authentication Mechanism Assurance. It does not however indicate a problem with the smartcard nor is it related to failures to log on with the smartcard referenced in the event. See http://blogs.technet.com/b/instan/archive/2010/01/15/enforce-smartcard-on-access-check-functionality-in-windows-2008-r2.aspx and Step 2: Link Certificate Policies to Groups on http://technet.microsoft.com/en-us/library/dd378897(WS.10).aspx#BKMK_Step2.