Skip to content
This repository has been archived by the owner on Apr 29, 2021. It is now read-only.

Commit

Permalink
staging all draft updates for cleaning and additions
Browse files Browse the repository at this point in the history 
network config category pages are still in progress
  • Loading branch information
lachellel committed Apr 3, 2016
1 parent 02585a5 commit 44de292
Show file tree
Hide file tree
Showing 26 changed files with 297 additions and 244 deletions.
4 changes: 4 additions & 0 deletions _config.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,10 @@ navigation:
url: identifiers
internal: true
coll: false
- text: Certificate Trust for a PIV Credential
url: pivcertchains
internal: true
coll: false
- text: Network Authentication
url: networkconfig/index/
internal: true
Expand Down
70 changes: 12 additions & 58 deletions _includes/network_index.md
View file
Original file line number Diff line number Diff line change
@@ -1,68 +1,22 @@
<div style="float:right; padding:10px; margin-right:20px; border-radius:10px; width:180px; height:40px; box-shadow:3px 3px 5px 0px; text-align:center; background-color:#CCC; color:#666666">
<div style="color:#000000">
<em>Difficulty: Moderate</em>
<em>Moderate</em>
</div>
</div>

## Introduction to Network Authentication Guides
## Introduction to Network Authentication Guide

This section is for configuring your Windows based computer network to accept and potentially require PIV for authentication.
The Network Authentication guides are for configuring your Windows _network domain_ for smartcard logon using PIV credentials. There are many useful pages and technical articles available online which include details on configurations and using generic smartcards. The information presented here is for common questions and configurations **specific** to the US Federal Government, **PIV** smartcards, and US Federal civilian agency certificate authorities.

There are many useful articles available online for you to review and use. These articles outline in detail the point and click options for configurations and using generic smartcards.
1. [Checking Ports and Protocols](../networkconfig/ports/)
2. [Domain Controller certificates](../networkconfig/domaincontrollers/)
3. [Addition of US Federal Certificate chains to the Trusted Root Certificate Authorities](../networkconfig/trustedroots/)
4. [Associating PIV credentials to the network domain user accounts](../networkconfig/accounts/)
5. [Configuring group policies for PIV (smartcard) logon](../networkconfig/grouppolicies/)

The information presented in this section and pages is to address some of your common questions and configurations **specific** to the US Federal Government, **PIV** smartcards, and US Federal civilian agency certificate authorities.

### Assumptions
#### Assumptions
* Users have PIV cards and PIV card readers
* User workstations have the drivers to read the PIV cards
* You're using Microsoft Active Directory to manage your Windows network
* Domain Controllers are Microsoft 2008 R2 or more recent versions
* User workstations joined to the network are Windows 7 or above
* There are options for workstations that are Mac OS based and joined to a Windows network - to be covered in a separate guide


### Before You Get Started
One of the most common questions is "What are all the certificates and what do I do with them?"

Explaining public key infrastructures and *the* Federal Public Key Infrastructure is an advanced topic and will be covered in additional guides. For your needs, there are two basic principles to understand:

1. Trust
2. Certificate *chains*

In the Federal Agencies, certificates may be issued to People (YOU), or Devices (SSL, Domain Controllers, Mobile Devices, etc).

Your PIV credential contain certificates and private key pairs - that are issued to YOU as a person, and to the CARD as a Device that you have in your possession.

To Trust YOU and your certificates, the workstations and network need to be configured for this trust. Certificate chains are one of the necessary methods to configure this trust.

Certificate chains can be complex to explain, so let's use a parable:

Download the Federal Common Policy Certificate Authority (COMMON) trusted _root_ certificate

* [COMMON can be downloaded here](http://http.fpki.gov/fcpca/fcpca.crt)
* cn=Federal Common Policy CA, ou=FPKI, o=U.S. Government, c=US
* 90 5f 94 2f d9 f2 8f 67 9b 37 81 80 fd 4f 84 63 47 f6 45 c1

Download the Intermediate Certificate Authority certificates

* [Intermediate Certificate Authority certificates] (http://http.fpki.gov/fcpca/caCertsIssuedByfcpca.p7c)
* The file type (p7c) can be
*
*

Identify and download any additional Intermediate Certificate Authority certificates

* You can generally ask your agency's information security team for help on the additional
* You can also look at your PIV card and certificates

Are you ready to get started?

#### Outline of Steps
1. [Checking the network for Ports and Protocols](#checking-the-network-for-ports-and-protocols)
2. Configuration considerations for Domain Controller certificates
2. [Addition of US Federal Certificate chains to the Trusted Root Certificate Authorities](#addition-of-us-federal-certificate-chains-to-the-trusted-root-certificate-authorities)
3. Publishing the US Federal Certificate chains to the NT Auth Store
4. [Associating PIV Credentials to the Active Directory User Accounts using altSecurityIdentities](#associating-piv-credentials-to-the-active-directory-user-accounts-using-altSecurityIdentities)
5. Configuring group policies for PIV (smartcard) logon

To help contribute to this effort, please follow 'Submit Issues Here' link at the top right to access the GitHub page for this site and provide any feedback.
* Domain Controllers are Microsoft 2008 R2 or 2012
* User workstations joined to the network are Windows 7, Windows 8 or Windows 10
* There are options for workstations that are Mac OS based and joined to a Windows network - to be covered in updated to this guide
25 changes: 12 additions & 13 deletions _networkconfig/1_portsprotocols.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,29 +6,28 @@ permalink: networkconfig/ports/
---
<div style="float:right; padding:10px; margin-right:20px; border-radius:10px; width:180px; height:40px; box-shadow:3px 3px 5px 0px; text-align:center; background-color:#CCC; color:#666666">
<div style="color:#000000">
<em>Difficulty: Moderate</em>
<em>Intermediate</em>
</div>
</div>

You need to be able to validate your PIV credential. The primary question answered during validation is: _Are you and your credential (PIV certificate) still trusted?_

#### Outline of Steps
1. [Checking the network for Ports and Protocols](#checking-the-network-for-ports-and-protocols)
2. Configuration considerations for Domain Controller certificates
2. [Addition of US Federal Certificate chains to the Trusted Root Certificate Authorities](#addition-of-us-federal-certificate-chains-to-the-trusted-root-certificate-authorities)
3. Publishing the US Federal Certificate chains to the NT Auth Store
4. [Associating PIV Credentials to the Active Directory User Accounts using altSecurityIdentities](#associating-piv-credentials-to-the-active-directory-user-accounts-using-altSecurityIdentities)
5. Configuring group policies for PIV (smartcard) logon
Why would a PIV credential not be _trusted_ anymore?

#### Checking the network for Ports and Protocols
Your workstations, servers and browsers may also need to retrieve and validate the certificate chains we talked about [here](#before-you-get-started).

The primary question answered during validation is: _Are you and the chain still trusted?_ You need to be able to validate the certificates during use. Your workstations, servers and browsers may also need to retrieve the certificate chains we talked about [here](#before-you-get-started).
This validation depends on ensuring the network traffic is open for the ports and protocols.

> Validation is performed using a variety of algorithms on different operating systems and with different cryptographic libraries. This section focuses on the _basics_ for common agency network configurations. In addition, the LDAP protocol for retrieving revocation information is not preferred and is being increasingly deprecated; therefore LDAP is not included in this guide.
{:class="alert"}
> Validation is performed using a variety of algorithms on different operating systems and with different cryptographic libraries. This section focuses on the _basics_ for common agency network configurations. In addition, the LDAP protocol for retrieving revocation information is not preferred and is being increasingly deprecated; therefore LDAP is not included in this guide.
#### Checking the Network for Ports and Protocols

Validation occurs using one of two mechanisms, over the HTTP protocol:

* On-line Certificate Status Protocol (OCSP): HTTP / Port 80
* Certificate Revocation Lists (CRLs): HTTP / Port 80
* Certificate Revocation Lists (CRLs): HTTP / Port 80


#### Simple Checks for Ports and Protocols


55 changes: 33 additions & 22 deletions _networkconfig/2_domaincontrollers.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,39 +10,50 @@ permalink: networkconfig/domaincontrollers/
</div>
</div>

### Domain Controller certificates
### Why Domain Controller Certificates?
To use smartcards and / or PIV credentials for network authentication, all the Domain Controllers need to have Domain Controller Authentication certificates.

> Just like your users are using certificates, the domain controllers are also authenticating as _devices_ using certificates. The users are authenticated and the domain controllers are authenticated, and each works together in the challenge response to create secure connections. It's required for the protocols, and if you want to learn more - search for information on _PKINIT_ protocols.
Include:
Getting the GUID commands
certutil / command to query domain controllers for certs and status
extensions for domain controller certs
where to get domain controller certs and options
### What do the Domain Controller Certificates need to include?
The certificate for each domain controller must meet the following specific format requirements:

1. The certificate **Key Usage** extension must contain:

Work with the Federal Public Key Infrastructure management team to request a domain controller certificate for your domain controller(s). Each domain controller that is going to authenticate smartcard users must have a domain controller certificate.
Digital Signature, Key Encipherment

The certificate for each domain controller must meet the following specific format requirements:
1. The certificate **Enhanced Key Usage** extension must contain:

* The certificate must have a CRL distribution-point extension that points to a valid certificate revocation list (CRL).
* Optionally, the certificate Subject section should contain the directory path of the server object (the distinguished name), for example:
CN=controller1.agency.gov OU=Domain Controllers DC=agency DC=gov
* The certificate Key Usage section must contain:
Digital Signature, Key Encipherment
Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)

* Optionally, the certificate Basic Constraints section should contain:
1. The certificate **Subject Alternative Name** extension must contain the Domain Name System (DNS) qualifier and name. This must be the fully qualified domain controller name. For example:

[Subject Type=End Entity, Path Length Constraint=None]
DNS Name=controller1.intranet.agency.gov

* The certificate Enhanced Key Usage section must contain:
1. The certificate **Subject Alternative Name** must also contain the global unique identifier (GUID) of the domain controller object in the domain.

* To determine the Domain Controller GUID, start Ldp.exe and locate the domain-naming context. Double-click the name of the domain controller that you want to view. The list of attributes for that object contains "Object GUID" followed by a long number. The number is the GUID for that object. For example:

Other Name: 1.3.6.1.4.1.311.25.1 = ac 4b 29 06 bb d6 5d 4f e3 9c 4c ab c3 6a 55 d9

Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)

* The certificate Subject Alternative Name section must contain the Domain Name System (DNS) name. If SMTP replication is used, the certificate Subject Alternative Name section must also contain the globally unique identifier (GUID) of the domain controller object in the directory.
* To determine the Domain Controller GUID, start Ldp.exe and locate the domain-naming context. Double-click the name of the domain controller that you want to view. The list of attributes for that object contains "Object GUID" followed by a long number. The number is the GUID for that object. For example:
1. The domain controller certificate must be installed in the domain controller's local computer's certificate store.

Other Name: 1.3.6.1.4.1.311.25.1 = ac 4b 29 06 bb d6 5d 4f e3 9c 4c ab c3 6a 55 d9 DNS Name=controller1.agency.gov
### How do I issue Domain Controller Certificates?
This is a challenging question to answer. US Federal Civilian agencies currently have a variety of policies on whether you should use a Domain Controller certificate issued from your agency's standalone or local Certificate Authority, or whether the certificate must be issued from a Certificate Authority managed and certified under the Federal Public Key Infrastructure (FPKI) Policy Authority To help answer this question, we're compiling a list of known policies and options available to all US Federal Civilian agencies here (TODO: INSERT LINK TO A REPO or MD page).

The best option for now is to talk with your Chief Information Security Officer (CISO) or Information Security office for a definitive answer and direction.
### Common Commands and Examples

* The domain controller certificate must be installed in the local computer's certificate store.
Getting the GUID commands

```
body { font-size: 12pt;
background-color: #fff}
```

certutil -dcinfo
/ command to query domain controllers for certs and status
extensions for domain controller certs
9 changes: 3 additions & 6 deletions _networkconfig/3_managingtrustroots.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -13,13 +13,12 @@ permalink: networkconfig/trustedroots/

### Addition of US Federal Certificate chains to the Trusted Root Certificate Authorities

The root certificate and intermediate CA certs are required by the domain controller to establish trust between the parent CA and the end users and applications.
The root certificate and intermediate certificates are required to be added to the _Trust Store_ on all domain controllers, workstations and servers in the domain.

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.
Active Directory must be configured to trust a certification authority to authenticate users based on certificates from that CA.

Both workstations and domain controllers must be configured to trust the certificates
Both workstations and domain controllers must be configured to trust the 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:

Expand Down Expand Up @@ -49,5 +48,3 @@ This task will configure Active Directory to trust the CA chain that signed the
certutil –dpublish –f "path_to_root_CA_cert" NTAuthCA

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


Loading

0 comments on commit 44de292

Please sign in to comment.