Troubleshooting PIV Logon

PIV logon begins at the client workstation. First, the system discovers smart card reader devices that are built into or attached to the workstation. Next, acceptable smart card logon certificates from any connected cards are provided to the Windows logon screen. In general, PIV cards are engineered to have one authenticate certificate marked eligible for smart card logon. However, in some instances, more than one certificate may have been inadvertently made eligible, meaning the user may first be asked to select the correct certificate for smart card logon. Conversely, the user may have a Facility Access Card (FAC) that omits access to any workstation. For more details on what is in use at your organization, speak with your agency’s credential issuer or Identity, Credential, and Access Management (ICAM) office.

Back to Process Overview

When the logon screen appears, if the system has detected a smart card reader and an attached (inserted) smart card with suitable certificates, the smart card logon option is displayed and the user is prompted to enter a PIN. Use the information below to troubleshoot symptoms encountered with card selection before PIN entry.

---

Symptom

Smart card icon is not displayed; user is not prompted for PIN.

---

Possible Cause 1 - Reader or Card Not Detected

Windows does not detect either the reader or the card due to a software or hardware issue with the card reader.

Diagnosis

1. Ask the user to make sure that the PIV card is fully inserted in the reader.
2. If the smart card reader is an external USB device, ask the user to remove the device and try inserting it into a different USB port.
3. Ask the user to try rebooting their workstation.
4. Ask the user to try using their PIV with their PIN elsewhere.
5. If the issue persists through reboot, and the PIV with PIN works elsewhere, the smart card reader may need to be replaced or the workstation may need to be serviced.

Resolution

Replace the smart card reader if it is an external device. Otherwise, schedule workstation repair.

---

Possible Cause 2 - Card Damaged

The PIV is damaged.

Diagnosis

If faulty workstation hardware or software is ruled out, and the card does not work on other readers, the PIV may need to be replaced.

To confirm that the card is functional, you can use the Certutil Tool, listed on the Useful Tools page, on a known working Windows workstation.

On the client:

1. Log in to Windows using a password.
2. Open the Start Menu, located in the bottom left corner of the screen.
3. Type cmd.
4. Click Command Prompt, shown under Best Match.

5. In the command prompt, type certutil -scinfo and press Enter.

6. A functioning card will return information on the card type and reader, begin polling for keys and validating certificates, and prompt for PIN entry. If this is the case with the card you are testing, click Cancel and close out of the command prompt.

7. If the card is malfunctioning, certutil will recognize that a reader is connected and a card is present but will display an error and will not prompt for PIN entry.

Resolution

Replace the PIV card if necessary.

Back to Process Overview

After the user enters their PIN, Windows tries to unlock the card using the PIN entered. After the card has been unlocked, the workstation packages the user’s PIV authentication certificate and sends it to the logon server, also known as a domain controller. The workstation must be able to trust the domain controller so that the workstation can securely connect to it. Use the information below to troubleshoot symptoms encountered after the PIN is entered but before logon occurs.

---

Symptom

After PIN entry, the following error is displayed on the logon screen:
Signing in with a smart card isn’t supported for your account. For more information, contact your administrator.

---

Possible Cause - Domain Controller Certificate

A suitable domain controller authentication certificate is not installed on the domain controller.

Diagnosis

On the client:

1. Log in to Windows using a password.
2. Open the Start Menu, located in the bottom left corner of the screen.
3. Type event viewer.
4. Click Event Viewer, shown under Best Match.

5. On the left side of the Event View, expand Applications and Services Logs, Microsoft, Windows, and Security-Kerberos on the tree.

6. Click Operational.
7. On the right side of the window, under Actions, click Enable Log (skip this step if the option reads ”Disable Log”; the log is already enabled).

8. Log out of Windows.
9. Try having the user log in to their workstation again using their PIV.
10. Log in to Windows using a password.
11. Repeat Steps 2 through 6 to return to the Security-Kerberos log in Event Viewer.
12. Click in the center of the window where ”Error” is shown. The following log will appear.

Resolution

On the domain controller:

1. Log in as a Domain Administrator.
2. Open the Start Menu.
3. Type mmc.exe.
4. Click MMC, shown under Best Match.

5. If prompted by a User Account Control pop-up, click Yes.

6. Click the MMC window and press and hold Ctrl. Then press M and release both keys.
7. In the Add or Remove Snap-ins window, click the following:
1. From the Available Snap-ins on the left, click Certificates.
2. In the center of the window, click the Add button.
3. In the Certificates snap-in window, click Computer account. Then click Next.

8. In the Select Computer window, click Finish.

9. In the Add or Remove Snap-ins window, click OK.
10. On the left side of the MMC window, click the > symbol to expand these items on the tree:
1. Certificates (Local Computer)
2. Personal

11. Under Personal, right-click Certificates.

12. Click All Tasks.
13. Click Request New Certificate.
14. In the Certificate Enrollment window, click Next.
15. Click Next.
16. Click the box next to the Domain Controller Authentication template. If you do not see this, ask your CA Administrator to publish this template.

17. Click Enroll.
18. Click Finish.

Back to Process Overview

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:

1. 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
2. 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).
3. 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.

---

Symptom

After PIN entry, one of the following errors displays on the logon screen:

1. An untrusted certification authority was detected while processing the smart card certificate used for authentication.

2. The smart card used for authentication has been revoked.

---

Possible Cause 1 - Certificate Fails Path Discovery and Validation

The user’s PIV authentication certificate fails path discovery and validation on the domain controller.

Diagnosis

On the client:

1. Log in to Windows using a password.
2. Open the Start Menu, located in the bottom left corner of the screen.
3. Type cmd.
4. Click Command Prompt, shown under Best Match.

5. In the command prompt, type echo %logonserver% and press Enter.

6. The current domain controller being used for Windows logon is displayed. This is the best domain controller to check first for troubleshooting invalid smart card logon events.

On the domain controller indicated above:

1. Log in as a Domain Administrator.
2. Open the Start Menu.
3. Type mmc.exe.
4. Log in to Windows using a password.
5. Open the Start Menu, located in the bottom left corner of the screen.
6. Type event viewer.
7. Click Event Viewer, shown under Best Match.

8. On the left side of the Event View, click the > symbol to expand each of these items on the tree:
1. Applications and Services Logs
2. Microsoft
3. Windows
4. CAPI2
9. Click Operational.
10. On the right side of the window, under Actions, click Enable Log (skip this step if the option reads ”Disable Log”; the log is already enabled).

11. Log out of Windows on the client workstation.
12. Have the user try to log in using their PIV, taking note of the time. The error should be shown on the logon screen.
13. On the domain controller, still in Event Viewer, on the right pane, click Refresh.
14. New log events will be shown. Look for the events with an “Error” status and the task category “Build Chain.”
15. Click the Details tab. In the UserData section, look for the user’s name in the Certificate [subjectName] field. If you do not see the user’s name, continue scrolling through the list of events to find the next event with an “Error” status and the task category “Build Chain.” Using results filtering may help to narrow this list down.

16. Once you find the event, scroll down through the details. You will see sections that say “-ChainElement.” These indicate each of the certificates in the path that was built. Within each chain element, look again for the ”- Certificate [ subjectName ],” indicating which certificate is being checked, and below it, a ”- TrustStatus” with an ”- Error Status” which will give more details about the failing validation.

Example 1: A certificate in the path is revoked.

Example 2: The path does not build to a trust anchor

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.

Resolution

1. 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.
2. 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.
3. 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

1. Follow Steps 1 through 15 for diagnosing Possible Cause 1.
2. Confirm that there is no error logged for the task category ”Build Chain” with matching certificate subjectName for the user.
3. Look for an error logged for task category ”Verify Chain Policy” with matching certificate subjectName for the user.
4. Confirm that the result logged is ”A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider.”

Resolution

Follow the steps in the Trust Stores Playbook to add the appropriate issuing CA for the PIV card to the Enterprise NTAuth trust store.

---

Symptom

During smart card logon attempt, the following error is displayed on the logon screen:
The system could not log you on. Your credentials could not be verified.

---

Possible Cause 1

The incorrect certificate was selected for smart card logon.

Resolution 1

1. In the logon screen, select a different certificate from the sign-in options. Note: Logon certificates generally display an account name in the form of an email address or user principal name.
2. Try entering the PIN again.

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.

Back to Process Overview

Once name mapping and PIV validation are complete, the domain controller sends a logon package to the client computer with the user’s domain permissions and a token that allows desktop logon for that user. If the user is permitted to log in to the computer, they will now be logged into their Windows desktop.

The first logon must always occur while the system has a network connection to the domain controller, whether it is directly attached to the organization’s network or via a VPN. After the first logon, if the Group Policy setting pictured below is set to a value greater than 0, the user’s logon token will be permanently cached by their workstation as long as the number of subsequent users to log in does not exceed this number.

If a future logon is attempted while the user’s workstation is disconnected from the organization’s network, and the logon token is cached, the workstation will only authenticate the PIV authentication certificate via PIN and, upon successful entry, will log the user into their desktop using their cached token and permissions. If the value is set to 0, caching does not occur and logon will only occur when the workstation is connected to the network and can communicate with a domain controller.

Back to Process Overview