After the domain controller’s authentication certificate is used to make a secure link from the workstation to the domain controller, the certificate data for the user’s smart card is sent to the domain controller for validation. The domain controller does the following to validate the credential:
-
-
- The domain controller looks up the user’s account in Active Directory (AD) using information found in the user’s PIV authentication certificate. This process is known as name mapping. More information about user name mapping can be found in the Account Linking Playbook -
- The certificate is sent to the Microsoft Crypto-API (CAPI) service running on the domain controller for path discovery and validation. CAPI performs basic certificate checks through Path Discovery and Validation (PDVal). -
- The domain controller checks its local copy of the Enterprise NTAUTH store for the presence of the issuing certification authority (CA) for the PIV authentication certificate. Steps for adding a certificate to this store can be found in the Trust Stores Playbook +
- The domain controller looks up the user’s account in Active Directory (AD) using information found in the user’s PIV authentication certificate. This process is known as name mapping. More information about user name mapping can be found in the Account Linking Playbook +
- The certificate is sent to the Microsoft Crypto-API (CAPI) service running on the domain controller for path discovery and validation. CAPI performs basic certificate checks through Path Discovery and Validation (PDVal). +
- The domain controller checks its local copy of the Enterprise NTAUTH store for the presence of the issuing certification authority (CA) for the PIV authentication certificate. Steps for adding a certificate to this store can be found in the Trust Stores Playbook
Note: Certificate validation of the PIV authentication certificate for smart card logon only occurs on the individual domain controller processing the logon request. The client computer does not check the validity of the logon certificate. Other applications outside of Windows logon may perform certificate validation locally, so it may still be a good idea to have a valid path installed on your organization’s client computers. if you have multiple logon servers in your environment, only the one responding to the individual logon request performs validation. Therefore, it is important to maintain a consistent configuration across your domain controllers.
Use the information below to troubleshoot additional symptoms encountered after the PIN is entered, but before logon occurs.
@@ -916,12 +916,12 @@ For our use, this complex process is simplified into the following workflows:Example 3: The revocation status is unreachable, or the revocation status signature cannot be validated due to an invalid trust path.
Note: The error status in Example 3 will occur for any certificate lower in the path than the above Examples for 1 and 2. For example, if a trusted root cannot be found at the top of the path, no valid revocation status will be found for any certificate issued below the trusted root, including the issuing CA certificate and the end user’s PIV authentication certificate. This situation occurs because the revocation data cannot have its signature verified for the same reasons that the certificate itself cannot.
-You can also use the PKI Interoperability Test Tool (PITT), listed on the Useful Tools page, to validate the certificate path on the logon server. The PITT Usage Guide contains procedures for using the tool.
+You can also use the PKI Interoperability Test Tool (PITT), listed on the Useful Tools page, to validate the certificate path on the logon server. The PITT Usage Guide contains procedures for using the tool.
Resolution
- On the domain controller, work through any path validation issues identified in the above steps and examples. Keep in mind that that path building comes before validation and that a path is built from the bottom up. In this instance, the PIV authentication certificate chains to a trust anchor, such as Federal Common Policy G2. Ensure that the correct trust anchor for your organization’s PIV credentials is installed on every domain controller. If you also trust certificates from other agencies and organizations, the appropriate roots and cross-certificates may need to be installed to complete the path.
- Find expired and revoked certificates that may be installed in your domain controller certificate store and delete them as appropriate. In a Windows environment, unexpected errors often result if you have duplicates of a certificate installed in a given store or have accidently installed an intermediate CA in the trusted root store or vice versa. -
- Lastly, you will need to allow outbound access over port TCP 80 from each domain controller to each of the CRL, OCSP, and AIA distribution points listed in the certificates in the path. For more information, see Path Discovery and Validation (PDVal). +
- Lastly, you will need to allow outbound access over port TCP 80 from each domain controller to each of the CRL, OCSP, and AIA distribution points listed in the certificates in the path. For more information, see Path Discovery and Validation (PDVal).
Possible Cause 2 - CA Not in the NTAuth Store
-
@@ -948,7 +948,7 @@ For our use, this complex process is simplified into the following workflows:
Possible Cause 2
The identifiers listed in the Smart Card Logon certificate on the card cannot be matched to an AD account.
Resolution 2
-Follow the suggestions in the Account Linking Playbook to ensure that the card identifier can be linked to the AD account. This may require User Principal Name (UPN) mapping, adding alternate security identifiers added to the AD record, or domain hinting.
+Follow the suggestions in the Account Linking Playbook to ensure that the card identifier can be linked to the AD account. This may require User Principal Name (UPN) mapping, adding alternate security identifiers added to the AD record, or domain hinting.
Back to Process Overview