PKI Microsoft Deploy and Manage

Deploying and Managing PKI Inside Microsoft

Deploying and Managing PKI inside Microsoft

Technical White Paper Published: February 2005; updated June 2009


CONTENTS

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

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

Initial PKI Deployment ........................................................................................................ 6 Changes to the Multi-Tier Structure 8

Security Requirements 9

Protection of CA Private Keys ........................................................................................ 10

Physical Security ............................................................................................................ 11

Network, Server, and Directory Security ........................................................................ 12

Policy Controls ............................................................................................................... 12

CRL and AIA Considerations ......................................................................................... 12

CRL Publication ............................................................................................................. 13

CRL Lifetime .................................................................................................................. 14

PKI-Enabled Services 14

Smart Cards for Remote Access .................................................................................... 15

Delegated Issuance ....................................................................................................... 16

Smart-Card Renewal ...................................................................................................... 16

IPsec 17

EFS 17

S/MIME 18

Key Archival and Recovery 19

Key Recovery Agents ..................................................................................................... 19

Dependencies ................................................................................................................ 20

SSL 20

Wireless 21

Product Updates and Associated Infrastructure Changes 21

NAP and Databaseless CA implementation ................................................................... 22

Cross-Forest Enrollment and Server Consolidation 23

Geographically Disbursed PKI 24

CA Server Management and Support ................................................................................ 26 Backup 26

Monitoring 26


Software Updates 27

Hardware Upgrades 27

Upcoming Initiatives ........................................................................................................... 28

Lessons Learned and Best Practices ................................................................................ 29 Plan for Future Upgrades to the Windows Server PKI 29

Carefully Consider the Number of CA Servers Needed 29

Consider Integration with a Public Root 29

Automate CRL Publication 30

Customize the CRL Publication Overlap Interval 30

Use New Keys for CA Renewal 30

Plan for Certificate Issuance Policies 31

Sanitize Elements of the PKI 32

Ensure Service Availability for High-Demand Applications 32

Conclusion ........................................................................................................................... 33

For More Information .......................................................................................................... 34


EXECUTIVE SUMMARY

Many 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 e-mail.

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, third-party

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® 2003, 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 May 2009, 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.

Situation

Microsoft IT needed a platform to help

secure network communications, help

protect data (both at rest and in

transit), and certify internal code.

Solution

Microsoft 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 e-mail

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 2003

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


INTRODUCTION

The 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 (a process

commonly referred to as ―dogfooding‖), 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 2003, 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 DEPLOYMENT

The 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. Hierarchy of the initial primary PKI design with Microsoft® Windows® 2000

Server

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 as a 16-year CA certificate lifetime, a 4,096-bit key

length, 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, by using 2,048-bit

keys. The CRL publication interval on the issuing CAs varied, depending on the function of

the certificates being issued.

End-entity certificates are 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 need to be renewed annually. The issuing CAs can thus

continue to issue end-entity certificates that will be valid for their full, intended one-year

validity period.


Changes to the Multi-Tier Structure

The 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 used to purchase individual

certificates for SSL-enabled Web sites that non-Microsoft personnel were intended to access.

Microsoft IT purchased these certificates from a publicly trusted, third-party 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 third-party

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 been shipped as trusted roots in Microsoft operating systems and a variety

of third-party operating systems. The GTE CyberTrust roots provide the ubiquity that

Microsoft needed to satisfy its public trust needs for both SSL and S/MIME.

With this new model, the third-party provider handled all of the issuance and revocation

needs for the new intermediate CA. Microsoft IT staff continued 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. Modified hierarchy

Security Requirements

Even though Microsoft internal hierarchy no longer had the previous intermediate CAs,

Microsoft IT did not lower any of the existing security controls. The root and the new

intermediate CA were offline and never exposed to network traffic, thereby minimizing the

chance of a compromise. Because these CAs were offline, Microsoft IT security staff

manually issued and published their certificates (through a portable medium) to Active

Directory. Additionally, the security staff issued certificates to all online enterprise CAs in the

appropriate Active Directory forest by manually copying certificate request files from the

online servers to the offline roots and intermediate. The security staff used portable media to

transport the certificates between servers. The requests were processed, and security staff

transferred the issued certificates from the offline CA back to the online server 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 protect the CA.

Offline root (and subordinate) CAs usually need higher levels of protection than issuing CAs.

Certificate Services in Windows Server 2003—the feature called Active Directory Certificate

Services (AD CS) in Windows Server 2008 and Windows Server 2008 R2—shipped with a

software cryptographic service provider (CSP) that complied with the Level-1 requirements of


Federal Information Processing Standard (FIPS) 140-1. To provide stronger protection of the

CA‘s private keys, Microsoft IT installed Hardware Security Modules (HSMs) on each CA

server. The modules were certified to FIPS 140-1, Level-2 and Level-3. Microsoft IT

determined that it needed to raise the security level of the offline root to FIPS 140-1, Level-3.

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 Web site at

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

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 Keys

The operating system manages the private-key pairs 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-1 Level-1 security risk, which an organization can mitigate by providing

more difficult and verifiable physical access to the Windows Server CA system.

Microsoft IT chose to mitigate the risk associated with private key storage by using HSMs in

all deployed CAs. 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. Microsoft IT decided to use the nCipher nShield HSM because:

It provides interaction with CryptoAPI.

It provides the FIPS 140-2 Level-2 and Level-3 validated security certifications that

Microsoft IT required for its security standards.

The nCipher nShield modules are certified for FIPS 140-1 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 used an HSM configured in

FIPS 140-1 Level-3 mode.

Each nShield HSM contains an integrated smart-card reader. When configuring the nCipher

HSMs, Microsoft IT created security worlds with administrative card sets, most composed of

six smart cards, any three of which were required to perform administrative functions. A

security world is a concept encompassing secure key protection practices, which can be

certified according to the Federal Information Processing Standards (FIPS) standards

Microsoft IT needed the administrative cards whenever it brought a new CA online and added

it to the associated security world. The Legal and Corporate Affairs department received two

cards, the Corporate Security team retained two others, and Microsoft IT stored the final two

at an offsite facility as a backup. The requirement of three smart cards for signing operations

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


provided role separation and guaranteed that performing such high-level functions required

the involvement of members from more than one group.

Microsoft IT adhered to the following model when creating nCipher security worlds for various

levels of the hierarchy:

A root security world for the offline corporate root CA

A policy security world for the offline intermediate CA

An issuing security world containing all online issuing CAs

The security worlds provided a distinction between the various CAs and administration

activities. By separating the issuing security world from the offline security worlds, and by

using the principle of least privilege, Microsoft IT obtained a greater level of assurance.

In addition to the security worlds and the administrative cards, the HSM configuration used

an operator smart card to help protect the private keys for each of the offline CAs. The

Corporate Security team holds these cards. Because the Corporate Security team does not

have access to the physical location of the servers, it had to cooperate with Microsoft IT

whenever it needed access to these servers‘ private keys. Originally, the operator cards for

the online issuing CAs remained inserted into the nShield modules because they were

needed each time a CA‘s key was accessed. However, Microsoft IT decided to change that

model and migrated to the module protection type instead, because leaving an operator card

inside the module is essentially the same as having the module protect the keys itself.

This level of security, in combination with stringent physical access, helped maintain a high

level of assurance regarding the use of these CAs.

Physical Security

A Microsoft IT-controlled vault houses the offline CAs. Without network connectivity,

certificate signing and revocation are manual processes that require physical access to the

vault.

Entrance into the vault requires at least two authorized people at a time, and only people who

have been approved by Corporate Security can enter the vault. Entry into the vault is further

controlled through multiple security requirements, including the combined use of building

access cards, biometrics, and personal identification numbers (PINs). In addition, one of the

persons entering the vault must be one of two specifically designated employees with

knowledge of the code needed to disarm the security alarm inside the vault.

Furthermore, the Microsoft Security Control Center monitors all vault entries and the alarm

status. By policy, the Security Control Center must be notified of any vault entry and provided

with the identities of the individuals making the entry. If the Security Control Center does not

receive a notification, it investigates any detected entry into the vault as suspicious.

Originally, the Microsoft IT vault housed the online issuing CAs as well. However, to provide

a more effective server and service management, Microsoft IT decided to move all of the

issuing CAs to a data center with the rest of the company‘s server infrastructure, but place

the CA computers into a separate security cage that employs a series of stringent security

controls for higher protection. CA cage access is restricted to a limited number of data-center

support personnel, and it requires the use of biometrics in addition to card keys. Inside the

cage, the rack that holds the CAs is protected with an alarm system that must be disarmed

by a minimum of two authorized individuals who must swipe their card keys. Finally, all


activities in the cage are monitored by video surveillance in addition to physical security staff

in the data center.

Network, Server, and Directory Security

Access control list (ACL) permissions control enrollment permissions on both the CA servers

and the certificate templates in Active Directory. 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 Active Directory containers controlled by ACLs. These

containers are part of the Active Directory 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 can be 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.

Policy Controls

In 2007, a new PKI Policy Committee was formed at Microsoft. It consisted of members of

the Legal and Corporate Affairs department, the Corporate Security team, the PKI product

group, and senior researchers in the area of cryptography. Additionally, the committee

published a new document about PKI standards; this document required the committee to

review and approved all proposed changes to the Microsoft IT PKI. Such changes include

creating a new CA, modifying template permissions, and provisioning new access. This extra

layer of control helps ensure that all Microsoft IT PKI operations match all corporate and

government policies, in addition to the overall Microsoft direction in the Certificate Services

arena.

CRL and AIA Considerations

During the installation and configuration of Certificate Services, Microsoft IT configured each

of the following:

Publication of offline CAs to Active Directory. Microsoft IT published the offline root

and subordinate CAs to Active Directory through certutil.exe. Microsoft IT published the

root certificate directly to the Certification Authorities and Authority Information Access

(AIA) containers of Active Directory. 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 Active Directory, Microsoft IT pushed it to all enterprise clients—in

multiple domains throughout the forest—in one process.

Microsoft IT also originally published the offline intermediate CAs' 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

the templates that it wanted.

CRL distribution point. The CRL distribution point 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 included in the offline root certificate by creating a

Capolicy.inf file and defining the paths that it wanted. Configuration of this extension in

Certificate Services after installation then defined which URLs would be included in the

certificates that the root CA issued.

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 Capolicy.inf the information that would be written into the root certificate. Configuration

of this extension in Certificate Services after installation then defined which URLs would

be included in the certificates that the root CA issued.

CRL Publication

When 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.


CRL Lifetime

Microsoft IT configured different CAs to have different CRL publication intervals, depending

on how the certificates that the CAs issued were being used. For example, Microsoft IT

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

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 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 vault 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.

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 Services

Microsoft 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 e-mail 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 Remote Access

A 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.

Smart cards must support authentication and authorization: The cardholder is authenticated

through the PIN, and can be authorized to access only a particular range of data on the card,

or carry out a particular range of activities with the card. A key feature of smart cards is that

they provide security-enhanced storage for data; one important component of such storage is

smart-card logon certificates.

The combined use of the smart cards and Extensible Authentication Protocol (EAP)/TLS

enables a much stronger authentication mechanism over the standard approach of entering a

user name and password.

The smart-card solution initially took advantage of technologies found in the Windows 2000

Server infrastructure, including Certificate Services, Routing and Remote Access, and

Internet Authentication Service (IAS). The smart-card solution was enhanced when Microsoft

IT upgraded to Windows Server 2003. The PKI enhancements to Windows Server 2003 and

Windows Server 2008 enabled Microsoft IT to better manage certificate enrollment and

renewals, as well as delegate the process of creating and distributing smart cards.

To 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 are 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.

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 Issuance

Microsoft IT did not want to allow users to simply enroll themselves for smart cards. 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, the plan was for Microsoft IT staff (located in Redmond,

Washington) 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

cover the issuance of smart cards to users on a regional basis. Microsoft IT decided to use

the delegated issuance model to support smart cards after the initial deployment.

The implementation of the 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 Renewal

The Microsoft IT team also took advantage of the flexibility of PKI features in Windows

Server 2003 and Windows Server 2008 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.


.

IPsec

IPsec 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.

Microsoft IT provided two utility CAs (per forest) that were issuing IPsec certificates to client

computers. Microsoft IT set the templates used for configuring the issuance of IPsec

certificates to autoenroll, 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 Web pages.

For more information about domain isolation via IPsec, refer to the IT Showcase white paper

"Improving Security with Domain Isolation" at

http://www.microsoft.com/downloads/details.aspx?FamilyID=A97DDC48-A364-4756-BB3C-

91DA274118FE&displaylang=en

EFS

EFS 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 auto enrolled certificate templates published on two utility CAs

(in each supported forest) that are signed by the Microsoft Corporate Root CA. Microsoft IT

configured the two CAs with key archival to enable easy recovery of lost keys. It configured

the EFS auto enrolled templates with a one-year validity period.


S/MIME

S/MIME is a technology that helps prevent impersonation and tampering with e-mail

messages. S/MIME enables users to encrypt outgoing messages and attachments so that

only intended recipients who have proper S/MIME certificates 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.

The current Microsoft implementation of S/MIME includes storing encryption and digital

signature certificates on smart cards. Employees can use any workstation equipped with a

smart-card reader to send and receive S/MIME-enabled e-mail.

Before Microsoft IT started issuing S/MIME certificates, it configured a dedicated issuing CA,

enabled it for key archival, and chained that CA up to a publicly trusted root (GTE CyberTrust

Global Root). Configuring the CA for key archival allowed for fast key recovery in the case of

lost keys, whereas establishing a third-party trust enabled Microsoft users to easily exchange

security-enhanced e-mail with external recipients. However, the default third-party root CA

policy did not include a key archival application policy. 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.

Microsoft IT now needed to publish certificate templates. 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 (just like most other

templates) seemed sufficient.

Two years was a better option

to minimize the number of

encryption keys to maintain

and recover.

Archival Was not necessary. Required for the purposes of

key recovery.

Number of keys Unlimited. Controlled for ease of

recovery.

Microsoft IT chose to allow users to auto enroll for digital signature certificates at any time

because there was no need to preserve those.

However, to simplify the recovery process, Microsoft IT decided to have a controlled

deployment of encryption certificates. As such, Microsoft IT restricted auto enrollment to

specific security groups. Such an approach also provided the opportunity for users to ―opt in‖

to the use of S/MIME, as well as reduced additional support costs that would otherwise be

associated with a global auto enrollment. As a result, Microsoft IT used a combination of an

internal group management tool called Autogroup and back-end synchronization jobs to allow

controlled enrollment of S/MIME encryption certificates.


Key Archival and Recovery

As 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

includes:

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 Agents

Only users with specific rights can perform key recovery. When keys are archived, they are

encrypted with the key recovery agent‘s public key and stored in the CA database. To

mitigate potential abuses of the key recovery process, Microsoft IT recommends using role

separation. 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 an nCipher HSM to store and help protect this key on recovery

workstations. In this scenario, each designated key recovery agent has an nCipher nShield

HSM installed on his or her workstation. Access to the recovery agent key requires this

module.


Dependencies

Several dependencies are required for an organization to take advantage of key archival and

recovery:

Key archival can be enabled only on Version 2 templates.

Key archival and recovery can be performed only on Windows Server 2003 Enterprise

Edition, Windows Server 2003 Datacenter Edition, Windows Server 2008 Enterprise, or

Windows Server 2008 Datacenter software running Certificate Services/AD CS.

The CSP 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.

For more information about the key archival and recovery process, refer to the white paper

"Key Archival and Management in Windows Server 2003" at

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/kyac

ws03.mspx.

SSL

SSL is a protocol that provides authentication and encryption capabilities for Web browsers,

network devices, and other connection-related technologies.

In the past, Microsoft purchased its SSL certificates from a third-party 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 third-party 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 posed 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 Microsoft technology—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 third-party

root. The root is the GTE CyberTrust Global Root, which Microsoft IT is currently using for

S/MIME and the SSL PKI services.

Today, the SSL CA 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 Enroll permissions to

the service account, which is used by the registration authority tool.

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

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/kyacws03.mspx



requests via the tool. Only requests for the approved URL 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 notification

service that notifies the user‘s contact distribution list (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.

The SSL CA is an enterprise CA that is dedicated to SSL certificate issuance only. It currently

chains to an offline subordinate, which then chains to the GTE CyberTrust Global Root.

Wireless

Wireless 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‘s implementation of such a mechanism was 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 autoenrollment for domain-member,

authenticated users and computers. Because the certificate provisioning process was

automated, successful enrollment required no additional action.

Product Updates and Associated Infrastructure Changes

Windows 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

Active Directory Certificate Services 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

NAP and Databaseless CA implementation

As part of Windows Server 2008 deployments, Microsoft IT added a new PKI-enabled

service—Network Access Protection—to its existing offerings. NAP 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 health

requirement 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 the health of 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*

NAP with 802.1X enforcement

NAP with VPN enforcement

NAP with Dynamic Host Configuration Protocol (DHCP) enforcement

NAP-NAC (Network Admission Control) enforcement

*Microsoft IT implementation

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

be able to communicate on the IPsec-protected network

HRA‘s responsibility is to validate client credentials and forward a certificate request to the

NAP CA on behalf of the client. HRA validates certificate requests by checking with the NAP

policy server to determine whether the NAP client is compliant with network health

requirements.

NAP certificate service requirements included the following:

Subject name: Supply 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

Because the subject name was set to Supply in the Request, Microsoft IT applied name

constraints to help further prevent unauthorized enrollment. 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 templates contain the Client Auth Application Policy. For the certificates to use the

Client Auth Application Policy , Microsoft IT needed to publish every NAP CA certificate in the

NTAUTH container of every NAP-enforced forest.

Because of the complex enrollment logic involving 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

determined to take the following actions to address these concerns:

Increase the database session count on each CA (to 120). This change allowed for

much larger number of requests to be processed per second.

Increase physical memory (to 8 GB).

As a short-term solution for the overgrowing database size, Microsoft IT enabled circular

logging, ran regular database clean-up scripts, and ran database defragmentation tasks to

preserve available disk space.

A long-term solution is use of the Databaseless CA feature in Windows Server 2008 R2.

Databaseless CA allows a CA server to not store issued certificates in its database. This

feature is especially valuable for the services like NAP where there is no requirement to

maintain records of issued certificates. 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 Beta) and a specific template (configured via Windows

Server 2008 R2 Beta or a Windows 7 client operating system).

As of this writing, Microsoft IT is upgrading all of its NAP CAs to Windows Server 2008 R2

Beta and enabling the new Databaseless CA feature on the CAs and on the templates

servicing NAP clients that are running Windows Server 2008 R2 Beta or a Windows 7 client

operating system.

Cross-Forest Enrollment and Server Consolidation

Perhaps 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 as well as hardware cost. Windows Server 2008 R2 (Beta) has finally broken those

boundaries.

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 Active


Directory objects from forest A (resource forest) to forest B (account forest) and enabling

referral on the Windows Server 2008 R2 Beta CA.

In March 2009, Microsoft IT began updating its infrastructure by enabling cross-forest

enrollment for its internally consumed services. In preparation for this important milestone,

Microsoft IT did not renew its issuing CA certificates for the services that it planned to enable

for cross-forest enrollment. Microsoft IT intends to continue to maintain the CRLs for the

remainder of the old CA certificates‘ lifetime, and will retire the CAs after those certificates

expire.

Geographically Disbursed PKI

The 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 initialize the HSMs protecting those CAs into separate security worlds. This

way, if those modules are compromised on the way to the remote data centers, only the

security world that they are part of will be affected, and no harm will 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 3 shows the revised Microsoft IT PKI hierarchy.


Figure 3. Primary Microsoft IT PKI

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

Figure 4. Existing third-party root infrastructure


CA SERVER MANAGEMENT AND SUPPORT

Microsoft IT's current PKI support model includes four 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 (two 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.

Backup

Microsoft IT regularly backs up its online and offline CAs. Online CAs are backed up on a

daily basis via an automated solution that copies the CA database, registry configuration, and

nCipher key protection–related files to a remote location, which is then backed up and stored

to tape. Microsoft IT decided to employ such backup practices to preserve the limited CA

server access. 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.

Monitoring

Service monitoring is critical to production operations. Microsoft IT relies on a combination of

Microsoft Operations Manager and a custom Certificate Services/AD CS monitoring tool to

oversee the health of its PKI.

A Microsoft Operations Manager implementation 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 generates and forwards an alert to the Global Operations

team's Microsoft Operations Manager console with the help of the Microsoft Operations

Manager agent.

Both the Microsoft Operations Manager agent account and the service account used by the

custom monitoring tool run with limited permissions on the CAs and have only read and write

access to the CAs‘ Application Event log, for the purpose of logging the event. This helps

prevent a potential attack on the server if either of those accounts is compromised.

Software Updates

To 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(MSCCM)).

MSCCM includes a server and an agent component, where the agent runs on every CA and

applies a set of updates based on the information it gets from the MSCCM server. To

minimize impact to production operations, the agents are configured to only execute the

updates restart the server (if necessary) during off hours. The entire process is automated,

which helps avoid a potential administrative overhead.

Hardware Upgrades

Microsoft 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 every

three 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 INITIATIVES

With so many new and exciting features being introduced to PKI-based technologies today,

here are some key areas that Microsoft IT will focus on next:

Microsoft Forefront™ Identity Manager Certificate Management (FIMCM). The CM

feature of Forefront Identity Manager is a centralized management system for deploying

and managing certificates and smart cards. Microsoft IT is currently engaged in an early

production deployment of CM, and plans to integrate all smart-card logon and S/MIME

certificates into CM within the next year.

Additional cross-forest enrollment and hardware consolidation efforts. Microsoft IT

is working aggressively toward consolidating its existing infrastructure. During the

consolidation process, the team is also re-evaluating the overall design and is

considering making additional changes to the infrastructure, such as moving all services

that involve archived keys to a shared set of CAs for simplified management and

administration.

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

Certificate Services Management Pack. The Windows Server 2008 Active Directory

Certificate Services Management Pack for Microsoft Operations Manager 2005 provides

a predefined set of processing rules and guidance designed specifically for monitoring

the performance and availability of the AD CS role services, including the Certification

Authority, Online Responder, and Network Device Enrollment services. Microsoft IT has

already begun using the new AD CS performance counters available in Windows

Server 2008 for enhanced performance monitoring, and is now considering evaluating

the complete new monitoring solution in its production environment.

Following key management standards—migrating from 1,024-bit RSA keys. The

U.S. National Institute of Standards and Technology issued NIST Special Publication

800-57, Recommendation for Key Management, which advises that 1024-bit RSA keys

will no longer be viable after December 31, 2010. Microsoft IT is currently working on

identifying all dependencies in addition to the migration steps.

For more information about the key migration standards, refer to the publication at

http://csrc.nist.gov/publications/drafts/800-57-part3/Draft_SP800-57-

Part3_Recommendationforkeymanagement.pdf.

http://csrc.nist.gov/publications/drafts/800-57-part3/Draft_SP800-57-Part3_Recommendationforkeymanagement.pdf

http://csrc.nist.gov/publications/drafts/800-57-part3/Draft_SP800-57-Part3_Recommendationforkeymanagement.pdf


LESSONS LEARNED AND BEST PRACTICES

By 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 PKI

If upgrading from Windows Server 2000 Server to obtain all the benefits associated with the

Windows Server 2003 or Windows Server 2008 PKI, the Active Directory 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 Needed

An organization should be realistic about the number of CAs that it needs to deploy. When an

organization uses Windows Server 2003 Certificate Services, 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 Root

An 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 a third party 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 Publication

The 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 Interval

The 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 Active Directory, 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://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3

pkibp.mspx.

Use New Keys for CA Renewal

Microsoft 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.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx



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.

Plan for Certificate Issuance Policies

The Windows Server 2003 or Windows Server 2008 PKI includes certificate policies and

application policies (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://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3

pkibp.mspx.

Sanitize Elements of the PKI

Microsoft IT discovered that issued certificates may contain potentially sensitive information

about the Microsoft infrastructure. By default, LDAP paths explicitly defining the Microsoft

Active Directory 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 Active Directory 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 e-

mail addresses on the Internet can lead to customer replies and unwanted e-mail. Official

contact information is more appropriately placed in an organization‘s publicly released CPS

documentation.

Ensure Service Availability for High-Demand Applications

Carefully examine the requirements of each PKI-enabled service, including the frequency at

which the certificates must be 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.




CONCLUSION

By 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 e-mail

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 Web sites 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 2000 Server, Windows Server 2003, and Windows Server 2008 PKI

services before it is released to the market.

Reduced certificate costs. Before the current infrastructure, the costs of using a third-

party 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, e-mail, 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 INFORMATION

For more information about PKI, refer to the following sources.

White papers:

"Key Archival and Management in Windows Server 2003"

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/sec

urity/kyacws03.mspx

"Best Practices for Implementing a Microsoft Windows Server 2003 Public Key

Infrastructure"

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/sec

urity/ws3pkibp.mspx.

Web sites:

Microsoft Public Key Infrastructure for Windows Server 2003 Technology Center

http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx

Federal Information Processing Standards

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

National Institute of Standards and Technology Federal PKI


Windows Server 2003 Security Services Technology Center

http://www.microsoft.com/windowsserver2003/technologies/security/

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, e-mail 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.

© 2009 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, Windows, Windows Server, and Windows





http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx

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


http://www.microsoft.com/windowsserver2003/technologies/security/

http://www.microsoft.com/

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


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.

PKI Microsoft Deploy and Manage

Documents

Transcript of PKI Microsoft Deploy and Manage