How to use FICAM
Dec 2022 - Update to Microsoft Network Authentication Issue
The Microsoft KB mentioned above is updated. Note that the "disabled" mode retirement is still targeted at 2/14/23. CISA encourages any agency still reliant on "disabled" mode to move to "compatibility mode" by following the CISA Guidance as soon as possible while a timeline and plans around long term resolution of this issue is finalized with Microsoft. Additional technical guidance can be requested through cyberlaison at CISA dot DHS dot gov.
May 2022 - Known PIV Network Authentication Issue
Some PIV-based authentication to Microsoft Domain Controllers are impacted by May 2022 Windows server patches. If you encounter these PIV network logon issues, please review the CISA Guidance which is supported by the following KB5014754—Certificate-based authentication changes on Windows domain controllers page. Additional technical guidance can be requested through cyberlaison at CISA dot DHS dot gov.
These Network Authentication guides will help you configure your Windows network domain for smart card logon using PIV credentials.
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.
Teamwork
Work with your Network Engineers, Domain Admins, Account Management, and Information Security colleagues to review the information, perform the configurations, and troubleshoot any issues.
Pre-Launch Checklist
Check the following items before reviewing these network guides and lessons learned:
- Users have PIV credentials and PIV card readers.
- You are using Microsoft Active Directory to manage your Windows network.
- Domain Controllers are Microsoft 2012 or newer.
- User workstations are joined to your network and are Windows 8 or Windows 10-based.
Configuration Checklist
There are five configuration categories to review with your colleagues. All five include steps that must be completed; it’s best to review and complete the configuration categories in this order:
- Network Ports and Protocols
- Domain Controllers
- Trust Stores
- Account Linking: Associating PIV credentials with User Accounts
- Group Policies and Enforcement
There are five additional guides:
- Network Tuning
- Local Certification Authority
- Authentication Assurance
- PIV Authentication on MacOS
- Troubleshooting PIV Logon
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. Submit an Issue to identify information that would be helpful to you, or consider contributing a page to these guides with your lessons learned.
Ports and Protocols
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.
Verifying and Troubleshooting
Non-accessible endpoints for the web services due to firewalls blocking access is a very common root cause for errors. If you encounter user errors including “Cannot validate” and similar domain controller errors, your first troubleshooting step should be to verify your network and access.
nslookup and certutil are your friendly tools
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.
It is simple to begin troubleshooting if the web services endpoints are accessible or blocked by firewall rules. You have the basic four utility tools for troubleshooting:
- certutil (Microsoft)
- openssl
- nslookup
- tracert
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.
Export your public key and certificate for PIV Authentication to a .cer file (mypiv_auth.cer), and run the following command in a command line from workstation(s) and domain controller(s):
certutil -verify -urlfetch mypiv_auth.cer >>verify_piv.txt
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.
Time is important
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 is also a graphical user interface to help perform these verification checks.
certutil -v -url mypiv_auth.cer
The graphical user interface allows you to check OCSP, CRL, and AIA (intermediate certificate retrievals).
Can federally operated certificate revocation services (CRL, OCSP) operate on port 80?
Yes. This very narrow class of services, that provide CRL and OCSP information for the purposes of verifying the revocation status of certificates used to make other HTTPS connections, should abide by best practices in the field and their respective specifications. For CRLs, follow RFC 5280 which states CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. For OCSP, follow RFC 6960 which states a CA may use port 443 for OCSP where privacy is a requirement. Agencies are encouraged to operate OCSP and CRL services via hostnames specifically reserved for those services, so that other related information and functionality can be served securely and privately. For more information see the Federal CIO Council HTTPS-Only Standard .
Web Services for Validating PIV Certificates
Revocation status is validated using using either Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs). To meet your initial network requirements, you should ensure the OCSP and CRL URLs included in your agency users’ PIV Credential Certificates are accessible from all workstations and domain controllers.
Type | Certificate Extension | Protocol (Port) | Considerations |
---|---|---|---|
OCSP | Authority Information Access | HTTP (80) | All PIV certificates have OCSP references and OCSP URLs which are Internet accessible and provided by the issuing CA. Intermediate CAs are not required to have OCSP available for the intermediate certificates. |
CRL | CRL Distribution Point (CDP) | HTTP (80) | All PIV certificates have CRL capabilities provided by the issuing CA. All intermediate CA certificates have CRL capabilities. CRL files have an expiration time that varies between 6 to 18 hours. CRL file sizes range from a few kilobytes to more than 30 megabytes (MB). |
Lightweight Directory Application Protocol (LDAP) for retrieving information is not preferred and has been increasingly deprecated; therefore, LDAP is not included.
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.
Web Services for the Federal Public Key Infrastructure
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 https://http.fpki.gov/fcpca/fcpca.crt will download a copy of the Federal Common Policy CA certificate.
You should consider allowing two protocols (ports): HTTP (80) and DNS (53). Although the web services for publishing CRLs are not currently served over HTTPS (443), you may want to allow HTTPS (443) to future proof for any expansion.