draft updates to network guides

_includes/network_index.md

@@ -6,7 +6,11 @@
 
 ## Introduction to Network Authentication Guide
 
-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.  
+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 five configuration categories to step through with your colleagues.  We recommend working with your Network Engineers, Domain Admins, Account Management, and Information Security colleagues to review the information, perform the configurations, and troubleshoot any issues together.  
 
 1. [Checking Ports and Protocols](../networkconfig/ports/)
 2. [Domain Controller certificates](../networkconfig/domaincontrollers/)
@@ -19,4 +23,4 @@ The Network Authentication guides are for configuring your Windows _network doma
 *  You're using Microsoft Active Directory to manage your Windows network
 *  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
+   * There are options for workstations that are Mac OS based and joined to a Windows network - to be covered in addendums to this guide

_networkconfig/1_portsprotocols.md

@@ -10,62 +10,81 @@ permalink: networkconfig/ports/
 </div>
 </div>
 
-This section covers the common network configurations and considerations for implementation including:
+Your workstations, servers, network domain controllers and applications need to validate the [revocation](../../pivcertchains#revocation) status of the PIV certificates and all intermediate certificate authority certificates.  In addition, the [certificate chain](../../pivcertchains#certificate-chains) path building may retrieve and download the intermediate certificate authority certificates.  
 
-1. [Ports and Protocols](#ports-and-protocols)
-1. [Common web services in the Federal Public Key Infrastructure](#common-web-services-in-the-federal-public-key-infrastructure)
-1. [Verifying and Troubleshooting](#verifying-and-troubleshooting)
-1. [Implementing local OCSP and CRL services inside your network](#implementing-local-ocsp-and-crl-services-inside-your-network)    
+The validation occurs in real-time (with some caching) and requires ensuring traffic over the network is open and available to the destination web services, ports, and protocols.   
 
+Many US 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.   You may find restricted or denied access to internet web services including the OCSP and CRL web services used in the certificate validations.  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.   
 
-Your workstations, servers, network domain controllers and applications need to validate the [revocation](../../pivcertchains#revocation) status of the PIV certificates and all intermediate certificate authority certificates.  In addition, the [certificate chain](../../pivcertchains#certificate-chains) path building may retrieve and download the intermediate certificate authority certificates.  
+This section covers the common network configurations and considerations including:
 
-This validation occurs in real-time (with some limited caching) and requires ensuring traffic over the network is open and available to the destination web services, ports, and protocols.   
+1. [Web services for validating PIV certificates](#web-services-for-validating-piv-certificates)
+1. [Web services for the Federal Public Key Infrastructure](#web-services-for-the-federal-public-key-infrastructure-root)
+1. [Verifying and Troubleshooting](#verifying-and-troubleshooting)
+1. [Implementing local OCSP and CRL services inside your network](#implementing-local-ocsp-and-crl-services-inside-your-network)  
 
-Many US Federal agencies may implement a layered network security model with firewalls, demilitarized zones (DMZs), proxies and Trusted Internet Connections (TICs) to monitor, defend and protect the networks, applications and users.   Therefore, you may find restricted or denied access to internet web services including the OCSP and CRL web services used in the certificate validations.  It is recommended to collaborate with your network engineers to review the web services, internet protocol (IP) addresses, ports and protocols and verify access from all local and wide area network segments.   
 
-#### Ports and Protocols
+#### Web services for validating PIV certificates
 
-[Revocation](../../pivcertchains#revocation) status is checked using one of two methods, over the HTTP protocol:
+[Revocation](../../pivcertchains#revocation) status is validated using one of two methods, over the HTTP protocol:
 
 | 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 certificate authority. Intermediate certificate authorities 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 certificate authority.  All intermediate certificate authority certificates have CRL capabilities.  CRL files have an expiration time which varies between 6 hours to 18 hours. CRL file sizes range from a few kilobytes to over 30 megabytes (MB).
 
-The LDAP protocol for retrieving revocation information is not preferred and is being increasingly deprecated; therefore LDAP is not included in this guide.
+Lightweight Directory Application Protocol (LDAP) for retrieving information is not preferred and has been increasingly deprecated; therefore LDAP is not included.
 
+To meet your initial network requirements, you should ensure the OCSP and CRL URLs included in *your agency* users' [PIV Authentication certificates](../details/#viewing-your-piv-credential) are accessible from all workstations and domain controllers.  
 
-#### Common web services in the Federal Public Key Infrastructure
+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 (COMMON) is the root of The
+#### Web services for the Federal Public Key Infrastructure
 
-To enable communications with the <what?> network of webservices available, including those currently operational and any expansion, it is recommended to allow outbound communications to the Federal Public Key Infrastructure Management Authority address space as registered with the American Registry for Internet Numbers (ARIN) under FPKI-NET:
+The Federal Common Policy Certificate Authority (COMMON) is the root certificate authority and has web services to publish both [certificate chains](../../pivcertchains#certificate-chains) (p7b files) and [CRLs](../../pivcertchains#revocation) 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, it is recommended to allow outbound communications to the Federal Public Key Infrastructure Management Authority address space as registered with the American Registry for Internet Numbers (ARIN) under FPKI-NET:
 
 | IPv4  |  Net Range  | 199.167.92.0 - 199.167.95.255 |
 | IPv4  |  CIDR  | 199.167.92.0 / 22 |
 | IPv6  |  Net Range  | 2620:9B:C000::- 2620:9B:C00F:FFFF:FFFF:FFFF:FFFF:FFFF |
 | IPv6  |  CIDR  | 12620:9B:C000::/44 |
 
+You should consider allowing two protocols (port): HTTP (80) and DNS (53).  Although the web services for publishing CRLs is not currently served over HTTPS (443), you may want to allow HTTPS (443) to future proof for any expansion.
 
 
 #### 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.   
+
+Troubleshooting if the web services endpoints are accessible or blocked is simple to begin.  You have the basic four utility tools for troubleshooting:
 
+*  certutil (Microsoft)
+*  openssl
 *  nslookup
 *  tracert
-*  certutil
-*  openssl
 
 
+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.text
+```certutil -verify -urlfetch mypiv_auth.cer >>verify_piv.txt
 ```
 
+The text file (txt) 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.  
 
-```certutil -verify -url mypiv_auth.cer >>verify_piv.text
+Alternately, there is a graphical user interface.  
+
+```certutil -v -url mypiv_auth.cer
 ```
 
+The graphical user interface allows you to check OCSP, CRL, and AIA (intermediate certificate retrievals).  
+
+
+
+
+
+
 
 
 

_networkconfig/2_domaincontrollers.md

@@ -6,17 +6,23 @@ permalink: networkconfig/domaincontrollers/
 ---
 <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>
 
-### 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.  
 
-### What do the Domain Controller Certificates need to include?
-The certificate for each domain controller must meet the following specific format requirements:
+To use smartcards and PIV credentials for network authentication, all the Domain Controllers need to have Domain Controller Authentication certificates.  
+
+>  When your users are using certificates to authenticate, the domain controllers are also authenticating as _devices_ using certificates.  Each works together  to create secure connections.  This is required for the protocols and if you want to learn more - search for information on _PKINIT_ protocols.  
+
+This section contains information on domain controller certificate profiles and issuing domain controller certificates.
+
+1. [Domain Controller Certificate Profiles](#domain-controller-certificate-profiles)
+1. [Issuing Domain Controller Certificates](#issuing-domain-controller-certificates)
+<!-- 1. [Common Commands and Examples](#common-commands-and-examples) -->
+
+#### Domain Controller Certificate Profiles
+The domain controller certificates need to be issued with a set of specific extensions and values.  The certificate for each domain controller must meet these requirements:
 
 1.  The certificate **Key Usage** extension must contain:
 
@@ -33,27 +39,26 @@ The certificate for each domain controller must meet the following specific form
 
 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:
+   *  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
 
 
-1.  The domain controller certificate must be installed in the domain controller's local computer's certificate store.
+1.  The domain controller certificate must be installed in the domain controller's local computer's personal certificate store.
+
+#### Issuing Domain Controller Certificates
+US Federal Civilian agencies have a variety of policies on whether you should use a Domain Controller certificate issued from your agency's local enterprise Certificate Authority, or whether the certificate must be issued from a Certificate Authority managed and certified under the Federal Public Key Infrastructure (FPKI).  Providing a common guide and recommendation is challenging as each agency's information security policy should be followed.
+
+It is not recommended to set up a local enterprise certificate authority just to issue domain controller certificates without ensuring the proper management and security protections are enabled, and your Chief Information Security Officer (CISO) has awareness and oversight for the certificate authority management.
 
-### 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 is to collaborate with your Chief Information Security Officer (CISO) or Information Security office for a definitive answer and direction.
 
-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
+<!-- ### Common Commands and Examples
 
 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
+extensions for domain controller certs -->

_networkconfig/3_managingtrustroots.md

@@ -6,15 +6,13 @@ permalink: networkconfig/trustedroots/
 ---
 <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>
 
+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.
 
-### Addition of US Federal Certificate chains to the Trusted Root Certificate Authorities
-
-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.   
-
+#### Addition of US Federal Certificate chains to the Trusted Root Certificate Authorities
 
 Active Directory must be configured to trust a certification authority to authenticate users based on certificates from that CA.
 
@@ -36,9 +34,9 @@ From here, follow these steps to import the intermediate certificate(s):
 2.	Follow the prompts in the Wizard to import the **Intermediate Certificate(s)** for the CA and click OK
 
 
-### Publish the CA Certificates to the NTAuth Store
+#### Publish the Federal Common Policy Certificate Authority (COMMON) root certificate to the NTAuth Store
 
-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.
+By publishing the CA certificate to the enterprise NTAuth store, the system administrator indicates that the CA is trusted for authentication using certain certificates.
 
 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: