Domain is Windows 2008 R2, client is Win7. I have added tha CA root cert (and all intermediate certs) to the local computer store on both domain controllers and the client. I have added the root CA and all intermediate CAs to the NTAuth store. I have changed the UPN on the AD user to match what's provided on the card. I can view the cert on both DCs and the client, and it looks OK. When I try to login using the card, I get the following error: An untrusted certificate authority was detected while processing the smart card certificate used for authentication Thoughts are welcome.

Hi, Hope the following article can give you some hints: You may encounter several smart card failure problems after you raise the domain functional level to Windows Server 2008 R2 domain function level in a network environment Guidelines for enabling smart card logon with third-party certification authorities Requirements for Domain Controller Certificates from a Third-Party CA You cannot use a smart card certificate to log on to a domain from a Windows Vista-based or a Windows Server 2008-based client computer If you would like to obtain more information, in order to get the answer effectively, it is recommended to post a new question in Windows Server Forum. Regards, Sabrina Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I appreciate the tips, but these aren't the errors I am seeing. I didn't generate the cert on this card (the feds did), and I know it works on other domains. I'm not getting the 'No valid certificates found' on the workstation (I am intimately familiar with that error, however, for our homegrown certs) I am seeing untrusted certificate authority error on the Win7 desktop and getting EventID 4771 on the domain controller. I believe I understand the process for third-party certs, as I have another card that works (different issuer). I am fairly certain that the root CA is trusted by the domain controller and has been added to the NTAUTH store in AD. I'm trying to figure out how to troubleshoot this alleged 'untrusted' chain. Blake

Blake - can you confirm that the CA that issued the domain controller certificate is the same as the CA that issued the smart card certificate? If they're different, you'll need to make sure that both the client and the DC trust both of them. Let us know if that helps, and if not, we can look a little deeper into where that error is coming from.David Beach - Microsoft Online Community Support

David, Many thanks for your reply. They are most certainly not the same. The CA that issued the domain controller cert is one I stood up. (Enterprise CA) The CA that cut the smart card cert, I believe, is Entrust. It's a government agency card. I have a third party card (from a different CA) that DOES work (so I feel confident that the domain controller cert is trusted by the client). When I view the smart card cert (on the client and on the domain controller), it seems to 'check out'. (I don't get any red x saying there is a chain issue) Any assistance in troubleshooting this is much appreciated.

Ok great, thanks for the clarification. Since you're seeing an error on the DC, it's likely that trust validation is failing there, possibly because of a revocation check failure. Can you post the full text of the 4771 event for us? Another thing to do is to export the cert from the smart card (public key only) to a file and then run certutil -verify -urlfetch against it on both the client and the DC. Make sure you're not having trouble checking the CRL or chaining up to the roots. More info on certutil here, if you need it: http://technet.microsoft.com/en-us/library/ee624045(WS.10).aspx David Beach - Microsoft Online Community Support

During the testing I saw denied outbound LDAP requests (which I assumed to be CRL checks) - so I had our firewall people open those. I've run the certutil verification, but I couldn't make much sense of it. I'll return with those results, as well as the event ID.

This is sanitized Kerberos pre-authentication failed. Account Information: Security ID: AD\joeuser Account Name: joeuser Service Information: Service Name: krbtgt/AD.DOMAIN.ORG Network Information: Client Address: ::ffff:172.16.17.52 Client Port: 49189 Additional Information: Ticket Options: 0x40810010 Failure Code: 0x3e Pre-Authentication Type: 15 Certificate Information: Certificate Issuer Name: Entrust Managed Services SSP CA Certificate Serial Number: XXXXXXXXx Certificate Thumbprint: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options and failure codes are defined in RFC 4120. If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.

what should I look for in the certutil -verify output?

Hi Blake, We think from the output you posted that we may know what's happening. Does your card chain up to the Common Policy Root CA? If yes, on your domain controller, find the certificate for the CA in the trusted root store, look at the properties of it, and go to the details tab. You'll see a button at the bottom labeled "Edit Properties" If you click that button, there will be a list of Certificate Purposes - by default the Smart Card Logon purpose may be disabled. If it is, enable it, and then close all the dialog boxes and check to see if it works or not.David Beach - Microsoft Online Community Support

It does chain up to the Common Policy Root CA. I'm checking my DC now. I'm checking the Common Policy cert in the local computer cert store, correct?

That's correct. On the DC, it should be under Trusted Root Certificate Authorities in the Computer store.David Beach - Microsoft Online Community Support

I'll report back with results!

I'm not entirely sure what happened. I looked at that usage and it was NOT enabled. I then tested another card (same issuer, same cert chain) and it worked immediately. (I still haven't changed the cert usage on the domain controller) I then deleted the AD account mapped to my original test card, recreated - and it worked as well. I'm making a note of your suggestion, should it arise in the future. I'm not sure why it works now but not before. Many many thanks for your insight. Blake

Glad to hear you got it working! Hopefully it stays working for you.David Beach - Microsoft Online Community Support