Smart-card Not Found Connect Smart-card
Maranda
The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.
There are many useful pages and technical articles available online that include details on configurations and using generic smart cards. The information presented here addresses common questions and configurations specific to the U.S. federal government, PIV smart cards, and U.S. federal civilian agency certification authorities.
We want to add additional information for installing Online Certificate Status Protocol (OCSP) services, addressing common errors and troubleshooting, and configuring MacOSX and other operating systems.
Your workstations, servers, network domain controllers, and applications need to validate the revocation status of the PIV certificates and all intermediate certificate authority (CA) certificates. In addition, the certificate chain path building may retrieve and download the intermediate CA certificates.
The validation occurs in real time (with some caching) and requires ensuring network traffic is open and available to the destination web services, ports, and protocols. Many U.S. federal agencies implement a layered network security model with demilitarized zones (DMZs), proxies, and Trusted Internet Connections (TICs) to monitor, defend, and protect the networks, applications and users.
Restricted or denied access to Internet web services including the OCSP and CRL web services used in the certificate validations lead to common errors and issues. Collaborate with your Network Engineers to review the web services, IP addresses, ports and protocols, and verify access from all local and wide-area network segments.
For the typical network domain, certutil will be your best option to identify a number of possible root causes. There are many options available in the certutil utility tool, and two are covered here.
The text file output will include a full check against all options for CRLs, OCSP, intermediate certificates to verify a trust chain, and the root (COMMON). Review all items and ensure at least one successful verification message is included for each check. You may see errors for the LDAP verifications and these can be ignored if a CRL or OCSP check is successful.
When reviewing the verification messages, you should pay careful attention to the time. For example, if a CRL file is not downloaded in under 15 seconds, it is very likely that you will encounter network authentication errors and will need to perform some tuning.
There are dozens of OCSP and CRL URLs for all issued PIV credentials. If you have users with PIV credentials from other agencies or partners, identifying all the URLs to verify against your network configurations will be more complex.
The Federal Common Policy Certificate Authority G2 (COMMON) is the root certificate authority and has web services to publish both certificate chains (p7b files) and CRLs for all intermediate certificate authorities which the root signs.
To enable communications with these Federal Common Policy Certificate Authority services, including those currently operational and any expansion, you should verify outbound communications to the base domain of http.fpki.gov. For example, a successful connection to will download a copy of the Federal Common Policy CA certificate.
When your users are using certificates to authenticate to the network, the domain controllers are also authenticating as devices using certificates. Each works together to create secure connections. To learn more, search for online resources that discuss Public Key Cryptography for Initial Authentication (PKINIT) protocols.
It is not recommended to set up a local enterprise CA just to issue domain controller certificates without ensuring the proper management and security protections are enabled. Your Chief Information Security Officer (CISO) must have awareness and oversight established for the CA management.
You may find that you have many applications that rely on User Principal Name values. There is no need to remove existing or stop populating new User Principal Name values in your transition to altSecurityIdentities.
You need to enable User Name Hints for your network domain. This will modify the logon prompts for Windows workstations and servers joined to the network domain. Your users will be prompted to provide both the PIV credential PIN value and a User Name Hint value.
To transition from UPN mapping to altSecurityIdentities account linking, you will need to configure a registry setting on all domain controllers. Only configure the registry setting below once you have completed the above steps and are ready to disable UPN mapping.
Note: Organizations should carefully plan their transition to the altSecurityIdentities account linking approach and test interoperability before implementing changes in their production IT environments. The registry configuration below will cause smart card logon to fail for any user missing the altSecurityIdentities attribute.
The U.S. federal government publishes the United States Government Configuration Baseline (USGCB) for use by Executive Branch agencies to promote uniform configurations for commonly used operating systems. The USGCB configuration guidelines for specific operating systems include references to some configurations related to smart card (PIV) logon and should be referenced first.
The information on this page is intended to answer questions and identify the most commonly used configuration options. For a full reference of options for each operating system, please refer to configuration guides published by other sources online.
These options are controlled by group policy applied to either Machine or User objects in your network domain. Planning is required to move to full User Based Enforcement and agencies are often using a combination of both Machine and User enforcement in their deployments.
You can set the policy option on a single user by checking the Smart Card is required for interactive logon check box in the user account properties. You can also apply this setting using group policy objects. When the scforceoption setting is applied, the SMARTCARD_REQUIRED flag is added to the UserAccountControl (UAC) and the DONT_EXPIRE_PASSWORD attribute is set to true.
Group policies can be configured by domain administrators to align with local security policies for maximum lifetimes of kerberos user tickets. This may cause users to be prompted to re-authenticate with their PIV when prompted with one of the following options:
These prompts happen when the kerberos ticket lifetime expires and a new authentication event is required. User is set to user based enforcement, which requires a new PKINIT event with the domain controller.
You can tune the network domain settings to help you and your users have a better experience and reduce errors. This section highlights some of the common tuning configurations for network domain logon. There are additional tuning configurations and we encourage you to start with these first and contribute others.
When a user authenticates to a Windows system, their logon credentials are cached to enable logon in the event the domain controller is unavailable. The United States Government Configuration Baseline (USGCB) for Windows 7 specifies that Interactive logon: Number of previous logons to cache (in case domain controller is not available) should be set to 2.
The Number of previous logons to cache can be modified in local or group policy in the following locationComputer Configuration\Windows Settings\Security Settings\Local Policies\Security options
By default, Windows will time out when downloading Certificate Revocation List(s) after 15 seconds. A number of CRLs in the government environment are large, greater than 20 MB in size, which will lead to the timeout happening. This example scenario can be common and a source of frustration to you and your users:
The default timeout value can be modified using local or group policy by modifying the Default URL retrieval timeout value found in the Certificate Path Validation Settings, Network Retrieval tab, located in Computer Configuration\Windows Settings\Security Settings\Public Key Policies
By default, Microsoft Windows will retrieve and cache 50 OCSP Responses for any one issuing CA before switching to CRL mode. Depending on the size of the CRL, this may be a poor performance decision. For environments where workstations routinely interact with large CRLs, a large value may significantly reduce network bandwidth consumption. This value can be increased by setting the CryptnetCachedOcspSwitchToCrlCount DWORD value in the following registry key:HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\ChainEngine\Config
This page provides some tips for using a local certification authority (CA) to issue a domain controller certificate. This is for local Microsoft CAs. Other platforms may be used and have different procedures.
If successful, you will see a new domain controller certificate in the Certificate (Local Computer) -> Personal -> Certificates folder. At the Certificate Template tab, you will also see a certificate generated with the custom certificate template.
You need to know the type of authenticator to implement increasingly granular authorization policies and to grant or deny a user access to information available from applications and shared network resources.
Within the federal enterprise, Windows smart card logon with a PIV card (PIV logon) is one method to satisfy Federal Information Security Management Act (FISMA) and National Institute of Standards and Technology (NIST) Risk Management Framework security controls for authentication. A PIV card enables Authenticator Assurance Level 3, two-factor authentication to a Windows desktop. Under normal conditions, this system is simple and easy for an end user to use. However, if this logon mechanism breaks, it can be difficult to troubleshoot logon and authentication errors. This page includes common symptoms and suggested steps to diagnose and solve these issues.
4a15465005