More Vocabulary

Chapters 18 and 19 exposed you to most of the security vocabulary you'll need to work with Certificate Services, but you need to learn some additional terms, as defined in the following sections.

Policy Modules

A policy module is a set of instructions that tells the CA what to do with incoming certificate requests. A policy module can automatically approve or reject a request, based on any criteria coded into the module; it can also mark a request as pending and leave it for a human administrator to handle. Policy modules can also modify the content of a certificate by adding or removing extensions. The standard policy module supplied with Windows 2000 does the following:

  • Approves incoming requests or marks them as pending, depending on the CA type and the setting you specify
  • Adds an optional extension to the certificate that specifies where the issuing CA's certificate can be obtained
  • Adds an optional extension that specifies where certificate revocation lists (CRLs) for the issuing CA can be obtained

Other applications, notably Microsoft Exchange Server, can implement their own policy modules, which can replace or augment the standard policy behavior. Microsoft offers tools that allow you to develop your own policy module if you need to change the policy behavior to match your organization's security standards.

Exit Modules

An exit module allows the CA to take some action after a certificate is generated. For example, an exit module might publish new certificates by putting them in the Active Directory service or mailing them to the original requestor. The standard Windows 2000 exit module performs two tasks: if the requestor specifies a file path, an Active Directory location, or both, the exit module publishes the new certificate to one or both locations; and it publishes CRLs for the CA to the location you specify.

Certificate Publishers

A certificate publisher serves the same function as any other kind of publisher: it makes desirable information available to clients who want it. Specifically, certificate publishers make certificate and CRL information available to clients, using whatever mechanism they want. The default certificate publisher in Windows 2000 is Active Directory, although you're free to export certificates or store them in another type of directory or publishing system.

Certificate Templates

A certificate template defines a cookie-cutter set of attributes and extensions that a newly issued certificate will have. For example, the Administrator certificate template specifies different attributes from a Domain Controller certificate. The idea behind certificate templates is that the person requesting a certificate can just pick a template that embodies the attributes and extensions he or she needs the new certificate to have, instead of being required to pick and choose from dozens (or even hundreds) of arcane attribute names.

Windows 2000 supports 21 certificate templates, listed in Table 20-1. When you request a certificate using a particular template, the CA knows which attributes and extensions to populate the new certificate with; as an administrator, you can control which templates individual users and groups can use when requesting new certificates. (In fact, you can also control whether they can request certificates at all!)

Each template defines the content of the certificate, using some combination of the template features listed in Table 20-2. You can't control the content of templates, so you must work with the attribute combinations hard coded into them by Microsoft.

Table 20-1. Certificate templates

Template Purpose Recipient


Signs code; signs certificate trust lists (CTLs); secures e-mail and EFS file systems; authenticates clients

People acting in an administrative role in the domain

Authenticated Session

Allows signature-only operations for client authentication

Network clients

Basic EFS

Encrypts EFS intermediate keys and files volumes

People who have access to EFS

Code Signing

Signs executable code to assert its trustworthiness

People who are authorized to sign executables and controls


Authenticates computers to servers and vice versa

Computers within a domain

Domain Controller

Authenticates clients to servers; authenticates servers to clients

Computers that act as Active Directory controllers

EFS Recovery Privileges

Recovers encrypted files when the original key material is unavailable

People who are designated EFS recovery Agents

Enrollment Agent

Requests certificates for users or computers

People who have certificate request authority

Exchange Enrollment Agent (offline request)

Generates offline certificate requests for Exchange mailbox owners

Enrollment agents who can request new certificates for Exchange users

Exchange Signature Only

Generates signature-only certificates for Exchange users

People who you want to allow to send signed messages with Exchange Server

Exchange User

Generates signature- and encryption-capable certificates

People who you want to allow to send signed or encrypted messages


Allows the use of IPSec encryption and authentication

Computers that use IPSec security

IPSec (offline request)

Allows computers that are not currently attached to the network to use IPSec when connected

Computers that use IPSec security

Router (offline request)

Authenticates clients to a server

Computers or routers that are managed as part of a domain

Smart Card Logon

Authenticates a client to a logon server

Smart card holders who use smart cards to log on; can't be used for secure e-mail or EFS security

Smart Card User

Authenticates a client; provides e-mail security

Smart card holders who have permission to use their smart cards to log on and secure e-mail

Subordinate Certification Authority

Issues and revokes certificates while acting as a subordinate CA

Subordinate CA computers

Trust List Signing

Signs the CTL

Administrators who have authorization to change the CTL's contents


Authenticates client-to-server messages; signs and encrypts e-mail; encrypts EFS data

Individual users with no other special privileges

User Signature

Signs e-mail; signs client-to-server authentication messages

Individual users who don't have encryption capability

Web Server

Authenticates server to clients

Web servers

Table 20-2. Certificate template features

Attribute Type Specifications

Basic constraints

Specifies whether this certificate can be used to sign other certificates and, if so, how many levels of nesting the resulting hierarchy can contain.

Default CSP list

Provides a list of cryptographic service providers (CSPs) that can be used with this certificate type. For example, EFS requires certificates generated with the Microsoft RSA CSP.

Display name

Displays the name when someone views the certificate's information; this is a "friendly" name that's less complex than the certificate's distinguished name (DN).

E-mail name

Specifies the e-mail address associated with the holder of this certificate.

Extended key usage

Specifies a list of extended functions (including signing a CTL, encrypting e-mail, and establishing secure network connections) for which this certificate can be used. The extended key usage information coexists with, and doesn't override, the standard key usage fields.

Key usage

Specifies what combination of basic operations (digital signatures, encryption, and key exchange) this certificate can be used for.

Machine certificate template

Specifies whether certificates that use this template are intended for use by people or by computers.

Security permissions

Specifies who can request a particular kind of certificate. For example, the default permissions for the Administrator template allow only users with administrative access to request administrator-level certificates.

Certificate Authority Types

Computers running Certificate Services can act as one of two distinct types of CAs: enterprise or stand-alone. Which type of CA you install determines to whom you can issue a certificate and what it can be used for, so the distinctions between them are important. The only real difference between the two is which policy module is installed, but the operational differences between them are significant.

Enterprise CA

The enterprise CA is designed to act as part of an enterprise security infrastructure. In that job, it can issue and revoke certificates for end users and subordinate CAs, according to the active policy modules and security settings you apply to the CA. As befits anything saddled with the "enterprise" label, enterprise CAs require Active Directory access. Several key features distinguish the enterprise CA from the stand-alone CA:

  • An enterprise CA is always trusted by all users and computers in its domain because the CA certificate appears in the Trusted Root Certification Authorities trust list in Active Directory.
  • Certificates issued by an enterprise CA can be used to log on to Windows 2000 domains with smart cards (as discussed in Chapters 18 and 19).
  • An enterprise CA publishes certificates and CRL information to Active Directory.

Another important difference between enterprise CAs and stand-alone CAs is that enterprise CAs use certificate types and templates to construct the content of newly issued certificates. This capability leads to some useful features. First, because they use templates, enterprise CAs can stuff the newly formed certificate with the proper set of attributes. In addition, enterprise CAs automatically fill in the subject name for newly issued certificates. Enterprise CAs have the unique property that they always either reject or approve a certificate request—they never mark one as pending. Enterprise CAs make this go/no-go decision based on the security permissions set on the requested template type, as well as on the account's permissions and group memberships in Active Directory.

Stand-Alone CA

The stand-alone CA doesn't require Active Directory—it's designed to be a separate box that can issue certificates for extranet or Internet use. As such, its purpose is to issue certificates for users who aren't part of your core organization and who won't have Active Directory access. The basic mechanics of certificate issuance for a stand-alone CA are similar to those for an enterprise CA, with a few exceptions:

  • Requests sent to a stand-alone CA are automatically marked as pending because the CA has no way to use templates and Active Directory information to verify them. This lack of directory information also means that requestors must completely fill out all the information in their request, because the CA has no way to look it up.
  • Certificates issued by a stand-alone CA can't be used for smart card-based logons, although you can store such certificates on a smart card.
  • Certificates and CRLs generated by the stand-alone CA aren't published anywhere—you must manually distribute them.

You can install a stand-alone CA on a server that participates in an Active Directory organization. If you do, the CA is able to publish certificate information if its server is a member of the Certificate Publishers group.

Microsoft Windows 2000 Server Administrator's Companion
Microsoft Windows 2000 Server Administrators Companion
ISBN: 0735617856
EAN: 2147483647
Year: 2003
Pages: 320

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: