PIV Enablement Playbook

If your organization does not issue its own PIV card authentication certificates, skip this task.

This step may be out of scope if you have already established your PKI infrastructure.

A subordinate issuing certificate authority is required to issue certificates from the root CA to lower tier systems and applications. The subordinate issuing CA acts as a middle tier between the root CA and the end client, allowing the root CA to be offline from the network, preventing compromise and protecting the integrity of the certificates that it issues.

You can install the CA role on any Windows Server that is already a member of the domain, unlike your offline Root CA. Follow the Root CA configuration steps until you reach the screen which asks to select “Standalone CA” vs. “Enterprise CA”. Please refer to this Microsoft TechNet Article for Installing a Subordinate CA.

Below is a guided walkthrough of the steps contained in the Microsoft Article with a few more explanatory details. The following steps are specific for Windows Server 2008 R2.

1. Open Server Manager, click Add Roles, click Next, and click Active Directory Certificate Services. Click Next two times.
2. On the Select Role Services page, click Certification Authority, and then click Next.
3. On the Specify Setup Type page, click Standalone or Enterprise, and then click Next (In this instance, you will be selecting Enterprise CA, as this will be a Domain Joined Issuing CA for that particular Agency)
4. On the Specify CA Type page, click Subordinate CA, and then click Next (Again, this is an Issuing CA, which belongs to the Federal PKI Infrastructure).
5. On the Set Up Private Key page, click Create a new private key, and then click Next.
6. On the Configure Cryptography page, select a cryptographic service provider, key length, and hash algorithm. Click Next.
7. On the Request Certificate page, browse to locate the root CA, or if the root CA is not connected to the network, save the certificate request to a file so that it can be processed later. Click Next.
8. On the Configure CA Name page, create a unique name to identify the CA. Click Next.
9. On the Set Validity Period page, specify the number of years or months that the CA certificate will be valid. Click Next.
10. On the Configure Certificate Database page, accept the default locations unless you want to specify a custom location for the certificate database and certificate database log. Click Next.
11. On the Confirm Installation Options page, review all of the configuration settings that you have selected. If you want to accept all of these options, click Install and wait until the setup process has finished.

Following are the instructions to install a Subordinate CA for Windows Server 2012

1. For the subordinate CA, you will select Enterprise CA, since this Subordinate CA will now be part of a broader PKI infrastructure (you will note that the option for Enterprise CA is no longer greyed out, since you are installing this Role on a Domain Member Server, and a Root CA already exists).
2. On the next screen you will select “Subordinate CA”, and continue to the next screen where you will be asked to specify the Private Key. Select “Create a new private key” option and continue.
3. The next configurational step will be to define Cryptography, you will use the same settings that were defined during the planning phase, and during the Root CA configuration phase, i.e. 4096 bits (or more), and a hash algorithm of at least 256 (SHA256), for this example.
4. Since this issuing CA is a Domain Member, you will give it a name or common name, the Distinguished Name Suffix, i.e. DC=GSA, DC=GOV and proceed to the next page where you will be prompted to receive a certificate from your Root CA.
5. When requesting a certificate from the Parent CA, which in this case is the Offline Root CA, you will choose a location that is local to the subordinate CA (or a secure network location).
6. Similarly to the Root CA, you will specify a local Certificate Store or Database location, as well the Log file location.
7. Finally, after all parameters are entered, you can run the configuration wizard. This wizard will generate a certificate request file on the local subordinate CA. This file will be used to request a certificate from the Root CA, by copying this file locally to the Root CA.
8. This is done by opening the CA Management console on the Root CA, right-clicking the Server Name on the left side navigation pane, and selecting, All Tasks > Submit New Request
9. Once the request is submitted, you will see a pending request dialog in the Management Console. Right-Click the request select All Tasks > Issue
10. Once complete, using the left side navigation pane, highlight Issued Certificates (you should only see one, since you have only issued a single certificate to your subordinate CA). Right click the Certificate and select > Open > Navigate to the details tab and click “Copy to file”, once the export wizard is complete, select the file format you wish to use for your certificate export (in this example, we will use DER encoded binary X.509 .CER). Specify a location to store the CA Certificate, you can store it directly on the Subordinate CA or a secure Network location, and click Finish.

If your organization does not issue its own PIV card authentication certificates, skip this task.

This step may be out of scope if you have already established your PKI infrastructure.

The root CA certificate will need to be requested from the parent CA. This provides the subordinate CA with the certificate that identifies the location of the root CA and establishes trust between the root CA and lower tier subordinate CAs and systems.

1. On the subordinate CA’s certificate services management console, right click on your subordinate CA in the left pane navigation field, select All Tasks > Install CA Certificate and finally, start the Certificate Service on the subordinate CA.
2. In the context of Federal PKI, subordinate issuing CA’s per agency, will import the CA Certificate for its parent, or offline issuing CA.

If your organization does not issue its own PIV card authentication certificates, skip this task.

This step may be out of scope if you have already established your PKI infrastructure.

Before signing and validating any certificates, it is necessary to configure the AIA and CDP extensions. These extensions point to the location of the trusted authority needed to validate certificates and the location of certificate revocation statuses, respectively. All certificates must be validated prior to application consumption.

This task will configure Active Directory Certificate Services with the ability to make CRLs available to clients. It is necessary to copy the Root CA’s certificate file and the Root CA’s CRL file to your Domain Controller with the FSMO Role of Infrastructure Master. After doing this, run the following commands on your Domain Controller:

    certutil –dspublish –f fcpca.crl <CAName>

And for the Root Certificate:

    certutil –dspublish –f fcpca.crt

The Root CA is now configured, and the subordinate, or issuing CA must be configured.

The root certificate and intermediate CA certs are required by the domain controller to establish a chain of trust between the parent CA and the end users and applications. This allows the domain controller to issue trusted certificates to PIV cards within the directory and confirm the validity of smart card certificates during an access attempt.

Active Directory must be configured to trust a certification authority to authenticate users based on certificates from that CA. Both Smartcard workstations and domain controllers must be configured with correctly configured certificates.

This task will configure Active Directory to trust the Certification Authority chain that signed the users’ authentication certificates. To configure Active Directory with the signing CA Certificate chain:

1. On your Active Directory Domain Controller server, select Active Directory Users and Computers
2. In the Management Console, right click the Domain and click Properties
3. Once you’re on the Group Policy Tab, click Open to open the Group Policy Management Console plug-in
4. Right Click Default Domain Policy and click Edit
5. Expand the Computer Configuration section and open Windows Settings > Security Settings > Public Key
6. Right click Trusted Root Certification Authorities and select Import
7. Follow the prompts in the Wizard to import the Root Certificate for the CA and click OK

From here, follow these steps to import the intermediate certificate(s):

1. Right click Intermediate Certification Authorities and select Import
2. Follow the prompts in the Wizard to import the Intermediate Certificate(s) for the CA and click OK

By publishing the CA certificate to the enterprise NTAuth store, the system administrator indicates that the CA is trusted to issue certain certificates. This allows the correct certificates to be issued to smartcards and thus enables logon through PIV card authentication.

This task will configure Active Directory to trust the CA chain that signed the users’ authentication certificates. To configure Active Directory with the signing CA Certificate chain:

1. On the Active Directory Domain Controller, launch an elevated command prompt to use the certutil utility

2. To Publish the Certificate to the Enterprise NTAuth store type

   certutil –dpublish –f "path_to_root_CA_cert" NTAuthCA
   

3. The CA is now trusted to issue certificates of this type

This task describes 2 common configurations related to domain Group Policy Objects (GPO).

scforceoption directs client Windows computers to enforce PIV logon for users. It is important to understand the ramifications of executing this step.

When you select the Smart Card is required for interactive logon check box in the Active Directory (AD) user account properties, Windows automatically resets the user password to a random complex password. In addition, Windows adds the SMARTCARD_REQUIRED flag to the UserAccountControl user account attribute and sets the DONT_EXPIRE_PASSWORD flag on the user account. The latter ensures that the user’s password never expires after the Smart Card is required for interactive logon option is selected.

When a user logs on to Windows either locally or remotely using a Remote Desktop session, the Windows client automatically checks for the presence of the SMARTCARD_REQUIRED flag. If the Smart Card is required for interactive logon option is set for the user, Windows rejects the logon attempt if it’s not made with smart card credentials.

Again, upon activation of scforceoption, users will no longer know the password to their account and will be required to use their PIV for authentication. Care should be used if enabling this option.

To enable or disable either of these policies:

1. Open the Group Policy Management Console
2. In the GPMC console tree, double-click Group Policy Objects in the forest and domain containing the GPO that you want to edit.
3. Right-click the GPO, and then click Edit.
4. In the console tree, edit the settings as appropriate.