Module 14: Designing a Public Key Infrastructure Overview Introducing a Public Key Infrastructure Using Certificates Examining the Certificate Life Cycle Choosing a Certification Authority Planning a Certification.
Download
Report
Transcript Module 14: Designing a Public Key Infrastructure Overview Introducing a Public Key Infrastructure Using Certificates Examining the Certificate Life Cycle Choosing a Certification Authority Planning a Certification.
Module 14: Designing a
Public Key
Infrastructure
Overview
Introducing a Public Key Infrastructure
Using Certificates
Examining the Certificate Life Cycle
Choosing a Certification Authority
Planning a Certification Authority Hierarchy
Mapping Certificates to User Accounts
Managing CA Maintenance Strategies
A Public Key Infrastructure (PKI) is the combination of
software, encryption technologies, and services that
enables organizations to protect the security of their
communications and business transactions. A PKI relies
on the exchange of digital certificates between
authenticated users and trusted resources. You can use
certificates in a PKI to secure data and manage
identification credentials from users both within and
outside your organization.
At the end of this module, you will be able to:
Describe the basic components of a PKI.
Define how certificates can be used in a PKI to certify applications
and services.
Define the basic functions of certificates within a certificate life
cycle.
Choose between public and private certification authorities (CAs).
Plan a hierarchy for organizing CAs in a network.
Use certificate mapping to apply user permissions to users who are
not included in your organization's Active Directory™ directory
service.
Plan recovery and maintenance strategies for CAs.
Introducing a Public Key Infrastructure
Key and Certificate
Management Tools
Certificate
Publication Point
Certification
Authority
Digital
Certificate
Certificate
Revocation List
Public Key–Enabled
Applications and Services
A PKI provides a framework of services, technologies,
protocols, and standards that you can use to deploy and
manage a strong and scalable security system.
The PKI of a network consists of the following basic
components:
Digital Certificate
Key and Certificate Management Tools
Certification Authority
Certificate Publication Point
Public Key–Enabled Applications and Services
Certificate Revocation List (CRL)
Digital Certificate
An electronic credential, consisting of a public key and
a private key, used to authenticate users. Certificates
provide the foundation of a PKI.
Key and Certificate Management Tools
Tools for administering and auditing digital certificates.
The certificates snap-in is used to manage certificates
on Microsoft® Windows® 2000-based CA.
Certification Authority
A trusted entity or service that issues digital certificates.
CAs can be configured< as either enterprise or standalone CAs. Enterprise CAs rely on Active Directory to
authenticate users, whereas stand-alone CAs do not. To
configure a Windows 2000-based computer as a CA,
you must install Certificate Services.
Certificate Publication Point
A directory service or other location where certificates
are stored and published. Active Directory is the
publication point for certificates for a Windows 2000based CA.
Public Key–Enabled Applications and Services
Applications and system services that require the
secure transfer of information. Applications that are
enabled for certificate-based security include Microsoft
Outlook® and Microsoft Internet Explorer. System
services that can be secured by using certificates
include Encrypting File System (EFS) and Internet
Protocol Security (IPSec).
Certificate Revocation List (CRL)
A list of certificates that have been revoked before
reaching the scheduled expiration date.
Using Certificates
Identifying Uses for Certificates
Determining Certificate Requirements
Using Certificate Templates
Before implementing certificate-based authentication,
you must determine which network resources, such as
data, applications, and services, must be secured. You
must also identify which users will need access to these
secured resources and the type of access rights that
will be required. To simplify administration of
certificates, you can use templates to predefine the
basic content of a certificate.
In this lesson you will learn about the following topics:
Identifying uses for certificates
Determining certificate requirements
Using certificate templates
Identifying Uses for Certificates
Applications
Secure Mail
Software Code Signing
Secure Web Communications
Secure Web Sites
Custom Security Solutions
Services
Smart Card Logon Process
IPSec Client Authentication
Encrypting File System
Applications
Secure Mail
Software Code Signing
Secure Web Communications
Secure Web Sites
Custom Security Solutions
Certificates can be used with a
variety of applications and
security services to provide
authentication, data integrity,
and security. After you have
identified the uses for
certificates in your
organization, you can design
an appropriate public key
security solution.
Applications
Certificates can provide a secure solution for:
Secure mail. Configure the Secure Multipurpose Internet Mail
Extension (S/MIME) protocol to ensure the integrity, origin, and
confidentiality of e mail messages.
Software code signing. Configure digital signatures to ensure the
integrity of software that is distributed over a network.
Secure Web communications. Use certificates with Secure Sockets
Layer (SSL) or Transport Layer Security (TLS) protocols for
authenticating and encrypting communications between servers
and clients.
Secure Web sites. Use certificates to authenticate access to secure
Web sites.
Custom security solutions. Use certificates to provide
confidentiality, integrity, authentication, and non-repudiation for
custom applications.
Services
Services
Certificates can provide a secure
solution for:
Smart Card Logon Process
IPSec Client Authentication
Encrypting File System
Smart card logon process. Use
certificates to authenticate
users with smart card devices
attached to their computers.
IPSec client authentication.
Use certificates to authenticate
transmissions between two
computers by using IPSec.
EFS. Use certificates to
distribute public and private
keys that protect the EFS file
encryption key.
Determining Certificate Requirements
Identify applications that require certificates
Determine the required level of security
Identify users, computers, and services requiring
certificates
Determine how to protect private keys
When planning certificate use, you must determine the
certificate requirements of your network. The
requirements will be based on applications, security
levels, and services running on the network. To
determine the certificate requirements of your network,
you must do the following:
Identify applications that require certificates.
Determine the required level of security.
Identify users, computers, and services requiring
certificates.
Determine how to protect private keys.
Identify applications that require certificates.
Within your organization, determine the risks associated
with exposing information to unauthorized users. For
example, a concern may be protecting e-mail messages
between business partners when exchanging
confidential data.
Determine the required level of security.
Select the level of security needed to protect the
integrity or privacy of information. Factors to consider
are length of the private key, cryptography algorithm,
certificate lifetime, and renewal cycle. For example, use
a longer private key length and a shorter certificate
lifetime to provide security for highly valuable
information
Identify users, computers, and services requiring certificates.
Identify the users, computers, and services that will
participate in the secure exchange of information. For
example, determine which users from external partners
will have access to an internal inventory database.
Determine how to protect private keys.
Select the level of security required to protect the
private key. Options include storing the private keys in
the user's profiles or, for improved security, requiring
the use of smart cards to store private keys.
Using Certificate Templates
Single-purpose Templates
E-mail
EFS
Multi-purpose Templates
EFS
E-mail
SSL
Using Certificate Templates A certificate template
defines the format and content of a certificate.
Certificate templates relieve users from making
decisions about the types of certificates that they need.
Instead, for the certificates that the user receives, users
can rely on the judgment of the certificate administrator.
Certificate templates are only used when the server that
is running Certificate Services is an enterprise CA.
Tip: When creating custom templates, select functionbased names for the templates. Function-based names
allow users to easily select the proper certificates based
on the tasks that the user is performing at that time.
When creating a certificate by using templates, you can
choose from the following:
Single-purpose template. Generates certificates that
can be used only for a single application. For example,
the Smart Card Logon certificate template is designed
for only smart card logon. Other single-purpose
templates include templates for EFS or S/MIME.
Multipurpose template. Generates certificates that can
be used for a number of applications, such as SSL,
S/MIME, and EFS. For example, a user certificate can
be used for both user authentication and EFS
encryption.
Certificate templates are secured by modifying the
discretionary access control list (DACL) of each
certificate template. Only users or groups that are given
the Enroll permission in the DACL will be allowed to
request a specific certificate template.
Note: Certificate templates are only installed and used
when you configure Windows 2000 Certificate Services
as an enterprise CA.
Examining the Certificate Life Cycle
Certificate Enrollment
Certificate Distribution
Certificate Revocation
Certificate Renewal
Certificate Auditing
The certificate life cycle defines the processes by which
a CA requests, issues, revokes, renews, and audits
certificates. A CA is an entity that has been entrusted to
issue certificates to individuals, computers, or
organizations to confirm their identities for current and
future transactions.
You define a certificate life cycle to meet your
organization's security requirements. The management
and configuration choices that you make for each stage
in the certificate life cycle will depend on the security
needs of your organization.
The Life Cycle of a Digital Certificate
In this lesson you will learn about the following topics:
Certificate enrollment
Certificate distribution
Certificate revocation
Certificate renewal
Certificate auditing
Certificate Enrollment
1
4
Verify Information
5
Create Certificate
6
Send or Post Certificate
Public
Enrollment
Information
Private
2
3
Certificate
Request
Client Computer
Certification Authority
To participate in a PKI, users and computers must
request and receive certificates from a CA. The process
of requesting and receiving a certificate is known as
enrollment. Typically, a user initiates enrollment by
providing unique information and a newly generated
public key. The CA uses the information provided to
authenticate the identity of the user before issuing a
certificate.
The process of requesting and issuing a certificate
varies with the CA and its policies, but can generally be
broken down into the following six steps.
Certificate Distribution
Certificate
Approved
Active Directory
Web page
Web
page
Stand-alone Requests
Web page
or Wizard
Web
page
CA
Wizard
Enterprise Requests
Certificates can be used with a variety of applications
and security services to provide authentication, data
integrity, and security. After you have identified the uses
for certificates in your organization, you can design an
appropriate public key security solution.
Processing Stand-alone CA Requests
When a user submits a certificate request to a Windows
2000 stand-alone CA, the request is considered pending
until the CA administrator approves or rejects the
request based on the submitted credentials of the user.
The certificate requester can view the Certificate
Services Web page to check the status of pending
certificates.
Processing Enterprise CA Requests
When a user submits a certificate request to a Windows
2000 enterprise CA, the request is immediately
processed because an enterprise CA uses Active
Directory to verify users. The certificate request will
either immediately fail or immediately be granted. If it is
granted, the certificate is issued, and the user will be
prompted to install it.
From an enterprise CA, a user can request a certificate
by using the Certificate Request wizard. The Certificate
Request wizard is launched from the Certificates
console and allows a user to select from different
certificate types, depending on the user's access rights.
Alternatively, certificates can be requested by
connecting to http://servername/certsrv, where
servername is a server with Certificate Services
installed.
Note: The CA administrator can use Group Policy to
configure the CA so that computers can automatically
request certificates without user intervention. Automatic
certificate requests free the administrator from explicitly
enrolling each computer-related certificate.
Certificate Revocation
Active Directory
CRL
CRL
CA Compromised
Employment
Status Changes
Private Key
Compromised
Certificate
Obtained
Fraudulently
Certificate Status
Changes
Certificate Server
Client Computer
Revoking a certificate may be necessary when some
security-related event, such as the dissolution of a
partnership with another company, creates a situation in
which it is no longer appropriate to consider a
certificate valid.
Certificates may need to be revoked if:
The security of the CA that issued the certificates is
compromised.
The recipient of certificate leaves an organization, or if
the recipient's employee status changes in any
significant way.
The private key of the certificate is compromised (for
example, a lost smart card).
A certificate was obtained fraudulently.
A certificate was issued to an individual who is no
longer a trusted partner.
Windows 2000 Certificate Services supports the use of industrystandard CRLs to distribute information about revoked certificates.
You publish a CRL by using the Certification Authority snap-in.
When you publish a CRL, it is stored in Active Directory, where
users and computers can retrieve it. The users and computers will
then store the CRL in their local caches.
You must establish a balance between the need to publish CRL
information as frequently as possible and the impact that
publication has on network traffic and server load. Frequent CRL
publication causes the change in the status of the certificate to be
known more quickly but also increases server load. Network traffic
is also affected because clients need to download the CRL each
time it expires and is republished.
Important: If the CRL is not available, a certificate cannot be verified
and access will be denied.
Certificate Renewal
1/1/2000
1/1/2000
Root CA
1/1/2000
Issuing CAs
Planning CA
Certificate Lifetime
Planning Certificate
Renewal
1/1/2000
1/1/2000
All certificates, including those issued to CAs and
users, have a finite lifetime. When a certificate reaches
its expiration date, it automatically becomes invalid and
can no longer be used. An expired certificate can be reissued or renewed with valid dates.
Planning CA Certificate Lifetime
When a CA issues a certificate to a user or computer,
the CA ensures that the validity period of the new
certificate falls within the validity period of the CA's own
certificate. This means that if the CA's certificate is valid
for only an additional six months, the longest validity
period that the CA will issue for a new certificate is six
months.
You need to ensure that a CA certificate has a sufficient
lifetime so that issued certificates do not need to be
renewed too frequently. Excessive renewal of
certificates may add an additional burden to users.
Whenever a certificate expires, the user needs to
contact the CA to request a new certificate because they
will need to acquire updated certificates.
Planning Certificate Renewal
An issuing CA issues certificates directly to users,
rather than to other CAs. Issuing CAs are responsible
for managing a much larger number of certificates than
a CA that issues certificates only to CAs. Frequently
renewing a CA's certificate with a new key makes an
attack on any one key less valuable to the attacker and
less damaging to your PKI.
Certificate Auditing
Certificate Services
Log and Database
Certificate
Server
01ea812…
1f21911…
Revoked Certificates
Issued Certificates
Pending Requests
Failed Requests
6b323e1…
Each CA maintains an audit trail that can be viewed in the
Certification Authorities Microsoft Management Console (MMC).
The audit trail records all of the certificate requests and the issued
certificates that are still active. The audit trail records all
transactions, including failed requests, and includes all of the
information contained in each issued certificate. The Certification
Authorities MMC console provides the ability to revoke a certificate
and add it to the revocation list.
An audit trail may be required to meet the security obligations of
the CA and your organization. You can query the audit trail to locate
and view information about any certificate request or any certificate
that the CA has issued. For example, if an issued certificate was
used for an illegal activity or for a fraudulent transaction, you might
be asked to provide records to security or law-enforcement
personnel.
In addition, you may need audit trail records to monitor
the network for security breaches. For example, you can
view the audit trail to detect failed certificate requests or
to determine whether someone has improperly obtained
certificates.
Note: You can view the contents of the Windows 2000
Certificate Services log and database by using the
Certification Authority snap-in.
Choosing a Certification Authority
Choosing a Commercial CA
Choosing a Private CA
Selecting a CA Policy
Discussion: Choosing a CA
There are two types of CAs that can provide certificates
for an organization: a commercial CA maintained by a
certificate-issuing company, or a private (internal) CA.
Private CAs require an administrative model for issuing
certificates and providing security for the root CA.
If you select a private CA, you will need to choose what
type of certificate policy (not to be confused with Group
Policy) you will implement for your organization's
certificate deployment.
In this lesson you will learn about the following topics:
Choosing a commercial CA
Choosing a private CA
Selecting a CA policy
Discussion: Choosing a CA
Choosing a Commercial CA
Request
External Customers
Issue
Commercial CA
Secure
Access
External Customers and
Clients
Outsourced Certificate
Management
Internal Web Server
Commercial CAs are created and managed by a thirdparty company. Choose a commercial CA when you
conduct most of your business with external customers
and clients, and you want to outsource the management
and issuance of certificates.
The following table outlines some of the advantages and
disadvantages of choosing a commercial CA.
Advantages
Disadvantages
Creates a greater level of confidence for
customers to conduct secure
transactions with the organization
Takes advantage of the expertise of a
professional service provider.
Potentially provides less flexibility in
managing certificates
Allows an organization to immediately
use certificate-based security while
developing an internally managed PKI
Takes advantafe of the provider's
understanding of teh technical,legal, and
business issues associated with
certificate use.
May require two different management
standards, one for internally issued
certificates and one for commercially
issued certificates.
Typically involves per-certificate costs.
Access to the CA must always be
available to access the CRL at the
commercial CA.
Choosing a Private CA
Request
External Partners
Issue
Private CA
Secure
Access
External Partners
Internal Certificate
Management
Web Server
Private CAs are created and managed internally within
the organization. Choose a private CA when you
conduct most of your business with partner
organizations and you want to maintain control of how
certificates are issued.
The table outlines some of the advantages and
disadvantages of choosing a private CA.
Advantages
Disadvantages
Allows a company to tightly
control its security policies.
Companies must manage their
own certificates.
Allows a company to manage its
certificate policy to match its
overall security policy.
Deployment schedule may take
longer than with a commercial
service provider.
Selecting a CA Policy
Active
Directory
Enterprise Policy
Administrator
Stand-Alone Policy
When installing Certificate Services to create a private
CA, you must select one of two different CA policy
models. The CA policy that you choose will determine
the characteristics and behavior of the CA. Choose the
policy model based on the role that the CA will play in
your organization's PKI deployment.
Enterprise Policy
A Windows 2000 enterprise CA uses Active Directory as
the user registration database. An enterprise CA has the
simplest administration model with the lowest overhead
per certificate. Choose an enterprise CA if you will issue
certificates to users and computers within your
organization.
Enterprise CAs have the following characteristics:
Enterprise CAs are dependent on the presence of Active Directory.
If a requestor does not have an account in Active Directory, the
requestor cannot acquire a certificate from an enterprise CA.
Enterprise CAs use domain user accounts to authenticate a
certificate requestor. Users who have appropriate permissions can
request a certificate from any enterprise CA.
Enterprise CAs use certificate templates to define certificates that
meet a particular purpose, and as a means of defining an
enrollment policy for the forest.
Note: Only members of the Enterprise Admins group can create an
enterprise CA.
Stand-Alone Policy
A stand-alone CA can function independently of Active
Directory. Choose a stand-alone CA if you will issue
certificates to users and computers outside of your
organization.
Stand-alone CAs have the following characteristics:
Stand-alone CAs require certificate requestors to explicitly supply
all identifying information about themselves and the type of
certificates desired (unlike a request to an enterprise CA, in which
the user's information is already in Active Directory and a certificate
template describes the certificate type). Using stand-alone CAs also
allows an organization to customize the information that may be
required from a user.
Stand-alone CAs regard all CA requests as pending until the
administrator of the stand-alone CA (by using the Certification
Authority console) verifies the identity of the requestor and allows
the request.
Stand-alone CAs cannot issue certificates for smart card
authentication to a Windows 2000 domain. However, other types of
certificates, such as a Web client certificate, can be issued and
stored on a smart card.
Stand-alone CAs do not use certificate templates. Only enterprise
CAs use certificate templates.
Discussion: Choosing a CA
CA Solution Must:
Provide Secure Online Ordering for Customers.
Manage User Accounts Internally.
Require Customers to Apply for and Receive Approval
to Enter Web Site.
When implementing Certificate Services, you must
choose between a private and a commercial CA. This
scenario shows how both types of CAs can be
integrated to provide a secure PKI solution.
Scenario
As the security architect, you are designing a PKI for
your organization. Your organization has just entered
into a partnership with a large retailer. Your organization
will provide online ordering for customers, and will
manage user accounts internally. Customers must apply
for and gain approval before they can access the Web
site. You need to provide a secure method for
customers to conduct sales transactions over the
Internet.
Your answers must:
Provide secure online ordering for customers
Manage user accounts internally
Require customers to apply for and receive approval to
enter Web site
Planning a Certification Authority Hierarchy
Examining a CA Hierarchy
Securing a CA
Planning a CA Hierarchy Based on Usage
Planning a CA Hierarchy Based on Organizational
Structure
Planning a CA Hierarchy Based on Location
The Windows 2000 PKI is based on a hierarchical CA
model, with a root CA and a hierarchy of subordinate
CAs beneath it. A certification hierarchy composed of
secure CAs provides scalability, ease of administration,
and compatibility with a growing number of commercial
and other third-party CAs. You can design a hierarchy
on the basis of usage, organization, or geography.
In this lesson you will learn about the following topics:
Examining a CA hierarchy
Securing a CA
Planning a CA hierarchy based on usage
Planning a CA hierarchy based on organizational
structure
Planning a CA hierarchy based on location
Examining a CA Hierarchy
Root CA
Subordinate
CAs
CA Database Capacity
Administrative Delegation
Enterprise Reorganization
Service Availability
Certificate Publication
Issuing
CAs
In its simplest form, a certification hierarchy consists of
a single CA. Large organizations typically require
multiple CAs due to the large number of services and
applications requiring certificates. Multiple CAs are
arranged in a hierarchy with clearly defined parent/child
relationships.
In a CA hierarchy, each parent CA certifies the child CAs
below it. The CA at the top of a hierarchy is called the
root authority or root CA. The child CAs of the root CAs
are called subordinate CAs. The root CA is used only to
sign subordinate CA certificates and the CA certificate
for the root CA itself. Below the subordinate CAs are
issuing CAs that issue certificates directly to users and
computers.
A certificate trust list (CTL) is a set of certificates that
the administrator determines to be trustworthy. The CTL
defines the certification path from the issuing CA up to
the root CA. For a client authentication certificate to be
used successfully, a CA listed in the CTL must issue the
certificate.
Some guidelines and considerations for designing a CA
hierarchy include:
CA Database capacity. As a recommendation, a single
Windows 2000 CA is designed to support up to 250,000
users.
Note: Microsoft has tested individual servers running
Windows 2000 Certificate Services that have managed
more than one million certificates.
Administrative delegation. CA hierarchies can span
multiple Active Directory forests. A subordinate CA can
be in the same domain as the parent, in a child domain
under the parent domain, or in a domain in a separate
forest. After you create a subordinate CA, you can
delegate management of that CA to a group of
administrators by using Group Policy.
Enterprise reorganization. You can reorganize a CA
hierarchy by adding or removing a CA and its
associated users from a CA hierarchy. However, you
cannot move a subset of users on a single CA to a new
CA without forcing the users to re-enroll with the new
CA.
Service availability. You can install multiple CAs in a
forest to ensure that at least one CA is always available
to process certificate enrollment requests.
Certificate publication. For an enterprise CA to publish a
user certificate to the user object in Active Directory, the
enterprise CA must have network connectivity to a
domain controller.
Note: CA policies can be mixed in a network. For
example, a network might have a stand-alone root CA
with enterprise subordinate CAs.
Securing a CA
Manually Issued
Certificates
Offline
Root CA
Subordinate
CAs
Securing the root CA is fundamental to the security of a
PKI. In Windows 2000, if a user or computer trusts the
root CA (by having its certificate in the user's or
computer's Trusted Root CAs certificate store), the user
or computer trusts every subordinate CA in the
hierarchy. The only exception is when a subordinate CA
has had its certificate revoked by the issuing CA or has
an expired certificate.
Securing the Offline Root CA
Securing an offline root CA is generally accomplished
by removing the root CA from the network and storing it
in a vault or other secure location. Establishing complex
procedures for creating new subordinate CAs, such as
requiring multiple operators to confirm actions
simultaneously, can also enhance physical security.
Issuing Certificates from an Offline CA
Offline CAs issue certificates to subordinate CAs
manually. This configuration, although more secure,
does add to administrative overhead.
During installation of a subordinate CA, a signed
certificate request is created, and this certificate request
must be manually delivered to the offline CA by using
removable media. When the offline CA receives the
request, it creates a message that contains the CA
certificate from the original request. The CA certificate
must then be physically carried back to the subordinate
CA, and only then is the installation of the subordinate
CA complete. In addition, administrators must manually
publish certificates to Active Directory.
Planning a CA Hierarchy Based on Usage
Root CA
Corporate CA
Subordinate CAs
Projects
Issuing CAs
SSL Client
SSL Server
E-Mail
Extranet
A usage hierarchy is based on the types of services and
applications that require certificates. As shown in the
preceding illustration, the root CA is at the top of the
hierarchy and has a self-signed certificate. The CAs
directly subordinate to the root CA are organized based
on the function of the certificates that the CA serves.
The subordinate CAs use certificates signed by the root
CA.
Below the subordinate CAs are a series of issuing CAs.
Issuing CAs issue certificates directly to users and
computers. The issuing CAs are organized by the type
of service or application requiring certificates. For
example, you may want to create a CA solely to issue
certificates for secure e-mail.
Planning a CA Hierarchy Based on Organizational
Structure
Root CA
Certificate
Chain
Subordinate CAs
Customers CA
Permanent
Employees CA
Partners CA
Employees CA
Contractors CA
Issuing CAs
Issuing CA
An organizational hierarchy is based on the
administrative structure of the organization. In the
organizational hierarchy model, the CAs directly
subordinate to the root CA are organized by the type of
business relationship-such as customers, partners, or
employees-that users have with the organization.
The issuing CAs may be organized along such
organizational boundaries as permanent employees and
contractors. The issuing policy might be based on the
organization of user accounts, so that stronger security
methods are applied to independent contractors,
temporary employees, or external business partners.
Planning a CA Hierarchy Based on Location
Root CA
Subordinate CAs
Asia
Europe
Sales
Marketing
Issuing CAs
USA
Engineering
Configuring a CA hierarchy by location allows you to
issue certificates according to the location of external
users or business partners. Issuing certificates based
on location may be a requirement due to legal
limitations (such as encryption key lengths imposed by
a country) or some other security export regulations.
The issuing CAs can be based on departments located
in each geographic location.
Mapping Certificates to User Accounts
One-to-One Mapping
Many-to-One Mappings
Your organization may need to support authentication of
external users who do not have an account in Active
Directory. Certificate mapping allows an organization to
provide access to a user based on the user's ownership
of a valid authentication certificate obtained from
outside the organization.
When certificate mapping is enabled, users are
authenticated in Active Directory on the authority of
these mapped certificates, and are granted rights and
permissions based on the authentication.
Certificate mapping can be configured in the following
ways:
One-to-one. Creates an association from an individual
certificate to a corresponding user account in Windows
2000.
Many-to-one. Creates an association for all certificates
from a specific CA to a Windows 2000 user account.
One-to-One Mapping
User Certificate
Mapping
User Account
1. Single Certificate Is Mapped to
a Single User Account
2. User Is Authenticated Using the
Mapped User Account
3. User Receives Rights and
Permissions Permitted by the
User Account
Resources
In one-to-one certificate mapping, you create an
association between an individual certificate held by a
user and a corresponding user account in Windows
2000. After a certificate has been mapped to the user
account in Windows 2000, the holder of the certificate is
authenticated based on the mapped Windows 2000 user
account. Following authentication, the user is granted
the rights and permissions permitted by the mapped
user account.
Manually administering one-to-one mapping requires
more administrative effort than administering many-toone mapping. Use one-to-one mapping when you have a
relatively small number of clients.
Tip: If you use one-to-one mapping for large numbers of
clients, consider developing custom Web enrollment
pages by using Active Server Pages (ASP) technology
to automate the mapping process.
Many–to–One Mappings
User Certificates
Mappings
User Account
1. All Certificates Issued by a CA Are
Mapped to a Single User Account
2. User Is Authenticated Using the
Mapped User Account
3. User Receives Rights and
Permissions Permitted by the
User Account
Resources
Many-to-one Certificate mappings map all certificates
from a single CA to a single Windows 2000 user
account. Many-to-one mapping allows any user who has
received a certificate from the CA to be granted the
access rights that are assigned to the Windows 2000
user account.
Many-to-one mapping is useful for authenticating large
numbers of users who may require access to a given
resource on your network, such as an internal Web site.
The CA that issues certificates to these users must be
installed as a trusted root for your site, domain,
organizational unit (OU), or forest. You can then set
rules that map all certificates issued by that CA to a
single user account in Windows 2000.
Mapping rules are set that check the information that is
contained in users' certificates, such as the users'
organization and the issuing CA, to determine whether
the information matches the criteria in the rules. When
the information in users' certificates matches the rules,
users are mapped to a specified user account. The
permissions set on the user account will apply to all
users who hold certificates issued from the trusted CA.
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 map your employees to a user
account that grants read access to the entire Web site.
Then, you can map consultants and employees of
business partners to other user accounts that allow
access only to nonconfidential information and selected
proprietary information.
Managing CA Maintenance Strategies
Planning a CA Recovery Strategy
Transferring Certificates Between Computers
A failed CA can result in requiring the reissue of all
certificates issued by that CA. If the failed certification
authority has subordinate CAs, all certificates issued by
the subordinate CAs must also be reissued.
CAs must be protected to ensure that a failed CA and its
Certificate Services database can be restored.
Protecting CAs includes planning a CA recovery
strategy and backing up or transferring certificates
between computers.
In this lesson you will learn about the following topics:
Planning a CA recovery strategy
Transferring certificates between computers
Planning a CA Recovery Strategy
Recovering from a Hardware Failure
Recovering from a Security Compromise
Minimizing Risk of CA Failure
A recovery plan must be developed to ensure that CAs
can be restored if Certificate Services fails or if a CA is
compromised. A failed or compromised CA can result in
valid certificate holders being denied access to
resources.
Recovering from a Hardware Failure
CAs can fail for a variety of reasons, such as failure of a
server hard drive, failure of a network adapter, failure of
a server, or corruption of the certification authority's
database.
If you cannot recover from a hardware failure, configure
a replacement server with the same computer name and
Internet Protocol (IP) address. After replacing the server,
use Windows 2000 Backup or the Certification Authority
Restore wizard to restore the CA from the most recent
backup.
Important: The restoration of a failed CA requires that
IIS also be restored, because the Web Enrollment
Support pages included with Certificate Services update
the IIS metabase.
Recovering from a Security Compromise
When a CA has been compromised, you must revoke the CA's
certificate. Revoking a CA's certificate invalidates the CA and its
subordinate CAs, in addition to invalidating all certificates issued
by the CA and its subordinate CAs. If you discover a compromised
CA, perform the following tasks as soon as possible:
1.
Revoke the compromised CA's certificate.
2.
Publish a new CRL containing the revoked CA certificate.
Caution: Client applications will store the previous CRL until it
expires. The updated CRL will not be downloaded until the outdated
CRL expires.
3.
Remove compromised CA certificates from Trusted Root
Certification Authorities stores and the CTL.
4.
Notify all affected users and administrators of the compromise. All
certificates issued by the affected CAs will be revoked.
5.
Deploy new certificates to replace the affected certificates.
Minimizing Risk of CA Failure
You can use the following preventive practices to reduce the risk of
CA failures and to minimize the disruption of CA services:
Provide duplicate CA services so that if one server is offline, another
server can still issue the appropriate certificates.
Back up CAs frequently so that they can be restored with a minimal
loss of data.
Install Certificate Services on hard disks by using disk arrays that
use redundant array of independent disks level 5 (RAID-5)
protection.
Prepare recovery plans and train administrative staff on recovery
plans.
Maintain records of all server and CA configuration information so
that exact configurations can be easily restored.
Maintain replacement servers for immediate recovery.
In some cases, you may want to transfer a certificate
from one computer to another. For example, if a CA is
being restored or a certificate holder is setting up a new
computer, you will export the certificate to the new or
repaired computer. You can use the import and export
capabilities in the Certificates MMC console to save and
restore certificates.
Exporting a Certificate
You might want to export a certificate to:
Back up a certificate and its associated private key
Copy a certificate for use on another computer.
Remove a certificate and its private key from the
certificate holder's current computer for installation on
another computer.
When you export a certificate, you copy the certificate
from its certificate store to a file that uses a standard
certificate storage format.
Importing a Certificate
You might want to import a certificate to:
Restore a damaged or lost certificate that you previously
backed up.
Install a certificate and its associated private key from a
computer that the certificate holder was previously using.
Install a certificate that another user, computer, or CA
sent to you in a file.
When you import a certificate, you copy the certificate
from a file that uses a standard certificate storage
format to either your user account certificate store, or
your computer account certificate store.
Transferring Certificates Between Computers
Exporting a Certificate
Backup Certificate and Private Key
Copy a Certificate from Computer
to Computer
Uninstall the Initial Certificate
Restore from Damage or Loss
Transfer from a Previous User’s
Computer to a New Computer
Install the Initial Certificate
Importing a Certificate
Lab A: Using Certificate-based Authentication
Lab A: Using Certificate-based Authentication
After completing this lab, you will be able to:
Create a CA hierarchy.
Load a user certificate.
Configure a Web server to use certificates.
Configure a Web server to require certificates for
authentication.
Revoke an issued certificate.
Prerequisites
Before working on this lab, you must have:
Knowledge of designing CA hierarchies.
Knowledge of deploying server certificates.
Knowledge of how to design certificate mapping to user
accounts.
Lab Setup
This lab environment includes the following resources:
The London computer configured as an enterprise root
CA for the nwtraders.msft forest.
Two computers, with one computer acting as the
enterprise subordinate CA.
Exercise 1: Configuring an Enterprise Subordinate CA
Scenario
Northwind Traders needs to secure its PKI. Northwind
Traders currently has a single enterprise root CA at its
London office. A failure of the London server would
require a PKI redeployment. Northwind Traders needs to
mitigate the risk of redeployment.
Goal
In this exercise, one of the two computers in your child
domain is configured to function as an enterprise
subordinate CA for the Northwind Traders forest.
Online Demo
Exercise 2: Installing a User Certificate Using MMC Scenario
User accounts and passwords are vulnerable to
interception by a network monitor, known as a network
sniffer, capturing them on the network. To prevent this
risk, a decision has been made to use certificate-based
authentication when accessing the Security Web site
located on the company's Web server.
Goal
In this exercise, a user certificate will be requested by
using the Certificates console in MMC.
Online Demo
Exercise 3: Configuring the Web Server to Use Certificatebased Authentication Scenario
User accounts and passwords are vulnerable to capture
by a network sniffer. To prevent this risk, a decision has
been made to use certificate-based authentication when
accessing the security subsite located on the division's
Web server.
Goal
In this exercise, you will configure a Web server to
require certificate-based authentication. User
certificates will be mapped to Active Directory accounts
within IIS.
Online Simulation
Exercise 4: Accessing a Web Site Using Certificate
Authentication Scenario
User accounts and passwords are vulnerable to capture
by a network sniffer. To prevent this risk, a decision has
been made to use certificate-based authentication when
accessing the security subsite located on the division's
Web server.
Goal
In this exercise, certificate-based authentication is
verified to ensure it is functional for the security subsite
on the division's Web server.
Online Demo
Exercise 5: Revoking a Certificate Scenario
Two users have resigned from Northwind Traders. Due
to their positions in the company, their user accounts
were immediately terminated, and you have been asked
to revoke their certificates that grant them access to the
Security Web site.
Goal
In this exercise, the certification authority console is
used to revoke both certificates and to publish the CRL.
Online Demo
Exercise 6: Testing the Certificate Revocation List Scenario
One of the former employees is attempting to access
the Security Web site by using their revoked certificate
for authentication.
Goal
In this exercise, the successful revocation of the former
employees' certificates is verified.
Online Demo
Review
Introducing a Public Key Infrastructure
Using Certificates
Examining the Certificate Life Cycle
Choosing a Certification Authority
Planning a Certification Authority Hierarchy
Mapping Certificates to User Accounts
Managing CA Maintenance Strategies