070-298 mspress - designing and managing a windows public key infrastructure (moc 2821a)

Part Number: X09-18729

Course Number: 2821A

Released: 07/2003

Delivery Guide

Designing and Managing a Windows® Public Key Infrastructure

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.

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.

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.

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

Description

Audience

Student prerequisites

viii Designing and Managing a Windows® Public Key Infrastructure

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.

Course objectives

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


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



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



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

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

Introduction

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, Outlook, 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.

Introduction iii

Instructor Notes The Introduction module provides students with an overview of the course content, materials, and logistics for Course 2821, Designing and Managing a Windows® Public Key Infrastructure.

To teach this course, you need the following materials:

! Delivery Guide ! Trainer Materials compact disc

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.

Presentation: 30 minutes

Required materials

Preparation tasks

iv Introduction

How to Teach This Module This section contains information that will help you to teach this module.

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.

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.

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.

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.

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.

Explain the Microsoft® Official Curriculum (MOC) program and present the list 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

Course materials

Important

Prerequisites

Course outline

Microsoft Official Curriculum

Introduction v

Inform students about the Microsoft Certified Professional (MCP) program, any certification exams that are related to this course, and the various certification options.

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.

Microsoft Certified Professional program

Facilities

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.

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 [email protected]. To inquire about the Microsoft Certified Professional program, send e-mail to [email protected].

Note

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 Administrator�s Companion

0-7356-1574-8

Microsoft Windows Server 2003 Admin Pocket Consultant

0-7356-1354-0

Microsoft Windows Server 2003 TCP/IP Protocols and Services Technical Reference

0-7356-1291-9

Microsoft Windows Server 2003 Administrator�s Companion

0-7356-1367-2

4 Introduction

Prerequisites


This course requires that you meet the following prerequisites:

! Knowledge of Microsoft Windows® 2000 or Windows Server 2003 core technologies and implementation, such as those described in the following 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 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

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


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.

You change your default password in Lab A, �Identifying Trusted Root CAs,� in Module 1 of this course.

Complex passwords

Note

8 Introduction

Microsoft Official Curriculum


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

Introduction 9

Microsoft Certified Professional Program


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.

This course helps students to prepare for:

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

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.

Introduction

Related certification exams

MCP certifications

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

The certification requirements differ for each certification category and are 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.

See the Microsoft Training and Certification Web site at http://www.microsoft.com/traincert/. You can also send e-mail to [email protected] if you have specific certification questions.

Microsoft Official Curriculum (MOC) and MSDN Training can help you 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/.

Certification requirements

For More Information

Acquiring the skills tested by an MCP exam

12 Introduction

Facilities


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

Module 1: Overview of Public Key Infrastructure

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, Outlook, 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.

Module 1: Overview of Public Key Infrastructure iii

Instructor Notes This module introduces students to a public key infrastructure (PKI) and its components. It also provides an overview of the topics that will be explained in the rest of the course.

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.

To teach this module, you need Microsoft® PowerPoint® file 2821A_01.ppt.

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.

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.

Presentation: 60 minutes Lab: 30 minutes

Required materials

Preparation tasks

Note

iv Module 1: Overview of Public Key Infrastructure

How to Teach This Module 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.

This section contains information that will help you to teach this module.

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.

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.

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.

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

What Is a PKI?

Components of a PKI

PKI Tools

Encryption Keys

Module 1: Overview of Public Key Infrastructure v

When you present this topic, consider discussing simple encryption algorithms, 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.

When you discuss this topic, use the example of two students in a classroom 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.

Discuss each step in the digital signing process and answer any questions.

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. When you discuss this topic, ensure that students understand the difference 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. Consider opening a certificate in the Certificates console when you discuss this 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.

This topic introduces the tasks that a CA performs in a PKI. Review each of the 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.

This topic introduces root and cross-certified hierarchies. Spend time discussing root CA hierarchies. If students have questions about cross certification hierarchies, defer the questions until you present Module 8, �Configuring Trust Between Organizations.�

How Does Symmetric Encryption Work?

How Does Public Key Encryption Work?

How Does Public Key Digital Signing Work?

What Is a Digital Certificate?

What Are Certificate Extensions?

What Is a Certification Authority?

Certification Authority Hierarchies

vi Module 1: Overview of Public Key Infrastructure

This topic introduces terminology that is used in the remainder of the course. 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.

The topic presents different methods for adding root CAs to a trusted root CA 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.

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.

Complete the automated setup or manual setup for Course 2821, Designing and Managing a Windows Public Key Infrastructure.

Roles in a Certification Authority Hierarchy

What Are Trusted Root Certificates?

Lab A

Setup requirement 1

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


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.

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.

Introduction

Objectives

2 Module 1: Overview of Public Key Infrastructure

Lesson: Introduction to PKI


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.

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.

Introduction

Lesson objectives


What Is a PKI?


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.

Introduction


Components of a PKI


A PKI consists of several interrelated objects, application, and services. These components work together to distribute and validate certificates. 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.

Introduction

PKI components


PKI Tools


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.

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.

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.

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.

Introduction

MMC snap-ins

Note

Command-line 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.

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.

Resource Kit tools

Programmatic tools


Lesson: Introduction to Cryptography


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.

Introduction

Lesson objectives


Encryption Keys


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.

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.

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.

Introduction

Key types

Warning


How Does Symmetric Encryption Work?


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.

When performing symmetric encryption, the sender of the original data 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.

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.

Introduction

The symmetric encryption process

Note


How Does Public Key Encryption Work?


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 following steps explain the process for how public key encryption is 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.

Introduction

The public key encryption process


How Does Public Key Digital Signing Work?


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 following steps explain the process for how a digital signature is applied to 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.

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.

Introduction

The digital signing process

Note


Lesson: Certificates and Certification Authorities


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.

Introduction

Lesson objectives


What Is a Digital Certificate?


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.

A digital certificate contains the following:

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

Introduction

Contents of a digital certificate


What Are Certificate Extensions?


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.

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.

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.

Introduction

Version 1 fields

Note


X.509 version 3 certificates are the current certificate format in a 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.

X.509 version 3 extensions


What Is a Certification Authority?


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.

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.

Introduction

CA tasks


Certification Authority Hierarchies


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.

Root hierarchies are preferred over cross certification hierarchies because they are easier to deploy, maintain, and troubleshoot.

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.

Introduction

Note

Root hierarchies


A cross certification hierarchy: ! 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 organization�s CA hierarchy.

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

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.

Cross certification hierarchies

Note


Roles in a Certification Authority Hierarchy


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.

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.

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.

Introduction

Root CAs

Policy CAs


Typically, you remove root CAs and policy CAs from the network to provide additional physical security and to protect the CAs from network attacks.

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.

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 Reading on the Web page on the Student Materials compact disc.

Note

Issuing CAs

Note


What Are Trusted Root Certificates?


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.

There exists more than one way to designate a root certificate as a trusted root 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.

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.

Introduction

Designating trusted root CAs

Important


! 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 Program

Windows XP or the Windows Server 2003 family

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


After completing this lab, you will be able to:

! Identify trusted root stores. ! Remove trusted root CAs that are not required.

This lab focuses on the concepts that are explained in this module and may not comply with Microsoft security recommendations.

Before working on this lab, you must have completed the course setup.

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.

Objectives

Note

Prerequisites

Additional information

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 administrative account.

a. Turn on your computer.

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 your own personal password.

a. In the Logon Message message box, click OK.

b. In the Change Password dialog box, in the New Password and 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 verify that the Administrative Tools menu appears.

" Click Start, and then verify that the Administrative Tools menu is available on the Start menu.

If Administrative Tools is not available, perform the tasks in Step 4. If Administrative Tools is available, proceed to Step 5.


(continued)


4. Add Administrative Tools to the Start menu.

a. Right-click Start, and then click Properties.

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 CA administrators.

a. Close all open windows and then log off.

b. Log on to your computer by using the following information:

• User name: CAadmin1 (on the domain controller) or CAadmin2 (on the member server)











8. Log on as a member of the 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)







11. Log on as a member of the auditors.



• User name: Auditor1 (on the domain controller) or Auditor2 (on the member server)


• Domain: Domain









14. Log on as a member of the key recovery agents.



• User name: KRA1 (on the domain controller) or KRA2 (on the member server)


• Domain: Domain





(continued)







17. Close all open windows and then log off the network.

" Close all open windows and log off.


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 administrative account for your domain.

" Ensure that you are logged on with the following account information:

• User name: Student1 (at the domain controller) or Student2 (at the member server)

• Password: Password (where Password is the password for your administrative account)


2. Create an MMC and then add the following snap-ins:

• Certificates � Current User

• Certificates � Local Computer

a. Click Start, click Run, type MMC and then click OK.

b. On the File menu, click Add/Remove Snap-in.

c. In the Add/Remove Snap-in dialog box, click Add.

d. In the Add Standalone Snap-in dialog box, in the Available Standalone Snap-ins list, select Certificates, and then click Add.

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 desktop as Certificate Management.

a. In the Console1 � [Console Root] window, on the File menu, click Save As.

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 for both the current user and the local computer in the Certificates MMC snap-in.

a. In the Certificate Management console, in the console tree, expand Certificates � Current User, expand Trusted Root Certification Authorities, and then click Certificates.

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 Components that are available in the Add/Remove Windows Components list.

a. Click Start, point to Control Panel, and then click Add or Remove Programs.

b. In the Add or Remove Programs dialog box, click Add/Remove Windows Components.

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 add the Group Policy object Default Domain Policy.

a. Click Start, click Run, type MMC and then click OK.



d. In the Add Standalone Snap-in dialog box, in the Available 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 Certification Authorities container in Default Domain Policy.

a. In the console tree, expand Default Domain Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Public Key Policies, and then click 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 and inspect CA certificate publication points in the Configuration naming context.

a. Click Start, click Run, type Adsiedit.msc and then click OK.

b. In the console tree, expand Configuration, expand CN=Configuration, DC=ForestName (where ForestName is the LDAP distinguished name of your forest), expand CN=Services, 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.

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

Module 2: Designing a Certification Authority Hierarchy

Module 2: Designing a Certification Authority Hierarchy iii

Instructor Notes This module introduces the students to designing a Certification Authority (CA) 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.


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


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.


! Read all of the materials for this module. ! 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.


Required materials

Important

Preparation tasks

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.


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.

This topic describes the applications that benefit from PKI. Although the topic 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.

Discuss the accounts that use the applications that students identified in the previous topic. Users, computers and services are the accounts that can use 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.

Emphasize how critical it is to identify all the technical requirements for a 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.

Emphasize how critical it is to identify all the business requirements for a successful CA hierarchy design. This topic may generate interesting discussions about the business requirements. Help the students to distinguish between technical and business requirements.

Project Scope

Applications that Use a PKI

Which Accounts use PKI-Enabled Applications?

How to Identify Technical Requirements

How to Identify 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.

Discuss the various services and applications that require certificates in a PKI. 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.

Use a scenario when you discuss this topic, and explain the performance 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.

Give examples of typical departments within an organization that may 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.

Explain that within an organization, different types of users may require 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.

The students might not know much about the legal requirements that are 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.

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.

Tell the students that the certificate policy describes how the organization�s PKI enforces the organization�s security policy.

Explain that after the certification policy is in place, the CPS states how to implement and enforce the certification policy in the organization.

CA Hierarchy Based on Certificate Use

CA Hierarchy Based on Location

CA Hierarchy Based on Departments

CA Hierarchy Based on Organizational Structure

Steps for Designing Legal Requirements

Security Policy

Certificate Policy

Certification Practice Statement

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.

Tell the students that these recommendations are just a few ways that they can meet security requirements. To generate an interesting discussion, ask the students for other ways the design can meet the security requirements.

List the external access requirements and ask the students to discuss how they would meet these requirements. Remind them that there can be multiple ways of meeting a requirement.

When you discuss application requirements, present some scenarios and ask students to provide input. Collect information and discuss the type of applications that students use in their organizations.

Tell the students that depending on the administration model of their organization, they might have different solutions for meeting administration 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.

This topic highlights the challenges that CA designers face when they try to ensure certificate availability for multiple regions, applications, and users. 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.

Review the different types of CAs. Give some examples for each security level and discuss the recommended depth of each. Discuss the optimal CA hierarchy depth and why it is optimal.

Use the slide to discuss the security level at each layer. Discuss the reasons for 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.

Explain the table on the slide. Discuss one example of a standalone CA and 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.

This is the first mention of the term role separation. Ensure that the students 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.

Recommendations for Meeting Security Requirements

Recommendations for Meeting External Access Requirements

Recommendations for Meeting Application Requirements

Recommendations for Meeting Administration Requirements

Recommendations for Meeting Availability Requirements

Recommended Depth of a CA Hierarchy

Security Levels in the CA Hierarchy

Considerations for Choosing a CA Type

CA Management Using Role Separation

Module 2: Designing a Certification Authority Hierarchy vii

Emphasize that because there are many factors to consider before students 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 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.

Guidelines for Designing a CA Hierarchy

Lab A

Module 2: Designing a Certification Authority Hierarchy 1

Overview


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.

Introduction

Objectives

2 Module 2: Designing a Certification Authority Hierarchy

Lesson: Identifying CA Hierarchy Design Requirements


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.

Introduction

Lesson objectives


Project Scope


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.

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.

Introduction

Scope dependencies


Applications that Use a PKI


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.

A Microsoft® Windows Server� 2003 PKI supports the following types of PKI-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.

Introduction

PKI-enabled applications


! 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?


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.

Several types of accounts can obtain digital certificates in a Windows 2003 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.

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.

Introduction

Who uses the applications?

Note


How to Identify Technical Requirements


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.

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 requirements also affect your design. A centralized administration model requires one central CA. A decentralized administration model requires additional CAs to delegate specific administration tasks.

The security requirements and the design of the issuing CAs determine the total 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.

Introduction

Security requirements

Administration requirements

Availability requirements


How to Identify Business Requirements


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.

To issue certificates to partners, ensure that at least one CA is accessible from 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.

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.

Introduction

External access requirements

Note


Availability requirements can affect your CA design in two ways:

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

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.

Availability requirements

Legal requirements


Lesson: Common CA Hierarchy Designs


There are several types of CA hierarchy designs. A CA hierarchy design depends on the requirements, structure, location, and processes of an organization.

After completing this lesson, you will be able to design CA hierarchies based on:

! Certificate use ! Geography ! Departments ! Organizational structure

Introduction

Lesson objectives


CA Hierarchy Based on Certificate Use


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.

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.

Introduction

Example


CA Hierarchy Based on Location


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.

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.

Introduction

Example


CA Hierarchy Based on Departments


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.

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.

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.

Introduction

Example

Note


CA Hierarchy Based on Organizational Structure


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.

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.

Introduction

Example


Lesson: Documenting Legal Requirements


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.


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

Introduction


Steps for Designing Legal Requirements


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

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.

To define legal 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.

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.

Introduction

Note

Steps to define the legal requirements

Note


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.

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.

Note


Security Policy


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.

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?

For more information about security policies and procedures, see RFC 2196, Site Security Handbook, at http://www.ietf.org/rfc/rfc2196.txt.

Introduction

Security policy

Note


Certificate Policy


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.

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.

Introduction

Certificate policy


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.

Note


Certification Practice Statement


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.

You can include the following sections in a certification practice statement. All 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.

Introduction

Certification practice statement


! Technical Security Controls. Describes the security measures to protect the CA�s private key and provides technical information about the security measures.

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.

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.

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 Managing a Windows Public Key Infrastructure.

Note

Note

Note


Lesson: Analyzing Design Requirements


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.

Introduction

Lesson objectives


Recommendations for Meeting Security Requirements


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.

The root CA is the most important CA in your hierarchy. If it is compromised, 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.

Introduction

Root and policy 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.

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.

If different issuance requirements exist for similar certificates, you must create 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.

Issuing CA security

Private key protection

Different issuance requirements


Recommendations for Meeting External Access Requirements


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.

Many applications that depend on PKI require external clients to recognize the certificates that your PKI hierarchy issues. To make CA certificates and CRLs 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.

Introduction

Recognition of certificates by external clients


You can manage certificates that are issued by private CAs more easily than certificates that are issued by external CAs. Even if you issue certificates from a 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.

External clients can only trust certificates that are issued from your PKI 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.

For more information about cross certification and qualified subordination, see Module 8, �Configuring Trust Between Organizations,� in Course 2821, Designing and Managing a Windows Public Key Infrastructure.

Management of certificates issued to external users

Trust certificates from another organization

Note


Recommendations for Meeting Application Requirements


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.

The following application requirements may affect your CA hierarchy design:

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

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.

Introduction

Application requirements

Note


Recommendations for Meeting Administration Requirements


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.

In a delegated administration scenario, you can:

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

Introduction

Delegated administration


You may make some of the following design decisions to support centralized 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.

Centralized administration


Recommendations for Meeting Availability Requirements


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.

Using multiple CAs is the best way to ensure that your infrastructure can support enterprise scalability and provide high availability. Implementing 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.

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.

Introduction

Make certificate templates highly available

Support multiple regions


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.

Use hardware RAID solutions for CAs. Do not use the software RAID services that Windows 2003 Server provides.

Minimize CA failure

Note


Lesson: Designing a CA Hierarchy Structure


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.

Introduction

Lesson objectives


Recommended Depth of a CA Hierarchy


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.

The following characteristics describe an organization that has low security 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.

Introduction

Low security requirements


The following characteristics describe an organization that has medium security requirements:

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

The following characteristics describe an organization that has high security requirements:

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

Medium security requirements

High security requirements


Security Levels in the CA Hierarchy


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.

An ideal PKI hierarchy consists of the following levels of CAs:

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

Introduction

Ideal PKI hierarchy design


The following characteristics describe the security 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.

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.

The following characteristics describe the security 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.

The following characteristics describe the security 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.

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.

Security characteristics of a root CA

Note

Security characteristics of a policy CA

Security characteristics of an issuing CA

Note


Considerations for Choosing a CA Type


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.

The following table compares standalone and enterprise CAs.

Standalone CA Enterprise CA Is typically used for offline CAs, but can also be used as an online CA

Is typically deployed as an issuing CA that issues certificates to users, computers, and services

Does not depend on Active Directory and can be deployed in other environments or in network segments where Active Directory cannot be contacted

Requires Active Directory as a configuration and registration database and as a publication point for certificates that are issued to users and computers

Supports requests for standard user and computer certificates, such as user-authentication certificates and Web-server certificates

Defines certificate formats in certificate templates that it issues

Requires that, by default, all certificate requests received by the standalone CA must be issued or denied by a certificate manager

Issues or denies certificate requests based on the discretionary access control list (DACL) of the requested certificate template

You can configure a certificate template to require certificate manager approval for issuance.

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.

Introduction

Comparing CA types

Note

Warning


CA Management Using Role Separation


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.

To create the criteria for separating roles, decide which individuals will perform each of the following tasks:

! Manage the CA configuration ! Issue or revoking certificates ! Configure and view audit logs ! Back up the CA

To help determine role separation, you can use the Common Criteria specification, which defines security standards for all forms of network security and includes specifications for managing PKIs.

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.

Introduction

Criteria for role separation

What is the Common Criteria specification?

Note


The specification identifies four roles for PKI management:

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

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.

Role Separation using Common Criteria

Warning


Guidelines for Designing a CA Hierarchy


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.

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.

Introduction

Guidelines


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.

Before working on this lab, you must have completed the course setup.

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.

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.

Objectives

Prerequisites


Scenario



Exercise 1 Identifying Applications and Certificate Holders

In this exercise, you will determine whether the certificate to support PKI-enabled applications was issued to users or computers.

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.

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 # #

Introduction

Scenario

Questions


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.

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.

Scenario


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

____________________________________________________________

____________________________________________________________

Questions


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.

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.

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

____________________________________________________________

____________________________________________________________

Scenario

Questions


3. Based on the requirements that are presented in this lab, draw your proposed CA hierarchy for Northwind Traders.

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

Module 3: Creating a Certification Authority Hierarchy

Module 3: Creating a Certification Authority Hierarchy iii

Instructor Notes This module introduces students to the process of creating a certification authority (CA) hierarchy based on a CA hierarchy design. Students will learn how to determine the correct settings and configuration for installing Certificate Services, validating certificates, and publishing certificate revocation lists (CRLs).


! Create an offline root CA. ! Design an infrastructure to validate certificates. ! Design an infrastructure to publish certificate revocation lists. ! Install a subordinate CA.

To teach this module, you need the following materials:

! Microsoft® PowerPoint® file 2821A_03.ppt ! The multimedia presentation The Certificate Chaining Engine



! Read all of the materials for this module. ! 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.

Presentation: 90 minutes Labs: 120 minutes

Required materials

Important

Preparation tasks

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.

Show the students the sample CAPolicy.inf file, which is found 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. 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.

Emphasize that the CAPolicy.inf file must exist in the %Windir% before you install Certificate Services.

Spend time describing object identifiers (OIDs) and where to acquire OIDs if the students are unfamiliar with the concept. Some of the students may have experience with OIDs from using Simple Network Management Protocol (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.

The settings that are described in this topic appear when you run the Certificate 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.

Although Hardware Security Modules (HSMs) increase the security of a CA, 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.

What Is a CAPolicy.inf file?

How to Create a CAPolicy.inf File

Guidelines for Implementing a Certificate Practice Statement

Define Settings for an Offline CA

Secure an Offline CA Using an HSM

Module 3: Creating a Certification Authority Hierarchy v

Spend time reviewing each of the guidelines. Emphasize to students that an incorrect decision during the installation of the root CA may require that they redeploy the entire PKI.

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.

Emphasize to students that certificate validation involves more than 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.

The multimedia files are installed on the instructor computer. To open a multimedia presentation, click the animation icon on the slide for that 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.

The five certificates for the practice are provided in the 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.

Guidelines for Deploying an Offline Root CA

Lab A

How Applications Check Certificate Status

Multimedia: The Certificate Chaining Engine

Practice: Identifying Matching Rules

vi Module 3: Creating a Certification Authority Hierarchy

The certificate chaining engine performs multiple validation tests to ensure that 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.

Explain the various reasons for revoking a certificate. Emphasize that although 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.

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.

Show students the animated slide. Discuss how the revocation recognition varies if a client computer running Windows 2000 Professional does not recognize delta CRLs.

Planning CRL publication intervals is based on all of the business drivers that are shown on the slide. Although many students may want to start modifying 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.

Discuss the reasons for choosing the Active Directory® directory service, Web servers, FTP servers, and file servers as publication points. Emphasize that students will typically use only Lightweight Directory Access Protocol (LDAP) and HTTP URLs.

Review the Certutil.exe syntax that is used in the ModifyAIAandCDP.cmd batch file with the students. Created for this course, the batch file automates the modification of the CDP and AIA URLs. Spend time reviewing the variables that are used in the batch file, and where modifications are required.

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.

Certificate Validation Tests

Reasons for Revoking Certificates

Types of CRLs

How CRLs Are Published

Criteria for Planning CRL Publication Intervals

Where to Create the Publication Points

Demonstration: How to Modify CDP and AIA Extensions

Lab B

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.

To install an enterprise CA, you must be a local administrator�to install Certificate Services and to request a machine certificate for the computer�and 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.

Before certificates are issued to subordinate CAs, the issuing CA must be 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.

Emphasize that the installation process varies when the parent CA is a standalone CA and when the parent CA is an enterprise CA. The Subordinate 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.

Discuss scenarios where the CDP and AIA extensions require modification for an enterprise CA. For example, discuss the publication of the CRL and CA certificate to a Web server that is located in a screened subnet.

During the demonstration, show students some of the additional options that 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.

Be sure to explain all of the modifications that students must make to a Windows 2000 forest before they can install a Windows Server 2003 PKI. Ensure that students understand that the order in which the modifications are performed is very important.

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.

Permissions for Installing an Enterprise CA

How to Prepare the Issuing CA

Steps for Installing an Enterprise Subordinate CA

Considerations for Configuring AIA and CDP Extensions

Demonstration: Using the PKI Health Tool

How to Deploy Windows Server 2003 PKI in a Windows 2000 Forest

Lab C

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.


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.

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.

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.

Setup requirement 1

Setup requirement 2

Important

Module 3: Creating a Certification Authority Hierarchy ix


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.

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.

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.

Lab A

Lab B

Lab C

Module 3: Creating a Certification Authority Hierarchy 1

Overview


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.

Introduction

Objectives

2 Module 3: Creating a Certification Authority Hierarchy

Lesson: Creating an Offline Root CA


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.

Introduction

Lesson objectives


What Is a CAPolicy.inf File?


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 Additional Reading on the Web page on the Student Materials compact disc.

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.

Definition

Important


In a CAPolicy.inf configuration file, you can define:

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

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

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

What is defined in the CAPolicy.inf file?

Note

Note


How to Create a CAPolicy.inf File


A CAPolicy.inf file defines the configuration of certificate services for both root CAs and subordinate CAs.

To create a 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.

Introduction

How to create a CAPolicy.inf file


Guidelines for Implementing a Certification Practice Statement


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.

The format of a CPS is defined in 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.

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.

In a CAPolicy.inf file, you can define a certification practice statement. The 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.

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.

Introduction

Note

Defining certificate policies

Note


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.

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.

What is an OID?

CA Policy format


Define Settings for an Offline CA


Before you install an offline CA, define and document its configuration settings so that you can rebuild the CA in the event of disaster.

Define the following settings for 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.

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.

Introduction

Defining the settings for an offline CA

Note


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.

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.

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.

Note

Note


Secure an Offline CA Using an HSM


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.

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.

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.

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.

Introduction

What is an HSM?

Note

Features of a HSM


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

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.

If you maintain the root CA in a secure data center or vault, perform the offline 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.

Secure private keys

Using secure business practices


Guidelines for Deploying an Offline Root CA


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.

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

Introduction

Guidelines


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

Consider these guidelines when deploying any offline CAs, whether the CA is an offline root CA or an offline subordinate CA.

Note


Lab A: Installing an Offline CA



! Configure CAPolicy.inf for the installation of an offline root CA. ! Install an offline root CA.

This lab focuses on the concepts that are explained in this module and 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.

Objectives

Note


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

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 Reading on the Web page on the Student Materials compact disc.

Prerequisites




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 using your local administrative account.

a. Turn on the computer.

b. On the member server, in the Please select the operating system to 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\ module3\CAPolicy.inf to D:\windows and clear the Read-only check box.

a. Open C:\moc\2821\labfiles\module3.

b. Copy CAPolicy.inf to the D:\windows folder.

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 to the D:\windows\ CAPolicy.inf file:

• Change OID to 1.2.3.4.5.6.7.8.9.x

• Set CrlPeriodUnits to CRLPeriodUnits=26

• Set CRLPeriod to CRLPeriod=weeks

• Change Webserver to DomainController

a. Open D:\windows\CAPolicy.inf.

b. Under [LegalPolicy], change OID to 1.2.3.4.5.6.7.8.9.x (where x is the last octet of your computer�s IP address).

c. Under [Certsrv_server], make the following changes:

• Set CrlPeriodUnits to CRLPeriodUnits=26

• Set CRLPeriod to CRLPeriod=weeks

• Set CRLDeltaPeriodUnits to CRLDeltaPeriodUnits=0

• Set CRLDeltaPeriod to CRLDeltaPeriod=days

d. On the Edit menu, click Replace.

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 CAPolicy.inf.

a. Save all changes, and then close 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 Programs in Control Panel.

a. Ensure that you are logged on as Administrator with a password of 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 with the following options:

• Stand-alone root CA

• CSP: Microsoft Strong Cryptographic Provider

• Hash algorithm: SHA-1

• Key length: 4096

• Common Name: Computer

• Distinguished name suffix: ForestName

• Validity Period: 20 Years

a. In the Add or Remove Programs dialog box, click Add/Remove Windows Components.

b. In the Windows Components Wizard, in the Components list, select the Certificate Services check box.

c. In the Microsoft Certificate Services dialog box, click Yes.

d. On the Windows Components page, click Next.

e. On the CA Type page, click Stand-alone root CA, enable the Use custom settings to generate the key pair and CA certificate check box, and then click Next.

f. On the Public and Private Key Pair page, set the following options:




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


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.

Introduction

Lesson objectives


How Applications Check Certificate Status


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

You cannot modify cache settings or turn off caching.

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.

For more information about path validation, see the white paper, Troubleshooting Certificate Status and Revocation, under Additional Reading on the Web page on the Student Materials compact disc.

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.

Introduction

Certificate discovery

Note

Path validation

Note

Revocation checking


Multimedia: The Certificate Chaining Engine


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.

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

File location

Key points


Practice: Identify Matching Rules


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.

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.

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

Introduction

Note

Certificate1.cer


Attribute Value 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

Attribute Value 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

Attribute Value 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

Attribute Value 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

Certificate2.cer

Certificate3.cer

Certificate4.cer

Certificate5.cer


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.

Chain building method for Chain 1:

Key match _______________________________________________________________

_______________________________________________________________

Chain building method for Chain 2:

Exact match

_______________________________________________________________

_______________________________________________________________

Analysis

Certificate 1 Certificate 5

Certificate 4

Certificate 3

Certificate 2


Certificate Validation Tests


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.

The operating system performs the following tests on each certificate in the 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.

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.

Introduction

Certificate validation tests

Note


! 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


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.

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.

Introduction

Reasons for revocation


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

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.

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.

Note

Note


Lesson: Planning CRL Publication


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.

Introduction

Lesson objectives


Types of CRLs


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.

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

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.

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.

Introduction

Base CRLs

Delta CRLs

Important


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.

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.

Note


How CRLs Are Published


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.

Each CA is configured with a CRL publication setting or CRL publish period. 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.

Introduction

The CRL publication process


Criteria for Planning CRL Publication Intervals


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.

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.

Introduction

Criteria


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

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.

Important


Where to Create the Publication Points


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.

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.

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.

Introduction

Publication points

Note


Demonstration: How to Modify CDP and AIA Extensions


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.

This demonstration focuses on the concepts in this lesson and as a result may not comply with Microsoft security recommendations.

ModifyAIAandCDP.cmd is a custom batch file that modifies the registry entries 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.

To modify the ModifyAIAandCDP.cmd file:

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.

Introduction

Note

What is the ModifyAIAandCDP.cmd?

Procedure for Modifying ModifyAIAandCDP.cmd


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.

You must publish the CRL to all configured LDAP and HTTP URLs for the 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.

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.

The CA certificate is published in the AIA URLs. To publish 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.

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.

Procedure for Publishing the CRL

Warning

Procedure Publishing the CA Certificate

Warning


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.

This lab focuses on the concepts that are explained in this module and may not comply with Microsoft security recommendations. For instance, this 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.

Objectives

Note



! A computer that has a dual-boot configuration that can function as both the offline root CA and the member server for your domain.

! 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

Prerequisites



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 MMC, ensure that the CRL publication interval is set to 26 weeks for the root CA.

a. Click Start, point to Administrative Tools, and then click Certification Authority.

b. In the console tree, expand Computer (where Computer is the NetBIOS 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:///, http://, and file://\\ URLs in the CRL distribution points (CDP) list on the Extensions tab of the Computer Properties dialog box.

a. In the console tree, right-click Computer, and then click Properties.

b. In the Computer Properties dialog box, on the Extensions tab, in the Select extension drop-down list, ensure that the box reads CRL Distribution Point (CDP).

c. Review the default ldap:///, http://, and file://\\ URLs in the CRL 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:///, http://, and file://\\ URLs in the Authority Information Access (AIA) list on the Extensions tab of the Computer Properties dialog box.

a. On the Extensions tab, in the Select extension drop-down list, select Authority Information Access (AIA).

b. Review the default ldap:///, http://, and file://\\ URLs.

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 modifications to ModifyAIAandCDP.cmd in the C:\moc\2821\labfiles\ Module3 folder.

• Clear the Read-only check box.

• Change all occurrences of Webserver to DomainController.

• Change all occurrences of ForestName to ForestName.

a. Open C:\moc\2821\Labfiles\Module3.

b. Right-click ModifyAIAandCDP.cmd and then click Properties.

c. In the ModifyAIAandCDP.cmd Properties dialog box, ensure that the Read-only check box is cleared, and then click OK.

d. Right-click ModifyAIAandCDP.cmd and then click Edit.

e. On the Edit menu, click Replace.

f. In the Replace dialog box, in the Find what box, type Webserver

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

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 LDAP distinguished name of your forest from the table at 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 ModifyAIAandCDP.cmd command file.

" In the C:\moc\2821\labfiles\Module3 window, double-click ModifyAIAandCDP.cmd.

6. Publish the latest version of the CRL.

a. In the Certification Authority console, in the console tree, right-click 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, increase the validity period of issued certificates to 10 years by using certutil �setreg.

a. At a command prompt, type certutil -setreg ca\ValidityPeriodUnits 10 and then press ENTER.

b. At the command prompt, type certutil -setreg ca\ValidityPeriod "Years" and then press ENTER.

c. Close the command prompt.

8. Restart Certificate Services from the Certification Authority console and then close the console.

a. Ensure that the Certification Authority console is the active window.

b. In the console tree, right-click Computer, click All Tasks, and then click Stop Service.

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 administrative account, and open Add or Remove Programs from Control Panel.

a. Turn on the domain controller.

b. Log on to the domain with the following account information:

• User name: Student1



c. On the Start menu, click Control Panel, and then click Add or Remove Programs.

2. Install the Application Server component with the following subcomponents: • Enable network COM+

access

• Internet Information Services (IIS)

• Common Files

• Internet Information Services Manager

• World Wide Web Service

• Active Server Pages


a. In the Add or Remove Programs dialog box, click Add/Remove Windows Components.

b. On the Windows Components page, in the Components list, click the phrase Application Server (not the check box), and then click Details.

c. In the Application Server dialog box, in the Subcomponents of Application Server list, select the Enable network COM+ access check box, click the phrase Internet Information Services (IIS) (not the check box) , and then click Details.

d. In the Internet Information Services (IIS) dialog box, in the Subcomponents of Internet Information Services (IIS) list, select the following subcomponent check boxes:

• Common Files

• Internet Information Services Manager

e. In the Subcomponents of Internet Information Services (IIS) list, 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


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 C:\Inetpub\wwwroot\ Legalpolicy and copy the C:\moc\2821\labfiles\ module3\rootcps.htm file to the Legalpolicy folder.

a. Open the C:\Inetpub\wwwroot folder.

b. Create a new subfolder named Legalpolicy.

c. Open C:\moc\2821\labfiles\Module3.

d. Copy the file rootcps.htm to the C:\inetpub\wwwroot\Legalpolicy folder.

4. Copy the contents of \\Computer\admin$\ system32\certsrv\ Certenroll to the C:\inetpub\wwwroot\ CertData folder.

a. Open C:\Inetpub\wwwroot.

b. Create a new subfolder named CertData.

c. Open \\Computer\admin$ (where Computer is the NetBIOS name of your offline root CA computer).

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 Local Intranet zone in Internet Explorer.

a. Open Internet Explorer.

b. In the Internet Explorer dialog box, click In the future, do not show 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 http://WebServer/ Legalpolicy/rootcps.htm in Internet Explorer.

" In Internet Explorer, in the Address bar, type http://WebServer/Legalpolicy/rootcps.htm (where WebServer is the fully qualified domain name of your domain controller), and then press 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 http://WebServer/CertData/Computer.crl in Internet Explorer.

a. In the Address bar, type http://WebServer/CertData/Computer.crl (where WebServer is the fully qualified domain name of your domain controller and Computer is the NetBIOS name of the offline root CA), 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 http://WebServer/CertData/Computer_Computer.crt.

a. In the Certificate Revocation List dialog box, click OK.

b. In Internet Explorer, in the Address bar, type 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 Enterprise Admins group and publish the CRL and CA certificate to Active Directory by using the following commands:

• certutil �dspublish �f Computer.crl

• certutil �dspublish �f Computer_Computer.crt RootCA

a. At a command prompt, type cd \inetpub\wwwroot\Certdata and then press ENTER.

b. To publish the latest CRL to Active Directory, at the command prompt, type certutil �dspublish �f Computer.crl (where Computer is the NetBIOS name of your offline root CA), and then press ENTER.

Verify that the response to the certutil command states that the certutil -dspublish command was completed successfully.

c. To publish the CA certificate to Active Directory, at the command prompt, type certutil �dspublish �f Computer_Computer.crt RootCA (where Computer is the NetBIOS name of your offline root CA), and then press ENTER.

Verify that the response to the certutil command states that the certutil -dspublish command was completed successfully.

11. Force Group Policy application by running gpupdate /force.

a. At the command prompt, type gpupdate /force and then press ENTER.

b. Close the command prompt.


(continued)


12. Open the URL http://WebServer/CertData/Computer_Computer.crt in Internet Explorer.


b. In Internet Explorer, in the Address bar, type 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 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 for the CA certificate.

a. In the Certificate dialog box, click Issuer Statement.

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


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.

Introduction

Lesson objectives


Permissions for Installing an Enterprise CA


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.

During the installation of an enterprise CA, several objects are modified in 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.

Introduction

Permissions to install the enterprise CA


How to Prepare the Issuing CA


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.

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.

Introduction

Preparation steps


Steps for Installing an Enterprise Subordinate CA


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:

The installation of the enterprise subordinate CA varies depending on the 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.

When you install Certificate Services, you must determine whether the 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.

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.

Introduction

Determine the CA type of the parent CA

Install Certificate Services

Note


When the installation is near completion, the submission of the CA certificate 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.

The final step in installing an enterprise CA is to install the CA certificate and 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.

Submit the subordinate CA certificate request

Install the certificate on the Enterprise CA


Considerations for Configuring AIA and CDP Extensions


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.

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.

You must manually publish the CA certificate and CRL to the externally accessible locations from the enterprise CA.

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.

Introduction

External users

Note

Internal users


Demonstration: Using the PKI Health Tool


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.


To use the 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.

Introduction

Note

Procedure for using the PKI Health Tool


To reset the warning periods for CA certificates, CRLs, and delta CRLs:

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.

Procedure for resetting warning periods


How to Deploy Windows Server 2003 PKI in a Windows 2000 Forest


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.

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.

To deploy Windows Server 2003 enterprise CAs in a Windows 2000 forest:

1. Upgrade all Windows 2000 domain controllers to Service Pack (SP) 3 or 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.

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.

Introduction

Warning

Procedure for deploying Windows Server 2003 enterprise CAs in a Windows 2000 forest

Note


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.

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.

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.

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.

Note

Note

Note


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.

This lab focuses on the concepts that are explained in this module and may not comply with Microsoft security recommendations. For instance, this 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 offline root CA and the member server for your domain.

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

Objectives

Note

Prerequisites


! 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

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 Student Materials compact disc.




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 computer from the classroom network.

a. Remove the offline root CA computer from the network by unplugging the network cable.

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 with the following options, and then save the request to a file named a:\request.req.

• Enterprise subordinate CA




• Common name: DomainCA

a. Ensure you are logged on with the following credentials:




b. Insert a newly formatted floppy disk into the floppy disk drive.

c. Insert the Windows Server 2003 Enterprise Edition disk into the CD-Rom drive, if you have not already done so.

d. Click Start, click Control Panel, and then click Add or Remove Programs.

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:




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 LDAP distinguished name of your forest from the table at 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, and then click Next.

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 local administrator of the root CA computer and then insert the floppy disk that contains the request.req file in the floppy drive.

a. Ensure that you are logged on with the following credentials:



b. Insert the floppy disk containing the certificate request file in the floppy disk drive.


(continued)


4. In the Certification Authority console, request a new certificate by using the A:\request.req request file.

a. Click Start, click Administrative Tools, and then click Certification Authority.

b. In the console tree, right-click Computer, point to All Tasks, and then 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 Authority console, issue the pending certificate request.

a. In the console tree, expand Computer, and then click Pending Requests.

b. In the details pane, right-click the pending certificate, point to All Tasks, and then click Issue.

6. Export the issued certificate to a PKCS #7 file named subca.p7b that includes all of the certificates in the certification path.

a. In the console tree, click Issued Certificates.

b. In the details pane, double-click the issued certificate.

c. In the Certificate dialog box, on the Details tab, click Copy to File.

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 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. 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 the Certification Authority console by using the a:\subca.p7b file.

a. Insert the floppy disk that contains the PKCS #7 file in the floppy drive.

b. Click Start, click Administrative Tools, and then click Certification 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 click Start Service.


(continued)


8. View the CA certificate for the DomainCA CA.

a. In the Certification Authority console, in the console tree, expand 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 tab.

" In the Certificate dialog box, click the Certification Path tab.

What is the CA hierarchy path for your enterprise subordinate CA? The CA hierarchy path is Computer => DomainCA

10. Close the Certificate dialog box and the DomainCA Properties dialog box.

a. In the Certificate dialog box, click OK.

b. In the DomainCA Properties dialog box, click OK.

11. Increase the validity period of issued certificates to 5 years by using certutil �setreg.

a. Open a command prompt.

b. At the command prompt, type certutil -setreg ca\ValidityPeriodUnits 5 and then press ENTER.

c. At the command prompt, type certutil -setreg ca\ValidityPeriod "Years" and then press ENTER.

d. Close the command prompt.

12. Restart Certificate Services from the Certification Authority console and then close the console.

a. Switch to the Certification Authority console.

b. In the console tree, right-click DomainCA, click All Tasks, and then click Stop Service.

c. In the console tree, right-click DomainCA, click All Tasks, and then click Start Service.


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

Module 4: Managing a Public Key Infrastructure

Module 4: Managing a Public Key Infrastructure iii

Instructor Notes Managing a Public Key Infrastructure (PKI) means managing certificates and 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 required to perform typical CA and certificate management tasks, and how to 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.




! Read all of the materials for this module. ! 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, under Additional Reading on the Web page on the Student Materials compact disc.


Required materials

Important

Preparation tasks

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.


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.

Explain how role-based administration can be used to organize CA 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.

Remind students that only members of the local Administrators security group on a CA can enable and disable role separation. Emphasize that they must restart Certificate Services to enforce the Role Separation configuration.

Based on what students have learned thus far, ask them to list some guidelines 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.

Consider demonstrating how to define a certificate manager for the instructor�s BridgeCA. Be sure to follow the guideline for assigning Issue and Manage Certificates permission to users or domain local groups.

Ensure that students understand which certificate management tasks are included in the certificate manager role.

Emphasize that certificate manager restrictions are defined based on group 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.

PKI Management Tasks

Common Criteria Roles in PKI Management

How to Enable and Disable Role Separation

Guidelines for Enabling Role Separation

How to Add a Certificate Manager

Certificate Manager Tasks

Certificate Manager Restrictions

Module 4: Managing a Public Key Infrastructure v

The Common Criteria Certificate Manager role does not perform all certificate 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.

Discuss these guidelines with the class. Ask students for feedback about the 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.

Consider demonstrating how to add a CA administrator in the Certification 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.

Review the CA management tasks and the tasks that administrators perform in each Common Criteria role.

Explain to students that they renew a certification authority when there is a 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.

Discuss the certificate-related events that can be audited. Discuss how to enable 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.

Review and discuss the guidelines for CA management with students.

Other Certificate Management Tasks

Guidelines for Certificate Management

How to Add a CA Administrator

Who Can Install and Configure a CA?

How to Renew a CA Certificate

How to Audit Certificate Services

Guidelines for Defining 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.

Describe the reasons for implementing disaster recovery and the situations in 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.

Tell students that to perform a complete disaster recovery, they use a recent 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.

Administrators back up the CA private key and public key to a PKCS #12 file 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.

Explain the two methods for backing up a CA: System State backup and 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.

Discuss how the type of restoration varies, depending on whether they are restoring a CA from a System State backup or a manual backup.

Summarize this module by discussing the guidelines on this page. Emphasize to students the importance of creating a disaster recovery plan to ensure that they 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).

Why Implement Disaster Recovery?

What to Document for Disaster Recovery

How to Back Up CA Private and Public Keys

Methods for Backing Up a CA

How to Restore Certificate Services

Guidelines for Planning Disaster Recovery of CAs

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.


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 Public Key Infrastructure.

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.



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

Setup requirement 1

Setup requirement 2

Lab A

Lab B

Module 4: Managing a Public Key Infrastructure 1

Overview


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.

Introduction

Objectives

2 Module 4: Managing a Public Key Infrastructure

Lesson: Introduction to PKI Management


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.

Introduction

Lesson objectives


PKI Management Tasks


Managing a PKI consists of two categories of management tasks: certificate management and CA management.

Managing certificates include the following 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.

Introduction

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

CA management tasks


Common Criteria Roles in PKI Management


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.

The Common Criteria PKI management roles in Microsoft® 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.

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.

Introduction

Common Criteria PKI management roles

Note


How to Enable and Disable Role Separation


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.

You can assign the necessary permissions to manage and CAs on any server 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.

To enforce role separation, at the command prompt, type:

certutil -setreg ca\RoleSeparationEnabled 1

To disable role separation, at the command prompt, type:

certutil -delreg ca\RoleSeparationEnabled

The certutil command is executed only when you restart the Certificate Services on the CA.

Introduction

Criteria for enforcing role separation

Procedure for enforcing role separation

Procedure for disabling role separation

Important


Guidelines for Enabling Role Separation


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.

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.

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.

Introduction

Guidelines

Warning


Lesson: Managing Certificates


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.

Introduction

Lesson objectives


How to Add a Certificate Manager


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.

To add a certificate manager:

1. Open the Certification Authority console. 2. In the console tree, right-click CAName, and then click Properties.

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.

Introduction

Procedure for adding a certificate manager

Note




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.

A user who is assigned Issue and Manage Certificates permission holds the 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.

Introduction



For more information about key archival and recovery, see Module 7, �Configuring Key Archival and Recovery,� in Course 2821, Designing and Managing a Windows Public Key Infrastructure.

Note


Certificate Manager Restrictions


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 restrictions allow a CA administrator to limit certificate 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.

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.

Introduction

Certificate manager restrictions

Warning


Other Certificate Management Tasks


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.

Designing certificate templates is considered a certificate management task. A 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.

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.

Introduction

Certificate template design

CRL publication


Guidelines for Certificate Management


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.

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.

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.

Introduction

Guidelines

Note


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

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.

Note


Lesson: Managing Certification Authorities


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.

Introduction

Lesson objectives


How to Add a CA Administrator


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.

To add a CA administrator:

1. Open the Certification Authority console. 2. In the console tree, right-click CAName, and then click Properties.

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.

Introduction

Procedure for adding a CA administrator

Note


Who Can Install and Configure a CA?


When you implement role separation, only specific roles can perform the CA installation and 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.

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.

Introduction

CA configuration tasks

Warning


How to Renew a CA Certificate


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.

When you renew a CA certificate, you can reuse its existing key pair or generate a new key pair. Never reuse a key pair more than once, because it is 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.

For more information about how renewing a CA with a new key affects certificate revocation and the names of CRLs, see the white paper, Troubleshooting Certificate Status and Revocation, under Additional Reading on the Web page on the Student Materials compact disc.

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.

Introduction

Considerations for renewing a CA certificate

Note


To renew a CA certificate:

1. Log on as a local administrator to the computer that is configured as a CA. 2. Open the Certification Authority console. 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.

Procedure for renewing a CA certificate


How to Audit Certificate Services


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.

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

To enable auditing for Certificate Services:

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

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.

Introduction

Events to audit

Procedure for enabling Certificate Services auditing

Note


To determine which events are audited on a CA:

1. Log on as user that is assigned the Manage auditing and security log user right.

2. Open the Certification Authority console. 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.

Procedure for configuring event auditing


Guidelines for Defining CA Management


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.

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.

Introduction

Guidelines


Lab A: Enabling Role Separation



! Enable and enforce role separation. ! Assign permissions for CA administrators and certificate managers. ! Assign auditing roles.

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.

For more information about enabling role separation in a Windows Server 2003 PKI, see the white paper, Windows Server 2003 PKI Operations Guide, under Additional Reading on the Web page on the Student Materials compact disc.

Objectives

Note

Prerequisites




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 administrative account for your domain, and then open the Certification Authority console.

a. Log on to the domain controller by using the following account information:


• Password: Password (where Password is the password assigned to your administrative account)


b. Click Start, click Administrative Tools, and then click Certification Authority.

2. Display the current permission assignments for DomainCA.

a. In the Certification Authority console, in the console tree, right-click DomainCA, and then click Properties.

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 the Manage CA permission.

a. In the DomainCA Properties dialog box, click Add.

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 group the Issue and Manage Certificates permission.

a. In the DomainCA Properties dialog box, click Add.

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

c. In the Multiple Names Found dialog box, in the Matching names list, select CertAdmins, and then click OK.

d. In the Select Users, Computers, or Groups dialog box, ensure that 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 are assigned to the Administrators, Domain Admins, and Enterprise Admins groups.

a. In the DomainCA Properties dialog box, in the Group or user names list, select Administrators, and then click Remove.

b. In the DomainCA Properties dialog box, in the Group or user names list, select Domain Admins, and then click Remove.

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 running the C:\moc\2821\labfiles\ module4\rolesep.cmd and then log off the network.

a. At a command prompt, type C: and then press ENTER.

b. At the command prompt, type cd \moc\2821\labfiles\module4 and then press ENTER.

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 administrator for your enterprise CA.

" Log on to the member server by using the following account information:

• User name: CAAdmin2



2. Open the Certification Authority console focused on the enterprise CA for your domain.


b. In the Microsoft Certificate Services message box, click OK.

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 account the Issue and Manage Certificates permission for the enterprise CA.

a. In the console tree, right-click DomainCA, and then click Properties.

b. In the DomainCA Properties dialog box, on the Security tab, click Add.

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 restrictions so that the CertAdmins group cannot manage certificates for the FinanceDept global group.

a. In the DomainCA Properties dialog box, on the Certificate Managers Restrictions tab, click Restrict certificate managers.

b. In the Available certificate managers drop-down list, select Domain\CertAdmins.

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 restrictions so that the Finance1 user account can only manage certificates that are issued to the FinanceDept group.

a. In the Available certificate managers drop-down list, select Domain\Finance1.

b. On the Certificate Managers Restrictions tab, in the Groups, users, or computers to manage list, select Everyone, and then click Remove.

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.

e. In the Multiple Names Found dialog box, in the Matching names list, 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 Finance department.

" Log on to your computer by using the following credentials:

• User name: Finance1 (on the domain controller) or Finance2 (on the member server)



2. Create the c:\temp folder to 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 to the enterprise CA in your domain by running requestcert.cmd in the C:\moc\2821\labfiles\ module4 folder.


b. In the C:\moc\2821\labfiles\module4 folder, double-click requestcert.cmd.

c. In the Select Certification Authority dialog box, click DomainCA, and then click OK.

d. Close all open windows and then log off the network.

4. Log on as a member of the Accounting department.


• User name: Accounting1 (on the domain controller) or Accounting2 (on the member server)


• Domain: Domain

5. Submit a certificate request to the enterprise CA in your domain by running requestcert.cmd in the C:\moc\2821\labfiles\ module4 folder.


b. In the C:\moc\2821\labfiles\module4 folder, double-click requestcert.cmd.

c. In the Select Certification Authority dialog box, click DomainCA, 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.



1. Log on as a member of the CAAdmins group.


• User name: CAAdmin1 (at the domain controller) or CAAdmin2 (at the member server)



2. Open the Certification Authority console.

" Click Start, click Administrative Tools, and then click Certification 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 Authority console to manage the enterprise CA on the domain controller.

a. In the Microsoft Certificate Services message box, click OK.

b. In the console tree, right-click Certification Authority, and then click Retarget Certification Authority.

c. In the Certification Authority dialog box, click Another computer, and then click Browse.

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 DomainCA Properties 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 the DomainCA Properties dialog box.

" In the DomainCA Properties dialog box, click the Auditing tab.

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

a. In the DomainCA Properties dialog box, click Cancel.

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 update CRL or delta CRL.

a. In the Revoked Certificates Properties dialog box, click Cancel.

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 certificate issued to Domain\Finance1.

a. In the Publish CRL dialog box, click Cancel.

b. In the console tree, click Issued Certificates.

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 Authority console and log off the network.

a. Close the Certification Authority console.

b. Close all open windows and then log off.


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 CertAdmins group.

" Log on to your computer with the following credentials:





" Click Start, click Administrative Tools, and then click Certification Authority.

When you work on the member server in your domain, an error will appear, information you that Certificate Services is not an installed service. You must retarget the console to the domain controller.


3. Retarget the Certification Authority console to manage the enterprise CA on the domain controller.






Important: Perform the next procedure on both computers in your domain

4. View the Security tab of the DomainCA Properties 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 properties.

a. In the DomainCA Properties dialog box, click Cancel.

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 update CRL or delta CRL.

a. In the Revoked Certificates Properties dialog box, click Cancel.

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 certificate issued to Domain\Finance1 or Domain\Finance2.

a. In the console tree, click Issued Certificates.

b. In the details pane, expand Requester Name, right-click the certificate specified below, point to All Tasks, and then click Revoke 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 certificate issued to Domain\Accounting1 or Domain\Accounting2.

a. In the Microsoft Certificate Services dialog box, click OK.

b. In the console tree, click Issued Certificates.

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 Authority console and log 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 administrative account for your domain.

" Ensure that you are logged on with the following credentials:


• Password: Password (where Password is the password assigned to your administrative account).


2. View the User Rights Assignment policy in the Domain Controller Security Policy.

a. Click Start, point to Administrative Tools, and then click Domain Controller Security Policy.

b. In the console tree, expand Local Policies, and then click User Rights 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 group the Manage auditing and security log user right.

a. In the Manage auditing and security log Properties dialog box, click Add User or Group.

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 auditing for object access.

a. In the console tree, click Audit policy.

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 settings and the log off.

a. At a command prompt, type gpupdate /force and then press ENTER.

b. Close the command prompt.

c. Close all open windows and then log off.


6. Log on as a member of the Auditors group for your domain.

" Log on to the member server with the following account information:

• User name: Auditor2


• Domain: Domain


(continued)


7. Open the Certification Authority console so that it manages the enterprise CA for your domain.







8. In the properties of the DomainCA, enable all auditing events.


b. In the DomainCA Properties dialog box, on the Auditing tab, in the 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


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.

Introduction

Lesson objectives


Why Implement Disaster Recovery?


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.

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 includes preparing for system problems and collecting 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.

Introduction

Important

Disaster recovery for CAs


In your disaster recovery planning, ensure that you plan for CA restoration. The 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.

Disaster recovery planning


What to Document for Disaster Recovery


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.

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.

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.

Introduction

Naming

Tip


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.

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.

Database paths

Miscellaneous


How to Back Up CA Private and Public Keys


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.

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.

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.

To export the CA certificate and associated private key to a PKCS #12 file:

1. Ensure that you are logged on as a CA administrator. 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.

Introduction

Note

Software CSPs

Procedure for backing up private and public keys when using software CSPs


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.

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.

Note

Hardware CSPs


Methods for Backing Up a CA


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.

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.

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.

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.

Introduction

System State backup

Manual backup

Note


How to Restore Certificate Services


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.

To restore from a System State backup, start the computer that hosts Certificate 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.

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

Introduction

Restoring from a System State backup

Procedure to restore Certificate Services from a System State backup


If Certificate Services is installed on a domain controller, you must restart the computer in Directory Services Restore Mode.

You can also restore Certificate Services by using the Certificate Services 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. To restore Certificate Services 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.

Note

Restoring from a manual backup

Procedure to restore from a manual backup


Guidelines for Planning Disaster Recovery of CAs


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.

Introduction


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.

Objectives

Note

Prerequisites


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.




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 using your domain administrator account.

" Log on to the member server with the following account information:


• Password: Password (where Password is the password that is assigned to your administrative account)


2. Create an MMC with Group Policy Object Editor with the Default Domain Controllers Policy loaded.

a. Click Start, click Run, type mmc, and then click OK.



d. In the Add Standalone Snap-in dialog box, in the Available 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 Assignment policy for Domain Controller Security Policy.

a. In the console tree, expand Default Domain Controllers Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click User Rights 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 Back up files and directories user right in Domain Controller Security Policy.

a. In the Back up files and directories Properties dialog box, click OK.

b. In the details pane, double-click Restore files and directories.

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 Manage auditing and security log user right in Domain Controller Security Policy.

a. In the Restore files and directories Properties dialog box, click OK.

b. 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 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 log off the network.

a. In the Manage auditing and security log Properties dialog box, click 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 Backup Operators group.

" Log on to the domain controller with the following account information:

• User name: Backup1



2. Perform a manual backup of the CA database and private key by using the certutil �f �backup c:\temp command.


b. At the command prompt, type certutil �f �backup c:\temp and then press ENTER.

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 C:\temp folder.

" Open the 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 backup of the enterprise CA and save the backup file as C:\Temp\SystemState.bkf.

a. Close the C:\temp folder.

b. Click Start, point to All Programs, point to Accessories, point to System Tools, and then click Backup.

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, and then click Next.

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 administrative account for your domain.

" Log on to the domain controller by using the following account information:




2. Remove the private key for the Subordinate Certification Authority certificate from the local machine store, and then delete the certificate.

a. On the desktop, open the Certificate Management console.

b. In the console tree, expand Certificates (Local Computer), expand Personal, and then click Certificates.

c. In the details pane, right-click Subordinate Certification Authority, 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, and then click Next.

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 administrative account for your domain.

" Log on to the member server by using the following account information:

• User name: CAadmin2



4. Open the Certification Authority console with the console connected to the enterprise CA in your domain.





e. In the Select Certification Authority dialog box, click DomainCA, and then click OK.


5. Restart Certificate Services in the Certification Authority console.

a. In the console tree, right-click DomainCA, point to All Tasks, and then click Stop Service.

b. In the console tree, right-click DomainCA, point to All Tasks, and then click Start Service.

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 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 using your administrative account for your domain.

" Ensure you are logged on to the domain controller with the following account information:




2. Remove the Windows Server 2003 compact disc from the CD-ROM drive and restart the domain controller with the shutdown event tracker reason of Security Issue.

a. If the Windows Server 2003 compact disc is in the CD-ROM drive, remove the compact disc from the CD-ROM drive.

b. Click Start, and then click Shut Down.

c. In the Shut Down Windows dialog box, in the What do you want the computer to do? drop-down list, select Restart.

d. In the Option drop-down list, select Security Issue, and then click OK.

3. Restart the domain controller in Directory Services Restore Mode.

a. When the computer restarts, press F8 to display the Windows Advanced Options menu.

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 controller as Administrator with a password of P@ssw0rd.

a. Log on to the domain controller by using the following account information:



b. In the Desktop message box, click OK.

5. Restore the System State backup stored in the C:\temp\Systemstate.bkf file.

a. Open the C:\temp folder.

b. In the C:\temp folder, double-click Systemstate.bkf.

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 using your administrative account for your domain.

" Ensure you are logged on to the member server by using the following account information:



• Domain: Domain


(continued)


7. After the domain controller restarts, ensure that you can start Certificate Services successfully on the enterprise CA.

a. Wait until the domain controller restarts.

b. Open the Certification Authority console.

c. In the console tree, right-click DomainCA, and then click Refresh.

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.



b. Close all open windows and log off the network.

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

Module 5: Configuring Certificate Templates

Module 5: Configuring Certificate Templates iii

Instructor Notes Certificate templates are rules or profiles that define the content of certificates 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 module introduces students to certificate templates and how to design certificate 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.

To teach this module, you need Microsoft PowerPoint® file 2821A_05.ppt.



! Read all of the materials for this module. ! 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.


Required materials

Important

Preparation tasks

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.


Give a brief introduction of certificate templates and their purpose. Emphasize 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.

Explain the differences between version 1 and version 2 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.

Explain that certificate templates can be categorized based on who they are 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 Windows Server 2003, under Additional Reading on the Web page on the Student Materials compact disc.

Explain which groups have the permissions to create and modify certificate 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 certificate templates.

Consider reviewing the DelegateTemplates.cmd batch file (located in C:\Moc\2821\Labfiles\Module5) to describe what permissions are assigned to each certificate template.

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.

What Are Certificate Templates?

Version 1 and Version 2 Certificate Templates

Categories of Default Certificate Templates

Delegation of Certificate Template Management

Lab A

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. This section describes the instructional methods for teaching each topic in this lesson.

Spend time describing how the validity period and renewal period settings work in a certificate template. Describe how the ValidityPeriodUnits and 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.

Focus on which criteria are met by the four certificate purposes. If you have the 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.

Do not spend a lot of time at this point on autoenrollment. Instead, emphasize the settings that must be enabled in the certificate template to enable autoenrollment. Focus on the Request Handling tab and the Permissions tab settings.

Use the screen shot on the slide to explain the content on the page. Emphasize 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.

Show the cryptographic service providers (CSPs) dialog box when discussing this page. The CSPs dialog box is accessible from the Request Handling tab of a certificate template.

Be sure that students understand the difference between application policies and certificate policies. This topic is very important and is a foundation for qualified subordination, which is discussed in Module 8, �Configuring Trust Between Organizations,� in Course 2821, Designing and Managing a Windows Public Key Infrastructure.

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.

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.

Guidelines for Determining Validity and Renewal Periods

Criteria for Selecting a Certificate Purpose

Guidelines for Choosing an Enrollment Method

Subject Name Requirements

Considerations for Choosing a CSP

Other Policies to Configure in a Certificate Template

Raise Issuance Security

Lab B

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.


Do not go beyond describing the available certificate template permissions. Emphasize that the Autoenroll permission is only available for version 2 certificate templates.

Review each of the guidelines for certificate template permissions. Mention that the Authenticated Users group is assigned Read permissions by default, so you 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.

Best practices require that a certificate template be published at two or more CAs in the CA hierarchy. Discuss how sites also play a part in deciding where 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.


Compare and contrast the two methods presented. Give examples of when you 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.

To add to this topic, ask student to provide other examples where modification of a template would be the best design decision.

To add to this topic, show how Microsoft has designed the Domain Controller Authentication certificate template to supersede the Domain Controller 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.

Consider showing the procedure in the Certificate Templates console in MMC.

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.

Certificate Template Permissions

Guidelines for Defining Certificate Template Permissions

Guidelines for Publishing a Certificate Template

Methods of Updating a Certificate Template

Guidelines for Modifying a Certificate Template

Guidelines for Superseding a Certificate Template

How to Supersede a Certificate Template Lab C

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.


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 Public Key Infrastructure.

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.

Setup requirement 1

Setup requirement 2

viii Module 5: Configuring Certificate Templates

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.



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

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

certificate templates.

Setup requirement 3

Lab A

Lab B

Lab C

Module 5: Configuring Certificate Templates 1

Overview


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

Introduction

Objectives

2 Module 5: Configuring Certificate Templates

Lesson: Introduction to Certificate Templates


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.

Introduction

Lesson objectives


What Are Certificate Templates?


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.

Only enterprise CAs can issue certificates based on certificate templates. When 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.

Introduction

Certificate template environment


Version 1 and Version 2 Certificate Templates


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.

When the first enterprise CA is installed in the forest, version 1 templates are 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.

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.

Windows 2000 Server family servers and Windows Server 2003 family servers can issue version 1 templates. Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition issue version 2 templates.

Introduction

Certificate template versions

Note

Who can issue version 1 and version 2 templates?


Categories of Default Certificate Templates


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.

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.

The following table describes the single-function certificate 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.

Introduction

Categories of templates

Single function templates for users


The following table describes the multiple function certificate templates for 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.

The following table describes the single function templates for computers in 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.

The following table describes multiple function certificate templates for 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.

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 Reading on the Web page on the Student Materials compact disc.

Multiple function templates for users

Single function templates for computers

Multiple function templates for computers

Note


Delegation of Certificate Template Management


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.

If you delegate certificate template management, including the ability to 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.

Individual certificate templates do not inherit the permissions that are assigned to the Certificate Templates container.

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.

Introduction

Delegating template management

Note

Tools for delegation


Lab A: Delegating Certificate Template Management



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


Objectives

Note



! 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

For more information about delegating the management of certificate templates, 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.

Prerequisites




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 domain administrative account.



• Password: Password (where Password is the password defined for your administrative account)


2. Open the Active Directory Sites and Services console and browse to the OID container.

a. On the Start menu, click Administrative Tools, and then click Active Directory Sites and Services.

b. On the View menu, click Show Services node.

c. In the console tree, expand Services, expand Public Key Services, and then click OID.

3. Modify the permissions of the OID container to grant the CertTmplAdmins global group Full Control permissions.

a. In the console tree, right-click OID, and then click Properties.

b. In the OID Properties dialog box, on the Security tab, click Add.

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

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 permissions to the CertTmplAdmins global group for the Certificate Templates container.

a. In the console tree, right-click Certificate Templates, and then click Delegate Control.

b. In the Delegation of Control Wizard, click Next.

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.

e. In the Multiple Names Found dialog box, in the Matching names list, 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 appears, and then click OK.

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, and then click Next.

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 Enterprise Admins group.

" Log on with the following credentials:





(continued)


6. In the C:\moc\2821\labfiles\ module5 folder, modify delegatetemplates.cmd to reflect your forest name and domain name.

a. Open the C:\moc\2821\labfiles\module5 folder.

b. Right-click delegatetemplates.cmd, and then click Properties.

c. In the delegatetemplates.cmd Properties dialog box, ensure that the 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 delegatetemplates.cmd command file and then log off the network.

a. In the C:\moc\2821\labfiles\module5 window, double-click delegatetemplates.cmd.

The output of the command file will show the addition of each 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


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.

For more information about certificate template design, see 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.

Introduction

Lesson objectives

Note


Guidelines for Determining Validity and Renewal Periods


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.

Introduction


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.

Guidelines


Criteria for Selecting a Certificate Purpose


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.

The following table briefly describes the certificate purposes.

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

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.

When you define certificate purpose in a certificate template, use the following 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.

Introduction

Criteria for selecting certificate purpose

Note

Guidelines for selecting the certificate purpose


Guidelines for Choosing an Enrollment Method


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 Settings

Supports only Windows XP and Windows Server 2003 family 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 Request Settings

Supports Windows 2000, Windows XP, and Windows Server 2003 family operating systems.

Supports only version 1 certificate templates for computers.

Introduction


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.

Guidelines


Subject Name Requirements


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.

Define the format of the subject name when you define a certificate template. 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.

Introduction

Configuring the subject name


In addition to the subject name, you can include additional names that reference 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.

Usually, a subject cannot request a certificate that uses a nonmatching subject name. For example, [email protected] would not be allowed to request a certificate with a subject name of [email protected].

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.

Use the following guidelines when defining subject name requirements in a certificate template:

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

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.

Alternate subject name options

Requesting certificates for a non-matching certificate name

Guidelines for defining subject name requirements

Note


Considerations for Choosing a CSP


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.

For each certificate template, you can designate one or more CSPs that are 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.

Introduction

Considerations for choosing CSPs


Other Policies to Configure in a Certificate Template


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

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.

Introduction

Application policies

Certificate policies

Note


The following table describes the three default certificate policy OIDs included 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.

The low assurance, medium assurance, and high assurance OIDs are unique for each Windows Active Directory forest.

Default certificate policy OIDs

Note


Raise Issuance Security


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.

On the Issuance Requirements tab of a certificate template, you can enable 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.

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.

Introduction

Certificate Manager Approval

Signing Requests


Lab B: Designing a Certificate Template


After completing this lab, you will be able to design a custom certificate template for code signing.


Before working on this lab, you must have knowledge about creating and modifying version 2 certificate templates.

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.

Objective

Note

Prerequisites

Scenario


For more information about configuring a certificate template, see 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.




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 on to the domain as a Certificate Template administrator.

" Log on to your computer with the following information:

• User name: Template1 (on the domain controller) or Template2 (on the member server)



2. Open the Certificate Templates console.

" Click Start, click Run, type Certtmpl.msc and then click OK.


1. Is there an existing certificate template that allows code signing? If so, what 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. ____________________________________________________________

____________________________________________________________

____________________________________________________________

Analyze existing certificate templates


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.

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 Directory

Disabled

Do not automatically reenroll if a duplicate certificate exists in Active Directory

Disabled

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.

Attribute Your recommended design Purpose Signature

Allow private key to be exported

Disabled

Minimum key size 1024

Do the following when the subject is enrolled and when the private key associated with this certificate is used

Enroll subject without requiring any user input

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

____________________________________________________________

____________________________________________________________

Scenario


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.

Attribute Your recommended design CA certificate manager approval Enabled

This number of authorized signatures

Disabled

Require the following for reenrollment

Same criteria as for enrollment

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


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.

Introduction

Lesson objectives


Certificate Template Permissions


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 certificate template.

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 certificate template.

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

Introduction

Available permissions


Guidelines for Defining Certificate Template Permissions


You must define the permissions for each certificate template to ensure that only authorized users, computers, or groups can obtain certificates based on a certificate template.

Use the following guidelines for assigning 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.

Introduction

Guidelines for defining certificate template permissions


Guidelines for Publishing a Certificate Template


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.

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.

Introduction

Guidelines


Lesson: Managing Changes in a Certificate Template


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.

Introduction

Lesson objectives


Methods of Updating a Certificate Template


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.

You can modify an existing certificate template by:

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

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.

Introduction

Methods to update a certificate template

Note


Guidelines for Modifying a Certificate Template


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.

Consider modifying an existing certificate template when:

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

Introduction

Guidelines for modifying a certificate template


Guidelines for Superseding a Certificate Template


When superceding, the new certificate template may supersede both existing version 1 or version 2 certificate templates.

Supersede an existing template when you want to:

! 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 certificate template.

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

You can force the application of the updated certificate template by forcing all certificate holders to re-enroll the updated certificate template.

Introduction

Guidelines for superseding a certificate template

Note


How to Supersede a Certificate Template


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.

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.

Introduction

How to supersede


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 CertTmplAdmins global group.

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

Objectives

Note

Prerequisites


For more information about creating certificate templates, 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.




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.









a. Click Start, click Run, type Certtmpl.msc and then click OK.

b. In the Certificate Templates dialog box, click OK.

3. Create a new certificate template named ComputerUser based on the User certificate template.

a. In the Certificate Templates console, in the details pane, right-click User, and then click Duplicate Template.

b. In the Properties of New Template dialog box, on the General tab, in 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 ComputerUser certificate template, define the validity period as 3 Years.

a. In the details pane, double-click the ComputerUser certificate template.

b. On the General tab, define the validity period as 3 Years.

c. Click Apply.


(continued)


5. On the Request Handling tab, define the minimum key size as 2048 bytes.

a. On the Request Handling tab, define the minimum key size as 2048 bytes.

b. Click Apply.

6. On the Security tab, view the current settings.

" Click the Security tab, and then view the 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 the ComputerUser certificate template, perform the following steps:

• Select Build from this Active Directory information.

• Select Common name.

• Select the Include e-mail name in subject name check box.

a. On the Subject Name tab, select Build from this Active Directory information.

b. In the Subject name format drop-down list, select Common name.

c. Select the Include e-mail name in subject name check box.

d. Leave all other settings as the default settings.

e. Click Apply.


(continued)


8. On the Extensions tab, remove the Encrypting File System application policy.

a. On the Extensions tab, select Application Policies, and then click Edit.

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.


a. Close the Certificate Templates console.

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 enterprise subordinate CA.

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.





• User name: CAadmin1 (on the domain controller) or CAadmin2 (on the member server)




" On the Start menu, click Administrative Tools, and then click Certification Authority.

If you are working on the member server in your domain, an error message appears, stating that Certificate Services is not an installed service. You must retarget the console to the domain controller.


3. Retarget the Certification Authority console to manage the enterprise CA in your domain.







(continued)



4. Configure the DomainCA to issue the ComputerUser certificates. Close all open windows and log off.

a. In the console tree, expand Certification Authority, expand DomainCA, and then click Certificate Templates.

b. In the console tree, right-click Certificate Templates, click New, and 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.



1. Ensure that you are logged with your domain administrative account.



• Password: Password (where Password is the password defined for your administrative account).

• Domain: Domain (where Domain is the NetBIOS name of your domain).

2. Connect to http://WebServer/certsrv and request a ComputerUser certificate by performing the following steps:

• Click Request a certificate.

• Click advanced certificate request.

• Click Create and Submit a request to this CA.

• Choose the ComputerUser certificate template.

• Ensure the key size is 2048 bytes.

• Type the friendly name: ComputerUser

• Click Yes in the Potential Scripting Violation dialog box.

• Install the issued certificate.


b. If the Internet Explorer dialog box appears, click In the future, do not show this message, and then click OK.

c. In the Address bar, type http://WebServer/certsrv (where WebServer is the fully qualified domain name of your domain controller) and then press ENTER.

d. On the Welcome page, click Request a certificate.

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 ComputerUser (where Computer is the NetBIOS name of your computer).

h. On the Advanced Certificate Request page, in the Key Options section, ensure that the key size is 2048.

i. On the Advanced Certificate Request page, in the Friendly Name box, type ComputerUser

j. On the Advanced Certificate Request page, scroll to the bottom of the page, and then click Submit.

k. In the Potential Scripting Violation dialog box regarding the Web site requesting a new certificate on your behalf, click Yes.

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 newly issued ComputerUser certificate.

a. On the desktop, double-click Certificate Management.

b. In the Certificate Management console, in the console tree, expand 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.


a. Click OK.

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 the domain as a Certificate Template administrator.


• User name: Template2



2. Create a new certificate template named SupersededUser based on one of the existing ComputerUser certificate templates.



c. In the details pane, right-click ComputerUser (where Computer is the NetBIOS name of your computer), and then click Duplicate Template.

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 unavailable in the SupersededUser certificate template.

a. In the details pane, double-click SupersededUser.

b. On the Request Handling tab, clear the Allow private key to be exported check box, and then click Apply.

4. Add the Low assurance issuance policy OID to the certificate template.

a. On the Extensions tab, click Issuance Policies, and then click Edit.

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 SupersededUser certificate template to supersede the two ComputerUser certificate templates.

a. On the Superseded Templates tab, click Add.

b. In the Add Superseded Template dialog box, in the Certificate templates list, click ComputerUser, press CTRL and click PartnerComputerUser (where PartnerComputer is the NetBIOS name 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.









• Domain: Domain

8. Configure the DomainCA to issue the SupersededUser certificate template.

a. On the Start menu, click Administrative Tools, and then click Certification Authority.

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 certificate templates from the list of certificate templates issued by the DomainCA. Close all open windows and log off

a. In the details pane, click ComputerUser, press CTRL and click PartnerComputerUser, right-click the selection, and then click Delete.

b. In the Disable certificate templates dialog box, click Yes.

c. Close the Certification Authority console.


Contents

Overview 1

Lesson: Introduction to Certificate Enrollment 2

Lesson: Enrolling Certificates Manually 9

Lesson: Autoenrolling Certificates 14

Lab A: Enrolling Certificates 23

Module 6: Configuring Certificate Enrollment

Module 6: Configuring Certificate Enrollment iii

Instructor Notes Certificate enrollment is the process of requesting and receiving a certificate from a certification authority (CA). In this module, students will learn about the various methods of enrolling certificates. Students 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. ! Enroll certificates manually. ! Autoenroll certificates. ! Enroll smart card certificates.

To teach this module, you need:

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



! Read all of the materials for this module. ! Complete the practices and lab. ! Review the multimedia presentation Certificate Enrollment. ! Read the white paper, Certificate Autoenrollment in Windows Server 2003.


Required materials

Important

Preparation tasks

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.


The multimedia files are installed on the instructor computer. To open a 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.

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.

Microsoft Windows Server� 2003 introduces several mechanisms for securing 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.

Review the guidelines presented in the slide. Enforce that client computers running Microsoft Windows® 2000 only support autoenrollment of computer 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.


The Certificate Enrollment Web site is best used for requests by either users or computers that do not have user or computer accounts in your organization�s 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.

Multimedia: Certificate Enrollment

Enrollment Methods

Guidelines for Securing the Enrollment Process

Considerations for Choosing an Enrollment Method

How to Enroll Certificates Using a Web-based Interface

Module 6: Configuring Certificate Enrollment v

The Certificates console is only available for requesting certificates from an enterprise CA. The MMC console allows you to install certificates for user accounts, computer accounts, or service accounts.

Consider demonstrating the Certificate Enrollment Wizard.

Certreq.exe was used to request certificates in Lab B: Backing Up and 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.


Do not spend a large amount of time comparing the two methods on this page. 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

Consider demonstrating how to add certificate templates for deployment by using automatic certificate request settings. During the demonstration, show that only version 1 certificate templates that are issued to computers are available for selection.

The first step in designing automatic certificate enrollment by using Autoenrollment settings is configuring a certificate template to support 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.

How to Request Certificates Using the MMC Wizard

Request Certificates Using Certreq.exe

Certificate Autoenrollment

How to Enable Autoenrollment Using Automatic Certificate Request Settings

Enable Autoenrollment in the Version 2 Certificate Template

vi Module 6: Configuring Certificate Enrollment

Share with the students that the Autoenrollment Settings Group Policy is available in a Windows Server 2003 forest and a Windows 2000 forest, as long 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.

Use the chart on the slide to compare and contrast the two autoenrollment processes. Ensure that the students are clear on when to choose each 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.

How to Enable Autoenrollment Settings in Group Policy

Considerations for Implementing Autoenrollment

Module 6: Configuring Certificate Enrollment vii

Lab Setup 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 Public Key Infrastructure.

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.

The ability to create and modify certificate templates is delegated to the CertTmplAdmins global group.

! Complete Lab A in Module 4, �Managing a Public Key Infrastructure,� in Course 2821.



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

Setup requirement 1

Setup requirement 2

Setup requirement 3

Lab A

Module 6: Configuring Certificate Enrollment 1

Overview


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.

Introduction

Objectives

2 Module 6: Configuring Certificate Enrollment

Lesson: Introduction to Certificate Enrollment


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

Windows Server� 2003 public key infrastructure (PKI). ! List the best practices for securing the enrollment process. ! Select an appropriate enrollment method for a security principal.

Introduction

Lesson objectives


Multimedia: Certificate Enrollment


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.

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

File location

Key points


Enrollment Methods


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.

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.

Introduction

Enrollment methods


! 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


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.

Secure the enrollment process by limiting the security groups that are assigned 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. Keep the certificate request pending until a certificate manager validates the 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.

Introduction

Certificate template permissions

Certificate manager approval


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

For autoenrollment to be successful, you can only require one authorized signature. More than one signature disables autoenrollment.

Registration authority

Note


Considerations for Choosing an Enrollment Method


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.

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.

Introduction

Considerations


Lesson: Enrolling Certificates Manually


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.

Introduction

Lesson objectives


How to Enroll Certificates Using a Web-based Interface


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.

The Web Enrollment Web site is located at http://ServerName/certsrv. To 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).

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.

Introduction

Procedure for using a Web-based interface

Important


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


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

To request a certificate by using the Certificates console:

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.

Introduction

Procedure for requesting a certificate


Request Certificates Using Certreq.exe


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.

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.

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.

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.

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.

When performing qualified subordination between two CAs in two separate CA hierarchies, the certreq �policy command constructs the qualified 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.

Introduction

Submit a request

Retrieve a request

Create a new request

Accept a new request

Create Cross Certification Authority certificates


Lesson: Autoenrolling Certificates


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.

Introduction

Lesson objectives


Certificate Autoenrollment


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.

Automatic enrollment of user certificates provides a quick and simple way to 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.

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.

Introduction

Benefits of autoenrollment

Autoenrollment methods


How to Enable Autoenrollment Using Automatic Certificate Request Settings


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.

To enable automatic 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.

Introduction

Enabling automatic certificate request settings


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.

Note


Enable Autoenrollment in the Version 2 Certificate Template


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 certificate template.

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.

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.

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.

Introduction

Request Handling

Note

Important


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.

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.

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.

Issuance Requirements

Permissions

Note


How to Enable Autoenrollment Settings in Group Policy


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.

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

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.

Introduction

Enabling Autoenrollment Settings

Note


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.

The Autoenrollment Settings are applied the next time the GPO is applied to the 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.

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.

Applying the Group Policy settings

Note


Considerations for Implementing Autoenrollment


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.

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 certificate templates.

Introduction

Considerations


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.

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.





! Knowledge about certificate enrollment methods for standalone and enterprise CAs.

! Knowledge about implementing automatic enrollment for user and computer certificates.

Objectives

Note

Prerequisites


For more information about enrolling certificates, read the white paper, Certificate Autoenrollment in Windows Server 2003, under Additional Reading on the Web page on the Student Materials compact disc.




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.

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.

Scenario


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

1. In the following table, indicate what enrollment methods are available for

each of the PKI-related projects. Scenario

Web-based

Certificate Enrollment

Wizard

Automatic Certificate

Request Settings (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. ____________________________________________________________

____________________________________________________________

____________________________________________________________

Questions


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 on to the domain as a CA administrator.

$ Log on to your computer by using the following information:




2. Configure the DomainCA to publish the IPSEC certificate template. Once completed, close all open 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 on to the domain as a local administrator of your computer.




• Domain: Domain


(continued)


4. In the Certificate Management console, view the certificates that are currently issued to your computer account.

a. On the desktop, double-click Certificate Management.

b. In the console tree, expand Certificates (Local Computer)¸ expand Personal, and then click Certificates.

Not all computers have certificates installed in the local computer 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 Wizard to request an IPSec certificate with the friendly name IPSec Authentication for your computer account.

a. In the console tree, right-click the Personal folder, point to All Tasks, and then click Request New Certificate.

b. In the Certificate Request Wizard, click Next.

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 newly issued IPSec certificate.

a. In the console tree, expand Certificate (Local Computer), expand Personal, and then click Certificates.

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.


a. Save any changes, and then close all open windows.

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 console, create a new certificate template named AutoenrollComputer based on the User Signature Only certificate template. Define the following attributes:

• Template display name: AutoComputer

• Validity period: 2 years

a. Log on to your computer with the following information:



• Domain: Domain (where Domain is the NetBIOS name of your Active Directory domain)

b. Click Start, click Run, type Certtmpl.msc and then click OK.

c. In the details pane, right-click User Signature Only, and then click 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 during enrollment option in the AutoComputer certificate template.

a. In the details pane, double-click AutoComputer.

b. On the Request Handling tab, click Prompt the user during enrollment.

c. Click Apply.


(continued)


3. Modify the permissions for the AutoComputer certificate template:

• Remove Domain Users from the discretionary access control list (DACL).

• Add the AutoenrollUsers group and assign it Read, Enroll, and Autoenroll permissions.

a. On the Security tab, in the Group or user names box, select Domain Users¸ and then click Remove.

b. On the Security tab, click Add.

c. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type Auto and then click Check Names.

d. In the Select Users, Computers, or Groups dialog box, ensure that AutoenrollUsers appears in the Enter the object names to select box, and then click OK.

e. On the Security tab, assign the AutoenrollUsers group Read, Enroll 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 your administrative account.

$ Log on to the domain by using the following credentials:

• Logon name: CAadmin2



2. Open the Certification Authority console and retarget the console to the domain controller in your domain.





e. In the Select Certification Authority dialog box, click DomainCA, and then click OK.


3. In the Certification Authority console, configure DomainCA to issue AutoComputer and AutoPartnerComputer and then log off.

a. In the console tree, expand DomainCA, and then click Certificate Templates.

b. Right-click Certificate Templates, click New, and then click Certificate Template to Issue.

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 your domain administrative account.

$ Log on to the domain by using the following credentials:

• Logon name: Student1

• Password: Password (where Password is the password defined for your administrative account

• Domain: Domain

5. In Active Directory Users and Computers, create a new GPO named Autoenrollment and link the GPO to the Module06 organizational unit. In the Autoenrollment GPO, enable the following autoenrollment options:

• Enroll certificates automatically

• Renew expired certificates, update pending certificates, and remove revoked certificates

• Update certificates that use certificate templates

Close all open windows and log off the network when complete

a. On the Start menu, click Administrative Tools, and then click Active Directory Users and Computers.

b. In the console tree, expand Domain.msft, expand Labs, and then click Module06.

c. Right-click Module06, and then click Properties.

d. In the Module06 Properties dialog box, on the Group Policy tab, click New.

e. In the name box of the new Group Policy object, type Autoenrollment and then click Edit.

f. In Group Policy Object Editor, expand User Configuration, expand Windows Settings, expand Security Settings, and then click Public Key Policies.

g. In the details pane, double-click Autoenrollment Settings.

h. In the Autoenrollment Settings Properties dialog box, enable the following options:

• Enroll certificates automatically

• Renew expired certificates, update pending certificates, and remove revoked certificates

• Update certificates that use certificate templates

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 AutoenrollUsers group.


• User name: Enroll1 (on the domain controller) or Enroll2 (on the member server)




(continued)


7. Force application of Group Policy by running gpupdate /force.


b. At the command prompt, type gpupdate /force and then press ENTER.


Wait for the Certificate Enrollment ballon to appear in the system tray. It may take 90 seconds to appear.

8. Click the Certificate Enrollment balloon and start the certificate enrollment process.

a. In the system tray, click the Certificate Enrollment balloon.

b. In the Certificate Enrollment dialog box, click Start.

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 console that is connected to the current user (Certmgr.msc).

$ Click Start, click Run, type Certmgr.msc and then click OK.

10. Refresh the personal certificates store in the Certificates � Current User console.

a. In the Certificates � Current User console, in the console tree, expand Certificates � Current User, expand Personal, and then click Certificates.

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 log off of the network.

a. Close the Certificates � Current User console.


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

Module 7: Configuring Key Archival and Recovery

Module 7: Configuring Key Archival and Recovery iii

Instructor Notes This module explains the importance of creating a strategy for data and key recovery. Students learn how Microsoft® Windows® XP and Windows Server� 2003 enhance the capability of data protection and data recovery.


! 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 all of the materials for this module. ! Read the white paper, Key Archival and Management in

Windows Server 2003, under Additional Reading on the Web page on the Student Materials compact disc.

! Complete the practice and the lab.


Required materials

Preparation tasks

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.


The Windows XP and Windows Server 2003 operating systems support key 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.

Focus on how private keys are lost. Many students will be unaware that actions, such as deleting a user profile or reinstalling the operating system, will result in the loss of private key material.

Do not spend a lot of time describing each export and request format. Consider 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.

Focus on which role performs each task and the formats that are used for each task. This information will help students understand when each format is used in the recovery process.

Review each guideline and answer any questions about the guidelines.

Consider asking the students whether their organization�s security policy 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. Ensure that the students know that there is more than one way to export a certificate�s private key. The application that you choose directly affects the export format of the private key. Provide the students with sufficient time to export their private key. If time permits, ask students to export their private key by using Internet Explorer.

Data Recovery and Key Recovery

What Are Key Archival and Key Recovery?

The Export and Request Formats

The Key Recovery Process

Guidelines for Key Archival

Guidelines for Key Recovery

How to Export a Private Key Manually

Practice: Archiving a Private Key Manually

Module 7: Configuring Key Archival and Recovery v

Review each guideline and answer any questions about the guidelines.

Perform the steps of performing a private key recovery. If time permits, ask students to follow the steps and recover the private key that they archived in the 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.

Do not spend a lot of time on this page. It describes the overall process for performing automatic key archival, and each step in the procedure is discussed in the topics that follow.

Consider opening the Certificate Templates console (Certtmpl.msc) and 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.

Use the animation in the slide to describe the round-robin selection of KRAs. Explain that the CA will choose two KRAs from the pool of four KRAs in the example on the slide. Ask the students whether they would consider 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.

Consider opening the Certificate Templates console (Certtmpl.msc) and 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 certificate template.

Focus on the tasks that each role in PKI management performs. Note that it is 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.

If students are not familiar with EFS, show this presentation before students begin the lab. The presentation discusses how EFS encrypts and decrypts files. If necessary, elaborate on the difference between symmetric and asymmetric encryption.


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.

Guidelines for Archiving a Private Key Manually

How to Recover an Archived Private Key Manually

Steps for Performing Automatic Archival of a Private Key

Steps for Designating Key Recovery Agents

How to Enable Key Archival and Configuration Options for a CA

Enable Key Archival in a Certificate Template

How to Recover an Archived Private Key

Multimedia: (Optional) How ESF Works

Lab A

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.


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.

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.

The ability to create and modify certificate templates is delegated to the CertTmplAdmins global group. Complete Lab A in Module 5, �Configuring Certificate Templates,� in Course 2821.

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.

Setup requirement 1

Setup requirement 2

Setup requirement 3

Setup requirement 4

Module 7: Configuring Key Archival and Recovery vii



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

Lab A

Module 7: Configuring Key Archival and Recovery 1

Overview


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® Windows Server� 2003 public key infrastructure (PKI).

! Implement manual key archival and recovery. ! Implement automatic key archival and recovery.

Introduction

Objectives

2 Module 7: Configuring Key Archival and Recovery

Lesson: Introduction to Key Archival and Recovery


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.

Introduction

Lesson objectives


Data Recovery and Key Recovery


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.

Choose data recovery when:

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

Introduction

When to choose data recovery


The disadvantages of data recovery are:

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

Choose key recovery when:

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

The disadvantages of implementing key recovery are:

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

The option to archive private keys is blocked if the certificate purpose is signature or signature and smart card logon.

Disadvantages of data recovery

When to choose key recovery

Disadvantages of key recovery

Note


What Are Key Archival and Key Recovery?


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.

Users can lose their private key because of the following:

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

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.

Introduction

How can users lose a private key?

Note


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.

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.

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.

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.

Key archival

Note

Key recovery

Note


The Export and Request Formats


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.

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.

Introduction

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

Request formats


The Key Recovery Process


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 process consists of the following steps:

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.

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.

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.

Introduction

The key recovery process

Note

Note


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.

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.

Note


Guidelines for Key Archival


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.

When you design key archival for your organization, secure the key 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.

Introduction

Guidelines for key archival


Guidelines for Key Recovery


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.

When you develop your organization�s key recovery process, consider these 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.

Introduction

Guidelines for key recovery


Lesson: Implementing Manual Key Archival and Recovery


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.

Introduction

Lesson objectives


How to Export a Private Key Manually


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.

To manually export a certificate and its associated private key:

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.

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.

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.

Introduction

Exporting keys and certificates

Note

Note


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.

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.

Important


Practice: Archiving a Private Key Manually


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.


To export the certificate and private key:

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.

Introduction

Note

Exporting keys from Certificates console


10. In the File to Export dialog box, in the File Name box, type C:\temp\privexport and then click Next.

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.

Note


Guidelines for Archiving a Private Key Manually


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.

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.

Introduction

Guidelines


How to Recover an Archived Private Key Manually


You can perform a manual recovery of a private key that is archived in a PKCS #12 file.

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.

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.

Introduction

Procedure

Tip


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


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.

Introduction

Lesson objectives


Steps for Performing Automatic Archival of a Private Key


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.

Key escrow is only supported on enterprise CAs running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition.

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.

Introduction

Note

Steps


Steps for Designating Key Recovery Agents


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.

To designate a 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.

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.

Introduction

Steps for designating a KRA

Note


How to Enable a Key Archival and Configuration Options for a CA


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.

If role separation is enforced on a CA, only a CA administrator can add or remove KRAs in the properties of the CA.

To enable a 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.

Introduction

Note

Procedure for enabling a CA for key archival and configuration options


When you designate the number of KRAs, you can designate between one and 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.

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.

Designating the number of KRAs

Note


Enable Key Archival in a Certificate Template


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.

To enable key archival for a certificate template, you must perform the 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.

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.

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.

Introduction

Enabling archival in a certificate template

Note

Note


How to Recover an Archived Private Key


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.

To extract the encrypted private key from the CA database, the certificate 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

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.

Introduction

Certificate manager tasks

Note


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.

The certutil �getkey command also identifies the KRA for the archived private key in its output.

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.

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.

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.

Note

KRA tasks

Note

User tasks


Multimedia: (Optional) How EFS Works


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.

This animation shows how EFS uses both symmetric and asymmetric encryption to encrypt and decrypt data in Windows 2000 and Windows XP.

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.

File Location

Key points

Additional reading


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.

This lab focuses on the concepts in this module and as a result may not 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.

Objectives

Note






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

For more information about configuring key recovery, see the white paper, Key Archival and Management in Windows Server 2003, under Additional Reading on the Web page on the Student Materials compact disc.

Prerequisites




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 certificate template administration account.

" Log on to the domain by using the following credentials:




2. In the Certificate Templates console, view the Issuance Requirement properties of the Key Recovery Agent certificate template.



c. In the details pane, double-click Key Recovery Agent.

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 Recovery Agent certificate template.

a. In the Key Recovery Agent Properties dialog box, on the Security tab, click Advanced.

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 properties of the Key Recovery Agent certificate template to assign the KRAs global group Read and Enroll permissions.

a. On the Security tab, click Add.

b. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type KRAs and then click Check Names.

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 administration account and password.

" Log on to your computer with the following credentials:



• Domain: Domain

6. Publish the Key Recovery Agent certificate template 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 member of the KRAs group.




• Domain: Domain (where Domain is the NetBIOS name of your domain).

2. Request a Key Recovery Agent certificate by using Web-based enrollment, and then log off the network.



c. In Internet Explorer, open the URL http://WebServer/certsrv (where WebServer is the fully qualified domain name of your domain controller).




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 Recovery Agent certificate requests, and then log off the network.

a. On the Start menu, click Administrative Tools, right-click Certification Authority, and then click Run as.

b. In the Run As dialog box, click The following user, and then provide 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)



4. Open the URL http://WebServer/certsrv and click the following:

• View the status of a pending certificate request

• Key Recovery Agent Certificate

• Install this Certificate


b. In Internet Explorer, open the URL http://WebServer/certsrv (where WebServer is the fully qualified domain name of your domain controller).

c. On the Welcome page, click View the status of a pending certificate request.

d. On the View the Status of a Pending Certificate Request page, click Key Recovery Agent Certificate (Date and Time).

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 your CA administrator account.





2. Open the Certification Authority console and perform the following actions:

• Define KRA1 and KRA2 as key recovery agents.

• Define the number of recovery agents to use as 2.


b. In the console tree, right-click DomainCA, and then click Properties.

c. In the DomainCA Properties dialog box, on the Recovery Agents tab, click Archive the key.

d. In the Number of recovery agents to use box, type 2

e. In the DomainCA Properties dialog box, on the Recovery Agents tab, click Add.

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 Authority console.

" Minimize the Certification 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 on using your domain administrative account.

" Ensure that you are logged on to the domain by using the following credentials:

• Logon name: Template2



2. Open the Certificate Management console and create a new certificate template named ArchiveEFS, based on the Basic EFS certificate template.

a. On the Start menu, click Run, type Certtmpl.msc and then click OK.

b. If the Certificate Templates message box appears, click OK.

c. In the details pane, right-click Basic EFS, and then click Duplicate Template.

d. In the Properties of New Template dialog box, in the Template display name box, type ArchiveEFS and then click OK.

3. In the ArchiveEFS certificate template, enable archival of the subject�s encryption private key.

a. In the details pane, double-click ArchiveEFS.

b. In the ArchiveEFS Properties dialog box, on the Request Handling tab, select the Archive subject�s encryption private key check box, and then click OK.





5. Ensure that you are logged on with your domain administrative account.

" Ensure that you are logged on to the domain with the following credentials:



• Domain: Domain


(continued)


6. Configure DomainCA to issue the ArchiveEFS certificate template, and then log off the network.

a. Restore the Certification Authority console.

b. In the console tree, expand DomainCA, and then click Certificate Templates.

c. Right-click Certificate Templates, point to New, and then click Certificate Template to Issue.

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 using your EFS user account with a password of P@ssw0rd.


• User name: EFS1 (at the domain controller) or EFS2 (at the member server)



2. In the Certificates � Current User console, use the Certificate Request Wizard to request an ArchiveEFS certificate with the friendly name of Archive EFS.

a. Click Start, click Run, type Certmgr.msc and then click OK.

b. In the console tree, expand Certificates � Current User, and then click Personal.

c. Right-click Personal, click All Tasks, and then click Request New 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 ArchiveEFS certificate.

a. In the console tree, expand Certificates- Current User, expand 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 Management console.


b. Close the Certificates � Current User console.

5. Create a new folder named C:\EFS. Assign the Users group Modify permission and enable EFS encryption for the folder.

a. On the Start menu, click My Computer.

b. In My Computer, double-click Local Disk (C:).

c. In the C:\ window, create a new folder named EFS.

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, prevent the hiding of known extension types, create a new text document named Secret.txt and type This is a secret! in the document.

a. Open the EFS folder.

b. On the Tools menu, click Folder Options.

c. In the Folder Options dialog box, on the View tab, clear the Hide extensions for known file types check box, and then click OK.

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 Secret.txt file to determine the thumbprint of the certificate that can open the encrypted file.

a. In the C:\EFS folder, right-click Secret.txt, and then click Properties.

b. In the Secret.txt Properties dialog box, on the General tab, click Advanced.

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 C:\EFS\Secret and log off the network.

a. In the Encryption Details for C:\EFS\Secret.txt dialog box, click OK.

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 administrative account.



• Password: Password (where Password is the password that was assigned to your administrative account)


2. In the System folder in Control Panel, delete the EFS1 profile (on the domain controller) or the EFS2 profile (on the member server), and then log off the network.

a. On the Start menu, click Control Panel, and then click System.

b. In the System Properties dialog box, on the Advanced tab, in the User Profiles section, click Settings.

c. In the User Profiles dialog box, under Profiles stored on this computer, select EFS1 (on the domain controller) or EFS2 (on the 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 administrative account.

" Log on by using the following credentials:

• 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 on using your Certificate Manager account.




• Domain: Domain


" On the Start menu, click Administrative Tools, and then click Certification Authority.

If you are working on the member server in your domain, an error appears that states that Certificate Services does not exist as an installed service. You must retarget the console to the domain controller.


7. Retarget the Certification Authority console to manage the enterprise CA in your 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 console, add the Archive Key column to issued certificates.

a. In the console tree, expand DomainCA (where Domain is the NetBIOS name of your domain), and then click Issued Certificates.

b. On the View menu, click Add/Remove Columns.

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 Authority console, find the serial number of the ArchiveEFS certificate that the CA issued to your EFS account.

a. In the details pane, expand the width of the Serial Number column to show the complete serial number.

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 (C:\moc\2821\labfiles\ module7\krt.exe), determine the key recovery agent for the EFS1 or EFS2 certificate.

a. Click Start, click Run, type C:\moc\2821\labfiles\module7\krt.exe and then click OK.

b. In the Key Recovery Tool, define the following settings, and then click Search.

• 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 key material to an output file named C:\moc\2821\ labfiles\module7\recover by using the Retrieve Blob button in the Key Recovery Tool.

a. In the Key Recovery Tool, in the Certificates list, select the certificate listed, and then click Retrieve Blob.

b. In the Save As dialog box, in the File name box, type C:\moc\2821\labfiles\module7\recover and then click Save.

c. In the Key Recovery Tool, click Close.


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 your KRA user account.

" Log on to the network by using the following credentials:




13. Recover the ArchiveEFS certificate private key to a file named C:\moc\2821\ labfiles\module7\EFS.pfx, and then close all open windows and log off the network.

a. Click Start, click Run, type C:\moc\2821\labfiles\module7\krt.exe and then click OK.

b. In the Key Recovery Tool, click Decrypt Blob.

c. In the Open dialog box, in the File name box, type C:\moc\2821\labfiles\module7\recover.blob and then click Open.

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 credentials:

• Logon name: EFS1 or EFS2


• Domain: Domain


• Logon name: EFS1 (on the domain controller) or EFS2 (on the member server)




(continued)


15. Import the EFS.pfx file into your personal store by using the following options:


• Click Mark this key as exportable. This will allow you to back up or transport your keys at a later time

• Certificate Store: Automatically select the certificate store based on the type of certificate

a. Open the C:\moc\2821\labfiles\module7 folder.

b. Double-click EFS.pfx.

c. On the Certificate Import Wizard page, click Next.

d. On the File to Import page, click Next.

e. On the Password page, in the Password box, type P@ssw0rd

f. Click Mark this key as exportable. This will allow you to back up or transport your keys at a later time, and then click Next.

g. On the Certificate Store page, click Automatically select the certificate store based on the type of certificate, and then click Next.

h. On the Completing the Certificate Import Wizard page, click Finish.

i. In the Certificate Import Wizard message box, click OK.

j. Close the C:\moc\2821\labfiles\module7 folder.

16. Attempt to open C:\EFS\Secret.txt.

a. Open the C:\EFS folder.

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.


a. Close Secret.txt � Notepad.


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

Module 8: Configuring Trust Between Organizations

Module 8: Configuring Trust Between Organizations iii

Instructor Notes In this module, students will to learn to how extend an organization�s PKI trust hierarchy to other organizations. By extending the trust hierarchy, an organization�s certificates can be used and trusted across organizations for purposes like secure e-mail messages, client authentication, and server 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.


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 of the features of the slides may not appear correctly.


! Read all of the materials for this module. ! Complete the practices and lab. ! Read the white paper, Windows .NET Qualified Subordination, under

Additional Reading on the Web page on the Student Materials compact 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 Reading on the Web page on the Student Materials compact disc for more 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 Reading on the Web page on the Student Materials compact disc for more information about constraints and policies.

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


Required materials

Important

Preparation tasks

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.


Explain the business reasons for establishing certificate trust between organizations. Do not go into details on this page, because each method is described fully on the pages that follow. Many students will be familiar with certificate trust lists (CTLs) if they have 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.

Use the slide to explain that the common root CA can either be a root CA that 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.

Explain that by using cross certification, students can issue a Cross 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. Explain that qualified subordination, which is an extension of Cross 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.

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.

Methods for Establishing Trust Between Organizations

How to Define Certificate Trust Lists

How to Deploy a Common Root CA

How to Implement Cross Certification

What Is Qualified Subordination?

What Is a Bridge CA?

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. Use this page as a general introduction to the following constraints that are 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. Consider using the whiteboard to draw examples of CA hierarchies and how the 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.

Build logical examples of namespace inclusions and exclusions for the students. 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.

Some students may argue that an application policy is not a constraint. 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.

Certificate policies are the basis of trust when you implement qualified 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.

In this topic, the students will think about the ways that they can apply qualified subordination in their organizations, so remind them of the legal implications of 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.

Review each guideline with the class. Ask students if they have any questions 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.

Provide students with sufficient time to answer the questions. Remind students that they must use each type of constraint as an answer.

Qualified Subordination Constraints

What Are Basic Constraints?

What Are Name Constraints?

What Are Application Policies?

What Are Certificate Policies?

How Qualified Subordination Effects a CPS

Guidelines for Designing Constraints

Practice: Identifying Constraints

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.

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.

Tell students to view the code on the topic page and notice that the PathLength entry starts at a value of zero, rather than a value of one.

Students may be unfamiliar with the syntax of Windows .inf files. Review the 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 Reading on the Web page on the Student Materials compact disc.

If students have questions about the application policy OIDs, open the Certificate Templates console and view the available object identifiers. Emphasize that most required application policies are predefined and available in the console.

Explain that when application policies are predefined, certificate policies are 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.

Provide students with sufficient time to complete the practice, and then review the answers with the class. The most common mistake that students make is to omit one of the namespaces in the solution. Discuss this common mistake, and 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.

Do not demonstrate the process at this point because the lesson ends with a demonstration about this topic. Emphasize that the students must create this certificate template to implement qualified subordination. No default template exists that can sign Cross Certification Authority certificate requests.

What Is a Policy.inf File?

Configure Basic Constraints

Configure Name Constraints

Configure Application Policies

Configure Certificate Policies

Practice: Configuring a Policy.inf File to Enforce Namespace Requirements

How to Create a Signing Certificate Template from an Enterprise CA

Module 8: Configuring Trust Between Organizations vii

Explain to students that they must perform major modifications to the Cross Certification Authority certificate template only when they do not use the default application policy signing OID. Consider showing students the Issuance 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.

You must perform this demonstration on the instructor computer exactly as it is written. This demonstration creates the Qualified Subordination Signing 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.

Explain that the Certreq.exe command-line tool generates the Cross Certification Authority certificate. Review the syntax of the command, and show students that even though they start at a command line, the process is actually a graphical process.

This topic prepares students for the upcoming lab. Explain that the only time that students must publish a Cross Certification Authority certificate is when 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.

Review the syntax of the certutil �viewstore command. The most common 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.

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.

Steps for Modifying a Cross Certification Authority Certificate Template

Demonstration: Creating Certificate Templates for Qualified Subordination

How to Create a Cross Certification Authority Certificate

How to Publish a Cross Certification Authority Certificate

How to Verify Qualified Subordination

Lab A

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.


The labs in this module require that a CA hierarchy with an offline root CA and an enterprise subordinate CA exist. Complete all of Lab A, Lab B, and Lab C in Module 3, �Creating a Certification Authority Hierarchy,� in Course 2821, Designing and Managing a Windows Public Key Infrastructure.

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.


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.

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.

Setup requirement 1

Setup requirement 2

Setup requirement 3

Setup requirement 4

Setup requirement 5

Module 8: Configuring Trust Between Organizations ix



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

Lab A

Module 8: Configuring Trust Between Organizations 1

Overview


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.

Introduction

Objectives

2 Module 8: Configuring Trust Between Organizations

Lesson: Introduction to Advanced PKI Hierarchies


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.

Introduction

Lesson objectives


Methods for Establishing Trust Between Organizations


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.

In a Windows Server 2003 PKI, you can use the following methods to configure trust between 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.

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 Authority certificate.

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

Introduction

Methods for establishing trust between organizations

Note


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.

When to establish trust


How to Define Certificate Trust Lists


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.

To define a CTL for 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 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.

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.

Introduction

Procedure for defining a CTL

Importing a CTL


How to Deploy a Common Root CA


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.

You can use one of the following methods to deploy a common root CA as a 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.

Introduction

Deploying a common root CA


To add a trusted root certification authority 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.

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.

A common root CA allows total trust between the organizations that designate the common root CA as a trusted root CA. Consider the following facts before 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.

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.

Procedure to deploy a trusted root CA to a GPO

Note

Considerations when deploying a common root CA

Note


How to Implement Cross Certification


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.

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.

To implement cross certification between two organizations:

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.

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.

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.

Introduction

Note

Steps for implementing cross certification

Tip

Note


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.

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.

Note


What Is Qualified Subordination?


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.

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.

Introduction

Defining constraints


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.

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 Additional Reading on the Web page on the Student Materials compact disc.

Note


What Is a Bridge CA?


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.

For more information about bridge CA design, see the Federal Bridge Certification Authority (FBCA) Web site at http://www.cio.gov/fbca/.

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.

Introduction

Note

Deploying a Bridge CA


Lesson: Qualified Subordination Concepts


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.

Introduction

Lesson objectives


Qualified Subordination Constraints


You can define different types of constraints for qualified subordination.

You can define the following constraints when you issue a Cross Certification 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.

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.

For more information about designing qualified subordination constraints, see the white paper, Planning and Implementing Qualified Subordination Using Windows Server 2003, Enterprise Edition, under Additional Reading on the Web page on the Student Materials compact disc.

Introduction

Types of subordination constraints

Defining constraints

Note


What Are Basic Constraints?


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.

For more information about basic constraints, see section 4.2.1.10 of 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.

Define basic constraints only in CA certificates that are issued to a subordinate 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 Authority certificate.

Introduction

Note

Recommendations for basic constraints


What Are Name Constraints?


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.

If the name that is specified in the request is not present in the list of constraints, the qualified CA will reject the request.

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.

For more information about name constraints, see section 4.2.1.11 of 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.

Introduction

Note

Example

Note


When you process name constraints, consider the following rules:

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

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.

Rules for processing name constraints

Note


What Are Application Policies?


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.

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.

For more information about certificate status checking and revocation, see the white paper, Troubleshooting Certificate Status and Revocation, under Additional Reading on the Web page on the Student Materials compact disc.

Introduction

Note

Note


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.

For more information about application policies, see section 4.2.1.13 of 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.

Note


What Are Certificate Policies?


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.

A Windows Server 2003 PKI includes the following predefined certificate 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.

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.

Introduction

Default certificate policies

Note


In addition to these default certificate policies, your organization can create 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.

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.

When certificate policies are implemented between organizations, the OIDs that one organization defines are mapped to the OIDs that the other organization defines. By defining mappings between the OIDs, equivalent OIDs are identified between the organizations.

For more information about certificate policies, see section 4.2.1.5 in 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.

Custom certificate policies

Note

Defining certificate policies between organizations

Note


How Qualified Subordination Effects a CPS


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.

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.

Introduction

Modifying the CPS


Guidelines for Designing Constraints


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.

Consider the following guidelines when you design qualified subordination 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.

Introduction

Guidelines for designing constraints


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

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.

Note


Practice: Identifying Constraints


In this practice, you will identify which qualified subordination constraints are required to meet the certificate requirements of Northwind Traders, a fictitious company.


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. To help you configure certificate trust between the two organizations, Contoso, Ltd has provided the following diagram of its CA hierarchy.

Introduction

Note

Scenario

CA hierarchy of Contoso Ltd


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.

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 c. Application Policy d. Certificate Policy d. Certificate Policy ____________________________________________________________

____________________________________________________________

Requirements

Questions


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 c. Application Policy d. Certificate Policy c. Application Policy ____________________________________________________________

____________________________________________________________

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 c. Application Policy d. Certificate Policy b. Name Constraint ____________________________________________________________

____________________________________________________________


Lesson: Configuring Constraints in a Policy.inf File


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.

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 Materials compact disc.

Introduction

Lesson objectives

Note


What Is a Policy.inf File?


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.

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.

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.

Introduction

A Policy.inf file

Note


Configure Basic Constraints


A basic constraint defines which CAs your organization trusts in a partner�s CA hierarchy by limiting the path length for a certificate chain.

You can define a basic constraint by adding a [BasicConstraintsExtension] 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.

Define basic constraints only in Cross Certification Authority certificates that 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.

Introduction

Configuring basic constraints

Guideline for defining a basic constraint


Configure Name Constraints


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.

Introduction


You implement name constraints by defining the Permitted and Excluded name 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 [email protected], 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.

Configuring name constraints


When you create a new CA, you can define name constraints for the CA by 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 name

Identifies the names of objects stored in directories.

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 Identifier (URI)

Identify resources on the Internet that use identifiers such as URL, FTP, HTTP, telnet, mailto, news, and gopher.

E-mail name and user principal name

Identify the suffixes used for e-mail addresses and UPN 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.

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 Web page on the Student Materials compact disc.

Acceptable name formats

Note


Configure Application Policies


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.

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.

To configure application policies in a policy.inf file, create the following 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

Introduction

Note

Configuring application policies


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.

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.

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

Note

Using Custom OIDs


Configure Certificate Policies


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.

If your organization has an OID that is issued by Internet Assigned Numbers 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

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.

After you define the OIDs for your organization�s certificate policies, obtain the complementary OIDs from the partner organization. Obtain the partner�s OIDs because the OIDs differ between the two organizations.

Introduction

Configuring certificate policies

Note

Obtaining OIDs from a partner


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

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.

Policy mapping

Policy qualifiers


Practice: Configuring a Policy.inf File to Enforce Namespace Requirements


In this practice, you will modify a policy.inf file to enforce the namespace requirements of your organization.


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.

To aid in the configuration of certificate trust between the two organizations, Contoso has provided you the following diagram of its CA hierarchy.

Introduction

Note

Scenario

Contoso�s CA hierarchy


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.

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: [NameConstraintsExtension]

[NameConstraintsExtension]

Include = NameConstraintsPermitted

Exclude = NameConstraintsExcluded

Critical = True

____________________________________________________________

____________________________________________________________

____________________________________________________________

Requirements

Questions


[NameConstraintsPermitted]

[NameConstraintsPermitted]

DirectoryName = "OU=lawyers,DC=contoso, DC=msft"

email = @contoso.msft

UPN = .contoso.msft

UPN = @contoso.msft

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

[NameConstraintsExcluded]

[NameConstraintsExcluded]

DirectoryName = "DC=nwtraders, DC=msft"

email = @nwtraders.msft

UPN = .nwtraders.msft

UPN = @nwtraders.msft

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________


Lesson: Implementing Qualified Subordination


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.

Introduction

Lesson objectives


How to Create a Signing Certificate Template from an Enterprise CA


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.

The first step in generating a Qualified Subordination certificate is to create a 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.

Introduction

Procedure for duplicating a certificate


After you create the Qualified Subordination certificate template, you define the purpose of the Qualified Subordination certificate and the CSP. To define the 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.

After you define the CSP and permissions, remove the Certificate Request Agent application policy from the certificate template. To remove the 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.

After you remove the Certificate Request Agent application policy from the certificate template, you can add the Qualified Subordination application policy OID to the certificate template in the following way:

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.

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 defining the certificate purpose and CSP

Procedure for removing the Certificate Request Agent application policy

Procedure for adding the Qualified Subordination application policy OID

Note


The final step in designing the Qualified Subordination certificate template is to publish the certificate template on an enterprise CA in your organization�s CA 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.

Procedure for publishing the certificate template


Steps for Modifying a Cross Certification Authority Certificate Template


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.

To make the initial modifications to the Cross Certification Authority certificate 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.

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.

Introduction

Procedure for modifying issuance requirements

Note


To deploy a certificate, you must be running Windows Server 2003, Enterprise Edition because only Windows Server 2003 enterprise servers support version 2 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.

2. Open the Certification Authority console. 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

then click Certificate Template to Issue. 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


Use the following procedure to modify, create, and publish the certificate templates that are necessary for qualified subordination.


The first step in creating a Qualified Subordination Signing certificate is to duplicate the Enrollment Agent certificate template. To create the Qualified Subordination Signing certificate 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.

To create the Qualified Subordination Signing certificate template, you must have the permissions to create and modify certificate templates.

Introduction

Note

Procedure for creating a Qualified Subordination Signing certificate template

Note


After creating the version 2 certificate template, make the following 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.

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.

After you create the Qualified Subordination Signing certificate template, and, if necessary, have modified the template, you must publish the two certificate templates on an enterprise CA in your CA hierarchy. To publish the certificate template:

1. Open the Certification Authority console. 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.

Ensure that you publish both the Cross Certification Authority and Qualified Subordination Signing certificate templates.

6. Close the Certification Authority console.

Procedure for modifying the attributes of the Certificate Template

Note


Important


How to Create a Cross Certification Authority Certificate


After you collect and configure all required files, you can create the Cross Certification Authority certificate.

To create a Cross Certification Authority 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.

Introduction

Steps to create a Cross Certification Authority certificate


How to Publish a Cross Certification Authority Certificate


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.

In this model, only two organizations are involved in the Cross 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.

In this model, the organizations that participate in the certificate trust issue and 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.

Introduction

Standard cross certification

Bridge cross certification


To publish the Cross Certification Authority certificates that were issued by the Bridge CA:

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.

Procedure for publishing Cross Certification Authority certificates


How to Verify Qualified Subordination


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.

You can use certutil.exe in the following way to verify the existence of the 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.

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.

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.

Introduction

Procedure for verifying qualified subordination

Warning

Note


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.

This lab focuses on the concepts in this module and as a result may not 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.

Objectives

Note







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

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 Web page on the Student Materials compact disc.

Prerequisites




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.

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.

Scenario

Note


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.










b. If the Certificate Templates dialog box appears, click OK.

3. Create a new certificate template named Qualified Subordination Signing based on the Enrollment Agent certificate template.

a. In the Certificate Templates console, in the details pane, right-click Enrollment Agent, and then click Duplicate Template.

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

4. Disable all CSPs for the Qualified Subordination Signing certificate except for the Microsoft Enhanced Cryptographic Provider v1.0 CSP.

a. In the details pane, double-click Qualified Subordination Signing.

b. On the Request Handling tab, click CSPs.

c. In the CSP Selection dialog box, in the CSPs list, select only Microsoft Enhanced Cryptographic Provider v1.0, and then click OK.

d. In the Qualified Subordination Signing Properties dialog box, click Apply.

5. Select the following issuance requirements:

• CA certificate manager approval

• Valid existing certificate

a. On the Issuance Requirements tab, click CA certificate manager approval.

b. Under Require the following for reenrollment, click Valid existing certificate, and then click Apply.


(continued)


6. Remove all existing application policy extensions, and add the Qualified Subordination application policy.

a. On the Extensions tab, select Application Policies, and then click Edit.

b. In the Edit Application Policies Extension dialog box, select Certificate Request Agent, and then click Remove.

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 Requirements tab for the Cross Certification Authority certificate template.

a. In the details pane, double-click Cross Certification Authority.

b. In the Cross Certification Authority Properties dialog box, click the Issuance Requirements tab.

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)







• Domain: Domain

10. Publish the Qualified Subordination Signing and the Cross Certification Authority certificate templates on the DomainCA.




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









2. Clear the Read-only check box on the C:\moc\2821\ labfiles\module8\ Domain-to-Bridge.inf file.


b. In the C:\moc\2821\labfiles\module8 folder, right-click Domain-to-Bridge.inf, and then click Properties.

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 in the Domain-to-Bridge.inf file to reflect your organization�s DNS domain name and forest LDAP distinguished name.

a. In the C:\moc\2821\labfiles\module8 folder, double-click Domain-to-Bridge.inf.

b. On the Edit menu, click Replace.

c. In the Replace dialog box, in the Find what box, type DNSDomain

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 policies in the Domain-to-Bridge.inf file to reflect your organization�s Medium Assurance certificate policy OID.


b. If the Certificate Templates dialog box appears, click Yes.

c. If the Certificate Templates message box appears, click OK.

d. In the console tree, right-click Certificate Templates, and then click 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 computer by using Remote Desktop Connection as Administrator with a password of P@ssw0rd.

a. On the Start menu, point to All Programs, point to Accessories, point to Communications, and then click Remote Desktop Connection.

b. In the Remote Desktop Connection dialog box, in the Computer box, type London and then click Connect.

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 computer to copy the Medium Assurance OID for the Northwind Traders forest to the Windows clipboard.


b. In the console tree, right-click Certificate Templates, and then click View Object Identifiers.

c. In the View Object Identifiers dialog box, in the Available object identifiers list, select Medium Assurance, and then click Copy Object Identifier.

d. Minimize the Remote Desktop Connection window.


(continued)


7. Replace all occurrences of BridgeMediumOID in the Domain-to-Bridge.inf file with the Medium Assurance OID from the Nwtraders forest.

a. In the taskbar, click Domain-to-Bridge.inf.


c. In the Replace dialog box, in the Find what box, type BridgeMediumOID

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 Domain-toBridge.inf � Notepad.

a. On the File menu, click Save.

b. Close the Domain-toBridge.inf � Notepad window.

9. In the Remote Desktop Connection, close all open windows and then log off the network.

a. In the taskbar, click London - Remote Desktop.

b. In the View Object Identifiers dialog box, click Close.

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.



1. Ensure that you are logged on to the network with your domain administrator account.





2. Request a Qualified Subordination Signing certificate by using Web-based enrollment.

• Certificate Template: Qualified Subordination Signing

• Friendly Name: QS Signing



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 Create and submit a request to this CA.

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 Web site to request a certificate on your behalf.

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 member of the certificate administrators.


• User name: Certadmin2


• Domain: Domain








5. Issue the pending Qualified Subordination Signing certificate request and then log off the network.

a. In the Certification Authority console, expand DomainCA, and then click Pending Requests.

b. In the details pane, select all pending certificate requests.

c. Right-click the pending certificate requests, point to All Tasks, and then click Issue.




6. Open the URL http://WebServer/certsrv and perform the following actions:

• Click View the Status of a Pending Certificate Request

• Click Qualified Subordination Signing Certificate (Date and Time)

• Click Install this certificate


b. In Internet Explorer, open the URL http://WebServer/certsrv.

c. On the Welcome page, click View the status of a pending certificate request.

d. On the View the Status of a Pending Certificate Request page, click Qualified Subordination Signing Certificate (Date and Time).

e. On the Certificate Issued page, click Install this certificate.

f. In the Potential Scripting Violation dialog box, click Yes to allow the Web site to add a certificate to your computer.

g. Ensure that the Certificate Installed page appears, which indicates that the certificate has been installed successfully.


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 \\London\Certenroll share by using the following credentials:



a. Click Start, click Run, type \\London\Certenroll and then click OK.

b. In the Connect to London.nwtraders.msft dialog box, enter the following credentials:



c. In the Connect to London.nwtraders.msft dialog box, click OK.

2. Copy the London.nwtraders.msft _bridgeCA.crt file to C:\moc\2821\labfiles\ module8.

a. In the \\London\Certenroll window, right-click London.nwtraders.msft_bridgeCA.crt, and then click Copy.

b. Open 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 Authority certificate request process by typing certreq �policy in the C:\moc\2821\ labfiles\module8 folder.


b. At the command prompt, do the following:

• Type C: and then press ENTER.

• Type cd \moc\2821\labfiles\module8 and then press ENTER.

• Type certreq �policy and then press ENTER.


(continued)


4. In the Certreq.exe wizard, provide the following information:

• Request file: London.nwtraders.msft_BridgeCA.crt

• .inf file: Domain-to-Bridge.inf

• Enrollment Registration Agent certificate: QS Signing certificate

• Request file name: CrossCA.req

a. In the Open Request File dialog box, in the Files of type drop-down list, select Certificate Files (*.cer,*.crt,*.der).

b. In the File name box, type C:\moc\2821\labfiles\module8 and then click Open.

c. Select London.nwtraders.msft_BridgeCA.crt, and then click Open.

d. In the Open Inf File dialog box, select Domain-to-Bridge.inf, and then click Open.

e. In the Certificate List dialog box, select your QS Signing certificate, and then click OK.

f. In the Save Request dialog box, in the File name box, type CrossCA.req and then click Save.

g. Close the command prompt.

5. In the Certification Authority console, submit the CrossCA.req certificate request file, and then save the resulting certificate as BridgeCA.cer.

a. On the Start menu, point to Administrative Tools, and then click Certification Authority.

b. In the console tree, right-click DomainCA, point to All Tasks, and then click Submit new request.

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.



6. Ensure that you are logged on to the network with your domain administrator account.




• Domain: Domain

7. Verify that the BridgeCA certificate is published by typing Certutil �viewstore "CN=BridgeCA,CN=AIA,CN=Public Key Services, CN=Services, CN=Configuration, DC=Domain,DC= msft?crossCertificatePair" at a command prompt.


b. At the command prompt, type Certutil �viewstore "CN=BridgeCA,CN=AIA,CN=Public Key Services, CN=Services,CN=Configuration, DC=Domain,DC=msft?crossCertificatePair� and then press ENTER.

c. In the View Certificate Store dialog box, click View Certificate.


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

1. Log on to the network using your domain administration account.





2. Copy the Medium Assurance certificate policy OID for your domain to the Windows clipboard.




d. In the View Object Identifiers dialog box, click Close.

e. Close Certificate Templates.

3. Connect to the London computer by using Remote Desktop Connection to log on as Administrator with a password of P@ssw0rd.

a. On the Start menu, point to All Programs, point to Accessories, point to Communications, and then click Remote Desktop Connection.

b. In the Remote Desktop Connection dialog box, in the Computer box, 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\ labfiles\module8\ Bridge-to-Domain.inf to C:\moc\2821\labfiles\ module8\Domain.inf.


b. In the C:\moc\2821\labfiles\module8 folder, double-click Bridge-to-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, replace MyMediumOID with the Medium Assurance certificate policy OID for your forest.

a. On the Edit menu, click Replace.

b. In the Replace dialog box, in the Find what box, type MyMediumOID

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 Assurance certificate policy OID for the Northwind Traders domain to the Clipboard.




d. In the View Object Identifiers dialog box, click Close.


7. In the Domain.inf file, replace BridgeMediumOID with the Medium Assurance certificate policy OID for the Northwind Traders forest.

a. On the taskbar, click Domain.inf.


c. In the Replace dialog box, in the Find what box, type BridgeMediumOID

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 close Domain.inf.

a. On the File menu, click Save, and then close the window.

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 connected to London using the Remote Desktop Connection.

" Ensure that you are still connected to the London computer using the Remote Desktop Connection with the following credentials:




2. Request a Qualified Subordination Signing certificate with a friendly name of Computer QS Signing


b. In the console tree, expand Personal, and then click Certificates.

c. In the console tree, right-click Certificates, point to All Tasks, and 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.

f. On the Certificate Friendly Name and Description page, in the Friendly name box, type Computer QS Signing (where Computer is the NetBIOS name of your computer), and then click Next.



i. Close the Certificates � Current User console.

3. Copy your domain�s enterprise CA�s subordinate Certification Authority certificate to the C:\moc\2821\labfiles\ module8 folder.

a. Open \\Dcname\certenroll (where Dcname is the NetBIOS name of the domain controller in your domain).

b. In the \\Dcname\certenroll window, right-click dcname.Domain.msft_DomainCA.crt (where Domain is the NetBIOS name of your domain), and then click Copy.

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 Authority certificate request process by typing certreq �policy in the C:\moc\2821\labfiles\ module8 folder.




• Type cd \moc\2821\labfiles\module8 and then press ENTER.

• Type certreq �policy and then press ENTER.

5. In the Certreq.exe prompts, provide the following information:

• Request file: Dcname.Domain.msft_DomainCA.crt

• Inf file: Domain.inf

• Enrollment Registration Agent certificate: Computer QS Signing certificate

• Request file name: Domain.req

a. In the Open Request File dialog box, in the Files of type drop-down list, select Certificate Files (*.cer,*.crt,*.der).

b. In the File name box, type C:\moc\2821\labfiles\module8 and then click Open.

c. Select Dcname.Domain.msft_DomainCA.crt, and then click Open.

d. In the Open Inf File dialog box, select Domain.inf, and then click Open.

e. In the Certificate List dialog box, select the certificate with the friendly name of Computer QS Signing, and then click OK.

f. In the Save Request dialog box, in the File name box, type Domain.req (where Domain is the NetBIOS name of your domain), and then click Save.

g. Close the command prompt.

6. In the Certification Authority console, submit the Domain.req certificate request file and then save the resulting certificate as Domain.cer.


b. In the console tree, right-click BridgeCA, point to All Tasks, and then click Submit new request.

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 computer, which terminates the Remote Desktop Console.

a. Close all open windows.

b. On the Start menu, click Log Off.

c. In the Log Off Windows dialog box, click Log Off.


" 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 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 the BridgeCerts folder.

" Move all Domain.cer (where Domain is the NetBIOS name of each student domain) files to the BridgeCerts folder.

3. Create and share a subfolder named ClientCerts.

a. Ensure that you are in the C:\moc\2821\labfiles\module8 window.

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 administrator account.






5. Publish all Cross Certification Authority certificates that the Bridge CA issued and stored in \\London\Bridgecerts to Active Directory by using the following command:

• Certutil �dspublish �f Domain.cer CrossCA



• Type Net use x: \\London\Bridgecerts /user:administrator P@ssw0rd and then press ENTER.

• Type x: and then press ENTER.

• Type dir and then press ENTER.

c. Type the following command for every Domain.cer file that exists in 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 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 your computer and then log 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.



1. Log on using your certificate template administrator account.






" Click Start, click Run, type Certtmpl.msc and then click OK.

3. Create a new certificate template named QS Email based on the User Signature Only certificate template.

a. In the Certificate Templates console, in the details pane, right-click User Signature Only, and then click Duplicate Template.

b. In the Properties of New Template dialog box, on the General tab, in the Template display name box, type QS Email and then click OK.

4. Add the Medium Assurance issuance policy OID to the certificate template.

a. In the details pane, double-click QS Email.

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 group Read and Enroll permissions and then log off.


b. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type QSA and then click Check Names.

c. In the Enter the object names to select box, ensure that QSAccounts appears, and then click OK.

d. Assign the QSAccounts group the Read and Enroll permissions, and then click OK.


f. Close all open windows and log off.


6. Log on using your domain administrator account and password.





7. Publish the QS Email certificate template to DomainCA.




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 subordination user account.


• User name: QualSub1 (on the domain controller) or QualSub2 (on the member server)




(continued)


9. In the Certificates � Current User console, request a QS Email certificate.


b. In the console tree, click Personal.

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.

f. On the Certificate Friendly Name and Description page, in the Friendly name box, type QS Email and then click Next.



10. Export the QS Email certificate to \\London\ClientCerts\ ComputerQSEmail.

a. In the console tree, expand Personal, and then click Certificates.

b. In the details pane, right-click the certificate with the friendly name of QS Email, point to All Tasks, and then click Export.

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 \\London\ClientCerts share.

a. Click Start, click Run, type \\London\ClientCerts and then click OK.

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 process with other organization�s certificates, and then log off the network.

a. If time permits, repeat the process with certificates that are issued by other organizations.

b. Close all open windows and log off.

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

Module 9: Deploying Smart Cards

Module 9: Deploying Smart Cards iii

Instructor Notes Smart cards provide secure storage for data and support authentication of users. Smart cards can take a number of forms, including credit cards, key-shaped tokens, Subscriber Identity Module (SIM) chips in Group Special Mobile (GSM) cellular phones, and Universal Serial Bus (USB) tokens. In this module, 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.

To teach this module, you need

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

Authentication.


! Read all of the materials for this module. ! 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,� under Additional Reading on the Web page on the Student Materials 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 Additional Reading on the Web page on the Student Materials compact 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.


Required materials

Preparation tasks

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.


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

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.

Do not spend time describing each application to the class. Consider asking the 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. Many students may be familiar with Windows 2000, which does not support the 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.


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

Review each of the hardware and software requirements on the slide. 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.

What Are Smart Cards?

Why Use Smart Cards?

Features of Smart Cards

Reasons to Use Smart Cards

Smart Cards for Administrative Tasks

Multimedia: How Smart Cards Change Kerberos Authentication

Requirements for Smart Card Logon

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.

Introduce the concepts of smart card enrollment agents and smart card 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.

Emphasize that the smart card enrollment agent is the most common method for initial smart card deployment. Explain that the enrollment agent allows the 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?

Explain that autoenrollment may not be an option for some organizations. Reiterate that the client computer must be running Windows XP Professional or 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.

Review each requirement this is listed on the slide. Be prepared to answer any 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. Do not spend a lot of time on this page, but ensure that the students understand 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. Spend time discussing the requirements for creating custom version 2 certificate templates for smart card certificates. Although there are two default templates 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.

Explain that an enrollment agent can request certificates for any user on the 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.

Smart Card Enrollment Methods

When to Implement a Smart Card Enrollment Agent

When to Implement Smart Card Autoenrollment

Guidelines for Smart Card Enrollment

Phases in Smart Card Deployment

Guidelines for Choosing a Smart Card Certificate Template

Steps for Designating an Enrollment Agent

vi Module 9: Deploying Smart Cards

Review each requirement for implementing a smart card enrollment station. Remind students that smart card enrollment is typically performed on designated enrollment stations, not domain controllers.

Consider demonstrating the Web Enrollment pages for smart card enrollment. Emphasize that only a local administrator can install the smart card enrollment 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.

Review which PKI management roles perform each required task. Mention that on some networks, one person may hold more than one role. Having multiple roles depends on whether common criteria role separation is enforced.

Compare and contrast each of the available options for smart card removal 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.

Review how to enforce smart card authentication for both interactive and 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.

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 Materials compact disc.

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.

Steps for Configuring an Enrollment Station

How to Enroll Smart Cards Using an Enrollment Agent

How to Autoenroll Smart Cards

How to Configure Smart Card Removal Behavior

How to Enforce Smart Card Authentication

Lab A

Module 9: Deploying Smart Cards vii


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 Module 3, �Creating a Certification Authority Hierarchy,� in Course 2821, Designing and Managing a Windows Public Key Infrastructure.

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.


The http://WebServer (where WebServer is the fully qualified domain name of 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 Certification Authority Hierarchy,� in Course 2821.



! 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 enterprise subordinate CA.

! 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 enterprise subordinate CA.

! CodeSignComputer certificates are issued to SCUser1 and SCUser2.

Setup requirement 1

Setup requirement 2

Setup requirement 3

Setup requirement 4

Lab A

Module 9: Deploying Smart Cards 1

Overview


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.

Introduction

Objectives

2 Module 9: Deploying Smart Cards

Lesson: Introduction to Smart Cards


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.


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

Introduction

Lesson outline


What Are Smart Cards?


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.

Introduction


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.

Using smart cards


Why Use Smart Cards?


Before you deploy smart cards in your organization�s network, determine whether smart cards will meet your organization�s business objective.

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.

Introduction

Business objectives


Features of Smart Cards


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.

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.

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.

Introduction

Note

Smart card storage


Reasons to Use Smart Cards


Several network applications can use smart cards to increase the security of encryption and digital signing services.

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.

Introduction

Using Smart Cards


Smart Cards for Administrative Tasks


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.

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.

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.

Introduction

Administrative tasks

Note


Multimedia: How Smart Cards Change Kerberos Authentication


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.

! How Kerberos authentication works. ! How smart cards modify the Kerberos authentication process.

Introduction

Key points


Requirements for Smart Card Logon


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.

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.

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.

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.

Introduction

Hardware requirements

Note

Note


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.

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.

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 Reading on the Web page on the Student Materials compact disc.

Software requirements

Note

Note


Lesson: Enrolling Smart Card Certificates


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.

Introduction

Lesson objectives


Smart Card Enrollment Methods


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.

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.

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.

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.

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.

Introduction

Enrollment agent

Note

Autoenrollment

Note


When to Implement a Smart Card Enrollment Agent


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.

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.

Use an enrollment agent for smart card deployment if your organization has the 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.

Introduction

Note

Using an enrollment agent


You can add additional security to the enrollment agent process by performing 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.

Securing the enrollment agent process


When to Implement Smart Card Autoenrollment


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.

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.

You can secure the autoenrollment process by requiring a smart card signature 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.

Introduction

Using autoenrollment

Securing the autoenrollment method


Guidelines for Smart Card Enrollment


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.

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.

Introduction

Enrollment agent


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.

Autoenrollment


Lesson: Deploying Smart Cards


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.

Introduction

Lesson objectives


Phases in Smart Card Deployment


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

For more information about infrastructure deployment by using MSF fundamentals, see http://www.microsoft.com/msf.

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.

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.

Introduction

Note

Envisioning

Business requirements


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.

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.

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.

Planning

Development

Implementation


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.

Note


Guidelines for Choosing a Smart Card Certificate Template


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.

Windows Server 2003 includes two smart card-related certificate templates in 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.

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.

Introduction

Smart card certificate templates

Note


Steps for Designating an Enrollment Agent


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.

To secure the enrollment process for an Enrollment Agent certificate template, 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.

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.

Introduction

Securing the enrollment process

Note


After you, as a certificate manager, modify and publish the Enrollment Agent certificate template on one or more CAs in your organization�s CA hierarchy, 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.

After you issue the pending certificate request, install the modified Enrollment Agent certificate by completing the following steps:

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.

Procedure for enrolling the Enrollment Agent certificate

Procedure for installing the modified Enrollment Agent certificate


Steps for Configuring an Enrollment Station


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.

To prepare a smart card certificate 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.

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.

To enroll a Computer certificate, the requesting user must be a member of the local Administrators group on the enrollment station.

Introduction

Steps for configuring the enrollment station

Note

Note


How to Enroll Smart Cards Using an Enrollment Agent


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.

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.

To manually request a Smart Card certificate on behalf of another user:

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.

Introduction

Important

Procedure for enrolling smart cards using an enrollment agent


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.

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.

Note


How to Autoenroll Smart Cards


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.

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.

A member of the Enterprise Admins group performs the following tasks to enable autoenrollment for smart card certificates:

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.

Users must be prompted to insert their smart card and enter their PIN during the autoenrollment process.

Introduction

Note

Procedure for a member of the Enterprise Admins group

Note


Publish the certificate template on one or more enterprise CAs in the CA hierarchy. After the certificate template is available for autoenrollment, a member of the Domain Admins group must enable Autoenrollment Settings in Group Policy. 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.

For more information about enabling certificate autoenrollment, see Module 6, �Configuring Certificate Enrollment,� in Course 2821, Designing and Managing a Windows Public Key Infrastructure.

After Group Policy is implemented to enable autoenrollment for users, the 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.

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.

Procedure for the CA administrator Procedure for a member of the Domain Admins group

Note

Procedure for the smart card enrollee

Note


How to Configure Smart Card Removal Behavior


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.

To enable smart card removal behavior settings in Group Policy:

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.

Introduction

Procedure for configuring smart card removal behavior


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


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.

To enforce smart card authentication for interactive logon, modify the properties of the user account to require a smart card. To modify the properties:

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.

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.

Introduction

Procedure for enforcing smart card authentication for interactive logon

Warning


To enforce smart card authentication for remote access, configure a remote access policy to require EAP/TLS authentication in the profile settings. The certificate that is used for authentication must contain the Client Authentication 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.

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.

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.

Procedure for enforcing smart card authentication for remote access

Note

Note


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.






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

For more information about deploying smart cards, see the white paper, Certificate Autoenrollment in Windows Server 2003, under Additional Reading on the Web page on the Student Materials compact disc.

Objectives

Note

Prerequisites



The following exercises in this lab require a 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.

Exercises that require a smart card reader



Exercise 0 Lab Setup Before you begin this lab, you must install the USB smart card reader that is provided.








2. Plug in the USB smart card reader so that Plug and Play can automatically install the drivers.

a. Plug the USB smart card reader into a USB port on your computer.

b. In the notification area, double-click the Safely Remove Hardware icon.

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, download updated drivers from the Internet for your USB smart card reader and then manually install the necessary drivers.

a. If the installation does not proceed automatically, the Welcome to the Found New Hardware Wizard page appears.

b. Download the latest Windows XP or Windows Server 2003 family drivers for your USB smart card reader.

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 reader is available for network authentication.

a. Log off.

b. Ensure that the Welcome to Windows dialog box displays a smart card 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.








2. Open the Certificate Templates console and view the properties of the Enrollment Agent certificate template.



c. In the details pane, double-click Enrollment Agent.

3. Take ownership of the Enrollment Agent certificate template.

a. In the Enrollment Agent Properties dialog box, on the Security tab, click Advanced.

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 Agent certificate templates to remove the Enroll Permission for the Domain Admins and Enterprise Admins groups. Then, assign the EnrollmentAgents group Read and Enroll permissions.

a. On the Security tab, click Domain Admins, and then clear the Enroll check box.

b. Click Enterprise Admins, and then clear the Enroll check box.

c. On the Security tab, click Add.

d. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type Enrollment, and then click Check Names.

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 Administrator account and password.




• Domain: Domain

6. Publish the Enrollment Agent certificate template on DomainCA.




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 member of the EnrollmentAgents group.


• User name: Agent1 (on the domain controller) or Agent2 (on the member server)



2. Request an Enrollment Agent certificate by using Web-based enrollment, and then log off the network.



c. In Internet Explorer, open the URL http://WebServer/certsrv (where WebServer is the fully qualified domain name of your domain controller).




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 Web site to request a certificate on your behalf.

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.



1. Log on using your certificate template administrator account.





2. Create a version 2 certificate template named AgentSmartCard based on the Smart Card Logon certificate template.



c. In the details pane, right-click Smartcard Logon, and then click 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 certificate template, select the following setting:

• CSP: Schlumberger Cryptographic Service Provider

a. In the details pane, double-click AgentSmartCard.

b. In the AgentSmartCard Properties dialog box, on the Request Handling tab, click CSPs.

c. In the CSP Selection dialog box, click Requests must use one of the following CSPs.

d. Under CSPs, select the Schlumberger Cryptographic Service Provider check box, and then click OK.

4. Configure the certificate template to mandate that the requestor sign a request with a certificate with the Certificate Request Agent application policy.

a. In the AgentSmartCard Properties dialog box, on the Issuance Requirements tab, click This number of authorized signatures.

b. Ensure that the Policy type required in signature drop-down list displays Application policy.

c. Ensure that the Application policy drop-down list displays Certificate Request Agent.

d. Click Apply.


(continued)


5. Add the High Assurance issuance policy to the AgentSmartCard certificate template.

a. In the AgentSmartCard Properties dialog box, on the Extensions tab, click Issuance Policies, and then click Edit.


c. In the Add Issuance Policy dialog box, click High Assurance, and then click OK.


e. Click Apply.

6. In the AgentSmartCard certificate template, assign the EnrollmentAgents Read and Enroll permissions.

a. In the AgentSmartCard Properties dialog box, on the Security tab, click Add.

b. In the Select Users, Computers, or Groups dialog box, in the Enter 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 box, and then click OK.

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 CA administrator.


• Logon name: CAAdmin1


• Domain: Domain

8. Configure the DomainCA to issue AgentSmartCard certificates.




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 your enrollment agent account.





2. Request a smart card certificate from the Certificate Services Web Enrollment pages.





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 ActiveX download settings for the Local intranet zone.

a. On the Tools menu, click Internet Options.

b. In the Internet Options dialog box, on the Security tab, click Local 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.



4. Log on to the domain using your administrative account.



• Password: Password (where Password is the password assigned to your domain administration account)

• Domain: Domain

5. Change the ActiveX download settings for the Local intranet zone to ask the user whether to allow Internet Explorer to download unsafe ActiveX controls.


b. On the Tools menu, click Internet Options.

c. In the Internet Options dialog box, on the Security tab, click Local intranet, and then click Custom Level.

d. In the Security Settings dialog box, in the Settings list, scroll to 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.



(continued)


6. Open the Default Domain Policy in Group Policy Object Editor.

a. On the Start menu, point to Administrative Tools, and then click Active Directory Users and Computers.

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 the user when Internet Explorer attempts to download an unsafe ActiveX control.

a. In Group Policy Object Editor, in the console tree, expand User Configuration, expand Windows Settings, expand Internet Explorer Maintenance, and then click Security.

b. In the details pane, double-click Security Zones and Content 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 administrative account.



• Password: Password (where Password is the password assigned to your domain administration account)

• Domain: Domain


(continued)


9. Download the smart card enrollment ActiveX control, close all open windows, and then log off the network.






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 on the Student Materials compact disc.

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 Student Materials compact disc.


1. Log on to the domain using your enrollment agent account.





2. Request a smart card certificate from the Certificate Services Web Enrollment pages for the following users:

• SCuser1 (on the domain controller)

• SCuser2 (on the 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 certificate.

a. On the Smart Card Certificate Enrollment Station page, click View 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 the smart card reader and then log off the network.


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 smart card authentication.

a. Insert the smart card into the smart card reader.

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 [email protected] or [email protected] (where Domain is the NetBIOS name of your domain) is currently logged on.


a. Remove the smart card from the smart card reader.






• Domain: Domain

8. Open an MMC console using 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.


a. Close Windows Task Manger.

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.



1. Log on to the domain using your certificate manager account with a password of P@ssw0rd.





2. Create a new certificate template named CodeSignComputer based on the Code Signing certificate template.



c. In the details pane, right-click Code Signing, and then click Duplicate 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 CodeSignComputer certificate template to prompt the user during enrollment.

a. In the details pane, double-click CodeSignComputer.

b. In the CodeSignComputer Properties dialog box, on the Request Handling tab, click Prompt the user during enrollment.

c. Click Apply.

4. Modify the issuance requirements to require an authorized signature with a Smart Card Logon application policy OID.

a. On the Issuance Requirements tab, click This number of authorized signatures.

b. In the Policy type required in signature drop-down list, select Application policy.

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 issuance policy OID.



c. Click Medium Assurance, and then click OK twice.

d. In the CodeSignComputer Properties dialog box, click Apply.

6. Assign Read, Enroll, and Autoenroll permissions to:

• SCUser1 (on the domain controller)

• SCUser2 (on the member server)


b. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type SCuser1 (on the domain controller) or SCUser2 (on the member server), and then click OK.

c. In the Group or user names list, select SCuser1 or SCUser2, allow 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 administrator account with a password of P@ssw0rd.


• User name: CAAdmin1


• Domain: Domain

8. Configure the DomainCA to issue the two CodeSignComputer certificate templates.




d. In the Enable Certificate Templates dialog box, click 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.





(continued)


10. Log on with your domain administration account.




• Domain: Domain

11. In Active Directory Users and Computers, link the Autoenrollment GPO to the Module09 organizational unit.

a. On the Start menu, click Administrative Tools, and then click Active Directory Users and Computers.


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.


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 on the Student Materials compact disc.

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

a. Insert the smart card into the smart card reader.

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 balloon and start the certificate enrollment process.

a. In the notification area, click the Certificate enrollment balloon.

b. In the Certificate Enrollment dialog box, click Start. A dialog box appears, informing you that you may need to enter your password or personal identification number (PIN) or insert a smart card.

3. Sign the certificate request with your smart card.

a. In the Certificate Enrollment dialog box, click OK.

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 CodeSignComputer certificate, and then save any change and log off the network.



c. Double-click CodeSignComputer (where Computer is the NetBIOS 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.




" Log on to your computer by using the following information:








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

____________________________________________________________

____________________________________________________________

Questions


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? Attribute Your recommended design 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. Attribute Your recommended design Purpose Signature and smart card logon

Do the following when the subject is enrolled and when the private key associated with this certificate is used

Prompt the user during enrollment and require user input when the 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.

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

Module 10: Securing Web Traffic by Using SSL

Module 10: Securing Web Traffic by Using SSL iii

Instructor Notes Secure Sockets Layer (SSL) is a protocol that provides encrypted 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 authentication, and to verify the Web site name. This module describes how 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.

To teach this module, you need:

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


! Read all of the materials for this module. ! Complete the lab. ! Review the multimedia presentation, Using SSL to Secure Web Traffic.


Required materials

Preparation tasks

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.


In this topic, review each reason for implementing SSL. Tell students about the 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. This multimedia presentation shows how SSL protects data and how the pre-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.


Focus on the server certificates and the user certificates that students implement in an SSL solution for a Web service. Mention which certificates are mandatory and which certificates are optional.

This topic can generate a lot of classroom discussion. Ask the students where their organization acquires their Web Server certificates. In many cases, the 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. Explain that if a Web server is only for internal use, such as an intranet application, the organization may acquire a Web Server certificate from a 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.

Why Use SSL to Secure Web Traffic?

Multimedia: Using SSL to Secure Web Traffic

Certificates Used for an SSL Session

Guidelines for Choosing a Private or Commercial CA

How to Acquire a Web Server Certificate from a Private CA

Module 10: Securing Web Traffic by Using SSL v

Tell students that they should install a Web Server certificate from a commercial CA if the Web server is an extranet Web server or is exposed to 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.

Explain to students that after they install a Web Server certificate on a Web server, they can configure various SSL options. Demonstrate the options if you installed a Web Server certificate on the instructor computer.

Expect to spend some extra time on this page, because students like to discuss their own custom configurations. Although the slide shows ISA as the firewall, 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.

Review each guideline in the slide and answer any questions. Spend extra time 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. Discuss each authentication method and the security issues of the weaker authentication protocols. For example, some methods, such as digest authentication, protect the transmitted password well, but weaken security on the domain controllers. Compare and contrast one-to-one and many-to-one certificate mappings. Ask 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.

Discuss the procedure to implement a certificate mapping in IIS. Also discuss scenarios in which students would perform the mapping in IIS. Examples 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.

How to Acquire a Web Server Certificate from a Commercial CA

SSL Configuration Options

Certificate Deployment for Complex Configurations

Guidelines for Enabling SSL Security

Web-based Authentication Methods

Types of Certificate Mapping

How to Implement Certificate Mapping in IIS

vi Module 10: Securing Web Traffic by Using SSL

Explain that Active Directory does not necessarily require them to perform the mapping as described on the page. If the certificate is issued by an enterprise 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.

Review each guideline and answer any questions.

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.


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.

All of the procedures in the lab assume that Common Criteria role separation is enforced. Students must complete Lab A in Module 4, �Managing a Public Key Infrastructure,� in Course 2821.

The ability to create and modify certificate templates is delegated to the CertTmplAdmins global group. Students must complete Lab A in Module 5, �Configuring Certificate Templates,� in Course 2821.

The http://WebServer (where WebServer is the fully qualified domain name of the student�s domain controller) is configured as a member of the Local intranet zone in the Default Domain Policy. Students must complete Lab B in Module 3, �Creating a Certification Authority Hierarchy,� in Course 2821.

How to Implement Certificate Mapping in Active Directory

Guidelines for Certificate Mapping

Lab A

Setup requirement 1

Setup requirement 2

Setup requirement 3

Setup requirement 4

Module 10: Securing Web Traffic by Using SSL vii


! 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


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.

Introduction

Objectives

2 Module 10: Securing Web Traffic by Using SSL

Lesson: Introduction to SSL Security


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

Introduction

Lesson objectives


Why Use SSL to Secure Web Traffic?


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.

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.

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.

Introduction

Using SSL

Note


Multimedia: Using SSL to Secure Web Traffic


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.

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.

Introduction

Key points


Certificates Used for an SSL Session


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.

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.

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.

Introduction

Web Server certificates

Note


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.

User certificates


Guidelines for Choosing a Private or Commercial CA


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.

Third-party organizations create and manage commercial CAs. Choose a 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.

Introduction

Choosing commercial 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.

Choosing private CAs


Lesson: Enabling SSL on a Web Server


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.

Introduction

Lesson objectives


How to Acquire a Web Server Certificate from a Private CA


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.

You can install a Web Server certificate from the Internet Information Services (IIS) console. In the console, you can request a Web Server certificate for a Web site from a private CA, and then configure the IIS server to implement 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.

Introduction

Procedure for requesting a Web Server certificate from a private CA


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.

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.

Note


How to Acquire a Web Server Certificate from a Commercial CA


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.

When you submit a Web Server certificate request to a commercial CA, it generates a certificate request file, which you then submit to the commercial CA organization. After it reviews the certificate request and validates your 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.

Introduction

Procedure for requesting a Web Server certificate from a commercial CA


6. 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, 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.

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.

Note


SSL Configuration Options


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.

You can use the following SSL configuration 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.

Introduction

SSL configuration options


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

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.

Note


Certificate Deployment for Complex Configurations


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.

When you cluster a Web server by using clustering or Network Load Balancing 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.

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.

Introduction

Deploying certificates for clustered servers

Note


Microsoft Internet Security and Acceleration (ISA) Server enables you to publish Web servers that are located in a network segment that is protected by 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.

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.

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.

Implementing SSL for Web servers that are protected by ISA server

Note

Note


Guidelines for Enabling SSL Security


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.

When you enable SSL security to protect Web servers on your network, 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.

Introduction

Guidelines for enabling SSL security


! 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


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. ! Enforce certificate-based authentication.

Introduction

Lesson objectives


Web-based Authentication Methods


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.

By using anonymous authentication, users can access the public areas of your 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 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 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.

Introduction

Anonymous authentication

Basic authentication

Digest authentication


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.

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 authentication is a more secure authentication in IIS than 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.

You can increase the strength of basic authentication by implementing 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 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.

Note

.NET Passport

Integrated Windows authentication

Basic authentication with SSL

Client certificates


Types of Certificate Mapping


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. In one-to-one certificate mapping, you create an association between a 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.

Introduction

One-to-one certificate mapping


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.

To implement many-to-one certificate mapping, install the CA that issues 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.

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.

Note

Many-to-one certificate mapping

Mixing mappings


How to Implement Certificate Mapping in IIS


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.

When you define certificate mappings, you must first obtain the certificate that 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.

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.

Introduction

Obtaining the user certificate

Note


After you obtain the user�s certificate, configure IIS to define the one-to-one or 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.

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.

Certificate mapping in IIS

Note


How to Implement Certificate Mapping in Active Directory


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.

The first step in certificate mapping is to obtain the user certificate from the 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.

After you obtain the user�s certificate, enable IIS to use Active Directory for certificate mapping. In the IIS console, select the Windows Directory Service Mapper in the properties dialog box of the Web sites.

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.

Introduction

Obtaining the user certificate

Enabling IIS to use Active Directory for certificate mapping

Note


You can define certificate mappings in Active Directory Users and Computers. You can use the defined mappings in this console at any IIS server in the forest that enables the Windows Directory Service Mapper.

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.

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.

Using Active Directory Users and Computers for certificate mapping

Note

Note


Guidelines for Certificate Mapping


Before you define certificate mapping in your organization, collect all of the information and requirements for Web-based application security for your organization.

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.

Introduction

Guidelines


! 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. ! Enforce certificate-based authentication. ! Perform certificate mapping in Active Directory. ! Perform certificate mapping in IIS.


Objectives

Note






! Created a Group Policy object named Autoenrollment that enables Autoenrollment Settings for user objects.

! Created a C:\Temp folder. ! 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.

! The knowledge and skills to deploy SSL for a Web server. ! The knowledge and skills to enforce certificate-based authentication for a

Web server.

Prerequisites



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.








2. In the Internet Information Services (IIS) Manager console, browse to the default Web site.

a. On the Start menu, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

b. In the console tree, expand Computer (where Computer is the NetBIOS name of your computer), expand Web Sites, and then click Default Web Site.


(continued)


3. Enable SSL by running the Web Server Certificate Wizard with the following options:

• Create a new certificate

• Send the request immediately to an online certification authority

• Organization: Domain

• Organizational unit: Corporate

• Common name: Computer.Domain.msft

• Country/Region: CA (Canada)

• State/province: Manitoba

• City/locality: Winnipeg

• SSL port: 443

• Certification authority: default

a. Right-click Default Web Site, and then click Properties.

b. In the Default Web Site Properties dialog box, on the Directory Security tab, click Server Certificate.

c. On the Welcome to the Web Server Certificate Wizard page, click Next.

d. On the Server Certificate page, click Create a new certificate, and then click Next.

e. On the Delayed or Immediate Request page, click Send the request immediately to an online certification authority, and then click Next.

f. On the Name and Security Settings page, accept the default settings, and then click Next.

g. On the Organization Information page, in the Organization box, type Domain (where Domain is the NetBIOS name of your domain).

h. In the Organizational unit box, type Corporate and then click Next.

i. On the Your Site�s Common Name page, in the Common name box, type Computer.Domain.msft (where Computer is the NetBIOS name of your computer and Domain is the NetBIOS name of your domain), and then click Next.

j. On the Geographical Information page, in the Country/Region drop-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 directory named Security that refers to C:\moc\2821\ labfiles\module10.

a. Right-click Default Web Site, point to New, and then click Virtual Directory.

b. On the Virtual Directory Creation Wizard page, click Next.

c. On the Virtual Directory Alias page, in the Alias box, type Security and then click Next.

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 128-bit encryption for the Security virtual directory.

a. In the console tree, right-click Security, and then click Properties.

b. In the Security Properties dialog box, on the Directory Security tab, 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 https://Partner.Domain. msft/security.


b. In the Address bar, type https://Partner.Domain.msft/security (where 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.








2. In the C:\moc\2821\labfiles\ module10 folder, do the following tasks:

• Clear the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here check box, and copy the existing permissions.

• Remove all permissions for users.

• Add default permissions for Domain\WebAccess.

a. Open C:\moc\2821\labfiles.

b. In the C:\moc\2821\labfiles folder, right-click Module10, and then click Properties.

c. In the Module10 Properties dialog box, on the Security tab, click Advanced.

d. In the Advanced Security Settings for Module10 dialog box, clear the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here check box.

e. In the Security dialog box, click Copy.

f. In the Advanced Security Settings for Module10 dialog box, click OK.

g. In the Module10 Properties dialog box, in the Group or user names box, select Users, and then click Remove.

h. Click Add.

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.








2. Configure the properties of the Security virtual directory with the following options:

• Require client certificates

• Enable client certificate mapping


b. In the console tree, expand Computer (where Computer is the NetBIOS name of your computer), expand Web Sites, expand Default Web Site, and then click Security.

c. In the console tree, right-click Security, and then click Properties.

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 forms of authentication for the Security Web site.

a. In the Security Properties dialog box, in the Authentication and access control section, click Edit.

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, activate the Windows directory service mapper.

a. In the console tree, right-click Web Sites, and then click Properties.

b. In the Web Sites Properties dialog box, on the Directory Security 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 access account.


• User name: Web1 (on the domain controller) or Web2 (on the member server)


• Domain: Domain

6. Acquire a user certificate using the Certificates � Current User console (Certmgr.msc).


b. In the console tree, click Personal.

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.

f. On the Certificate Friendly Name and Description page, in the Friendly name box, type Web Authentication and then click Next.



i. Close the Certificates console.


(continued)


7. Connect to your partner�s Security Web site, https://Partner.Domain.msft/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 is the NetBIOS name of your domain), and then press ENTER.

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 on using your Web access account.





2. Export your User certificate by using a Base-64 encoded X.509 (.CER) format to a file named C:\temp\web.cer.



c. In the details pane, right-click the certificate that is issued to Web1 or 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)


3. Log on to the network using your domain administrative account.





.

4. In Web Sites properties, clear the Enable the Windows directory service mapper check box.


b. In the console tree, expand Computer (where Computer is the NetBIOS 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 box, and then click OK.

e. If the Inheritance Overrides dialog box appears, click Cancel.

5. In the properties of the Security virtual directory, define a 1-to-1 mapping with the following properties:

• Certificate: \\Partner\c$\temp\ web.cer

• Map Name: Web Authentication

• Account: Domain\Web2 (on the domain controller) or Domain\Web1 (on the member server)


Close all open windows and log off the network.

a. In the console tree, expand Computer (where Computer is the NetBIOS name of your computer), expand Web Sites, expand Default Web Site, and then click Security.

b. In the console tree, right-click Security, and then click Properties.

c. In the Security Properties dialog box, on the Directory Security tab, in the Secure communications section, click Edit.

d. In the Secure Communications dialog box, click Edit.

e. In the Account Mappings dialog box, on the 1-to-1 tab, click Add.

f. If the Insert disk message box appears, click Cancel.

g. In the Open dialog box, in the File name box, type \\Partner\c$\temp\web.cer (where Partner is the NetBIOS name of your partner�s computer), and then click Open.

h. In the Map to Account dialog box, enter the following information:

• Map Name: Web Authentication

• Account: Domain\Web2 (on the domain controller) or Domain\Web1 (on the member server) where Domain is the 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 access account.




• Domain: Domain(where Domain is the NetBIOS name of your domain)

7. Attempt to open https://Partner.Domain. msft/security.


b. In the Address bar, type https://Partner.Domain.msft/security (where Partner is the NETBIOS name of your partner's computer and Domain is the NetBIOS name of your domain), and then press ENTER.

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.


a. Close Internet Explorer


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

Module 11: Configuring E-mail Security

Module 11: Configuring E-mail Security iii

Instructor Notes E-mail security protects e-mail messages from modification and inspection when the e-mail is transmitted from the sender to the receiver. The Windows Server� 2003 Public Key Infrastructure (PKI) prevents the modification and inspection of e-mail messages by providing e-mail digital 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).



! Read all of the materials for this module. ! Complete the lab. ! Read the white paper, Key Archival and Management in

Windows Server 2003, under Additional Reading on the Web page on the 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.


Required materials

Preparation tasks

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


In this topic, describe how the KMS service archives the private key in an Exchange 2000 environment. Explain that although a KMS 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 Reading on the Web page on the Student Materials compact disc. In this topic, explain how the key archival process is performed by the Windows Server 2003 CA, rather than by a separate service, such as the KMS service.

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.

Remind students that there is more than one way to secure e-mail messages in 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.

E-mail Security in a Windows 2000 Environment

Changes to E-mail Security in a Windows Server 2003 Environment

Steps to Secure RFC-based E-mail Protocols

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. This page provides an overview of the following topics. Provide only a brief summary of the upcoming topics. Ask students how their organization uses e-mail certificates. Discuss the benefits and drawbacks of each certificate template strategy. You can also 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

Demonstrate each configuration step to configure the enterprise CA. Mention that although not all organizations implement role separation, it is a best practice to separate the certificate manager and key recovery agent roles.

Demonstrate each step in deploying an e-mail certificate to the organization�s 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.

Mention that the configuration steps that are in this topic are applicable to Microsoft Outlook 2000 and Outlook 2002. Do not spend time comparing the 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 Course 2821, Designing and Managing a Windows Public Key Infrastructure. This topic reviews the PKI roles that are involved in the key recovery process. Ask students what they would use to perform each step in the process. Review each guideline on the slide and answer any questions. Discuss the circumstances in which students should revoke a certificate before the private key is recovered, and when they should not revoke the certificate before the private key is recovered.

Steps to Configure Secure E-mail Messages How to Create the Required Certificate Templates

Steps for Configuring an Enterprise CA

How to Deploy E-mail Certificates

Configure Outlook 2002 for Secure E-mail Messages

How to Recover E-mail Private Keys Guidelines for Recovering E-mail Private Keys

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. The classroom does not provide an Exchange 2000 Server, so you cannot 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. Tell the students that the steps for importing the KMS database records depend 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.

Review each guideline presented on the slide and answer any student questions.

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 organization�s CA hierarchy.

Steps for Exporting a KMS Database

Steps for Importing a KMS Database

Guidelines for Migrating a KMS Database

Lab A

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.


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.

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.


The http://WebServer (where WebServer is the fully qualified domain name of 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 Certification Authority Hierarchy,� in Course 2821.

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.

Setup requirement 1

Setup requirement 2

Setup requirement 3

Setup requirement 4

Setup requirement 5

viii Module 11: Configuring E-mail Security


! 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


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.

Introduction

Objectives

2 Module 11: Configuring E-mail Security

Lesson: Introduction to E-mail Security


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.

Introduction

Lesson objectives


E-mail Security in a Windows 2000 Environment


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.

The KMS service provides the following functionality in a 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.

Introduction

E-mail security in Windows 2000


Changes to E-mail Security in a Windows Server 2003 Environment


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.

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.

If you are running Exchange 2000, you can move all key archival functions to a 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.

Introduction

Note

E-mail security in Windows Server 2003


Steps to Secure RFC-based E-mail Protocols


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.

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

Introduction

SSL ports


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.

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.

Implementing SSL

Note


Lesson: Configuring Secure E-mail Messages


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.

Introduction

Lesson objectives


Steps to Configure Secure E-mail Messages


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.

To configure secure 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.

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.

Introduction

Configuring secure e-mail messages

Note


How to Create the Required Certificate Templates


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.

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 Additional Reading on the Web page on the Student Materials compact disc.

To deploy certificates for secure e-mail messages, first choose the certificate 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.

Introduction

Note

Choosing a certificate template strategy


To create a version 2 certificate template for e-mail encryption:

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.

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.

To create a version 2 certificate template for e-mail digital signing:

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.

Creating an e-mail encryption certificate

Note

Creating an e-mail signing certificate


Steps for Configuring an Enterprise CA


Configure an enterprise CA to issue the certificates that are necessary for secure e-mail messages in an Exchange Server 2003 environment.

To configure an 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.

Introduction

Configuring an enterprise CA


How to Deploy E-mail Certificates


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.

To deploy e-mail 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.

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.

Introduction

Deploying e-mail certificates

Note


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


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.

After you acquire e-mail encryption and e-mail digital signing 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.

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.

After users select their certificate for signing e-mail, they must choose the 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.

Introduction

Choosing signing and encryption certificates

Note

Choosing a hash algorithm


After users select their certificate for encrypting e-mail, they must choose an 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.

The final step in configuring an e-mail client is to designate the default 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.

Choosing an encryption algorithm

Defining e-mail default settings


Lesson: Recovering E-mail Private Keys


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.

Introduction

Lesson objectives


How to Recover E-mail Private Keys


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.

The certificate manager performs the following initial tasks to recover the 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.

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.

Introduction

Certificate manager tasks

Note


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.

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.

KRA tasks

User tasks


Guidelines for Recovering E-mail Private Keys


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.

Guidelines


Lesson: Migrating a KMS Database to a CA Running Windows Server 2003


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.

Introduction

Lesson objectives


Steps for Exporting a KMS Database


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.

To export the KMS 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 performing the following steps: 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.

Introduction

Exporting the KMS database


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


You must import certificate and keys to a CA database in order to provide migration services for the KMS database in Exchange 2000.

The first step in importing a KMS database into the CA database is to 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.

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.

By default, an enterprise CA running Windows Server 2003 prohibits 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

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.

Introduction

Implement key archival on the enterprise CA

Note

Enable foreign certificates import

Note


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.

After the KMS database export file is available on the target CA, a CA 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.

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.

Copy the export file

Import the KMS database

Note


Guidelines for Migrating a KMS Database


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.

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.

Introduction

Guidelines


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.

This lab focuses on the concepts in this module and as a result may not 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.

Objectives

Note






! Created a Group Policy object named Autoenrollment that enables 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.

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 Materials compact disc.

Prerequisites




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.



1. Log on to the domain using your domain administrative account.





2. Create Exchange mailboxes for the Mail1 and Mail2 user accounts.

a. On the Start menu, point to All Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers.


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 GPO to the Module11 organizational unit.

a. In the console tree, right-click Module11, and then click Properties.

b. In the Module11 Properties dialog box, on the Group Policy tab, 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 attribute for the Mail1 and Mail2 user accounts. When completed, close all open windows and log off the network.

a. In the details pane, select both Mail1 and Mail2, right-click both Mail1 and Mail2, and then click Properties.

b. In the Properties On Multiple Objects dialog box, click E-mail.

c. In the E-mail box, type %username%@Domain.msft (where Domain 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 user who has been delegated permissions to create and modify certificate templates or by using your domain administrative account.

" Log on to the domain with the following credentials:




6. In Domain Security Policy, enable strong private key protection so that the user must always enter a password when accessing a certificate�s private key. When completed, close all open windows and log off the network.

a. On the Start menu, point to Administrative Tools, and then click Domain Security Policy.

b. In Default Domain Security Settings, in the console tree, expand Local Policies, and then click Security Options.

c. In the details pane, double-click System cryptography: Force strong key protection for user keys stored on the computer.

d. In the System cryptography: Force strong key protection for user 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 user who has been delegated permissions to create and modify certificate templates or log on using your domain administrative account.





2. Update Group Policy. a. Open a command prompt.


3. Open the Certificate Template console and create a new certificate template named SMIMESign, based on the Exchange Signature Only certificate template.



c. In the details pane, right-click Exchange Signature Only, and then click Duplicate 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 certificate template, select the following:

• Publish certificate in Active Directory

• Do not automatically reenroll if a duplicate certificate exists in Active Directory

• Prompt the user during enrollment and require user input when the private key is used

a. In the details pane, double-click SMIMESign.

b. In the SMIMESign Properties dialog box, on the General tab, select the Publish certificate in Active Directory check box, select the Do not automatically reenroll if a duplicate certificate exists in Active Directory check box, and then click Apply.

c. On the Request Handling tab, click Prompt the user during enrollment and require user input when the private key is used, and then click Apply.


(continued)


5. On the Extensions tab, add the Medium Assurance 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, select the following:

• Subject name format: Fully distinguished name

• Include e-mail name in subject name: Enabled

• E-mail name: Enabled

• User principal name (UPN): Enabled

a. On the Subject name tab, click Build from this Active Directory information, and then select the following:





b. On the Subject name tab, click Apply.

7. On the Security tab, assign the MailUsers group Read, Enroll, and Autoenroll permissions.


b. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type Mail and then click Check 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 template named SMIMEEncrypt, based on the Exchange User certificate template.

a. In the details pane, right-click Exchange User, and then click Duplicate Template.

b. In the Properties of New Template dialog box, in the Template display name box, type SMIMEEncrypt and then click OK.


(continued)


9. In the SMIMEEncrypt certificate template, select the following:

• Publish certificate in Active Directory

• Do not automatically reenroll if a duplicate certificate exists in Active Directory

• Archive subject�s encryption private key

• Prompt the user during enrollment and require user input when the private key is used

a. In the details pane, double-click SMIMEEncrypt.

b. In the SMIMEEncrypt Properties dialog box, on the General tab, select the Publish certificate in Active Directory check box, select the Do not automatically reenroll if a duplicate certificate exists in Active Directory check box, and then click Apply.

c. On the Request Handling tab, click Archive subject�s encryption private key.

d. On the Request Handling tab, click Prompt the user during enrollment and require user input when the private key is used, and then click Apply.

10. On the Extensions tab, add the Medium Assurance 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, select the following check boxes:





a. On the Subject name tab, click Build from this Active Directory information, and then select the following:





b. On the Subject name tab, click Apply.


(continued)


12. On the Security tab, assign the MailUsers group Read, Enroll, and Autoenroll permissions.


b. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type Mail and then click Check Names.

c. In the Multiple Names Found dialog box, 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 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.





14. Log on using your domain administrative account.




• Domain: Domain

15. Update Group Policy. a. Open a command prompt.


16. Configure DomainCA to issue the SMIMEEncrypt and SMIMESign 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 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 using your e-mail user account.


• User name: Mail1 (on the domain controller) or Mail2 (on the member server)



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 Autoenrollment process.

a. In the notification area, click the Certificate Enrollment balloon.

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 Outlook 2002 profiles with the following settings:

• Server Type: Microsoft Exchange Server

• Microsoft Exchange Server: MemberServer (where MemberServer is the NetBIOS name of your member server)


a. On the desktop, double-click Microsoft Outlook.

b. On the Outlook 2002 Startup page, click Next.

c. On the E-mail Accounts page, click Yes, and then click Next.

d. On the Server Type page, click Microsoft Exchange Server, and then click Next.

e. On the Exchange Server Settings page, in the Microsoft Exchange Server box, type MemberServer (where MemberServer is the NetBIOS name of your member server).

f. On the Exchange Server Settings page, in the User Name box, type Mail1 (on the domain controller) or Mail2 (on the member server), and then click Check Name.

If you are performing these tasks on the member server, you 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 Mail1 (on the domain controller), and then skip the activation of Outlook 2002.

a. In the User Name dialog box, in the Name box, type Mail1 (on the domain controller).

b. In the Initials box, type m1 (on the domain controller), and then click 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 mail2 (on the member server), verify the Outlook mail account configuration, and then skip the activation of Outlook 2002.

a. In the Microsoft Outlook error dialog, click Don�t Send.

b. In the Microsoft Outlook dialog, click No.

c. In the User Name dialog box, in the Name box, type Mail2 (on the member server).

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 Wizard page appears, click Activate Later, and then click Exit.

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 Wizard page appears, click Activate Later, and then click Exit.

Microsoft Outlook now starts successfully.


6. View the security settings for Outlook 2002.

a. Maximize the Inbox � Microsoft Outlook window.

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 digital signing for all outgoing messages.

a. In the Options dialog box, on the Security tab, select the following check boxes:

• 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 message with the following settings:

• To: Mail2 (on the domain controller) or Mail1 (on the member server)

• Subject: Encrypted and Signed

• Message body: This is an encrypted message.

a. On the toolbar, click New.

b. If the Using Word as your E-mail Editor balloon appears, click No Thanks.

c. Create an e-mail message with the following settings:

• To: Mail2 (on the domain controller) or Mail1 (on the member server)

• Subject: Encrypted and Signed

• Message body: This is an encrypted and digitally signed 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 partner.

a. Wait for the message to arrive from your 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.


a. Close the message.

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.




1. Log on to the domain using your domain administrative account.





2. In the DNS console, create an MX record for your mail server in your domain�s forward lookup zone.

a. On the Start menu, point to Administrative Tools, and then click DNS.

b. In the console tree, expand Computer (where Computer is the NetBIOS 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 is configured to forward unresolved DNS queries. When completed, close all open windows and log off.

a. In the console tree, right-click Computer (where Computer is the NetBIOS name of your computer), and then click Properties.

b. In the Computer Properties dialog box, click the Forwarders tab.

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 your e-mail user account.




• Domain: Domain

5. Record the e-mail address of a user in another organization, and then start Microsoft Outlook.

a. In the space provided, record the e-mail name of a user in a different organization who is participating in this exercise:

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 digitally sign all outgoing messages.

a. On the Tools menu, click Options.

b. In the Options dialog box, on the Security tab, clear the Encrypt contents and attachments for outgoing messages check box, and then click OK.

7. Create a new encrypted e-mail message with the following settings:

• To: e-mail name (where e-mail name is the e-mail address of a partner in a different organization)

• Subject: Signing between organizations

• Message body: This is a signed message.

a. On the toolbar, click New.

b. Create an e-mail message with the following options:

• To: e-mail name (where e-mail name is the e-mail address of a partner in a different organization)

• Subject: Signing between organizations

• Message body: This is a signed message.

c. On the tool bar, click Send.

d. In the Signing data with your private signature key dialog box, in the CryptoAPI Private Key box, type P@ssw0rd and then click OK.

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 sign the e-mail message, Signing between organizations.

a. In your Inbox, double-click the message titled Signing between organizations.

b. In the message window, click the red ribbon.


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