NetHope Haiti Emergency Response – https://secure.groundspring.org/dn/index.php?aid=10514

Doctors without borders – https://donate.doctorswithoutborders.org/SSLPage.aspx?pid=197&hbc=1&__utma=1.2707009755311606300.1263527892.1263527892.1263527892.1&__utmb=1.1.10.1263527892&__utmc=1&__utmx=-&__utmz=1.1263527892.1.1.utmcsr=bing.com%7Cutmccn=(referral)%7Cutmcmd=referral%7Cutmcct=/search&__utmv=-&__utmk=23734074

Catholic Relief Services – https://secure.crs.org/site/Donation2?1080.donation=form1&df_id=1080

American Red Cross (Haiti Relief and Development) – https://american.redcross.org/site/Donation2?idb=1946232924&df_id=4437&4437.donation=form1&JServSessionIdr004=8xigfzwt61.app196b

United Way Worldwide Disaster Fund – https://volunteer.united-e-way.org/uwwwdisaster/donate/

Food for the Poor – https://secure3.convio.net/ffp/site/Donation2?df_id=6320&6320.donation=form1

Remember when you donate to follow your employers process for “Matching Gifts” – HR is a good place to start if this is not easily found within your organization.

What this blog entry is NOT intended to be:

• A debate about a common Federal Identity namespace and authentication directory.
• A debate about Microsoft Windows versus other operating systems.
• A debate about the Shared Service Provider or Managed Service Offering models.
• A debate about the effectiveness of PKI bridges or hierarchies.

This blog entry is intended to:

• Provide information so that anyone with a requirement for logical access using PIV cards will know what the steps are they can take to help meet HSPD-12 and OMB 05-24.

First to support the use of smart cards for network authentication, we assume that the agency or department has already completed the following, in accordance with the dates established by the OMB.

1. Implemented a compliant FIPS-201-1 PIV Card Issuing (PCI) System, or have signed with either GSA’s managed service offering – USAccess or another shared service provider solution for user sponsorship, registration, issuance and activation of the PIV credential.
2. Have selected a PIV middleware vendor and solution for use in the organization.
3. Have selected a smart card reader compatible with the OS and approved for use on FIPS201 Approved Products List.

In addition to the aforementioned items, if the agency is planning on using the PIV cards for smart card logon, to Microsoft Windows XP, Windows Vista or later operating system, then the following requirements must also be addressed by the organization to successful logon with the PIV cards to the network.

Microsoft Windows XP SP2 and SP3, in a Microsoft Windows Server 2003 forest has the following requirements for smart card logon.  With Windows Vista and the upcoming Windows 7, the UPN and Smart Card Logon EKU are optional, more information is available here;  however, for today let’s focus on Microsoft Windows XP.

• The x.509 certificate issued to the end entity must have enhanced key usage of Smart Card Logon (1.3.6.1.4.1.311.20.2.2) and Client Authentication (1.3.6.1.5.5.7.3.2), the subject alternative name field must be populated with a UPN value.
• The x.509 certificate issued to the end entity must have the CRL Distribution Point (CDP) populated.
• Key usage must be of type "Digital Signature".

For HSPD-12 PIV card certificates issued under the Federal Common Policy Framework, these certificate properties are populated and meet the requirements.  However, there are infrastructure requirements that also need to be addressed by each agency, wishing to use their employee and contractor PIV cards for network smart card logon.  The order of steps below are of no particular significance, however, all must be completed for a successful implementation.

1. The issuing CA, that issued the user’s PIV_authentication certificate MUST be trusted by the organization’s forest in the NTAuth container.  A copy fo the certificate from the CA in a base64 encoded file format can be published by an Enterprise Administrator or Schema Administrator from a member server using CERTUTIL -DSPUBLISH ["nameofthefile"].CER NTAuthCA.  This step basically states that the CA is trusted by the forest and domain controllers (DCs) for issuing of credentials to be used for network authentication.
2. The ROOT CA of the certificate chain must be trusted by each client and DC that will participate in the network authentication process.  For HSPD-12, this will almost always be the "Common Policy" or the Federal Bridge Cross Certification Root, depending on how the agency established their trust to the federal root CAs.  For the certificate to be trusted, there are several ways to get the certificate, 1) Microsoft Certificate Update Program, clients configured properly will download this file from the Microsoft Update site, 2) download from the AIA location in a subordinate certificate and publish to forest manually, 3) acquire from GSA, or Federal PKI Policy Authority (FPKIPA) and publish manually.  To manually publish the file to the organization’s forest so that all clients and DCs will trust the root, use CERTUTIL -DSPUBLISH ["nameoffile"].CER RootCA from a domain member server with Enterprise or Schema Administrator rights.
3. The CDP and\or the Online Certificate Status Protocol (OCSP) responder referenced in the leaf certificates must be accessible by the DCs that will process the authentication request.  Note, if you have NOT deployed Microsoft Windows Server 2008 and OCSP is your preferred validation method, then a third party OCSP client will be required.  OCSP client functionality is an inherent capability in Microsoft Windows Vista, Windows 7 and Windows Server 2008.
4. Each DC server that will process authentication requests, MUST also be issued a DC Authentication Certificate for mutual authentication with the clients during the Kerberos PKINIT process. This DC Authentication certificate can be an internally issued certificate, exclusive of the PKI chain used for the PIV credentials.  FIPS and the x.509 Common Policy Framework intends on issuing strong credentials to users at the MEDIUM and HIGH Assurance Profiles; it is important to note that each of these profiles requires a face to face identity vetting process.  The administrators for DCs are not likely to request DC Authentication certificates by meeting with the issuance authority face to face for each DC.  Therefore, an internal Microsoft Windows Server 2003 or 2008 CA deployed in accordance with the organization’s policies is capable of automatically enrolling, renewing and deploying the certificates to the DCs; this process is called "auto enrollment and auto renewal".   However, if the agency’s policy requires the use of a third party CA or purchase of certificates from a service provider, the certificates can be requested using PKCS and installed on each DC manually.  The external DC certificate process requires a manual request, installation, renewal and maintenance of the DC Authentication certificates.  In addition, for external DC Authentication certificates, each client on your network will require access to the CDP, OCSP and AIA locations in the DC certificates for validation during the PKIINT process; if the root for the DC certificates is not already trusted, a trust as previously described will need to be established.

The following are additional items that should be verified, for the smart card logon process to be successful…

1. Each client machine MUST also be a member of the forest/domain that they will attempt to authenticate to; non-domain joined machines cannot participate in smart card logon.
2. Each user object in the forest must have a matching UPN value in certificate.  For example, John Doe at agency.gov with a PIV card from USAccess issued with 19202837@fedidcard.govas the UPN will not authenticate if the domain user object has a UPN of john.doe@agency.gov.  Therefore, the UPN in the domain will need to be changed to match the value in the certificate, and the suffix "fedidcard.gov" must be added to the forest.  Click here for more information.  Of course if you submitted the user’s registration to USAccess with your own internal UPN values, then no change should be required for the authentication to work.  USAccess supports both options, and agencies with their own PCI System will have flexibility to use whatever value makes the most sense for their implementation. 

This posting is provided "AS IS" with no warranties,  and confers no rights.