Hello, I am trying to setup smart card authentication with certificates that were not issued from a PKI infrastructure in my environment. I have installed certificates on all domain controllers in the enterprise. These Domain certificates were issued from the SAME infrastructure that my smart card certificates are issued from. The environment is is currently disconnected, with no access to the PKI infrastructure. I am trying to configure revocation checking so that it can take place using CRLs that are periodically updated manually (for now). I know by default Windows 2008 R2 will try to validate using the URLs referenced in the certs, but that is not an option. The Goal: Smart card authentication in a Windows 2008 R2 environment that is "airgapped" from (has no network access to) the PKI infrastructure that issues the certificates for the users and the DCs by using manually updated CRLs Tools Available: Tumbleweed Desktop Validator Enterprise Standard Windows 2008 R2 What has been done so far (not a complete list): Imported the relevant root CAs into the NTAuth Store using Root level domain controller Installed certificates on each Domain Controller Rebooted each domain controller Installed Tumbleweed Enterprise product on each DC and configured it to use CRL, not OCSP for revocation checking. I am pointing it to a location where I manually place the CRL files. created and set the registry option for UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors to 1 The problems encountered: I am receiving the following errors or results on all DC's in the enterprise: Event ID 29 "The Key Distribution Center (KDC) cannot find a suitable certificate to use for smart card logons..." Event ID 19 "This event indicates an attempt was made to use smart card logon, but the KDC is unable to use the PKINIT protocol because it is missing a suitable certificate" running certutil -dcinfo verify produces "The revocation function was unable to check revocation because the revocation server was offline 0x80092013 (-2146885613) I am certain it is possible that I could have overlooked something, or am just ignorant of all that is required to make this work. I am looking for some guidance on how to get this working properly, or at least some information that will get me closer to the stated goal Thank You

It sounds like the DCs do not recognize your manually created DC certs as KDC certs Please check the requirements in http://support.microsoft.com/kb/291010 Brian

I have validated that the certificates installed meet the requriements set forth in the link that you provided. Just to clarify, the rest of the message from Event ID 29 reads ... "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" I dont want to go down the road of enrolling for another 18 certificates unless I can find a smoking gun that something isn't right with the ones I received. Based upon that link, the certs should be fine. Is there any insight into why the KDC service could not verify the certificate? I am thinking that the disconnected network is coming into play here. Again I am trying to get this working without the DCs having to communicate outside this network to validate the certs. Any ideas? Thanks

At other customers with disconnected networks, the trick is to create a "shadow" publication point. For example, if the CRLs are published to www.example.com/pki/caname.crl and www.example.com/pki/caname+.crl, we create a server to host the CRLs on the disconnected network using the external DNS name. The process is admin-heavy as you must manually copy the CRLs to the publication points each day/hour per the CRL publication interval. The same thing can be done with OCSP if needed. You sound like you attempted this, but it is not working. You should not receive any errors when running certutil -dcinfo (or certutil -verify -urlfetch DCCERT.crt against a DC certificate from a client system). What I would do is check proxy configuration (may be trying to use a proxy server since the DNS name is external to your org). You may have to add the DNS name as an exception in your proxy configuration rules. Brian