Smart Card Logon Testing is failing

[Guest mcos1979]

Hello, we are currently in the process of testing user log-ins via smart card authentication on a closed network and we have had no success logging on with our smart cards on test workstations. We've received the domain controller certificates from an external domain, along with two root CA certs and two intermediate certs. The workstations output an error of: "The system could not log you on. You cannot use a smart card to logon because smart card log on is not supported for your user account(Windows 7)" or "The system could not log you on. The server authenticating you reported and error (0xC00000BB). You can find further details in the event log. Please report this error the system administrator (Windows XP)". There are no useful errors to review from the workstation event logs.

 

 

On the domain controllers, the following errors appear in the System logs:

 

 

EVENT ID 19: Source: Kerberos-Key-Distribution-Center This event indicates an attempt was made to use smartcard logon, but the KDC is unable to use PKINIT protocol because it is missing a suitable certificate

 

 

EVENT ID 29: Source: Kerberos-Key-Distribution-Center 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.

 

 

These are the item i've checked/verified so far:

 

 

1) Opened up ther Certificates.mmc snap-in and verified (under the Computer account) the DC certificate is located in the "Personal" certificates, the Root CA certificates are located in the "Trusted Root Certification Authorities", and the intermediate/subordinate certs are located with the "Intermediate Certification Authorities" folders

 

 

2) Modified the Default Domain Policy and ensured the certificates were imported to their respective folders as well. Ran a gpupdate /force on my test workstation and verified the policy works and the certs were loaded.

 

 

3) Ran certutil -viewstore -enterprise NTAuth and verified the certificates were published.

 

 

4) Copied the DC cert to my workstation and ran from command prompt the following command: certutil -verify -URLFetch DC.cer

 

The common results were:

 

Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)

 

Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

 

Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

 

Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x10000000)

 

-----------------------------------Certificate AIA---------------------------------------

 

319.1654.0: 0x800072efd (WIN32: 12029): http://URL

 

Failed "AIA" Time: 0

 

Error Retrieving URL: Error 0.80072efd (WIN32: 12029)

 

URL

 

-----------------------------------Certificate CDP---------------------------------------

 

Same message as above for AIA

 

 

ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)

 

CertUtil:: The revocation function was unable to check revocation because the revocation server was offline

 

 

5) Copied my user certificate to the DC and again ran the following command against it: certutil -verify -URLFetch usercert.cer

 

 

 

6) From my regular user account, I am able to verify that the CDP URLs are correct and can download the CRLs.

 

 

 

I hope I provided enough detail. My colleagues and I are stumped as to what is preventing the revocation checks and going out to the CDP URLs which are valid, ultimately preventing us from logging on with our smart cards. Has anyone ever ran into this issue? Your help is appreciated in advance.

 

Continue reading...