Tải bản đầy đủ (.pdf) (77 trang)

Microsoft Press windows server 2008 Policies and PKI and certificate security phần 5 docx

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (926.68 KB, 77 trang )

280 Part II: Establishing a PKI
Figure 12-12 OCSP Response Signing enables the OCSP No Revocation Checking extension
Case Study: Certificate Template Design
You are responsible for designing certificate templates for your organization. The software
development department has created several custom applications that require digital signing
prior to network deployment. Digital signatures are required to meet the company’s security
policy regarding custom application security. The company uses a mix clients running
Windows XP and Windows Vista and servers running Windows Server 2003 and Windows
Server 2008.
Requirements
To meet the security policy, the manager of the security department has provided you with the
following requirements:
■ The code-signing certificate must be stored on a Gemalto .NET Base CSP smart card.
■ Only members of the Code Signing group can request a code-signing certificate.
■ All initial code-signing certificate requests are subject to the approval of the company’s
notary public.
Chapter 12: Designing Certificate Templates 281
■ If you already have a code-signing certificate, you can reenroll without having to meet
with the notary public again.
■ The code-signing certificate must be valid for four years.
■ The code-signing certificate must never reuse a previous key pair.
■ The code-signing certificate must have a key length of 1,024 bits.
Case Study Questions
1. What MMC console do you use to perform certificate template management?
2. Does the default Code Signing certificate template meet the design requirements?
3. Can you modify the default Code Signing certificate template? If not, what would you
do?
4. Should you create a version 2 or a version 3 certificate template?
5. In the following table, specify the settings on the General tab to meet the design
requirements for your custom code-signing certificate template.
6. In the following table, specify the settings on the Request Handling tab to meet the


design requirements for the custom code-signing certificate template.
Attribute Your recommended design
Template display name
Template name
Validity period
Publish certificate in Active Directory
Do not automatically reenroll if a duplicate certificate
exists in Active Directory
For automatic renewal of smart card certificates, use the
existing key if a new key cannot be created
Attribute Your recommended design
Purpose
Allow private key to be exported
Minimum key size
Do the following when the subject is enrolled and when
the private key associated with this certificate is used
CSPs
282 Part II: Establishing a PKI
7. In the following table, specify the settings on the Issuance Requirements tab to meet the
design requirements for the custom code-signing certificate template.
8. How must you configure the settings on the Superseded Templates tab to ensure that all
certificates a CA issues for code signing use the version 2 certificate template?
9. What permission assignment modifications are required for the custom code signing
certificate?
Best Practices for Certificate Template Design
When designing certificate templates, the following best practices should be employed:
■ Determine whether a default version certificate template meets your business goals.
A default template does not require any modifications other than permission
assignment.
■ If you need to change settings in a certificate template other than permissions, duplicate

a template that is closest to the required template. This minimizes the number of
changes required.
■ If you replace an existing certificate template with an updated template, ensure that you
add the previous template to the Superseded Templates tab.
■ To enroll a certificate, a user or computer must be assigned Read and Enroll permissions,
either directly or through group membership.
■ To enroll a certificate with autoenrollment, a user or computer must be assigned Read,
Enroll, and Autoenroll permissions.
■ To modify a certificate template, a user must be assigned Write permissions.
■ Determine whether you should deploy fewer certificates with multiple purposes or
many certificates with specific purposes. The decision is based on the purposes you
require and whether you foresee removing a purpose from a certificate holder.
■ Do not create certificate templates that exceed the lifetime of the issuing CA or the
values declared in the CA\ValidityPeriodUnits and CA\ValidityPeriod registry entries.
A CA will issue the certificate with a lifetime equal to the lowest value of the three
entries.
Attribute Your recommended design
CA certificate manager approval
This number of authorized signatures
Require the following for reenrollment
Chapter 12: Designing Certificate Templates 283
■ Use version 3 certificate templates only if the operating systems of the computers that
will use the certificate template and the applications that will use the certificate tem-
plates support CNG algorithms. Currently, CNG–based algorithms are supported only
on Windows Vista and Windows Server 2008. Table 12-2 summarizes common
applications and their support for version 3 certificates.
Additional Information
■ Microsoft Official Curriculum, Course 2821: “Designing and Managing a Windows
Public Key Infrastructure” ( />■ “Implementing and Administering Certificate Templates” ( />downloads/details.aspx?FamilyID=3c670732-c971-4c65-be9c-c0ebc3749e24&
displaylang=en)

■ 283218: “A Certification Authority Cannot Use a Certificate Template”
■ 281260: “A Certificate Request That Uses a New Template Is Unsuccessful”
■ 313629: “A Custom Smart Card Template Is Unavailable on the Smart Card Enrollment
Station”
■ 330238: “Users Cannot Enroll for a Certificate When the Include E-Mail Name in
Subject Name Option Is Selected on the Template”
Note
The last four articles in the list above can be accessed through the Microsoft Knowl-
edge Base. Go to and enter the article number in the Search the
Knowledge Base text box.
Table 12-2
Application Support for Version 3 Certificates
Application name
Verify a certificate chain with version 3
certificates using CNG algorithms
Use algorithms that are not
supported by CAPI (CSP)
EFS Yes No
IPsec Yes Yes
Kerberos No No
S/MIME Microsoft Office Outlook 2003: no
Outlook 2007: yes
Outlook 2003: no
Outlook 2007: yes
Smart Card Logon No No
SSL Yes Yes
Wireless Yes Yes

285
Chapter 13

Role Separation
An important step in designing and implementing a public key infrastructure (PKI) is
determining the groups or users who will manage it. To facilitate secure administration of
Certificate Services, both the Windows Server 2003 Certificate Services and Windows Server
2008 Active Directory Certificate Services (AD CS) support Common Criteria role separation.
Common Criteria role separation requires that PKI management be configured so that no
single person has full control, thereby protecting an organization against a “malicious PKI
administrator.”
There are other roles that must be considered when designing and implementing your
organization’s PKI in addition to the roles defined in the Common Criteria protection profile.
This chapter will discuss how to plan PKI management and implement role separation.
Note
Because there is no difference in implementing Common Criteria role separation in
Windows Server 2003 and Windows Server 2008, the rest of this chapter will refer to Windows
Server 2008.
Common Criteria Roles
According to Common Criteria guidelines, no user can hold more than one PKI management
role—and any user who does hold two or more PKI management roles must be blocked from
all management functions.
Note
You can assign multiple users the same role when defining role-holders. Enforcing
Common Criteria role separation on a Windows Server 2008 certification authority (CA)
ensures that a single user cannot hold multiple roles, but multiple users can hold the same role.
Common Criteria Levels
“Certificate Issuing and Management Components Family of Protection Profiles” is a stan-
dards document that defines requirements for the issuance, revocation, and management of
X.509 certificates. Taking into consideration that different security levels are required for dif-
ferent organizations, the standards document describes four protection profiles. Each profile
provides additional safety through increased security and assurance requirements for X.509
certificate distribution.

286 Part II: Establishing a PKI
More Info Windows Server 2008 Certificate Services is designed to meet the role
definitions listed in version 1.0 of “Certificate Issuing and Management Components Family of
Protection Profiles,” which can be found at />PP_CIMC_SL1-4_V1.0.pdf.
Security Level 1
Certificate Issuing and Management Components (CIMC) Security Level 1 defines the mini-
mum level of certificate management security for environments in which threats against the
PKI are considered to be low. It defines two PKI management roles:
■ CA administrator Responsible for account administration, key generation of the CA
certificate’s key pair, and auditing configuration
■ Certificate manager Responsible for certificate management. Management functions
include issuing and revoking certificates
In addition to these two roles, the PKI must restrict access to only authorized PKI users and
implement only cryptographic algorithms that are validated against Federal Information
Processing Standards (FIPS) 140-1, “Security Requirements for Cryptographic Modules.”
Security Level 2
CIMC Security Level 2 increases the level of certificate management security for environments
in which the risks and consequences of data disclosure are not considered a significant issue.
It also increases security by rejecting certificate requests by unauthorized users. All users must
authenticate with the PKI before certificate issuance.
Security Level 2 uses the same two management roles as Security Level 1. The difference is
that Level 2 requires increased auditing and cryptographic protection of audit logs and
system backups. In addition, FIPS 140-1 Level 2 cryptographic modules are required for the
protection of a CA’s key pair.
Security Level 3
CIMC Security Level 3 further raises the security level and is intended for environments in
which it is considered a moderate risk if data is disclosed or loss of data integrity. As compared
to Security Level 2, CIMC Security Level 3 implements additional integrity controls to
ensure that an unauthorized person cannot modify data. This includes protection against an
unauthorized person who gains physical access to a CA.

Security Level 3 defines three PKI management roles:
■ CA administrator Responsible for account administration, key generation of the CA
certificate’s key pair, and auditing configuration.
Chapter 13: Role Separation 287
Choosing Auditing Behavior
Windows Server 2003 Service Pack 1 and Windows Server 2008 allow you to choose
which Common Criteria role can define audit settings. The default behavior in Windows
Server 2003 and Windows Server 2008 is to allow the Auditor role to both define
audit settings at the CA and to view and maintain the audit logs.
With Windows Server 2003 Service Pack 1 or Windows Server 2008 installed, you can
instead choose to have the CA administrator role define the audit settings at a specific
CA. This is accomplished by having a local administrator run the following certutil
command:
certutil -setreg CA\InterfaceFlags +IF_ENABLEADMINASAUDITOR
Once the command executes and Certificate Services is restarted, the task of defining
the CA audit settings is allocated to the CA administrator role rather than the CA
auditor role.
■ Certificate manager Responsible for certificate management. Management functions
include issuing and revoking certificates.
■ Auditor Responsible for maintaining the CA audit logs.
Additional security measures include having at least two persons involved in the control and
management of private keys, implementing FIPS 140-1 Level 3 protection of CA keys, and
requiring digital signatures for all data transferred between the CA and the hardware security
module (HSM).
Security Level 4
CIMC Security Level 4 provides the highest PKI security protection. It is intended for
environments in which the consequences of data disclosure and loss of data integrity by
either authorized or unauthorized users are significant to the organization.
Security Level 4 defines four PKI management roles:
■ CA administrator Responsible for account administration and key generation of the CA

certificate’s key pair
■ Certificate manager Responsible for certificate management, including functions such
as issuing and revoking certificates
■ Auditor Responsible for maintaining and viewing the CA audit log entries in the
Windows Security log
■ Backup operator Responsible for performing backups of PKI information
288 Part II: Establishing a PKI
Security Level 4 requires signed third-party timestamping of audit logs to increase integrity. In
addition, cryptographic modules at each CA must be validated to FIPS 140-1 Level 4.
Note
The only cryptographic module rated at FIPS 140-1 Level 4 at the time of this book’s
publication is the AEP Keyper Enterprise ( />key_management/keyper/ent_overview.aspx). More FIPS 140-1 Level 4 devices should be
available in the near future.
Windows Implementation of Common Criteria
Windows Server 2008 allows you to define PKI management roles in compliance with the
four roles defined in CIMC Security Level 4. The Windows Server PKI management roles are:
■ CA administrator
■ Certificate manager
■ Backup operator
■ Auditor
The following sections detail information on Windows Server Common Criteria roles and
how to implement each role.
Note
AD CS does not require the user to have local administrative rights on the CA
computer for day-to-day PKI management. The user must be assigned only the CA
permissions or the user rights associated with one of the four Common Criteria roles.
Important The only tasks where administrative rights are required at a CA are the
installation of a new CA or the renewal of a CA certificate. You must be a member of the local
administrators to install AD CS and to generate key material in the local machine store. In
addition, you must be a member of Enterprise Admins to install or renew an enterprise CA.

CA Administrator
A CA administrator configures and maintains the CA. A user assigned the CA administrator
role can designate other CA administrators, assign certificate managers, and perform the
following CA management tasks:
■ Configure extensions Define URLs for both CRL Distribution Points (CDPs) and
Authority Information Access (AIA).
■ Configure policy and exit modules Policy and exit modules determine the actions a CA
takes during certificate issuance. For example, the default policy module allows a CA
Chapter 13: Role Separation 289
administrator to configure whether all certificate requests are pended or issued based
on the user’s credentials. An exit module allows you to define whether the certificate
information is published to preconfigured file share locations.
Using Exit Modules
Exit modules can be used in many ways to enhance the functionality of a Windows
Server 2008 CA. For example, Microsoft has deployed a custom exit module that
performs a real-time, centralized logging function that tracks all issued certificates into a
Microsoft SQL Server database. This functionality is discussed in the article “Microsoft
IT Showcase: Deploying PKI Inside Microsoft,” available at />downloads/details.aspx?FamilyId=46CA7043-0433-4140-853A-05F01430A30D&display-
lang=en.
In the default exit module for Certificate Services, you can enable additional functional-
ity by enabling the Simple Mail Transfer Protocol (SMTP) functionality within the exit
module. The SMTP functionality allows the CA to send SMTP e-mail messages to desig-
nated e-mail recipients when specific CA activities take place, such as the publication
of a certificate revocation list (CRL), revocation of a certificate, or stopping and starting
of Certificate Services. The SMTP exit module functionality is discussed in the “Win-
dows Server 2003 PKI Operations Guide,” available at />loads/details.aspx?FamilyID=8e25369f-bc5a-4083-a42d-436bdb363e7e&DisplayLang=en.
■ Define certificate manager restrictions Restrict each certificate manager to
management of specific combinations of global groups and certificate templates.
■ Define enrollment agent restrictions Restrict each defined enrollment agent to manage-
ment of specific combinations of global groups and certificate templates.

■ 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.
■ Define key recovery agents Designate key recovery agent certificates at a CA for the
archival and recovery of private keys at the CA database.
■ Define other CA administrators Designate CA administrators to perform CA
management tasks.
■ Delete a single record in the CA database By using the certutil –deleterow command
to delete the record associated with the certificate, you can remove specific certificate
information from the CA database.
■ Enable, publish, or configure the CRL schedule Manage all aspects of publishing CRLs
and delta CRLs at a CA.
■ Read the CA configuration information View the CA’s current configuration and
modify only those areas enabled for modification by CA administrators.
290 Part II: Establishing a PKI
■ Stop and start Certificate Services Stop and start Certificate Services to apply registry
changes.
Warning
This does not prevent a local administrator from stopping and starting
Certificate Services. This only allows a CA administrator to stop and start Certificate Services.
■ Configure audit parameters As mentioned earlier in the chapter, by running certutil -
setreg CA\InterfaceFlags +IF_ENABLEADMINASAUDITOR you can allow a CA
administrator to define audit settings at a CA rather than allow a CA auditor to configure
these settings. A CA administrator can enable the following auditing settings for the CA
in the Certification Authority console:
❑ Back Up And Restore The CA Database. Logs any attempt to back up or restore
the CA database to the Windows Security log.
❑ Change CA Configurations Logs any attempt to modify CA configuration. This
can include defining AIA and CDP URLs or defining a key recovery agent.
❑ Change CA Security Settings Logs any attempt to modify CA permissions. This
can include adding CA administrators or certificate managers.

❑ Issue And Manage Certificate Requests Logs any attempt by a certificate manager
to approve or deny certificate requests that are in a pending state.
❑ Revoke Certificates And Publish CRLs Logs any attempt by a certificate manager to
revoke an issued certificate or by a CA administrator to publish an updated CRL.
❑ Store And Retrieve Archived Keys Logs any attempt during the enrollment
process to archive private keys in the CA database or by certificate managers to
extract archived private keys from the CA database.
❑ Start And Stop Certificate Services Logs any attempt by the CA administrator to
start or stop Certificate Services.
Note
To ensure that all events related to Certificate Services auditing are logged to the
security log, ensure that both success and failure events are enabled for Object Access at the
CA. The settings can be applied directly in the Local Security Settings or by applying a Group
Policy Object (GPO) with the required auditing settings.
Certificate Manager
This role approves or denies certificate enrollment requests and revokes issued certificates.
Specifically, a user assigned the certificate manager role can:
■ Issue or deny pending certificate requests At a standalone CA all certificate requests are
pended by default until a certificate manager approves the certificate requests. Likewise,
Chapter 13: Role Separation 291
a certificate template can be defined so that a certificate manager must approve a
certificate request before the CA issues the certificate.
■ Revoke issued certificates A certificate manager can revoke a certificate if the organiza-
tion’s revocation policy requires certificate revocation. For example, a certificate can
be revoked if the private key is compromised. Certificate revocation terminates the
certificate’s validity prior to expiration.
■ Determine key recovery agents A certificate manager determines which defined key
recovery agent can decrypt an archived private key from the CA database.
■ Extract archived private keys from the CA database A certificate manager can extract the
archived private key from the CA database. The private key is extracted in a binary

large object (BLOB) format, which is an encrypted PKCS #7 file that only the designated
key recovery agent can decrypt.
Note
A binary large object (BLOB) is a data type that can store any format of data in a binary
format.
Auditor
An auditor can view the CA’s Security event log to review auditing events related to Certificate
Services.
Backup Operator
Performs backups of the CA database, the CA configuration, and the CA’s private and public
key pairs, known as a key pair.
Note
If the CA’s private and public key pair is stored on an HSM, backup operators can back
up the CA key pair only if the HSM’s security context allows this ability.
Assigning Common Criteria Roles
Once you determine which users should hold each Common Criteria role, you must define
the role-holders. The definition is CA-specific, meaning that you can assign different role-
holders at each CA in the hierarchy.
Tip
Assign the permissions for Common Criteria role separation to either domain local
groups (for domain member computers) or local groups within the local Security Account
Management (SAM) database of each CA.
292 Part II: Establishing a PKI
CA Manager
You can use the following procedure to define a CA administrator at a CA:
1. Open the Certification Authority console.
2. In the console tree, right-click CAName, and then click Properties.
3. On the Security tab, click Add, and then type the names of any users or domain local
groups that will be CA administrators.
4. Assign the users or groups Manage CA permission, and then click OK.

Certificate Manager
You can use the following procedure to define a certificate manager at a CA:
1. Open the Certification Authority console.
2. In the console tree, right-click CAName, and then click Properties.
3. On the Security tab, click Add, and then type the names of any domain local groups that
will be certificate managers.
4. Assign the users or groups Issue and Manage Certificates permission, and then
click OK.
Auditor
You can use the following procedure to assign a user the role of auditor:
1. From Administrative Tools, open Local Security Policy.
2. In the console tree, expand Local Policies, and then click User Rights Assignment.
3. In the details pane, double-click Manage Auditing And Security Log.
4. Add the user accounts or groups that will perform auditing at the CA, and then
click OK.
5. Close Local Security Policy.
Warning
A CA auditor is assigned the auditor role systemwide. The user cannot be limited
to viewing only Security event log entries related to Certificate Services. The user can view all
entries in the Security event log.
Backup Operator
You can use the following procedure to assign a user or group the role of backup operator:
1. From Administrative Tools, open Local Security Policy.
2. In the console tree, expand Local Policies, and then click User Rights Assignment.
Chapter 13: Role Separation 293
3. In the details pane, double-click Backup Files And Directories.
4. Add the user accounts or groups that will perform auditing at the CA, and then click
OK.
5. In the details pane, double-click Restore Files And Directories.
6. Add the user accounts or groups that will perform auditing at the CA, and then

click OK.
7. Close Local Security Policy.
Note
Alternatively, you can choose to simply add the user account to the local Backup
Operators group.
Implementing Certificate Manager Restrictions
Some organizations may require further restrictions on certificate manager activities. Rather
than allow a certificate manager to issue or revoke any certificate issued by a CA, the
organization may want a certificate manager to manage only a subset of all certificates.
AD CS allows a CA administrator to define restrictions for certificate managers. Not only can
a certificate manager restriction limit a certificate manager to issuing or revoking certificates
whose subject has membership in a specified security group (as previously implemented in
Windows Server 2003), but now, you can further restrict the certificate manager to managing
only certificates based on specific certificate templates.
For example, assume that the following groups are assigned the Issue and Manage Certificates
permission:
■ APACCertManagers
■ EMEACertManagers
■ EFSManagers
Important
To define a certificate manager restriction for a specific user or group, the user
or group must be explicitly defined in the Issue and Manage Certificates permission on the CA’s
security tab. You cannot define certificate manager restrictions for users or groups nested
within a group assigned the Issue and Manage Certificates permission.
A CA administrator could then restrict which combinations of groups/computers/users
and certificate templates each manager group can manage. For example, you could limit the
APACCertManagers group to issuing certificates to or revoking certificates only of the members of
294 Part II: Establishing a PKI
the APACUsers and APACComputers groups. You could limit the EMEACertManagers group
to issuing and revoking certificates issued to the EMEAUsers and EMEAComputers groups.

Important
If a user account has membership in both the APACUsers and EMEAUsers
groups, the certificate issued to that user can be managed by certificate managers in either
the APACCertManagers or EMEACertManagers groups.
The new functionality allows you to define restrictions further. As shown in Figure 13-1, you
can now restrict a certificate manager to a combination of certificate templates and to specific
groups.
Figure 13-1 Restricting certificate managers
In the example, the EFSManagers group can manage certificates based only on the Archive
EFS certificate template that is issued to members of the EFSUsers group. This new
combination allows you to not only restrict the manager to members of a specific group but to
a specific certificate template.
Note
To implement certificate manager restrictions, the CA computer account must be
included in the Pre–Windows 2000 Compatible Access group. Membership in this group allows
the CA to determine the group memberships defined for the subject of a certificate.
Chapter 13: Role Separation 295
Enforcing Common Criteria Role Separation
You can enforce Common Criteria role separation on the Windows Server 2003 Enterprise
and Datacenter Editions and Windows Server 2008 Enterprise and Datacenter Editions. By
enforcing role separation, AD CS blocks any user account that is assigned two or more Com-
mon Criteria roles from all Certificate Services management activities.
For example, if a user is assigned both the CA Administrator and Certificate Manager roles,
the user cannot perform the tasks defined for either role.
To enforce Common Criteria role separation, a local administrator of the computer must
configure the RoleSeparationEnabled registry value. This is done by performing the following
procedure:
1. Type the following command at a command prompt:
certutil –setreg CA\RoleSeparationEnabled 1
2. Restart AD CS.

If any users are assigned two or more roles, their administrative activities are blocked immediately.
Tip
If you accidentally assign yourself two or more Common Criteria roles and block
yourself from PKI management tasks, a local administrator must disable Common Criteria role
separation by typing certutil –delreg CA\RoleSeparationEnabled and then restarting AD CS.
With role separation disabled, a CA administrator or local administrator must fix the role
assignments and reenable Common Criteria role separation.
Role Separation and CA Certificate Renewal
The one scenario where role separation hinders PKI management activities is the case
of CA certificate renewal. When a CA’s certificate is renewed, a user may have to hold
different roles. The user:
■ Must be a CA administrator to publish an updated CRL.
■ Must be a local administrator to renew the CA certificate.
■ Must be a member of the local Administrators group to access the local machine
store of a software-based cryptographic service provider (CSP), such as the
Microsoft Strong Cryptographic Service Provider v1.0.
■ Must be a member of the ForestRootDomain\Domain Admins or Enterprise
Admins group to allow creation of the CDP and CA certificate objects within the
Configuration naming context.
❑ A new CDP object is created in the CN=CAName,CN=CDP,CN=Public Key
Services,CN=Services,CN=Configuration,ForestRootDomain (where CAName
296 Part II: Establishing a PKI
is the NetBIOS name of the CA computer and ForestRootDomain is the Light-
weight Directory Access Protocol (LDAP) distinguished name of the forest)
container.
❑ A new CA certificate object is created in the AIA container (CN=AIA,
CN=Public Key Services,CN=Services,CN=Configuration,ForestRootDomain).
❑ A new CA certificate object is added to the NTAuth store (CN=NTAuth-
Certificates,CN=Public Key Services,CN=Services,CN=Configuration,Forest-
RootDomain).

❑ If the CA is an enterprise CA, a new CA certificate object is created in the
Enrollment Services container (CN=Enrollment Services,CN=Public Key
Services,CN=Services,CN=Configuration,ForestRootDomain).
If the CA is an enterprise root CA, a new CA certificate object is created in the
Certification Authorities container (CN=Certification Authorities,CN=Public Key
Services,CN=Services,CN=Configuration,ForestRootDomain).
To accomplish the task of CA certificate renewal, you must disable role separation
temporarily during the CA certificate renewal process. Ensure that the account that
performs the CA certificate renewal is a member of the Enterprise Admins group, is a
member of the local Administrators group, and is assigned the Manage CA permission.
Once the CA certificate renewal process is completed, role separation should be enforced.
Other PKI Management Roles
In addition to the Common Criteria roles, Windows Server 2008 can implement other roles in
the PKI management structure, which are discussed in this section.
Local Administrator
The CA’s local administrator is any member of the local Administrators group in the local
accounts database of the CA computer. This typically includes the local Administrator
account and the Domain Admins global group from the CA computer’s domain. The
membership can also contain the Enterprise Admins group from the forest root domain.
A local administrator can perform the following tasks at a Windows Server 2008 CA:
■ All CA administrator tasks By default, the local Administrators group is assigned the
Manage CA permission.
■ All certificate manager tasks By default, the local Administrators group is assigned the
Issue and Manage Certificates permission.
■ Enable or disable Common Criteria role separation Members of the local Administrators
group have the required permissions to make the necessary registry modifications to
enable or disable Common Criteria role separation.
Chapter 13: Role Separation 297
■ Install Certificate Services To install Certificate Services, the installer must be a member
of the local Administrators group.

■ Renew a CA certificate To renew a CA certificate, the user must have access to the local
machine’s certificate store. By default, only members of the local Administrators group
have the necessary access.
Enterprise Admins
By default, Enterprise Admins are able to create and modify objects stored in Active Directory
Domain Services Configuration naming context. When you install an enterprise CA in your
forest, a member of the Enterprise Admins group must perform the installation to ensure that
the required objects are created in the Configuration naming context.
Note
The user performing the installation must also be a member of the local Administra-
tors group to install AD CS.
Enterprise Admins Tasks
A member of the Enterprise Admins group is able to perform the following PKI administration
tasks:
■ Install an enterprise CA Only members of the Enterprise Admins group can create the
required objects in the Configuration naming context when an enterprise CA is
installed.
■ Modify and create certificate templates A member of the Enterprise Admins group can
modify permissions of a version 1 certificate template and all properties of a version 2
or version 3 certificate template. In addition, members of the Enterprise Admins group
can create new version 2 or version 3 certificate templates based on existing version 1,
version 2, or version 3 certificate templates.
■ Publish CA certificates to Active Directory Domain Services A member of the Enterprise
Admins group can publish the CA certificate for an offline CA, NTAuth certificates, and
Cross Certification Authority certificates to the Configuration naming context.
■ Publish offline CA CRLs to Active Directory Domain Services A member of the Enter-
prise Admins group can publish the CRL for an offline CA to the Configuration naming
context.
Certificate Template Manager
In some organizations, the task of managing certificate templates can be delegated to a custom

group rather than be left to the Enterprise Admins group.
298 Part II: Establishing a PKI
Certificate Template Manager Tasks
A certificate template manager is able to manage the properties of existing certificate
templates. In addition, a certificate template manager is able to create, modify, or delete
version 2 or version 3 certificate templates.
Assigning the Certificate Template Manager Role
Three separate tasks must be performed to assign the Certificate Template Manager role:
■ Delegate permissions to the Certificate Templates container in the Configuration
naming context to create new certificate templates.
■ Delegate permissions to the OID container in the Configuration naming context to
create new object identifiers (OIDs).
■ Delegate permissions to every existing certificate template in the Certificate Templates
container in the Configuration naming context.
Delegate Permissions for Creation of New Templates You can delegate the permission
to create new templates by assigning permissions to a custom universal group for the
CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,
ForestRootDomain container.
1. Log on as a member of the Enterprise Admins group or the forest root domain Domain
Admins group.
2. Open the Active Directory Sites And Services console.
3. From the View menu, ensure that the Show Services Node setting is enabled.
4. In the console tree, expand Services, expand Public Key Services, and then click
Certificate Templates.
5. In the console tree, right-click Certificate Templates, and then click Delegate Control.
6. In the Delegation Of Control wizard, click Next.
7. On the Users Or Groups page, click Add.
8. In the Select Users, Computers, Or Groups dialog box, type a user or group name, and
then click OK.
9. On the Users Or Groups page, click Next.

10. On the Tasks To Delegate page, click Create A Custom Task To Delegate, and then click
Next.
11. 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.
Chapter 13: Role Separation 299
12. On the Permissions page, in the Permissions list, enable Full Control, and then click
Next.
13. On the Completing The Delegation Of Control wizard page, click Finish.
Delegate Permissions for Creation of New OIDs When a certificate template is created,
an OID is generated to identify the certificate template. To create a new certificate template, a
user must be delegated the permission to create new OIDs in the CN=OID,CN=Public Key
Services,CN=Services,CN=Configuration,ForestRootDomain container.
1. Log on as a member of the Enterprise Admins group or the forest root domain Domain
Admins group.
2. Open the Active Directory Sites And Services console.
3. On the View menu, ensure that the Show Services Node setting is enabled.
4. In the console tree, expand Services, expand Public Key Services, right-click OID, and
then click Properties.
5. In the OID Properties dialog box, on the Security tab, click Advanced.
6. In the Advanced Security Settings For OID dialog box, click Add.
7. In the Select Users, Computers, Or Groups dialog box, type the names of the users or
groups you want to delegate certificate management permissions to, and then click OK.
8. In the Permissions Entry For OID dialog box, in the Apply To drop-down list, select This
Object And All Descendant Objects, select the Allow check box for Full Control, and
then click OK.
9. In the Advanced Security Settings For OID dialog box, click OK.
10. In the OID Properties dialog box, click OK.
Delegate Permissions to Every Existing Certificate Template in the Certificate Once
you delegate permissions for creating and modifying new certificate templates, you must
modify the permissions of the existing certificate templates.

You can run a script file to delegate certificate template permissions to a custom universal
group. The script file must include the 34 default certificate templates and any other custom
certificate templates that exist when the script is executed.
For each certificate template, the script must include the following line:
dsacls "CN=
TemplateName
,CN=Certificate Templates,CN=Public Key
Services,CN=Services,CN=Configuration,
ForestRootDomain
" /G
DomainName
\
GroupName
:SDDTRCWDWOLCWPRPCCDCWSLO
300 Part II: Establishing a PKI
For example, to delegate certificate template permissions for the EFS Recovery Agent
certificate template in the example.com forest to a group named example\Template-
Adminstrators, you would use the following command:
dsacls "CN=EFSRecovery,CN=Certificate Templates,CN=Public Key
Services,CN=Services,CN=Configuration,DC=example,DC=com" /G
example\TemplateAdministrators:SDDTRCWDWOLCWPRPCCDCWSLO
On the Disc A copy of this script is included on the accompanying CD-ROM. The script,
DelegateTemplateModification.cmd, must be modified to replace the example\Template-
Administrators group with the name of the custom universal group deployed in your forest.
Editing Existing Certificate Templates
If a delegated certificate template administrator attempts to edit an existing certificate
template, the attempt will fail unless the certificate template administrator takes ownership of
the certificate template. To take ownership, the certificate template administrator must:
1. Open the Certificate Templates console (Certtmpl.msc).
2. Right-click the existing certificate template, and then click Properties.

3. On the Security tab, click Advanced.
4. On the Owner tab, in the Change Owner To list, select the certificate template adminis-
trator’s user account name, and then click Apply.
5. In the Advanced Security Settings For TemplateName dialog box, click OK.
6. In the TemplateName Properties dialog box, click OK.
Enrollment Agent
An enrollment agent is able to request certificates on behalf of other users.
Enrollment Agent Tasks
The enrollment agent role is typically used to request smart card certificates on behalf of other
users. An enrollment agent validates the smart card requestor’s identity and then submits a
smart card request on behalf of the requestor. The enrollment request differs from a normal
enrollment request in that the enrollment agent signs the request with a certificate that has
the Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) in the certificate’s Application
Policies extension. The CA enforces that the certificate request must be signed by a certificate
with the Certificate Request Agent OID if the subject provided in the certificate request does
not match the identity of the account used to submit the certificate request.
Chapter 13: Role Separation 301
Assigning the Enrollment Agent Role
To assign the enrollment agent role, a user must request a certificate with the Certificate
Request Agent OID in the Application Policy or in the Enhanced Key Usage extension.
By default, the Enrollment Agent version 1 certificate template includes the necessary OID. A
user becomes an enrollment agent by requesting and receiving a certificate based on the
Enrollment Agent certificate template.
Note
The design decisions for deploying enrollment agent and smart card certificates are
discussed in Chapter 21, “Deploying Smart Cards.”
Key Recovery Agent
The key recovery agent role is responsible for recovering private keys archived in the CA
database. Only the holders of the private key associated with the Key Recovery Agent
certificate can recover the private keys once a certificate manager extracts the PKCS #7 BLOB

file from the CA database.
Key Recovery Agent Tasks
A key recovery agent is responsible for decrypting a PKCS #7 BLOB file that contains an
encrypted copy of the user’s certificate and private key. The resulting decryption provides a
PKCS #12 object (file) that can be imported by the user into his or her profile.
A key recovery agent is dependant on the certificate manager role to extract the encrypted
PKCS#7 BLOB file from the CA database. The key recovery agent should not be assigned
the certificate manager role to ensure that at least two people are involved in the key recovery
process.
Warning
You should never assign a user both the certificate manager and key recovery
agent roles. Even though Common Criteria role separation does not address key archival,
allowing one user to hold both the certificate manager and key recovery agent roles allows
that user to both extract and decrypt an archived private key from the CA database.
Assigning the Key Recovery Agent Role
To assign the key recovery agent role, a user must have a certificate with the Key Recovery
Agent application policy OID. The default Key Recovery Agent version 2 certificate template
includes this application policy OID and can be further secured by limiting the users and
groups with enrollment permissions.
302 Part II: Establishing a PKI
In addition, a CA must be configured to enable key recovery. This is done by designating one
or more Key Recovery Agent certificates to act as the CA’s key recovery agent. Only the
holders of the private keys associated with the selected Key Recovery Agent certificates are
able to decrypt the extracted PKCS #7 BLOBs.
Note
The design decisions for deploying key recovery agents and enabling key archival and
recovery are discussed in Chapter 18, “Archiving Encryption Keys.”
Case Study: Planning PKI Management Roles
In this case study, you will look at the definition of PKI Management roles.
Scenario

You are the security services manager for Tailspin Toys. Your organization implements a two-
tier CA hierarchy, as shown in Figure 13-2.
Figure 13-2 The Tailspin Toys CA hierarchy
The CA hierarchy implements two issuing CAs:
■ Tailspin Toys Infrastructure CA This CA issues certificates to domain controllers,
servers, computers, and network devices.
■ Tailspin Toys Employee CA This CA issues certificates to employees (users) of Tailspin
Toys.
The issuing CAs are managed by two different teams: The network services team manages the
Tailspin Toys Infrastructure CA, and the directory services team manages the Tailspin Toys
Employee CA. Your team, security services, has the ability to manage both CAs.
CA Name: Tailspin Toys Employee CA
CA Validity Period: 10 Years
Name: Tailspin Toys Corporate Root CA
CA Validity Period: 20 Years
CA Name: Tailspin Toys Infrastructure CA
CA Validity Period: 10 Years
Chapter 13: Role Separation 303
Within each department, different users are assigned the PKI Common Criteria roles of CA
Administrator and Certificate Manager. Backups are performed by a centralized backup
services account. Auditing is performed by members of both the security services team
and the internal audit department. The security policy of Tailspin Toys requires strong
enforcement of Common Criteria role separation for PKI management.
Case Study Questions
1. The backup software implemented by Tailspin Toys uses a centralized backup services
account. When reviewing the event logs, the backup operator notices that the backup
fails every night on the two issuing CAs. On inspecting the event logs further, the
backup software reports that the failed backup item is the System State backup. What is
the likely cause of the error?
2. When inspecting the security permission assignments at the Tailspin Toys Infrastruc-

ture CA, you accidentally assign the CA Administrator group the Issue and Manage
Certificates permission. When you try and fix the permissions assignment error, you
find that access is denied. What must be done to fix the issue?
3. The certificate for the Tailspin Toys Employee CA is reaching the halfway point of its
validity period and must be renewed. You are logged on to the CA as a CA Administrator
but all attempts to renew the CA certificate fail. Who must perform the renewal of the
CA certificate?
4. The Tailspin Toys Employee CA implements key archival for both Encrypting File
System (EFS) certificates and e-mail encryption certificates. The security policy of your
organization requires that all key recovery operations be performed by at least two
employees. If you are assigned the Key Recovery Agent role, what Common Criteria role
can you not hold, because this would break the security policy for key recovery?
5. Tailspin Toys implements several version 1 certificate templates at the Tailspin Toys
Infrastructure CA. You have delegated the task of managing certificate templates to
Andy, a member of the IT security team. Andy is able to create new version 2 and version
3 certificate templates but is unable to modify the permissions for any of the version 1
certificate templates deployed at the Tailspin Toys Infrastructure CA. Why is Andy
unable to modify the version 1 certificate templates?
6. Tailspin Toys wishes to deploy a new enterprise subordinate CA named Tailspin Toys
Contractor CA to issue certificates to contractors and vendors working on-site. When
you attempt to install the enterprise CA, the options for both enterprise root CA and
enterprise subordinate CA are unavailable. What group memberships are required to
install an enterprise CA?
304 Part II: Establishing a PKI
7. You have enabled auditing at all issuing CAs in the CA hierarchy. Today, you received a
call from the audit department indicating that no events related to Certificate Services
exist in the Windows Security log. You view the properties of each CA and find that the
auditing is configured at each CA, as shown in Figure 13-3.
Figure 13-3 Auditing settings defined at the Tailspin Toys Employee CA
Why are there no audit entries related to Certificate Services?

Additional Information
■ Microsoft Official Curriculum, Course 2821: “Designing and Managing a Windows
Public Key Infrastructure” ( />2821Afinal.mspx)
■ “PKCS #7: Cryptographic Message Syntax Standard” ( />pkcs/doc/pkcs-7.doc)
■ “Windows Server 2003 PKI Operations Guide” ( />windowsserver/en/library/e1d5a892-10e1-417c-be13-99d7147989a91033.mspx?mfr=true)
■ “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key
Infrastructure” ( />481d-8a96-03e0be7374ed1033.mspx?mfr=true)

×