070-298 MSPress - Designing and Managing A Windows Public Key Infrastructure (MOC 2821A) PDF

Designing and Managing a
Windows Public Key ®
Infrastructure
Delivery Guide
Course Number: 2821A
Part Number: X09-18729

Released: 07/2003
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. 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, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
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.
 2003 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Active Directory, ActiveX,
MSDN, PowerPoint, and Windows Media 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.
Course Number: 2821A

Part Number: X09-18729
Released: 07/2003
Designing and Managing a Windows® Public Key Infrastructure iii
Contents
Introduction
Course Materials......................................................................................................2
Additional Reading from Microsoft Press...............................................................3
Prerequisites ............................................................................................................4
Course Outline.........................................................................................................5
Initial Logon Procedure ...........................................................................................7
Microsoft Official Curriculum.................................................................................8
Microsoft Certified Professional Program...............................................................9
Facilities ................................................................................................................12
Module 1: Overview of Public Key Infrastructure
Overview .................................................................................................................1
Lesson: Introduction to PKI ....................................................................................2
Lesson: Introduction to Cryptography.....................................................................7
Lesson: Certificates and Certification Authorities.................................................12
Lab A: Identifying Trusted Root CAs ...................................................................23
Module 2: Designing a Certification Authority Hierarchy
Overview .................................................................................................................1
Lesson: Identifying CA Hierarchy Design Requirements .......................................2
Lesson: Common CA Hierarchy Designs..............................................................10
Lesson: Documenting Legal Requirements...........................................................15
Lesson: Analyzing Design Requirements..............................................................23
Lesson: Designing a CA Hierarchy Structure........................................................33
Lab A: Designing a CA Hierarchy ........................................................................42
Module 3: Creating a Certification Authority Hierarchy
Overview .................................................................................................................1
Lesson: Creating an Offline Root CA .....................................................................2
Lab A: Installing an Offline CA ............................................................................14
Lesson: Validating Certificates .............................................................................20
Lesson: Planning CRL Publication........................................................................30
Lab B: Publishing CRLs and AIAs .......................................................................39
Lesson: Installing a Subordinate CA .....................................................................49
Lab C: Implementing a Subordinate Enterprise CA..............................................59
Module 4: Managing a Public Key Infrastructure
Overview .................................................................................................................1
Lesson: Introduction to PKI Management...............................................................2
Lesson: Managing Certificates ................................................................................8
Lesson: Managing Certification Authorities .........................................................16
Lab A: Enabling Role Separation ..........................................................................24
Lesson: Planning for Disaster Recovery................................................................40
Lab B: Backing Up and Restoring a Certification Authority ................................51
iv Designing and Managing a Windows® Public Key Infrastructure
Module 5: Configuring Certificate Templates

Overview .................................................................................................................1
Lesson: Introduction to Certificate Templates.........................................................2
Lab A: Delegating Certificate Template Management............................................8
Lesson: Designing and Creating Certificate Templates.........................................13
Lab B: Designing a Certificate Template ..............................................................25
Lesson: Publishing a Certificate Template ............................................................31
Lesson: Managing Changes in a Certificate Template ..........................................35
Lab C: Configuring Certificate Templates ............................................................40
Module 6: Configuring Certificate Enrollment
Overview .................................................................................................................1
Lesson: Introduction to Certificate Enrollment .......................................................2
Lesson: Enrolling Certificates Manually .................................................................9
Lesson: Autoenrolling Certificates ........................................................................14
Lab A: Enrolling Certificates.................................................................................23
Module 7: Configuring Key Archival and Recovery
Overview .................................................................................................................1
Lesson: Introduction to Key Archival and Recovery ..............................................2
Lesson: Implementing Manual Key Archival and Recovery.................................13
Lesson: Implementing Automatic Key Archival and Recovery ............................21
Multimedia: (Optional) How EFS Works..............................................................29
Lab A: Configuring Key Recovery........................................................................30
Module 8: Configuring Trust Between Organizations
Overview .................................................................................................................1
Lesson: Introduction to Advanced PKI Hierarchies ................................................2
Lesson: Qualified Subordination Concepts ...........................................................13
Lesson: Configuring Constraints in a Policy.inf File.............................................28
Lesson: Implementing Qualified Subordination....................................................41
Lab A: Implementing a Bridge CA .......................................................................53
Module 9: Deploying Smart Cards
Overview .................................................................................................................1
Lesson: Introduction to Smart Cards .......................................................................2
Lesson: Enrolling Smart Card Certificates ............................................................12
Lesson: Deploying Smart Cards ............................................................................19
Lab A: Deploying Smart Cards .............................................................................35
Course Evaluation..................................................................................................63
Module 10: Securing Web Traffic by Using SSL
Overview .................................................................................................................1
Lesson: Introduction to SSL Security......................................................................2
Lesson: Enabling SSL on a Web Server..................................................................9
Lesson: Implementing Certificate-based Authentication.......................................20
Lab A: Deploying SSL Encryption on a Web Server ............................................31
Designing and Managing a Windows® Public Key Infrastructure v
Module 11: Configuring E-mail Security

Overview .................................................................................................................1
Lesson: Introduction to E-mail Security..................................................................2
Lesson: Configuring Secure E-mail Messages ........................................................7
Lesson: Recovering E-mail Private Keys ..............................................................16
Lesson: Migrating a KMS Database to a CA Running Windows Server 2003 .....20
Lab A: Configuring Secure E-mail in Exchange Server 2003...............................26
Course Evaluation .................................................................................................43
Designing and Managing a Windows® Public Key Infrastructure vii
About This Course

This section provides you with a brief description of the course, audience,
suggested prerequisites, and course objectives.
Description This four-day, instructor-led course provides students with the knowledge and
skills to design, deploy, and manage a public key infrastructure (PKI) to support
applications that require distributed security. Students get hands-on experience
implementing solutions to secure PKI-enabled applications and services, such
as Microsoft® Internet Explorer, Microsoft Exchange Server, Internet
Information Services, and Microsoft Outlook.
Audience This course is intended for IT systems engineers who are responsible for
designing and implementing security solutions. Individuals should have
knowledge and experience to install and configure the Active Directory®
directory service and security mechanisms for computers running Microsoft
Windows® 2000 Server or Windows Server™ 2003 family.
Student prerequisites This course requires that students meet the following prerequisites:
! Familiarity with Windows 2000 or Windows Server 2003 core technologies
and implementation, such as those described in the following Microsoft
Official Curriculum (MOC) courses:
• Course 2274: Managing a Microsoft Windows Server 2003 Environment
• Course 2275: Maintaining a Microsoft Windows Server 2003
Environment
• Course 2152: Implementing Microsoft Windows 2000 Professional and
Server
! Familiarity with Windows 2000 or Windows 2003 networking technologies
and implementation, such as those described in the following MOC courses:
• Course 2277: Implementing, Managing, and Maintaining a Microsoft
Windows Server 2003 Network Infrastructure: Network Services
• Course 2153: Implementing a Microsoft Windows 2000 Network
Infrastructure
! Familiarity with Windows 2000 or Windows 2003 directory services
technologies and implementation, such as those described in the following
MOC courses:
• Course 2279: Planning, Implementing, and Maintaining a Microsoft
Windows Server 2003 Active Directory Infrastructure
• Course 2154: Implementing and Administering Microsoft Windows 2000
Directory Services
viii Designing and Managing a Windows® Public Key Infrastructure
Course objectives After completing this course, the student will be able to:
! Describe PKI and the major components of a PKI.
! Design a certification authority (CA) hierarchy to meet business
requirements.
! Install Certificate Services to create a CA hierarchy.
! Perform certificate management tasks, CA management tasks, and plan for
disaster recovery of Certificate Services.
! Create and publish a certificate template, and replace an existing certificate
template.
! Enroll a certificate manually, autoenroll a certificate, and enroll a smart card
certificate.
! Implement manual and automatic key archival and recovery in a Windows
Server 2003 PKI.
! Configure trust between organizations by configuring and implementing
qualified subordination.
! Deploy smart cards in a Windows environment.
! Secure a Web environment by implementing SSL security and certificate-
based authentication for Web applications.
! Implement secure e-mail messages by using Microsoft Exchange Server in a
Windows 2000 or Windows 2003 environment.
Designing and Managing a Windows® Public Key Infrastructure ix
Course Timing
The following schedule is an estimate of the course timing. Your timing may
vary.
Day 1
Start End Module
9:00 9:30 Introduction
9:30 10:30 Module 1: Overview of Public Key Infrastructure
10:30 10:45 Break
10:45 11:15 Lab A: Identifying Trusted Root CAs
11:15 12:15 Module 2: Designing a Certification Authority Hierarchy
12:15 1:15 Lunch
1:15 2:00 Lab A: Designing a CA Hierarchy
2:00 2:30 Module 3: Creating a Certification Authority Hierarchy
2:30 2:45 Break
2:45 3:45 Module 3: Creating a Certification Authority Hierarchy
(continued)
3:45 4:15 Lab A: Installing an Offline CA
4:15 5:00 Lab B: Publishing CRLs and AIAs
Day 2
Start End Module
9:00 9:30 Day 1 review
9:30 10:15 Lab C: Implementing a Subordinate Enterprise CA
10:15 11:15 Module 4: Managing a Public Key Infrastructure
11:15 11:30 Break
11:30 12:15 Lab A: Enabling Role Separation
12:15 1:15 Lunch
1:15 2:15 Lab B: Backing Up and Restoring a Certification Authority
2:15 3:15 Mod 5: Configuring Certificate Templates
3:15 3:30 Break
3:30 3:45 Lab A: Delegating Certificate Template Management
3:45 4:15 Lab B: Designing a Certificate Template
4:15 4:45 Lab C: Configuring Certificate Templates
x Designing and Managing a Windows® Public Key Infrastructure
Day 3
Start End Module
9:30 10:30 Module 6: Configuring Certificate Enrollment
10:30 10:45 Break
10:45 11:30 Lab A: Enrolling Certificates
11:30 12:30 Module 7: Configuring Key Archival and Recovery
12:30 1:30 Lunch
1:30 2:15 Lab A: Configuring Key Recovery
2:15 2:30 Break
2:30 3:30 Mod 8: Configuring Trust Between Organizations
3:30 5:00 Lab A: Implementing a Bridge CA
Day 4
Start End Module
9:30 10:30 Mod 9: Deploying Smart Cards
10:30 10:45 Break
10:45 12:15 Lab A: Deploying Smart Cards
12:15 1:15 Lunch
1:15 2:15 Mod 10: Securing Web Traffic by Using SSL
2:15 3:00 Lab A: Deploying SSL Encryption on a Web Server
3:00 3:15 Break
3:15 4:15 Mod 11: Configuring E-mail Security
4:15 5:00 Lab A: Configuring Secure E-mail in Exchange Server 2003
Designing and Managing a Windows® Public Key Infrastructure xi
Trainer Materials Compact Disc Contents

The Trainer Materials compact disc contains the following files and folders:
! Autorun.exe. When the compact disc is inserted into the compact disc drive,
or when you double-click the Autorun.exe file, this file opens the compact
disc and allows you to browse the Student Materials or Trainer Materials
compact disc.
! Autorun.inf. When the compact disc is inserted into the compact disc drive,
this file opens Autorun.exe.
! Default.htm. This file opens the Trainer Materials Web page.
! Readme.txt. This file explains how to install the software for viewing the
Trainer Materials compact disc and its contents and how to open the Trainer
Materials Web page.
! 2821A_ms.doc. This file is the Manual Classroom Setup Guide. It contains
the steps for manually setting up the classroom computers.
! 2821A_sg.doc. This file is the Automated Classroom Setup Guide. It
contains a description of classroom requirements, classroom configuration,
instructions for using the automated classroom setup scripts, and the
Classroom Setup Checklist.
! Powerpnt. This folder contains the Microsoft PowerPoint® slides that are
used in this course.
! Pptview. This folder contains the Microsoft PowerPoint Viewer 97, which
can be used to display the PowerPoint slides if Microsoft PowerPoint 2002
is not available. Do not use this version in the classroom.
! Setup. This folder contains the files that install the course and related
software to computers in a classroom setting.
! Student. This folder contains the Web page that provides students with links
to resources pertaining to this course, including additional reading, review
and lab answers, lab files, multimedia presentations, and course-related Web
sites.
! Tools. This folder contains files and utilities used to complete the setup of
the instructor computer.
! Webfiles. This folder contains the files that are required to view the course
Web page. To open the Web page, open Windows Explorer, and in the root
directory of the compact disc, double-click Default.htm or Autorun.exe.
xii Designing and Managing a Windows® Public Key Infrastructure
Student Materials Compact Disc Contents

The Student Materials compact disc contains the following files and folders:
! Autorun.exe. When the compact disc is inserted into the compact disc drive,
or when you double-click the Autorun.exe file, this file opens the compact
disc and allows you to browse the Student Materials compact disc.
! Autorun.inf. When the compact disc is inserted into the compact disc drive,
this file opens Autorun.exe.
! Default.htm. This file opens the Student Materials Web page. It provides
students with resources pertaining to this course, including additional
reading, review and lab answers, lab files, multimedia presentations, and
course-related Web sites.
! Readme.txt. This file explains how to install the software for viewing the
Student Materials compact disc and its contents and how to open the
Student Materials Web page.
! Addread. This folder contains the additional reading pertaining to this
course.
! Flash. This folder contains the installer for the Macromedia Flash 6.0 plug-
in for Microsoft Internet Explorer.
! Fonts. This folder contains fonts that may be required to view Microsoft
Word documents that are included with this course.
! Labfiles. This folder contains files that are used in the hands-on labs. These
files are used to prepare the student computers for the hands-on labs.
! Media. This folder contains files that are used in multimedia presentations
for this course.
! Mplayer. This folder contains the setup file to install Microsoft
Windows Media® Player.
! Practices. This folder contains files that are used in the hands-on practices.
! Webfiles. This folder contains the files that are required to view the course
Web page. To open the Web page, open Windows Explorer, and in the root
directory of the compact disc, double-click Default.htm or Autorun.exe.
! Wordview. This folder contains the Word Viewer that is used to view any
Word document (.doc) files that are included on the compact disc.
Designing and Managing a Windows® Public Key Infrastructure xiii
Document Conventions
The following conventions are used in course materials to distinguish elements
of the text.
Convention Use
Bold Represents commands, command options, and syntax that must

be typed exactly as shown. It also indicates commands on menus
and buttons, dialog box titles and options, and icon and menu
names.
Italic In syntax statements or descriptive text, indicates argument
names or placeholders for variable information. Italic is also
used for introducing new terms, for book titles, and for emphasis
in the text.
Title Capitals Indicate domain names, user names, computer names, directory
names, and folder and file names, except when specifically
referring to case-sensitive names. Unless otherwise indicated,
you can use lowercase letters when you type a directory name or
file name in a dialog box or at a command prompt.
ALL CAPITALS Indicate the names of keys, key sequences, and key
combinations — for example, ALT+SPACEBAR.
monospace Represents code samples or examples of screen text.
[] In syntax statements, enclose optional items. For example,
[filename] in command syntax indicates that you can choose to
type a file name with the command. Type only the information
within the brackets, not the brackets themselves.
{} In syntax statements, enclose required items. Type only the
information within the braces, not the braces themselves.
| In syntax statements, separates an either/or choice.
! Indicates a procedure with sequential steps.
... In syntax statements, specifies that the preceding item may be
repeated.
. Represents an omitted portion of a code sample.
.
.
THIS PAGE INTENTIONALLY LEFT BLANK
Introduction
Contents
Introduction 1
Course Materials 2
Additional Reading from Microsoft Press 3
Prerequisites 4
Course Outline 5
Initial Logon Procedure 7
Microsoft Official Curriculum 8
Microsoft Certified Professional Program 9
Facilities 12
MSDN, Outlook, PowerPoint, and Windows Media are either registered trademarks or trademarks
of Microsoft Corporation in the United States and/or other countries.
respective owners.
Introduction iii
Instructor Notes
Presentation: The Introduction module provides students with an overview of the course
30 minutes content, materials, and logistics for Course 2821, Designing and Managing a
Windows® Public Key Infrastructure.
Required materials To teach this course, you need the following materials:
! Delivery Guide
! Trainer Materials compact disc
Preparation tasks To prepare for this course, you must:

! Complete the Course Preparation Checklist that is included with the trainer
course materials.
! Thoroughly review the Instructor Notes for this course.
! Review all multimedia for this course.
iv Introduction
How to Teach This Module

This section contains information that will help you to teach this module.
Introduction Welcome students to the course and introduce yourself. Provide a brief
overview of your background to establish credibility.
Ask students to introduce themselves and provide their background, product
experience, and expectations of the course.
Record student expectations on a whiteboard or flip chart that you can reference
later in class.
Course materials Tell students that everything they will need for this course is provided at their
desk.
Have students write their names on both sides of the name card.
Describe the contents of the student workbook and the Student Materials
compact disc.
Important This course has assessment items for each lesson, located on the
Student Materials compact disc. You can use them as pre-assessments to help
students identify areas of difficulty, or you can use them as post-assessments to
validate learning.
Consider using them to reinforce learning at the end of the day. You can also
use them at the beginning of the day as a review for the content that was taught
on the previous day.
Tell students where they can send comments and feedback on this course.
Demonstrate how to open the Web page that is provided on the Student
Materials compact disc by double-clicking Autorun.exe or Default.htm in the
Student folder on the Trainer Materials compact disc.
Prerequisites Describe the prerequisites for this course. This is an opportunity for you to
identify students who may not have the appropriate background or experience
to attend this course.
Course outline Briefly describe each module and what students will learn. Be careful not to go
into too much detail because the course is introduced in detail in Module 1.
Explain how this course will meet students’ expectations by relating the
information that is covered in individual modules to their expectations.
Microsoft Official Explain the Microsoft® Official Curriculum (MOC) program and present the list
Curriculum of additional recommended courses.
Refer students to the Microsoft Official Curriculum Web page at
http://www.microsoft.com/traincert/training/ for information about curriculum
paths.
Introduction v
Microsoft Certified Inform students about the Microsoft Certified Professional (MCP) program, any
Professional program certification exams that are related to this course, and the various certification
options.
Facilities Explain the class hours, extended building hours for labs, parking, restroom
location, meals, phones, message posting, and where smoking is or is not
allowed.
Let students know if your facility has Internet access that is available for them
to use during class breaks.
Also, make sure that the students are aware of the recycling program if one is
available.
Introduction 1
Introduction
*****************************ILLEGAL FOR NON-TRAINER USE******************************

2 Introduction
Course Materials

The following materials are included with your kit:
! Name card. Write your name on both sides of the name card.
! Student workbook. The student workbook contains the material covered in
class, in addition to the hands-on lab exercises.
! Student Materials compact disc. The Student Materials compact disc
contains the Web page that provides you with links to resources pertaining
to this course, including additional readings, review and lab answers, lab
files, multimedia presentations, and course-related Web sites.
Note To open the Web page, insert the Student Materials compact disc into
the CD-ROM drive, and then in the root directory of the compact disc,
double-click Autorun.exe or Default.htm.
! Assessments. There are assessments for each lesson, located on the Student
Materials compact disc. You can use them as pre-assessments to identify
areas of difficulty, or you can use them as post-assessments to validate
learning.
! Course evaluation. To provide feedback on the course, training facility, and
instructor, you will have the opportunity to complete an online evaluation
near the end of the course.
To provide additional comments or feedback on the course, send e-mail to
support@mscourseware.com. To inquire about the Microsoft Certified
Professional program, send e-mail to mcphelp@microsoft.com.
Introduction 3
Additional Reading from Microsoft Press

Microsoft Windows Server™ 2003 books from Microsoft Press can help you do
your job—from the planning and evaluation stages through deployment and
ongoing support—with solid technical information to help you get the most out
of the Windows Server 2003 key features and enhancements. The following
titles supplement the skills taught in this course:
Title ISBN
Microsoft Windows Security Resource Kit 0-7356-1868-2

Microsoft Windows Server 2003 Security 0-7356-1574-8
Administrator’s Companion
Microsoft Windows Server 2003 Admin Pocket 0-7356-1354-0

Consultant
Microsoft Windows Server 2003 TCP/IP Protocols and 0-7356-1291-9

Services Technical Reference
Microsoft Windows Server 2003 Administrator’s 0-7356-1367-2

Companion
4 Introduction
Prerequisites

This course requires that you meet the following prerequisites:
! Knowledge of Microsoft Windows® 2000 or Windows Server 2003 core
MOC courses:
• Course 2274: Managing a Microsoft Windows Server 2003 Environment
• Course 2275: Maintaining a Microsoft Windows Server 2003
Environment
• Course 2152: Implementing Microsoft Windows 2000 Professional and
Server
! Knowledge of Windows 2000 or Windows 2003 networking technologies
and implementation, such as those described in the following MOC courses:
• Course 2277: Implementing, Managing, and Maintaining a Microsoft
Windows Server 2003 Network Infrastructure: Network Services
• Course 2153: Implementing a Microsoft Windows 2000 Network
Infrastructure
! Knowledge of Windows 2000 or Windows 2003 directory services
MOC courses:
• Course 2279: Planning, Implementing, and Maintaining a Microsoft
Windows Server 2003 Active Directory Infrastructure
• Course 2154: Implementing and Administering Microsoft Windows 2000
Directory Services
Introduction 5
Course Outline

Module 1, “Overview of Public Key Infrastructure,” explains the basic concepts
of a public key infrastructure (PKI) and its components. It also provides an
overview of the topics that will be explained in-depth in the course. After
completing this module, you will be able to describe PKI and its basic
components.
Module 2, “Designing a Certification Authority Hierarchy,” introduces a CA
hierarchy design. It explains the major design tasks, including identifying
business and legal requirements and planning a certification authority (CA)
hierarchy structure. After completing this module, you will be able to design a
CA hierarchy.
Module 3, “Creating a Certification Authority Hierarchy,” introduces the
process of creating a CA hierarchy based on a CA hierarchy design. It discusses
how to determine the correct settings and configuration for installing Certificate
Services, validating certificates, and publishing certificate revocation lists
(CRLs). After completing this module, you will be able to create a CA
hierarchy.
Module 4, “Managing a Public Key Infrastructure,” explains how managing a
PKI includes managing certificates and CAs to ensure that the PKI functions
properly in the event of a disaster. It also discusses PKI management roles that
are required to perform typical CA and certificate management tasks, and how
to recover a PKI in the event of a failure. After completing this module, you
will be able to manage certificates and CAs.
Module 5, “Configuring Certificate Templates,” discusses certificate templates
and how to design them. It also explains how to create, publish, and change
certificate templates. After completing this module, you will be able to
configure certificate templates.
Module 6, “Configuring Certificate Enrollment,” explains the process and
various methods of enrolling certificates. After completing this module, you
will be able to configure certificate enrollment.
6 Introduction
Course Outline (continued)

Module 7, “Configuring Key Archival and Recovery,” discusses the importance
of creating a strategy for data and key recovery. It also explains how
Windows XP and Windows Server 2003 enhance data protection and data
recovery. After completing this module, you will be able to configure key
archival and recovery.
Module 8, “Configuring Trust Between Organizations,” explains how to extend
an organization’s PKI trust hierarchy to other organizations. It discusses how an
organization’s certificates can be used and trusted across organizations for
purposes like secure e-mail messages, client authentication, and server
authentication. After completing this module, you will be able to configure trust
between organizations.
Module 9, “Deploying Smart Cards,” explains how smart cards provide secure
storage for data and support authentication of users. After completing this
module, you will be able to deploy smart cards.
Module 10, “Securing Web Traffic by Using SSL,” explains that Secure
Sockets Layer (SSL) is a protocol that provides encrypted communications over
the Internet. It also discusses how to implement security in a Web environment.
After completing this module, you will be able to secure Web traffic by using
SSL.
Module 11, “Configuring E-mail Security,” explains that the PKI in the
Windows Server family prevents modification and inspection of e-mail
messages by providing e-mail digital signing and e-mail encryption certificates
to users. After completing this module, you will be able to implement secure
e-mail messages in a Microsoft Exchange environment.
Introduction 7
Initial Logon Procedure

Complex passwords To meet the complexity requirements for the password that you will use in this
course, you must include characters in your password from at least three of the
following four categories:
! Uppercase letters (A to Z)
! Lowercase letters (a to z)
! Numbers (0 to 9)
! Symbols (! @ # $)
To create the password that you will use in this course, you must log on either
as Student1 on the domain controller, or Student2 on the member server.
Note You change your default password in Lab A, “Identifying Trusted Root
CAs,” in Module 1 of this course.
8 Introduction
Microsoft Official Curriculum

Introduction Microsoft Training and Certification develops Microsoft Official Curriculum
(MOC), including MSDN® Training, for computer professionals who design,
develop, support, implement, or manage solutions by using Microsoft products
and technologies. These courses provide comprehensive skills-based training in
instructor-led and online formats.
Introduction 9
Microsoft Certified Professional Program

Introduction Microsoft Training and Certification offers a variety of certification credentials
for developers and IT professionals. The Microsoft Certified Professional
program is the leading certification program for validating your experience and
skills, keeping you competitive in today’s changing business environment.
Related certification This course helps students to prepare for:
exams
! Exam 70-214: Implementing and Managing Security in a Windows 2000
Network Infrastructure
! Exam 70-220: Designing Security for a Microsoft Windows 2000 Network
! Exam 70-298: Designing Security for a Microsoft Windows Server 2003
Network
Exam 70-220 is a core choice or an elective choice for the MCSE on Microsoft
Windows 2000, and exam 70-298 is a core choice or an elective choice for the
MCSE on Microsoft Windows Server 2003.
MCP certifications The Microsoft Certified Professional program includes the following
certifications.
! MCSA on Microsoft Windows 2000
The Microsoft Certified Systems Administrator (MCSA) certification is
designed for professionals who implement, manage, and troubleshoot
existing network and system environments based on Microsoft
Windows 2000 platforms, including the Windows Server 2003 family.
Implementation responsibilities include installing and configuring parts of
the systems. Management responsibilities include administering and
supporting the systems.
10 Introduction
! MCSE on Microsoft Windows 2000

The Microsoft Certified Systems Engineer (MCSE) credential is the premier
certification for professionals who analyze the business requirements and
design and implement the infrastructure for business solutions based on the
Windows 2000 platform and Microsoft server software, including the
Windows .Server 2003 family. Implementation responsibilities include
installing, configuring, and troubleshooting network systems.
! MCAD
The Microsoft Certified Application Developer (MCAD) for Microsoft
.NET credential is appropriate for professionals who use Microsoft
technologies to develop and maintain department-level applications,
components, Web or desktop clients, or back-end data services or work in
teams developing enterprise applications. The credential covers job tasks
ranging from developing to deploying and maintaining these solutions.
! MCSD
The Microsoft Certified Solution Developer (MCSD) credential is the
premier certification for professionals who design and develop leading-edge
business solutions with Microsoft development tools, technologies,
platforms, and the Microsoft Windows DNA architecture. The types of
applications MCSDs can develop include desktop applications and multi-
user, Web-based, N-tier, and transaction-based applications. The credential
covers job tasks ranging from analyzing business requirements to
maintaining solutions.
! MCDBA on Microsoft SQL Server™ 2000
The Microsoft Certified Database Administrator (MCDBA) credential is the
premier certification for professionals who implement and administer
Microsoft SQL Server databases. The certification is appropriate for
individuals who derive physical database designs, develop logical data
models, create physical databases, create data services by using Transact-
SQL, manage and maintain databases, configure and manage security,
monitor and optimize databases, and install and configure SQL Server.
! MCP
The Microsoft Certified Professional (MCP) credential is for individuals
who have the skills to successfully implement a Microsoft product or
technology as part of a business solution in an organization. Hands-on
experience with the product is necessary to successfully achieve
certification.
! MCT
Microsoft Certified Trainers (MCTs) demonstrate the instructional and
technical skills that qualify them to deliver Microsoft Official Curriculum
through Microsoft Certified Technical Education Centers (Microsoft
CTECs).
Introduction 11
Certification The certification requirements differ for each certification category and are
requirements specific to the products and job functions addressed by the certification. To
become a Microsoft Certified Professional, you must pass rigorous certification
exams that provide a valid and reliable measure of technical proficiency and
expertise.
For More Information See the Microsoft Training and Certification Web site at
http://www.microsoft.com/traincert/.
You can also send e-mail to mcphelp@microsoft.com if you have specific
certification questions.
Acquiring the skills Microsoft Official Curriculum (MOC) and MSDN Training can help you
tested by an MCP exam develop the skills that you need to do your job. They also complement the
experience that you gain while working with Microsoft products and
technologies. However, no one-to-one correlation exists between MOC and
MSDN Training courses and MCP exams. Microsoft does not expect or intend
for the courses to be the sole preparation method for passing MCP exams.
Practical product knowledge and experience are also necessary to pass the MCP
exams.
To help prepare for the MCP exams, use the preparation guides that are
available for each exam. Each Exam Preparation Guide contains exam-specific
information, such as a list of the topics on which you will be tested. These
guides are available on the Microsoft Training and Certification Web site at
http://www.microsoft.com/traincert/.
12 Introduction
Facilities

Module 1: Overview of
Public Key
Infrastructure
Contents
Overview 1
Lesson: Introduction to PKI 2
Lesson: Introduction to Cryptography 7
Lesson: Certificates and Certification
Authorities 12
Lab A: Identifying Trusted Root CAs 23
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part
of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted
in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or
for any purpose, without the express written permission of Microsoft Corporation.
license to these patents, trademarks, copyrights, or other intellectual property..
respective owners.
Module 1: Overview of Public Key Infrastructure iii
Instructor Notes
Presentation: This module introduces students to a public key infrastructure (PKI) and its
60 minutes components. It also provides an overview of the topics that will be explained in
the rest of the course.
Lab:
30 minutes After completing this module, students will be able to:
! Describe PKI and its basic components.
! Describe how symmetric and public key encryption works.
! Define the role of certificates and certification authorities (CAs) in a PKI.
Required materials To teach this module, you need Microsoft® PowerPoint® file 2821A_01.ppt.
Preparation tasks To prepare for this module:
! Read all of the materials for this module.
! Complete the lab.
! Read the Microsoft Knowledge Base article 293781, “Trusted Root
Certificates That Are Required By Windows 2000,” under Additional
Reading on the Web page on the Student Materials compact disc.
! Read the white paper, PKI Enhancements in Windows XP Professional and
Windows Server 2003, under Additional Reading on the Web page on the
Student Materials compact disc for details about PKI functionality in
Microsoft Windows Server™ 2003.
Note Each lesson in a module has assessment items, which are located on the
Student Materials compact disc. You can use them as pre-assessments to help
students identify areas of difficulty, or you can use them as post-assessments to
validate learning.
Consider using them to reinforce learning at the end of the day. You can also
use them at the beginning of the day as a review of the content that you taught
on the previous day.
iv Module 1: Overview of Public Key Infrastructure

This module provides introductory information about a PKI, including
cryptography, certificates, and CAs, so that students learn the basic information
about a PKI before they proceed with the rest of the course.
If students do not meet the prerequisites of the course, this module may take
longer than 60 minutes to teach. Spend the extra time to ensure that all students
understand the material.
Lesson: Introduction to PKI

This lesson introduces the topic of a public key infrastructure. The lesson
defines what a PKI is and what students accomplish by deploying a PKI. The
lesson presents the components of a PKI and the management tools that ship
with Windows Server 2003.
This section describes the instructional methods for teaching each topic in this
lesson.
What Is a PKI? Ensure that students understand what a PKI is. Consider asking students
whether they have a PKI in their organization. Review the PKI requirements
that are presented in the topic, and discuss how a PKI meets those requirements.
Components of a PKI Review each of the PKI components that are presented in the slide. Answer
questions from the students about how a specific component in a PKI is used.
PKI Tools Demonstrate the Microsoft Management Console (MMC) consoles and the
graphical management tools from the Windows Server 2003 Resource Kit.
Remember that the students cannot use several of these management tools until
they install their CA hierarchy in Module 3.
Inform students that this course does not discuss PKI programming details. For
example, it does not explain CryptoAPI or CAPICOM programming solutions.
If students are interested in these topics, refer them to
http://msdn.microsoft.com.
Lesson: Introduction to Cryptography

This lesson is a high-level overview of the encryption and decryption processes.
It explains symmetric and asymmetric encryption. The slides present detailed
information about how a key pair uses the public key encryption and public key
digital signing processes.
Encryption Keys This topic compares symmetric keys and asymmetric keys. Explain that these
two encryption methods are not mutually exclusive. By telling students that the
two encryption methods can work in tandem, you better prepare them for the
upcoming public key encryption and digital signing topics.
Module 1: Overview of Public Key Infrastructure v
How Does Symmetric When you present this topic, consider discussing simple encryption algorithms,
Encryption Work? such as replacing a letter with the next letter in the alphabet. For example,
replace the letter A with the letter B, replace the letter B with the letter C, and
so on. If the sender and recipient of a message know the key, they can both
encrypt and decrypt the message.
Explain to students that this lesson does not compare and contrast the various
symmetric encryption protocols.
How Does Public Key When you discuss this topic, use the example of two students in a classroom
Encryption Work? exchanging secure e-mail messages. Explain each step in the process and
answer any questions about the process.
You may discover that students are unaware that public key encryption also
uses symmetric encryption in the process. Many books have incorrectly stated
that all data is encrypted with the recipient’s public key.
How Does Public Key Discuss each step in the digital signing process and answer any questions.
Digital Signing Work?
Lesson: Certificates and Certification Authorities

This lesson defines certificates and certification authorities. The terminology
that is used in the remainder of the course is introduced in this lesson. Ensure
that students understand terms such as certificate extensions, subordinate CAs,
and parent CAs.
What Is a Digital When you discuss this topic, ensure that students understand the difference
Certificate? between a digital certificate and a private key. Many students assume that these
terms are synonymous. The truth is, the possession of a digital certificate does
not guarantee possession of the associated private key.
This topic discusses general properties of a certificate. Do not go into detail
about certificate extensions; they are discussed in the next topic.
What Are Certificate Consider opening a certificate in the Certificates console when you discuss this
Extensions? topic. When you view the certificate, show the Details tab and demonstrate how
to filter the list of extensions.
Define each of the extensions that are mentioned in this topic so that students
are familiar with them. These extensions are discussed frequently in the
remainder of the course.
What Is a Certification This topic introduces the tasks that a CA performs in a PKI. Review each of the
Authority? tasks that are presented in the topic. Also, use the correct definition of a CA. A
CA is a certification authority, not a certificate authority, which is a common
misconception.
Certification Authority This topic introduces root and cross-certified hierarchies. Spend time discussing
Hierarchies root CA hierarchies. If students have questions about cross certification
hierarchies, defer the questions until you present Module 8, “Configuring Trust
Between Organizations.”
vi Module 1: Overview of Public Key Infrastructure
Roles in a Certification This topic introduces terminology that is used in the remainder of the course.
Authority Hierarchy Spend extra time explaining the purpose of policy CAs in a CA hierarchy.
Many students do not understand why a policy CA is required.
The topic compares internal and external policies. Use the example of two
divisions in a corporation that have very different security requirements for
certificate issuance. For example, a power company may have different
issuance requirements for employees at a nuclear plant than employees at the
organization’s corporate office. In this example, explain that the organization
may require two policy CAs to define and enforce the different issuance
requirements.
What Are Trusted Root The topic presents different methods for adding root CAs to a trusted root CA
Certificates? store. Emphasize that a computer’s operating system often defines how students
deploy trusted root CA certificates. For example, tell students that they cannot
use Group Policy to deploy trusted root CA certificates to client computers
running Microsoft Windows NT® or Windows® 98.
Lab A Ensure that students perform all steps in Exercise 0, Lab Setup.
The steps in Exercise 0 add the Administrative Tools menu to the Start menu
for the PKI management user accounts that students use in the rest of the labs in
the course. Later in the course, if the Administrative Tools menu is missing for
a specific user account, have the students perform the steps in Exercise 0.
The remainder of the lab inspects the trusted root certificate stores. At the end
of the lab, review the importance of trusted root CA certificates and discuss
which root certificates the students may consider deleting from the trusted root
store.
Lab A: Identifying Trusted Root CAs

In this lab, students add the Administrative Tools menu to the Start menu for
several PKI administration user accounts. Students use these accounts to
perform PKI management tasks in later labs in this course. In addition, students
investigate several methods of deploying trusted root certificates to the
computers on their organization’s network.
In this lab, the students will:
! Identify trusted root stores.
! Remove trusted root CAs that are not required.
Lab Setup
The following list describes the setup requirements for the labs in this module.
Setup requirement 1 Complete the automated setup or manual setup for Course 2821, Designing and
Managing a Windows Public Key Infrastructure.
Module 1: Overview of Public Key Infrastructure vii
Lab Results
Performing the labs in this module introduces the following configuration
changes:
! Students define a custom password for the Student1 account (on the domain
controller) or Student2 account (on the member server).
! Administrative Tools is added to the Start menu for the following
administrative user accounts:
• Student1 (on the domain controller) or Student2 (on the member
server)
• CAadmin1 (on the domain controller) or CAadmin2 (on the member
server)
• CertAdmin1 (on the domain controller) or CertAdmin2 (on the
member server)
• KRA1 (on the domain controller) or KRA2 (on the member server)
! Students create a custom console named Certificate Management for the
Student1 or Student2 account and place it on the desktop. The console
contains the Certificates console viewing the current user store and the
Certificates console viewing the local computer store.
Module 1: Overview of Public Key Infrastructure 1
Overview

Introduction Public key infrastructure (PKI) refers to the integration of technology,
infrastructure, and practices that enable organizations to secure their
communications and business transactions on the Internet.
PKI combines digital certificates, public key cryptography, and certification
authorities to form the security architecture of a network. Typically, you use a
PKI to issue digital certificates to individual users, computers and services;
publish certificates and public keys in directories so that messages can be
encrypted and digital signatures can be verified; and enforce an organization’s
security policies.
PKI provides the foundation for all application and network security, including
access control to information resources from Web browsers, secure e-mail
messages, and digital forms signing.
Objectives After completing this module, you will be able to:
! Describe PKI and its basic components.
! Describe how symmetric and public key encryption works.
! Define the role of certificates and certification authorities (CAs) in a PKI.
2 Module 1: Overview of Public Key Infrastructure
Lesson: Introduction to PKI

Introduction A PKI consists of digital certificates, CAs, and other registration authorities that
verify and authenticate the validity of each user, service, or computer that is
involved in an electronic transaction.
Designing a PKI involves configuring certificate templates and CAs,
developing support procedures, and establishing a system of checks and
balances for administrative authority.
Lesson objectives After completing this lesson, you will be able to:
! Describe how PKI meets the security and technical requirements of an
organization.
! Describe the components of a PKI.
! Describe the management tools that are included in a Microsoft®
Windows Server™ 2003 PKI.
What Is a PKI?

Introduction A PKI is the combination of software, encryption technologies, processes, and
services that enables an organization to secure its communications and business
transactions. A PKI relies on the exchange of digital certificates between
authenticated users and trusted resources. You use certificates to secure data
and manage identification credentials from users and computers both within and
outside your organization.
You can design a PKI solution to meet the following security and technical
requirements of your organization:
! Confidentiality. You use a PKI to encrypt data that is stored or transmitted.
! Integrity. You use a PKI to digitally sign data. A digital signature helps you
identify if another user or process modified the data.
! Authenticity. A PKI provides several authenticity mechanisms.
Authentication data passes through hash algorithms, such as Shivest Hash
Algorithm 1 (SHA1) to produce a message digest. The message digest is
then digitally signed by using the sender’s private key to prove that the
message digest was produced by the sender.
! Nonrepudiation. When data is digitally signed, the digital signature provides
proof of the integrity of the signed data and proof of the origin of the data. A
third party can verify the integrity and origin of the data at any time. This
verification cannot be refuted by the owner of the certificate that digitally
signed the data.
! Availability. You can install multiple CAs in your CA hierarchy to issue
certificates. If one CA is not available in the CA hierarchy, another CA can
issue a certificate.
Components of a PKI

Introduction A PKI consists of several interrelated objects, application, and services. These
components work together to distribute and validate certificates.
PKI components A PKI includes the following components:
! Certificate and CA management tools. Provide both graphical user interface
(GUI) and command-line tools to manage issued certificates, publish CA
certificates and CRLs, configure CAs, import and export certificates and
keys, and recover archived private keys.
! Certification authorities. Issue certificates to users, computers, and services
and manage the certificates. Each certificate that a CA issues is signed with
the digital certificate of that CA.
! Certificate and CRL distribution points. Provide publication locations where
certificates and CRLs are publicly available, either within or outside of an
organization. Publishers can use any kind of directory service, including
X.500, Lightweight Directory Access Protocol (LDAP), or directories in a
specific operating system. Publishers can also publish certificates and CRLs
on Web servers.
! Certificate templates. Define the content and purpose of a digital certificate.
A certificate template defines issuance requirements, certificate purpose,
implemented extensions, such as application policy or extended key usage,
and enrollment permissions for certificates that a CA issues.
! Digital certificates. Provide the foundation of a PKI. Digital certificates are
electronic credentials that are associated with a public key and a private key
that an organization uses to authenticate users.
! Certificate revocation lists (CRL). List the certificates that a CA has
revoked before the certificate has reached its scheduled expiration date.
! Public key-enabled applications and services. Support public key
encryption so you can implement public key security. You can only
implement these components after you configure your PKI to issue, publish,
and control certificates.
PKI Tools

Introduction Windows Server 2003 includes a suite of tools to manage a PKI, including
Microsoft Management Console (MMC) consoles, command-line tools, and
management tools in the Windows Server 2003 Resource Kit.
MMC snap-ins Windows Server 2003 provides the following MMC snap-ins for managing a
PKI:
Console Use this console to
Certificates Manage the local certificate store for users, computers,

and services.
Certificate Templates Create, modify, and manage all of the certificate
templates in a Windows Server 2003 forest.
Certification Authority Manage the CA and the certificates that the CA issues,
and to publish the CRLs.
Note The Windows Server 2003 Administration Pack (Adminpak.msi)

includes these snap-ins, allowing you to manage a Windows Server 2003
network from a client computer running Microsoft Windows® XP.
Adminpak.msi also includes a custom console named Public Key Management,
which includes the Certification Authority, Certificate Templates, and
Certificates consoles in a single MMC console.
Command-line tools Windows Server 2003 provides the following command-line tools for managing
CAs and requesting certificates from a CA:
! Certutil.exe. Allows you to script CA and certificate management tasks
including management of the CA, publication of CRL and CA certificates,
revocation of certificates, and recovery of archived private keys.
! Certreq.exe. Allows you to script certificate requests from a CA and
generate Cross Certification Authority certificate requests.
Resource Kit tools The Windows Server 2003 Resource Kit includes the following management
tools for managing a PKI:
! Key Recovery Tool (Krt.exe). Determines key recovery agents (KRAs) and
recovers archived private key material from the CA database.
! PKI Health Tool (Pkiview.msc). Validates a CRL distribution point (CDP)
and Authority Information Access (AIA) URLs for every CA in an
organization’s CA hierarchy.
! Chkcdp.exe. Validates CDP and AIA extensions for a selected certificate.
Programmatic tools Microsoft provides the following APIs to apply cryptography

programmatically:
! CryptoAPI. A cryptographic API that provides a set of functions so
applications can programmatically encrypt or digitally sign data.
! CAPICOM. A reduced set of APIs that enable applications to encrypt or
digitally sign data with far less code than CryptoAPI requires.
Lesson: Introduction to Cryptography

Introduction Cryptography provides a means of protecting data by converting it into an
unreadable form to secure transmission between networks or organizations or to
store data securely on computer disks. Cryptography is an important technology
for e-commerce, intranets, extranets, and other Web-based applications.
There are two types of cryptographic techniques—symmetric and asymmetric
cryptography. You use symmetric keys and asymmetric keys together to
provide a variety of security functions to secure networks and information.
! Describe the types of encryption keys.
! Describe how symmetric encryption works.
! Describe how public key encryption works.
! Describe how public key digital signing works.
Encryption Keys

Introduction Encryption involves both the encryption of data into an encrypted format and
decryption of the resulting data back into its original format. You use either the
same key or two separate but related keys for the encryption and decryption
processes.
Key types You use the following types of keys to encrypt and decrypt data:
! Symmetric key. The same key is used for both encryption and decryption.
When encrypting data, the sender uses the symmetric key to ensure that an
unauthorized person or process cannot inspect the original data. The
recipient uses the same symmetric key to decrypt the data.
Warning Because the symmetric key is used for both encrypting and
decrypting the data, you must protect it from interception. If the symmetric
key is intercepted, all data that is encrypted with the symmetric key is
susceptible to inspection.
! Asymmetric key. This type of key is a combination of two mathematically-

related keys; a public key and a private key, which is often referred to as a
key pair. Both keys are used to encrypt and decrypt the data.
• If the public key encrypts the data, the associated private key decrypts
the data.
• If the private key encrypts the data, the associated public key decrypts
the data.
The private key is never exposed to network users. It is protected in a user
or computer profile or on a physical device, such as a smart card.
The public key, which is an attribute of the certificate, is widely distributed
in locations such as the Active Directory® directory service to ensure that
other users can obtain the public key for encryption and digital signing of
data.
How Does Symmetric Encryption Work?

Introduction Symmetric encryption uses the same key for encryption and decryption.
Because of its speed, you typically use symmetric encryption to encrypt large
amounts of data. Symmetric encryption is also referred to as bulk encryption.
The symmetric When performing symmetric encryption, the sender of the original data
encryption process encrypts the data by using the symmetric key. The result is cipher text—the
encrypted format of the original content—which is transmitted to the recipient.
When the recipient receives the cipher text, he decrypts the data with the same
symmetric key to obtain the original data.
If the symmetric key is compromised, the encrypted data is also compromised.
Note Most encryption solutions deploy a mixture of symmetric and

asymmetric encryption. The data is encrypted by using symmetric encryption.
The symmetric key is transmitted securely between client and server by using
asymmetric encryption.
How Does Public Key Encryption Work?

Introduction When you implement public key encryption, the recipient’s key pair protects
the original data from inspection by encrypting the original data during
transmission.
The public key The following steps explain the process for how public key encryption is
encryption process applied to the original plaintext data:
1. The sender retrieves the recipient’s public key. In an Active Directory
environment, the sender retrieves the public key by retrieving the recipient’s
certificate from Active Directory and then retrieving the public key from the
certificate.
2. The sender generates a symmetric key and uses this key to encrypt the
original data.
3. The symmetric key is encrypted with the recipient’s public key to prevent
the symmetric key from being intercepted during transmission.
4. The encrypted symmetric key and encrypted data are sent to the recipient.
5. The recipient uses her private key to decrypt the encrypted symmetric key.
6. The encrypted data is decrypted with the symmetric key, which results in
the recipient obtaining the original data.
How Does Public Key Digital Signing Work?

Introduction When you implement digital signing, the key pair of the sender protects the
original data from modification by implementing a digital signature for the
original data. The digital signature does not protect the data from inspection
during transmission.
The digital signing The following steps explain the process for how a digital signature is applied to
process the original data:
1. A hash algorithm is applied to the original data. A hash algorithm takes any
form of data and produces a mathematical result for the inputted data. This
result is referred to as the hash value.
Note A single character change in the original data will result in a change
in value of more than half of the digits in the resulting hash value. This
change in value protects data from simple modifications, such as inflating a
dollar value in a contract.
2. The resulting hash value is encrypted by using the sender’s private key. The
encryption protects the hash value from modification during the
transmission of the hash value to the recipient.
3. The sender sends the certificate, the encrypted hash value, and the original
data to the recipient. The certificate includes the sender’s public key as one
of the attributes of the certificate.
4. The recipient retrieves the sender’s public key from the received certificate.
The recipient uses the public key to decrypt the encrypted hash value. The
successful decryption and validation of the sender’s certificate proves that
the data originated from the sender.
5. The recipient passes the original data through the same hash algorithm. The
resulting hash value is compared to the hash value received from the sender.
If the two hash values are identical, the original data was not modified during
the transmission from sender to receiver.
Lesson: Certificates and Certification Authorities

Introduction Digital certificates and certification authorities (CAs) are basic components of a
PKI. Digital certificates are electronic credentials that identify individuals,
organizations, and computers. CAs issue and certify certificates. A certificate
not only identifies its owner as an entity on the network, it also identifies the
CA that issued the certificate.
! Describe a certificate.
! Describe common certificate extensions.
! Describe the tasks that a CA performs.
! Describe CA hierarchies.
! Describe the roles in a CA hierarchy.
! Designate trusted root CAs.
What Is a Digital Certificate?

Introduction A digital certificate provides information about the subject of the certificate, the
validity of the certificate, and what application and services may use the
certificate. A digital certificate also provides a way to identify the holder of the
certificate. Certificates use cryptographic techniques to solve the problem of no
physical contact between the two entities that perform a transaction. Instead of
an organization identifying the certificate holder in a face-to-face meeting, an
application or service verifies each certificate holder by validating the
certificate that each holder presents.
It is difficult for a user or computer to impersonate someone else because the
certificates are digitally signed by the CA that issues the certificate. An attacker
cannot modify the certificate without the CA’s knowledge. An attacker cannot
assume the identity of the user or computer that is listed in the subject of the
certificate without gaining access to the private key that is associated with the
certificate.
Contents of a digital A digital certificate contains the following:
certificate
! The public cryptographic key from the certificate subject’s key pair.
! Information about the subject that requested the certificate.
! Information about the CA that issued the certificate.
Before a CA issues a certificate, the CA verifies the identity of the requestor.

This verification can include a manual background check of the requestor or an
examination of the Discretionary Access Control List (DACL) of the requested
certificate template to ensure that the requesting user or computer has the
required permissions to enroll the requested certificate.
What Are Certificate Extensions?

Introduction The information that a digital certificate contains is stored in the certificate in
attributes known as certificate extensions. The certificate extension fields
describe additional information about the subject of the certificate. By knowing
what attributes are available in a certificate, you can gather more information
about the holder of the certificate and what applications a user can use the
certificate for.
Version 1 fields The initial format of a digital certificate was known as an X.509 version 1
certificate format. This format defined fields for a certificate that described
basic attributes of the subject, the issuer, and the validity of the certificate.
X.509 version 1 includes the following fields:
! Subject. Provides the name of the computer, user, network device, or service
that the CA issues the certificate to. The subject name is commonly
represented by using an X.500 or LDAP format.
! Serial Number. Provides a unique identifier for each certificate that a CA
issues.
! Issuer. Provides a distinguished name for the CA that issued the certificate.
The issuer name is commonly represented by using an X.500 or LDAP
format.
! Valid From. Provides the date and time when the certificate becomes valid.
! Valid To. Provides the date and time when the certificate is no longer
considered valid.
Note The date when an application or service evaluates the certificate must fall
between the Valid From and Valid To fields of the certificate for the certificate
to be considered time valid.
! Public Key. Contains the public key of the key pair that is associated with
the certificate.
X.509 version 3 X.509 version 3 certificates are the current certificate format in a
extensions Windows Server 2003 PKI. In addition to the version 1 fields, an X.509 version
3 certificate includes extensions that provide additional functionality and
features to the certificate. These extensions are optional and are not necessarily
included in each certificate that the CA issues:
! Subject alternative name. A subject may be presented in many different
formats. For example, if the certificate must include a user’s account name
in the format of an LDAP distinguished name, e-mail name, and a user
principal name (UPN), you can include the e-mail name and UPN in a
certificate by adding a subject alternative name extension that includes these
additional name formats.
! CRL distribution points (CDP). When a user, service, or computer presents
a certificate, an application or service must determine whether the certificate
has been revoked before its validity period has expired. The CDP extension
provides one or more URLs where the application or service can retrieve the
CRL from.
! Authority Information Access (AIA). After an application or service
validates a certificate, the certificate of the CA that issued the certificate,
also referred to as the parent CA, must also be evaluated for revocation and
validity. The AIA extension provides one or more URLs from where an
application or service can retrieve the issuing CA certificate.
! Enhanced key usage. This attribute describes what applications or services a
certificate may be used for by including an object identifier (OID) for each
supported application or service. The OID is a sequence of numbers from a
worldwide registry that are unique in the world.
! Application policies. Also describes what applications or services that a
certificate may be used for by including an OID for each supported
application or service. The contents of the Enhanced Key Usage field must
match the contents of the Application Policies extension.
! Certificate policies. Describes what measures an organization takes to
validate the identity of a certificate requestor before a certificate is issued.
An OID represents the validation process and may include a policy-
qualified URL that fully describes the measures taken to validate the
identity.
What Is a Certification Authority?

Introduction A CA in a Windows Server 2003 network is a computer with the Certificate
Services service loaded. A CA is an important part of a Microsoft PKI solution.
CA tasks A CA performs the following network management tasks in a
Windows Server 2003 network:
! Verifies the identity of a certificate requestor. Before a CA issues a
certificate to a requesting user, computer, or service, the CA validates the
requestor to ensure that certificates are issued only to approved users or
computers. The method of validating the requestor depends on what type of
CA the user or computer submits the certificate request to. For example, the
certificate policy of a CA may require a background check before a
certificate is issued. Or, the CA may issue the certificate based on the
credentials that are presented during the certificate request.
! Issues certificates to requesting users, computers, and services. After the
CA validates the identity of the requesting user, computer, or service, the
CA issues the requested certificate. The type of certificate that the user
requests determines the content of the issued certificate. For example, an
IPSec certificate includes application policies that enable only Internet
Protocol Security (IPSec) authentication for the certificate usage.
! Manages certificate revocation. The CA publishes a CRL at regular
intervals. The CRL consists of a list of certificate serial numbers that the CA
issues for certificates that can no longer be trusted. In the published CRL,
the CA includes the certificate serial number and the reason that the
certificate was revoked.
Certification Authority Hierarchies

Introduction You can deploy one of two CA models: a root hierarchy or a cross certification
hierarchy. Windows Server 2003 networks recognize and support both models.
In a root CA hierarchy, all of the CAs in the organization’s CA hierarchy are
chained to a common root CA. In a cross certification hierarchy, a CA in one
organization’s root CA hierarchy issues a subordinate CA certificate to a CA in
another organization’s CA hierarchy.
Note Root hierarchies are preferred over cross certification hierarchies because
they are easier to deploy, maintain, and troubleshoot.
Root hierarchies A root CA hierarchy:

• Enhances security and scalability. It protects the upper layers of the CA
hierarchy from network attacks by removing the upper layers of the CA
hierarchy of the network.
• Provides flexible administration to the CA hierarchy. You can use role
separation to delegate CA management to separate administration groups
in an organization.
• Supports commercial CAs. All commercial CAs, such as VeriSign, GTE,
Thawte, and RSA, implement trusted root CA hierarchies.
• Supports most applications. Applications such as Microsoft Internet
Explorer and Netscape Communicator support certificates that root CA
hierarchies issue, as do Internet Information Services (IIS) and Apache
Web servers.
Cross certification A cross certification hierarchy:

hierarchies
! Provides interoperability between businesses and between products. When
cross certification is implemented, the certificates are logically chained to
the trusted root CA of the organization that is evaluating the presented
certificate.
! Joins disparate PKI domains. You can issue a Cross Certification Authority
from any CA in your organization’s hierarchy to any CA in a partner
! Assumes complete trust of a foreign CA hierarchy. Cross certification does
not enforce any constraints on the certificates that a partner organization
issues. You must implement qualified subordination to implement
constraints on those certificates.
Note For more information about qualified subordination and cross

certification, see Module 8, “Configuring Trust Between Organizations,” in
Course 2821, Designing and Managing a Windows Public Key Infrastructure.
Roles in a Certification Authority Hierarchy

Introduction Each CA in a CA hierarchy is assigned a role, which is determined by the CA’s
location in the CA hierarchy. Common roles in a CA hierarchy include a root
CA, a policy CA, and an issuing CA.
Root CAs A root CA is the highest CA in a CA hierarchy and is the trust point for all
certificates that are issued by the CAs in the CA hierarchy. If a user, computer,
or service trusts a root CA, they implicitly trust all certificates that are issued by
all other CAs in the CA hierarchy.
A root CA is different from all other CAs in that it issues its own certificate.
This means that the Issuer and Subject fields of the certificate contain the same
distinguished name. A root CA only issues certificates to other CAs that are
directly subordinate to it.
Policy CAs A policy CA is typically located on the second-tier of a CA hierarchy, directly
beneath the root CA. In this scenario, the root CA is often referred to as a
parent CA, because the root CA issued a Subordinate Certification Authority
certificate to the policy CA. In fact, any CA that issues a certificate to another
CA is referred to as a parent CA. The CA that receives the certificate from a
parent CA is known as a subordinate CA.
The role of a policy CA is to describe the policies and procedures that an
organization implements to secure its PKI, the processes that validate the
identity of certificate holders, and the processes that enforce the procedures that
manage certificates. A policy CA issues certificates only to other CAs. The CAs
that receive these certificates must uphold and enforce the policies that the
policy CA defined.
If different divisions, sectors, or locations of an organization require different
issuance policies and procedures, you must add policy CAs to the hierarchy to
define each unique policy. For example, an organization may implement one
policy CA for all certificates that it issues internally to employees, and another
policy CA for all certificates that it issues to nonemployees.
Note Typically, you remove root CAs and policy CAs from the network to
provide additional physical security and to protect the CAs from network
attacks.
Issuing CAs An issuing CA is typically located on the third tier or lower in a CA hierarchy.
An issuing CA issues certificates to other computers, users, network devices,
services, or other issuing CAs. An issuing CA is always online.
The parent CA for an issuing CA can be a policy CA or another issuing CA.
The issuing CA must enforce the policies and procedures that are described in
the policy CA above the issuing CA in the CA hierarchy.
Note This topic assumes that an organization deploys a three-tiered CA

hierarchy as described in the white paper, Best Practices for Implementing a
Microsoft Windows Server 2003 Public Key Infrastructure, under Additional
What Are Trusted Root Certificates?

Introduction A root certificate is self-signed and provides the highest instance of trust in a
CA hierarchy. The CA that issues the root certificate is also the recipient of the
certificate. You must add the root CA certificates to a trusted root store to
designate which root certificates are trusted root CAs. Certificates that chain to
a trusted root CA are trusted by all computers and users in your organization.
When a user, computer, or service presents a certificate to an application, the
application determines if the certificate is issued by a CA chains to a trusted
root CA certificate. A client computer implicitly trusts the CA if it chains to a
trusted root CA certificate.
Designating trusted root There exists more than one way to designate a root certificate as a trusted root
CAs certificate. You can designate trusted root certificates in the following ways:
! Participate in the Microsoft Root Certificate Program. Microsoft includes a
set of root certificates in the trusted root store. These root certificates
include root certificates from commercial CAs such as VeriSign, GTE,
Thawte, and RSA. There are more than 100 default trusted root certificates.
If Microsoft approves additional root certificates, you can download them
automatically if you select the Update Root Certificates check box in Add
or Remove Programs in Control Panel.
Important It is not necessary to keep all designated root certificates.

Microsoft requires only five trusted root certificates for all code signing and
certificate trust operations required for Windows 2000 or higher. For a
complete list of required trusted root certificates, see the Microsoft
Knowledge Base article 293781, “Trusted Root Certificates That Are
Required By Windows 2000,” under Additional Reading on the Web page
on the Student Materials compact disc.
! A local administrator can add a root certificate to the local computer’s

trusted root store by using the Certificates console. Any certificates in the
local computer’s trusted root store are trusted by all users of that computer.
! A user can add a root certificate to his trusted root store by using the
Certificates console. Any certificates included in the user’s trusted root store
are trusted only by that user.
! A domain administrator or user with the permission to modify Group Policy
can designate trusted root certificates for all computers in the site, domain,
or organizational unit where the Group Policy object applies.
! An enterprise administrator can publish root certificates in the NTAuth store
of the configuration naming context (NC). A member of the Enterprise
Admins group can publish trusted root CA certificates to the configuration
naming context in the CN=NTAuthCertificates,,CN=Public Key Services,
CN=Services,CN=Configuration,DC=ForestRootDomain container by
using the certutil.exe command.
! Publish root certificates in the AIA container of the configuration naming
context. A member of the Enterprise Admins group can publish trusted root
CA certificates to the configuration naming context in the
CN=AIA,CN=Public Key Services, CN=Services,CN=Configuration,
DC=ForestRootDomain container by using the certutil.exe command.
Not all operating systems support the preceding methods. The following table
defines the minimum requirements for an operating system to recognize a root
CA certificate.
Method Minimum operating system required
Microsoft Root Certificate Windows XP or the Windows Server 2003 family

Program
Local machine’s trusted root store Windows NT® 4.0 and later
User’s trusted root store Windows NT 4.0 and later
Group Policy Windows 2000 and later
NTAuth store Windows 2000 and later
AIA container Windows 2000 and later
Lab A: Identifying Trusted Root CAs

Objectives After completing this lab, you will be able to:
! Identify trusted root stores.
! Remove trusted root CAs that are not required.
Note This lab focuses on the concepts that are explained in this module and
may not comply with Microsoft security recommendations.
Prerequisites Before working on this lab, you must have completed the course setup.
Additional information For more information about trusted root CAs, see article Q293781, “Trusted
Root Certificates That Are Required By Windows 2000,” in the Microsoft
Knowledge Base at http://support.microsoft.com/?kbid=293781.
Estimated time to
complete this lab:
30 minutes
Exercise 0
Lab Setup
You must change the password for your network administrative account before you start the lab.
This user account is referred to as your domain administrative account in all subsequent labs. In
addition, you must add the Administrative Tools menu to the Start menu for the PKI
administration accounts.
Tasks Detailed steps
Important: Perform this procedure on both computers in your domain.
1. Log on with your domain a. Turn on your computer.

administrative account. b. If you are sitting at the member server, choose Member Server from
the Boot menu, and then press ENTER.
c. Log on to your computer by using the following account information:
• User name: Student1 (on the domain controller) or Student2 (on
the member server)
• Password: P@ssw0rd
• Domain: Domain (where Domain is the NetBIOS name of your
domain)
2. Change your password to a. In the Logon Message message box, click OK.
your own personal b. In the Change Password dialog box, in the New Password and
password. Confirm New Password boxes, type Password (where Password is a
new password for your administrative account), and then click OK.
c. In the Change Password message box, click OK.
d. In the Manage Your Server window, click Don’t display this page at
logon, and then close the window.
What is your new password?

Write the new password that is assigned to your Student1 or Student2 account.
3. Open the Start menu and " Click Start, and then verify that the Administrative Tools menu is
verify that the available on the Start menu.
Administrative Tools menu If Administrative Tools is not available, perform the tasks in Step 4.
appears. If Administrative Tools is available, proceed to Step 5.
(continued)
4. Add Administrative Tools a. Right-click Start, and then click Properties.

to the Start menu. b. In the Taskbar and Start Menu Properties dialog box, click Start
menu, and then click Customize.
c. In the Customize Start Menu dialog box, on the Advanced Tab, in
the Start menu items list, under System Administrative Tools, click
Display on the All Programs and the Start menu, and then click
OK.
d. In the Taskbar and Start Menu Properties dialog box, click OK.
5. Log on as a member of the a. Close all open windows and then log off.
CA administrators. b. Log on to your computer by using the following information:
• User name: CAadmin1 (on the domain controller) or CAadmin2
(on the member server)
domain)
Administrative Tools menu If Administrative Tools is not available, perform the tasks in Step
appears. 7. If Administrative Tools is available, proceed to Step 8.

OK.
certificate administrators. b. Log on to your computer with the following information:
• User name: CertAdmin1 (on the domain controller) or
CertAdmin2 (on the member server)
• Domain: Domain
(continued)
OK.
auditors. b. Log on to your computer by using the following information:
• User name: Auditor1 (on the domain controller) or Auditor2 (on
the member server)
• Domain: Domain
OK.
key recovery agents. b. Log on to your computer by using the following information:
• User name: KRA1 (on the domain controller) or KRA2 (on the
member server)
• Domain: Domain
(continued)
OK.
17. Close all open windows and " Close all open windows and log off.
then log off the network.
Exercise 1
Creating a Custom MMC
In this exercise, you will create a custom MMC by using the Certificates snap-in for the current
user and the local computer.
Scenario
Your manager has asked you to create a custom MMC that includes the Certificates MMC snap-in
for the current user and the local computer so that you can investigate the default trusted root CAs.
Important: Perform this procedure at both the computers in your domain.
1. Log on with your " Ensure that you are logged on with the following account information:
administrative account for • User name: Student1 (at the domain controller) or Student2 (at the
your domain. member server)
• Password: Password (where Password is the password for your
administrative account)
domain)
2. Create an MMC and then a. Click Start, click Run, type MMC and then click OK.
add the following snap-ins: b. On the File menu, click Add/Remove Snap-in.
• Certificates – Current c. In the Add/Remove Snap-in dialog box, click Add.
User
d. In the Add Standalone Snap-in dialog box, in the Available
• Certificates – Local Standalone Snap-ins list, select Certificates, and then click Add.
Computer
e. In the Certificates snap-in dialog box, click My user account, and
then click Finish.
f. In the Add Standalone Snap-in dialog box, in the Available
Standalone Snap-ins list, select Certificates, and then click Add.
g. In the Certificates snap-in dialog box, click Computer account, and
then click Next.
h. In the Select Computer dialog box, click Local computer (the
computer this console is running on), and then click Finish.
i. In the Add Standalone Snap-in dialog box, click Close.
j. In the Add/Remove Snap-in dialog box, click OK.
3. Save the MMC on the a. In the Console1 – [Console Root] window, on the File menu, click
desktop as Certificate Save As.
Management. b. In the Save As dialog box, click Desktop.
c. In the Save As dialog box, in the File name box, type Certificate
Management and then click Save.
Exercise 2
Viewing CA Certificates in Certificates MMC
In this exercise, you will investigate the trusted root CA certificates that are loaded in the
Certificates MMC snap-in.
Scenario
Your manager has asked you to enumerate the root certificates trusted by your organization. You
must determine how many certificates are listed in Certificates MMC for the current user and the
local computer.
1. View the trusted root CAs a. In the Certificate Management console, in the console tree, expand
for both the current user and Certificates – Current User, expand Trusted Root Certification
the local computer in the Authorities, and then click Certificates.
Certificates MMC snap-in.
How many CAs are listed in the Certificates container?
103 CAs are listed in the Certificates container.
1. (continued) b. In the Certificate Management console, in the console tree, expand

Certificates (Local Computer), expand Trusted Root Certification
Authorities, and then click Certificates.
Why are the same number of CAs shown in the local computer and the current user account?
Both containers display all root certificates that are trusted by the computer for that user. The
containers do not differentiate between root certificates trusted by the user and root certificates
trusted by the local computer.
How does the addition of a trusted root CA certificate differ in the Certificates (Local Computer) snap-in and
the Certificates - Current User snap-in?
A trusted root CA certificate that is added to the Certificates (Local Computer) snap-in is trusted by
all users of the computer, whereas a trusted root CA certificate that is added to the Certificates –
Current User snap-in is trusted only by the current user.
Exercise 3
Analyzing CA Certificate Distribution Methods
In this exercise, you will examine methods of distributing trusted root CA certificates to users and
computers in your organization.
Scenario
You organization wishes to deploy a private PKI. You must determine the best way to distribute
trusted root CA certificate from the private PKI to users and computers in your organization.
1. View the list of Windows a. Click Start, point to Control Panel, and then click Add or Remove
Components that are Programs.
available in the b. In the Add or Remove Programs dialog box, click Add/Remove
Add/Remove Windows Windows Components.
Components list.
c. On the Windows Components page, scroll to the bottom of the
Components list.
What does the Update Root Certificates component provide when it is enabled?
When Microsoft adds CAs to the trusted root CA program, they are automatically downloaded to the
computer.
1. (continued) d. On the Windows Components page, click Cancel.

e. Close the Add or Remove Programs dialog box.
2. Create an MMC and then a. Click Start, click Run, type MMC and then click OK.
add the Group Policy object b. On the File menu, click Add/Remove Snap-in.
Default Domain Policy.
c. In the Add/Remove Snap-in dialog box, click Add.
Standalone Snap-ins list, select Group Policy Object Editor, and
then click Add.
e. In the Select Group Policy Object dialog box, click Browse.
f. In the Browse for a Group Policy Object dialog box, select Default
Domain Policy, and then click OK.
g. In the Select Group Policy Object dialog box, click Finish.
h. In the Add Standalone Snap-in dialog box, click Close.
i. In the Add/Remove Snap-in dialog box, click OK.
(continued)
3. View the Trusted Root a. In the console tree, expand Default Domain Policy, expand
Certification Authorities Computer Configuration, expand Windows Settings, expand
container in Default Domain Security Settings, expand Public Key Policies, and then click
Policy. Trusted Root Certification Authorities.
Are there any certificates included in the Trusted Root Certification Authorities details pane?
No. No CA certificates are included in this store by default.
If certificates are included in the details pane, where are they applied?
To all computers in the domain or organizational unit where the Group Policy object is applied.
3. (continued) b. Close the MMC snap-in without saving any changes.
4. Open the ADSI Edit console a. Click Start, click Run, type Adsiedit.msc and then click OK.
and inspect CA certificate b. In the console tree, expand Configuration, expand
publication points in the CN=Configuration, DC=ForestName (where ForestName is the
Configuration naming LDAP distinguished name of your forest), expand CN=Services,
context. expand CN=Public Key Services, and then click CN=AIA.
Are there any certificates in the AIA container? What types of certificates are added to this store?
No. You can add private CA certificates to this store, which you must add manually.
4. (continued) c. Close the ADSI Edit console

d. Close all open windows and then shut down the computer.
Module 2: Designing a
Certification Authority
Hierarchy
Contents
Overview 1
Lesson: Identifying CA Hierarchy Design
Requirements 2
Lesson: Common CA Hierarchy Designs 10
Lesson: Documenting Legal Requirements 15
Lesson: Analyzing Design Requirements 23
Lesson: Designing a CA Hierarchy
Structure 33
Lab A: Designing a CA Hierarchy 42
respective owners.
Module 2: Designing a Certification Authority Hierarchy iii
Instructor Notes
Presentation: This module introduces the students to designing a Certification Authority (CA)
60 minutes Hierarchy. The major tasks involved in designing a PKI are the design of the
CA hierarchy and the configuration of the CAs in that hierarchy.
Lab:
45 minutes After completing this module, students will be able to:
! Identify requirements for designing a CA hierarchy.
! Describe common CA hierarchy designs.
! Describe policies and documents for specifying the legal requirements of a
CA hierarchy design.
! Identify the impact of design requirements and determine design changes to
a CA hierarchy design.
! Design a CA hierarchy to meet business requirements.
Important It is recommended that you use PowerPoint 2002 or later to display

the slides for this course. If you use PowerPoint Viewer or an earlier version of
PowerPoint, all the features of the slides may not appear correctly.

! Complete the lab.
! See RFC 2196, Site Security Handbook, at http://www.ietf.org/
rfc/rfc2196.txt for information about security policies and procedures.
! See RFC 2527 for details and examples on developing a certification
practice statement (CPS).
! Read the white paper, Best Practices for Implementing a Microsoft
Wiindows Server 2003 Public Key Infrastructure, under Additional
Reading on the Web page on the Student Materials compact disc for more
information about best practices on CA hierarchy design.
iv Module 2: Designing a Certification Authority Hierarchy

Lesson: Identifying CA Hierarchy Design Requirements

This lesson describes the importance of doing detailed research before
designing a CA hierarchy. A successful CA hierarchy design requires that
students collect and verify all the required details about their organization and
its processes.
Avoid teaching this lesson from a theoretical perspective. The best way to teach
this lesson is to provide examples of requirements and draw from your
experience and that of the students.
lesson.
Project Scope Describe how to determine the scope of a project. Explain how project scope
depends on administration models and the prior existence of PKI in an
organization. Warn the students that if they do not clearly define the scope of
the project, it can continue to grow as the project progresses.
Applications that Use a This topic describes the applications that benefit from PKI. Although the topic
PKI provides some examples, there is an excellent opportunity to ask students for
their input on applications in their organizations that use a PKI. Focus on the
PKI applications that students are not familiar with.
Which Accounts use Discuss the accounts that use the applications that students identified in the
PKI-Enabled previous topic. Users, computers and services are the accounts that can use
Applications? PKI-enabled applications. Tell the students that certificates that are issued to
services are either issued to a user account or to a computer account, depending
on the specific service. For example, Encrypting File System (EFS) issues the
EFS Recovery Agent certificate to a user account, whereas Internet Information
Services (IIS) implements a Web Server certificate that is issued to the
computer account on which IIS is installed.
How to Identify Emphasize how critical it is to identify all the technical requirements for a
Technical Requirements successful CA hierarchy design. This topic may generate interesting discussions
about the technical requirements. To help the students, provide a real scenario
and ask the students to identify the requirements.
How to Identify Emphasize how critical it is to identify all the business requirements for a
Business Requirements successful CA hierarchy design. This topic may generate interesting discussions
about the business requirements. Help the students to distinguish between
technical and business requirements.
Module 2: Designing a Certification Authority Hierarchy v
Lesson: Common CA Hierarchy Designs

This lesson introduces some of the different types of CA hierarchy designs.
Explain that understanding the organization’s requirements and processes is one
of the basic criteria for implementing a particular design because the CA
hierarchy design depends on the requirements, structure, location, and processes
of the organization.
CA Hierarchy Based on Discuss the various services and applications that require certificates in a PKI.
Certificate Use Tell the students that they can implement this design when the business defines
certificate management based on application management. Ask students to give
input and provide examples of their CA hierarchy structures.
CA Hierarchy Based on Use a scenario when you discuss this topic, and explain the performance
Location reasons, legal reasons, and business requirements for issuing certificates that are
based on location. Explain that location-based design is commonly used in
geographically distributed networks, with the CAs deployed at major hub sites
on the network.
CA Hierarchy Based on Give examples of typical departments within an organization that may
Departments implement PKI-enabled applications, and ask the students if they would design
a CA hierarchy based on departments. Explain that this CA design is one in
which an organization’s management scheme is decentralized with management
delegated to each division, department, or business unit. Tell the students that
this design may require separate policy CAs, depending on issuance policy
requirements.
CA Hierarchy Based on Explain that within an organization, different types of users may require
Organizational Structure different issuance requirements and delegation of management to separate CAs.
Tell the students that they can create separate CAs for employees, contractors
and partners. This is a good topic of discussion, so ask the students to share
their experiences. Be prepared to discuss examples from your own experience.
Lesson: Documenting the Legal Requirements

This lesson emphasizes the legal requirements required when designing a PKI.
Focus on support procedures and administrative systems and how implementing
these effectively ensures that your certificate services provide level of security
required for your organization. A PKI is only as good as the policies and
procedures that are implemented to ensure the valid use of certificates.
Steps for Designing The students might not know much about the legal requirements that are
Legal Requirements required in a PKI. Be prepared to present scenarios and real life examples to
emphasize how critical legal requirements are when designing a CA hierarchy.
Do not spend too much time explaining security policy, the certificate policy
statement, and the certification practice statement. Students will learn about
these in the next three topics.
Security Policy Emphasize that the PKI design is derived from the security policy. Present an
example of a security policy and ask the students to design a CA hierarchy
based on your example.
Certificate Policy Tell the students that the certificate policy describes how the organization’s PKI
enforces the organization’s security policy.
Certification Practice Explain that after the certification policy is in place, the CPS states how to
Statement implement and enforce the certification policy in the organization.
vi Module 2: Designing a Certification Authority Hierarchy
Lesson: Analyzing Design Requirements

This lesson discusses how you can analyze design requirements, and design a
CA hierarchy that can meet those requirements. Focus on how each requirement
affects the ultimate design of the CA hierarchy.
Recommendations for Tell the students that these recommendations are just a few ways that they can
Meeting Security meet security requirements. To generate an interesting discussion, ask the
Requirements students for other ways the design can meet the security requirements.
Recommendations for List the external access requirements and ask the students to discuss how they
Meeting External Access would meet these requirements. Remind them that there can be multiple ways
Requirements of meeting a requirement.
Recommendations for When you discuss application requirements, present some scenarios and ask
Meeting Application students to provide input. Collect information and discuss the type of
Requirements applications that students use in their organizations.
Recommendations for Tell the students that depending on the administration model of their
Meeting Administration organization, they might have different solutions for meeting administration
Requirements requirements. Have students discuss how they meet administration
requirements for their own organizations. If students are hesitant to discuss their
organization, be prepared to discuss examples from your own experience.
Recommendations for This topic highlights the challenges that CA designers face when they try to
Meeting Availability ensure certificate availability for multiple regions, applications, and users.
Requirements Students may get into a discussion of CA placement in the event of WAN links
being unavailable. If this discussion ensues, ensure that you guide the students
back to the main topic.
Lesson: Designing a CA Hierarchy Structure

This lesson describes how to combine the previous information to decide on the
final structure of the CA hierarchy. Be sure that students understand optimal
CA hierarchy depth, security levels, CA policies and CA management
techniques before they plan a CA hierarchy.
Recommended Depth of Review the different types of CAs. Give some examples for each security level
a CA Hierarchy and discuss the recommended depth of each. Discuss the optimal CA hierarchy
depth and why it is optimal.
Security Levels in the Use the slide to discuss the security level at each layer. Discuss the reasons for
CA Hierarchy an increase or decrease in security at each level. Note that as security decreases,
accessibility must increase, allowing for user and computer access to online
CAs.
Considerations for Explain the table on the slide. Discuss one example of a standalone CA and
Choosing a CA Type enterprise CA. Provide other examples and ask students to choose a CA type for
each example. You can provide the example of Exchange 5.5. Explain that if
students want to use the KMS of Exchange 5.5, they need a
Wiindows Server 2003 standalone CA installed to issue the certificates. This is
an application requirement that determines the CA type.
CA Management Using This is the first mention of the term role separation. Ensure that the students
Role Separation understand the concept and the benefits of implementing role separation.
Provide some examples to explain the concept. Let the students know that they
will learn more about role separation in the following modules.
Module 2: Designing a Certification Authority Hierarchy vii
Guidelines for Designing Emphasize that because there are many factors to consider before students
a CA Hierarchy create a CA design, they must collect all the required information, verify the
information, identify how to meet those requirements, and study the impact on
the CA hierarchy design before finalizing the design.
Lab A Lab A is a design lab. Consider divining the class into groups of three to four
students to discuss the lab contents. AT the end of the lab, have each group
present their answers. Spend extra time reviewing each of the proposed CA
hierarchies. Remember that any answer can be correct, as long as the students
back up the design with appropriate business, technical, or security criteria.
Lab A: Designing a CA Hierarchy

In this lab, the students design a CA hierarchy that meets the requirements that
are presented in the lab material.
In this lab, the students:
! Identify CA hierarchy design requirements.
! Analyze CA hierarchy technical and business requirements.
! Design a CA hierarchy to meet technical and business requirements.
If you divide the classroom into groups of three or four students, ensure that
you do not allow the lab to take longer than the prescribed 60 minutes. Leave
sufficient time to discuss each group’s answers to the lab questions.
If autoenrollment fails, verify the following:
! That the AutoenrollUsers group is assigned Read, Enroll, and Autoenroll
permissions.
! That there are two AutoComputer certificate templates published at the
enterprise subordinate CA.
! That the Autoenrollment GPO exists.
! That the Autoenrollment GPO is correctly defined to enable all
autoenrollment options for users, not computers.
! That the Autoenrollment GPO is linked to the Module06 organizational unit
(OU).
Lab Setup
There are no lab setup requirements that affect replication or customization.
Lab Results
There are no configuration changes on student computers that affect replication
or customization.
Module 2: Designing a Certification Authority Hierarchy 1
Overview

Introduction Designing a certification authority (CA) hierarchy is the first step that you
perform when you design a public key infrastructure (PKI). It is also the most
critical step because without CAs, you cannot deploy the certificates that are
required for PKI-enabled applications. A CA issues certificates, uses certificate
templates, and provides an enrollment target for all certificate-based functions.
The CA hierarchy that you design must meet all business requirements of your
organization.
! Identify requirements for designing a CA hierarchy.
! Describe common CA hierarchy designs.
! Describe policies and documents for specifying the legal requirements of a
CA hierarchy design.
! Identify the impact of design requirements and determine design changes to
a CA hierarchy design.
! Design a CA hierarchy to meet business requirements.
2 Module 2: Designing a Certification Authority Hierarchy
Lesson: Identifying CA Hierarchy Design Requirements

Introduction To support PKI-enabled applications in your organization, you must design and
implement a CA hierarchy. Begin by determining the certificate requirements
for your organization.
! Identify the scope of a CA hierarchy.
! Identify applications that use a PKI.
! Identify the accounts that use PKI-enabled applications.
! Identify business and technical requirements for designing a CA hierarchy.
Project Scope

Introduction After you assess your organization’s technical and business requirements,
determine the optimal CA hierarchy to meet these requirements. Your CA
hierarchy design may include the entire hierarchy or, if a PKI already exists for
your organization, only a portion of the CA hierarchy.
By determining the scope of the CA hierarchy design before you develop it, you
can determine whether it will meet your business or technical requirements.
Scope dependencies The scope of the CA hierarchy design depends upon:
! The CA management strategy implemented by your organization. In a
centralized strategy, a central team may define the design, with little input
from other stakeholders. In a decentralized strategy, separate departments
may define the design for their portions of the CA hierarchy, which a central
design team then organizes into one hierarchy.
! The prior existence of a PKI in your organization. If a PKI exists, the
technical requirements will include modifications to the existing PKI to
support the new project. Modifications can include changing permissions,
issuing different certificates, or adding new CAs to the hierarchy.
Applications that Use a PKI

Introduction Before you design a public key infrastructure, identify the information that you
want to protect and the cost of implementing a strong security system in your
organization. If your organization requires electronic purchasing, secure e-mail,
secure connections for roaming users, or digital signing of files, configure CAs
to issue and manage certificates for each of these business solutions.
PKI-enabled A Microsoft® Windows Server™ 2003 PKI supports the following types of PKI-
applications enabled applications:
! Digital signatures. Secures Internet transactions by encrypting and
decrypting messages, authenticate the account from which the message was
sent and confirm that the content received is identical to the content that was
sent.
! Smart card logon. Implements two-factor authentication. Provide a smart
card and a PIN to verify your credentials on the network.
! Secure e-mail. Provides confidential communication, data integrity, and
non-repudiation for e-mail messages. You can enhance e-mail security by
using certificates to verify a sender’s credentials, the point of origin of a
message, and the authenticity of a message.
! Software code signing. Protects computers from installation of unauthorized
ActiveX® controls or Java applets. Authenticode technology enables
software publishers to digitally sign any form of active content, including
multiple-file archives.
! IP security. Allows encrypted and digitally-signed communication to pass
between two computers or between a computer and a router over a public
network.
! 802.1x. Allows only authenticated users to access a network and protects the
data that is transmitted across a network. An Institute of Electrical and
Electronics Engineers, Inc. (IEEE) standard, 802.1x in PKI provides
centralized user identification, authentication, dynamic key management,
and accounting to grant authenticated network access to 802.11 wireless
networks and wired Ethernet networks.
! Software restriction policy. Enables you to identify the programs that can
run on a computer by performing a digital hash function on the binary code
of applications.
! Internet authentication. Authenticates the client and server for transactions
in a client-server transmission. For example, when you use SSL, or Secure
Sockets Layer encryption, a client authenticates the Web server by
validating the certificates that the server presents.
! Encrypting File System. Encrypts data. To recover EFS-encrypted data, you
can implement key recovery or data recovery, or both. To perform key
recovery, you recover the user’s private key from a Windows 2003
enterprise CA database and import it into any user’s certificate store that
allows the decryption of all encrypted files. To perform data recovery, you
implement EFS recovery agents, which cannot access a user’s private key.
They can only access the randomly-generated file encryption key.
Which Accounts Use PKI-Enabled Applications?

Introduction After you identify the applications that you want to secure by using a PKI,
determine the security principals that will use these applications. Security
principals are user accounts, computer accounts, and service accounts. You
must issue digital certificates to the security principals for each required
application.
Who uses the Several types of accounts can obtain digital certificates in a Windows 2003
applications? Server network:
! Users. When a digital certificate is issued to a user, it uniquely identifies the
user to a PKI-enabled application. The user may obtain one or more digital
certificates for different purposes on the network.
! Computers. When a digital certificate, also known as a machine certificate,
is issued to a computer, it uniquely identifies the computer to a PKI-enabled
application. A digital certificate is typically used to authenticate a computer
with other computers or users. A computer may obtain one digital certificate
that is enabled for multiple purposes or several digital certificates, one for
each purpose on the network.
! Services. When a digital certificate is issued to a service, it uniquely
identifies the service when the service participates on the network. The
digital certificate authenticates the service with computers, users, or other
services, and also provides encryption services if the service must encrypt
transmitted data.
Note Certificates are not issued directly to services. A certificate is issued

either to the computer account that hosts the service, for example, Microsoft
Internet Information Services (IIS), or to a user account that is used by the
service, for example, the EFS Recovery Agent.
How to Identify Technical Requirements

Introduction Technical requirements influence your CA hierarchy design by defining how
the technology must be implemented. For example, a technical requirement
may define the minimum specifications for servers that act as CAs on a
network.
Common technical requirements that affect CA hierarchy design include
security requirements, administration requirements, and availability
requirements.
Security requirements A CA hierarchy design must enforce an organization’s security policy and any
security policy requirements of external partners. You can enforce the security
policy by implementing additional security measures, such as installing
hardware storage modules for a public and private key pair (commonly known
as a key pair) on a CA, or by defining a certification practice statement.
Administration Administration requirements also affect your design. A centralized
requirements administration model requires one central CA. A decentralized administration
model requires additional CAs to delegate specific administration tasks.
Availability The security requirements and the design of the issuing CAs determine the total
requirements number of CAs that an organization requires. For example, if your organization
is geographically dispersed, you can publish a certificate template on CAs that
are located at each hub site on the network. This way, the certificate template is
available in each geographic location for computer or user certificate requests.
How to Identify Business Requirements

Introduction The business requirements for designing a PKI include internal and external
access requirements, availability requirements, and legal requirements. Identify
other critical factors, including the applications and users of PKI-enabled
applications. For example, if users use an application at all times, require that it
is available 24 hours a day, 7 days a week and that the PKI is available at all
times to provide certificate services.
External access To issue certificates to partners, ensure that at least one CA is accessible from
requirements the Internet. You can use Microsoft Internet Security and Acceleration (ISA)
Server to implement Web publishing and to authenticate partners with Active
Directory and enable them to connect to an enterprise CA on the private
network.
If the certificates that your CA hierarchy issues are used on external networks,
ensure that your design also includes publication of certificate revocation lists
(CRLs) and CA certificates to externally accessible locations for certificate
validation. The external clients must verify that the issued certificates and CA
certificates are valid whenever a certificate is presented for authentication or
encryption services.
Note For more information about certificate validation, see the white paper,
Troubleshooting Certificate Status and Revocation, under Additional Reading
on the Web page on the Student Materials compact disc.
Availability Availability requirements can affect your CA design in two ways:

requirements
! When an application must be available 24 hours a day, 7 days a week,
ensure that the certificate template is issued by at least two CAs in the CA
hierarchy so that if one CA is unavailable, the second CA can issue
certificates.
! To make certificates available locally, place the CAs at remote offices or
remote hub locations. This design will reduce the amount of wide area
network (WAN) traffic that certificate enrollment, validation, and renewal
causes.
Legal requirements Certification authorities must inform certificate holders and requestors about
any legal requirements and obligations for certificate use of issued certificates.
By defining certification practice statements, an organization can define legal
requirements for certificate enrollment, use, and revocation.
You can also use a certification practice statement (CPS) to define the liability
of an organization in the event of a breach of security. A CPS defines the
maximum liability of host organizations.
Lesson: Common CA Hierarchy Designs

Introduction There are several types of CA hierarchy designs. A CA hierarchy design
depends on the requirements, structure, location, and processes of an
organization.
Lesson objectives After completing this lesson, you will be able to design CA hierarchies based
on:
! Certificate use
! Geography
! Departments
! Organizational structure
CA Hierarchy Based on Certificate Use

Introduction A certificate use hierarchy implements separate issuing CAs for each type of
service or application that is deployed on the network and requires certificates.
The issuing CA for that service or application publishes all certificate templates
related to that service or application For example, you can issue e-mail
encryption and signature certificates from a common Secure/Multipurpose
Internet Mail Extensions (S/MIME) CA.
Similarly, you can issue Basic EFS certificates and EFS Recovery Agent
certificates from an EFS CA. You can also issue User, Computer, and IPSec
certificates for a Remote Access Services (RAS) CA.
By using a CA hierarchy design based on certificate use, you can separate
certificate manager responsibilities. For example, you can assign different
managers for e-mail certificates and remote access certificates. You can also
implement different issuance requirements at each issuing CA to meet any legal
requirements required for a specific certificate type.
Example As shown in the preceding illustration, the root CA is at the top of the hierarchy
and has a self-signed certificate. A policy CA below the root CA enforces the
certificate policies of the organization.
Below the policy CA are a series of issuing CAs, which:
! Issue certificates directly to users and computers.
! Are organized by the type of service or application that requires certificates.
CA Hierarchy Based on Location

Introduction When you configure a CA hierarchy by location, you issue certificates
according to the location of external users or business partners. You may want
to issue certificates based on location because of:
! Legal requirements to manage all PKI activities in the country where the
certificate holders exist.
! Business requirements for CA availability in the event of WAN failure.
Example To localize the distribution, management, and enrollment of certificates, you

can create issuing CAs based on geographic region. For example, if your
organization has network hub sites in Canada, the United States, and India, you
can deploy separate issuing CAs for each location. Each region’s CA would
allow computers and users to access local CAs for all certificate requests.
CA Hierarchy Based on Departments

Introduction When you configure a CA hierarchy by department, you delegate the
administration of CAs to specific individuals in each department. Typically,
highly decentralized organizations use this design to delegate the administration
of network services to specific departments, yet maintain a centralized PKI for
the entire organization.
Example To delegate the administration of CAs and certificates to individual
departments, create issuing CAs based on departments. In the example in the
slide, administration responsibilities are delegated to the Manufacturing,
Engineering, and Accounting departments. Each department’s CA issues only
the certificates that are related to the PKI-enabled applications running in that
department.
Note If the departments implement differing issuance requirements, each

department may also require its own policy CA to specify the certificate
policies each department has implemented. If multiple departments share the
same issuance requirements, their departmental CAs may be subordinate to a
common policy CA.
CA Hierarchy Based on Organizational Structure

Introduction An organizational CA hierarchy is based on the categories of users that request
certificates in a PKI. In this model, subordinate CAs are organized by the type
of business relationship that users have with an organization, such as
employees, independent contractors, and external business partners.
Example In the slide, the issuing policy is based on these three types of user accounts.
This design ensures that the organization applies strong security methods to all
three types of users.
To separate the certificates in an organization’s PKI, create separate CAs for
each user type. Individuals can then obtain only certificates from CAs that issue
certificates to their employee classification.
An organizational CA structure also enables you to enforce different issuance
requirements for employees versus contractors or partners. For example, your
organization may require that a partner submit government-issued identification
before it issues a certificate. In contrast, an employee must only provide her
network credentials.
Lesson: Documenting Legal Requirements

Introduction To provide the required level of security, your PKI design must specify how it
supports procedures and practices for the organization’s system of
administrative authority.
Although the IT department is responsible for setting and maintaining PKI
policies and practices, be sure to involve representatives from other
departments, including human resources, finance, legal, and marketing, when
you establish certificate policies. The legal and financial uses of a PKI make
these departments stakeholders.
After completing this lesson, you will be able to:
! Identify the steps for designing legal requirements for a PKI.
! Describe the functions and components of a security policy, a certificate
policy, and a certification practice statement.
Steps for Designing Legal Requirements

Introduction Define the legal requirements in your organization for using certificates that are
issued by CAs. The legal requirements are published in the organization’s
security policy, the certificate policy, and certification practice statements
(CPS).
Note Your organization’s legal department must review all three documents
produced in this process: the security policy, the certificate policy, and the
certification practice statement.
Steps to define the legal To define legal requirements:

requirements
1. Develop your organization’s security policy. The security policy is a
confidential written document that defines an organization’s attitude toward
security. It defines how security is applied to resources and services on the
organization’s network.
2. Create the certificate policy. The certificate policy is a written document
that defines how an organization will issue and use certificates, what
measures it will use to validate the subject of the certificate, and the legal
requirements it must comply with to use certificates that its PKI issues. The
certificate policy can be a confidential document, or it can be a standards
document that describes the issuance requirements for certificates that are
used between organizations.
3. Create the certification practice statement. The CPS is a statement of
practices that a CA uses to issue, revoke, and manage certificates. It
describes how an organization’s certificate policy is applied to the
organization’s PKI system architecture and operating procedures.
Note A CPS can support one or more certificate policies. For each
certificate policy, the CPS must define how it supports the certificate policy
and provide any details that are not in the certificate policy.
4. Publish the CPS on a CA. The CPS must be available to all users and
computers that acquire certificates from your PKI. To make the CPS
available, publish it on one or more CAs in the CA hierarchy. Based on the
types of certificates that the CA issues and to whom, different certification
practice statements may exist on each CA in the hierarchy.
Note A CPS that is published on a policy CA affects the policy CA and any
subordinate CAs. If the same CPS is effective for all of the CAs, deploy the
CPS only on the policy CA.
Security Policy

Introduction When designing a PKI, record the decisions that you make. You can use this
record to assist you in future planning and to communicate with external
businesses. For example, this record can include information about how to use a
CA and its certificates, the degree of trust that can be placed in these
certificates, and the legal liabilities if the trust is broken.
Security policy A security policy is a high-level document that the corporate IT group creates
that defines the rules for using security services in the organization. It reflects
the organization’s business and IT strategy and defines its security goals. To
create a security policy document for your organization, find answers to the
following questions:
! What are the organization’s security concerns? For example, is it concerned
about loss of data, vandalized Web sites, or computer viruses?
! How does the organization value data? For example, does some data require
higher security than other data?
! What resources does the organization value most, and how does it secure
those resources?
The security policy document must also answer high-level PKI questions, such
as:
! What applications must be secured by using certificates?
! What kind of security services will be offered by using certificates?
Note For more information about security policies and procedures, see RFC
2196, Site Security Handbook, at http://www.ietf.org/rfc/rfc2196.txt.
Certificate Policy

Introduction When a certificate is issued, it includes a statement to the certificate user that a
particular public key is bound to a certificate subject. A certificate policy
describes how the subject—a user, computer, or network device—is verified
before a certificate is issued to that subject, and how the subject can use the
certificate and key pair for transactions.
Certificate policy A certificate policy can include the following information:
! The user identification process. Establishes how a user is identified. For
example, must the user meet in person or only provide his network
credentials?
! Private key management requirements. Identifies where the private key is
stored. For example, is the private key stored on smart cards, other hardware
devices, or on the local computer? The policy can also define if the private
key can be exported or archived.
! The process for responding to lost or compromised private keys. Dictates
who is responsible for the loss of private keys if they are compromised, and
identifies the process to implement if a private key is lost or compromised.
! Certificate enrollment and renewal requirements. Establishes what
identification a user must present in person, and whether a meeting in
person is required again to renew a certificate.
! The maximum dollar value for transactions. Identifies the highest monetary
amount that is allowed when a digital signature is used to sign purchase
orders. For example, a certificate policy may limit transactions to no more
than U.S. $10,000.
Note The United States Department of Defense (DoD) defines its required
certificate policies in the report, X.509 Security Policy for the U.S. Department
of Defense, at http://www.c3i.osd.mil/org/sio/ia/pki/
DoD_CP_V60_31May2002.pdf. Each certificate policy describes the
identification methods that DoD uses to validate the identity of the certificate
requestor, the types of transactions that it allows, and the storage requirements
for each certificate policy.
Certification Practice Statement

Introduction A certification practice statement (CPS) is a statement about the practices that
the CA uses when it issues certificates. It describes how an organization’s
certificate policy is applied to the organization’s PKI system architecture and
operating procedures. The CPS translates certificate policies into operational
procedures on the CA level. A certificate policy discusses certificate
management; the CPS discusses CA management.
Certification practice You can include the following sections in a certification practice statement. All
statement of these sections are not required in your organization’s CPS, but it is
recommended that the author of your CPS uses these topics as a guideline.
! Introduction. Identifies the users, computers, or services that request
certificates and the applications that follow the CPS. It also provides contact
information for the organization.
! General Provisions. Provides information about the organization’s
obligations, liability, and financial responsibility. This section can also
describe how compliance audits are performed to ensure that the CPS is
followed.
! Identification and Authentication. Details how a local registration authority
(LRA) identifies the subject of the certificate for initial certificate issuance
and for certificate renewal.
! Operational Requirements. Describes the operational requirements of the
CA, such as certificate issuance, certificate revocation, certificate audit, key
archival, and disaster recovery.
! Physical, Procedural, and Personnel Security Controls. Defines in general
terms the security controls that the CA implements. This section provides
assurances to the requestors that the CA operations are secured.
! Technical Security Controls. Describes the security measures to protect the

CA’s private key and provides technical information about the security
measures.
Note Do not provide too much information in this section about security
controls so that the CA is not open to attack or compromised.
! Certificate and CRL Profile. Identifies the versions of certificates and CRLs
that the PKI supports. This section also details what extensions are
implemented by the CA, and whether the extensions are marked as critical.
! Specification Administration. Describes how the organization will maintain
the CPS. It includes change procedures, publication procedures, and
approval procedures.
Note For more information about each recommended section of the CPS, see
RFC 2527 “Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework,” under Additional Reading on the Web
page on the Student Materials compact disc.
Publish the CPS publicly on the Internet or to a location that is accessible to all
certificate holders. Every certificate that a CA issues that implements the
issuance procedures that are described in a CPS should include a URL in the
certificate that directs people to the public document. You can publish the CPS
at a higher level of the CA hierarchy, such as on the Policy CA. The CPS is still
effective for the subordinate CAs and their issued certificates.
Note You designate the location of your CPSs by creating a CAPolicy.inf file
and copying it to the CA’s system directory before the CA is installed or
renewed. For more information about a CAPolicy.inf file, see Module 3,
“Creating a Certification Authority Hierarchy,” in Course 2821, Designing and
Lesson: Analyzing Design Requirements

Introduction After you identify your organization’s requirements for security, external
access, applications, administration, and availability, determine their impact on
your CA hierarchy design and the design changes that you must make to meet
the requirements.
! Identify how security requirements influence a CA hierarchy design.
! Identify how external access requirements influence a CA hierarchy design.
! Identify how application requirements influence a CA hierarchy design.
! Identify how administration requirements influence a CA hierarchy design.
! Identify how availability requirements influence a CA hierarchy design.
Recommendations for Meeting Security Requirements

Introduction Security requirements for CAs can affect where the CAs are physically located
on the network, how they are connected to the network, and where their private
keys are stored. The level of security can result in the CA being removed from
the network or made available to network users over the network, but not
physically available.
Root and policy CA The root CA is the most important CA in your hierarchy. If it is compromised,
security every other CA and certificate in your hierarchy is compromised. You can
enhance the security of the root CA by keeping it disconnected from the
network and using subordinate CAs to issue certificates to other subordinate
CAs or to end users. Likewise, you must protect policy CAs from attack. A
policy CA defines the practices and procedures that you use when you deploy
certificates to users and computers.
To secure your root CA and policy CA:
! Install them by using a standalone CA.
! Remove them from the network.
! Store them in a physically secure location, such as a safe or a secured server
room.
! Install them on a removable disk and store the disk in a secure location.
Issuing CA security To secure issuing CAs, place the CA in a secured server room, preferably one
that requires security card access to enter the room. Further enhance their
security by taking the following actions:
! Limit the number of services that are installed on the issuing CA and disable
any unused services on the issuing CA. These measures will reduce
additional connections to the CA for other services that are installed on it
and prevent attackers from exploiting known vulnerabilities in those
services.
! Dedicate a server running Windows 2003 Server, Enterprise Edition to
function as the issuing CA. This way, improperly configured applications or
services will not compromise the security of the CA. The only security
configuration that you must implement is that of the CA.
Private key protection Depending on the security requirements of your organization, you can protect
the private keys of computers, users, and CAs by implementing any of the
following cryptographic service providers (CSPs):
! Software CSPs. Key pairs are stored in the protected store of the local
computer. You can strengthen the key pair by using a longer key length for
the root CA, such as 4096 bytes.
! Smart cards or PC card tokens. Key pairs are generated and stored on a
smart card or a PC card token. This storage protects the private key by
providing two-factor authentication. You must have access to the physical
smart card and know the smart card’s PIN to unlock the private key.
! Hardware Security Modules (HSM). Hardware CSPs support a wide range
of cryptographic operations and technologies. Keys that are stored in
hardware cryptographic devices can have longer lifetimes than keys that are
stored on hard disks by software CSPs because the tamper-resistant
hardware crypto-devices are more secure.
Another advantage of using hardware CSPs is that the key material is kept
outside of the computer’s memory and within the hardware device. This makes
it impossible to access the CA’s key by causing a memory dump.
Different issuance If different issuance requirements exist for similar certificates, you must create
requirements individual certificate templates for each issuance requirement. For example, you
can have different issuance requirements for fulltime employees and
contractors. If you issue a smart card to fulltime employees when they join the
organization, all other certificates that they request require that they sign the
request by using their smart card. For contractors, the certificate will be issued
only after a meeting in person. Implementing different issuance requirements
requires separate certificate templates, which can be issued from different CAs
in the hierarchy.
Recommendations for Meeting External Access Requirements

Introduction When you design your CA hierarchy, determine whether the certificates that the
CA hierarchy issues must be validated externally. If the certificates are
presented to users or computers outside of your organization, your design must
provide access to CRLs and AIAs to allow the external computers to validate
the certificates. The design can range from placing a CA in a place that users or
computers can access over the Internet, to publishing CRLs and CA certificates
to externally accessible locations.
Recognition of Many applications that depend on PKI require external clients to recognize the
certificates by external certificates that your PKI hierarchy issues. To make CA certificates and CRLs
clients available to external clients:
! Implement a CA hierarchy that uses a commercial CA from a third party. If
the commercial CA is trusted by other organizations, your certificates are
trusted by chaining your server certificate to the commercial CA.
! Cross-certify your CA hierarchy with that of another organization. You can
then trust all certificates that the partner organization issues that can cross
the trust between the CA hierarchies.
! Define qualified subordination between your CA hierarchy and that of
another organization. Qualified subordination defines constraints on the
certificates that the other organization issues, which results in limiting the
certificates that your organization will trust.
! Publish the CA certificate and CRL data to external distribution points. By
trusting your organization’s root CA, external clients can access the
distribution points from the external network and validate issued
certificates.
Management of You can manage certificates that are issued by private CAs more easily than
certificates issued to certificates that are issued by external CAs. Even if you issue certificates from a
external users private PKI, you must still publish the CA certificates and CRLs to a
publication point that is available to the external network if you want external
computers to be able to access them. You must add external Authority
Information Access (AIA) and CRL distribution point (CDP) locations that are
accessible from the public network, and manually publish the CA certificate
and CRLs to those locations. This is true for all CAs in the CA hierarchy—from
the CA that issues the certificates to the root CA.
You can have total control of the certificates that are issued by private CAs.
These CAs offer you the advantage of immediately revoking a certificate if a
user or computer does not follow the revocation policy that is included in your
CPS. In contrast, a commercial CA may not be responsive to a request to
revoke an external user’s certificate.
Trust certificates from External clients can only trust certificates that are issued from your PKI
another organization hierarchy if the external organization trusts your root CA. You can trust
externally issued certificates by implementing:
! Certificate trust lists. Defines which certification authorities you trust in
another organization, what purposes you can use certificates for, and how
long you will trust the certificates.
! Cross certification. Enables two CA hierarchies to trust certificates that are
issued by the other CA hierarchy.
! Qualified subordination between the two organizations. Like cross
certification, qualified subordination enables two CA hierarchies to trust
certificates that are issued by the other CA hierarchy. The difference is that
you can apply constraints to the relationship when you use qualified
subordination.
Note For more information about cross certification and qualified

subordination, see Module 8, “Configuring Trust Between Organizations,” in
Recommendations for Meeting Application Requirements

Introduction Before you configure certificate services for your public key infrastructure,
define your organization’s application needs. For example, determine if your
organization requires electronic purchasing, secure e-mail, secure connections
for roaming users, or digital signing of files. If so, configure CAs to issue and
manage certificates for each of these applications.
Application The following application requirements may affect your CA hierarchy design:
requirements
! Minimizing the number of issued certificates. Create multiple-use certificate
templates. The user can use a single certificate for multiple applications.
This is only possible if you can define common applications that all users or
a large subset of users will utilize.
! Minimizing the number of CAs. Do not implement a separate CA for each
certificate that you want to issue. Consider publishing multiple certificate
templates on a single CA. For example, you can publish all application-
related certificates on one CA.
! Managing CAs based on applications. To delegate the management of
certificates for a specific application, create a dedicated CA for the issuance
of the certificates. Your organization can designate administrators—called
certificate managers—to manage the certificates.
Note The second and third requirements may cause actions that are in conflict.
If you arrive at conflicting design decisions, refer to your organization’s
security policy to determine which action to take.
Recommendations for Meeting Administration Requirements

Introduction You select the administration model for your PKI based on the number and
location of certificate users and CAs—in addition to your organization’s
business requirements and how your organization delegates responsibility for
IT administration.
Typically, organizations deploy either a delegated or centralized administration
model. The model that your organization deploys will affect how CAs are
organized and physically located in your CA design.
Delegated In a delegated administration scenario, you can:
administration
! Place CAs at the same locations as the administrative staff. You can prevent
remote administration by placing CAs at the same locations as the
administrative staff. Local administration is possible when the CA is local to
the administrative staff.
! Implement issuing CAs based on the existing project teams. Each project
team may have one or more CAs in the hierarchy that are dedicated to
issuing certificates for its projects.
! Implement role separation. Role separation enables you to designate CA
administrators, certificate managers, auditors, and backup operators on a
CA-by-CA basis.
Centralized You may make some of the following design decisions to support centralized
administration administration:
! Prohibit remote administration of the CAs. You can modify the user rights
on the CA to prevent CA administrators or certificate managers from
connecting remotely. Likewise, you can configure terminal services to
prevent remote connections by CA administrators or certificate managers.
! Place CAs in secure physical locations. Place the CAs in a centralized and
secure location, such as a server room with key card access, that limits
access by CA administrators and certificate managers.
! Deploy fewer CAs and place them at major hubs of the network. It is not
necessary to deploy additional CAs to remote sites to enable remote
administration. Instead, your design can have fewer CAs, located at major
hubs of the network.
Some organizations may base their trust hierarchy on the organizational

structure of their organization. In this model, the CAs that are directly
subordinate to the root CA are organized by the type of business relationship
that users have with the organization, such as customers, partners, or
employees.
For example, an organization may configure issuing CAs to support different
types of business relationships, such as permanent employees and contractors. It
can base the issuing policy on the organization of user accounts, so that it
applies stronger security measures to independent contractors, temporary
employees, and external business partners.
Recommendations for Meeting Availability Requirements

Introduction The number of users, computers, and applications that work with certificates
define the availability requirements for your CA hierarchy design. This number
can be as broad as an entire organization or as narrow as a single user.
Make certificate Using multiple CAs is the best way to ensure that your infrastructure can
templates highly support enterprise scalability and provide high availability. Implementing
available multiple CAs in the CA hierarchy enables you to take a CA offline for
maintenance or backup, which leaves other CAs in the hierarchy to service
certificate requests.
Support multiple regions The physical location of the users, computers, and applications that require
certificates defines the number of geographic regions that your PKI must
support. Your organization may require different certificate solutions for users
in remote offices or who travel frequently than for users who work at the
headquarters. Requirements can also differ based on the geographic location.
For example, consider restricting users in one country from using their
certificates to access data in one of the organization’s business units in another
country. It may be necessary to place a CA in each region to provide for local
issuance and renewal of certificates.
Minimize CA failure To determine the best configuration for your CA infrastructure, evaluate the
following factors in your organization that affect CA capacity, performance,
and scalability:
! The number of certificates that you must issue and renew
! The key lengths of the issuing CA certificates
! The type of hardware that your CAs require
! The number and configuration of the client computers
! The quality of your network connections
For many organizations, CA performance is limited primarily by the amount of

physical storage that is available and the quality of the clients’ network
connectivity to the CA. If too many clients attempt to access your CA over slow
network connections, autoenrollment requests can be delayed.
When you select the server hardware for your CAs, consider the following
information:
! Disk size. Ensure that sufficient disk space exists for the CD to issue
certificates.
! Disk performance. Use a redundant arrays of independent disks (RAID) 5 or
RAID 0+1 that is set for the database volume to provide performance and
fault tolerance.
! Number of volumes. Use separate disks for the database and log files. Use
RAID 1 for the database log files and operating system volume to provide
performance and fault tolerance.
! RAID stripe size. Use a stripe size that is larger than 64 kilobytes (KB).
RAID 5 or RAID 0+1 provides increased rates of enrollment and fault
tolerance in the event of disk failure.
Note Use hardware RAID solutions for CAs. Do not use the software RAID
services that Windows 2003 Server provides.
Lesson: Designing a CA Hierarchy Structure

Introduction After you collect all of the requirements and study their impact on your CA
hierarchy design, you can determine the final structure of your PKI hierarchy
and the other operational details.
In this lesson, you will learn how to plan a CA hierarchy by determining the
hierarchy depth, security levels, CA policies, and by planning role separation
and identifying CA management practices.
! Describe the optimal number of layers for a CA hierarchy.
! Identify the security level of a specific CA hierarchy.
! Select a CA policy.
! Plan role separation for a CA hierarchy.
! Identify best practices for designing a CA hierarchy.
Recommended Depth of a CA Hierarchy

Introduction An ideal PKI hierarchy design divides the responsibility of the CAs into three
roles or levels: root CAs, policy CAs, and issuing CAs. In general, root and
policy CAs are configured to be offline, and issuing CAs are configured to be
online and available to service end-user enrollment requests. Policy CAs are
subordinate to root CAs, and issuing CAs are directly subordinate to policy
CAs.
When you design your CA hierarchy, do not go deeper than 3 or 4 levels.
Greater depth than that does not provide additional security; it only creates
complex and longer certificate chains. Fewer than 3 levels decreases security.
Consider the following to decide on the optimal depth of your CA hierarchy
based on the security requirements of your organization.
Low security The following characteristics describe an organization that has low security
requirements requirements:
! It has a 1-level CA hierarchy with a single root CA, because there are not
many certificate requests.
! It does not require high security because the CA services are not exposed to
the Internet.
! It has lower security requirements for CA security.
Medium security The following characteristics describe an organization that has medium security
! It has a 2-level CA hierarchy with an offline root CA and online
subordinates.
! It must remove only the root CA from the network.
! It requires the availability of multiple issuing CAs on the network, because
of the large number of users.
! Two or more CAs issue each certificate template because of fault tolerance
requirements.
High security The following characteristics describe an organization that has high security
! It has a 3-level or 4-level CA hierarchy with an offline root CA, an offline
subordinate or policy CA, and online issuing subordinates.
! Its employees or external vendors work in several geographic regions.
Security Levels in the CA Hierarchy

Introduction An ideal PKI hierarchy design consists of three levels: root CAs, policy CAs,
and issuing CAs. This approach provides the most secure, flexible, and scalable
enterprise configuration. Security of a CA depends upon its position in the CA
hierarchy. Security is maximized at the root CA and decreases incrementally as
you move away from the root CA.
The root CA has the highest level of trust in a PKI. All certificates that are
chained to the same root CA certificate are considered invalid if the root CA
certificate is compromised. Because of this dependency, take the highest
security measures possible to protect the root CA’s key pair. These measures
can include implementing strong physical security measures or implementing
an hardware security module (HSM) for private key storage.
Ideal PKI hierarchy An ideal PKI hierarchy consists of the following levels of CAs:
design
! A root CA that is configured as a standalone CA and are removed from the
network.
! One or more policy CAs that are configured as standalone CAs and are
removed from the network.
! One or more issuing CAs that are configured as enterprise CAs and are
connected to the network.
Security characteristics The following characteristics describe the security of a root CA:
of a root CA
! A root CA is permanently offline.
! A root CA provides a high level of physical and cryptographic security.
! A root CA supports the largest key size, hardware tokens, and levels two
and three of Federal Information Processing Standards (FIPS) 140-1.
Note FIPS are defined by the Computer Security Resource Center at the
National Institute of Standards and Technology (NIST). The FIPS 140
standards define security requirements for cryptographic modules. You can
view the standards on Computer Security Resource Center Web site at
http://csrc.nist.gov/publications/fips.
As the distance from the root CA increases, the physical and configuration
security requirements decrease for policy CAs and issuing CAs.
Security characteristics The following characteristics describe the security of a policy CA:
of a policy CA
! A policy CA is permanently offline.
! A policy CA may require a hardware storage module for private key
storage, but it may implement a lower FIPS 140-1 level of security, if the
security policy of the organization allows it.
! More than one Policy CA may be required if the organization must
implement different issuance requirements. For example, some countries
may require specific issuance requirements that are not required by other
countries in which the organization operates.
Security characteristics The following characteristics describe the security of an issuing CA:
of an issuing CA
! An issuing CA is a member of the domain.
! An issuing CA is always online, and responds to certificate requests over the
network.
! An issuing CA requires physical security, such as a server room that
requires card key access.
Note To avoid an oversized PKI for smaller environments, you can combine
the first two levels of the hierarchy—the root and policy CAs—into one level.
You can design a single level PKI hierarchy for basic PKI services. If you
remove the root and the policy tiers from the CA hierarchy, the result is a single
point of failure. One CA serves as the root CA, the policy CA, and the issuing
CA. Because the CA must issue certificates, it cannot be taken offline. Security
and flexibility is limited with this type of design.
Considerations for Choosing a CA Type

Introduction Wiindows Server 2003 supports two types of CAs: standalone CAs and
enterprise CAs. Both types can issue certificates to users and computers.
However, there are some important differences between the two types of CAs.
Comparing CA types The following table compares standalone and enterprise CAs.
Standalone CA Enterprise CA
Is typically used for offline CAs, but can also be used as Is typically deployed as an issuing CA that issues
an online CA certificates to users, computers, and services
Does not depend on Active Directory and can be Requires Active Directory as a configuration and
deployed in other environments or in network segments registration database and as a publication point for
where Active Directory cannot be contacted certificates that are issued to users and computers
Supports requests for standard user and computer Defines certificate formats in certificate templates that it
certificates, such as user-authentication certificates and issues
Web-server certificates
Requires that, by default, all certificate requests received Issues or denies certificate requests based on the
by the standalone CA must be issued or denied by a discretionary access control list (DACL) of the requested
certificate manager certificate template
Note You can configure a certificate template to require certificate manager

approval for issuance.
Warning If you decide to change the CA type after you install a CA, you must
first back up the entire database and the key pair, reinstall the CA with the new
CA type by using the same key pair, and then restore the CA database.
CA Management Using Role Separation

Introduction Be sure to define a PKI management model early in the process of designing
your CA hierarchy. To ensure that one administrator cannot manage all aspects
of the PKI or compromise PKI services, separate management roles among
several administrators in your organization. Without role separation, there is no
accountability for an individual who performs all roles of the PKI management.
Criteria for role To create the criteria for separating roles, decide which individuals will perform
separation each of the following tasks:
! Manage the CA configuration
! Issue or revoking certificates
! Configure and view audit logs
! Back up the CA
What is the Common To help determine role separation, you can use the Common Criteria
Criteria specification? specification, which defines security standards for all forms of network security
and includes specifications for managing PKIs.
Note For more information about Common Criteria, see the Common Criteria
Web site at http://www.commoncriteria.org.
The Common Criteria specification is an international standard that provides a

recognized framework for standardizing security. The Common Criteria
specification helps IT professionals:
! Clearly specify their security problem.
! Compare various security solutions for a particular problem.
Role Separation using The specification identifies four roles for PKI management:
Common Criteria
! CA administrator. Configures and manages Certificate Services, designates
certificate managers, and renews CA certificates.
! Certificate manager. Issues and revokes certificates.
! Auditor. Reviews the security event log for success and failure audit events
that are related to Certificate Services.
! Backup Operator. Performs backups of the CA database, the CA
configuration, and the CA’s key pair.
Warning When you implement role separation, the user can be in only one of
the Common Criteria roles. If the user is assigned more than one role, that user
is blocked from performing any Certificate Services management activities.
Guidelines for Designing a CA Hierarchy

Introduction It is critical that you design your CA hierarchy carefully and thoroughly to
avoid costly redesigns. One wrong design decision can lead to redesigning the
entire CA hierarchy and reissuing all certificates. This topic summarizes the
entire lesson in the form of guidelines that you should follow to create a
successful CA hierarchy design.
Guidelines Consider the following when you design your organization’s CA hierarchy:
! First decide how many CAs you require and where to locate them. Collect
the requirements for each CA.
! Select the CA type before you deploy any CA.
! Start at the top and work downwards. Deploy the root CA first. If you
choose to deploy a private root CA, ensure that the root CA is secure.
! To secure the root CA, the most common solution is to keep the root CA
offline. Deploy the root CA in a physically secure location. Do not make the
computer a member of any domain.
! Keep the CA hierarchy 3 to 4 layers deep. More than 4 layers adds
complexities to the CA design that are difficult to manage. Fewer than 3
layers does not ensure high security.
! Define security levels and appropriate CA policies for each CA in your
hierarchy, depending upon design requirements.
! Implement role separation so that one person cannot compromise the
security of your organization’s PKI.
Before you deploy users, computers, and certificates, ensure that:

! You identify all of the PKI-related requirements of your organization.
! Your CA hierarchy design meets all of the requirements.
Lab A: Designing a CA Hierarchy

! Identify CA hierarchy design requirements.
! Analyze CA hierarchy technical and business requirements.
! Design a CA hierarchy to meet technical and business requirements.
Prerequisites Before working on this lab, you must have completed the course setup.
Additional information For more information about designing a CA hierarchy, see the white paper, Best
Practices for Implementing a Microsoft Wiindows Server 2003 Public Key
Infrastructure, under Additional Reading on the Web page on the Student
Materials compact disc.
Scenario Northwind Traders recently hired you as its PKI administrator. You must
analyze the organization’s business and technical requirements to design a CA
hierarchy for the organization. The CA hierarchy must also enforce the security
policy of Northwind Traders.
Estimated time to
complete this lab:
45 minutes
Exercise 1
Identifying Applications and Certificate Holders
Introduction In this exercise, you will determine whether the certificate to support PKI-
enabled applications was issued to users or computers.
Scenario The organization is planning the following projects that require digital
certificates.
! IPSec with certificate-based authentication The Human Resources (HR)
department wants to protect all network transmissions to the HR data server
by using IPSec. The server runs Wiindows Server 2003. The HR department
client computers run either Windows 2000 Professional or Windows XP
Professional.
! EFS The Consulting department wants to implement EFS on the portable
computers of all consultants. The portable computers run Windows XP
Professional and are members of one of the organization’s Active Directory
domains.
! Web-based time tracking system The Payroll department has created a
Web-based time tracking system on the corporate intranet. The Web site
authenticates all employees by using certificate-based authentication. Client
computers in the organization run Windows ME, Windows NT® 4.0
Workstation, Windows 2000 Professional, and Windows XP Professional.
All communications with the time tracking system must be protected against
inspection.
! Customer extranet Web Site Customers will connect to an extranet Web
site that is protected by SSL. User accounts will be stored in a SQL database
for authentication to the Web site.
! Smart card authentication A staged rollout will implement smart cards
for employees. Initially, the smart cards will be optional for interactive
logons, but mandatory for L2TP/IPSec VPN connections. The organization
will issue a Windows XP computer to each employee before it issues a
smart card.
Questions Complete the following table based on the information in the scenario. For each
application, identify whether the certificates that the application implements are
required for users or computers.
Application User certificate Computer certificate
IPSec " #
EFS # "
Web-based time tracking # #
system
Customer extranet Web " #
site
Smart card authentication # #
Exercise 2
Identifying Technical and Business Requirements
In this exercise, you will identify the technical and business requirements of
Northwind Traders. These requirements will determine the design of your CA
hierarchy.
Scenario Northwind Traders is in the process of planning several IT projects that require
digital certificates. When researching the design of the organization’s CA
hierarchy, you identify the following technical and business requirements for
PKI-enabled applications.
! The corporate headquarters is located in Hong Kong. All centralized
network services are managed out of Hong Kong.
! Northwind Traders has regional offices in Lisbon and Mexico City. The
organization delegates all network administration to the remote offices,
where local administration teams manage all aspects of the network.
! The organization implements three domains, one at each network location.
! The network implements a Service Level Agreement (SLA) that requires all
critical network services to be available at all times. The PKI is a critical
network service and must honor the SLA.
! Northwind Traders places a high value on security. A written security policy
exists for the organization. The following sections in the security policy will
influence the design of your CA hierarchy. The security policy requires that:
• Enterprise servers are stored in secure network locations.
• Additional hardware security measures (if available) are implemented to
increase security beyond what the operating system offers.
• Any network identification and encryption technology are protected
against interception and theft. Protection measures include removal from
the network, advanced cryptography devices, and physical security.
! Northwind Traders plans to deploy Microsoft Exchange Server 2003 for all
e-mail services. In addition, the organization will require the
implementation of S/MIME security for selected users in the organization.
These users must be able to exchange secure e-mail with specific partner
organizations.
! The Web-based time tracking system and the customer extranet Web sites
require SSL encryption.
! The organization uses separate administration teams to manage user
accounts and computer accounts. Therefore, the CA hierarchy must support
separate management of user and computer certificates.
! The European Union requires that companies that operate in Europe
implement specific issuance processes for certificates that are used to sign
e-mail messages that are sent between companies. Only users in the Lisbon
office must implement these policies.
Questions 1. Will the organization’s CA hierarchy require offline CAs?

Yes. The organization’s CA hierarchy will require one or two layers to
be offline. Northwind Traders’ security policy mandates that any
network identification and encryption technology are protected against
interception and theft of the root CA’s private keys.
____________________________________________________________
____________________________________________________________
____________________________________________________________
2. What additional security measures are required for the offline CAs?
All CAs must implement hardware storage modules to protect each
CA’s key pair.
____________________________________________________________
____________________________________________________________
____________________________________________________________
3. Are there any external requirements for the CA hierarchy?

Yes. The extranet Web site must be accessible by customers. Also,
partner organizations must be able to recognize the S/MIME
certificates.
____________________________________________________________
____________________________________________________________
____________________________________________________________
4. Is role separation required in your CA hierarchy design? If so, how would

you implement it?
Yes. Role separation is required to manage the CAs. A local
administration team in each regional office will manage the CAs.
____________________________________________________________
____________________________________________________________
____________________________________________________________
5. How many policy CAs are required for the CA hierarchy?

Two. The Lisbon office must implement European Union issuance
requirements for email certificates, which must be stated as a separate
policy CA. A separate policy CA may be used for the other regions.
____________________________________________________________
____________________________________________________________
____________________________________________________________
Exercise 3
Designing a CA Hierarchy
In this exercise, you will design a CA hierarchy for Northwind Traders, based
on the requirements that are presented in Exercise 1 and 2 of this lab.
Scenario The organization is in the process of planning several projects that require
digital certificates. Now that you have gathered and analyzed all technical and
business requirements, you must design the CA hierarchy.
Questions 1. What CA hierarchy design best fits the requirements of the organization?
a. CA hierarchy based on certificate use
b. CA hierarchy based on geography
c. CA hierarchy based on departments
d. Combination of certificate use and geography
d. The CA hierarchy must be based on certificate use, to allow separate
CAs to issue computer and user certificates, and geography, to allow
decentralized administration.
____________________________________________________________
____________________________________________________________
____________________________________________________________
2. If offline CAs are implemented at the first and second levels of the CA
hierarchy, where will you locate the offline CAs?
Locate the offline root and offline subordinate CAs at the Hong Kong
office, because all centralized network services are performed there.
____________________________________________________________
____________________________________________________________
____________________________________________________________
3. Based on the requirements that are presented in this lab, draw your proposed
CA hierarchy for Northwind Traders.
Module 3: Creating a
Hierarchy
Contents
Overview 1
Lesson: Creating an Offline Root CA 2
Lab A: Installing an Offline CA 14
Lesson: Validating Certificates 20
Lesson: Planning CRL Publication 30
Lab B: Publishing CRLs and AIAs 39
Lesson: Installing a Subordinate CA 49
Lab C: Implementing a Subordinate
Enterprise CA 59
respective owners.
Module 3: Creating a Certification Authority Hierarchy iii
Instructor Notes
Presentation: This module introduces students to the process of creating a certification
90 minutes authority (CA) hierarchy based on a CA hierarchy design. Students will learn
how to determine the correct settings and configuration for installing Certificate
Labs: Services, validating certificates, and publishing certificate revocation lists
120 minutes (CRLs).
After completing this module, students will be able to:
! Create an offline root CA.
! Design an infrastructure to validate certificates.
! Design an infrastructure to publish certificate revocation lists.
! Install a subordinate CA.
Required materials To teach this module, you need the following materials:
! Microsoft® PowerPoint® file 2821A_03.ppt
! The multimedia presentation The Certificate Chaining Engine


! Complete the practice and labs.
! Review all demonstrations for this module.
! Review the multimedia presentation The Certificate Chaining Engine.
! Read RFC 2527 for details about designing certificate policies and
certificate practice statements.
! Read the white paper, Best Practices for Implementing a Microsoft
Windows Server 2003 Public Key Infrastructure, under Additional Reading
on the Web page on the Student Materials compact disc for information
about defining the validity period for issued certificates.
! Read the white paper, Troubleshooting Certificate Status and Revocation,
under Additional Reading on the Web page on the Student Materials
compact disc for information about validating paths.
! Read RFC 3280 for more information about certificate attributes and
publishing CRLs.
! View the sample CAPolicy.inf file in Appendix B of the white paper,
Planning and Implementing Cross-Certification and Qualified
Subordination Using Windows Server 2003, under Additional Reading on
the Web page on the Student Materials compact disc.
iv Module 3: Creating a Certification Authority Hierarchy

Lesson: Creating an Offline CA

This section describes the instructional methods for teaching this lesson.
This lesson discusses the procedure for installing Certificate Services as an
offline root CA. Before you teach this lesson, be sure to read the white paper,
Best Practices for Implementing a Windows Server 2003 PKI, under
Additional Reading on the Web page on the Student Materials compact disc.
What Is a CAPolicy.inf Show the students the sample CAPolicy.inf file, which is found in Appendix B
file? of the white paper, Planning and Implementing Cross-Certification and
Qualified Subordination Using Windows Server 2003, under Additional
Reading on the Web page on the Student Materials compact disc. Do not spend
too much time explaining the format of the CAPolicy.inf file. Students will
learn more about this file in a later topic.
Emphasize that CAPolicy.inf is used for both root CAs and subordinate CAs.
The last section of the page explains the configuration settings that are relevant
for non-root CAs.
How to Create a Emphasize that the CAPolicy.inf file must exist in the %Windir% before you
CAPolicy.inf File install Certificate Services.
Guidelines for Spend time describing object identifiers (OIDs) and where to acquire OIDs if
Implementing a the students are unfamiliar with the concept. Some of the students may have
Certificate Practice experience with OIDs from using Simple Network Management Protocol
Statement (SNMP) and Management Information Bases (MIBs).
Emphasize to students that if they plan to issue certificates to external users, or
if the certificates that they issue will be validated by outside organizations,
should not start deploying a PKI until they acquire an OID for their
organization.
Define Settings for an The settings that are described in this topic appear when you run the Certificate
Offline CA Services Installation Wizard. These settings must be known and documented
before you start the wizard to ensure that students provide the correct settings to
the wizard.
Secure an Offline CA Although Hardware Security Modules (HSMs) increase the security of a CA,
Using an HSM they are not required for all CA deployments. An organization’s security policy
and security requirements define the need for an HSM.
If you have Internet access, consider browsing the Chrysalis ITS Web site at
http://www.chrysalis-its.com/trusted_systems/systems_home.htm and the
nCipher Web site at www.ncipher.com to show students examples of HSM
devices.
Module 3: Creating a Certification Authority Hierarchy v
Guidelines for Deploying Spend time reviewing each of the guidelines. Emphasize to students that an
an Offline Root CA incorrect decision during the installation of the root CA may require that they
redeploy the entire PKI.
Lab A In this lab, ensure that the students use the correct naming scheme for the
offline root CA. Also ensure that the students select Offline CA on the Boot
menu, and that they do not perform the lab procedure on the Member Server
partition.
Lesson: Validating Certificates

This lesson emphasizes the purpose and importance of valid certificates.
Students will learn how to plan certificate validation by checking certificate
status, learning about the certificate chaining engine and reasons for certificate
revocation.
How Applications Check Emphasize to students that certificate validation involves more than
Certificate Status determining if the certificate is revoked.
Read the white paper, Troubleshooting Certificate Status and Revocation, under
Additional Reading on the Web page on the Student Materials compact disc
for more information about checking certificate status.
Multimedia: The The multimedia files are installed on the instructor computer. To open a
Certificate Chaining multimedia presentation, click the animation icon on the slide for that
Engine multimedia presentation.
After you view the presentation, prepare students for the Identifying Matching
Rules practice by reviewing the following certificate extensions that the
certificate chaining engine uses:
! AIA (Authority Information Access). Provides information about where to
retrieve the CA certificate.
! CDP (CRL distribution point). Provides information about where to retrieve
the CRL.
! AKI (Authority Key Identifier). Provides information about the CA
certificate that signed the evaluated certificate.
! SKI (Subject Key Identifier). Contains information about the current
certificate.
Practice: Identifying The five certificates for the practice are provided in the
Matching Rules C:\moc\2821\practices\Module3 folder. Ask students to open the five
certificates and record the required information in the appropriate tables.
Students will require up to 30 minutes to complete the practice. Be sure to
review the answers and discuss what matching rules the certificate chaining
engine used for the two certificate chains.
vi Module 3: Creating a Certification Authority Hierarchy
Certificate Validation The certificate chaining engine performs multiple validation tests to ensure that
Tests a presented certificate is valid. Tell the students that any test failure will result
in the certificate chaining engine assigning a penalty to the chain, which could
result in the certificate chaining engine not selecting the chain.
Reasons for Revoking Explain the various reasons for revoking a certificate. Emphasize that although
Certificates CertificateHold enables a certificate to be unrevoked, placing a hold on a
certificate is not recommended, because it becomes difficult to determine if a
certificate was valid at a specific time.
Read RFC 3280 for more information about reasons to revoke a certificate.
Lesson: Planning CRL Publication

In this lesson, students will learn how to plan to publish a CRL by determining
CRL publication intervals and publication points, and by identifying servers
where they can publish CRLs. Students will also learn about the factors to
consider when they determine the frequency of CRL publication.
Types of CRLs Ensure that students understand the difference between base CRLs and delta
CRLs. Do not spend too much time on this topic. Students will learn more
about this later in the lesson.
When discussing delta CRLs in this lesson, emphasize that only computers
running Microsoft Windows® XP or Windows Server™ 2003 recognize delta
CRLs.
How CRLs Are Show students the animated slide. Discuss how the revocation recognition
Published varies if a client computer running Windows 2000 Professional does not
recognize delta CRLs.
Criteria for Planning Planning CRL publication intervals is based on all of the business drivers that
CRL Publication are shown on the slide. Although many students may want to start modifying
Intervals the overlap-related registry settings, emphasize that they should modify these
registry settings only if publication latency is causing problems on their
organization’s network.
Where to Create the Discuss the reasons for choosing the Active Directory® directory service, Web
Publication Points servers, FTP servers, and file servers as publication points. Emphasize that
students will typically use only Lightweight Directory Access Protocol (LDAP)
and HTTP URLs.
Demonstration: How to Review the Certutil.exe syntax that is used in the ModifyAIAandCDP.cmd
Modify CDP and AIA batch file with the students. Created for this course, the batch file automates the
Extensions modification of the CDP and AIA URLs. Spend time reviewing the variables
that are used in the batch file, and where modifications are required.
Lab B At the completion of the lab, verify that students can connect to all of the URLs
that they test in the lab. If a student cannot connect to one of the URLs, verify
that they typed the URL correctly, and that the domain controller’s DNS name
is added to the Local intranet zone in Internet Explorer.
Module 3: Creating a Certification Authority Hierarchy vii
Lesson: Installing a Subordinate CA

In this lesson, students will learn how to install a subordinate CA, submit
requests to online and offline CAs, and configure AIA and CDP extensions for
online CAs. Students will also learn about the permissions that are required to
install a CA, and how to use the PKI Health Tool to validate extensions.
Finally, they will learn how to deploy a Windows Server 2003 enterprise CA in
a Windows 2000 forest.
Permissions for To install an enterprise CA, you must be a local administrator—to install
Installing an Enterprise Certificate Services and to request a machine certificate for the computer—and
CA also be a member of the Enterprise Admins group—to add the CA object in the
Configuration naming context. Consider showing the objects that are created in
the configuration naming context by using the ADSIEdit.msc console on the
Windows Server 2003 Support Tools. Show the objects that are created in the
CDP and AIA containers.
How to Prepare the Before certificates are issued to subordinate CAs, the issuing CA must be
Issuing CA configured with the correct CDP and AIA extensions. Mention that the validity
period of the subordinate CA is based on the validity period of the Subordinate
Certification Authority certificate template and the ValidityPeriodUnit registry
setting that is configured on the issuing CA.
Steps for Installing an Emphasize that the installation process varies when the parent CA is a
Enterprise Subordinate standalone CA and when the parent CA is an enterprise CA. The Subordinate
CA Certification Authority certificate request must be saved to a PKCS #10 file if
the parent CA is a standalone CA. Only when the parent CA is an enterprise CA
can the certificate request be sent directly to the parent CA.
Considerations for Discuss scenarios where the CDP and AIA extensions require modification for
Configuring AIA and an enterprise CA. For example, discuss the publication of the CRL and CA
CDP Extensions certificate to a Web server that is located in a screened subnet.
Demonstration: Using During the demonstration, show students some of the additional options that
the PKI Health Tool they can configure by using the PKI Health Tool, such as the warning intervals
for expiration of a CRL or CA certificate or the viewing of the certificate stores
that are available in Active Directory.
How to Deploy Windows Be sure to explain all of the modifications that students must make to a
Server 2003 PKI in a Windows 2000 forest before they can install a Windows Server 2003 PKI.
Windows 2000 Forest Ensure that students understand that the order in which the modifications are
performed is very important.
Lab C During the lab, ensure that students configure the correct name for the
enterprise subordinate CA. The CA name must be DomainCA (where Domain
refers to the NetBIOS name of their domain—for example,
ThePowerCompanyCA). Students often mistakenly use their computer name
instead of the domain name, or they type DomainCA, in this lab.
Verify that no errors are reported in the PKI Health Tool at the end of the lab.
Students must troubleshoot each error individually. Typically, the error is a
mistyped URL in the ModifyCDPandAIA.cmd command file that is used in
Lab B. Other common errors include not copying the CRL or CA certificate
files to the correct locations and not adding the domain controller’s DNS name
to the Local intranet zone in the default domain policy.
viii Module 3: Creating a Certification Authority Hierarchy
Lab A: Installing an Offline CA

In this lab, students will create the offline root CA for their organization’s CA
hierarchy. They will modify the CApolicy.inf file, install Certificate Services,
and perform some minor post-installation configuration.
Students perform the hands-on labs in pairs. Emphasize that some procedures
are performed at one computer, and not the other computer. For example, the
installation of the offline CA only occurs at the dual-boot computer in the
computer pair.
Lab B: Publishing CRLs and AIAs

In this lab, students will complete the post-installation configuration of the
offline root CA by defining the CDP and AIA extensions for issued certificates.
Students will also publish the CA certificate and CRL information to the
locations that are referred to in the AIA and CDP extensions of issued
certificates.
Lab C: Implementing a Subordinate Enterprise CA

In this lab, students will install a subordinate enterprise CA to the offline root
CA that they created in Lab A. To simulate an offline CA, students will remove
the root CA from the network by unplugging its network cable.
Students will also use the PKI Health Tool from the Windows Server 2003
Resource Kit to validate the CDP and AIA extensions that are configured on the
root CA.
Lab Setup
Setup requirement 1 The labs in this module require the creation of a custom MMC console named
Certificate Management, which is saved on the desktop. To prepare student
computers to meet this requirement, complete Module 1, “Overview of Public
Key Infrastructure,” in Course 2821, Designing and Managing a Windows
Public Key Infrastructure.
Setup requirement 2 The procedures in the three labs in this module are divided between two partner
computers. Ensure that the students perform each procedure on the correct
computer, as designated in the lab manual.
Important The labs in this module are also dependent on the classroom
configuration that is specified in the Customization Information section at the
end of the Automated Classroom Setup Guide for this course.
Module 3: Creating a Certification Authority Hierarchy ix
Lab Results
changes:
Lab A At the completion of Lab A:
! CAPolicy.inf is configured as required and saved in the %Windir% folder.
! The dual-boot computer is configured as an offline root CA for the student
pair’s CA hierarchy.
Lab B At the completion of Lab B:

! Internet Information Services (IIS) is installed on the domain controller.
! The CA certificate and CRL for the offline CA are published in Active
Directory and on the domain controller’s Web site.
! The domain controller’s DNS name is added as a member of the Local
intranet zone in Internet Explorer.
Lab C At the completion of Lab C:

! The domain controller computer is configured as an online subordinate
enterprise CA for the student pair’s CA hierarchy.
! The PKI Health Tool is initialized.
! The member server computer’s Boot menu is configured to use the Member
Server configuration by default.
Module 3: Creating a Certification Authority Hierarchy 1
Overview

Introduction Before you create the certification authority (CA) hierarchy based on your CA
hierarchy design, ensure that you have collected and verified all the required
data and information about your organization. Also ensure that the
infrastructure for installing the CA hierarchy is in place. In this module, you
will learn how to create a CA hierarchy by installing certificate services and
configuring the CAs.
! Create an offline root CA.
! Design an infrastructure to validate certificates.
! Design an infrastructure to publish certificate revocation lists (CRLs).
! Install a subordinate CA.
2 Module 3: Creating a Certification Authority Hierarchy
Lesson: Creating an Offline Root CA

Introduction In a CA hierarchy, there are three types of CAs: root CAs, policy CAs, and
issuing CAs. Typically, you place the root CA offline to enhance the security of
the CA hierarchy.
To create a secure CA hierarchy, you begin by installing Certificate Services
and by installing and configuring an offline root CA. When you install an
offline root CA, you identify the CA attributes, document and publish the legal
requirements of your organization, identify the CA implementation details, and
then secure the offline root CA.
! Explain what a CAPolicy.inf file is.
! Create a CAPolicy.inf file.
! Create and implement a certification practice statement (CPS).
! Determine the required settings for installing an offline root CA.
! Secure an offline root CA by using a Hardware Security Module (HSM).
! List the guidelines for deploying an offline root CA.
What Is a CAPolicy.inf File?

Definition A CAPolicy.inf file is an optional file that is used to configure Certificate
Services. You use it to install and renew root CAs and subordinate CAs. A
CAPolicy.inf file provides:
! Basic information about the CA. For example, it lists distribution points for
the self-signed certificate and defines the implemented certification practice
statement of the CA.
! Information about certificate renewal. For example, it lists the certificate
lifetime of the self-signed certificate.
Before you install the offline root CA, modify the CAPolicy.inf file and then
save it in the %Windir% folder of the root or subordinate CA. For a sample of
the CAPolicy.inf file, see the white paper, Planning and Implementing Cross-
Certification and Qualified Subordination Using Windows Server 2003, under
Important If you use the CAPolicy.inf file to install a CA, also use it for CA
renewal. Otherwise, the previously defined settings may be lost.
What is defined in the In a CAPolicy.inf configuration file, you can define:

CAPolicy.inf file?
! Certification practice statement (CPS). The CPS is a statement about the
practices that CA uses when it issues certificates. The CPS reflects the
organization’s certificate policy and security policy.
! CRL publication intervals. When you install a CA, you can define the
publication intervals for the base certificate revocation list (CRL). The
length of a publication interval depends on the estimated number of
certificates that the CA will revoke, and the role that the CA plays in the CA
hierarchy. For example, an offline root CA has a longer CRL publication
interval than an online issuing CA.
! CA renewal settings. You can define the CA certificate renewal settings,
such as the key length, validity period of the certificate, and whether to re-
use the existing key pair, for an offline CA.
! Key size. When you renew a root CA, the settings in the CAPolicy.inf file
determine the length of the key pair. During installation, the Certificate
Services Installation Wizard defines the length of the key pair.
! Certificate validity period for a root CA. Typically, the validity period for
the root CA is 10-20 years.
Note You do not define the validity period for subordinate CAs in the
CAPolicy.inf file. The CA that issues the subordinate CA certificate defines
the validity period.
! CRL distribution point (CDP) and Authority Information Access (AIA)

paths. Typically, you do not want a root CA certificate to include CDP and
AIA paths for the certificate validation process. By configuring the
following entries in the CAPolicy.inf file, you ensure that the CDP and AIA
extensions are not included in the root CA certificate.
[CRLDistributionPoint]
Empty=True
[AuthorityInformationAccess]
Empty=True
Note Typically, revocation checking is not performed on the root CA

certificate. Instead, the validating computer or application checks only that the
root CA certificate exists in the trusted root CA store. By removing the CRL
and AIA paths from the root CA certificate, you ensure that revocation
checking is not performed on the root CA certificate.
You must use a CAPolicy.inf file to define the following settings for a non-root
CA:
! Certification practice statement
! CRL publication intervals
! CA renewal settings
! Renewal key size
How to Create a CAPolicy.inf File

Introduction A CAPolicy.inf file defines the configuration of certificate services for both
root CAs and subordinate CAs.
How to create a To create a CAPolicy.inf file:
CAPolicy.inf file
1. Ensure that you are logged on to the computer as a local Administrator.
2. In Notepad, create CAPolicy.inf. Use the sample file in Appendix B of the
white paper, Planning and Implementing Cross-Certification and Qualified
Subordination Using Windows Server 2003, as a template. The white paper
is under Additional Reading on the Web page on the Student Materials
compact disc.
3. Save the file to %Windir%\capolicy.inf.
Guidelines for Implementing a Certification Practice Statement

Introduction A CPS describes how an organization’s certificate policy is applied to the
organization’s PKI system architecture and operating procedures. It defines the
rules for enrolling, revoking, and using certificates that are issued by a CA.
Note The format of a CPS is defined in RFC 2527, “Internet X.509 Public Key
Infrastructure Certificate Policy and Certification Practices Framework,” under
You can configure a CAPolicy.inf file to point to a CA’s CPS by using a URL
pointer. You see this CPS when you view the CA certificate and click Issuer
Statement.
Defining certificate In a CAPolicy.inf file, you can define a certification practice statement. The
policies CPS can be valid for one or more certificate policies that are enforced by the
CA and subordinate CAs in the CA hierarchy. Each CPS requires a unique
object identifier (OID), and a policy statement. A policy statement can be a
URL pointer to the policy statement.
Note It is not mandatory that you implement a CPS in the CAPolicy.inf file on
every CA in the CA hierarchy. Typically, you define the CPS at the policy CA
level of the CA hierarchy. If an organization requires different certification
practice statements, you must implement separate policy CAs—one for each
CPS.
What is an OID? An OID is a sequence of numbers that identifies a specific object, such as an
algorithm or attribute type, or a specific policy. When you define the OID for a
policy, you can use either a public OID or a private OID. You can obtain a
public OID from the OID registry. You can obtain publicly recognized OIDs
from the following sources:
! Internet Assigned Numbers Authority (IANA). Issues OIDs for free under the
Private Enterprises branch.
! American National Standards Institute (ANSI). Issues OIDs under the U.S.
Organizations branch. Each OID must be purchased.
! British Standards Institute (BSI). Issues OIDs under the UK Organizations
branch. Each OID must be purchased.
! Other agencies that are on the Internet.
You can generate a private OID after you install Certificate Services on your
network. The Certificate Templates console can issue private OIDs that exist in
the Microsoft OID space. Each forest generates a unique OID within the
Microsoft OID space.
CA Policy format Use the following syntax to define a certificate policy and CPS in the
CAPolicy.inf file:
[PolicyStatementExtension]
Policies = InternalPolicy
[InternalPolicy]
OID = 1.3.3.4.6.6.7.8.9.10
Text = "The internal employees CPS"
URL = "http://www.nwtraders.msft/LegalPolicy/internal.htm"
The [PolicyStatementExtension] section defines all certificate policies that are

defined in a CAPolicy.inf file.
For each certificate policy defined in the [PolicyStatementExtension] section, a
separate policy section must exist. In the policy section, you must define a
unique OID for each certificate policy, text to appear with the CPS, and a URL
that indicates where the CPS may be obtained. Make the URL an HTTP URL
that is accessible from all network locations.
Define Settings for an Offline CA

Introduction Before you install an offline CA, define and document its configuration settings
so that you can rebuild the CA in the event of disaster.
Defining the settings for Define the following settings for an offline CA:
an offline CA
CA Policy. Install an offline root or offline policy CA as a standalone CA to
ensure that the computer can be removed from the network. A standalone CA
does not require that the computer is a domain member or that it has
connectivity to the Active Directory® directory service.
Computer Name. Also called the network basic input/output system (NetBIOS)
name, the computer name cannot be changed after you install Certificate
Services, nor can the computer’s membership in a domain or workgroup be
changed.
CA Name. This setting describes the purpose of the CA. It consists of the
common name and the distinguished name suffix. When you define the CA
Name, you can define the distinguished name suffix as the Lightweight
Directory Access Protocol (LDAP) distinguished name of the forest root
domain. For example, if you want to create a CA named Contoso Ltd Root CA
for the Contoso.msft forest, you define the common name as Contoso Ltd Root
CA and the distinguished name suffix as DC=contoso,DC=msft.
Note Each space in the name uses three characters due to the escape character
sequence (%20). For example, the name My CA is seven characters in length
and is represented as My%20CA.
Cryptographic Service Provider. Windows 2000 Certificate Services ships with

several software cryptographic service providers (CSPs), such as basic, strong,
and enhanced CSPs. The private keys that software CSPs generate are archived
and encrypted in the protected store. You can use a hardware-based CSP to
provide higher-level key protection for a certificate authority’s private key.
Key length. For most root CAs, the largest interoperable key length is 4096 bits.
Exceptions may apply if you use a hardware CSP or smart card to store the CA
key. The longer the signature key length, the greater the CPU utilization during
certificate generation.
Note If you install the Windows Server 2003 CA as a subordinate CA to an

existing third-party CA, ensure that the third-party CA supports the key length
of the Windows Server 2003 CA. Some third-party CAs support key lengths up
to only 2048 bits.
Validity period. When a CA issues a certificate to a user or computer, it ensures

that the validity period of the new certificate falls within the validity period of
its own certificate. Ensure that a CA certificate has a sufficient lifetime so that it
is not necessary to renew the issued certificates frequently. For example, if the
CA certificate has a validity period of six months, you must renew your issued
certificates at least once every six months. If the CA certificate’s lifetime is two
years, you can choose longer validity periods of up to two years.
The lifetime of a certificate that is issued by a Windows standalone CA is one
year by default. For a Windows enterprise CA, it is two years by default.
Because these values may not match your organization’s requirements, set a
registry key to adjust the value.
Note For more information about defining the validity period for issued
certificates, see the section titled “Set the validity period for issued certificates
on the offline root CA” in the white paper, Best Practices for Implementing a
Windows Server 2003 PKI, under Additional Reading on the Web page on the
Student Materials compact disc.
Database and log settings. You can improve the performance of the CA
hierarchy by using separate disks for the database and log files. Using more
physical drives in a redundant array of independent disks (RAID) set also
improves disk write performance.
Store the database on a RAID 5 or RAID 0+1 volume and store the database log
files on a RAID 1 mirror set. Ensure that the database and logs are stored on a
different volume from the operating system.
Secure an Offline CA Using an HSM

Introduction To secure your PKI and maintain the integrity of issued certificates, protect the
root key with the best available physical, technological, and operational
security. For example, to store root keys that you value highly, use specialized
hardware, such as a Hardware Security Module (HSM) that is dedicated to
preventing theft, tampering, and access to the private key, also known as the
secret key.
What is an HSM? A HSM is a dedicated hardware device that works with a host CA server to
provide a secure storage location for the CA’s root key or subordinate CA’s
private keys. HSM is an optional security device that you manage separately.
Note It is not mandatory to deploy an HSM on an offline CA to secure private

and public keys. Determine whether your organization’s security policy and
certificate policy require it.
Features of a HSM An HSM can provide highly secure operations by using multilayered hardware
and software tokens and other key features, including:
! Hardware-based, cryptographic operations. Examples include random
number generation, key generation, digital signatures, and key archival and
recovery.
! Hardware protection of private keys. The private keys are stored on the
HSM device, rather than on the local disk subsystem of the CA, which
separates the keys from the physical computer that hosts the CA.
! Secure management of private keys. All management tasks of the private
keys use the HSM’s CSP. The management occurs in the HSM, which
separates the management tasks from the computer that hosts the HSM.
! Acceleration of cryptographic operations. This feature offloads key
generation from the host server.
! Load balancing and failover in hardware modules. You can provide load
balancing and failover protection by using multiple HSMs that are linked
together.
! Split-key functions. By using an HSM, you can define a pool of certificate
operators, and specify that more than one operator is required for all signing
operations. For example, you can define three certificate operators, and
require two operators to perform all signing operations. This split-key
functionality ensures that a single person cannot perform CA management
tasks.
Secure private keys Consider securing the high value private keys by using HSM. If you store the
private key on the host server’s hard drive or in system memory, an attacker can
copy, delete, or compromise the hard drive if he gains physical control of the
host system. In a key is compromised, you must generate a new private key and
replace all certificates that were signed by using the compromised key. Such a
security breach like can cause significant downtime and replacement costs.
To secure your private keys in Windows Server 2003:
! Permit key generation, storage, and management by using HSMs. All
certificate signing operations are performed exclusively at the HSM.
! Enable all cryptographic functions to be performed within the CSP module
that generated the CA’s private keys.
! Use hardware-based CSPs to move cryptographic operations from host
processors to specialized hardware.
Using secure business If you maintain the root CA in a secure data center or vault, perform the offline
practices CRL publication and transfer the CRL by using multiple trusted personnel.
After you obtain the CRL, you must manually transfer it from the security area
to a location where you can propagate the CRL to the CRL distribution points
(CDPs).
Place the offline root CA server in secured storage until you must do one of the
following:
! Issue or renew a new subordinate CA certificate.
! Issue an updated CRL.
Perform the offline CRL publication several days before the previously issued
CRL expires in case the offline root CA has a hardware or publication failure.
Allow adequate time to publish and replicate the CRL to all CDP locations and
to ensure that you identify and correct any errors or failures.
Guidelines for Deploying an Offline Root CA

Introduction Your organization’s business requirements and processes will determine how
you deploy an offline CA. Use the following guidelines to help you
successfully deploy an offline CA and also reduce redesign and redeployment
time.
Guidelines ! Do not connect the root CA to the network. If you disconnect an offline
stand-alone root CA from the network to provide a secure CA environment,
do not join the computer to the domain.
! Implement empty CDP and AIA extensions for the root CA. Configure
empty CDP and AIA extensions to ensure that the certificate chaining
engine does not perform revocation checking on the root CA certificate. The
only validity check that is performed on the root CA certificate is for
inclusion in the trusted root CA store.
! Implement a hardware CSP or HSM. To make a root CA’s signing keys
more secure, use a hardware CSP or HSM. You can use the Microsoft CA
with any third-party hardware CSP that supports CSPs that are based on
Cryptographic Application Programming Interface (CryptoAPI).
! Choose a key length that all protocols and applications support. Incorporate
larger key lengths and at least 2048 bits. Do not use key lengths greater than
4096 bits as this increases certificate and certificate chain sizes that may not
be supported by all protocols and applications. For example, the storage
structure on many smart cards is too small to successfully store certificates
for large-keyed PKI hierarchies.
! Use a unique distinguished name for the CA. The distinguished name should
identify the purpose of the CA so that your users can easily recognize it.
Make it unique in the PKI community—all computers, users, and services
that will evaluate the certificates that the CA issues. The PKI community
can also include external computers, users, and services, if the certificates
are used on the Internet or between organizations.
! Implement a long validity period. Configure root CAs to have a longer
lifecycle than an online issuing CA, which is typically 10-20 years. A long
validity period reduces the administrative burden of being required to renew
the root CA frequently. Renew the CA certificate every 10 years, and use a
new key pair for every other renewal.
Note Consider these guidelines when deploying any offline CAs, whether the
CA is an offline root CA or an offline subordinate CA.
Lab A: Installing an Offline CA

! Configure CAPolicy.inf for the installation of an offline root CA.
! Install an offline root CA.
may not comply with Microsoft security recommendations. For instance, this
lab does not implement HSM storage of the private key material for the offline
CA.
Prerequisites Before working on this lab, you must have:

! A computer with a dual-boot configuration that can function as both the
offline root CA and the member server for your domain.
! Reviewed the following table.
Computer Domain controller Forest name
DenverCA vancouver.adatum.msft DC=adatum,DC=msft

BrisbaneCA perth.fabrikam.msft DC=fabrikam,DC=msft
BonnCA lisbon.lucernepublish.msft DC=lucernepublish,DC=msft
SantiagoCA lima.litwareinc.msft DC=litwareinc,DC=msft
SingaporeCA bangalore.tailspintoys.msft DC=tailspintoys,DC=msft
TunisCA casablanca.wingtiptoys.msft DC=wingtiptoys,DC=msft
MiamiCA acapulco.thephonecompany.msft DC=thephonecompany,DC=msft
SuvaCA auckland.cpandl.msft DC=cpandl,DC=msft
MoscowCA stockholm.adventureworks.msft DC=adventureworks,DC=msft
MontevideoCA caracas.blueyonderair.msft DC=blueyonderair,DC=msft
TokyoCA manila.woodgrovebank.msft DC=woodgrovebank,DC=msft
NairobiCA khartoum.treyresearch.msft DC=treyresearch,DC=msft
Additional information For more information about deploying a CA hierarchy with

Windows Server 2003, see the white paper, Best Practices for Implementing a
Microsoft Windows Server 2003 Public Key Infrastructure, under Additional
Estimated time to
complete this lab:
30 minutes
Exercise 1
Configuring CAPolicy.inf for installing the Offline Root CA
In this exercise, you will modify CAPolicy.inf to support the installation of the offline root CA for
your forest. You will also publish the Certificate Practice Statement at a predefined location on
your organization’s domain controller.
Scenario
Your organization requires the implementation of a private PKI. You must install an offline CA to
secure the CA hierarchy.
Important: Perform this procedure at the offline CA for your organization.
1. Log on to the root CA by a. Turn on the computer.

using your local b. On the member server, in the Please select the operating system to
administrative account. start list, select Offline CA and then press ENTER.
c. Log on to the Offline CA computer as Administrator with a password
of P@ssw0rd.
d. If the Manage Your Server windows appears, click Don’t display this
page at logon, and then close the window.
2. Copy C:\moc\2821\labfiles\ a. Open C:\moc\2821\labfiles\module3.

module3\CAPolicy.inf to b. Copy CAPolicy.inf to the D:\windows folder.
D:\windows and clear the
Read-only check box. c. Right-click D:\windows\CAPolicy.inf and then click Properties.
d. In the CAPolicy.inf Properties dialog box, ensure that the Read-only
check box is cleared, and then click OK.
3. Make the following changes a. Open D:\windows\CAPolicy.inf.

to the D:\windows\ b. Under [LegalPolicy], change OID to 1.2.3.4.5.6.7.8.9.x (where x is the
CAPolicy.inf file: last octet of your computer’s IP address).
• Change OID to c. Under [Certsrv_server], make the following changes:
1.2.3.4.5.6.7.8.9.x
• Set CrlPeriodUnits to CRLPeriodUnits=26
• Set CrlPeriodUnits to
CRLPeriodUnits=26 • Set CRLPeriod to CRLPeriod=weeks
• Set CRLPeriod to • Set CRLDeltaPeriodUnits to CRLDeltaPeriodUnits=0

CRLPeriod=weeks • Set CRLDeltaPeriod to CRLDeltaPeriod=days
• Change Webserver to d. On the Edit menu, click Replace.
DomainController e. In the Replace dialog box, in the Find what box, type Webserver
f. In the Replace with box, type DomainController (where
DomainController is the fully qualified domain name of your domain
controller from the table at the beginning of the lab), and then click
Replace All.
g. In the Replace dialog box, click Cancel.
(continued)
Why are the CDP and AIA URLs defined as Empty in CAPolicy.inf for an offline root CA?
The CDP and AIA locations are not required for root CA certificates. By defining the CDP and AIA
URLs as empty, you ensure that applications do not check the root CA certificate for revocation.
When does the operating system read CAPolicy.inf?
The operating system reads the CAPolicy.inf file during the initial installation of the offline root CA
and during the renewal of the CA certificate.
4. Save all changes and close a. Save all changes, and then close CAPolicy.inf.
CAPolicy.inf. b. Close all open windows.
Exercise 2
Installing the Offline Root CA
In this exercise, you will install the offline root CA by using the settings in CAPolicy.inf.
Scenario
After you create CApolicy.inf, you must install Certificate Services on the offline root CA as a
standalone root CA.
Important: Perform this procedure at the offline CA for your organization.
1. Open Add or Remove a. Ensure that you are logged on as Administrator with a password of
Programs in Control Panel. P@ssw0rd at the offline root CA.
b. On the Start menu, click Control Panel, and then click Add or
Remove Programs.
2. Install Certificates Services a. In the Add or Remove Programs dialog box, click Add/Remove
with the following options: Windows Components.
• Stand-alone root CA b. In the Windows Components Wizard, in the Components list, select
• CSP: Microsoft Strong the Certificate Services check box.
Cryptographic c. In the Microsoft Certificate Services dialog box, click Yes.
Provider d. On the Windows Components page, click Next.
• Hash algorithm: SHA-1 e. On the CA Type page, click Stand-alone root CA, enable the Use
• Key length: 4096 custom settings to generate the key pair and CA certificate check
• Common Name: box, and then click Next.
Computer f. On the Public and Private Key Pair page, set the following options:
• Distinguished name • CSP: Microsoft Strong Cryptographic Provider
suffix: ForestName • Hash algorithm: SHA-1
• Validity Period: 20 • Key length: 4096
Years
g. On the Public and Private Key Pair page, click Next.
h. On the CA Identifying Information page, enter the following
information:
• Common Name for this CA: Computer (where Computer is the
NetBIOS name of the offline CA from the table at the beginning of
the lab)
• Distinguished name suffix: ForestName (where ForestName is the
LDAP distinguished name of your forest from the table at the
beginning of the lab)
• Validity Period: 20 Years
i. On the CA Identifying Information page, click Next.
(continued)
2. (continued) j. On the Certificate Database Settings page, accept the default settings,
and then click Next.
k. In the Microsoft Certificate Services dialog box, click OK.
l. Insert the Windows Server 2003 Enterprise Edition disk into the
CD-ROM drive, if you have not already done so.
m. On the Completing the Windows Components Wizard page, click
Finish.
n. Close the Add or Remove Programs dialog box.
o. Close all open windows.
Lesson: Validating Certificates

Introduction You can trust a certificate only if it is chained to a trusted root CA. In a PKI,
when you chain a certificate to a trusted root CA, the certificate is considered a
trusted certificate for the operation, subject to other validation tests that the
certificate chaining engine performs.
! List the steps for checking the status of a certificate.
! Describe the certificate chaining engine.
! Describe the importance of certificate validation.
! Identify the reasons for revoking certificates.
How Applications Check Certificate Status

Introduction When a certificate is presented to an application, the application must first
determine the validity of the certificate before the application uses the
certificate to encrypt data or to authenticate the subject of the certificate. Three
distinct but interrelated processes in the CryptoAPI determine a certificate’s
validity. These processes are certificate discovery, path validation, and
revocation checking.
Certificate discovery Certificate discovery is the process of collecting CA certificates from the cache,
Group Policy, enterprise policy, and AIA URLs in issued certificates. All
certificates are cached when the certificates are selected from a store or from a
URL.
Note You cannot modify cache settings or turn off caching.
Path validation Path validation is the validation of all certificates in a certificate chain until the
certificate chain terminates at a trusted, self-signed certificate.
The path validation process ensures that a valid certification path is established
for a given end certificate. A valid certification path is defined as an end-entity
certificate that chains a certificate to a trusted root CA.
Note For more information about path validation, see the white paper,
Revocation checking Each certificate in the certificate chain is checked to verify that none of the
certificates were revoked. Revocation checking can occur either in conjunction
with the chain building process or after the chain is built.
In Windows XP and Windows Server 2003, the certificate chaining engine
checks revocation as the certificate chain is built. In contrast, in Windows 2000,
the certificate chaining engine does not perform revocation checking until the
complete chain is built.
Multimedia: The Certificate Chaining Engine

File location To view the Certificate Chaining Engine presentation, open the Web page on
the Student Materials compact disc, click Multimedia, and then click the title
of the presentation.
Key points ! Applications use the certificate chaining engine to validate a certificate.
! The certificate chaining engine validates each certificate in the chain.
! Validation begins at the computer or user certificate, continues to the
issuing CA certificate, proceeds to the policy CA certificate, and ends at a
self-signed root certificate.
! The certificate chaining engine uses one of three matching techniques to
find the CA certificate of the issuing CA:
• An exact match
• A key match
• A name match
! The type of match that the certificate chaining engine uses depends on
information in a certificate extension called the AKI, or Authority Key
Identifier.
! Multiple chains can exist after the CA renews its certificate, because the
certificate chaining engine matches all previous versions of the CA
certificate by using a name match. The certificate chaining engine builds
and then ranks every possible chain.
! After it calculates every possible chain, the certificate chaining engine ranks
the chains and selects the best certificate chain for an application.
Practice: Identify Matching Rules

Introduction This practice requires you to review the Authority Key Identifier (AKI) and
Subject Key Identifier (SKI) extensions of certificates to determine how the
certificate chaining engine assembles certificate chains.
Note This practice focuses on the concepts in this lesson and as a result may
not comply with Microsoft security recommendations.
Five certificates are provided for you in the C:\moc\2821\practices\module3

folder. Open the five certificates and record the information in the following
tables.
Certificate1.cer Attribute Value
Subject CN = Microsoft Windows Hardware Compatibility

OU = Microsoft Corporation
OU = Microsoft Windows Hardware Compatibility Intermediate
CA
OU = Copyright (c) 1997 Microsoft Corp.
Serial number 19 8b 11 d1 3f 9a 8f fe 69 a0
AKI Certificate Issuer:
CN=Microsoft Root Authority
OU=Microsoft Corporation
OU=Copyright (c) 1997 Microsoft Corp.
Certificate SerialNumber=
00 c1 00 8b 3c 3c 88 11 d1 3e f6 63 ec df 40
SKI n/a
Subject CN = Alice Ciccu, CN = Users, DC = nwtraders, DC = msft

Serial number 61 0a 6b 59 00 00 00 00 00 05
AKI KeyID=11 e5 27 a7 84 71 da c7 f8 37 f8 21 f8 2f bd 94 8e f6 19 ad
SKI 54 a3 39 bc b7 12 90 d6 24 b3 64 65 30 30 53 8c 6e 6f c2 64
Subject CN = RootCA, DC = nwtraders, DC = msft

Serial number 01 5e 26 32 5d eb 8d 90 45 b3 df ef 44 24 01 a9
AKI n/a
SKI 68 39 c2 63 90 d9 58 46 2a 51 54 d8 9d 13 1c f3 1c ab f1 ab
Subject CN = Microsoft Root Authority, OU = Microsoft Corporation,

OU = Copyright (c) 1997 Microsoft Corp.
Serial number 00 c1 00 8b 3c 3c 88 11 d1 3e f6 63 ec df 40
AKI KeyID=5b d0 70 ef 69 72 9e 23 51 7e 14 b2 4d 8e ff cb
Certificate Issuer:
CN=Microsoft Root Authority, OU=Microsoft Corporation,
OU=Copyright (c) 1997 Microsoft Corp.
Certificate SerialNumber=00 c1 00 8b 3c 3c 88 11 d1 3e f6 63 ec
df 40
SKI n/a
Subject CN = IssuingCA, DC = nwtraders, DC = msft

Serial number 61 1f a5 24 00 00 00 00 00 02
AKI KeyID=68 39 c2 63 90 d9 58 46 2a 51 54 d8 9d 13 1c f3 1c ab f1
ab
SKI 11 e5 27 a7 84 71 da c7 f8 37 f8 21 f8 2f bd 94 8e f6 19 ad
Analysis Based on the information in the preceding tables, complete the following
graphic for the two certificate chains and then identify the certificate matching
method that was used to build the chains.
Certificate 3
Certificate 4
Certificate 5
Certificate 1
Certificate 2
Chain building method for Chain 1:

Key match
_______________________________________________________________
_______________________________________________________________
Chain building method for Chain 2:

Exact match
_______________________________________________________________
_______________________________________________________________
Certificate Validation Tests

Introduction Certificate validation is the process of validating a certificate to ensure that the
information in the certificate is authentic and that the certificate is used for its
intended purpose. The operating system performs certificate validation
automatically, and repeats it for each certificate in the certificate chain until it
reaches the root CA certificate.
Certificate validation The operating system performs the following tests on each certificate in the
tests certificate path during the validation process:
! Time validity. The current date and time must fall between the certificate’s
start and expiration dates. A certificate can fail this test when the computer’s
clock is not synchronized with the network’s current time.
Note An expired CA certificate in the certification path does not invalidate

the path. However, it does not provide the best possible path. In a
Windows Server 2003 PKI, a certification path is valid as long as the CA
certificate was valid when the certificate was issued.
! Certificate recognition. A certificate must conform to a valid X.509

standard for digital certificates. The operating system may not recognize the
certificate if the issuing CA does not follow the X.509 standard or if the
certificate is corrupted.
! Certificate contents. The X.509 standard defines some certificate attributes
that a valid certificate must include. If any of the required attributes are
missing or are incorrectly populated, the certificate chaining engine deems
the certificate invalid.
! Signature check. The issuing CA’s private key digitally signs the contents of
all issued certificates. If a digital signature validation fails, it indicates that
either the contents of the certificate were modified after the certificate was
issued or the certificate is corrupt.
! Revocation check. The operating system compares the serial number of the
certificate with all entries in the CA’s CRL to determine if the certificate
was revoked before its validity period expired.
! Root check. The certificate of the issuing CA must be chained to either a
trusted root or be included in a signed certificate trust list (CTL). The
certificate is considered chained to a nontrusted root if neither of these
conditions exist.
! Policy validation. The application may require that a certificate contain
specific certificate policies or application policies. If the certificate does not
include these policies, the certificate cannot be used by the application.
! Critical extensions. If the certificate contains an extension that is marked as
critical, but the application does not know how to implement or use the
extension, the operating system rejects the certificate.
Reasons for Revoking Certificates

Introduction Certificate revocation is the process of removing the validity of a certificate
prematurely. When a certificate manager revokes a certificate, the certificate
manager can specify the reason for revoking the certificate.
Reasons for revocation Use one of the following reason codes when revoking a certificate:
! KeyCompromise. The private key that is associated with the certificate is
compromised and is in the possession of an unauthorized individual—for
example, if a portable computer is stolen or a smart card is lost.
! CACompromise. The smart card or disk on which the CA’s private key is
stored is compromised and is in the possession of an unauthorized
individual. When a certificate manager revokes a CA’s certificate, all
certificates issued by that CA are considered revoked.
! AffiliationChanged. An individual is terminated or has resigned from an
organization. It is not necessary to revoke a certificate when an individual
changes departments, unless your security policy requires that different
certificate are issued by a departmental CA.
! Superseded. A new certificate must be issued if a smart card fails or the
legal name of a user has changed. The new certificate supersedes the
previous certificate, which must be revoked.
! CessationOfOperation. If your organization decommissions a CA, use this
revocation code to revoke the CA’s certificate. Do not revoke the certificate
if the CA publishes CRLs for the currently issued certificates, but it does not
issue new certificates.
! CertificateHold. A temporary revocation that indicates that a CA will not

vouch for a certificate at a specific time. After a certificate is revoked by
using CertificateHold, you can later unrevoke the certificate.
Note Although CertificateHold allows a certificate to be unrevoked, the

CertificateHold reason code is not recommended because it becomes
difficult to determine if a certificate was valid at a specific time.
! RemoveFromCRL. If you revoke a certificate by using CertificateHold, you

can unrevoke the certificate. The unrevoking process still lists the certificate
in the CRL, but with the revocation code set to RemoveFromCRL. The
RemovefromCRL reason code is specific to the CertificateHold reason and
is only used in delta CRLs.
! Unspecified. You can revoke a certificate without providing a specific
revocation code. Using Unspecified is not recommended, however, because
it does not provide an audit trail that identifies why a certificate was
revoked.
Note For more information about certificate revocation reason codes, see RFC
3280, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, under Additional Reading on the Web page on
the Student Materials compact disc.
Lesson: Planning CRL Publication

Introduction When a certificate is presented to an application, the application determines the
revocation status of the certificate by checking whether the certificate is
included in the CRL that the CA published.
A computer will acquire an updated CRL from a CRL publication point only if
the CRL that is cached on the computer has expired. This lesson will help you
determine how frequently CRLs are published based on inputs, such as network
traffic; how frequently certificates are revoked; and the importance of CRL
freshness for your organization or application.
! Identify the difference between base and delta CRLs.
! Describe the process of CRL publication.
! Determine the criteria for planning CRL publication intervals.
! Establish the criteria for determining publication points.
! Create publication points.
Types of CRLs

Introduction After a certificate manager revokes a certificate, a CA publishes the revocation
information in a CRL. A frequently published CRL increases network traffic
because computers download the updated CRL more frequently. A less
frequently published CA reduces network traffic but increases the latency
before a computer is aware of a newly revoked certificate.
Windows Server 2003 provides two types of CRLs—base CRLs and delta
CRLs. These two types work together to balance latest CRL information and
latency issues with the distribution of the CRLs.
Base CRLs A base CRL contains the serial numbers of all certificates that were revoked on
a CA and their revocation reasons, if the reasons were provided at the time of
revocation. The final publishing location of the base CRL must be accessible
from the URL in the certificate. If a CA revokes a large number of certificates,
the size of the base CRL can exceed 1 megabyte (MB).
Delta CRLs When the number of issued certificates increases, the number of revoked
certificates also increases. Revoked certificates are added to the CRL as a
collection of serial numbers. To decrease the size of the CRL and to make more
frequent updates valuable, a delta CRL keeps only these certificates that have
been revoked since the last publication of the base CRL.
Only computers running Windows XP Professional or Windows Server 2003
can check the validity of certificates against delta CRLs. If your network does
not use these operating systems, do not implement delta CRLs.
Important After a CA administrator implements delta CRLs on a CA, client

computers must always obtain valid base and delta CRLs when they validate
certificates. If the base CRL or delta CRL is unavailable, the certificate will fail
a revocation check.
Consider the following guidelines when you use delta CRLs:

! Use delta CRLs with issuing CAs whenever possible.
! Do not use delta CRLs with offline CAs because the number of CA
certificates is typically low.
! Do not publish frequent delta CRLs to Active Directory if replication is
scheduled. Replication can take up to eight hours to synchronize the Active
Directory database in a wide area network (WAN) environment.
Note You must download the base CRL initially and when the previous base
CRL expires. You can force the client computer to retrieve a more recent base
CRL even though the current base CRL is still valid by having the delta CRL
point to a higher number base CRL.
How CRLs Are Published

Introduction When a client computer downloads a base CRL, the base CRL remains in the
CryptoAPI cache until it expires. Therefore, if only base CRLs are used, as in
Windows 2000, client computers that have a valid CRL in their cache will not
recognize any manual updates to the CRL.
The CRL publication Each CA is configured with a CRL publication setting or CRL publish period.
process The CRL publish period defines when a CA will automatically publish an
updated CRL. When a CA is first installed, the publish period is set to one
week, but you can configure it manually.
As shown in the slide above, CRLs are published in the following sequence:
1. The initial base CRL (CRL#1) is published with one revoked certificate.
2. Soon after, Cert5 is revoked.
3. When the delta CRL (CRL#2) is published, the delta CRL includes Cert5.
4. A second certificate, Cert7, is revoked.
5. When the updated delta CRL (CRL#3) is published, the delta CRL now
contains Cert5 and Cert7.
6. Finally, when the base CRL is published, the base CRL (CRL#4) includes
the serial numbers for Cert3, Cert5, and Cert7.
Any new delta CRLs will now include only certificates that have been revoked
since base CRL CRL#4 was issued.
Criteria for Planning CRL Publication Intervals

Introduction Determining the frequency of publishing CRLs requires significant planning by
a CA administrator—who must define the CRL publication intervals by
balancing the base CRL and delta CRL intervals.
Criteria Use the following criteria when you plan CRL publication intervals:
! Client operating systems. If your client computers run Windows 2000 or
earlier versions, you must define short base CRL publication intervals so
that the computers have up-to-date information.
! CRL retrieval network load. The more frequently you publish the base CRL,
the more frequently all clients download the base CRL, which increases the
size of the base CRL. The larger its size, the more network traffic that client
computers generate. Publishing the CRL less frequently reduces the network
traffic that is associated with CRL publication.
! Delta CRL size. Publishing the base CRL after long intervals results in large
delta CRLs. Use delta CRLs to reduce the size of downloaded CRLs, in
addition to making more frequent updates valuable.
! CRL revocation frequency. The number of certificates that are revoked
within a period greatly influences the publication interval for both base and
delta CRLs. Publish the CRLs in a timely manner so that the revoked
certificates are recognized. Balance the interval against the network load
resulting from CRL download traffic.
! Replication latency. The delta CRL and base CRL publication intervals are
limited by the replication latency of Active Directory. Because the
replication latency can be as high as eight hours, defining CRL publication
to an interval of fewer than eight hours can result in the CRL being
unavailable until the Active Directory replication is completed. Replication
latency results in the failure of the path validation process.
! Registry settings. You can change three default registry settings to define
CRL publication intervals. A CRL is valid for a period that differs from its
publication period. The validity period is extended beyond the publication
period so that Active Directory replication can occur. You can adjust the
overlap period for CRL publication by modifying the following registry
settings:
• CRLOverlapPeriod. The amount of time that a CRL’s lifetime is
extended so that a client can obtain the updated CRL before the previous
CRL expires. The default value is ten percent of the CRL validity period,
up to a maximum of 12 hours. For example, if the CRL publication
interval is every ten days, the CRLOverlapPeriod is one day.
• CRLOverlapUnits. The unit of measurement for the
CRLOverlapPeriod registry setting.
• ClockSkewMinutes. The value that is added for overlap periods to
allow for time differential between clients. The default value is ten
minutes.
The combination of these three registry settings ensures that a newly
published CRL is distributed to all CRL distribution points before the
previous CRL expires. They prevent a situation in which the previous CRL
expires, and replication latency prevents the new CRL from being published
to the CRL distribution points.
Important Only modify these registry values if replication issues prevent

the publication of the updated CRLs before the previous CRLs expire. If
there are no latency issues, do not modify the default values.
Where to Create the Publication Points

Introduction After you install a root CA, configure two X.509 version 3 extension fields,
known as the AIA and the CDP extensions. These extensions apply to all
certificates that the root CA issues.
The formatting and publishing of AIA and CDP extension URLs are generally
the same for root CAs, policy CAs, and issuing CAs. The difference between
offline CAs and online CAs is that offline CAs require manual certificate and
CRL publishing to a directory or Web server.
Publication points To ensure accessibility to all computers in the forest, publish the offline root
CA certificate and the offline root CA’s CRL to Active Directory using the
certutil command. This places the root CA certificate and CRL in the
Configuration naming context, which Active Directory replicates to all domain
controllers in the forest.
For computers that are not members of Active Directory, place the CA
certificate and CRL on Web servers by using the HTTP protocol. Locate the
Web servers on the internal network, and also on the external network if
external client computers require access.
You can also publish certificates and CRLs to FTP:// and FILE:// URLs, but it
is recommended that you use only LDAP and HTTP URLs, because they are
the most widely supported URL formats for interoperability purposes.
Note The order in which the CDP and AIA extensions are listed is important
because the certificate chaining engine searches the URLs sequentially. Place
the LDAP URL first in the list.
Demonstration: How to Modify CDP and AIA Extensions

Introduction You must modify the CDP and AIA extension URLs for an offline root CA to
reflect the publication locations that your organization uses. You can create a
batch file named ModifyAIAandCDP.cmd that automates the modification of
the CDP and AIA extensions. Before you run the batch file, you must modify it
to reflect the forest name and Web publication points that you implemented for
your organization’s PKI.
Note This demonstration focuses on the concepts in this lesson and as a result
What is the ModifyAIAandCDP.cmd is a custom batch file that modifies the registry entries
ModifyAIAandCDP.cmd? that store the CDP and AIA extensions. Modify the following settings for the
file:
! The LDAP distinguished name of the forest root domain. This name is used
in the LDAP URLs contained in the configuration naming context.
! The DNS name of the Web server. If you implement HTTP URLs, you must
type the correct DNS name of the Web server that hosts the CRL and AIA.
Procedure for Modifying To modify the ModifyAIAandCDP.cmd file:

ModifyAIAandCDP.cmd
1. Ensure you are logged on to the Windows Server 2003 CA as a member of
the local Administrators group.
2. Open C:\moc\2821\Labfiles\Module3\ModifyAIAandCDP.cmd.
3. Browse to the line:
certutil -setreg ca\DSConfigDN CN=Configuration,forestname
4. Change ForestName to the LDAP distinguished name of your forest root

domain. For example, if your forest root domain is nwtraders.msft, the
LDAP distinguished name is DC=nwtraders,DC=msft.
5. Search for and replace all occurrences of WebServer with the DNS name of
the Web server where the CDP and AIA are published.
6. Save all changes, and then close ModifyAIAandCDP.cmd.
7. Double-click C:\moc\2821\Labfiles\Module3\ModifyAIAandCDP.cmd.
Procedure for You must publish the CRL to all configured LDAP and HTTP URLs for the
Publishing the CRL CDP. To publish the CRL to the LDAP URL for the CDP:
1. Log on as a member of the Enterprise Admins group.
2. Type the following command:
Certutil –dspublish –f CRLName.crl
To publish the CRL to the HTTP URL for the CDP, you must copy the
CRLName.crl file to the virtual directory that is referred to in the HTTP URL
for the CDP.
Warning If you receive an error message when you run the certutil command
to publish the CRL, fix the CDP LDAP URL in the ModifyCDPandAIA.cmd
command file, and then run the command file again.
Procedure Publishing The CA certificate is published in the AIA URLs. To publish the CA certificate
the CA Certificate to the LDAP URL for the AIA:
1. Log on as a member of the Enterprise Admins group.
2. Type the following command:
Certutil –dspublish –f CertName.crt [RootCA|SubCA]
If you are publishing the root CA certificate, type RootCA at the end of the
command line. If you are publishing a policy CA or issuing CA certificate, type
SubCA at the end of the command line.
To publish the CA certificate to the configured HTTP URL for the AIA, you
must copy the CertName.crt file to the virtual directory referenced in the HTTP
URL for the AIA.
Warning If you receive an error message when you run the certutil command
to publish the CA certificate, fix the AIA LDAP URL in the
ModifyCDPandAIA.cmd command file, and then run the command file again.
Lab B: Publishing CRLs and AIAs

! Define the CRL publication interval and configure the correct CRL and AIA
publication URLs for all issued certificates.
! Publish the CA certificate and CRL information to the locations that are
referred to in the AIA and CDP extensions of issued certificates.
! Add the WebServer URL to the local intranet site in a GPO.
lab does not comply with the recommendation to implement an HSM storage
device for the protection of the private key material of the offline CA.

! A computer that has a dual-boot configuration that can function as both the
! A domain controller that can host the offline root CA’s certificate
revocation list, CA certificate, and certificate practice statement.
! Reviewed the following table.
Computer Domain controller Forest name
DenverCA vancouver.adatum.msft DC=adatum,DC=msft

BrisbaneCA perth.fabrikam.msft DC=fabrikam,DC=msft
BonnCA lisbon.lucernepublish.msft DC=lucernepublish,DC=msft
SantiagoCA lima.litwareinc.msft DC=litwareinc,DC=msft
SingaporeCA bangalore.tailspintoys.msft DC=tailspintoys,DC=msft
TunisCA casablanca.wingtiptoys.msft DC=wingtiptoys,DC=msft
MiamiCA acapulco.thephonecompany.msft DC=thephonecompany,DC=msft
SuvaCA auckland.cpandl.msft DC=cpandl,DC=msft
MoscowCA stockholm.adventureworks.msft DC=adventureworks,DC=msft
MontevideoCA caracas.blueyonderair.msft DC=blueyonderair,DC=msft
TokyoCA manila.woodgrovebank.msft DC=woodgrovebank,DC=msft
NairobiCA khartoum.treyresearch.msft DC=treyresearch,DC=msft
Estimated time to
complete this lab:
45 minutes
Exercise 1
Defining CRL and AIA Publication Settings
In this exercise, you will complete the configuration of the offline root CA by defining the CRL
publication interval, ensuring that the CA certificate and CRL are available when the CA is offline,
and configuring the correct CRL and AIA publication URLs for all issued certificates.
Scenario
After you install the standalone root CA, you must modify the CDP and AIA extensions at the root
CA to refer to locations that are available when the standalone root CA is removed from the
network.
Important: Perform this procedure on the offline CA for your organization.
1. In Certification Authority a. Click Start, point to Administrative Tools, and then click
MMC, ensure that the CRL Certification Authority.
publication interval is set to b. In the console tree, expand Computer (where Computer is the NetBIOS
26 weeks for the root CA. name of the offline CA).
c. In the console tree, right-click Revoked Certificates, and then click
Properties.
d. In the Revoked Certificates Properties dialog box, ensure that the
CRL publication interval is 26 weeks.
e. In the Revoked Certificates Properties dialog box, ensure that the
Publish Delta CRLs check box is cleared, and then click OK.
Should you enable delta CRLs for an offline root CA?
Do not implement delta CRLs, because the publication of each delta CRL would require access to the
offline root CA in order to copy the delta CRL to an online publication location.
2. Review the default ldap:///, a. In the console tree, right-click Computer, and then click Properties.
http://, and file://\\ URLs in b. In the Computer Properties dialog box, on the Extensions tab, in the
the CRL distribution points Select extension drop-down list, ensure that the box reads CRL
(CDP) list on the Distribution Point (CDP).
Extensions tab of the
Computer Properties dialog c. Review the default ldap:///, http://, and file://\\ URLs in the CRL
box. distribution points (CDP) list.
(continued)
What are the default CRL distribution point (CDP) URLs?
D:\WINDOWS\system32\Certsrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,
CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>
http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
file://\\<ServerDNSName>\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
Why should you not delete the URL that begins with D:\WINDOWS\system32\certsrv\certenroll?
The URL that begins with D:\WINDOWS\system32\certsrv\certenroll is where the updated CRL is
posted when you manually publish a CRL or when Certificate Services publishes the CRL at the CRL
publication interval.
3. Review the default ldap:///, a. On the Extensions tab, in the Select extension drop-down list, select
http://, and file://\\ URLs in Authority Information Access (AIA).
the Authority Information b. Review the default ldap:///, http://, and file://\\ URLs.
Access (AIA) list on the
Extensions tab of the
Computer Properties dialog
box.
What are the default AIA URLs?
D:\WINDOWS\system32\Certsrv\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt
ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,
CN=Services,<ConfigurationContainer><CAObjectClass>
http://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt
file://\\<ServerDNSName>\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt
(continued)
3. (continued) c. Click OK.
4. Make the following a. Open C:\moc\2821\Labfiles\Module3.

modifications to b. Right-click ModifyAIAandCDP.cmd and then click Properties.
ModifyAIAandCDP.cmd in
the C:\moc\2821\labfiles\ c. In the ModifyAIAandCDP.cmd Properties dialog box, ensure that
Module3 folder. the Read-only check box is cleared, and then click OK.
• Clear the Read-only d. Right-click ModifyAIAandCDP.cmd and then click Edit.

check box. e. On the Edit menu, click Replace.
• Change all occurrences f. In the Replace dialog box, in the Find what box, type Webserver
of Webserver to g. In the Replace with box, type DomainController (where
DomainController. DomainController is the fully qualified domain name of your domain
• Change all occurrences controller from the table at the beginning of the lab), and then click
of ForestName to Replace All.
ForestName. h. In the Replace dialog box, in the Find what box, type ForestName
i. In the Replace with box, type ForestName (where ForestName is the
beginning of the lab), and then click Replace All.
j. In the Replace dialog box, click Cancel.
k. On the File menu, click Save, and then close the window.
5. Execute the " In the C:\moc\2821\labfiles\Module3 window, double-click

ModifyAIAandCDP.cmd ModifyAIAandCDP.cmd.
command file.
6. Publish the latest version of a. In the Certification Authority console, in the console tree, right-click
the CRL. Revoked Certificates, click All Tasks, and then click Publish.
b. In the Publish CRL dialog box, click New CRL, and then click OK.
7. At a command prompt, a. At a command prompt, type

increase the validity period certutil -setreg ca\ValidityPeriodUnits 10 and then press ENTER.
of issued certificates to 10 b. At the command prompt, type
years by using certutil – certutil -setreg ca\ValidityPeriod "Years" and then press ENTER.
setreg.
c. Close the command prompt.
8. Restart Certificate Services a. Ensure that the Certification Authority console is the active window.
from the Certification b. In the console tree, right-click Computer, click All Tasks, and then
Authority console and then click Stop Service.
close the console.
c. In the console tree, right-click Computer, click All Tasks, and then
click Start Service.
d. Close the Certification Authority console.
e. Close all open windows.
Exercise 2
Publishing the CRL and AIA Information
In this exercise, you will publish the CA certificate and CRL information to the locations that are
referred to in the AIA and CDP extensions of issued certificates. By publishing the CRL and CA
certificate to these locations, you ensure that the certificate chaining engine can validate issued
certificates.
Scenario
After you modify the CDP and AIA extensions for issued certificates, you must publish the CRL
and CA certificate for the offline root CA to the LDAP and HTTP locations.
Important: Perform this procedure on the domain controller for your domain.
1. Log on with your domain a. Turn on the domain controller.

administrative account, and b. Log on to the domain with the following account information:
open Add or Remove
Programs from Control • User name: Student1
Panel. • Password: Password (where Password is the password for your
domain)
c. On the Start menu, click Control Panel, and then click Add or
Remove Programs.
2. Install the Application a. In the Add or Remove Programs dialog box, click Add/Remove
Server component with the Windows Components.
following subcomponents: b. On the Windows Components page, in the Components list, click the
• Enable network COM+ phrase Application Server (not the check box), and then click Details.
access
c. In the Application Server dialog box, in the Subcomponents of
• Internet Information Application Server list, select the Enable network COM+ access
Services (IIS) check box, click the phrase Internet Information Services (IIS) (not
• Common Files the check box) , and then click Details.
• Internet Information d. In the Internet Information Services (IIS) dialog box, in the
Services Manager Subcomponents of Internet Information Services (IIS) list, select
the following subcomponent check boxes:
• World Wide Web
Service • Common Files
• Active Server Pages • Internet Information Services Manager
• World Wide Web e. In the Subcomponents of Internet Information Services (IIS) list,
Service click the phrase World Wide Web Service (not the check box), and
then click Details.
(continued)
2. (continued) f. In the World Wide Web Service dialog box, in the Subcomponents
of World Wide Web Service list, select the following subcomponent
check boxes:
• Active Server Pages
• World Wide Web Service
g. In the World Wide Web Service, dialog box, click OK.
h. In the Internet Information Services (IIS) dialog box, click OK.
i. In the Application Server dialog box, click OK.
j. On the Windows Components page, click Next.
k. Insert the Windows Server 2003 Enterprise Edition disk into the
CD-ROM drive, if you have not already done so.
l. If the Files Needed dialog box appears, in the Files Needed dialog
box, in the Copy files from box, type x:\i386 (where x is the drive
letter of your CD-ROM drive), and then click OK.
m. On the Completing the Windows Components Wizard page, click
Finish.
n. Close the Add or Remove Programs dialog box.
o. Close all open windows.
3. Create a new folder called a. Open the C:\Inetpub\wwwroot folder.

C:\Inetpub\wwwroot\ b. Create a new subfolder named Legalpolicy.
Legalpolicy and copy the
C:\moc\2821\labfiles\ c. Open C:\moc\2821\labfiles\Module3.
module3\rootcps.htm file to d. Copy the file rootcps.htm to the C:\inetpub\wwwroot\Legalpolicy
the Legalpolicy folder. folder.
4. Copy the contents of a. Open C:\Inetpub\wwwroot.

\\Computer\admin$\ b. Create a new subfolder named CertData.
system32\certsrv\
Certenroll to the c. Open \\Computer\admin$ (where Computer is the NetBIOS name of
C:\inetpub\wwwroot\ your offline root CA computer).
CertData folder. d. When prompted for credentials, use the following credentials:
• User name: Administrator
e. In Windows Explorer, double-click System32, double-click Certsrv,
and then double-click Certenroll.
f. Copy all files in the \\Computer\admin$\system32\Certsrv\Certenroll
share to C:\inetpub\wwwroot\CertData.
g. Close all open windows.
(continued)
5. Add http://WebServer to the a. Open Internet Explorer.

Local Intranet zone in b. In the Internet Explorer dialog box, click In the future, do not show
Internet Explorer. this message, and then click OK.
c. On the Tools menu, click Internet Options.
d. In the Internet Options dialog box, on the Security tab, click Local
Intranet, and then click Sites.
e. In the Local intranet dialog box, in the Add this Web site to the zone
box, type http://WebServer (where WebServer is the fully qualified
domain name of your domain controller), and then click Add.
f. In the Local intranet dialog box, click Close.
g. In the Internet Options dialog box, click OK.
6. Open the URL " In Internet Explorer, in the Address bar, type
http://WebServer/ http://WebServer/Legalpolicy/rootcps.htm (where WebServer is the
Legalpolicy/rootcps.htm in fully qualified domain name of your domain controller), and then press
Internet Explorer. ENTER.
Does the Certificate Practice Statement appear in Internet Explorer?
Yes. If correctly configured, the Certificate Practice Statement is now available from the
http://WebServer/legalpolicy/rootcps.htm URL.
7. Open the URL a. In the Address bar, type http://WebServer/CertData/Computer.crl

http://WebServer/CertData/ (where WebServer is the fully qualified domain name of your domain
Computer.crl in Internet controller and Computer is the NetBIOS name of the offline root CA),
Explorer. and then press ENTER.
b. In the File Download dialog box, click Open.
Does the certificate revocation list appear?
Yes. If correctly configured, the certificate revocation list is now available from the
http://WebServer/CertData/Computer.crl URL.
(continued)
8. Open the URL a. In the Certificate Revocation List dialog box, click OK.
http://WebServer/CertData/ b. In Internet Explorer, in the Address bar, type
Computer_Computer.crt. http://WebServer/CertData/Computer_Computer.crt (where
WebServer is the fully qualified domain name of your domain
controller and Computer is the NetBIOS name of the CA server) and
then press ENTER.
c. In the File download dialog box, click Open.
It will take several seconds for the CA certificate to open.
Is the CA certificate trusted by all computers?
No. Currently the CA certificate is only trusted by the offline root CA. The two computers that are
members of the domain do not know or trust the offline root CA certificate because it does not chain
the certificate to a trusted root.
9. Close Internet Explorer. a. In the Certificate dialog box, click OK.

b. Close Internet Explorer.
10. Log on as a member of the a. At a command prompt, type cd \inetpub\wwwroot\Certdata and then
Enterprise Admins group press ENTER.
and publish the CRL and b. To publish the latest CRL to Active Directory, at the command prompt,
CA certificate to Active type certutil –dspublish –f Computer.crl (where Computer is the
Directory by using the NetBIOS name of your offline root CA), and then press ENTER.
following commands:
Verify that the response to the certutil command states that the
• certutil –dspublish –f certutil -dspublish command was completed successfully.
Computer.crl
c. To publish the CA certificate to Active Directory, at the command
• certutil –dspublish –f prompt, type certutil –dspublish –f Computer_Computer.crt RootCA
Computer_Computer.crt (where Computer is the NetBIOS name of your offline root CA), and
RootCA then press ENTER.
Verify that the response to the certutil command states that the
certutil -dspublish command was completed successfully.
11. Force Group Policy a. At the command prompt, type gpupdate /force and then press
application by running ENTER.
gpupdate /force. b. Close the command prompt.
(continued)
12. Open the URL a. Open Internet Explorer.

http://WebServer/CertData b. In Internet Explorer, in the Address bar, type
/Computer_Computer.crt in http://WebServer/CertData/Computer_Computer.crt (where
Internet Explorer. WebServer is the fully qualified domain name of your domain
controller and Computer is the NetBIOS name of the offline root CA
from the table at the beginning of the lab) and then press ENTER.
c. In the File download dialog box, click Open, and then view the
attributes of the certificate in root CA certificate.
Is the CA certificate trusted by all computers?
Yes. By publishing the root CA certificate to Active Directory by using the certutil –dspublish
command, the root CA certificate is now located in the AIA store and is trusted by all domain
members. The gpupdate /force command forced the application of Group Policy to the domain
controller in the domain.
13. View the Issuer Statement a. In the Certificate dialog box, click Issuer Statement.
for the CA certificate. b. In the Disclaimer dialog box, click More Info.
What appears in Internet Explorer? What is the benefit of using a Web-based URL for the issuer statement?
The Certificate Practice Statement appears in Internet Explorer. By using a Web-based URL, you can
update the CPS. It is not necessary to reissue the RootCA certificate when the update is made to a
referenced URL.
14. Close all open windows. a. Close Internet Explorer.

b. In the Disclaimer dialog box, click Close.
c. In the Certificate dialog box, click OK.
d. Close all open windows.
Lesson: Installing a Subordinate CA

Introduction In a PKI hierarchy, a CA under a root CA is called the subordinate CA. The
certificate signature key of a subordinate CA is certified by another CA.
! Identify the permissions that are required to install an enterprise CA.
! Prepare an issuing CA to issue Subordinate Certification Authority
certificates.
! Identify the sequence of steps for installing an enterprise subordinate CA.
! Describe the considerations for configuring AIA and CDP extensions.
! Use the PKI Health Tool to validate all AIA and CDP extensions.
! Deploy a Windows 2003 enterprise CA in a Windows 2000 forest.
Permissions for Installing an Enterprise CA

Introduction Installing an enterprise CA creates some objects in the configuration partition
of Active Directory. Because the modification is made to the configuration
naming context, only selective groups have permission to modify the
configuration naming context, as required by the installation of an enterprise
CA.
Permissions to install During the installation of an enterprise CA, several objects are modified in
the enterprise CA CN=Public Key Services,CN=Services,CN=Configuration,
DC=ForestRootDomain (where ForestRootDomain is the LDAP distinguished
name of the forest root domain).
Only the Enterprise Admins and Domain Admins group from the forest root
domain have permission to create objects in the configuration naming context,
specifically, CRLs and CA certificates.
In addition, only local administrators have permission to add new services to a
Windows Server 2003 computer and access the local computer certificate store
to install the Subordinate Certification Authority certificate.
How to Prepare the Issuing CA

Introduction Before certificates are issued to subordinate CAs, you must ensure that the
issuing CA is configured with the correct CDP and AIA extensions, and that it
issues the Subordinate Certification Authority certificate with the required
validity period.
Preparation steps To prepare the issuing CA to issue Subordinate Certification Authority
certificates, perform the following configurations:
1. Ensure that all CDP and AIA extensions are valid. The CDP and AIA
extensions must be modified so that the extensions refer to valid URLs. If
the issuing CA is an offline CA, the CDP and AIA extensions must refer to
network resources that are located on online servers.
2. Configure the maximum validity period for all issued certificates. On each
certification authority in the CA hierarchy, you can configure the maximum
validity period for all certificates by using the certutil command. For
example, to set the maximum validity period for certificates issued by a CA
to 10 years, use the following certutil commands:
certutil -setreg ca\ValidityPeriodUnits 10
certutil -setreg ca\ValidityPeriod "Years"
After you define the registry values, you must restart Certificate Services.
3. Configure the validity period of the Subordinate Certification Authority
certificate template. If the issuing CA is an enterprise CA, you can define
the validity period in the properties of the certificate template. The validity
period for a Subordinate Certification Authority certificate that is issued by
an enterprise CA is the lesser value of the validity period that is configured
in the certificate template or in the ValidityPeriodUnits and
ValidityPeriod registry settings.
For a standalone CA, you can define the certificate validity period for issued
certificates only by using the definition of ValidityPeriodUnits and
ValidityPeriod.
Steps for Installing an Enterprise Subordinate CA

Introduction The CA that issues the Subordinate Certification Authority certificate digitally
signs the certificate that is issued to a subordinate CA. The process that you use
to install an enterprise subordinate CA depends on the type of CA that issues
the Subordinate Certification Authority certificates. To install an enterprise
subordinate, perform the following steps:
Determine the CA type The installation of the enterprise subordinate CA varies depending on the CA
of the parent CA policy of the parent CA. If the parent CA is a standalone CA, you must submit
the request to the CA by using a certificate request file. Only subordinate CA
requests that are sent to an enterprise CA can be processed by the parent CA
immediately.
Install Certificate When you install Certificate Services, you must determine whether the
Services subordinate CA will act as an offline policy CA or as an online issuing CA. Its
role will affect the installation settings on the following pages of the Certificate
Services Wizard:
! Certification Authority Type. On this page, you must install an offline
policy CA as a standalone subordinate CA. It is recommended that you
install an online issuing CA as an enterprise subordinate CA.
Note You can also install a standalone CA policy for an issuing CA if a

standalone CA is required. For example, Microsoft Exchange Server 5.5
requires that an online standalone CA is integrated with its Key
Management Server (KMS) service.
! CA Identifying Information. On this page, you identify the common name

and the distinguished name suffix for the subordinate CA. An enterprise
subordinate CA will automatically populate the distinguished suffix name
with the LDAP distinguished name of the forest root domain. You must type
it manually when you install a standalone subordinate CA.
Submit the subordinate When the installation is near completion, the submission of the CA certificate
CA certificate request request varies depending on whether the parent CA in the CA hierarchy is an
online or an offline CA.
! For an online parent CA, submit the request directly to the CA. In the drop-
down list on the CA Certificate Request page, you can select any
enterprise CAs that is published in Active Directory. The requesting CA
sends the certificate request directly to the parent CA, and the parent CA
issues the Subordinate Certification Authority certificate immediately.
! For an offline parent CA:
a. Save the request to a .req file.
The .req file uses a PKCS #10 format. The subordinate CA request is
based on the private key length that is designated in the Certificate
Services wizard. It includes the public key of the CA’s key pair.
b. Submit the .req file on the offline CA.
c. Ensure that a certificate manager issues the pended certificate request.
d. Export the entire certificate path in a PKCS #7 format.
Install the certificate on The final step in installing an enterprise CA is to install the CA certificate and
the Enterprise CA start Certificate Services. The process will vary depending on whether the
subordinate CA submits its certificate request to an enterprise CA or a
standalone CA.
! When a subordinate CA sends a Subordinate Certification Authority
certificate request to an enterprise CA, the parent CA returns the certificate
immediately. Certificate Services automatically restarts after the certificate
is installed.
! When a subordinate CA sends a Subordinate Certification Authority
certificate request to a standalone CA, the PKCS #7 file that is issued by the
standalone CA must be loaded on the subordinate CA. Certificate Services
restarts after the PKCS #7 file is installed.
Considerations for Configuring AIA and CDP Extensions

Introduction An enterprise CA may require additional AIA and CDP locations for all issued
certificates. While the configuration of AIA and CDP extensions URLs for an
online CA is similar to the offline root CA configuration, there are different
considerations that you must take into account.
External users If external accounts must validate the issued certificates, you must make the CA
certificate and CRL for the issuing CA available externally. For these locations,
ensure that:
! The CDP and AIA locations are available to external users. For example,
publish the CA certificate and CRLs to a Web cluster that is located in the
perimeter network of your organization.
! Your Internet-accessible DNS service can resolve the path that the URLs
refer to. Do not use internal NetBIOS names in your URL path.
Note You must manually publish the CA certificate and CRL to the externally
accessible locations from the enterprise CA.
Internal users The CDP and AIA extensions do not require modification if the certificate is
validated only by internal accounts. By default, the extensions are published to:
! Active Directory. The CA certificate and CRL are published in the
configuration naming context and are available for retrieval from any
domain controller in the forest.
! Web service. The CA certificate and CRL are available from the Web
service that is installed on the enterprise CA. Because the enterprise CA is
online, any client can connect to the Web page URLs to download the latest
CA certificate and CRLs to validate the path.
! The local path. The CA publishes the CA certificates to the local
\\CAName\Certenroll share (where CAName is the NetBIOS name of the
CA computer). You can copy the CRLs and CA certificate in this share to
external locations.
Demonstration: Using the PKI Health Tool

Introduction After you install your CA hierarchy, it is recommended that you ensure that all
AIA and CDP extensions are valid. The Windows 2003 Resource Kit includes
the PKI Health Tool so you can validate all CDP and AIA extensions.
Procedure for using the To use the PKI Health Tool:

PKI Health Tool
1. Register the PKI Health Tool dynamic link library (DLL), by running
regsvr32 C:\moc\2821\labfiles\module3\pkiview.dll.
2. In the Regsvr32 dialog box, click OK.
3. In C:\moc\2821\labfiles\module3, open pkiview.msc.
4. In the console tree, click each CA in the CA hierarchy, and then in the
details pane, review the status of each CRL and AIA location.
Publication points that are correctly configured appear with an OK status. The
status column also indicates any problems the PKI Health Tool identifies for the
AIA or CDP extensions.
For example, if you type an incorrect URL for a CDP or AIA extension, the
status column reports that the CDP or AIA extension’s status as Unable to
Download. The status column also provides information if a CDP or AIA
extension is near expiration, or has already expired.
Procedure for resetting To reset the warning periods for CA certificates, CRLs, and delta CRLs:
warning periods
1. In the PKI Health Tool, in the console tree, right-click Enterprise PKI,
and then click Options.
2. In the Options dialog box, change the CRL status to 7 days, and then click
OK.
3. In the console tree, right-click BridgeCA, and then click Refresh.
The status column for the CDP locations changes to Expiring.
How to Deploy Windows Server 2003 PKI in a Windows 2000 Forest

Introduction Many organizations have an existing Windows 2000 network infrastructure.
They may be unable or unwilling to immediately upgrade to a Windows 2003
network infrastructure. To deploy a Windows Server 2003 PKI in a
Windows 2000 network, you must upgrade the Active Directory schema to add
the necessary classes and attributes that a Windows Server 2003 PKI requires.
Warning Modifying the Active Directory schema is not a standard operation.

Be sure to present it to your organization’s Active Directory change
management team before you deploy.
Procedure for deploying To deploy Windows Server 2003 enterprise CAs in a Windows 2000 forest:
Windows Server 2003
enterprise CAs in a 1. Upgrade all Windows 2000 domain controllers to Service Pack (SP) 3 or
Windows 2000 forest later.
Windows 2000 SP 3 applies modifications to the Windows 2000 operating
system that Windows 2003 Certificate Services requires. These
modifications are also required to run the adprep command to update the
forest schema.
2. If you are running Exchange Server 2000, ensure that the Secretary and
LabeledURI attributes are protected against corruption by the
Windows Server 2003 schema extensions.
These attributes are also attributes of the InetOrgPerson class. They do not
match the RFC 2798 defined formats.
Note For information about how to modify the Secretary and LabeledURI
attributes to match the RFC 2798 defined formats see article Q314649,
“Windows Server 2003 ADPREP Command Causes Mangled Attributes in
Windows 2000 Forests That Contain Exchange 2000 Servers,” in the
Microsoft Knowledge Base at http://support.microsoft.com/
default.aspx?scid=kb;[LN];314649.
3. Run adprep /forestprep on the schema master for the forest by using the
Windows Server 2003 installation CD-ROM.
The adprep /forestprep command updates the schema of the
Windows 2000 forest with the schema modifications that Windows 2003
Certificate Services requires.
Note To run adprep /forestprep, you must be a member of the Enterprise

Admins group, the Schema Admins group, and the Domain Admins group
of the domain in which the schema master is located.
4. Run adprep /domainprep on the infrastructure master for the forest by

using the Windows Server 2003 installation CD-ROM.
The adprep /domainprep command updates the domain with the Group
Policy modifications that Windows 2003 Certificate Services requires.
Note To run adprep /domainprep, you must be a member of the

Enterprise Admins group and the Domain Admins group of the domain in
which the infrastructure master is located.
5. If there are multiple domains in your forest, create a custom universal group
that contains each domain’s Cert Publishers group. Assign the custom
universal group read and write permissions to the userCertificate attribute
for all user objects in each domain in the forest.
Note For more information about the procedures to assign these permissions,
see article Q28127, “Windows 2000 Certification Authority Configuration to
Publish Certificates in Active Directory of Trusted Domain” in the
Microsoft Knowledge Base at http://support.microsoft.com/
default.aspx?scid=kb;[LN];281271.
Lab C: Implementing a Subordinate Enterprise CA

! Install an enterprise subordinate CA below an offline root CA in a CA
hierarchy.
! Use the PKI Health Tool to validate CRL and AIA publication points.
lab does not comply with the recommendation that the top two levels of the CA
hierarchy be offline.

! A floppy disk for transferring certificate request and response files between
the offline root CA and the subordinate enterprise CA.
! A computer with a dual-boot configuration that will function as both the
! A domain controller that will host the offline root CA’s certificate
revocation list, CA certificate, and certificate practice statement, and also
act as the enterprise subordinate CA.
! Completed the following table to assist in the completion of the lab.

Computer Domain Forest name
DenverCA Adatum DC=adatum,DC=msft

BrisbaneCA Fabrikam DC=fabrikam,DC=msft
BonnCA Lucernepublish DC=lucernepublish,DC=msft
SantiagoCA Litwareinc DC=litwareinc,DC=msft
SingaporeCA Tailspintoys DC=tailspintoys,DC=msft
TunisCA Wingtiptoys DC=wingtiptoys,DC=msft
MiamiCA Thephonecompany DC=thephonecompany,DC=msft
SuvaCA Cpandl DC=cpandl,DC=msft
MoscowCA Adventureworks DC=adventureworks,DC=msft
MontevideoCA Blueyonderair DC=blueyonderair,DC=msft
TokyoCA Woodgrovebank DC=woodgrovebank,DC=msft
NairobiCA Treyresearch DC=treyresearch,DC=msft
Additional information For more information about implementing a subordinate enterprise CA, see the
white paper, Best Practices for Implementing a Microsoft Windows Server 2003
Public Key Infrastructure, under Additional Reading on the Web page on the
Estimated time to
complete this lab:
45 minutes
Exercise 1
Installing the Subordinate Enterprise CA
In this exercise, you will install an enterprise CA as a subordinate to the offline root CA that you
previously created. To simulate an offline CA, you will remove the root CA from the network by
unplugging its network cable.
Scenario
Northwind Traders requires an enterprise subordinate CA so that it can deploy certificates that are
based on Windows Server 2003 certificate templates.
Important: Perform this procedure on the offline CA computer for your organization.
1. Unplug the offline root CA a. Remove the offline root CA computer from the network by unplugging
computer from the the network cable.
classroom network. b. Leave the offline root CA computer turned on.
Important: Perform this procedure on the domain controller for your domain. You will require a
floppy disk for transporting the CA certificate request file between the offline root CA and the
subordinate enterprise CA that you are installing.
2. Install Certificates Services a. Ensure you are logged on with the following credentials:
with the following options, • User name: Student1
and then save the request to
a file named a:\request.req. • Password: Password (where Password is the password for your
• Enterprise subordinate
CA • Domain: Domain (where Domain is the NetBIOS name of your
domain)
• CSP: Microsoft Strong
Cryptographic b. Insert a newly formatted floppy disk into the floppy disk drive.
Provider c. Insert the Windows Server 2003 Enterprise Edition disk into the
• Hash algorithm: SHA-1 CD-Rom drive, if you have not already done so.
• Key length: 2048 d. Click Start, click Control Panel, and then click Add or Remove
Programs.
• Common name:
DomainCA e. In the Add or Remove Programs window, click Add/Remove
Windows Components.
f. On the Windows Components page, select the Certificate Services
check box.
g. In the Microsoft Certificate Services dialog box, click Yes.
h. On the Windows Components page, click Next.
i. On the CA Type page, click Enterprise subordinate CA, select the
Use custom settings to generate the key pair and CA certificate
check box, and then click Next.
(continued)
2. (continued) j. On the Public and Private Key Pair page, set the following options:
• CSP: Microsoft Strong Cryptographic Provider
• Hash algorithm: SHA-1
• Key length: 2048
k. On the Public and Private Key Pair page, click Next.
l. On the CA Identifying Information page, enter the following
information:
• Common Name for this CA: DomainCA (where Domain is the
NetBIOS name of your domain from the table at the beginning of
the lab)
• Distinguished name suffix: ForestName (where ForestName is the
beginning of the lab)
Verify that the forest LDAP name that appears is the name of your
forest.
m. On the CA Identifying Information page, click Next.
n. On the Certificate Database Settings page, accept the default settings,
o. On the CA Certificate Request page, click Save the request to a file.
p. In the Request file box, type a:\request.req and then click Next.
q. In the Microsoft Certificate Services dialog box, click Yes to
temporarily stop Internet Information Services.
r. If the Files Needed dialog box appears, in the Files Needed dialog
box, in the Copy files from box, type x:\i386 (where x is the drive
letter of your CD-ROM drive), and then click OK.
s. In the Microsoft Certificate Services message box, acknowledge that
the CA installation is incomplete, and then click OK.
t. On the Completing the Windows Components Wizard page, click
Finish.
u. Close the Add or Remove Programs dialog box.
v. Remove the floppy disk that contains the certificate request file from
the floppy drive.
Important: Perform this procedure only on the offline CA for your organization. You must use the
floppy disk that contains the certificate request file from the enterprise subordinate CA.
3. Ensure you are logged on as a. Ensure that you are logged on with the following credentials:
a local administrator of the • User name: Administrator
root CA computer and then
insert the floppy disk that • Password: P@ssw0rd
contains the request.req file b. Insert the floppy disk containing the certificate request file in the
in the floppy drive. floppy disk drive.
(continued)
4. In the Certification a. Click Start, click Administrative Tools, and then click Certification
Authority console, request a Authority.
new certificate by using the b. In the console tree, right-click Computer, point to All Tasks, and then
A:\request.req request file. click Submit new request.
c. In the Open Request File dialog box, in the File name box, type
A:\Request.req and then click Open.
5. In the Certification a. In the console tree, expand Computer, and then click Pending
Authority console, issue the Requests.
pending certificate request. b. In the details pane, right-click the pending certificate, point to All
Tasks, and then click Issue.
6. Export the issued certificate a. In the console tree, click Issued Certificates.
to a PKCS #7 file named b. In the details pane, double-click the issued certificate.
subca.p7b that includes all
of the certificates in the c. In the Certificate dialog box, on the Details tab, click Copy to File.
certification path. d. On the Welcome to the Certificate Export Wizard page, click Next.
e. On the Export File Format page, click Cryptographic Message
Syntax Standard – PKCS #7 Certificates (.P7B), select the Include
all certificates in the certification path if possible check box, and
then click Next.
f. On the File to Export page, in the File name box, type a:\subca.p7b
g. On the Completing the Certificate Export Wizard page, click
Finish.
h. In the Certificate Export Wizard message box, click OK.
i. In the Certificate dialog box, click OK.
j. Close the Certification Authority console.
k. Close all open windows.
l. Remove the floppy disk that contains the certificate request file from
the floppy drive.
Important: Perform this procedure on the domain controller for your domain. Use the floppy disk that
contains the issued certificate from the offline root CA.
7. Install the CA certificate in a. Insert the floppy disk that contains the PKCS #7 file in the floppy
the Certification Authority drive.
console by using the b. Click Start, click Administrative Tools, and then click Certification
a:\subca.p7b file. Authority.
c. In the console tree, right-click DomainCA, point to All Tasks, and then
click Install CA Certificate.
d. In the Select file to complete CA installation dialog box, in the File
name box, type a:\subca.p7b and then click Open.
e. In the console tree, right-click DomainCA, point to All Tasks, and then
(continued)
8. View the CA certificate for a. In the Certification Authority console, in the console tree, expand
the DomainCA CA. DomainCA, right-click DomainCA, and then click Properties.
b. In the DomainCA Properties dialog box, click View Certificate.
What is the validity period of the Subordinate Certification Authority certificate?
The validity period is for ten years, as defined in the ValidityPeriodUnits registry entry of the root CA.
9. View the Certification Path " In the Certificate dialog box, click the Certification Path tab.
tab.
What is the CA hierarchy path for your enterprise subordinate CA?
The CA hierarchy path is Computer => DomainCA
10. Close the Certificate dialog a. In the Certificate dialog box, click OK.
box and the DomainCA b. In the DomainCA Properties dialog box, click OK.
Properties dialog box.
11. Increase the validity period a. Open a command prompt.
of issued certificates to 5 b. At the command prompt, type
years by using certutil – certutil -setreg ca\ValidityPeriodUnits 5 and then press ENTER.
setreg.
c. At the command prompt, type
certutil -setreg ca\ValidityPeriod "Years" and then press ENTER.
d. Close the command prompt.
12. Restart Certificate Services a. Switch to the Certification Authority console.

from the Certification b. In the console tree, right-click DomainCA, click All Tasks, and then
Authority console and then click Stop Service.
close the console.
c. In the console tree, right-click DomainCA, click All Tasks, and then
Module 4: Managing a
Public Key Infrastructure
Contents
Overview 1
Lesson: Introduction to PKI Management 2
Lesson: Managing Certificates 8
Lesson: Managing Certification Authorities 16
Lab A: Enabling Role Separation 24
Lesson: Planning for Disaster Recovery 40
Lab B: Backing Up and Restoring a
Certification Authority 51
respective owners.
Module 4: Managing a Public Key Infrastructure iii
Instructor Notes
Presentation: Managing a Public Key Infrastructure (PKI) means managing certificates and
60 minutes certification authorities (CAs) to ensure that the PKI functions properly in the
event of a disaster. Students learn to identify PKI management roles that are
Labs: required to perform typical CA and certificate management tasks, and how to
115 minutes recover a PKI in the event of a failure.
! Describe the use of Common Criteria roles in PKI management.
! Perform certificate management tasks.
! Perform CA management tasks.
! Plan for disaster recovery of Certificate Services.


! Complete the labs.
! For more information about implementing Common Criteria role separation,
see the white paper, Windows Server™ 2003 PKI Operations Guide, under
Additional Reading on the Web page on the Student Materials compact
disc.
! For more information about how renewing a CA with a new key affects
certificate revocation and the names of certificate revocation lists (CRLs),
see the white paper, Troubleshooting Certificate Status and Revocation,
compact disc.
iv Module 4: Managing a Public Key Infrastructure

Lesson: Introduction to PKI Management

In this lesson, students learn about the management tasks that are required to
manage certificates and CAs. These tasks are performed by individuals who are
in specific PKI administration roles. A CA administrator decides which users
and groups to assign to the predefined roles.
lesson.
PKI Management Tasks This topic explains the tasks that are involved in managing certificates and
CAs. Ensure that the students understand the distinction between certificate
management and CA management.
Common Criteria Roles Explain how role-based administration can be used to organize CA
in PKI Management administrators into separate, predefined task-based roles. Describe the Common
Criteria roles that administrators can use to manage certificates and CAs.
Emphasize that they should distribute management roles across different
individuals to ensure that a single individual cannot compromise PKI services.
How to Enable and Remind students that only members of the local Administrators security group
Disable Role Separation on a CA can enable and disable role separation. Emphasize that they must
restart Certificate Services to enforce the Role Separation configuration.
Guidelines for Enabling Based on what students have learned thus far, ask them to list some guidelines
Role Separation for enabling role separation. Discuss these guidelines with the class.
Lesson: Managing Certificates

This lesson describes the tasks that are involved in managing certificates. It
discusses the specific tasks that individuals perform in the Common Criteria
certificate manager role, how to designate certificate managers, and how to
restrict certificate managers. In addition, the lesson defines certificate
management tasks that are not defined in the Common Criteria role, and
provides guidelines for certificate management.
How to Add a Certificate Consider demonstrating how to define a certificate manager for the instructor’s
Manager BridgeCA. Be sure to follow the guideline for assigning Issue and Manage
Certificates permission to users or domain local groups.
Certificate Manager Ensure that students understand which certificate management tasks are
Tasks included in the certificate manager role.
Certificate Manager Emphasize that certificate manager restrictions are defined based on group
Restrictions memberships, not by a certificate template. Many students will assume that they
define certificate managers based on a templates, rather than on group
memberships. Consider describing a scenario in which a user has two group
memberships. In this situation, two certificate managers can manage the
certificates that are issued to the user.
Module 4: Managing a Public Key Infrastructure v
Other Certificate The Common Criteria Certificate Manager role does not perform all certificate
Management Tasks management tasks. Ask students if they can identify other certificate
management tasks, beyond those that are discussed in this topic.
When you describe these tasks, clarify that an individual who performs a
Common Criteria role can also perform the tasks that are described on this
page. The actual design decision is based on the security policy of the
organization—specifically, whether the organization allows one person to
perform two or more tasks.
Guidelines for Discuss these guidelines with the class. Ask students for feedback about the
Certificate Management guidelines to see if they recommend different practices for their organization.
Lesson: Managing Certification Authorities

In this lesson, students will learn about CA management, which includes how to
add a CA administrator, who can install and configure CAs, and how to renew
and audit certificates. The lesson also discusses guidelines for CA management.
How to Add a CA Consider demonstrating how to add a CA administrator in the Certification
Administrator Authority console in Microsoft Management Console (MMC). Mention to
students that they should assign only domain local groups or local groups as CA
administrators.
Discuss the fact that users may be blocked from CA management tasks if an
incorrect permission is assigned. For example, if an administrator assigns a
group Manage CA and Issue and Manage Certificates permissions, the users in
the group are immediately blocked from all CA and certificate management
tasks.
Who Can Install and Review the CA management tasks and the tasks that administrators perform in
Configure a CA? each Common Criteria role.
How to Renew a CA Explain to students that they renew a certification authority when there is a
Certificate change in the CA certificate policy or when the CA’s Certification Authority
certificate expires. Remind students to never re-use a key pair more than once
when they renew the CA certificate. Also remind them to select the appropriate
key length for the CA public and private key pair. Explain the importance of
having a plan to renew the CA certificate before it expires.
How to Audit Certificate Discuss the certificate-related events that can be audited. Discuss how to enable
Services auditing, how to configure event auditing, and where to view the recorded
events in Event Viewer. Emphasize that Certificate Services auditing requires
that you enable success and failure audits for Object Access.
Guidelines for Defining Review and discuss the guidelines for CA management with students.
CA Management
vi Module 4: Managing a Public Key Infrastructure
Lesson: Planning for Disaster Recovery

In this lesson, students will learn to back up and restore CAs. Students will also
learn about the importance of creating a disaster recovery plan, and what to
document in that plan.
Why Implement Disaster Describe the reasons for implementing disaster recovery and the situations in
Recovery? which disaster recovery is useful. Emphasize that students should first try to
repair their computer by using Safe Mode or other utilities that the operating
system provides before they implement disaster recovery.
What to Document for Tell students that to perform a complete disaster recovery, they use a recent
Disaster Recovery backup of their entire system, including the registry, the system files, and the
data files. Tell them that this topic includes recommendations about additional
information to document to ensure a successful recovery.
How to Back Up CA Administrators back up the CA private key and public key to a PKCS #12 file
Private and Public Keys by exporting the CA’s certificate and including the private key. Discuss how to
back up a CA’s private and public key for hardware and software cryptographic
service providers (CSPs). Consider demonstrating how to back up the key pair.
Methods for Backing Up Explain the two methods for backing up a CA: System State backup and
a CA manual backup. Tell the students that it is recommended that they use System
State backups when backing up a CA for disaster recovery. Tell students that
they must perform a manual backup of the CA when they want to change the
policy of the CA from a standalone CA to an enterprise CA. This configuration
change requires that only the CA database and private key are backed up.
How to Restore Discuss how the type of restoration varies, depending on whether they are
Certificate Services restoring a CA from a System State backup or a manual backup.
Guidelines for Planning Summarize this module by discussing the guidelines on this page. Emphasize to
Disaster Recovery of students the importance of creating a disaster recovery plan to ensure that they
CAs can quickly restore all of their systems and data to normal operation in the event
of a disaster.
Lab A: Enabling Role Separation

In this lab, students will enable role separation and then investigate the tasks
that CA administrators and certificate managers perform.
In this lab, students will:
! Enable and enforce role separation.
! Assign permissions for CA administrators and certificate managers.
! Assign auditing roles.
If a student assigns two roles to the same security group in this lab (typically
the CAAdmins or CertAdmins global groups), ask them to disable role
separation (certutil –delreg ca\RoleSeparationEnabled) and remove the extra
permission assignment. Be sure to remind the student to enable role separation
afterwards (certutil –setreg ca\RoleSeparationEnabled 1).
Module 4: Managing a Public Key Infrastructure vii
Lab B: Backing Up and Restoring a Certification Authority

In this lab, students will perform a manual backup and a System State backup.
They will:
! Assign the backup role for Certificate Services.
! Perform a manual back up of a CA by using Certutil.exe.
! Back up a CA by performing a System State backup.
! Restore a CA from a System State backup.
This lab will take about one hour to complete. If the system state restoration
fails, students can restore Certificate Services from the manual backup files that
they created in the lab.
Lab Setup
Setup requirement 1 The labs in this module require the creation of a custom MMC named
Certificate Management to be saved on the desktop. To prepare student
computers to meet this requirement, complete Module 1, “Overview of Public
Key Infrastructure,” in Course 2821, Designing and Managing a Windows
Setup requirement 2 The student in each student pair whose computer is the domain controller for
their domain will perform the manual backup and System State backup. The
other student in each student pair will observe the lab results.
Lab Results
changes:
! The CAAdmins group is assigned Manage CA permission.
! The CertAdmins group is assigned Issue and Manage Certificates
permission.
! Role separation is enforced.
! Auditing is enabled on the enterprise subordinate CA.

! A manual backup of the enterprise subordinate CA exists in the C:\Temp
folder.
! A PKCS #12 file of the CA’s private key exists in the C:\Temp folder.
! A System State backup of the enterprise subordinate CA exists in the
C:\Temp folder.
! Certificate Services is restored and running on the enterprise subordinate
CA.
Module 4: Managing a Public Key Infrastructure 1
Overview

Introduction Certificates and certification authorities (CAs) are two main components of a
public key infrastructure (PKI) that require detailed planning for the PKI design
and implementation. You must manage these two components to ensure that a
PKI functions properly during normal operations and in the event of a disaster.
To enhance the security of your PKI, you split the management of CAs and
certificates between distinct groups of users. This way, you ensure that no one
user manages all aspects of the PKI.
In this module, you will learn how to manage certificates and CAs, which PKI
management roles are required to perform typical CA tasks and certificate
management tasks, and what steps to take to ensure that you can recover your
PKI in the event of a failure.
! Describe the use of Common Criteria roles in PKI management.
! Perform certificate management tasks.
! Perform CA management tasks.
! Plan for disaster recovery of Certificate Services.
2 Module 4: Managing a Public Key Infrastructure
Lesson: Introduction to PKI Management

Introduction Managing certificates and CAs involves various management tasks. Individuals
in specific PKI administration roles perform these tasks. Each role in PKI
administration includes a specific set of management tasks. A CA administrator
decides which users and groups to assign to the predefined roles.
! Describe the tasks that are involved in managing a PKI.
! Define the common criteria roles in PKI management.
! Enable and disable role separation.
! List the guidelines for enabling role separation.
PKI Management Tasks

Introduction Managing a PKI consists of two categories of management tasks: certificate
management and CA management.
Certificate management Managing certificates include the following tasks:
tasks
! Create and modify certificate templates. A certificate template, which is an
object in the Active Directory® directory service, defines the attributes of
certificates that are issued to computers and users for use with PKI-enabled
applications, including issuance requirements and permissions for
enrollment.
! Issue or deny pending certificate requests. When you use highly valuable or
sensitive certificate templates, such as the Key Recovery Agent certificate
template, keep the certificate request pending before you issue it. This way,
the certificate manager can evaluate the certificate request, ensure that it is
from an authorized user, computer, or service, and then issue or deny the
certificate request.
! Revoke issued certificates. A certificate manager must revoke a certificate if
the recipient of the certificate breaks the rules that are defined in the
certificate practice statement or if the private key that is associated with the
certificate is compromised. Revocation terminates the validity of the
certificate before its validity period expires.
! Determine key recovery agents (KRAs). A certificate manager determines
which defined KRA can decrypt an archived private key from the CA
database.
CA management tasks Managing CAs includes the following tasks:

! Install CAs. When you deploy a CA, designate one person to perform the
installation and initial configuration of the CA.
! Renew CA certificates. Be sure to renew the CA certificate periodically to
ensure its continued validity.
! Define key recovery agents. A certificate manager determines one or more
KRAs whose public keys encrypt the archived private keys on a specific
CA. The KRAs can then use their private keys to recover the archived
private keys from the CA database.
! Define certificate managers. Designate certificate managers to issue and
deny certificate requests and to extract encrypted private keys from the CA
database for key recovery.
! Back up and restore the CA. Back up the CA database and then restore it to
ensure that you can recover the contents of the CA database in the event of
CA failure.
! Audit Certificate Services. Audit all Certificate Services management tasks
to ensure that the people who perform these tasks are following all rules that
are defined in the organization’s security policy.
Common Criteria Roles in PKI Management

Introduction Use role-based administration to organize CA administrators into separate,
predefined task-based roles. To assign a role to a user or group, assign the
security permissions, group memberships, or user rights that are associated with
the role.
Distribute management roles among several individuals in your organization to
ensure that a single individual cannot compromise PKI services. Role
separation enables one person to audit the actions of another person.
Common Criteria PKI The Common Criteria PKI management roles in Microsoft®
management roles Windows Server™ 2003 include:
! CA Administrator. Configures and maintains the CA, designates other CA
administrators and certificate managers, and renews CA certificates.
! Certificate Manager. Approves or denies certificate enrollment requests and
revokes issued certificates.
! Backup Operator. Performs backups of the CA database, the CA
configuration, and the CA’s private and public key pair (also known as a
key pair).
! Auditor. Defines what events are audited for Certificate services and
reviews the security log in Windows Server 2003 for success and failure
audit events that are related to Certificate Services.
You define the CA Administrator and Certificate Manager roles on each CA in

the CA hierarchy. You define the Backup Operator and Auditor roles in either
the Local Security Policy or a Group Policy object that is applied to the CA
computer.
Note Role-based administration is supported by both Windows 2003 enterprise

CAs and standalone CAs running Windows Server 2003, Enterprise Edition or
Windows Server 2003, Datacenter Edition.
How to Enable and Disable Role Separation

Introduction You enable role separation by editing the registry of the Windows Server 2003
family server running Certificate Services. When you edit this registry setting,
any assigned roles are in effect until a local administrator of the server disables
role separation in the registry. You must be a local administrator of the CA
computer to enable and disable the role separation registry setting.
The CA administrator can assign and change CA roles when role separation is
enabled or disabled. When role separation is enabled, the CA administrator
cannot assign a user to more than one CA role.
Criteria for enforcing You can assign the necessary permissions to manage and CAs on any server
role separation running the Windows Server 2003 family. However, you can enforce role
separation only on CAs running Windows Server 2003, Enterprise Edition and
Windows Server 2003, Datacenter Edition, including the 64-bit version of both
versions.
A local administrator must enable role separation on each CA to enforce the
separation of roles.
Procedure for enforcing To enforce role separation, at the command prompt, type:
role separation
certutil -setreg ca\RoleSeparationEnabled 1
Procedure for disabling To disable role separation, at the command prompt, type:
role separation
certutil -delreg ca\RoleSeparationEnabled
Important The certutil command is executed only when you restart the
Certificate Services on the CA.
Guidelines for Enabling Role Separation

Introduction The extent to which you separate roles depends on the level of security that you
require for a particular service. Assign a user the fewest possible roles to
achieve the greatest level of security.
Guidelines Consider the following guidelines when you enable role separation:
! Assign roles to domain local groups, not to users. Assign PKI roles to
domain local groups in the domain in which the CA’s computer account is
located or to local groups in the CA computer’s Security Accounts Manager
(SAM) database. If you assign the role directly to a user account, you must
re-assign permissions for the role if a different user is assigned the role.
However, if you assign the role to a group, you only must modify the group
membership to allow a different user to assume the role.
! Assign a user to one role. A user’s group memberships defines the users
role in PKI management if permissions are assigned to groups. If a user is
assigned two or more PKI management roles, Certificate Services prevents
the user from performing any management functions on the CA.
! Limit membership in the Local Administrators group. CA administrators
and certificate managers must not be members of the local Administrators
group. Membership in this group is only required to enable role separation,
to install the CA, and to renew the CA certificate. It is considered excess
privilege to make a CA administrator or certificate manager a local
administrator of the CA.
Warning If you assign a second CA role to a user when role separation is

enabled, the user may be locked out of administering a CA. Because of role
separation, the user cannot perform any activity on the CA, including removing
herself from one of the roles.
Lesson: Managing Certificates

Introduction Certificate management includes reviewing, issuing, and denying certificate
requests by using the guidelines that an organization defines in the certificate
practice statement (CPS). Using a CPS provides guidelines for certificate use,
ensures that the certificates are issued only to authorized users, and enables the
revocation of certificates if they are not used as defined in the CPS.
! Add a certificate manager.
! Identify certificate manager tasks.
! Restrict certificate managers.
! Identify other certificate management tasks.
! Follow guidelines for certificate management.
How to Add a Certificate Manager

Introduction Certificate managers issue certificates, deny issue certificate requests, and
revoke certificate before the certificates expire. A user that is a member of a
group assigned the Manage CA permission can designate certificate managers
by modifying the permissions of the CA.
Procedure for adding a To add a certificate manager:
certificate manager
1. Open the Certification Authority console.
2. In the console tree, right-click CAName, and then click Properties.
Note It is recommended to only assign domain local groups or local groups

as certificate managers. The domain local groups must be added from the
domain in which the CA is a member and the local groups from the local
SAM database of the CA.
3. On the Security tab, click Add, and then type the names of any domain
local groups that will be CA administrators.
4. Assign the users or groups Issue and Manage Certificates permission, and
then click OK.
Certificate Manager Tasks

Introduction A certificate manager is responsible for all management functions of the
certificates that are issued by a CA. Management functions include issuing or
denying pending certificates (subject to the certificate practice statement of the
CA), deleting certificates from the CA database, and revoking certificates
before their validity period expires.
Certificate Manager A user who is assigned Issue and Manage Certificates permission holds the
Tasks Certificate Manager common criteria role. A certificate manager performs the
following tasks:
! Issues certificates. If a certificate template places the certificate request in a
pending state, a certificate manager can issue the certificate if the certificate
request is valid.
! Deletes certificates. A certificate manager can delete a certificate from the
CA database if the certificate has been revoked or has expired.
! Denies certificate requests. If a certificate template places the certificate
request in a pending state, a certificate manager can deny the certificate if
the certificate request is not valid.
! Revokes certificates. If the recipient of a certificate breaks the rules that are
defined in the CPS, or if the private key of a certificate is compromised, a
certificate manager can revoke the certificate and terminate the validity of
the certificate before its expiry date.
! Determines Key Recovery Agents. A certificate manager can inspect the
properties of a certificate by using an archived private key to determine
which KRA can recover the archived private key. The certificate manager
retrieves the archived private key from the CA database and provides the
extracted blob to the KRA for recovery.
Note For more information about key archival and recovery, see Module 7,
“Configuring Key Archival and Recovery,” in Course 2821, Designing and
Certificate Manager Restrictions

Introduction Although some organizations’ security policies allow certificate managers to
manage all certificates that are issued by a CA, other organizations require that
certificate managers manage only a subset of the issued certificates.
Certificate manager Certificate manager restrictions allow a CA administrator to limit certificate
restrictions managers to managing only certificates that are issued to specific security
groups. If a user or computer does not belong to a security group that the
certificate manager is allowed to manage, the certificate manager is blocked
from certificate management functions.
For example, if a certificate manager is allowed to only manage certificates that
are issued to the members of the Marketing global group, the certificate
manager is blocked from revoking or issuing certificates that are issued to users
who are not members of that group.
To restrict a certificate manager, a CA administrator must assign Issue and
Manage Certificates permission to the certificate manager’s user account. If you
assign a group Issue and Manage Certificates permission, you cannot assign
individual certificate manager restrictions to the individual members of the
group. You can only define certificate manager restrictions to security
principals that are assigned Issue and Manage Certificates permission.
Warning In Windows Server 2003, you cannot restrict certificate management

to specific certificate templates, only to specific global groups. A certificate
manager can issue, deny, or revoke certificate requests for any certificate that is
requested by a user who has membership in a group that the certificate manager
manages.
Other Certificate Management Tasks

Introduction In addition to the tasks that are performed in the Certificate Manager role, there
are other tasks related to certificate management, such as certificate template
design and publication of certificate revocation lists (CRL) information that are
not performed by the Certificate Manager role.
Certificate template Designing certificate templates is considered a certificate management task. A
design designated certificate template administrator is responsible for creating and
modifying certificate templates.
By default, only members of the Enterprise Admins and Domain Admins
groups in the forest root domain can create and modify certificate templates.
Only these two groups have the necessary permissions to modify objects in the
CN=Certificate Templates and CN=OID containers in the CN=Public Key
Services, CN=Services, CN=Configuration, CN=ForestRootDomainDN (where
ForestRootDomainDN is the Lightweight Directory Access Protocol (LDAP)
distinguished name of the forest root domain) container in Active Directory.
You can delegate the administration of certificate templates by assigning the
Full Control permission to a universal or global group to the Certificate
Templates and OID containers.
CRL publication Another certificate management task is the publication of CRL information. By
default, users and groups that are assigned Manage CA permission can publish
CRLs and delta CRLs on a CA.
In addition to publishing the CRL, a user or group that has the Manage CAs
permission can modify the publication interval for CRLs. Separate publication
intervals are defined for CRLs and for delta CRLs.
Guidelines for Certificate Management

Introduction Certificate management includes managing certificates that are issued by a CA,
which includes issuing pending certificates, denying invalid certificate requests,
and revoking certificates. Certificate management tasks also include designing
certificate templates and publishing CRLs.
Guidelines Consider the following guidelines for managing certificates:
! Assign roles to domain local groups or to local groups in the CA computer’s
SAM database. Assign Issue and Manage Certificates permission to domain
local groups in the domain in which the CA’s computer account is located
or to local groups in the CA computer’s SAM database.
Note If you implement certificate manager restrictions, you must assign

Issue and Manage Certificates permission to each individual certificate
manager’s user account. You can define certificate manager restrictions
only for user or group accounts that are directly assigned the Issue and
Manage Certificates permission.
! Do not assign Issue and Manage Certificates permission to members of the

local Administrators group. Such an assignment creates excess permissions,
which allows the certificate manager to perform other computer
management tasks that you may not want him to perform.
! Delegate the management of certificate templates to a separate security

group. Although there are no restrictions against assigning the certificate
template administration permissions to one of the Common Criteria role
holders, it is recommended that you implement a separate security group to
manage certificate templates.
Note The decision whether to delegate certificate template management to

a custom group must be based on the security policy of your organization. If
the security policy allows one group to hold multiple roles, consider
combining the certificate template management role with either the CA
administrators or certificate manager’s role.
! Implement certificate manager restrictions. Such restrictions enable you to

delegate more certificate management tasks by ensuring that a certificate
manager can manage only certificates that are issued to members of a
specific security group. Certificate manager restrictions can reduce the
number of CAs in the CA hierarchy by allowing two or more groups to
share certificate management on a specific CA.
Lesson: Managing Certification Authorities

Introduction Another PKI management role is the management of CAs, which includes
creating and signing certificates, issuing and managing CRLs, keeping a record
of all expired and revoked certificates, and formulating policies and statements.
You can delegate CA management on a CA basis in the CA hierarchy to ensure
that one CA administrator cannot manage all aspects of the PKI.
! Add a CA administrator.
! Identify who can install and configure a CA.
! List the steps for renewing a CA certificate.
! Configure auditing for Certificate Services.
! List the guidelines for CA management.
How to Add a CA Administrator

Introduction You define a CA administrator in the Certification Authority console. It is
recommended that you only assign domain local groups or local groups as CA
administrators.
Procedure for adding a To add a CA administrator:
CA administrator
2. In the console tree, right-click CAName, and then click Properties.
Note It is recommended to only assign domain local groups or local groups

as CA administrators. The domain local groups must be added from the
domain in which the CA is a member and the local groups from the local
SAM database of the CA.
3. On the Security tab, click Add, and then type the names of the domain local
groups that will be CA administrators.
4. Assign the users or groups Manage CA permission, and then click OK.
Who Can Install and Configure a CA?

Introduction When you implement role separation, only specific roles can perform the CA
installation and configuration tasks.
CA configuration tasks You can divide CA configuration responsibilities into three general tasks:
! Install. Only local administrators of a computer can install Certificate
Services to create a CA. If the CA is an enterprise CA, the installer must
also be a member of the Enterprise Admins group, so that the installer can
modify the configuration naming context with the new CA’s naming
information.
! View. When you enable role separation, only Common Criteria role holders
can view the current configuration of the CA. Members of the local
Administrators and Enterprise Admins groups cannot view the CA
configuration unless they are also assigned a single PKI management role.
! Modify. Only CA administrators can modify the current configuration of a
CA when role separation is implemented. The only exception to this rule is
when the CA certificate is renewed. Only members of the Local
Administrators group can renew an enterprise CA’s certificate. To renew the
CA certificate, you must temporarily disable role separation.
Warning A local administrator can view and modify the CA configuration at

any time by disabling role separation. Ensure that you enable auditing on CAs
to determine if a local administrator is modifying CA configuration settings.
How to Renew a CA Certificate

Introduction You renew a CA certificate when a change occurs in the certificate policy or
when the CA’s issuing certificate expires. Like any account, each CA is also
issued a certificate. A root CA issues a certificate for itself. A subordinate CA
gets its certificate from its parent CA. Every CA certificate has a defined
validity period, during which the CA can issue certificates. After the CA
reaches the expiration date, the CA does not have a valid certificate of its own.
Considerations for When you renew a CA certificate, you can reuse its existing key pair or
renewing a CA generate a new key pair. Never reuse a key pair more than once, because it is
certificate mathematically possible to derive a private key from the matching public key. If
you generate a new key pair for the CA, the CA creates a separate CRL for that
key pair.
Note For more information about how renewing a CA with a new key affects
certificate revocation and the names of CRLs, see the white paper,
When you choose a key length for the CA’s key pair, ensure that the key length
is neither too short nor too long. Short key lengths can compromise the CA’s
private key. If you implement a long key length, it can take too much time for
the Cryptographic Service Provider (CSP) to generate key pairs. When you
renew a CA certificate, you can implement a longer key length if the previous
key length was too short. To protect a CA against attackers who attempt to
determine the private key based on the public key, always implement a key
length between 1024 and 4096 bits.
Although a CA that is approaching the end of its validity period issues
certificates that are valid for shorter periods of time, you must have a plan to
renew the CA certificate before it expires.
Procedure for renewing To renew a CA certificate:

a CA certificate
1. Log on as a local administrator to the computer that is configured as a CA.
3. In the console tree, click the name of the CA.
4. On the Action menu, point to All Tasks, and then click Renew CA
Certificate.
5. Do one of the following:
a. Click Yes if you want to generate a new key pair for the CA certificate.
b. Click No if you want to reuse the current key pair for the CA certificate.
How to Audit Certificate Services

Introduction You can enable auditing on a CA in Windows Server 2003 to provide an audit
log for all CA and certificate management tasks. All Certificate Services
auditing is reported to the security log in Event Viewer.
Events to audit You can enable auditing of the following events for Certificate Services on a
CA. These events record who performs the audited tasks:
! Back up and restore the CA database
! Change CA configurations
! Change CA security settings
! Issue and manage certificate requests
! Revoke certificates and publish CRLs
! Store and retrieve archived keys
! Start and stop Certificate Services
Procedure for enabling To enable auditing for Certificate Services:

Certificate Services
auditing ! Configure the server to audit successes and failures for object access.
! Enable all auditing events for the CA.
! Define who can perform auditing by assigning a user or group the Manage
auditing and security log user right. Defining who can perform auditing
enables the user or group to audit all events on the CA, not just the CA-
related events.
Note To ensure that you maintain role separation, do not assign the Manage
auditing and security log user right to members of the CA Administrators and
Certificate Managers groups on a CA.
Procedure for To determine which events are audited on a CA:

configuring event
auditing 1. Log on as user that is assigned the Manage auditing and security log user
right.
3. In the console tree, click the name of the CA that you want to audit for
events.
4. On the Action menu, click Properties.
5. On the Auditing tab, click the events that you want to audit.
Guidelines for Defining CA Management

Introduction CA management includes the installation and configuration of a CA. It also
includes the renewal of a CA certificate when the validity period of the
certificate expires.
Guidelines Consider the following guidelines for defining CA management:
Assign roles to domain local groups or to local groups in the CA computers
security account management (SAM) database. Assign the Manage CA
permission to domain local groups in the domain in which the CA’s computer
account is located or local groups in the CA computer’s SAM database. If you
assign the role directly to a user account, you will have to redefine the role if a
different user takes on the role. However, if you assign the role to a group, you
will only have to modify the group membership to allow a different user to
assume the role.
Do not assign Manage CA permission to members of the local Administrators
group. Such an assignment creates excess permissions, which allows the CA
manager to perform other computer management tasks.
Disable role separation only for certificate renewal. Role separation ensures
that a user can hold only one of the Common Criteria roles. Certificate renewal
for a CA requires that the user is a local Administrator of the computer and is
assigned Manage CA permission.
Enable auditing of all PKI management tasks. Auditing provides complete
details of all management tasks that are performed on a CA. Auditing reveals if
a local administrator has attempted to disable role separation and perform PKI
management tasks.
Lab A: Enabling Role Separation

! Enable and enforce role separation.
! Assign permissions for CA administrators and certificate managers.
! Assign auditing roles.
Note This lab focuses on the concepts in this module and as a result may not
comply with Microsoft security recommendations. For instance, the Issue and
Manage Certificates permission is assigned to a user account rather than to a
security group.

! Installed a Windows Server 2003 CA hierarchy with an offline standalone
root CA and an online subordinate enterprise CA.
! Knowledge of how to implement role separation for a Windows Server 2003
PKI.
Additional information For more information about enabling role separation in a Windows Server 2003
PKI, see the white paper, Windows Server 2003 PKI Operations Guide, under
Estimated time to
complete this lab:
45 minutes
Exercise 1
Defining CA Administrators and Certificate Managers
In this exercise, you will modify the default permissions for the DomainCA (where Domain is the
NetBIOS name of your Active Directory domain) to enable role separation. You will designate the
CAadmins group as CA administrators and the CertAdmins group as certificate managers for your
enterprise subordinate CA and then enforce role separation.
Scenario
The security policy and the certificate policy for your organization require that you enable role
separation in your PKI. You must configure the enterprise subordinate CA to implement role
separation so that you can designate groups as CA administrators and certificate managers.
Important: Perform this procedure at the domain controller for your domain.
1. Log on by using your a. Log on to the domain controller by using the following account
administrative account for information:
your domain, and then open • User name: Student1
the Certification Authority
console. • Password: Password (where Password is the password assigned to
your administrative account)
domain)
b. Click Start, click Administrative Tools, and then click Certification
Authority.
2. Display the current a. In the Certification Authority console, in the console tree, right-click
permission assignments for DomainCA, and then click Properties.
DomainCA. b. In the DomainCA Properties dialog box, click the Security tab.
Which groups are designated as CA administrators and certificate managers? What permission are the groups
assigned?
The Administrators, Domain Admins and Enterprise Admins groups are designated as both CA
administrators and certificate managers. CA administrators are assigned the Manage CA permission
and certificate managers are assigned the Issue and Manage Certificates permission.
(continued)
3. Assign the CAadmins group a. In the DomainCA Properties dialog box, click Add.
the Manage CA permission. b. In the Select Users, Computers, or Groups dialog box, in the Enter
the object names to select box, type CA and then click Check Names.
c. In the Multiple Names Found dialog box, in the Matching names list,
select CAadmins, and then click OK.
d. In the Select Users, Computers, or Groups dialog box, ensure that
CAadmins appears in the Enter the object names to select box, and
then click OK.
e. In the DomainCA Properties dialog box, in the Group or user names
list, select CAadmins, and then in the Permissions for CAadmins list,
select the Allow check box for the Manage CA permission.
The Request Certificates permission is automatically assigned to
any security principals that were added to the discretionary
access control list (DACL). You can leave this default permission
assignment.
f. In the DomainCA Properties dialog box, click Apply.
4. Assign the CertAdmins a. In the DomainCA Properties dialog box, click Add.
group the Issue and b. In the Select Users, Computers, or Groups dialog box, in the Enter
Manage Certificates the object names to select box, type Cert and then click Check
permission. Names.
select CertAdmins, and then click OK.
CertAdmins appears in the Enter the object names to select box, and
then click OK.
e. In the DomainCA Properties dialog box, in the Group or user names
list, select CertAdmins, and then in the Permissions for CertAdmins
list, select the Allow check box for the Issue and Manage Certificates
permission.
f. In the DomainCA Properties dialog box, click Apply.
(continued)
5. Remove all permissions that a. In the DomainCA Properties dialog box, in the Group or user names
are assigned to the list, select Administrators, and then click Remove.
Administrators, Domain b. In the DomainCA Properties dialog box, in the Group or user names
Admins, and Enterprise list, select Domain Admins, and then click Remove.
Admins groups.
c. In the DomainCA Properties dialog box, in the Group or user names
list, select Enterprise Admins, and then click Remove.
d. In the DomainCA Properties dialog box, click OK.
6. Enforce role separation by a. At a command prompt, type C: and then press ENTER.
running the b. At the command prompt, type cd \moc\2821\labfiles\module4 and
C:\moc\2821\labfiles\ then press ENTER.
module4\rolesep.cmd and
then log off the network. c. At the command prompt, type rolesep.cmd and then press ENTER.
e. Close all open windows and then log off.
Exercise 2
Restricting Certificate Managers
In this exercise, you will implement restrictions that limit the groups that the CertAdmins group can
manage certificates for.
Scenario
The security policy of your organization requires that only a specific user account, Finance1, may
manage the certificates that are issued to members of the Finance department. You must enforce
this policy by implementing certificate manager restrictions.
Important: Perform this procedure only on the member server for your domain.
1. Log on as a CA " Log on to the member server by using the following account
administrator for your information:
enterprise CA. • User name: CAAdmin2
domain)
2. Open the Certification a. Click Start, click Administrative Tools, and then click Certification
Authority console focused Authority.
on the enterprise CA for b. In the Microsoft Certificate Services message box, click OK.
your domain.
c. In the console tree, right-click Certification Authority, and then click
Retarget Certification Authority.
d. In the Certification Authority dialog box, click Another computer,
and then click Browse.
e. In the Select Certification Authority dialog box, select DomainCA,
and then click OK.
f. In the Certification Authority dialog box, click Finish.
3. Assign the Finance1 user a. In the console tree, right-click DomainCA, and then click Properties.
account the Issue and b. In the DomainCA Properties dialog box, on the Security tab, click
Manage Certificates Add.
permission for the enterprise
CA. c. In the Select User, Computer, or Group dialog box, in the Enter the
object name to select box, type Fin and then click Check Names.
d. In the Multiple Names Found dialog box, in the Matching names
list, select Finance1, and then click OK.
e. In the Select User, Computer, or Group dialog box, ensure that
Finance1 appears in the Enter the object name to select box, and
then click OK.
(continued)
3. (continued) f. In the DomainCA Properties dialog box, in the Group or user names
list, select Finance1, and then in the Permissions for Finance1 list,
select the Allow check box for the Issue and Manage Certificates
permission.
g. In the DomainCA Properties dialog box, click Apply.
4. Enable certificate manager a. In the DomainCA Properties dialog box, on the Certificate Managers
restrictions so that the Restrictions tab, click Restrict certificate managers.
CertAdmins group cannot b. In the Available certificate managers drop-down list, select
manage certificates for the Domain\CertAdmins.
FinanceDept global group.
c. On the Certificate Managers Restrictions tab, click Add.
d. In the Select Users, Computers, or Groups dialog box, in the Enter
the object names to select box, type Fin and then click Check Names.
e. In the Multiple Names Found dialog box, in the Matching names list,
select FinanceDept, and then click OK.
f. In the Select Users, Computers, or Groups dialog box, ensure that
FinanceDept appears in the Enter the object names to select box, and
then click OK.
g. On the Certificate Managers Restrictions tab, in the Groups, users,
or computers to manage list, select Domain\FinanceDept, and then
click Deny.
5. Define certificate manager a. In the Available certificate managers drop-down list, select
restrictions so that the Domain\Finance1.
Finance1 user account can b. On the Certificate Managers Restrictions tab, in the Groups, users,
only manage certificates that or computers to manage list, select Everyone, and then click
are issued to the Remove.
FinanceDept group.
c. On the Certificate Managers Restrictions tab, click Add.
d. In the Select User, Computer, or Group dialog box, in the Enter the
object name to select box, type Fin and then click Check Names.
select FinanceDept, and then click OK.
f. In the Select User, Computer, or Group dialog box, ensure that
FinanceDept appears in the Enter the object name to select box, and
then click OK.
g. In the DomainCA Properties dialog box, click OK.
h. Close all open windows and then log off.
Exercise 3
Generating Certificate Requests
In this exercise, you will log on as different users in the domain and generate certificate requests by
using a batch file that uses the CertReq.exe certificate request command file.
Scenario
To simulate a network where several certificates are issued, you must log on to the network by
using different user accounts and execute a command file that requests user certificates from the
enterprise CA in your organization.
1. Log on as a member of the " Log on to your computer by using the following credentials:
Finance department. • User name: Finance1 (on the domain controller) or Finance2 (on
the member server)
domain)
2. Create the c:\temp folder to a. Open a command prompt.

store temporary files. b. In the command prompt, type c: and then press ENTER.
c. In the command prompt, type md \Temp and then press ENTER.
3. Submit a certificate request a. Open C:\moc\2821\labfiles\module4.

to the enterprise CA in your b. In the C:\moc\2821\labfiles\module4 folder, double-click
domain by running requestcert.cmd.
requestcert.cmd in the
C:\moc\2821\labfiles\ c. In the Select Certification Authority dialog box, click DomainCA,
module4 folder. and then click OK.
d. Close all open windows and then log off the network.
Accounting department. • User name: Accounting1 (on the domain controller) or
Accounting2 (on the member server)
• Domain: Domain
5. Submit a certificate request a. Open C:\moc\2821\labfiles\module4.

to the enterprise CA in your b. In the C:\moc\2821\labfiles\module4 folder, double-click
domain by running requestcert.cmd.
requestcert.cmd in the
C:\moc\2821\labfiles\ c. In the Select Certification Authority dialog box, click DomainCA,
module4 folder. and then click OK.
d. Close all open windows and then log off.
Exercise 4
Testing CA Administrator Tasks
In this exercise, you will log on as a user that has the Manage CA permission and attempt to
perform several CA and certificate management tasks.
Scenario
After enabling role separation for the issuing CA in your organization, you must determine what
tasks the CA administrators can perform for CA management and certificate management.
CAAdmins group. • User name: CAAdmin1 (at the domain controller) or CAAdmin2
(at the member server)
domain)
2. Open the Certification " Click Start, click Administrative Tools, and then click Certification
Authority console. Authority.
When you work on the member server in your domain, an error
will appear, informing you that Certificate Services is not an
installed service. You must retarget the console to the domain
controller.
Important: Perform this procedure on the member server in your domain.
3. Retarget the Certification a. In the Microsoft Certificate Services message box, click OK.
Authority console to b. In the console tree, right-click Certification Authority, and then click
manage the enterprise CA Retarget Certification Authority.
on the domain controller.
c. In the Certification Authority dialog box, click Another computer,
d. In the Select Certification Authority dialog box, select DomainCA,
and then click OK.
e. In the Certification Authority dialog box, click Finish.
4. View the Security tab of the a. In the console tree, right-click DomainCA, and then click Properties.
DomainCA Properties b. In the DomainCA Properties dialog box, click the Security tab.
dialog box.
(continued)
Can you modify the permissions for the CA?
Yes, CA administrators can modify the permissions for the CA.
5. View the Auditing tab of " In the DomainCA Properties dialog box, click the Auditing tab.
the DomainCA Properties
dialog box.
Can you modify the audit settings for the CA?
No, only accounts that are assigned the Manage Audit and Security log user right can modify the
auditing properties of a CA.
6. View the CRL Publication a. In the DomainCA Properties dialog box, click Cancel.
properties. b. In the console tree, expand DomainCA.
c. In the console tree, right-click Revoked Certificates, and then click
Properties.
Can you modify the CRL and delta CRL publication intervals?
Yes, a CA administrator can modify CRL and delta CRL publication intervals.
7. Attempt to publish an a. In the Revoked Certificates Properties dialog box, click Cancel.
update CRL or delta CRL. b. In the console tree, right-click Revoked Certificates, point to All
Tasks, and then click Publish.
Can you publish the CRL and delta CRL?
Yes, a CA administrator can publish CRL and delta CRL publication intervals.
8. Attempt to revoke the a. In the Publish CRL dialog box, click Cancel.
certificate issued to b. In the console tree, click Issued Certificates.
Domain\Finance1.
c. In the details pane, expand Requester Name, right-click the certificate
by using a requester name of Domain\Finance1, and then point to All
Tasks.
(continued)
Can you revoke a certificate?
No. Only users that are assigned the Issue and Manage Certificates permission for a CA can issue and
revoke certificates.
9. Close the Certification a. Close the Certification Authority console.

Authority console and log b. Close all open windows and then log off.
off the network.
Exercise 5
Testing Certificate Manager Tasks
In this exercise, you will log on as a user with the Issue and Manage Certificates permission and
attempt various CA and certificate management tasks.
Scenario
After enabling role separation for the issuing CA in your organization, you must determine what
tasks the certificate managers can perform to manage CAs and certificates.
1. Log on as a member of the " Log on to your computer with the following credentials:
CertAdmins group. • User name: CertAdmin1 (on the domain controller) or
CertAdmin2 (on the member server)
domain)
2. Open the Certification " Click Start, click Administrative Tools, and then click Certification
Authority console. Authority.
When you work on the member server in your domain, an error
will appear, information you that Certificate Services is not an
controller.
Authority console to b. In the console tree, right-click Certification Authority, and then click
manage the enterprise CA Retarget Certification Authority.
on the domain controller.
and then click OK.
Important: Perform the next procedure on both computers in your domain
4. View the Security tab of the a. In the console tree, right-click DomainCA, and then click Properties.
DomainCA Properties b. In the DomainCA Properties dialog box, click the Security tab.
dialog box.
(continued)
Can you modify the permissions for the CA?
No, only CA administrators can modify the permissions for the CA.
5. View the CRL Publication a. In the DomainCA Properties dialog box, click Cancel.
properties. b. In the console tree, expand DomainCA, right-click Revoked
Certificates, and then click Properties.
Can you modify the CRL and delta CRL publication intervals?
No, only CA administrators can modify CRL and delta CRL publication intervals.
6. Attempt to publish an a. In the Revoked Certificates Properties dialog box, click Cancel.
update CRL or delta CRL. b. In the console tree, right-click Revoked Certificates, and then point to
All Tasks.
Can you publish the CRL and delta CRL?
No, only CA administrators can publish CRL and delta CRL publication intervals.
7. Attempt to revoke the a. In the console tree, click Issued Certificates.

certificate issued to b. In the details pane, expand Requester Name, right-click the certificate
Domain\Finance1 or specified below, point to All Tasks, and then click Revoke
Domain\Finance2. Certificate.
• Domain controller: Domain\Finance1
• Member server: Domain\Finance2
c. In the Certificate Revocation dialog box, in the Reason code drop-
down list, select Key Compromise, and then click Yes.
Can you revoke this certificate?
No. Certificate manager restrictions are in place, and only Finance1 is assigned the permission to
revoke certificates that are issued to the Finance department.
(continued)
8. Attempt to revoke the a. In the Microsoft Certificate Services dialog box, click OK.
certificate issued to b. In the console tree, click Issued Certificates.
Domain\Accounting1 or
Domain\Accounting2. c. In the details pane, right-click the certificate specified below, point to
All Tasks, and then click Revoke Certificate.
• Domain controller: Domain\Accounting1
• Member server: Domain\Accounting2
d. In the Certificate Revocation dialog box, in the Reason code drop-
down list, select Key Compromise, and then click Yes.
Can you revoke this certificate?
Yes. Certificate manager restrictions allow you to revoke any certificate that is not issued to a member
of the FinanceDept group.
9. Close the Certification a. Close the Certification Authority console.

Authority console and log b. Close all open windows and then log off.
off the network.
Exercise 6
Enabling Certificate Services Auditing
In this exercise, you will continue to implement role separation by defining auditors and auditing
settings for Certificate Services. You will enable Certificate Services auditing so that all CA
administration and certificate management tasks are recorded in the security event log.
Scenario
The written security policy of your organization requires that separate auditors review all CA
administration and certificate management tasks that are recorded in the Windows Server 2003
event logs. You must delegate the auditing user rights to a designated group of users.
1. Log on with your " Ensure that you are logged on with the following credentials:
administrative account for • User name: Student1
your domain.
• Password: Password (where Password is the password assigned to
your administrative account).
domain)
2. View the User Rights a. Click Start, point to Administrative Tools, and then click Domain
Assignment policy in the Controller Security Policy.
Domain Controller Security b. In the console tree, expand Local Policies, and then click User Rights
Policy. Assignment.
c. In the details pane, double-click Manage auditing and security log.
Which security groups are assigned the Manage auditing and security log user right?
The security group Domain\Exchange Enterprise Servers and Administrators is assigned the security
policy setting Manage auditing and security log.
(continued)
3. Assign the Domain\Auditors a. In the Manage auditing and security log Properties dialog box, click
group the Manage auditing Add User or Group.
and security log user right. b. In the Add User or Group dialog box, click Browse.
c. In the Select Users, Computers, or Groups dialog box, in the Enter
the object names to select box, type Audit and then click Check
Names.
d. In the Multiple Names Found dialog box, in the Matching names list,
select Auditors, and then click OK.
e. In the Select Users, Computers, or Groups dialog box, verify that
Auditors appears in the Enter the object names to select box, and
then click OK.
f. In the Add User or Group dialog box, verify that Domain\Auditors
appears in the User or group names box, and then click OK.
g. In the Manage auditing and security log Properties dialog box, click
OK.
4. Enable success and failure a. In the console tree, click Audit policy.
auditing for object access. b. In the details pane, double-click Audit object access.
c. In the Audit object access Properties dialog box, select the Define
these policy settings, Success, and Failure check boxes, and then
click OK.
d. Close the Default Domain Controller Security Settings window.
5. Update Group Policy a. At a command prompt, type gpupdate /force and then press ENTER.
settings and the log off. b. Close the command prompt.
c. Close all open windows and then log off.
6. Log on as a member of the " Log on to the member server with the following account information:
Auditors group for your • User name: Auditor2
domain.
• Domain: Domain
(continued)
Authority console so that it Authority.
manages the enterprise CA b. In the Microsoft Certificate Services message box, click OK.
for your domain.
and then click OK.
8. In the properties of the a. In the console tree, right-click DomainCA, and then click Properties.
DomainCA, enable all b. In the DomainCA Properties dialog box, on the Auditing tab, in the
auditing events. Events to audit list, select all check boxes.
c. In the Microsoft Certificate Services message box, click OK.
d. In the DomainCA Properties dialog box, click OK.
e. Close the Certification Authority console.
f. Close all open windows and then log off.
Lesson: Planning for Disaster Recovery

Introduction You must create a disaster recovery plan to ensure that you can quickly restore
your systems and data to normal operation in the event of a natural disaster or a
technical disaster.
! List the reasons for implementing disaster recovery.
! Determine what to document about CA configuration in case you must
rebuild the CA.
! Back up the CA private and public keys.
! Describe the methods to back up a CA.
! Restore Certificate Services.
! List the guidelines for planning disaster recovery of CAs.
Why Implement Disaster Recovery?

Introduction Use disaster recovery to restore your system if your hard disk fails and you
must replace or reformat it. You can also restore your system if critical system
files have been accidentally erased or corrupted.
Important Only use disaster recovery after you have attempted to repair your
system by using Safe Mode, the Recovery Console, and the Emergency Repair
Process.
Disaster recovery for Disaster recovery includes preparing for system problems and collecting
CAs information about system repair and recovery options. For Certificate Services,
implement disaster recovery plans when:
! Certificate Services fail. Certificate Services may not start when incorrect
versions of the Certificate Services files exist on the CA, or when an
executable or dynamic link-library (DLL) is corrupted on the CA.
! The CA is configured incorrectly. Incorrect configuration of the CA can
cause Certificate Services to fail to start. You can restore the CA to its
previous, approved state by performing disaster recovery.
Disaster recovery In your disaster recovery planning, ensure that you plan for CA restoration. The
planning disaster recovery plan must include the following information:
! Recovering from hardware failure. Based on the security policy of your
organization, determine the solution for recovering from hardware failure.
You can maintain duplicate hardware for a recovery CA or keep duplicate
devices for key components of the CA, such as the CPU or motherboard.
! Recovering from a compromised CA. If a CA is compromised, your disaster
recovery plan must include plans for rebuilding the CA and also what you
will do with the issued certificates. Typically, you revoke the currently
issued certificates and issue new ones.
! Minimizing the risk of a CA failure. Manage the risk of hardware failure by
implementing hardware redundancy. For example, install the CA database
on either a redundant array of independent disks (RAID) 0+1 or RAID 5
volume to prevent CA failure due to a single disk failure.
What to Document for Disaster Recovery

Introduction To perform a complete disaster recovery, you must use a recent backup of your
entire system, including the registry, the system files, and your data files. For
your CA hierarchy, record all CA identification information.
Naming Consider the following guidelines when you complete the CA identification
information during Certificate Services setup:
! CA name. The logical name that is assigned to the CA. The CA name is also
the common name of the CA’s distinguished name in Active Directory.
! Computer name. The network basic input/output system (NetBIOS)
computer name is used to generate the path for the CA certificate location in
Active Directory. When you install Certificate Services, you are warned that
you cannot change the computer name or its domain membership. Changing
the computer name can lead to the failure of Certificate Services.
! Distinguished name suffix. The X.500 distinguished name suffix that is
appended to the CA name. The X.500 distinguished name should match the
LDAP distinguished name of the forest root domain.
Tip You can document the names registered by the CA in Active Directory by
recording the output of the certutil –v –ds command. Consider redirecting the
output of the command to a text file for future reference.
Database paths Certificate Services uses local storage for its database, configuration data,
backup data, and logging data. You can specify locations for the database and
log file during the setup of the CA, or you can change them later manually.
When you document database paths, include the following information:
! Database path. For best performance, the CA database should be stored on
a disk drive separate from the operating system. For best performance, store
the CA database on a hardware RAID 5 or hardware RAID 0+1 volume set.
These volume sets maximize disk throughput and enable you to recover the
CA database in the event of a single disk failure.
! Backup location of the CA database. If you back up the CA database by
using the Certification Authority Backup Wizard, document the path that the
backed up database is saved to. This way, you can recover the CA in the
event of CA failure by using the backed up files.
! Log file location. Store the CA log files on a separate disk drive from the
operating system. For best performance, store the log files on a volume that
implements hardware RAID 1 mirroring.
Miscellaneous In addition to documenting the CA naming and database path information,

document the following additional CA attributes in the event of a CA failure:
! CAPolicy.inf. Keep a copy of CAPolicy.inf when you install the CA. You
can use this file for both documentation and CA renewal purposes.
Typically, CAPolicy.inf varies between CAs in an organization.
Maintaining a copy of each CAPolicy.inf ensures recover all CAs in the CA
hierarchy.
! Key length. The key length represents the length of the keys that the CA
generated for issued certificates. If you rebuild the CA, you must reenter the
key length.
! Registry key backup. Configuration information for Certificate Services is
stored in the registry under HKLM\System\CurrentControlset\Services\
Certsrv\CAName. Including this registry key in your backup ensures that
you can restore all defined registry settings.
! Role separation configuration. The documentation must indicate whether
role separation is enabled on the CA. If role separation is enabled, the
documentation must include the security groups that are assigned the
Common Criteria roles of CA Administrator, Certificate Manager, Backup
Operator, and Auditor.
! CRL and AIA publication points. Include the publication points that are used
for CRL and CA certificate publication for all CA certificates that existed
for the CA during its lifetime.
! Cryptographic service provider (CSP). Be sure to include what CSP is
implemented on the CA and also include any CSP-specific configuration
information.
How to Back Up CA Private and Public Keys

Introduction In addition to performing a System State backup, consider backing up the CA
private key and public key manually to a PKCS #12 file. To back up the key
pair manually, export the CA certificate and include the private key from the
computer store. The PKCS #12 format protects the private key by implementing
strong private key protection.
If the CA’s private key is included in your backup set, you can reinstall
Certificate Services by using an existing key pair, and then install the CA by
using the same name parameters that you used to originally install the CA.
Note The key pair is included in the System State backup, but is not stored as a
separate PKCS #12 file. Backing up the key pair allows you to reinstall the CA
by using the same key pair.
Software CSPs If you use software CSPs, the CA’s private key is stored in the local computer’s
certificate store. You can backup the CA’s key pair and certificate by exporting
the certificate by using the Certificates console, or by using the Certutil
-backupkey command.
Procedure for backing To export the CA certificate and associated private key to a PKCS #12 file:
up private and public
keys when using 1. Ensure that you are logged on as a CA administrator.
software CSPs 2. On the CA, open a command prompt.
3. At the command prompt, type Certutil –backupkey folder (where folder is
the name of folder where the PKCS #12 file will be created).
4. At the Enter new password prompt, type a password for the PKCS #12
file.
5. At the Confirm new password prompt, retype the password for the
PKCS#12 file.
6. Ensure that the CAName.p12 (where CAName is the name of the CA) exists
in folder.
Note When you export the CA certificate and private key by using Certutil
–backupkey, the PKCS #12 file uses the .p12 extension, instead of the .pfx
extension. The content of the file is the same, despite the different extension.
Hardware CSPs If you use a hardware CSP, use the backup software that is included with the
hardware device to back up the CA’s key pair. Because you may back up the
key pair up using a proprietary format, ensure that you can restore the
certificate and private key in the event of hardware failure by taking the
following actions:
! Back up the certificate and private key to multiple backup media. This way,
you protect against failure of the backed up media. Restore the backups to
verify that they are successful.
! Maintain a redundant Hardware Security Module (HSM) device so that you
protect against failure of the HSM hardware. If the hardware fails, you can
attach the backup device to the CA and then import the certificate and
private key.
Methods for Backing Up a CA

Introduction You can back up Certificate Services on a Windows 2003 Server by using two
methods: a System State backup or a manual backup. Plan to back up the CA on
a regular basis, regardless of whether the CA is an offline CA or an issuing CA.
Use full backups to provide the fastest recovery and the most reliable data
redundancy.
System State backup The recommended method for backing up a CA is a System State backup by
using the Windows 2003 Backup utility. Perform this method on the computer
that hosts Certificate Services to back up the CA database, log files, key pair,
the IIS metabase, and all Certificate Services registry settings.
A System State backup not only includes the Certificate Service configuration
and files, it also includes the key components of the operating system. When
you restore a CA by using the System State backup, you restore all aspects of
the computer that hosts Certificate Services.
Manual backup You can also manually back up the CA by using the Certificate Services
Backup Wizard. A manual backup includes the CA database and CA log files.
It can also include the CA’s key pair. It does not include the IIS metabase or
registry settings information. Use a manual CA backup only when System State
backup is not possible.
To back up Certificate Services by performing a manual backup, you must back
up Certificate Services and IIS. When you back up IIS, you back up the IIS
metabase, too. The IIS metabase includes extensions that were created when the
Web Enrollment pages were installed for Certificate Services.
Note When you back up a CA for disaster recovery, it is recommended that

you use a System State backup, rather than a manual CA backup. A System
State backup ensures that all related components of the Windows 2003 Server
installation are included in the backup set.
How to Restore Certificate Services

Introduction To restore a CA, you must restore Certificate Services. The method you use to
restore Certificate Services varies depending on what you are restoring. If you
are replacing the hardware that the CA uses, you must restore Certificate
Services from the System State backup. If you are restoring Certificate Services
only on the CA, you must restore Certificate Services from both the Certificate
Services backup and the IIS metabase backup.
The method also differs depending on whether the CA was backed up by using
a System State backup, or by using the Certification Authority Backup Wizard
and the Internet Information Services Backup Wizard. If you perform backups
by using the System State backup, that is the only available method that you
can use to restore Certificate Services.
Restoring from a System To restore from a System State backup, start the computer that hosts Certificate
State backup Services in Directory Services Restore Mode if the CA is installed on a domain
controller. Using Directory Services Restore Mode is required because the
System State backup includes other system state information such as the Active
Directory database, in addition to the Certificate Services configuration. If the
CA is not installed on a domain controller, you can restore the System State
backup without restarting the CA in a different mode.
Procedure to restore To restore Certificate Services from a System State backup:
Certificate Services from
a System State backup 1. In System Tools, open Backup.
2. In the Backup Utility window, click the Restore and Manage Media tab.
3. In the console tree, expand the latest backup set, and then select System
State.
4. In the Restore files to drop-down list, select Original location, and then
click Start Restore.
5. When the restore is completed, restart the computer.
Note If Certificate Services is installed on a domain controller, you must

restart the computer in Directory Services Restore Mode.
Restoring from a manual You can also restore Certificate Services by using the Certificate Services
backup Backup Wizard to restore a previous manual backup of Certificate Services.
During the restore procedure, you must designate which backup folder contains
the manual backup of the CA database.
Procedure to restore To restore Certificate Services from a manual backup:
from a manual backup
1. Log on as a member of the Backup Operators group.
2. Open a command prompt.
3. At the command prompt, type :
certutil -restore BackupDirectory
(where BackupDirectory is the folder where the manual backup database

exists)
After you restore the CA manually, you must perform the following tasks:
! Restore the Microsoft IIS metabase. This step is only required if the
metabase was lost or corrupted along with the Certificate Services
information. Unless you restore the metabase, you cannot load the
Certificate Services Web pages.
! Restore all registry settings. The manual restoration does not include any
Certificate Services registry settings. It is recommended that you create a
script of all registry settings by using the following command:
Certutil –setreg CA\Registrykey Value
By creating a script of the registry settings, you create documentation of all

registry settings that are defined on the CA, and provide the ability to
restore all registry settings during disaster recovery.
Guidelines for Planning Disaster Recovery of CAs

Introduction You must create a disaster recovery plan to ensure that you can quickly restore
all of your systems and data to normal operation in the event of a disaster. To
protect against the loss of critical data, back up the CA database, the CA
certificate, and the CA keys. Back up the CA on a regular basis, based on the
number of certificates that are issued over the same interval.
When planning disaster recovery of CAs:
! Ensure that you have backed up the CA key pair.
! Back up the CA on a regular basis.
! Plan the backup interval based on the number of certificates that are issued.
! Separate the backup and restore roles to increase security.
! Store all backup media in a secured location.
! Test restored CAs on a regular basis to ensure that all backups are
successful.
Lab B: Backing Up and Restoring a Certification

Authority

! Assign the backup role for Certificate Services.
! Back up a CA by using Certutil.exe.
! Back up a CA by performing a System State backup.
! Restore a CA from a System State backup.

! Deployed a Windows Server 2003 CA hierarchy with an offline root CA
and an enterprise subordinate CA.
! Implemented and enforced role separation at the enterprise CA in your
domain.
! Enabled auditing for Certificate Services.
! Created an MMC named Certificate Management on the desktop with the
Certificates – Current User and Certificates (Local Computer) snap-ins
loaded.
! Knowledge about Windows Server 2003 CA backup and restoration.
Additional information For more information about backing up and restoring a CA, see the white paper,
Windows Server2003 PKI Operations Guide, under Additional Reading on the
Web page on the Student Materials compact disc.
Estimated time to
complete this lab:
60 minutes
Exercise 1
Determining Backup Privileges
In this exercise, you will determine which users are assigned backup and restore user rights and
whether role separation rules are violated in the default user rights assignments.
Scenario
You have attempted to back up the CA database and private key by using your domain
administrator account.
1. Log on to the network by " Log on to the member server with the following account information:
using your domain • User name: Student2
• Password: Password (where Password is the password that is
assigned to your administrative account)
domain)
2. Create an MMC with Group a. Click Start, click Run, type mmc, and then click OK.
Policy Object Editor with b. On the File menu, click Add/Remove Snap-in.
the Default Domain
Controllers Policy loaded. c. In the Add/Remove Snap-in dialog box, click Add.
Standalone Snap-ins list, click Group Policy Object Editor, and then
click Add.
e. In the Select Group Policy Object dialog box, click Browse.
f. In the Browse for a Group Policy Object dialog box, on the All tab,
click Default Domain Controllers Policy, and then click OK.
g. In the Select Group Policy Object dialog box, click Finish.
h. In the Add Standalone Snap-in dialog box, click Close.
i. In the Add/Remove Snap-in dialog box, click OK.
3. View the User Rights a. In the console tree, expand Default Domain Controllers Policy,
Assignment policy for expand Computer Configuration, expand Windows Settings, expand
Domain Controller Security Security Settings, expand Local Policies, and then click User Rights
Policy. Assignment.
b. In the details pane, double-click Back up files and directories.
(continued)
Which security groups are assigned the Back up files and directories user right?
The Administrators, Backup Operators, and Server Operators security groups are assigned the Back
up files and directories user right. Server Operators may appear as the a SID (*S-1-5-32-549)
4. View the properties for the a. In the Back up files and directories Properties dialog box, click OK.
Back up files and directories b. In the details pane, double-click Restore files and directories.
user right in Domain
Controller Security Policy.
Which security groups are assigned the Restore files and directories user right?
The Administrators, Backup Operators, and Server Operators security groups are assigned the
Restore files and directories user right. Server Operators may appear as the a SID (*S-1-5-32-549).
5. View the properties for the a. In the Restore files and directories Properties dialog box, click OK.
Manage auditing and b. In the details pane, double-click Manage auditing and security log.
security log user right in
Domain Controller Security
Policy.
Which security groups are assigned the Manage auditing and security log user right?
The Domain\Exchange Enterprise Servers, Domain\Auditors, and Administrators were assigned the
Manage auditing and security logs user right. Domain\Auditors were assigned the Manage auditing
and security log user right in Lab A of this module.
Which group members are blocked from managing any aspect of the CA when role separation is enforced?
Administrators are blocked. A security principal cannot hold two of the four predefined roles: auditor,
backup operator, CA administrator, or certificate manager.
6. Close all open windows and a. In the Manage auditing and security log Properties dialog box, click
log off the network. OK.
b. Close the MMC without saving changes.
Exercise 2
Backing Up Certificate Services
In this exercise, you will back up the CA’s database and private key by using the certutil
command. You use this command in a custom script to back up the CA private key and CA
database.
Scenario
To protect your organization from the failure of the enterprise CA, you must back up the CA’s
private key and CA database to ensure that the CA can be restored in the event of a CA failure.
1. Log on as a member of the " Log on to the domain controller with the following account
Backup Operators group. information:
• User name: Backup1
domain)
2. Perform a manual backup of a. Open a command prompt.

the CA database and private b. At the command prompt, type certutil –f –backup c:\temp and then
key by using the certutil –f press ENTER.
–backup c:\temp command.
c. At the command prompt, at the Enter new password prompt, type
P@ssw0rd and then press ENTER.
d. At the command prompt, at the Confirm new password prompt, type
P@ssw0rd and then press ENTER.
3. View the contents of the " Open the C:\temp folder.

C:\temp folder.
Which files and folders were created by the certutil –f -backup c:\temp command?
The command created a backup of the CA’s private key (DomainCA.p12) and a backup of the CA
database in the C:\temp\DataBase folder.
(continued)
4. Perform a System State a. Close the C:\temp folder.

backup of the enterprise CA b. Click Start, point to All Programs, point to Accessories, point to
and save the backup file as System Tools, and then click Backup.
C:\Temp\SystemState.bkf.
c. On the Welcome to the Backup or Restore Wizard page, click Next.
d. On the Backup or Restore page, click Back up files and settings,
e. On the What to Back Up page, click Let me choose what to back
up, and then click Next.
f. On the Items to Back up page, in the Items to back up list, expand
My Computer, click the System State check box, and then click
Next.
g. On the Backup Type, Destination, and Name page, click Browse.
h. In the Save As dialog box, in the File name box, type
C:\Temp\SystemState and then click Save.
i. On the Backup Type, Destination, and Name page, click Next.
j. On the Completing the Backup or Restore Wizard page, click
Finish.
The backup will take several minutes because it includes the
Active Directory database, the CA database, and the CA’s key
pair.
k. In the Backup Progress dialog box, click Close.
l. Close all open windows and then log off.
Exercise 3
Removing the CA’s private key from the CA certificate store
In this exercise, you will delete the CA’s private key to simulate the corruption or loss of the CA’s
private key from the CA’s local machine store.
Scenario
Your organization has experienced a corruption on the hard disk. The corruption has caused the loss
of the CA’s private key pair, which is preventing certificate services from starting.
1. Log on as by using your " Log on to the domain controller by using the following account
your domain. • User name: Student1
domain)
2. Remove the private key for a. On the desktop, open the Certificate Management console.
the Subordinate b. In the console tree, expand Certificates (Local Computer), expand
Certification Authority Personal, and then click Certificates.
certificate from the local
machine store, and then c. In the details pane, right-click Subordinate Certification Authority,
delete the certificate. point to All Tasks, and then click Export.
You must scroll to the right and expand the column width to view
the Certificate Template column.
d. On the Welcome to the Certificate Export Wizard page, click Next.
e. On the Export Private Key page, click Yes, export the private key,
f. On the Export File Format page, select the following options:
• Personal Information Exchange – PKCS #12 (.PFX)
• Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above)
• Delete the private key if the export is successful
g. On the Export File Format page, click Next.
h. On the Password page, type P@ssw0rd in the Password and Confirm
password dialog boxes, and then click Next.
i. On the File to Export page, in the Filename box, type
c:\temp\issuingca and then click Next.
(continued)
2. (continued) j. In the Certificate Export Wizard, click Finish.

k. In the Certificate Export Wizard message box, click OK.
l. In the details pane, right-click the Subordinate Certification
Authority certificate, and then click Delete.
m. In the Certificates dialog box, click Yes.
n. Close the Certificate Management console without saving any changes.
3. Log on using your " Log on to the member server by using the following account
your domain. • User name: CAadmin2
domain)
Authority console with the Authority.
console connected to the b. In the Microsoft Certificate Services message box, click OK.
enterprise CA in your
domain. c. In the console tree, right-click Certification Authority, and then click
e. In the Select Certification Authority dialog box, click DomainCA,
and then click OK.
5. Restart Certificate Services a. In the console tree, right-click DomainCA, point to All Tasks, and then
in the Certification click Stop Service.
Authority console. b. In the console tree, right-click DomainCA, point to All Tasks, and then
Does Certificate Services start successfully if the CA’s private key is deleted or corrupted?
No, a message appears, stating that the Keyset does not exist on the CA.
6. Minimize the Certification a. In the Microsoft Certificate Services message box, click OK.
Authority console. b. Minimize the Certification Authority console.
Exercise 4
Restoring the System State Backup
In this exercise, you will restart the domain controller in Active Directory Restore Mode and restore
the System State backup. The restoration will restore the CA’s private key to the machine store of
the domain controller.
Scenario
To recover from the failure of certificate services, you will restore the CA configuration data and
CA database by performing a System State restore.
Important: Perform this procedure at the domain controller for your domain.
1. Ensure you are logged on by " Ensure you are logged on to the domain controller with the following
using your administrative account information:
account for your domain. • User name: Student1
domain)
2. Remove the Windows a. If the Windows Server 2003 compact disc is in the CD-ROM drive,
Server 2003 compact disc remove the compact disc from the CD-ROM drive.
from the CD-ROM drive b. Click Start, and then click Shut Down.
and restart the domain
controller with the shutdown c. In the Shut Down Windows dialog box, in the What do you want the
event tracker reason of computer to do? drop-down list, select Restart.
Security Issue. d. In the Option drop-down list, select Security Issue, and then click
OK.
3. Restart the domain a. When the computer restarts, press F8 to display the Windows
controller in Directory Advanced Options menu.
Services Restore Mode. b. On the Windows Advanced Options menu, select Directory Services
Restore Mode (Windows domain controllers only), and then press
ENTER.
c. In the Please select the operating system to start screen, press
ENTER.
Does the recovery of System State data always require restarting the enterprise CA in Directory Services
Restore Mode?
No, you must only restart the enterprise CA in Directory Services Restore Mode when the enterprise
CA is installed on a domain controller.
(continued)
4. Log on to the domain a. Log on to the domain controller by using the following account
controller as Administrator information:
with a password of • User name: Administrator
P@ssw0rd.
b. In the Desktop message box, click OK.
5. Restore the System State a. Open the C:\temp folder.

backup stored in the b. In the C:\temp folder, double-click Systemstate.bkf.
C:\temp\Systemstate.bkf
file. c. On the Welcome to the Backup or Restore Wizard page, click Next.
d. On the Backup or Restore page, click Restore files and settings, and
then click Next.
e. On the What to Restore page, in the Items to restore list, expand
File, expand Systemstate.bkf, click the System State check box, and
then click Next.
f. On the Completing the Backup or Restore Wizard page, click
Finish.
g. In the Warning dialog box, click OK.
h. In the Check Backup File Location dialog box, click OK.
The restore will take several minutes because it includes all
objects that are included in the System State backup.
i. In the Restore Progress dialog box, click Close.
j. In the Backup Utility dialog box, click Yes to restart the computer.
6. Ensure you are logged on by " Ensure you are logged on to the member server by using the following
using your administrative account information:
account for your domain. • User name: CAadmin2
• Domain: Domain
(continued)
7. After the domain controller a. Wait until the domain controller restarts.
restarts, ensure that you can b. Open the Certification Authority console.
start Certificate Services
successfully on the c. In the console tree, right-click DomainCA, and then click Refresh.
enterprise CA.
Did the CA start after the System State backup was restored?
Yes. The restore of the System State backup restores the CA’s private key to the CA local machine
store.
8. Close all open windows and a. Close the Certification Authority console.
log off the network. b. Close all open windows and log off the network.
Module 5: Configuring
Certificate Templates
Contents
Overview 1
Lesson: Introduction to Certificate
Templates 2
Lab A: Delegating Certificate Template
Management 8
Lesson: Designing and Creating
Certificate Templates 13
Lab B: Designing a Certificate Template 25
Lesson: Publishing a Certificate Template 31
Lesson: Managing Changes in a Certificate
Template 35
Lab C: Configuring Certificate Templates 40
respective owners.
Module 5: Configuring Certificate Templates iii
Instructor Notes
Presentation: Certificate templates are rules or profiles that define the content of certificates
60 minutes that Microsoft enterprise certification authorities issue. These rules can be either
simple or complex and may apply to all users or specific groups of users. This
Labs: module introduces students to certificate templates and how to design certificate
75 minutes templates. They will also learn about creating, publishing, and changing
certificate templates.
! Describe the function of certificate templates in a Microsoft®
Windows Server™ 2003 public key infrastructure (PKI).
! Design and create a certificate template.
! Publish a certificate template.
! Replace an existing certificate template with an updated certificate template.
Required materials To teach this module, you need Microsoft PowerPoint® file 2821A_05.ppt.


! Complete the practices and lab.
! Read the white paper Implementing and Administering Certificate
Templates in Windows Server 2003 under Additional Reading on the Web
page on the Student Materials compact disc.
iv Module 5: Configuring Certificate Templates

Lesson: Introduction to Certificate Templates

In this lesson, students will learn about certificate templates, versions of
certificate templates, default certificate templates, and how to delegate
certificate template management.
lesson.
What Are Certificate Give a brief introduction of certificate templates and their purpose. Emphasize
Templates? that only an enterprise certificate authority (CA) can issue certificate templates
and the templates are stored as objects in the Configuration naming context.
Consider using ADSIEdit.msc to show the actual storage location of the
certificate templates within the Configuration naming context.
Version 1 and Version 2 Explain the differences between version 1 and version 2 certificate templates.
Certificate Templates Consider opening the Certificate Templates console (Certtmpl.msc) to show the
default certificate templates. Explain that version 2 certificate templates can
only be issued by enterprise CAs running on Windows Server 2003, Enterprise
Edition or Datacenter Edition.
Categories of Default Explain that certificate templates can be categorized based on who they are
Certificate Templates issued to or how they are used. For definitions of all user and computer
certificate templates available in Windows Server 2003, refer the students to the
white paper, Implementing and Administering Certificate Templates in
Delegation of Certificate Explain which groups have the permissions to create and modify certificate
Template Management templates by default. If an organization wants to delegate the administration of
certificate templates to other security groups, they must delegate permissions as
shown in this section.
Emphasize that delegation on the Certificate Templates container only affects
future certificate templates. Administrators must execute the
DelegateTemplates.cmd batch file to modify the permissions of the default
Consider reviewing the DelegateTemplates.cmd batch file (located in
C:\Moc\2821\Labfiles\Module5) to describe what permissions are assigned to
each certificate template.
Lab A In this lab, students will learn to delegate the permissions to create new
certificate templates and to modify existing certificate templates.
The most common errors are mistakes in replacing the DomainName and
ForestName variables. If the student has made an error, the execution of the
batch file will complete in too short of a time frame.
Have the students verify the permissions of an existing certificate template to
ensure that the CertTmplAdmins group is assigned Read and Write
permissions.
Module 5: Configuring Certificate Templates v
Lesson: Designing and Creating a Certificate Template

This lesson describes the process of creating a certificate template and the
information that is required to create a certificate template. The students will
also learn about key archival, recovery process, and enrollment methods.
lesson.
Guidelines for Spend time describing how the validity period and renewal period settings work
Determining Validity and in a certificate template. Describe how the ValidityPeriodUnits and
Renewal Periods ValidityPeriod registry keys at the issuing CA will affect the validity period.
Consider providing examples where the registry keys are less than the value
defined in a certificate template.
Criteria for Selecting a Focus on which criteria are met by the four certificate purposes. If you have the
Certificate Purpose Certificate Templates console open, consider showing how the options on the
Request Handling tab are enabled and unavailable based on the purpose that is
selected.
Guidelines for Choosing Do not spend a lot of time at this point on autoenrollment. Instead, emphasize
an Enrollment Method the settings that must be enabled in the certificate template to enable
autoenrollment. Focus on the Request Handling tab and the Permissions tab
settings.
Subject Name Use the screen shot on the slide to explain the content on the page. Emphasize
Requirements that if you use Active Directory® directory service to populate the subject of the
certificate, all name formats required must be defined for the user account. Tell
the class that the most common attribute not filled in is the E-mail name
attribute.
Discuss cases in which the user must provide the subject name in the certificate
request. Examples include when a user account or computer account do not
exist in Active Directory for the subject.
Considerations for Show the cryptographic service providers (CSPs) dialog box when discussing
Choosing a CSP this page. The CSPs dialog box is accessible from the Request Handling tab of
a certificate template.
Other Policies to Be sure that students understand the difference between application policies and
Configure in a certificate policies. This topic is very important and is a foundation for qualified
Certificate Template subordination, which is discussed in Module 8, “Configuring Trust Between
Organizations,” in Course 2821, Designing and Managing a Windows Public
Key Infrastructure.
Raise Issuance Security One of the fundamental reasons for deploying a PKI is to increase the proof of
identity for users of the network. Ensure that students understand how the
measures described on this page increase the issuance security, and strengthen
the connection between the subject of the certificate and the certificate itself.
Lab B Do not allow the lab to go beyond the allocated 30 minutes. Review the
answers with the classroom, and discuss how each tab is configured. Remind
students that all PKI application deployment projects start with the certificate
template design.
vi Module 5: Configuring Certificate Templates
Lesson: Publishing a Certificate Template

In this lesson, the students will learn how to define permissions for a certificate
template, and then publish the certificate template so that it is available for
enrollment.
lesson.
Certificate Template Do not go beyond describing the available certificate template permissions.
Permissions Emphasize that the Autoenroll permission is only available for version 2
Guidelines for Defining Review each of the guidelines for certificate template permissions. Mention that
Certificate Template the Authenticated Users group is assigned Read permissions by default, so you
Permissions do not have to assign the Read permission, but manual assignment does ensure
that the necessary permissions are assigned.
Ask the students why the guidelines include assigning the permissions to global
or universal groups. You cannot use domain local groups because the
permission assignments would not be recognized outside of the forest root
domain in a multidomain forest or multiforest environment.
Guidelines for Best practices require that a certificate template be published at two or more
Publishing a Certificate CAs in the CA hierarchy. Discuss how sites also play a part in deciding where
Template to publish the CA. Use the example shown in the slide to aid the discussion.
Lesson: Managing Changes in a Certificate Template

In this lesson students will learn methods to modify an existing certificate
template. The students will learn how to decide between simple modification of
the certificate template and superseding a certificate template.
lesson.
Methods of Updating a Compare and contrast the two methods presented. Give examples of when you
Certificate Template would choose each method. For example, if you need to add an issuance policy
to a certificate template for usage with another organization, you must
supersede the template so that all existing certificates are replaced.
Guidelines for Modifying To add to this topic, ask student to provide other examples where modification
a Certificate Template of a template would be the best design decision.
Guidelines for To add to this topic, show how Microsoft has designed the Domain Controller
Superseding a Authentication certificate template to supersede the Domain Controller
Certificate Template certificate template. The reason that this was done is the addition of the Smart
Card Logon application policy and switching to autoenrollment settings for
deploying the certificate template.
How to Supersede a Consider showing the procedure in the Certificate Templates console in MMC.
Certificate Template
Lab C If a student is not paired with another student for the lab, the user will not have
a PartnerComputerUser certificate template available when performing
Exercise 4 – Superceding a Certificate Template. The lab will proceed without
problems if the user only supersedes the ComputerUser certificate template.
Module 5: Configuring Certificate Templates vii
Lab A: Delegating Certificate Template Management

In this lab, students will delegate the ability to create and modify certificate
templates to a custom global group named CertTmplAdmins.
In this lab, students:
! Delegate the permissions to create new certificate templates.
! Delegate the permissions to modify existing certificate templates.
The students will only encounter problems with this lab if they do not correctly
modify the DelegateTemplates.cmd command file.
Lab B: Designing a Certificate Template

In this lab, students design a custom version 2 certificate template for code
signing. The configuration of the certificate template is based on design
requirements identified in the lab.
In this lab, students design a custom certificate template for code signing.
Lab C: Configuring Certificate Templates

In this lab, each student creates his own custom version 2 certificate template.
The certificate templates are published at the enterprise subordinate CA, and
then a single updated certificate template supersedes them.
! Create a version 2 certificate template.
! Modify the attributes of a version 2 certificate template.
! Publish a version 2 certificate template.
! Supercede a version 2 certificate template.
Lab Setup
Setup requirement 1 The labs in this module require that a CA hierarchy with an offline root CA and
an enterprise subordinate CA exist.
! Complete Lab A, Lab B, and Lab C in Module 3, “Creating a Certification
Authority Hierarchy,” in Course 2821, Designing and Managing a Windows
Setup requirement 2 All of the procedures in the lab assume that Common Criteria role separation is
enforced.
! Complete Lab A in Module 4, “Managing a Public Key Infrastructure,” in
Course 2821, Designing and Managing a Windows Public Key
Infrastructure.
viii Module 5: Configuring Certificate Templates
Setup requirement 3 The ability to create and modify certificate templates is delegated to the
CertTmplAdmins global group. This is a requirement for Lab C.
! Complete Lab A in this module.
Lab Results
changes:
! Full control permissions are delegated for the OID container to the
CertTmplAdmins global group.
! Full control permissions are delegated for the Certificate Templates
container to the CertTmplAdmins global group.
! The DelegateTemplates.cmd file is modified to reflect the domain and forest
name of the students’ computers.
! Full control permissions are delegated for each existing certificate template
to the CertTmplAdmins global group.

! Students will create a certificate template design for a custom code signing
certificate.
! The custom version 2 certificate template will meet the design requirements
provided in the lab.
Lab C At the completion of Lab C:

! Each partner has created a ComputerUser certificate template.
! The ComputerUser certificate templates are published at the enterprise
subordinate CA.
! The Student1 and Student2 accounts have used Web enrollment to enroll
certificates based on the ComputerUser certificate templates.
! The SupersededUser certificate template supersedes the two ComputerUser
Module 5: Configuring Certificate Templates 1
Overview

Introduction Certificate templates define the format of certificates that Microsoft enterprise
certificate authorities (CAs) issue. Each template is customized for its intended
usage. The type of certificate templates that you use in your organization
depends on the public key-enabled applications that are deployed in your
organization and the security requirements of your organization. You can issue
multiple types of certificates to meet a variety of security or application
requirements.
When a CA receives a request for a certificate, groups of rules and settings are
applied to that request to perform the requested function, such as certificate
issuance or renewal. These rules can be simple or complex and may apply to all
users or specific groups of users.
! Describe the function of certificate templates in a Microsoft®
! Design and create a certificate template.
! Publish a certificate template.
! Replace an existing certificate template with an updated certificate template.
2 Module 5: Configuring Certificate Templates
Lesson: Introduction to Certificate Templates

Introduction When the CA creates a certificate, the CA uses a certificate template to define
the attributes of the certificate. For example, the attributes can be the authorized
uses of the certificate, the cryptographic algorithms used with the certificate, the
format of the subject, the public key length, issuance requirements, and the
certificate life time.
! Identify the function of a certificate template.
! Identify the differences between version 1 and version 2 certificate
templates.
! Identify commonly used certificate templates.
! Delegate permissions for template management.
What Are Certificate Templates?

Introduction Certificate templates are the sets of rules and settings that define the format and
content of a certificate based on its intended usage. Certificate templates are
configured on a CA and are applied against the incoming certificate requests.
Certificate templates also give instructions to the client about how to create and
submit a valid certificate request.
Certificate template Only enterprise CAs can issue certificates based on certificate templates. When
environment a certificate template is defined, the definition of the certificate template must
be available to all CAs in the forest. To ensure distribution of the certificate
template’s definition, the certificate template information is stored in the Active
Directory® directory service, in the CN=Certificate Templates,CN=Public Key
Services,CN=Services,CN=Configuration, DC=ForestRootNameDN container
(where ForestRootNameDN is the Lightweight Directory Access Protocol
(LDAP) distinguished name of the forest root domain). The replication of the
certificate templates depends upon the Active Directory replication schedule,
and the certificate template may not be available at all CAs until replication is
completed.
Associated with the certificate template is a discretionary access control list
(DACL) that defines which security principals have permissions to read, enroll,
or modify the certificate template.
Version 1 and Version 2 Certificate Templates

Introduction Windows Server 2003 family servers support two types of certificate templates:
version 1 and version 2. Windows 2000 family servers only support the
issuance of certificates that are based on version 1 certificate templates.
Certificate template When the first enterprise CA is installed in the forest, version 1 templates are
versions created by default. Unlike version 2 templates, these cannot be modified or
removed, but they can be duplicated. When you duplicate a version 1 template,
it creates a version 2 template. Version 1 templates are provided for backward
compatibility and support many general needs for subject certification. For
example, there are certificates that allow Encrypting File System (EFS)
encryption, client authentication, smart card logon, or server authentication.
Note Windows Server 2003, Standard Edition only issues certificates that are
based on version 1 templates.
You use version 2 templates to customize settings in the template. The default
configuration supplies several preconfigured version 2 templates and the ability
to create more.
Version 2 template definitions are stored in Active Directory, although you can
create and modify version 2 templates at any Windows Server 2003 family
computer or Microsoft Windows® XP Professional computer with the
Windows Server 2003 Administration pack installed. Certificates based on
version 2 templates can only be issued by a CA running Windows Server 2003,
Enterprise Edition or Windows Server 2003, Datacenter Edition.
Who can issue version 1 Windows 2000 Server family servers and Windows Server 2003 family servers
and version 2 can issue version 1 templates. Windows Server 2003, Enterprise Edition and
templates? Windows Server 2003, Datacenter Edition issue version 2 templates.
Categories of Default Certificate Templates

Introduction When you install Windows Server 2003 family CAs, a number of preconfigured
certificate templates are created by default. These templates are designed to
meet the needs of most organizations.
Categories of templates You can divide the certificate templates into two categories: certificate
templates issued to users and certificate templates issued to computers. Only
computers can use certificates that are issued to computers; and likewise, only
users can use certificates that are issued to users. Another way to distinguish
between certificate templates is based on how they are used:
! Single function: A certificate template can be highly restricted and only be
used for a single function. For example, you can use a Basic EFS certificate
template only to encrypt and decrypt files that are protected by using EFS.
! Multiple functions: You can use a certificate template for multiple
functions. For example, you can use a user certificate template to encrypt
and decrypt files, authenticate with a server, and send and receive secure e-
mail by using the same certificate.
Single function The following table describes the single-function certificate templates for users
templates for users in Windows Server 2003.
Template Function
Basic EFS Encrypts and decrypts data by using EFS. The private key
is used to decrypt the file encryption key (FEK) which is
used to encrypt and decrypt the EFS protected data.
Authenticated Session Authenticates a user with a Web server. The private key is
used to sign the authentication request.
Smart Card Logon Authenticates a user with the network by using a smart
card.
Multiple function The following table describes the multiple function certificate templates for
templates for users users in Windows Server 2003.
Template Function
Administrator User authentication, EFS encryption, secure e-mail, and

certificate trust list signing.
User User authentication, EFS encryption, and secure e-mail.
Smart Card User Authenticates with the network by using a smart card and
uses the smart card for secure e-mail.
Single function The following table describes the single function templates for computers in
templates for computers Windows Server 2003.
Template Function
Web Server Authenticates the Web server to connecting clients. The

connecting clients use the public key to encrypt the data
that is sent to the Web server when using Secure Socket
Layers (SSL) encryption.
IPSec Provides certificate-based authentication for computers by
using Internet Protocol security (IPSec) for network
communications.
Multiple function The following table describes multiple function certificate templates for
templates for computers computers in Windows Server 2003.
Template Function
Computer Provides both client and server authentication abilities to a

computer account. The default permissions for this
template only allow enrollment by Windows 2000 and
Windows Server 2003 family servers that are not domain
controllers.
Domain Controller Provides both client and server authentication abilities to a
computer account. Default permissions only allow
enrollment by domain controllers.
Note For definitions of all the user and computer certificate templates that are
available in Windows Server 2003, see the white paper, Implementing and
Administering Certificate Templates in Windows Server 2003 under Additional
Delegation of Certificate Template Management

Introduction By default, only members of the Domain Admins group in the forest root
domain and the Enterprise Admins group are assigned the necessary
permissions to create and modify certificate templates. If your organization’s
security policy requires that role separation be implemented for certificate
template management, or you need to delegate the ability to create and manage
certificate templates, you can modify the default permissions.
Delegating template If you delegate certificate template management, including the ability to
management duplicate and create new certificate templates, assign the following permissions
to global or universal groups:
! Full Control permissions to the CN=Certificate Templates,
CN=Public Key Services,CN=Services,CN=Configuration,
DC=ForestRootDN container.
! Full control permissions to the CN=OID,CN=Public Key Services,
CN=Services,CN=Configuration,DC=ForestRootDN container.
! Full Control permissions to each existing certificate template object in the
CN=Certificate Templates,CN=Public Key Services,CN=Services,
CN=Configuration,DC=ForestRootDN container.
Note Individual certificate templates do not inherit the permissions that are
assigned to the Certificate Templates container.
Tools for delegation Use the following tools to delegate the ability to create and manage certificate
templates:
! The Active Directory Sites and Services console. Allows you to delegate
permissions to the CN=Certificate Templates and CN=OID containers
within the Configuration naming context.
! The Dsacls.exe command-line tool from the Windows Server 2003 Support
Tools. Allows you to delegate permissions to the individual certificate
templates.
Lab A: Delegating Certificate Template Management

! Delegate the permissions to create new certificate templates.
! Delegate the permissions to modify existing certificate templates.

! Implemented and enforced role separation at the enterprise CA in your
domain.
! Knowledge of how to delegate the ability to create and modify certificate
templates.
! Completed the following table to assist in the completion of the lab.
Computer Forest name Domain
Denver DC=adatum,DC=msft Adatum

Brisbane DC=fabrikam,DC=msft Fabrikam
Bonn DC=lucernepublish,DC=msft Lucernepublish
Santiago DC=litwareinc,DC=msft Litwareinc
Singapore DC=tailspintoys,DC=msft Tailspintoys
Tunis DC=wingtiptoys,DC=msft Wingtiptoys
Miami DC=thephonecompany,DC=msft Thephonecompany
Suva DC=cpandl,DC=msft Cpandl
Moscow DC=adventureworks,DC=msft Adventureworks
Montevideo DC=blueyonderair,DC=msft Blueyonderair
Tokyo DC=woodgrovebank,DC=msft Woodgrovebank
Nairobi DC=treyresearch,DC=msft Treyresearch
Additional information For more information about delegating the management of certificate templates,
read the white paper, Implementing and Administering Certificate Templates in
Estimated time to
complete this lab:
15 minutes
Exercise 1
Delegating Certificate Template Administration Permissions
In this exercise, you will delegate the permission to create and modify certificate templates to a
custom global group named CertTmplAdmins.
Scenario
Your organization wants to extend the PKI role separation model to assign the ability to create and
manage certificate templates to a designated group in the organization. You must delegate the
required permissions to this designated group, named CertTmplAdmins.
1. Log on by using your " Ensure that you are logged on with the following credentials:
domain administrative • User name: Student1
account.
• Password: Password (where Password is the password defined for
domain)
2. Open the Active Directory a. On the Start menu, click Administrative Tools, and then click Active
Sites and Services console Directory Sites and Services.
and browse to the OID b. On the View menu, click Show Services node.
container.
c. In the console tree, expand Services, expand Public Key Services, and
then click OID.
3. Modify the permissions of a. In the console tree, right-click OID, and then click Properties.
the OID container to grant b. In the OID Properties dialog box, on the Security tab, click Add.
the CertTmplAdmins global
group Full Control c. In the Select Users, Computers, or Groups dialog box, in the Enter
permissions. the object names to select box, type Cert and then click Check
Names.
d. In the Multiple Names Found dialog box, in the Matching names list,
select CertTmplAdmins, and then click OK.
e. In the Select Users, Computers, or Groups dialog box, in the Enter
the object names to select box, ensure that CertTmplAdmins
appears, and then click OK.
f. In the OID Properties dialog box, in the Group or user names list,
select CertTmplAdmins.
g. In the OID Properties dialog box, in the Permissions for
CertTmplAdmins list, select the Allow check box for Full Control,
and then click OK.
(continued)
4. Delegate administrative a. In the console tree, right-click Certificate Templates, and then click
permissions to the Delegate Control.
CertTmplAdmins global b. In the Delegation of Control Wizard, click Next.
group for the Certificate
Templates container. c. On the Users or Groups page, click Add.
d. In the Select Users, Computers, or Groups dialog box, in the Enter
the object names to select box, type Cert and then click Check
Names.
select CertTmplAdmins, and then click OK.
f. In the Select Users, Computers, or Groups dialog box, in the Enter
the object names to select box, ensure that CertTmplAdmins
g. On the Users or Groups page, click Next.
h. On the Tasks to Delegate page, click Create a custom task to
delegate, and then click Next.
i. On the Active Directory Object Type page, click This folder,
existing objects in this folder, and creation of new objects in this
folder, and then click Next.
j. On the Permissions page, in the Permissions list, enable Full Control,
k. On the Completing the Delegation of Control Wizard page, click
Finish.
l. Close Active Directory Sites and Services.
5. Log on as a member of the " Log on with the following credentials:

Enterprise Admins group. • User name: Student2
domain)
(continued)
6. In the C:\moc\2821\labfiles\ a. Open the C:\moc\2821\labfiles\module5 folder.

module5 folder, modify b. Right-click delegatetemplates.cmd, and then click Properties.
delegatetemplates.cmd to
reflect your forest name and c. In the delegatetemplates.cmd Properties dialog box, ensure that the
domain name. Read-only attribute check box is cleared, and then click OK.
d. In the C:\moc\2821\labfiles\module5 folder, right-click
delegatetemplates.cmd, and then click Edit.
e. On the Edit menu, click Replace.
f. In the Replace dialog box, enter the following information:
• Find what: ForestName
• Replace with: ForestName (where ForestName is the LDAP
distinguished name of your forest root domain shown in the table at
the beginning of the lab)
g. In the Replace dialog box, click Replace All, and then enter the
following information:
• Find what: DomainName
• Replace with: Domain (where Domain is the NetBIOS name of
your domain)
h. In the Replace dialog box, click Replace All, and then click Cancel.
i. Save any changes, and then close delegatetemplates.cmd - Notepad.
7. Run the a. In the C:\moc\2821\labfiles\module5 window, double-click

delegatetemplates.cmd delegatetemplates.cmd.
command file and then log The output of the command file will show the addition of each
off the network. Access Control Entry (ACE) to the default certificate templates.
b. Close the C:\moc\2821\labfiles\module5 window.
c. Close all open Windows, and then log off.
Lesson: Designing and Creating Certificate Templates

Introduction Before you create a certificate template, collect all the information that is
required to configure the template. For example, find out the intended use of the
certificate, the users or groups who will use the certificate, the validity period
and key length of the certificate and document the configuration in the
organization’s Certificate Practice Statement (CPS).
! List the guidelines for determining optimal validity and renewal periods for
a certificate template.
! Define the certificate purpose to meet the needs of a certificate template.
! Determine which enrollment option to use.
! Define the Subject Name requirements.
! Describe the considerations for selecting a cryptographic service provider
(CSP).
! Define other policies that you configure in a certificate template.
! Explain how to raise issuance security in a certificate template.
Note For more information about certificate template design, see the white
paper Implementing and Administering Certificate Templates in
Guidelines for Determining Validity and Renewal Periods

Introduction Every certificate has a predefined validity period. The validity period defines
the time frame in which the certificate can be used. Before the validity period
concludes, you can renew the certificate to extend the validity period.
In addition to the validity period value that is configured in a certificate
template, each CA may further constrain the validity period by defining the
maximum lifetime for all of the certificates that the CA issues. You can define
the maximum lifetime of a certificate by using the following Certutil
commands:
certutil -setreg ca\ValidityPeriodUnits 10
certutil -setreg ca\ValidityPeriod "Years"
The renewal period is the amount of time prior to the end of the validity period
when the subject can renew the certificate by using autoenrollment. Renewing
the certificate during this interval ensures that last-minute requests for
certificate renewal can be serviced before certificate expiration, allowing
uninterrupted use of the certificate.
Guidelines When defining the validity period and renewal period for a certificate template,
use the following guidelines:
! Do not make the validity period of a certificate template longer than the
remaining validity period of the issuing CA. For example, if a CA only has
two years remaining in its validity period, it cannot issue certificates with a
validity period of more than two years.
! Ensure that the validity period for a certificate template reflects the security
policy of the organization. For example, longer validity periods may only be
implemented for certificates that you issue to employees as compared to the
certificates that you issue to contractors.
! Do not set long validity periods that allow for an attacker to derive the
private key from the public key that is included in a certificate’s attributes.
Consider restricting user and computer certificates to validity periods of less
than two years.
! Define the ValidityPeriodUnits and ValidityPeriod registry entries to allow
the maximum validity period that is required for certificates that the CA
issues. You cannot issue certificates with a longer validity period than those
defined for a CA’s ValidityPeriodUnits and ValidityPeriod registry entries.
! Ensure that the renewal period allows sufficient time for renewal. The
renewal period defines the time interval before the expiration of the
certificate when an attempt to autorenew the certificate takes place.
Defining a renewal period that is too short will not allow autoenrollment to
take place. For example, the Cryptographic application programming
interface (CryptoAPI), starts automatic certificate renewal attempts when
80% of the certificate validity period has expired.
Criteria for Selecting a Certificate Purpose

Introduction When you determine the certificate purpose for a certificate template, ensure
that you select a purpose that meets the usage criteria of the certificate template.
Criteria for selecting The following table briefly describes the certificate purposes.
certificate purpose
Certificate purpose Intended use
Signature Data signing, authentication, nonrepudiation

Encryption Data encryption and decryption
Signature and encryption Data encryption and decryption, digital data signing,
authentication
Signature and smart card logon Smart card logon, digital data signing
Note The certificate purpose setting determines whether you can enable key
archival for a certificate template. Key archival is only possible if the certificate
purpose is set to Encryption or Signature and encryption.
Guidelines for selecting When you define certificate purpose in a certificate template, use the following
the certificate purpose guidelines:
! Use the Signature or Signature and smart card logon purposes for
authentication-only certificates. These purposes prevent the certificate from
being used for encryption purposes.
! Use only the Signature and encryption purpose for non-vital certificates. It
is more secure to issue separate certificates for signature or encryption
purposes.
! Implement the Signature and smart card logon purpose for all smart card
certificates.
Guidelines for Choosing an Enrollment Method

Introduction Certificate enrollment is the process by which a user obtains a certificate.
Within a certificate template, you can define what method of enrollment is
available for the certificate template. The following table describes the methods
of enrollment.
Enrollment method Description
Manual enrollment Supports all Windows operating systems.

Requires a user or computer to connect to a
Windows Server 2003 CA and manually request a certificate.
Autoenrollment Supports only Windows XP and Windows Server 2003 family
Settings servers for user and computer certificates.
Supports only version 2 certificate templates.
Allows the subjects to automatically enroll for certificates,
retrieve issued certificates, and renew expiring certificates.
Automatic Certificate Supports Windows 2000, Windows XP, and
Request Settings Windows Server 2003 family operating systems.
Supports only version 1 certificate templates for computers.
Guidelines Use the following guidelines when choosing an enrollment method:

! Implement manual enrollment for client computers running
pre-Windows 2000 operating systems. These computers do not support any
autoenrollment methods.
! Configure autoenrollment for only computer certificates for Windows 2000-
based computers. For computers running Windows 2000, autoenrollment is
only available for version 1 computer certificates by using the Automatic
Certificate Requests Settings policy in Group Policy. There is no
mechanism for autoenrollment of user certificates.
! Configure user and computer autoenrollment for Windows XP and
Windows Server 2003 family computers. Autoenrollment is available for
both user and computer certificates if Windows XP or
Windows Server 2003 family clients exist on the network and
Autoenrollment Settings is enabled in Group Policy.
! Do not enable autoenrollment for high value or sensitive certificates.
Manual enrollment is recommended for high value certificates, such as Key
Recovery Agent certificates, that require certificate manager approval for
issuance.
Subject Name Requirements

Introduction The subject name of a certificate identifies the user, computer, or service that
the certificate represents. Windows Server 2003 CAs can either build the
subject name automatically or request it from the subject manually. Windows
obtains the information from Active Directory for automatic building. To
provide the name manually, the subject supplies that information in the
certificate request, for example by using the Web-based enrollment pages.
Configuring the subject Define the format of the subject name when you define a certificate template.
name You can include various options with the subject name and also use specific
configuration settings for the same. The various subject name formats are:
! None. Does not enforce any name format for this field.
! Common name. The CA creates the subject name from the common name
(CN) obtained from Active Directory. The common name should be unique
within a domain, but may not be unique within an enterprise.
! Fully distinguished name. The certification authority creates the subject
name from the fully distinguished name obtained from Active Directory.
Using the fully distinguished name guarantees that the name is unique
within an enterprise.
! E-mail name. If the e-mail name field is populated in the Active Directory
user object, then the e-mail name will be included with either the common
name or fully distinguished name as part of the subject name.
Alternate subject name In addition to the subject name, you can include additional names that reference
options the subject in the subject alternative name. The alternate subject name option
allows storing different name formats of the subject name. For certificates that
are issued to users, the following alternate subject name formats are available:
! E-mail name. The e-mail name field that is populated in the Active
Directory user object.
! User principal name (UPN). The UPN is part of the Active Directory user
object.
For certificates that are issued to computers, the following alternate subject
name formats are available:
! Domain Name System (DNS) name. The fully qualified domain name
(FQDN) of the subject that requested the certificate.
! Service principal name (SPN). The service principal name is part of the
Active Directory computer object.
Requesting certificates Usually, a subject cannot request a certificate that uses a nonmatching subject
for a non-matching name. For example, user1@nwtraders.msft would not be allowed to request a
certificate name certificate with a subject name of user2@nwtraders.msft.
The only subject that can request a certificate for another user is one who holds
a certificate based on the Enrollment Agent template. That subject can request
certificates on behalf of any other subject. For example, an enrollment agent
can request Smart Card User or Smart Card Logon certificates on behalf of
other users.
Guidelines for defining Use the following guidelines when defining subject name requirements in a
subject name certificate template:
requirements
! On the Subject Name tab of a certificate template, select the Supply in the
request option for certificates that are issued to users or computers that do
not have accounts in Active Directory. This option allows the user to
provide the subject name during the certificate request.
Note The Supply in the request option allows you to apply a custom
subject name in a certificate request. For example, a code signing certificate
may require the company name in the subject of the certificate, rather than
the individual user’s name.
! On the Subject Name tab of a certificate template, select the Build from
this Active Directory information option for users or computers that have
accounts in Active Directory. This option ensures that the same information
that is stored for a user or computer account in Active Directory is also
populated into a certificate that is issued to the user or computer.
! Ensure that a user or computer account in Active Directory has all the
required alternate subject name formats that are defined in the object’s
properties. For example, a request for a certificate that populates the
alternate subject name with a user’s e-mail name will fail if the user account
does not have an e-mail name configured.
Considerations for Choosing a CSP

Introduction Cryptographic service providers (CSPs) are software components that are
required to generate a public key and a private key, often referred to as a key
pair, and perform all cryptographic functions for the CA and clients of the CA.
Security vendors can write CSPs to provide a variety of encryption and
signature algorithms. Selecting specific CSPs allows the administrator to
control what algorithms and key lengths are used with the certificate.
Considerations for For each certificate template, you can designate one or more CSPs that are
choosing CSPs enabled for key pair generation. Each of these CSPs can support different
cryptographic algorithms and, therefore, different key lengths. The selected
CSPs must meet the security requirements for certificates based on that
certificate template. When choosing a CSP, consider the following:
! Choosing multiple CSPs can add unnecessary complexity to certificate
enrollment. For example, if you choose multiple CSPs for smart card
autoenrollment, and the CSP is smart card-based, the user will be prompted
to insert a smart card for each indicated CSP, even if the user has a single
smart card.
! Third-party CSPs must be manually loaded at each client that enrolls a
certificate that implements the CSP, and at the workstation where the
configuration of the certificate template is performed. Windows Server 2003
Server ships with several default CSPs. If your organization requires
additional CSPs, such as the CSP for a Hardware Security Module (HSM),
the CSPs must be loaded manually at each CA that will use the HSM
devices.
! The CSP must provide required key length and storage options. A certificate
that is used to sign high-value transactions, such as banking transactions,
should use a longer key length. The selected CSP must support the required
key length. Additionally, the CSP must store the associated private key in a
secured location. For example, for the banking transactions, it may be
preferable to protect the private key by storing the private key on a smart
card or other hardware token. The selected CSP must support storage of the
private key on a smart card in this case.
Other Policies to Configure in a Certificate Template

Introduction A CA can define policies, such as application and issuance policies, also known
as certificate policies, that must be followed for certificate usage.
Application policies Application policies are settings that indicate the applicability of a certificate to
a set of applications and define the function of the certificate. These are
represented in a certificate by an object identifier (OID) that is defined for a
given application. When a subject presents its certificate, it is examined by the
party validating the certificate to verify the application policy and determine if
the certificate can perform the requested action.
By restricting which application policies are defined in a certificate template, a
certificate may not be used for undesired transactions. For example, a certificate
with the Secure Email OID cannot be used for client authentication function.
Because some implementations of PKI applications may not understand
application policies, both application policies and Enhanced Key Usage (EKU)
fields appear in certificates that a Microsoft CA issues. EKU is similar to
application policy, in that EKU also defines the functions of certificate.
Certificate policies Certificate policies define the measures that are used to identify the subject of
the certificate. For example, your organization may require a face-to-face
meeting before the certificate is issued to provide for a higher level of assurance
for the issued certificate. To indicate that a face-to-face meeting was required
for a certificate, an OID is added to the certificate in the certificate policy
attribute.
Note A certificate policy is sometimes referred to as an issuance policy,

because it describes the conditions under which the certificate is issued.
When a subject presents its certificate, the target server or application examines
it to verify the issuance policy and determine if that level of issuance policy is
sufficient to perform the requested action.
Default certificate policy The following table describes the three default certificate policy OIDs included
OIDs in Windows Server 2003.
OID type Description
Low assurance Provides no additional mechanism to identify the subject of the

certificate. For example, a certificate that is issued based only on
the credentials provided can be a low assurance certificate.
Medium assurance Requires additional validation of the certificate’s subject. For
example, a smart card certificate may require an administrator to
have a face-to-face meeting with an employee before it issues the
smart card to an employee.
High assurance Requires research into the subject’s identity. For example, a high
assurance certificate may require that an organization perform a
background check on an employee before issuing the certificate.
Note The low assurance, medium assurance, and high assurance OIDs are
unique for each Windows Active Directory forest.
Raise Issuance Security

Introduction You can configure a certificate template to increase the issuance security of a
certificate by requiring the user or computer to provide additional forms of
identification for the certificate request. The additional forms of identification
can include providing photo identification, meeting face-to-face with a local
registration authority, or signing the certificate request with a previously issued
signing certificate.
Certificate Manager On the Issuance Requirements tab of a certificate template, you can enable
Approval Certificate Manager Approval. This setting sets all certificates to a pending
state until a certificate manager issues or denies the certificate request. The
certificate manager must first validate the identity of the certificate requestor
before issuing or denying the certificate request. In some cases, the certificate
manager will record any forms of identification that the user presents into a
custom certificate issuance database application.
Signing Requests An existing certificate may sign a certificate to increase the issuance security.
You can configure a certificate template to require a signature with a certificate
with a specific application policy OID, certificate policy OID, or combination
of application and certificate policy OIDs. The assumption here is that the
possession of the private key associated with the signing certificate increases
the issuance security of the certificate request.
Lab B: Designing a Certificate Template

Objective After completing this lab, you will be able to design a custom certificate
template for code signing.
Prerequisites Before working on this lab, you must have knowledge about creating and
modifying version 2 certificate templates.
Scenario You are a PKI administrator of your company network. The company is in the
process of deploying several projects that require certificates from your PKI
hierarchy.
In one project, you must increase the security for Microsoft Excel macros. The
Accounting department implements several Excel workbooks for month-end
procedures. These workbooks contain macros that were developed by the
Accounting IT department.
Currently, the macro security in Microsoft Excel must be set to Low Security to
allow the macros to run without user intervention. Because of the lowered
security, a virus that was distributed in an Excel workbook infected several
computers on the company network.
To increase the security of the Excel macros, you must deploy certificates to the
programmers in the Accounting IT department, so that the programmers can
digitally sign the macros. After the programmers sign the macros, you can
change the macro security setting for the Excel workbooks to High Security to
prevent unsigned macros from being used.
Additional information For more information about configuring a certificate template, see the white
paper, Implementing and Administering Certificate Templates in
Estimated time to
complete this lab:
30 minutes
Exercise 1
Review an Existing Certificate Template
In this exercise, you will gather design requirements for the certificate template, and then analyze
an existing certificate template.
Requirements
During the information gathering stage, you identify the following requirements:
! The subject of the certificate must contain the company name, not the name of the programmer
that signs the certificate.
! The code signing certificate must be stored on a Schlumberger CryptoFlex 8 KB smart card.
! Only members of the Accounting IT department may request a code signing certificate
! All code signing certificate requests and renewals must be approved by Arlene Huff, the
Accounting IT department manager.
! The code signing certificate must be valid for five years.
! The code signing certificate must have a minimum key length of 1024 bits.
! All code signing certificates that the organization issues must meet these requirements.
Open the Certificate Templates MMC

To answer the following questions, it is recommended that you view the certificate templates in the
Certificate Templates MMC. Use the following procedure to open the Certificate Templates MMC.
1. Ensure that you are logged " Log on to your computer with the following information:
on to the domain as a • User name: Template1 (on the domain controller) or Template2
Certificate Template (on the member server)
administrator.
domain)
2. Open the Certificate " Click Start, click Run, type Certtmpl.msc and then click OK.
Templates console.
Analyze existing 1. Is there an existing certificate template that allows code signing? If so, what
certificate templates is the name of the certificate template?
Yes. The Code Signing certificate template allows code signing.
____________________________________________________________
____________________________________________________________
____________________________________________________________
2. Does the Code Signing certificate template meet the design requirements?
No. The Code Signing certificate template has a one-year validity
period and does not implement any issuance requirements.
____________________________________________________________
____________________________________________________________
____________________________________________________________
3. Can you modify the Code Signing certificate template to meet the design
requirements?
No. The Code Signing certificate template is a version 1 certificate
template that allows you to modify only the certificate template
permissions.
____________________________________________________________
____________________________________________________________
____________________________________________________________
4. Can you convert the Code Signing certificate template into a version 2
certificate template?
No. You cannot convert a version 1 certificate template into a version 2
certificate template.
____________________________________________________________
____________________________________________________________
____________________________________________________________
5. How do you create a version 2 certificate template for code signing?

To create a version 2 Code Signing certificate template, you must
duplicate the version 1 Code Signing certificate template.
____________________________________________________________
____________________________________________________________
____________________________________________________________
Exercise 2
Designing the Custom Code Signing Certificate Template
In this exercise, you will design a custom version 2 certificate template that
meets the design requirements that are outlined in Exercise 1.
Scenario To meet the design requirements, you must create a version 2 certificate
template for code signing.
1. In the following table, define the settings on the General tab to meet the
design requirements for your custom Code Signing certificate template.
Attribute Your recommended design
Template display name Any valid name

Template name Any valid name (no spaces allowed)
Validity period 5 years
Renewal period 6 weeks
Publish certificate in Active Disabled
Directory
Do not automatically reenroll if Disabled
a duplicate certificate exists in
Active Directory
2. In the following table, define the settings on the Request Handling tab to
meet the design requirements for the custom Code Signing certificate
template.
Purpose Signature
Allow private key to be Disabled
exported
Minimum key size 1024
Do the following when the Enroll subject without requiring any user
subject is enrolled and when input
the private key associated with
this certificate is used
CSPs Only enable the Schlumberger
Cryptographic Service Provider
3. How must you configure the settings on the Subject name tab to meet the
design requirements?
You must enter the subject name in the certificate request so that the
requestor can provide the company name as the subject of the
certificate.
____________________________________________________________
____________________________________________________________
____________________________________________________________
4. In the following table, define the settings on the Issuance Requirements

tab to meet the design requirements for the custom Code Signing certificate
template.
CA certificate manager approval Enabled

This number of authorized Disabled
signatures
Require the following for Same criteria as for enrollment
reenrollment
5. How must you configure the settings on the Superseded Templates tab to
ensure that all certificates that a certification authority issues for code
signing use the version 2 certificate template?
Add the Code Signing certificate template to the Superseded Templates
tab.
____________________________________________________________
____________________________________________________________
____________________________________________________________
6. Assuming that all of the developers that require the code signing certificate
are in a global group named Company_CodeSigners, what permissions must
you assign to the Company_CodeSigners group?
You must assign Read and Enroll permissions to the
Company_Codesigners group.
____________________________________________________________
____________________________________________________________
____________________________________________________________
7. Are any other modifications required for the permissions assignments?

You must remove the Enroll permission from the Domain Admins
group and the Enterprise Admins group.
____________________________________________________________
____________________________________________________________
____________________________________________________________
Lesson: Publishing a Certificate Template

Introduction When you request a certificate from a Windows Server 2003 enterprise CA, you
can only select from certificate templates that are published at a CA. If a
certificate template is not published at a CA in the CA hierarchy, you cannot
request a certificate based on that template.
To publish a certificate template, you need to define certificate template
permissions and choose the CA that will issue the certificate template.
! Identify the permissions for certificate template objects.
! Define certificate template permissions.
! Publish certificate templates.
Certificate Template Permissions

Introduction Certificate template permissions define the security principals that can read,
modify, or enroll certificates based on certificate templates. You must define
the permissions for each certificate template to ensure that only authorized
users, computers, or group members can obtain certificates based on a
Available permissions The permissions that you can assign for a certificate template include:
! Full Control. Allows a security principal to modify all attributes of a
certificate template, including the permissions for the certificate template.
! Read. Allows a security principal to find the certificate template in Active
Directory when enrolling for certificates.
! Write. Allows a security principal to modify the all the attributes of a
certificate template, except for the permissions that are assigned to the
! Enroll. Allows a security principal to enroll for a certificate based on the
certificate template. To enroll for a certificate, the security principal must
also have Read permissions for the certificate template.
! Autoenroll. Allows a security principal to receive a certificate through the
autoenrollment process. Autoenrollment permissions require that the user
has both Read and Enroll permissions.
Guidelines for Defining Certificate Template Permissions

Introduction You must define the permissions for each certificate template to ensure that
only authorized users, computers, or groups can obtain certificates based on a
Guidelines for defining Use the following guidelines for assigning permissions:
certificate template
permissions ! Assign permissions only to global or universal groups. It is not
recommended to assign permissions to domain local groups, because they
are only recognized in the domain where the domain local group exists, and
can result in an inconsistent application of permissions. Never assign
permissions directly to an individual user or computer account.
! Grant global or universal groups the Read and Enroll permissions to enable
enrollment via the Certificates console in Microsoft Management Console
(MMC) or through Web-based enrollment.
! Enable autoenrollment of a certificate template by adding the user or
computer account to groups that are granted Read, Enroll, and Autoenroll
permissions.
! Enable certificate renewal by adding a user or computer account to a
security group assigned Read, Enroll, and Autoenroll permissions.
! Restrict Write and Full Control permissions to certificate template managers
to ensure that the templates are properly configured.
Guidelines for Publishing a Certificate Template

Introduction Before the certificates based on a certificate template are available to users and
computers, the certificate template must be published at one or more CAs on
the network. The publication of the certificate template completes the certificate
template creation process by ensuring that the certificate is available for
enrollment.
Guidelines Use the following guidelines when publishing certificate templates to enable
certificate enrollment on the network:
! Publish certificate templates on at least two CAs in the forest. When you
publish a certificate template on two or more CAs in the forest, you ensure
that the certificate template is available for enrollment even if a CA fails on
the network. As long as the available CA chains to the same trusted root, it
does not matter which CA in the CA hierarchy issues the certificate to a
requesting user or computer.
! Publish certificate templates on local CAs. If your network has multiple
network segments, consider publishing a certificate template to a CA at each
network segment where the certificates based on the template will be used.
This ensures that if a wide area network (WAN) link fails, users or
computers can still enroll certificates by requesting the certificates from a
CA on the local network segment.
Lesson: Managing Changes in a Certificate Template

Introduction There will be times when you must modify or delete a certificate template to
correct some errors or to meet a new requirement. Depending upon the template
version and the impact of the change, you can update a certificate template by
either modifying or superseding it.
! Describe the methods of updating a certificate template.
! Describe the guidelines for modifying a certificate template.
! Describe the guidelines for superseding a certificate template.
! Identify the steps of superseding a certificate template.
Methods of Updating a Certificate Template

Introduction In your CA hierarchy, you might have one certificate template for each job
function, such as file encryption or code signing, or a few templates that cover
functions for most common groups of subjects. You may have to modify an
existing certificate template due to incorrect settings that were defined in the
original certificate template; or you may have to merge multiple existing
certificate templates into a single template.
Methods to update a You can modify an existing certificate template by:
certificate template
! Modifying the original certificate template. You can modify a version 2
certificate template at any time by making changes to the certificate
template and applying those changes to the certificate template. After the
changes are made, any certificate issued by a CA based on that certificate
template will apply the changes made to the certificate template.
! Superseding existing certificate templates. If multiple certificate templates
exist that provide the same or similar functionality, you may supersede the
existing certificate template with a single certificate template. This is
accomplished by designating that a new certificate template supersedes, or
replaces, the existing certificate templates.
Note Both modification and superseding affect only those certificates that are
issued after you modify the certificate. Existing certificates are not modified
until the user or computer holding the certificate based on the certificate
template renews the certificate or enrolls a new certificate based on the
modified or superseded certificate template.
If autoenrollment is enabled for the updated certificate template or the

superseded certificate template, the users or computers will automatically enroll
the updated certificates.
Guidelines for Modifying a Certificate Template

Introduction You may need to modify a certificate template after you have completed the
initial design of the certificate template. A modified certificate template may or
may not require re-issuance of existing certificates. The decision must be based
on the changes made to the certificate template.
Guidelines for modifying Consider modifying an existing certificate template when:
a certificate template
! The changes affect only a single certificate template. If the changes do not
require certificates to be re-issued to all current certificate holders, you can
simply modify an existing certificate template.
! The existing certificate template is a version 2 certificate template. Only
version 2 certificate templates support modification. If the existing
certificate template is a version 1 certificate template, you must supersede
the existing certificate template with a version 2 certificate template.
! The changes to the certificate template are relatively minor. A minor change
is typically a change that does not require that you re-issue existing
certificates that are based on the certificate template. For example, changing
the permissions for a certificate template to allow additional groups to enroll
the certificate template would not require the re-issuance of all existing
certificates.
Guidelines for Superseding a Certificate Template

Introduction When superceding, the new certificate template may supersede both existing
version 1 or version 2 certificate templates.
Guidelines for Supersede an existing template when you want to:
superseding a certificate
template ! Consolidate multiple existing certificate templates into a single certificate
template. For example, if your organization acquires another organization, it
is possible that multiple certificate templates exist that provide the same
functionality.
! Modify a version 1 certificate template. Version 1 certificate templates do
not allow modification. By superseding the version 1 certificate template
with a version 2 certificate template, you can modify the settings of the
! Modify the certificate lifetime. If you must change the lifetime of an
existing certificate template, supersede the existing certificate template.
! Modify the key size for a certificate. By superseding the existing certificate
template, you do not run into confusion where two certificates that are based
on the same certificate template have varying key lengths. Only the new
certificate template will implement the new key length.
! Add application or issuance policies. Superseding ensures that two
certificates based on the same certificate template do not have mismatched
application or issuance policies. Only certificates based on the new
certificate template will include the OIDs that the application or issuance
policies designate.
Note You can force the application of the updated certificate template by
forcing all certificate holders to re-enroll the updated certificate template.
How to Supersede a Certificate Template

Introduction Superseding a certificate template ensures that the newly created certificate
template replaces one or more existing certificate templates. By superseding the
existing certificate templates, you ensure that the subjects of certificates based
on the old template obtain new certificates based on the new template.
How to supersede To supersede an existing certificate template:
1. Log on as a user who has permissions to modify the certificate template.
2. Open the Certificate Templates console and create a new certificate
template that applies the new settings that you require for the certificate
template.
3. In the properties of the new certificate template, on the Superseded
Templates tab, add all superseded certificate templates and apply the
changes.
4. In the details pane, right-click the newly created certificate template, and
then click Reenroll All Certificate Holders.
Lab C: Configuring Certificate Templates

! Create a version 2 certificate template.
! Modify the attributes of a version 2 certificate template.
! Publish a version 2 certificate template.
! Supercede a version 2 certificate template.

! Installed a Windows Server 2003 CA hierarchy that has an offline
standalone root CA and an online subordinate enterprise CA.
! Implemented and enforced role separation for the enterprise CA in your
domain.
! Delegated the permission to create and modify certificate templates to the
! Created an MMC console named Certificate Management on the desktop
with the Certificates – Current User and Certificates (Local Computer)
snap-ins loaded.
! Configured http://WebServer (where WebServer is the fully qualified
domain name of your domain controller) as a member of the Local Intranet
site in the Default Domain Policy.
! Knowledge about creating and modifying version 2 certificate templates.
Additional information For more information about creating certificate templates, read the white paper,
Implementing and Administering Certificate Templates in
Estimated time to
complete this lab:
30 minutes
Exercise 1
Creating a Certificate Template
In this exercise, you will create a version 2 certificate template based on the User certificate
template.
Scenario
Your organization must implement a modified version of the User certificate template. Each
division of your organization will maintain its own version of the modified User certificate
template.
administrator.
domain)
2. Open the Certificate a. Click Start, click Run, type Certtmpl.msc and then click OK.
Templates console. b. In the Certificate Templates dialog box, click OK.
3. Create a new certificate a. In the Certificate Templates console, in the details pane, right-click
template named User, and then click Duplicate Template.
ComputerUser based on the b. In the Properties of New Template dialog box, on the General tab, in
User certificate template. the Template display name box, type ComputerUser (where
Computer is the NetBIOS name of your computer), and then click OK.
What members of the Windows Server 2003 family can issue the newly created certificate template?
Only Windows Server 2003, Enterprise Edition and Windows Server 2003, Data Center Edition can
issue version 2 certificate templates.
4. On the General tab of the a. In the details pane, double-click the ComputerUser certificate template.
ComputerUser certificate b. On the General tab, define the validity period as 3 Years.
template, define the validity
period as 3 Years. c. Click Apply.
(continued)
5. On the Request Handling a. On the Request Handling tab, define the minimum key size as 2048
tab, define the minimum key bytes.
size as 2048 bytes. b. Click Apply.
6. On the Security tab, view " Click the Security tab, and then view the settings.
the current settings.
If you want to restrict enrollment to members of the Marketing department, what would you do?
You would create a global group that contains all Marketing department users. Then assign Read and
Enroll permissions to the Marketing global group.
Why is it necessary to use global or universal groups when you assign permissions to certificate templates?
Certificate template objects are stored in the configuration naming context. By using global or
universal groups when you assign permissions, all domains in the forest can recognize the groups.
7. On the Subject name tab of a. On the Subject Name tab, select Build from this Active Directory
the ComputerUser information.
certificate template, perform b. In the Subject name format drop-down list, select Common name.
the following steps:
c. Select the Include e-mail name in subject name check box.
• Select Build from this
Active Directory d. Leave all other settings as the default settings.
information. e. Click Apply.
• Select Common name.
• Select the Include
e-mail name in subject
name check box.
(continued)
8. On the Extensions tab, a. On the Extensions tab, select Application Policies, and then click
remove the Encrypting File Edit.
System application policy. b. In the Edit Application Policies Extension dialog box, select
Encrypting File System, and then click Remove.
c. In the Edit Application Policies Extension dialog box, click OK.
d. In the ComputerUser Properties dialog box, click OK.
9. Close all open windows and a. Close the Certificate Templates console.
log off the network. b. Close all open windows, and then log off.
Exercise 2
Publishing a Certificate Template
In this exercise, you will publish your modified User certificate template on the DomainCA
Scenario
After you create a custom User certificate template, publish the certificate template on an enterprise
CA so that users can enroll the certificate based on the modified template.
on to the domain as a • User name: CAadmin1 (on the domain controller) or CAadmin2
administrator.
domain)
2. Open the Certification " On the Start menu, click Administrative Tools, and then click
Authority console. Certification Authority.
If you are working on the member server in your domain, an error
message appears, stating that Certificate Services is not an
controller.
Authority console to manage b. In the console tree, right-click Certification Authority, and then click
the enterprise CA in your Retarget Certification Authority.
domain.
and then click OK.
(continued)
4. Configure the DomainCA to a. In the console tree, expand Certification Authority, expand
issue the ComputerUser DomainCA, and then click Certificate Templates.
certificates. Close all open b. In the console tree, right-click Certificate Templates, click New, and
windows and log off. then click Certificate Template to Issue.
c. In the Enable Certificate Templates dialog box, click ComputerUser
(where Computer is the NetBIOS name of your computer), and then
click OK.
d. In the details pane, ensure that the ComputerUser certificate template
appears in the details pane.
f. Close all open windows, and then log off.
Exercise 3
Enrolling the Certificate Template
In this exercise, you will perform a certificate request to indicate that the certificate template that
you created and published has the format of the certificate.
Scenario
After you publish the certificate template on the enterprise CA in your domain, you must enroll the
certificate to ensure that the certificate is issued as required.
with your domain • User name: Student1 (on the domain controller) or Student2 (on
administrative account. the member server)
your administrative account).
domain).
2. Connect to a. Open Internet Explorer.

http://WebServer/certsrv b. If the Internet Explorer dialog box appears, click In the future, do
and request a ComputerUser not show this message, and then click OK.
certificate by performing the
following steps: c. In the Address bar, type http://WebServer/certsrv (where WebServer
is the fully qualified domain name of your domain controller) and then
• Click Request a press ENTER.
certificate.
d. On the Welcome page, click Request a certificate.
• Click advanced
certificate request. e. On the Request a Certificate page, click advanced certificate
request.
• Click Create and
Submit a request to f. On the Advanced Certificate Request page, click Create and submit
this CA. a request to this CA.
• Choose the g. On the Advanced Certificate Request page, in the Certificate

ComputerUser Template drop-down list, select ComputerUser (where Computer is
certificate template. the NetBIOS name of your computer).
• Ensure the key size is h. On the Advanced Certificate Request page, in the Key Options
2048 bytes. section, ensure that the key size is 2048.
• Type the friendly name: i. On the Advanced Certificate Request page, in the Friendly Name
ComputerUser box, type ComputerUser
• Click Yes in the j. On the Advanced Certificate Request page, scroll to the bottom of the
Potential Scripting page, and then click Submit.
Violation dialog box. k. In the Potential Scripting Violation dialog box regarding the Web site
• Install the issued requesting a new certificate on your behalf, click Yes.
certificate. l. On the Certificate Issued page, click Install this certificate.
(continued)
2. (continued) m. In the Potential Scripting Violation dialog box regarding the addition
of one or more certificate to your computer, click Yes.
n. Ensure that the Certificate Installed page indicates that Your new
certificate has been successfully installed.
o. Close Internet Explorer.
3. View the properties of the a. On the desktop, double-click Certificate Management.

newly issued ComputerUser b. In the Certificate Management console, in the console tree, expand
certificate. Certificates – Current User, expand Personal, and then click
Certificates.
c. In the details pane, scroll to the right and double-click the certificate
that has the friendly name of ComputerUser.
d. On the General tab, view the properties of the ComputerUser
certificate.
What is the validity period of the certificate?
The certificate is valid for three years.
4. View the Details tab. " Click the Details tab
What application policies are included in the application policies extension?
The extension includes the Client Authentication and Secure Email application policies.
5. Close all open windows and a. Click OK.

log off the network. b. Save any changes, and then close the Certificate Management console.
c. Close all open windows, and then log off.
Exercise 4
Superceding a Certificate Template
In this exercise, you will create a new certificate template that supersedes the three existing
certificate templates. The new certificate template modifies the existing certificate templates by
preventing the export of the private key and by adding a Low assurance issuance policy.
Scenario
Your organization has consolidated operations by creating a centralized IT department. Rather than
having separate certificate templates for each division, the organization will deploy a common
certificate template. This new certificate template must supersede the three existing templates and
make minor modifications to the certificate template.
1. Ensure you are logged on to " Log on to your computer with the following information:
the domain as a Certificate • User name: Template2
Template administrator.
domain)
2. Create a new certificate a. Click Start, click Run, type Certtmpl.msc and then click OK.
template named b. In the Certificate Templates dialog box, click OK.
SupersededUser based on
one of the existing c. In the details pane, right-click ComputerUser (where Computer is the
ComputerUser certificate NetBIOS name of your computer), and then click Duplicate Template.
templates. d. In the Properties of New Template dialog box, on the General tab, in
the Template display name box, type SupersededUser and then click
OK.
3. Make private key export a. In the details pane, double-click SupersededUser.

unavailable in the b. On the Request Handling tab, clear the Allow private key to be
SupersededUser certificate exported check box, and then click Apply.
template.
4. Add the Low assurance a. On the Extensions tab, click Issuance Policies, and then click Edit.
issuance policy OID to the b. In the Edit Issuance Policies Extension dialog box, click Add.
c. In the Add Issuance Policy dialog box, click Low Assurance, and
then click OK.
d. In the Edit Issuance Policies Extension dialog box, click OK.
e. Click Apply.
(continued)
5. Configure the a. On the Superseded Templates tab, click Add.

SupersededUser certificate b. In the Add Superseded Template dialog box, in the Certificate
template to supersede the templates list, click ComputerUser, press CTRL and click
two ComputerUser PartnerComputerUser (where PartnerComputer is the NetBIOS name
certificate templates. of your partner’s computer), and then click OK.
c. On the Superseded Templates tab, ensure that both certificate
templates appear in the Certificate Templates list.
d. In the SupersededUser Properties dialog box, click OK.
on to the domain as a • User name: CAadmin1
administrator. • Password: P@ssw0rd
• Domain: Domain
8. Configure the DomainCA to a. On the Start menu, click Administrative Tools, and then click
issue the SupersededUser Certification Authority.
certificate template. b. In the console tree, expand Certification Authority, expand
DomainCA, and then click Certificate Templates.
c. In the console tree, right-click Certificate Templates, click New, and
then click Certificate Template to Issue.
d. In the Enable Certificate Templates dialog box, click
SupersededUser, and then click OK.
e. In the details pane, ensure that the SupersededUser certificate
template appears.
9. Remove the two superseded a. In the details pane, click ComputerUser, press CTRL and click
certificate templates from PartnerComputerUser, right-click the selection, and then click Delete.
the list of certificate b. In the Disable certificate templates dialog box, click Yes.
templates issued by the
DomainCA. Close all open c. Close the Certification Authority console.
windows and log off d. Close all open windows and then log off.
Certificate Enrollment
Contents
Overview 1
Lesson: Introduction to Certificate
Enrollment 2
Lesson: Enrolling Certificates Manually 9
Lesson: Autoenrolling Certificates 14
Lab A: Enrolling Certificates 23
respective owners.
Module 6: Configuring Certificate Enrollment iii
Instructor Notes
Presentation: Certificate enrollment is the process of requesting and receiving a certificate
60 minutes from a certification authority (CA). In this module, students will learn about the
various methods of enrolling certificates. Students can either process the
Lab: certificate requests manually or automatically depending upon the approval
45 minutes requirement from the certificate manager.
! Select the appropriate certificate enrollment method for a given scenario.
! Enroll certificates manually.
! Autoenroll certificates.
! Enroll smart card certificates.
Required materials To teach this module, you need:

! Microsoft® PowerPoint® file 2821A_06.ppt.
! The multimedia presentation Certificate Enrollment.


! Review the multimedia presentation Certificate Enrollment.
! Read the white paper, Certificate Autoenrollment in Windows Server 2003.
iv Module 6: Configuring Certificate Enrollment

Lesson: Introduction to Certificate Enrollment

This lesson discusses the certificate enrollment processes that are available for
users, computers, and other network devices.
lesson.
Multimedia: Certificate The multimedia files are installed on the instructor computer. To open a
Enrollment multimedia presentation, click the animation icon on the slide.
After viewing the multimedia, ensure that the students understand how the
certificate enrollment process works. Review where the key pair is generated
during a certificate request; highlight the difference between a certificate
generated on smart card and a certificate generated in the current user or local
computer store.
Enrollment Methods Prepare examples of each enrollment method, to stress some of the decision
factors in choosing an enrollment method. Tell the students that two or more of
the certificate enrollment methods can meet some requirements.
Guidelines for Securing Microsoft Windows Server™ 2003 introduces several mechanisms for securing
the Enrollment Process the enrollment process. Consider opening the Certificate Templates console
(Certtmpl.msc) and demonstrating how you would enforce each of the options
shown in the slide.
Considerations for Review the guidelines presented in the slide. Enforce that client computers
Choosing an Enrollment running Microsoft Windows® 2000 only support autoenrollment of computer
Method certificates while computers running Microsoft Windows XP or an operating
system in the Windows Server 2003 family support autoenrollment of both user
and computer certificates.
Lesson: Enrolling Certificates Manually

This lesson describes manual certificate enrollment, including the Certificate
Enrollment Web site, the Certificates console, and the Certreq.exe command-
line tool.
lesson.
How to Enroll The Certificate Enrollment Web site is best used for requests by either users or
Certificates Using a computers that do not have user or computer accounts in your organization’s
Web-based Interface forest. Web enrollment is also the preferred enrollment method for pending
certificate requests, or requests from an external network that must traverse a
firewall.
Consider demonstrating the Web enrollment procedure as you discuss the
process.
Module 6: Configuring Certificate Enrollment v
How to Request The Certificates console is only available for requesting certificates from an
Certificates Using the enterprise CA. The MMC console allows you to install certificates for user
MMC Wizard accounts, computer accounts, or service accounts.
Consider demonstrating the Certificate Enrollment Wizard.
Request Certificates Certreq.exe was used to request certificates in Lab B: Backing Up and
Using Certreq.exe Restoring a Certification Authority, in Module 4, “Managing a Public Key
Infrastructure,” Course 2821, Designing and Managing a Windows Public Key
Infrastructure. Consider showing the contents of the Requestcert.cmd and
Certreq.inf files in the C:\Moc\2821\Labfiles\Module4 folder, to illustrate what
information is required as input when requesting a certificate.
Lesson: Autoenrolling Certificates

In this lesson, students will learn the basics of certificate autoenrollment. The
lesson compares automatic certificate request settings and Autoenrollment
Settings. Be sure that you understand the differences and the decision points for
choosing one method over the other.
lesson.
Certificate Do not spend a large amount of time comparing the two methods on this page.
Autoenrollment More details are available in the topics that follow this topic. Discuss the major
differences between automatic certificate request settings and Autoenrollment
Settings.
Automatic Certificate Request Settings
! Only deploys computer certificates
! Requires version 1 certificate templates
! Deploys to computers running Windows 2000, Windows XP, and operating
systems in the Windows Server 2003 family
Autoenrollment Settings
! Deploys user and computer certificates
! Requires version 2 certificate templates
! Only deploys to computers running Windows XP and operating systems in
the Windows Server 2003 family
How to Enable Consider demonstrating how to add certificate templates for deployment by
Autoenrollment Using using automatic certificate request settings. During the demonstration, show
Automatic Certificate that only version 1 certificate templates that are issued to computers are
Request Settings available for selection.
Enable Autoenrollment The first step in designing automatic certificate enrollment by using
in the Version 2 Autoenrollment settings is configuring a certificate template to support
Certificate Template Autoenrollment. Consider showing each tab in the Certificate Templates
console, which is described in the slide.
Stress that to deploy a certificate template by using Autoenrollment settings, a
universal group must be assigned the Read, Enroll, and Autoenroll permissions.
vi Module 6: Configuring Certificate Enrollment
How to Enable Share with the students that the Autoenrollment Settings Group Policy is
Autoenrollment Settings available in a Windows Server 2003 forest and a Windows 2000 forest, as long
in Group Policy as the Windows Server 2003 schema extensions are applied to the
Windows 2000 forest.
Remind the students that you can only define this group policy setting by
editing the Group Policy object (GPO) from a computer running Windows XP
with the Windows Server 2003 Administration Pack (Adminpak.msi) installed
or from a computer running Windows Server 2003.
Considerations for Use the chart on the slide to compare and contrast the two autoenrollment
Implementing processes. Ensure that the students are clear on when to choose each
Autoenrollment autoenrollment method.
Lab A: Enrolling Certificates

In this lab, students will combine design and implementation to acquire
certificates from their organization’s enterprise subordinate CA.
! Determine which enrollment method to use for specific scenarios.
! Enroll certificates by using the Certificate Enrollment Wizard.
! Enroll certificates by using Autoenrollment.
When performing this lab, it is inevitable that the students do not have enough
patience when they wait for autoenrollment to occur. Remind students that all
Group Policy objects that are applied to the computer and user must be
evaluated before the autoenrollment process begins. They may have to wait for
a period of up to 90 seconds before enrollment takes place.
If autoenrollment fails, verify the following:
! Is the AutoenrollUsers group assigned Read, Enroll, and Autoenroll
permissions.
! Are the two AutoComputer certificate templates published at the enterprise
subordinate CA.
! Does the Autoenrollment GPO exist?
! Is the Autoenrollment GPO correctly defined to enable all autoenrollment
options for users, not computers.
! Is the Autoenrollment GPO linked to the Module06 OU.
Module 6: Configuring Certificate Enrollment vii
Lab Setup
an enterprise subordinate CA exist.
! Complete Lab A, Lab B, and Lab C in Module 3, “Creating a Certification
Authority Hierarchy,” in Course 2821, Designing and Managing a Windows
enforced.
Course 2821.
Course 2821.
Lab Results
changes:
! An Internet Protocol security (IPSec) certificate is installed at both the
domain controller and member server.
! Two certificate templates are created that are based on the User Signature
Only certificate template, AutoComputer and AutoPartnerComputer. The
two certificate templates enable autoenrollment.
! The Autoenrollment GPO is created and linked to the Module06
organizational unit. The GPO enabled autoenrollment of user certificates.
! The CertAdmins group is assigned the Issue and Manage Certificates
permission.
! AutoComputer and AutoPartnerComputer are issued to the Enroll1 and
Enroll2 user accounts.
Module 6: Configuring Certificate Enrollment 1
Overview

Introduction Certificate enrollment is a process that is used for requesting and receiving a
certificate from a certification authority (CA).
Certificate enrollment involves:
! Configuring permissions to establish which security principals have Enroll
permissions for specific templates.
! Appointing a certificate manager who reviews each certificate request and
issues or denies the request.
There are various methods for enrolling certificates. You can either process the
certificate requests manually or automatically depending upon the approval
requirement from the certificate manager.
! Select the appropriate certificate enrollment method for a given scenario.
! Perform manual certificate enrollment.
! Enable autoenrollment of certificates.
2 Module 6: Configuring Certificate Enrollment
Lesson: Introduction to Certificate Enrollment

Introduction Certificate enrollment is initiated when a user, service, or computer requests a
certificate. The certificate request is processed to determine if the requestor has
the correct permissions to enroll the requested certificate. In some cases, the
certificate may be kept pending until a certificate manager issues the requested
certificate from a pending state.
! Describe the sequence of steps in the certificate enrollment process.
! Describe the methods available for certificate enrollment in a Microsoft
! List the best practices for securing the enrollment process.
! Select an appropriate enrollment method for a security principal.
Multimedia: Certificate Enrollment

File location To view the Certificate Enrollment Process presentation, open the Web page on
the Student Materials compact disc, click Multimedia, and then click the title
of the presentation.
Key points ! Certificate enrollment is the process of requesting and installing certificates
for a user, computer, or service.
! The policies and processes of the CA define how you request and receive
certificates.
! A stand-alone CA supports only Web-based enrollment, and an enterprise
CA supports both Web-based and Microsoft Management Console (MMC)
enrollment.
! A cryptographic service provider (CSP) installed on the computer generates
the private and public keys, also known as a key pair, for the certificate
request. A CSP can be software-based or hardware-based.
! The public key is sent to the CA along with the certificate requestor
information.
Enrollment Methods

Introduction Certificate enrollment is the process by which a user obtains a certificate from
the CA. A Windows Server 2003 family CA provides several methods for
certificate enrollment. The enrollment method that you choose to acquire a
certificate will rely on the type of CA that you are requesting the certificate
from, and the physical location of the client computer and the issuing CA on the
network.
Enrollment methods When requesting certificates from CAs running an operating system in the
Windows Server 2003 family, the following enrollment methods are available:
! Web-based. Allows you to connect to a CA by using a Web browser, and
perform common tasks, such as requesting certificates from a CA or
requesting the CA’s certificate. For a stand-alone or enterprise CA, the Web
pages are the primary way to interface with the CA. Web enrollment is also
used when an external user requests a certificate from a CA that is protected
by a firewall.
! Certificates console. Allows a user or computer to request certificates from
an enterprise CA by using the Certificate Request Wizard. The wizard
allows you to select the enterprise CA and the certificate template, and
define additional settings, such as key length and CSP.
! Certreq.exe. Allows you to submit, retrieve, create, and accept certificate
requests that are sent to a Windows Server 2003 CA. You can also use
Certreq.exe to create and sign Cross Certification Authority certificate
requests. You can also place the Certreq.exe command syntax in a batch file
to script certificate requests.
! Autoenrollment. Allows clients to automatically submit certificate requests

to a CA and retrieve and store issued certificates. Microsoft Windows® XP
and Windows Server 2003 clients can participate in autoenrollment for both
user and computer certificates. Autoenrollment reduces the total cost of
ownership by reducing the costs associated with the certificate enrollment
and renewal process.
! Enrollment agent. Requests Smart Card User certificates and Smart Card
Logon certificates on behalf of other users by signing the certificate request
with their Enrollment Agent certificate. The enrollment agent role allows
you to implement a security policy that requires face-to-face meetings for
smart card issuance. When the identity of the requesting user is verified, the
enrollment agent can request a smart card certificate on the behalf of the
user.
Guidelines for Securing the Enrollment Process

Introduction Any subject that has at least Read and Enroll permissions for a certificate
template can request certificates. To control what certificates are issued and
how the issuance process is implemented, an administrator can use an
enrollment policy to place some restrictions on the process that occurs after a
certificate request is made.
To secure the enrollment process, place restrictions on the certificates that are
issued and the certificate issuance process.
Certificate template Secure the enrollment process by limiting the security groups that are assigned
permissions the Enroll permissions. Assign permissions for the certificate templates to either
global or universal groups. If role separation is enabled at a CA, only certificate
managers can modify the certificate template permissions.
Certificate manager Keep the certificate request pending until a certificate manager validates the
approval user’s credentials. To enable certificate manager approval, a certificate template
manager must select the CA certificate manager approval check box on the
Issuance Requirements tab of the certificate template. This will place the
certificate request into the Pending Requests container of the CA until a
certificate manager approves or denies the request.
Registration authority Require that the certificate request a private key of a previous enrolled
certificate sign it and define what issuance policy or application policy must
exist in the signing certificate. The certificate template can require one or more
signatures be applied to the certificate request.
For example, you can create a version 2 certificate template based on the basic
Encrypting File System (EFS) certificate that requires that the certificate
request be signed by a certificate with the Smart Card Logon application policy.
The assurance is raised because, to use a smart card certificate, the user must
possess the physical smart card and know the smart card’s personal
identification number (PIN).
Note For autoenrollment to be successful, you can only require one authorized
signature. More than one signature disables autoenrollment.
Considerations for Choosing an Enrollment Method

Introduction To select the certificate enrollment method that is appropriate for your
organization, you should consider the security principals, the operating system
on the client computers, the policy requirements, the physical location of the
client computer and the issuing CA on the network, and the type of CAs.
All this information can help you decide the appropriate enrollment method.
Considerations When you choose an enrollment method for certificates that your organization’s
PKI issues, consider the following:
! You can request certificates from stand-alone CAs by using the Web
enrollment pages or the CertReq.exe command-line utility. You can also
submit certificate requests directly to the CA by using the Certification
Authority console.
! Enterprise CAs allow certificate enrollment by using the Web Enrollment
pages, the Certificates console, autoenrollment certificates by using Group
Policy, or the CertReq.exe command-line utility.
! Computers running Microsoft Windows 2000 can use autoenrollment only
for computer certificates by using version 1 certificate templates and the
Automatic Certificate Request Settings policy in Group Policy.
Autoenrollment of user certificates is not possible for Windows 2000
clients.
! Windows XP and Windows Server 2003 support autoenrollment for both
user and computer certificates by using the Autoenrollment Settings policy
in Group Policy and version 2 certificate templates.
! Autoenrollment Settings in Group Policy requires the use of version 2
certificate templates. Version 2 certificate templates can only be issued by
Windows Server 2003, Enterprise Edition and Windows Server 2003,
Datacenter Edition servers that are configured as enterprise CAs.
Lesson: Enrolling Certificates Manually

Introduction Manual enrollment is the only way to enroll certificates for pre-Windows 2000
clients. However, you can also use manual enrollment for clients running later
versions of Windows. For example, for high-security certificates, such as an
enrollment agent certificate which allows requests on behalf of other users, you
can enforce manual enrollment.
! Enroll certificates by using a Web-based interface.
! Enroll certificates by using the MMC wizard.
! Request certificates by using Certreq.exe.
How to Enroll Certificates Using a Web-based Interface

Introduction Every CA that is hosted on a server running Windows Server 2003 includes a
Web Enrollment Web site. The Web Enrollment Web site allows users to
perform various tasks that are related to requesting certificates from both stand-
alone and enterprise CAs.
Procedure for using a The Web Enrollment Web site is located at http://ServerName/certsrv. To
Web-based interface request a certificate by using the Web Enrollment Web site:
1. In the Address bar of Internet Explorer, type http://ServerName/certsrv
(where ServerName is the name of the Windows Server 2003 Web server
that hosts the CA).
Important You must add the ServerName Web site to the Local intranet or
Trusted sites zone in Internet Explorer if the Windows Server 2003 Internet
Explorer Enhanced Security Settings are enabled. Addition to these zones
ensures that the Microsoft ActiveX® controls included in the Web site are
allowed to download to Web clients.
2. Click Request a certificate.

3. On the Request a Certificate page, do one of the following:
• To enroll a User certificate, click User Certificate.
• To enroll any other certificate, click Advanced certificate request. In
the Advanced Certificate Request page, submit a request to the CA
that indicates the certificate template, CSP, and other attributes of the
requested certificate.
4. If you see the Certificate Issued Web page, click Install this certificate,
and then close Internet Explorer.
If you do not see the Certificate Issued Web page, then you do not meet
issuance requirements of the certificate template, or the issuance requirements
of the certificate template may have kept the certificate request pending.
You can request a certificate from the Web pages with advanced options. These
include options for CSP, hash algorithm key generation, creating a new key set
or using an existing key set, marking the keys as exportable, enabling strong
key protection, and using the local computer store to generate the key.
How to Request Certificates Using the MMC Wizard

Introduction You use the Certificates console only to request certificates from a
Windows 2000 Server or a Windows Server 2003-based computer that is
configured as an enterprise CA. The Certificates console displays the
certificates currently enrolled for the user or computer account, and displays
other properties such as trusted root CAs and existing certificate trust lists.
As a user, when you add Certificates to your MMC, you can manage
certificates only for your user account. As the administrator of the computer,
you can manage certificates that are issued to:
! Yourself - the My user account option
! Your computer - the Computer account option
! Local services - the Service account option
Procedure for To request a certificate by using the Certificates console:

requesting a certificate
1. Open the Certificates console.
2. In the console tree, expand Certificates, expand Personal, and then click
Certificates.
3. On the Action menu, point to All Tasks, and then click Request New
Certificate to start the Certificate Request Wizard.
4. In the Certificate Request Wizard, click Next.
5. On the Certificate Types page, select the type of certificate that you want
to request, and then click Next.
6. On the Certificate Friendly Name and Description page, type a display
name for your new certificate, and then click Next.
7. In the Certificate Request Wizard, click Finish.
8. After the Certificate Request Wizard has successfully finished, click OK to
install the issued certificate.
Request Certificates Using Certreq.exe

Introduction You can use Certreq.exe to submit, retrieve, and accept certificate requests. It
allows you to script the certificate enrollment process and also request Qualified
Subordination certificates. By using Certreq.exe with its primary switches, you
can perform common certificate-related tasks.
Submit a request Use the certreq –submit command to submit a previously created request file
to a CA. The request file can be a PKCS#10, a PKCS#7 or CMC certificate
request format. CMC is also known as the Certificate Management protocol
using Cryptographic Message Syntax (CMS). The command can include
parameters to specify which CA the request is submitted to, whether to include
the certificate revocation list (CRL) for the CA in the output file, and the format
of the output file.
Retrieve a request Use Certreq.exe to retrieve a response to a previous request from a CA, if the
previous certificate request was kept pending. Use certreq –retrieve
RequestID where RequestID is the identification number of the certificate
request. This command can be used after the certificate is issued.
Create a new request Use the certreq –new PolicyFile command to submit a new certificate request
to a CA. The certificate request information is based on the data stored in an
input policy file. PolicyFile is an information (.inf) file that contains a textual
representation of the extensions that are used to qualify a request.
Accept a new request When you submit a new request file, you must accept and install the response to
the request. You can do this by using the certreq –accept command.
Create Cross When performing qualified subordination between two CAs in two separate CA
Certification Authority hierarchies, the certreq –policy command constructs the qualified
certificates subordination request file based on the CA certificate and the policy.inf file that
defines the qualified subordination constraints for the Cross Certification
Authority certificate.
Lesson: Autoenrolling Certificates

Introduction When you autoenroll certificates, the system provides a quick and simple way
to issue certificates to users and computers. By using autoenrollment you can
issue certificates for users and computers in your organization without requiring
user input. This reduces the costs associated with deploying a PKI by removing
the responsibilities of the users in the certificate enrollment process.
! Describe the benefits and methods of autoenrollment.
! Enable autoenrollment by using Automatic Certificate Request Settings.
! Enable autoenrollment in version 2 certificate templates.
! Enable autoenrollment settings in Group Policy.
! Describe the considerations for implementing autoenrollment.
Certificate Autoenrollment

Introduction Autoenrollment enables organizations to automatically deploy public key-based
certificates to users and computers. It also supports smart card-based
certificates. The autoenrollment feature allows organizations to manage all
aspects of the certificate lifecycle including certificate enrollment, certificate
renewal, superceding of certificates and multiple signature requirements.
Benefits of Automatic enrollment of user certificates provides a quick and simple way to
autoenrollment issue certificates to users. It also enables faster deployment of PKI applications,
such as smart card logon, Encrypting File System (EFS), Secure Sockets Layer
(SSL), and Signed Multipurpose Internet Mail Extensions (S/MIME) within an
Active Directory® directory service environment.
User and computer autoenrollment:
! Minimizes the high cost of normal PKI deployments.
! Reduces the total cost of ownership for a PKI implementation when clients
running Windows XP Professional are configured to use Active Directory.
Autoenrollment methods In a Windows Server 2003 PKI, there are two methods of enabling
autoenrollment of certificates:
! Automatic Certificate Request Settings. Is a Group Policy setting that
enables the deployment of version 1 certificates to computers running
Windows 2000, Windows XP, and Windows Server 2003.
! Autoenrollment Settings. Is based on a combination of group policy settings
and version 2 certificate templates. This combination allows the client
computer running Windows XP Professional or Windows Server 2003 to
enroll user or computer certificates automatically.
How to Enable Autoenrollment Using Automatic Certificate Request

Settings

Introduction Automatic Certificate Request Settings provides automated installation of
computer certificates based on version 1 certificate templates for
Windows 2000, Windows XP, and Windows Server 2003 clients. The
certificates distributed by automatic certificate request settings are defined in
Group Policy and can be defined for the site, domain, or organizational unit.
Enabling automatic To enable automatic certificate request settings:
certificate request
settings 1. From Administrative Tools, open Active Directory Users and Computers.
2. In the console tree, right-click the domain or organizational unit where you
want to implement the ACRS Group Policy setting, and click Properties.
3. In the DomainName or OUName Properties dialog box, on the Group
Policy tab, either create a new Group Policy object (GPO), link an existing
GPO, or edit an existing GPO.
4. In the Group Policy Object Editor, expand Computer Configuration,
expand Windows Settings, expand Security Settings, expand Public Key
Policies, and then click Automatic Certificate Request Settings.
5. In the console tree, right-click Automatic Certificate Request Settings,
point to New, and the click Automatic Certificate Request.
6. In the Automatic Certificate Request Setup Wizard, click Next.
7. In the Certificate Template page, in the list of available certificate
templates, choose the version 1 certificate template that you wish to deploy
automatically, and then click Next.
8. In the Automatic Certificate Request Setup Wizard, click Finish.
Note The GPO must be linked to the organizational unit that contains the
target computer accounts. Automatic certificate request settings can only be
defined for computer accounts.
Enable Autoenrollment in the Version 2 Certificate Template

Introduction To enable autoenrollment, you must create a version 2 certificate template in
Active Directory. If you require autoenrollment for an existing version 1
certificate template, you must create a version 2 certificate template based on
the version 1 certificate template.
To enable autoenrollment in a certificate template, you must modify settings on
the Request Handling, Issuance Requirements, and Permissions tabs of the
Request Handling On the Request Handling tab of a version 2 certificate template, you can
choose whether to Prompt the user during enrollment. If you enable this
option, the user will be prompted to perform the automatic enrollment of a
certificate. Choosing the Enroll subject without requiring any user input
option will ensure that the certificate is automatically enrolled without user
intervention.
Note Never enable the Prompt the user during enrollment option for
certificates issued to computers or service accounts. Only enable this option for
certificates issued to users.
In some cases you do require user input for certificate autoenrollment. For
example, a smart card certificate requires user input so that the user is prompted
to insert the smart card in the smart card reader when required.
Important If more than one smart card CSP is made available on this tab, the
user may be prompted for every CSP when enrolling for this template. Users
with one smart card will have to cancel the prompts for the unavailable CSPs.
Issuance Requirements The Issuance Requirements tab allows you to enforce additional requirements
for certificate enrollment. For example, you can add a requirement for CA
certificate manager approval. Autoenrollment will check for pending certificate
requests, and complete the installation of the certificate when the CA certificate
manager issues the pending certificate.
If the certificate template requires that a registration authority (RA) certificate
sign the certificate request, autoenrollment will only be enabled if only a single
signature is required.
Permissions Use the Permissions tab to assign Read, Enroll, and Autoenroll permissions. To
autoenroll a certificate template, a user or computer must belong to a security
group that is assigned the Read, Enroll, and Autoenroll permissions. Only
groups that are assigned these three permissions are enabled for autoenrollment.
Note It is recommended that you assign the Read, Enroll, and Autoenroll
permissions to either global or universal groups. This is because the certificate
template objects are stored in the Configuration naming context of the forest.
How to Enable Autoenrollment Settings in Group Policy

Introduction When a certificate template is configured to enable autoenrollment, and the
certificate template is published to one or more enterprise CAs in the CA
hierarchy, you must configure Group Policy to enable Autoenrollment Settings.
The Autoenrollment Settings defines what certificates are to be deployed by
using autoenrollment.
Enabling To enable Autoenrollment Settings:
Autoenrollment Settings
1. From Administrative Tools, open Active Directory Users and Computers.
2. In the console tree, right-click the domain or organizational unit where you
want to implement the Autoenrollment Settings, and then click Properties.
Note For autoenrollment, the GPO must be linked to either the domain or
the organizational unit where the user or computer accounts exist.
3. In the DomainName or OUName Properties dialog box, on the Group

Policy tab, depending upon your requirement either create a new GPO, link
an existing GPO, or edit an existing GPO.
4. In the Group Policy Object Editor, in the console tree, expand Computer
Configuration for computer autoenrollment or expand User Configuration
for user autoenrollment.
5. In the console tree, expand Windows Settings, expand Security Settings,
and then click Public Key Policies.
6. In the details pane, double-click Autoenrollment Settings.
7. In the Autoenrollment Settings dialog box, ensure that the following

settings are selected:
• The Enroll certificates automatically button. This setting enables
autoenrollment of certificates for the organizational unit where the GPO
is linked.
• The Renew expired certificates, update pending certificates, and
remove revoked certificates check box. This setting enables certificate
autoenrollment for certificate renewal, issuance of pending certificates,
and removal of revoked certificates from the subject’s certificate store.
• The Update certificates that use certificate templates check box. This
setting enables autoenrollment for superseded certificate templates.
8. Click OK. Autoenrollment is now enabled for the organizational unit where
the GPO is linked.
Applying the Group The Autoenrollment Settings are applied the next time the GPO is applied to the
Policy settings user or computer. However:
! User autoenrollment is triggered when the user performs an interactive log
on and at Group Policy refresh intervals.
! Computer autoenrollment is triggered when the computer is restarted.
! Both user and computer Autoenrollment Settings are also applied at the
default GPO refresh intervals.
You can manually refresh the GPO settings at a client running Windows XP or
Windows Server 2003 by forcing Group Policy update. You can refresh the
GPO settings by running GPUpdate /force at the target workstation.
Note You can also force autoenrollment from the Certificates console by right-
clicking the Certificates – certificate store node in the console tree, pointing to
All Tasks, and then clicking Automatically Enroll Certificates.
Considerations for Implementing Autoenrollment

Introduction To select an autoenrollment method for automatically deploying certificates to
both users and computers in your domain, you should consider several factors,
such as the operating system and the type of certificate template.
Considerations Consider the following to determine whether to use automatic certificate
request settings or Autoenrollment Settings to automatically deploy certificates
in your network:
! Automatic certificate request settings is the only autoenrollment mechanism
that Windows 2000-based computers support for issuing computer
certificates. Windows 2000 does not support a mechanism for the automatic
enrollment of user certificates.
! You can use Autoenrollment Settings to automatically enroll both user and
computer certificates for clients running Windows XP and
Windows Server 2003. Clients running Windows 2000 do not support
Autoenrollment Settings.
! Automatic certificate request settings can only deploy certificates based on
version 1 certificate templates. Autoenrollment Settings only supports
certificates based on version 2 certificate templates.
! Both automatic certificate request settings and Autoenrollment Settings are
options to automatically deploy computer certificates to computers. The
chosen method will depend on the operating system of the client computers
and the version of the certificate template.
! Only Autoenrollment Settings supports the automatic renewal of certificates
when a certificate nears the end of its validity period.
! Only Autoenrollment Settings supports the automatic issuance of pending
certificate requests. Pending certificates are only supported in version 2
Lab A: Enrolling Certificates

! Determine which enrollment method to use for specific scenarios.
! Enroll certificates by using the Certificate Enrollment Wizard.
! Enroll certificates by using Autoenrollment.
Note This lab focuses on the concepts that are explained in this module and as
a result may not comply with Microsoft security recommendations. For
instance, two certificate templates that have the same purpose are configured
for autoenrollment, rather than one certificate template.

domain.
! Knowledge about certificate enrollment methods for standalone and
enterprise CAs.
! Knowledge about implementing automatic enrollment for user and
computer certificates.
Additional information For more information about enrolling certificates, read the white paper,
Certificate Autoenrollment in Windows Server 2003, under Additional
Estimated time to
complete this lab:
45 minutes
Exercise 1
Choosing an Enrollment Method
In this exercise, you will determine the best method to enroll certificates based
on the scenario that is provided.
Scenario You are the PKI administrator of your organization’s network. The organization
is in the process of deploying several projects that require certificates to be
issued by your PKI hierarchy.
The following projects are in the planning stage. You must recommend to
management what enrollment method to use to deploy the certificates.
! CA certificates. As shown in the following diagram, t company’s CA
hierarchy will consist of an offline root CA, an offline policy CA, three
enterprise subordinate CAs that are based on geographic region, and an
additional enterprise subordinate CA, that issues certificates to customers on
the extranet.
! IPSec with certificate based authentication. The Human Resources (HR)

department wants to protect all network transmissions to the HR data server
by using IPSec. The data server is running Windows Server 2003, Standard
Edition. The client computers run Windows 2000 Professional or
Windows XP Professional.
! EFS encryption. The Consulting department wants to implement EFS
encryption on consultants’ portable computers. These computers run
Windows XP Professional and are members of the organization’s Active
Directory domain.
! Web-based time tracking system. The Payroll department has created a

Web-based time tracking system on the corporate intranet. All employees in
the organization will be authenticated with the Web site by using certificate-
based authentication. The client computers in the company include
Windows ME, Windows NT® 4.0 Workstation, Windows 2000
Professional, and Windows XP Professional.
! Customer extranet Web site. Customers will connect to the extranet CA to
obtain certificates for authentication. Only certificates that the extranet CA
issues will be recognized by the Web site for customer authentication. The
customer computers can be running any operating system.
Questions 1. In the following table, indicate what enrollment methods are available for
each of the PKI-related projects.
Automatic
Certificate Certificate
Enrollment Request Settings
Scenario Web-based Wizard (ACRS) Autoenrollment
CA installation " # # #
IPSec certificate distribution # # " "
EFS encryption # # # "
Web-based time tracking system " " # "
Customer extranet Web site " # # #
2. When you install a subordinate CA to an offline CA, why is it necessary to

submit the certificate request to the offline CA in a PKCS #7 file format?
Offline CAs use a standalone CA policy. A standalone CA policy
processes certificate requests only by using Web-based enrollment
pages. The only way to submit a request to install a subordinate CA is
to submit the request in a PKCS #7 file format.
____________________________________________________________
____________________________________________________________
____________________________________________________________
3. What method of deploying IPSec certificates reduces the total cost of

ownership and installs the IPSec certificates on computers without user
intervention?
The IPSec certificate template is a version 1 certificate template. You
can distribute version 1 certificates by using ACRS in Group Policy.
ACRS provides automatic enrollment of version 1 computer-based
certificates to computers running Windows 2000, Windows XP, or
Windows Server 2003.
____________________________________________________________
____________________________________________________________
____________________________________________________________
4. To deploy EFS certificates to the consultants’ portable computers, you have

determined that autoenrollment will help distribute the EFS certificates.
Arrange the following tasks in the correct order for distributing the Basic
EFS certificates:
4 Enable Autoenrollment Settings in Group Policy on the domain.
1 Duplicate the Basic EFS certificate template.
3 Publish the new certificate template to the NorthAmerica CA, the
Europe CA, and the Asia CA.
2 Change the permissions on the new certificate template to grant the
consultants Read, Enroll, and Autoenroll permissions.
5. Can you use a version 2 certificate template to provide authentication for the
Web-based tracking system?
Yes. The Windows ME, Windows NT 4.0 and Windows 2000 client
computers must request the certificate by using Web-based enrollment.
Client computers running Windows XP clients can use autoenrollment.
____________________________________________________________
____________________________________________________________
____________________________________________________________
6. What enrollment methods can external customers use to acquire certificates

from the extranet CA in order to use the customer extranet Web site?
External client computers can use only Web-based enrollment to
acquire certificates from the extranet CA. Only forest members can use
the Certificate Enrollment Wizard.
____________________________________________________________
____________________________________________________________
____________________________________________________________
7. What can you do to increase the issuance security of the certificates that the
extranet CA issues to external customers?
Configure the version 2 certificate to require CA certificate manager
approval. This configuration sets the status of the certificate request to
Pending until a CA certificate manager approves the certificate request.
____________________________________________________________
____________________________________________________________
____________________________________________________________
Exercise 2
Enrolling Computer Certificates by Using the Certificate
Enrollment Wizard
In this exercise, you will enroll an IPSec certificate for your computer by using the Certificate
Enrollment Wizard in the Certificates console.
Scenario
To prevent unauthorized computers from connecting to network resources, your company
implements IPSec by using Authentication Headers (AH) to authenticate all network access. To
strengthen the authentication, you will deploy certificate-based authentication, which requires that
an IPSec certificate is installed on each computer.
1. Ensure that you are logged $ Log on to your computer by using the following information:
on to the domain as a CA • User name: CAadmin1
administrator.
domain)
publish the IPSEC Certification Authority.
certificate template. Once b. In the console tree, expand Certification Authority, expand
completed, close all open DomainCA, and then click Certificate Templates.
windows and log off.
c. Right-click Certificate Templates, click New, and then click
Certificate Template to Issue.
d. In the Enable Certificate Templates dialog box, click IPSEC and
then click OK.
e. In the details pane, verify that IPSEC appears.
f. Close the Certification Authority console.
g. Close all open windows, and then log off.
3. Ensure that you are logged $ Log on to your computer by using the following information:
on to the domain as a local • User name: Student1 (on the domain controller) or Student2 (on
administrator of your the member server)
computer.
• Domain: Domain
(continued)
4. In the Certificate a. On the desktop, double-click Certificate Management.

Management console, view b. In the console tree, expand Certificates (Local Computer)¸ expand
the certificates that are Personal, and then click Certificates.
currently issued to your
Not all computers have certificates installed in the local computer
computer account.
store at this point of the course. Therefore, the Certificates store
may not be available.
Machine certificates are already installed on which computer in your domain? Why?
Two certificates are installed on the domain controller. One certificate is the subordinate CA
certificate, which was installed when the domain controller was configured as a subordinate enterprise
CA. The other is a Domain Controller certificate, which Active Directory automatically issues to all
domain controllers.
5. Use the Certificate Request a. In the console tree, right-click the Personal folder, point to All Tasks,
Wizard to request an IPSec and then click Request New Certificate.
certificate with the friendly b. In the Certificate Request Wizard, click Next.
name IPSec Authentication
for your computer account. c. On the Certificate Types page, click IPSEC, and then click Next.
d. On the Certificate Friendly Name and Description page, in the
Friendly name box, type IPSec Authentication and then click Next.
e. On the Completing the Certificate Request Wizard page, click
Finish.
f. In the Certificate Request Wizard message box, click OK.
6. View the properties of the a. In the console tree, expand Certificate (Local Computer), expand
newly issued IPSec Personal, and then click Certificates.
certificate. b. In the details pane, scroll to the right and then double-click the
certificate that has the friendly name IPSec Authentication.
What is the intended purpose of the IPSec certificate?
It provides security for communication over the Internet.
6. (continued) c. Click OK.

(continued)
If you want to deploy IPSec certificates to 1,000 portable computers in your company, would the Certificate
Request Wizard be the best certificate enrollment method to use?
No. It would be necessary for a local administrator to run the Certificate Enrollment Wizard on each
of the 1,000 portable computers, which would take a long time.
To deploy IPSec certificates to Windows 2000 Professional and Windows XP Professional computers, what
autoenrollment method would you choose?
You must use ACRS to deploy certificates automatically in this case. The IPSec certificate template is a
version 1 certificate template. ACRS supports the automatic deployment of version 1 computer
certificates on computers running Windows 2000, Windows XP, or Windows Server 2003.
7. Close all open windows and a. Save any changes, and then close all open windows.
log off the network. b. Log off.
Exercise 3
Creating a User Certificate Template that Enables
Autoenrollment
In this exercise, you will create a certificate template based on the User certificate template, which
enables autoenrollment. You will deploy the new certificate template to user accounts by using
autoenrollment.
Scenario
To reduce the costs and effort of issuing user certificates, you must create a version 2 certificate
template that is based on the User certificate template.
1. In the Certificate Templates a. Log on to your computer with the following information:
console, create a new • User name: Template1 (on the domain controller) or Template2
certificate template named (on the member server)
AutoenrollComputer based
on the User Signature Only • Password: P@ssw0rd
certificate template. Define • Domain: Domain (where Domain is the NetBIOS name of your
the following attributes: Active Directory domain)
• Template display name: b. Click Start, click Run, type Certtmpl.msc and then click OK.
AutoComputer c. In the details pane, right-click User Signature Only, and then click
• Validity period: 2 years Duplicate Template.
d. In the Properties of New Template dialog box, on the General tab,
type the following information:
• Template display name: AutoComputer (where Computer is the
NetBIOS name of your computer)
• Validity period: 2 years
e. Click OK.
2. Enable the Prompt the user a. In the details pane, double-click AutoComputer.
during enrollment option in b. On the Request Handling tab, click Prompt the user during
the AutoComputer enrollment.
c. Click Apply.
(continued)
3. Modify the permissions for a. On the Security tab, in the Group or user names box, select Domain
the AutoComputer Users¸ and then click Remove.
certificate template: b. On the Security tab, click Add.
• Remove Domain Users c. In the Select Users, Computers, or Groups dialog box, in the Enter
from the discretionary the object names to select box, type Auto and then click Check
access control list Names.
(DACL).
• Add the AutoenrollUsers appears in the Enter the object names to select box,
AutoenrollUsers group and then click OK.
and assign it Read,
Enroll, and Autoenroll e. On the Security tab, assign the AutoenrollUsers group Read, Enroll
permissions. and Autoenroll permissions, and then click OK.
Exercise 4
Deploying the Certificates by Using Autoenrollment
In this exercise, you will deploy the AutoComputer certificates by using autoenrollment.
Scenario
To enable autoenrollment, you must configure the DomainCA to issue the AutoComputer
certificates, and then modify Group Policy to enable autoenrollment of certificates. Users in the
Module06 organizational unit must then log on to receive the certificates by using autoenrollment.
1. Log on to the domain with $ Log on to the domain by using the following credentials:
your administrative account. • Logon name: CAadmin2
domain)
2. Open the Certification a. On the Start menu, click Administrative Tools, and then click
Authority console and Certification Authority.
retarget the console to the b. In the Microsoft Certificate Services message box, click OK.
domain controller in your
domain. c. In the console tree, right-click Certification Authority, and then click
e. In the Select Certification Authority dialog box, click DomainCA,
and then click OK.
3. In the Certification a. In the console tree, expand DomainCA, and then click Certificate
Authority console, configure Templates.
DomainCA to issue b. Right-click Certificate Templates, click New, and then click
AutoComputer and Certificate Template to Issue.
AutoPartnerComputer and
then log off. c. In the Enable Certificate Templates dialog box, click AutoComputer
(where Computer is the NetBIOS name of your computer), press CTRL
and click AutoPartnerComputer (where PartnerComputer is the
NetBIOS name of your partner’s computer), and then click OK.
d. In the details pane, verify that the AutoComputer and
AutoPartnerComputer certificate templates appear.
f. Log off.
(continued)
Important: Perform this procedure on the domain controller in your domain.
4. Log on to the domain, with $ Log on to the domain by using the following credentials:
your domain administrative • Logon name: Student1
account.
your administrative account
• Domain: Domain
5. In Active Directory Users a. On the Start menu, click Administrative Tools, and then click Active
and Computers, create a new Directory Users and Computers.
GPO named b. In the console tree, expand Domain.msft, expand Labs, and then click
Autoenrollment and link Module06.
the GPO to the Module06
organizational unit. c. Right-click Module06, and then click Properties.
d. In the Module06 Properties dialog box, on the Group Policy tab,
In the Autoenrollment GPO, click New.
enable the following e. In the name box of the new Group Policy object, type Autoenrollment
autoenrollment options: and then click Edit.
• Enroll certificates f. In Group Policy Object Editor, expand User Configuration, expand
automatically Windows Settings, expand Security Settings, and then click Public
• Renew expired Key Policies.
certificates, update g. In the details pane, double-click Autoenrollment Settings.
pending certificates, and
remove revoked h. In the Autoenrollment Settings Properties dialog box, enable the
certificates following options:
• Update certificates that • Enroll certificates automatically

use certificate templates • Renew expired certificates, update pending certificates, and
Close all open windows and remove revoked certificates
log off the network when • Update certificates that use certificate templates
complete
i. Click OK.
j. Close Group Policy Object Editor.
k. In the Module06 Properties dialog box, click Close.
l. Close Active Directory Users and Computers.
m. Close all open windows, and then log off.
6. Log on as a member of the $ Log on to your computer by using the following information:
AutoenrollUsers group. • User name: Enroll1 (on the domain controller) or Enroll2 (on the
member server)
Active Directory domain)
(continued)
7. Force application of Group a. Open a command prompt.

Policy by running gpupdate b. At the command prompt, type gpupdate /force and then press ENTER.
/force.
Wait for the Certificate Enrollment ballon to appear in the system tray. It may take 90 seconds to appear.
8. Click the Certificate a. In the system tray, click the Certificate Enrollment balloon.
Enrollment balloon and start b. In the Certificate Enrollment dialog box, click Start.
the certificate enrollment
process.
Was there any additional user input required to enroll the two autoenrollment certificates?
No. The certificates did not require any additional user input for enrollment.
What type of certificates require user input for installation ?
Smart card certificates require user input. When prompted, the user must place the smart card in the
smart card reader. Additionally, certificates that implement strong private key protection require user
input to enroll and to access the private key.
9. Open the Certificates $ Click Start, click Run, type Certmgr.msc and then click OK.
console that is connected to
the current user
(Certmgr.msc).
10. Refresh the personal a. In the Certificates – Current User console, in the console tree, expand
certificates store in the Certificates – Current User, expand Personal, and then click
Certificates – Current User Certificates.
console. b. Scroll to the right to view the Certificate Template column.
.
(continued)
Does the certificate store contain both autoenrollment certificates?
Yes. The autoenrollment process installed the certificates based on the AutoComputer and
AutoPartnerComputer certificate templates.
11. Close all open windows and a. Close the Certificates – Current User console.
log off of the network. b. Close all open windows, and then log off.
Key Archival and
Recovery
Contents
Overview 1
Lesson: Introduction to Key Archival and
Recovery 2
Lesson: Implementing Manual Key Archival
and Recovery 13
Lesson: Implementing Automatic Key
Archival and Recovery 21
Multimedia: (Optional) How EFS Works 29
Lab A: Configuring Key Recovery 30
respective owners.
Module 7: Configuring Key Archival and Recovery iii
Instructor Notes
Presentation: This module explains the importance of creating a strategy for data and key
60 minutes recovery. Students learn how Microsoft® Windows® XP and
Windows Server™ 2003 enhance the capability of data protection and data
Lab: recovery.
45 minutes
! Describe the key archival and recovery process in a Windows Server 2003
public key infrastructure (PKI).
! Implement manual key archival and recovery.
! Implement automatic key archival and recovery.
! Read the white paper, Key Archival and Management in
! Complete the practice and the lab.
iv Module 7: Configuring Key Archival and Recovery

Lesson: Introduction to Key Archival and Recovery

This lesson introduces students to data and key recovery, the file formats that a
PKI uses to export and import certificates, and the key archival and recovery
process. Students will also learn about the guidelines for securing the key
archival and recovery process.
lesson.
Data Recovery and Key The Windows XP and Windows Server 2003 operating systems support key
Recovery recovery and data recovery. Tell students to use data recovery when they want
to recover data, but not when they want to access the individual private keys of
a user. Explain that they use key recovery when they want to recover data
without issuing new certificates. Ask students what method their organizations
would pursue in their PKI design. Also ask if the students’ organizations may
consider implementing both forms of recovery.
What Are Key Archival Focus on how private keys are lost. Many students will be unaware that actions,
and Key Recovery? such as deleting a user profile or reinstalling the operating system, will result in
the loss of private key material.
The Export and Request Do not spend a lot of time describing each export and request format. Consider
Formats running the Certificates MMC console (certmgr.msc) and showing where the
export format selection occurs. For request formats, consider connecting to the
Web Enrollment page of London (http://london/certsrv) and showing the
options for selecting the certificate request format.
The Key Recovery Focus on which role performs each task and the formats that are used for each
Process task. This information will help students understand when each format is used
in the recovery process.
Guidelines for Key Review each guideline and answer any questions about the guidelines.
Archival
Guidelines for Key Consider asking the students whether their organization’s security policy
Recovery requires separation of the certificate manager and key recovery agent (KRA)
roles. Remind the students that the KRA role is not a Common Criteria role, so
they can perform this dual assignment.
Lesson: Implementing Manual Key Archival and Recovery

This lesson describes how to archive a certificate’s private key manually. This
process is useful for version 1 certificate templates and version 2 certificate
templates that do not implement private key archival, but allow the export of
the certificate’s private key.
How to Export a Private Ensure that the students know that there is more than one way to export a
Key Manually certificate’s private key. The application that you choose directly affects the
export format of the private key.
Practice: Archiving a Provide the students with sufficient time to export their private key. If time
Private Key Manually permits, ask students to export their private key by using Internet Explorer.
Module 7: Configuring Key Archival and Recovery v
Guidelines for Archiving Review each guideline and answer any questions about the guidelines.
a Private Key Manually
How to Recover an Perform the steps of performing a private key recovery. If time permits, ask
Archived Private Key students to follow the steps and recover the private key that they archived in the
Manually previous practice Archiving a Private Key Manually.
Lesson: Implementing Automatic Key Archival and Recovery

In this lesson, students will learn about the steps that are required to
automatically archive encryption certificate private keys. The lesson describes
how to designate KRAs, archive keys on a CA, and define key archival in a
certificate template. The lesson ends with a discussion about using the Key
Recovery Tool from the Windows Server 2003 Resource Kit.
Steps for Performing Do not spend a lot of time on this page. It describes the overall process for
Automatic Archival of a performing automatic key archival, and each step in the procedure is discussed
Private Key in the topics that follow.
Steps for Designating Consider opening the Certificate Templates console (Certtmpl.msc) and
Key Recovery Agents reviewing the settings that are defined in the Key Recovery Agent certificate
template. Show the students that the certificate request is pending until a CA
certificate manager approves the request.
How to Enable Key Use the animation in the slide to describe the round-robin selection of KRAs.
Archival and Explain that the CA will choose two KRAs from the pool of four KRAs in the
Configuration Options example on the slide. Ask the students whether they would consider
for a CA implementing a round-robin selection of KRAs or if they would use all of the
defined KRAs for each archived private key on the CA.
Enable Key Archival in a Consider opening the Certificate Templates console (Certtmpl.msc) and
Certificate Template creating a version 2 certificate template based on the basic EFS certificate
template. When you discuss the modifications that are required to enable key
archival in the certificate template, show the related settings in the version 2
How to Recover an Focus on the tasks that each role in PKI management performs. Note that it is
Archived Private Key not necessary to separate the KRA and certificate manager roles, but discuss the
security implications if you do combine the two roles on your network.
Multimedia: (Optional) If students are not familiar with EFS, show this presentation before students
How ESF Works begin the lab. The presentation discusses how EFS encrypts and decrypts files.
If necessary, elaborate on the difference between symmetric and asymmetric
encryption.
The multimedia files are installed on the instructor computer. To open a
multimedia presentation, click the animation icon on the slide.
Lab A In the lab, students will perform a key recovery of an EFS encryption private
key. If students do not know how EFS encryption works, show them the How
EFS Works presentation.
vi Module 7: Configuring Key Archival and Recovery
Lab A: Configuring Key Recovery

In this lab, students will configure the automatic archival of EFS certificates. To
emulate the loss of a certificate, the user’s administrative account will delete the
EFS user’s profile folder, which requires that students recover the user’s EFS
encryption key.
! Enroll a KRA.
! Enable key recovery on an enterprise CA running Windows Server 2003,
Enterprise Edition.
! Create a certificate template that enables key recovery.
! Perform key recovery.
When performing this lab, students are first exposed to the Key Recovery Tool
from the Windows Server 2003 Resource Kit. Consider demonstrating the tool
before the start of the lab if your students think it would be helpful.
Lab Setup
Setup requirement 1 The labs in this module require the existence of a CA hierarchy with an offline
root CA and an enterprise subordinate CA. Complete all of Labs A, B, and C in
Module 3, “Creating a Certification Authority Hierarchy,” in Course 2821,
Designing and Managing a Windows Public Key Infrastructure.
Setup requirement 2 All of the procedures in Lab A assume that Common Criteria role separation is
enforced. Complete Lab A in Module 4, “Managing a Public Key
Infrastructure,” in Course 2821.
CertTmplAdmins global group. Complete Lab A in Module 5, “Configuring
Certificate Templates,” in Course 2821.
Setup requirement 4 The http://WebServer (where WebServer is the fully qualified domain name of
your domain controller) is configured as a member of the Local intranet zone in
the Default Domain Policy.
! Complete Lab B in Module 3, “Creating a Certification Authority
Hierarchy,” in Course 2821.
Module 7: Configuring Key Archival and Recovery vii
Lab Results
changes:
! The Key Recovery Agent certificate template is published on the enterprise
subordinate CA.
! KRA1 and KRA2 are designated as KRAs for the enterprise subordinate
CA.
! A version 2 certificate template, ArchiveEFS, based on the Basic EFS
certificate template, is created and published.
! The student has created an EFS protected file.
! The user’s ArchiveEFS certificate and private key are removed by deleting
the user’s profile.
! The user’s ArchiveEFS certificate and private key are recovered by using
the Key Recovery Tool (KRT.exec) from the Windows Server 2003
Resource Kit.
Module 7: Configuring Key Archival and Recovery 1
Overview

Introduction If you lose a public and private key pair (often referred to as a key pair), and
related certificates due to system failure or any other reason, it can be time
consuming and expensive to replace the keys and the data that the keys protect.
As part of your certificate management plan, create a strategy for data and key
recovery.
By using key archival and recovery, you can archive and recover the private
key portion of a key pair, in the event that a user loses her private key, or an
administrator must assume the role of a user to access or recover data.
! Describe the key archival and recovery process in a Microsoft®
! Implement manual key archival and recovery.
! Implement automatic key archival and recovery.
2 Module 7: Configuring Key Archival and Recovery
Lesson: Introduction to Key Archival and Recovery

Introduction Private key recovery does not recover any data. Instead, it enables a user to
access encrypted data by restoring the lost or damaged private key to the user’s
profile. This lesson introduces you to data and key recovery, the file formats
that a PKI uses to export and import certificates, and the key archival and
recovery process.
You will also learn about the best practices for securing the key archival and
recovery process in your organization.
! Determine what recovery method to use in your organization.
! Describe key archival and recovery.
! Select an export or request format for a given requirement.
! Describe the key recovery process.
! List the guidelines for implementing key archival.
! List the guidelines to use to implement a key recovery successfully.
Data Recovery and Key Recovery

Introduction Windows Server 2003 provides the following methods for the recovery of
encrypted data:
! Data recovery. Allows data recovery agents to access encrypted data
without accessing the private key material of the user that originally
encrypted the data.
! Key recovery. Allows key recovery agents (KRAs) to retrieve the original
certificate, private key, and public key that were used to encrypt the data
from the CA database.
The Microsoft Windows® XP and Windows Server 2003 family operating

systems support both data and key recovery for Encrypting File System (EFS)
encrypted files. The decision whether to use one or both methods depends upon
your business requirements and your organization’s security policy.
When to choose data Choose data recovery when:
recovery
! There is no existing PKI.
! It is not necessary for users to manage certificates or private keys.
! Your security policy does not allow for the recovery of private key material.
Disadvantages of data The disadvantages of data recovery are:

recovery
! Users cannot recover their own data. An administrative process recovers
user data.
! Data recovery is a manual process and occurs on a file-by-file basis.
! Users must re-enroll for new certificates because data recovery does not
recover users’ keys.
! It may be necessary for administrators to revoke previous EFS certificates if
the private key has been compromised.
! You cannot implement central management for standalone workstations or
workstations in environments that do not use the Active Directory®
directory service, because the EFS Recovery Agent policy can be centrally
enforced only by using Group Policy.
When to choose key Choose key recovery when:

recovery
! Your organization wants to limit certificate re-enrollment.
! You want to minimize the revocation of existing certificates.
! You want to recover encrypted data in applications other than EFS.
! You want to import the certificate and key pair on multiple computers.
Disadvantages of key The disadvantages of implementing key recovery are:

recovery
! User key recovery is a manual process that involves certificate managers,
KRAs, and users.
! Key recovery allows KRAs access to the private keys of users.
Note The option to archive private keys is blocked if the certificate purpose is
signature or signature and smart card logon.
What Are Key Archival and Key Recovery?

Introduction You use key archival and recovery to recover a lost or archived private key.
This process is implemented in two phases—key archival and key recovery—
and is also referred to as key escrow.
How can users lose a Users can lose their private key because of the following:
private key?
! Deletion of a user profile. A software cryptographic service provider (CSP)
encrypts and stores a private key by using the Data Protection API. The
encrypted private key is stored in the local file system and registry in the
user’s profile folder. Deleting the profile results in the loss of the private
key.
! Reinstallation of the operating system. When you reinstall the operating
system, you cannot access the previous user profiles, including the
encrypted key material that is stored in the user’s profile folder.
! Disk corruption. If the hard disk is corrupted such that users cannot log in or
access their profile, access to the user’s private keys is lost.
! Stolen computer. When a user’s computer is stolen, access to the private key
material in the profile is also lost.
Note The path in the user’s profile where the private key material is stored is
\Documents and Settings\UserName\Application Data\Microsoft\
SystemCertificates\My\Keys.
Key archival Use key archival when your security policy requires automated protection of
private keys. Key archival archives the user’s private key on the CA database so
that the private key may be recovered if the private key is lost or corrupted.
When an administrator enables key archival in a certificate template, users
provide their private key to the certification authority (CA) in a CMC
(Certificate Management Protocol) request format. CMC uses CMS
(Cryptographic Message Syntax), an RFC-based syntax for certificate requests.
The CA stores that private key in its database.
Note You can also add private keys to the CA database by importing PKCS
#12 (.pfx) or Microsoft Outlook® Exchange Security (.epf) file formats by using
the certutil–importkms command.
Key recovery Use key recovery after the key archival process has stored the subject’s private
key in the CA database. During the key recovery process, the certificate
manager retrieves an encrypted blob file that contains the certificate and private
key from the CA database. A KRA then decrypts the private key from the
encrypted file and returns the certificate and private key to the user.
Note Key recovery allows a trusted agent to access a user’s private keys. For
this reason, use key recovery only if your organization permits an administrator
to have access to another user’s private key.
The Export and Request Formats

Introduction A PKI uses several file formats to export and import certificates, certificate
chains, and private keys. You must select the correct export format, which
depends upon the business needs for exporting and importing the certificate.
Export formats When a user exports a certificate by using the Certificates console, the
Certification Authority console, Certutil.exe, or Internet Explorer, the following
export formats are available:
! PKCS #7 - Cryptographic Message Syntax Standard. Describes general
syntax for cryptographic data, such as digital signatures and digital
envelopes. Use the PKCS #7 file format for the following purposes:
• To export certificates without the associated private key.
• To download certificate chains from a CA.
! PCKCS #12 - Personal Information Exchange Syntax Standard. Specifies a
portable format for storing or transporting a user’s private keys and
certificates. Choose this file format when you want to export a certificate
and its associated private key. Because the private key is included in the
export, the PKCS #12 file is protected with a password.
Request formats The request format defines what information is included in the certificate
request. When a computer, user, or service requests a certificate from a
Windows Server 2003 CA, the following request formats are available:
! PKCS #10 - Certification Request Standard. Describes the syntax of a
request for the certification of a public key, a name, and a set of attributes.
When a user requests a certificate from a CA by saving the request in a file,
the PKCS #10 file format stores the request information and the public key
of the key pair. The certificate requestor than submits the PKCS #10
certificate request file to an offline CA to complete the certificate request.
! CMC – Certificate Management protocol using CMS. Provides an envelope
for a PKCS #10 request. The format also allows the inclusion of more
attributes, such as qualified subordination constraints and extensions or the
signing of a certificate request.
The Key Recovery Process

Introduction You use the key recovery process to recover an archived private key from the
CA database. The process involves both the certificate manager and the KRA
roles. The key recovery process begins when a user or computer’s private key is
lost or corrupted.
The key recovery The key recovery process consists of the following steps:
process
1. The recovery process begins after the user or computer can no longer access
the private key material.
2. The user, or a certificate manager for the CA that issued the certificate,
determines the serial number of the certificate. The serial number uniquely
identifies an issued certificate.
Note You can recover a certificate’s private key by presenting only the
subject name of the certificate, but if more than one certificate with the
same subject name exists in the CA database, only the serial number can
differentiate the certificates.
3. A certificate manager extracts the encrypted private key and certificate from
the CA database. The export format of the private key and certificate is a
PKCS #7 file, which is encrypted by using the public key of the Key
Recovery Agent certificate. The certificate manager can use either the Key
Recovery Tool (krt.exe) or certutil –getkey to extract the PKCS #7 file
from the CA database.
Note The encrypted PKCS # 7 files in the database, referred to as blobs,

contain the issuer name and serial number of each Key Recovery Agent
certificate for KRA identification purposes during recovery.
4. The certificate manager transfers the PKCS #7 file to the KRA. Because the
PKCS #7 file is encrypted so that only defined KRA can recover the
encrypted certificate and private key, no additional security is required for
the transfer.
5. The KRA recovers the private key and certificate from the encrypted PKCS
#7 file at a secure workstation, also known as the recovery workstation. The
extraction is performed by using certutil –recoverkey or the Key Recovery
Tool. The private key and certificate are stored in a PKCS #12 file and are
protected with a KRA-assigned password.
6. The KRA then supplies the PKCS #12 file to the user, who provides the
KRA-assigned password and imports the certificate and private key into his
certificate store by using the Certificate Import Wizard.
Note The KRA can also hold the role of the certificate manager for a user. The
organization’s security policy determines whether to combine the KRA and a
certificate manager into one role or keep them as separate roles.
Guidelines for Key Archival

Introduction Archiving private keys in the CA database can sometimes lead to the
compromise of private keys. An unauthorized person can acquire a private key
and impersonate the original subject of the certificate that is associated with the
private key.
Guidelines for key When you design key archival for your organization, secure the key archival
archival process by ensuring that you carefully monitor all operations of key archival.
Consider the following guidelines:
! Do not archive private keys for certificates that have high value, are
sensitive, or that secure high-value transactions—except under extreme
circumstances. For example, do not enable key archival for Key Recovery
Agent certificates because if an unauthorized person accesses the private
key, he may be able to recover other private keys that are archived in the
CA database.
! Never archive private keys that are used for digital signing. It would cause
non-repudiation problems. If the certificate purpose is designated as
signature or signature and smartcard logon, the certificate template blocks
key archival.
! Limit the number of CAs that archive keys for a certificate purpose. Do not
archive keys for users at many CAs in the CA hierarchy because recovery
operations then become confusing.
! Store the Key Recovery Agent certificate and private key on a smart card.
This way, you ensure that the private key that is associated with the Key
Recovery Agent certificate is not stored on the local disk subsystem. The
smart card ensures that the KRA has access to the smart card and knows the
smart card’s PIN to perform key recovery.
Guidelines for Key Recovery

Introduction The key recovery process retrieves the archived private key from the CA
database and allows the holder of the PKCS #12 file to import the certificate
and private key. Remember that whoever has the private key that is associated
with the subject of a certificate is the subject for all intents and purposes.
Guidelines for key When you develop your organization’s key recovery process, consider these
recovery guidelines:
! Enforce role separation of certificate managers and KRAs. This way, you
ensure that one individual cannot extract and recover the private key from
the CA database, which adds a level of operational security to the key
recovery process.
! Revoke the certificate that is associated with a private key immediately after
you recover it if the private key may be compromised. This way, a user
cannot use the key pair for future encryption or digital signing purposes.
The private key can still be used to decrypt previously encrypted files, but
further attempts to encrypt files by using the public key will fail during the
certificate validation process.
! Remove Key Recovery Agent certificates and private keys from the
associated user’s profile. You can protect the certificate and private key by
exporting them from the KRA’s user profile and only performing key
recovery at a secured workstation.
! Develop a secure method for transporting the private keys to the original
owner. After the KRA creates the PKCS #12 file, you must securely transfer
the file to the original owner of the private key. Then destroy the PKCS #12
file to prevent the certificate and private key from being imported in the
future.
Lesson: Implementing Manual Key Archival and Recovery

Introduction Depending upon the type of certificate templates that you deploy, you can
implement manual or automatic key archival and recovery. If you deploy
certificate templates based on version 1 or version 2 certificate templates that
do not implement key archival, you can archive only the private keys by
implementing manual key archival and recovery. In this lesson, you will learn
how to implement manual key archival and recovery.
! Describe the process of manually archiving a private key.
! List the guidelines for manually archiving a private key.
How to Export a Private Key Manually

Introduction You can perform manual key archival for any certificates that are based on
certificate templates on which a certificate manager has enabled the Allow
private key to be exported option. Users can export their private keys to a
PKCS #12 file by using the Certificates console, or to an Outlook Key Export
format by using Outlook. Both methods allow the certificate and private key to
be stored in a password-protected file that you can use to recover the private
key.
Exporting keys and To manually export a certificate and its associated private key:
certificates
1. Choose the export method. The method that you use depends on the
certificate template that the certificate is based on. If the certificate contains
the Secure Email application policy or Extended Key Usage object identifier
(OID), you can use either Outlook or the Certificates console. If the
certificate does not contain the Secure Email OID, you must use the
Certificates console.
Note You can also use Internet Explorer to export a certificate and its
associated private key. This method is useful for workstations running
Windows operating systems earlier than Windows 2000 that do not include
the Certificates console.
2. Choose the export format. This decision is based on the tool that you use to
archive the private key. If you use the Certificates console, you can export
the file to a PKCS #12 file. If you use Outlook, you can export the file to an
Exchange Security file.
Note You can export X.509v1 certificates only to the Outlook Security file
format. For X.590v3 certificates, you can use either an Outlook Security
files or a PKCS#12 file.
When you export a certificate and its private keys, the following options are
available:
• Include all certificates in the certification path if possible. This option
includes the entire certificate chain of the exported certificate. This
allows the import to include all certificates in the certificate chain up to
the root certificate.
• Enable strong protection (requires IE 5.0, Windows NT 4.0, SP4 or
later). This option requires a password to access the private key that is
stored in the PKCS#12 file. Provide this password to the CA
administrators so they can import the private key to the CA database.
• Delete the private key if the export is successful. This option deletes the
private key that is associated with the certificate from the certificate
store. You must use this option when you export a certificate and private
key so that the private key is removed from the user’s profile.
Important The private key is deleted only if the export is completed

successfully. If the export is not successful, the private key is not deleted.
3. Store the exported file in a secure location. After the certificate and private
key are exported, store the export file in a physically secure location. Copy
the export file to a CD-ROM and then store the CD-ROM in a safe location.
In addition, import the export file to the CA database by using the certutil –
importkms <export file> command.
Practice: Archiving a Private Key Manually

Introduction In this practice, you will export a certificate and private key from your user
store to a PKCS #12 file by using the Certificates console.
Exporting keys from To export the certificate and private key:

Certificates console
1. Log on as Student1 or Student2.
2. On the desktop, open the Certificate Management console.
3. In the console tree, expand Certificates - Current User, expand Personal,
and then click Certificates.
4. Right-click the certificate that you want to export, click All Tasks, and then
click Export.
5. In the Certificate Export Wizard, click Next.
6. On the Export Private Key page, click Yes, export the private key, and
then click Next.
7. On the Export File Format page, select Personal Information Exchange-
PKCS#12 (.PFX), and then click the following options:
• Include all certificates in the certification path if possible.
• Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above).
8. Click Next.
9. On the Password page, in the Password and Confirm password boxes,
type P@ssw0rd and then click Next.
10. In the File to Export dialog box, in the File Name box, type
C:\temp\privexport and then click Next.
Note Create the C:\temp folder if it does not exist on your computer.
11. On the Completing the Certificate Export Wizard page, click Finish.
12. In the Certificate Export Wizard message box, click OK.
Guidelines for Archiving a Private Key Manually

Introduction You can manually archive private keys only if the certificate template allows
private key to be exported. If it does not, the Certificate Export Wizard prevents
the inclusion of the private key in the export file.
Guidelines When manually archiving private keys, consider the following guidelines:
! Save the export file with strong private key protection. The strong private
key protection enables a password on the export file. Only users that know
the private key protection password can import the private key from the
export file to the certificate store.
! Perform data recovery or key recovery on secure workstations and remove
the private key from the user’s profile. By performing the key recovery on
secure workstations, you ensure that private key material is not left on a
user’s computer. After you complete the recovery procedure, remove the
certificate and private key from the recovery workstation hard disk.
! Physically secure the export file. The export file, a PKCS #12 or EPF file,
contains the certificate and private key. Store the file in a physically secure
location to prevent an attacker from gaining access to the export file. Do not
store the export file on a network share or on the local disk system. Consider
writing the export file to a nonvolatile media, such as a CD-ROM, and
storing the media in a safe.
! Make private key export unavailable for high-value or sensitive certificates.
You can configure a certificate template to block private key export. This
way, another user or computer cannot export a user or computer’s private
key. For example, a certificate template administrator should disable private
key export for the private key of a certificate that is used to sign high-value
purchase orders on an e-commerce site. Preventing private key export
ensures that an attacker cannot acquire the private key and use it to forge a
purchase order.
How to Recover an Archived Private Key Manually

Introduction You can perform a manual recovery of a private key that is archived in a PKCS
#12 file.
Procedure To recover an archived private key:
1. Obtain the private key archive file. The file can be either a PKCS# 12 or
EPF format.
2. In the Certificate Import Wizard, click Next.
3. On the File to Import page, in the File name box, verify the private key
archive file name, and then click Next.
4. On the Password page, in the Password box, type the password that is used
to protect the private key archive file.
5. On the Password page, choose from the following options:
• Enable strong private key protection. You will be prompted every
time the private key is used by an application if you enable this
option. Requires a password every time an application attempts to
access the private key.
• Mark this key as exportable. This will allow you back up or
transport your keys at a later time. Allows you to export the private
key at a later date.
6. Click Next.
7. In the Certificate Store page, click Automatically select the certificate
store based on the type of certificate, and then click Next.
Tip Do not select Place all certificates in the following store if the export
file contains all certificates in the certificate chain. Choosing to place all
certificates in a specific store results in the CA certificates being placed in
your personal store.
8. On the Completing the Certificate Import Wizard page, click Finish.

9. Verify that the certificate and private key are successfully imported.
Lesson: Implementing Automatic Key Archival and

Recovery

Introduction To implement automatic key archival and recovery, you must designate KRAs,
enable a CA for key archival and configuration, enable key archival in a
certificate template, validate an archived private key, and recover an archived
private key. Automatic key archival and recovery removes the responsibility of
exporting certificates and private keys from the user and automates the process
so that user intervention is not required.
! List the steps for performing automatic archival of a private key.
! List the steps for designating KRAs.
! Enable for key archival and configuration options for a CA.
! Enable key archival in a certificate template.
! Recover an archived private key.
Steps for Performing Automatic Archival of a Private Key

Introduction Windows Server 2003 implements key archival and recovery, also referred to as
key escrow, in a Windows Server 2003 enterprise CA. Key escrow requires that
certificate templates enable automatic private key archiving so that the private
key may be recovered from the CA database in the event of the corruption or
loss of the private key. Automatic key archival ensures that the private keys are
archived without user intervention. It stores the archived material in a central
database, which eliminates the need to collect and securely store individual
export files that contain the private key material.
Note Key escrow is only supported on enterprise CAs running

Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter
Edition.
Steps To enable automatic archival:

1. Designate key recovery agents. Designate all user accounts that will act as
KRAs by assigning the user (or a group in which the user has membership)
the Enroll permission for the Key Recovery Agent certificate and by having
the user obtain a Key Recovery Agent certificate. This certificate allows the
user to recover private keys that are archived in the CA database that are
encrypted by using her Key Recovery Agent public key.
2. Enable the CA for key archival and configure options. Key archival is
enabled on a CA-by-CA basis. On each CA that you want to archive private
keys, you must designate the certificates of the KRAs and how many KRAs
can recover each archived private key.
3. Enable certificate templates for key archival. To enable key archival,
configure the certificate template to enable the Archive subject’s
encryption private key check box. This way, the private key is submitted
in a certificate request that is based in that certificate template.
Steps for Designating Key Recovery Agents

Introduction The first step in enabling automatic archival of private keys is to designate
which user accounts will function as KRAs. The KRA role can extract an
encrypted private key from the CA database. The process of designating a KRA
involves several CA management roles.
Steps for designating a To designate a KRA:
KRA
1. Define permissions for the Key Recovery Agent certificate template. Assign
Read and Enroll permissions for the Key Recovery Agent certificate
template to a global or universal group. Restrict group membership to only
approved KRAs.
2. Publish the Key Recovery Agent certificate template on an enterprise CA in
the organization. A CA administrator performs this step. Because the Key
Recovery Agent certificate template is a version 2 certificate template, the
enterprise CA must be running Windows Server 2003, Enterprise Edition or
Windows Server 2003, Datacenter Edition.
3. Issue Key Recovery Agent certificates to the approved KRAs. The KRAs
must request a Key Recovery Agent certificate from the CA on which the
CA administrator published the Key Recovery Agent certificate template.
Note You must use Web Enrollment Pages when enrolling the Key
Recovery Agent certificate. Web Enrollment Pages saves a cookie that
refers to the pending certificate request, thereby allowing a direct link to the
certificate request after the certificate is released from its pending state.
4. Issue the pending certificate. A certificate manager must perform this step.
The Key Recovery Agent certificate template requires that a certificate
manager review the certificate request before he issues the pending
certificate. After the certificate is issued, the requesting KRA must install
the certificate by using Web Enrollment Pages on the enterprise CA.
How to Enable a Key Archival and Configuration Options for a CA

Introduction To implement key archival, you must designate one or more holders of Key
Recovery Agent certificates as KRAs for the CA. Designate them by adding
one or more Key Recovery Agent certificates that are published in Active
Directory to the properties of the CA. When Certificate Services starts, the CA
validates each designated Key Recovery Agent certificate, and prohibits key
recovery if a certificate fails the validity checks.
Note If role separation is enforced on a CA, only a CA administrator can add

or remove KRAs in the properties of the CA.
Procedure for enabling a To enable a CA for key archival and configuration options:
CA for key archival and
configuration options 1. Log on to the CA as a user who is assigned the CA administrator role.
2. In Administrative Tools, open the Certification Authority console.
3. In the console tree, right-click CAName (where CAName is the logical name
of your CA), and then click Properties.
4. In the CAName Properties dialog box, on the Recovery Agents tab, click
Archive the key, and then click Add.
5. In the Key Recovery Agent Selection dialog box, add one or more of the
Key Recovery Agent certificates published in Active Directory, and then
click OK.
6. On the Recovery Agents tab, in the Number of recovery agents to use
box, type a number between 1 and the number of Key Recovery Agent
certificates added, and then click OK.
7. Restart Certificate Services.
Designating the number When you designate the number of KRAs, you can designate between one and
of KRAs the number of KRAs that are designated at a CA.
! If you choose a number equal to the total number of Key Recovery Agent
certificates that are designated on the CA, the holder of the Key Recovery
Agent certificate’s private key can recover all private keys that are archived
in the CA database.
! If you choose a number less than the total number of Key Recovery Agent
certificates that are designated on the CA, the CA implements a round-robin
selection method to choose the KRAs for each archived private key that is
stored in the CA database. The selection results in the random designation
of KRAs.
Note The random selection of KRAs requires that a certificate manager

determine which KRAs can recover a specific private key that is archived in the
CA database.
Enable Key Archival in a Certificate Template

Introduction To archive private keys for specific certificates, you must configure the
certificate templates to enable key archival and to be published to a CA that is
enabled for key archival.
Enabling archival in a To enable key archival for a certificate template, you must perform the
certificate template following modifications to the certificate template:
! Ensure that the purpose of the certificate template is encryption or signature
and encryption. A Windows Server 2003 CA prohibits the archival of a key
whose purpose is signature or signature and smart card logon.
! Allow the private key to be exported. The private key must be marked as
exportable; otherwise the enrollment process cannot send the private key to
the issuing CA during a certificate request.
Note Alternatively, the CSP must support the crypt_ archivable flag. Every
default Microsoft CSP that is included in the operating system supports this
flag.
! Ensure that the CSP that the certificate template uses permits key export. If
the CSP does not allow key export, the private key cannot be sent to the
issuing CA during the certificate enrollment process. For example, a smart
card CSP prohibits the private key from being exported from the smart card
during the smart card enrollment process.
! Select the Archive subject’s encryption private key check box. This
setting enforces that all certificates based on this certificate template archive
the private key, if the certificates are issued by a CA that is enabled for key
archival.
Note The CA that issues the certificates that are based on the archive-enabled
certificate template must be enabled for key archival. If the CA does not have at
least one KRA defined in its properties, the archival of the private key fails.
How to Recover an Archived Private Key

Introduction If you enforce role separation for your organization, the process of recovering
an archived private key is split between the management roles on the CA. The
certificate manager and the KRA must work together to recover the private key.
Certificate manager To extract the encrypted private key from the CA database, the certificate
tasks manager performs the following steps:
1. Identifies the certificate in the CA database. To identify the certificate to be
recovered, the certificate manager must know one of the following:
• The serial number of the certificate
• The Common Name (CN) of the user that requested the certificate
• The User Principal Name (UPN) of the user stored in the certificate’s
subject or alternate subject name
• The public key hash of the certificate
Note The certificate manager can determine these certificate attributes by

examining the certificate in the Certification Authority console.
2. Determines the KRA for the archived private key. After uniquely identifying
the certificate, the certificate manager must determine one or more KRAs
who can recover the certificate’s private key from the CA database. The
certificate manager can use the Key Recovery Tool from the
Windows Server 2003 Resource Kit. The tool identifies the Key Recovery
Agent certificate that is associated with the private key that can decrypt the
archived private key.
3. Extracts the PKCS #7 blob. To extract the archived private key from the CA
database, the certificate manager can use the Key Recovery Tool or the
certutil -getkey <serial number> <outputblob> command. The tool or
command extracts the archived private key for the certificate with the
matching serial number into a PKCS #7 file. The output blob is formatted as
an encrypted PKCS #7 structure that contains the private key encrypted with
the KRA’s public key, the Key Recovery Agent certificates, and the entire
certificate chain.
Note The certutil –getkey command also identifies the KRA for the archived
private key in its output.
KRA tasks When the archived private key is extracted to a PKCS #7 blob, the identified
KRA must recover the private key. The KRA has both the private key that can
decrypt the archived private key and the archived private key that was
encrypted with the KRA’s public key. In other words, only the KRA that holds
the private key that is associated with the public key that was used to encrypt
the archived private key can recover the archived private key. To recover the
archived private key:
1. Recover the archived private key from the encrypted PKCS #7 blob. The
KRA can use the Key Recovery Tool or the certutil -recoverkey
outputblob user.pfx command to recover the private key. These processes
use the KRA’s private key to recover the encrypted private key and store the
recovered private key with its certificate chain in a PKCS #12 file named
user.pfx. The PKCS #12 file is protected with a password that was provided
during the command processing.
Note An event log message with event ID 787 is generated when a private
key is recovered from the database. This message indicates that Certificate
Services recovered an archived private key.
2. Hand deliver the PKCS #12 to the user or place it on a network share that is
accessible only by that user. Do not put the PKCS #12 file on a public
network share or send it in an e-mail message it to the user. Inform the user
of the password that is required to import the private key and certificate
chain that is stored in the PKCS #12 file.
User tasks After receiving the PKCS #12 file from the KRA, the user must import the
private key and the associated certificate chain into her personal certificate. The
user double-clicks the PKCS #12 file and runs the Certificate Import Wizard.
When proceeding through the wizard, the user must provide the password that
is used to protect the PKCS #12 file.
Multimedia: (Optional) How EFS Works

File Location To view the How EFS Works presentation, open the Web page on the Student
Materials compact disc, click Multimedia, and then click the title of the
presentation.
Key points This animation shows how EFS uses both symmetric and asymmetric
encryption to encrypt and decrypt data in Windows 2000 and Windows XP.
Additional reading For more information about EFS, see the white paper, Encrypting File System
in Windows XP and Windows Server 2003, under Additional Reading on the
Web page on the Student Materials CD.
Lab A: Configuring Key Recovery

! Enroll a KRA.
! Enable key recovery on an enterprise CA running Windows Server 2003,
Enterprise Edition.
! Create a certificate template that enables key recovery.
! Perform key recovery.
comply with Microsoft security recommendations. For instance, this lab does
not export the Key Recovery Agent certificates and private keys to PKCS #12
files. Nor does the lab remove the KRA user accounts from Active Directory or
revoke the EFS user certificates after KRA recovers the private keys from the
CA database.

domain.
domain name of your domain controller) as a member of the Local intranet
! Knowledge about certificate enrollment methods for standalone and
enterprise CAs.
! Knowledge about implementing automatic enrollment for user and
computer certificates.
! Knowledge about key archival and recovery in a Windows Server 2003
environment.
! Knowledge about EFS encryption.
Additional information For more information about configuring key recovery, see the white paper, Key
Archival and Management in Windows Server 2003, under Additional Reading
Estimated time to
complete this lab:
45 minutes
Exercise 1
Publishing the Key Recovery Agent Certificate Template
In this exercise, you will configure the enterprise CA in your domain to issue Key Recovery Agent
certificates. To enforce role separation, you will issue these certificates to users that do not hold
Common Criteria management roles.
Scenario
Your organization wants the ability to recover private keys that are used for EFS encryption in the
event that the private keys are corrupted or deleted accidentally.
1. Log on using your " Log on to the domain by using the following credentials:
certificate template • User name: Template2
administration account.
domain)
2. In the Certificate Templates a. Click Start, click Run, type Certtmpl.msc and then click OK.
console, view the Issuance b. In the Certificate Templates dialog box, click OK.
Requirement properties of
the Key Recovery Agent c. In the details pane, double-click Key Recovery Agent.
certificate template. d. In the Key Recovery Agent Properties dialog box, click the Issuance
Requirements tab.
What special requirements are implemented for certificate enrollment of the Key Recovery Agent
certificates?
All certificate requests must be approved by a CA certificate manager.
3. Take ownership of the Key a. In the Key Recovery Agent Properties dialog box, on the Security
Recovery Agent certificate tab, click Advanced.
template. b. In the Advanced Security Settings for
LDAP://ForestName/KeyRecoveryAgent (where ForestName is the
DNS name of your forest), on the Owner tab, click Template2, and
then click Apply.
c. Click OK.
(continued)
4. Modify the security a. On the Security tab, click Add.

properties of the Key b. In the Select Users, Computers, or Groups dialog box, in the Enter
Recovery Agent certificate the object names to select box, type KRAs and then click Check
template to assign the KRAs Names.
global group Read and
Enroll permissions. c. In the Select Users, Computers, or Groups dialog box, click OK.
d. Assign the KRAs group Read and Enroll permissions, and then click
OK.
5. Log on using your domain " Log on to your computer with the following credentials:
administration account and • User name: CAadmin1
password.
• Domain: Domain
6. Publish the Key Recovery a. On the Start menu, click Administrative Tools, and then click
Agent certificate template Certification Authority.
on DomainCA. b. In the console tree, expand DomainCA (where Domain is the NetBIOS
name of your domain), and then click Certificate Templates.
d. In the Enable Certificate Templates dialog box, select Key Recovery
Agent, and then click OK.
e. In the details pane, verify that the Key Recovery Agent certificate
template appears.
g. Log off the network.
Exercise 2
Enrolling the Key Recovery Agent certificates
In this exercise, you will log on by using a non-administrative account that is a member of the
KRAs global group, and then you will request a Key Recovery Agent certificate.
Scenario
Your organization has decided to implement non-administrator accounts as the KRAs for your
organization. The KRAs must now enroll the modified Key Recovery Agent certificate templates.
1. Log on to the network as a " Log on to the domain by using the following credentials:
member of the KRAs group. • User name: KRA1 (on the domain controller) or KRA2 (on the
member server)
domain).
2. Request a Key Recovery a. Open Internet Explorer.

Agent certificate by using b. If the Internet Explorer dialog box appears, click In the future, do
Web-based enrollment, and not show this message, and then click OK.
c. In Internet Explorer, open the URL http://WebServer/certsrv (where
controller).
e. On the Request a Certificate page, click advanced certificate
request.
f. On the Advanced Certificate Request page, click Create and submit
a request to this CA.
g. On the Advanced Certificate Request page, in the Certificate
Template drop-down list, select Key Recovery Agent.
h. On the Advanced Certificate Request page, in the Friendly Name
box, type Key Recovery Agent and then click Submit.
i. In the Potential Scripting Violation dialog box, click Yes to allow the
Web site to request a certificate on your behalf.
j. On the Certificate Pending page, record the certificate request ID in
the following space:
• Request ID: _______________________
k. Close Internet Explorer.
(continued)
Why does the CA not issue the certificate immediately?
The certificate is set to a pending status until a CA certificate manager issues the certificate.
Why is it preferable to request a Key Recovery Agent certificate by using Web-based enrollment?
If the certificate is set to a pending status, the Web-based enrollment method uses cookies, which
enable you to check the status of the pending certificate request.
Wait at this point until your partner completes the initial enrollment process for the Key Recovery Agent
certificate.
3. Issue the Pending Key a. On the Start menu, click Administrative Tools, right-click
Recovery Agent certificate Certification Authority, and then click Run as.
requests, and then log off b. In the Run As dialog box, click The following user, and then provide
the network. the following credentials:
• User name: Domain\CertAdmin1 (where Domain is the NetBIOS
name of your domain)
c. In the Run As dialog box, click OK.
d. In the Certification Authority console, expand DomainCA, and then
click Pending Requests.
e. In the details pane, select all pending certificate requests.
f. Right-click the pending certificate requests, point to All Tasks, and
then click Issue.
g. Close the Certification Authority console.
(continued)

http://WebServer/certsrv and b. In Internet Explorer, open the URL http://WebServer/certsrv (where
click the following: WebServer is the fully qualified domain name of your domain
• View the status of a controller).
pending certificate c. On the Welcome page, click View the status of a pending certificate
request request.
• Key Recovery Agent d. On the View the Status of a Pending Certificate Request page, click
Certificate Key Recovery Agent Certificate (Date and Time).
• Install this Certificate e. On the Certificate Issued page, click Install this certificate.
f. In the Potential Scripting Violation dialog box, click Yes to accept
that the Web site adds a certificate to your computer.
g. Ensure that the Certificate Installed page appears, which indicates that
the certificate has been installed successfully.
h. Close Internet Explorer.
i. Close all open windows and log off the network.
Exercise 3
Enabling Key Recovery on the Enterprise CA
In this exercise, you will enable key recovery on the enterprise CA by adding the Key Recovery
Agent certificates that are issued to the KRAs in your forest.
Scenario
You must designate the certificate for each KRA to enable key recovery on the enterprise CA.
1. Log on to the network using " Log on to the domain by using the following credentials:
your CA administrator • Logon name: CAadmin1
account.
domain)
Authority console and Certification Authority.
perform the following b. In the console tree, right-click DomainCA, and then click Properties.
actions:
c. In the DomainCA Properties dialog box, on the Recovery Agents tab,
• Define KRA1 and click Archive the key.
KRA2 as key recovery
agents. d. In the Number of recovery agents to use box, type 2
• Define the number of e. In the DomainCA Properties dialog box, on the Recovery Agents tab,
recovery agents to use click Add.
as 2. f. In the Key Recovery Agent Selection dialog box, select the Key
Recovery Agent certificate issued to KRA1, and then click OK.
g. In the DomainCA Properties dialog box, on the Recovery Agents tab,
click Add.
h. In the Key Recovery Agent Selection dialog box, select the Key
Recovery Agent certificate issued to KRA2, and then click OK.
i. In the DomainCA Properties dialog box, click OK.
j. In the Certification Authority dialog box, click Yes to restart
Certificate Services.
3. Minimize the Certification " Minimize the Certification Authority console.

Authority console.
Exercise 4
Creating an Archive-enabled Certificate Template
In this exercise, you will create a new certificate template based on the Basic EFS certificate
template that enables key archival.
Scenario
Your company wants to deploy EFS to encrypt critical data files. Rather than implement an EFS
Recovery Agent, you will archive the EFS encryption private keys on an enterprise CA on a
computer running Windows Server 2003, Enterprise Edition.
1. Ensure that you are logged " Ensure that you are logged on to the domain by using the following
on using your domain credentials:
administrative account. • Logon name: Template2
2. Open the Certificate a. On the Start menu, click Run, type Certtmpl.msc and then click OK.
Management console and b. If the Certificate Templates message box appears, click OK.
create a new certificate
template named c. In the details pane, right-click Basic EFS, and then click Duplicate
ArchiveEFS, based on the Template.
Basic EFS certificate d. In the Properties of New Template dialog box, in the Template
template. display name box, type ArchiveEFS and then click OK.
3. In the ArchiveEFS a. In the details pane, double-click ArchiveEFS.

certificate template, enable b. In the ArchiveEFS Properties dialog box, on the Request Handling
archival of the subject’s tab, select the Archive subject’s encryption private key check box,
encryption private key. and then click OK.
log off the network. b. Close all open windows and then log off.
5. Ensure that you are logged " Ensure that you are logged on to the domain with the following
on with your domain credentials:
administrative account. • Logon name: CAadmin1
• Domain: Domain
(continued)
6. Configure DomainCA to a. Restore the Certification Authority console.

issue the ArchiveEFS b. In the console tree, expand DomainCA, and then click Certificate
certificate template, and Templates.
c. Right-click Certificate Templates, point to New, and then click
d. In the Enable Certificate Templates dialog box, select ArchiveEFS,
and then click OK.
e. In the details pane, ensure that ArchiveEFS appears.
g. Close all open windows and then log off.
Exercise 5
Acquiring an ArchiveEFS Certificate
In this exercise, you will acquire an ArchiveEFS certificate, and then use the private key to encrypt
a file on drive C. You will verify that EFS used the private key from the ArchiveEFS certificate to
encrypt the file encryption key.
Scenario
After you deploy the ArchiveEFS certificate, all users who implement EFS must acquire an
ArchiveEFS certificate. Deployment of the ArchiveEFS certificate to all users of the network
ensures that private key recovery is possible for all EFS-encrypted files.
1. Log on to your domain by " Log on to the domain by using the following credentials:
using your EFS user account • User name: EFS1 (at the domain controller) or EFS2 (at the
with a password of member server)
P@ssw0rd.
domain)
2. In the Certificates – Current a. Click Start, click Run, type Certmgr.msc and then click OK.
User console, use the b. In the console tree, expand Certificates – Current User, and then
Certificate Request Wizard click Personal.
to request an ArchiveEFS
certificate with the friendly c. Right-click Personal, click All Tasks, and then click Request New
name of Archive EFS. Certificate.
d. On the Welcome to the Certificate Request Wizard page, click Next.
e. On the Certificate Types page, select ArchiveEFS, and then click
Next.
f. On the Certificate Friendly Name and Description page, in the
Friendly name box, type Archive EFS and then click Next.
g. On the Completing the Certificate Request Wizard page, click
Finish.
h. In the Certificate Request Wizard message box, click OK.
3. View the details of the a. In the console tree, expand Certificates- Current User, expand
ArchiveEFS certificate. Personal, and then click Certificates.
b. In the details pane, double-click the ArchiveEFS certificate.
You must scroll to the right and expand the column width to view
the Certificate Template column.
c. In the Certificate dialog box, on the Details tab, in the Show drop-
down list, select Properties only.
(continued)
What value appears in the Thumbprint attribute?
Answers will vary. Every certificate has a unique thumbprint value. The thumbprint is a digital hash
of the contents of the certificate, signed with the issuing CA’s private key.
4. Close the Certificate a. In the Certificate dialog box, click OK.

Management console. b. Close the Certificates – Current User console.
5. Create a new folder named a. On the Start menu, click My Computer.

C:\EFS. Assign the Users b. In My Computer, double-click Local Disk (C:).
group Modify permission
and enable EFS encryption c. In the C:\ window, create a new folder named EFS.
for the folder. d. Right-click EFS, and then click Properties.
e. In the EFS Properties dialog box, on the Security tab, under Group
or user names, select Users.
f. Under Permissions for Users, select the Allow check box for the
Modify permission, and then click Apply.
g. On the General tab, click Advanced.
h. In the Advanced Attributes dialog box, select the Encrypt contents
to secure data check box, and then click OK twice.
6. In the C:\EFS folder, a. Open the EFS folder.

prevent the hiding of known b. On the Tools menu, click Folder Options.
extension types, create a
new text document named c. In the Folder Options dialog box, on the View tab, clear the Hide
Secret.txt and type This is a extensions for known file types check box, and then click OK.
secret! in the document. d. On the File menu, click New, and then click Text Document.
e. Rename the new text document Secret.txt.
f. Double-click Secret.txt.
g. In the document, type This is a secret!
h. Save the changes, and then close the file.
7. View the properties of the a. In the C:\EFS folder, right-click Secret.txt, and then click Properties.
Secret.txt file to determine b. In the Secret.txt Properties dialog box, on the General tab, click
the thumbprint of the Advanced.
certificate that can open the
encrypted file. c. In the Advanced Attributes dialog box, click Details.
d. In the Encryption Details for C:\EFS\Secret.txt dialog box, adjust
the column widths in the Users Who Can Transparently Access This
File section so you can view the Certificate Thumbprint column.
(continued)
Does the value of the certificate thumbprint in the Data Decryption Field attribute match your certificate
thumbprint that you recorded earlier?
Yes, the value is the same. EFS uses the private key of the ArchiveEFS certificate to encrypt the file
encryption key.
t
8. Close the property sheets for a. In the Encryption Details for C:\EFS\Secret.txt dialog box, click
C:\EFS\Secret and log off OK.
the network. b. In the Advanced Attributes dialog box, click OK.
c. In the Secret.txt Properties dialog box, click OK.
Exercise 6
Performing Key Recovery
In this exercise, you will recover the private key of the ArchiveEFS certificate that the issuing CA
issued to your EFS user account.
Scenario
The EFS# (where # is 1 or 2) user has experienced problems with her profile. To fix the problem, a
local administrator has deleted her user profile. When the user logs on to the network, the problem
is fixed, but she can no longer access her EFS encrypted files. You must recover the EFS private
key to enable this user to access her EFS encrypted files.
1. Log on with your domain " Log on to the domain by using the following credentials:
administrative account. • User name: Student1 (on the domain controller) or Student2 (on
the member server)
• Password: Password (where Password is the password that was
assigned to your administrative account)
2. In the System folder in a. On the Start menu, click Control Panel, and then click System.
Control Panel, delete the b. In the System Properties dialog box, on the Advanced tab, in the
EFS1 profile (on the domain User Profiles section, click Settings.
controller) or the EFS2
profile (on the member c. In the User Profiles dialog box, under Profiles stored on this
server), and then log off the computer, select EFS1 (on the domain controller) or EFS2 (on the
network. member server), and then click Delete.
d. In the Confirm Delete dialog box, click Yes.
e. In the User Profiles dialog box, click OK.
f. In the System Properties dialog box, click OK.
3. Log on using your domain " Log on by using the following credentials:
administrative account. • User name: EFS1 (on the domain controller) or EFS2 (on the
member server)
• Domain: Domain
4. Open C:\EFS\Secret.txt. a. Open the C:\EFS folder.

b. In the C:\EFS window, double-click Secret.txt.
(continued)
Can you open the Secret.txt document?
No. The ArchiveEFS certificate’s private key was deleted when you deleted the user’s profile.
4. (continued) c. In the Notepad message box, click OK.

d. Close Notepad.
5. Ensure that you are logged " Log on by using the following credentials:
on using your Certificate • User name: CertAdmin1 (on the domain controller) or
Manager account. CertAdmin2 (on the member server)
• Domain: Domain
6. Open the Certification " On the Start menu, click Administrative Tools, and then click
If you are working on the member server in your domain, an error
appears that states that Certificate Services does not exist as an
controller.
Authority console to manage b. In the console tree, right-click Certification Authority, and then click
the enterprise CA in your Retarget Certification Authority.
domain.
d. In the Select Certification Authority dialog box, select DomainCA
(where Domain is the NetBIOS name of your domain), and then click
OK.
(continued)
8. In Certification Authority a. In the console tree, expand DomainCA (where Domain is the NetBIOS
console, add the Archive name of your domain), and then click Issued Certificates.
Key column to issued b. On the View menu, click Add/Remove Columns.
certificates.
c. In the Add/Remove Columns dialog box, in the Available Columns
list, select Archived Key, and then click Add.
d. In the Add/Remove Columns dialog box, click OK.
e. In the details pane, scroll to the right and ensure that the Archived Key
column for the issued ArchiveEFS certificates contains the value Yes.
9. In the Certification a. In the details pane, expand the width of the Serial Number column to
Authority console, find the show the complete serial number.
serial number of the
ArchiveEFS certificate that
the CA issued to your EFS
account.
What is the serial number of the ArchiveEFS certificate that was issued to your EFS user account?
Answers will vary. Every certificate that a CA issues is assigned a unique certificate serial number.
9. (continued) b. Close the Certification Authority console.
10. In Key Recovery Tool a. Click Start, click Run, type C:\moc\2821\labfiles\module7\krt.exe
(C:\moc\2821\labfiles\ and then click OK.
module7\krt.exe), determine b. In the Key Recovery Tool, define the following settings, and then
the key recovery agent for click Search.
the EFS1 or EFS2
certificate. • Certification authority (CA): Dcname.Domain.msft\DomainCA
(where Dcname is the NetBIOS name of your domain controller
and Domain is the NetBIOS name of your domain)
• Search Criteria drop-down list: Common Name
• Search Criteria box: EFS1 (on the domain controller) or EFS2 (on
the member server)
(continued)
Does the serial number of the ArchiveEFS certificate that was issued to your EFS account match the
previously recorded serial number?
Yes, the serial number matches. This certificate is associated with the archived key for your EFS
account.
When is it prefereable to search for the archived certificate by serial number rather than by common name?
Search by serial number when a user has multiple certificates that have archived private keys.
10. (continued) c. In the Key Recovery Tool, in the Certificates list, select the listed
certificate, and then click Show KRA.
What is the subject and serial number of the Key Recovery Agent certificates that can recover the private key
of the EFS users’ certificate?
Both Key Recovery Agent certificates can recover the encrypted private key because two Key
Recovery Agent certificates the CA administrator designated two Key Recovery Agent certificates for
the server.
10. (continued) d. In the Key Recovery Agents Used for Archival dialog box, click
Close.
(continued)
Can you use your certificate manager account to recover the private key?
No. You do not have access to the Key Recovery Agent certificate’s private key that can recover the
EFS account private key that is stored in the CA database.
When can you use the Recover button in the Key Recovery Tool?
You can use the Recover button in the Key Recovery Tool only when you hold both the certificate
manager and key recovery agent roles.
11. Export the encrypted private a. In the Key Recovery Tool, in the Certificates list, select the certificate
key material to an output file listed, and then click Retrieve Blob.
named C:\moc\2821\ b. In the Save As dialog box, in the File name box, type
labfiles\module7\recover C:\moc\2821\labfiles\module7\recover and then click Save.
by using the Retrieve Blob
button in the Key Recovery c. In the Key Recovery Tool, click Close.
Tool. d. Close all open windows and then log off.
If you did not have access to the Key Recovery Tool, what certutil command can you use to extract the
PKCS #7 blob from the CA database?
You can use certutil –getkey [EFS1|EFS2] C:\moc\2821\labfiles\module7\recover.blob.

(continued)
12. Log on to the network with " Log on to the network by using the following credentials:
your KRA user account. • User name: KRA1 (on the domain controller) or KRA2 (on the
member server)
13. Recover the ArchiveEFS a. Click Start, click Run, type C:\moc\2821\labfiles\module7\krt.exe
certificate private key to a and then click OK.
file named C:\moc\2821\ b. In the Key Recovery Tool, click Decrypt Blob.
labfiles\module7\EFS.pfx,
and then close all open c. In the Open dialog box, in the File name box, type
windows and log off the C:\moc\2821\labfiles\module7\recover.blob and then click Open.
network. d. In the Save As dialog box, enter the following information:
• File name: EFS.pfx
• Confirmation: P@ssw0rd
e. In the Save As dialog box, click Save.
f. In the Key Recovery Tool Info dialog box, click OK.
g. In the Key Recovery Tool, click Close.
14. Log on using the following " Log on by using the following credentials:
credentials: • Logon name: EFS1 (on the domain controller) or EFS2 (on the
• Logon name: EFS1 or member server)
EFS2 • Password: P@ssw0rd
• Password: P@ssw0rd • Domain: Domain (where Domain is the NetBIOS name of your
• Domain: Domain Active Directory domain)
(continued)
15. Import the EFS.pfx file into a. Open the C:\moc\2821\labfiles\module7 folder.
your personal store by using b. Double-click EFS.pfx.
the following options:
c. On the Certificate Import Wizard page, click Next.
d. On the File to Import page, click Next.
• Click Mark this key as
exportable. This will e. On the Password page, in the Password box, type P@ssw0rd
allow you to back up f. Click Mark this key as exportable. This will allow you to back up
or transport your keys or transport your keys at a later time, and then click Next.
at a later time g. On the Certificate Store page, click Automatically select the
• Certificate Store: certificate store based on the type of certificate, and then click Next.
Automatically select h. On the Completing the Certificate Import Wizard page, click
the certificate store Finish.
based on the type of
certificate i. In the Certificate Import Wizard message box, click OK.
j. Close the C:\moc\2821\labfiles\module7 folder.
16. Attempt to open a. Open the C:\EFS folder.

C:\EFS\Secret.txt. b. In the C:\EFS folder, double-click Secret.txt.
Can you open Secret.txt? Why or why not?
Yes. You now have the private key that can decrypt the file encryption key that is stored in the Data
Decryption Field attribute of Secret.txt.
17. Close all open windows and a. Close Secret.txt – Notepad.

Trust Between
Organizations
Contents
Overview 1
Lesson: Introduction to Advanced PKI
Hierarchies 2
Lesson: Qualified Subordination Concepts 13
Lesson: Configuring Constraints in a
Policy.inf File 28
Lesson: Implementing Qualified
Subordination 41
Lab A: Implementing a Bridge CA 53
respective owners.
Module 8: Configuring Trust Between Organizations iii
Instructor Notes
Presentation: In this module, students will to learn to how extend an organization’s PKI trust
60 minutes hierarchy to other organizations. By extending the trust hierarchy, an
organization’s certificates can be used and trusted across organizations for
Lab: purposes like secure e-mail messages, client authentication, and server
90 minutes authentication.
This module describes the various methods of extending your CA hierarchy to
other organizations.
! Describe advanced PKI hierarchies.
! Describe how constraints are used in qualified subordination.
! Configure a policy.inf file to implement qualified subordination constraints.
! Implement qualified subordination between certification authority (CA)
hierarchies.

PowerPoint, all of the features of the slides may not appear correctly.

! Read the white paper, Windows .NET Qualified Subordination, under
disc for details about planning and deploying qualified subordination.
! See the Federal Bridge Certification Authority (FBCA) Web site at
http://www.cio.gov/fbca/ for more information about Bridge CA design.
! Read the white paper, Planning and Implementing Cross-Certification and
Qualified Subordination Using Windows Server 2003, under Additional
information about designing qualified subordination constraints.
! Read section 4.2.1 in RFC 3280, Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile, under Additional
information about constraints and policies.
! Read the white paper, Troubleshooting Certificate Status and Revocation,
compact disc for more information about certificate status checking and
revocation.
! View an example of a policy.inf file in Appendix A of the white paper,
Planning and Implementing Cross-Certification and Qualified
Subordination Using Windows Server 2003, under Additional Reading on
the Web page on the Student Materials compact disc. Also, view a sample
of CAPolicy.inf in Appendix B of the same white paper.
iv Module 8: Configuring Trust Between Organizations

Lesson: Introduction to Advanced PKI Hierarchies

This lesson introduces students to advanced PKI hierarchies. These hierarchies
include common root CAs, cross certification, qualified subordination, and
Bridge CAs.
lesson.
Methods for Explain the business reasons for establishing certificate trust between
Establishing Trust organizations. Do not go into details on this page, because each method is
Between Organizations described fully on the pages that follow.
How to Define Certificate Many students will be familiar with certificate trust lists (CTLs) if they have
Trust Lists implemented CTLs in a Microsoft Windows NT® 4.0 or Windows® 2000
network. Ensure that the students understand that CTLs are a Microsoft solution
and are not interoperable with other operating systems.
How to Deploy a Use the slide to explain that the common root CA can either be a root CA that
Common Root CA one of the organizations in the trust relationship hosts, a root CA that a hosting
organization managed, or a commercial CA entity such as VeriSign, RSA, or
Thawte.
How to Implement Cross Explain that by using cross certification, students can issue a Cross Certification
Certification Authority certificate from a CA in their organization to a CA in another
organization. Emphasize that all certificates that are issued by the CA that is
listed in the subject of the Cross Certification Authority certificate are trusted.
All CAs that are subordinate to the CA that is listed in the subject of the Cross
Certification Authority certificate are also trusted. You can not apply
constraints with cross certification.
What Is Qualified Explain that qualified subordination, which is an extension of Cross
Subordination? Certification. Qualified subordination, allows the student to apply constraints in
the Cross Certification Authority certificate. Do not spend a lot of time
discussing the actual qualified subordination constraints, because this is the
focus of the entire module.
What Is a Bridge CA? Use the animation in the slide to explain how Cross Certification Authority
certificates are issued in a bridge CA hierarchy. Be sure that students
understand that any certificate that a CA in the bridge hierarchy issues may be
used in all participating organizations. The bridge CA hierarchy is the PKI
hierarchy structure that is used for the lab in this module. Consider showing this
slide again before students begin the lab.
Module 8: Configuring Trust Between Organizations v
Lesson: Qualified Subordination Concepts

This lesson defines the constraints that you can apply in a Cross Certification
Authority certificate. It describes each constraint and how the constraint can
restrict certificates that are issued by a partner’s organization.
Qualified Subordination Use this page as a general introduction to the following constraints that are
Constraints available when the student implements qualified subordination. Do not spend a
lot of time discussing the details of each constraint, because the details are
presented in the pages that follow.
What Are Basic Consider using the whiteboard to draw examples of CA hierarchies and how the
Constraints? path length defines which CAs are trusted in a partner CA. Emphasize that if
students want to restrict trusted certificates to a specific CA, they must
implement a path length of zero.
What Are Name Build logical examples of namespace inclusions and exclusions for the students.
Constraints? The best example to use is the scenario in which a namespace is mistakenly
included in both namespace inclusions and exclusions. Emphasize that an
excluded namespace always takes precedence in this scenario. Do not explain
name formats in detail at this point; wait until the next lesson.
What Are Application Some students may argue that an application policy is not a constraint.
Policies? Although this is technically true, in this context, an application policy
constrains what application policy object identifiers (OIDs) must be included in
a partner’s certificate for use in your organization. Emphasize that the
application policies are represented as OIDs, not as text.
What Are Certificate Certificate policies are the basis of trust when you implement qualified
Policies? subordination. Certificate policies describe what measures are taken to identify
the holder of a certificate’s private key. Present examples of issuance measures
the student can take to prove a user’s identity. Good examples include viewing
photo identification, performing background checks, performing credit checks,
or even certifying DNA. Each of these can be included in an issued certificate
by defining a custom OID.
How Qualified In this topic, the students will think about the ways that they can apply qualified
Subordination Effects a subordination in their organizations, so remind them of the legal implications of
CPS certificate trust. Emphasize that they are now trusting certificates that are issued
to nonemployees. The CPS is the only contract they have with these external
participants. The only way that qualified subordination succeeds is through the
efforts of each organization’s legal departments, to ensure that all constraint are
met and can be audited for enforcement.
Guidelines for Designing Review each guideline with the class. Ask students if they have any questions
Constraints about the guidelines. Warn students that the biggest mistake they can make is to
over design a solution. Explain that they should only define the constraints that
are necessary to meet their business requirements. If they do not need to limit
which applications their organization trusts, they should not define each
allowed application. Also, tell them not to define application policies in the
design.
Practice: Identifying Provide students with sufficient time to answer the questions. Remind students
Constraints that they must use each type of constraint as an answer.
vi Module 8: Configuring Trust Between Organizations
Lesson: Configuring Constraints in a Policy.inf File

In this lesson, students will learn how to define the qualified subordination
constraints in the policy.inf file. In contrast to the previous lesson, which was
theoretical, this lesson teaches how to configure qualified subordination. Do not
rush through this lesson because it is the basis for the lab at the end of the
module.
What Is a Policy.inf File? Consider comparing the policy.inf file to CAPolicy.inf, which is discussed in
Module 3. Focus on the differences between the two files, and explain that the
primary difference is that for a policy.inf file, it is not necessary to name the file
policy.inf. Also, the policy.inf file can exist in any folder on the network.
CAPolicy.inf must be named CAPolicy.inf, and can only exist in the %windir%
folder.
Configure Basic Tell students to view the code on the topic page and notice that the PathLength
Constraints entry starts at a value of zero, rather than a value of one.
Configure Name Students may be unfamiliar with the syntax of Windows .inf files. Review the
Constraints code on the page and describe how the [NameConstraintsExtension] section is a
pointer to following sections that describe the included and excluded
namespaces.
Emphasize that all subject names that are included in a certificate must pass the
name constraint tests—including the subject and alternate subject name
extensions.
If students have questions about the available formats for name constraints,
refer them to the white paper, Planning and Implementing Cross-Certification
and Qualified Subordination using Windows Server 2003, under Additional
Configure Application If students have questions about the application policy OIDs, open the
Policies Certificate Templates console and view the available object identifiers.
Emphasize that most required application policies are predefined and available
in the console.
Configure Certificate Explain that when application policies are predefined, certificate policies are
Policies almost always custom OIDs. Spend time discussing where the students can
obtain an OID for their organization. Use the slide to discuss the process for
mapping the certificate policy OIDs.
Practice: Configuring a Provide students with sufficient time to complete the practice, and then review
Policy.inf File to Enforce the answers with the class. The most common mistake that students make is to
Namespace omit one of the namespaces in the solution. Discuss this common mistake, and
Requirements how the omission can lead to the organization rejecting a valid certificate.
Lesson: Implementing Qualified Subordination

In this lesson, students learn about the process of configuring and issuing a
Cross Certification Authority certificate with qualified subordination
constraints.
How to Create a Signing Do not demonstrate the process at this point because the lesson ends with a
Certificate Template demonstration about this topic. Emphasize that the students must create this
from an Enterprise CA certificate template to implement qualified subordination. No default template
exists that can sign Cross Certification Authority certificate requests.
Module 8: Configuring Trust Between Organizations vii
Steps for Modifying a Explain to students that they must perform major modifications to the Cross
Cross Certification Certification Authority certificate template only when they do not use the
Authority Certificate default application policy signing OID. Consider showing students the Issuance
Template Requirements tab of a version 2 certificate in the Certificate Templates console
(Certtmpl.msc), and discuss how they would implement a custom application
policy OID.
Demonstration: Creating You must perform this demonstration on the instructor computer exactly as it is
Certificate Templates for written. This demonstration creates the Qualified Subordination Signing
Qualified Subordination certificate template that the lab requires, and then publishes it and the Cross
Certification Authority certificate template. The most common error in this
demonstration is to omit publishing the Cross Certification Authority certificate
template.
How to Create a Cross Explain that the Certreq.exe command-line tool generates the Cross
Certification Authority Certification Authority certificate. Review the syntax of the command, and
Certificate show students that even though they start at a command line, the process is
actually a graphical process.
How to Publish a Cross This topic prepares students for the upcoming lab. Explain that the only time
Certification Authority that students must publish a Cross Certification Authority certificate is when
Certificate they implement a Bridge CA. Explain that the Cross Certification Authority
certificates that a Bridge CA issues must be published at all organizations that
participate in the bridge CA hierarchy. Discuss the scenario in which a new
organization joins a Bridge CA hierarchy. Explain each organization in the
Bridge CA hierarchy must publish the certificate issued by the Bridge CA to the
new organization to allow trust of the certificates issued by the new
organization.
How to Verify Qualified Review the syntax of the certutil –viewstore command. The most common
Subordination mistake students make is to mistype the command. If time permits, demonstrate
other ways to verify the publication of the Cross Certification Authority
certificate, such as by using the ADSIEdit.msc console.
Lab A This lab is the longest lab in the course. Consider providing the students with
extra time to take a break during the lab. It is recommended that you review the
two policy.inf files with the students before they create the Cross Certification
Authority certificate request files. This way, they can catch any errors before
they affect the rest of the lab.
The lab uses Terminal Services to connect to the instructor computer. Ensure
that Terminal Services is configured as presented in the Manual Setup Guide
for this course, so that one user account is allowed multiple terminal sessions.
viii Module 8: Configuring Trust Between Organizations
Lab A: Implementing a Bridge CA

In this lab, students will implement a Bridge CA hierarchy with the instructor’s
computer acting as the Bridge CA in the CA hierarchy.
In this lab, students will:
! Create and issue a Qualified Subordination Signing certificate.
! Configure a policy.inf file to enforce qualified subordination constraints.
! Create a Cross Certification Authority certificate request.
! Verify qualified subordination.
! Publish Bridge CA certificates in the Active Directory® directory service.
Lab Setup
an enterprise subordinate CA exist. Complete all of Lab A, Lab B, and Lab C in
your domain controller) is configured as a member of the Local intranet zone in
the Default Domain Policy. Complete Lab B in Module 3, “Creating a
Certification Authority Hierarchy,” in Course 2821.
Setup requirement 5 The instructor must perform the demonstration titled Creating Certificate
Templates for Qualified Subordination before students starting Lab A. The lab
depends on the completion of this demonstration, because it prepares the
London computer to issue Qualified Subordination Signing and Cross
Certification Authority certificates. Complete the demonstration titled Creating
Certificate Templates for Qualified Subordination in Module 8, “Configuring
Trust Between Organizations,” in Course 2821.
Module 8: Configuring Trust Between Organizations ix
Lab Results
changes:
! A custom certificate template named Qualified Subordination Signing is
published on the enterprise subordinate CA.
! The Domain-to-Bridge.inf file is modified to enforce the required qualified
subordination constraints and policies.
! A Qualified Subordination Signing certificate is issued to Student1.
! A Cross Certification Authority certificate that implements the qualified
subordination constraints that are defined in the Domain-to-Bridge.inf file is
issued to the Bridge CA.
! The Bridge-to-Domain.inf file is copied to Domain.inf (where Domain is
the NetBIOS name of a student pair’s domain).
! The Domain.inf file is modified to enforce the required qualified
subordination constraints and policies.
! A Cross Certification Authority certificate that implements the qualified
subordination constraints that are defined in the Domain.inf file is issued to
each subordinate enterprise CA, which completes the Bridge CA hierarchy.
! All Cross Certification Authority certificates that the Bridge CA issued are
copied to the \\London\BridgeCerts share.
! All existing Cross Certification Authority certificates that the BridgeCA
issued are published in each student forest’s Active Directory database by
using the dspublish –f Certname.crt CrossCA command.
! A QS Email certificate template is created. The certificate template meets
all qualified subordination constraints.
! QS Email certificates are issued to QualSub1 and QualSub2.
! All QS Email certificates are copied to a share named \\London\ClientCerts.
Module 8: Configuring Trust Between Organizations 1
Overview

Introduction Your organization may require that certificates be used and trusted across
organizations for purposes such as sending secure e-mail messages and
authenticating workstations and computers. To accomplish certificate trust
between organizations, you can extend your organization’s public key
infrastructure (PKI) to trust other organizations.
The validation of certificates requires the availability of all certificates and
certificate revocation lists (CRLs) in a certificate chain. You may use a
certificate for the purposes that the certificate stipulates if the certificate is
proved to be valid, and if the certificate is chained to a trusted root CA.
The root CA certificate provides the trust anchor from which CA hierarchies are
derived. When you extend trust to another organization, you issue a Cross
Certification Authority certificate to a CA in the other organization, so that its
CAs logically chain to your organization’s trusted root CA.
This module describes the various methods of extending your CA hierarchy to
other organizations. You will learn about qualified subordination, which
provides a more flexible and manageable trust mechanism in a Microsoft®
Windows Server™ 2003 environment.
! Describe advanced PKI hierarchies.
! Describe how constraints are used in qualified subordination.
! Configure a policy.inf file to implement qualified subordination constraints.
! Implement qualified subordination between certification authority (CA)
hierarchies.
2 Module 8: Configuring Trust Between Organizations
Lesson: Introduction to Advanced PKI Hierarchies

Introduction There are various ways to establish trust between two or more CA hierarchies.
You select the appropriate method for establishing trust according to your
organization’s requirements, infrastructure, and operating systems that your
organization uses.
For example, Windows 2000 can only use certificate trust lists (CTLs) to
establish a trust between two CA hierarchies. However, CTLs cannot be used
by organizations that implement non-Microsoft solutions.
! Describe the methods for establishing trust between organizations.
! Connect organizations’ CA hierarchies by using a certificate trust list.
! Connect organizations’ CA hierarchies by using a common root CA.
! Connect organizations’ CA hierarchies by using cross certification.
! Connect organizations’ CA hierarchies by using qualified subordination.
! Connect organizations’ CA hierarchies by using a Bridge CA.
Methods for Establishing Trust Between Organizations

Introduction When you establish a certificate trust, you enable the organization to trust the
certificates that are issued to computers, users, and services in another
organization.
Methods for establishing In a Windows Server 2003 PKI, you can use the following methods to
trust between configure trust between organizations:
organizations
! A certificate trust list. A CTL is a list of root CA certificates that are signed
by trusted CAs. Administrators use CTLs for specific purposes, such as to
authenticate computers or to secure e-mail messages.
! A common root CA. When you configure enterprise subordinate CAs that
are subordinate to a common root CA, certificates that are issued by the
subordinate CAs are recognized and accepted between organizations.
Note Alternatively, each organization can designate the other

organization’s root CA as a trusted root CA.
! Cross certification. An organization can issue Cross Certification Authority

certificates to a CA in another organization’s CA hierarchy. After the
certificate is issued, all certificates that are chained to this CA are
completely trusted by the organization that issued the Cross Certification
! Qualified subordination. An extension to cross certification, qualified
subordination places constraints on the Cross Certification Authority
certificate that restrict which certificates are considered trusted from the
partner organization. The constraints can restrict certificates based on
namespace, certificate use, or how the certificate was issued.
! A bridge CA. This method for establishing trust allows multiple
organizations to establish certificate trust. Every organization issues a
certificate to a common Bridge CA, and the Bridge CA issues certificates to
the root CA of each organization.
When to establish trust Consider implementing certificate trust when your organization must:
! Trust certificates that are issued by another organization’s CA hierarchy.
! Recognize certificates that are issued to people that are external to your
organization.
How to Define Certificate Trust Lists

Introduction By using a certificate trust list, you can limit the purpose for which you trust
certificates that are issued by another organization. You can also control the
validity period of certificates that are issued by an external organization.
To trust the certificate of an external organization, you must place the self-
signed root certificate from the organization in the Enterprise Trust container of
a Group Policy object (GPO).
For example, a partner organization has a CA that issues certificates for server
authentication, client authentication, code signing, and secure e-mail messages.
Your organization wants to trust only the certificates that the partner
organization issues for secure e-mail messages. You can define a CTL so that
the certificates that the partner organization issues are valid only for secure e-
mail messages. Any certificates that are issued for another purpose are not
accepted for use by any computer or user that the GPO that defines the CTL is
applied to.
Procedure for defining a To define a CTL for a GPO:
CTL
1. Log on to a domain for which you have administrative privileges to manage
the GPO.
2. Open the GPO that you want to edit.
3. In the console tree, expand Computer Configuration, expand Windows
Settings, expand Security Settings, expand Public Key Policies, and then
click Enterprise Trust.
4. On the Action menu, point to New, and then click Certificate Trust List.
Follow the steps in the Certificate Trust List Wizard to create a certificate
trust list for the GPO.
Importing a CTL You can export a CTL from one GPO and import it to another GPO in another
organizational unit or domain. The import and export function ensures that the
same CTL settings are enforced between Group Policy containers.
How to Deploy a Common Root CA

Introduction Deploying a common root CA allows certificates to be trusted between
organizations. The common root CA can either be a root CA that one of the
organizations in the trust relationship hosts, or a commercial CA entity, such as
VeriSign, RSA, or Thawte.
Deploying a common You can use one of the following methods to deploy a common root CA as a
root CA trusted root CA for your organization:
! Use the certutil –dspublish <CA Certificate> RootCA command to
configure the common root CA as a trusted root CA for the entire forest.
The common root CA is then published as a trusted root CA in the
configuration naming context and designated as a trusted root CA in every
domain in the forest.
! Define the root CA as a trusted root CA in Group Policy to configure the
common root CA for a specific domain or organizational unit. Only
computers that have Group Policy applied to their accounts in Active
Directory will recognize the root CA.
Procedure to deploy a To add a trusted root certification authority to a GPO:

trusted root CA to a
GPO 1. Log on to a domain for which you have administrative privileges to manage
the GPO.
2. Open the GPO that you want to edit.
3. In the console tree, expand Computer Configuration, expand Windows
Settings, expand Security Settings, expand Public Key Policies, and then
click Trusted Root Certification Authorities.
4. On the Action menu, point to All Tasks, and then click Import.
5. Use the Certificate Import Wizard to import a root certificate and install it as
a trusted root CA for the GPO.
Note You can import a trusted root certificate from a PKCS #12 file, a
PKCS #7 file, a certificate file, or a Microsoft serialized certificate store file.
Considerations when A common root CA allows total trust between the organizations that designate
deploying a common the common root CA as a trusted root CA. Consider the following facts before
root CA you deploy a common root CA:
! The root CA is restricted by the security policy and certificate policy of the
organization that hosts the common root CA. These policies may not align
with your organization’s policies.
! The cost of a Subordinate Certification Authority certificate may be high,
and every certificate that is issued by the subordinate CA that your
organization hosts may incur additional costs.
! Organizations other than your trusted partner can use the common root CA.
If a certificate is chained to the common root CA, the certificate is trusted
for all purposes, even if this is not what your organization wants. A common
root CA implies total trust for certificates that are chained to the common
root CA.
Note Rather than acquire certificates from a common root CA, the two
organizations can designate the other organization’s root CA as a trusted root
CA. Like a common root CA, this configuration results in total trust of all
certificates that are issued by the other organization’s CA hierarchy.
How to Implement Cross Certification

Introduction By using cross certification, you can issue a Cross Certification Authority
certificate from a CA in your organization to a CA in another organization. The
Cross Certification Authority certificate allows your organization to trust
certificates that are issued by the other organization’s CA and any CA that is
subordinate to it.
Note If the Cross Certification Authority certificate is issued to a partner’s root

CA, your organization will trust any certificate that the partner’s CA hierarchy
issues.
Steps for implementing To implement cross certification between two organizations:

cross certification
1. Obtain a CA certificate from your partner organization. The certificate
identifies the CA that will be issued the Cross Certification Authority
certificate from a CA in your organization.
2. Issue a Cross Certification Authority certificate from an issuing CA in your
CA hierarchy to a CA in the partner organization.
Tip Issue the Cross Certification Authority certificate from an issuing CA

in your CA hierarchy rather than the root CA to ensure more frequent
publication of the CRL.
3. Provide a CA certificate from your organization’s CA hierarchy to the

partner organization in order to issue a Cross Certification Authority
certificate.
Note Use caution when choosing the CA certificate that you provide to the
partner organization. The partner organization will recognize only user and
computer certificates that are issued by the chosen CA or CAs that are
subordinate to the chosen CA.
4. Ensure that the partner organization issues a Cross Certification Authority

certificate based on the information in the CA certificate that your
organization provides.
For example, to configure complete trust between Contoso, Ltd and Northwind
Traders, the issuing CA in each CA hierarchy must issue a Cross Certification
Authority certificate to the root CA in the partner organization’s CA hierarchy.
The Cross Certification Authority certificate allows certificates that the partner
organization issues to be trusted by PKI-enabled applications in your
organization.
Note The Cross Certification Authority certificates are stored in the Active
Directory database of the organization that issues the certificate. The issuing
organization uses the certificate to build certificate chains for certificates that
the partner organization issues.
What Is Qualified Subordination?

Introduction Qualified subordination applies constraints to the Cross Certification Authority
certificate that is issued to a CA in a partner’s CA hierarchy. The constraints
extend cross certification by defining which certificates your organization
considers trustworthy.
Defining constraints When you implement qualified subordination, you can define the following
constraints:
! Limit the namespaces. Define what namespaces are allowed and prohibited
by certificates that are issued by a partner’s CA hierarchy. For example, you
can apply a name constraint that prohibits certificates that are issued by a
partner’s CA hierarchy for your organization’s namespace.
! Define the depth of the partner’s CA hierarchy. Use a basic constraint to
define how many layers of the partner’s CA hierarchy your organization
trusts, rather than trusting all CAs in the CA hierarchy. For example, you
can trust only the CA that the Cross Certification Authority certificate is
issued for, or you can define the number of subordinate layers that you trust
in the CA that is issued the Cross Certification Authority certificate.
! Define applications. Define which applications will accept certificates that
the partner organization issues to computers, users, or services. For
example, you may trust only certificates that are used for secure e-mail
messages.
! Restrict certificate policies. Define the certificate issuance procedures that
the partner organization must implement. A partner organization will
designate the certificate policies that it implements for a certificate by
including an object identifier (OID) in the issued certificates.
By defining the qualified subordination constraints for the organization that

issues the Cross Certification Authority certificate, the issuing organization can
define certificate restrictions that enforce the security policy of the issuing
organization.
Note For more information about planning and deploying qualified

subordination, see the white paper, Planning and Implementing Cross-
Certification and Qualified Subordination Using Windows Server 2003, under
What Is a Bridge CA?

Introduction When you want to establish trust between three or more organizations, it is
easier to implement qualified subordination by using a Bridge CA. The Bridge
CA acts as a link between the CA hierarchies in each organization. Certificates
that participating organizations issue are trusted by the other members of the
bridge CA hierarchy, as long as the certificate meets any qualified
subordination criteria that is defined by that participant in the Bridge CA
hierarchy.
A Bridge CA reduces the complexity of defining trust between CA hierarchies
when there are three or more CA hierarchies. Also, it is easier to add an
organization to an existing Bridge CA design than to configure a separate trust
relationship.
Note For more information about bridge CA design, see the Federal Bridge
Certification Authority (FBCA) Web site at http://www.cio.gov/fbca/.
Deploying a Bridge CA When you deploy a Bridge CA:

1. An issuing CA on each participating organization issues a Cross
Certification Authority certificate to the Bridge CA.
2. The Bridge CA issues Cross Certification Authority certificates to the root
CA of each participating organization.
Each Cross Certification Authority certificate includes the qualified

subordination constraints that are defined by the organization that issued the
Cross Certification Authority certificate. Typically, only the participating
organizations define these constraints, not the Bridge CA.
The implementation of a Bridge CA does not prevent the implementation of
separate qualified subordination relationships between the participating
organizations. For example, two organizations may use the Bridge CA to
recognize secure e-mail certificates, but implement separate Cross Certification
Authority certificates to recognize Client Authentication certificates.
Lesson: Qualified Subordination Concepts

Introduction Use qualified subordination to define the certificates that your organization
trusts. When you use qualified subordination, you implement various
constraints to control the relationship between multiple organizations’ CA
hierarchies.
For example, you can define the namespaces for which your hierarchy will
accept certificates, specify the acceptable uses of certificates, and define the
issuance practices that other organizations must follow when issuing certificates
to their users for your organization to trust their certificates.
! Describe the available constraints in qualified subordination.
! Describe how basic constraints can restrict cross certification.
! Describe how name constraints can restrict cross certification.
! Describe how application policy can restrict cross certification.
! Describe how certificate policy can restrict cross certification.
! Identify the relationship between qualified subordination and the certificate
practice statement.
! Identify the best practices for implementing constraints in qualified
subordination scenarios.
Qualified Subordination Constraints

Introduction You can define different types of constraints for qualified subordination.
Types of subordination You can define the following constraints when you issue a Cross Certification
constraints Authority certificate:
! Basic constraint. Defines the maximum number of CAs from a partner’s CA
hierarchy that can be included in a certificate’s certification path.
! Name constraint. Defines what namespaces are allowed and prohibited in
certificates that a partner’s CA hierarchy issues.
! Application policy. Defines the purposes that are allowed for certificates that
a partner’s CA hierarchy issues. For example, you can choose to trust only
those certificates that are used for server authentication or code signing.
! Certificate policy. Defines the mechanisms that a partner organization
implement to increase the security of certificates that it issues. For example,
your organization may trust only those certificates that the partner’s CA
hierarchy issues in face-to-face interviews.
Defining constraints You can define constraints for qualified subordination in one of the following
ways:
! When you install a CA, you can define constraints in CAPolicy.inf. The
constraints are then implemented on the CA during the installation of the
CA or during the certificate renewal process.
! When you issue a Cross Certification Authority certificate, the request
process for the certificate defines constraints in a policy.inf file.
Note For more information about designing qualified subordination

constraints, see the white paper, Planning and Implementing Qualified
Subordination Using Windows Server 2003, Enterprise Edition, under
What Are Basic Constraints?

Introduction Basic constraints allow a CA administrator to limit the path length for a
certificate chain. You can specify a basic constraint that defines the maximum
number of CAs that can exist below the CA where the basic constraint is
assigned. Basic constraints are best defined on the subordinate CA, not on the
root CA.
For example, if you define a path length of one, your organization only trusts
certificates that are issued by the CA that is listed in the subject of the Cross
Certification Authority certificate and CAs that are directly subordinate to the
CA. Certificates issued by a CA two levels below are not trusted.
Note For more information about basic constraints, see section 4.2.1.10 of
RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate
Recommendations for Define basic constraints only in CA certificates that are issued to a subordinate
basic constraints CA in your organization’s CA hierarchy. If you implement a basic constraint in
the Root CA certificate, a change in the basic constraint requires a complete
redeployment of the CA hierarchy.
You can define basic constraints in a Cross Certification Authority certificate
that you issue to the root CA of a partner organization. Changing the basic
constraints in this scenario only requires that you issue a new Cross
Certification Authority certificate and delete the previous Cross Certification
What Are Name Constraints?

Introduction You use name constraints to define namespaces that are managed by each CA
in your organization and namespaces that you trust from other organizations.
When you deploy a Cross Certification Authority certificate, consider both the
namespaces that you want to accept from the partner’s CA and the namespaces
that you want to reject.
Note If the name that is specified in the request is not present in the list of
constraints, the qualified CA will reject the request.
Example For example, when you configure qualified subordination between your
organization and a partner organization, you usually do not want your partner’s
CA infrastructure to issue certificates that contain names in your organization’s
namespace. The use of name constraints can ensure that your namespace, and
all recognized formats of your namespace, are excluded in certificates that your
partner’s CA hierarchy issues.
Note For more information about name constraints, see section 4.2.1.11 of
Rules for processing When you process name constraints, consider the following rules:
name constraints
! A certificate is accepted if all names in the certificate match the
corresponding permitted name constraints.
! A certificate is rejected if any names in the certificate request match the
corresponding excluded name constraints.
! If a namespace is defined in both a permitted and an excluded name
constraint, the excluded name constraint takes precedence.
! Name constraints are applied to the Subject attribute and any existing
Subject Alternative Name extensions.
Note Constraints apply only when the namespace types that are specified as
name constraints exist in the presented certificate. If no namespace of the
specified types exists is in the certificate, the certificate is not acceptable.
What Are Application Policies?

Introduction Applications use application policies to determine if a certificate can be used
for a given purpose, such as authenticating a user, encrypting data, or signing a
device driver. When an application receives signed information from a user, it
reviews the certificate that is associated with the private key and verifies that
the certificate contains the required application policy OID.
Application policies provide the same functionality as the Enhanced Key Usage
(EKU) extension in a certificate. Both application policy and EKU indicate
what purposes a certificate may be used for and both are represented by OIDs.
If the application policy extension is not present in a certificate, an application
or service examines the EKU extension for the required OIDs.
Note Application policies are only supported by computers running

Windows XP or Windows Server 2003 family.
When you issue certificates that include both Application Policy and EKU
extensions, ensure that the two extensions are identical in their assignment of
OIDs. They must not be in conflict with each other. Otherwise, there policies
will be applied inconsistently when either extension is used.
Note For more information about certificate status checking and revocation,
see the white paper, Troubleshooting Certificate Status and Revocation, under
When you define application policies in a certificate that is issued to a CA, the
OIDs that are associated with the application policy are applied to all issued
certificates. The All Applications OID indicates that the application policy
includes all application policies. This application policy is normally reserved
for certificates that are issued to CAs.
Note For more information about application policies, see section 4.2.1.13 of
What Are Certificate Policies?

Introduction Certificate policies, also referred to as issuance policies, identify the level of
trust between the CA hierarchy of your organization and another organization.
For example, a certificate policy can define that you trust only those certificates
that were issued during a face-to-face meeting with a network administrator.
The issuing organization defines the rules to issue certificates by including an
OID in the certificate policy field of the issued certificate. The certificate policy
OID indicates that the certificate was issued after meeting the issuance
requirements that are associated with the certificate policy OID.
Default certificate A Windows Server 2003 PKI includes the following predefined certificate
policies policies:
! All Issuance (2.5.29.32.0). Allows the acceptance of any certificates that
have issuance policy OIDs. Typically, this OID is assigned only to CA
certificates.
! Low Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.400). Used for certificates that
are issued with no additional security requirements.
! Medium Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.401). Used for certificates
that may have additional security requirements for issuance. For example, a
smart card certificate that is issued in a face-to-face meeting with a smart
card issuer may be considered a medium assurance certificate and would
contain the medium assurance OID.
! High Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.402). Used for certificates that
are issued with maximum security. The issuance of a high assurance
certificate may require additional background checks and a digital signature
from a designated approver.
Note The x.y.z portion of the OID is a randomly generated numeric sequence
that is unique for each forest that has the Windows Server 2003 schema
extensions.
Custom certificate In addition to these default certificate policies, your organization can create
policies custom OIDs to use for custom certificate policies. The OIDs should be part of
an OID space, which you acquire from the Internet Assigned Numbers
Authority (IANA) or a similar organization.
For example, two organizations that are involved in a purchaser and seller
relationship can define custom OIDs to represent digital signature certificates
for specific purchase amounts. They may define one OID for purchases
between $100,000 and $500,000 and another OID for purchases greater than
$500,000. Applications can then use these OIDs to recognize whether a person
had the appropriate signing authority for a specific volume purchase.
Note Certificate policy extensions are only recognized by computers running

Windows XP or Windows Server 2003 family. If the extension is marked
critical, the Cryptographic API (CryptoAPI) passes the extensions to the
application. It is up to the calling application to enforce the requirement of the
certificate policy OID.
Defining certificate When certificate policies are implemented between organizations, the OIDs that
policies between one organization defines are mapped to the OIDs that the other organization
organizations defines. By defining mappings between the OIDs, equivalent OIDs are
identified between the organizations.
Note For more information about certificate policies, see section 4.2.1.5 in
How Qualified Subordination Effects a CPS

Introduction Implementing qualified subordination may affect your organization’s security
policy, certificate policy, and certificate practice statement (CPS).
Implementing qualified subordination may increase the number of certificates
that your organization accepts and increases the number of organizations that
may accept your organization’s certificates. Your organization’s security policy
must reflect security issues that may result from the extension of your network
boundaries.
After you modify the security policy, modify the certificate policy to account
for how your PKI will enforce the modified security policy. Also, be sure to
update the CPS to include the rules and regulations that are based on the
updated certificate policy.
Modifying the CPS If your organization implements qualified subordination, you must modify the
CPS because:
! The current CPS does not refer to external client computers. Therefore, the
rules that are defined in the CPS do not apply to external client computers.
! Your current certificate policy does not contain guidelines about the
acceptance of external digital certificates. Update the CPS to reflect any
restrictions on the use of certificates that other organizations manage. The
restrictions are defined in the qualified subordination constraints, which are
contained in the Cross Certification Authority certificate your CA issues to
the other organization’s CA.
! The liability of your organization now extends to actions by nonemployees.
The CPS acts as a contract between your organization and the participants
of the PKI. Define the procedures of the CA and the responsibilities of the
non-employee participants in the CPS.
! The CPS acts as the formal agreement between your organization and the
external participants.
Guidelines for Designing Constraints

Introduction When you design qualified subordination constraints, ensure that the constraints
do not negatively affect the security of your PKI. Also ensure that you do not
over design the constraints, and that you meet only the intended objectives.
Guidelines for designing Consider the following guidelines when you design qualified subordination
constraints constraints:
! Apply only required constraints. Implement only those constraints that are
required to meet the security policy.
! Issue separate Cross Certification Authority certificates for each purpose.
This approach is preferable to combining multiple requirements into a single
Cross Certification Authority certificate. Each project that requires PKI
cooperation between two organizations poses unique constraint
requirements. Define the set of requirement for each purpose in separate
Cross Certification Authority certificates.
! Exclude your namespace in all name constraints. Excluding your
namespace from certificates that the partner organization issues ensures that
subjects in your organization only use certificates issued from your CA
hierarchy.
! Define basic constraints only on Cross Certification Authority certificates
that are subordinate CAs. Basic constraints limit the path length of a
certificate chain. If you issue the certificate to a root CA, and the partner’s
root CA is an offline CA, you must increase the certificate path length to
reach the partner’s issuing CAs.
! Design constraints that enforce your organization’s security policy. When

you extend your organization’s PKI to external clients, the qualified
subordination constraints must reflect and enforce your required security
policy.
Note Review the security policy or certificate policy to ensure that they
provide sufficient information to define qualified subordination constraints.
! Modify your CPS to reflect the inclusion of external users in your PKI.
Usually, a CPS only applies to internal users. Before you extend the PKI
beyond your organization through qualified subordination, be sure to revise
your CPS to account for external users.
Practice: Identifying Constraints

Introduction In this practice, you will identify which qualified subordination constraints are
required to meet the certificate requirements of Northwind Traders, a fictitious
company.
Scenario You are a network administrator for Northwind Traders, where e-mail
communication is conducted between the members of your legal department
and your organization’s law firm, Contoso, Ltd. You must ensure the security
of all e-mail messages exchanged between the two organizations.
CA hierarchy of Contoso To help you configure certificate trust between the two organizations, Contoso,
Ltd Ltd has provided the following diagram of its CA hierarchy.
Requirements Northwind Traders developed certificate requirements to secure e-mail

messages with Contoso. It has updated its CPS to reflect the following
requirements:
! Northwind Traders must validate that the physical security implemented by
Contoso, Ltd. for MailCA meets all of the requirements for physical security
that are defined in Northwind Traders’ security policy. Your organization
must accept only certificates that are issued by the MailCA.
! The organizations may exchange e-mail messages to approve contracts and
legal documents, for example, documents that Contoso develops for
Northwind Traders’ business. To ensure that Northwind Traders verifies the
subject of the certificates presented from the Contoso CA, all participants
must undergo a face-to-face interview and background check before
Northwind Traders issues a mail certificate.
! The current project requires only support for e-mail messages. The
Northwind Trader’s PKI and PKI-enabled applications must reject
certificates for any other purpose.
! Northwind Traders will accept only certificates from the Contoso CA
hierarchy that are issued to employees of Contoso.msft. If the name in a
certificate is not from Contoso, the certificate should be rejected.
Questions Based on the scenario and requirements presented, answer the following
questions:
1. What type of constraint must you apply to ensure that only certificates that
are issued by the MailCA are accepted from employees of Contoso, Ltd.?
a. Basic Constraint
b. Name Constraint
c. Application Policy
d. Certificate Policy
a. Basic Constraint
____________________________________________________________
____________________________________________________________
2. What type of constraint must you apply to ensure that background checks
are performed for all Contoso employees who will send encrypted and
digitally signed e-mail messages?
a. Basic Constraint
b. Name Constraint
____________________________________________________________
____________________________________________________________
3. What type of constraint must you apply to ensure that only secure e-mail
certificates are accepted from Contoso, Ltd. employees?
a. Basic Constraint
b. Name Constraint
____________________________________________________________
____________________________________________________________
4. What type of constraint must you apply to ensure that only secure e-mail
certificates from Contoso, Ltd. are accepted?
a. Basic Constraint
b. Name Constraint
b. Name Constraint
____________________________________________________________
____________________________________________________________
Lesson: Configuring Constraints in a Policy.inf File

Introduction The main reason for implementing qualified subordination is to restrict which
certificates your organization trusts from a partner’s CA. You restrict
certificates by defining constraints in the policy.inf file.
You can define constraints either when you install a CA in your CA hierarchy
or when you issue a Cross Certification Authority certificate to a partner’s CA.
In this lesson, you will learn how to configure various constraints in a policy.inf
file.
! Describe the purpose and format of a policy.inf file.
! Configure basic constraint in a policy.inf file.
! Configure name constraints in a policy.inf file.
! Configure application policy in a policy.inf file.
! Configure certificate policy in a policy.inf file.
Note For more information about implementing qualified subordination

constraints, see the white paper, Planning and Implementing Cross-
Certification and Qualified Subordination using Windows Server 2003,
Enterprise Edition, under Additional Reading on the Web page on the Student
What Is a Policy.inf File?

Introduction A policy.inf file is a configuration file that defines the constraints that are
applied to a Cross Certification Authority certificate when qualified
subordination is defined. The constraints can include basic constraints, name
constraints, application policies, and certificate policies. You can modify a
policy.inf file and use it to submit certificate requests to the CA for other types
of certificates.
A Policy.inf file You specify the path and file name of a policy.inf file when you request the
Cross Certification Authority certificate by running the certreq.exe –policy
command. A policy.inf file:
! Is created and defined by an administrator manually.
! Is read during the creation of a Cross Certification Authority certificate.
! Is defined on the signing CA where you create the request—not on the CA
whose CA certificate you use during the request.
! Can exist in any folder on the requesting computer. Unlike CAPolicy.inf, a
policy.inf file can be stored in any folder on the computer where the
certificate request is generated. In addition, the policy.inf file can use any
file name as long as the syntax is correct.
Note To see an example of a policy.inf file, see appendix A of the white paper,
Planning and Implementing Cross-Certification and Qualified Subordination
using Windows Server 2003, under Additional Reading on the Web page on
the Student Materials compact disc, and see Appendix B in the same
whitepaper for a sample of CAPolicy.inf.
Configure Basic Constraints

Introduction A basic constraint defines which CAs your organization trusts in a partner’s CA
hierarchy by limiting the path length for a certificate chain.
Configuring basic You can define a basic constraint by adding a [BasicConstraintsExtension]
constraints section to the policy.inf file. The [BasicConstraintsExtension] defines the
maximum levels of a partner’s CA hierarchy from which you will accept
certificates.
[BasicConstraintsExtension]
PathLength = 1
When you define a basic constraint with a path length of one, it enforces the
restriction to accept only certificates that are issued by the CA that is named in
the subject field of the Cross Certification Authority certificate and CAs that are
directly subordinate to it.
If the CA that issues the Cross Certification Authority certificate evaluates a
certificate issued by a CA two levels below the CA, the certificate is rejected.
Guideline for defining a Define basic constraints only in Cross Certification Authority certificates that
basic constraint you issue to subordinate CAs in a partner’s CA hierarchy. If you implement a
basic constraint in a Cross Certification Authority certificate that is issued to a
root CA, the PathLength constraint must be large enough to reach the issuing
CAs in the partner’s CA hierarchy. A large PathLength constraint can mean you
end up trusting additional CAs beyond those that your organization intended to
trust.
Configure Name Constraints

Introduction When you enforce name constraints, you accept a certificate only if each name
in the certificate’s subject or alternate subject names matches at least one of the
name constraints that is enforced in the Cross Certification Authority
certificate.
If the certificate contains a Lightweight Directory Access Protocol (LDAP)
distinguished name format and in a User Principal Name (UPN) format in the
subject and alternate subject name, both names should match permitted name
constraints. If one of the subject names does not match, the certificate does not
pass the name constraints.
Configuring name You implement name constraints by defining the Permitted and Excluded name
constraints constraints in the [NameConstraintsExtension] section of a policy.inf file.
For example, if your organization, Contoso, Ltd, wants to implement name
restrictions so that certificates that Northwind Traders issues include only the
Northwind Traders names—and exclude Contoso, Ltd names, add the following
sections to a policy.inf:
[NameConstraintsExtension]
Include = NameConstraintsPermitted
Exclude = NameConstraintsExcluded
Critical = True
[NameConstraintsPermitted]
DirectoryName = "DC=nwtraders, DC=msft"
email = @nwtraders.msft
UPN = .nwtraders.msft
UPN = @nwtraders.msft
[NameConstraintsExcluded]
DirectoryName = "DC=Contoso, DC=msft"
email = @contoso.msft
UPN = .contoso.msft
UPN = @contoso.msft
In this example, if the CA that issued the Cross Certification Authority

certificate is presented a certificate with the e-mail name of
BDecker@nwtraders.msft, the certificate is accepted. However, if the certificate
that is presented contains a subject name of
CN=bdecker,OU=Corporate,DC=northwindtraders,DC=msft, the certificate is
rejected because the namespace does not match either a permitted or excluded
namespace.
Acceptable name When you create a new CA, you can define name constraints for the CA by
formats configuring CAPolicy.inf. Similarly, when you create a Cross Certification
Authority certificate, you define name constraints in the policy.inf file.
The following table describes the various naming and addressing formats for
name constraints.
Naming and
addressing format Description
Relative distinguished Identifies the names of objects stored in directories.

name Relative distinguished name constraints restrict a qualified
subordinate CA to issue certificates only to specific users or
computers in Active Directory.
DNS domain name Identifies the DNS name of a computer or network device.
Domain Name System (DNS) name constraints designate a
specific DNS host name or a DNS namespace for subject
names.
Uniform Resource Identify resources on the Internet that use identifiers such as
Identifier (URI) URL, FTP, HTTP, telnet, mailto, news, and gopher.
E-mail name and user Identify the suffixes used for e-mail addresses and UPN
principal name suffixes. Include both UPN and e-mail constraints in a name
constraint listing to differentiate between e-mail and UPN
requests.
IP address Identifies the IP address of a computer or network device.
IP address constraints allow you to specify either specific IP
addresses, or ranges of IP addresses.
Other name Allows you to extend name constraints to undefined name
formats.
Identified by a name and an OID.
Note For more information about naming and addressing formats, see the
white paper, Planning and Implementing Cross-Certification and Qualified
Subordination Using Windows Server 2003, under Additional Reading on the
Configure Application Policies

Introduction You can configure an application to accept only those certificates that contain
specific application policies. When the application receives signed information
from a user, it reviews the certificate that is associated with the private key that
signed the information and verifies that the certificate chain has the required
OID as a valid application policy.
Note If the application policy extension does not exist in a presented

certificate, an application policy constraint evaluates the EKU extension of the
presented certificate.
When you issue a Cross Certification Authority certificate, you can configure a
policy.inf file to specify which application policy OIDs are permitted in
certificates that the partner organization issues.
Configuring application To configure application policies in a policy.inf file, create the following
policies sections:
[ApplicationPolicyStatementExtension]
Policies = AppEmailPolicy, AppCodeSignPolicy, AppAuthPolicy
CRITICAL = FALSE
[AppEmailPolicy]
OID = 1.3.6.1.5.5.7.3.4 ; Secure Email
[AppCodeSignPolicy]
OID = 11.3.6.1.5.5.7.3.3 ; Code Signing
[AppAuthPolicy]
OID = 1.3.6.1.5.5.7.3.2 ; Client Authentication
The [ApplicationPolicyStatementExtension] section defines all application

policy setting sections that exist in the policy.inf file. In this case, it defines
three application policy sections. – one for each section defined in
[ApplicationPolicyStatementExtension] where an OID is associated with each
application policy.
Note You can view all defined application policy OIDs in the Certificate
Templates console by right-clicking Certificate Templates in the console tree,
and then clicking View Object Identifiers.
Using Custom OIDs If you define a custom application policy OID, you must map application
policies between organizations in the [ApplicationPolicyMappingsExtension]
section. This section uses the same format where the local OID maps to the
OID that the other organization in the qualified subordination uses, as shown in
the following code sample:
[ApplicationPolicyMappingsExtension]
1.3.6.1.4.1.311.21.64 = 1.2.3.4.98
1.3.6.1.4.1.311.21.65 = 1.2.3.4.100
critical = true
Configure Certificate Policies

Introduction You use certificate policies to identify the extent to which your organization
trusts the identity that is presented in a certificate that another organization’s
CA hierarchy issues. Including a certificate policy OID in an issued certificate
indicates that the issued certificate meets the issuance requirements associated
with the certificate policy OID.
Configuring certificate If your organization has an OID that is issued by Internet Assigned Numbers
policies Authority (IANA), you should use the OID tree to identify certificate policies.
By creating a subtree below the OID tree, you can assign a unique OID to each
defined certificate policy. To define certificate policies, create the following
sections in the policy.inf file or in CAPolicy.inf:
[PolicyStatementExtension]
Policies = HighAssurancePolicy, MediumAssurancePolicy,
CRITICAL = FALSE
[HighAssurancePolicy]
OID = 1.3.6.1.4.1.311.21.8.247374.109598.50717.506190032.1.401
[MediumAssurancePolicy]
OID = 1.3.6.1.4.1.311.21.8.247374.109598.50717.506190032.1.402
Note The high assurance and medium assurance certificate policy OIDs are
unique for every forest. To obtain the OIDs used in your forest, right-click
Certificate Templates in the Certificate Templates console, and then click
View Object Identifiers.
Obtaining OIDs from a After you define the OIDs for your organization’s certificate policies, obtain the
partner complementary OIDs from the partner organization. Obtain the partner’s OIDs
because the OIDs differ between the two organizations.
Policy mapping When qualified subordination is configured between two CAs that use
certificate policies, you must map the OIDs between the two organizations in
the policy.inf file that you create. Policy mapping ensures that only authorized
OIDs from a partner organization are allowed in certificates that the partner
organization issues. The policy mapping associates the partner organization’s
OID with an OID that is defined in your organization’s PKI.
The following example shows how certificate policy mapping is configured in
CAPolicy.inf or a policy.inf file.
[PolicyMappingsExtension]
1.3.6.1.4.1.311.21.8.247374.109598.50717.506190032.1.401=
1.3.6.1.4.1.311.21.8.242424.101010.50717.505050505.1.401
1.3.6.1.4.1.311.21.8.247374.109598.50717.506190032.1.402=
1.3.6.1.4.1.311.21.8.242424.101010.50717.505050505.1.402
Policy qualifiers You can provide additional information about the certificate policies that are
implemented at a CA by configuring policy qualifiers. Policy qualifiers are
typically URLs that provide information directly or provide links to information
that describe the purpose of the certificate policy. The following code sample
shows how to define a policy qualifier for the LegalPolicy certificate policy:
[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.microsoft.com/policy/isspolicy.asp"
When a user views the certificate in an application, she initially views the
defined Notice text. She can then view the referenced URL by clicking the
ensuing Details button. This configuration ties the CPS to the issued
certificates.
Practice: Configuring a Policy.inf File to Enforce Namespace

Requirements

Introduction In this practice, you will modify a policy.inf file to enforce the namespace
requirements of your organization.
Scenario You are a network administrator for Northwind Traders. Your organization
requires e-mail communication between the members of the legal department
and your organization’s law firm, Contoso, Ltd.
Contoso’s CA hierarchy To aid in the configuration of certificate trust between the two organizations,
Contoso has provided you the following diagram of its CA hierarchy.
Requirements Northwind Traders will only accept certificates from the Contoso CA hierarchy
that are issued to employees of Contoso.msft. If the name in a certificate is not
from Contoso, the certificate should be rejected. Enforce name constraints at all
times.
Contoso informs you that all e-mail certificates will include the following name
formats in the subject and subject alternative name fields:
! E-mail address. All certificates will include the employee’s e-mail address
in the subject name. The e-mail address will include the e-mail suffix
@contoso.msft.
! Directory name. All certificates will include the employee’s LDAP
distinguished name in the subject alternative name. All accounts that will
participate in the e-mail project are located in the Lawyers organizational
unit of the Contoso.msft domain.
Questions Answer the following questions based on the scenario:

1. What name formats must be included in the policy.inf file to restrict the
namespace that Contoso.msft uses?
The policy.inf file must include e-mail and directory name formats for
the Contoso.msft namespace.
____________________________________________________________
____________________________________________________________
2. In the space provided, complete the required sections of the policy.inf file:
Include = NameConstraintsPermitted
Exclude = NameConstraintsExcluded
Critical = True
____________________________________________________________
____________________________________________________________
____________________________________________________________
DirectoryName = "OU=lawyers,DC=contoso, DC=msft"
email = @contoso.msft
UPN = .contoso.msft
UPN = @contoso.msft
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
DirectoryName = "DC=nwtraders, DC=msft"
email = @nwtraders.msft
UPN = .nwtraders.msft
UPN = @nwtraders.msft
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
Lesson: Implementing Qualified Subordination

Introduction In this lesson, you will learn how to issue a Cross Certification Authority
certificate that implements qualified subordination constraints to a CA in an
external CA hierarchy. You will create a Qualified Subordination Signing
certificate, and then modify the Cross Certification Authority certificate
template to require that a certificate request be signed with the Qualified
Subordination Signing certificate. You will also learn how to publish the Cross
Certification Authority certificate and verify the qualified subordination.
! Create a signing certificate template from an enterprise CA.
! Modify the attributes of a Cross Certification Authority certificate.
! Create a qualified subordination Cross Certification Authority certificate.
! Publish a qualified subordination Cross Certification Authority certificate.
! Verify the qualified subordination.
How to Create a Signing Certificate Template from an Enterprise CA

Introduction To request a Cross Certification Authority certificate, the requestor must sign
the certificate request with a signing certificate that includes the Qualified
Subordination application policy OID. No default certificate template includes
this application policy OID. You must configure a custom version 2 certificate
template that includes the Qualified Subordination OID in a certificate’s
application policy extension.
Procedure for The first step in generating a Qualified Subordination certificate is to create a
duplicating a certificate version 2 certificate template by duplicating the Enrollment Agent certificate
template. To duplicate a certificate:
1. Open the Certificate Templates console.
2. In the details pane, right-click Enrollment Agent, and then click Duplicate
Template.
3. In the Properties of New Template dialog box, on the General tab, in the
Template display name box, type Qualified Subordination and then click
OK.
Procedure for defining After you create the Qualified Subordination certificate template, you define the
the certificate purpose purpose of the Qualified Subordination certificate and the CSP. To define the
and CSP purpose and CSP:
1. In the details pane, double-click Qualified Subordination.
2. In the Qualified Subordination Properties dialog box, on the Request
Handling tab, click CSPs.
3. In the CSP Selection dialog box, click Requests must use one of the
following CSPs.
4. In the CSPs list, select Microsoft Enhanced Cryptographic Provider
v1.0, and then click OK.
5. In the Qualified Subordination dialog box, on the Security tab, assign
Read and Enroll permissions to a global group that contains the Qualified
Subordination signing agents that you defined.
6. Click Apply.
Procedure for removing After you define the CSP and permissions, remove the Certificate Request
the Certificate Request Agent application policy from the certificate template. To remove the
Agent application policy Certificate Request Agent application policy:
1. In the Qualified Subordination Properties dialog box, on the Extensions
tab, in the Extensions included in this template list, select Application
Policies, and then click Edit.
2. In the Edit Application Policies Extension dialog box, in the Application
policies list, select Certificate Request Agent, and then click Remove.
3. In the Edit Application Policies Extension dialog box, click OK.
Procedure for adding After you remove the Certificate Request Agent application policy from the
the Qualified certificate template, you can add the Qualified Subordination application policy
Subordination OID to the certificate template in the following way:
application policy OID
1. In the Qualified Subordination Properties dialog box, on the Extensions
tab, in the Extensions included in this template list, select Application
Policies, and then click Edit.
2. In the Edit Application Policies Extension dialog box, click Add.
3. In the Add Application Policy dialog box, in the Application policies list,
select Qualified Subordination, and then click OK.
4. In the Edit Application Policies Extension dialog box, ensure that
Qualified Subordination appears in the Application policies list, and then
click OK.
5. In the Qualified Subordination Properties dialog box, click OK.
Note You can substitute a custom application policy for the Qualified
Subordination application policy OID by clicking New in the Add Application
Policy dialog box.
Procedure for The final step in designing the Qualified Subordination certificate template is to
publishing the publish the certificate template on an enterprise CA in your organization’s CA
certificate template hierarchy. Publishing the certificate template will make the certificate template
available to potential Qualified Subordination signing agents. To publish the
certificate template:
1. Ensure you are logged on as a CA administrator, and then open the
Certification Authority MMC.
2. In the Certification Authorities console, in the console tree, expand
CAName (where CAName is the logical name of your CA), and then click
Certificate Templates.
3. In the console tree, right-click Certificate Templates, click New, and then
click Certificate Template to Issue.
4. In the Enable Certificate Templates dialog box, select Qualified
Subordination, and then click OK.
5. In the details pane, verify that Qualified Subordination appears.
6. Have the Qualified Subordination signing agents acquire a Qualified
Subordination certificate.
Steps for Modifying a Cross Certification Authority Certificate

Template

Introduction After you create the Qualified Subordination certificate template, modify the
Cross Certification Authority certificate template to ensure that it requires that
the requestor have a Qualified Subordination application policy in the signing
certificate.
Procedure for modifying To make the initial modifications to the Cross Certification Authority certificate
issuance requirements template, the certificate template manager must modify the issuance
requirements. To modify the issuance requirements:
1. Open the Certificate Templates console.
2. In the console tree, click Certificate Templates.
3. In the details pane, double-click Cross Certification Authority.
4. In the Cross Certification Authority Properties dialog box, on the
Issuance Requirements tab, ensure that one authorized signature is
required.
5. In the Policy type required in signature drop-down list, select Application
Policy.
6. In the Application policy drop-down list, select Qualified Subordination.
Note If you defined a custom application policy for the Qualified

Subordination certificate template, select the name that is assigned to the
custom application policy.
7. Click OK.
Procedure for To deploy a certificate, you must be running Windows Server 2003, Enterprise
publishing the certificate Edition because only Windows Server 2003 enterprise servers support version 2
template certificate templates. To configure Windows Server 2003, Enterprise Edition to
issue Qualified Subordination Signing and Cross Certification Authority
certificate templates:
1. Log on as a CA administrator on a computer running Windows Server 2003,
Enterprise Edition that has Certificate Services configured as an enterprise
CA.
3. In the console tree, expand CAName (where CAName is the name of your
CA).
4. In the console tree, right-click Certificate Templates, point to New, and
5. In the Enable Certificate Templates dialog box, in the list of available
templates, click Cross Certification Authority, and then click OK.
6. In the details pane, ensure that Cross Certification Authority appears.
7. Close the Certification Authority console.
Demonstration: Creating Certificate Templates for Qualified

Subordination

Introduction Use the following procedure to modify, create, and publish the certificate
templates that are necessary for qualified subordination.
Procedure for creating a The first step in creating a Qualified Subordination Signing certificate is to
Qualified Subordination duplicate the Enrollment Agent certificate template. To create the Qualified
Signing certificate Subordination Signing certificate template:
template
1. Open the Certificate Templates (Certtmpl.msc) console.
2. In the details pane, right-click Enrollment Agent, and then click Duplicate
Template.
3. In the Properties of New Template dialog box, on the General tab, in the
Template display name box, type Qualified Subordination Signing and
then click OK.
Note To create the Qualified Subordination Signing certificate template, you

must have the permissions to create and modify certificate templates.
Procedure for modifying After creating the version 2 certificate template, make the following
the attributes of the modifications to the certificate template attributes:
1. In the details pane, double-click Qualified Subordination Signing.
2. On the Extensions tab, select Application Policies, and then click Edit.
3. In the Edit Application Policies Extension dialog box, select Certificate
Request Agent, and then click Remove.
4. In the Edit Application Policies Extension dialog box, click Add.
5. In the Add Application Policy dialog box, select Qualified Subordination
and then click OK.
6. In the Edit Application Policies Extension dialog box, click OK.
Note You can increase the security of the Qualified Subordination Signing
certificate by using a custom application policy OID and then configuring the
Cross Certification Authority certificate template to require the custom OID.
Procedure for After you create the Qualified Subordination Signing certificate template, and,
publishing the certificate if necessary, have modified the template, you must publish the two certificate
template templates on an enterprise CA in your CA hierarchy. To publish the certificate
template:
2. In the console tree, expand CAName (where CAName is the name of the
CA).
3. In the console tree, right-click Certificate Templates, click New, and then
click Certificate Template to Issue.
4. In the Enable Certificate Templates dialog box, click Cross Certification
Authority, press CTRL and click Qualified Subordination Signing, and
then click OK.
5. In the details pane, verify that Cross Certification Authority and
Qualified Subordination Signing appear.
Important Ensure that you publish both the Cross Certification Authority
and Qualified Subordination Signing certificate templates.
6. Close the Certification Authority console.

How to Create a Cross Certification Authority Certificate

Introduction After you collect and configure all required files, you can create the Cross
Certification Authority certificate.
Steps to create a Cross To create a Cross Certification Authority certificate:
certificate 1. Acquire the CA certificate of the CA that you want to issue the Cross
Certification Authority certificate for.
2. Create a policy.inf file.
3. Copy the partner’s CA certificate and policy.inf file to a common folder.
The qualified subordination process does not require that the CA certificate
and policy.inf file exist in a specific folder. But saving both files in the same
folder simplifies the process.
4. At a command prompt, type certutil –policy to create the certificate request
file that enforces all of the qualified subordination constraints that are
defined in the policy.inf file.
5. When requested, the user who created the Cross Certification Authority
request must provide the CA certificate, the policy.inf file, and the Qualified
Subordination Signing certificates. The Qualified Subordinate Signing
certificate must include the application policy OID that the Cross
Certification Authority certificate template requires.
6. Save the resulting certificate request file when the certutil –policy
command is completed.
7. A user who has the permissions to request a Cross Certification Authority
certificate must submit the Cross Certification Authority certificate request
in the Certification Authority console by right-clicking the CA in the
console tree, and then clicking Submit certificate request.
How to Publish a Cross Certification Authority Certificate

Introduction The Cross Certification Authority certificate must exist in the Active Directory
database in the organization that uses the certificate to build certificate chains.
The publication of Cross Certification Authority certificates depends on the
cross-certification model of your organization.
Standard cross In this model, only two organizations are involved in the Cross Certification
certification Authority project. Each organization will issue the other organization a Cross
Certification Authority certificate that contains the qualified subordination
constraints that are required by the issuing organization.
When one organization issues a Cross Certification Authority certificate to the
other organization, the Cross Certification Authority certificate is automatically
published to Active Directory based on the default publication settings that are
defined in the Cross Certification Authority certificate template.
Bridge cross In this model, the organizations that participate in the certificate trust issue and
certification receive Cross Certification Authority certificates with the Bridge CA. Cross
Certification Authority certificates are not exchanged directly between the
organizations that participate in the bridge model.
To build certificate chains, each organization requires that the certificates issued
by the Bridge CA are published in that organization’s Active Directory
database.
Procedure for To publish the Cross Certification Authority certificates that were issued by the
publishing Cross Bridge CA:
certificates 1. On the Bridge CA, copy all issued Cross Certification Authority certificates
to a common share.
2. On each forest that is connected to the Bridge CA, run certutil –dspublish
–f certificate1.crt CrossCA (where certificate1.crt is the first Cross
Certification Authority certificate).
3. Repeat the process for all certificates that the Bridge CA issues to all forests
that are connected to the Bridge CA.
How to Verify Qualified Subordination

Introduction The final step in configuring qualified subordination between two CAs is to
verify that the Cross Certification Authority certificate was successfully saved
in Active Directory. Verify that the certificate is published in the configuration
naming context of your Active Directory and that the Cross Certification
Authority certificate is chained to your organization’s root CA.
Procedure for verifying You can use certutil.exe in the following way to verify the existence of the
qualified subordination Cross Certification Authority certificate:
1. Open a command prompt.
2. At the command prompt, type certutil -viewstore "CN=CAName,
CN=AIA,CN=Public Key Services, CN=Services,
CN=Configuration,DC=ForestRootDN?crossCertificatePair
where CAName is the name of the CA that the Cross Certification Authority
certificate is issued to, and ForestRootDN is the LDAP distinguished name
of the forest that issued the Cross Certification Authority certificate.
Warning If the Cross Certification Authority certificate does not appear,

verify the syntax of the certutil command.
3. In the View Certificate Store dialog box, select the Cross Certification
Authority certificate that you want to view, and then click View Certificate.
Note Multiple Cross Certification Authority certificates can exist when a

Cross Certification Authority certificate is renewed or when multiple Cross
Certification Authority certificates are issued for different projects or
purposes.
4. In the Certificate dialog box, on the Certification Path tab, ensure that the
certification path shows that the CAName certificate is chained to your
organization’s root CA certificate.
Lab A: Implementing a Bridge CA

! Create and issue a Qualified Subordination Signing Certificate.
! Configure a policy.inf file to enforce qualified subordination constraints.
! Create a Cross Certification Authority certificate request.
! Verify qualified subordination constraints.
! Publish Bridge CA certificates in Active Directory.
comply with Microsoft security recommendations. For instance, this lab does
not comply with the recommendation that role separation should be enabled on
the Bridge CA for PKI management.

domain.
! Completed the instructor demonstration in Module 8, “Creating Certificate
Templates for Qualified Subordination.”
! Knowledge about qualified subordination constraints.
! Knowledge about configuring qualified subordination in a
Windows Server 2003 environment.
Additional information For more information about implementing qualified subordination, read the
white paper, Planning and Implementing Qualified Subordination Using
Windows Server 2003, Enterprise Edition under Additional Reading on the
Estimated time to
complete this lab:
90 minutes
Scenario All organizations in the classroom must configure certificate trust between the
organizations by using the certificate bridge service that Northwind Traders
offers.
To enforce the qualified subordination constraints, Northwind Traders and its
partners will implement qualified subordination between the partners’ issuing
CAs and the bridge CA that exists at Northwind Traders.
The finalized bridge CA configuration for the classroom is based on the
following diagrams. Each subordinate enterprise CA will issue a Cross
Certification Authority certificate to the bridge CA on the instructor computer
and will be issued a Cross Certification Authority certificate from the
BridgeCA.
Note The classroom does not require deployment of all 24 computers. If there
are fewer than 24 computers, each pair of computers can be cross-certified with
the Bridge CA, thereby enabling certificate trust to occur between all
organizations in the classroom.
Exercise 1
Creating a Qualified Subordination Signing Certificate Template
In this exercise, you will create a Qualified Subordination Signing certificate that an administrator
uses to sign the Cross Certification Authority certificate request.
Scenario
A Cross Certification Authority certificate request must be signed with a certificate with the
Qualified Subordination application policy OID. You must create and issue these certificates to the
users who will request the Qualified Subordination Signing certificates.
domain)
Templates console. b. If the Certificate Templates dialog box appears, click OK.
template named Qualified Enrollment Agent, and then click Duplicate Template.
Subordination Signing b. In the Properties of New Template dialog box, on the General tab, in
based on the Enrollment the Template display name box, type Qualified Subordination
Agent certificate template. Signing and then click OK.
4. Disable all CSPs for the a. In the details pane, double-click Qualified Subordination Signing.
Qualified Subordination b. On the Request Handling tab, click CSPs.
Signing certificate except
for the Microsoft Enhanced c. In the CSP Selection dialog box, in the CSPs list, select only
Cryptographic Provider v1.0 Microsoft Enhanced Cryptographic Provider v1.0, and then click
CSP. OK.
d. In the Qualified Subordination Signing Properties dialog box, click
Apply.
5. Select the following a. On the Issuance Requirements tab, click CA certificate manager
issuance requirements: approval.
• CA certificate manager b. Under Require the following for reenrollment, click Valid existing
approval certificate, and then click Apply.
• Valid existing certificate
(continued)
6. Remove all existing a. On the Extensions tab, select Application Policies, and then click
application policy Edit.
extensions, and add the b. In the Edit Application Policies Extension dialog box, select
Qualified Subordination Certificate Request Agent, and then click Remove.
application policy.
c. Click Add.
d. In the Add Application Policy dialog box, in the Application policies
list, select Qualified Subordination, and then click OK.
e. In the Edit Application Policies Extension dialog box, click OK.
f. On the Extensions tab, click OK.
7. View the Issuance a. In the details pane, double-click Cross Certification Authority.
Requirements tab for the b. In the Cross Certification Authority Properties dialog box, click the
Cross Certification Issuance Requirements tab.
Authority certificate
template.
What issuance requirements exist for the Cross Certification Authority certificate template?
The certificate request must be signed by a certificate with the Qualified Subordination application
policy.
How can you increase the security for Cross Certification Authority certificates?
You can implement a custom OID in the application policy of the Qualified Subordination certificate
template, and require that the custom application policy OID be used to sign the certificate request for
the Cross Certification Authority certificate.
7. (continued) c. In the Cross Certification Authority Properties dialog box, click

Cancel.
(continued)
9. Log on using your domain " Log on to your computer by using the following credentials:
administration account and • User name: CAadmin1
password.
• Domain: Domain
10. Publish the Qualified a. On the Start menu, click Administrative Tools, and then click
Subordination Signing and Certification Authority.
the Cross Certification b. In the console tree, expand DomainCA, and then click Certificate
Authority certificate Templates.
templates on the
DomainCA. c. Right-click Certificate Templates, click New, and then click
d. In the Enable Certificate Templates dialog box, select the following
certificate templates:
• Cross Certification Authority
• Qualified Subordination Signing
e. In the Enable Certificate Templates dialog box, click OK.
f. In the details pane, ensure that the Cross Certification Authority and
Qualified Subordination Signing certificate templates appear.
g. Close the Certification Authority console.
Exercise 2
Configuring the Policy.inf File
Introduction
In this exercise, you will configure the policy.inf file to enforce the required qualified subordination
constraints for the bridge CA deployment.
Scenario
Your organization wants to participate in the federated bridge project. To limit the certificates that
are trusted from other organizations, you must implement the following qualified subordination
constraints in the policy.inf file.
Qualified subordination constraints Required settings
Basic Constraints Limit to two CAs below your CA and inhibit policy mapping
Name Constraints Allow any namespace except your organization’s namespace
Certificate Policies Allow only certificates with the Medium Assurance certificate
policy, which indicates that the certificates were issued in a face-to-
face meeting
Application Policies Accept only certificates for secure e-mail, client authentication, and
server authentication from the partner organizations
Setup
Use the following table to help you complete the lab.
Computer DNS domain Forest name
Vancouver adatum.msft DC=adatum,DC=msft

Perth fabrikam.msft DC=fabrikam,DC=msft
Lisbon lucernepublish.msft DC=lucernepublish,DC=msft
Santiago litwareinc.msft DC=litwareinc,DC=msft
Singapore tailspintoys.msft DC=tailspintoys,DC=msft
Tunis wingtiptoys.msft DC=wingtiptoys,DC=msft
Miami thephonecompany.msft DC=thephonecompany,DC=msft
Suva cpandl.msft DC=cpandl,DC=msft
Moscow adventureworks.msft DC=adventureworks,DC=msft
Montevideo blueyonderair.msft DC=blueyonderair,DC=msft
Tokyo woodgrovebank.msft DC=woodgrovebank,DC=msft
Nairobi treyresearch.msft DC=treyresearch,DC=msft
administration account and • User name: Student1
password.
domain)
2. Clear the Read-only check a. Open C:\moc\2821\labfiles\module8.

box on the C:\moc\2821\ b. In the C:\moc\2821\labfiles\module8 folder, right-click Domain-to-
labfiles\module8\ Bridge.inf, and then click Properties.
Domain-to-Bridge.inf file.
c. In the Domain-to-Bridge.inf Properties dialog box, clear the Read-
only check box, and then click OK.
3. Update the name constraints a. In the C:\moc\2821\labfiles\module8 folder, double-click Domain-to-

in the Domain-to-Bridge.inf Bridge.inf.
file to reflect your b. On the Edit menu, click Replace.
organization’s DNS domain
name and forest LDAP c. In the Replace dialog box, in the Find what box, type DNSDomain
distinguished name. d. In the Replace with box, type DNSDomain (where DNSDomain is the
DNS name of your Active Directory domain from the table at the
beginning of the exercise), and then click Replace All.
e. In the Replace dialog box, in the Find what box, type ForestName
f. In the Replace with box, type ForestName (where ForestName is the
DNS name of your Active Directory forest from the table at the
beginning of the exercise), and then click Replace All.
g. In the Replace dialog box, click Cancel.
h. Minimize Domain-to-Bridge.inf – Notepad.
(continued)
4. Update the certificate a. Click Start, click Run, type Certtmpl.msc and then click OK.
policies in the Domain-to- b. If the Certificate Templates dialog box appears, click Yes.
Bridge.inf file to reflect your
organization’s Medium c. If the Certificate Templates message box appears, click OK.
Assurance certificate policy d. In the console tree, right-click Certificate Templates, and then click
OID. View Object Identifiers.
e. In the View Object Identifiers dialog box, in the Available object
identifiers list, select Medium Assurance, and then click Copy
Object Identifier.
f. In the View Object Identifiers dialog box, click Close.
g. Close Certificate Templates.
h. In the taskbar, click Domain-to-Bridge.inf – Notepad.
i. On the Edit menu, click Replace.
j. In the Replace dialog box, in the Find what box, type
MyMediumOID
k. In the Replace dialog box, right-click Replace with, and then click
Paste.
l. Click Replace All.
m. Click Cancel.
n. Minimize Domain-to-Bridge.inf – Notepad.
5. Connect to the London a. On the Start menu, point to All Programs, point to Accessories, point
computer by using Remote to Communications, and then click Remote Desktop Connection.
Desktop Connection as b. In the Remote Desktop Connection dialog box, in the Computer box,
Administrator with a type London and then click Connect.
password of P@ssw0rd.
c. In the Log On to Windows dialog box, log on by using the following
credentials:
• Log on to: Nwtraders
d. In the Log On to Windows dialog box, click OK.
6. Connect to the London a. Click Start, click Run, type Certtmpl.msc and then click OK.
computer to copy the b. In the console tree, right-click Certificate Templates, and then click
Medium Assurance OID for View Object Identifiers.
the Northwind Traders
forest to the Windows c. In the View Object Identifiers dialog box, in the Available object
clipboard. identifiers list, select Medium Assurance, and then click Copy
Object Identifier.
d. Minimize the Remote Desktop Connection window.
(continued)
7. Replace all occurrences of a. In the taskbar, click Domain-to-Bridge.inf.

BridgeMediumOID in the b. On the Edit menu, click Replace.
Domain-to-Bridge.inf file
with the Medium Assurance c. In the Replace dialog box, in the Find what box, type
OID from the Nwtraders BridgeMediumOID
forest. d. Clear the contents of the Replace with box.
e. Right-click Replace with, and then click Paste.
f. Click Replace All.
g. Click Cancel.
What name constraints are defined in the Domain-to-Bridge.inf file?
The Domain-to-Bridge.inf file excludes your domain’s name space in the defined name constraints.
What application policies are defined in the Domain-to-Bridge.inf file?
Secure e-mail, client authentication, and server authentication application policies are defined in the
file.
8. Save any changes and close a. On the File menu, click Save.
Domain-toBridge.inf – b. Close the Domain-toBridge.inf – Notepad window.
Notepad.
9. In the Remote Desktop a. In the taskbar, click London - Remote Desktop.
Connection, close all open b. In the View Object Identifiers dialog box, click Close.
windows and then log off
the network. c. Close Certificate Templates.
d. On the Start menu, click Log Off.
e. In the Log Off Windows dialog box, click Log Off.
Exercise 3
Requesting a Qualified Subordination Signing Certificate
In this exercise, you will request a Qualified Subordination Signing certificate so that you can issue
a Cross Certification Authority certificate to the Bridge CA that is located on the instructor’s
computer.
Scenario
Now that the Qualified Subordination Signing certificate template is configured and published on
the enterprise subordinate CA, a member of the Domain Admins group must request a Qualified
Subordination Signing certificate.
on to the network with your credentials:
domain administrator • User name: Student1
account.
domain)
2. Request a Qualified a. Open Internet Explorer.

Subordination Signing b. In Internet Explorer, open the URL http://WebServer/certsrv (where
certificate by using Web- WebServer is the fully qualified domain name of your domain
based enrollment. controller).
• Certificate Template: c. On the Welcome page, click Request a certificate.
Qualified
Subordination Signing d. On the Request a Certificate page, click advanced certificate
request.
• Friendly Name: QS
Signing e. On the Advanced Certificate Request page, click Create and submit
f. On the Advanced Certificate Request page, in the Certificate
Template drop-down list, select Qualified Subordination Signing.
g. On the Advanced Certificate Request page, in the Friendly name
box, type QS Signing and then click Submit.
h. In the Potential Scripting Violation dialog box, click Yes to allow the
i. On the Certificate Pending page, record the certificate request ID in
the following space:
• Request ID: _______________________
j. Close Internet Explorer.
(continued)
3. Log on to the network as a " Log on to the domain by using the following credentials:
member of the certificate • User name: Certadmin2
administrators.
• Domain: Domain
b. In the Microsoft Certificate Services message box, click OK.
and then click OK.
5. Issue the pending Qualified a. In the Certification Authority console, expand DomainCA, and then
Subordination Signing click Pending Requests.
certificate request and then b. In the details pane, select all pending certificate requests.
log off the network.
c. Right-click the pending certificate requests, point to All Tasks, and
then click Issue.

http://WebServer/certsrv and b. In Internet Explorer, open the URL http://WebServer/certsrv.
perform the following
actions: c. On the Welcome page, click View the status of a pending certificate
request.
• Click View the Status
of a Pending d. On the View the Status of a Pending Certificate Request page, click
Certificate Request Qualified Subordination Signing Certificate (Date and Time).
• Click Qualified e. On the Certificate Issued page, click Install this certificate.
Subordination Signing f. In the Potential Scripting Violation dialog box, click Yes to allow the
Certificate (Date and Web site to add a certificate to your computer.
Time) g. Ensure that the Certificate Installed page appears, which indicates that
• Click Install this the certificate has been installed successfully.
certificate h. Close Internet Explorer.
i. Close all open windows.
Exercise 4
Generating the Cross Certification Authority Certificate for the
Bridge CA
In this exercise, you will generate the Cross Certification Authority certificate for the Bridge CA,
and then inspect the certificate properties.
Scenario
You must issue a Cross Certification Authority certificate to the Bridge CA to enforce the qualified
subordination constraints that are defined in the Domain-to-Bridge.inf policy file.
1. Open the a. Click Start, click Run, type \\London\Certenroll and then click OK.
\\London\Certenroll share b. In the Connect to London.nwtraders.msft dialog box, enter the
by using the following following credentials:
credentials:
• User name:
Administrator • Password: P@ssw0rd
• Password: P@ssw0rd c. In the Connect to London.nwtraders.msft dialog box, click OK.
2. Copy the a. In the \\London\Certenroll window, right-click

London.nwtraders.msft London.nwtraders.msft_bridgeCA.crt, and then click Copy.
_bridgeCA.crt file to b. Open C:\moc\2821\labfiles\module8.
C:\moc\2821\labfiles\
module8. c. Right-click C:\moc\2821\labfiles\module8, and then click Paste.
d. Close all open windows.
3. Start the Cross Certification a. Open a command prompt.

Authority certificate request b. At the command prompt, do the following:
process by typing certreq –
policy in the C:\moc\2821\ • Type C: and then press ENTER.
labfiles\module8 folder. • Type cd \moc\2821\labfiles\module8 and then press ENTER.
• Type certreq –policy and then press ENTER.
(continued)
4. In the Certreq.exe wizard, a. In the Open Request File dialog box, in the Files of type drop-down
provide the following list, select Certificate Files (*.cer,*.crt,*.der).
information: b. In the File name box, type C:\moc\2821\labfiles\module8 and then
• Request file: click Open.
London.nwtraders.msft_ c. Select London.nwtraders.msft_BridgeCA.crt, and then click Open.
BridgeCA.crt
d. In the Open Inf File dialog box, select Domain-to-Bridge.inf, and
• .inf file: Domain-to- then click Open.
Bridge.inf
e. In the Certificate List dialog box, select your QS Signing certificate,
• Enrollment Registration and then click OK.
Agent certificate: QS
Signing certificate f. In the Save Request dialog box, in the File name box, type
CrossCA.req and then click Save.
• Request file name:
CrossCA.req g. Close the command prompt.
5. In the Certification a. On the Start menu, point to Administrative Tools, and then click
Authority console, submit Certification Authority.
the CrossCA.req certificate b. In the console tree, right-click DomainCA, point to All Tasks, and then
request file, and then save click Submit new request.
the resulting certificate as
BridgeCA.cer. c. In the Open Request File dialog box, select CrossCA.req, and then
click Open.
d. In the Save Certificate dialog box, in the File name box, type
BridgeCA.cer and then click Save.
on to the network with your credentials:
domain administrator • User name: Student1 (on the domain controller) or Student2 (on
account. the member server)
• Domain: Domain
7. Verify that the BridgeCA a. Open a command prompt.

certificate is published by b. At the command prompt, type Certutil –viewstore
typing Certutil –viewstore "CN=BridgeCA,CN=AIA,CN=Public Key Services,
"CN=BridgeCA,CN=AIA, CN=Services,CN=Configuration,
CN=Public Key Services, DC=Domain,DC=msft?crossCertificatePair” and then press ENTER.
CN=Services,
CN=Configuration, c. In the View Certificate Store dialog box, click View Certificate.
DC=Domain,DC=
msft?crossCertificatePair"
at a command prompt.
(continued)
Do the certificate purposes match the application policies that are defined in the Domain-to-Bridge.inf file?
Yes. The purposes are: Protects e-mail messages (secure email), Ensures the identity of a remote
computer (server authentication), and Proves your identity to a remote computer (client
authentication).
7. (continued) d. In the Certificate dialog box, click the Details tab.
What name constraints are defined in the Cross Certification Authority certificate? Do these name constraints
match those that are defined in the Domain-to-Bridge.inf file?
Yes. The certificate shows name constraint exclusions for your namespace as defined in the Domain-to-
Bridge.inf file.
What policy mappings are defined in the Cross Certification Authority certificate? Do these policy mappings
match the certificate policy extensions in the Domain-to-Bridge.inf file?
The certificate shows policy mapping where the OID for Medium Assurance in your organization
maps to the Medium Assurance OID for Northwind Traders.
7. (continued) e. In the Certificate dialog box, click the Certification Path tab.
(continued)
What is the certification path for the certificate?
RootCA # DomainCA # BridgeCA (where RootCA is the NetBIOS name of your offline root CA and
Domain is the NetBIOS name of your domain)
7. (continued) f. In the Certificate dialog box, click OK.

g. In the View Certificate Store dialog box, click OK.
Exercise 5
Modifying the Policy.inf File on the Bridge CA
In this exercise, you will generate a Cross Certification Authority certificate on the Bridge CA for
your organization’s subordinate enterprise CA.
Scenario
After you issue a Cross Certification Authority certificate on the Bridge CA from your subordinate
enterprise CA, the Bridge CA must now issue a Cross Certification Authority certificate to your
organization’s subordinate enterprise CA.
Important: Perform this procedure on the member server for your domain.
your domain administration • User name: Student2
account.
domain)
2. Copy the Medium a. Click Start, click Run, type Certtmpl.msc and then click OK.
Assurance certificate policy b. In the console tree, right-click Certificate Templates, and then click
OID for your domain to the View Object Identifiers.
Windows clipboard.
c. In the View Object Identifiers dialog box, in the Available object
Object Identifier.
d. In the View Object Identifiers dialog box, click Close.
e. Close Certificate Templates.
3. Connect to the London a. On the Start menu, point to All Programs, point to Accessories, point
computer by using Remote to Communications, and then click Remote Desktop Connection.
Desktop Connection to log b. In the Remote Desktop Connection dialog box, in the Computer box,
on as Administrator with a type London and then click Connect.
c. In the Log On to Windows dialog box, log on by using the following
credentials:
d. In the Log On to Windows dialog box, click OK.
(continued)
4. Copy C:\moc\2821\ a. Open C:\moc\2821\labfiles\module8.

labfiles\module8\ b. In the C:\moc\2821\labfiles\module8 folder, double-click Bridge-to-
Bridge-to-Domain.inf to Domain.inf.
C:\moc\2821\labfiles\
module8\Domain.inf. c. On the File menu, click Save As.
d. In the Save-as dialog box, in the File name box, type Domain.inf
(where Domain is the NetBIOS name of your domain).
e. In the Save as type drop-down list, select All Files, and then click
Save.
5. In the Domain.inf file, a. On the Edit menu, click Replace.

replace MyMediumOID b. In the Replace dialog box, in the Find what box, type
with the Medium Assurance MyMediumOID
certificate policy OID for
your forest. c. Right-click Replace with, and then click Paste.
d. Click Replace All.
e. Click Cancel.
f. Minimize the Domain.inf – Notepad window
6. Copy the Medium a. Click Start, click Run, type Certtmpl.msc and then click OK.
Assurance certificate policy b. In the console tree, right-click Certificate Templates, and then click
OID for the Northwind View Object Identifiers.
Traders domain to the
Clipboard. c. In the View Object Identifiers dialog box, in the Available object
Object Identifier.
d. In the View Object Identifiers dialog box, click Close.
7. In the Domain.inf file, a. On the taskbar, click Domain.inf.

replace BridgeMediumOID b. On the Edit menu, click Replace.
with the Medium Assurance
certificate policy OID for c. In the Replace dialog box, in the Find what box, type
the Northwind Traders BridgeMediumOID
forest. d. Clear the contents of the Replace with box.
e. Right-click the Replace with box, and then click Paste.
f. Click Replace All.
g. Click Cancel.
8. Save any changes and then a. On the File menu, click Save, and then close the window.
close Domain.inf. b. Close all open windows in the Remote Desktop Connection.
Important: Do not disconnect or log off from the Remote Desktop Connection.
Exercise 6
Creating the Cross Certification Authority Certificate
In this exercise, you will create the Cross Certification Authority certificate for your enterprise
subordinate CA on the Bridge CA.
Scenario
You must now create a Cross Certification Authority certificate for your subordinate enterprise CA
that implements the qualified subordination constraints that are implemented in the Domain.inf
information file.
1. Ensure that you are still " Ensure that you are still connected to the London computer using the
connected to London using Remote Desktop Connection with the following credentials:
the Remote Desktop • User name: Administrator
Connection.
2. Request a Qualified a. Click Start, click Run, type Certmgr.msc and then click OK.
Subordination Signing b. In the console tree, expand Personal, and then click Certificates.
certificate with a friendly
name of Computer QS c. In the console tree, right-click Certificates, point to All Tasks, and
Signing then click Request New Certificate.
d. On the Certificate Request Wizard page, click Next.
e. On the Certificate Types page, in the Certificate Types list, select
Qualified Subordination Signing, and then click Next.
Friendly name box, type Computer QS Signing (where Computer is
the NetBIOS name of your computer), and then click Next.
Finish.
i. Close the Certificates – Current User console.
3. Copy your domain’s a. Open \\Dcname\certenroll (where Dcname is the NetBIOS name of the
enterprise CA’s subordinate domain controller in your domain).
Certification Authority b. In the \\Dcname\certenroll window, right-click
certificate to the dcname.Domain.msft_DomainCA.crt (where Domain is the NetBIOS
C:\moc\2821\labfiles\ name of your domain), and then click Copy.
module8 folder.
c. Open C:\moc\2821\labfiles\module8.
d. Right-click C:\moc\2821\labfiles\module8, and then click Paste.
e. Close all open windows.
(continued)
4. Start the Cross Certification a. Open a command prompt.

Authority certificate request b. At the command prompt, do the following:
process by typing certreq –
policy in the • Type C: and then press ENTER.
C:\moc\2821\labfiles\ • Type cd \moc\2821\labfiles\module8 and then press ENTER.
module8 folder. • Type certreq –policy and then press ENTER.
5. In the Certreq.exe prompts, a. In the Open Request File dialog box, in the Files of type drop-down
provide the following list, select Certificate Files (*.cer,*.crt,*.der).
information: b. In the File name box, type C:\moc\2821\labfiles\module8 and then
• Request file: click Open.
Dcname.Domain.msft_ c. Select Dcname.Domain.msft_DomainCA.crt, and then click Open.
DomainCA.crt
d. In the Open Inf File dialog box, select Domain.inf, and then click
• Inf file: Domain.inf Open.
• Enrollment Registration e. In the Certificate List dialog box, select the certificate with the
Agent certificate: friendly name of Computer QS Signing, and then click OK.
Computer QS Signing
certificate f. In the Save Request dialog box, in the File name box, type
Domain.req (where Domain is the NetBIOS name of your domain),
• Request file name: and then click Save.
Domain.req
g. Close the command prompt.
6. In the Certification a. On the Start menu, point to Administrative Tools, and then click
Authority console, submit Certification Authority.
the Domain.req certificate b. In the console tree, right-click BridgeCA, point to All Tasks, and then
request file and then save click Submit new request.
the resulting certificate as
Domain.cer. c. In the Open Request File dialog box, select Domain.req, and then
click Open.
d. In the Save Certificate dialog box, in the File name box, type
Domain.cer and then click Save.
7. Log off the London a. Close all open windows.

computer, which terminates b. On the Start menu, click Log Off.
the Remote Desktop
Console. c. In the Log Off Windows dialog box, click Log Off.
8. Close all open windows and " Close all open windows and then log off.
Wait until all student teams reach this point in the lab before you continue.
Exercise 7
Publishing the Bridge CA Cross CA Certificates
In this exercise, you will publish the Cross Certification Authority certificates that the Bridge CA
issued to each subordinate enterprise CA in the classroom. The publication ensures that your
organization will recognize certificates that meet the qualified subordination constraints from all
other organizations that participate in the Bridge CA hierarchy.
Scenario
Now that your organization has successfully issued a Cross Certification Authority certificate to the
Bridge CA, you must publish all Cross Certification Authority certificates that the Bridge CA issues
to participating organizations to your organization’s Active Directory directory service.
Important: The instructor will perform this procedure on the London computer.
1. Create and share a subfolder a. Open C:\moc\2821\labfiles\module8.

named BridgeCerts. b. Create a subfolder named BridgeCerts.
c. Right-click BridgeCerts, and then click Sharing and Security.
d. In the BridgeCerts Properties dialog box, click Share this folder, and
then click OK.
2. Move all Domain.cer files to " Move all Domain.cer (where Domain is the NetBIOS name of each
the BridgeCerts folder. student domain) files to the BridgeCerts folder.
3. Create and share a subfolder a. Ensure that you are in the C:\moc\2821\labfiles\module8 window.
named ClientCerts. b. Create a subfolder named ClientCerts.
c. Right-click ClientCerts, and then click Sharing and Security.
d. In the ClientCerts Properties dialog box, click Share this folder, and
then click Permissions.
e. In the Permissions for ClientCerts dialog box, select Everyone, click
Change, and then click OK.
f. In the ClientCerts Properties dialog box, on the Security tab, assign
the Users group Modify permissions, and then click OK.
g. Close the C:\moc\2821\labfiles\module8 window.
(continued)
4. Log on using your domain " Log on to the domain by using the following credentials:
administrator account. • User name: Student1 (on the domain controller) or Student2 (on
the member server)
domain)
5. Publish all Cross a. Open a command prompt.

Certification Authority b. At the command prompt, do the following:
certificates that the Bridge
CA issued and stored in • Type Net use x: \\London\Bridgecerts /user:administrator
\\London\Bridgecerts to P@ssw0rd and then press ENTER.
Active Directory by using • Type x: and then press ENTER.
the following command: • Type dir and then press ENTER.
• Certutil –dspublish –f c. Type the following command for every Domain.cer file that exists in
Domain.cer CrossCA the \\London\Bridgecerts share, and then press ENTER.
• Certutil –dspublish –f Domain.cer CrossCA (where Domain is
the NetBIOS name of each domain in the classroom).
d. Repeat the command until all Cross Certification Authority certificates
that the Bridge CA issued are published in Active Directory.
e. At the command prompt, do the following:
• Type C: and then press ENTER.
• Type net use x: /d and then press ENTER.
f. Close the command prompt.
Why must you publish the Cross Certification Authority certificates that were issued by the BridgeCA in
your organization’s Active Directory?
The certificate chaining engine requires these certificates to build certificate chains for certificates that
other CAs issued in the Bridge CA hierarchy.
(continued)
6. Update Group Policy for a. Open a command prompt.

your computer and then log b. At the command prompt, type gpupdate /force and then press ENTER.
off the network.
Exercise 8
Issuing Certificates that Meet Qualified Subordination
Constraints
In this exercise, you will create certificate templates for two certificates, one that meets the
qualified subordination constraints and one that does not meet the qualified subordination
constraints. You will then copy the issued certificates to a common share on the London computer.
Scenario
After you enable qualified subordination for the bridge CA hierarchy, you must evaluate certificates
that other organizations issued in the bridge CA hierarchy.
domain)
2. Open the Certificate " Click Start, click Run, type Certtmpl.msc and then click OK.
Templates console.
template named QS Email User Signature Only, and then click Duplicate Template.
based on the User Signature b. In the Properties of New Template dialog box, on the General tab, in
Only certificate template. the Template display name box, type QS Email and then click OK.
4. Add the Medium Assurance a. In the details pane, double-click QS Email.

issuance policy OID to the b. On the Extensions tab, select Issuance Policies, and then click Edit.
c. In the Edit Issuance Policies Extension dialog box, click Add.
d. In the Add Issuance Policy dialog box, in the Issuance policies list,
select Medium Assurance, and then click OK.
e. In the Edit Issuance Policies Extension dialog box, click OK.
f. On the Extensions tab, click Apply.
(continued)
5. Assign the QSAccounts a. On the Security tab, click Add.

group Read and Enroll b. In the Select Users, Computers, or Groups dialog box, in the Enter
permissions and then log the object names to select box, type QSA and then click Check
off. Names.
c. In the Enter the object names to select box, ensure that QSAccounts
d. Assign the QSAccounts group the Read and Enroll permissions, and
then click OK.
f. Close all open windows and log off.
administrator account and • User name: CAadmin1
password.
domain)
7. Publish the QS Email a. On the Start menu, click Administrative Tools, and then click
certificate template to Certification Authority.
DomainCA. b. In the console tree, expand DomainCA, and then click Certificate
Templates.
d. In the Enable Certificate Templates dialog box, click QS Email, and
then click OK.
e. In the details pane, ensure that the QS Email certificate template
appears.
g. Log off of the network.
8. Log on using your qualified " Log on to your computer by using the following credentials:
subordination user account. • User name: QualSub1 (on the domain controller) or QualSub2 (on
the member server)
domain)
(continued)
9. In the Certificates – Current a. Click Start, click Run, type Certmgr.msc and then click OK.
User console, request a QS b. In the console tree, click Personal.
Email certificate.
c. In the console tree, right-click Personal, point to All Tasks, and then
click Request New Certificate.
e. On the Certificate Types page, in the Certificate Types list, select QS
Email, and then click Next.
Friendly name box, type QS Email and then click Next.
Finish.
10. Export the QS Email a. In the console tree, expand Personal, and then click Certificates.
certificate to b. In the details pane, right-click the certificate with the friendly name of
\\London\ClientCerts\ QS Email, point to All Tasks, and then click Export.
ComputerQSEmail.
c. On the Certificate Export Wizard page, click Next.
d. On the Export Private Key page, click Next.
e. On the Export File Format page, accept the default settings, and then
click Next.
f. On the File to Export page, in the File name box, type
\\London\ClientCerts\ComputerQSEmail (where Computer is the
NetBIOS name of your computer), and then click Next.
g. On the Completing the Certificate Export Wizard page, click
Finish.
h. In the Certificate Export Wizard message box, click OK.
i. Close the Certificates – Current User console.
11. Open the a. Click Start, click Run, type \\London\ClientCerts and then click OK.
\\London\ClientCerts share. b. In the \\London\ClientCerts window, double-click any QSEmail
certificate that a computer in another organization issued.
c. In the File Download dialog box, click Open.
.
(continued)
Does the Certificate dialog box indicate that all certificate purposes are recognized?
Yes. The Certificate dialog box does not indicate any unknown purposes. The certificate purposes are:
Protect e-mail messages (Secure email) and Prove your identity to a remote computer (client
authentication).
11. (continued) d. In the Certificate dialog box, click the Certification Path tab.
What is the certification path of the QS Email certificate?
RootCA # DomainCA # BridgeCA # PartnerCA #Qualsubx (where RootCA is the name of your
offline root CA, Domain is the NetBIOS name of your domain, Partner is the NetBIOS name of the
partner’s domain, and x is either 1 or 2).
11. (continued) e. In the Certificate dialog box, click OK.
12. If time permits, repeat the a. If time permits, repeat the process with certificates that are issued by
process with other other organizations.
organization’s certificates, b. Close all open windows and log off.
and then log off the
network.
Module 9: Deploying
Smart Cards
Contents
Overview 1
Lesson: Introduction to Smart Cards 2
Lesson: Enrolling Smart Card Certificates 12
Lesson: Deploying Smart Cards 19
Lab A: Deploying Smart Cards 35
Course Evaluation 63
respective owners.
Module 9: Deploying Smart Cards iii
Instructor Notes
Presentation: Smart cards provide secure storage for data and support authentication of users.
60 minutes Smart cards can take a number of forms, including credit cards, key-shaped
tokens, Subscriber Identity Module (SIM) chips in Group Special Mobile
Lab: (GSM) cellular phones, and Universal Serial Bus (USB) tokens. In this module,
90 minutes students will learn about smart cards and how to deploy them.
! Describe the use of smart cards in a Microsoft® Windows Server™ 2003 PKI
environment.
! Deploy smart cards in a Windows Server 2003 PKI environment.
Required materials To teach this module, you need

! Microsoft PowerPoint® file 2821A_09.ppt.
! The multimedia presentation, How Smart Cards Change Kerberos
Authentication.

! Complete the practices and the lab.
! Review the multimedia presentation, How Smart Cards Change Kerberos
Authentication.
! Read the Microsoft Knowledge Base article 281245, “Guidelines for
Enabling Smart Card Logon with Third-Party Certification Authorities,”
compact disc for details about implementing smart cards by using a third-
party CA.
! See http://www.microsoft.com/msf for more information about
infrastructure deployment by using Microsoft Solutions Framework (MSF)
fundamentals.
! Read the white paper, Logistics of Smart Card Deployment, under
disc, and review The Smart Card Deployment Cookbook, at
http://www.microsoft.com/technet/security/prodtech/smrtcard/smrtcdcb for
more information about planning a smart card deployment project.
iv Module 9: Deploying Smart Cards

Lesson: Introduction to Smart Cards

This lesson introduces students to smart cards and how they can use smart cards
to increase security in a Microsoft Windows® network.
lesson.
What Are Smart Cards? Describe how a smart card can increase security for interactive logons, client
authentication, remote logons, and wireless authentication. Provide examples
for each scenario to help students understand the benefits of smart card security.
If you have a smart card, consider showing it to students if they have never used
a smart card.
Why Use Smart Cards? This page provides greater detail about the security benefits of using smart
cards. Review each benefit with the class and ask students if they can think of
other business objectives that are met by implementing smart cards.
Features of Smart Cards Do not focus only on the fact that the private key, public key, and associated
certificate are stored on the smart card device. Spend time discussing how the
smart card protects the private key material. Ask students if their companies use
smart cards. If the students use smart cards, ask them to share why they chose a
smart card vendor. Typically, this will lead to a discussion about the toolkits
that are available from a specific smart card vendor.
Reasons to Use Smart Do not spend time describing each application to the class. Consider asking the
Cards class if they did not know that smart cards are an available form of security for
a specific application. If students are unaware that a smart card may be used for
a specific application, provide an example of how smart cards increase the
security for that application.
Smart Cards for Many students may be familiar with Windows 2000, which does not support the
Administrative Tasks administrative tasks that this topic describes. Mention that you can perform
these administrative tasks with smart cards on a Windows 2000 network, if the
tasks are performed on a computer running Windows XP or
Windows Server 2003 that is a member of a Windows 2000 domain.
Multimedia: How Smart The multimedia files are installed on the instructor computer. To open a
Cards Change Kerberos multimedia presentation, click the animation icon on the slide.
Authentication
Use this interactive multimedia presentation to focus on specific portions of the
smart card authentication process. Consider starting the presentation by
showing a normal Kerberos authentication process. Then, show how a smart
card changes the initial ticket-granting ticket (TGT) acquisition. Ensure that
students understand that only the TGT acquisition process changes when they
implement smart cards. After a user acquires a TGT, the same process is used to
acquire a Session Ticket (ST) if you authenticated by typing your credentials or
by providing a smart card and associated personal identification number (PIN).
Requirements for Smart Review each of the hardware and software requirements on the slide.
Card Logon Emphasize that you can use different vendors for smart card readers and smart
cards. In other words, you can use a Schlumberger smart card with a GemPlus
smart card reader.
Module 9: Deploying Smart Cards v
Lesson: Enrolling Smart Card Certificates

This lesson compares the two methods that are available for enrolling smart
card certificates.
Smart Card Enrollment Introduce the concepts of smart card enrollment agents and smart card
Methods autoenrollment. Do not go into details about each deployment. This page
introduces the two enrollment methods, which are discussed in detail on the
following pages.
When to Implement a Emphasize that the smart card enrollment agent is the most common method for
Smart Card Enrollment initial smart card deployment. Explain that the enrollment agent allows the
Agent enforcement of issuance policy. In other words, a local registration authority
must validate the requestor’s identity, based on the security requirements of the
organization, before it issues the smart card certificate.
Emphasize that if the student does not follow the process for even one smart
card certificate, the result is that all smart card certificates are distrusted. The
reason is that if one certificate is disproved, how do you attest to the validity of
the other smart card certificates?
When to Implement Explain that autoenrollment may not be an option for some organizations.
Smart Card Reiterate that the client computer must be running Windows XP Professional or
Autoenrollment later to take advantage of autoenrollment. Consider opening the Certificate
Templates console and discussing how you can require that the certificate
request be signed with an existing smart card certificate on the Issuance
Requirements tab of a version 2 certificate template.
Guidelines for Smart Review each requirement this is listed on the slide. Be prepared to answer any
Card Enrollment student questions about the guidelines.
Lesson: Deploying Smart Cards

This lesson describes each step in the planning and implementation of a smart
card deployment project. Each topic in the lesson provides information about a
step in the project.
Phases in Smart Card Do not spend a lot of time on this page, but ensure that the students understand
Deployment the planning requirements for a smart card deployment. This topic helps
students realize the amount of planning that is required for a smart card
deployment and how MSF provides a structured approach.
Guidelines for Choosing Spend time discussing the requirements for creating custom version 2 certificate
a Smart Card Certificate templates for smart card certificates. Although there are two default templates
Template for smart cards, most organizations must customize the template. Mention that a
version 2 certificate template must require the requestor to sign the request with
a certificate that includes the Certificate Request Agent application policy for
the certificate template to appear in the list of available smart card certificates
on the Web Enrollment pages.
Steps for Designating an Explain that an enrollment agent can request certificates for any user on the
Enrollment Agent network, including network administrators. All enrollment agent requests must
be audited to ensure that the certificates that they acquire are distributed to the
users, and are not impersonation attempts by an enrollment agent. Mention to
students that they can increase the issuance security for enrollment agents by
creating a custom version 2 certificate template based on the Enrollment Agent
certificate. A custom template enables them to keep the enrollment agent
requests pending until a certificate manager approves the request.
vi Module 9: Deploying Smart Cards
Steps for Configuring an Review each requirement for implementing a smart card enrollment station.
Enrollment Station Remind students that smart card enrollment is typically performed on
designated enrollment stations, not domain controllers.
How to Enroll Smart Consider demonstrating the Web Enrollment pages for smart card enrollment.
Cards Using an Emphasize that only a local administrator can install the smart card enrollment
Enrollment Agent Microsoft ActiveX® control. Once the control is downloaded, a non-
administrator can use the control if an administrator configures Group Policy to
allow the initialization of unsafe ActiveX controls.
How to Autoenroll Smart Review which PKI management roles perform each required task. Mention that
Cards on some networks, one person may hold more than one role. Having multiple
roles depends on whether common criteria role separation is enforced.
How to Configure Smart Compare and contrast each of the available options for smart card removal
Card Removal Behavior behavior. A good scenario to use is the case of a user with two smart cards: one
for day-to-day activities and one for administrative functions. Ask the students
how they can implement this scenario if the smart card removal behavior is set
to either lock the workstation or force logoff. The solution is to implement two
smart card readers on the workstation.
How to Enforce Smart Review how to enforce smart card authentication for both interactive and
Card Authentication remote authentication attempts. If students implement smart cards at their
organization, ask them if they enforce smart card use for interactive logons,
remote logons, or both logon scenarios.
Lab A Some training centers may not provide smart card readers and smart cards for
the students. In this scenario, students can perform all exercises in the lab
except for the following exercises:
! Exercise 0, in which students install the smart card reader
! Exercise 5, in which students enroll the smart card
! Exercise 7, in which students sign a Code Signing certificate request with
the private key that is associated with the student’s smart card certificate
A smart card reader is required to perform these exercises. If students do not

have a smart card reader, they should watch the demonstrations instead.
The demonstrations are located at C:\Program Files\2821 Slides on the
instructor computer, or under Multimedia on the Web page on the Student
Lab A: Deploying Smart Cards

In this lab, students will deploy smart cards by using a smart card enrollment
station.
! Deploy smart cards by using an enrollment agent.
! Sign a certificate request with a smart card.
! Plan re-enrollment of smart card certificates.
Module 9: Deploying Smart Cards vii
Lab Setup
Setup requirement 1 The labs in this module require that there is a CA hierarchy with an offline root
CA and an enterprise subordinate CA. Complete all of Labs A, B, and C in
the student’s domain controller) is configured as a member of the Local intranet
zone in the Default Domain Policy. Complete Lab B in Module 3, “Creating a
Lab Results
changes:
! A smart card reader is installed on each student computer.
! The Enrollment Agent certificate template is modified to allow enrollment
only by members of the EnrollmentAgents group.
! The Enrollment Agent certificate template is published on the enterprise
subordinate CA in each student forest.
! Enrollment Agent certificates are issued to Agent1 and Agent2.
! A version 2 certificate template named AgentSmartCard, based on the
Smartcard Logon certificate template, is created and published on the
! Internet Explorer is modified to allow the download of unsafe ActiveX
controls.
! AgentSmartCard certificates are issued to SCUser1 and SCUser2 by the
enrollment agents.
! The Autoenrollment Group Policy object (GPO) is linked to the Module09
organizational unit (OU).
! CodeSignComputer certificate templates are created and published to the
! CodeSignComputer certificates are issued to SCUser1 and SCUser2.
Module 9: Deploying Smart Cards 1
Overview

Introduction Smart cards can take a number of forms, including credit card shapes, key-
shaped tokens, Subscriber Identity Module (SIM) chips in Group Special
Mobile (GSM) cellular phones, and Universal Serial Bus (USB) tokens.
Smart cards provide secure storage for data and support authentication of users.
In this module, you will learn about smart cards and how to deploy them.
! Describe the use of smart cards in a Microsoft® Windows Server™ 2003
environment.
! Enroll smart card certificates.
! Deploy smart cards in an Active Directory® directory service environment.
2 Module 9: Deploying Smart Cards
Lesson: Introduction to Smart Cards

Introduction Microsoft views smart cards as a key component of its public key infrastructure
(PKI) support. You use smart cards to enhance the security for client
authentication, interactive logon, and secure e-mail messages.
Lesson outline After completing this lesson, you will be able to:
! Describe the security features of smart cards.
! Identify what business objectives can be met by using smart cards.
! Describe the key characteristics of smart cards.
! Identify the applications that can use smart cards to increase the security of
encryption and digital signing services.
! Use smart cards for administrative tasks.
! Describe how the use of smart cards modifies the Kerberos version 5
authentication protocol.
! Describe the hardware and software requirements for using smart cards.
What Are Smart Cards?

Introduction A smart card is a microcomputer without a graphical user interface. It contains
a built-in processor and is programmable. Smart cards are used to store data
securely, including public and private keys (often referred to as a key pair), and
public key certificates.
A smart card is a device that you can use for storing certificates, public keys,
and private keys. Smart cards provide tamper-resistant and portable security
solutions for tasks such as securing e-mail messages and logging on to a
domain.
Smart cards are supported in a Windows 2000 or Windows Server 2003 Active
Directory environment for authentication attempts from client computers
running Windows 2000, Windows XP, and Windows Server 2003 family.
Using smart cards Smart cards enhance the security for network authentication by using
cryptography-based identification. Instead of supplying a user name and
password, the user must possess the smart card and know the personal
identification number (PIN) of the smart card to be authenticated on the
network. An attacker must obtain both the user’s smart card and the PIN to
impersonate the user, rather than simply guess the user’s user name and
password.
Smart cards enhance the security for the following purposes:
! Interactive logon. The user presents her smart card credentials when she
initially logs on to a workstation.
! Client authentication. The user presents her smart card credentials for all
client authentication attempts, such as connecting to a share on a remote
server.
! Remote logon. The user presents her smart card credentials for remote
access and virtual private network (VPN) authentication attempts.
! Wireless authentication. In a network that implements 802.1x
authentication, a smart card provides authentication for users when they
connect to the wireless network.
Why Use Smart Cards?

Introduction Before you deploy smart cards in your organization’s network, determine
whether smart cards will meet your organization’s business objective.
Business objectives You can meet the following business objectives by implementing smart cards:
! Store PKI credentials securely. Smart cards provide a separate physical
device that stores the user’s certificate and key pair, and protects them with
a PIN, rather than the user’s password.
! Enable two-factor authentication. Smart cards increase authentication
security by implementing two-factor authentication. This type of
authentication requires something you have—the physical smart card—and
something you know—the PIN that unlocks the private key stored on the
smart card.
! Enhance the security of interactive user logons to the corporate network.
Smart cards prevent the transmission of unencrypted or weakly encrypted
credentials over the network.
! Provide selective access to data, resources, and Web sites. You can restrict
access to resources by deploying smart cards to authorized users only. You
can also require that the users are authenticated by using their smart card.
! Increase password security for remote users. Smart card authentication
protects dial-up and VPN users from network credential interception.
Features of Smart Cards

Introduction A smart card possesses the following major characteristics:
! A built-in processor. The processor on the smart card interacts with the
cryptographic service provider (CSP) to generate key pairs.
! A programmable card. The smart card works with the CSP to enable access
to the key pair and to certificates that are stored on the smart card.
! Secure storage of private keys. The smart card protects access to private
keys by requiring a PIN or other mechanism, such as the user’s thumbprint,
to unlock the private key.
! Isolation of security-related operations. Smart card cryptographic functions
for authentication, digital signing, and key exchange are performed on the
smart card and are isolated from the computer’s operating system.
Note The feature set of the smart card and the smart card management tools
are the primary decision factors when you choose a smart card vendor.
Typically, these factors are more important in the selection of a smart card
vendor that the price of the individual smart cards.
Smart card storage A smart card uses a custom file system to store data. It provides storage for one
or more of the following things:
! Private keys. The private key is protected by the PIN of the smart card.
! Public keys. The public key of the key pair is presented as a form of
authentication.
! Certificates. The certificate that is associated with the key pair is presented
during authentication.
Reasons to Use Smart Cards

Introduction Several network applications can use smart cards to increase the security of
encryption and digital signing services.
Using Smart Cards You can use smart cards for the following purposes:
! Client authentication. You can use the key pair that is stored on a smart card
to authenticate client computers on a Web site. When prompted for
credentials, the user chooses his smart card certificate from a dialog box,
and then types his PIN to prove his identity.
! Interactive logon. You can use the key pair that is stored on a smart card to
authenticate an interactive logon. The smart card provides Kerberos version
5 authentication to an Active Directory domain by using Public Key
initialization (PKINIT) extensions.
! Remote access authentication. You can use the certificate that is stored on a
smart card to provide dial-up or VPN authentication, which is protected by
the use of Extensible Authentication Protocol with Transport Layer Security
(EAP/TLS).
! Secure e-mail messages. You can use the key pair that is stored on a smart
card to digitally sign and decrypt secure e-mail messages.
! Code signing. You can use the key pair in a smart card to digitally sign
software applications, such as Microsoft ActiveX® controls, to prove that
the applications were created by a trusted source.
! Signing certificate requests. You can use the key pair to sign a certificate
request. Because of the two-factor authentication, the digital signature
provides higher assurance of the requestor’s identity.
! Custom applications. You can use the key pair in a smart card to digitally
sign and encrypt data in custom applications by using CAPICOM or
Cryptographic API (CryptoAPI). CAPICOM is a COM component that
exposes the richness of CryptoAPI in an easy-to-use object model.
CAPICOM and CryptoAPI provide a set of functions that allow applications
to encrypt and digitally sign data.
Smart Cards for Administrative Tasks

Introduction In Windows 2000, there were limitations on smart card use for administrative
functions. Windows XP Professional and Windows Server 2003 family provide
enhancements to smart card use that enable the use of smart cards for
administrative tasks.
Administrative tasks When you use client computers running Windows XP Professional or
Windows Server 2003, you can use a smart card for the following
administrative tasks:
! Promote a domain controller. When you install a new domain controller in
the domain, provide a smart card and PIN on the Network Credentials
page in the Active Directory Installation Wizard.
Note The new domain controller must be a domain member to allow smart
card authentication when running Dcpromo.exe.
! Use alternate credentials. Use the runas command with the /smartcard
option to use a smart card as proof of identity when running applications
that use the Secondary Logon service.
! Connect to a terminal server. Use Remote Desktop Connection to enable
smart card authentication to a terminal server if the terminal server runs a
Windows Server 2003 family operating system.
! Connect to network resources. Use the net use command with the
/smartcard option to provide a smart card as authentication when you
connect to network resources with alternate credentials. Or, if the Credential
Manager appears when you connect to a network resource, you can choose
the smart card and type the associated PIN to prove your identity.
Multimedia: How Smart Cards Change Kerberos Authentication

Introduction To view the How Smart Cards Change Kerberos Authentication presentation,
open the Web page on the Student Materials compact disc, click Multimedia,
and then click the title of the presentation.
Key points ! How Kerberos authentication works.
! How smart cards modify the Kerberos authentication process.
Requirements for Smart Card Logon

Introduction To deploy smart cards in a Windows Server 2003 or Windows 2000 Active
Directory environment, you must meet both hardware and software
requirements. These requirements ensure a successful smart card deployment
that increases the security of authentication and encryption on the network.
Hardware requirements Meet the following hardware requirements to implement smart card
authentication in your network:
! Acquire a smart card reader for each client workstation and a smart card
for each user. Client computers running Windows 2000, Windows XP, and
Windows Server 2003 family support serial, USB or PC Card attached
smart cards that are Plug and Play compliant. The smart card readers must
be on the Windows 2000, Windows XP, or Windows Server 2003 hardware
compatibility list (HCL) or provide drivers for the required operating
systems.
Note To find a complete list of supported Plug and Play smart card readers
in Windows XP and Windows Server 2003, search for the phrase “smart
card readers” in the Windows XP or Windows Server 2003 Help files.
! Select a smart card vendor. Select one smart card vendor for your
organization. Using multiple vendors results in the need for multiple smart
card CSPs. The smart card must be on the Windows 2000, Windows XP, or
Windows Server 2003 family HCL. In addition, ensure that the smart card
vendor provides a tool set to manage the issued smart cards.
Note Client computers running Windows XP and the

Windows Server 2003 family support GemPlus, Infineon, and Schlumberger
smart cards in the default installation. For a detailed list of the smart cards
that Windows XP and Windows Server 2003 supports, search for
“supported smart cards” in the Windows XP and Windows Server 2003
Help files.
Software requirements Meet the following software requirements to implement smart card
authentication in your network:
! Acquire the CSP that is associated with the selected smart cards. The CSP
provides an interface between the operating system and the smart card to
enable the storage and retrieval of key material from the smart card.
Although the default installation includes CSPs for GemPlus, Infineon, and
Schlumberger smart cards, other Rivest Shamir Adleman (RSA)-based
cryptographic smart cards are also supported, provided the card vendor has
developed its own CSP for the card using CryptoAPI and the Smart Card
Software Developer’s Kit.
Note If you deploy a CSP that is not included in the default installation,
ensure that you fully test the CSP and associated smart card drivers before
you deploy the solution in your organization.
! Provide smart card authentication through PKINIT extensions to the

Kerberos version 5 protocol. An Active Directory environment is required
to implement Kerberos authentication. The computer with the smart card
reader and the user must both have accounts in a Windows Server 2003 or
Windows 2000 domain.
! Store the certificate authority (CA) that issues the smart card certificate in
the NTAuth certificate store in Active Directory. When a user presents a
smart card certificate for authentication, the application that validates the
certificate verifies that the certificate of the issuing CA is in the NTAuth
store.
When you install an enterprise CA, the CA certificate is automatically
published to the NTAuth store. If you issue smart card certificates from a
third-party CA, manually publish the CA certificate to the NTAuth store by
using the certutil –dspublish –f <CACertname> NTAuthCA command.
Note For more information about implementing smart cards with a third-party
CA, see the Knowledge Base article 281245, “Guidelines for Enabling Smart
Card Logon with Third-Party Certification Authorities,” under Additional
Lesson: Enrolling Smart Card Certificates

Introduction Smart cards increase authentication security by implementing two-factor
authentication. Two factor authentication requires:
! Something you have. In this case, the something you have is the physical
smart card.
! Something you know. To use the smart card, you must know the user PIN to
unlock the private key that is stored on the smart card.
When you deploy smart cards, you must decide whether to implement an
enrollment agent, to implement smart card autoenrollment to issue the smart
card certificates, or to use a combination of both deployment methods.
! Compare smart card deployment methods.
! Identify when to implement a smart card enrollment agent.
! Identify when to implement smart card autoenrollment.
! Describe the best practices for smart card enrollment.
Smart Card Enrollment Methods

Introduction Organizations implement smart cards to increase the value of certificates that
are issued to network users. There are two ways that you can enroll smart cards:
you can use an enrollment agent or you can use autoenrollment.
Enrollment agent When you initially enroll the smart card during a face-to-face meeting, you
validate the identity of the smart card requestor by using an enrollment agent.
An enrollment agent, who has a trusted role in the PKI, verifies the identity of
the smart card requestor and then requests the smart card certificate on the
user’s behalf.
Note The enrollment agent—also referred to as a local registration authority

(LRA)—may also ask the smart card requestor to provide identification. In
some organizations, the LRA then records in a database the forms of
identification that the user presented so that the credentials can be used to verify
the user at a later date.
Autoenrollment You typically use autoenrollment for smart card renewal requests. After the
smart card user proves her identity during the initial registration, many
organizations consider possession of the smart card and knowledge of the smart
card’s PIN sufficient proof of identity.
A PKI administrator can reduce the costs that are associated with smart card
enrollment for certificate renewal by requiring that the certificate renewal
request be signed by a smart card certificate. This way, the original user that
was issued the smart card can renew the smart card certificate.
Note Some organizations use autoenrollment for the initial smart card
deployment and for certificate renewal. This strategy is only possible when the
security policy of the organization allows smart card enrollment without
additional validation of the user’s identity.
When to Implement a Smart Card Enrollment Agent

Introduction Whether your organization uses a smart card enrollment agent depends on the
requirements of your security policy and the operating systems that your
organization uses.
Note The smart card certificate request is typically performed in the presence
of the certificate requestor. Some organizations enroll the smart card certificates
before the meeting with the smart card certificate requestor. In this case, the
validation of the subject’s identity is delegated to a security officer or notary
public within the organization, who distributes the smart card to the user only
after validating the identity of the user.
Using an enrollment Use an enrollment agent for smart card deployment if your organization has the
agent following conditions:
! Client computers on the network run Windows 2000 or later. For these
client computers, using an enrollment agent is the only way to distribute
smart card certificates securely. Windows 2000 clients do not support the
automatic distribution of certificates by using Autoenrollment Settings in
Group Policy.
! Your security policy requires face-to-face meetings. Establish a process to
ensure that the enrollment agent verifies the identity of the user before
processing the certificate request. This verification ensures that the
enrollment agent requests the certificate only for the requesting user.
! Your security policy allows enrollment agents. An Enrollment Agent
certificate is a high-value certificate that allows the holder to request a
certificate on behalf of another user. Some organizations consider the
implementation of enrollment agents as a security risk.
Securing the enrollment You can add additional security to the enrollment agent process by performing
agent process the following actions:
! Keep all enrollment agent requests pending. By creating a version 2
certificate template that is based on the Enrollment Agent certificate
template, you can add an issuance requirement that the certificate request
must be approved by a CA certificate manager. This requirement ensures
that only authorized personnel receive an Enrollment Agent certificate.
! Train enrollment agents. By providing training for enrollment agents, you
ensure that they enforce the certificate policy when they issue smart card
certificates to network users. For example, enrollment agents may require
training about what information to record for a user, such as a passport or
driver license, before they issue the smart card certificates.
! Audit all enrollment agent activities. Ensure that you audit all issue and
manage certificate request events. This way, you ensure that all certificate
requests that enrollment agents make to Windows Server 2003 are recorded
in the security log. Ensure that the enrollment agent is not configured to
perform auditing in the domain or on the CA, so that they cannot modify the
event logs.
When to Implement Smart Card Autoenrollment

Introduction In a Windows XP or Windows Server 2003 environment, you can reduce the
costs of smart card certificate renewal by using autoenrollment. Autoenrollment
reduces the costs of deployment by moving the renewal process to the smart
card holder, rather than the enrollment agent.
Using autoenrollment Consider using autoenrollment if your organization has the following
conditions or requirements:
! Client computers on the network run Windows XP or later. Only these
operating systems support smart card certificate autoenrollment for user
accounts.
! Your organization’s security policy authorizes autoenrollment. The security
policy must support the process of users enrolling smart cards based on their
current user credentials.
! You are renewing smart card certificates. You can ease the administrative
effort for smart card renewals by implementing autoenrollment and
requiring smart card users to sign re-enrollment certificate requests with
their existing smart card certificates.
Securing the You can secure the autoenrollment process by requiring a smart card signature
autoenrollment method for autoenrollment requests. Require that the signing certificate includes the
Smart Card Logon application policy object identifier (OID) or a custom
certificate policy that indicates that the original smart card was issued in a face-
to-face meeting.
Guidelines for Smart Card Enrollment

Introduction Regardless of which method your organization chooses for enrolling and
renewing smart cards, ensure that the process for issuing smart card certificates
does not compromise your network’s security.
Enrollment agent Use the following guidelines if you plan to deploy smart card certificates by
using an enrollment agent:
! Limit Enroll permission for the Enrollment Agent certificate template to a
custom global or universal group that contains only the smart card
enrollment agents. Users who are issued smart cards do not require the
Enroll permission unless you are using autoenrollment for smart card
certificate renewal.
! Ensure that the Issue and manage certificate requests event is included in
the Auditing event and also configured on all CAs in the CA hierarchy. This
way, all certificates that are issued by the enrollment agent are included in
the audit log.
! Perform background checks on all users who will be enrollment agents.
This validates the identity of the enrollment agent.
! Require a face-to-face meeting for the smart card enrollment process. This
requirement ensures that the enrollment agent verifies the smart card user,
and that the user witnesses the issuance of the smart card certificate.
! Use an enrollment agent to issue smart card certificates to users who use
computers running Windows 2000. Windows 2000 only supports issuing
smart cards by using an enrollment agent. A Windows 2000 computer
cannot use autoenrollment for certificate issuance.
Autoenrollment Use the following guidelines if you plan to deploy smart card certificates by
using autoenrollment:
! Limit membership in the global or universal group with Read, Enroll, and
Autoenroll permissions. Do not place users in these groups until an
enrollment agent has issued their initial smart card certificates. By delaying
the membership assignment, you ensure that the user cannot bypass the
enrollment process.
! Use autoenrollment only for smart card certificate renewal. Only an
enrollment agent can confirm the certificate requestor’s identity before
issuing the smart card certificate. You can increase autoenrollment security
by requiring that the renewal request be signed with the previous smart card
certificate.
! Choose one smart card vendor for smart card deployment. Using multiple
smart card CSPs in the Smart Card certificate template prompts the user to
insert each type of smart card during the autoenrollment process, even if the
user possesses only one smart card.
! Require user input for the autoenrollment process. This way, users are
prompted to insert their smart card when the certificate request is
completed.
Lesson: Deploying Smart Cards

Introduction The smart card deployment process is organized into four phases. Each phase
includes a series of milestones that help your organization track progress and
ensure that the deployment meets its requirements.
! Describe the phases in deploying smart cards.
! Use the guidelines for choosing a Smart Card certificate template.
! Designate an enrollment agent.
! Configure an enrollment station.
! Manually enroll a smart card.
! Autoenroll a smart card.
! Define actions for smart card removal.
! Enforce smart card logon.
Phases in Smart Card Deployment

Introduction To deploy smart cards in your organization, use a structured methodology, such
as the Microsoft Solutions Framework (MSF), to ensure that you consider all
parts of the deployment and plan effectively. MSF recommends the following
infrastructure deployment for all enterprise projects:
! Envisioning
! Planning
! Development
! Implementation
Note For more information about infrastructure deployment by using MSF

fundamentals, see http://www.microsoft.com/msf.
Envisioning Before you start detailed planning for deploying smart cards, ensure that your
organization possesses a clear vision of how it will use smart card technology.
In the envisioning phase, identify the business requirements for smart card
deployment.
Business requirements The following business requirements can affect a smart card deployment:
! Enhancement of the security of users who log on to the corporate network.
! Secure remote access to the corporate network.
! Migration toward the elimination of passwords.
Document the results of the envisioning phase in a vision scope document.

These documents identify the goals, value proposition, and high-level features
and risks of your organization’s smart card deployment strategy.
Planning After the stakeholders in the organization approve the vision scope document,
begin to write the detailed planning and specifications for smart card logon. In
the planning phase, you create the functional specifications document, which
should identify the following requirements:
! Smart card requirements. Identifies what storage space is required on the
smart card and if there are any physical dimension requirements. For
example, some smart cards are thicker than others and they deteriorate faster
because they rub against the smart card readers.
! Smart card reader requirements. Identifies which types of smart card
readers are required. For example, USB, serial, or PC Card readers. Some
computers now offer built-in smart card readers.
! Smart card management tools. Identify which smart card management tools
your deployment plan requires. For example, you may want a tool that
allows remote resets of smart card PINs.
In addition to the functional specification, the planning phase should include a

master schedule for the deployment, budget estimates, and risk assessments.
Development The development phase proves the feasibility of the design that your
organization created during the planning phase. During the development phase,
you build a proof-of-concept project in a lab environment, and then roll out the
project to a limited number of computers and users in the production network as
part of a pilot project.
Implementation While the pilot project is underway, prepare for the implementation of smart
card deployment by completing the following tasks:
! Draft policies and procedures. Clarifying smart card use in policies and
procedures ensures that all participants in the smart card project know their
responsibilities and how to use the smart cards. For example, your
organization will need a policy to respond to lost or stolen cards. The policy
depends on the organization’s security requirements, how it uses smart
cards, and the access level of the employee who is missing the card.
! Prepare the smart card issuance process. Your organization must determine
how smart cards will be deployed. You can deploy smart cards by using an
enrollment agent or autoenrollment.
! Identify certificate template requirements. Depending on the issuance
process that your organization chooses, you can require the creation of
custom certificate templates to meet the security policies.
! Train help desk and issuance staff. These individuals are the first line of
support when smart card deployment problems occur.
! Determine how many smart cards and readers are required. A user may
have multiple identities on the network, and may require one smart card for
each identity. In addition, if the user has more than one computer, they may
require a smart card reader for each computer.
! Deploy readers and begin issuance process. After the planning is
completed, your organization is ready to deploy the smart cards and smart
card readers.
Note For more information about planning a smart card deployment project,
see the white paper, Logistics of Smart Card Deployment, under Additional
Reading on the Web page on the Student Materials compact disc. Also see The
Smart Card Deployment Cookbook, at http://www.microsoft.com/technet/
security/prodtech/smrtcard/smrtcdcb.
Guidelines for Choosing a Smart Card Certificate Template

Introduction To prepare a CA to issue smart card certificates, first choose which certificate
templates must be published on the CA. You can use an existing version 1
certificate template or create a customized version 2 certificate template.
Smart card certificate Windows Server 2003 includes two smart card-related certificate templates in
templates the default certificate templates, which are published in the Active Directory
forest:
! Smart Card Logon. This certificate template allows the smart card holder to
use a smart card to authenticate his credentials on the network.
! Smart Card User. This certificate template allows the smart card holder to:
• Use a smart card to authenticate his credentials on the network.
• Receive encrypted e-mail messages.
• Send digitally-signed e-mail messages.
Both of the default smart card-related certificate templates are version 1

certificate templates. You cannot deploy them by using certificate
autoenrollment.
To implement certificate autoenrollment or implement a smart card certificate
by using custom application policies or custom certificate policies, create a
version 2 certificate template, based on the Smart Card Logon or Smart Card
User certificate template.
Note You can modify the CSPs that the default certificate templates use and
the permissions for each certificate template. For other modifications, you must
create a version 2 certificate template based on the default certificate template.
Steps for Designating an Enrollment Agent

Introduction Enrolling an initial Smart Card certificate requires an enrollment agent. The
enrollment agent is a user on your network who has acquired an Enrollment
Agent certificate based on the Enrollment Agent certificate template. The
holder of an Enrollment Agent certificate can perform certificate requests on
behalf of any other user on the network, including administrators. The
certificate holder must be highly trusted in a PKI environment.
Securing the enrollment To secure the enrollment process for an Enrollment Agent certificate template,
process implement the following modifications to a version 2 certificate template based
on the Enrollment Agent certificate template:
! Modify the permissions of the certificate template to allow Read and Enroll
permissions to only one global group or universal group. Assign
membership in these groups to authorized enrollment agents only.
Note It is a common misconception that an enrollment agent must be an

administrator. The enrollment agent does not require administrative group
membership.
! Modify the issuance requirements of the version 2 certificate template to

require certificate manager approval. This modification keeps all
Enrollment Agent certificate requests pending until a certificate manager
validates the enrollment agent’s identity.
If your organization’s security policy requires strong protection of the

Enrollment Agent private key, you can store the Enrollment Agent certificate
on a smart card. To do this, use the smart card manufacturer’s CSP when you
request the certificate. In addition, modify a version 2 certificate template based
on the Enrollment Agent certificate template to accept requests that use the
smart card CSP.
Procedure for enrolling After you, as a certificate manager, modify and publish the Enrollment Agent
the Enrollment Agent certificate template on one or more CAs in your organization’s CA hierarchy,
certificate each designated enrollment agent must acquire an Enrollment Agent certificate.
Because of the requirement to keep all Enrollment Agent certificate requests
pending, request Enrollment Agent certificates by using the Web Enrollment
pages of an enterprise CA.
To request the modified Enrollment Agent certificate:
1. Log on as a user who is a member of the global or universal group and is
assigned Read and Enroll permissions for the modified Enrollment Agent
certificate.
2. In Internet Explorer, in the Address bar, type http://EnterpriseCA/certsrv,
where EnterpriseCA is the name of the Windows Server 2003 Web server
that hosts the CA.
3. On the Welcome page, click Request a certificate.
4. On the Request a Certificate page, click advanced certificate request.
5. On the Advanced Certificate Request page, click Create and submit a
request to this CA.
6. On the Advanced Certificate Request page, perform the following actions:
• In the Certificate Template drop-down list, select the version 2
certificate template based on the Enrollment Agent template.
• Under Key Options, in the CSP drop-down list, select the CSP that you
require. The default CSP is the Microsoft Enhanced Cryptographic
Provider 1.0.
• In the Friendly name box, type a display name for the certificate.
7. Click Submit.
8. On the Certificate Pending page, record the certificate request ID.
Procedure for installing After you issue the pending certificate request, install the modified Enrollment
the modified Enrollment Agent certificate by completing the following steps:
Agent certificate
1. Log on as the user who requested the modified Enrollment Agent certificate.
2. In the Address bar of Internet Explorer, type http://EnterpriseCA/certsrv,
where EnterpriseCA is the name of the Windows Server 2003 Web server
that hosts the CA.
3. Click View the status of a pending certificate request.
4. On the View the Status of a Pending Certificate Request page, click the
pending certificate request link.
5. On the Certificate Issued page, click Install this certificate.
6. On the Certificate Installed page, ensure that the message states that your
new certificate has been installed successfully.
Steps for Configuring an Enrollment Station

Introduction In most networks, smart card certificate enrollment is performed from a
designated certificate enrollment station. The enrollment station may be a
computer that is dedicated to the enrollment of smart cards or the enrollment
agent’s personal computer.
Steps for configuring To prepare a smart card certificate enrollment station:
the enrollment station
1. Install a smart card reader on the enrollment station to enroll Smart Card
certificates. The smart card reader must be on the Windows 2000,
Windows XP, or Windows Server 2003 family HCL.
Note If the Enrollment Agent certificate is stored on a smart card reader,

you must install two smart card readers on the enrollment station. One
reader enrolls new smart cards and the other reader reads the Enrollment
Agent private key from the enrollment agent’s smart card.
2. Install additional CSPs. If you implement smart cards that use a CSP that is
not included in the default installation of Windows 2000, Windows XP, or
Windows Server 2003, you must manually install the CSP on the enrollment
station.
3. Determine if the enrollment station has a certificate with the Client
Authentication object identifier in its Extended Key Usage or Application
Policy extensions in the computer store. If a certificate exists, no additional
certificates are required. If a certificate does not exist, enroll a Computer
certificate in the certificate store of the computer.
Note To enroll a Computer certificate, the requesting user must be a

member of the local Administrators group on the enrollment station.
How to Enroll Smart Cards Using an Enrollment Agent

Introduction After you deploy the Enrollment Agent certificates and enable the enrollment
station for smart card access, the enrollment agent can then perform manual
certificate requests on behalf of other users.
Important Only a local administrator can install the smart card enrollment
ActiveX control. After the control is downloaded, non-administrators can use
the control if you configure Group Policy to allow the download of unsafe
ActiveX controls.
Procedure for enrolling To manually request a Smart Card certificate on behalf of another user:
smart cards using an
enrollment agent 1. Ensure that you log on as a user who has an Enrollment Agent certificate in
his personal store, or in higher security networks, on a separate smart card.
2. In Internet Explorer, open http://EnterpriseCA/certsrv (where
EnterpriseCA is the DNS name of the enterprise CA that is configured to
issue the smart card certificates).
3. On the Welcome page, click Request a certificate.
4. On the Request a Certificate page, click advanced certificate request.
5. On the Advanced Certificate Request page, click Request a certificate
for a smart card on behalf of another user using the smart card
certificate enrollment station.
6. On the Smart Card Certificate Enrollment Station page, do the

following:
• In the Certificate Template drop-down list, select Smart Card Logon
or Smart Card User.
• In Certification Authority, click the name of the CA that you want to
issue the smart card certificate from.
• In Cryptographic Service Provider, select the CSP of the smart card’s
manufacturer.
Note You can also choose a version 2 certificate template if a version 2

certificate template uses a smart card CSP and implements an Issuance
Requirement that the request is signed with a certificate with the Certificate
Request Agent application policy OID.
7. On the Smart Card Certificate Enrollment Station page, in the

Administrator Signing Certificate section, click Select Certificate, click
the Enrollment Agent certificate that will sign the enrollment request, and
then click OK.
8. On the Smart Card Certificate Enrollment Station page, in User To
Enroll, click Select User, select the appropriate user account, and then click
Enroll.
9. When prompted, insert the smart card into the smart card reader on the
enrollment agent’s computer, and then click OK.
10. When prompted, enter the PIN for the smart card.
How to Autoenroll Smart Cards

Introduction To renew a smart card certificate, you can use autoenrollment instead of
performing the renewal on a smart card enrollment station. Users with client
computers running Windows XP or the Windows Server 2003 family can renew
their smart card certificates by using autoenrollment.
Note Client computers running versions of Windows prior to Windows XP do

not support autoenrollment of user certificates. However, the computers can
connect to a Windows Server 2003 Terminal Server from a Windows XP
Remote Desktop client. Users can then renew their Smart Card certificate in the
Remote Desktop client.
The process of implementing autoenrollment for smart card certificates is

divided among members of the Enterprise Admins group, the CA
Administrator, members of the Domain Admins group, and the smart card
enrollee.
Procedure for a member A member of the Enterprise Admins group performs the following tasks to
of the Enterprise enable autoenrollment for smart card certificates:
Admins group
1. Create a custom certificate template with autoenrollment enabled.
Autoenrollment can only be used to deploy version 2 certificate templates.
Create a version 2 certificate template based on either the Smart Card Logon
or Smart Card User certificate templates.
2. Modify the certificate template to enable autoenrollment. Smart card
certificates require that all users who receive the certificate through
autoenrollment are assigned Read, Enroll, and Autoenrollment permissions.
In addition, configure the certificate template to prompt the user during
enrollment.
Note Users must be prompted to insert their smart card and enter their PIN
during the autoenrollment process.
Procedure for the CA Publish the certificate template on one or more enterprise CAs in the CA
administrator hierarchy.
Procedure for a member After the certificate template is available for autoenrollment, a member of the
of the Domain Admins Domain Admins group must enable Autoenrollment Settings in Group Policy.
group To do so, create a Group Policy object (GPO) and perform the following
actions in User Configuration:
! Click Enroll certificates automatically. This setting enables
autoenrollment of certificates for the OU or domain where the GPO is
linked.
! Select the Renew expired certificates, update pending certificates, and
remove revoked certificates check box. This enables certificate
autoenrollment for certificate renewal, issuance of pending certificates, and
removal of revoked certificates from the subject’s certificate store.
! Select the Update certificates that use certificate templates check box.
This enables autoenrollment of superseded certificate templates.
After the GPO is defined, link the GPO to the OU or domain where the user
accounts that will be enabled for smart card autoenrollment exist in Active
Directory.
Note For more information about enabling certificate autoenrollment, see

Module 6, “Configuring Certificate Enrollment,” in Course 2821, Designing
and Managing a Windows Public Key Infrastructure.
Procedure for the smart After Group Policy is implemented to enable autoenrollment for users, the
card enrollee smart card enrollee performs the following tasks:
1. After autoenrollment has been enabled, an informational balloon appears on
the user’s taskbar during the next Group Policy pulse interval or the next
logon. The user clicks the balloon to start the autoenrollment process. After
a few seconds, the balloon disappears and only the icon remains in the
system tray.
2. The user is prompted to insert the smart card and type the user PIN for the
smart card. This completes the autoenrollment process.
Note If the Smart Card certificate template contains more than one CSP,
the user may need to repeat the installation of the smart card in the reader to
reach the appropriate smart card CSP.
How to Configure Smart Card Removal Behavior

Introduction When users remove their smart card from a computer and walk away from the
computer, any user can use the computer with the same authentication settings
and access the data. To prevent this situation from occurring, specify what
actions you want users to take when they remove their smart card. The default
setting for Windows 2000 and Windows Server 2003 is no action.
The Interactive Logon: Smart card removal behavior Group Policy setting
defines the actions that users will take when they remove their smart card. This
Group Policy setting ensures that consistent smart card removal behavior is
applied to all computers that are affected by the GPO.
Smart card removal behavior is defined in the Computer Settings of a GPO.
You can apply the GPO on the domain or on a specific OU where the computer
accounts of computers with smart card readers are located.
Procedure for To enable smart card removal behavior settings in Group Policy:
configuring smart card
removal behavior 1. In the Group Policy Object Editor, in the console tree, browse to
Computer Configuration/Windows Settings/Security Settings/
Local Policies/Security Options.
2. In the details pane, double-click Interactive Logon: Smart card removal
behavior.
3. In the Interactive Logon: Smart card removal behavior Properties
dialog box, select one of the following options:
• No Action. The removal of the smart card does not lock the workstation
or log off the current user.
• Lock Workstation. The removal of the smart card locks the
workstation. The user must press CTRL + ALT + DEL and provide the
PIN or user name and password to unlock the workstation.
• Force Logoff. The user who is currently logged on is automatically
logged off.
4. Click OK.
In some PKI deployments, an administrator may have two smart cards; one to
authenticate users and one to perform administrative tasks. If your organization
configures smart card removal behavior to lock the workstation or log off the
user, the administrator’s workstation requires a second smart card reader to
perform a secondary logon.
If a second smart card reader is not installed, the attempt to switch between the
two smart cards either logs off the administrator or locks the workstation.
How to Enforce Smart Card Authentication

Introduction Some organizations may want to enforce smart card logon after it issues smart
cards to all users in the organization. You can choose to enforce smart card log
on for interactive logon, remote access authentication, or both.
Procedure for enforcing To enforce smart card authentication for interactive logon, modify the
smart card properties of the user account to require a smart card. To modify the properties:
authentication for
interactive logon 1. Open Active Directory Users and Computers.
2. In the console tree, browse to the container or OU where the user’s account
exists.
3. In the details pane, right-click the user account, and then click Properties.
4. In the user’s Properties dialog box, on the Account tab, in the Account
options list, select the Smart card is required for interactive logon check
box.
5. Click OK to apply the account option setting.
By defining this account option in Active Directory in Windows Server 2003,

you transfer password control from the user to the operating system. The
operating system now manages the user’s password, assigns a maximum length
password that is equivalent to 255 characters, and ensures that the password
meets complexity requirements. If an administrator resets the password at a
later date, the user can use the password for network logon, but not for
interactive logons.
Warning To enforce smart card logon in your organization, plan for situations
in which users forget their smart card at home. In such a situation, you can issue
temporary smart cards or make the Smart card is required for interactive logon
option unavailable temporarily.
Procedure for enforcing To enforce smart card authentication for remote access, configure a remote
smart card access policy to require EAP/TLS authentication in the profile settings. The
authentication for certificate that is used for authentication must contain the Client Authentication
remote access OID in the application policy or Enhanced Key Usage (EKU) extensions.
To configure a remote access policy to require EAP/TLS authentication:
1. In Administrative Tools, click Routing and Remote Access.
Note If your network implements Remote Authentication Dial-In User

Service (RADIUS) for remote access authentication, edit the remote access
policy in the Internet Authentication Services console on the server that
hosts Internet Authentication Services.
2. In the console tree, click Remote Access Policies.

3. In the details pane, double-click the remote access policy that you want to
configure to use only smart card authentication.
4. In the properties of the remote access policy dialog box, click Edit Profile.
5. On the Edit Dial-in Profile dialog box, on the Authentication tab, clear all
check boxes, and then click EAP Methods.
6. In the Select EAP Providers dialog box, in the EAP types list, click Smart
Card or other certificate (Server –Configured), and then click Edit.
7. In the Smart Card or other Certificate Properties dialog box, verify that
a certificate appears in the Certificate issued to drop-down list, and then
click OK.
Note The Routing and Remote Access server must have a certificate
installed in the certificate store of the computer that enables Server
Authentication. You can enroll either a Domain Controller certificate or
Computer certificate to meet this requirement.
8. In the Select EAP Providers dialog box, click OK.

9. In the Edit Dial-in Profile dialog box, click OK.
No specific configuration of the dial-in conditions is required when you

configure a remote access policy. The authentication requirements are only
enforced after a remote access connection meets the conditions of the remote
access policy.
Lab A: Deploying Smart Cards

! Deploy smart cards by using an enrollment agent.
! Sign a certificate request with a smart card.
! Plan re-enrollment of smart card certificates.

domain.
! Created a Group Policy object named Autoenrollment that enables
Autoenrollment Settings for user objects.
! The knowledge and skills to deploy smart cards to computers running
Windows Server 2003 family.
Additional information For more information about deploying smart cards, see the white paper,
Certificate Autoenrollment in Windows Server 2003, under Additional
Exercises that require a The following exercises in this lab require a smart card reader:
smart card reader
! Exercise 0
! Exercise 5
! Exercise 7
A smart card reader is required to perform this exercise. If you do not have a
smart card reader, watch the demonstration instead. The demonstration is
located under Multimedia on the Web page on the Student Materials compact
disc.
Estimated time to
complete this lab:
90 minutes
Exercise 0
Lab Setup
Before you begin this lab, you must install the USB smart card reader that is provided.
administration account and • User name: Student1 (on the domain controller) or Student2 (on
password. the member server)
domain)
2. Plug in the USB smart card a. Plug the USB smart card reader into a USB port on your computer.
reader so that Plug and Play b. In the notification area, double-click the Safely Remove Hardware
can automatically install the icon.
drivers.
c. In the Safely Remove Hardware dialog box, ensure that the operating
system recognizes the smart card reader, and then click Close.
3. If the installation fails, a. If the installation does not proceed automatically, the Welcome to the
download updated drivers Found New Hardware Wizard page appears.
from the Internet for your b. Download the latest Windows XP or Windows Server 2003 family
USB smart card reader and drivers for your USB smart card reader.
then manually install the
necessary drivers. c. On the Welcome to the Found New Hardware Wizard page, click
Install from a list or specific location (Advanced), and then click
Next.
d. On the Please choose your search and installation options page,
click Search for the best driver in these locations, and then click
Next.
e. On the Please choose your search and installation options page,
select the Include this location in the search check box, type the path
where you downloaded the updated drivers, and then click Next.
f. On the Completing the Found New Hardware Wizard page, click
Finish.
4. Verify that the smart card a. Log off.

reader is available for b. Ensure that the Welcome to Windows dialog box displays a smart card
network authentication. reader next to the keyboard.
Exercise 1
Modifying and Publishing the Enrollment Agent Certificate
Template
In this exercise, you will modify the permissions of the Enrollment Agent certificate template, and
then publish the certificate template on your organization’s enterprise subordinate CA.
Scenario
Your organization’s security policy requires that a smart card enrollment agent only issue smart
cards after validating the identity of the smart card requestor. The security policy requires that the
smart card requestor’s identity be validated by attending a face-to-face meeting with the smart card
enrollment agent. The Enrollment Agent certificate enables the holder to enroll certificates on
behalf of another user. You must modify the permissions to allow only designated enrollment
agents to acquire the certificate.
domain)
Templates console and view b. If the Certificate Templates message box appears, click OK.
the properties of the
Enrollment Agent certificate c. In the details pane, double-click Enrollment Agent.
template.
3. Take ownership of the a. In the Enrollment Agent Properties dialog box, on the Security tab,
Enrollment Agent certificate click Advanced.
template. b. In the Advanced Security Settings for
LDAP://ForestName/KeyEnrollmentAgent (where ForestName is the
DNS name of your forest), on the Owner tab, click Template2, and
then click Apply.
c. Click OK.
(continued)
4. Modify the Enrollment a. On the Security tab, click Domain Admins, and then clear the Enroll
Agent certificate templates check box.
to remove the Enroll b. Click Enterprise Admins, and then clear the Enroll check box.
Permission for the Domain
Admins and Enterprise c. On the Security tab, click Add.
Admins groups. Then, d. In the Select Users, Computers, or Groups dialog box, in the Enter
assign the EnrollmentAgents the object names to select box, type Enrollment, and then click
group Read and Enroll Check Names.
permissions. e. In the Select Users, Computers, or Groups dialog box, ensure that
EnrollmentAgents appears in the Enter the object names to select
box, and then click OK.
f. Assign the EnrollmentAgents group Read and Enroll permissions,
and then click OK.
5. Log on using your CA " Log on to your computer by using the following credentials:
Administrator account and • User name: CAadmin1
password.
• Domain: Domain
6. Publish the Enrollment a. On the Start menu, click Administrative Tools, and then click
Agent certificate template Certification Authority.
on DomainCA. b. In the console tree, expand DomainCA, and then click Certificate
Templates.
d. In the Enable Certificate Templates dialog box, select Enrollment
Agent, and then click OK.
e. In the details pane, verify that Enrollment Agent appears.
g. Log off.
Exercise 2
Acquiring the Enrollment Agent Certificates
In this exercise, you will log on as a non-administrative account that is a member of the
EnrollmentAgents global group, and then request an Enrollment Agent certificate.
Scenario
Your organization has decided to designate the corporate security officers as the enrollment agents
for your organization. The security officers must acquire an Enrollment Agent certificate so they
can enroll smart card certificates on behalf of other users.
1. Log on to the network as a " Log on to your computer by using the following credentials:
member of the • User name: Agent1 (on the domain controller) or Agent2 (on the
EnrollmentAgents group. member server)
domain)
2. Request an Enrollment a. Open Internet Explorer.

Agent certificate by using b. If the Internet Explorer dialog box appears, click In the future, do
Web-based enrollment, and not show this message, and then click OK.
c. In Internet Explorer, open the URL http://WebServer/certsrv (where
controller).
e. On the Request a Certificate page, click advanced certificate
request.
f. On the Advanced Certificate Request page, click Create and submit
g. On the Advanced Certificate Request page, in the Certificate
Template drop-down list, select Enrollment Agent.
h. On the Advanced Certificate Request page, in the Friendly Name
box, type Enrollment Agent and then click Submit.
(continued)
2. (continued) i. In the Potential Scripting Violation dialog box, click Yes to allow the
j. On the Certificate Issued page, click Install this certificate.
k. In the Potential Scripting Violation dialog box, click Yes to allow the
Web site to add a certificate to your computer.
l. Ensure that the Certificate Installed page appears, which indicates that
the certificate has been installed successfully.
m. Close Internet Explorer.
n. Close all open windows and then log off.
Exercise 3
Creating a Custom Smart Card Certificate
In this exercise, you will create a new version 2 certificate template for smart cards. Available only
to enrollment agents, the version 2 certificate template designates that the certificate was issued in
an interview in person.
Scenario
Your organization’s security policy requires that you deploy a customized version of the Smart
Card Logon certificate to all smart card users. The security policy also requires that all smart card
certificates are issued by an enrollment agent.
certificate template • Logon name: Template2
domain)
2. Create a version 2 certificate a. Click Start, click Run, type Certtmpl.msc and then click OK.
template named b. If the Certificate Templates message box appears, click OK.
AgentSmartCard based on
the Smart Card Logon c. In the details pane, right-click Smartcard Logon, and then click
certificate template. Duplicate Template.
d. In the Properties of New Template dialog box, in the Template
display name box, type AgentSmartCard and then click OK.
3. In the AgentSmartCard a. In the details pane, double-click AgentSmartCard.

certificate template, select b. In the AgentSmartCard Properties dialog box, on the Request
the following setting: Handling tab, click CSPs.
• CSP: Schlumberger c. In the CSP Selection dialog box, click Requests must use one of the
Cryptographic Service following CSPs.
Provider
d. Under CSPs, select the Schlumberger Cryptographic Service
Provider check box, and then click OK.
4. Configure the certificate a. In the AgentSmartCard Properties dialog box, on the Issuance
template to mandate that the Requirements tab, click This number of authorized signatures.
requestor sign a request with b. Ensure that the Policy type required in signature drop-down list
a certificate with the displays Application policy.
Certificate Request Agent
application policy. c. Ensure that the Application policy drop-down list displays Certificate
Request Agent.
d. Click Apply.
(continued)
5. Add the High Assurance a. In the AgentSmartCard Properties dialog box, on the Extensions
issuance policy to the tab, click Issuance Policies, and then click Edit.
AgentSmartCard certificate b. In the Edit Issuance Policies Extension dialog box, click Add.
template.
c. In the Add Issuance Policy dialog box, click High Assurance, and
then click OK.
e. Click Apply.
6. In the AgentSmartCard a. In the AgentSmartCard Properties dialog box, on the Security tab,
certificate template, assign click Add.
the EnrollmentAgents Read b. In the Select Users, Computers, or Groups dialog box, in the Enter
and Enroll permissions. the object names to select box, type Enrollment, and then click
Check Names.
c. In the Select Users, Computers, or Groups dialog box, ensure that
EnrollmentAgents appears in the Enter the object names to select
d. In the AgentSmartCard Properties dialog box, on the Security tab, in
the Group or user names list, select EnrollmentAgents, allow Read
and Enroll permissions, and then click OK.
7. Log on to the domain as a " Log on to the domain by using the following credentials:
CA administrator. • Logon name: CAAdmin1
• Domain: Domain
issue AgentSmartCard Certification Authority.
certificates. b. In the console tree, expand Certification Authority, expand
DomainCA, and then click Certificate Templates.
d. In the Enable Certificate Templates dialog box, select
AgentSmartCard, and then click OK.
e. In the details pane, verify that AgentSmartCard appears.
Exercise 4
Enabling Unsafe ActiveX Control Download
Internet Explorer considers the smart card enrollment ActiveX control an unsafe ActiveX control.
In this exercise, you will modify Group Policy to allow the downloading of unsafe ActiveX
controls.
Scenario
The security policy of your organization does not allow users to be local administrators of their
computers. By default, only local administrators can download unsafe ActiveX controls in the
Local intranet site. You must configure Group Policy so that all users are prompted whether to
allow Internet Explorer to download unsafe ActiveX controls.
1. Log on to the domain using " Log on to the domain by using the following credentials:
your enrollment agent • User name: Agent1 (on the domain controller) or Agent2 (on the
account. member server)
domain)
2. Request a smart card a. Open Internet Explorer.

certificate from the b. In Internet Explorer, open the URL http://WebServer/certsrv (where
Certificate Services Web WebServer is the fully qualified domain name of your domain
Enrollment pages. controller).
c. On the Welcome page, click Request a certificate.
d. On the Request a Certificate page, click advanced certificate
request.
e. On the Advanced Certificate Request page, click Request a
certificate for a smart card on behalf of another user by using the
smart card certificate enrollment station.
What error message do you receive?
A message that states that an ActiveX control on this page is not safe.
2. (continued) f. In the Microsoft Internet Explorer message box, click OK.

(continued)
What additional error message do you receive on the domain controller?
A message that states that the ActiveX control failed to download.
2. (continued) g. On the domain controller, in the Microsoft Internet Explorer message

box, click OK.
3. Attempt to modify the a. On the Tools menu, click Internet Options.

ActiveX download settings b. In the Internet Options dialog box, on the Security tab, click Local
for the Local intranet zone. intranet, and then click Custom Level.
Can you customize the Active X download settings? If not, who can?
No, the configuration of custom security settings is not available for non-administrator accounts. Only
a member of the local Administrators group can modify the security options.
3. (continued) c. In the Internet Options dialog box, click OK.

d. Close Internet Explorer.
your administrative account. • User name: Student1
your domain administration account)
• Domain: Domain
5. Change the ActiveX a. Open Internet Explorer.

download settings for the b. On the Tools menu, click Internet Options.
Local intranet zone to ask
the user whether to allow c. In the Internet Options dialog box, on the Security tab, click Local
Internet Explorer to intranet, and then click Custom Level.
download unsafe ActiveX d. In the Security Settings dialog box, in the Settings list, scroll to
controls. Initialize and script ActiveX controls not marked as safe, and then
click Prompt.
e. In the Security Settings dialog box, click OK.
f. In the Warning! dialog box, click Yes.
g. In the Internet Options dialog box, click OK.
h. Close Internet Explorer.
(continued)
6. Open the Default Domain a. On the Start menu, point to Administrative Tools, and then click
Policy in Group Policy Active Directory Users and Computers.
Object Editor. b. In the console tree, right-click Domain, and then click Properties.
c. In the Domain Properties dialog box, on the Group Policy tab, click
Default Domain Policy, and then click Edit.
7. Modify the GPO to prompt a. In Group Policy Object Editor, in the console tree, expand User
the user when Internet Configuration, expand Windows Settings, expand Internet Explorer
Explorer attempts to Maintenance, and then click Security.
download an unsafe b. In the details pane, double-click Security Zones and Content
ActiveX control. Ratings.
c. In the Internet Explorer Enhanced Security Configuration dialog
box, click Continue.
d. In the Security Zones and Content Ratings dialog box, click Import
the current security zones and privacy settings, and then click
Modify Settings.
e. In the Internet Properties dialog box, on the Security tab, click Local
intranet, and then click Custom Level.
f. In the Security Settings dialog box, in the Settings list, ensure that
Initialize and script ActiveX controls not marked as safe is set to
Prompt, and then click OK.
g. In the Internet Properties dialog box, click OK.
h. In the Security Zones and Content Ratings dialog box, click OK.
i. Close Group Policy Object Editor.
j. In the Domain Properties dialog box, click OK.
k. Close Active Directory Users and Computers.
l. Close all open windows and then log off.
8. Log on to domain with your " Log on to the domain by using the following credentials:
administrative account. • User name: Student1
your domain administration account)
• Domain: Domain
(continued)
9. Download the smart card a. Open Internet Explorer.

enrollment ActiveX control, b. In Internet Explorer, open the URL http://WebServer/certsrv (where
close all open windows, and WebServer is the fully qualified domain name of your domain
then log off the network. controller).
c. On the Welcome page, click Request a certificate.
request.
f. In the Internet Explorer dialog box, click Yes to download the smart
card enrollment ActiveX control.
g. In the Internet Explorer dialog box, click Yes to allow interaction
with the smart card enrollment ActiveX control.
Exercise 5
Performing Smart Card Enrollment Agent Requests
In this exercise, you will act as the enrollment agent and request a smart card certificate on behalf
of another user.
A smart card reader is required to perform this exercise. If you do not have a smart card reader,
view the demonstration instead. The demonstration is located under Multimedia on the Web page
Scenario
Now that you have configured Internet Explorer to allow the downloading of unsafe ActiveX
controls, you are ready to start enrolling smart cards for other users.
If you do not have access to a Schlumberger smart card and smart card reader, view the demonstration on the
your enrollment agent • User name: Agent1 (on the domain controller) or Agent2 (on the
domain)
2. Request a smart card a. Open Internet Explorer.

certificate from the Certificate b. In Internet Explorer, open the URL http://WebServer/certsrv (where
Services Web Enrollment WebServer is the fully qualified domain name of your domain
pages for the following users: controller).
• SCuser1 (on the domain c. On the Welcome page, click Request a certificate.
controller)
• SCuser2 (on the request.
member server)
f. In the Internet Explorer dialog box, click Yes to download the smart
card enrollment ActiveX control.
(continued)
2. (continued) g. On the Smart Card Certificate Enrollment Station page, ensure that
the following information appears:
• Certificate Template: AgentSmartCard
• Certification Authority: DomainCA
• Cryptographic Service Provider: Schlumberger Cryptographic
Service Provider
• Administrator Signing Certificate: Agent1 (on the domain
controller) or Agent2 (on the member server)
h. On the Smart Card Certificate Enrollment Station page, click Select
User.
i. In the Select User dialog box, in the Enter the object name to select
box, type SC and then click Check Names.
j. In the multiple Names Found dialog box, click SCUser1 (on the
domain controller) or SCUser2 (on the member server), and then click
OK.
k. In the Select User dialog box, click OK.
l. Insert the Schlumberger smart card into the smart card reader.
m. On the Smart Card Certificate Enrollment Station page, click
Enroll.
n. In the Confirm Smart Card PIN dialog box, in the Please enter your
PIN box, type 00000000 and then click OK.
The CSP generates the key pair on the smart card, the enrollment
agent certificate signs the certificate request, the CA issues the
certificate, and the CSP installs the certificate on the smart card.
When the enrollment is completed, the View Certificate button
appears.
3. View the details of the issued a. On the Smart Card Certificate Enrollment Station page, click View
certificate. Certificate.
b. In the Certificate dialog box, click the Details tab.
How does the certificate indicate that it was issued in a face-to-face interview?
The Certificate Policies attribute contains the High Assurance object identifier.
Does the certificate indicate that an enrollment agent requested the certificate?
No, the certificate does not contain any indication that the certificate was requested by an enrollment
agent.
(continued)
4. Remove the smart card from a. In the Certificate dialog box, click OK.
the smart card reader and then b. Close Internet Explorer.
c. Remove the smart card from the smart card reader.
d. Close all open windows and log off.
5. Log on to the network using a. Insert the smart card into the smart card reader.
smart card authentication. b. In the Log On to Windows dialog box, in the PIN box, type 00000000
and then click OK.
c. Press CTRL+ALT+DELETE.
What user is currently logged on?
Either SCUser1@Domain.msft or SCUser2@Domain.msft (where Domain is the NetBIOS name of

your domain) is currently logged on.
6. Close all open windows and a. Remove the smart card from the smart card reader.
• Domain: Domain
8. Open an MMC console using a. Open a command prompt.

the smart card credentials. b. Insert the smart card into the smart card reader.
c. At the command prompt, type runas /smartcard "mmc.exe" and then
press ENTER.
d. At the Enter the PIN prompt, type 00000000 and then press ENTER.
e. Press CTRL+ALT+DELETE.
f. In Windows Task Manager, click the Processes tab.
(continued)
What user name is associated with the MMC.exe process?
Either SCUser1 or SCUser2 is associated with the MMC.exe process.
9. Close all open windows and a. Close Windows Task Manger.

log off the network. b. Close the snap-in without saving changes.
d. Log off.
Exercise 6
Configuring a Certificate to Require a Smart Card Signature
During Autoenrollment
In this exercise, you will design a version 2 certificate template based on the Code Signing
certificate template, which requires a smart card signature during the smart card autoenrollment
process.
Scenario
Your organization must increase the issuance security for code signing certificates. It has
determined that signing the Code Signing certificate request with your smart card will meet the
issuance requirements of the organization. You must implement a version 2 certificate template that
requires that users use a smart card certificate to sign the Code Signing certificate request.
your certificate manager • User name: Template1 (on the domain controller) or Template2
account with a password of (on the member server)
P@ssw0rd.
domain)
2. Create a new certificate a. Click Start, click Run, type Certtmpl.msc and then click OK.
template named b. If the Certificate Templates message box appears, click OK.
CodeSignComputer based
on the Code Signing c. In the details pane, right-click Code Signing, and then click Duplicate
certificate template. Template.
d. In the Properties of New Template dialog box, in the Template
display name box, type CodeSignComputer (where Computer is the
NetBIOS name of your computer), and then click OK.
3. Configure the a. In the details pane, double-click CodeSignComputer.

CodeSignComputer b. In the CodeSignComputer Properties dialog box, on the Request
certificate template to Handling tab, click Prompt the user during enrollment.
prompt the user during
enrollment. c. Click Apply.
4. Modify the issuance a. On the Issuance Requirements tab, click This number of authorized
requirements to require an signatures.
authorized signature with a b. In the Policy type required in signature drop-down list, select
Smart Card Logon Application policy.
application policy OID.
c. In the Application policy drop-down list, select Smart Card Logon.
d. In the CodeSignComputer Properties dialog box, click Apply.
(continued)
5. Add the Medium Assurance a. On the Extensions tab, click Issuance Policies, and then click Edit.
issuance policy OID. b. In the Edit Issuance Policies Extension dialog box, click Add.
c. Click Medium Assurance, and then click OK twice.
d. In the CodeSignComputer Properties dialog box, click Apply.
6. Assign Read, Enroll, and a. On the Security tab, click Add.

Autoenroll permissions to: b. In the Select Users, Computers, or Groups dialog box, in the Enter
• SCUser1 (on the the object names to select box, type SCuser1 (on the domain
domain controller) controller) or SCUser2 (on the member server), and then click OK.
• SCUser2 (on the c. In the Group or user names list, select SCuser1 or SCUser2, allow
member server) Read, Enroll, and Autoenroll permissions, and then click OK.
Wait at this point until your partner completes the creation of the CodeSignComputer certificate template.
7. Log on using your CA " Log on to the domain by using the following credentials:
administrator account with a • User name: CAAdmin1
• Domain: Domain
issue the two Certification Authority.
CodeSignComputer b. In the console tree, expand Certification Authority, expand
certificate templates. DomainCA, and then click Certificate Templates.
CodeSignComputer (where Computer is the NetBIOS name of your
computer), press CTRL and click CodeSignPartnerComputer (where
PartnerComputer is the NetBIOS name of your partner’s computer),
and then click OK.
e. In the details pane, ensure that CodeSignComputer and
CodeSignPartnerComputer appear.
9. Close all open windows and a. Close the Certification Authority console.
(continued)
10. Log on with your domain " Log on to the domain by using the following credentials:
administration account. • User name: Student1
• Domain: Domain
11. In Active Directory Users a. On the Start menu, click Administrative Tools, and then click Active
and Computers, link the Directory Users and Computers.
Autoenrollment GPO to the b. In the console tree, expand Domain.msft, expand Labs, and then click
Module09 organizational Module09.
unit.
c. Right-click Module09, and then click Properties.
d. In the Module09 Properties dialog box, on the Group Policy tab,
click Add.
e. In the Add a Group Policy Object Link dialog box, on the All tab,
select Autoenrollment, and then click OK.
f. In the Module09 Properties dialog box, click OK.
12. Close all open windows and a. Close Active Directory Users and Computers.
Exercise 7
Signing an Autoenrollment Certificate Request with a Smart Card
In this exercise, you will test your CodeSignComputer certificate deployment to ensure that you are
prompted to provide your smart card PIN to sign the certificate request.
A smart card reader is required to perform this exercise. If you do not have a smart card reader,
view the demonstration instead. The demonstration is located under Multimedia on the Web page
Scenario
To increase the issuance security of Code Signing certificates, the version 2 certificate template
requires that all certificate requests be signed with a smart card certificate. You must test the
autoenrollment process to ensure that the requesting user is prompted for the smart card PIN during
autoenrollment.
If you do not have access to a Schlumberger smart card and smart card reader, you can view the
demonstration under Multimedia on the Web page on the Student Materials compact disc.
1. Log on using your smart a. Insert the smart card into the smart card reader.
card. b. In the Log On to Windows dialog box, in the PIN box, type 00000000
and then click OK.
Wait for the automatic enrollment ballon to appear in the notification area, which may take up to 90 seconds.
If it does not appear, type gpupdate /force at a command prompt.
2. Click the autoenrollment a. In the notification area, click the Certificate enrollment balloon.
balloon and start the b. In the Certificate Enrollment dialog box, click Start.
certificate enrollment
A dialog box appears, informing you that you may need to enter
process.
your password or personal identification number (PIN) or insert
a smart card.
3. Sign the certificate request a. In the Certificate Enrollment dialog box, click OK.
with your smart card. b. In the Confirm Smart Card PIN dialog box, in the Please enter your
PIN code box, type 00000000 and then click OK.
4. View the properties of the a. Click Start, click Run, type Certmgr.msc and then click OK.
CodeSignComputer b. In the console tree, expand Personal, and then click Certificates.
certificate, and then save
any change and log off the c. Double-click CodeSignComputer (where Computer is the NetBIOS
network. name of your computer).
You must scroll to the right to view the Certificate Template
column.
(continued)
Is there any indication in the properties of the CodeSignComputer certificate that a smart card signature was
required to issue the certificate?
No. As currently configured, the certificate properties do not indicate that a smart card signature is
required. If such a requirement is defined elsewhere, the Medium Assurance issuance policy OID or a
custom issuance policy OID can designate this issuance process.
4. (continued) d. In the Certificate dialog box, click OK.

Exercise 8
Planning for Re-enrollment
In this exercise, you will determine the best method to re-enroll the smart card certificates that were
issued to the users in your organization.
Scenario
You are the PKI administrator of your organization’s network. The organization successfully
deployed smart card certificates to the organization’s users by using an enrollment agent.
The validity period of the smart card certificates will expire in a few months. Your manager has
asked you to develop a method to re-enroll the smart card certificates, but without the same
administrative effort and time of the initial project, when smart card certificates were issued.
Requirements
In addition to reducing the time and effort involved, you must meet the following requirements:
! The client computers run a mix of Windows 2000 Professional and Windows XP Professional.
The solution must provide automated re-enrollment for both client operating systems.
! Some portable computers are not members of domains in the organization’s forest. The re-
enrollment design must allow users of these portable computers to re-enroll their smart card
certificates.
! The smart card users must provide proof that their previous smart card was issued in a face-to-face
interview.
! If a smart card user attempts to enroll the previous version of the smart card certificate template,
the users must be issued a certificate based on the new certificate template.
! Smart card certificates must be issued only to Schlumberger smart cards.
CA Hierarchy Configuration
Your organization’s network has a Windows 2000 Active Directory directory service that
implements the Windows Server 2003 PKI. It has deployed the following CA hierarchy:
The following information describes the configuration of the CA hierarchy:

! The Root CA and Policy CA are offline CAs and are removed from the network.
! The Root CA and Policy CA are running Windows Server 2003, Standard Edition, and use
Hardware Security Module (HSM) to protect private keys.
! The Europe CA and Asia CA are online CAs, which are configured as enterprise subordinate CAs.
! The Europe CA and Asia CA run Windows Server 20003, Enterprise Edition.
! The Europe CA and Asia CA issue all certificates to users in the forest.
Open the Certificate Templates MMC

To answer the following questions, it is recommended that you view the certificate templates in the
Certificate Templates MMC. Use the following procedure to open the Certificate Templates MMC.
1. Ensure that you are logged " Log on to your computer by using the following information:
administrator.
domain)
Templates console. b. In the Certificate Templates dialog box, click OK.
Questions Based on the CA hierarchy configuration and the stated requirements, answer
the following design questions:
1. How can you automate the renewal of smart card certificates for users who
have Windows XP computers that are members of the forest?
You can automate the renewal of smart card certificates by using
Autoenrollment Settings to automatically distribute the updated
certificates to user accounts.
____________________________________________________________
____________________________________________________________
____________________________________________________________
2. How can you automate the re-enrollment of smart card certificates for users
who have computers running Windows XP that are not members of the
forest?
Autoenrollment Settings do not work for users who use computers that
are not domain members. Several alternatives exist. The user can log on
to a computer that is a member of a domain or use remote desktop to
connect to a computer running Windows Server 2003 that is a member
of the domain.
____________________________________________________________
____________________________________________________________
____________________________________________________________
3. If a user has a computer running Windows 2000 Professional, can you use
autoenrollment to re-enroll the smart card certificate? If not, what do you
recommend as a solution for this user?
A user that has a computer running Windows 2000 Professional must
log on to a computer running Windows XP that is a member of the
domain.
____________________________________________________________
____________________________________________________________
____________________________________________________________
4. How can a user prove her identity when you renew her smart card certificate
without having another face-to-face meeting with a smart card enrollment
agent?
The certificate template can require that the user sign the certificate
request with the private key of their current smart card certificate.
____________________________________________________________
____________________________________________________________
____________________________________________________________
5. What combination of application policies and issuance policies can identify

the AgentSmartCard certificates that you created in Exercise 3 of this lab?
The AgentSmartCard certificate includes a Smart Card User
application policy OID and a High Assurance issuance policy OID.
____________________________________________________________
____________________________________________________________
____________________________________________________________
6. How would you configure the Issuance Requirements tab of a new version
2 smart card certificate template to require the user to sign the smart card
certificate request with his current smart card?
CA certificate manager approval Disabled

This number of authorized signatures Enabled and 1
Policy type required in signature Both application and issuance policy
Application policy Smart Card logon
Issuance policies High Assurance
Require the following for re-enrollment Valid existing certificate
7. In the following table, define the settings on the Request Handling tab to
meet the design requirements for the new smart card certificate template.
Purpose Signature and smart card logon

Do the following when the subject is Prompt the user during enrollment
enrolled and when the private key and require user input when the
associated with this certificate is used private key is used
CSPs Only enable the Schlumberger
Cryptographic Service Provider
8. How would you ensure that certificate requests for a certificate based on the
AgentSmartCard certificate template are issued a certificate based on the
new certificate template?
Add the AgentSmartCard certificate to the Superseded Templates tab
of the new version 2 smart card certificate.
____________________________________________________________
____________________________________________________________
____________________________________________________________
9. What permissions must you assign to allow autoenrollment of the new

version 2 smart card certificates?
You must assign Read, Enroll, and Autoenroll permissions to the group
that contains all smart card users.
____________________________________________________________
____________________________________________________________
____________________________________________________________
Course Evaluation

Your evaluation of this course will help Microsoft understand the quality of
your learning experience.
At a convenient time before the end of the course, please complete a course
evaluation, which is available at http://www.CourseSurvey.com.
Microsoft will keep your evaluation strictly confidential and will use your
responses to improve your future learning experience.
Module 10: Securing
Web Traffic by Using
SSL
Contents
Overview 1
Lesson: Introduction to SSL Security 2
Lesson: Enabling SSL on a Web Server 9
Lesson: Implementing Certificate-based
Authentication 20
Lab A: Deploying SSL Encryption on a
Web Server 31
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part
of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted
in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or
for any purpose, without the express written permission of Microsoft Corporation.
respective owners.
Module 10: Securing Web Traffic by Using SSL iii
Instructor Notes
Presentation: Secure Sockets Layer (SSL) is a protocol that provides encrypted
60 minutes communications over the Internet. It is the default protocol that e-commerce
sites use to protect data from theft and exposure, to enable certificate-based
Lab: authentication, and to verify the Web site name. This module describes how
45 minutes security is implemented in a Web environment.
The students will learn to implement SSL security and certificate-based
authentication.
! Describe how security is implemented in a Web environment.
! Configure Internet Information Services 6.0 (IIS) to implement SSL
security.
! Implement certificate-based authentication for Web applications.
Required materials To teach this module, you need:

! Microsoft® PowerPoint® file 2821A_10.ppt.
! The multimedia presentation, Using SSL to Secure Web Traffic.

! Complete the lab.
! Review the multimedia presentation, Using SSL to Secure Web Traffic.
iv Module 10: Securing Web Traffic by Using SSL

Lesson: Introduction to SSL Security

This lesson introduces students to implementing SSL security for IIS. The
lesson describes how SSL protects transmitted data and discusses how
certificates are used to implement SSL.
lesson.
Why Use SSL to Secure In this topic, review each reason for implementing SSL. Tell students about the
Web Traffic? security risks that occur when they do not implement SSL on a Web site.
Include discussions about authentication interception and the interception of
actual data. If students ask about IPSec encryption, compare it to SSL
encryption and mention that SSL is an application-layer encryption that requires
that applications know how to implement this form of encryption. In
comparison, IPSec performs encryption at the IP layer.
Multimedia: Using SSL This multimedia presentation shows how SSL protects data and how the pre-
to Secure Web Traffic master secret is exchanged between the Web client and the Web server. Ensure
that students understand how encryption occurs when data is transmitted
between the Web server and the Web client.
Introduce the multimedia presentation as an example of how certificates are
used. After the multimedia presentation, review the process and answer any
questions.
The multimedia files are installed on the instructor computer. To open a
multimedia presentation, click the animation icon on the slide.
Certificates Used for an Focus on the server certificates and the user certificates that students implement
SSL Session in an SSL solution for a Web service. Mention which certificates are mandatory
and which certificates are optional.
Guidelines for Choosing This topic can generate a lot of classroom discussion. Ask the students where
a Private or Commercial their organization acquires their Web Server certificates. In many cases, the
CA organizations purchase certificates from commercial certification authorities
(CAs)—even when the certificate is only for internal use—and never expose the
certificates to external Web clients.
Lesson: Enabling SSL on a Web Server

This lesson describes the process of implementing SSL encryption on a Web
server.
How to Acquire a Web Explain that if a Web server is only for internal use, such as an intranet
Server Certificate from a application, the organization may acquire a Web Server certificate from a
Private CA private CA in your CA hierarchy. Discuss the certificate template selection at
this point. Explain that the Web Server certificate is recommended because the
Web Server Certificate Wizard only looks for the Web Server certificate
template. Tell students that they can use a custom version 2 certificate template
for installation, but the students cannot use the wizard with the custom
template. Consider demonstrating the steps by installing a Web Server
certificate on the instructor computer.
Module 10: Securing Web Traffic by Using SSL v
How to Acquire a Web Tell students that they should install a Web Server certificate from a
Server Certificate from a commercial CA if the Web server is an extranet Web server or is exposed to
Commercial CA external clients that must trust the content of your Web server. Mention to
students that the same installation method is used if you acquire a Web Server
certificate from a standalone CA, rather than from an enterprise CA. The only
difference with the acquisition from a commercial CA is that money is
exchanged when the certificate is purchased.
SSL Configuration Explain to students that after they install a Web Server certificate on a Web
Options server, they can configure various SSL options. Demonstrate the options if you
installed a Web Server certificate on the instructor computer.
Certificate Deployment Expect to spend some extra time on this page, because students like to discuss
for Complex their own custom configurations. Although the slide shows ISA as the firewall,
Configurations you can discuss other firewall and SSL-acceleration options. For example, if
you use a CheckPoint Firewall-1 firewall, you use the same certificate
deployment as ISA with Server Publishing. Likewise, if you use a Web
accelerator, such as an F5 device, you implement the same configuration as the
ISA with Web Publishing. To decide whether to use a particular firewall or
device, students should review the documentation of the firewall or SSL
acceleration device.
Guidelines for Enabling Review each guideline in the slide and answer any questions. Spend extra time
SSL Security discussing the modification requirements for the CPS when a Web server is
exposed to nonemployees.
Lesson: Implementing Certificate-Based Authentication

After you implement SSL, you can increase the strength of user authentication
by requiring certificate-based authentication. This lesson describes the process
of implementing certificate-based authentication in an Active Directory®
directory service environment and other environments.
Web-based Discuss each authentication method and the security issues of the weaker
Authentication Methods authentication protocols. For example, some methods, such as digest
authentication, protect the transmitted password well, but weaken security on
the domain controllers.
Types of Certificate Compare and contrast one-to-one and many-to-one certificate mappings. Ask
Mapping students to open the Certificates console (Certmgr.msc) and view a certificate
that is issued to their user account. Look at the Details tab and discuss how
many-to-one mappings are configured. Compare similar attributes on the
Details tab. For example, if the subject name drops the first CN=UserName
attribute, all certificates that one CA issues can be mapped to a single user
account.
How to Implement Discuss the procedure to implement a certificate mapping in IIS. Also discuss
Certificate Mapping in scenarios in which students would perform the mapping in IIS. Examples
IIS include a Web server in a workgroup, a Web server in a Microsoft®
Windows NT® 4.0 domain, and a Web server in a Novell NetWare network.
Remind students that the person who configures the mapping in IIS must know
the password of the user account. In most cases, the remote user does not
control the user account—the person who defines the mapping controls this
user account.
vi Module 10: Securing Web Traffic by Using SSL
How to Implement Explain that Active Directory does not necessarily require them to perform the
Certificate Mapping in mapping as described on the page. If the certificate is issued by an enterprise
Active Directory CA in your organization, the user’s User Principal Name (UPN) may exist in a
subject alternate name. The UPN is mapped to a user’s account by matching the
UPN in the certificate to a UPN in the global catalog. This implicit mapping
works because the UPN is unique in the forest.
Guidelines for Review each guideline and answer any questions.
Certificate Mapping
Lab A Ensure that the students enter the correct DNS name for their Web server in
Exercise 1, step 3i of the lab. Many students will accept the default setting,
which is the computer’s NetBIOS name, rather than the computer’s DNS name.
Lab A: Deploying SSL Encryption on a Web Server

In this lab, students will deploy smart cards by using a smart card enrollment
station.
! Install a Web Server certificate.
! Enable SSL encryption for a Web server virtual directory.
! Enforce certificate-based authentication.
! Perform certificate mapping in Active Directory.
! Perform certificate mapping in IIS.
Lab Setup
Setup requirement 1 The labs in this module require that there is a CA hierarchy with an offline root
CA and an enterprise subordinate CA. Students must complete all of Labs A, B,
and C in Module 3, “Creating a Certification Authority Hierarchy,” in Course
2821, Designing and Managing a Windows Public Key Infrastructure.
enforced. Students must complete Lab A in Module 4, “Managing a Public Key
CertTmplAdmins global group. Students must complete Lab A in Module 5,
“Configuring Certificate Templates,” in Course 2821.
zone in the Default Domain Policy. Students must complete Lab B in Module 3,
“Creating a Certification Authority Hierarchy,” in Course 2821.
Module 10: Securing Web Traffic by Using SSL vii
Lab Results
changes:
! A Web Server certificate is installed on the member server and the domain
controller for each student pair of computers.
! C:\moc\2821\labfiles\Module10 is configured as an IIS virtual directory
named Security.
! The permissions for the folder c:\moc\2821\labfiles\Module10 are modified
to allow only Read access to the Domain\WebAccess domain local group.
! The Security virtual folder is configured to require client certificates for
authentication.
! The Windows Directory Service Mapper is enabled to allow Active
Directory certificate mapping.
! The Windows Directory Service Mapper is later made unavailable to allow
IIS certificate mapping.
! Web Authentication certificates are issued to the Web1 and Web2 user
accounts.
! The Web1 and Web2 Web Authentication certificates are exported to
Base 64-encoded export files.
! The Base 64-encoded export files are mapped to the Web1 and Web2 user
accounts in IIS by implementing one-to-one mappings.
Module 10: Securing Web Traffic by Using SSL 1
Overview

Introduction Secure Sockets Layer (SSL) is a protocol that provides encrypted
communications on the Internet. It is the default protocol that e-commerce sites
use to protect data from theft and exposure, to enable certificate-based
authentication, and to verify the Web site name.
! Describe how security is implemented in a Web environment.
! Configure Internet Information Services 6.0 (IIS) to implement SSL
security.
! Implement certificate-based authentication for Web applications.
2 Module 10: Securing Web Traffic by Using SSL
Lesson: Introduction to SSL Security

Introduction Hypertext Transfer Protocol (HTTP) sends and receives data between Web
servers and Web clients in the form of plain text. It transfers authentication data
in clear text formats or in easily decrypted formats such as Base64. HTTP poses
a big security risk for Web traffic because anyone can view the plain text data
that travels over HTTP. For security purposes, many businesses that operate on
the Web use encryption in the form of SSL.
! Explain why you should use SSL to secure Web traffic.
! Describe how SSL works.
! Identify the certificates that SSL requires.
! Determine whether to obtain a certificate for a Web server from a private or
commercial certificate authority (CA).
Why Use SSL to Secure Web Traffic?

Introduction HTTP is one of the most commonly used protocols on the Internet today, but it
allows inspection of all data in the data stream while the data is transmitted.
Using SSL SSL is an application-level protocol that encrypts HTTP traffic to protect the
confidentiality of data. Implementing SSL offers the following advantages:
! You can use Web-based applications to input and transmit confidential data.
The data is encrypted from the Web-based client to the Web server.
! You can validate the identity of the Web server. The Web server provides
its certificate as a form of authentication. If the certificate is chained to a
root CA that the Web client trusts, and if the certificate passes all validity
tests by the client’s certificate chaining engine, the certificate chaining
engine designates the Web site as authenticated and trusted.
Note The Domain Name System (DNS) name that a user types in the Web
browser must match the subject of the Web Server certificate. If the name does
not match, a warning appears.
Multimedia: Using SSL to Secure Web Traffic

Introduction To view the Using SSL to Secure Web Traffic presentation, open the Web page
on the Student Materials compact disc, click Multimedia, and then click the
title of the presentation.
Key points This presentation demonstrates how a Web client and a Web server establish a
secure socket layer (SSL) connection, including:
! The process of exchanging a certificate.
! The components of the certificate that are used in the process.
Certificates Used for an SSL Session

Introduction When you deploy SSL security on a Web server, you must acquire the
necessary certificates for the Web server. Each user that is authenticated by the
Web server may also require a certificate.
Web Server certificates You can implement SSL on a Web server when you install a Web server
certificate in the Web server’s computer profile. The Web server certificate
enables the ability to modify the SSL configuration on the Web server and
authenticates the Web server’s identity. A Web client uses the Web Server
certificate to secure the client-generated session key when it is transmitted from
the Web client to the Web server.
When you enable SSL on the Web server, IIS ensures that a Web server
certificate exists in the computer’s machine store. If a Web Server certificate
does not exist in the machine store, you can use the Web Server Certificate
Wizard to create and submit a certificate request to an enterprise CA, or to an
external CA if you use a commercial CA.
Note The Web Server Certificate Wizard issues only certificates that are based
on the Web Server certificate template. If you require a customized version 2
certificate template that is based on the Web Server certificate template, you
cannot use the Web Server Certificate Wizard to generate the Web server’s
certificate request.
User certificates When you enable SSL, you can also implement certificate-based authentication.
In this authentication method, the user presents a certificate that includes the
Client Authentication application policy object identifier (OID) to the Web
server. The certificate that the user presents must chain to a root CA that the
Web server trusts and pass all validity tests that the Web server applies to the
certificate.
When the user connects to a Web site that enforces certificate-based
authentication, the user’s Internet browser prompts the user to select a
certificate from the user’s certificate store. IIS examines the information in the
presented certificate and uses the user account that is associated with the
certificate to log on the user. When IIS has verified the user with the user’s
certificate, the user is authenticated and can use the site.
Guidelines for Choosing a Private or Commercial CA

Introduction When you enable SSL on a Web server, determine the type of CA that you will
acquire the Web Server certificate and user authentication certificates from.
Typically, you acquire the certificates from either a private CA, which is
managed and hosted by your organization, or a commercial CA.
Choosing commercial Third-party organizations create and manage commercial CAs. Choose a
CAs commercial CA if you conduct most of your business with external customers
and clients and you want to outsource the management and issuance of
certificates.
The advantages of choosing a commercial CA include:
! Increased user confidence when you conduct transactions because the
organization that hosts the commercial CA has PKI expertise and industry
recognition.
! Immediate trust of the Web Server certificate by all organizations that trust
the commercial root CA.
! Liability insurance for commerce-based Web sites.
The disadvantages of choosing a commercial CA include:

! Less flexibility in managing certificates.
! Different management standards in some cases—one for internally issued
certificates and one for commercially issued certificates.
! Higher costs because commercial CAs usually include charges for each
certificate.
Choosing private CAs Organizations create and manage private CAs internally. Choose a private CA
if you conduct most of your business with partner organizations and you want
to maintain control of how your company issues certificates.
The advantages of choosing a private CA include:
! Ability of an organization to enforce its certificate policies.
! Ability of an organization to manage its certificate policy to match its
overall security policy.
! Easy modification of certificates to include custom application policies or
certificate policies in issued certificates.
! The use of autoenrollment to deploy both user and computer certificates
without user intervention.
! Reduced costs that are associated with issuing certificates.
The disadvantages of choosing a private CA include:

! Time and resources that are required for an organization to manage its own
certificates.
! Time and resources that are required for an organization to deploy its own
public key infrastructure (PKI), which may require even more time if the
organization currently uses a commercial service provider.
Lesson: Enabling SSL on a Web Server

Introduction To enable SSL on a Web server, acquire and install a Web Server certificate,
and then determine how you will configure the Web server to implement SSL
encryption. The configuration process ensures that your implementation of SSL
meets the security needs of your organization.
! Acquire a Web Server certificate from a private CA.
! Acquire a Web Server certificate from a commercial CA.
! List SSL configuration options.
! Deploy certificates for complex configurations.
! List the guidelines for enabling SSL security.
How to Acquire a Web Server Certificate from a Private CA

Introduction If your organization wants to implement SSL encryption on a Web server on
your private network, the Web server administrator submits the certificate
request to an online enterprise CA (also called a subordinate enterprise CA) on
your organization’s network. The CA immediately processes the certificate
request based on the permissions that are assigned to the computer account of
the IIS server or the Web administrator that submits the request.
Procedure for You can install a Web Server certificate from the Internet Information Services
requesting a Web Server (IIS) console. In the console, you can request a Web Server certificate for a
certificate from a private Web site from a private CA, and then configure the IIS server to implement
CA SSL encryption.
To request a Web Server certificate from a private CA:
1. In Administrative Tools, open the Internet Information Services (IIS)
console.
2. In the console tree, expand Web Sites, right-click Web Site (where Web Site
is the name of the Web site where you want to enable SSL encryption), and
then click Properties.
In the Web Site Properties dialog box, on the Directory Security tab, click
Server Certificate.
a. On the Welcome to the Web Server Certificate Wizard page, click
Next.
b. On the Server Certificate page, click Create a new certificate, and
then click Next.
3. On the Delayed or Immediate Request page, click Send the request
immediately to an online certification authority, and then click Next.
4. Provide name and key details for the Web Server certificate request by
performing the following steps:
a. On the Name and Security Settings page, enter the Friendly name for
the certificate, key length, and CSP information, and then click Next.
b. On the Organizational Information page, enter the names of the
organization and the organizational unit (OU), and then click Next.
c. On the Your Site’s Common Name page, enter the fully qualified
domain name (FQDN) of the Web site, and then click Next.
d. On the Geographical Information page, enter country/region,
state/province and city/locality information, and then click Next.
e. On the SSL Port page, accept the default SSL port, and then click Next.
5. On the Choose a Certification Authority page, choose which online
enterprise CA you want to submit the certificate request to, and then click
Next.
6. On the Certificate Request Submission page, review the certificate request
parameters, and then click Next.
The CA will either issue or deny the certificate request based on the
issuance requirements of the Web Server certificate template.
7. On the Completing the Web Server Certificate Wizard page, click
Finish.
If a Web server hosts multiple Web sites, you can install separate Web Server
certificates for each Web site. To do this, run the Web server Certificate Wizard
in the properties of each Web site the Web server hosts.
Note When you request a Web Server certificate, ensure that the FQDN that
you enter in the display name of the Web site matches the FQDN that all clients
use to connect to the Web site. If the name does not match, the user receives an
error message that the certificate name does not match the name of the Web
site. The only way to rectify the name mismatch is to remove the existing Web
Server certificate and request a new Web Server certificate with the correct
FQDN.
How to Acquire a Web Server Certificate from a Commercial CA

Introduction If your organization requires that anyone who connects to your Web site can
recognize the Web server certificate that implements SSL, you typically request
the certificate from a commercial CA organization. The certificate is chained to
a common trusted root CA that most organizations trust.
Procedure for When you submit a Web Server certificate request to a commercial CA, it
requesting a Web Server generates a certificate request file, which you then submit to the commercial
certificate from a CA organization. After it reviews the certificate request and validates your
commercial CA organization’s identity, the commercial CA organization issues the Web Server
certificate.
To request a Web Server certificate from a commercial CA:
1. In Administrative Tools, open the Internet Information Services (IIS)
console.
2. In the console tree, expand Web Sites, right-click Web Site (where Web Site
is the name of the Web site where you want to enable SSL encryption), and
then click Properties.
3. In the Web Site Properties dialog box, on the Directory Security tab, click
Server Certificate.
4. In the Server Certificate Wizard:
a. On the Welcome to the Web Server Certificate Wizard page, click
Next.
b. On the Server Certificate page, click Create a new certificate, and
then click Next.
5. On the Delayed or Immediate Request page, click Prepare the request
now, but send it later to create a PKCS #10 certificate request file, and
then click Next.
6. Provide name and key details for the Web Server certificate request by
a. On the Name and Security Settings page, enter the Friendly name for
the certificate, the key length, and CSP information, and then click Next.
b. On the Organization Name page, enter the names of the organization
and the OU, and then click Next.
c. On the Your site’s Common Name page, enter the FQDN of the Web
site, and then click Next.
d. On the Geographical Information page, enter country/region,
state/province and city/locality information, and then click Next.
e. On the Certificate Request File Name page, enter a name for the
certificate request file, and then click Next.
f. On the Certificate Request Submission page, review the certificate
request parameters, and then click Next.
g. On the Completing the Web Server Certificate Wizard page, click
Finish.
7. Send the certificate request file to the commercial CA organization.
8. Install the certificate from the commercial CA organization by performing
the following steps:
a. In the Internet Information Services (IIS) console, in the Web Site
Properties dialog box, on the Directory Security tab, click Server
Certificate.
b. On the Welcome to the Web Server Certificate Wizard page, click
Next.
c. On the Pending Certificate Request page, click Process the pending
request and install the certificate, and then click Next.
d. On the Process a Pending Request page, designate the certificate
response file from the commercial CA organization, and then click Next.
e. On the Certificate Summary page, review the details of the Web Server
certificate, and then click Next.
f. On the Completing the Web Server Certificate Wizard page, click
Finish.
Note You must implement this procedure when you request certificates for
third-party Web servers, such as an Apache Web server, or for SSL-acceleration
network devices, such as an F5 Web accelerator device.
SSL Configuration Options

Introduction After you install a Web Server certificate on your Web server, you can
implement SSL encryption options to define how SSL encryption is enforced
on the Web server. If there are multiple Web sites on the Web server, each Web
site can implement unique SSL configuration options.
SSL configuration You can use the following SSL configuration options:
options
! Enforce SSL encryption for the entire Web site. Ensures that access to the
Web site, directory, and files on the Web site are protected with SSL
encryption. If a user uses a weaker form of authentication, such as basic
authentication, the authentication data is encrypted to prevent interception.
! Enforce 128-bit encryption. Increases the strength of the encryption for all
data that is transmitted to and from the SSL-protected Web site. Using this
option requires that all Web browsers support 128-bit encryption. A Web
browser that does not perform 128-bit encryption cannot access the Web
site.
! Require client certificates. Enables certificate-based authentication for the
Web site after you enable SSL. Certificate-based authentication enforces
mutual authentication of the user and the Web server by using the user’s
certificate and the Web server’s certificate to prove the identity of the user
and the Web server.
! Implement host headers. Allows multiple Web sites to share an IP address

on a Web server if the Web server hosts multiple SSL-protected Web sites.
The Web server determines which Web site content to provide to the Web
client by inspecting the FQDN in the host headers that the user’s browser
sends \to the Web server.
Note To implement host headers, acquire Web Server certificates for each
FQDN that is defined in a host header.
! Define SSL listening ports. Defines what port the Web site uses to listen for
SSL connections. By default, the Web site listens on Transport Control
Protocol (TCP) port 443, but you can configure a custom port. For example,
if your Web server hosts multiple Web sites, and the Web browsers in your
organization do not support host headers, you can host multiple SSL-
protected Web sites on a Web server by configuring unique listening ports
for SSL for each Web site.
Certificate Deployment for Complex Configurations

Introduction To ensure high availability and enhance the security of Web servers that are
protected with SSL encryption, you can implement advanced network
configurations. For example, if you cluster Web servers to ensure high
availability in the event of server failure, and you place Web servers behind
firewalls to check the content that is transmitted to the Web server, you can
implement an advanced network configuration to deploy certificates for SSL-
protection of these Web sites.
Deploying certificates When you cluster a Web server by using clustering or Network Load Balancing
for clustered servers Service (NLBS), you can configure the Web servers in the cluster to protect the
Web sites by using SSL encryption. A cluster or an NLBS cluster requires that
you deploy a Web Server certificate with the same subject name on each Web
server in the cluster.
Note There is no advantage to deploying the same Web Server certificate on

each node in a Web server cluster. A clustered Web server will not fail over for
SSL-protected Web sites even if the same Web Server certificate and key pair
are implemented on each node in the cluster. It does not fail over because the
new node that the Web browser connects to does not have access to the current
symmetric session key, which results in a new session key being generated.
Implementing SSL for Microsoft Internet Security and Acceleration (ISA) Server enables you to
Web servers that are publish Web servers that are located in a network segment that is protected by
protected by ISA server the ISA server. There are two methods for publishing a Web site:
! Server publishing. All HTTPS traffic that is destined to the Web server is
routed from the ISA server to the Web server. The content of the HTTPS
data stream remains encrypted and is not inspected on the ISA server.
! Web publishing. All HTTPS traffic is terminated on the ISA server.
Therefore, an organization can apply application-level filters that enable
perimeter inspection of all content that is sent to the Web server. For
example, by installing the URLScan filter on the ISA server, the ISA server
can inspect all Web-based traffic for allowed HTTP verbs and allowed
extensions of Web content. After the ISA server inspects the HTTPS data, it
can redirect the data as either HTTP or HTTPS traffic, depending on how
Web publishing is defined.
Note For more information about configuring Server Publishing and Web
Publishing on an ISA server, see Module 7, “Configuring Access to Internal
Resources,” in Course 2159, Deploying and Managing Microsoft Internet and
Security Acceleration Server 2000.
! If the ISA server implements Server publishing, the Web Server certificate
is only required on the Web server. The SSL data stream is not decrypted
until it reaches the Web server.
! If the ISA server implements Web publishing, the installation locations of
the Web Server certificate depend on how Web publishing is configured.
Consider the following guidelines for determining where to install the Web
Server certificate:
• If the ISA server redirects the HTTPS traffic as HTTP traffic, install the
Web Server certificate only on the ISA server. The certificate is not
required on the Web server.
• If the ISA server redirects HTTPS traffic as HTTPS traffic, install a Web
Server certificate on the ISA server and another Web Server certificate
on the Web server. The subject of the ISA server’s Web Server
certificate must be the URL that Web clients use to connect to the Web
site. The subject of the Web server’s Web Server certificate must be the
URL that the ISA server uses to redirect HTTPS traffic to the Web
server.
Note If the HTTPS traffic is redirected as HTTPS traffic, a new HTTPS

session is established between the ISA server and the Web server. A developer
must ensure that the application maintains state information so that no data is
lost in the event of a Web client experiencing a failover to another node in the
cluster.
Guidelines for Enabling SSL Security

Introduction Before you implement SSL encryption for Web servers in your organization,
you must ensure that your design for SSL encryption meets all of your
organization’s requirements.
Guidelines for enabling When you enable SSL security to protect Web servers on your network,
SSL security consider the following guidelines:
! Enable SSL for only those Web sites that require enhanced security. Enable
SSL for the entire Web site, not just for specific pages on the Web site. This
way, basic authentication, if implemented, is not compromised when you
switch to Web pages that are not protected by SSL.
! Ensure that all Web clients trust the root CA certificate of the Web server’s
certificate chain.
• If a commercial CA issues the Web Server certificate, all organizations
that trust the commercial CA organization trust your certificate.
• If a private CA issues the Web Server certificate, the organizations that
connect to the Web server must trust your organization’s root CA or
issue a Cross Certification Authority certificate to the CA in your
organization that issued the Web Server certificate.
! Update your organization’s CPS to reflect the liability of the host
organization if the Web site is compromised. Update the CPS to reflect
where the Web clients come from. For example, if the Web site is a public
Web site, the CPS must accommodate external users that connect to the
Web site.
! Ensure that all CA certificates and CRLs in the certificate chain can be
downloaded. Most Web browsers check CRLs when a user connects to
SSL-protected Web sites. If all CA certificates and CRLs are unavailable,
the certificate chaining engine cannot determine the validity of the Web
Server’s certificate, which results in the connecting users receiving a
Security Alert message.
! Ensure that the subject of the Web Server certificate matches the DNS name
of the Web server. If the subject name does not match the FQDN of the Web
site, the connecting user is warned that it may be a fake Web site.
Lesson: Implementing Certificate-based Authentication

Introduction After you enable SSL encryption on a Web site, you can increase the strength of
authentication by enforcing certificate-based authentication. Rather than type a
user account and password for authentication, a user presents a certificate from
her user certificate store. The Web server or the Active Directory® directory
service performs certificate mapping to associate the certificate account either
in Active Directory or in the local Security Account Management (SAM)
database of the Web server.
! Identify security levels of Web-based authentication methods.
! Describe how certificate mapping works.
! Implement certificate mapping in IIS and in Active Directory.
! List the guidelines for certificate mapping.
Web-based Authentication Methods

Introduction IIS supports several methods for authenticating user accounts when a user
connects to a Web-based application. Each Web-based authentication method
provides different levels of security for the user account and password
combination.
Anonymous By using anonymous authentication, users can access the public areas of your
authentication Web site without being prompted for a user name or password. When you
configure your Web site for anonymous access and a user attempts to connect to
your public site, IIS automatically authenticates the user by using the Internet
Guest Account (IUSR_ComputerName). The authentication security rating for
anonymous authentication is not applicable because no authentication
credentials are provided to the Web server.
Basic authentication Basic authentication is an authentication protocol that is defined as part of the
HTTP 1.0 protocol and is supported by the majority of browsers. The advantage
of basic authentication is its widespread support and compatibility. Its
disadvantage is that passwords are sent over the network in an unencrypted
form by using Base64 encoding.
Many organizations consider basic authentication a security risk, because
someone can easily intercept and decipher passwords by monitoring
communications on your network.
Digest authentication Digest authentication offers an advantage over basic authentication in that
passwords are not sent over the network. Instead, the browser takes both the
user’s password and other information about the user’s request to the Web
server, creates a hash, a form of nonreversible encryption, and sends it to the
IIS server. Because it is not feasible to decipher nonreversible encryption
mathematically, the original text cannot be deciphered from the hash. This hash
is compared to a version of the hash that is stored in the user’s properties.
Note To implement digest authentication, you must select the Store password
in reversible encryption option for a user account and the user must change
their password after the option is selected.
Digest authentication increases the security of the transmitted password, but

reduces the security of the password storage in Active Directory, because the
password is not stored in reversible encryption format.
.NET Passport Microsoft .NET Passport is a suite of e-business services that makes it easier,
faster, and more secure to purchase goods and services online. Users can create
a single sign-in name and password for easy, secure access to all Web sites and
services that use .NET Passport. These Web sites rely on the .NET Passport
central server to authenticate users, rather than hosting and maintaining their
own proprietary authentication systems. However, it is the responsibility of the
Web site to control user’s permissions.
All .NET Passport sign-in and core profile cookies are strongly encrypted. Each
participating Web site receives a unique encryption key to ensure privacy.
Integrated Windows Integrated Windows authentication is a more secure authentication in IIS than
authentication the previously discussed forms of authentication because user names and
passwords are not sent across the network. Integrated Windows authentication
either uses the Challenge/Response authentication in Microsoft Windows NT®,
or the Kerberos version 5 protocol.
Authentication is more secure if Kerberos version 5 is used rather than NTLM,
but Kerberos version 5 is only available if the client and Web server are running
Windows 2000 or later and the two computers are members of the same Active
Directory forest or forests that implement a root trust.
Basic authentication You can increase the strength of basic authentication by implementing SSL
with SSL encryption on the Web site on which you implemented basic authentication.
SSL encrypts the Base64 encoded password so that the password cannot be
compromised. This method provides higher security for the authentication data
and provides the most interoperability with other vendor’s Web browsers.
Client certificates Client certificates allow a user to present a certificate to the Web server as a
form of authentication. If the certificate is associated with an account in Active
Directory or the local SAM database of the Web server, the user connects to the
Web server with all of the privileges and authorization that are assigned to that
user account.
Client certificates are a very secure form of authentication because the user who
presents the certificate must also have access to the private key that is
associated with the certificate.
Types of Certificate Mapping

Introduction Your organization may need to support the authentication of external users who
do not have a user account in Active Directory. Certificate mapping allows a
user to access a Web site if the user owns a valid authentication certificate and
an associated private key that the user obtained from outside the organization.
When you use certificate mapping, Active Directory or IIS authenticates users
based on the authority of the presented certificates. The IIS server grants access
to the Web site based on the authentication results. Certificate mapping requires
that a Web Server certificate be installed for the Web site to allow mutual
authentication of the Web site and the user certificate.
You can configure certificate mapping as a one-to-one or many-to-one
mapping. Use one-to-one mapping when you have a relatively small number of
clients or you require individualized access permissions. Use many-to-one
certificate mapping to authenticate large numbers of users who require access to
a particular resource on your network, such as an intranet site.
One-to-one certificate In one-to-one certificate mapping, you create an association between a
mapping certificate that is held by a user and a corresponding user account in Active
Directory or the local SAM database of the IIS server. After you associate a
certificate with a user account, the local SAM database or Active Directory
authenticates the certificate holder based on the associated user account. After
authentication occurs, the user is granted the rights and permissions that the
associated user account permits.
A one-to-one certificate mapping can be either an implicit mapping or an
explicit mapping. Use an implicit mapping when the certificate’s subject
matches a user’s User Principal Name (UPN). Use an explicit mapping when a
certificate’s subject or subject alternative name does not directly map to a user
account in Active Directory.
Note A one-to-one implicit mapping requires that the CA certificate of the CA

that issued the user’s certificate be included in the NTAuth certificate store.
You can view the contents of the NTAuth certificate store by using the PKI
Health Tool in the Windows Server 2003 Resource Kit.
Many-to-one certificate To implement many-to-one certificate mapping, install the CA that issues
mapping certificates to the users as a trusted root for your site, domain, OU, or forest.
You can then set rules that associate all certificates that the CA issues with a
single user account in Windows 2000.
You can use separate many-to-one certificate mappings for different groups that
may require access to resources on your network. You can configure user
accounts that grant different sets of rights and permissions on the basis of the
clients’ ownership of valid certificates that match the mapping rules. For
example, you can associate your employees with a user account that grants
Read access to the entire Web site. Then, you can associate consultants and
employees of business partners with other user accounts that allow access only
to nonconfidential information and selected proprietary information.
Mixing mappings If you define both one-to-one and many-to-one mappings in Active Directory or
IIS, the one-to-one mappings take precedence, which means that you can map
specific groups and individuals. For example, you can associate users from your
company with many-to-one mappings allowing common access privileges to all
users in your company when connecting to a Web site. If one or two specific
individuals require additional privileges when connecting to the Web site,
implement specific one-to-one mappings for those users.
Manually administering one-to-one mappings requires more administrative
effort than administering many-to-one mappings.
How to Implement Certificate Mapping in IIS

Introduction You would perform certificate mapping in IIS when the IIS server is not a
member of an Active Directory forest, or when the certificate mapping is not
required at any other IIS servers in the organization. When you define the
certificate mappings in the Internet Information Services (IIS) console, you
only define the certificate mappings for that particular Web site. To use the
mappings on a second Web site, you must redefine the certificate mappings.
Obtaining the user When you define certificate mappings, you must first obtain the certificate that
certificate an external user will present to your Web site for authentication. The user who
provides the certificate must export this certificate by using a Base64 encoded
format.
Note The easiest way to export the certificate is to open the Certificates
console and use the Certificate Export Wizard.
The IIS server must trust the root CA of the user’s certificate chain, because the
certificate is from an external organization. You can trust the user’s root CA by
importing the root CA certificate into the trusted root store in Active Directory
or on the IIS server. Or, your organization can issue a Cross Certification
Authority certificate to the CA that issued the user’s certificate. This certificate
implements qualified subordination constraints so that the presented certificate
is trusted.
Certificate mapping in After you obtain the user’s certificate, configure IIS to define the one-to-one or
IIS many-to-one certificate mappings. To perform the certificate mapping in IIS:
1. In the Internet Information Services (IIS) console, enable certificate
mapping.
2. Choose whether to perform a one-to-one or many-to-one mapping. The
mapping method determines what attributes of the user certificate IIS uses
to determine which user account to associate with the presented certificate.
3. Import the user’s certificate. You can import and sort multiple certificates
within the list to determine certificate mapping priorities. If you use a many-
to-one mapping, you can define what attributes IIS inspects in the presented
certificate to determine which organization issued the certificate.
4. Select the user account to map to the user certificate and provide the
password for the user account.
Note In the certificate mapping process, you must enter the user’s
password. If the person who configures the certificate mapping is not the
user, the person must know the user’s password or be able to reset it.
How to Implement Certificate Mapping in Active Directory

Introduction You can also use Active Directory to map certificates to user accounts. Several
user certificate templates automatically publish issued certificates to the
properties of a user account. When you perform certificate mapping in Active
Directory, you associate certificates that are issued externally with user
accounts.
Obtaining the user The first step in certificate mapping is to obtain the user certificate from the
certificate external user. You can export the certificate in either a Base64 or Distinguished
Encoding Rules (DER)-encoded format when the certificate is associated with
an account in Active Directory.
If the certificate is from an external organization, configure certificate trust
between your organization and the organization that issued the certificate. To
do so, import the root CA certificate into the trusted root store in Active
Directory or issue a Cross Certification Authority certificate to the CA that
issued the user’s certificate.
Enabling IIS to use After you obtain the user’s certificate, enable IIS to use Active Directory for
Active Directory for certificate mapping. In the IIS console, select the Windows Directory Service
certificate mapping Mapper in the properties dialog box of the Web sites.
Note To use the Active Directory certificate mapping on multiple Web servers,
each Web server must enable certificate mapping and enable the Windows
Directory Service Mapper.
Using Active Directory You can define certificate mappings in Active Directory Users and Computers.
Users and Computers You can use the defined mappings in this console at any IIS server in the forest
for certificate mapping that enables the Windows Directory Service Mapper.
Note Active Directory Users and Computers refers to certificate mappings as

name mappings.
To define a certificate mapping in Active Directory Users and Computers:

1. In the console, select Advanced Features. You can then define name
mappings by right-clicking the user account. You define the name mappings
on a user account-by-user account basis.
2. Import the user’s certificate. In the Security Identity Mapping dialog box,
you can add one or more user certificates to associate with the selected user
account.
3. Define whether to perform a one-to-one or many-to-one mapping. When
you add the certificate, the issuer and subject attributes appear in the Add
Certificate dialog box.
Note Many-to-one mappings in Active Directory do not allow the detailed

definitions that IIS allows. You can only define that all certificates that are
issued by a specific CA are associated with a single user account.
Guidelines for Certificate Mapping

Introduction Before you define certificate mapping in your organization, collect all of the
information and requirements for Web-based application security for your
organization.
Guidelines Consider the following guidelines when you define certificate mapping in your
organization:
! Define certificate mappings in IIS if the certificate mapping is:
• Required on only one IIS server. The certificate mappings that you
define on an IIS server are only recognized by that IIS server. If you
require the same certificate mapping on an additional IIS server, you
must redefine the certificate mapping on the new IIS server.
• Defined in a non-Active Directory environment. Centralized certificate
mappings require that you define the certificate mapping in Active
Directory. If the domain is a Windows NT 4.0 domain, or the network
uses a non-Microsoft operating system, you must define the certificate
mappings on each IIS server on the network.
! Define certificate mappings in Active Directory if more than one IIS server
will use the certificate mapping. When you configure a certificate template,
you can choose to publish the certificate in the UserCertificate attribute of
the user account in Active Directory. These certificate mappings are
available to any IIS server in the forest, which reduces the effort to associate
certificates with user accounts.
! Disable or delete a user account immediately to prevent a user who no

longer works in your organization from accessing the network. A Web
server only recognizes a certificate revocation when the Web server
downloads an updated version of the CRL—which it does only when the
current CRL expires from the Web server’s Internet Explorer cache.
! Use qualified subordination constraints to define which certificates you
trust from a partner organization. You can further define qualified
subordination constraints to approve only certificates with specific
namespaces, application policies, or certificate policies.
Lab A: Deploying SSL Encryption on a Web Server

! Install a Web Server certificate.
! Enable SSL encryption for a Web server virtual directory.
! Perform certificate mapping in Active Directory.
! Perform certificate mapping in IIS.

domain.
Autoenrollment Settings for user objects.
! Created a C:\Temp folder.
! The knowledge and skills to deploy SSL for a Web server.
! The knowledge and skills to enforce certificate-based authentication for a
Web server.
Estimated time to
complete this lab:
45 minutes
Exercise 1
Enabling SSL Encryption in IIS
In this exercise, you will install a Web Server certificate on both computers in your domain. You
will then enforce SSL encryption for the Security virtual directory to ensure that SSL protects all
communications to the virtual directory.
Scenario
Your organization posts sensitive information to a publicly accessible Web site. To protect the data
in the Web virtual directory from interception, you must enable SSL encryption.
domain)
2. In the Internet Information a. On the Start menu, point to Administrative Tools, and then click
Services (IIS) Manager Internet Information Services (IIS) Manager.
console, browse to the b. In the console tree, expand Computer (where Computer is the NetBIOS
default Web site. name of your computer), expand Web Sites, and then click Default
Web Site.
(continued)
3. Enable SSL by running the a. Right-click Default Web Site, and then click Properties.
Web Server Certificate b. In the Default Web Site Properties dialog box, on the Directory
Wizard with the following Security tab, click Server Certificate.
options:
c. On the Welcome to the Web Server Certificate Wizard page, click
• Create a new certificate Next.
• Send the request d. On the Server Certificate page, click Create a new certificate, and
immediately to an online then click Next.
certification authority
e. On the Delayed or Immediate Request page, click Send the request
• Organization: Domain immediately to an online certification authority, and then click
• Organizational unit: Next.
Corporate f. On the Name and Security Settings page, accept the default settings,
• Common name: and then click Next.
Computer.Domain.msft g. On the Organization Information page, in the Organization box,
• Country/Region: CA type Domain (where Domain is the NetBIOS name of your domain).
(Canada) h. In the Organizational unit box, type Corporate and then click Next.
• State/province: i. On the Your Site’s Common Name page, in the Common name box,
Manitoba type Computer.Domain.msft (where Computer is the NetBIOS name of
• City/locality: Winnipeg your computer and Domain is the NetBIOS name of your domain), and
• SSL port: 443 then click Next.
• Certification authority: j. On the Geographical Information page, in the Country/Region drop-

default down list, select CA (Canada).
k. In the State/province box, type Manitoba
l. In the City/locality box, type Winnipeg and then click Next.
m. On the SSL Port page, accept the default setting, and then click Next.
n. On the Choose a Certification Authority page, accept the CA that is
presented, and then click Next.
o. On the Certificate Request Submission page, click Next.
p. On the Completing the Web Server Certificate Wizard page, click
Finish.
q. Click OK.
4. Create a new virtual a. Right-click Default Web Site, point to New, and then click Virtual
directory named Security Directory.
that refers to C:\moc\2821\ b. On the Virtual Directory Creation Wizard page, click Next.
labfiles\module10.
c. On the Virtual Directory Alias page, in the Alias box, type Security
d. On the Web Site Content Directory page, in the Path box, type
C:\moc\2821\labfiles\module10 and then click Next.
e. On the Virtual Directory Access Permissions page, accept the default
settings, and then click Next.
f. On the Virtual Directory Creation Wizard page, click Finish.
(continued)
5. Enable SSL and require a. In the console tree, right-click Security, and then click Properties.
128-bit encryption for the b. In the Security Properties dialog box, on the Directory Security tab,
Security virtual directory. under Secure communications, click Edit.
c. In the Secure Communications dialog box, click Require secure
channel (SSL), click Require 128-bit encryption, and then click OK.
d. In the Security Properties dialog box, click OK.
e. Close Internet Information Services (IIS) Manager.
Wait until your partner completes the previous procedure before you proceed with the lab.
6. In Internet Explorer, open a. Open Internet Explorer.

https://Partner.Domain. b. In the Address bar, type https://Partner.Domain.msft/security (where
msft/security. Partner is the NETBIOS name of your partner’s computer and Domain
is the NetBIOS name of your domain), and then press ENTER.
c. If the Security Alert dialog box appears, click In the future, do not
show this warning, and then click OK.
Verify that the Welcome to the Secure Web Site page appears in
red letters on a black background.
What zone is the Web site located in? If the Web site has any active content, what zone would you
configure for the URL?
The Web site is part of the Internet zone. To view active content, add the zone to the Trusted Sites
zone or the Local intranet zone. These zones allow ActiveX controls to be downloaded.
7. Close Internet Explorer. " Close Internet Explorer.

Exercise 2
Securing the Security Virtual Folder
In this exercise, you will change the permissions of the folder that contains the contents of the
Security Web site so that only members of the Web Access group can access the Web site.
Scenario
You must protect the contents of the Security Web site so that only authorized users may connect to
the site, rather than all users in the domain.
1. Log on using your domain " Ensure that you are logged on with the following credentials:
domain)
2. In the C:\moc\2821\labfiles\ a. Open C:\moc\2821\labfiles.

module10 folder, do the b. In the C:\moc\2821\labfiles folder, right-click Module10, and then
following tasks: click Properties.
• Clear the Allow c. In the Module10 Properties dialog box, on the Security tab, click
inheritable permissions Advanced.
from the parent to
propagate to this d. In the Advanced Security Settings for Module10 dialog box, clear
object and all child the Allow inheritable permissions from the parent to propagate to
objects. Include these this object and all child objects. Include these with entries
with entries explicitly explicitly defined here check box.
defined here check box, e. In the Security dialog box, click Copy.
and copy the existing f. In the Advanced Security Settings for Module10 dialog box, click
permissions. OK.
• Remove all permissions g. In the Module10 Properties dialog box, in the Group or user names
for users. box, select Users, and then click Remove.
• Add default permissions h. Click Add.
for Domain\WebAccess.
i. In the Select Users, Computers, or Groups dialog box, in the Enter
the object names to select box, type Web and then click Check
Names.
j. In the Multiple Names Found dialog box, in the Matching names
box, select WebAccess, and then click OK.
k. In the Select Users, Computers, or Groups dialog box, click OK.
l. In the Module10 Properties dialog box, click OK.
m. Close the C:\moc\2821\labfiles folder.
Exercise 3
Enabling Certificate Mapping in Active Directory
In this exercise, you will enable IIS to use Active Directory to perform certificate mapping.
Scenario
Your organization plans to replicate the Security Web site to multiple Web servers in the
organization. To ensure that consistent certificate mappings occur, you must configure IIS to use
the Active Directory name mapper.
1. Log on using your domain " Ensure that you are logged on to the domain with the following
administration account and credentials:
password. • User name: Student1 (on the domain controller) or Student2 (on
the member server)
domain)
2. Configure the properties of a. On the Start menu, point to Administrative Tools, and then click
the Security virtual directory Internet Information Services (IIS) Manager.
with the following options: b. In the console tree, expand Computer (where Computer is the NetBIOS
• Require client name of your computer), expand Web Sites, expand Default Web
certificates Site, and then click Security.
• Enable client certificate c. In the console tree, right-click Security, and then click Properties.
mapping d. In the Security Properties dialog box, on the Directory Security tab,
under Secure communications, click Edit.
e. In the Secure Communications dialog box, click Require client
certificates.
f. In the Secure Communications dialog box, click Enable client
certificate mapping, and then click OK.
g. In the Security Properties dialog box, click Apply.
3. Clear the check boxes for all a. In the Security Properties dialog box, in the Authentication and
forms of authentication for access control section, click Edit.
the Security Web site. b. In the Authentication Methods dialog box, clear all authentication
method check boxes, and then click OK.
c. In the Security Properties dialog box, click OK.
(continued)
What does clearing all check boxes accomplish?
Clearing all check boxes prevents Internet Explorer from presenting a user authentication dialog box
if certificate-based authentication fails.
4. In the Web site’s properties, a. In the console tree, right-click Web Sites, and then click Properties.
activate the Windows b. In the Web Sites Properties dialog box, on the Directory Security
directory service mapper. tab, click Enable the Windows directory service mapper, and then
click OK.
c. If the Inheritance Overrides dialog box appears, click Cancel.
d. Close Internet Information Services (IIS) Manager.
e. Close all open windows and log off.
5. Log on using your Web " Log on to the domain by using the following credentials:
access account. • User name: Web1 (on the domain controller) or Web2 (on the
member server)
• Domain: Domain
6. Acquire a user certificate a. Click Start, click Run, type Certmgr.msc and then click OK.
using the Certificates – b. In the console tree, click Personal.
Current User console
(Certmgr.msc). c. In the console tree, right-click Personal, point to All Tasks, and then
click Request New Certificate.
e. On the Certificate Types page, in the Certificate Types list, select
User, and then click Next.
Friendly name box, type Web Authentication and then click Next.
Finish.
i. Close the Certificates console.
(continued)
7. Connect to your partner’s a. Open Internet Explorer.

Security Web site, b. If the Internet Explorer dialog box appears, click In the future, do
https://Partner.Domain.msf not show this message, and then click OK.
t/security.
c. In the Address bar, type https://Partner.Domain.msft/security (where
Partner is the NETBIOS name of your partner’s computer and Domain
d. In the Security Alert dialog box, click In the future, do not show this
warning, and then click OK.
e. In the Client Authentication dialog box, ensure that Web1 or Web2 is
selected, and then click OK.
Did you successfully connect to the Web site by using certificate-based authentication?
Yes. The certificate successfully mapped to the Web1 or Web2 user accounts in Active Directory.
What attribute must you select in a certificate template to enable Active Directory certificate mapping?
The certificate template must enable the Publish certificate in Active Directory attribute, so that the
certificate is stored as an attribute of the user account that the certificate was issued to.
8. Close all open windows. a. Close Internet Explorer.

b. Close all open windows.
Exercise 4
Enabling Certificate Mapping in Internet Information Services
In this exercise, you will change IIS to perform the certificate mapping between certificate and user
accounts.
Scenario
You must post the Security Web site on a Web server that is not a domain member in your
organization’s DMZ. You must modify the properties of the Security Web site to perform the
certificate mapping in IIS, rather than in Active Directory.
1. Ensure that you are logged " Ensure that you are logged on with the following credentials:
on using your Web access • User name: Web1 (on the domain controller) or Web2 (on the
domain)
2. Export your User certificate a. Click Start, click Run, type Certmgr.msc and then click OK.
by using a Base-64 encoded b. In the console tree, expand Personal, and then click Certificates.
X.509 (.CER) format to a
file named c. In the details pane, right-click the certificate that is issued to Web1 or
C:\temp\web.cer. Web2, point to All Tasks, and then click Export.
d. On the Certificate Export Wizard page, click Next.
e. On the Export Private Key page, click No, do not export the private
key, and then click Next.
f. On the Export File Format page, click Base-64 encode X.509
(.CER), and then click Next.
g. On the File to Export page, in the File name box, type
C:\temp\web.cer and then click Next.
h. On the Completing the Certificate Export Wizard page, click
Finish.
i. In the Certificate Export Wizard message box, click OK.
j. Close the Certificates – Current User console.
k. Close all open windows and then log off.
(continued)
your domain administrative • User name: Student1 (on the domain controller) or Student2 (on
account. the member server)
domain)
.
4. In Web Sites properties, a. On the Start menu, point to Administrative Tools, and then click
clear the Enable the Internet Information Services (IIS) Manager.
Windows directory service b. In the console tree, expand Computer (where Computer is the NetBIOS
mapper check box. name of your computer), and then click Web Sites.
c. In the console tree, right-click Web Sites, and then click Properties.
d. In the Web Sites Properties dialog box, on the Directory Security
tab, clear the Enable the Windows directory service mapper check
e. If the Inheritance Overrides dialog box appears, click Cancel.
5. In the properties of the a. In the console tree, expand Computer (where Computer is the NetBIOS
Security virtual directory, name of your computer), expand Web Sites, expand Default Web
define a 1-to-1 mapping Site, and then click Security.
with the following b. In the console tree, right-click Security, and then click Properties.
properties:
c. In the Security Properties dialog box, on the Directory Security tab,
• Certificate: in the Secure communications section, click Edit.
\\Partner\c$\temp\
web.cer d. In the Secure Communications dialog box, click Edit.
• Map Name: Web e. In the Account Mappings dialog box, on the 1-to-1 tab, click Add.
Authentication f. If the Insert disk message box appears, click Cancel.
• Account: Domain\Web2 g. In the Open dialog box, in the File name box, type
(on the domain \\Partner\c$\temp\web.cer (where Partner is the NetBIOS name of
controller) or your partner’s computer), and then click Open.
Domain\Web1 (on the h. In the Map to Account dialog box, enter the following information:
member server)
• Map Name: Web Authentication
• Account: Domain\Web2 (on the domain controller) or
Close all open windows and Domain\Web1 (on the member server) where Domain is the
log off the network. NetBIOS name of your domain.
i. In the Map to Account dialog box, click OK.
j. In the Confirm Password dialog box, in the Password box, type
P@ssw0rd and then click OK.
(continued)
5. (continued) k. In the Account Mappings dialog box, click OK.

l. In the Secure Communications dialog box, click OK.
m. In the Security Properties dialog box, click OK.
n. Close Internet Information Services (IIS) Manager.
o. Close all open windows and then log off.
6. Log on using your Web " Log on to the domain by using the following credentials:
access account. • User name: Web1 (on the domain controller) or Web2 (on the
member server)
• Domain: Domain(where Domain is the NetBIOS name of your
domain)
7. Attempt to open a. Open Internet Explorer.

https://Partner.Domain. b. In the Address bar, type https://Partner.Domain.msft/security (where
msft/security. Partner is the NETBIOS name of your partner's computer and Domain
c. In the Client Authentication dialog box, ensure that Web1 or Web2 is
selected, and then click OK.
Did you successfully connect to the Web site with certificate-based authentication?
Yes. The certificate mapped successfully to the Web1 or Web2 user accounts in IIS.
(continued)
What security risk exists when you enable certificate mapping in IIS?
The person who enables certificate mapping must know the password of the user account that the
certificate is associated with.
8. Close all open windows and a. Close Internet Explorer

E-mail Security
Contents
Overview 1
Lesson: Introduction to E-mail Security 2
Lesson: Configuring Secure E-mail
Messages 7
Lesson: Recovering E-mail Private Keys 16
Lesson: Migrating a KMS Database to a
CA Running Windows Server 2003 20
Lab A: Configuring Secure E-mail in
Exchange Server 2003 26
Course Evaluation 43
respective owners.
Module 11: Configuring E-mail Security iii
Instructor Notes
Presentation: E-mail security protects e-mail messages from modification and inspection
60 minutes when the e-mail is transmitted from the sender to the receiver. The
Windows Server™ 2003 Public Key Infrastructure (PKI) prevents the
Lab: modification and inspection of e-mail messages by providing e-mail digital
45 minutes signing and e-mail encryption certificates to users. In this module, students will
learn how to secure e-mail messages in a Microsoft Exchange 2003
environment.
! Describe how e-mail security is implemented by a server running Exchange
in a Windows Server 2003 environment.
! Implement secure e-mail messages in an Exchange 2003 environment.
! Recover e-mail private keys.
! Migrate a Key Management Server (KMS) database to a
Windows Server 2003 Enterprise Edition enterprise certification authority
(CA).
! Complete the lab.
! Read the white paper, Key Archival and Management in
Student Materials compact disc for more information about how to archive
private keys on a Windows Server 2003 CA and how to migrate a KMS
database to a Windows Server 2003 CA.
! Read the white paper, Windows 2000 Server and Key Management Server
Interoperability, under Additional Reading on the Web page on the
Student Materials compact disc for more information about how the KMS
service in Exchange Server 2000 provides private key archival for e-mail
encryption certificates.
iv Module 11: Configuring E-mail Security

Lesson: Introduction to E-mail Security

Microsoft Exchange 2000 provided e-mail security in a Windows 2000
environment by using the KMS service. Windows Server 2003 enhances e-mail
security by introducing improvements for data protection and private key
recovery.
In this lesson, students learn how to protect e-mail messages from modification
and inspection by implementing e-mail encryption and digital signing by using
Secure Multipurpose Internet Mail Extensions (S/MIME).
lesson.
E-mail Security in a In this topic, describe how the KMS service archives the private key in an
Windows 2000 Exchange 2000 environment. Explain that although a KMS environment
Environment provides private key archival for e-mail encryption certificates, you cannot
extend the KMS service to archive other encryption private keys, such as an
Encrypting File System (EFS) private key.
If students are unfamiliar with the KMS service functionality, tell them to see
the key archival process that is discussed in the white paper, Windows 2000
Server and Key Management Server Interoperability, under Additional
Changes to E-mail In this topic, explain how the key archival process is performed by the
Security in a Windows Server 2003 CA, rather than by a separate service, such as the KMS
Windows Server 2003 service.
Environment
Focus on where the e-mail encryption key pair is generated. Explain that when
you use the KMS service, the private keys are generated on the Exchange server
on behalf of the requesting user. This allows the KMS service to archive the
private key, and then securely transmit the private key to the requesting user in
a secured e-mail message.
On the Windows Server 2003 enterprise CA, the key pair is generated on the
requesting user’s computer. The private key is encrypted with the CA’s public
key, and then transmitted securely to the CA.
Steps to Secure RFC- Remind students that there is more than one way to secure e-mail messages in
based E-mail Protocols an Exchange Server 2000 or Exchange Server 2003 environment. If a network
contains non-Microsoft e-mail clients, these clients may connect to the mail
server by using Request for Comment (RFC)-based protocols. Explain that
these protocols transmit authentication data and application data in plain text. If
they implement Secure Socket Layers (SSL) for these RFC-based protocols,
they ensure that information is encrypted when it is transmitted between the e-
mail client and the e-mail server.
Module 11: Configuring E-mail Security v
Lesson: Configuring Secure E-mail Messages

This lesson discusses all of the steps that are required to configure e-mail
messages that are protected by S/MIME in a Microsoft Exchange environment.
The lesson explains how to decide which certificate templates to deploy, how to
configure the enterprise CA, how to plan the deployment of the certificates to
end users, and how to configure the Microsoft Outlook® client software.
Steps to Configure This page provides an overview of the following topics. Provide only a brief
Secure E-mail Messages summary of the upcoming topics.
How to Create the Ask students how their organization uses e-mail certificates. Discuss the
Required Certificate benefits and drawbacks of each certificate template strategy. You can also
Templates demonstrate the important certificate template settings that are related to secure
e-mail certificates. Focus on the following actions:
! Prompting the user during enrollment and when the private key is used
! Publishing the certificate template to Active Directory
! Archiving the encryption private key in the CA database
! Enabling autoenrollment
Steps for Configuring an Demonstrate each configuration step to configure the enterprise CA. Mention
Enterprise CA that although not all organizations implement role separation, it is a best
practice to separate the certificate manager and key recovery agent roles.
How to Deploy E-mail Demonstrate each step in deploying an e-mail certificate to the organization’s
Certificates users. Highlight which consoles and resource kit utilities are used in each step
of the process. Most students will be familiar with deploying certificates, so
consider asking them to tell you how they accomplish each task.
Configure Outlook 2002 Mention that the configuration steps that are in this topic are applicable to
for Secure E-mail Microsoft Outlook 2000 and Outlook 2002. Do not spend time comparing the
Messages various encryption and digital signing protocols. Instead, recommend that the
students implement the strongest form of encryption possible for both
encryption and digital signing.
Lesson: Recovering E-mail Private Keys

This lesson discusses the processes that are required to recover an archived
e-mail encryption private key. The material in this lesson is a review of the
material presented in Module 7, “Configuring Key Archival and Recovery,” in
How to Recover E-mail This topic reviews the PKI roles that are involved in the key recovery process.
Private Keys Ask students what they would use to perform each step in the process.
Guidelines for Review each guideline on the slide and answer any questions. Discuss the
Recovering E-mail circumstances in which students should revoke a certificate before the private
Private Keys key is recovered, and when they should not revoke the certificate before the
private key is recovered.
vi Module 11: Configuring E-mail Security
Lesson: Migrating a KMS Database to a CA Running

Windows Server 2003
This lesson may not be relevant to all students, so consider not teaching it if
none of the students’ organizations have deployed the KMS service in
Microsoft Exchange.
If you do teach this lesson, be sure to tell students that the processes that are
discussed require that an organization is running the KMS service in Microsoft
Exchange 2000. If the organization is running an earlier version of the KMS
service, they must first upgrade to Exchange 2000 before they can perform the
migration.
Steps for Exporting a The classroom does not provide an Exchange 2000 Server, so you cannot
KMS Database demonstrate the steps for exporting the KMS database. Emphasize to the
students that they must back up the KMS database before they export it.
Explain that they perform the backup so that when they export the KMS
database records, the records are removed from the KMS database.
Ensure that students understand that they are restricted where they can import
the exported KMS database records. They can import the KMS database
records only to the CA database of the CA whose Subordinate Certification
Authority certificate is selected in the Exchange KMS Key Export Wizard.
Steps for Importing a Tell the students that the steps for importing the KMS database records depend
KMS Database on whether the certificates were issued by the same CA that the KMS database
records will be imported to. If the KMS database uses the CA that is the target
of the KMS database import, they only need to run the certutil –importKMS
command. If the issuing CA is not the same as the target CA, they must enable
foreign import on the CA. This way, they can import the archived private keys
for certificates that the CA did not issue.
Guidelines for Migrating Review each guideline presented on the slide and answer any student questions.
a KMS Database
Lab A Before students begin the lab, explain how qualified subordination constraints
enables e-mail messages to be exchanged securely between the organizations
that participate in the bridge CA hierarchy.
If you have time, ask students to complete the “If time permits” lesson of the
lab. This lesson builds on the bridge CA hierarchy that is defined in Module 8.
Students exchange e-mail messages with other organizations by using the
SMIMESign certificate and SMIMEEncrypt certificate that are issued by their
Module 11: Configuring E-mail Security vii
Lab A: Configuring Secure E-mail in Exchange Server 2003

In this lab, students will implement S/MIME e-mail security for e-mail
messages that are sent within their organization and for e-mail messages that
are sent between organizations.
! Deploy certificates for S/MIME encryption and digital signing.
! Archive S/MIME encryption certificate private keys.
! Enable S/MIME e-mail security for Outlook 2002.
Lab Setup
Setup requirement 1 The labs in this module require the existence of a CA hierarchy with an offline
root CA and an enterprise subordinate CA. Complete all of Labs A, B, and C in
Module 3, “Creating a Certification Authority Hierarchy,” in Course 2821.
Infrastructure” in Course 2821.
zone in the Default Domain Policy. Complete Lab B in Module 3, “Creating a
Setup requirement 5 Each student’s domain is a participant in the bridge CA network that
implements the instructor computer’s CA as a bridge CA. The student’s
enterprise subordinate CA must issue a Cross Certification Authority certificate
to the Bridge CA, and the Bridge CA must issue a Cross Certification Authority
certificate to each domain enterprise subordinate CA. Complete Lab A in
Module 8, “Configuring Trust Between Organizations,” in Course 2821.
viii Module 11: Configuring E-mail Security
Lab Results
changes:
! Exchange Server 2003 mailboxes are created for Mail1 and Mail2.
! The Force strong key protection for users keys stored on the computer
Group Policy setting is selected in the Default Domain Policy.
! The SMIMESign version 2 certificate template is created based on the
Exchange Signature Only certificate template.
! The MailUsers group is assigned Read, Enroll, and Autoenroll permissions
for the SMIMESign certificate template.
! The SMIMEEncrypt version 2 certificate template is created based on the
Exchange User certificate template.
! The MailUsers group is assigned Read, Enroll, and Autoenroll permissions
for the SMIMEEncrypt certificate template.
! The SMIMESign and SMIMEEncrypt certificate templates are published on
the enterprise subordinate CA in each student forest.
! SMIMESign and SMIMEEncrypt certificates are issued to the Mail1 and
Mail2 user accounts.
! Strong private key protection is enforced for the Mail1 and Mail2 user
accounts when the users access the private keys of the SMIMESign and
SMIMEEncrypt certificates.
! The SMIMESign certificate is designated as the default e-mail digital
signing certificate.
! The SMIMEEncrypt certificate is designated as the default e-mail
encryption certificate.
! Secure e-mail messages are exchanged between the Mail1 and Mail2 user
accounts.
! Mail Exchanger (MX) Domain Name System (DNS) resource records are
created for each student domain to send e-mail messages to the Exchange
Server in each domain.
! Secure e-mail messages are exchanged between two or more organizations.
Module 11: Configuring E-mail Security 1
Overview

Introduction Electronic mail, or e-mail, is the most popular application in organizations for
exchanging information. If the e-mail application is not configured to be secure,
someone can intercept this information before it reaches the intended recipient.
E-mail security means protecting e-mail messages from inspection and
modification when the e-mail is transmitted from the sender to the receiver. The
public key infrastructure (PKI) in the Microsoft® Windows Server™ 2003
family prevents modification and inspection of e-mail messages by providing
the e-mail digital signing and e-mail encryption certificates to users.
! Describe how e-mail security is implemented by a server running Microsoft
Exchange in a Windows Server 2003 environment.
! Implement secure e-mail messages in an Exchange 2000 environment.
! Recover e-mail private keys.
! Migrate the Key Management Service (KMS) database to an enterprise
certification authority (CA) in Windows Server 2003 Enterprise Edition.
2 Module 11: Configuring E-mail Security
Lesson: Introduction to E-mail Security

Introduction Microsoft Exchange 2000 provides e-mail security in a Microsoft
Windows® 2000 environment by using the KMS service. Windows Server 2003
enhances e-mail security by improving data protection and private key
recovery.
You can protect e-mail messages from inspection by encrypting the contents of
the e-mail message. You can protect e-mail messages from modification by
implementing digital signatures. Microsoft Exchange and Microsoft Outlook®
implement e-mail encryption and digital signing by using Secure Multipurpose
Internet Mail Extensions (S/MIME).
! Identify the key features of mail security in a Windows 2000 environment.
! Identify the changes to mail security in a Windows Server 2003
environment.
! Secure authentication in e-mail applications.
E-mail Security in a Windows 2000 Environment

Introduction Microsoft first offered key archival and recovery features in Microsoft
Exchange Server 4.0 through the KMS service of Exchange.
In an Exchange 2000 environment, the KMS service acts as a registration
authority (RA) to a Windows 2000 enterprise CA. It provides user registration
and key archival capabilities to an Exchange e-mail system. The KMS service
requests certificates from the enterprise CA on behalf of Exchange users, and
archives e-mail encryption private keys which enables key recovery.
E-mail security in The KMS service provides the following functionality in a Windows 2000
Windows 2000 environment:
! Requests certificates from a Windows 2000 enterprise CA. The KMS service
requests certificates for e-mail encryption from the enterprise CA on behalf
of a user.
! Archives the private keys of the certificates used for e-mail encryption in the
KMS database. Because the KMS service requests the certificate on behalf
of a user, the key pair is generated on the computer running the KMS
service. The KMS service then archives the private key in the KMS
database.
! Validates certificate revocation list (CRL) information in the Active
Directory® directory service. When the KMS service requests a certificate,
the KMS service validates the certificate of the issuing CA to determine the
revocation status of the issuing CA.
The KMS service publishes the e-mail encryption certificates to the user’s
userSMIMECertificate attribute in Active Directory. This publication enables
other users to send encrypted e-mail messages to the user whose certificate is
published in Active Directory.
Changes to E-mail Security in a Windows Server 2003 Environment

Introduction Windows Server 2003, Enterprise Edition provides significant improvement in
data protection and private key recovery. In a Windows Server 2003 PKI
environment, the key recovery functionality is moved from the KMS service to
an enterprise CA running Windows Server 2003, Enterprise Edition. The KMS
service does not exist in Exchange Server 2003, which is the latest version of
Exchange.
Moving the key archival functionality to a CA running Windows Server 2003
integrates all certificate functionality in a single service, rather than multiple
services. The configuration and management of archived private keys is
performed by CA administrators and certificate managers by using
Windows Server 2003 certificate management consoles, rather than by using
Exchange Server 2003 consoles.
Note Exchange 2000 Server can exist in a Windows Server 2003 forest as long
as it runs on a member server running Windows 2000. You cannot install
Exchange 2000 Server on a server running Windows Server 2003.
E-mail security in If you are running Exchange 2000, you can move all key archival functions to a
Windows Server 2003 Windows Server 2003 enterprise CA by upgrading your CAs to
Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter
Edition. Upgrading your CAs offers the following advantages:
! Moves the key archival functionality to a single location. Certificates are
issued from the same location where the private keys are archived.
! Enables autoenrollment of S/MIME certificates. When you deploy version 2
certificate templates, you can use autoenrollment to deploy the certificates
to users on your network.
! Imports previously archived private keys. You can import private keys and
certificates that are archived in a KMS database to a CA running
Windows Server 2003. This way, the CA can recover private keys that were
previously archived in the KMS database.
Steps to Secure RFC-based E-mail Protocols

Introduction In addition to digitally signing and encrypting e-mail messages, you can
increase the security of authentication and data transmission for several Request
for Comment (RFC)-based e-mail protocols. These RFC-based protocols
include Post Office Protocol version 3 (POP3), Internet Message Access
Protocol (IMAP4), Simple Mail Transfer Protocol (SMTP), and Network News
Transfer Protocol (NNTP).
For example, a common protocol that is used to retrieve e-mail from an e-mail
server is POP3. POP3 transmits all data between the e-mail client and the
e-mail server in plaintext, which means that the message content and the
authentication data that is sent to the e-mail server may be intercepted in the
communication channel.
In Exchange 2000 or Exchange Server 2003 environments, the authentication
information that is sent from the e-mail client to the Exchange server is the
user’s credentials for the user’s domain.
SSL ports By implementing Secure Socket Layers (SSL), you can protect the RFC-based
protocols that are used to send and receive e-mail from a server running
Exchange 2000 or Exchange Server 2003. SSL encrypts the data between the
e-mail client and the server. When SSL is implemented, the server accepts
connections on the SSL port, rather than on the standard port.
The following table shows the protocols that SSL can protect and lists the
default and SSL-protected ports.
Protocol Default port SSL port
POP3 TCP 110 TCP 995

IMAP4 TCP 143 TCP 993
SMTP TCP 25 TCP 25
NNTP TCP 119 TCP 563
Implementing SSL To implement SSL for POP3, IMAP4, SMTP, and NNTP on a server running
Exchange, perform the following steps:
1. Install a Web Server certificate on the server running Exchange. A Web
Server certificate includes the Server Authentication application policy
required for SSL encryption. You can use one Web Server certificate for all
SSL-enabled protocols on the server running Microsoft Exchange.
2. Enable SSL Listening ports on the Microsoft Exchange Server. Designate
the Web Server certificate for each protocol that can implement SSL, and
then enable SSL protection.
Note All protocols that can implement SSL can use the same Web Server
certificate, but you must designate the certificate individually for each
protocol.
3. Configure SSL in the e-mail applications. Configure the e-mail client

software to connect to the server running Exchange by using the SSL-
enabled port, rather than the default port. After you enable SSL, the server
does not accept connections to the default port. The method that you use to
modify the port that the client connects to varies depending on the client
software that your organization implements.
Lesson: Configuring Secure E-mail Messages

Introduction Before you can digitally sign and encrypt e-mail messages, you must create
certificate templates, configure the enterprise CA for key archival and recovery,
deploy certificates, and configure your e-mail client to use the certificates.
! Configure secure e-mail messages in a Windows Server 2003 PKI
environment.
! Create required version 2 certificate templates to configure secure e-mail
messages.
! Configure the enterprise CA for secure e-mail messages.
! Deploy certificate templates for secure e-mail messages.
! Configure Microsoft Outlook 2002 for secure e-mail messages.
Steps to Configure Secure E-mail Messages

Introduction To implement secure e-mail messages, you digitally sign and encrypt e-mail
messages. You enable each user account individually by assigning the user the
required certificates.
Configuring secure To configure secure e-mail messages:
e-mail messages
1. Create certificate templates. Although typically you create separate
certificate templates to implement digitally signing and encrypting of
messages, you can deploy one certificate that implements both.
2. Configure an enterprise CA to implement key archival and recovery. Only
Windows Server 2003 enterprise CAs can implement key archival and
recovery. In addition, for private key archival and recovery for encryption-
enabled certificates, the enterprise CA operating system must be
Windows Server 2003, Enterprise Edition or Windows Server 2003,
Datacenter Edition.
3. Deploy the certificate using autoenrollment settings. By using
autoenrollment, you can deploy version 2 certificate templates to users with
computers running Windows XP or the Windows Server 2003 family.
Autoenrollment reduces the time and effort that is required to deploy digital
signing and mail encryption certificates.
Note If your client computers do not use Windows XP or the

Windows Server 2003 family, you can automatically distribute the secure
e-mail certificates by using a combination of CAPICOM scripting.
CAPICOM is a superset of the Cryptographic application programming
interface (CryptoAPI).
4. Verify the configuration of Outlook. After you deploy the digital signing
and e-mail encryption certificates, the user must configure Outlook 2002 to
use the certificates to send and receive secure e-mail messages.
How to Create the Required Certificate Templates

Introduction You must create custom version 2 certificate templates to use autoenrollment
for deploying e-mail encryption and e-mail signing certificates and for
archiving e-mail encryption private keys. To create the version 2 certificate
templates, you must be a member of the Enterprise Admins group or the
Domain Admins group of the forest root domain, or you must be a user who has
been designated the required permissions to create version 2 certificate
templates.
Note For more information about how to delegate permissions to create and
modify certificate templates, see the white paper, Implementing and
Administering Certificate Templates in Windows Server 2003, under
Choosing a certificate To deploy certificates for secure e-mail messages, first choose the certificate
template strategy templates that you want to deploy. You can:
! Implement split keys by designing two certificate templates, one for e-mail
encryption and one for digitally signing e-mail messages.
! Implement either e-mail encryption or implement digital signing—not both.
This approach requires that you implement only one certificate template.
! Implement one e-mail certificate template that enables both e-mail
encryption and digital signing.
Creating an e-mail To create a version 2 certificate template for e-mail encryption:

encryption certificate
1. Duplicate the Exchange User certificate template, which allows only the
encryption of secure e-mail messages.
2. In the new version 2 certificate template:
a. Choose a Cryptographic Service Provider (CSP) that enables the private
key to be exported. After the private key is exported, the private key can
be archived in the issuing CA’s CA database.
b. On the Request Handling tab, select the Archive subject’s encryption
private key check box.
c. On the Request Handling tab, select Prompt the user during
enrollment and require user input when the private key is used.
This step ensures that the user enters a password every time the private
key is used. It also ensures that an attacker cannot gain access to the
private key by acquiring the user’s password. The attacker must also
know the password for private key access.
Note For client computers running Windows XP Service Pack 1 or later or

the Windows Server 2003 family, an administrator must enable the System
cryptography: Force strong key protection for user keys stored on the
computer security option in Group Policy.
d. On the General tab, select the Publish certificate in Active Directory

check box. This way, other users on the network can find the user’s
certificate in Active Directory to access the user’s encryption public key
when they send an encrypted e-mail message to the user.
3. Enable autoenrollment for the version 2 certificate template. Assign Read,
Enroll, and Autoenroll permissions to a global group or universal group that
contains all users that require the e-mail encryption certificates.
Creating an e-mail To create a version 2 certificate template for e-mail digital signing:
signing certificate
1. Create a new version 2 certificate template by duplicating the Exchange
Signature Only certificate template. This certificate template allows secure
e-mail messages to be digital signed, but not encrypted.
2. In the version 2 certificate template, on the Request Handling tab, select
Prompt the user during enrollment and require user input when the
private key is used.
3. On the General tab, select the Publish certificate in Active Directory
check box. This step ensures that other users on the network can find the
user’s certificate in Active Directory to access the signing public key when
they verify a signed message that the user sent.
4. Enable autoenrollment for the version 2 certificate template. Assign Read,
Enroll, and Autoenroll permissions to a global group or universal group that
contains all users that require the e-mail encryption certificates.
Steps for Configuring an Enterprise CA

Introduction Configure an enterprise CA to issue the certificates that are necessary for secure
e-mail messages in an Exchange Server 2003 environment.
Configuring an To configure an enterprise CA:
enterprise CA
1. Enforce role separation. If your organization’s security policy requires that
you enforce role separation, a local administrator of the CA must type the
following command, and then restart Certificate Services:
certutil -setreg ca\RoleSeparationEnabled 1
2. Define key recovery agents (KRAs). Designating a KRA is a two-step

process. The KRA designee must acquire a Key Recovery Agent certificate,
and then a CA administrator must designate the KRA in the properties of the
CA.
3. Designate certificate managers by assigning a user or domain local group
the Issue and Manage Certificate permission in the properties of the CA.
4. Publish custom templates. A CA administrator publishes the custom version
2 certificate templates—one for e-mail encryption and one for e-mail digital
signing.
How to Deploy E-mail Certificates

Introduction You can deploy the digital signing certificates and e-mail encryption certificates
to users after the certificate templates are created and a CA administrator
enables an enterprise CA for key archival.
Deploying e-mail To deploy e-mail certificates:
certificates
1. Enforce high security for strong password protection. Enable the System
cryptography: Force strong key protection for user keys stored on the
computer security option in Group Policy to ensure that users are required
to enter a password when they access an e-mail certificate’s private key.
Note If the security policy of your organization does not require strong
password protection, you can deploy the certificates without user
intervention.
2. In the Certificate Templates console, in the properties of the certificate

template select Prompt the user during enrollment and require user
input when the private key is used.
3. Define permissions for the certificate templates. To limit the number of
users who will receive the e-mail certificates, you can assign Read, Enroll,
and Autoenroll user permissions to a universal or global group that only
contains that subset of users in the Certificate Templates console. To deploy
the certificates to all users in the organization, assign the necessary
permissions to the Authenticated Users group.
4. Publish the new certificate templates to an enterprise CA. A CA

administrator must publish the e-mail encryption certificate template to one
or more enterprise CAs that enable key archival and recovery by using the
Certification Authority console. You can publish the digital signing
certificate template on any enterprise CA.
5. Enable Autoenrollment Settings in Group Policy for users. Select all
Autoenrollment Settings check boxes in the User Configuration/
Windows Settings/Security Settings/Public Key Policies container. You
can apply Group Policy on a domain to affect all users in the domain or
apply it to a specific organizational unit (OU) to only affect user objects in
that OU structure.
Configure Outlook 2002 for Secure E-mail Messages

Introduction After you acquire e-mail certificates for encrypting e-mail and digitally signing
e-mail, configure your e-mail client to use the certificates. Also configure how
the e-mail client will use the certificates. You can choose what hash algorithms
and encryption the e-mail client will use. You can also configure the settings to
always sign or encrypt outgoing messages.
Choosing signing and After you acquire e-mail encryption and e-mail digital signing certificates,
encryption certificates either choose the certificates or let Outlook 2000 automatically select the
certificates. You can use multiple certificates in your certificate store to perform
secure e-mail operations. For example, your smart card certificate may also
offer secure e-mail functionality.
Note You can implement separate certificates for signing and encryption. Or,
if you acquire a multipurpose certificate, you can designate the same certificate
for both purposes.
Choosing a hash After users select their certificate for signing e-mail, they must choose the
algorithm algorithm for signing e-mail messages. Users can choose from the following
cryptographic message digest algorithms:
! Secure Hash Algorithm version 1 (SHA1). Takes a message of fewer than
264 bits in length and produces a 160-bit message digest.
! Message Digest version 5 (MD5). Takes a message of arbitrary length and
produces a 128-bit message digest.
Choosing an encryption After users select their certificate for encrypting e-mail, they must choose an
algorithm algorithm for encrypting e-mail messages. Users can choose from the following
symmetric encryption algorithms:
! Data Encryption Standard (DES). An encryption algorithm that encrypts
data with a 56-bit randomly generated symmetric key.
! Rivest’s Cipher version 2 (RC2) (40-bit). A variable key-size block cipher
with an initial block size of 64 bits that uses an additional string of 40 bits
called a salt. The salt is appended to the encryption key, and this lengthened
key is used to encrypt the message.
! RC2 (128-bit). A variation on the RC2 (40-bit) cipher where the salt length
is increased to a length of 88 bits.
! Triple DES (3DES). A variation on the DES encryption algorithm in which
DES encryption is applied three times to the plaintext. The plaintext gets
encrypted with key A, then key B, and finally key C. The most common
form of 3DES uses only two keys: the plaintext gets encrypted with key A,
then with key B, and finally with key A again.
Defining e-mail default The final step in configuring an e-mail client is to designate the default settings
settings for outgoing e-mail messages. A user designates these settings by performing
the following procedures:
1. Open Microsoft Outlook.
2. On the Tools menu, click Options.
3. In the Options dialog box, on the Security tab, configure the following
settings:
• Encrypt contents and attachments for outgoing messages. Encrypts
all outgoing messages. To send an encrypted outgoing message, you
must have access to all recipients’ encryption digital certificates, which
are stored in individual contact objects in Outlook or retrieved from
User, InetOrgPerson, or Contact objects in Active Directory.
• Add digital signature to outgoing messages. Digitally signs all
outgoing e-mail messages and includes the user’s encryption certificate
in the outgoing signed e-mail message.
• Send clear text signed message when sending signed messages. Sends
a clear text message that allows the message to be viewed in the preview
pane without validating the digital signature.
• Request secure receipt for all S/MIME signed messages. Requires
that a return receipt is sent by the recipient of messages signed by
S/MIME.
Lesson: Recovering E-mail Private Keys

Introduction Designing private key recovery is the final step in migrating to a
Windows Server 2003 PKI from the KMS database in Exchange 2000. You
must recover private keys for user accounts that have been imported from the
KMS database. Users of these cannot create new encrypted messages without
the new keys. Another reason for recovering the private keys is if a user looses
the key or forgets the password.
Recover e-mail private keys requires the cooperation of the certificate manager,
the key recovery agent, and the end user.
! Recover the e-mail private keys.
! List the guidelines for recovering the e-mail private keys.
How to Recover E-mail Private Keys

Introduction The recovery of a private key is a manual process that requires the cooperation
of the certificate manager, the KRA, and the user whose certificate and private
key are being recovered.
Certificate manager The certificate manager performs the following initial tasks to recover the
tasks e-mail private key:
1. Determines the KRA used for the archived private key and certificate. The
certificate manager can use either the certutil –getkey command or the Key
Recovery Tool from the Windows Server 2003 Resource Kit to determine
the KRA for an archived private key.
2. Extracts the encrypted PKCS #7 blob from the CA database. The blob
contains the encrypted private key and certificate. The data is encrypted
with the KRA’s public key, so that only the KRA can recover the encrypted
private key and certificate.
Note If you recover a private key from the CA database because the private
key was compromised, revoke the associated certificate so that the certificate
cannot be used for further encryption.
KRA tasks The KRA performs the following tasks after obtaining the PKCS #7 blob from
the certificate manager:
1. Selects a tool to recover the private key from the PKCS #7 blob. If role
separation is enabled, the KRA can recover the private key by using the
certutil –recoverkey <Certificate Serial Number> command or the Key
Recovery Tool to extract the PKCS #7 blob from the CA database.
2. Performs the private key and certificate recovery operation. The KRA
extracts the private key and certificate from the PKCS #7 blob and stores the
private key and certificate in a PKCS #12 file that is password protected, by
using one of the following processes:
• If using the Key Recovery Tool, the KRA indicates the CA on which the
private key is archived, selects the certificate that is associated with the
archived private key, and then clicks Recover.
• If using the Certutil.exe command, the KRA uses the
certutil –recoverkey <Certificate Serial Number>
command to recover the private key and the certificate.
3. Transports the private key to the user. The KRA must securely transport the
PKCS #12 file that contains the extracted private key and certificate to the
original user of the private key. The transport method that the KRA uses
must follow the security policy of your organization. For example, some
organizations may require hand delivery of the PKCS #12 file; other
organizations may allow the KRA to e-mail the PKCS #12 file to the user.
User tasks After the key recovery agent recovers the private key and certificate, the user
imports the PKCS #12 file into his certificate store. To import it, the user must
have the PKCS #12 file and know the associated password that the KRA
defined. The user then:
1. Imports the certificate and private key into their certificate store. The user
imports them by using the Certificate Import Wizard, during which the user
must provide the associated password for the PKCS #12 file.
2. Reconfigures Outlook to use the private key. After the private key and
certificate are imported into the user’s certificate store, the user ensures that
Outlook uses the recovered private key for e-mail encryption operations.
Guidelines for Recovering E-mail Private Keys

Guidelines Implement the following guidelines if your organization enables private key
recovery for e-mail certificates:
! Enable role separation between the certificate manager and key recovery
agent roles. If a user holds both roles, it is possible for that user to
impersonate another user.
! Always revoke the certificate that is associated with a compromised private
key before you perform key recovery. Revoking the certificate ensures that
you cannot use the certificate for further encryption operations. You can use
the recovered private key to recover previously encrypted messages.
! Prohibit the recovery of digital signature private keys. If you implement the
same certificate for e-mail digital signing and e-mail encryption, do not
implement key archival. The possession of a dual-purpose e-mail private
key allows impersonation of the certificate subject.
! Minimize the number of CAs that perform key archival. This way, you
reduce the number of CAs that a certificate manager must search to find an
archived private key. You also reduce the number of CAs that may require
additional physical security measures to protect the archived private keys.
Lesson: Migrating a KMS Database to a CA Running

Windows Server 2003

Introduction If your organization plans to migrate to Exchange Server 2003, you must
import the KMS database into a Windows Server 2003 CA database, because
Exchange Server 2003 does not support the KMS service. By importing the
KMS database, you can also implement all key management services in one
database.
! Export the KMS database.
! Import the KMS database.
! List the guidelines for migrating the KMS database.
Steps for Exporting a KMS Database

Introduction When you export the KMS database, the archived private keys are moved from
the KMS database to the Windows Server 2003 CA database. After all private
keys are exported from the KMS database, you can remove the KMS service
from the Exchange 2000 server.
Exporting the KMS To export the KMS database:
database
1. Acquire the Subordinate Certification Authority certificate of the target
enterprise CA running Windows Server 2003, Enterprise Edition or any
other encryption certificate that is issued to the CA. The public key of the
certificate is used in the export process to encrypt the export file.
2. Ensure that you are exporting the database from a server running Exchange
2000. If the KMS database is in a previous version of Exchange, you must
first upgrade to Exchange 2000.
3. Before exporting the KMS database, perform a full backup of the server and
then validate the backup. The backup allows recovery of the exported
certificates and private keys if the export fails in any way.
4. Export the archived private keys from the server running Exchange 2000 by
a. Start Exchange System Manager.
b. In the console tree, expand Administrative Groups, expand
AdminGroup (where AdminGroup is the name of the Administrative
Group), and then click Advanced Security.
c. In the details pane, right-click Key Manager, point to All Tasks, and
then click Export Users.
d. Enter the KMS password to access the KMS database.
After the password is verified, the Exchange KMS Key Export Wizard
starts.
5. In the Exchange KMS Key Export Wizard, select the Subordinate

Certification Authority certificate that will be used to encrypt the export file,
and then validate it by typing the first eight characters of the Certificate
Thumbprint field. This field contains the SHA1 hash of the certificate,
which is stored in hexadecimal format.
6. Enter the name of the export file. Do not type in a path, only the file name.
The file will be saved in the C:\program files\exchsrvr\KMSDATA folder.
7. Select which users’ private keys are to be exported. You can select the
private keys to export from an alphabetic list of users or from a mailbox
store, server, or administrative group.
At the end of this step, the KMS service exports the records. On average,
approximately 100 records are exported per minute. The actual performance
varies depending on the hardware configuration.
Steps for Importing a KMS Database

Introduction You must import certificate and keys to a CA database in order to provide
migration services for the KMS database in Exchange 2000.
Implement key archival The first step in importing a KMS database into the CA database is to
on the enterprise CA implement key archival on the target Windows Server 2003 enterprise CA. This
task requires distribution of Key Recovery Agent certificates and designation of
one or more KRAs on the target enterprise CA.
Note For more information about how to implement key archival and
recovery, see Module 7, “Configuring Key Archival and Recovery,” in Course
2821, Designing and Managing a Windows Public Key Infrastructure.
Enable foreign By default, an enterprise CA running Windows Server 2003 prohibits

certificates import certificates and private keys that are issued by another CA to be imported into
the CA database. To enable import of foreign certificates and private keys, you
must configure the enterprise CA by running the following Certutil.exe
command and then restarting Certificate Services:
certutil –setreg ca\KRAFlags +KRAF_ENABLEFOREIGN
Note This step is only required if you are migrating the certificates in the KMS
database to a different CA than the CA that issued the certificates. If you
upgrade the Windows 2000 CA to Windows Server 2003 Enterprise Server, it is
not necessary to perform this step.
Copy the export file After you export the KMS database, copy the export file to the CA running
Windows Server 2003 where the KMS database is to be imported. The import
file is encrypted with the public key of the target CA running
Windows Server 2003, so that only that CA can decrypt the export file and
import the KMS database contents. Copy the export file to the local file system
of the target CA or to removable media that may be loaded on the target CA.
Import the KMS After the KMS database export file is available on the target CA, a CA
database administrator can import the KMS database into the CA database running
Windows Server 2003 by using the following Certutil.exe command:
certutil.exe –f –importKMS [name of import file]
When foreign certificates are imported into a CA database, the –f switch is used
to inform the CA that the private keys and certificates are from a foreign CA.
Note You can also use the certutil –f –importKMS command to import
PKCS #12 and Outlook EPF files into the CA database if foreign CAs issued
the certificates.
Guidelines for Migrating a KMS Database

Introduction To consolidate all archived private keys into one database, you can import the
private keys and certificates that are archived in the KMS database to a
Windows Server 2003 enterprise CA database running on
Windows Server 2003, Enterprise Edition or Windows Server 2003,
Datacenter Edition.
Guidelines When planning the migration of an existing Windows 2000 KMS database to a
Windows Server 2003, enterprise CA, implement the following guidelines:
! Enable foreign certificate import on the Windows Server 2003 enterprise
CA if the target enterprise CA running Windows Server 2003 was not the
CA used by the server running Exchange 2000 KMS service.
! Verify the backup of the KMS database before you export it. Exporting
private keys from the KMS database removes the private keys from the CA
database. By performing and verifying the backup, you ensure that you can
roll back the export of the KMS database.
! Change the default KMS administrator password. By default, the KMS
administrator’s password is password. Always modify this weak password,
because anyone who knows the KMS administrator password can export the
KMS database.
! Store the KMS database export file in a secure location. Although the KMS
database export is encrypted with the target CA’s Subordinate Certification
Authority public key, the export file does contain the user’s secure e-mail
certificates and private keys.
Lab A: Configuring Secure E-mail in

Exchange Server 2003

! Deploy certificates for S/MIME encryption and digital signing.
! Archive S/MIME encryption certificate private keys.
! Enable S/MIME e-mail security in Outlook 2002.
comply with Microsoft security recommendations. For instance, this lab enables
encrypting and digital signing of all outgoing messages, rather than encrypting
and digital signing on a message-by-message basis.

domain.
autoenrollment settings for user objects.
! Enabled key archival on the enterprise subordinate CA in your domain.
! Configured your CA hierarchy to participate in a Bridge CA hierarchy, with
the London computer as the Bridge CA (only if time permits).
! Configured the London computer with Stub zones for all DNS domains that
are used in the classroom.
! Microsoft Exchange Server 2003 installed on the member server in your
organization.
! The knowledge and skills to deploy secure e-mail certificates in a
Windows Server 2003 family environment.
Additional information For more information about securing e-mail in Exchange Server 2003, read the
white paper, Windows 2000 Server and Key Management Server
Interoperability, under Additional Reading on the Web page on the Student
Estimated time to
complete this lab:
45 minutes
Exercise 1
Creating Exchange Server 2003 Mailboxes
In this exercise, you will create mailboxes for the Mail1 and Mail2 user accounts. In addition, you
will implement certificate autoenrollment for user accounts in the Module11 organizational unit.
Scenario
Your organization wants to enable S/MIME for specific users in the organization, so that they can
encrypt and digitally sign e-mail messages. You must create mailboxes for the selected users and
then enable autoenrollment in Group Policy to allow the automatic distribution of the S/MIME
digital certificates.
account.
domain)
2. Create Exchange mailboxes a. On the Start menu, point to All Programs, point to Microsoft
for the Mail1 and Mail2 user Exchange, and then click Active Directory Users and Computers.
accounts. b. In the console tree, expand Domain.msft, expand Labs, and then click
Module11.
c. In the details pane, select Mail1 and Mail2, right-click the selected
user accounts, and then click Exchange Tasks.
d. On the Exchange Task Wizard page, click Next.
e. On the Available Tasks page, in the Select a task to perform list,
click Create Mailbox, and then click Next.
f. On the Create Mailbox page, accept the default settings, and then
click Next.
g. On the Completing the Exchange Task Wizard page, click Finish.
3. Link the Autoenrollment a. In the console tree, right-click Module11, and then click Properties.
GPO to the Module11 b. In the Module11 Properties dialog box, on the Group Policy tab,
organizational unit. click Add.
c. In the Add a Group Policy Object Link dialog box, on the All tab,
click Autoenrollment, and then click OK.
d. In the Module11 Properties dialog box, click OK.
(continued)
4. Configure the E-mail a. In the details pane, select both Mail1 and Mail2, right-click both
attribute for the Mail1 and Mail1 and Mail2, and then click Properties.
Mail2 user accounts. When b. In the Properties On Multiple Objects dialog box, click E-mail.
completed, close all open
windows and log off the c. In the E-mail box, type %username%@Domain.msft (where Domain
network. is the NetBIOS name of your domain), and then click OK.
d. Close Active Directory Users and Computers.
5. Log on to the domain as a " Log on to the domain with the following credentials:
user who has been delegated • Logon name: Student1
permissions to create and
modify certificate templates • Password: Password (where Password is the password for your
or by using your domain administrative account)
administrative account. • Domain: Domain (where Domain is the NetBIOS name of your
domain)
6. In Domain Security Policy, a. On the Start menu, point to Administrative Tools, and then click
enable strong private key Domain Security Policy.
protection so that the user b. In Default Domain Security Settings, in the console tree, expand
must always enter a Local Policies, and then click Security Options.
password when accessing a
certificate’s private key. c. In the details pane, double-click System cryptography: Force strong
When completed, close all key protection for user keys stored on the computer.
open windows and log off d. In the System cryptography: Force strong key protection for user
the network. keys stored on the computer dialog box, click Define this policy
setting, click User must enter a password each time they use a key,
and then click OK.
e. Close Default Domain Security Settings.
Exercise 2
Creating and Publishing S/MIME Certificate Templates
In this exercise, you will create two certificate templates for secure e-mail: a digital signing
certificate template and an e-mail encryption certificate template.
Scenario
Your company wants to implement S/MIME e-mail security by using split key pairs. To meet this
goal, you must create two certificate templates, one for digital signing and one for e-mail
encryption.
1. Log on to the domain as a " Log on to the domain by using the following credentials:
user who has been delegated • Logon name: Template2
permissions to create and
modify certificate templates • Password: P@ssw0rd
or log on using your domain • Domain: Domain (where Domain is the NetBIOS name of your
administrative account. Active Directory domain)
2. Update Group Policy. a. Open a command prompt.

b. At the command prompt, type gpupdate /force and then press ENTER.
Template console and create b. If the Certificate Templates message box appears, click OK.
a new certificate template
named SMIMESign, based c. In the details pane, right-click Exchange Signature Only, and then
on the Exchange Signature click Duplicate Template.
Only certificate template. d. In the Properties of New Template dialog box, in the Template
display name box, type SMIMESign and then click OK.
4. In the SMIMESign a. In the details pane, double-click SMIMESign.

certificate template, select b. In the SMIMESign Properties dialog box, on the General tab, select
the following: the Publish certificate in Active Directory check box, select the Do
• Publish certificate in not automatically reenroll if a duplicate certificate exists in Active
Active Directory Directory check box, and then click Apply.
• Do not automatically c. On the Request Handling tab, click Prompt the user during
reenroll if a duplicate enrollment and require user input when the private key is used,
certificate exists in and then click Apply.
Active Directory
• Prompt the user
during enrollment and
require user input
when the private key is
used
(continued)
5. On the Extensions tab, add a. On the Extensions tab, click Issuance Policies, and then click Edit.
the Medium Assurance b. In the Edit Issuance Policies Extension dialog box, click Add.
issuance policy OID.
c. In the Add Issuance Policy dialog box, click Medium Assurance, and
then click OK.
e. On the Extensions tab, click Apply.
6. On the Subject name tab, a. On the Subject name tab, click Build from this Active Directory
select the following: information, and then select the following:
• Subject name format: • Subject name format: Fully distinguished name
Fully distinguished • Include e-mail name in subject name: Enabled
name
• E-mail name: Enabled
• Include e-mail name in
subject name: Enabled • User principal name (UPN): Enabled
• E-mail name: Enabled b. On the Subject name tab, click Apply.
• User principal name

(UPN): Enabled
7. On the Security tab, assign a. On the Security tab, click Add.
the MailUsers group Read, b. In the Select Users, Computers, or Groups dialog box, in the Enter
Enroll, and Autoenroll the object names to select box, type Mail and then click Check
permissions. Names.
c. In the Multiple Names Found, in the Matching names list, click
MailUsers, and then click OK.
d. In the Select Users, Computers, or Groups dialog box, click OK.
e. In the Group or user names list, select MailUsers, assign the
MailUsers group Read, Enroll, and Autoenroll permissions, and then
click OK.
8. Create a new certificate a. In the details pane, right-click Exchange User, and then click
template named Duplicate Template.
SMIMEEncrypt, based on b. In the Properties of New Template dialog box, in the Template
the Exchange User display name box, type SMIMEEncrypt and then click OK.
(continued)
9. In the SMIMEEncrypt a. In the details pane, double-click SMIMEEncrypt.

certificate template, select b. In the SMIMEEncrypt Properties dialog box, on the General tab,
the following: select the Publish certificate in Active Directory check box, select
• Publish certificate in the Do not automatically reenroll if a duplicate certificate exists in
Active Directory Active Directory check box, and then click Apply.
• Do not automatically c. On the Request Handling tab, click Archive subject’s encryption
reenroll if a duplicate private key.
certificate exists in d. On the Request Handling tab, click Prompt the user during
Active Directory enrollment and require user input when the private key is used,
• Archive subject’s and then click Apply.
encryption private key
• Prompt the user
during enrollment and
require user input
when the private key is
used
10. On the Extensions tab, add a. On the Extensions tab, click Issuance Policies, and then click Edit.
the Medium Assurance b. In the Edit Issuance Policies Extension dialog box, click Add.
issuance policy OID.
c. In the Add Issuance Policy dialog box, click Medium Assurance, and
then click OK.
e. On the Extensions tab, click Apply.
11. On the Subject name tab, a. On the Subject name tab, click Build from this Active Directory
select the following check information, and then select the following:
boxes: • Subject name format: Fully distinguished name
• Subject name format: • Include e-mail name in subject name: Enabled
Fully distinguished
name • E-mail name: Enabled
• Include e-mail name in • User principal name (UPN): Enabled

subject name: Enabled b. On the Subject name tab, click Apply.
• E-mail name: Enabled
• User principal name
(UPN): Enabled
(continued)
12. On the Security tab, assign a. On the Security tab, click Add.
the MailUsers group Read, b. In the Select Users, Computers, or Groups dialog box, in the Enter
Enroll, and Autoenroll the object names to select box, type Mail and then click Check
permissions. Names.
click MailUsers, and then click OK.
d. In the Select Users, Computers, or Groups dialog box, click OK.
e. In the SMIMEEncrypt Properties dialog box, in the Group or user
names list, ensure that MailUsers is selected.
f. In the Group or user names list, select MailUsers, assign MailUsers
Read, Enroll, and Autoenroll permissions, and then click OK.
then log off the network. b. Close all open windows and then log off.
administrative account. • Logon name: CAadmin1
• Domain: Domain
15. Update Group Policy. a. Open a command prompt.

b. At the command prompt, type gpupdate /force and then press ENTER.
16. Configure DomainCA to a. On the Start menu, point to Administrative Tools, and then click
issue the SMIMEEncrypt Certification Authority.
and SMIMESign certificate b. In the console tree, expand DomainCA, and then click Certificate
templates. Templates.
c. In the console tree, right-click Certificate Templates, click New, and
SMIMEEncrypt, press CTRL and click SMIMESign, and then click
OK.
e. In the details pane, ensure that SMIMEEncrypt and SMIMESign
appear.
Exercise 3
Configuring Outlook 2002
In this exercise, you will autoenroll the SMIMEEncrypt and SMIMESign certificates and then
configure Outlook 2002 to use two certificates when you implement S/MIME e-mail security.
Scenario
After you deploy the two S/MIME certificates, the users can now send and receive digitally signed
and encrypted e-mail messages.
1. Log on to your domain " Log on to the domain by using the following credentials:
using your e-mail user • User name: Mail1 (on the domain controller) or Mail2 (on the
domain)
Note: It may take up to 90 seconds for the Certificate Enrollment balloon to appear on the screen. You can
type gpupdate /force to speed up the application of the GPO.
Note: In step 2 below, the order of the procedural steps may vary, depending on Group Policy. For example,
steps f through i may occur before steps c through e. The order is a random event that is based on the
Autoenrollment GPO.
2. Start the Certificate a. In the notification area, click the Certificate Enrollment balloon.
Autoenrollment process. b. In the Certificate Enrollment dialog box, click Start.
c. In the Creating a new RSA signature key dialog box, click Set
Security Level.
d. In the Creating a new RSA signature key dialog box, in the
Password and Confirm boxes, type P@ssw0rd and then click Finish.
e. In the Creating a new RSA signature key dialog box, click OK.
f. In the Creating a new RSA exchange key, click Set Security Level.
g. In the Creating a new RSA exchange key dialog box, in the
Password and Confirm boxes, type P@ssw0rd and then click Finish.
h. In the Creating a new RSA exchange key dialog box, click OK.
i. In the Exporting your private exchange key dialog box, in the
CryptoAPI Private Key box, type P@ssw0rd and then click OK.
(continued)
Why do you have to provide the password associated with your exchange key?
The SMIMEEncrypt certificate template enables private key archival. The private key is encrypted
and securely transmitted to the issuing CA.
3. Configure the default a. On the desktop, double-click Microsoft Outlook.

Outlook 2002 profiles with b. On the Outlook 2002 Startup page, click Next.
the following settings:
c. On the E-mail Accounts page, click Yes, and then click Next.
• Server Type: Microsoft
Exchange Server d. On the Server Type page, click Microsoft Exchange Server, and then
click Next.
• Microsoft Exchange
Server: MemberServer e. On the Exchange Server Settings page, in the Microsoft Exchange
(where MemberServer is Server box, type MemberServer (where MemberServer is the NetBIOS
the NetBIOS name of name of your member server).
your member server) f. On the Exchange Server Settings page, in the User Name box, type
• User name: Mail1 (on Mail1 (on the domain controller) or Mail2 (on the member server), and
the domain controller) then click Check Name.
or Mail2 (on the If you are performing these tasks on the member server, you
member server) will receive a Microsoft Outlook error. This error is due to a
DLL mismatch between Exchange Server 2003 and Microsoft
Outlook 2002. To configure your mailbox, proceed to step 5.
g. In the User Name box, ensure that Mail1 is underlined, and then click
Next.
h. On the Congratulations! page, click Finish.
4. Define the user name as a. In the User Name dialog box, in the Name box, type Mail1 (on the
Mail1 (on the domain domain controller).
controller), and then skip the b. In the Initials box, type m1 (on the domain controller), and then click
activation of Outlook 2002. OK.
c. If the Microsoft Office XP Professional with FrontPage Activation
Wizard page appears, click Activate Later, and then click Exit.
If you are performing these tasks on the domain controller,
proceed to step 6.
(continued)
5. Define the user name as a. In the Microsoft Outlook error dialog, click Don’t Send.
mail2 (on the member b. In the Microsoft Outlook dialog, click No.
server), verify the Outlook
mail account configuration, c. In the User Name dialog box, in the Name box, type Mail2 (on the
and then skip the activation member server).
of Outlook 2002. d. In the Initials box, type m2 (on the member server), and then click
OK.
e. If the Microsoft Office XP Professional with FrontPage Activation
f. Close Microsoft Outlook.
g. On the desktop, right-click Microsoft Outlook, and then click
Properties.
h. In the Mail Setup - Outlook dialog box, click E-mail Accounts.
i. In the E-Mail Accounts dialog box, click View or change existing
e-mail accounts, and then click Next.
j. In the Deliver new e-mail to the following location drop-down list,
verify that Mailbox - Mail2 (on the member server) appears, click
Cancel, and then click Close.
k. On the desktop, double-click Microsoft Outlook.
l. If the Microsoft Office XP Professional with FrontPage Activation
Microsoft Outlook now starts successfully.
6. View the security settings a. Maximize the Inbox – Microsoft Outlook window.
for Outlook 2002. b. On the Tools menu, click Options.
c. In the Options dialog box, on the Security tab, click Settings.
Does Outlook 2002 automatically recognize the SMIMESign and SMIMEEncrypt certificates?
Yes. The Change Security Settings dialog box is automatically configured to use the newly installed
certificates.
6. (continued) d. In the Change Security Settings dialog box, click OK.

(continued)
7. Enable encryption and a. In the Options dialog box, on the Security tab, select the following
digital signing for all check boxes:
outgoing messages. • Encrypt contents and attachments for outgoing messages
• Add digital signature to outgoing messages
b. In the Options dialog box, leave all other default settings, and then
click OK.
8. Create an encrypted e-mail a. On the toolbar, click New.

message with the following b. If the Using Word as your E-mail Editor balloon appears, click No
settings: Thanks.
• To: Mail2 (on the domain
c. Create an e-mail message with the following settings:
controller) or Mail1 (on the
member server) • To: Mail2 (on the domain controller) or Mail1 (on the member
server)
• Subject: Encrypted and
Signed • Subject: Encrypted and Signed
• Message body: This is an • Message body: This is an encrypted and digitally signed
encrypted message. message.
d. On the tool bar, click Options.
It may be necessary to move the toolbars to view the Options
button.
e. In the Message Options dialog box, click Security Settings.
Are the default settings that you defined enforced for outgoing messages?
Yes. The Security Properties dialog box is set to encrypt and digitally sign the outgoing message.
8. (continued) f. In the Security Properties dialog box, click OK.

g. In the Message Options dialog box, click Close.
h. On the toolbar, click Send.
i. In the Signing data with your private signature key dialog box, in
the CryptoAPI Private Key box, type P@ssw0rd and then click OK.
Why was it necessary to enter your password? How does this password protect your identity?
The Default Domain Policy enforces strong private key protection. The password protects your
identity because an attacker must not only gain access to your user account, he must also know the
password that protects your digital signing private key.
(continued)
9. Open the message from your a. Wait for the message to arrive from your partner.
partner. b. In the Inbox, select the encrypted e-mail message from your partner.
How does Outlook 2002 indicate that the e-mail message is encrypted? Can you preview the message?
A blue lock icon indicates that the e-mail message is encrypted. You cannot view an encrypted message
in the preview pane.
9. (continued) c. In the Inbox, double-click the encrypted e-mail message from your
partner.
d. In the Using your private exchange key to decrypt dialog box, in the
CryptoAPI Private Key dialog box, type P@ssw0rd and then click
OK.
Why was it necessary to type a password in order to view the message?
It was necessary to type a password because the private key that decrypts the message is protected
with strong private key protection, which requires that you enter a password.
How do you know that the message was both encrypted and digitally signed?
In the right-hand corner of the message, a blue lock indicates that the message is encrypted and a red
ribbon indicates that the message is digitally signed.
10. Close all open windows and a. Close the message.

then log off the network. b. Close Inbox – Microsoft Outlook.
Exercise 4 (If time permits)

Sending Secure E-mail Between Organizations
In this exercise, you will send e-mail messages between your organization and other organizations
by using the Bridge CA configuration that you created in Module 8.
Scenario
Your organization must now exchange secure e-mail messages with the other organizations in the
classroom.
Use the following table to help you complete the lab.
Computer MailServer
Vancouver Denver.adatum.msft
Perth Brisbane.fabrikam.msft
Lisbon Bonn.lucernepublish.msft
Lima Santiago.litwareinc.msft
Bangalore Singapore.tailspintoys.msft
Casablanca Tunis.wingtiptoys.msft
Acapulco Miami.thephonecompany.msft
Auckland Suva.cpandl.msft
Stockholm Moscow.adventureworks.msft
Caracas Montevideo.blueyonderair.msft
Manila Tokyo.woodgrovebank.msft
Khartoum Nairobi.treyresearch.msft
Note This lab assumes that you have successfully completed Lab 8A: Implementing a Bridge CA.
account.
2. In the DNS console, create a. On the Start menu, point to Administrative Tools, and then click
an MX record for your mail DNS.
server in your domain’s b. In the console tree, expand Computer (where Computer is the NetBIOS
forward lookup zone. name of your computer), expand Forward Lookup Zones, and then
click Domain.msft (where Domain is the NetBIOS name of your
domain).
c. Right-click the details pane, and then click New Mail Exchanger
(MX).
d. In the New Resource Record dialog box, in the Fully qualified
domain name (FQDN) of mail server box, type MailServer (where
MailServer is the fully qualified domain name of your mail server from
the table at the beginning of this exercise), and then click OK.
3. Verify that the DNS server a. In the console tree, right-click Computer (where Computer is the
is configured to forward NetBIOS name of your computer), and then click Properties.
unresolved DNS queries. b. In the Computer Properties dialog box, click the Forwarders tab.
When completed, close all
open windows and log off.
What IP address are the unresolved DNS queries forwarded to? What computer does this IP address belong
to?
Unresolved DNS queries are forwarded to 192.168.x.200 (where x is the classroom number). This is the
IP address of the London computer.
3. (continued) c. If the IP address for the forwarder is missing, in the Selected domain’s
forwarder IP address list box, type 192.168.x.200 (where x is your
classroom number), click Add, and then click Apply.
d. In the Computer Properties dialog box, click OK.
e. Close the DNS console.
Wait until all DNS forwarders in the classroom are configured before proceeding.
(continued)
4. Log on to your domain with " Log on to the domain by using the following credentials:
your e-mail user account. • User name: Mail1 (on the domain controller) or Mail2 (on the
member server)
• Domain: Domain
5. Record the e-mail address of a. In the space provided, record the e-mail name of a user in a different
a user in another organization who is participating in this exercise:
organization, and then start
Microsoft Outlook.
b. On the desktop, double-click Outlook.
c. If the Microsoft Office XP Professional with FrontPage Activation
Wizard appears, click Activate Later.
d. On the Welcome to the Microsoft Office Activation Wizard page,
click Exit.
6. Enable only the option to a. On the Tools menu, click Options.

digitally sign all outgoing b. In the Options dialog box, on the Security tab, clear the Encrypt
messages. contents and attachments for outgoing messages check box, and
then click OK.
7. Create a new encrypted e- a. On the toolbar, click New.

mail message with the b. Create an e-mail message with the following options:
following settings:
• To: e-mail name (where e-mail name is the e-mail address of a
• To: e-mail name (where partner in a different organization)
e-mail name is the
e-mail address of a • Subject: Signing between organizations
partner in a different • Message body: This is a signed message.
organization) c. On the tool bar, click Send.
• Subject: Signing d. In the Signing data with your private signature key dialog box, in
between organizations the CryptoAPI Private Key box, type P@ssw0rd and then click OK.
• Message body: This is a
signed message.
Wait until you receive a message from your partner in the other organization. You must receive the message
to view the certificate information of the sender.
8. View the certificate used to a. In your Inbox, double-click the message titled Signing between
sign the e-mail message, organizations.
Signing between b. In the message window, click the red ribbon.
organizations.
(continued)
Is the digital signature valid for the signed message?
Yes. No errors appear for the signed message.
8. (continued) c. In the Message Security Properties dialog box, select Signer: e-mail
name (where e-mail name is the e-mail name of the person that sent the
message), and then click View Details.
d. In the Signature dialog box, click View Certificate.
e. In the View Certificate dialog box, click the Certification Path tab.
What is the certification path of the certificate?
The certification path of the certificate is:

rootCA # domainCA # BridgeCA # partnerCA # Certificate
(where rootCA is your organization’s root CA, domain is the NetBIOS name of your domain, partner is
the NetBIOS name of your partner’s domain, and Certificate is the subject name of the certificate.
8. (continued) f. In the View Certificate dialog box, click OK.

g. In the Signature dialog box, click OK.
h. In the Message Security Properties dialog box, click Close.
i. Close the Signing between organizations message.
j. Close Microsoft Outlook.
k. Close all open windows and then log off.
Course Evaluation

Your evaluation of this course will help Microsoft understand the quality of
your learning experience.
To complete a course evaluation, go to http://www.CourseSurvey.com.
Microsoft will keep your evaluation strictly confidential and will use your
responses to improve your future learning experience.

070-298 MSPress - Designing and Managing A Windows Public Key Infrastructure (MOC 2821A) PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

070-298 MSPress - Designing and Managing A Windows Public Key Infrastructure (MOC 2821A) PDF

Загружено:

Авторское право:

Доступные форматы

Designing and Managing a

Windows Public Key ®

Part Number: X09-18729

 2003 Microsoft Corporation. All rights reserved.

Course Number: 2821A

Module 5: Configuring Certificate Templates

Module 11: Configuring E-mail Security

About This Course

Trainer Materials Compact Disc Contents

Student Materials Compact Disc Contents

Bold Represents commands, command options, and syntax that must

 2003 Microsoft Corporation. All rights reserved.

Preparation tasks To prepare for this course, you must:

How to Teach This Module

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Additional Reading from Microsoft Press

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Microsoft Windows Security Resource Kit 0-7356-1868-2

Microsoft Windows Server 2003 Admin Pocket 0-7356-1354-0

Microsoft Windows Server 2003 TCP/IP Protocols and 0-7356-1291-9

Microsoft Windows Server 2003 Administrator’s 0-7356-1367-2

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Course Outline (continued)

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Initial Logon Procedure

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Microsoft Official Curriculum

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Microsoft Certified Professional Program

*****************************ILLEGAL FOR NON-TRAINER USE******************************

! MCSE on Microsoft Windows 2000

*****************************ILLEGAL FOR NON-TRAINER USE******************************

 2003 Microsoft Corporation. All rights reserved.

How to Teach This Module

Lesson: Introduction to PKI

Lesson: Introduction to Cryptography

Lesson: Certificates and Certification Authorities

Lab A: Identifying Trusted Root CAs

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Lesson: Introduction to PKI

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Certificates Manage the local certificate store for users, computers,

Note The Windows Server 2003 Administration Pack (Adminpak.msi)

Programmatic tools Microsoft provides the following APIs to apply cryptography

Lesson: Introduction to Cryptography

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

! Asymmetric key. This type of key is a combination of two mathematically-

How Does Symmetric Encryption Work?

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Note Most encryption solutions deploy a mixture of symmetric and

How Does Public Key Encryption Work?

*****************************ILLEGAL FOR NON-TRAINER USE******************************

How Does Public Key Digital Signing Work?

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Lesson: Certificates and Certification Authorities

*****************************ILLEGAL FOR NON-TRAINER USE******************************

What Is a Digital Certificate?

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**