IT Showcase: Deploying and Managing PKI Inside Microsoft...

Deploying and Managing PKI Inside Microsoft

Technical White PaperOriginally Published: February 2005

Updated: September 2011


CONTENTS

Executive Summary............................................................................4

Introduction.......................................................................................5

Initial PKI Deployment........................................................................6

Changes to the Multi-Tier Structure....................................................9

Security Requirements.........................................................................................................11

Protection of CA Private Keys 11

Physical Security 12

Network, Server, and Directory Security 12

Installation and Implementation Considerations.........................................................................................................14

CRL, AIA, and Certificate Template Considerations 14

CRL Publication 14

CRL Lifetime 15

PKI-Enabled Services.........................................................................................................17

Smart Cards for Network Access 17

Smart Card Infrastructure................................................................................................18

Delegated Issuance.........................................................................................................18

Smart Card Renewal.......................................................................................................19

IPsec 19

EFS 20

S/MIME 20

Key Archival and Recovery 21

Key Recovery Agents......................................................................................................21

Dependencies..................................................................................................................22

SSL 22

Wireless 23

NAP 24


Product Updates and Associated Infrastructure Changes.........................................................................................................26

Cross-Forest Enrollment and Server Consolidation 26

Geographically Disbursed PKI 27

Disaster Recovery 28

CA Server Management and Support.........................................................................................................30

Backup 30

Monitoring 30

Software Updates 31

Hardware Upgrades 31

Upcoming Initiatives.........................................................................................................32

Lessons Learned and Best Practices.........................................................................................................33

Plan for Future Upgrades to the Windows Server PKI 33

Carefully Consider the Number of CA Servers Needed 33

Consider Integration with a Public Root 33

Automate CRL Publication 34

Customize the CRL Publication Overlap Interval 34

Use New Keys for CA Renewal 34

Plan for Certificate Issuance Policies 35

Sanitize Elements of the PKI 36

Ensure Service Availability for High-Demand Applications 36

Use Hardware Security Modules 36

Have a Clearly Defined Policy 36

Conclusion.........................................................................................................38


For More Information.........................................................................................................39


EXECUTIVE SUMMARYMany of the techniques and products available to help secure an enterprise network rely on some form of cryptography. A public key infrastructure (PKI) provides the certificates used by each party involved in a cryptographically secured electronic transaction. To help secure the Microsoft corporate network and certify its software, Microsoft Information Technology (Microsoft IT) needed to implement several initiatives that required cryptographic techniques. Today, these initiatives include:

Certificate-based 802.1X wireless authentication.

Smart cards for two-factor remote access authentication.

Secure Multipurpose Internet Mail Extensions (S/MIME) for digitally signing and encrypting email.

Encrypting File System (EFS) for file and folder encryption.

Internet Protocol security (IPsec) for the security of network transactions.

Secure Sockets Layer (SSL) for the security of web connections.

Network Access Protection (NAP) for enforcing system health.

These initiatives required the presence of an enterprise-wide PKI to provide public key–based security services.

Running its own certification authorities (CAs) rather than using commercial, non-Microsoft services enabled Microsoft IT to more securely manage the infrastructure and reduce the costs associated with issuing certificates and managing an external CA relationship. Implementing an enterprise PKI enabled Microsoft IT to better secure its network-based communications.

Microsoft IT's easy-to-manage, standards-based, scalable PKI solution resulted in a method to exchange sensitive data, compatibility with other Microsoft applications, and lower infrastructure costs.

This white paper describes the production deployment and use of the PKI features available in the Windows Server 2008 and Windows Server 2008 R2 operating systems. This white paper also offers lessons learned and best practices, and it includes a discussion on the future directions of the technology at Microsoft. It assumes that readers are technical decision makers and are already familiar with the fundamentals of public key cryptography systems, the benefits that such systems offer, and the components required to implement those systems. Links to additional sources of information about PKI are available in the "For More Information" section at the end of this paper.

This paper, first published in June 2005 and updated in September 2011, reflects the deployment of new Microsoft products within the corporate infrastructure and describes associated infrastructure changes.

Note: For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names used in this paper do not represent real resource names used within Microsoft and are for illustration purposes only.


SituationMicrosoft IT needed a platform to help secure network communications, help protect data (both at rest and in transit), and certify internal code.

SolutionMicrosoft IT deployed Certificate Services in Windows Server 2003, and Active Directory Certificate Services in Windows Server 2008 and Windows Server 2008 R2, to implement an infrastructure for encrypted communications, security-enhanced remote authentication, and software validation.

Benefits Enabled strong network user

authentication by using smart cards Helped protect email

communications by using S/MIME Improved security of Web

connections by using SSL or TLS Helped ensure the confidentiality of

stored data by using EFS Helped ensure the confidentiality

and integrity of transmitted data by implementing IPsec

Enforced system health by using NAP

Products & Technologies Windows Server 2008 Windows Server 2008 R2 Windows-based PKI and CA Certificate Services and Active

Directory Certificate Services Smart cards EFS IPsec S/MIME SSL NAP

INTRODUCTIONThe charter of Microsoft IT is to maintain an IT environment composed of services, applications, and an infrastructure that provides availability, privacy, and security to Microsoft employees in more than 400 locations worldwide. Microsoft IT is responsible for running the company's internal networks, telecommunication systems, corporate servers, and all line-of-business applications. In addition, Microsoft IT is committed to testing Microsoft enterprise products in a production environment before they are released to the public and providing feedback to the product development groups by being their first and best customer.

Currently, the server infrastructure at Microsoft consists of servers running Windows Server 2008 and Windows Server 2008 R2. Security continues to be at the highest level of priority across all areas of product development at Microsoft and within the corporate infrastructure. By implementing an enterprise PKI, Microsoft IT can use standards-based cryptographic technologies to help secure the Microsoft corporate network and its data.


INITIAL PKI DEPLOYMENTThe first PKI hierarchy at Microsoft was introduced in February 2000 and consisted of three tiers: one stand-alone offline root CA; two stand-alone intermediate CAs; and multiple specialized, online enterprise issuing CAs.

The offline root and two intermediates functioned as follows:

Microsoft Corporate Root CA. This CA was the root of the corporate PKI hierarchy. Its only purpose was to issue or revoke the certificates of the two offline intermediate CAs.

Microsoft Intermediate Intranet CA. This offline intermediate CA certified all other CAs used to issue certificates intended for use only within the bounds of the Microsoft corporate network environment.

Microsoft Intermediate Extranet CA. This offline intermediate CA certified all other CAs used to issue certificates intended for use outside the bounds of the Microsoft corporate network, including the Internet and the Microsoft extranet environment.

There was no support for cross-forest enrollment; therefore, each forest required its own set of enterprise CAs. However, each forest used the same offline stand-alone root and intermediate CAs.

All the enterprise issuing CAs were subordinate to the intermediate CAs. Table 1 details the function of each issuing enterprise CA in the hierarchy.

Table 1. Types of Online Enterprise Issuing CAs Initially Deployed

Type of CA Function

Intranet Network Issued certificates for network-wide services that related to general server, user, or network administration, such as an enrollment agent and EFS data recovery

Intranet Computer Issued authentication and IPsec certificates for computer accounts, including domain controllers

FTE User Issued user-based certificates for full-time Microsoft employees on the corporate network for general client authentication and EFS

Non-FTE User Issued certificates for temporary contract and vendor staff users on the corporate network for general client authentication and EFS

Intranet Level 2 User Issued certificates for full-time Microsoft employee users for smart card logon

Personnel E-Mail Issued certificates for S/MIME digital signatures and encryption services

Extranet Computer Issued certificates for computers outside the corporate network, such as web servers and business partner systems

Figure 1 shows the hierarchy of CAs in the initial primary PKI design that Microsoft IT created. A secure, Microsoft IT–controlled vault housed all of the CAs.


Figure 1. Original PKI hierarchy

The stand-alone, offline root signed the offline intermediate CAs. Then, the offline intermediates signed the online enterprise subordinate CAs. The online enterprise CAs were the issuing CAs for all certificates issued internally at Microsoft.

Microsoft IT defined the root certificate with a 16-year CA certificate lifetime, a 4,096-bit RSA key, and a 90-day Certificate Revocation List (CRL) publishing interval. The CRL was published to an external Hypertext Transfer Protocol (HTTP) path and in the Active Directory directory service through a Lightweight Directory Access Protocol (LDAP) URL. Microsoft IT defined a two-year CA lifetime for each of the issuing CAs that used 2,048-bit RSA keys. The CRL publication interval on the issuing CAs varied, depending on the function of the certificates being issued.

End-entity certificates were generally issued with a validity period of one year or less. Because a CA cannot issue a certificate with a validity period that exceeds that of its own certificate, the certificates for issuing CAs needed to be renewed annually. This allowed


issuing CAs to continue to issue end-entity certificates that were valid for their full, intended one-year validity period.


CHANGES TO THE MULTI-TIER STRUCTUREThe primary reason for deploying the three-tier hierarchy was the intended separation of internally used certificates versus those that would be used outside the company, which would potentially drive the need for different certificate policies in addition to overall service management practices. However, the existing private corporate root was not very usable for security-enhanced communications outside the Microsoft corporate network. Because the Microsoft corporate root was unique to Microsoft, no one outside Microsoft trusted it by default. It is critical that client computers trust certificates, such as those used for SSL server authentication. Because of this requirement, Microsoft IT purchased individual certificates for SSL-enabled websites that were intended for access by non-Microsoft personnel. Microsoft IT purchased these certificates from a publicly trusted non-Microsoft provider, rather than issuing them from the Microsoft internal PKI infrastructure.

As the use of individual publicly trusted certificates grew, Microsoft IT found that purchasing these certificates was increasingly expensive. The use of S/MIME was also increasing. S/MIME certificates were all issued by CAs that chained to the Microsoft corporate root. To facilitate usage of these certificates outside the Microsoft corporate network, external recipients needed to manually install the Microsoft Corporate Root certificate. This process and the user education around it proved to be laborious. Microsoft IT needed to include the architecture of a public root hierarchy in its PKI infrastructure for external security requirements, so that all parties could acknowledge that they trusted the root of the certificate chain.

Rather than continue to buy each end-entity certificate individually from a trusted non-Microsoft provider, Microsoft IT decided to create a second, independent PKI infrastructure by subordinating its own offline intermediate CA to that of a publicly trusted root CA. Microsoft IT agreed to pay GTE CyberTrust, Inc., an annual fee for subordinating a Microsoft CA under the GTE CyberTrust Root and GTE CyberTrust Global Root. Since 1998, both of these root certificates have shipped as trusted roots in Microsoft operating systems and a variety of non-Microsoft operating systems. The GTE CyberTrust roots provided the ubiquity that Microsoft needed to satisfy its public trust needs for both SSL and S/MIME.

With this new model, the non-Microsoft provider handles all of the issuance and revocation needs for the new intermediate CA. Microsoft IT staff continues to own and manage all the internally managed CAs. These new developments negated the need to retain the original intranet and extranet offline intermediate CAs, for that reason Microsoft IT made a decision to retire them.

Figure 2 depicts the hierarchical changes after Microsoft IT adopted a publicly trusted root model.


Figure 2. Original hierarchy, modified for non-Microsoft root


SECURITY REQUIREMENTSEven though the Microsoft internal hierarchy no longer has the previous intermediate CAs, Microsoft IT did not lower any of the existing security controls when it created the new hierarchy. The root and the new intermediate CA are offline and never exposed to network traffic, thereby minimizing the chance of a compromise. Because these CAs are offline, Microsoft IT security staff manually issues and published their certificates (through a portable medium) to Active Directory Domain Services (AD DS). Additionally, the security staff issues certificates to all online enterprise CAs in the appropriate AD DS forest by manually copying certificate request files from the online servers to the offline roots and intermediate. The security staff uses trusted portable media to transport the certificates between servers. The requests are processed, and security staff transfers the issued certificates from the offline CA back to the enterprise CA for installation.

To decide on the security required for a CA, Microsoft IT determined the risks of attack on the CA in addition to the costs of a CA compromise. Higher risks of attacks on the CA and higher costs of a CA compromise justified higher costs for security measures to help protect the CA. Offline root (and subordinate) CAs typically require higher levels of protection than issuing CAs.

After evaluating the risks of an attack and then weighing those against the cost of service recovery, an organization should determine its own level of security protection for its CAs, especially the root CA. Security protection does not have to be expensive, especially for smaller companies. There might be adequate protection in having the offline root CA in a secure computer cabinet or using removable media that is stored in a safe.

The sections that follow describe the security measures that Microsoft IT took in its Windows Server PKI infrastructure.

Protection of CA Private KeysCertificate Services in Windows Server 2003—the feature called Active Directory Certificate Services (AD CS) in Windows Server 2008 and Windows Server 2008 R2—ships with a software cryptographic service provider (CSP) that complies with the Level-1 requirements of Federal Information Processing Standard (FIPS) 140-2. The operating system manages the key pairs that are generated by a software CSP in Windows Server. This situation exposes a considerable risk if the system is compromised. With these keys, an attacker can re-create the CA and issue seemingly valid certificates. This is a typical FIPS 140-2 Level-1 security risk, which an organization can mitigate by providing more difficult and verifiable physical access to the Windows Server–based CA system.

Note: The National Institute of Standards and Technology (NIST) issues the FIPS standards and guidelines for use within the U.S. federal government. FIPS 140-1 defines the "Security Requirements for Cryptographic Modules" as of January 1994. FIPS 140-2 defines the same topic but does so with more stringent security requirements as of June 2001. For specific definitions of the various security levels, visit the NIST PKI website at http://csrc.nist.gov/pki/.

To provide stronger protection of CA private keys, Microsoft IT installed Hardware Security Modules (HSMs) on each CA server. By using specialized, tamper-resistant hardware to help protect private cryptographic keys, HSMs provide a high level of security for the keys, for the CA, and for the certificates that the CA signs.


http://csrc.nist.gov/pki/

The HSMs are certified for FIPS 140-2 Level-3 compliance. This was important in establishing a level of trust between Microsoft and its business partners, including the U.S. government. The Microsoft Corporate Root CA uses an HSM configured in FIPS 140-2 Level-3 mode.

Each HSM is part of a trusted security boundary, sometimes referred to as a "domain" or "security world." Microsoft IT implemented a multiple-person, multiple-token model where no single internal group has full control over the private keys. Control of the private keys is divided among Microsoft IT, Legal and Corporate Affairs, and the Corporate Security teams. Access tokens are dispersed across the groups and stored securely. Additionally, the access tokens are stored in multiple sites to mitigate a disaster at one site.

Microsoft IT adhered to the following model when creating HSM security boundaries for various levels of the hierarchy:

A root security boundary for the offline Corporate Root CA

An issuing security boundary that contains all online issuing CAs

An issuing security boundary that contains all "remote" CAs—that is, issuing CAs that are not in direct physical control of Microsoft IT

The security boundaries provided a distinction between the various CAs and administration activities. By creating separate security boundaries and by using the principle of least privilege, Microsoft IT obtained a greater level of assurance. This level of security, in combination with stringent physical access, helps maintain a high level of assurance regarding the use of these CAs.

Physical SecurityThe initial PKI deployment was physically located in a Microsoft IT-controlled vault that housed both the offline and online CAs. Microsoft IT later decided to move the infrastructure to an enterprise data center to take advantage of common support processes and security controls. Microsoft IT placed the CA computers into a dedicated security cage that employs a series of stringent security controls for higher protection.

Entrance into the data center is limited to authorized individuals and is controlled by a layered set of physical access controls, including guards, doors, building access cards, and biometrics. Access to the CA security cage is protected by its own access control list (ACL) with an additional layer of security measures.

Network, Server, and Directory SecurityACL control enrollment permissions on both the CA servers and the certificate templates in AD DS. Microsoft IT restricted the issuance of sensitive certificate types—such as issuance of server authentication certificates, which validate the identity of the server computer—to only designated personnel. All of the information was published to various AD DS containers controlled by ACLs. These containers are part of the AD DS Configuration container, enabling the Configuration container to be replicated to all domain controllers within the forest. Microsoft IT thus maintains central control over enrollment of these certificates, mitigating the possibility of unauthorized certificate issuance and usage.

Though authorized data-center personnel have physical access to the CA servers, logon is not allowed (access is limited to hardware maintenance and support only). To assist with operating system and service monitoring, Microsoft IT reached an agreement with the


Microsoft Global Operations team that acts as the first point of contact for support of the entire infrastructure at Microsoft (including domain controllers and other high-security servers) and allowed a subset of Global Operations senior staff members to log on to the CAs for the purpose of troubleshooting and regular maintenance. Members of this support team must use two-factor authentication to log on.

Before access is provisioned, each support technician must take CA training (in the form of a video course prepared by the Microsoft IT CA team) and have his or her manager certify that training was successfully completed. Upon completion of the training, each support technician must go through an official access-provisioning request process, which has been recently tied into the overall elevated account-provisioning process for all high-security access at Microsoft. After CA access is approved, the records are logged into a secure-access database and reviewed on a quarterly basis.

Most CA servers require all connections to the CA to be over IPsec, with the exception of the CAs that issue IPsec certificates. Additionally, each CA uses the software firewall included in Windows Server to further limit allowed traffic.


INSTALLATION AND IMPLEMENTATION CONSIDERATIONS

CRL, AIA, and Certificate Template ConsiderationsDuring the installation and configuration of AD CS, Microsoft IT configured each of the following:

Publication of offline CA certificates to AD DS. Microsoft IT published the offline root and subordinate CA certificates to AD DS through use of the command-line tool certutil.exe. Microsoft IT published the root certificate directly to the Certification Authorities and Authority Information Access (AIA) containers of AD DS. Microsoft IT uses the Certification Authorities container to define trusted root CAs within the enterprise, and all enterprise clients recognize it. Microsoft IT could have opted to distribute the root certificate by using Group Policy. However, this distribution would have required separate policy configurations for each domain in the enterprise structure. By publishing the root certificate directly to AD DS in each required forest, Microsoft IT pushed it to all enterprise clients—in multiple domains throughout the forest—in one process.

Microsoft IT also published the offline intermediate CA certificates in the AIA container. This action provided a location from which users could obtain the certificates for the CAs. This container was an effective repository for CA certificates because it, along with the other PKI-related containers, is part of the Configuration container, which is replicated to every domain controller within the forest.

Certificates to be issued. Microsoft restricted the issuing CAs to issuing only specific certificate types. By default, an enterprise CA is preconfigured with a variety of certificate templates. Microsoft IT deleted unwanted certificate templates from the CAs and added only the templates that it wanted. In Windows Server 2008 and Windows Server 2008 R2, default templates can be suppressed through a CAPolicy.inf file.

CRL distribution point (CDP). The CDP is an extension in a certificate that defines where a CA publishes its CRL. The CRL distribution point is where any client or application that is performing certificate validation, including revocation checking, can retrieve the current CRL from the issuing CA. This location is written into the certificates that the CA issues. Before Microsoft IT installed Certificate Services, it defined the CRL distribution point URLs that would be used by a CA by creating a Capolicy.inf file and defining paths. Configuration of this extension in Certificate Services after installation then defined which URLs would be included in the certificates that the root CA issued. A self-signed root CA should not list any CDPs.

Authority Information Access. Similar to the CRL distribution point extension, the AIA extension defines where the CA's certificate is published. This information is also written into certificates that the CA issues. Prior to the installation of the CA, Microsoft IT defined (in a Capolicy.inf file) the information that the CA would use. Configuration of this extension in Certificate Services after installation then defined which URLs would be included in the certificates that the root CA issued. A self-signed root CA should not list any AIA locations.

CRL PublicationWhen any application, user, or process validates a certificate, it makes sure that the certificate chains to a root that is trusted on that system, is time-valid, and contains the


specific functional capabilities for which it is being presented. If all of these checks pass, the certificate is considered valid.

The CRL is checked to make sure that certificates that otherwise would be considered valid have not been revoked. The CRL itself is a file, signed by the CA, that contains a list of revoked certificates. The list defines the revoked certificates by serial number, and it includes the revocation date in addition to the reason for revocation. The application that is performing the certificate validation determines whether or not it checks for revoked certificates as part of the validation process. When an application checks for revoked certificates, it retrieves the current CRL from one of the URLs specified in the CRL distribution point extension of the certificate being validated. After the CRL is retrieved, it is typically cached until its expiration. After a CRL is cached, the application performs further revocation checks against this cached copy, eliminating the need to retrieve the CRL for each revocation check. When expired, the CRL itself becomes invalid, forcing the download of a new CRL.

Microsoft IT carefully considered which locations and protocols to publish in certificate CDPs. Most certificates use a combination of HTTP and AD DS (LDAP) CDPs that are highly available. Microsoft IT also analyzed who the current and future relying parties of the certificates would be. CRL distribution points must be available to anyone who must validate the certificate. Microsoft IT considered whether certificates would need to be validated from outside the corporate network and made CDPs available from outside as needed. Many CRLs are hosted on a highly available Windows Azure–based solution.

CRL LifetimeMicrosoft IT configured different CAs to have different CRL publication intervals, depending on how the certificates that the CAs issued were used. For example, Microsoft IT initially configured the CRL lifetime to be 24 hours for the smart card CAs, and four days for the utility CAs. (Utility CAs are those CAs that issue a variety of certificates to Microsoft users and computers, including IPsec, wireless, domain controller authentication, remote access and Internet Authentication Service [IAS], and EFS).

The purpose of the differential was to balance the need for timely CRL updates if a certificate needed to be revoked, while minimizing the performance impacts of frequent CRL retrieval and directory replication. With the revocation of a smart card authentication certificate, Microsoft IT wanted the revocation status to take effect as quickly as possible. Because a CRL is typically cached until it expires, short expirations would ensure timely CRL updates that would reflect current revocation status more quickly.

CRL publishing for the offline CAs is a manual process. The CRL lifetime for the offline CAs at Microsoft is 90 days. Members of the Corporate Security team must enter the CA cage to manually publish the CRL from these offline CAs because they are normally turned off and always lack network connectivity. Certificate Services/AD CS handles CRL publishing for the online CAs automatically at the predetermined intervals.

A CRL has an established lifetime, and a new CRL must be published before the old CRL expires. The CRL publication interval includes a buffer to define a specific amount of time for which existing CRLs will remain valid after the next scheduled CRL publication. The purpose of this overlap period is to provide time for manual publication and replication of the newly created CRL prior to the expiration of the original CRL, and to avoid leaving a gap in the availability of a valid CRL. The default overlap period is 10 percent of the CRL lifetime period, with a maximum of 12 hours.


When Microsoft IT decided to publish a new CRL every 24 hours for smart card CAs, the default overlap period was reduced to just 2.4 hours. Because this period did not provide sufficient time for replication of the new CRL throughout Microsoft IT's worldwide enterprise before the previous CRL expired, Microsoft IT needed to manually configure the CRL overlap to extend the validity period. The extended period ensured that the old CRL would remain valid while the new CRL was being replicated throughout the network. As such, smart card CA CRLs are published 24 hours with a 24-hour overlap period, making the CRL valid for 48 hours. The rest of the CA CRLs are published every four days with a four-day overlap period, making those CRLs valid for eight days.


PKI-ENABLED SERVICESMicrosoft IT had several user requirements that needed the deployment of cryptographic technologies. These requirements included:

Enabling strong network user authentication by using smart cards.

Helping to ensure the confidentiality and integrity of transmitted data by using IPsec.

Helping to ensure the confidentiality of stored data by using EFS.

Helping to secure email by using S/MIME encryption and digital signatures.

Helping to secure web connections by using SSL or Transport Layer Security (TLS).

Enforcing health of domain-member computers by implementing NAP.

The following sections describe how Microsoft IT was able to meet each of those requirements with the help of Certificate Services/AD CS.

Smart Cards for Network AccessA smart card is a credit card–size, portable token that holds memory, a file and operating system, and a microprocessor. It might also contain radio frequency identification (RFID) and a personal identification photo printed on it—both important in considering physical authorization to company buildings or other controlled-access facilities.

Microsoft IT considered several alternative technology solutions before selecting smart cards as the preferred solution. Smart cards provided the best overall value based on reliability, performance, cost, features, mobility benefits, ease of support, and integration with the Microsoft IT Windows network environment.

Note: For more information about the Microsoft IT decision to deploy smart cards and about the deployment, see "Smart Card Deployment at Microsoft" at http://technet.microsoft.com/en-us/library/cc964306.aspx.

A key feature of smart cards is that they provide security-enhanced storage of data, including cryptographic data. Smart cards implement authentication through a user PIN, which then authorizes the user to access data on the smart card. A smart card implements multiple cryptographic algorithms that allow keys to be generated on the card and not be exportable from the card. An authentication certificate with the private key protected by a smart card allows for strong two-factor authentication: something the user has (smart card) and something the user knows (PIN). The combined use of the smart cards and a PKI-capable authentication protocol such as Extensible Authentication Protocol (EAP)/TLS enables a much stronger authentication mechanism over the standard approach of entering a user name and password.

The initial smart card deployment at Microsoft was built upon several technologies found in the Windows 2000 Server infrastructure, including Certificate Services, Routing and Remote Access, and IAS. The smart card solution was enhanced when Microsoft IT upgraded to Windows Server 2003. The PKI enhancements to Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 enabled Microsoft IT to better manage certificate enrollment and renewals, as well as delegate the process of creating and distributing smart cards.


http://technet.microsoft.com/en-us/library/cc964306.aspx

Smart Card InfrastructureTo enable issuance of smart card logon certificates, Microsoft IT deployed two CA servers for each production forest, and configured those to chain under the Microsoft Corporate Root CA. The two smart card CAs act as smart card issuing authorities only—no other certificate templates were deployed on these servers.

Two other certificate types are required for enabling smart card-based logon:

Domain controller authentication certificates (for all domain controllers in the forest)

Remote access and IAS server certificates (for all Remote Authentication Dial-In User Service [RADIUS] servers participating if smart cards are used for virtual private network [VPN] access)

Microsoft IT issues both of those certificates from another set of CAs (utility CAs) that also chain to the Microsoft Corporate Root CA.

The Microsoft corporate environment encompasses nine forests, which include production, preproduction, and other business and test environments. Today, one administrator must sometimes manage resources across multiple forests. Hence, if an administrator must use his or her card to authenticate to a resource in another forest, the smart card CA that issued the administrator's logon certificate must be trusted for authentication in the forest where the resource is being accessed. To accomplish that, Microsoft IT manually publishes the certificate of the issuing smart card CA to the NTAuth container of every forest where the administrator might attempt to access the resource.

Delegated IssuanceMicrosoft IT did not want to allow users to enroll themselves for smart cards through self-service. Microsoft IT wanted to maintain control of the issuance and distribution so that a face-to-face authentication could be performed and so that only authorized users received smart cards.

For the initial pilot deployment, Microsoft IT staff (located in Redmond, Washington) intended to create and issue smart cards to all Puget Sound users, and then subsequently issue smart cards to all other users worldwide. However, Microsoft IT quickly discovered that for ongoing support, it needed a more distributed plan to securely and quickly issue smart cards to users regionally. Microsoft IT decided to use a delegated issuance model to support smart cards after the initial deployment.

The implementation of a delegated issuance model was possible only after Microsoft IT upgraded the corporate PKI to Windows Server 2003. The enhanced flexibility of the Windows Server 2003 and Windows Server 2008 PKIs—particularly the ability to specify detailed issuance requirements on the certificate templates—enabled the delegated issuance model to support the required limited functionality role of Delegated Issuance Officers (DIOs). Microsoft IT wanted to distribute the issuance of smart cards and maintain control over the issuance of the certificates on them. The delegated issuance model allowed the DIOs to submit certificate requests on behalf of other users, but the issuance of those certificates required the explicit approval of Microsoft IT. The new issuance requirement settings on Windows Server 2003 certificate templates enabled Microsoft IT to specify all new certificate requests to be set to a pending status and require approval from a certificate manager. After the request was approved and the certificate was issued, the DIO would be able to retrieve the certificate and write it to the user's smart card.


Members of Microsoft IT went on a worldwide tour to visit and train the various DIOs on their duties, required procedures, security considerations for smart card distribution, and how to use the internally developed smart card tools. Afterward, DIOs participated in weekly teleconferences with Microsoft IT to keep up to date on emerging and continuing issues.

Smart Card RenewalThe Microsoft IT team also took advantage of the flexibility of PKI features starting in Windows Server 2003 to enable users to renew their smart card certificates themselves. By using the new issuance requirement features, Microsoft IT was able to configure the certificate template such that authorized enrollment agents must perform initial enrollments for all new smart card certificates. However, each user can renew his or her own smart card certificate by employing the existing valid certificate to sign the renewal request for its replacement. This ability greatly reduces the ongoing costs associated with a smart card deployment because Microsoft IT no longer needs to manually renew each smart card when the certificate expires.

In addition to enabling users to renew their own smart card certificates, auto renewal functionality helps to ensure that users renew their certificates prior to expiration. The certificate template configuration allows for specification of the renewal period. When a certificate reaches this period, auto renewal code prompts the user to renew the certificate and provides an automated method to do so.

IPsecIPsec is a framework of open standards for helping to protect communications over IP networks through the use of cryptographic security services.

In 2004, Microsoft IT introduced the concept of domain isolation to its corporate network. The purpose of such an initiative was to help protect domain-member, IT-managed resources from clients that are not members of an isolated domain. Microsoft IT chose IPsec as the enforcement method, and through a combination of Group Policy, IPsec policies and filters, Kerberos, and other key technologies, implemented it across the company.

Connection Manager, deployed to allow secure remote access to the corporate network, was also designed to require the use of IPsec in order to establish a secure connection to a domain-member resource. Additionally, Microsoft IT integrated Secure Remote User scripts that ran a set of checks on a client attempting to connect to the corporate network, and then performed several actions on that client to ensure that it met all the appropriate security policies. One of those actions was acquiring a computer certificate from one of the corporate utility CAs.

The initial CA implementation to support IPsec had two utility CAs per forest that were issuing IPsec certificates to client computers. When Microsoft IT upgraded the CA infrastructure to Windows Server 2008 R2, it took advantage of cross-forest enrollment and began issuing all IPsec certificates from four utility CAs in the primary corporate forest. All CAs that issue IPsec certificates are signed under the Microsoft Corporate Root CA.

Microsoft IT set the templates used for configuring the issuance of IPsec certificates to automatically enroll, which helped streamline the issuance process. If, for any reason, the client failed to automatically obtain an IPsec certificate when trying to connect via remote access (Connection Manager), the client had an option to manually acquire such a certificate by using the CAs' web enrollment pages. To allow that, however, Microsoft IT had to ensure


that the issuing CA servers themselves would allow non-IPsec traffic; as a result, the servers were configured as IPsec boundary computers. Microsoft IT then published an IPsec Offline template on each of the utility CAs so that non-IPsec configured hosts could enroll for an IPsec certificate via the webpages.

EFSEFS is a component of the NTFS file system. It enables transparent encryption and decryption of files by using advanced, standard cryptographic algorithms. Any individual or program that does not have the appropriate cryptographic key cannot read the encrypted data. Encrypted files can be protected even from those who gain physical possession of the computer that contains the files. Even persons who are authorized to access the computer and its file system cannot view the data.

Microsoft IT enabled EFS via automatically enrolled certificate templates published on a utility CA that is signed by the Microsoft Corporate Root CA. Microsoft IT configured the CA with key archival to enable easy recovery of lost keys. It configured the EFS automatically enrolled templates with a one-year validity period.

S/MIMES/MIME is a technology that helps prevent impersonation and tampering with email messages. S/MIME enables users to encrypt outgoing messages and attachments so that only intended recipients who have the proper certificates and keys can read them. With S/MIME, users can also digitally sign outgoing messages. When a user digitally signs a message, he or she gives the recipient a way to verify the identity of the sender and verify that the message has not been tampered with.

Before Microsoft IT began issuing S/MIME certificates, it configured dedicated issuing CAs, enabled them for key archival, and chained them to a publicly trusted root (GTE CyberTrust Global Root). Configuring the CAs for key archival allowed for fast key recovery in the case of lost keys. Establishing a trust with a non-Microsoft entity enabled Microsoft users to easily exchange security-enhanced email with external recipients. However, the default non-Microsoft root CA policy did not include an application policy for key archival. To enable it, Microsoft IT cross-certified its own intermediate CA that included such an application policy with the GTE CyberTrust Global Root, which in turn allowed that function.

The current Microsoft implementation of S/MIME includes storing encryption and digital signature certificates on a smart card. Employees can use any workstation equipped with a smart card reader to send and receive S/MIME-enabled email.

Because the usage requirements and management practices for digital signature were going to be slightly different from that of encryption, Microsoft IT decided to create two separate templates. Table 2 shows the differences that led to that decision.

Table 2. Differences Between Digital Signature and Encryption

Consideration Digital signature Encryption

Validity period One year Two years to minimize the number of encryption keys to maintain and recover

Archival Not required Required for the purposes of key recovery


Number of keys Unlimited Controlled for ease of recovery and directory consistency

Microsoft IT chose to allow authorized users to automatically enroll for digital signature certificates at any time because there was no need to archive them, and updates to a digital signature certificate are relatively transparent to S/MIME senders and receivers.

However, to simplify the recovery process, Microsoft IT decided to have a controlled deployment of encryption certificates. As such, Microsoft IT restricted automatic enrollment to specific security groups. Such an approach also provided the opportunity for users to "opt in" to the use of S/MIME encryption, in addition to reducing additional support costs that would otherwise be associated with a large-scale deployment of S/MIME encryption. Microsoft IT used Microsoft Forefront Identity Manager (FIM) to manage the group that allows controlled enrollment of S/MIME encryption certificates.

Key Archival and RecoveryAs previously mentioned, both EFS and S/MIME can use key archival. Private-key recovery does not recover any data or messages; it provides only recovery of lost or damaged keys. Often, keys must be recovered before encrypted data can be recovered.

One of the advantages of key recovery over data recovery is the savings recouped in support costs. For example, without key archival, if an EFS user encrypts a folder that contains 5 gigabytes (GB) of data on his or her local workstation and subsequently loses the private key, support teams must go through a laborious process of data recovery. This process may include:

1. Backing up the locally encrypted data.

2. Transporting the backup to a recovery workstation.

3. Restoring the encrypted data onto a support technician's recovery computer.

4. Decrypting the data.

5. Creating a new backup set of the decrypted data.

6. Providing the data back to the user on a read-only network share.

7. Having the user restore and re-encrypt the data for his or her own use.

Alternatively, due to the costs involved, decisions on when to spend limited support resources on such tasks might prohibit the data recovery effort except in critical cases, thereby depriving some users of access to their lost data.

With key archival, support staff must restore only the user's private key to enable the user to decrypt his or her own data at will. Key archival and recovery benefits the user by improving support services and speeding access to the encrypted data, while reducing support costs for the enterprise. Additionally, the recovery agent does not need to have direct access to the encrypted material, providing an even greater level of security for confidential business data.

Key Recovery AgentsOnly users with specific rights can perform key recovery. When user keys are archived, they are encrypted with the key recovery agent's public key and stored in the CA database. The


people who hold the key recovery agent certificate may be separate from those who are able to retrieve the encrypted blob from the CA. As a result, the people authorized to retrieve archived key blob from the CA database may not possess the key recovery agent certificate and key needed to decrypt the blob. Those who do possess the key recovery agent certificate and key may not have access to the CA database. In this scenario, to recover a lost key, multiple people from different groups must be involved in the process.

To provide further security of the highly sensitive key recovery agent certificate and private key, Microsoft IT uses a HSM to store and help protect this key on recovery workstations. In this scenario, each designated key recovery agent has a HSM installed on his or her workstation. Access to the recovery agent key requires this module.

DependenciesSeveral dependencies are required for an organization to take advantage of key archival and recovery:

Key archival can be enabled only on version 2 or version 3 templates.

Key archival and recovery can be performed only on Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition, Windows Server 2008 Enterprise, Windows Server 2008 Datacenter, Windows Server 2008 R2 Enterprise, or Windows Server 2008 R2 Datacenter software running Certificate Services/AD CS.

The CSP that is used to generate the key must be able to export the key. For example, the Microsoft CSP that Microsoft IT uses with its smart card infrastructure is capable of a one-time export of its private key, for the purpose of key archival. Most smart card CSPs, however, cannot export private keys and rely on keys being created elsewhere and imported securely to the smart card.

Note: For more information about the key archival and recovery process, refer to the white paper "Key Archival and Management in Windows Server 2008" at http://technet.microsoft.com/en-us/library/ee449489(WS.10).aspx.

SSLSSL is a protocol that provides authentication and encryption capabilities for web browsers, network devices, and other connection-related technologies.

In the past, Microsoft purchased SSL certificates from a non-Microsoft PKI provider by prepaying for a large quantity on a yearly basis. Additionally, to manage the issuance of those certificates to the end user and provide technical support, Microsoft IT had a staff of two administrators who were enrolled into the non-Microsoft SSL administration service, which also required the use of "administrator"-type SSL certificate that needed to be paid for and renewed on a periodic basis. This approach was a significant cost to the company, taking into account the large population of web servers that Microsoft IT must maintain to run the company's web based services.

As a result, Microsoft IT decided to use Certificate Services and introduce an internal PKI that would issue its own SSL certificates to Microsoft web server administrators, but at the same time provide a public root trust by chaining to a non-Microsoft root. Microsoft IT implemented an offline intermediate CA that is signed by the GTE CyberTrust Global Root. The intermediate CA signs an enterprise issuing CA that is dedicated to SSL. Today, the SSL CA


http://technet.microsoft.com/en-us/library/ee449489(WS.10).aspx

issues thousands of certificates that are used both inside and outside the company, with significantly lower operational costs.

To manage the issuance of SSL certificates, Microsoft IT collaborated with an internal development team and created a custom registration authority tool that is now being used to service internal SSL consumers. All SSL certificate requests must go through this tool; no direct enrollment is allowed. The CA has been configured to allow only enrollment requests that originate from the registration authority tool. The enrollment interface enforces the business rules (as determined by Microsoft) that support its ability to continue to be chained under a publically trusted root.

Before a user can request an SSL certificate through the tool, he or she must obtain an authorization for the site. The authorization process ensures that a valid business justification is presented and all proper approval is received before any further action can be taken. After that has been accomplished, the user can successfully start submitting his or her certificate requests via the tool. Only requests for the approved domain name will be allowed; requests for any additional sites must follow the same process as described previously.

Another key feature that the internal registration authority application provides is a service that notifies a distribution list (provided by the requestor and required for enrollment) 30 days, 7 days, and 1 day before the certificate expiration date. This functionality helps prevents service interruptions by enabling timely renewals.

WirelessWireless networking enables users to easily access resources on a corporate network without having to maintain a physical network connection. To provide secure authentication to company resources, a proper authentication mechanism must be put in place. Microsoft IT implemented a combination of 802.1X authentication with certificates and EAP-TLS.

Microsoft IT chose to enforce the use of both user and computer certificates for 802.1X authentication. When a computer comes online and attempts to access the network in order to log on to the domain, it must present a valid computer certificate. When it does so, the authentication request is processed, and if successful, the computer is connected to the network. After the computer is connected to the network, the normal computer authentication occurs, and normal processes such as Group Policy updates can occur. By the time the computer authentication has occurred, the system is ready for user logon. The process of authenticating the computer and obtaining network access prior to user logon enables the user to perform an online interactive logon, as opposed using cached credentials.

After the user successfully logs onto the computer, a short delay occurs before the system attempts the 802.1X user authentication. The system attempts to perform an 802.1X authentication, by using the user certificate, similar to the one performed via the computer certificate. If the authentication attempt fails, the wireless network access is dropped. If it succeeds, the system remains on the network.

To enable user-based and machine-based certificate authentication, Microsoft IT relied on the deployment of the existing utility CAs, which enabled automatic enrollment for domain-member, authenticated users and computers. Because the certificate provisioning process was automated, successful enrollment required no additional action. User and computer certificates used for wireless are issued out of three utility CAs in the primary corporate


forest. By using cross-forest enrollment capabilities in Windows Server 2008 R2, the CAs can service users and computers in other domains where a trust exists.

NAPNAP is a technology introduced in the Windows Vista and Windows Server 2008 operating systems. It includes client and server components that enable administrators to create and enforce policies that define the required software and system configurations for computers that connect to the corporate network. NAP enforces client health by inspecting and assessing client computers, limiting network access when client computers are deemed noncompliant, and remediating noncompliant client computers for unlimited network access.

Some of the enforcement combinations include:

NAP with IPsec enforcement (Microsoft IT implementation)

NAP with 802.1X enforcement

NAP with VPN enforcement

NAP with Dynamic Host Configuration Protocol (DHCP) enforcement

NAP-NAC (Network Admission Control) enforcement

A NAP implementation usually consists of the following components: NAP clients, a NAP enforcement point, and a NAP health policy server (a server that is running Network Policy Server [NPS]). Additionally, NAP with IPsec-specific enforcement requires a CA server and a Health Registration Authority (HRA) for issuing NAP health certificates to clients in order to communicate on the IPsec-protected network.

The HRA's responsibility is to validate client credentials and forward a certificate request to the NAP CA on behalf of the client. The HRA validates certificate requests by checking with the NAP policy server to determine whether the NAP client complies with network health requirements.

NAP certificate requirements include the following:

Subject name: Supplied in the request.

Application policies: Client authentication, NAP health (custom), IPsec Internet Key Exchange (IKE).

Validity period: 72 hours with no renewal.

Enrollment access: HRA accounts only.

Availability: Inability to get a NAP certificate would keep a client off the network.

Microsoft IT implemented six CAs dedicated to issuing NAP certificates. The CAs all chain to the Microsoft Corporate Root CA and are located in the primary corporate forest. By using cross-forest enrollment in Windows Server 2008 R2, the CAs can service requests for clients across multiple forests where a trust exists. The CAs are physically located in three major Microsoft data centers around the world to provide quick issuance of NAP certificates and provide redundancy in the event of a disaster.

The reason for establishing such a short validity period, as well as no renewal value on the HRA-only certificate template, is to enforce more frequent state checks that must pass through the HRA. NAP certificate templates contain the Client Authentication application policy. For the certificates to use this policy, Microsoft IT needed to publish every NAP CA certificate to the NTAuth container of every NAP-enforced forest.


Because of the complex enrollment logic involved in evaluating various parameters on multiple enrollment requests, the NAP CAs started to exhibit much higher memory consumption compared to any other CA. Additionally, the short validity period on the NAP certificate templates triggered a significantly larger number of issued certificates. Microsoft IT took the following actions to address these concerns:

Increase the database session count on each CA to 300. This change allowed for a much larger number of requests to be processed per second.

Increase physical memory to 8 GB.

Microsoft IT found that NAP generated a large number of issued certificates. The number of certificates caused the CA database to get very large, which in turn caused excessive disk usage. Because NAP certificates are short lived and there is no need for revocation, there is no need to maintain records of issued NAP certificates. With an upgrade of the NAP CAs to Windows Server 2008 R2, Microsoft IT was able to implement the "databaseless CA" feature that allowed NAP certificates to not be tracked in the internal CA database. Instead of performing database clean-up tasks after thousands of certificates have already been issued, this feature prevents the certificate from entering the Issued Certificates database altogether—after it is enabled on the CA (running Windows Server 2008 R2) and a specific template (configured via Windows Server 2008 R2 or Windows 7).


PRODUCT UPDATES AND ASSOCIATED INFRASTRUCTURE CHANGESWindows Server 2008 and Windows Server 2008 R2 have introduced certificate service–related enhancements, including the following:

Windows Server 2008:

Improved enrollment capabilities that enable delegated enrollment agents to be assigned on a per-template basis

Enhanced performance monitoring with the addition of new performance counters

Scalable, high-speed revocation status response services that combine CRLs and integrated Online Responder services

Support for Cryptography Next Generation (CNG) to enable the use of Suite B algorithms

Enhanced service monitoring with the introduction of the Windows Server 2008 AD CS Management Pack for Microsoft Operations Manager 2005

More detailed server administration with restricted certificate managers

Failover cluster support

Windows Server 2008 R2:

Cross-forest enrollment capability that allows for consolidation of existing hardware

Databaseless CA feature to avoid storing unnecessary certificate records

Best Practice Analyzer for improved configuration practices

Web-based certificate enrollment protocol to allow enrollment over the Internet

Cross-Forest Enrollment and Server ConsolidationPerhaps one of the biggest challenges in managing a multiple-forest PKI is the necessity to mirror the original configuration to the other supported forests, due to the lack of cross-forest enrollment functionality. Such a limitation has always equated to duplicated administrative efforts and additional hardware cost. Windows Server 2008 R2 addresses these challenges with the introduction of cross-forest enrollment.

Cross-forest enrollment now available in Windows Server 2008 R2 helps organizations consolidate their infrastructure by enabling users and computers from forests B, C, and D to enroll from a CA server in forest A. That is accomplished by copying the necessary AD DS objects from forest A (resource forest) to forest B (account forest) and enabling referral on the Windows Server 2008 R2 CA.

In March 2009, Microsoft IT began updating its infrastructure by enabling cross-forest enrollment for many of its internally consumed services, including NAP, wireless, and IPsec. In preparation for this important milestone, Microsoft IT did not renew the CA certificates for the CAs that were designated for retirement in the account forests. Microsoft IT will continue to maintain the CRLs for the remainder of the old CA certificates' lifetime, and will retire the CAs after those certificates expire. Figure 3 shows the forest view of the Microsoft IT PKI after the implementation of cross-forest enrollment.


Figure 3. Issuing CAs by forest

Geographically Disbursed PKIThe introduction of NAP and its requirements for very short-lived certificates and reliance on almost instantaneous enrollment abilities produced the need for not only multiple CAs to ensure service availability, but also—for the first time in Microsoft IT history—to host issuing CAs in remote locations, in closer proximity to the client. As a result, Microsoft IT collaborated with its international data-center management teams and built secure locations to host NAP CAs at international data centers. Microsoft IT then negotiated special security procedures with remote teams to ensure those CAs, which were no longer physically maintained by the Microsoft IT PKI staff, remained compliant with the high security requirements for the rest of the infrastructure.

Because the remote CAs were no longer in physical care of the primary PKI staff, Microsoft IT decided to put the HSMs that help protect those CAs into separate security boundaries. This way, if those modules were compromised on the way to the remote data centers, only the keys within that boundary would be affected, and no harm would be done to the other CAs.


Due to the introduction of the previously mentioned services to the Microsoft environment, Microsoft IT needed to include additional CAs and make other changes to its hierarchy.

Figure 4 shows the infrastructure of the third-party root.

Disaster RecoveryDisaster recovery for a PKI consists mainly of the following actions:

Ensure that runtime components such as CRL distribution points and AIA locations continue to be available and up to date, and that users of existing certificates can continue to function without interruption. This includes the ability to revoke certificates as needed. This is vital for all certificate types.

Ensure that new enrollments and renewals can be processed. Depending on the usage of the certificates, this may be vital to implement immediately. In some cases, the service may be able to withstand some downtime. For example, services such as NAP cannot afford to be without new issuance, whereas smart card and S/MIME certificates may be more lenient.

Microsoft IT invested significant time in creating and validating a disaster recovery plan for the corporate PKI. Microsoft IT began the process by identifying the disaster scenarios that it needed to mitigate. Microsoft IT determined that it needed to be able to withstand a large-scale natural disaster that destroys all data residing at the primary corporate data center. To mitigate this risk and others, Microsoft IT implemented the following technical updates:

Figure 3. Issuing CAs by region


Recovery of offline CAs. Microsoft IT placed backup hardware and software on standby in a secondary data center. This includes servers and HSMs. Additionally, Microsoft IT takes regular backups of the offline CA key material and certificate databases, and then stores them at the secondary data center. HSM activation tokens are stored at a secure off-site location. Microsoft IT placed a high importance on maintaining the same high level of security at the secondary location that existed at the primary site.

Recovery of online CAs. Creation of recovery plans for online CAs varied by the type of certificates that the CA issued. NAP issuing CAs were already redundant across multiple CAs in multiple regions, and recovery plans consisted of preparing new CAs that Microsoft IT could put into service as needed to replace the lost CAs. Recovery plans for some CAs required the recovery of the existing CA from a previous backup to a new computer. Microsoft IT created a dedicated virtual machine environment by using Windows Server failover clustering and Windows Server Hyper-V to host many of the CAs in the secondary data center as virtual machines.

Temporary CRL publication. Microsoft IT implemented a dedicated computer with HSMs that can be used to resign existing CRLs as needed until a CA can be restored. This requires a copy of a CRL and the correct access tokens to initialize the HSM, along with the certificate and key data to be present on the computer. By using the certutil.exe –sign command, an administrator can resign a CRL for an extended period, allowing the enterprise to function until the CA can be fully restored. The CRL then must be manually published to the appropriate distribution locations.

It is important to note that in addition to implementing the correct technical solution to help protect the confidentiality, integrity, and availability of critical PKI services, an organization must implement the proper processes and procedures. Microsoft IT carefully implemented recovery processes that it could realistically execute in the event of a disaster, and it tested them for validity.


CA SERVER MANAGEMENT AND SUPPORTMicrosoft IT's current PKI support model includes the following tiers:

Tier 1: Microsoft Service Desk (multiple members). All user enquires originate at this tier. Technician asks users a series of questions to help direct them to the appropriate team.

Tier 2: Microsoft Global Operations team (multiple members). The Global Operations team receives escalations from the Service Desk, or sometimes from other infrastructure support teams if an issue has already been identified. This team also receives and responds to all PKI monitoring alerts. A Global Operations analyst then begins investigation and follows support articles prepared by the Microsoft IT PKI team. Even though Global Operations staff members have been provisioned with CA access, they are not PKI experts; if they receive a request that requires more in-depth knowledge of Certificate Services/AD CS, they forward the request to Tier 3 in the support model.

Tier 3: Certificate Services Operations team (four members). This team manages certificate enrollment, revocation, and recovery of Microsoft IT issued certificates. It also provides assistance with troubleshooting of specific PKI usage scenarios.

Tier 4: Certificate Services Engineering team (three members). This team manages the deployment of new cryptographic solutions, identifies shortfalls in the current infrastructure, and proposes and deploys new design changes. It also receives escalation requests from Tier 3 and helps resolve operational issues. In the case of an overly complex case or a potential software bug, the team involves the PKI product group, and then both teams work together to find and document a solution.

BackupMicrosoft IT regularly backs up its online and offline CAs. Online CAs are backed up on a daily basis via a script running as a scheduled task that copies the CA database and registry configuration to a remote location. This copy is then backed up and stored to tape. Microsoft IT decided to employ such backup practices to preserve the limited access to CA servers. This way, multiple members of the backup organization are not required to have access to the CA servers themselves; they only need to be able to access the remote location that contains the specific files necessary for backup.

Microsoft IT backs up its offline CAs every time after signing a new subordinate CA certificate request. CA database, registry information, and nCipher key protection–related files are all copied to two copies of CDs, which are then stored at two separate, secure off-site locations.

In the event of a corrupted CA, the backed-up data can be used to successfully restore the services onto a different piece of hardware with a properly configured nCipher module.

MonitoringService monitoring is critical to production operations. Microsoft IT relies on a combination of Microsoft System Center Operations Manager and a custom Certificate Services/AD CS monitoring tool to oversee the health of its PKI.

An Operations Manager implementation at Microsoft consists of a monitoring server, health agents, and a set of management packs, each specific to a particular area being monitored. Microsoft IT deployed monitoring agents to every CA in its managed environment. The agents run and perform the checks enforced by each management pack, and then report to


the management server. From there, an automatic ticketing system generates support tickets and forwards those to the Global Operations group.

The custom Certificate Services/AD CS monitoring tool runs on every CA as well. Its job is to perform Certificate Services/AD CS-specific checks, including verifying that the service is running, the CRL publication occurred on time, the CA certificate is not nearing its expiration date, and all AIA and CRL distribution point paths contain the expected data. If the tool identifies any discrepancies, it writes events into an event log. The event log triggers alerts that are generated with the help of Operations Manager.

Both the Operations Manager agent account and the service account used by the custom monitoring tool run with limited permissions on the CAs. They have read and write access to only the needed event logs, for the purpose of logging the event. This helps prevent a potential attack on the server if either of those accounts is compromised.

Software UpdatesTo make sure that the CA servers are up to date on all software updates, including fixes and security updates, Microsoft IT uses Microsoft System Center Configuration Manager 2007.

Configuration Manager includes a server and an agent component, where the agent runs on every CA and applies a set of updates based on the information that it gets from the server running Configuration Manager. To minimize impact to production operations, the agents are configured to only execute the updates and restart the server (if necessary) during off-hours. The entire process is automated, which helps avoid a potential administrative overhead.

Hardware UpgradesMicrosoft IT follows the same hardware refresh schedule that is followed by the rest of the departments within the company, which includes upgrading the hardware components approximately every five years. When a hardware upgrade is necessary, the Microsoft PKI team backs up the current server, takes it offline, and then restores the backup on the newly built server.


UPCOMING INITIATIVESMany new features are being introduced to PKI-based technologies today. Here are some key areas that Microsoft IT will focus on next:

FIM Certificate Management. The Certificate Manager feature of FIM is a centralized management system for deploying and managing certificates and smart cards. Microsoft IT is currently engaged in a Certificate Manager pilot and may implement the feature for all forests in the near future.

Additional cross-forest enrollment and hardware consolidation efforts. Microsoft IT has greatly simplified the AD CS architecture by introducing cross-forest enrollment. Efforts are underway to implement cross-forest enrollment for services that have not yet taken advantage of it.

Virtualization. With today's efforts to minimize overall infrastructure management costs, virtual server–based services are driving many deployment goals. The Microsoft PKI team is considering moving most (if not all) of its PKI servers to virtual machine–based infrastructure. As part of the initiative, network-based HSMs would become the primary key storage mechanisms. However, the Microsoft PKI team knows that it must take special care to account for the additional security concerns of running in a virtual environment.

Following key management standards—migrating from 1,024-bit RSA keys. NIST issued Special Publication 800-57, Recommendation for Key Management, which advises that 1024-bit RSA keys would no longer be viable after December 31, 2010. Microsoft IT has begun migration to 2,048-bit RSA keys for several certificate types.

Following cryptographic standards—migrating from SHA-1 to SHA-256. NIST Special Publication 800-57 also advises a transition from SHA-1 to SHA-256 as the hash algorithm used for digital signatures for Certificate Authorities. Microsoft IT has begun the planning and design process to update the infrastructure with CAs that use SHA-256 and that will not disrupt the current PKI.

For more information about the key migration standards, refer to the publication at http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_PART3_key-management_Dec2009.pdf.


http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_PART3_key-management_Dec2009.pdf

http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_PART3_key-management_Dec2009.pdf

LESSONS LEARNED AND BEST PRACTICESBy thoroughly evaluating detailed service requirements and future growth potential, Microsoft IT learned several valuable lessons that can be applied as best practices in most other PKI deployment plans. Microsoft IT learned many of the lessons during the deployment and some of the lessons as outcomes of the deployment.

Plan for Future Upgrades to the Windows Server PKIIf upgrading from Windows Server 2000 Server to obtain all the benefits associated with the Windows Server 2003 or Windows Server 2008 PKI, the AD DS schema must be extended at least to the version provided with Windows Server 2003. Additionally, client computers should be running Windows XP Professional or Windows Vista.

The first step in preparing for the upgrade is to plan for the schema extension. An organization must run Adprep.exe with the /ForestPrep command-line switch to extend the schema before any other work commences.

Carefully Consider the Number of CA Servers NeededAn organization should be realistic about the number of CAs that it needs to deploy. When an organization uses AD CS, it does not need to create separate CAs for different applications. Each CA can issue all the certificates that are in use in that forest.

Microsoft IT realized that the number of CAs deployed in the original plans created unnecessary administrative complications and overhead. Decommissioning some underused CAs and consolidating their certificate templates to other CAs proved to have no effect on performance, but yielded significant savings in server hardware and ongoing maintenance. In situations where enrollment services are critical, Microsoft IT employs multiple CAs, configured identically, to provide failover redundancy.

Consider Integration with a Public RootAn organization should consider how it will address the issue of root trust for public-facing PKI-enabled services. Implementing only a self-signed root CA will not provide root trust for users outside the bounds of a network environment. Depending on an organization's needs and the scope of its deployment, there are two primary ways that an organization can address this problem: It can either purchase individual certificates as needed or subordinate its own CA under a publicly trusted root.

Microsoft IT implemented a new offline intermediate CA that chains to the publicly trusted GTE CyberTrust Root and GTE CyberTrust Global Root. The offline intermediate CA subordinates multiple issuing CAs, which can issue both SSL and S/MIME certificates. Purchasing the necessary SSL certificates through an organization outside Microsoft represented a significant cost for Microsoft. With the use of the new, publicly trusted infrastructure, Microsoft IT's internal PKI realizes significant savings. Microsoft IT pays an annual fee for subordination to a publicly trusted root and can issue an unlimited number of certificates, rather than paying for each certificate issued. Additionally, Microsoft increased its control over the certificate issuance process by handling the issuance of all end-entity certificates internally.


Automate CRL PublicationThe availability of valid CRLs is crucial for uninterrupted operation by PKI-enabled services and applications. Automating CRL publication to external locations can be challenging because most enterprises do not connect their public-facing web servers directly to corporate network resources. There are typically firewalls and perimeter networks that isolate publicly accessed servers from other servers.

Windows Server 2003 CAs can be configured to automatically write new CRL files to shares on other servers, whereas Windows 2000 Server requires separate procedures to perform this function. This improvement enabled Microsoft IT to reduce its external CRL publication intervals from once a week to once every 24 hours for such time-sensitive certificates as those used for smart card remote access logons. Microsoft IT CAs now write their CRL material directly to a specific drop point. A periodic synchronization routine automatically runs, accesses the data on the drop point, and makes the data available on the externally facing web servers in a timely manner.

Customize the CRL Publication Overlap IntervalThe overlap between the time when a new CRL is issued and the time when an old CRL expires needs to be managed. With CRL publication in AD DS, replication time must be considered. Microsoft IT needed to provide sufficient time for replication of the newly published CRL before the old CRL expired and would no longer be valid for certificate validation purposes. Additionally, with external HTTP URLs, Microsoft IT needed enough time to provide for manual publication of newly issued CRLs to these points.

For detailed information about defining CRL publication overlap, refer to the white paper "Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure" at http://technet.microsoft.com/en-us/library/cc739695(WS.10).aspx.

Use New Keys for CA RenewalMicrosoft IT recommends renewing CA certificates by using new keys rather than reusing the old keys. Using new keys for CA renewal reduces the likelihood of having any ambiguous or improper certificate chains in the hierarchy.

Using existing keys for certificate renewal may cause certificate chains to link to either the old or the new CA certificate, creating ambiguous certificate chains. However, if an organization uses a new key during CA certificate renewal, the certificate chains down the line will use only the new key, thereby eliminating any ambiguity.

Using a new key does not break the chains created for end-entity certificates issued under the old CA certificate. Previously issued certificates will continue to chain to the appropriate CA certificate. However, multiple keys require multiple CRLs. During revocation checking, a CRL must be signed by the same key used to sign the end-entity certificate. As a result of using new keys for CA renewal, the CA must issue a CRL for each valid key to help ensure the validity of the certificates issued. Because of the importance of CRL availability in successfully managing the issuance of new keys for CA renewal, an organization should plan its CRL propagation strategy carefully.

Multiple CRL files and CA certificate files are typically differentiated through the addition of a key version suffix to the file name. For this reason, Microsoft IT recommends using the appropriate variable when defining CRL distribution point and AIA extensions.


http://technet.microsoft.com/en-us/library/cc739695(WS.10).aspx

Plan for Certificate Issuance PoliciesThe Windows Server 2003 or Windows Server 2008 PKI includes certificate policies and application policies (extended key usage (EKU) in Windows 2000 Server). Each type of policy has its own unique object identifier (OID) values. These OID values are written into corresponding extensions within the certificate. For a certificate to be valid for any specific purpose, the appropriate OID for that purpose must be present within the appropriate policy extension. For example, for an end-entity certificate to be valid for EFS usage, the EFS OID value must be present in the application policy extension for every certificate in the chain.

By default, a root CA certificate is valid for all application policies and all certificate policies. However, by default, subordinate CAs are valid only for all application policies. By using the value of "all" for these policies, every application or issuance policy OID, whether recognized or not, is considered valid. However, specifying any individual policy OID overrides the "all" value. When the "all" value is overridden, a particular policy must be explicitly defined in the policy to be considered valid.

Initially, Microsoft IT did not anticipate using issuance policies. Shortly after the initial deployment process, Microsoft IT planned to include an issuer statement in the root certificate. This statement included a space within the certificate for embedding legal disclaimers or other items of reference, and it included a hyperlink to the Microsoft Certification Practice Statement CPS. The CA interpreted the inclusion of the issuer statement as an issuance policy, which thereby invalidated all other possible issuance policies. Initially, this situation was not a problem. However, when Microsoft IT decided to accommodate the potential use of issuance polices in its issuing CAs, it attempted to renew the intermediate certificates and include the All Issuance Policies value within them as well. Because the All Issuance Policies value had been overridden in the root certificate with the inclusion of the issuance statement, the effective issuance policies in the intermediate CA certificates were then restricted to only the issuance statement policy.

To re-enable the All Issuance Policies functionality, Microsoft IT had to renew the root certificate. To provide this functionality, in addition to the desired issuer statement, Microsoft IT needed to modify the Capolicy.inf file to include the specific All Issuance Policies OID along with the appropriate information for the issuer statement. Microsoft IT then repeated this configuration by renewing each of the offline intermediate CAs to match the "all" functionality of the root. The online enterprise subordinate CAs, however, have no issuance policies defined, thus limiting the use of any issuance policies in certificates that they issue. If ever required in the future, Microsoft IT can easily implement needed policies by simply renewing the issuing CA certificate and including the policies.

Microsoft IT recommends that all deployments of PKI that incorporate the use of subordinate CAs should plan for the use of issuance policies. Planning for issuance policies forces the consideration of which specific enhanced key usage and issuance policies an organization will enable when it deploys a CA. Alternatively, security administrators can change the default settings for issuance policies on the subordinate CAs to match the root. In either case, consideration of this factor at the planning stage of a deployment will eliminate the need to renew the certificate chain from the root down every time an organization needs a new enhanced key usage or issuance policy.


For more information about setting policies in the Capolicy.inf file, refer to the white paper "Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure" at http://technet.microsoft.com/en-us/library/cc739695(WS.10).aspx.

Sanitize Elements of the PKIMicrosoft IT discovered that issued certificates might contain potentially sensitive information about the Microsoft infrastructure. By default, LDAP paths explicitly defining the Microsoft AD DS structure were stored in the CRL distribution point and AIA extensions. Microsoft IT chose to remove this information from its CA and end-entity certificates for reasons of corporate confidentiality.

Enterprises concerned with the security of their AD DS structures should plan to sanitize their certificates of any corporate confidential information that they do not want released externally. An organization should include contact information in the certificates only if it wants users to be able to use those channels for support. The publication of internal email addresses on the Internet can lead to customer replies and unwanted email. Official contact information is more appropriately placed in an organization's publicly released CPS documentation.

Ensure Service Availability for High-Demand ApplicationsCarefully examine the requirements of each PKI-enabled service, including the frequency at which certificates are issued, the number of such requests, and the potential impact to the service if redundancy and appropriate availability are not accounted for. An organization should configure its CAs with enough memory to process all requests and to enable the newly available features (such as Databaseless CA feature) to prevent the servers from running out of disk space.

Use Hardware Security ModulesMicrosoft IT highly recommends the use of an HSM to help secure the keys of any production CA. Software CSPs do not provide strong protection of the CA key in the event of a CA compromise and cannot enforce strong controls around key usage. When an organization is deciding whether to implement an HSM as part of a PKI, it should carefully consider the value of the information that the PKI is helping to protect.

Have a Clearly Defined PolicyBefore an organization implements a PKI, it should create a clearly defined policy that covers at a minimum:

Issuance requirements for each type of certificate.

Revocation processes.

CA key sizes and algorithms.

Physical/logical security of CAs.

High-level procedures for making changes to the PKI.

The life cycle for each published certificate template that addresses these potential events:

Issuance



Recovery

Renewal

Revocation

A framework exists for the creation of Certificate Policy and Certificate Practice Statement documents, "Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework" (http://www.ietf.org/rfc/rfc2527.txt). Not all PKIs require such formal documentation, but defining policies in the beginning can help the implementation go more smoothly.


http://www.ietf.org/rfc/rfc2527.txt

CONCLUSIONBy designing, implementing, and supporting a PKI that uses a self-signed root CA certificate for internal security needs and a separate PKI chained to a public root for enabling public-facing SSL and S/MIME requirements, Microsoft IT accomplished its goals for the Microsoft PKI implementation. Business benefits can be summarized as follows:

Increased security. Microsoft employees use cryptographic technologies and applications each day. The remote access logon to the corporate network is accomplished through smart cards. The ability to use S/MIME when exchanging email helps give senders, by means of encryption, confidence that no one other than the intended recipient can read messages. The ability to use S/MIME helps give recipients, by means of digital signatures, confidence that the contents of messages have not been altered. With the use of SSL, users of intranet and Internet websites can exchange sensitive data through an encrypted connection.

Application and service compatibility. Deploying a self-hosted Microsoft PKI enables Microsoft teams to test each new Microsoft product for compatibility and interoperability with Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 PKI services before it is released to the market.

Reduced certificate costs. Before the current infrastructure, the costs of using a non-Microsoft public CA for certificate delivery on a certificate-by-certificate basis were high. Running an internal PKI at Microsoft has reduced these costs. In addition, the new PKI model has reduced the required support infrastructure by enabling the consolidation of CA servers in each forest.

Ease of manageability. Because Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 offer PKI capability out of the box, a self-hosted PKI solution was easy to implement and is easy to manage.

Conformance to industry standards. Implementing an enterprise PKI enables Microsoft IT to use standards-based cryptographic technologies to help secure Microsoft corporate resources. These technologies include encrypted files, folders, wireless communications, email, remote network access, and web server connections.

Reduced overall infrastructure management cost. By enabling cross-forest enrollment and consolidating physical hardware, companies can cut significant costs associated with the management of multiple CAs scattered across multiple forests.


FOR MORE INFORMATIONFor more information about PKI, refer to the following sources.

White papers:

"Key Archival and Management in Windows Server 2008"http://technet.microsoft.com/en-us/library/ee449489(WS.10).aspx

"Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure"http://technet.microsoft.com/en-us/library/cc739695(WS.10).aspx

Websites:

Windows Server 2008 R2 AD CShttp://technet.microsoft.com/en-us/windowsserver/dd448615

Federal Information Processing Standardshttp://csrc.nist.gov/publication s /fips/

National Institute of Standards and Technology Federal PKIhttp://csrc.nist.gov/p k i/

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Microsoft grants you the right to reproduce this White Paper, in whole or in part, specifically and solely for the purpose of personal education.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.

© 2011 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, Forefront, Hyper-V, Windows, Windows Azure, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.


http://www.microsoft.com/technet/itshowcase

http://www.microsoft.com/

http://csrc.nist.gov/pki/

http://csrc.nist.gov/publications/fips/

http://technet.microsoft.com/en-us/windowsserver/dd448615


http://technet.microsoft.com/en-us/library/ee449489(WS.10).aspx

IT Showcase: Deploying and Managing PKI Inside Microsoft...

Documents

Transcript of IT Showcase: Deploying and Managing PKI Inside Microsoft...