Active Directory Certificate Services

Active Directory Certificate Services (AD CS) provides customizable services for issuing and managing certificates in software security systems that use public key technologies. For background information about public key cryptography and the benefits of having a public key infrastructure (PKI), see Public Key Infrastructures.

You can use AD CS to create one or more certification authorities (CA) to receive certificate requests, verify the information in the requests and the identity of the requester, issue certificates, revoke certificates, and publish certificate revocation data.

With AD CS, you can also:

  • Set up Web enrollment, the Network Device Enrollment Service, and the Online Responder service.

  • Manage enrollment and revocation of certificates for users, computers, services, and network devices such as routers.

  • Use Group Policy to distribute and manage certificates.

Additional references

  • Active Directory Certificate Services Overview

  • Common Scenarios for Using Active Directory Certificate Services

  • Setting Up Active Directory Certificate Services

  • Managing a Certification Authority

  • Use the Network Device Enrollment Service

  • Using Policy to Manage Active Directory Certificate Services

  • Troubleshoot Active Directory Certificate Services

  • Active Directory Certificate Services Resources


Active Directory Certificate Services Overview

Active Directory Certificate Services (AD CS) role services can be set up on servers running a variety of operating systems, including Windows Server® 2008, Windows Server 2003, and Windows 2000 Server. However, not all operating systems support all features or design requirements, and creating an optimal design requires careful planning and lab testing before you deploy AD CS in a production environment. Although you can deploy AD CS with a single server for a single certification authority (CA), deployments can involve multiple servers configured as root, policy, and issuing CAs, and other servers configured as Online Responders.

Note

AD CS is not available on Server Core installations of Windows Server 2008 or Windows Server 2008 for Itanium-Based Systems. A limited set of server roles is available for the Server Core installation option of Windows Server 2008 and for Windows Server 2008 for Itanium-Based Systems.

The following table lists the AD CS components that can be configured on different editions of Windows Server 2008.

Components | Web Edition | Standard Edition | Enterprise Edition | Datacenter Edition
CA | No | Yes | Yes | Yes
Network Device Enrollment Service | No | No | Yes | Yes
Online Responder service | No | No | Yes | Yes
Certification Authority Web Enrollment Support | No | Yes | Yes | Yes

The following features are available on servers running Windows Server 2008 that have been configured as CAs.

AD CS Features | Web Edition | Standard Edition | Enterprise Edition | Datacenter Edition
Customizable version 2 and version 3 certificate templates | No | No | Yes | Yes
Key archival | No | No | Yes | Yes
Role separation | No | No | Yes | Yes
Certificate manager restrictions | No | No | Yes | Yes
Delegated enrollment agent restrictions | No | No | Yes | Yes

Customizing AD CS

AD CS includes programmable interfaces so that developers can create support for additional transports, policies, and certificate properties and formats. For information about customizing AD CS, see Certificate Services Architecture (http://go.microsoft.com/fwlink/?LinkId=91405).

Managing AD CS

The following Microsoft Management Console (MMC) snap-ins can be used to manage AD CS:

  • Certification Authority. The primary tool for managing a CA, certificate revocation, and certificate enrollment.

  • Certificate Templates. Used to duplicate and configure certificate templates for publication to Active Directory Domain Services (AD DS) and for use with enterprise CAs.

  • Online Responder. Used to configure and manage Online Certificate Status Protocol (OCSP) responders.

  • Enterprise PKI. Used to monitor multiple CAs, certificate revocation lists (CRLs), and authority information access locations, and to manage AD CS objects that are published to AD DS.

  • Certificates. Used to view and manage certificate stores for a computer, user, or service.

Additional references

  • Public Key Infrastructures

  • Types of Certification Authorities


Public Key Infrastructures

A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs), and registration authorities that verify and authenticate the validity of each entity that is involved in an electronic transaction through the use of public key cryptography. Standards for PKIs are still evolving, even as they are being widely implemented as a necessary element of electronic commerce. For more information about planning a PKI and using public key cryptography, see Active Directory Certificate Services Resources.

The Microsoft PKI supports a hierarchical CA model that is scalable and provides consistency with a growing number of commercial and other CA products.

In its simplest form, a certification hierarchy consists of a single CA. However, a hierarchy frequently contains multiple CAs with clearly defined parent/child relationships. In this model, the child subordinate CAs are certified by their parent CA-issued certificates, which bind a CA's public key to its identity. The CA at the top of a hierarchy is referred to as the root CA. The child CA of a root CA is called a subordinate CA. For more information, see Types of Certification Authorities.

In Windows, if you trust a root CA (by having its certificate in your Trusted Root Certification Authorities certificate store), you trust every subordinate CA that has a valid CA certificate in the hierarchy. Thus, a root CA is a very important point of trust in an organization and should be secured accordingly. For more information, see CA Certificates.

There are several practical reasons for setting up multiple subordinate CAs, including:

  • Usage. Certificates may be issued for a number of purposes, such as secure e-mail and network authentication. The issuing policy for these uses may be distinct, and separation provides a basis for administering these polices.

  • Organizational divisions. There may be different policies for issuing certificates, depending upon an entity's role in the organization. Again, you can create subordinate CAs to separate and administer these policies.

  • Geographic divisions. Organizations may have entities at multiple physical sites. Network connectivity between these sites may require individual subordinate CAs for many or all sites.

  • Load balancing. If your PKI will be used to issue and manage a large number of certificates, having only one CA can result in considerable network load for that single CA. Using multiple subordinate CAs to issue the same kind of certificates divides the network load between CAs.

  • Backup and fault tolerance. Multiple CAs increase the possibility that your network will always have operational CAs available to respond to user requests.

A CA hierarchy can also provide administrative benefits, including:

  • Flexible configuration of the CA security environment to tailor the balance between security and usability. For example, you may choose to employ special-purpose cryptographic hardware on a root CA, operate it in a physically secure area, or operate it offline. These may be unacceptable for subordinate CAs, due to cost or usability considerations.

  • The ability to "turn off" a specific portion of the CA hierarchy without affecting established trust relationships. For example, you can easily shut down and revoke an issuing CA certificate that is associated with a specific business unit without affecting other parts of the organization.

Additional references

  • Active Directory Certificate Services Overview


Types of Certification Authorities

A certification authority (CA) accepts a certificate request, verifies the requester's information according to the policy of the CA, and then uses its private key to apply its digital signature to the certificate. The CA then issues the certificate to the subject of the certificate for use as a security credential within a public key infrastructure (PKI). A CA is also responsible for revoking certificates and publishing a certificate revocation list (CRL).

A CA can be an outside entity, such as VeriSign, or it can be a CA that you create for use by your organization by installing Active Directory Certificate Services (AD CS). Each CA can have distinct proof-of-identity requirements for certificate requesters, such as a domain account, employee badge, driver's license, notarized request, or physical address. Identification checks such as this often warrant an onsite CA, so that organizations can validate their own employees or members.

Microsoft enterprise CAs use a person's user account credentials as proof of identity. In other words, if you are logged on to a domain and request a certificate from an enterprise CA, the CA can authenticate your identity based on your account in Active Directory Domain Services (AD DS).

Every CA also has a certificate to confirm its own identity, issued by another trusted CA or, in the case of root CAs, issued by itself. It is important to remember that anyone can create a CA. Therefore, a user or administrator must decide whether to trust that CA and, by extension, the policies and procedures that the CA has in place for confirming the identity of the entities that are issued certificates by that CA.

Root and subordinate CAs

A root CA is meant to be the most trusted type of CA in an organization's PKI. If the root CA is compromised or issues a certificate to an unauthorized entity, then any certificate-based security in your organization becomes vulnerable. Therefore, both the physical security and the certificate issuance policy of a root CA are normally more rigorous than those for subordinate CAs. While root CAs can be used to issue certificates to end users for such tasks as sending secure e-mail, in most organizations they will only be used to issue certificates to other CAs, called subordinate CAs.

A subordinate CA is a CA that has been issued a certificate by another CA in your organization. Typically, a subordinate CA will issue certificates for specific uses, such as secure e-mail, Web-based authentication, or smart card authentication. Subordinate CAs can also issue certificates to other CAs that are more subordinate. Together, a root CA, the subordinate CAs that have been certified by the root, and subordinate CAs that have been certified by other subordinate CAs form a certification hierarchy.

For more information about certification hierarchies, see Public Key Infrastructures.

Enterprise and stand-alone CAs

This version of AD CS supports the installation of stand-alone CAs and enterprise CAs. For information about the operational characteristics of enterprise CAs and stand-alone CAs, see Enterprise Certification Authorities and Stand-Alone Certification Authorities.

Additional references

  • Active Directory Certificate Services Overview


Enterprise Certification Authorities

Enterprise certification authorities (CAs) can issue certificates for purposes such as digital signatures, secure e-mail by using S/MIME (Secure Multipurpose Internet Mail Extensions), authentication to a secure Web server by using Secure Sockets Layer (SSL) or Transport Layer Security (TLS), and logging on to a domain by using a smart card.

An enterprise CA has the following characteristics:

  • Requires access to Active Directory Domain Services (AD DS).

  • Uses Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain.

  • Publishes user certificates and certificate revocation lists (CRLs) to AD DS. In order to publish certificates to AD DS, the server that the CA is installed on must be a member of the Certificate Publishers group. This is automatic for the domain the server is in, but the server must be delegated the proper security permissions to publish certificates in other domains.

Note

You must be a member of the Domain Admins group or be an administrator with Write access to AD DS to install an enterprise root CA.

An enterprise CA issues certificates based on a certificate template. The following functionality is possible when you use certificate templates:

  • Enterprise CAs enforce credential checks on users during certificate enrollment. Each certificate template has a security permission set in AD DS that determines whether the certificate requester is authorized to receive the type of certificate they have requested.

  • The certificate subject name can be generated automatically from the information in AD DS or supplied explicitly by the requestor.

  • The policy module adds a predefined list of certificate extensions to the issued certificate. The extensions are defined by the certificate template. This reduces the amount of information a certificate requester has to provide about the certificate and its intended use.

  • Autoenrollment can be used to issue certificates.

Additional references

  • Types of Certification Authorities


Stand-Alone Certification Authorities

Stand-alone certification authorities (CAs) can issue certificates for purposes such as digital signatures, secure e-mail by using S/MIME (Secure Multipurpose Internet Mail Extensions), and authentication to a secure Web server by using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

A stand-alone CA has the following characteristics:

  • Unlike an enterprise CA, a stand-alone CA does not require the use of Active Directory Domain Services (AD DS). Even if you are using AD DS, stand-alone CAs can be used as offline trusted root CAs in a CA hierarchy or to issue certificates to clients over an extranet or the Internet.

  • When users submit a certificate request to a stand-alone CA, they must provide their identifying information and specify the type of certificate they need. (This does not need to be done when submitting a request to an enterprise CA because the enterprise user's information is already in AD DS and the certificate type is described by a certificate template). The authentication information for requests is obtained from the local computer's Security Accounts Manager database.

  • By default, all certificate requests sent to the stand-alone CA are set to pending until the administrator of the stand-alone CA verifies the submitted information and approves the request. The administrator has to perform these tasks because the certificate requester's credentials are not verified by the stand-alone CA.

  • Certificate templates are not used.

  • The administrator has to explicitly distribute the stand-alone CA's certificate to the domain user's trusted root store, or users must perform that task themselves.

  • If a cryptographic provider supporting elliptic curve cryptography (ECC) is used, a stand-alone CA will honor every key usage for the ECC key. For more information, see Cryptography Next Generation (http://go.microsoft.com/fwlink/?LinkID=85480).

When a stand-alone CA uses AD DS, the CA has these additional features:

  • If a member of the Domain Admins group or an administrator with Write access to a domain controller installs a stand-alone root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. For this reason, if you install a stand-alone root CA in an Active Directory domain, you should not change the default action of the CA upon receiving certificate requests (which marks requests as pending). Otherwise, you will have a trusted root CA that automatically issues certificates without verifying the identity of the certificate requester.

  • If a stand-alone CA is installed by a member of the Domain Admins group of the parent domain in the enterprise, or by an administrator with Write access to AD DS, then the stand-alone CA will publish its CA certificate and the certificate revocation list (CRL) to AD DS.

Additional references

  • Types of Certification Authorities


Common Scenarios for Using Active Directory Certificate Services

One or more certification authorities (CAs) can be configured to support a number of scenarios that require the added security that certificates can provide. The following checklists identify the general steps and procedures needed to configure one or more CAs to enable these scenarios.

  • Checklist: Configure CAs to Issue and Manage Certificates

  • Checklist: Protect Encrypted Data from Loss by Enabling Key Archival and Recovery

  • Checklist: Enhance Certificate Revocation Checking in Diverse Environments by Setting Up an Online Responder Array

  • Checklist: Authenticate Web Servers with Certificates Issued by a Windows-Based CA

  • Checklist: Enhance Wireless Network Security by Requiring Certificates for Authentication and Encryption

  • Checklist: Strengthen Identity Management by Issuing Certificates for Smart Cards


Checklist: Configure CAs to Issue and Manage Certificates

Most organizations deploy an offline root certification authority (CA) and one or more subordinate CAs as a public key infrastructure (PKI). After these CAs have been installed on servers, a number of follow-up steps must be completed before the PKI can be used to issue, support, and manage certificates. These follow-up tasks involve setting up certificate revocation options, configuring certificates or certificate templates, and configuring enrollment and issuance options.

Task | Reference
Plan the PKI. | Public Key Infrastructures
Set up a stand-alone or enterprise root CA. | Install a Root Certification Authority
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Complete additional CA configuration tasks. | Managing a Certification Authority
Install and configure certificate templates. | Managing Certificate Templates
Configure certificate enrollment. | Managing Certificate Enrollment


Checklist: Protect Encrypted Data from Loss by Enabling Key Archival and Recovery

If a certificate that is used to encrypt data with Encrypting File System (EFS) is lost, the data cannot be recovered unless a key recovery agent has been configured. Planning for and establishing a key archival and recovery plan based on Microsoft certification authority (CA) certificates can help you protect your organization's data resources from becoming irretrievable if the original EFS key is no longer accessible.

Task | Reference
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Install and configure certificate templates. | Managing Certificate Templates
Configure key archival and recovery. | Managing Key Archival and Recovery
Configure certificate enrollment. | Managing Certificate Enrollment


Checklist: Enhance Certificate Revocation Checking in Diverse Environments by Setting Up an Online Responder Array

Unlike certificate revocation lists (CRLs), which are distributed periodically, contain information about all certificates that have been revoked or suspended, and can become quite large, an Online Responder responds to client requests for information about the status of individual certificates. The amount of data retrieved per request remains constant no matter how many revoked certificates there might be, which makes it easier to provide current status information to large numbers of clients when it might take an unacceptable amount of time for clients to download a CRL. Setting up multiple linked Online Responders in an Array can provide flexibility and scalability to revocation checking in diverse network environments.

Task | Reference
Set up additional subordinate certification authorities (CAs). | Install a Subordinate Certification Authority
Install and configure certificate templates. | Managing Certificate Templates
Configure the issuing CA to issue Online Certificate Status Protocol (OCSP) Response Signing certificates. | Configure a CA to Support OCSP Responders
Install and configure the Online Responder. | Set Up an Online Responder
Create a revocation configuration for the Online Responder. | Creating a Revocation Configuration
Create an Online Responder Array. | Managing an Online Responder Array


Checklist: Authenticate Web Servers with Certificates Issued by a Windows-Based CA

Certificates can be used to authenticate queries sent by clients to Web servers. By using certificates issued by a Microsoft certification authority (CA), clients can verify that the query results have not been tampered with and that the results were returned by the correct domain controller or Web server.

Task | Reference
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Install and configure a Web Server certificate template. | Managing Certificate Templates
Configure certificate enrollment. | Managing Certificate Enrollment


Checklist: Enhance Wireless Network Security by Requiring Certificates for Authentication and Encryption

Wireless networks make it possible for network users to access data and resources from multiple locations without relying on a physical connection to the network. The large number and variety of wireless clients and the potential security risks that they pose make it important for administrators to enhance data protection and to prevent unwanted clients from accessing the network. Certificates issued and supported by a Microsoft certification authority (CA) can enhance the security of a wireless network with strong certificate-based authentication and encrypted communication between clients and network servers.

Task | Reference
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Install and configure certificate templates, including the RAS and IAS Server, Workstation Authentication, and User certificate templates. | Managing Certificate Templates
Configure certificate enrollment. | Set Up Automatic Certificate Enrollment
Deploy RAS and IAS Server certificates. | Deploy a CA and NPS Server Certificate
Configure 802.1X wireless clients by using Group Policy. | Configure 802.1X Wireless Clients Running Windows Vista with Group Policy
Configure 802.1X wireless access points as Remote Authentication Dial-In User Service (RADIUS) clients in Network Policy Server (NPS). | Add a New RADIUS Client
If you want to perform authorization by group, create a user group in Active Directory Domain Services (AD DS) that contains the users who are allowed to access the network through the wireless access points. | Create a Group for a Network Policy
In NPS, configure one or more network policies for 802.1X wireless access. | Add a Network Policy Create policies for 802.1X Wired or Wireless with a Wizard


Checklist: Strengthen Identity Management by Issuing Certificates for Smart Cards

Smart cards and other physical authentication tokens improve upon basic password-based authentication by requiring users to supplement something they know—a password or personal identification number (PIN)—with something they have—the smart card or token. An obstacle to smart card deployments has been the cost and difficulty in managing smart card certificates. However, issuing and managing certificates with a Windows-based certification authority (CA) can be an efficient and cost-effective solution for deploying smart cards.

Task | Reference
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Install and configure certificate templates. | Managing Certificate Templates
Configure and implement a smart card enrollment station. | Set Up and Use a Smart Card Enrollment Station
Configure smart card clients. | Configure Smart Card Clients (http://go.microsoft.com/fwlink/?LinkID=94261)
Issue smart cards to users. | Issue Smart Cards (http://go.microsoft.com/fwlink/?LinkID=94262)


Setting Up Active Directory Certificate Services

Active Directory Certificate Services (AD CS) role services can be set up individually, with multiple role services on a single server, or with each role service installed on a separate server. The role services and configuration options that are available will vary depending on the version of Windows Server 2008 that you are using. For more information, see Active Directory Certificate Services Overview.

The following topics explain installation options for various AD CS role services:

  • Setting Up a Certification Authority

  • Set Up Certification Authority Web Enrollment Support

  • Configure the Network Device Enrollment Service

  • Setting Up Online Responder Services in a Network


Setting Up a Certification Authority

Many organizations will set up multiple certification authorities (CAs), including a root and subordinate CA. The following topics describe how to set up different types of CAs and other installation-related procedures.

  • Install a Root Certification Authority

  • Install a Subordinate Certification Authority

  • Set Up a Certification Authority by Using a Hardware Security Module

  • Move a CA to a Different Computer

  • Uninstall a Certification Authority


Install a Root Certification Authority

For most organizations, a root certification authority (CA) certificate is the first Active Directory Certificate Services (AD CS) role service that they install. In a basic public key infrastructure (PKI), a root CA may be the only CA that an organization deploys.

Whether you install just one CA or multiple CAs, the root CA certificate establishes the foundation and basic rules that govern certificate issuance and use for your entire PKI. Where the root certificate defines standards for what is acceptable and unacceptable in the PKI hierarchy, AD CS applies those standards to any other CAs and AD CS role services.

A root CA can be a stand-alone or enterprise CA. If there is more than one CA in the organization, many organizations minimize the exposure of their root CA by keeping it offline except when it is needed to process a request for a subordinate CA certificate.

Membership in local Administrators, or equivalent, is the minimum required to complete this procedure. If this will be an enterprise CA, membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To install a root CA

  1. Open Server Manager, click Add Roles, click Next, and click Active Directory Certificate Services. Click Next two times.

  2. On the Select Role Services page, click Certification Authority. Click Next.

  3. On the Specify Setup Type page, click Standalone or Enterprise. Click Next.

    Note

    You must have a network connection to a domain controller in order to install an enterprise CA.

  4. On the Specify CA Type page, click Root CA. Click Next.

    For more information, see Types of Certification Authorities.

  5. On the Set Up Private Key page, click Create a new private key. Click Next.

  6. On the Configure Cryptography page, select a cryptographic service provider, key length, and hash algorithm. Click Next.

    For more information, see Cryptographic Options for CAs.

  7. On the Configure CA Name page, create a unique name to identify the CA. Click Next.

    For more information, see Certification Authority Naming.

  8. On the Set Validity Period page, specify the number of years or months that the root CA certificate will be valid. Click Next.

  9. On the Configure Certificate Database page, accept the default locations unless you want to specify a custom location for the certificate database and certificate database log. Click Next.

    For more information, see Certificates Database.

  10. On the Confirm Installation Options page, review all of the configuration settings that you have selected. If you want to accept all of these options, click Install and wait until the setup process has finished.

Additional references

  • Setting Up a Certification Authority

  • Certification Authority Naming

  • Cryptographic Options for CAs

  • Certificates Database

  • Install a Subordinate Certification Authority


Certification Authority Naming

Before you configure certification authorities (CAs) in your organization, you should establish a CA naming convention.

Names for CAs cannot be more than 64 characters in length. You can create a name by using any Unicode character, but you might want to use the ANSI character set if interoperability is a concern. For example, certain types of routers will not be able to use the Network Device Enrollment Service to enroll for certificates if the CA name contains special characters such as an underscore.

Important

If you use non-Latin characters (such as Cyrillic, Arabic, or Chinese characters), your CA name must contain fewer than 64 characters. If you use only non-Latin characters, your CA name can be no more than 37 characters in length.

In Active Directory Domain Services (AD DS), the name that you specify when you configure a server as a CA becomes the common name of the CA, and this name is reflected in every certificate that the CA issues. For this reason, it is important that you do not use the fully qualified domain name for the common name of the CA. This way, malicious users who obtain a copy of a certificate cannot identify and use the fully qualified domain name of the CA to create a potential security vulnerability.

The CA name does not have to be identical to the name of the computer. However, you cannot change the name of a server after Active Directory Certificate Services (AD CS) has been installed without invalidating all the certificates issued by the CA.

To change the server name after AD CS has been installed, you must uninstall the CA, change the name of the server, reinstall the CA, and reissue all the certificates issued by the CA.

You do not have to reinstall a CA if you rename a domain; however, you will have to reconfigure the CA to support the name change. For more information, see Windows Server 2003 Active Directory Domain Rename Tools (http://go.microsoft.com/fwlink/?LinkId=91448).

Additional references

  • Install a Root Certification Authority


Cryptographic Options for CAs

Selecting cryptographic options for a certification authority (CA) can have significant security, performance, and compatibility implications for that CA. Although the default cryptographic options may be suitable for most CAs, the ability to implement custom options can be useful to administrators and application developers with a more advanced understanding of cryptography and a need for this flexibility. Cryptographic options can be implemented by using cryptographic service providers (CSPs) or key storage providers.

CSPs are hardware and software components of Windows operating systems that provide generic cryptographic functions. CSPs can be written to provide a variety of encryption and signature algorithms.

Key storage providers can provide strong key protection on computers running Windows Vista or Windows Server 2008.

On the Configure Cryptography page of the CA setup process, you can configure the following options:

  • Select a cryptographic service provider. Windows Server 2008 includes a number of CSPs, and additional CSPs or key storage providers can be added. In Windows Server 2008, the provider list includes the name of the algorithm. All providers with a number sign (#) in the name are Cryptography Next Generation (CNG) providers. CNG providers can support multiple asymmetric algorithms. CSPs can implement only a single algorithm.

    Note

    For more information, see Cryptography Next Generation (http://go.microsoft.com/fwlink/?LinkID=85480).

  • Key character length. Each CSP supports different character lengths for cryptographic keys. Configuring a longer key character length can enhance security by making it more difficult for a hostile user to decrypt the key, but it can also slow down the performance of cryptographic operations.

  • Select the hash algorithm for signing certificates issued by this CA. Hash algorithms are used to sign CA certificates and certificates issued by a CA to ensure that they have not been tampered with. Each CSP can support different hash algorithms.

    Note

    The list of available hash algorithms can be restricted further if the DiscreteAlgorithm option has been configured in a CAPolicy.inf file installed on the computer before CA setup begins.

  • Use strong private key protection features provided by the CSP (this may require administrator interaction every time the private key is accessed by the CA). This option can be used to help prevent unapproved use of the CA and its private key by requiring the administrator to enter a password before every cryptographic operation.

Additional references

  • Install a Root Certification Authority


Certificates Database

When you install a certification authority (CA), you also need to create a CA database to record:

  • Every certificate issued by the CA.

  • Every private key archived by the CA.

  • Every certificate revoked by the CA.

  • Every certificate request received by the CA, regardless of whether the request is approved, denied, or set to pending.

This database should be located on an NTFS file system partition on the server's disk drives to provide the best security possible for the database file. You specify the locations for the database during the setup of a CA. By default, the database is located in systemroot\system32\certlog.

You also specify the location of the CA database log during Active Directory Certificate Services (AD CS) setup. The CA database log keeps a record of every transaction involving the CA database. CA database logs are used when restoring the CA from a backup. If a CA is restored from a backup that is one month old, then the CA database can be updated with more recent activity recorded in the log to restore the database to its most current state. When you back up a CA, the existing certificate database logs will be truncated in size because they will no longer be needed to restore the certificate database to its most current state.

The name of the database file is based on the name of the CA, with an .edb extension.

The Certification Authority snap-in allows you to view and administer the CA database.

For more information about CA backup and restore, see Protecting a CA from Data Loss.

Additional references

  • Install a Root Certification Authority


Install a Subordinate Certification Authority

After a root certification authority (CA) has been installed, many organizations will install one or more subordinate CAs to implement policy restrictions on the public key infrastructure (PKI) and to issue certificates to end clients. Using at least one subordinate CA can help protect the root CA from unnecessary exposure.

If a subordinate CA will be used to issue certificates to users or computers with accounts in an Active Directory domain, installing the subordinate CA as an enterprise CA allows you to use the client's existing account data in Active Directory Domain Services (AD DS) to issue and manage certificates and to publish certificates to AD DS.

Membership in local Administrators, or equivalent, is the minimum required to complete this procedure. If this will be an enterprise CA, membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To install a subordinate CA

  1. Open Server Manager, click Add Roles, click Next, and click Active Directory Certificate Services. Click Next two times.

  2. On the Select Role Services page, click Certification Authority, and then click Next.

  3. On the Specify Setup Type page, click Standalone or Enterprise, and then click Next.

    For more information, see Types of Certification Authorities.

    Note

    You must have a network connection to a domain controller in order to install an enterprise CA.

  4. On the Specify CA Type page, click Subordinate CA, and then click Next.

  5. On the Set Up Private Key page, click Create a new private key, and then click Next.

  6. On the Configure Cryptography page, select a cryptographic service provider, key length, and hash algorithm. Click Next.

    For more information, see Cryptographic Options for CAs.

  7. On the Request Certificate page, browse to locate the root CA, or if the root CA is not connected to the network, save the certificate request to a file so that it can be processed later. Click Next.

    Note

    The subordinate CA cannot be used until it has been issued a root CA certificate and this certificate has been used to complete the installation of the subordinate CA.

  8. On the Configure CA Name page, create a unique name to identify the CA. Click Next.

    For more information, see Certification Authority Naming.

  9. On the Set Validity Period page, specify the number of years or months that the CA certificate will be valid. Click Next.

  10. On the Configure Certificate Database page, accept the default locations unless you want to specify a custom location for the certificate database and certificate database log. Click Next.

    For more information, see Certificates Database.

  11. On the Confirm Installation Options page, review all of the configuration settings that you have selected. If you want to accept all of these options, click Install and wait until the setup process has finished.

Additional references

  • Setting Up a Certification Authority

  • Install a Root Certification Authority


Set Up a Certification Authority by Using a Hardware Security Module

Using a hardware security module (HSM) can enhance the security of a certification authority (CA) and public key infrastructure (PKI).

An HSM is a dedicated hardware device that is managed separately from the operating system. These modules provide a secure hardware store for CA keys, as well as a dedicated cryptographic processor to accelerate signing and encrypting operations. Windows utilizes the HSM through the CryptoAPI interfaces—the HSM functions as a cryptographic service provider (CSP) device.

HSMs typically are PCI adapters but are also available as network-based appliances. If an organization plans to implement two or more CAs, you can install a single network-based HSM and share it among multiple CAs.

In order to set up a CA by using an HSM, the HSM must be installed and configured before you set up any CAs whose keys will be stored on the HSM.

Additional references

  • Setting Up a Certification Authority


Move a CA to a Different Computer

Certification authorities (CAs) are configured to exist for many years or decades, during which time you may want to upgrade the hardware and operating system that supports the CA.

Moving a CA from one computer to a second computer involves the following procedures:

  • Backing up the CA on the first computer

  • Restoring the CA on the second computer

You must also confirm that the computer that you are restoring the CA on has the same name as the computer that you backed up the CA from. If the name is different, see article 298138 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=94223).

To move a CA from a server that is running Windows Server 2003 to a server that is running Windows Server® 2008, you can either complete the Windows upgrade first and then move the CA or move the CA first and then upgrade Windows.

  • To upgrade Windows first: Upgrade the first server from Windows Server 2003 to Windows Server 2008, back up the CA on this server, and then restore the CA on a second server running Windows Server 2008.

  • To move the CA first: Back up the CA on a computer running Windows Server 2003, restore the CA on a second computer running Windows Server 2003, and then upgrade the second server to Windows Server 2008.

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To back up a CA

  1. Open the Certification Authority snap-in.

  2. If you are backing up an enterprise CA, click Certificate Templates for the CA, and record the names of the certificate templates that are listed.

    Note

    Certificate template settings are stored in Active Directory Domain Services (AD DS) and are not automatically backed up. You will need to manually add the certificate templates that you need to the new CA.

  3. In the Certification Authority snap-in, right-click the CA name, click All Tasks, and then click Back up CA to start the Certification Authority Backup Wizard.

  4. Click Next, and select the Private key and CA certificate and Certificate database and certificate database log check boxes.

  5. Specify an empty folder or storage media as the backup location, and then click Next.

  6. Type a password for the CA private key backup file, and type it a second time to confirm the password.

  7. Click Next, verify that the Private Key and CA Certificate and Issued Log and Pending Requests backup settings are displayed, and then click Finish.

  8. Click Start, click Run, type regedit, and then click OK.

    Caution

    Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

  9. Locate and right-click the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

  10. Click Export.

  11. Save the registry file in the CA backup folder that you used for the Certification Authority Backup Wizard.

  12. Uninstall the CA from the old server, and then rename the old server or permanently disconnect it from the network.

Before you begin the restore procedure, confirm that the %Systemroot% folder of the target server running Windows Server 2008 matches the %Systemroot% folder of the server from which the backup is taken.

In addition, the location of the CA restore must match the location of the CA backup. For example, if you back up the CA from the D:\Winnt\System32\Certlog folder, you must restore the backup to the D:\Winnt\System32\Certlog folder. After you restore the backup, you can move the CA database files to a different location.

Membership in local Administrators, or equivalent, is the minimum required to complete this procedure. If this is an enterprise CA, membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To restore a CA on a new server from a backup copy

  1. Open Server Manager, and click Active Directory Certificate Services. Click Next two times.

  2. On the Select Role Services page, select the Certification Authority check box, and then click Next.

  3. On the Specify Setup Type page, click either Standalone or Enterprise, and then click Next.

    For more information, see Types of Certification Authorities.

    Note

    You must have a network connection to a domain controller in order to install an enterprise CA.

  4. On the Specify CA Type page, click the appropriate CA type, and then click Next.

  5. On the Set Up Private Key page, click Use existing private key, click Select a certificate and use its associated private key, and then click Next.

  6. On the Select Existing Certificate page, click Import, type the path of the .P12 file in the backup folder, type the password that you chose in the previous procedure to protect the backup file, and then click OK.

  7. In the Public and Private Key Pair dialog box, verify that Use existing keys is selected.

  8. Click Next two times.

  9. On the Configure Certificate Database page, specify the same location for the certificate database and certificate database log as on the previous CA computer. Click Next.

    For more information, see Certificates Database.

  10. On the Confirm Installation Options page, review all of the configuration settings that you have selected. If you want to accept all of these options, click Install and wait until the setup process has finished.

  11. Open the Services snap-in to stop the Active Directory Certificate Services (AD CS) service.

  12. Locate the registry file that you saved in the backup procedure, and then double-click it to import the registry settings. If the path that is shown in the registry export from the old CA differs from the new path, you must adjust your registry export accordingly.

    Caution

    Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

  13. Open the Certification Authority snap-in, right-click the CA name, click All Tasks, and then click Restore CA to open the Certification Authority Restore Wizard.

  14. Click Next, and select the Private key and CA certificate and Certificate database and certificate database log check boxes.

  15. Type the backup folder location, and then click Next.

  16. Verify the backup settings. The Issued Log and Pending Requests settings should be displayed.

  17. Click Finish, and then click Yes to restart AD CS when the CA database is restored.

  18. If this is an enterprise CA, restore the certificate templates from AD DS that you recorded in the previous procedure. For more information, see Add a Certificate Template to a Certification Authority.

Additional references

  • Setting Up a Certification Authority


Uninstall a Certification Authority

There may be times when you need to uninstall a certification authority (CA). However, clients will not be able to send requests to this CA and some applications that depend on your public key infrastructure (PKI) may not function properly after a CA that is needed to verify the validity and revocation status of a certificate has been uninstalled.

If you are permanently decommissioning the CA before its expected expiration date, then the CA certificate should be revoked from its parent CA and you should list "Cease of operation" as the reason for the revocation. If the CA is a self-signed root CA, then all of the certificates issued by the CA that have not expired should be revoked and a certificate revocation list (CRL) should be generated that lists the same reason. This will indicate that the certificates are no longer valid because the CA has been decommissioned.

Uninstalling an enterprise CA should be done properly to ensure that its CA enrollment object is removed from Active Directory Domain Services (AD DS). Failure to do so may cause Active Directory clients to continue attempts to enroll for certificates from that CA. If an enterprise CA cannot be uninstalled normally, use the Enterprise PKI snap-in to manually remove the CA objects from AD DS.

If you are uninstalling an enterprise CA, membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To uninstall a CA

  1. Click Start, point to Administrative Tools, and click Server Manager.

  2. Under Roles Summary, click Remove Roles to start the Remove Roles Wizard. Click Next.

  3. Clear the Active Directory Certificate Services check box, and click Next.

  4. On the Confirm Removal Options page, review the information, and then click Remove.

  5. If Internet Information Services (IIS) is running and you are prompted to stop the service before proceeding with the uninstall process, click OK.

  6. After the Remove Roles Wizard is finished, you must restart the server to complete the uninstall process.

The procedure is slightly different if you have multiple Active Directory Certificate Services (AD CS) role services installed on a single server. You can use the following procedure to uninstall a CA but retain other AD CS role services.

You must log on with the same permissions as the user who installed the CA to complete this procedure. If you are uninstalling an enterprise CA, membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To uninstall a CA role service

  1. Click Start, point to Administrative Tools, and click Server Manager.

  2. Under Roles Summary, click Active Directory Certificate Services.

  3. Under Roles Services, click Remove Role Services.

  4. Clear the Certification Authority check box, and click Next.

  5. On the Confirm Removal Options page, review the information, and then click Remove.

  6. If IIS is running and you are prompted to stop the service before proceeding with the uninstall process, click OK.

  7. After the Remove Roles Wizard is finished, you must restart the server to complete the uninstall process.

If the remaining role services, such as the Online Responder service, were configured to use data from the uninstalled CA, you must reconfigure these services to support a different CA.

After a CA has been uninstalled, the following information is left on the server:

  • The CA database

  • The CA public and private keys

  • The CA's certificates in the Personal store

  • The CA's certificates in the shared folder, if a shared folder was specified during AD CS setup

  • The CA chain's root certificate in the Trusted Root Certification Authorities store

  • The CA chain's intermediate certificates in the Intermediate Certification Authorities store

  • The CA's CRL

This information is kept on the server by default, in case you are uninstalling and then reinstalling the CA. For example, you might uninstall and reinstall the CA if you want to change a stand-alone CA to an enterprise CA.

Additional references

  • Setting Up a Certification Authority


Set Up Certification Authority Web Enrollment Support

Active Directory Certificate Services (AD CS) Web enrollment support can be installed on any computer running Windows Server® 2008 Standard, Windows Server 2008 Enterprise, or Windows Server 2008 Datacenter. The certificate enrollment data can come from a certification authority (CA) on a computer running Windows Server 2008, a CA on a computer running Windows Server 2003, or from a non-Microsoft CA.

The following procedure can be used if none of the AD CS role services (such as a CA) have been installed on this computer.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To install Web enrollment support

  1. Click Start, point to Administrative Tools, and then click Server Manager.

  2. Click Manage Roles. Under Active Directory Certificate Services, click Add role services. If a different AD CS role service has already been installed on this computer, select the Active Directory Certificate Services check box in the Role Summary pane, and then click Add role services.

  3. On the Select Role Services page, select the Certification Authority Web Enrollment Support check box.

  4. Click Add required role services, and then click Next.

  5. On the Specify CA page, if a CA is not installed on this computer, click Browse to select the CA that you want to associate with Web enrollment, click OK, and then Next.

  6. Click Next, review the information listed, and click Next again.

  7. On the Confirm Installation Options page, click Install.

  8. When the installation is complete, review the status page to verify that the installation was successful.

Additional considerations

  • Installation of the Web enrollment pages configures the computer as a registration authority. This computer is also known as a "CA Web proxy" or a "Web enrollment station."

Additional references

  • Setting Up a Certification Authority


Configure the Network Device Enrollment Service

Setting up the Network Device Enrollment Service involves the following tasks:

  • Add the account that will be the registration authority to the Internet Information Services (IIS) user group.

  • Set up and configure the Network Device Enrollment Service.

Membership in the Administrators group is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To add a designated registration authority to the IIS_IUSRS group

  1. Open the Local Users and Groups snap-in, and double-click the Groups folder.

  2. Click the IIS_IUSRS built-in group.

  3. On the Action menu, click Add to Group.

  4. Click Add, type the domain name of the account that will be the registration authority, and then click OK.

Membership in Enterprise Admins or Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To set up and configure the Network Device Enrollment Service

  1. On the server where you want to install the Network Device Enrollment Service, open Server Manager, and click Add Roles to start the Add Roles Wizard.

  2. On the Select Server Roles page, select the Active Directory Certificate Services check box, and then click Next two times.

  3. On the Select Role Services page, clear the Certification Authority check box, and then select the Network Device Enrollment Service check box.

    You are prompted to install IIS and Windows Activation Service.

  4. Click Add Required Role Services, and then click Next three times.

  5. On the Specify User Account page, click Select User, and type the user name and password for the account that the Network Device Enrollment Service will use to authorize certificate requests. Click OK, and then click Next.

  6. On the Specify CA page, if this computer does not host a CA, select either the CA name or Computer name check box, click Browse to locate the CA that will issue the Network Device Enrollment Service certificates, and then click Next.

  7. On the Specify Registry Authority Information page, type the name of the registration authority in the RA name box. Under Country/region, select the country/region you are in, and then click Next.

  8. On the Configure Cryptography page, accept the default values for the signature and encryption keys or configure your own values, and then click Next.

  9. Review the summary of configuration options, and then click Install.

For more information about the Simple Certificate Enrollment Protocol (SCEP), see the Internet Engineering Task Force Web site (http://go.microsoft.com/fwlink/?LinkId=71055).

For more information about the Network Device Enrollment Service, see AD CS: Network Device Enrollment Service (http://go.microsoft.com/fwlink/?LinkId=85475) and Microsoft SCEP Implementation Whitepaper (http://go.microsoft.com/fwlink/?LinkId=93875).

Additional references

  • Setting Up Active Directory Certificate Services

  • Use the Network Device Enrollment Service


Setting Up Online Responder Services in a Network

Setting up Online Responder services involves several interrelated steps. Several of these steps must be performed on the certification authority (CA) that will be used to issue the Online Certificate Status Protocol (OCSP) signing certificates necessary for an Online Responder to function. These steps include configuring the appropriate certificate template, enabling the certificate template, and configuring and completing certificate autoenrollment so that the computer hosting the Online Responder has the certificates needed for the Online Responder to function.

Installation and configuration of an Online Responder involves using Server Manager to install the Online Responder service, the Certificate Templates snap-in to configure and publish OCSP Response Signing certificate templates, the Certification Authority snap-in to include OCSP extensions in the certificates that it will issue and to issue OCSP Response Signing certificates, and the Online Responder snap-in to create a revocation configuration.

The following topics describe the steps needed to complete these installation and configuration steps and how to verify that the installation was successful.

  • Configure a CA to Support OCSP Responders

  • Set Up an Online Responder

  • Creating a Revocation Configuration

  • Verify an Online Responder Installation


Configure a CA to Support OCSP Responders

To function properly, an Online Responder must have a valid Online Certificate Status Protocol (OCSP) Response Signing certificate. This OCSP Response Signing certificate is also needed if you are using a non-Microsoft OCSP responder.

Configuring a certification authority (CA) to support OCSP responder services includes the following steps:

  1. Configure certificate templates and issuance properties for OCSP Response Signing certificates.

  2. Configure enrollment permissions for any computers that will be hosting Online Responders.

  3. If this is a Windows Server 2003–based CA, enable the OCSP extension in issued certificates.

  4. Add the location of the Online Responder or OCSP responder to the authority information access extension on the CA.

  5. Enable the OCSP Response Signing certificate template for the CA.

The certificate template used to issue an OCSP Response Signing certificate must contain an extension titled "OCSP No Revocation Checking" and the OCSP Signing application policy. Permissions must also be configured to allow the computer that will host the Online Responder to enroll for this certificate.

The following procedure is for a CA that is installed on a computer running Windows Server 2008.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To configure the certificate template for an OCSP Response Signing certificate issued by a Windows Server 2008–based CA

  1. Open the Certificate Templates snap-in.

    Note

    If you are completing this procedure on a computer that does not have a CA or Online Responder installed, you may need to install the Active Directory Certificate Services (AD CS) Remote Server Administration Tools in order to use the Certificate Templates snap-in. For more information about the Remote Server Administration Tools, see Administer an Online Responder from Another Computer.

  2. Right-click the OCSP Response Signing template, and then click Properties.

  3. Click the Security tab. Under Group or user name, click Add.

  4. Click Object Types, select the Computers check box, and then click OK.

  5. Type the name of or browse to select the computer hosting the Online Responder or OCSP responder services, and click OK.

  6. In the Group or user names dialog box, click the computer name, and in the Permissions dialog box, select the Read and Enroll check boxes. Then click OK.

The following procedure is for a CA that is installed on a computer running Windows Server 2003. The procedure must be completed on a computer running Windows Server 2008.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To configure the certificate template for an OCSP Response Signing certificate issued by a Windows Server 2003–based CA

  1. Open the Certificate Templates snap-in.

  2. Right-click the OCSP Response Signing template, and then click Duplicate. Click Windows 2003 Server, Enterprise Edition, and then click OK.

  3. Click the Security tab. Under Group or user name, click Add, and then type the name of or browse to select the computer hosting the Online Responder or OCSP responder services.

  4. Click Object Types, select the Computers check box, and then click OK.

  5. Type the name of or browse to select the computer hosting the Online Responder or OCSP responder services, and click OK.

  6. In the Group or user names dialog box, click the computer name, and in the Permissions dialog box, select the Read and Enroll check boxes.

Note

The default OCSP Response Signing certificate template contains an extension titled "OCSP No Revocation Checking." Do not remove this extension, which is used by many clients to verify that responses signed with the signing certificate are valid.

If the CA is installed on a computer running Windows Server 2003, you must complete the following procedure in order to configure the policy module on the CA to issue certificates that include this extension.

You must be a local administrator to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To prepare a computer running Windows Server 2003 to issue OCSP Response Signing certificates

  1. On the server hosting the CA, open a command prompt, and type:

    certutil -v -setreg policy\EnableRequestExtensionList +1.3.6.1.5.5.7.48.1.5

  2. Stop and restart the CA. You can do this at a command prompt by running the following commands:

    net stop certsvc
net start certsvc

To configure your CA for OCSP, you must use the Certification Authority snap-in to complete the following CA configuration steps:

  • Add the location of the Online Responder or OCSP responder to the authority information access extension.

  • Enable the certificate template for the CA.

You must be a CA administrator to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To configure a CA to support an Online Responder or OCSP responder services

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. Click the Extensions tab.

  5. In the Select extension list, click Authority Information Access (AIA), and then click Add.

  6. Specify the locations from which users can obtain certificate revocation data, such as http://computername/ocsp.

  7. Select the Include in the online certificate status protocol (OCSP) extension check box.

  8. In the console tree of the Certification Authority snap-in, right-click Certificate Templates, and then click New Certificate Templates to Issue.

  9. In Enable Certificate Templates, select the OCSP Response Signing template and any other certificate templates that you configured previously, and then click OK.

  10. Double-click Certificate Templates, and verify that the modified certificate templates appear in the list.

Additional references

  • Setting Up Online Responder Services in a Network

  • Renew OCSP Response Signing Certificates with an Existing Key


Set Up an Online Responder

An Online Responder can be installed on any computer running Windows Server® 2008 Enterprise or Windows Server 2008 Datacenter. The certificate revocation data can come from a certification authority (CA) on a computer running Windows Server 2008, a CA on a computer running Windows Server 2003, or from a non-Microsoft CA.

Note

Internet Information Services (IIS) must also be installed on this computer before the Online Responder can be installed.

The following procedure can be used if none of the Active Directory Certificate Services (AD CS) role services (such as a CA) have been installed on this computer.

Membership in local Administrators, or equivalent, is the minimum required to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To install the Online Responder service

  1. Click Start, point to Administrative Tools, and then click Server Manager.

  2. Click Manage Roles. Under Active Directory Certificate Services, click Add role services. If a different AD CS role service has already been installed on this computer, select the Active Directory Certificate Services check box in the Role Summary pane, and then click Add role services.

  3. On the Select Role Services page, select the Online Certificate Status Protocol check box.

    A message appears explaining that IIS and Windows Activation Service (WAS) must also be installed to support OCSP.

  4. Click Add required role services, and then click Next three times.

  5. On the Confirm Installation Options page, click Install.

  6. When the installation is complete, review the status page to verify that the installation was successful.

Additional considerations

  • Before an Online Responder can be used, you must also create a revocation configuration. See Creating a Revocation Configuration.

Additional references

  • Setting Up Online Responder Services in a Network


Creating a Revocation Configuration

An Online Responder can make revocation information available from multiple certification authorities (CAs) and multiple CA certificates. However, each CA and CA certificate served by an Online Responder requires a separate revocation configuration.

A revocation configuration includes all of the settings that are needed to respond to status requests regarding certificates that have been issued by using a specific CA key. These configuration settings include the following:

  • CA certificate. This certificate can be located in Active Directory Domain Services (AD DS), in the local certificate store, or imported from a file.

  • Signing certificate for the Online Responder. This signing certificate can be selected automatically for you, selected manually (which involves a separate import step after you add the revocation configuration), or you can use the selected CA certificate to also serve as the signing certificate.

  • Revocation provider. The revocation provider will provide the revocation data used by this configuration. For a Windows Server 2008 provider, this information is entered as one or more URLs where valid base CRLs and delta CRLs can be obtained.

Before you begin to add a new revocation configuration, make sure you have the information in the preceding list available.

You must have Manage Online Responder permissions on all of the Online Responders in the array to complete this procedure. For more information about administering a public key infrastructure, see Implement Role-Based Administration.

To add a revocation configuration to an Online Responder

  1. Open the Online Responder snap-in.

  2. In the console tree, click Revocation Configuration.

    A list of existing revocation configurations appears in the details pane.

  3. In the Actions pane, click Add Revocation Configuration to start the Add Revocation Configuration Wizard.

  4. Provide the information requested in the wizard.

    • For information about the Select CA Certificate Location page, see Revocation Configuration CA Certificates.

    • For information about the Select Signing Certificate page, see Revocation Configuration Signing Certificates.

  5. When all the information has been entered, click Finish, and then click Yes to complete the setup process.

You can modify the properties of an existing revocation configuration, view its CA certificate, or delete the revocation configuration, by selecting the revocation configuration and clicking Edit Properties in the Actions pane.

The following properties of a revocation configuration can be modified:

  • Local CRL. For more information, see Manage Revocation Data by Using Local CRLs.

  • Revocation provider. For more information, see Revocation Provider Properties.

  • Signing. For more information, see Revocation Provider Signing.

Additional references

  • Setting Up Online Responder Services in a Network


Revocation Configuration CA Certificates

Use the following criteria to select the revocation configuration certificate:

  • If the CA certificate has been published to Active Directory Domain Services (AD DS) and the computer you are configuring has access to this information in AD DS, click Select a certificate for an existing enterprise CA.

  • If AD DS cannot be accessed and you know the name of the CA certificate and that it exists in the local root certificate store, click Select a certificate from the local certificate store.

    Note

    This option is not available if the Online Responder is not on the same computer as the Online Responder snap-in.

  • If AD DS cannot be accessed and the CA certificate (with a .cer extension) is available on removable media, click Import certificate from a file.

Additional references

  • Creating a Revocation Configuration


Revocation Configuration Signing Certificates

The following options are available for selecting a revocation configuration signing certificate:

  • The default option, Automatically select a signing certificate, will generally meet most organization's needs. This option allows the revocation configuration setup process to identify a suitable signing certificate in the local certificate store. However, if you also enable an option to automatically enroll for a signing certificate, the Online Responder service will enroll for and use that signing certificate.

  • When selecting Manually select a signing certificate, the Online Responder will not assign any signing certificate and the user will have to manually select a signing certificates for each of the Online Responder Array members.

  • Use the CA certificate for the revocation configuration can be selected if the Online Responder is installed on the same computer as the CA.

Note

The default installation of Online Responder services does not allow for automatic enrollment of the Online Certificate Status Protocol (OCSP) Response Signing certificate from a hardware security module (HSM) that requires interaction from the user. If you need to use an HSM to distribute OCSP Response Signing certificates, you must modify the Online Responder service to run as Local System with interaction enabled. In addition, on the Signing tab of the Online Responder Properties page, the Do not display UI for cryptographic operations check box must be cleared.

Additional references

  • Creating a Revocation Configuration


Revocation Provider Properties

Online Responders in Windows Server® 2008 use the Microsoft certificate revocation list (CRL)-based revocation provider to provide certificate status. This revocation provider is the component that an Online Responder contacts to check the status of a certificate. The revocation provider is responsible for obtaining updated CRLs and determining the status of a certificate based on a CRL.

You can select one or more CRLs and delta CRLs for use with your Online Responders, and you can define how often the revocation provider receives updated CRLs.

To configure revocation provider properties for an Online Responder, enter the URLs for the CRL distribution points where the CRLs and, if wanted, delta CRLs can be accessed.

When multiple CRLs and delta CRLs are entered, you can control the order of precedence for each by moving the CRL distribution point listings up or down. Where there are discrepancies in revocation data between two CRLs, the CRL listed first takes precedence.

You can also modify the refresh rate for CRL data. The default interval is the CRL validity period.

Additional references

  • Creating a Revocation Configuration


Revocation Provider Signing

The Signing tab on the Online Responder Properties page shows the hash algorithm that is used to help verify signing operations for Online Responder responses to clients.

The following signing options can be configured:

  • Do not prompt for credentials for cryptographic operations. If the signing key is strongly protected by an additional password, selecting this option means the Online Responder will not prompt the user for the password and will fail silently.

    Note

    Do not select this option if a hardware security module (HSM) is used to protect private keys.

  • Automatically use renewed signing certificates. Instructs the Online Responder to automatically use renewed signing certificates without asking the Online Responder administrator to manually assign them.

  • Enable NONCE extensions support. Instructs the Online Responder to inspect and process an Online Certificate Status Protocol (OCSP) request that includes a nonce extension. If a nonce extension is included in the OCSP request and this option is selected, the Online Responder will ignore any cached OCSP response and will create a new response that includes the nonce provided in the request. If this option is disabled and a request that includes a nonce extension is received, the Online Responder will reject the request with an "unauthorized" error.

    Note

    The Microsoft OCSP client does not support the nonce extension.

  • Use any valid OCSP signing certificate. By default the Online Responder will only use signing certificates that are issued by the same CA that issued the certificate being validated. This option allows modifying the default behavior and instructs the Online Responder to use any valid existing certificate that includes the OCSP Signing EKU extension.

    Note

    At this time Windows Vista does not support this option, and certificate status requests from current Windows Vista clients will fail if this option is selected.

The following Online Responder identifier options can be used to select whether to include the key hash or the subject of the signing certificate in the response:

  • Key hash of the signing certificate. Some cryptographic service providers (CSPs) require the key hash of the signing certificate in order to access private keys.

  • Subject of the signing certificate. Some cryptographic service providers (CSPs) require the subject of the signing certificate in order to access private keys.

Additional references

  • Creating a Revocation Configuration


Verify an Online Responder Installation

After you have completed setting up an Online Responder, you can verify that it is functioning properly by confirming that you can autoenroll certificates, revoke certificates, and make accurate revocation data available from the Online Responder.

You must be a CA administrator to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To verify that the Online Responder functions properly

  1. On the certification authority (CA), configure several certificate templates to autoenroll certificates for a computer running Windows Vista or Windows XP Professional.

  2. When information about the new certificates has been published to Active Directory domain controllers, open a command prompt on the client computer and enter the following command to start certificate autoenrollment:

    certutil -pulse

    Note

    It can take up to eight hours for information about new certificates to be replicated to Active Directory domain controllers.

  3. On the client computer, use the Certificates snap-in to verify that the certificates have been issued to the user and to the computer, as appropriate. If they have not been issued, repeat step 2. You can also stop and restart the client computer to initiate certificate autoenrollment.

  4. On the CA, use the Certification Authority snap-in to view and revoke one or more of the issued certificates by clicking Certification Authority (Computer)/CA name/Issued Certificates and selecting the certificate you want to revoke. On the Action menu, point to All Tasks, and then click Revoke Certificate. Select the reason for revoking the certificate, and click Yes.

  5. In the Certification Authority snap-in, publish a new certificate revocation list (CRL) by clicking Certification Authority (Computer)/CA name/Revoked Certificates in the console tree. Then, on the Action menu, point to All Tasks, and then click Publish.

  6. To remove all CRL distribution point extensions from the issuing CA, open the Certification Authority snap-in, and then select the CA. On the Action menu, click Properties.

  7. On the Extensions tab, confirm that Select extension is set to CRL Distribution Point (CDP).

  8. Click any CRL distribution points that are listed, click Remove, and click OK.

  9. Stop and restart Active Directory Certificate Services (AD CS).

  10. Repeat steps 1 and 2 above, and then verify that client computers can still obtain revocation data. To do this, use the Certificates snap-in to export the certificate to a .cer file. At a command prompt, type:

    certutil -url exportedcert.cer

  11. In the Verify and Retrieve dialog box that appears, click the From CDP and From OCSP buttons and confirm that the revocation data is retrieved from the Online Responder and not from a CRL distribution point.

Additional references

  • Setting Up Online Responder Services in a Network


Managing a Certification Authority

Management of a certification authority (CA) involves two broad categories of tasks: infrequent tasks, which include key configuration tasks and implementing a management framework, and recurring tasks, which include the common daily operations of a CA, such as issuing and revoking certificates and publishing revocation data.

  • Install and Use the Certification Authority Snap-In

  • Infrequent Management Tasks

  • Recurring Management Tasks


Install and Use the Certification Authority Snap-In

The Certification Authority snap-in can be used to administer a certification authority (CA) on this computer or on another computer. The snap-in is installed automatically on a computer where a CA has been installed. Otherwise, you must first install the Active Directory Certificate Services (AD CS) Remote Server Administration Tools.

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To administer a CA on this computer

  1. If this is the first time you are using the Certification Authority snap-in on this computer, click Start, click Run, type mmc, and then press ENTER.

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

  3. Add the Certification Authority snap-in to the list on the right.

  4. Select the computer hosting the CA that you want to administer, and then click OK.

You can also use an existing instance of the Certification Authority snap-in to switch from administering one CA to administering another CA.

You must be a CA administrator on the remote CA to complete this procedure. For more information, see Implement Role-Based Administration.

To administer a CA on another computer

  1. Open the Certification Authority snap-in.

  2. On the Action menu, click Retarget Certification Authority.

  3. Click Another computer, and type the name of the computer.

You can also customize the Certification Authority snap-in by using display filters. With filters, you can restrict the items displayed in the details pane of the Certification Authority snap-in to items that meet a set of criteria you establish. For example, you can create a filter that will display in the Issued Certificates folder only those certificates that were effective after a specific date.

You do not need to be a CA administrator, but you must have permissions to perform administration tasks on the CA to complete this procedure. For more information, see Implement Role-Based Administration.

To set display filters for the Certification Authority snap-in

  1. Open the Certification Authority snap-in.

  2. Click any of the displayed folders except Certificate templates.

  3. On the View menu, click Filter.

  4. For each of the selection criteria:

    • Click Add.

    • In Field, click the field on which to filter.

    • In Operation, click the operation to qualify the filter value for this field.

    • In Value, type the qualification value.

The Remote Server Administration Tools can be installed on a computer running Windows Server® 2008 by using the Add Features Wizard.

You must be an administrator on the server to complete this procedure. For more information, see Implement Role-Based Administration.

To install the AD CS Remote Server Administration Tools

  1. Open Server Manager.

  2. Under Features Summary, click Add Features to start the Add Features Wizard.

  3. On the Select Features page, click the plus sign that appears to the left of the Remote Server Administration Tools check box, and then click the plus sign to the left of the Role Administration Tools check box.

  4. Select the Active Directory Certificate Services check box, click Next, and then click Install.

  5. When installation is complete, click Close.

To perform remote administration tasks from a computer running Windows Vista, you can obtain the Remote Server Administration Tools Pack from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=89361).

Additional references

  • Managing a Certification Authority


Infrequent Management Tasks

The following management tasks need to be performed when a certification authority (CA) is initially deployed or when significant changes are needed.

  • Securing Active Directory Certificate Services

  • Configuring Certificate Revocation

  • Deploying Certificate Templates

  • Managing Key Archival and Recovery

  • Managing Policy and Exit Modules

  • Protecting a CA from Data Loss


Securing Active Directory Certificate Services

It is important to define and implement an Active Directory Certificate Services (AD CS) management model when you develop a certification authority (CA) infrastructure. This management model should complement your existing security management delegation plan and, if necessary, can help you meet Common Criteria requirements for role separation.

To ensure that a single individual cannot compromise public key infrastructure (PKI) services, it is best to distribute management roles across different individuals in your organization.

To understand the roles and activities associated with managing AD CS, see Implement Role-Based Administration.

For additional important security and management role-related tasks, see:

  • Restrict Certificate Managers

  • Establish Restricted Enrollment Agents

  • Configure CA Event Auditing

  • Send E-mail When a Certification Event Occurs


Implement Role-Based Administration

You can use role-based administration to organize certification authority (CA) administrators into separate, predefined CA roles, each with its own set of tasks. Roles are assigned by using each user's security settings. You assign a role to a user by assigning that user the specific security settings that are associated with the role. A user that has one type of permission, such as Manage CA permission, can perform specific CA tasks that a user with another type of permission, such as Issue and Manage Certificates permission, cannot perform.

Note

Role-based administration is supported by both Windows Server® 2008 and Windows Server 2003 enterprise and stand-alone CAs.

The following table describes the roles, users, and groups that can be used to implement role-based administration. To assign a role to a user or group, you must assign the role's corresponding security permissions, group memberships, or user rights to the user or group. These security permissions, group memberships, and user rights are used to distinguish which users have which roles.

Roles and groups | Security permission | Description
CA administrator | Manage CA | Configure and maintain the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate. These permissions are assigned by using the Certification Authority snap-in.
Certificate manager | Issue and Manage Certificates | Approve certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA officer. These permissions are assigned by using the Certification Authority snap-in.
Backup operator | Back up file and directories Restore file and directories | Perform system backup and recovery. Backup is an operating system feature.
Auditor | Manage auditing and security log | Configure, view, and maintain audit logs. Auditing is an operating system feature. Auditor is an operating system role.
Enrollees | Read Enroll | Enrollees are clients who are authorized to request certificates from a CA. This is not a CA role.

All CA roles are assigned and modified by members of local Administrators, Enterprise Admins, or Domain Admins. On enterprise CAs, local administrators, enterprise administrators, and domain administrators are CA administrators by default. Only local administrators are CA administrators by default on a stand-alone CA. If a stand-alone CA is installed on a server that is joined to an Active Directory domain, domain administrators are also CA administrators.

The CA administrator and certificate manager roles can be assigned to Active Directory users or local users in the Security Accounts Manager (SAM) of the local computer, which is the local security account database. As a best practice, you should assign roles to group accounts instead of individual user accounts.

Only CA administrator, certificate manager, auditor, and backup operator are CA roles. The other users described in the table are relevant to role-based administration and should be understood before assigning CA roles.

Only CA administrators and certificate managers are assigned by using the Certification Authority snap-in. To change the permissions of a user or group, you must change the user's security permissions, group membership, or user rights.

To set CA administrator and certificate manager security permissions for a CA

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. Click the Security tab, and specify the security permissions.

Roles and activities

Each CA role has a specific list of CA administration tasks associated with it. The following table lists all the CA administration tasks along with the roles in which they are performed.

Activity | CA administrator | Certificate manager | Auditor | Backup operator | Local administrator | Notes
Install CAs |  |  |  |  | X |
Configure policy and exit modules | X |  |  |  |  |
Stop and start the Active Directory Certificate Services (AD CS) service | X |  |  |  |  |
Configure extensions | X |  |  |  |  |
Configure roles | X |  |  |  |  |
Renew CA keys |  |  |  |  | X |
Define key recovery agents | X |  |  |  |  |
Configure certificate manager restrictions | X |  |  |  |  |
Delete a single row in the CA database | X |  |  |  |  |
Delete multiple rows in the CA database (bulk deletion) | X | X |  |  |  | The user must be both a CA administrator and a certificate manager. This activity cannot be performed when role separation is enforced.
Enable role separation |  |  |  |  | X |
Issue and approve certificates |  | X |  |  |  |
Deny certificates |  | X |  |  |  |
Revoke certificates |  | X |  |  |  |
Reactivate certificates that are placed on hold |  | X |  |  |  |
Renew certificates |  | X |  |  |  |
Enable, publish, or configure certificate revocation list (CRL) schedules | X |  |  |  |  |
Recover archived keys |  | X |  |  |  | Only a certificate manager can retrieve the encrypted key data structure from the CA database. The private key of a valid key recovery agent is required to decrypt the key data structure and generate a PKCS #12 file.
Configure audit parameters |  |  | X |  |  | By default, the local administrator holds the system audit user right.
Audit logs |  |  | X |  |  | By default, the local administrator holds the system audit user right.
Back up the system |  |  |  | X |  | By default, the local administrator holds the system backup user right.
Restore the system |  |  |  | X |  | By default, the local administrator holds the system backup user right.
Read the CA database | X | X | X | X |  | By default, the local administrator holds the system audit and system backup user rights.
Read CA configuration information | X | X | X | X |  | By default, the local administrator holds the system audit and system backup user rights.

Additional considerations

  • Enrollees are allowed to read CA properties and CRLs, and can request certificates. On an enterprise CA, a user must have Read and Enroll permissions on the certificate template to request a certificate. CA administrators, certificate managers, auditors, and backup operators have implicit Read permissions.

  • An auditor holds the system audit user right.

  • A backup operator holds the system backup user right. In addition, the backup operator has the ability to start and stop the Active Directory Certificate Services (AD CS) service.

Assigning roles

The CA administrator for a CA assigns users to the separate roles of role-based administration by applying the security settings required by a role to the user's account. The CA administrator can assign a user to more than one role, but the CA is more secure when each user is assigned to only one role. When this delegation strategy is used, fewer CA tasks can be compromised if a user's account becomes compromised.

Administrator concerns

The default installation setting for a stand-alone CA is to have members of the local Administrators group as CA administrators. The default installation setting for an enterprise CA is to have members of the local Administrators, Enterprise Admins, and Domain Admins groups as CA administrators. To limit the power of any of these accounts, they should be removed from the CA administrator and certificate manager roles when all CA roles are assigned.

As a best practice, group accounts that have been assigned CA administrator or certificate manager roles should not be members of the local Administrators security group. Also, CA roles should only be assigned to group accounts and not individual user accounts.

Note

Membership in the local Administrators group on the CA is required to renew a CA certificate. Members of this group can assume administrative authority over all other CA roles.


Restrict Certificate Managers

A certificate manager can approve certificate enrollment and revocation requests, issue certificates, and manage certificates. This role can be configured by assigning a user or group the Issue and Manage Certificates permission.

When you assign this permission to a user or group, you can further refine their ability to manage certificates by group and by certificate template. For example, you might want to implement a restriction that they can only approve requests or revoke smart card logon certificates for users in a certain office or organizational unit that is the basis for a security group.

This restriction is based on a subset of the certificate templates enabled for the certification authority (CA) and the user groups that have Enroll permissions for that certificate template from that CA.

You must be a CA administrator or a member of Enterprise Admins, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To configure certificate manager restrictions for a CA

  1. Open the Certification Authority snap-in, and right-click the name of the CA.

  2. Click Properties, and then click the Security tab.

  3. Verify that the user or group that you have selected has Issue and Manage Certificates permission. If they do not yet have this permission, select the Allow check box, and then click Apply.

  4. Click the Certificate Managers tab.

  5. Click Restrict certificate managers, and verify that the name of the group or user is displayed.

  6. Under Certificate Templates, click Add, select the template for the certificates that you want this user or group to manage, and then click OK. Repeat this step until you have selected all certificate templates that you want to allow this certificate manager to manage.

  7. Under Permissions, click Add, type the name of the client for whom you want the certificate manager to manage the defined certificate types, and then click OK.

  8. If you want to block the certificate manager from managing certificates for a specific user, computer, or group, under Permissions, select this user, computer, or group, and click Deny.

  9. When you are finished configuring certificate manager restrictions, click OK or Apply.

Additional references

  • Securing Active Directory Certificate Services


Establish Restricted Enrollment Agents

An enrollment agent is a user who can enroll for a certificate on behalf on another client. Unlike a certificate manager, an enrollment agent can only process the enrollment request and cannot approve pending requests or revoke issued certificates.

Windows Server 2008 includes three certificate templates that enable different types of enrollment agents:

  • Enrollment Agent. Used to request certificates on behalf of another subject.

  • Enrollment Agent (Computer). Used to request certificates on behalf of another computer subject.

  • Exchange Enrollment Agent (Offline Request). Used to request certificates on behalf of another subject and supply the subject name in the request. This template is used by the Network Device Enrollment Service for its enrollment agent certificate.

When you create an enrollment agent, you can further refine the agent's ability to enroll for certificates on behalf of others by group and by certificate template. For example, you might want to implement a restriction that the enrollment agent can only enroll for smart card logon certificates for users in a certain office or organizational unit that is the basis for a security group.

This restriction is based on a subset of the certificate templates enabled for the certification authority (CA) and the user groups that have Enroll permissions for that certificate template from that CA.

Important

You can only apply enrollment agent restrictions on Windows Server 2008–based CAs. Enrollment agent policy must also be configured properly.

You must be a CA administrator or a member of Enterprise Admins, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To configure enrollment agent restrictions for a CA

  1. Open the Certification Authority snap-in, right-click the name of the CA, and then click Properties.

  2. Click the Enrollment Agents tab, click Restrict enrollment agents, and click OK on the message that appears.

  3. Under Enrollment agents, click Add, type the names of the users or groups that you want to configure, and then click OK. Click Everyone, and then click Remove.

  4. Under Certificate Templates, click Add, select the template for the certificates that you want this user or group to be able to enroll from, and then click OK. Repeat this step until you have selected all certificate templates that you want to enable for this enrollment agent. When you have finished adding the names of certificate templates, click <All>, and then click Remove.

  5. Under Permissions, click Add, type the names of the users or groups for whom you want the enrollment agent to manage the defined certificate types, and then click OK. Click Everyone, and then click Remove.

  6. If you want to block the enrollment agent from managing certificates for a user, computer, or group, under Permissions, select this user, computer, or group, and then click Deny.

  7. When you are finished configuring enrollment agent restrictions, click OK or Apply.
Note

The user or group that you applied enrollment agent restrictions to must have a valid enrollment agent certificate for the CA before they can act as an enrollment agent, whether restricted enrollment agent permissions have or have not been configured.

Additional references

  • Securing Active Directory Certificate Services


Configure CA Event Auditing

You can audit a variety of events relating to the management and activities of a certification authority (CA):

  • Back up and restore the CA database

  • Change the CA configuration

  • Change CA security settings

  • Issue and manage certificate requests

  • Revoke certificates and publish certificate revocation lists (CRLs)

  • Store and retrieve archived keys

  • Start and stop Active Directory Certificate Services (AD CS)

You must be a CA administrator or a CA auditor to complete this procedure. The CA auditor must perform this procedure if the CA has been configured to enforce role-based administration. For more information, see Implement Role-Based Administration.

To configure CA event auditing

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Auditing tab, click the events you want to audit, and then click OK.

  5. On the Action menu, point to All Tasks, and then click Stop Service.

  6. On the Action menu, point to All Tasks, and then click Start Service.

Additional considerations

  • To audit events, the computer must also be configured for auditing of object access. Audit policy options can be viewed and managed in local or domain Group Policy under Computer Configuration\Windows Settings\Security Settings\Local Policies.

Additional references

  • Securing Active Directory Certificate Services

  • Protecting a CA from Data Loss


Send E-mail When a Certification Event Occurs

The following procedure configures a certification authority (CA) to send e-mail when a certification event occurs.

Membership in Domain Admins or local Administrators, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To send e-mail when a certification event occurs

  • At an elevated command prompt, type:

    certutil -setreg exit\smtp\<smtpserverServerName>

    certutil -setreg exit\smtp\<eventfilter +Event>

Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up data on your computer.

The following tables explain the command values and options available for this procedure.

Value | Description
certutil | The name of the command-line tool.
-setreg | Modifies the registry.
exit\smtp\smtpserver | The registry value that contains the name of the Simple Mail Transfer Protocol (SMTP) server.
exit\smtp\eventfilter | The registry value that contains the list of events that the CA should monitor. When any of these events occur, the CA will send e-mail.
+ | Indicates that, if there are current entries stored in this registry value, this entry should be appended to them.
Event | Specifies the event to add to the list of events for the CA to monitor. An event can be any value in the following table.

Event value | Description
ExitEvent_CertIssued | Specifies the action of issuing a certificate.
ExitEvent_CertPending | Specifies the action of a certificate request being received by the CA and set to pending.
ExitEvent_CertDenied | Specifies the action of a certificate request being received by the CA and that request being denied.
ExitEvent_CertRevoked | Specifies the action of a revocation of an existing certificate.
ExitEvent_CRLIssued | Specifies the action of a certificate revocation list (CRL) being issued.
ExitEvent_Startup | Specifies the action of the CA during startup.
ExitEvent_Shutdown | Specifies the action of the CA during shutdown.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

  • When the ExitEvent_CRLIssued, ExitEvent_Startup, and ExitEvent_Shutdown events occur, the CA does not contain an e-mail address because there is no user associated with this event. Therefore, an e-mail address must be configured when using these events. To configure the e-mail address to send e-mail when these events occur, type the following certutil commands at a command prompt:

    certutil -setreg exit\smtp\CRLIssued\To<E-mailString>
certutil -setreg exit\smtp\Startup\To<E-mailString>
certutil -setreg exit\smtp\Shutdown\To<E-mailString>
    E-mailString specifies an e-mail address or a string of e-mail addresses that are separated by semicolons.

  • If the SMTP server is not set to accept anonymous connections, the CA must be configured to provide a user name and password when it connects. To configure the CA to authenticate with the SMTP server, type the following certutil commands at a command prompt:

    certutil -setreg exit\smtp\SMTPAuthenticate 1
certutil -setsmtpinfo<UserName>
    UserName specifies the user name of a valid account on the SMTP server. You will be prompted to provide the password for this user name.

  • To view the complete syntax for this command, at a command prompt, type:

    certutil -setreg -?
  • For more information about the certutil command-line tool, see the certutil command reference (http://go.microsoft.com/fwlink/?LinkId=81249).

Additional references

  • Securing Active Directory Certificate Services


Configuring Certificate Revocation

Every certificate is issued with a specific validity period. Revoking a certificate invalidates it as a trusted security credential before its original validity period expires. There are a number of reasons why a certificate can become untrustworthy as a security credential before its scheduled expiration. Examples include:

  • Compromise, or suspected compromise, of the certificate subject's private key.

  • Compromise, or suspected compromise, of a certification authority's (CA) private key.

  • Discovery that a certificate was obtained fraudulently.

  • Change in the status of the certificate subject as a trusted entity.

  • Change in the name of the certificate subject.

It is not always possible to contact a CA or other trusted server for information about the validity of a certificate. To effectively support certificate status checking, a client must be able to access revocation data to determine whether the certificate is valid or has been revoked. To support a variety of scenarios, Active Directory Certificate Services (AD CS) supports industry-standard methods of certificate revocation. These include publication of certificate revocation lists (CRLs) and delta CRLs, which can be made available to clients from a variety of locations, including Active Directory Domain Services (AD DS), Web servers, and network file shares.

Note

In Windows Server® 2008, an Online Responder can be used to make CRL data more readily accessible in complex network environments. An Online Responder uses the certificate revocation data from CRLs and processes certificate status requests from clients on a certificate-by-certificate basis.

CRLs are complete, digitally signed lists of certificates that have been revoked. These lists are published periodically and can be retrieved and cached by clients (based on the configured lifetime of the CRL) and used to verify a certificate's revocation status.

Because CRLs can become large, depending on the number of certificates issued and revoked by a CA, you can also publish smaller, interim CRLs called delta CRLs. Delta CRLs contain only the certificates revoked since the last regular CRL was published. This allows clients to retrieve the smaller delta CRL and more quickly build a complete list of revoked certificates. The use of delta CRLs also allows revocation data to be published more frequently because the size of the delta CRL usually does not require as much time to transfer as a full CRL.

Additional references

  • Specify CRL Distribution Points

  • Configure CRL and Delta CRL Overlap Periods

  • Schedule Publication of Certificate Revocation Lists

  • Manage Certificate Revocation

  • Setting Up Online Responder Services in a Network


Specify CRL Distribution Points

You can add, remove, or modify certificate revocation list (CRL) distribution points in issued certificates by using the following procedure. However, modifying the URL for a CRL distribution point only affects newly issued certificates. Previously issued certificates will continue to reference the original location.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To specify CRL distribution points in issued certificates

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties, and then click the Extensions tab. Confirm that Select extension is set to CRL Distribution Point (CDP).

  4. Do one or more of the following. (The list of CRL distribution points is in the Specify locations from which users can obtain a certificate revocation list (CRL) box.)

    To add a new CRL distribution point

    Click Add, type the name of the new CRL distribution point, and then click OK.

    To remove a CRL distribution point from the list

    Click the CRL distribution point, click Remove, and then click OK.

    To indicate that you want to use a URL as a CRL distribution point

    Click the CRL distribution point, select the Include in the CDP extension of issued certificates check box, and then click OK.

    To indicate that you do not want to use a URL as a CRL distribution point

    Click the CRL distribution point, clear the Include in the CDP extension of issued certificates check box, and then click OK.

    To indicate that you want to use a URL as a delta CRL distribution point

    Click the CRL distribution point, select the Publish Delta CRLs to this location check box, and then click OK.

    To indicate that you do not want to use a URL as a delta CRL distribution point

    Click the CRL distribution point, clear the Publish Delta CRLs to this location check box, and then click OK.

    To indicate that you want to publish this location in CRLs to point clients to a delta CRL

    Click the CRL distribution point, select the Include in CRLs. Clients use this to find Delta CRL locations check box, and then click OK.

    To indicate that you do not want to publish this location in CRLs to point clients to a delta CRL

    Click the CRL distribution point, clear the Include in CRLs. Clients use this to find Delta CRL locations check box, and then click OK.

  5. Click Yes to stop and restart Active Directory Certificate Services (AD CS).

CRL URLs can be HTTP, FTP, LDAP, or FILE addresses. You can use the following variables when specifying the address of the CRL.

Variable | Value
CAName | The name of the CA
CAObjectClass | The object class identifier for a CA, used when publishing to an LDAP URL
CATruncatedName | The "sanitized" name of the CA, truncated to 32 characters with a hash at the end
CDPObjectClass | The object class identifier for CRL distribution points, used when publishing to an LDAP URL
CertificateName | The renewal extension of the CA
ConfigurationContainer | The location of the Configuration container in Active Directory Domain Services (AD DS)
CRLNameSuffix | Inserts a name suffix at the end of the file name when publishing a CRL to a file or URL location
DeltaCRLAllowed | When a delta CRL is published, this replaces the CRLNameSuffix variable with a separate suffix to distinguish the delta CRL from the CRL
ServerDNSName | The DNS name of the CA server
ServerShortName | The NetBIOS name of the CA server

Additional references

  • Configuring Certificate Revocation

  • Manage Certificate Revocation


Configure CRL and Delta CRL Overlap Periods

You can adjust the relationship between a certificate revocation list (CRL) and delta CRL by configuring an overlap period between the two. This setting is particularly useful when publication of the next base or delta CRL is delayed or the client is unable to obtain a new CRL or delta CRL at the scheduled publication time.

The overlap period for CRLs is the amount of time at the end of a published CRL's lifetime that a client can use to obtain a new CRL before the old CRL is considered unusable. The default setting for this value is 10 percent of the CRL's lifetime12 hours. Because some environments may require longer periods to replicate a CRL, this setting can be configured manually.

Note

The maximum value for either the CRL or delta CRL overlap period is 12 hours.

When both a base CRL and delta CRL have been recently published, a revoked certificate may appear in both CRLs. This is because the newer delta CRL may still point to the older base CRL while the new base CRL is being replicated. Having the certificate appear in both CRLs ensures the revocation information is available.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To configure a CRL and delta CRL overlap period

  1. At a command prompt, type:

    certutil -setreg ca\CRLOverlapUnits Value

    certutil -setreg ca\CRLOverlapPeriod Units

    certutil -setreg ca\CRLDeltaOverlapUnits Value

    certutil -setreg ca\DeltaOverlapPeriod Units

  2. Open the Certification Authority snap-in.

  3. In the console tree, click the name of the CA.

  4. On the Action menu, point to All Tasks, and click Stop Service to stop the service.

  5. On the Action menu, point to All Tasks, and click Start Service to start the service.
Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

The following table lists the values that can be used in the Certutil syntax described in this procedure.

Value | Description
Certutil | Specifies the name of the command-line tool.
-setreg | Modifies the registry.
ca\CRLOverlapUnits | Indicates the registry value that stores the value for the CRL overlap setting.
ca\CRLDelataOverlapUnits | Indicates the registry value that stores the value for the delta CRL overlap setting.
Value | Provides the numerical value to set this option to.
ca\CRLOverlapPeriod | Indicates the registry value that stores the value for the CRL overlap unit type setting.
ca\DeltaOverlapPeriod | Indicates the registry value that stores the value for the delta CRL overlap unit type setting.
Units | Provides the type of units for the overlap period. Valid values are Minutes, Hours, and Days.
Note

If your environment is not configured to issue delta CRLs, the settings for CRLDeltaOverlapUnits and DeltaOverlapPeriod will have no effect.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

Additional references

  • Configuring Certificate Revocation

  • Schedule Publication of Certificate Revocation Lists


Schedule Publication of Certificate Revocation Lists

You must establish a regular publication schedule for certificate revocation data so that a highly accurate certificate revocation list (CRL) is always available to clients. When establishing this schedule, the need for accurate, up-to-date data must be balanced against the impact that frequent downloads of new CRLs can have on clients.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To schedule the publication of the CRL

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Revoked Certificates.

  3. On the Action menu, click Properties.

  4. In CRL publication interval, type the increment and click the unit of time to use for the automatic publishing of the CRL.

At the defined interval, a new CRL will be published by default in the following folder: systemroot\system32\CertSrv\CertEnroll\. If the computer is a domain member and has permission to write to Active Directory Domain Services (AD DS), then the CRL is also published to AD DS.

The publishing period for a CRL is not the same as the validity period for a CRL. By default, the validity period of a CRL exceeds the publishing period of a CRL by 10 percent (up to a 12-hour maximum) to allow for directory replication.

Scheduling publication of delta CRLs

You can extend your CRL publication schedule by also establishing a schedule for the publication of delta CRLs.

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To schedule the publication of the delta CRL

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Revoked Certificates.

  3. On the Action menu, click Properties.

  4. Select the Publish Delta CRLs check box.

  5. In Publication interval, type the increment and click the unit of time to use for the automatic publishing of the delta CRL.

Additional references

  • Configuring Certificate Revocation

  • Configure CRL and Delta CRL Overlap Periods


Deploying Certificate Templates

When you create an enterprise certification authority (CA), certificate templates are stored in Active Directory Domain Services (AD DS) and can be made available to all enterprise CAs in the forest. This centralizes the location for use by all CAs in the enterprise, as well as simplifies replication, security management, and the upgrade of certificate templates when a CA is upgraded to a more recent version of a Windows server operating system. Note that this requires the root domain's Domain Admins group to have been granted Full Control permissions to all certificate templates or for this permission to have been granted to another user or group.

Once you have planned and created the appropriate certificate templates, they will be replicated automatically to all domain controllers in the enterprise. This replication normally takes approximately eight hours to complete. Because of this interval, you should create the certificate template and allow it to replicate before issuing certificates based on the certificate template to clients. This is best accomplished during an idle time in your environment. Configuring templates and using certificates before replication is completed can have unwanted effects.

  • Managing Certificate Templates

  • Add a Certificate Template to a Certification Authority

  • Remove a Certificate Template from a Certification Authority


Managing Key Archival and Recovery

When users lose their private keys, any information that was persistently encrypted with the corresponding public key is no longer accessible. Using key archival and recovery helps protect encrypted data from permanent loss if, for example, an operating system needs to be reinstalled, the user account to which the encryption key was originally issued is no longer available, or the key is otherwise no longer accessible. To help protect private keys, Microsoft enterprise certification authorities (CAs) can archive a user's keys in its database when certificates are issued. These keys are encrypted and stored by the CA.

This private key archive makes it possible for the key to be recovered at a later time. The key recovery process requires an administrator to retrieve the encrypted certificate and private key and then a key recovery agent to decrypt them. When a correctly signed key recovery request is received, the user's certificate and private key are provided to the requestor. The requestor would then use the key as appropriate or securely transfer the key to the user for continued use. As long as the private key is not compromised, the certificate does not have to be replaced or renewed with a different key.

Key archival and recovery are not enabled by default. This is because many organizations would consider the storage of the private key in multiple locations to be a security vulnerability. Requiring organizations to make explicit decisions about which certificates are covered by key archival and recovery and who can recover archived keys helps ensure that key archival and recovery are used to enhance security rather than detract from security.

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To configure your environment for key archival of Encrypting File System (EFS) certificates

  1. Create a key recovery agent account or designate an existing user to serve as the key recovery agent.

  2. Configure the key recovery agent certificate template and enroll the key recovery agent for a key recovery agent certificate. For information, see Identify a Key Recovery Agent.

  3. Register the new key recovery agent with the CA. For information, see Enable Key Archival for a CA.

  4. Configure a certificate template, such as Basic EFS, for key archival, and enroll users for the new certificate. If users already have EFS certificates, ensure that the new certificate will supersede the certificate that does not include key archival. For information, see Configure a Certificate Template for Key Archival.

  5. Enroll users for encryption certificates based on the new certificate template.

    Users are not protected by key archival until they have enrolled for a certificate that has key recovery enabled. If they have identical certificates that were issued before key recovery was enabled, data encrypted with these certificates is not covered by key archival.

For more information about key archival and recovery, see Key Archival and Recovery in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkID=92523).

Additional references

  • Recover a Lost Key


Identify a Key Recovery Agent

A key recovery agent is a person who is authorized to recover a certificate on behalf of an end user. Because the role of key recovery agents can involve sensitive data, only highly trusted individuals should be trusted with this responsibility.

To identify a key recovery agent, you must configure the key recovery agent certificate template to allow the person delegated with this responsibility to enroll for a key recovery agent certificate.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure the key recovery agent certificate template

  1. Open the Certificate Templates snap-in.

  2. In the console tree, right-click the key recovery agent certificate template.

  3. Click Duplicate Template.

  4. In the Duplicate Template dialog box, select the Windows 2003 Server, Enterprise Edition check box unless all of your certification authorities (CAs) and client computers are running Windows Vista or Windows Server® 2008.

  5. In Template, type a new template display name, and then modify any other optional properties as needed.

  6. On the Security tab, click Add, type the name of the users you want to issue the key recovery agent certificates to, and then click OK.

  7. Under Group or user names, select the user names that you just added. Under Permissions, select the Read and Enroll check boxes.

    Note

    To enhance security and control of the key recovery process, it is recommended that autoenrollment not be used for key recovery agent certificates.

  8. Click OK.

Before the new key recovery agent can enroll for a certificate based on the new certificate template that you created, the template must first be added to the CA. For information about how to complete this procedure, see Add a Certificate Template to a Certification Authority.

If the certificate was configured with Read and Enroll permissions, the new key recovery agent must use the Certificates snap-in and the Certificate Import Wizard to obtain a key recovery certificate. If the certificate template was configured with Autoenroll permissions, the certificate will be issued automatically the next time the user logs on to the network.

Note

By default, the CA certificate manager approval check box is selected on the Issuance Requirements tab. Unless you clear this check box, a CA manager must approve the certificate request before a key recovery agent certificate is issued.

The next procedure, Enable Key Archival for a CA, cannot be completed until the key recovery agent has obtained this certificate.

Additional references

  • Managing Key Archival and Recovery


Enable Key Archival for a CA

Before a key recovery agent can use a key recovery certificate, the key recovery agent must have enrolled for the key recovery certificate and be registered as the recovery agent for the certification authority (CA).

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To enable key archival for a CA

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. Click the Recovery Agents tab, and then click Archive the key.

  5. In Number of recovery agents to use, type the number of key recovery agents that will be used to encrypt the archived key.

    The Number of recovery agents to use must be between one and the number of key recovery agent certificates that have been configured.

  6. Click Add. Then, in Key Recovery Agent Selection, click the key recovery certificates that are displayed, and click OK.

  7. The certificates should appear in the Key recovery agent certificates list, but their status is listed as Not loaded.

  8. Click OK or Apply. When prompted to restart the CA, click Yes. When the CA has restarted, the status of the certificates should be listed as Valid.

The list of Key recovery agent certificates can include the status values and causes in the following table.

Status | Cause
Expired | The certificate's expiration date has passed, so the certificate cannot be used.
Invalid | The certificate may be malformed or causes an error when loading.
Not found | The certificate was configured but cannot be located by the CA.
Not loaded | The certificate was configured but has not yet been loaded by the CA.
Revoked | The certificate has been revoked and cannot be used.
Untrusted | The root CA for this certificate is not trusted by the CA.
Valid | The certificate has been loaded by the CA and is operating normally.

If the Number of recovery agents to use value exceeds the number of recovery agent certificates with the status of Valid, enrollment requests that require key archival will fail.

Additional references

  • Managing Key Archival and Recovery


Configure a Certificate Template for Key Archival

The key archival process takes place when a certificate is issued. Therefore, a certificate template must be modified to archive keys before any certificates are issued based on this template.

Key archival is strongly recommended for use with the Basic Encrypting File System (EFS) certificate template in order to protect users from data loss, but it can also be valuable when applied to other types of certificates.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure a certificate template for key archival and recovery

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Duplicate Template.

  3. In the Duplicate Template dialog box, select the Windows 2003 Server, Enterprise Edition check box unless all of your certification authorities (CAs) and client computers are running Windows Vista or Windows Server® 2008.

  4. In Template, type a new template display name, and then modify any other optional properties as needed.

  5. On the Security tab, click Add, type the name of the users or groups you want to issue the certificates to, and then click OK.

  6. Under Group or user names, select the user or group names that you just added. Under Permissions, select the Read and Enroll check boxes, and if you want to automatically issue the certificate, also select the Autoenroll check box.

    Note

    To implement autoenrollment, all three check boxes must be selected.

  7. On the Request Handling tab, select the Archive subject's encryption private key check box.

  8. If users already have EFS certificates that are not configured for key archival and recovery, click the Superseded Templates tab, click Add, and then click the name of the template that you want to replace.

  9. Click OK.

Users are not protected by key archival until they have enrolled for a certificate that has key recovery enabled. If they have identical certificates that were issued before key recovery was enabled, they are not covered by key archival. Clients must be re-enrolled to receive a certificate that is based on the changed template if they already have a valid certificate that is based on the old template. For more information about re-enrolling clients, see Re-Enroll All Certificate Holders.

Additional references

  • Managing Key Archival and Recovery


Recover a Lost Key

Users who lose a private key will be unable to recover data that is encrypted with that key. By recovering a key and restoring it to the client computer, the data can be decrypted and used.

The complete recovery process includes three procedures:

  • Obtain the serial number of the archived certificate.

  • Perform the key recovery.

  • Restore the key to the client's computer.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To obtain the serial number of an archived certificate

  1. Log on to the computer hosting the certification authority (CA).

  2. Open the Certification Authority snap-in.

  3. In the console tree, click the CA name, and then click Issued Certificates.

  4. On the View menu, click Add/Remove Columns.

  5. Under Available Column, click Archived Key, and then click Add.

    Archived Key should now appear in Displayed Columns.

  6. Click OK, and then, in the details pane, scroll to the right and confirm that the last certificate issued to the user has a Yes value in the Archived Key column.

  7. Double-click the certificate.

  8. Click the Details tab. Record the serial number of the certificate. (Do not include spacing between digit pairs.) You will need this information to complete the recovery procedure.

    The serial number will be a hexadecimal string that is 20 characters long. The serial number of the private key is the same as the serial number of the certificate. For the purposes of this procedure, the serial number will be referred to as serialnumber.

  9. Click OK, and close the Certification Authority snap-in.

  10. At a command prompt, type:

    Certutil -getkey <serialnumber> outputblob
    Note

    The Recipient Info section in the output of this command identifies the serial numbers of the key recovery agent certificates whose private keys are needed to decrypt the blob and recover the key.

  11. At a command prompt, type:

    dir outputblob
    Note

    If the file outputblob does not exist, you might have typed the serial number incorrectly for the certificate. The outputblob file is a PKCS #7 file containing the key recovery agent certificates and the user certificate and chain. The inner content is an encrypted PKCS #7 file containing the private key (encrypted to the key recovery agent certificates).

The domain administrator must transfer the output file to the key recovery agent, who performs the actual recovery procedure.

You must be a user with a key recovery agent certificate registered with the CA to complete this procedure. The key recovery agent must be stored in the key recovery agent's Personal certificate store on the computer where the key recovery procedure will take place. For more information, see Implement Role-Based Administration.

To recover the archived certificate

  1. At a command prompt, type:

    Certutil -recoverkey outputblob <filename>.pfx

  2. When prompted, enter a new password. When requested, confirm the new password by typing it a second time.

  3. Copy the saved .pfx file to the computer where recovery is to be completed.

  4. Close all windows and log off the computer.

After the key has been recovered, it must be imported on the computer where the data is stored.

You must be the client to whom the certificate was issued or an administrator on the client computer to complete this procedure. For more information, see Implement Role-Based Administration.

To import the recovered key

  1. Open the Certificates snap-in for the user to whom the certificate was issued.

  2. In the console tree, right-click Personal, click All Tasks, and then click Import.

  3. In the Certificate Import Wizard, click Next.

  4. In File name, type the path and file name of the .pfx file, and then click Next.

  5. In Password, type the password you entered in the previous procedure, and then click Next.

  6. On the Certificate Store page, click Automatically select the certificate store based on the type of certificate, and then click Next.

  7. On the Completing the Certificate Import Wizard page, click Finish.

  8. To verify that the recovered certificate has been imported successfully, in the console tree, double-click Personal, and then click Certificates.

  9. Double-click the certificate. Click the Details tab, and then verify that the serial number matches the original.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

Additional references

  • Managing Key Archival and Recovery


Managing Policy and Exit Modules

Policy modules determine whether a certificate request should be automatically approved, denied, or marked as pending. Exit modules provide an opportunity to perform certain tasks after a certificate is issued.

Active Directory Certificate Services (AD CS) includes one policy module (Certpdef.dll) and one exit module (Certxds.dll). The policy module includes two separate policies: enterprise and stand-alone. To compare a certification authority (CA) that uses an enterprise policy and a CA that uses a stand-alone policy, see Enterprise Certification Authorities and Stand-Alone Certification Authorities.

As a CA administrator, you can replace these default modules with your own custom policy and exit modules or another vendor's policy and exit modules. In addition, if you have upgraded to AD CS in Windows Server® 2008 from Certificate Services in an earlier version of Windows, you can use the same policy module you used prior to upgrading. When you view the properties of the CA, the policy module will be listed either as a legacy policy module or with its original name, depending on how it was created.

Policy module

The policy module provided with a Windows Server 2008–based CA determines the default action of a CA upon receiving a certificate request: approve, deny, or mark as pending.

In the majority of instances, the administrator of a stand-alone CA should set all incoming certificate requests to pending. Otherwise, because the stand-alone CA does not verify the identity of requesters via Active Directory Domain Services (AD DS), there is no way to verify the identity and validity of the certificate requester.

The CA can have only one policy module loaded at a time.

Exit module

The exit module that is provided with a Windows Server 2008–based CA can be configured to perform the following functions:

  • Send e-mail when a certification event occurs.

  • Publish certificates to the file system.

This is not an exhaustive list of the functions of the exit module. Unlike the policy module, multiple exit modules can be used by a CA simultaneously.

Customizing AD CS policy and exit modules

To configure the settings of the default policy and exit modules, see Configuring the Policy and Exit Modules.

To configure options for sending e-mail, see Send E-mail When a Certification Event Occurs.

Programmable interfaces are included in AD CS for developers to create customized policy modules. For more information, see Certificate Services Architecture (http://go.microsoft.com/fwlink/?LinkId=91405).

If you have created a customized policy module and you want to change the policy module, see Select a Different Policy Module.

If you have created a customized exit module and you want to change or add an exit module, see Select a Different Exit Module.


Configuring the Policy and Exit Modules

The administrator of a certification authority (CA) can configure settings in the default policy and exit modules provided with Active Directory Certificate Services (AD CS) by using the Certification Authority snap-in.

You can configure the following policy module settings:

  • The default action of the CA upon receiving a valid certificate request. You can specify whether a stand-alone CA will hold incoming certificate requests as pending or automatically issue the certificate. In most cases, for security reasons, it is recommended that all incoming certificate requests to a stand-alone CA be marked as pending.

    To change the default action of a CA upon receipt of a certificate request, see Set the Default Action Upon Receipt of a Certificate Request.

You can configure the following exit module settings:

  • Allow certificate publication to the file system. You can select whether to allow the publishing of certificates to the file system. Actual publication will only occur if the certificate request specifies a file system location where the certificate is to be published.

    To allow or disallow the publishing of certificates to the file system, see Publish Certificates to the File System.

  • Send e-mail when a certification event occurs. You can configure the CA to send e-mail when a certification event occurs, such as the issuance of a certificate or when a certificate request is set to pending.

    To configure options for sending e-mail, see Send E-mail When a Certification Event Occurs.

Additional references

  • Managing Policy and Exit Modules


Select a Different Policy Module

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To select a different policy module

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Policy Module tab, click Select.

  5. Click the new policy module, and then click OK.

  6. If the policy module has its own configuration interface, you can configure it by clicking Properties.

  7. Stop and restart the CA.

Additional considerations

  • To register a new policy module so that it is available in the list of policy modules, see Certificate Services Architecture (http://go.microsoft.com/fwlink/?LinkId=91405).

  • Only one policy module can be active at a time.

  • To stop and restart the CA, at the command prompt, type:

    net stop certsvc
net start certsvc

Additional references

  • Managing Policy and Exit Modules


Select a Different Exit Module

An exit module provides an opportunity to perform certain tasks after a certificate is issued. You can replace the default exit module with a different exit module. To register a new exit module so that it is available in the list of exit modules, see Exit Modules (http://go.microsoft.com/fwlink/?LinkId=91407).

Note

Multiple exit modules can be enabled at the same time.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To select a different exit module

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Exit Module tab, click Add.

  5. Click the new exit module, and then click OK.

  6. If the exit module has its own configuration interface, you can configure it by clicking Properties.

  7. Stop and restart Active Directory Certificate Services (AD CS).

Additional references

  • Managing Policy and Exit Modules


Protecting a CA from Data Loss

A certification authority (CA) is an important resource for any organization. Therefore, it is important to plan for potential problems, such as hard disk failure or database corruption, by backing up and restoring a CA regularly. A complete backup of a server will also provide backup for the CA installed on the server. However, you can also back up and restore just the CA. Also, for hardware that is several years old, some organizations might decide to move a CA to new hardware both to improve performance and to remove older hardware from service before a critical component failure occurs.

  • Back Up a Certification Authority

  • Restore a CA from a Backup Copy


Back Up a Certification Authority

You can back up a certification authority (CA) without having to back up the entire server on which the CA is installed. However, in most situations you should use the Backup snap-in to back up and restore both the CA and the server at the same time.

You must be a CA administrator or a member of the Backup Operators group, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To back up a CA by using the Certification Authority snap-in

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, point to All Tasks, and click Back Up CA.

  4. Follow the instructions in the CA Backup Wizard.

You can also back up a CA by using the Certutil command-line tool.

You must be a CA administrator or a member of the Backup Operators group, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To back up a CA by using Certutil

  • At a command prompt, type:

    certutil -backup <BackupDirectory>

    BackupDirectory is the path used to store the backup data.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

Additional references

  • Protecting a CA from Data Loss


Restore a CA from a Backup Copy

In general, you should use the Backup snap-in to back up and restore both a certification authority (CA) and the server at the same time. However, there may be times when you want to restore just a CA without restoring the entire server on which the CA is installed.

You must be a CA administrator or a member of the Backup Operators group, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To restore a CA from a backup copy by using the Certification Authority snap-in

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, point to All Tasks, and click Restore CA.

  4. Follow the instructions in the Certification Authority Restore Wizard.

You can also complete this procedure by using the Certutil command-line tool.

You must be a CA administrator or a member of the Backup Operators group, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To restore a CA from a backup copy by using Certutil

  • At a command prompt, type:

    certutil -restore <BackupDirectory>

    BackupDirectory specifies the path where the backup data is located.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

Additional references

  • Protecting a CA from Data Loss


Recurring Management Tasks

The following tasks will likely be performed on a daily, weekly, or other frequent basis.

  • Managing Certificate Enrollment

  • Manage Certificate Revocation


Managing Certificate Enrollment

The administrator of a certification authority (CA) can manage certificate enrollment by:

  • Configuring certificate enrollment and autoenrollment options on certificate templates. For more information, see Issuing Certificates Based on Certificate Templates.

  • Enabling certificate autoenrollment options in Group Policy. For more information, see Configure Certificate Autoenrollment.

  • Configuring the default request handling options for the CA. For more information, see Set the Default Action Upon Receipt of a Certificate Request.

    Note

    You can specify whether a stand-alone CA will hold incoming certificate requests as pending or automatically issue the certificate. In most cases, for security reasons, it is recommended that all incoming certificate requests to a stand-alone CA be marked as pending.

  • Selecting whether to allow certificates to be published to the file system. Actual publication will only occur if the certificate request specifies a file system location where the certificate is to be published. For more information, see Publish Certificates to the File System.

  • Evaluating and acting on pending certificate requests. For more information, see Review Pending Certificate Requests.

Additional references

  • Recurring Management Tasks


Configure Certificate Autoenrollment

Many certificates can be distributed without the client even being aware that enrollment is taking place. These can include most types of certificates issued to computers and services, as well as many certificates issued to users.

To automatically enroll clients for certificates in a domain environment, you must:

  • Configure a certificate template with Autoenroll permissions. For more information, see Issuing Certificates Based on Certificate Templates.

  • Configure an autoenrollment policy for the domain.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure autoenrollment Group Policy for a domain

  1. On a domain controller running Windows Server 2008, click Start, point to Administrative Tools, and then click Group Policy Management.

  2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  3. Right-click the Default Domain Policy GPO, and then click Edit.

  4. In the Group Policy Management Console (GPMC), go to User Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  5. Double-click Certificate Services Client - Auto-Enrollment.

  6. Select the Enroll certificates automatically check box to enable autoenrollment. If you want to block autoenrollment from occurring, select the Do not enroll certificates automatically check box.

  7. If you are enabling certificate autoenrollment, you can select the following check boxes:

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

    • Update certificates that use certificate templates

  8. Click OK to accept your changes.

Additional references

  • Managing Certificate Enrollment


Set the Default Action Upon Receipt of a Certificate Request

You can configure the policy module to automatically approve all certificate requests or to mark requests as pending until an administrator can review and act upon the request. The choice will likely depend on the security implications of the certificates being issued, the intended recipients of the certificates, and other factors.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To set the default action upon receipt of a certificate request

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Policy Module tab, click Properties.

  5. Click the option you want:

    • To have the CA administrator review every certificate request before issuing a certificate, click Set the certificate request status to pending.

    • To have the CA issue certificates based on the configuration of the certificate template, click Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate.

  6. Stop and restart the CA.
Caution

In most cases, for security reasons, it is recommended that all incoming certificate requests to a stand-alone CA be marked as pending. Unlike enterprise CAs, stand-alone CAs do not use Active Directory Domain Services (AD DS), even if it is available, to verify that an individual or computer is authorized to be issued a certificate from the CA automatically. For stand-alone CAs, the CA administrator is responsible for verifying the identity of the certificate requestor.

If you change the setting from Set the certificate request status to pending to Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate, this will apply only to certificate requests submitted to the CA after the default action has been changed. If there are pending requests held by the CA, these requests will remain pending until the CA administrator issues the certificates or denies the requests.

Additional references

  • Managing Certificate Enrollment

  • Review Pending Certificate Requests


Review Pending Certificate Requests

One of the most important and common duties of a certification authority (CA) administrator or certificate manager is to review pending certificate requests to decide whether the requested certificate should be issued or not.

In most cases, for security reasons, it is strongly recommended that all incoming certificate requests to a stand-alone CA be marked as pending. Unlike enterprise CAs, stand-alone CAs do not use Active Directory Domain Services (AD DS), even if it is available, to verify that an individual or computer is authorized to be issued a certificate from the CA automatically. For stand-alone CAs, the CA administrator is responsible for verifying the identity of the certificate requestor.

You must be a CA administrator or certificate manager to complete this procedure. For more information, see Implement Role-Based Administration.

To review pending certificate requests

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Pending Requests.

  3. In the details pane, examine each certificate request by noting the values for requester name, requester e-mail address, and any other fields that you consider critical information for issuing the certificate.

Additional considerations

  • Failed certificate requests can also be issued by using the same procedure in the Failed Requests container. However, not all of the security requirements for the certificate can be verified when issuing a failed request. Caution should be used.

Additional references

  • Managing Certificate Enrollment

  • Set the Default Action Upon Receipt of a Certificate Request


Publish Certificates to the File System

The following procedure can be used to publish issued certificates to the file system.

To request a certificate and have it published to the file system, certificate requestors must include a certfile:true attribute in their request. After the certificate is issued, it is copied to FileName.cer, where FileName is the request ID of the certificate request.

The file is copied to the CertEnroll folder on the certification authority (CA).

Note

You cannot use this method to overwrite files.

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To publish certificates to the file system

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Exit Module tab, click Properties.

  5. On the Publication Settings tab, select the Allow certificates to be published to the file system check box, and then click OK.

  6. Stop and restart the CA.

Additional references

  • Managing Certificate Enrollment


Manage Certificate Revocation

Certificates can be revoked for a variety of reasons, including:

  • The key has been compromised.

  • The certification authority (CA) that issued the certificate has been compromised.

  • The certificate is no longer valid for the intended purpose or has been superseded by another certificate.

  • The client no longer qualifies for the certificate.

You must be a CA administrator or certificate manager to complete this procedure. For more information, see Implement Role-Based Administration.

To revoke a certificate

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Issued Certificates.

  3. In the details pane, click the certificate you want to revoke.

  4. On the Action menu, point to All Tasks, and click Revoke Certificate.

  5. Select the reason for revoking the certificate, adjust the time of the revocation, if necessary, and then click Yes.

The following reason codes are available:

  • Unspecified

  • Key Compromise

  • CA Compromise

  • Change of Affiliation

  • Superseded

  • Cease of Operation

  • Certificate Hold

If you specify "Certificate Hold" as the reason for revoking the certificate, it typically means that you may want to unrevoke the certificate at a future time. Only certificates that have been revoked with the reason of "Certificate Hold" can be unrevoked.

You must be a CA administrator or certificate manager to complete this procedure. For more information, see Implement Role-Based Administration.

To unrevoke a certificate

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Revoked Certificates.

  3. In the details pane, click the certificate you want to unrevoke.

  4. On the Action menu, point to All Tasks, and click Unrevoke Certificate.

  5. Select the reason for unrevoking the certificate, adjust the time of the revocation, if necessary, and then click Yes.

To be meaningful, certificate revocation must be combined with the publication and distribution of certificate revocation data.

Additional references

  • Configuring Certificate Revocation


Use the Network Device Enrollment Service

The Network Device Enrollment Service allows software on routers and other network devices running without domain credentials to obtain certificates based on the Simple Certificate Enrollment Protocol (SCEP).

Note

SCEP was developed to support the secure, scalable issuance of certificates to network devices by using existing certification authorities (CAs). The protocol supports CA and registration authority public key distribution, certificate enrollment, certificate revocation, certificate queries, and certificate revocation queries.

The Network Device Enrollment Service performs the following functions:

  • Generates and provides one-time enrollment passwords to administrators.

  • Submits SCEP enrollment requests to the CA.

  • Retrieves enrolled certificates from the CA and forwards them to the network device.

  • Enrolling for a certificate with the Network Device Enrollment Service involves the software used to manage the network device, the registration authority, the computer hosting the Network Device Enrollment Service, and the CA.

  • You must be registration authority for the CA and an administrator on the network device to complete this procedure. For more information, see Implement Role-Based Administration.

To request and enroll for a certificate by using the Network Device Enrollment Service

  1. Run the software used to manage the network device, and use this software to generate an RSA public/private key pair configured for one of the following:

    • Signing and signature verification

    • Encryption and decryption

    • Signing, signature verification, encryption, and decryption

  2. Use the device software to forward this key pair to the registration authority on the computer hosting the Network Device Enrollment Service.

  3. Open Internet Explorer, and go to http://localhost/certsrv/mscep_admin.

  4. If the password table is not full, the Network Device Enrollment Service will create a random password and embed it in an HTML page that is returned to the caller.

    Note

    Every time you connect to this URL, a different challenge password is displayed. Each challenge password is valid for 60 minutes and can only be used once.

  5. Use the device software, along with the password, to submit a certificate request through the Network Device Enrollment Service, which relays the request to the CA.

  6. If the enrollment request is successful, the requested certificate is returned to the device from the CA through the Network Device Enrollment Service.

By default, the Network Device Enrollment Service can only cache five passwords at a time. If the password cache is full when you submit a password request, you must do one of the following before resubmitting your request:

  • Wait until one of the passwords has expired before submitting a new request.

  • Stop and restart Internet Information Services (IIS) to delete all passwords stored in the cache.

  • Configure the service to cache more than five passwords at a time.

Additional references

  • Managing a Certification Authority

  • Configure the Network Device Enrollment Service


Using Policy to Manage Active Directory Certificate Services

Domain Group Policy can be used to manage the following types of certificate-related activities in an Active Directory Domain Services (AD DS) environment:

  • Credential roaming

  • Autoenrollment of certificates

  • Certificate path validation

  • Certificate distribution

Credential roaming

Credential roaming allows X.509 certificates, certificate requests, and private keys specific to a user in AD DS to be stored independently from the user profile and used on any computer on the network.

Until recently, user certificates and private keys on computers running Windows became part of the user profile after they were issued and placed in the user's certificate store. The only way to use these certificates and private keys on more than one computer was to copy the user profile from one computer to another, which could involve an extremely large amount of data that could be accessed by any person with the appropriate administrative rights.

Digital certificates and private keys involve comparatively small amounts of data that need to be stored in a secure manner. Credential roaming policy provides a means for managing the use of these credentials on multiple computers in a manner that addresses the secure storage and size requirements of digital certificates and private keys.

Credential roaming was first made available for domain controllers running Windows Server 2003 Service Pack 1 (SP1). The credential roaming implementation in Windows Vista and Windows Server 2008 is easier to configure and manage. In addition, credential roaming policy in Windows Server 2008 makes it possible to roam stored user names and passwords as well as certificates and keys.

For more information, see Enable Credential Roaming.

For more information about credential roaming and significant differences between its implementation in Windows Server 2008, Windows Server 2003, Windows Vista, and Windows XP, see Configuring and Troubleshooting Certificate Services Client–Credential Roaming (http://go.microsoft.com/fwlink/?LinkID=85332).

Certificate autoenrollment

Many organizations use Group Policy to automatically enroll users, computers, or services for certificates.

For more information, see Configure Certificate Autoenrollment.

Certificate path validation

As certificate use for secure communication and data protection is increasing, administrators can use certificate trust policy to enhance their control of certificate use and public key infrastructure performance by using certificate path validation options.

Certificate path validation settings in Group Policy allow administrators to manage stores, trusted publishers, network retrieval, and revocation checking.

For more information, see Manage Certificate Path Validation.

Certificate distribution

The certificate distribution capabilities in Group Policy are a powerful method for managing certificate-related trust in an organization. It allows you to ensure that certain certificates are trusted and that certificate chain building occurs with little or no user intervention. You can also block the use of certificates that you cannot directly revoke because they were issued by an external certification authority (CA).

For more information, see Use Policy to Distribute Certificates.

Additional references

  • Managing a Certification Authority


Enable Credential Roaming

To use credential roaming, all of your organization's domain controllers should be running Windows Server 2003 Service Pack 1 (SP1) or Windows Server® 2008. In addition, clients used for credential roaming must also be running Windows Vista, Windows XP Service Pack 2 (SP2), Windows Server 2003 SP1, or Windows Server 2008.

If you have at least one domain controller running Windows Server 2008 in your Active Directory environment, you can use Group Policy to configure credential roaming.

If you do not have a domain controller running Windows Server 2008, you must complete the following procedures before configuring credential roaming through Group Policy:

  1. Prepare Active Directory Domain Services (AD DS). AD DS needs to be prepared to store users' certificates, keys, and Data Protection application programming interface (DPAPI) master keys.

  2. Exclude directories in roaming profiles. If roaming profiles are used, certain directories have to be excluded from roaming to avoid conflicts with credential roaming.

  3. Install the Group Policy ADM template. Credential roaming will be enabled through a Group Policy ADM template that sets the appropriate registry values on a client computer.

For assistance with these preparatory steps in networks with domain controllers that are still running Windows Server 2003, see Configuring and Troubleshooting Certificate Services Client–Credential Roaming (http://go.microsoft.com/fwlink/?LinkID=85332).

Membership in Enterprise Admins or Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure credential roaming for a domain by using Group Policy

  1. On a domain controller running Windows Server 2008, click Start, point to Administrative Tools, and then click Group Policy Management.

  2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  3. Right-click the Default Domain Policy GPO, and then click Edit.

  4. In the Group Policy Management Console (GPMC), go to User Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  5. Double-click Certificate Services Client - Credential Roaming.

  6. Click Enabled to configure credential roaming or Disabled to block its use.

  7. If you clicked Enabled, you can also customize the following options:

    • Maximum tombstone credentials lifetime in days. Allows you to define how long a roaming credential will remain in AD DS for a certificate or key that has been deleted locally.

    • Maximum number of roaming credentials per user. Allows you to define a maximum number of certificates and keys that can be used with credential roaming.

    • Maximum size (in bytes) of a roaming credential. Allows you to restrict roaming for credentials that exceed a defined size.

    • Roam stored user names and passwords. Allows you to include or exclude stored user names and passwords from the credential roaming policy.

  8. Click OK to accept your changes.

The default options for credential roaming in step 7 will be acceptable to many organizations. However, credential roaming can affect the size of the Active Directory database if an organization has a large number of users and credentials. For information that can help you estimate the potential impact of credential roaming on your Active Directory database, see Configuring and Troubleshooting Certificate Services Client–Credential Roaming (http://go.microsoft.com/fwlink/?LinkID=85332).

Additional references

  • Using Policy to Manage Active Directory Certificate Services


Manage Certificate Path Validation

Certificate path validation settings in Windows Server 2008 allow you to manage the settings for certificate path discovery and validation for all users in a domain. You can use Group Policy to easily configure and manage these certificate validation settings. The following are some of the tasks you can perform with these settings:

  • Deploy intermediate certification authority (CA) certificates.

  • Block certificates that are not trusted.

  • Manage certificates used for code signing.

  • Configure retrieval settings for certificates and certificate revocation lists (CRLs).

Certificate path validation settings are available in Group Policy at the following location: Computer Configuration\Windows Settings\Security Settings\Public Key Policies.

When you double-click Certificate Path Validation Settings at this location, additional options are available by selecting the following tabs:

  • Stores

  • Trusted Publishers

  • Network Retrieval

  • Revocation

The following procedure describes how to configure certificate path validation settings. The sections following the procedure will describe the settings in each of these areas.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure path validation Group Policy for a domain

  1. On a domain controller, click Start, point to Administrative Tools, and then click Group Policy Management.

  2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  3. Right-click the Default Domain Policy GPO, and then click Edit.

  4. In the Group Policy Management Console (GPMC), go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  5. Double-click Certificate Path Validation Settings, and then click the Stores tab.

  6. Select the Define these policy settings check box.

  7. Configure the optional settings that you need to apply.

  8. When you are finished making changes, you can select a different tab to modify additional settings, or click OK to apply the new settings.

Stores tab

Some organizations want to prevent users in the domain from configuring their own set of trusted root certificates and to decide which root certificates within the organization can be trusted. The Stores tab can be used to accomplish this.

The following options are available on the Stores tab:

  • Allow user trusted root CAs to be used to validate certificates. Clearing this check box prevents users from deciding which root CA certificates to use to validate certificates. Although this option can help prevent users from trusting and validating certificates from a chain that is not secure, it can also result in application failures or lead users to disregard root certificate trust as a means of validating a certificate that is presented to them.

  • Allow users to trust peer trust certificates. Clearing this check box prevents users from making their own decisions about which peer certificates to trust. Although this option can help prevent users from trusting certificates from a source that is not secure, it can also result in application failures or lead users to disregard certificates as a means of establishing trust. You can also select the certificate purposes, such as signing or encryption, for which peer trust certificates can be used.

  • Root CAs the client computer can trust. In this section, you can identify specific root CAs that can be trusted by users in the domain:

    • Third-Party Root CAs and Enterprise Root CAs. By including both non-Microsoft and enterprise root CAs, you broaden the range of root CA certificates that a user can trust.

    • Only Enterprise Root CAs. By restricting trust to only enterprise root CAs, you effectively restrict trust to certificates issued by an internal enterprise CA that obtains authentication information from and publishes certificates to Active Directory Domain Services (AD DS).

  • For certificate-based authentication of users and computers the client computers must use CAs registered in the Active Directory

    • CAs must also be compliant with User Principal Name constraints. These settings also restrict trust to internal enterprise CAs. In addition, the user principal name constraint would prevent them from trusting authentication-related certificates that do not conform to conditions related to user principal names.

In addition, some organizations may want to identify and distribute specific trusted root certificates to enable business scenarios where additional trust relationships are needed. To identify the trusted root certificates that you would like to distribute to clients in your domain, see Use Policy to Distribute Certificates.

Trusted Publishers tab

Software signing is being used by a growing number of software publishers and application developers to verify that their applications come from a trusted source. However, many users do not understand or ignore the signing certificates associated with applications that they install.

The policy options on the Trusted Publishers tab of the certificate path validation policy allow you to control who can make decisions about trusted publishers:

  • Administrators and users

  • Only administrators

  • Only enterprise administrators

In addition, policy options on this tab allow you to require that trusted publisher certificates be checked that they:

  • Have not been revoked

  • Have valid time stamps

Network Retrieval tab

To be effective, certificate-related data such as certificate revocation lists (CRLs) and certificates in the Microsoft Root Certificate Program must be updated regularly. However, problems can arise if validation checking and retrieval of certificate revocation data and cross-certificates are interrupted because more data is being transferred than originally anticipated.

Network retrieval settings allow administrators to:

  • Automatically update certificates in the Microsoft Root Certificate Program.

  • Configure retrieval timeout values for CRLs and path validation (larger default values may be useful if network conditions are not optimal).

  • Enable issuer certificate retrieval during path validation.

  • Define how frequently cross-certificates are downloaded.

Revocation tab

To support revocation checking, Active Directory Certificate Services (AD CS) supports the use of CRLs and delta CRLs as well as Online Certificate Status Protocol (OCSP) responses distributed by Online Responders.

Path validation Group Policy settings allow administrators to optimize the use of CRLs and Online Responders, particularly in situations where extremely large CRLs or network conditions detract from performance.

The following settings are available:

  • Always prefer Certificate Revocation Lists (CRLs) over Online Certificate Status Protocol (OCSP) responses. In general, clients should use the most recent revocation data that is available, regardless of whether it comes from a CRL or Online Responder. If this option is selected, a revocation check from an Online Responder will only be used if a valid CRL or delta CRL is not available.

  • Allow CRL and OCSP responses to be valid longer than their lifetime. It is generally not recommended to allow CRLs and OCSP responses to be valid beyond their validity period. However, this option might be needed in situations where clients are unable to connect to a CRL distribution point or Online Responder for an extended amount of time. However, the length of time beyond the stated validity period that a CRL or OCSP response can be used is also configurable under this policy setting.

Additional references

  • Using Policy to Manage Active Directory Certificate Services


Use Policy to Distribute Certificates

Certificates are important credentials. Administrators may not want to let users decide which certificates to trust and which not to trust. Often the decision to trust or not trust a particular certificate should be made by an administrator or individual who is knowledgeable about the particular certificate and its trust implications for the organization.

In conjunction with other certificate-related Group Policy settings available in Windows Server 2008 domains, you can use Group Policy to distribute the following types of certificates to clients.

Type of certificate | Description
Trusted Root Certification Authorities | Implicitly trusted certification authorities (CAs). Includes all of the certificates in the Third-Party Root Certification Authorities store plus root certificates from your own organization and Microsoft.
Enterprise Trust | A certificate trust list provides a mechanism for trusting self-signed root certificates from other organizations and limiting the purposes for which these certificates are trusted.
Intermediate Certification Authorities | Certificates issued to subordinate CAs.
Trusted Publishers | Certificates from CAs that are trusted.
Untrusted Certificates | Certificates that you have explicitly decided not to trust because they are no longer valid for their intended purpose or because they are from a source that domain clients should not trust.
Trusted People | Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To add certificates to the Trusted Root Certification Authorities store for a domain

  1. Click Start, point to Administrative Tools, and then click Group Policy Management.

  2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  3. Right-click the Default Domain Policy GPO, and then click Edit.

  4. In the Group Policy Management Console (GPMC), go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  5. Right-click the Trusted Root Certification Authorities store.

  6. Click Import and follow the steps in the Certificate Import Wizard to import the certificates.

Additional references

  • Using Policy to Manage Active Directory Certificate Services


Troubleshoot Active Directory Certificate Services

This section lists a few common issues you may encounter when using the Certification Authority snap-in or working with certification authorities (CAs). For more information about troubleshooting and resolving problems with CAs, see Active Directory Certificate Services Troubleshooting (http://go.microsoft.com/fwlink/?LinkId=89215).

What problem are you having?

  • Clients do not automatically enroll for certificates after autoenrollment is configured

  • A CA could not be installed as an enterprise CA, or CA Web enrollment support could not be installed to recognize a stand-alone CA

  • Error when accessing the CA Web pages

  • A user tries to log on with the smart card and receives this message: "The system cannot log you on to this domain because the system's computer account in its primary domain is missing or the password on the account is incorrect."

  • When trying to enroll for a certificate from a computer or account belonging to a child domain of the domain where the CA is located, the following message appears: "No template could be found. There are no CAs from which you have permission to request a certificate, or an error occurred while accessing the Active Directory."

  • An enrollment agent cannot enroll on behalf of a user for a specific certificate template

  • Restricted certificate manager or enrollment agent operations cannot be completed after a domain is renamed

  • I cannot add a new version 2 or version 3 certificate template to my CA

  • I have a problem that is not listed here

Clients do not automatically enroll for certificates after autoenrollment is configured.
  • Cause: The Group Policy information used for autoenrollment has not yet replicated to the client computers. By default, this information can take up to two hours to replicate to all computers.

  • Solution: Wait for Group Policy to complete replication or use the Gpupdate command-line tool to force replication to occur immediately. For more information, see Gpupdate (http://go.microsoft.com/fwlink/?LinkId=94248).

A CA could not be installed as an enterprise CA, or CA Web enrollment support could not be installed to recognize a stand-alone CA.
  • Cause: The CA was installed by a user who is not a member of the Enterprise Admins or Domain Admins group; therefore, the enterprise CA option was not available and information about the CA cannot be published to Active Directory Domain Services (AD DS).

  • Solution: Log on as a user who is a member of the Enterprise Admins or Domain Admins group to install the CA and CA Web enrollment support.

  • Cause: The domain was not accessible during CA setup.

  • Solution: Ensure that you have network connectivity to a domain controller during CA setup.

Error when accessing the CA Web pages.
  • Cause: The user accessing the Web pages is not a member of the Administrators or Power Users group on the local computer. When a newer version of the Web enrollment software is available on the CA, the client computer must install that software. The user must be a member of the Administrators or Power Users group to install the software.

  • Solution: Log on as a user who is a member of the Administrators or Power Users group to access the Web enrollment pages and download the newer version of the software.

  • Cause: Web pages aren't installed on the CA.

  • Solution: From a command prompt on the CA, run certutil -vroot to install the Web enrollment pages.

  • Cause: Web pages do not have permissions to execute scripts.

  • Solution: From the Internet Information Services (IIS) management console, open the CertSrv folder and confirm that there are execute script permissions on the folder. The CertSrv folder is: Systemroot/System32/Certsrv.

A user tries to log on with the smart card and receives this message: "The system cannot log you on to this domain because the system's computer account in its primary domain is missing or the password on the account is incorrect."
  • Cause: The computer account may be disabled, or the CA that issued the smart card certificate is not trusted by the computer.

  • Solution:

    1. Verify that the computer account is enabled in the domain.

    2. Use the Certificates snap-in to verify that the root CA's certificate is in the Trusted Root Certification Authorities store on the user's computer.

    3. Use the Certificates snap-in to verify that the domain controller has been issued a domain controller certificate that can be verified to a trusted root.

When trying to enroll for a certificate from a computer or account belonging to a child domain of the domain where the CA is located, the following error appears: "No template could be found. There are no CAs from which you have permission to request a certificate, or an error occurred while accessing the Active Directory."
  • Cause: The necessary security permissions are not set on the certificate templates.

  • Solution: Modify the security permissions for the certificate templates to include the child domain accounts from which you want to allow enrollment. To set access control for certificate templates, see Issuing Certificates Based on Certificate Templates.

    Some access control caches must time out after making changes to security permissions, so you might have to wait a short period of time before the new security permissions are replicated through the network.

An enrollment agent cannot enroll on behalf of a user for a specific certificate template.
  • Cause: Enrollment agent restrictions may have been configured to prevent the enrollment agent from enrolling for certificates based on the certificate template for this user group.

  • Solution: This behavior may be by design, if you do intend for the enrollment agent to enroll for certificates based on this certificate template or for this group of users. If it is not by design, follow the steps in Establish Restricted Enrollment Agents to configure the correct enrollment agent permissions for this group and certificate template.

  • Cause: The enrollment agent certificate is configured with a Cryptography Next Generation (CNG) key, and the certificate is being requested from a Windows Server 2003–based CA.

  • Solution: Use an enrollment agent certificate that is compatible with Windows Server 2003–based CAs, or request the certificate from a CA on a computer running Windows Server 2008.

Restricted certificate manager or enrollment agent operations cannot be completed after a domain is renamed.
  • Cause: For restricted officer operations, a CA relies on the Security Accounts Manager (SAM) name of the requestor that is stored in the Active Directory database to verify that the officer has rights to manage the request. However, the SAM name contains the domain name and the restricted officer operation will fail if the domain name is changed (instead of just the DNS portion of the name).

  • Solution: Disable or reconfigure the restricted officer permissions before attempting the enrollment operation again.

I cannot add a new version 2 or version 3 certificate template to my CA.
  • Cause: The CA is installed on a server running Windows Server 2008 Standard. Version 2 and version 3 certificate templates and certificate autoenrollment can only be used with CAs installed on Windows Server 2008 Enterprise or Windows Server 2008 Datacenter.

  • Solution: Upgrade to Windows Server 2008 Enterprise or Windows Server 2008 Datacenter.

I have a problem that is not listed here.
  • Cause: Check the event log of the server. It often contains more detailed error messages that can help you diagnose and solve the problem you are having.

  • Solution: For more information about events that are logged by Active Directory Certificate Services, see Active Directory Certificate Services Troubleshooting (http://go.microsoft.com/fwlink/?LinkId=89215).


Active Directory Certificate Services Resources

  • For extensive evaluation, design, deployment, troubleshooting, and technical reference information, including white papers and Knowledge Base (KB) articles, see Active Directory Certificate Services (http://go.microsoft.com/fwlink/?LinkID=85613).

  • For information about developing applications that use Active Directory Certificate Services (AD CS), see Win32 and COM Security Development (http://go.microsoft.com/fwlink/?LinkId=92771).

  • For public information about public key infrastructures (PKIs), see the National Institute of Standards and Technology (NIST) PKI Web site (http://go.microsoft.com/fwlink/?LinkId=92772).

  • For information about the PKI X.509 (pkix) working group, see the Internet Engineering Task Force (IETF) Web site (http://go.microsoft.com/fwlink/?LinkID=29885).


Issuance Requirements

A certification authority (CA) processes each certificate request by using a defined set of rules. The CA may issue some certificates with no proof of identification and require proof of identification before other types of certificates are issued. This provides different levels of assurance for different certificates. These levels of assurance are represented in certificates as issuance policies.

An issuance policy (also known as an enrollment or certificate policy) is a group of administrative rules that is implemented when issuing certificates. They are represented in a certificate by an object identifier (also known as an OID) that is defined at the CA. This object identifier is included in the issued certificate. When a subject presents its certificate, it can be examined by the target to verify the issuance policy, and determine if that level of issuance policy is sufficient to perform the requested action.

Windows Server 2003 and Windows Server® 2008 include four predefined issuance policies:

  • All Issuance (2.5.29.32.0). The all issuance policy indicates that the issuance policy contains all other issuance policies. Typically, this object identifier is only assigned to CA certificates.

  • Low Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.400). The low assurance object identifier is used to represent certificates that are issued with no additional security requirements.

    Note

    The x.y.z portion of the object identifier is a randomly generated numeric sequence that is unique for each Active Directory forest.

  • Medium Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.401). The medium assurance object identifier is used to represent certificates that have additional security requirements for issuance. For example, a smart card certificate that is issued in a face-to-face meeting with a smart card issuer might be considered a medium assurance certificate and contain the medium assurance object identifier.

  • High Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.402). The high assurance object identifier is used to represent certificates that are issued with the highest security. For example, the issuance of a key recovery agent certificate might require additional background checks and a digital signature from a designated approver because a person holding this certificate can recover private key material from an enterprise CA.

In addition, you can create your own object identifiers to represent custom issuance policies.

When subjects submit certificate requests to a CA, the request can either be automatically approved or placed into a "pending" state. A pending state is normally used for certificates that require a higher level of assurance and consequently require more administration and further verification of the request. There are a number of settings that can configure the authentication and signature requirements for issuance certificates that are based on a template.

Setting | Description
CA certificate manager approval | All certificates are placed into the pending container for a certificate manager to issue or deny.
This number of authorized signatures | This setting requires the certificate request to be digitally signed by one or more subjects before it can be issued. This enables several other configuration parameters.
Policy type required in signature | The signatures that are required for issuing a certificate must contain either a specific application policy, issuance policy, or both. This is how the CA determines whether the signature is appropriate for authorizing the issuance of the subject's certificate. This option is enabled when This number of authorized signatures is set.
Application policy | Specifies the application policy that is checked for when signing a certificate request. This option is enabled when Policy type required in signature is set to either Application policy or Both application and issuance policy.
Issuance policy | Specifies which issuance policies will be checked when signing a certificate request. This option is enabled when Policy type required in signature is set to either Issuance policy or Both application and issuance policy.

The ability to modify or create new application policies is only available with version 2 and version 3 certificate templates. For more information, see Default Certificate Templates.

Clients must be re-enrolled to receive a certificate based on a modified template if they already have a valid certificate based on the previous template. For more information about re-enrolling clients, see Re-Enroll All Certificate Holders.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To modify an issuance policy

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. Click the Issuance Requirements tab.

  4. Provide the requested information.

Additional references

  • Certificate Template Extensions

  • Make Issuance or Application Policy Critical


Guidelines for Using Alternate Signature Formats

Selecting the option Use alternate signature formats implements the PKCS #1 v2.1 signature format for certificates.

For certificates based on RSA algorithms, PKCS #1 v2.1 specifies separate object identifiers for the hash algorithm and for the asymmetric algorithm. (In PKCS #1 v.1.5, only one object identifier is used to identify both the hash and asymmetric algorithms.) In addition, if you select the alternate signature format for certificates based on RSA algorithms, an enhanced cryptographic formula is used to create the signature.

For certificates not based on RSA algorithms, selecting Use alternate signature formats specifies separate object identifiers for the hash algorithm and for the asymmetric algorithm.

Before using the alternate signature format in your certificates, you need to verify that your clients' CAs and clients can accept these signature formats. Earlier versions of Windows cannot validate certificates that use the alternate signature format. In addition, certificates issued by using the alternate signature format might not be compatible with non-Microsoft certification authorities or non-Microsoft clients.

For more information about PKCS #1 v.2.1, see PKCS #1: RSA Cryptography Standard (http://go.microsoft.com/fwlink/?LinkId=66621) on the RSA Laboratories Web site.

For more information about the RSA implementation of the signature format, see Raising the Standard for RSA Signatures: RSA-PSS (http://go.microsoft.com/fwlink/?LinkId=66622) on the RSA Laboratories Web site.


Registration Authorities

A registration authority (RA) is a computer that is configured for an administrator to request and retrieve issued certificates on behalf of other users.

An RA does not have to be installed on the same computer as the certification authority for which it processes certificate requests.


General Tab

You can view information about the fields, extensions, and properties that define an issued certificate by double-clicking any certificate displayed in the certificate store.

Selecting the General tab provides a general overview of the certificate, including the following information:

  • Supported uses of the certificate. Summary information, such as the applications, signing, encryption, or authentication, for which the certificate can be used. This section also explains if a certificate has expired or is not valid.

  • Entity to which the certificate was issued. The name of recipient of the certificate. Recipients can include end users, computers, or entities such as CAs.

  • The issuer of the certificate. The name of the CA that issued the certificate.

  • Validity period of the certificate. This includes the date the certificate becomes valid to the date that the certificate expires.

  • Issuer statement. Clicking the Issuer Statement button opens a separate window with a text containing additional information about the certificate or a URL where additional information can be obtained.


Cryptography

A new Cryptography tab is available for version 3 certificate templates in Windows Server® 2008. This tab replaces and extends the cryptographic service provider (CSP) selection dialog box accessible by clicking the CSPs button on the Request Handling tab of a version 2 certificate template. The Cryptography tab contains the following options:

  • Algorithm name. This option allows you to select an advanced algorithm for encryption, signing, or both (depending on the template's purpose). By default, the following algorithms are available: DSA, ECDH_P256, ECDH_P384, ECDH_P521, ECDSA_P256, ECDSA_P384, ECDSA_P521, and RSA. Only the algorithms that are available for a specific certificate template purpose will be listed.

  • Minimum key size. This option allows you to specify a minimum required size for the keys used with the chosen algorithm. By default, the minimum key length supported on the computer for the chosen algorithm will be used.

  • Providers. Version 2 templates offered a list of CryptoAPI CSPs, while version 3 templates offer a dynamically populated list of Cryptography Next Generation (CNG) providers. This list is populated with all providers available on the computer that meet the criteria specified by a combination of the following configuration options: Algorithm name and Minimum key size on the Cryptography tab, and Purpose and Allow private key to be exported on the Request Handling tab.

  • Hash algorithm. This option allows you to choose an advanced hash algorithm. By default, the following algorithms are available: AES-GMAC, MD2, MD4, MD5, SHA1, SHA256, SHA384, and SHA512.

  • Use alternate signature format. When the RSA algorithm is selected, this check box allows you to specify that certificate requests created for this template include a discrete signature in PKCS #1 V2.1 format.

    Note

    This setting applies to the certificate request only, not the certificate that is issued by the CA from this template.

Additional references

  • Configuring a Certificate Template


NAP Enforcement Methods

NAP enforcement methods

Network Policy Server (NPS) enforces Network Access Protection (NAP) health policies for the following network technologies:

  • Internet Protocol security (IPsec) policies for Windows Firewall on client computers. For NAP IPsec enforcement, the IPsec enforcement client must be installed on client computers. For more information, see NAP Enforcement for IPsec Communications.

  • 802.1X port-based wired and wireless network access control. For more information, see NAP Enforcement for 802.1X.

  • Dynamic Host Configuration Protocol (DHCP) Internet Protocol version 4 (IPv4) address lease and renewal. For more information, see NAP Enforcement for DHCP.

  • Terminal Server Gateway (TS Gateway) connections with Terminal Services. For more information, see NAP Enforcement for Terminal Services Gateway.

  • Virtual private networks (VPN) with Routing and Remote Access. For more information, see NAP Enforcement for VPN.

Using multiple enforcement methods

Each of these NAP enforcement methods has strengths and weaknesses. By combining enforcement methods, you can eliminate most of the weaknesses of your NAP deployment. Deploying multiple NAP enforcement methods, however, can make your NAP implementation more complex to manage.

See Also

  • Network Access Protection in NPS
  • NAP Components
  • Windows Security Health Validator


Create a New Certificate Template

You can create a new certificate template by duplicating an existing template and using the existing template's properties as the default for the new template. Different applications and types of certification authorities (CAs) support different certificate templates. For example, some certificate templates can only be issued and managed by enterprise CAs running Windows Server 2003, and some may require that the CA be running Windows Server® 2008. Review the list of default certificate templates, and examine their properties to identify the existing certificate template that most closely meets your needs. This will minimize the amount of configuration work that you need to do.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To create a new certificate template

  1. Open the Certificate Templates snap-in.

  2. Right-click the template to copy from, and then click Duplicate Template.

  3. Choose the minimum version of CA that you want to support.

  4. Type a new name for this certificate template.

  5. Make any necessary changes, and click OK.

Additional references

  • Managing Certificate Templates

  • Default Certificate Templates


Issuing Certificates Based on Certificate Templates

Active Directory Certificate Services (AD CS) supports a variety of enrollment and renewal methods, including autoenrollment without any client interaction and interactive enrollment methods such as the Certificate Request Wizard and the AD CS Web pages.

Note

If you deploy non-Microsoft certification authorities (CAs) or custom certificate enrollment and renewal applications, you must perform any configuration required for those CAs and applications.

How a certificate is obtained by a client is controlled in large part by the security properties of the certificate template.

When certificate templates are published on a server, each template contains an access control list (ACL) that defines the specific operations a subject can perform with a certificate.

Setting Description

Full Control

The selected group or user can perform any action on this template.

Read

The selected group or user can read this template.

Write

The selected group or user can modify this template.

Enroll

The selected group or user can submit a certificate issuance or renewal request based on this template.

Autoenroll

The selected group or user can submit a certificate request based on this template by way of autoenrollment.

Note

This option will not work unless the Enroll option is also selected.

The most common use of certificates is for subject enrollment with autoenrollment permitted. In this case, the subject must be granted Read, Enroll, and Autoenroll permissions.

If you do not want to autoenroll users, but do not want to make manual or Web-based enrollment available, granting the Read and Enroll permissions is appropriate.

When subjects already hold a certificate, they need only Read and Enroll permissions to renew that certificate, whether they use autoenrollment or not.

Write and Full Control permissions should be restricted to CA managers to ensure the templates are not improperly configured.

  • Managing Certificate Templates

  • Set Up Automatic Certificate Enrollment

  • Allow Subjects to Request a Certificate Based on a Template

  • Re-Enroll All Certificate Holders

  • Modify an Issuance Policy

  • Configure Certificate Publishing in Active Directory Domain Services


Add the Online Responder Snap-in to a Console

You can use the Online Responder snap-in to monitor and manage the Online Responder service and revocation configurations on this computer or another computer.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To add the Online Responder snap-in to a console

  1. Click Start, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, double-click Online Responder, select the computer on which the Online Responder is installed, and then click Finish.

  4. If you have no more snap-ins to add to the console, click OK.

  5. To save this console, on the File menu, click Save.

Additional references

  • Administer an Online Responder from Another Computer


Enable Security Center in Group Policy

You can use this procedure to install Group Policy Management and enable Security Center on NAP-capable clients using Group Policy. Security Center is required for some Network Access Protection (NAP) deployments that use Windows Security Health Validator (WSHV).

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

Install Group Policy Management

  1. Click Start, and then click Server Manager. Server Manager opens.

  2. In the left pane, click Features, and in the details pane, in Features Summary, click Add Features. The Add Features Wizard opens.

  3. In Select Features, in Features, select Group Policy Management, and then click Next.

  4. In Confirm Installation Selections, click Install.

  5. In Installation Results, review the information, and then click Close.
To enable Security Center in Group Policy

  1. Click Start, and in Start Search, type gpmc.msc, and then press ENTER. The Group Policy Management console opens.

  2. In the left pane, double-click your forest.

  3. Double-click, Domains, and then double-click the domain that contains the Group Policy that you want to manage.

  4. Right-click Default Domain Policy, and then click Edit.

  5. In the console tree, double-click Computer Configuration, double-click Administrative Templates, double-click Windows Components, and then double-click Security Center.

  6. Double-click Turn on Security Center (Domain PCs only), click Enabled, and then click OK.


Managing Online Responders

Procedures are available to complete the following basic Online Responder management tasks:

  • Add the Online Responder Snap-in to a Console

  • Audit Online Responder Operations

  • Administer an Online Responder from Another Computer

  • Modify the Online Responder Web Proxy

  • Add OCSP Locations to Issued Certificates

  • Renew OCSP Response Signing Certificates with an Existing Key


Display Certificate Stores

Using the Certificates snap-in, you can display the certificate store for a user, a computer, or a service according to the purpose for which the certificates were issued or by using their logical storage categories. When you display certificates according to their storage categories, you can also choose to display the physical stores, showing the certificate storage hierarchy. (This is recommended for advanced users only.)

If you have the user rights to do so, you can import or export certificates from any of the folders in the certificate store. Additionally, if the private key associated with a certificate is marked as available for export, you can export both into a PKCS #12 file.

Windows can also publish certificates to Active Directory. Publishing a certificate in Active Directory enables all users or computers with adequate permissions to retrieve the certificate as needed.

Certificate stores

Certificates can be displayed by purpose or by logical stores, as shown in the following table. Displaying certificates by logical stores is the Certificates default.

Note

The list of certificate purpose stores does not include all the possible purpose stores.

Display by Folder name Contents

Logical Store

Personal

Certificates associated with private keys to which you have access. These are the certificates that have been issued to you or to the computer or service for which you are managing certificates.

Note to administrators: Computers in a Windows Server 2003 Active Directory domain can have certificates automatically placed in this store through the use of Group Policy-based autoenrollment. For more information, see "Automatic certificate request settings."

Trusted Root Certification Authorities

Implicitly trusted certification authorities. Includes all of the certificates in the Third-Party Root Certification Authorities store plus root certificates from your organization and Microsoft.

If you are an administrator and want to add third-party certification authority certificates to this store for all computers in a Windows Server 2003 Active Directory domain, you can use Group Policy to distribute trusted root certificates to your organization. For more information, see "Trusted root certification authority policy."

Enterprise Trust

A container for certificate trust lists. A certificate trust list provides a mechanism for trusting self-signed root certificates from other organizations and limiting the purposes for which these certificates are trusted. For more information about Enterprise trust see "Enterprise trust policy."

Intermediate Certification Authorities

Certificates issued to subordinate certification authorities. If you are an administrator, you can use Group Policy to distribute certificates to the Intermediate Certification Authorities store.

Trusted People

Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook. If you are a domain administrator, you can use Group Policy to distribute certificates to the Trusted People store.

Other People

Certificates issued to people or end entities that are implicitly trusted. These certificates must be part of a trusted certification hierarchy. Most often these are cached certificates for services like Encrypting File System, where certificates are used for creating authorization for decrypting an encrypted file.

Trusted Publishers

Certificates from certification authorities that are trusted by Software Restriction policies. If you are a domain administrator, you can use Group Policy to distribute certificates to the Trusted Publishers store.

Disallowed Certificates

These are certificates that you have explicitly decided not to trust using either Software Restriction policy or by clicking "Do not trust this certificate" when the decision is presented to you in mail or a Web browser. If you are a domain administrator, you can use Group Policy to distribute certificates to the Disallowed Certificates store.

Third-Party Root Certification Authorities

Trusted root certificates from certification authorities other than Microsoft and your organization. You cannot use Group Policy to distribute certificates to the Third-Party Root Certification Authorities store.

Certificate Enrollment Requests

Pending or rejected certificate requests.

Active Directory User Object

Certificates associated with your user object and published in Active Directory.

Purpose

Server Authentication

Certificates that server programs use to authenticate themselves to clients.

Client Authentication

Certificates that client programs use to authenticate themselves to servers.

Code Signing

Certificates associated with key pairs used to sign active content.

Secure E-mail

Certificates associated with key pairs used to sign e-mail messages.

Encrypting File System

Certificates associated with key pairs that encrypt and decrypt the symmetric key used for encrypting and decrypting data by Encrypting File System (EFS).

File Recovery

Certificates associated with key pairs that encrypt and decrypt the symmetric key used for recovering encrypted data by Encrypting File System (EFS).

When you look at the contents of a certificate store in Logical Store mode, you will occasionally see what appear to be two copies of the same certificate in the store. This occurs because the same certificate is stored in separate physical stores under a logical store. When the contents of the physical certificate stores are combined into one logical store view, both instances of the same certificate are displayed.

You can verify this by setting View Options to show the Physical certificate stores and then noting that the certificate is stored in separate physical stores under the same logical store. You can verify that it is the same certificate by comparing the serial numbers.

Additional references

  • Display Certificate Stores in Logical Store Mode

  • Display Certificate Stores in Purpose Store Mode

  • Display Archived Certificates

  • Move Certificates


Enable the Network Access Protection Service on Clients

You can use this procedure to enable and configure the Network Access Protection (NAP) service on NAP-capable client computers. You must enable this service when you deploy NAP.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To enable the Network Access Protection service on clients

  1. Click Start, Control Panel, System and Maintenance, Administrative Tools, and then double-click Services.

  2. In the services list, scroll down to and double-click Network Access Protection Agent.

  3. In the Network Access Protection Agent Properties dialog box, change Startup Type to Automatic, and then click OK.


Troubleshoot Online Responders

This section lists a few common issues you may encounter when using the Online Responder snap-in or working with Online Responder Arrays. For more information about troubleshooting and resolving problems with Online Responders, see Active Directory Certificate Services Troubleshooting (http://go.microsoft.com/fwlink/?LinkId=89215).

What problem are you having?

  • The Online Responder service did not start

  • The Online Responder's signing certificate could not be located

  • An attempt to create a revocation configuration failed

  • The signing certificate for the Online Responder configuration will expire soon

  • The signing certificate for the revocation configuration has expired

  • An Online Responder revocation configuration cannot be loaded

  • The Online Responder service could not retrieve a CRL for the specified revocation configuration

The Online Responder service did not start.
  • Cause: The Online Responder service can fail to start because of corrupted registry information or insufficient system resources.

  • Solution: Try to restart the Online Responder service from the Services snap-in (services.msc). If the Online Responder service fails to start, check the event log for other errors that may be related to this failure. If not enough system resources are available to start the Online Responder service, try to restart the computer or free system resources. If the registry information is corrupted, you must use Server Manager to uninstall and reinstall the Online Responder service.

The Online Responder's signing certificate could not be located.
  • Cause: The OCSP Response Signing certificate is not present in either the Personal certificate store for the computer account or, if the signing certificate should have been issued by using autoenrollment, autoenrollment was not completed.

  • Solution: If an OCSP Response Signing certificate is not present in the Personal certificate store for the local computer, and the revocation is configured for manual OCSP Response Signing certificate enrollment or auto-discovery, you should enroll for a certificate manually. For configurations in which the Online Responder service enrolls for its certificate, manual enrollment will not work and you need to identify the reason that autoenrollment did not work. Possible reasons include:

    • The computer on which the Online Responder service is running cannot connect to a certification authority (CA) that has been configured to issue certificates based on the OCSP Response Signing template.

    • The Online Responder does not have Read, Enroll, and, if autoenrollment is being used, Autoenroll permissions on the OCSP Response Signing template.

An attempt to create a revocation configuration failed.
  • Cause: An attempt to create a revocation configuration failed with the message "Bad signing certificate on Array Controller."

  • Solution: Verify that OCSP Response Signing certificate template has been correctly configured. Otherwise, configure the certificate template to allow manual enrollment for these signing certificates.

The signing certificate for the Online Responder configuration will expire soon.
  • Cause: When autoenrollment is not being used, a reminder to renew an expiring certificate is generated automatically when a certificate has a configured percentage of its lifetime left (by default, this is 10 percent of its total validity period). You can check the time remaining on the current signing certificate by using the Certificates snap-in to examine the OCSP Response Signing certificate in the Personal certificate store of the computer or the Online Responder service.

  • Solution: If the OCSP Response Signing certificate template has been configured for automatic enrollment and renewal, further action may not be needed. For manual configurations, you can renew the signing certificate by using the Certificates snap-in and the Certificate Renewal Wizard.

The signing certificate for the revocation configuration has expired.
  • Cause: Automatic renewal of the signing certificate failed, or manual certificate renewal was not completed before the expiration date.

  • Solution: For configurations in which the Online Responder service enrolls for its certificate, manual enrollment will not work and you need to identify the reason that autoenrollment did not work. Possible reasons include:

    • The computer on which the Online Responder service is running cannot connect to a CA that has been configured to issue certificates based on the OCSP Response Signing template.

    • The Online Responder does not have Read, Enroll, and Autoenroll permissions on the OCSP Response Signing template.

    A CA administrator should use the Certification Authority and Certificate Templates snap-ins to verify the availability and configuration of the OCSP Response Signing template before autoenrollment can be tried again.

    If the revocation configuration is set up for manual enrollment of the OCSP Response Signing certificate, locate the signing certificate within the Online Responder computer's local computer Personal certificate store.

    For manual configurations, you can renew the signing certificate by using the Certificates snap-in and the Certificate Renewal Wizard.

    It is also possible that the OCSP Response Signing certificate could not be renewed because the CA key that was used to sign the original OCSP Response Signing certificate has been renewed and is no longer available. To overcome this problem, you must allow the OCSP Response Signing certificate to be renewed with an existing key. For more information, see Renew OCSP Response Signing Certificates with an Existing Key.

An Online Responder revocation configuration cannot be loaded.
  • Cause: The revocation configuration has become corrupted.

  • Solution: Use the Online Responder snap-in to delete and re-create the revocation configuration. If this problem occurred on an Array member, you can delete the corrupted configuration from the Array member and then synchronize the Array to re-create the revocation configuration. If you are encountering this problem on an Array controller, temporarily set another computer as the Array controller, synchronize the Array, and then reset the original computer to be the Array controller.

The Online Responder service could not retrieve a CRL for the specified revocation configuration.
  • Cause: Certificate revocation list (CRL) publication failed, CRL distribution points are invalid, or the Online Responder service could not access the published CRL.

  • Solution: To identify and address CRL retrieval problems for an Online Responder:

    1. Use the Online Responder snap-in to verify that the URLs configured for base and delta CRL distribution points are valid.

    2. Use the Certification Authority snap-in to verify the URLs to which the CA will publish base and delta CRLs.

    3. On the computer to which the base CRL is published, examine the Freshest CRL extension for the base CRL. Verify that this identifies a location where the delta CRL can be found.

    4. Republish the current CRL, if necessary, by typing the following command at a command prompt: certutil -crl

    5. Then, verify that Online Responder service can access the CRL. From the Online Responder snap-in, right-click Array Configuration, and click Refresh Revocation Data.


Certificate Template Versions

Microsoft certification authorities (CAs) support three types of certificate templates: version 1, version 2, and version 3.

CAs that are set up on servers running Windows Server 2003, Standard Edition, or Windows 2000 Server support only version 1 templates. CAs that are set up on servers running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, support both version 1 and version 2 templates. CAs that are set up on servers running Windows Server® 2008 support all three versions. In addition, version 3 certificate templates can only be used by clients on computers running Windows Server 2008 or Windows Vista®.

Version 1 certificate templates

Version 1 templates are provided for backward compatibility and support many general needs for subject certification. They are created by default when a CA is installed and cannot be modified or removed. When you duplicate a version 1 template, the duplicate becomes a version 2 or version 3 template that can be modified.

Version 2 certificate templates

Version 2 certificate templates allow customization of most settings in the template. Several preconfigured version 2 templates are supplied in the default configuration, and more can be added as necessary. This allows complete configuration flexibility for administrators.

Version 3 certificate templates

Version 3 certificates allow administrators to add advanced Suite B cryptographic settings to their certificates. Suite B includes advanced options for encryption, digital signatures, key exchange, and hashing. Certificates based on version 3 certificate templates can only be issued from CAs installed on servers running Windows Server 2008 and used on clients running Windows Server 2008 or Windows Vista.

Duplicating certificate templates

New certificate templates are created by duplicating existing templates. Many settings are copied from the original template. You can also select whether to create the duplicate as a version 2 or version 3 certificate template.

To create a new certificate, you should create the duplicate based on an existing template closest in function to the intended template.

If you create a new template by duplicating a template of a different type, the new template may include settings that you did not intend to use.

When duplicating a template, examine the subject type of the original template and ensure that you duplicate a template that has a similar function to that of the intended template.

Although most settings for certificate templates can be edited after the template is duplicated, the subject type cannot be changed.

Additional references

  • Certificate Template Concepts

  • Create a New Certificate Template


Modify the Properties of a Certificate

You can modify the properties of a certificate for a number of reasons:

  • Adding or modifying a friendly name to help differentiate it from other similar certificates.

  • Changing the purpose of the certificate by adding or disabling purposes.

  • Specifying cross-certificate download locations.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic..

To modify the properties of a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Do one of the following:

    • If you are in Logical Certificate Stores view mode, in the console tree under Logical Store, click Certificates.

    • If you are in Certificate Purpose view mode, in the console tree, click Purpose.

  3. In the details pane, click the certificate you want to modify.

  4. On the Action menu, click Properties.

  5. Make the desired changes:

    1. To change the friendly name of the certificate, in Friendly name, type the new name.

    2. To change the description of the certificate, in Description, type the new description.

    3. To enable all purposes for the certificate, based on the certificate type, in Certificate purposes, click Enable all purposes for this certificate.

    4. To disable all purposes for the certificate, in Certificate purposes, click Disable all purposes for this certificate.

    5. To designate specific purposes for the certificate, in Certificate purposes, click Enable only the following purposes and select the appropriate check boxes.

    6. To modify cross-certificate properties, click the Cross-Certificates tab, click Specify additional Cross-Certificate download locations, enter the URL where the cross-certificates can be obtained, and click Add URL.

    7. Click OK to accept all changes.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC .


Save a Certificate Request in a File

You can prepare a certificate request for use later, or to retain a copy of the request even if is processed at the same time as it is saved.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To save a certificate request in a PKCS #10 or CMC file

  1. Open Internet Explorer.

  2. In Internet Explorer, open http://servername/certsrv, where servername is the name of the Web server running Windows Server 2003 where the certification authority you want to access is located.

  3. Click Request a certificate, and under Advanced certificate request click Create and submit a request to this CA.

  4. Enter any identifying information requested and any other options you require.

  5. Under Additional Options, select the file format you want to use.

  6. In the Full path name field, type a path and file name.

  7. Click Submit. The file is saved to your computer's desktop.

  8. If you are finished using the Certificate Services Web pages, close Internet Explorer.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • The component that enables Web enrollment in this version of Windows is different from the component that enables Web enrollment in Windows Server 2003 and Windows XP. Windows Server 2003 CA Web enrollment pages must be updated to support both Windows Vista® and earlier clients. For more information, see the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=63592).

  • You also need to make http://servername a trusted site for Internet Explorer in order to browse for a file on the computer's disk drive. To make http://servername a trusted site, in Internet Explorer, click Tools, point to Internet Options, point to Security, point to Trusted Sites, and then click Sites. Type http://servername, and click OK.

Additional reference

  • Request Certificates Using the Certificate Request Wizard


Renew a Certificate with the Same Key

Renewing a certificate with the same key allows you maximum compatibility with past uses of the accompanying key pair, but does nothing to enhance the security of the certificate and key pair.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To renew a certificate with the same key

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree, click Certificates - Current User, select Personal, and click Certificates.

  3. In the details pane, click the certificate you are renewing.

  4. On the Action menu, point to All Tasks, select Advanced Operations, and then click Renew this certificate with the same key to start the Certificate Renewal Wizard.

  5. If more than one certificate is listed in the Request Certificates window, select the certificate that you want to renew. Do one of the following:

    • Use the default values to renew the certificate.

    • Click Details and then Properties to provide your own certificate renewal settings. You need to know the certification authority issuing the certificate.

  6. Click Enroll. After the Certificate Renewal Wizard has successfully finished, click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC

  • Once renewed, the old certificate will be archived.

  • You can use this procedure to request certificates from an enterprise certification authority only. To request certificates from a stand-alone certification authority, you need to request certificates by means of Web pages. A Windows certification authority has its Web pages located at http://servername/certsrv, where servername is the name of the server that hosts the certification authority.


Hash Algorithms

A hash algorithm is an algorithm that produces a hash value of some piece of data, such as a message or session key. With a good hash algorithm, changes in the input data can alter every bit in the resulting hash value. For this reason, hashes are useful in detecting any modification in a data object, such as a message. Furthermore, a good hash algorithm makes it computationally infeasible to construct two independent inputs that have the same hash. Typical hash algorithms include MD5, SHA-1, and SHA-256.


Subject Names

The holder of the private key associated with a certificate is known as the subject. This can be a user, a program, or virtually any object or service.

Because the subject can vary greatly depending on who or what it is, some flexibility is needed when providing the subject name in the certificate request. Windows can either build the subject name automatically or request it from the subject manually. If it automatically provides the subject name, Windows obtains the information from Active Directory.

You can configure this process to include or exclude information useful in the environment. If configured to manually provide the subject name, the subject supplies that information in the certificate request, for example by using the Web-based enrollment pages.

Subject names in certificates can be presented using the following formats:

  • Common name. The certification authority creates the subject name from the common name (CN) obtained from Active Directory. This should be unique within a domain, but might not be unique within an enterprise.

  • Fully distinguished name (DN). The certification authority creates the subject name from the fully distinguished name obtained from Active Directory. This guarantees that the name is unique within an enterprise.

  • Include e-mail name in subject name. If the e-mail name field is populated in the Active Directory user object, this e-mail name will be included with either the common name or fully distinguished name as part of the subject name.

  • None. A name value is not required for this certificate.

The following alternate subject name options can also be specified:

  • E-mail name. If the e-mail name field is populated in the Active Directory user object, that e-mail name will be used.

  • DNS name. The fully qualified domain name (FQDN) of the subject that requested the certificate. This is most frequently used in computer certificates

  • User principal name (UPN). The user principal name is part of the Active Directory user object and will be used.

  • Service principal name (SPN). The service principal name is part of the Active Directory computer object and will be used.


Add a Setting to a Network Policy

Add a setting to a network policy

You can use this procedure to add a setting to an existing network policy.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To add a setting to a network policy

  1. Open the NPS console, and then double-click Policies.

  2. Click Network Policies, and then double-click the policy that you want to configure.

  3. In Settings, click the setting that you want to configure, and then provide the value for the setting.

See Also

  • Network Policy Settings Properties


NPS Server Certificate: Configure the Template and Autoenrollment

Configure the server certificate template and autoenrollment

You can use this procedure to configure the certificate template that Active Directory® Certificate Services (AD CS) uses as the basis for server certificates enrolled to servers running Network Policy Server (NPS).

Membership in both the Enterprise Admins and the root domain's Domain Admins group is the minimum required to complete this procedure.

To configure the certificate template and auto-enrollment

  1. On the computer where Active Directory Certificate Services is installed, click Start, click Run, type mmc, and then click OK.

  2. On the File menu, click Add/Remove Snap-in, and then click Add. The Add or Remove Snap-ins dialog box opens.

  3. In Available snap-ins, double-click Certification Authority. Select the CA that you want to manage, and then click Finish. The Certification Authority dialog box closes, returning to the Add or Remove Snap-ins dialog box.

  4. In Available snap-ins, double-click Certificate Templates, and then click OK.

  5. In the console tree, click Certificate Templates. All of the certificate templates are displayed in the details pane.

  6. In the details pane, click the RAS and IAS Server template.

  7. On the Action menu, click Duplicate Template. In the Duplicate Template dialog box, select the template version appropriate for your deployment, and then click OK. The new template properties dialog box opens.

  8. On the General tab, in Display Name, type a new name for the certificate template or keep the default name. Select the Publish Certificate in Active Directory check box.

  9. Click the Security tab. In Group or user names, click RAS and IAS servers.

  10. In Permissions for RAS and IAS servers, under Allow, select the Enroll and Autoenroll permission check boxes, and then click OK.

  11. Double-click Certification Authority, double-click the CA name, and then click Certificate Templates. On the Action menu, point to New, and then click Certificate Template to Issue.

  12. Click the name of the certificate template you just configured, and then click OK. For example, if you did not change the default certificate template name, click Copy of RAS and IAS Server, and then click OK.

  13. On the computer where Active Directory Domain Services is installed, click Start, click Run, type mmc, and then click OK.

  14. On the File menu, click Add/Remove Snap-in, and then click Add. The Add or Remove Snap-ins dialog box opens.

  15. In Available snap-ins, double-click Group Policy Management Console. The Select Group Policy Object wizard opens. Click Browse, and then select the appropriate Group Policy object (the default object is Default Domain Policy). Click OK, click Finish, and then click OK again.

  16. Double-click Default Domain Policy. Open Computer Configuration, then Windows Settings, then Security Settings, and then Public Key Policies.

  17. Double-click Certificate Services Client - Auto-Enrollment. The Properties dialog box opens.

  18. In Configuration Model, select Enabled.

  19. Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box.

  20. Select the Update certificates that use certificate templates check box, and then click OK.

Additional considerations

After you complete this procedure, servers running NPS automatically enroll a server certificate when Group Policy is refreshed. To refresh Group Policy, reboot the server or, at the command prompt, run gpupdate.

See Also

  • NPS Server Certificate: CA Installation


Obtain a Certificate

To enroll for a certificate, a certificate request must be made by the user, computer, or service that has access to the private key associated with the public key that will be part of the certificate. Depending upon the public key policies established by your system administrator, users, computers and services can autoenroll for certificates without user intervention.

Users can also obtain certificates by:

  • Initiating autoenrollment from the Certificates snap-in.

  • Requesting certificates by using the Certificate Request Wizard.

  • Requesting a certificate over the Web.

In addition, administrators can request smart card user certificates and smart card certificates for logging on to the system on behalf of other users by using their enrollment agent certificate.

The following topics contain procedures to use for obtaining certificates:

  • Autoenroll for a Certificate from the Certificates Snap-in

  • Request Certificates Using the Certificate Request Wizard

  • Request a Certificate Over the Web

  • Enroll for Certificates on Behalf of Other Clients

Additional reference

  • Manage Certificates


Renew a Certificate

Every certificate has a validity period. After the end of the validity period, the certificate is no longer considered an acceptable or usable credential. The Certificates snap-in enables you to renew a certificate issued from a Windows enterprise certification authority (CA) before or after the end of its validity period by using the Certificate Renewal Wizard.

Renewing certificates

You can either renew the certificate with the same key set you used before, or you can renew a certificate with a new key set. This decision can be based on a number of factors, including the life of the certificate, the length of the existing or future key, the value of the data protected by the key pair, and the likelihood or unlikelihood that a private key has been obtained by a hostile user.

Before you renew a certificate, you need to know:

  • The issuing certification authority.

  • (Optional) If you want a new public key and private key pair for the certificate, the cryptographic service provider (CSP) that should be used to generate the key pair.

Windows provides an expiration notification to let you know that specific user or computer certificates have expired or are about to expire. In most cases, autoenrollment will automatically renew these certificates the next time you are connected to the network and log onto the computer.

The following topics contain procedures to use for renewing certificates:

  • Renew a Certificate with a New Key

  • Renew a Certificate with the Same Key

In addition, you can renew certificates issued from both Windows enterprise CAs and Windows stand-alone CAs with the Certificate Services Web pages by pasting in the contents of a PKCS #7 file. For more information, see the following topic:

  • Request a Certificate Using a PKCS #10 or PKCS #7 File

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can be managed only by an administrator or a user who has been given the appropriate permissions.


RADIUS Clients

RADIUS clients

A network access server (NAS) is a device that provides some level of access to a larger network. A NAS using a RADIUS infrastructure is also a RADIUS client, sending connection requests and accounting messages to a RADIUS server for authentication, authorization, and accounting.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

To deploy NPS as a RADIUS server, a RADIUS proxy, or a Network Access Protection (NAP) policy server, you must configure RADIUS clients in NPS.

RADIUS client examples

Examples of network access servers are:

  • Network access servers that provide remote access connectivity to an organization network or the Internet. An example is a computer running the Windows Server® 2008 operating system and the Routing and Remote Access service that provides either traditional dial-up or virtual private network (VPN) remote access services to an organization intranet.

  • Wireless access points that provide physical layer access to an organization network using wireless-based transmission and reception technologies.

  • Switches that provide physical layer access to an organization's network, using traditional LAN technologies, such as Ethernet.

  • RADIUS proxies that forward connection requests to RADIUS servers that are members of a remote RADIUS server group that is configured on the RADIUS proxy.

RADIUS Access-Request messages

RADIUS clients either create RADIUS Access-Request messages and forward them to a RADIUS proxy or RADIUS server, or they forward Access-Request messages to a RADIUS server that they have received from another RADIUS client but have not created themselves.

RADIUS clients do not process Access-Request messages by performing authentication, authorization, and accounting. Only RADIUS servers perform these functions.

NPS, however, can be configured as both a RADIUS proxy and a RADIUS server simultaneously, so that it processes some Access-Request messages and forwards other messages.

NPS as a RADIUS client

NPS acts as a RADIUS client when you configure it as a RADIUS proxy to forward Access-Request messages to other RADIUS servers for processing. When you use NPS as a RADIUS proxy, the following general configuration steps are required:

  1. Network access servers, such as wireless access points and VPN servers, are configured with the IP address of the NPS proxy as the designated RADIUS server or authenticating server. This allows the network access servers, which create Access-Request messages based on information they receive from access clients, to forward messages to the NPS proxy.

  2. The NPS proxy is configured by adding each network access server as a RADIUS client. This configuration step allows the NPS proxy to receive messages from the network access servers and to communicate with them throughout authentication. In addition, connection request policies on the NPS proxy are configured to specify which Access-Request messages to forward to one or more RADIUS servers. These policies are also configured with a remote RADIUS server group, which tells NPS where to send the messages it receives from the network access servers.

  3. The NPS or other RADIUS servers that are members of the remote RADIUS server group on the NPS proxy are configured to receive messages from the NPS proxy. This is accomplished by configuring the NPS proxy as a RADIUS client.

RADIUS client properties

When you add a RADIUS client to the NPS configuration through the NPS snap-in or through the use of the netsh commands for NPS, you are configuring NPS to receive RADIUS Access-Request messages from either a network access server or a RADIUS proxy.

When you configure a RADIUS client in NPS, you can designate the following properties:

  • Client name

    A friendly name for the RADIUS client, which makes it easier to identify when using the NPS snap-in or netsh commands for NPS.

  • IP address

    The Internet Protocol version 4 (IPv4) address or the Domain Name System (DNS) name of the RADIUS client.

  • Client-Vendor

    The vendor of the RADIUS client. Otherwise, you can use the RADIUS standard value for Client-Vendor.

  • Shared secret

    A text string that is used as a password between RADIUS clients, RADIUS servers, and RADIUS proxies. When the Message Authenticator attribute is used, the shared secret is also used as the key to encrypt RADIUS messages. This string must be configured on the RADIUS client and in the NPS snap-in.

  • Message Authenticator attribute

    Described in RFC 2869, "RADIUS Extensions," a Message Digest 5 (MD5) hash of the entire RADIUS message. If the RADIUS Message Authenticator attribute is present, it is verified. If it fails verification, the RADIUS message is discarded. If the client settings require the Message Authenticator attribute and it is not present, the RADIUS message is discarded. Use of the Message Authenticator attribute is recommended.

    Note

    The Message Authenticator attribute is required and enabled by default when you use EAP authentication.

  • Client is NAP-capable

    A designation that the RADIUS client is compatible with Network Access Protection (NAP), and NPS sends NAP attributes to the RADIUS client in the Access-Accept message.


Add a Constraint to a Network Policy

Add a constraint to a network policy

You can use this procedure to add a constraint to an existing network policy.

Constraints are additional network policy parameters that are optional. Constraints differ from network policy conditions in one substantial way: when a condition does not match a connection request, NPS continues to evaluate other configured network policies in search of a match for the connection request, but when a constraint does not match a connection request, NPS does not evaluate additional network policies, NPS rejects the connection request and the user or computer is denied network access.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To add a constraint to a network policy

  1. Open the Network Policy Server (NPS) Microsoft Management Console (MMC) snap-in, double-click Policies, and then click Network Policies.

  2. In the upper details pane, double-click the network policy to which you want to add a constraint, and then click the Constraints tab.

  3. In Constraints, click the constraint that you want to add to the policy.

  4. In the details pane, configure the value for the constraint, and then click OK.


Network Policies

Network Policies

Network policies are sets of conditions, constraints, and settings that allow you to designate who is authorized to connect to the network and the circumstances under which they can or cannot connect. When you deploy Network Access Protection (NAP), health policy is added to the network policy configuration so that NPS performs client health checks during the authorization process.

When processing connection requests as a RADIUS server, Network Policy Server (NPS) performs both authentication and authorization for the connection request. During the authentication process, NPS verifies the identity of the user or computer that is connecting to the network. During the authorization process, NPS determines whether the user or computer is allowed to access the network.

To make this determination, NPS uses network policies that are configured in the NPS Microsoft Management Console (MMC) snap-in. NPS also examines the dial-in properties of the user account in Active Directory Domain Services (AD DS) to perform authorization.

Note

In Internet Authentication Service (IAS) in the Windows Server® 2003 operating systems, network policies were called remote access policies.

Network policies can be viewed as rules. Each rule has a set of conditions and settings. NPS compares the conditions of the rule to the properties of connection requests. If a match occurs between the rule and the connection request, the settings defined in the rule are applied to the connection.

When multiple network policies are configured in NPS, they are an ordered set of rules. NPS checks each connection request against the first rule in the list, then the second, and so on, until a match is found.

Each network policy has a Policy State setting that allows you to enable or disable the policy. When you disable a network policy, NPS does not evaluate the policy when authorizing connection requests.

Important

If you want NPS to evaluate a network policy when performing authorization for connection requests, you must configure the Policy State setting by selecting the Policy enabled check box.

Network policy properties

There are four categories of properties for each network policy:

  • Overview

    These properties allow you to specify whether the policy is enabled, whether the policy grants or denies access, and whether a specific network connection method, or type of network access server, is required for connection requests. Overview properties also allow you to specify whether the dial-in properties of user accounts in AD DS are ignored. If you select this option, only the settings in the network policy are used by NPS to determine whether the connection is authorized. For more information, see Network Policy Overview Properties.

  • Conditions

    These properties allow you to specify the conditions that the connection request must have in order to match the network policy; if the conditions configured in the policy match the connection request, NPS applies the settings designated in the network policy to the connection. For example, if you specify the network access server IPv4 address (NAS IPv4 Address) as a condition of the network policy and NPS receives a connection request from a NAS that has the specified IP address, the condition in the policy matches the connection request. For more information, see Network Policy Conditions Properties.

  • Constraints

    Constraints are additional parameters of the network policy that are required to match the connection request. If a constraint is not matched by the connection request, NPS automatically rejects the request. Unlike the NPS response to unmatched conditions in the network policy, if a constraint is not matched, NPS does not evaluate additional network policies; the connection request is just denied. For more information, see Network Policy Constraints Properties.

  • Settings

    These properties allow you to specify the settings that NPS applies to the connection request if all of the network policy conditions for the policy are matched. For more information, see Network Policy Settings Properties.

When you add a new network policy using the NPS MMC snap-in, you must use the New Network Policy Wizard. After you have created a network policy using the wizard, you can customize the policy by double-clicking the policy in NPS to obtain the policy properties.


Add Array Members

When you create an Online Responder, it does not automatically become a member of an Array. Each Online Responder needs to be added to the Array manually.

You must have Manage Online Responder permissions on all of the Online Responders that you want to add to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To add members to an Array

  1. Open the Online Responder snap-in.

  2. In the console tree, click Array Configuration Members.

  3. In the Actions pane, click Add Array Members.

  4. Type the name and network path of the computer hosting the Online Responder you want to add to the Array, or click Browse to navigate to the Online Responder, and then click OK.

  5. Repeat this procedure for each member that you want to add to the Array.

Additional references

  • Managing an Online Responder Array


Network Access Protection in NPS

Network Access Protection in NPS

Network Access Protection (NAP) is a client health policy creation, enforcement, and remediation technology that is included in Windows Vista® and Windows Server® 2008. With NAP, you can establish health policies that define such things as software requirements, security update requirements, and required configuration settings for computers that connect to your network.

NAP enforces health policies by inspecting and assessing the health of client computers, restricting network access when client computers are noncompliant with health policy, and remediating noncompliant client computers to bring them into compliance with health policy before they are granted full network access. NAP enforces health policies on client computers that are attempting to connect to a network; NAP also provides ongoing health compliance enforcement while a client computer is connected to a network.

NAP is an extensible platform that provides an infrastructure and an application programming interface (API) set for adding components to NAP clients and servers running Network Policy Server (NPS) that check a computer's health, enforce network health policy, and remediate noncompliant computers to bring them into compliance with health policy.

By itself, NAP does not provide components to verify or remediate a computer's health. Other components, known as system health agents (SHAs) and system health validators (SHVs), provide client computer health state inspection and reporting, validation of client computer health state compared to health policy, and configuration settings to help the client computer become compliant with health policy.

The Windows Security Health Agent (WSHA) is included in Windows Vista as part of the operating system. The corresponding Windows Security Health Validator (WSHV) is included in Windows Server 2008 as part of the operating system. By using the NAP API set, other products can also implement SHAs and SHVs to integrate with NAP. For example, an antivirus software vendor can use the API set to create a custom SHA and SHV. These components can then be integrated into the NAP solutions that software vendor's customers deploy.

If you are a network or system administrator planning to deploy NAP, you can deploy NAP with the WSHA and WSHV that are included with the operating system. You can also check with other software vendors to find out if they provide SHAs and SHVs for their products.

NAP overview

Most organizations create network policies that dictate the type of hardware and software that can be deployed on the organization network. These policies frequently include rules for how client computers can be configured before connecting to the network. For example, many organizations require that client computers run antivirus software with recent antivirus updates installed, and that client computers have a software firewall installed and enabled before connecting to the organization network. A client computer that is configured according to the organization network policy can be viewed as compliant with policy, while a computer that is not configured according to the organization network policy can be viewed as noncompliant with policy.

NAP allows you to use NPS to create policies that define client computer health. NAP also allows you to enforce the client health policies you create, and to automatically update, or remediate, NAP-capable client computers to bring them into compliance with client health policy. NAP provides continuous detection of client computer health to guard against cases in which a client computer is compliant when it connects to the organization network but becomes noncompliant while connected.

NAP provides complementary client computer and organization network protection by ensuring that computers connecting to the network comply with organization network and client health policies. This protects the network from harmful elements introduced by client computers, such as computer viruses, and it also protects client computers from harmful elements that could be introduced by the network to which it is connecting.

In addition, NAP autoremediation reduces the amount of time that noncompliant client computers are prevented from accessing organization network resources. When autoremediation is configured and clients are in a noncompliant state, NAP client components can rapidly update the computer using resources you supply on a remediation network, allowing the now-compliant client to be more quickly authorized by NPS to connect to the network.

NPS and NAP

NPS provides the ability to act as a NAP policy server for all NAP enforcement methods.

When you configure NPS as a NAP policy server, NPS evaluates statements of health (SoH) sent by NAP-capable client computers that want to connect to the network. You can configure NAP policies in NPS that allow client computers to update their configuration to become compliant with your organization's network policy.

Client computer health

Health is defined as information about a client computer that NAP uses to determine whether to allow or deny client access to a network. An assessment of client computer health status represents a client computer's configuration state in comparison to the state that is required by health policy.

Example measurements of health include:

  • The operational status of Windows Firewall. Is the firewall enabled or disabled?

  • The update status of antivirus signatures. Are the antivirus signatures the most recent ones available?

  • The installation status of security updates. Are the most recent security updates installed on the client?

The client computer's health status is encapsulated in a SoH, which is issued by NAP client components. NAP client components send the SoH to NAP server components for evaluation to determine whether the client is compliant and can be granted full network access.

NAP allows administrators to ensure ongoing compliance with health policies, and, optionally, to limit the access of noncompliant computers until their health state can be brought into compliance with health policy.

In NAP terminology, verifying that a computer meets your defined health requirements is called health policy validation. NPS performs health policy validation for NAP.

How NAP enforcement works

NAP enforces health policies with client-side components that inspect and assess the health of client computers, server-side components that restrict network access when client computers are deemed noncompliant, and both client and server-side components that assist in remediating noncompliant client computers for full network access.

Key processes of NAP

To help protect network access, NAP relies on three processes: policy validation, NAP enforcement and network restriction, and remediation and ongoing compliance.

Policy validation

With NPS, you can create client health policies using SHVs that allow NAP to detect, enforce, and remediate client computer configurations.

WSHA and WSHV provide the following functionality for NAP-capable computers:

  • The client computer has firewall software installed and enabled.

  • The client computer has antivirus software installed and running.

  • The client computer has current antivirus updates installed.

  • The client computer has antispyware software installed and running.

  • The client computer has current antispyware updates installed.

  • Microsoft Update Services is enabled on the client computer.

In addition, if NAP-capable client computers are running Windows Update Agent and are registered with a Windows Server Update Service (WSUS) server, NAP can verify that the most recent software security updates are installed based on one of four possible values that match security severity ratings from the Microsoft Security Response Center (MSRC).

When you create policies that define the client computer health status, policies are validated by NPS. The NAP client-side components send a SoH to the NPS server during the network connection process. NPS examines the SoH and compares it to health policies.

NAP enforcement and network restriction

NAP denies noncompliant client computers access to the network or allows them access only to a special restricted network called a remediation network. A remediation network provides client computers with access to remediation servers, which provide software updates, and to any other key NAP services, such as Health Registration Authority (HRA) servers, that are required to bring noncompliant NAP clients into compliance with health policy.

The NAP enforcement setting in NPS network policy allows you to use NAP to limit the network access or observe the state of NAP-capable client computers that do not comply with your network health policy.

You can choose to restrict access, defer restriction of access, or allow access with network policy settings. For more information, see Network Policy Settings Properties.

Remediation

Noncompliant client computers that are put into a restricted network might undergo remediation. Remediation is the process of automatically updating a client computer so that it meets current health policies. For example, a restricted network might contain a File Transfer Protocol (FTP) server that automatically updates the virus signatures of noncompliant client computers that have outdated signatures.

Ongoing compliance

NAP can enforce health compliance on client computers that are already connected to the network. This functionality is useful for ensuring that a network is protected on an ongoing basis as health policies change and the health of client computers change. For example, NAP determines that the client computer is in a noncompliant state if a health policy requires that Windows Firewall is turned on and an administrator inadvertently turns the firewall off on a client computer. NAP will then disconnect the client computer from the organization network and connect the client computer to the remediation network until Windows Firewall is turned back on.

You can use NAP settings in NPS network policies to configure autoremediation so that NAP client components automatically attempt to update the client computer when it is not compliant. As with NAP enforcement settings, autoremediation is configured in network policy settings.

See Also

  • NAP Components
  • Health Policies
  • NAP Enforcement Methods
  • Remediation Server Groups
  • Windows Security Health Validator
  • Network Access Quarantine Control
  • Create NAP Policies with a Wizard


Display Certificate Stores in Purpose Store Mode

Certificate Purpose mode allows you to view and inspect certificates based on what they are intended to be used for, such as client authentication or key recovery, rather than on their logical roles.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To display certificate stores in Certificate purpose view mode

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Open Certificates - Current User or Certificates (Local Computer).

  3. Right-click Certificates - Current, click View, and then click Options.

  4. Under View mode, click Certificate purpose, and then click OK. The title Intended Purposes will appear at the top of the right-hand column, allowing you to select the type of certificates you need to inspect more closely.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


Re-Enroll All Certificate Holders

This procedure is used when a critical change is made to the certificate template and you want all subjects that hold a certificate that is based on this template to re-enroll as quickly as possible. The next time the subject verifies the version of the certificate against the version of the template on the certification authority (CA), the subject will re-enroll.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To re-enroll all certificate holders

  1. Open the Certificate Templates snap-in.

  2. Right-click the template that you want to use, and then click Reenroll All Certificate Holders.

Additional references

  • Issuing Certificates Based on Certificate Templates


Designate a Controller for the Array

When an Array contains multiple Online Responders, one Online Responder in the Array must be designated as the Array controller. Configuration settings on the Array controller override conflicting settings on other Online Responders in an Array.

You must have Manage Online Responder permissions on all of the Online Responders in the Array to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To designate an Array controller

  1. Open the Online Responder snap-in.

  2. In the console tree, click Array Configuration Members.

  3. Select the Online Responder that you want to designate as the Array controller.

  4. In the Actions pane, click Set as Array Controller.

After the new Array controller has been selected, the revocation configuration data from this Online Responder is retrieved and compared against the configuration data for the other Online Responders that are Array members.

Additional references

  • Managing an Online Responder Array


Manage Certificates

Certificates are typically issued to a particular computer, user, or service, for specific purposes, for specific durations, and often for specific recipients. As a result, at times you might need to obtain additional certificates, renew existing certificates, examine or modify the properties of a certificate, or move certificates. Although many of these tasks can be performed for a single user, computer, or service, other tasks are best performed automatically by an administrator from a server. The following sections describe common certificate management tasks and the procedure to complete them.

  • Obtain a Certificate

  • Renew a Certificate

  • View Certificates

  • Modify the Properties of a Certificate

  • Delete a Certificate

  • Find Certificates

  • Back Up Certificates

  • Move Certificates

  • Automate Certificate Management


NPS Server Certificate: CA Installation

CA installation

You can use this procedure to install Active Directory® Certificate Services (AD CS) so that you can enroll a server certificate to servers running Network Policy Server (NPS). If you deploy certificate-based authentication, NPS servers must have a server certificate. During the authentication process, NPS servers send their server certificate to client computers as proof of identity.

Membership in both the Enterprise Admins and the root domain's Domain Admins group is the minimum required to complete this procedure.

To install Active Directory Certificate Services

  1. Log on as a member of both the Enterprise Admins group and the root domain's Domain Admins group.

  2. Click Start, and then click Server Manager. The Server Manager console opens. In Roles Summary, click Add roles.

  3. The Add Roles wizard opens. Click Next.

  4. On the Select Server Roles page, in Roles, select Active Directory Certificate Services, and then click Next twice.

  5. On the Select Role Services page, in Role services, click Certification Authority, and then click Next.

  6. On the Specify Setup Type page, click Enterprise, and then click Next.

  7. On the Specify CA Type page, click Root CA, and then click Next.

  8. On the Set Up Private Key page, click Create a new private key, and then . click Next.

  9. On the Configure Cryptography for CA page, keep the default settings, and then click Next.

  10. On the Configure CA Name page, keep the suggested common name for the CA or change the name according to your requirements, and then click Next.

  11. On the Set Validity Period page, in Select validity period for the certificate generated for this CA, type the number and select the time value (Years, Months, Weeks, or Days) that determines the date upon which certificates issued by the CA will expire. The default setting of five years is recommended. Click Next.

  12. On the Configure Certificate Database page, in Certificate database location and Certificate database log location, specify the folder location for these items. If you specify locations other than the default locations, ensure that the folders are secured with access control lists (ACLs) that prevent unauthorized users or computers from accessing the CA database and log files. Click Next, and then click Finish.


Add a Certificate Template to a Certification Authority

In order for certificates to be issued by a certification authority (CA), the certificate template must be registered with a CA.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To add a certificate template to a CA

  1. Open the Certification Authority snap-in, and double-click the name of the CA.

  2. Right-click the Certificate Templates container, click New, and then click Certificate Template to Issue.

  3. Select the certificate template, and click OK.

Additional references

  • Deploying Certificate Templates


Object Identifiers

Object identifiers (also known as OIDs) are numbers that identify an object class or attribute. An object identifier is represented as a dotted decimal string, such as 1.2.3.4, with each dot representing a new branch in the hierarchy.

Object identifiers are organized into an industry-wide global hierarchy. National registration authorities issue root object identifiers to individuals or organizations, who manage the hierarchy below their root object identifier.

Object identifiers must be unique within an enterprise.

To create a new object identifier

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

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

  4. In Edit Application Policies Extension, click Add.

  5. In Add Application Policy, click New.

  6. Provide the requested information.


Synchronize Members with an Array Configuration

All Online Responders in an Array must use the same configuration data. The configuration data for an Array is defined on an Array controller. You must synchronize members of the Array with the Array controller to ensure that all members of the Array have the same configuration as the Array controller.

You must have Manage Online Responder permissions on all of the Online Responders in the Array to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To synchronize members with an Array controller

  1. Open the Online Responder snap-in.

  2. In the console tree, click Array Configuration Members.

  3. In the Actions pane, click Synchronize Responder Configuration.

Additional references

  • Managing an Online Responder Array


Checklist: Create an Online Responder Array

After the Online Responder Array has been planned, setting up the Array involves a number of procedures that must be completed in succession.

Task | Reference
Configure a CA to support Online Responders. | Configure a CA to Support OCSP Responders
Set up Online Responders that you intend to add to the Array. | Set Up an Online Responder
Add Online Responders to the Array. | Add Array Members

Additional references

  • Managing an Online Responder Array


Supersede Templates

There may be times when you want to modify the properties of a type of certificate that has already been issued to clients. You can do this by creating an updated certificate template for that certificate purpose and specifying that you want subjects of certificates based on the old template to obtain new certificates based on the new template. This procedure forces subjects to obtain a new certificate before the renewal date specified in the original certificate template.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To supersede templates

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. Click the Superseded Templates tab.

  4. Click Add.

  5. Click one or more templates to supersede, and then click OK.

  6. Make any other changes to the template that you want to include, and click OK.

Additional references

  • Configuring a Certificate Template


Back Up Certificates

Certificates are important credentials. Their loss or corruption can cause serious harm. Such harm can come from delays in authenticating your identity, blocking authentication, or making it impossible to retrieve encrypted data. You can back up certificates to protect them from loss or corruption, or to move them to a different computer.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To back up a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Do one of the following:

    • If you are in Logical Certificate Stores view mode, in the console tree, click Certificates.

    • If you are in Certificate Purpose view mode, in the console tree, click Purpose.

  3. In the details pane, click the certificate you want to export.

  4. On the Action menu, point to All Tasks, and then click Export.

  5. In the Certificate Export Wizard, click No, do not export the private key. (This option will appear only if the private key is marked as exportable and you have access to the private key.)

  6. Provide the following information in the Certificate Export Wizard by selecting the file format you want to use to store the exported certificate: a DER-encoded binary X.509 (.CER), a Base64-encoded X.509 (CER), or a PKCS #7 Certificates (.P7B) file.

    • If you are exporting the certificate to a PKCS #7 file, you also have the option to include all certificates in the certification path.

  7. If required, In Password, type a password to encrypt the private key you are exporting. In Confirm password, type the same password again, and then click Next.

  8. In File name, type a file name and path for the PKCS #12 file that will store the exported certificate and private key, click Next, and then click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • After the Certificate Export Wizard is finished, the certificate will remain in the certificate store in addition to being in the new file. If you want to remove the certificate from the certificate store, you must delete it.

Additional references

Back Up a Certificate With Its Private Key.


Create NAP Policies with a Wizard

Create NAP policies with a wizard

You can use this procedure to create the health policies, connection request policies, and network policies required to deploy Network Access Protection (NAP) with Network Policy Server (NPS).

This procedure explains how to start the New Network Access Protection Policies wizard. When you run the wizard, you first choose the network connection method that you have deployed, such as Terminal Services Gateway (TS Gateway) or 802.1X wireless, and then enter the information required for the wizard to create all of the NPS policies for that connection method.

Note

In this context, network connection method is synonymous with NAP enforcement method.

After you run the wizard, the following policies are created:

  • Two health policies: compliant and noncompliant.

  • One connection request policy.

  • Three network policies: compliant, noncompliant, and non-NAP capable.

Running the New Network Access Protection Policies wizard is not the only step required to deploy NAP. Each network connection method requires that you deploy hardware and software components for your NAP deployment.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To create NAP policies with a wizard

  1. Open the NPS console. If it is not already selected, click NPS (Local). If you are running the NPS MMC snap-in and want to create NAP policies on a remote NPS server, select the server.

  2. In Getting Started and Standard Configuration, select Network Access Protection (NAP) policy server. The text and links below the text change to reflect your selection.

  3. Click Configure NAP with a wizard. The New Network Access Protection Policies wizard opens.

See Also

  • NAP Enforcement Methods
  • Health Policies
  • Connection Request Policies
  • Network Policies
  • Network Access Protection in NPS


Administer an Online Responder from Another Computer

One advantage of Online Responders is that they can be deployed to provide revocation checking services at a remote location or even outside of the local intranet. However, this would frequently require the ability to manage the Online Responder from another computer.

By default, the Online Responder snap-in is installed automatically when an Online Responder is installed on a server. The Online Responder can be installed on a different server by using Server Manager to install Active Directory Certificate Services (AD CS) tools.

Before you can enable remote administration, you must configure Online Responder–related firewall settings on the computer hosting the Online Responder.

You must be local administrator to configure firewall settings. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To configure firewall settings to enable remote administration of an Online Responder

  1. Open Server Manager.

  2. Under Configuration, expand Windows Firewall with Advanced Security.

  3. Expand Inbound Rules, and click Online Responder Service (DCOM-In).

  4. In the Actions pane, click Enable Rule.

  5. Click Online Responder Service (RPC-In), and in the Action pane, click Enable Rule.

  6. To identify authorized users or computers that can access the Online Responder through each inbound Online Responder firewall rule, in the Actions pane, click Properties for each of these rules, and then click the Users and Computers tab.

You must be local administrator on the remote computer to install Remote Server Administration Tools. You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To administer a remote Online Responder

  1. On the remote computer, open Server Manager.

  2. Under Features Summary, click Add Features.

  3. Expand Remote Server Administration Tools and Role Administration Tools.

  4. Select the Active Directory Certificate Services check box, click Next, and then click Install.

  5. When the installation process is finished, click Close.

  6. Click Start, type mmc, and press ENTER.

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

  8. Click the Online Responder snap-in, click Add, and then click OK.

  9. In the console tree, click the Online Responder.

  10. On the Action menu, click Retarget Responder to identify the Online Responder that you want to manage.

Additional considerations

  • If the computer you want to perform remote administration tasks from is running Windows Vista, you can obtain the Remote Server Administration Tools Pack from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkID=89361).

  • If there is a firewall between the Online Responder and the remote computer, the firewall must be configured to allow data to pass through port 80 between Internet Information Services (IIS) and the Online Responder. Similar results can be achieved by using the reverse-proxy capability of Microsoft Internet Security and Acceleration (ISA) Server.

  • It may also be necessary to configure DCOM permissions to enable the Online Responders in an array to authenticate to each other.

Additional references

  • Managing Online Responders


Create a Custom Certificate Request

Administrators usually configure certificate templates in advance so that clients can use them to request or enroll for certificates. However, there might be occasions when none of the preconfigured certificate templates can meet a client's needs.

Custom requests can be used to modify a certificate template to meet unique needs, or to create a new certificate not based on a template. They can also be used to save a certificate request to a file for processing at a different time or on a different computer.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To create a custom certificate request

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In Logical Certificate Stores view mode, double-click Personal, and then click Certificates.

  3. On the Action menu, point to All Tasks, select Advanced Operations, and then click Create custom request to launch the Certificate Enrollment Wizard. Click Next.

  4. On the Custom Request page, click the drop-down list next to Templates, and do one of the following:

    • If you know what kind of certificate you want and want to accept the default configuration options, select the appropriate certificate template.

    • If you need a completely customized certificate, select (No template) CNG key or (No template) Legacy key.

    Note

    CNG keys might not be compatible with all applications.

  5. Each certificate template includes a standard set of extensions that can indicate additional subject identification information, or it can indicate key usage information, which specifies the tasks (such as signature or encryption) for which a key can be used. If you want to use only the custom extensions that you specify, select the Suppress default extensions check box.

  6. Select the file format you want to use for your certificate request:

    • PKCS #10 is a widely used format for certificate requests

    • CMC can be used to prepare requests that will be submitted to a non-Microsoft certification authority.

  7. Click Next.

  8. Click Details to view details of the certificate request. If you want to customize the request further, click Properties and fill in the desired options. When you are done, click OK to exit Certificate Properties, and then click Next.

  9. Enter a file name and path, and then click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC

Additional references

  • Request Certificates Using the Certificate Request Wizard


Modify an Issuance Policy

Certificates can be requested by any subject that has at least Read and Enroll permissions for the corresponding certificate template. In some cases, the administrator may want to place some restrictions on the process that occurs after a certificate request is made. This gives the administrator control of what certificates are issued and how the issuance process is implemented. This type of restriction is known as an issuance policy (also known as an enrollment or certificate policy). Issuance policies can contain requirements for certificate manager approval, multiple authorized signature requirements, and whether application and issuance policies should be implemented for this certificate. For more information, see Application Policy.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To modify an issuance policy

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. Click the Issuance Requirements tab.

  4. Provide the requested information.

  5. Click Apply.

Additional considerations

  • This procedure is applicable to version 2 and version 3 certificate templates. For more information, see Certificate Template Versions.

Additional references

  • Issuing Certificates Based on Certificate Templates

  • Issuance Requirements


Deploy Client Computer Certificates

Deploy client computer certificates

You can use this procedure to configure the certificate template that Active Directory® Certificate Services (AD CS) uses as the basis for computer certificates that are enrolled to domain member client computers.

Membership in both the Enterprise Admins and the root domain's Domain Admins group is the minimum required to complete this procedure.

To configure the certificate template and auto-enrollment

  1. On the computer where Active Directory Certificate Services is installed, click Start, click Run, type mmc, and then click OK.

  2. On the File menu, click Add/Remove Snap-in, and then click Add. The Add or Remove Snap-ins dialog box opens.

  3. In Available snap-ins, double-click Certification Authority. Select the CA that you want to manage with the snap-in, and then click Finish. The Certification Authority dialog box closes, returning to the Add or Remove Snap-ins dialog box.

  4. In Available snap-ins, double-click Certificate Templates, and then click OK.

  5. In the console tree, click Certificate Templates. All of the certificate templates are displayed in the details pane.

  6. In the details pane, click the Workstation Authentication template.

  7. On the Action menu, click Duplicate Template. The Duplicate Template dialog box opens. Select the template version appropriate for your deployment, and then click OK. The new template properties dialog box opens.

  8. On the General tab, in Display Name, type a new name for the certificate template or keep the default name. Select the Publish Certificate in Active Directory check box.

  9. Click the Security tab. In Group or user names, click Domain Computers.

  10. In Permissions for Domain Computers, under Allow, select the Enroll and Autoenroll permission check boxes, and then click OK.

  11. Double-click Certification Authority, double-click the CA name, and then click Certificate Templates. On the Action menu, point to New, and then click Certificate Template to Issue. The Enable Certificate Templates dialog opens.

  12. Click the name of the certificate template you just configured, and then click OK. For example, if you did not change the default certificate template name, click Copy of Workstation Authentication, and then click OK.

  13. On the computer where Active Directory Domain Services (AD DS) is installed, click Start, click Run, type mmc, and then click OK.

  14. On the File menu, click Add/Remove Snap-in, and then click Add. The Add or Remove Snap-ins dialog opens.

  15. In Available snap-ins, double-click Group Policy Management Console. The Select Group Policy Object wizard opens. Click Browse, and then select the appropriate Group Policy object (the default object is Default Domain Policy). Click OK, click Finish, and then click OK again.

  16. Double-click Default Domain Policy. Open Computer Configuration, then Windows Settings, then Security Settings, and then Public Key Policies.

  17. Double-click Certificate Services Client - Auto-Enrollment. The Properties dialog box opens.

  18. In the Properties dialog box, in Configuration Model, select Enabled.

  19. Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box.

  20. Select the Update certificates that use certificate templates check box, and then click OK.

Additional considerations

After you complete this procedure, domain member client computers automatically enroll a client computer certificate when Group Policy is refreshed. To refresh Group Policy, reboot the client computer or, at the command prompt, run gpupdate.


Windows Security Health Validator

Windows Security Health Validator

The Windows Security Health Validator (WSHV) provides settings that you can configure based on the requirements of your deployment.

WSHV settings

You can configure the following WSHV settings for your policy.

Firewall

To use the setting A firewall is enabled for all network connections, the firewall software that is running on the client computer must be Windows Firewall software or other firewall software that is compatible with Windows Security Center.

Firewall software that is not compatible with Windows Security Center cannot be managed or detected by Windows Security Health Agent (WSHA) on the client computer.

If you select A firewall is enabled for all network connections, WSHA on the client computer checks if firewall software is running on the client computer and takes the following actions.

  • If the client computer is not running firewall software, the client computer is restricted to a remediation network until firewall software is installed and running.

  • If the only firewall software running on the client computer is a firewall that is not compliant with Windows Security Center, WSHA reports to the Network Access Protection (NAP) service that no firewall is enabled, and the client computer is restricted to a remediation network.

Important

If you select A firewall is enabled for all network connections and client computers are not running Windows Firewall or other Windows Security Center-compliant firewall software, client computers cannot connect to your network.

If you do not select A firewall is enabled for all network connections, WSHA on the client computer does not attempt to enable firewall software or restrict client computers to a remediation network if they are not running firewall software. Because of this, client computers that are not running firewall software are not prevented from connecting to your network.

Autoremediation

If you select A firewall is enabled for all network connections, you enable NAP autoremediation, and WSHA on the client computer reports that no firewall is enabled, either because there is no firewall or the firewall software on the client computer is not compatible with Windows Security Center, then WSHV directs WSHA on the client computer to turn on Windows Firewall.

Important

If autoremediation is enabled and client computers are running firewall software that is not compliant with Windows Security Center and it is not detected by WSHA, WSHA on the client computer turns on Windows Firewall on the client computer, resulting in the client computer running two different firewalls simultaneously. Any exceptions configured on the noncompliant firewall are not configured in Windows Firewall, which could cause a loss of functionality on the client computer, depending on how it is configured. For this reason, it is not recommended for client computers to run two different firewalls simultaneously.

Virus protection

If you select An antivirus application is on, WSHA on the client computer verifies that antivirus software is running on the client computer. If the client computer is not running antivirus software, the client computer is restricted to a remediation network until antivirus software is installed and running.

The antivirus software that is running on the client computer must be compatible with Windows Security Center. Antivirus software that is not compatible with Windows Security Center cannot be managed or detected by WSHA on the client computer. If the only antivirus software running on the client computer is an antivirus application that is not compliant with Windows Security Center, the WSHA reports to WSHV that no antivirus is enabled, and the client computer is restricted to a remediation network.

If you select Antivirus is up to date, WSHA on the client computer verifies that the antivirus definitions for your antivirus applications are the most current versions and are up-to-date.

To verify that antivirus software is running and that antivirus definitions are the most recent updates available, you must select both An antivirus application is on and Antivirus is up to date.

If you do not select An antivirus application is on, WSHA on the client computer does not attempt to detect whether client computers are running antivirus software. Because of this, client computers that are not running antivirus software are not prevented from connecting to your network.

If you do not select both An antivirus application is on and Antivirus is up to date, WSHA on the client computer does not attempt to detect whether client computers are running antivirus software with the most recent antivirus definitions. Because of this, client computers that are not running antivirus software or that are running antivirus software with out-of-date antivirus definitions are not prevented from connecting to your network.

Spyware protection

If you select An antispyware application is on, WSHA on the client computer verifies that antispyware software is running on the client computer. If the client computer is not running antispyware software, the client computer is restricted to a remediation network until antispyware software is installed and running.

The antispyware software that is running on the client computer must be Windows Defender or other antispyware software that is compatible with Windows Security Center.

Antispyware software that is not compatible with Windows Security Center cannot be managed or detected by WSHA on the client computer. If the only antispyware software running on the client computer is an antispyware application that is not compatible with Windows Security Center, the WSHA reports to WSHV that no antispyware is enabled, and the client computer is restricted to a remediation network.

If you select Antispyware is up to date, WSHA on the client computer verifies that the antispyware definitions for your antispyware applications are the most current versions and are up-to-date.

To verify that antispyware software is running and that antispyware definitions are the most recent updates available, you must select both An antispyware application is on and Antispyware is up to date.

If you do not select An antispyware application is on, WSHA on the client computer does not attempt to detect whether client computers are running antispyware software. Because of this, client computers that are not running antispyware software are not prevented from connecting to your network.

If you do not select both An antispyware application is on and Antispyware is up to date, WSHA on the client computer does not attempt to detect whether client computers are running antispyware software with the most recent antispyware definitions. Because of this, client computers that are not running antispyware software or that are running antispyware software with out-of-date antispyware definitions are not prevented from connecting to your network.

Autoremediation

If you select An antispyware application is on, you enable NAP autoremediation, and WSHA on the client computer reports that no antispyware is enabled, either because there is no antispyware or the antispyware software on the client computer is not compatible with Windows Security Center, then WSHV directs WSHA on the client computer to turn on Windows Defender.

Important

If autoremediation is enabled and client computers are running antispyware software that is not compliant with Windows Security Center and the antispyware is not detected by WSHA, WSHA on the client computer turns on Windows Defender on the client computer, resulting in the client computer running two different antispyware applications simultaneously.

Note

You can configure autoremediation using the NAP Client Management MMC snap-in.

Automatic updating

If you select Automatic Updating is on, and Microsoft Update Services is not enabled on the client computer, WSHA restricts the client computer to a remediation network until Microsoft Update Services is enabled.

Microsoft Update Services is enabled when one of the following settings is selected on the client computer:

  • Install updates automatically (recommended)

  • Download updates, but let me choose whether to install them

  • Check for updates, but let me choose whether to download and install them

Autoremediation

If you select Automatic updates are enabled, you enable NAP autoremediation, and WSHA on the client computer reports that Microsoft Update Services is not enabled, then WSHV directs WSHA on the client computer to enable Microsoft Update Services and to configure Microsoft Update Services to automatically download and install updates.

Note

You can configure autoremediation using the NAP Client Management MMC snap-in.

Security update protection

Do not configure Security Update Protection in your WSHV policy unless client computers on your network are running Windows Update Agent. In addition, client computers that are running Windows Update Agent must be registered with a server running Windows Server Update Service (WSUS).

Important

Do not configure Security Update Protection in your WSHV policy unless client computers are running Windows Update Agent and they are registered with a WSUS server. If these conditions are not met and you configure Security Update Protection in your WSHV policy, the policy cannot be enforced by WSHA on the client computer. Because of this, WSHA restricts client computers to a remediation network and they cannot connect to your network.

If client computers are running Windows Update Agent and are registered with a WSUS server, you can configure Security Update Protection for your WSHV policy.

In that case, if you select Enforce quarantine for missing security updates and the most recent security updates are not installed, WSHA restricts the client computer to a remediation network until the most recent software security updates are installed.

You can configure Security Update Protection with several possible values that match security severity ratings from the Microsoft Security Response Center (MSRC). These values are:

  • Critical only. If selected, client computers are required to have all security updates with an MSRC severity rating of Critical. If client computers do not have these updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

  • Important and above. This is the default setting. If selected, client computers are required to have all security updates with an MSRC severity rating of Important or Critical. If client computers do not have these updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

  • Moderate and above. If selected, client computers are required to have all security updates with an MSRC severity rating of Moderate, Important, and Critical. If client computers do not have these updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

  • Low and above. If selected, client computers are required to have all security updates with an MSRC severity rating of Low, Moderate, Important, and Critical. If client computers do not have these updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

  • All. If selected, client computers are required to have all security updates, regardless of their severity rating by the MSRC. If client computers do not have the most recent updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

After you configure the security update severity rating level, you can specify the minimum number of hours allowed since the client has checked the WSUS server for new security updates. The default value for the minimum synchronization time is 22 hours.

When a client computer first attempts to connect to a NAP-enabled network and the Security Update Protection setting is configured in the WSHV policy, WSHA determines whether to restrict the client computer to a remediation network based on the most recent time that the client computer checked the WSUS server for security updates. WSHA determines whether to restrict the client to a remediation network in the following way.

  • If the client check for updates occurred at an interval greater than the WSHV-configured minimum number of hours allowed between checks, the client computer is restricted to a remediation network. After the client checks for updates and downloads and installs any recent updates, the client is allowed full network access.

  • If the client check for updates occurred at an interval that is equal to or less than the WSHV-configured minimum number of hours allowed between checks, the client computer is not restricted to a remediation network.

Note

WSHA on the client computer only performs this check the first time that the client computer attempts to connect to the network. If the client computer remains connected to the network for longer than the configured minimum synchronization time, WSHA does not trigger a check for security updates, does not trigger download of updates, and does not restrict the client computer to a remediation network.

Autoremediation

For autoremediation to work with the Security Update Protection setting enabled and configured in your WSHV policy, the following must be true:

  • Client computers on your network are running Windows Update Agent.

  • Client computers that are running Windows Update Agent are registered with a WSUS server.

  • Autoremediation is configured and enabled.

If these conditions are met, WSHA on the client computer checks with the WSUS server to discover the most recent security updates. If WSHA discovers that the most recent security updates of the configured MSRC severity rating are not installed on the client computer, WSHA downloads and installs the most recent security updates.


NAP Components

NAP components

Network Access Protection (NAP) consists of multiple client and server components. There are common NAP components that are used in all NAP deployments and there are components that are used only for specific deployments, depending on the NAP enforcement method or methods that you choose.

NAP enforcement methods are any of several network access technologies that work in conjunction with Network Access Protection to enforce health policies. The enforcement methods are Dynamic Host Configuration Protocol (DHCP), Internet Protocol security (IPsec), virtual private networking (VPN), Terminal Services Gateway (TS Gateway), and Extensible Authentication Protocol (EAP), which you can use for 802.1X-based wireless and wired connections that are authenticated by an NPS server.

Common NAP components

Common NAP components consist of both client and server components and are used by all NAP enforcement methods.

Client components

A NAP-capable client is a computer that has the NAP components installed and can verify its health state by sending a statement of health (SoH) to Network Policy Server (NPS).

Following are the NAP-capable client computer components of the NAP infrastructure.

  • Statement of health (SoH)

    A declaration from a client computer that asserts its health status. System health agents (SHAs) create statements of health (SoHs) and send them to a corresponding system health validator (SHV) on an NPS server.

  • System health agent (SHA)

    A component that checks the state of the client computer to determine whether the settings monitored by the SHA are up-to-date and configured correctly. For example, the Windows Security Health Agent (WSHA) can monitor Windows Firewall, whether antivirus software is installed, enabled, and updated, whether antispyware software is installed, enabled, and updated, and whether Microsoft Update Services is enabled and the computer has the most recent security updates from Microsoft Update Services. There might also be SHAs (and corresponding system health validators) available from other companies that provide different functionality.

  • NAP agent

    A client-side service that collects and manages health information. Processes statements of health from the various system health agents and reports client health to the NAP administration server.

  • Enforcement client

    Client software that integrates with network access technologies, such as DHCP, VPN, and IPsec. To use NAP, at least one NAP enforcement client must be installed and enabled on client computers. Individual NAP enforcement clients are enforcement method-specific and are described in the following section. The NAP enforcement client requests access to a network, communicates a client computer's health status to the NAP server that is providing the network access, such as the NPS server, and communicates the restricted status of the client computer to other components of the NAP client architecture.

Server components

Following are the server components of the NAP infrastructure.

  • Remediation server

    Hosts the updates that NAP agent can use to bring noncompliant client computers into compliance. For example, a remediation server can host antivirus signatures. If health policy requires that NAP client computers have the latest antivirus definitions installed, an antivirus SHA, an antivirus SHV, an antivirus policy server, and the remediation server used to host the antivirus signatures work in concert to update noncompliant computers.

  • System health validators (SHVs)

    Server software counterparts to SHAs. Each SHA on the client has a corresponding SHV in NPS. NPS uses SHVs to verify the statement of health that is made by its corresponding SHA on the client computer.

    SHAs and SHVs are matched to each other, along with a corresponding policy server (used by a SHV to determine the current conditions for system health) and perhaps a remediation server.

    A SHV can also detect that no SoH has been received (such as the case in which the SHA has never been installed, or has been damaged or removed). If the SoH does not meet the defined policy, the SHV sends a statement of health response (SoHR) message to the SHA.

    One network might have more than one kind of SHV. If it does, the NPS server must coordinate the output from all of the SHVs and determine whether to limit the access of a noncompliant computer. This requires careful planning when defining health policies for your environment and evaluating how different SHVs interact.

    The Windows Security Health Validator (WSHV) can verify a SoH from the WSHA on a client computer. There might also be SHVs (and corresponding SHAs) available from other companies that provide different functionality.

  • Health policies

    Rules created by configuring individual SHVs and adding them to a health policy, and then configuring policy conditions. Health policies are then implemented and enforced by NPS when you add them to the settings of a network policy.

  • Statement of health response (SoHR)

    The validation of a SoH. If the client computer is noncompliant, the SoHR contains remediation instructions that the SHAs on the client use to bring the client computer configuration into compliance with health policy.

    Each type of SoH stores different kinds of information about system health status, and SoHR messages store different kinds of information about how to become compliant with the health policy requirements that are configured in NPS.

Enforcement method-specific components

Following are the enforcement method-specific components of the NAP infrastructure.

  • Enforcement technology

    One of five network access technologies that can be configured to enforce NAP policies.

  • Enforcement server

    A component on a NAP server that is typically matched with a NAP enforcement client and that restricts a client computer’s network access based on its health compliance. There are several NAP enforcement servers: one for DHCP address configurations, one for VPN connections, one for IPsec-protected communication, one for Terminal Services Gateway (TS Gateway), and one for Extensible Authentication Protocol (EAP), which you can use for 802.1X-based connections that are authenticated by an NPS server.

See Also

  • Network Access Protection in NPS
  • NAP Enforcement Methods
  • Windows Security Health Validator


Realm Names

Realm names

The User-Name RADIUS attribute is a character string that typically contains a user account location and a user account name. The user account location is also called the realm or realm name, and is synonymous with the concept of domain, including DNS domains, Active Directory® domains, and Windows NT 4.0 domains. For example, if a user account is located in the user accounts database for a domain named example.com, then example.com is the realm name.

In another example, if the User-Name RADIUS attribute contains the user name user1@example.com, user1 is the user account name and example.com is the realm name. Realm names can be presented in the user name as a prefix or as a suffix:

  • Example\user1. In this example, the realm name Example is a prefix; and it is also the name of a Windows NT 4.0 domain.

  • user1@example.com. In this example, the realm name example.com is a suffix; and it is either a DNS domain name or the name of an Active Directory domain.

You can use realm names configured in connection request policies while designing and deploying your RADIUS infrastructure to ensure that connection requests are routed from RADIUS clients, also called network access servers, to RADIUS servers that can authenticate and authorize the connection request.

When NPS is configured as a RADIUS server with the default connection request policy, NPS processes connection requests for the domain in which the NPS server is a member and for trusted domains.

To configure NPS to act as a RADIUS proxy and forward connection requests to untrusted domains, you must create a new connection request policy. In the new connection request policy, you must configure the User Name attribute with the realm name that will be contained in the User-Name attribute of connection requests that you want to forward. You must also configure the connection request policy with a remote RADIUS server group. The connection request policy allows NPS to calculate which connection requests to forward to the remote RADIUS server group based on the realm portion of the User-Name attribute.

Acquiring the realm name

The realm name portion of the user name is provided when the user types password-based credentials during a connection attempt or when a Connection Manager (CM) profile on the user's computer is configured to provide the realm name automatically.

You can designate that users of your network provide their realm name when typing their credentials during network connection attempts.

For example, you can require users to type their user name, including the user account name and the realm name, in User name in the Connect dialog box when making a dial-up or virtual private network (VPN) connection.

In addition, if you create a custom dialing package with the Connection Manager Administration Kit (CMAK), you can assist users by adding the realm name automatically to the user account name in CM profiles that are installed on users' computers. For example, you can specify a realm name and user name syntax in the CM profile so that the user only has to specify the user account name when typing credentials. In this circumstance, the user does not need to know or remember the domain where their user account is located.

During the authentication process, after users type their password-based credentials, the user name is passed from the access client to the network access server. The network access server constructs a connection request and includes the realm name within the User-Name RADIUS attribute in the Access-Request message that is sent to the RADIUS proxy or server.

If the RADIUS server is an NPS server, the Access-Request message is evaluated against the set of configured connection request policies. Conditions on the connection request policy can include the specification of the contents of the User-Name attribute.

You can configure a set of connection request policies that are specific to the realm name within the User-Name attribute of incoming messages. This allows you to create routing rules that forward RADIUS messages with a specific realm name to a specific set of RADIUS servers when NPS is used as a RADIUS proxy.

Attribute manipulation rules

Before the RADIUS message is either processed locally (when NPS is being used as a RADIUS server) or forwarded to another RADIUS server (when NPS is being used as a RADIUS proxy), the User-Name attribute in the message can be modified by attribute manipulation rules. You can configure attribute manipulation rules for the User-Name attribute by selecting User name on the Conditions tab in the properties of a connection request policy. NPS attribute manipulation rules use regular expression syntax.

You can configure attribute manipulation rules for the User-Name attribute to change the following:

  • Remove the realm name from the user name (also known as realm stripping).

    For example, the user name user1@example.com is changed to user1.

  • Change the realm name but not its syntax.

    For example, the user name user1@example.com is changed to user1@wcoast.example.com.

  • Change the syntax of the realm name.

    For example, the user name example\user1 is changed to user1@example.com.

After the User-Name attribute is modified according to the attribute manipulation rules that you configure, additional settings of the first matching connection request policy are used to determine whether:

  • The NPS server processes the Access-Request message locally (when NPS is being used as a RADIUS server).

  • The NPS server forwards the message to another RADIUS server (when NPS is being used as a RADIUS proxy).

Caution

Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Note

When the user name does not contain a domain name, NPS supplies one. By default, the NPS-supplied domain name is the domain of which the NPS server is a member. You can specify the NPS-supplied domain name through the following registry setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn\DefaultDomain

Some non-Microsoft network access servers delete or modify the domain name as specified by the user. As the result, the network access request is authenticated against the default domain, which might not be the domain for the user's account. To resolve this problem, configure your RADIUS servers to change the user name into the correct format with the accurate domain name.


EAP Overview

EAP and NPS

Extensible Authentication Protocol (EAP) extends Point-to-Point Protocol (PPP) by allowing arbitrary authentication methods that use credential and information exchanges of arbitrary lengths. EAP was developed in response to demand for authentication methods that use security devices, such as smart cards, token cards, and crypto calculators. EAP provides an industry-standard architecture for supporting additional authentication methods within PPP.

By using EAP, you can support additional authentication schemes, known as EAP types. These schemes include token cards, one-time passwords, public key authentication using smart cards, and certificates. EAP, in conjunction with strong EAP types, is a critical technology component for secure virtual private network (VPN) connections, 802.1X wired connections, and 802.1X wireless connections. Both the network access client and the authenticator, such as the NPS server, must support the same EAP type for successful authentication to occur.

Important

Strong EAP types, such as those based on certificates, offer better security against brute-force or dictionary attacks and password guessing than password-based authentication protocols, such as CHAP or MS-CHAP.

With EAP, an arbitrary authentication mechanism authenticates a remote access connection. The authentication scheme to be used is negotiated by the remote access client and the authenticator (either the network access server or the Remote Authentication Dial-In User Service [RADIUS] server). Routing and Remote Access includes support for EAP-TLS and MD5-Challenge by default. You can plug in other EAP modules to the server running Routing and Remote Access to provide other EAP methods.

EAP allows for an open-ended conversation between the remote access client and the authenticator. The conversation consists of authenticator requests for authentication information and the responses by the remote access client. For example, when EAP is used with security token cards, the authenticator can separately query the remote access client for a name, PIN, and card token value. As each query is asked and answered, the remote access client passes through another level of authentication. When all questions have been answered satisfactorily, the remote access client is authenticated.

Windows Server® 2008 includes an EAP infrastructure, two EAP types, and the ability to pass EAP messages to a RADIUS server (EAP-RADIUS).

EAP infrastructure

EAP is a set of internal components that provide architectural support for any EAP type in the form of a plug-in module. For successful authentication, both the remote access client and authenticator must have the same EAP authentication module installed. You can also install additional EAP types. The components for an EAP type must be installed on every network access client and every authenticator.

Note

The Windows Server 2003 operating systems provide two EAP types: MD5-Challenge and EAP-TLS. MD5-Challenge is not supported in Windows Server 2008.

EAP-TLS

EAP-Transport Level Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. If you are using smart cards for remote access authentication, you must use the EAP-TLS authentication method. The EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and encrypted key determination between the remote access client and the authenticator. EAP-TLS provides the strongest authentication and key determination method.

Note

During the EAP-TLS authentication process, shared secret encryption keys for Microsoft Point-to-Point Encryption (MPPE) are generated.

EAP-TLS is supported only on servers that are running Routing and Remote Access, that are configured to use Windows Authentication or RADIUS, and that are members of a domain. A network access server running as a standalone server or a member of a workgroup does not support EAP-TLS.

Using RADIUS as a transport for EAP

Using RADIUS as a transport for EAP is the passing of EAP messages of any EAP type by a RADIUS client to a RADIUS server for authentication. For example, for a network access server that is configured for RADIUS authentication, the EAP messages sent between the remote access client and network access server are encapsulated and formatted as RADIUS messages between the network access server and the RADIUS server. When you use EAP over RADIUS, it is called EAP-RADIUS.

EAP-RADIUS is used in environments where RADIUS is used as the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each network access server, only at the RADIUS server. In the case of an NPS server, you only need to install EAP types on the NPS server.

In a typical use of EAP-RADIUS, a server running Routing and Remote Access is configured to use EAP and to use an NPS server for authentication. When a connection is made, the remote access client negotiates the use of EAP with the network access server. When the client sends an EAP message to the network access server, the network access server encapsulates the EAP message as a RADIUS message and sends it to its configured NPS server. The NPS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the network access server. The network access server then forwards the EAP message to the remote access client. In this configuration, the network access server is only a pass-through device. All processing of EAP messages occurs at the remote access client and the NPS server.

Routing and Remote Access can be configured to authenticate locally, or to a RADIUS server. If Routing and Remote Access is configured to authenticate locally, all EAP methods will be authenticated locally. If Routing and Remote Access is configured to authenticate to a RADIUS server, all EAP messages will be forwarded to the RADIUS server with EAP-RADIUS.

Enabling EAP

To enable EAP-based authentication

  1. Enable EAP as an authentication protocol on the network access server. For more information, see your network access server documentation.

  2. Enable EAP and, if needed, configure the EAP type to the constraints on the appropriate network policy. For more information, see Add a Constraint to a Network Policy.

  3. Enable and configure EAP on the remote access client. For more information, see your access client documentation.

See Also

  • NPS CRL Checks
  • NPS CRL Check Registry Settings


Deploying Network Access Quarantine Control

Deploying Network Access Quarantine Control

To deploy Network Access Quarantine Control (NAQC), you must complete the following steps:

  • Install and configure Routing and Remote Access as a virtual private network (VPN) server.

  • Install Network Policy Server (NPS) if you have multiple VPN servers. (This step is optional.) Configure all VPN servers as RADIUS clients in NPS, register the NPS server in Active Directory® Domain Services (AD DS), if applicable, and configure Accounting to your requirements. Also, configure VPN servers to forward connection requests to your NPS server. Use an identical shared secret on VPN and NPS servers to allow secure communications between the servers.

  • If you want to customize the checks performed on the client computer, create a client-side script that validates client configuration information. If you do not want to create a client-side script, you can use quarchk.cmd, which is installed on the server when you install Connection Manager Administration Kit (CMAK). Quarchk.cmd is located in the folder %systemroot%\Program Files\CMAK\Support.

  • Create a Connection Manager (CM) profile with CMAK. While running the wizard, enter settings that are appropriate for your deployment and ensure that you take the following steps:

    • On the Add Custom Actions wizard page, in Action type, select Post-connect, and then click New. In New Custom Action, in Description, type a name for the post-connect action.

    • In New Custom Action, in Program to run, click Browse to add either your custom client-side script or quarchk.cmd. To locate quarchk.cmd, in Browse, ensure that All files (*.*) is selected, click quarchk.cmd, and then click Open.

    • In New Custom Action, in Parameters, add the following parameters:

      %ServiceDir% %ServiceName% RASQuarantineConfigPassed %Domain% %USERNAME% 7250

    • Click OK, and continue running the CMAK wizard, configuring settings per your requirements, until you reach the Install Additional Files with the Connection Manager Profile page. Click Add. In Browse, click rqc.exe, and then click Open.

  • Distribute the CM profile for installation on remote access client computers.

  • On VPN servers, start the Remote Access Quarantine Agent service and change the startup type to automatic. This step enables the listener component of NAQC.

  • Configure one quarantine network policy on VPN or NPS servers using the following instructions as a guideline.

Note

The registry key RASQuarantineConfigPassed is located in the RQS entry on the server running Routing and Remote Access at the following registry path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RQS (AllowedSet).

Network policy

On your VPN servers or NPS servers, you must create a quarantine network policy for VPN connections. It is recommended that you grant VPN access to users who are members of an Active Directory group. Therefore, before creating the network policy in NPS or Routing and Remote Access, create a VPN users group in AD DS. When you run the New Network Policy wizard, you can then select the Active Directory group that you created.

The notification and listener components of NAQC use port 7250 by default. When you create the quarantine policy, you must configure Inbound Filters (also called Input Filters) to allow network traffic on port 7250, or the notification component (Rqc.exe), which runs on client computers, cannot notify the remote access server listener component (Remote Access Quarantine Agent service) that the script has run successfully. You can specify another port, but if so, you must also configure the listener and notification components to use this new port.

In addition, you must configure the network policy settings with Quarantine IP Filters or Quarantine Session Timers, depending on your deployment of NAQC.

How the network policy works

When the connection is made from the VPN client to the VPN server, the access server or NPS server compares the connection request to the configured network policies until it finds a policy whose conditions and constraints match the connection request. If conditions do not match, the network policy is not used, and the next network policy is evaluated. If constraints do not match, the connection is rejected.

If the connection request matches the quarantine policy and the user is authenticated and authorized to connect to the network, the access server implements the restrictions (Quarantine IP Filters and Quarantine Session Timers) that exist in the network policy on the access server or that are returned by NPS in the Access-Accept message.

Important

Notification by the client to the server running Routing and Remote Access that the administrator-provided script or quarchk.cmd has run successfully is not secure and can be spoofed by a malicious user. NAQC is intended only to help verify a managed client computer configuration.

See Also

  • Network Access Quarantine Control
  • Network Access Quarantine Control and NAP


Manage Revocation Data by Using Local CRLs

Ideally, certificate revocation data is managed in a central location and immediately made available to all potential users. But this is not always possible in complex network environments.

Organizations that use Online Responders, however, can create a local certificate revocation list (CRL) to manage certificate revocation data locally during intervals when the Online Responder is unable to obtain updated revocation data from a certification authority (CA) or other Online Responder. The next time a connection is established, you can replicate local CRL data back to the CA CRL and remove the local CRL. Until it is removed, the local CRL will always take precedence over the revocation status information from the revocation provider.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To modify certificate data in a local CRL

  1. Open the Online Responder snap-in.

  2. In the console tree, click Revocation Configuration.

    A list of existing revocation configurations appears in the details pane.

  3. Right-click a revocation configuration, and click Local Certificate Revocation List.

  4. In the Local Certificate Revocation List dialog box, select the certificate whose data you want to modify.

  5. Click Update.

  6. Modify the values that you want to change.

  7. Click OK twice to exit the Local Certificate Revocation List dialog box.

When your local revocation data has been synchronized with the revocation data for the entire CA, you should delete all data from the local CRL.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To delete one or more certificates from a local CRL

  1. Open the Online Responder snap-in.

  2. In the console tree, click Revocation Configuration.

    A list of existing revocation configurations appears in the details pane.

  3. Right-click a revocation configuration, and click Local Certificate Revocation List.

  4. In the Local Certificate Revocation List dialog box, select the certificate or certificates you want to remove from the local CRL.

  5. Click Remove.

  6. Click OK twice to exit the Local Certificate Revocation List dialog box.

Additional references

  • Managing a Revocation Configuration

  • Audit Revocation Configuration Changes

  • Manage Online Responder Security


NAP Enforcement for 802.1X

NAP enforcement for 802.1X

Network Access Protection (NAP) enforcement for 802.1X port-based network access control is deployed with a server running Network Policy Server (NPS) and an EAP host enforcement client component. With 802.1X port-based enforcement, the NPS server instructs an 802.1X authenticating switch or an 802.1X compliant wireless access point to place noncompliant 802.1X clients on a remediation network. The NPS server limits the client's network access to the remediation network by applying IP filters or a virtual LAN identifier to the connection. 802.1X enforcement provides strong network restriction for all computers accessing the network through 802.1X-capable network access servers.

Requirements for 802.1X wired

To deploy NAP with 802.1X wired, you must configure the following:

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Install and configure 802.1X authenticating switches.

  • Enable the NAP EAP enforcement client and the NAP service on NAP-capable client computers.

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

  • If you are using PEAP-TLS or EAP-TLS with smart cards or certificates, deploy a public key infrastructure (PKI) with Active Directory® Certificate Services (AD CS).

  • If you are using PEAP-MS-CHAP v2, issue server certificates with either AD CS or purchase server certificates from another trusted root certification authority (CA).

Requirements for 802.1X wireless

To deploy NAP with 802.1X wireless, you must configure the following:

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Install and configure 802.1X wireless access points.

  • Enable the NAP EAP enforcement client and the NAP service on NAP-capable client computers.

  • Configure the WSHV or install and configure other SHAs and SHVs, depending on your NAP deployment.


Certificate Extensions

The Extensions tab allows an administrator to define specific application policies, issuance policies, certificate subject types, and key usage attributes for a certificate template.

Application policies

Application policies are settings that inform a target that the subject holds a certificate that can be used to perform a specific task. They are represented in a certificate by an object identifier that is defined for a given application. This object identifier is included in the issued certificate. When a subject presents its certificate, the certificate can be examined by the target to verify the application policy and determine whether the subject can perform the requested action.

Issuance policies

Issuance policies, also referred to as certificate policies, define the measures that are used to identify the subject of the certificate and thereby define the level of assurance for an issued certificate. For example, your organization might require a face-to-face meeting before the certificate is issued to provide for a higher level of assurance for the issued certificate.

Certificate subject type

The certificate subject type, also referred to as the certificate template information, defines the purpose of a certificate or certificate template.

The certificate subject type extension cannot be edited. If an administrator requires a specific subject type to be applied to a certificate, the administrator should clone from a certificate template that includes the required subject type.

Key usage

A certificate enables the subject to perform a specific task. To help control the usage of a certificate outside its intended purpose, restrictions are automatically placed on certificates. Key usage is a restriction method that determines what a certificate can be used for. It allows the administrator to issue certificates that can only be used for specific tasks or certificates that can be used for a broad range of functions. If no key usage is specified, the certificate can be used for any purpose.

For signatures, key usage can be limited to one or more of the following purposes:

  • Digital signature

  • Signature is a proof of origin (nonrepudiation)

  • Certificate signing

  • CRL signing

For encryption key usage, the following options are available:

  • Key exchange without key encryption

  • Key exchange only with key encryption

Additional reference

  • Request a Certificate


Move Certificates

Many applications look for a certificate in only one certificate store. If a certificate is not in the certificate store that you need, you can move it from one store to another.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To move a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Under the logical store where the certificate is stored, click Certificates.

  3. In the details pane, click the certificate you are moving. (To select more than one certificate, hold down CTRL and click each certificate.)

  4. On the Action menu, click Cut.

  5. Click the logical certificate store where you want to move the certificate.

    Where?

    • Certificates - Current User/Logical store Name

  6. On the Action menu, click Paste.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • In Certificates, you can only move an object within certificate stores. For example, you cannot move an object to a folder in Windows Explorer. To move a certificate to or from a folder on the file system or a removable storage device, see Import a Certificate, Export a Certificate, and Export a Certificate with the Private Key.


NAP Enforcement for Terminal Services Gateway

NAP enforcement for Terminal Services Gateway

Terminal Services Gateway (TS Gateway) is a new role service available in Windows Server® 2008. With TS Gateway, authorized users can connect from any Internet-connected device to terminal servers and remote desktops on your organization network. In addition, the health state of client computers that are Terminal Services clients can be enforced and monitored with Network Access Protection (NAP).

NAP enforcement for TS Gateway is deployed with a server running Network Policy Server (NPS) and a TS Gateway server.

Requirements

To deploy NAP with TS Gateway, you must configure the following:

  • Install and configure TS Gateway. When you run the Add Roles Wizard to install the TS Gateway role service, you must select Terminal Services. Later, on the Select Role Services page, you can select the TS Gateway role service for installation.

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

  • If you are using PEAP-TLS or EAP-TLS with smart cards or certificates, deploy a public key infrastructure (PKI) with Active Directory® Certificate Services (AD CS).

  • If you are using PEAP-MS-CHAP v2, issue server certificates with either AD CS or purchase server certificates from a trusted root certification authority (CA).

  • Enable NAP health policy checks on the TS Gateway server using the TS Gateway Manager snap-in.

  • Enable the NAP TS Gateway enforcement client, the EAP enforcement client, and the NAP service on NAP-capable client computers.


Upgrade Existing Templates

When you upgrade a certification authority (CA), you may need to update the Active Directory schema to support new certificate template attributes. For more information about updating the Active Directory schema with Adprep.exe, see the Command Line Reference (http://go.microsoft.com/fwlink/?LinkID=20331).

In addition, you need to upgrade the certificate templates to include and configure these attributes. Upgrading the certificate templates applies the proper security permissions on the existing certificate templates and installs new certificate templates.

If you do not perform this procedure before upgrading your CAs to Windows Server® 2008, you will be prompted when opening the Certificate Templates snap-in. If this procedure has already been performed in your enterprise, you will not receive a prompt when you open Certificate Templates.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To install new templates and upgrade existing templates

  1. Open the Certificate Templates snap-in.

  2. When prompted to install new certificate templates, click OK.

Additional considerations

  • After a CA has been upgraded and certificate templates have been installed, you can create new version 2 or version 3 copies of any certificate template in the domain. For more information, see Create a New Certificate Template.

Additional references

  • Managing Certificate Templates


NAP Enforcement for VPN

NAP enforcement for VPN

Network Access Protection (NAP) enforcement for virtual private networking (VPN) is deployed with a VPN enforcement server component and a VPN enforcement client component. Using this enforcement method, VPN servers can enforce health policy when client computers attempt to connect to the network using a VPN connection. VPN enforcement provides strong limited network access for all computers accessing the network through a VPN connection.

Note

VPN enforcement is different from Network Access Quarantine Control, which is a feature in Windows Server® 2003 and Internet Security and Acceleration (ISA) Server 2004.

Requirements

To deploy NAP with VPN, you must configure the following:

  • Install and configure Routing and Remote Access as a VPN server. Configure your server running Network Policy Server (NPS) as the primary RADIUS server in Routing and Remote Access.

  • In NPS, configure VPN servers as RADIUS clients. Also configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Enable the NAP Remote Access and EAP enforcement clients on NAP-capable client computers.

  • Enable the NAP service on NAP-capable client computers.

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

  • If you are using PEAP-TLS or EAP-TLS with smart cards or certificates, deploy a public key infrastructure (PKI) with Active Directory® Certificate Services (AD CS).

  • If you are using PEAP-MS-CHAP v2, issue server certificates with either AD CS or purchase server certificates from a trusted root certification authority (CA).

Additional considerations

If you deploy the NAP VPN enforcement method and you have configured NAP enforcement with the Allow full network access for a limited time option, VPN clients that are connected to the network when the expiration time is reached are automatically disconnected whether they are compliant or noncompliant with health policy.

After the expiration date and time, VPN clients that attempt to connect to the network are placed on a restricted network if they are noncompliant with health policy, while compliant clients are allowed full network access.


Certification Path Tab

Using the Certification path tab, you can view the path from the selected certificate to the certification authorities that issue the certificate.

Before it trusts a certificate, this version of Windows must verify that the certificate comes from a trusted source. This verification process is called path validation.

Path validation involves processing public key certificates and their issuer certificates in a hierarchical fashion until the certificate chain terminates at a trusted, self-signed certificate. Typically, this is a root CA certificate. If there is a problem with one of the certificates in the path, or if it cannot find a certificate, the certification path is considered a non-trusted certification path.

A typical certification path includes a root certificate and one or more intermediate certificates. By clicking View Certificate, you can also learn more about the certificates for each certification authority in the path.


Certification Authorities

The Certification Authority snap-in allows you to perform a variety of administrative tasks, including:

  • Start and stop the certification authority (CA).

  • Back up and restore the CA.

  • Change exit and policy modules.

  • View the CA certificate.

  • Install or reinstall a CA certificate for the CA.

  • Set security permissions and delegate administrative control for the CA.

  • Revoke certificates.

  • View or modify certificate revocation list (CRL) distribution points.

  • Publish CRLs and schedule CRL publication.

  • Configure the types of certificates that are to be issued by the CA.

  • View information about certificates that have been issued or revoked.

  • View, approve, or deny pending certificate requests.

  • View failed certificate requests.

  • Renew the CA's certificate.

For more information about installing, configuring, and using the Certification Authority snap-in, see Managing a Certification Authority.


Configure 802.1X Wireless Clients Running Windows Vista with Group Policy

Use the procedures in this topic to configure the Wireless Network (IEEE 802.11) Policies for client computers running Windows Vista® that connect to your wireless network through 802.1X authenticating wireless access points (APs).

This document provides the detailed steps to create and configure the Windows Vista Wireless Network (IEEE 802.11) Policies and wireless configuration profiles for wireless computers running Windows Vista.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

Configure wireless clients running Windows Vista by using the Wireless Network (IEEE 802.11) Policies

The New Vista Wireless Network (IEEE 802.11) Policies enables you to configure, prioritize and manage multiple wireless profiles that each use different profile names and different wireless settings, while using the same Service Set Identifier (SSID). For example, you can configure two (or more) profiles using the same SSID; one profile to use Smart Cards and one profile to use Protected Extensible Authentication Protocol Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2), or one using Wi-Fi Protected Access version 2 (WPA2)-Enterprise and one using WPA-Enterprise. The ability to configure mixed-mode deployments using a common SSID is one of the enhancements in the Wireless Network (IEEE 802.11) Policies for Windows Vista.

Note

You can use the Windows Vista Wireless Network (IEEE 802.11) Policies to configure wireless computers running Windows Vista and Windows Server 2008. You cannot use this policy to configure computers running Windows XP. Computers running Windows XP cannot interpret settings in a Windows Vista Wireless Network (IEEE 802.11) Policies.

You can use these features to configure security and authentication settings, manage wireless profiles, and specify permissions for wireless networks that are not configured as preferred networks.
Opening the Wireless Network (IEEE 802.11) Policies properties

Use this procedure to access the Wireless Network (IEEE 802.11) Policies.

To open the Wireless Network (IEEE 802.11) Policies properties

  1. Open the Group Policy Management Console (GPMC).

  2. In Default Domain Policy, open Computer Configuration, open Windows Settings, open Security Settings, and then select Wireless Network (IEEE 802.11) Policies.

    • If there is a Wireless Network Policy shown in the details pane, with the Type listed as Vista, right-click that policy, and then click Properties, to access the properties of the wireless policy.

      Note

      The wireless policy is not necessarily listed as New Vista Wireless Network Policy in the details pane of the GPMC. If the default policy name was previously changed from New Vista Wireless Network Policy to another name, the name change is reflected in the GPMC details pane.

    • If there is not a Wireless Network Policy shown in the details pane, with the Type listed as Vista, right-click Wireless Network (IEEE 802.11) Policies, and then click Create A New Windows Vista Policy to activate and open New Vista Wireless Network Policy Properties.

      Note

      After the Windows Vista wireless policy is added, it is only listed in the GPMC details pane, when Wireless Network (IEEE 802.11) Policies is selected.

Configure PEAP-MS-CHAP v2 and EAP-TLS wireless infrastructure profiles

The procedures in this section provide the steps to configure the Windows Vista Wireless Network (IEEE 802.11) Policies to create one or more wireless profiles that wireless clients running Windows Vista will use to connect to your wireless network. The first procedure provides the steps to use Windows Vista Wireless Network (IEEE 802.11) Policies to configure a wireless profile for PEAP-MS-CHAP v2. The second procedure provides the steps to use Windows Vista Wireless Network (IEEE 802.11) Policies to configure a wireless profile for EAP-TLS.

Note

PEAP-MS-CHAPv2 is easier to deploy than other authentication methods, such as Extensible Authentication Protocol-Transport Layer Security (EAP-TLS). PEAP does not require the deployment of a public key infrastructure (PKI); only a Remote Authentication Dial-In User Service (RADIUS) server is required to provide a certificate. Additionally, PEAP does not require the deployment of an infrastructure, such as smart cards or another type of client certificates, to validate connecting clients.

Configuring a PEAP-MS-CHAP v2 wireless profile

This procedure provides the steps required to configure a PEAP-MS-CHAP v2 wireless profile.

To configure a PEAP-MS-CHAP v2 wireless profile

  1. In Windows Vista Wireless Network (IEEE 802.11) Policies Properties, on the General tab, do one of the following:

    • To add a new profile, click Add, and then select Infrastructure.

    • To modify an existing profile, select the profile, and then click Edit.

    Note

    For more information about the settings on any tab, press F1 while viewing that tab.

  2. On the Connection tab, do the following:

    1. In Profile Name, type a name for this wireless profile.

    2. In Network Name(s) (SSID), type the SSID that corresponds to the SSID configured on your wireless APs, and then click Add.

    3. If present, select NEWSSID, and then click Remove.

    4. If your wireless access point is configured to suppress its broadcast beacon, select Connect even if the network is not broadcasting.

      Note

      Enabling this option can create a security risk because wireless clients will probe for and attempt connections to any wireless network. By default, this setting is not enabled.

  3. Click the Security tab, click Advanced, and then configure the following:

    1. To configure advanced 802.1X settings, in IEEE 802.1X, select Enforce advanced 802.1X settings.

      Note

      When the advanced 802.1X settings are enforced, the default values for Max Eapol-Start Msgs, Held Period, Start Period, and Auth Period are sufficient for most wireless deployments.

    2. To enable Single Sign On, select Enable Single Sign On for this network.

      Note

      The remaining default values in Single Sign On are sufficient for most wireless deployments.

    3. In Fast Roaming, select This network uses pre-authentication, if your wireless AP is configured for pre-authentication.

  4. Click OK to return to the Security tab, and then configure the following:

    1. In Select the security methods for this network, for Authentication, select WPA2-Enterprise if it is supported by your wireless AP and wireless client network adapters. Otherwise, select WPA-Enterprise.

    2. In Encryption, select AES, if it is supported by your wireless AP and wireless client network adapters. Otherwise, select TKIP.

      Note

      The settings for both Authentication and Encryption must match the settings configured on your wireless AP. On the Security tab, the default settings for Authentication Mode, Max Authentication Failures, and Cache user information for subsequent connections to this network are sufficient for most wireless deployments.

  5. In Select a network authentication method, select Protected EAP (PEAP), and then click Properties. In the Protected EAP Properties dialog box, configure the following:

    1. Verify that Validate server certificate is selected.

    2. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your Network Policy server.

      Note

      This setting limits the trusted root CAs that clients trust to the selected values. If no trusted root CAs are selected, then clients will trust all trusted root CAs in their trusted root certification authority store.

    3. In the Select Authentication Method list, select Secured password (EAP-MS-CHAP v2).

    4. Select Enable Fast Reconnect.

    5. Clear Enable Quarantine checks.

  6. Click Configure. In the EAP MSCHAPv2 Properties dialog box, verify Automatically use my Windows logon name and password (and domain if any) is selected, click OK, and then click OK to close Protected EAP Properties.

  7. Click OK to close the Security tab.
Configuring an EAP-TLS wireless profile

This procedure provides the steps required to configure an EAP-TLS wireless profile.

To configure an EAP-TLS wireless profile

  1. In Windows Vista Wireless Network (IEEE 802.11) Policies Properties, on the General tab, click Add, and then select Infrastructure.

    Note

    For more information about the settings on any tab, press F1 while viewing that tab.

  2. On the Connection tab, do the following:

    1. In Profile Name, type a name for the EAP-based profile.

    2. In Network Name(s) (SSID), type the SSID that corresponds to the SSID configured on your wireless APs, and then click Add.

    3. If present, select NEWSSID, and then click Remove.

    4. If your wireless access point is configured to suppress its broadcast beacon, select Connect even if the network is not broadcasting.

      Note

      Enabling this option can create a security risk because wireless clients will probe for and attempt connections to any wireless network. By default, this setting is not enabled.

  3. Select the Security tab, click Advanced, and then configure the following:

    1. To configure advanced 802.1X settings, in IEEE 802.1X, select Enforce advanced 802.1X settings.

      Note

      When the advanced 802.1X settings are enforced, the default values for Max Eapol-Start Msgs, Held period, Start Period, and Auth Period are sufficient for most wireless deployments.

    2. In Single Sign On, select Enable Single Sign On for this network.

      Note

      The remaining default values in Single Sign On are sufficient for most wireless deployments.

    3. In Fast Roaming, select This network uses pre-authentication if your wireless AP is configured for pre-authentication.

  4. Click OK to return to the Security tab, and then configure the following:

    1. In Select the security methods for this network, for Authentication, select WPA2-Enterprise if it is supported by your wireless AP and wireless client network adapters. Otherwise, select WPA-Enterprise.

    2. In Encryption, select AES (preferred) if it is supported by your wireless AP and wireless client network adapters. Otherwise, select TKIP.

      Note

      The settings for both Authentication and Encryption must match the settings configured on your wireless AP. On the Security tab, the default settings for Authentication Mode, Max Authentication Failures, and Cache user information for subsequent connections to this network are sufficient for most wireless deployments.

  5. In Select a network authentication method, select Smart Card or other certificate (EAP-TLS). On the Security tab, click Properties, and then configure the following:

    1. In When connecting, verify that Use a certificate on this computer and Use simple certificate selection are selected.

    2. Verify that Validate server certificate is selected.

      In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your Network Policy Server (NPS).

      Note

      This setting limits the trusted root CAs that clients trust to the selected values. If no trusted root CAs are selected, then clients will trust all trusted root CAs in their trusted root certification authority store.

  6. Click OK to close Smart Card or other Certificate Properties, and then click OK again to close the EAP Profile.

Configuring connection preference order for wireless networks

Wireless clients running Windows Vista attempt to connect to wireless networks in the order specified in Windows Vista Wireless Policy. This procedure demonstrates how to specify the order of wireless profiles to which domain clients running Windows Vista will attempt to connect.

To specify the order of wireless networks

  1. Open the Windows Vista Wireless Network (IEEE 802.11) Policies Properties. On the General tab, in Connect to available networks in the order of profiles listed below, select any profile, then click the "up arrow" or the "down arrow" to move the profile to the desired location in the list.

  2. Click OK to save the change, and then close the Windows Vista Wireless Policy.

Defining network permissions

You can configure the following on the Network Permissions tab to specify network permissions:

  • To block your domain members running Windows Vista from gaining access to ad hoc networks, select Prevent connections to ad-hoc networks.

  • To block your domain members running Windows Vista from gaining access to infrastructure networks, select Prevent connections to infrastructure networks.

  • To allow your domain members running Windows Vista to view network types (ad hoc or infrastructure) to which they are denied access, select Allow user to view denied networks.

    Note

    The Remove button on the Network Permissions tab allows you to remove only those networks that you have defined by using the Add feature. Networks that are defined on the General tab, in Connect to available networks in the order of profiles listed below, cannot be removed from the permissions list.
Adding wireless networks to the Deny list

For a variety of reasons, you might want to block managed wireless computers from connecting to other wireless networks that are within range of the organization’s wireless network. For example, an adjoining building might have a wireless AP broadcasting, which can be seen on your network wireless client computers running Windows Vista.

This procedure demonstrates how to use the Windows Vista Wireless Network (IEEE 802.11) Policies to allow or deny permissions for wireless networks.

To add a wireless network to the Deny list

  1. Open the Windows Vista Wireless Policy.

  2. On the Network Permissions tab, click Add.

  3. On the New Permission Entry dialog box, configure the following:

    1. In Network Name (SSID) type the SSID of a wireless network.

    2. In Network Type, select Infrastructure or Ad-hoc.

      Note

      If you are unsure whether the broadcasting network is an infrastructure or ad hoc network, you can configure a network permission entry for both types.

    3. In Permission, select Deny.

  4. Click OK. On the Network Permissions tab, select Allow user to view denied networks, and then click OK.
To prevent users from viewing blocked networks

To prevent users from seeing broadcasting networks to which you want to deny access. This procedure demonstrates how to prevent your wireless clients from displaying wireless networks to which you have denied access.

To prevent users from viewing networks in the Deny list

  1. Open the Windows Vista Wireless Policy.

  2. On the Network Permissions tab, clear the Allow user to view denied networks check box, and then click OK.
Exporting wireless profiles

In addition to creating a backup of configured profiles, the export and import features are used to support independent hardware vendor (IHV) extensibility. An administrator can include IHV-specific connectivity or security settings in an Extensible Markup Language (XML) profile and then import this profile to wireless Group Policy. Because these settings do not display onscreen in Windows Vista, importing them is the only way that a profile can include these settings in wireless Group Policy.

This procedure demonstrates how to export a wireless profile.

To export a wireless profile

  1. In Windows Vista Wireless Network (IEEE 802.11) Policies Properties, on the General tab, in Connect to available networks in the order of profiles listed below, select the profile you want to export, and then click Export.

  2. In the Save exported profile as dialog box, verify that Save as type is (*.xml), and then click Save.

    Note

    By default, the profile is saved as an XML file in the Documents folder of the current user. The profile name is automatically provided in its file name. If you specify a different name for the exported file, such as "Backup.xml," when imported the profile will appear in "Connect to available networks" in the order of profiles listed below with the original profile name and the original SSID.
Importing a wireless profile

This procedure demonstrates how to import a wireless profile. You can use the import feature to restore profiles that have been deleted. You can also use the import feature to restore a profile that was changed after a backup copy was exported.

To import a wireless profile

  1. In Windows Vista Wireless Network (IEEE 802.11) Policies Properties, on the General tab, in Connect to available networks in the order of profiles listed below, click Import.

  2. In Import a profile, navigate to the profile that you want to import, and then click Open.

    Note

    By default, the Open to import a profile dialog box opens the most recent directory that has been accessed using the import and export features.

  3. Select the profile, and then click Open.


Deploy a CA and NPS Server Certificate

Deploy a CA and NPS server certificate

You can use these procedures to install Active Directory® Certificate Services (AD CS) and enroll a server certificate to servers running Network Policy Server (NPS). If you deploy certificate-based authentication, servers running NPS must have a server certificate. During the authentication process, these servers send their server certificate to client computers as proof of identity.

The process of configuring NPS server certificate enrollment occurs in three stages:

  • Install the AD CS server role. This step is required only if you have not already deployed a certification authority (CA) on your network.

  • Configure a server certificate template and autoenrollment. The CA issues certificates based on a certificate template, so you must configure the template for the NPS server certificate before the CA can issue a certificate. When you configure autoenrollment, all servers running NPS on your network will automatically receive a server certificate when Group Policy on the server running NPS is refreshed. If you add more servers later, they will automatically receive a server certificate, too.

  • Refresh Group Policy on servers running NPS. When Group Policy is refreshed, the servers running NPS receive two certificates. One certificate is the server certificate based on the template that you configured in the previous step. This certificate is used by NPS to prove its identity to client computers that attempt to connect to your network. The other certificate is the CA's certificate, which is automatically installed on the servers running NPS in the Trusted Root Certification Authorities certificate store. NPS uses this certificate to determine whether to trust certificates it receives from other computers. For example, if you deploy EAP-TLS, client computers use a certificate to prove their identities to the server running NPS. When the server receives a certificate from a client computer, trust for the certificate is established because the server running NPS finds the issuing CA certificate in its own Trusted Root Certification Authorities certificate store.

Rather than autoenrolling an NPS server certificate, you might want to enroll the certificate using one of the following methods:

  • Manually import a NPS server certificate from floppy disk or compact disc into the NPS certificate store.

  • Use the Certificate Services Web enrollment tool to obtain the NPS server certificate.

Because the NPS server certificate is a computer certificate, you must import the certificate into the certificate store for the Local Computer rather than for the Current User.

Caution

If the NPS server certificate is erroneously installed in the Current User certificate store, NPS cannot use the certificate for PEAP or EAP authentication because the certificate's private keys have an incorrectly configured access control list (ACL) that prevents key access by the local system. You can verify the location of the NPS server certificate by using the Certificates MMC snap-in. If the NPS server certificate is in the incorrect location, do not attempt to drag and drop the certificate from the Current User to the Local Computer certificate store. The private keys for the certificate will still have an incorrectly configured ACL. Instead, revoke the certificate using AD CS and issue a new server certificate to the server running NPS.

To deploy a CA and autoenroll NPS server certificates, perform the following procedures:

  • NPS Server Certificate: CA Installation

  • NPS Server Certificate: Configure the Template and Autoenrollment


Request a Certificate

Requesting certificates through the Certificates snap-in is a simple process that involves a few straightforward steps involving the Certificate Enrollment Wizard. You can request any type of certificate that has been preconfigured and made available by an administrator of the certification authority (CA) that will process the certificate request.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To request a certificate

  1. Open the Certificates snap-in for a user or computer.

  2. In the console tree, click Certificates - Current User or Certificates (Local Computer). Select the Personal certificate store.

  3. On the Action menu, point to All Tasks, and then click Request New Certificate to start the Certificate Enrollment Wizard. Click Next.

  4. Select the types of certificates that you want to request.

  5. You can click Details to review additional information about each certificate.

    If a caution symbol appears below the certificate, you might need to provide additional information before requesting that type of certificate. Click the More information is required to enroll for this certificate. Click here to configure message and provide the requested information, such as the location of a valid signing certificate.

  6. To finish, click Enroll.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC

  • You can use this procedure to request certificates from an enterprise certification authority only. To request certificates from a stand-alone CA, you need to request certificates by means of Web pages. A Windows CA has its Web pages located at http://servername/certsrv, where servername is the name of the server hosting the CA.

  • You can use this procedure to request certificates based on templates where the subject name is generated by Windows only. To request a certificate based on a template configured to obtain the subject name from the subject, you need to request certificates by means of Web pages.

  • If the requested certificate type requires approval before it is issued, you need to retrieve the completed certificate via Web pages. A Windows CA has its Web pages located at http://servername/certsrv, where servername is the name of the server hosting the CA.

  • In order to request a Digital Signature Standard (DSS) certificate from an enterprise CA, you must select the User Signature Only certificate template in the Certificate Request Wizard.

Additional references

  • Request Certificates Using the Certificate Request Wizard

  • Subject Names

  • Certificate Extensions


Add the Certificates Snap-in to an MMC

You can use the Certificates snap-in to manage certificates for a user, computer, or service account. To switch between managing certificates for your user account, a computer, or a service, you must add separate instances of the Certificates snap-in to the console.

Adding the Certificates Snap-in to an MMC

  • For a user account

  • For a computer account

  • For a service

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To add the Certificates snap-in to an MMC for a user account

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, double-click Certificates, and then:

    • If you are logged on as an administrator, click My user account, and then click Finish.

    • If you are logged on as a user, Certificates automatically loads.

  4. If you have no more snap-ins to add to the console, click OK.

  5. To save this console, on the File menu, click Save.

Additional considerations

  • User certificates can be managed by the user or by an administrator.

Local Administrators is the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To add the Certificates snap-in to an MMC for a computer account

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, double-click Certificates

  4. Select Computer account and then click Next.

  5. Do one of the following:

    • To manage certificates for the local computer, click Local computer, and then click Finish.

    • To manage certificates for a remote computer, click Another computer and type the name of the computer, or click Browse to select the computer name, and then click Finish.

  6. If you have no more snap-ins to add to the console, click OK.

  7. To save this console, on the File menu, click Save.

Additional considerations

  • To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

  • To manage certificates for another computer, you can either create another instance of Certificates in the console, or right-click Certificates (Computer Name), and then click Connect to Another Computer.

Local Administrators is the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To add the Certificates snap-in to an MMC for a service

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, double-click Certificates

  4. Select Service account and then click Next.

  5. Do one of the following:

    • To manage certificates for services on your local computer, click Local computer, and then click Next.

    • To manage certificates for service on a remote computer, click Another computer and type the name of the computer, or click Browse to select the computer name, and then click Next.

  6. Select the service for which you are managing certificates.

  7. Click Finish, and then click Close.

  8. If you have no more snap-ins to add to the console, click OK.

  9. To save this console, on the File menu, click Save.

Additional considerations

  • To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

  • To manage certificates for a service on another computer, you can either create another instance of Certificates in the console, or right-click Certificates - Service (Service Name) on Computer Name, and then click Connect to Another Computer.


View Certificate Properties

The Certificate Properties dialog box provides information and property selections for certificates and cross-certificates. It contains two tabs, General and Cross-Certificates, and can be accessed by right-clicking a certificate and selecting Properties.

  • Properties General Tab

  • Properties Cross-Certificates Tab


Modify the Online Responder Web Proxy

The Online Responder Web proxy cache represents the service interface for the Online Responder. It is implemented as an Internet Server Application Programming Interface (ISAPI) extension hosted by Internet Information Services (IIS), and it performs the following operations:

  • Request decoding. After a request is received by the Online Responder Web proxy, the decoder component will try to decode the request and extract the certificate serial number to be validated.

  • Response caching. After a request is received and a certificate serial number is extracted, the Online Responder Web proxy will check the local cache for a valid response. The cache item validity period is set by default to the certificate revocation list (CRL) validity period from which the response was generated.

You can modify the following Web proxy–related settings for an Online Responder:

  • Web proxy threads. This setting refers to the number of threads that will be allocated by the Online Responder ISAPI extension for handling requests. Increasing the number of threads will use more of the server's memory and reducing the number of threads will reduce the number of clients that can be served concurrently.

  • Cache entries allowed. The cache is implemented as part of the Online Responder's ISAPI extension and is an in-memory cache only. The recommended cache size is between 1,000 and 10,000 entries. The minimum cache entries allowed is five. A small cache size will cause more cache faults and will result in a higher load on the Online Responder service for lookup and signing operations; a large cache size will increase the Online Responder's memory usage.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To modify the Online Responder Web proxy

  1. Open the Online Responder snap-in, and select the Online Responder.

  2. Click Responder Properties on the Action menu, or click Responder Properties in the Action pane.

  3. Click the Web Proxy tab, modify the Web proxy options that you want to change, and then click OK.

Additional references

  • Managing Online Responders


Details Tab

Using the Certificates snap-in, you can view information about the fields, extensions, and properties that define an issued certificate by double-clicking any certificate displayed in the certificate store. The following fields, extensions, and properties can be viewed using Certificates:

The Details dialog box provides the following information about the certificate:

  • Version: The X.509 version number.

  • Serial number: The unique serial number that the issuing certification authority assigns to the certificate. The serial number is unique for all certificates issued by a given certification authority.

  • Signature algorithm: The hash algorithm that the certification authority uses to digitally sign the certificate.

  • Issuer: Information regarding the certification authority that issued the certificate.

  • Valid from: The beginning date for the period in which the certificate is valid.

  • Valid to: The final date for the period in which the certificate is valid.

  • Subject: The name of the individual, computer, device, or certification authority to whom the certificate is issued. If the issuing certification authority exists on a domain member server in your enterprise, this will be a distinguished name within the enterprise. Otherwise, this may be a full name and e-mail name or some other personal identifier.

  • Public key: The public key type and length associated with the certificate.

  • Thumbprint algorithm: The hash algorithm that generates a digest of data (or thumbprint) for digital signatures.

  • Thumbprint: The digest (or thumbprint) of the certificate data.

  • Friendly name: (Optional) A friendly, or common, name for the name in the Subject field.

  • Enhanced key usage: (Optional) The purposes for which this certificate can be used.

There are additional possible X.509v3 extensions that could be in a certificate. If they are present, they will be displayed as well.

Additional references

Certificate Validity Periods

Hash Algorithms

Cryptographic Service Providers

Guidelines for Using Alternate Signature Formats


Enable and Disable NAP Enforcement Clients

Enable and Disable NAP Enforcement Clients

You can use this procedure to enable or disable one or more NAP enforcement clients, including the DHCP enforcement client, the Remote Access enforcement client, the EAP enforcement client, the Internet Protocol security (IPsec) enforcement client, and the Terminal Services Gateway (TS Gateway) enforcement client, on NAP-capable computers.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To enable and disable NAP enforcement clients

  1. To open the NAP client configuration console, click Start, click All Programs, click Accessories, click Run, type NAPCLCFG.MSC, and click OK.

  2. Click Enforcement Clients. In the details pane, right-click the enforcement client that you want to enable or disable, and then click Enable or Disable.


Remove a Member from an Array

At times you may need to delete a member from an Array if the Array is no longer needed, has become corrupted, has been compromised, or is otherwise being reconfigured.

You must have Manage Online Responder permissions on all of the Online Responders in the Array to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To remove a member from an Array

  1. Open the Online Responder snap-in.

  2. In the console tree, click Array Configuration.

  3. Select the Array member that you want to delete.

  4. On the Action menu or in the Actions pane, click Delete Array Member.

Additional considerations

  • If the Array member that you want to delete is the Array controller, you must first designate a new Array controller for the Array before removing the former Array controller. For more information, see Designate a Controller for the Array.

Additional references

  • Managing an Online Responder Array


Renew OCSP Response Signing Certificates with an Existing Key

Online Certificate Status Protocol (OCSP) Response Signing certificates need to be signed by the same certification authority (CA) key that was used to sign the end-entity certificates that they provide status for.

After a CA key is renewed, the CA will be using the new key to sign newly issued certificates. In the period between the time a CA certificate is renewed and the expiration date of the original CA certificate, the CA cannot issue or renew OCSP Response Signing certificates, which may prevent an Online Responder from signing OCSP responses.

To overcome this issue, Windows Server 2008–based CAs can be configured to modify the default behavior and allow OCSP Response Signing certificates to be issued by using a renewed CA key.

You must be an administrator on the server hosting the CA to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To allow OCSP Response Signing certificates to be renewed by using existing CA keys

  1. On the CA computer, open a command prompt, and type:

    certutil -setreg ca\UseDefinedCACertInRequest 1

  2. Press ENTER.

  3. Restart the CA service.

Additional references

  • Managing Online Responders


Certificate Template Concepts

Certificate templates are an integral part of an enterprise certification authority (CA). They are an important element of the certificate policy for an environment, which is the set of rules and formats for certificate enrollment, use, and management.

When a CA receives a request for a certificate, groups of rules and settings must be applied to that request to perform the requested function, such as certificate issuance or renewal. These rules can be simple or complex and may apply to all users or specific groups of users. Certificate templates are the sets of rules and settings that are configured on a CA to be applied against incoming certificate requests. Certificate templates also give instructions to the client on how to create and submit a valid certificate request.

Certificates based on a certificate template can only be issued by an enterprise CA. The templates are stored in Active Directory Domain Services (AD DS) for use by every CA in the forest. This allows the CA to always have access to the current standard template and ensures consistent application of the certificate policy across the forest.

Administrators of Windows Server® 2008–based enterprise CAs can use a number of predefined certificate templates. For more information, see Default Certificate Templates.

Certificate templates introduced in Windows Server 2008, Windows Server 2003, and Windows 2000 have different levels of configurability. For more information, see Certificate Template Versions.


Display Archived Certificates

Archived certificates are certificates that have expired or have been renewed. In many cases, it is good practice to retain archived certificates instead of deleting them. For example, you would need to keep an archived certificate to verify digital signatures on old documents signed using the key on the now-expired or renewed certificate.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To display archived certificates

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Right-click the appropriate certificates container, click View, and then click Options.

  3. Under Show the following, select the Archived certificates check box, and then click OK.

  4. Click one of the certificate stores. In the right-hand column, Archived certificates are identified with an A attribute in the Status column.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


Configure 802.1X Wired Clients Running Windows Vista with Group Policy

Use the procedures in this topic to configure the Wired Network (IEEE 802.3) Policies for client computers running Windows Vista® that connect to your wired Ethernet network through 802.1X authenticating switches.

This document provides the detailed steps to create and configure the Wired Network (IEEE 802.3) Policies and wired configuration profile for computers running Windows Vista.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

Configure 802.1X Wired Clients by using Wired Network (IEEE 802.3) Policies

This document provides the detailed steps to add and configure the Wired Network (IEEE 802.3) Policies, and to configure a configuration profile for computers running Windows Vista. For example, you can configure a profile to use smart cards or Protected Extensible Authentication Protocol Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2), and enable Single Sign On for computers connecting to the wired network through an 802.1X authenticating switch.

Note

You can use the Windows Vista Wired Network (IEEE 802.3) Policies to configure computers running Windows Vista and Windows Server 2008. You cannot use this policy to configure computers running Windows XP. Computers running Windows XP cannot interpret settings in a Windows Vista Wired Network (IEEE 802.3) Policies.

You can use these features to configure security and authentication settings, manage wireless profiles, and specify permissions for wireless networks that are not configured as preferred networks.
Opening the Wired Network (IEEE 802.3) Policies properties

Use this procedure to access the Wired Network (IEE 802.3) Policy.

To open the Wired Network (IEEE 802.3) Policies properties

  1. Open the Group Policy Management Console (GPMC).

  2. In Default Domain Policy, open Computer Configuration, open Windows Settings, open Security Settings, and then select Wired Network (IEEE 802.3) Policies.

    • If there is an activated Windows Vista wired network policy in the details pane:

      Right-click the New Vista Wired Network Policy, and then click Properties, to access the properties of the wired network policy.

      Note

      The wired policy is not necessarily listed as New Vista Wired Network Policy in the details pane of the GPMC. If the default policy name was previously changed from New Vista Wired Network Policy to another name, the name change is reflected in the GPMC details pane.

    • If there is not an activated Windows Vista wired policy in the details pane:

      Right-click Wired Network (IEEE 802.3) Policies, and then click Create A New Windows Vista Policy to activate and open the New Vista Wired Network Policy Properties.

      Note

      After the Windows Vista Wired Policy is added, it is only listed in the GPMC details pane when Wireless Network (IEEE 802.11) Policies is selected.

Configure wired clients running Windows Vista by using the Wired Network (IEEE 802.3) Policies

This section contains procedures that will demonstrate the features provided in the Wired Network (IEEE 802.3) Policies for Windows Vista. You can use these features to configure security and authentication settings for computers running Windows Vista that are connecting to your network through an 802.1X authenticating switch.
Configuring a PEAP-MS-CHAP v2 profile

This procedure provides the steps required to configure a PEAP-MS-CHAP v2 profile.

To configure a profile for PEAP-MS-CHAP v2 wired connections

  1. On the General tab, do the following:

    1. In Policy Name, type a name for the wired network policy.

    2. In Description, type a brief description of the policy.

    3. Ensure that Use Windows Wired Auto Config service for clients is selected.

      Note

      For more information about the settings on any tab, press F1 while viewing that tab.

  2. On the Security tab, do the following:

    1. Select Enable use of IEEE 802.1X authentication for network access.

    2. In Select a network authentication method, select Protected EAP (PEAP).

    3. In Authentication mode, select User re-authentication.

    4. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed.

    5. To specify that user credentials are held in cache, select Cache user information for subsequent connections to this network.

  3. To configure Single Sign On or advanced 802.1X settings, click Advanced. On the Advanced tab, do the following:

    1. To configure advanced 802.1X settings, select Enforce advanced 802.1X settings, and then modify — only as necessary — the settings for: Max Eapol-Start Msgs, Held Period, Start Period, Auth Period, Eapol-Start Message.

    2. To configure Single Sign On, select Enable Single Sign On for this network, and then modify — as necessary — the settings for:

      Perform Immediately before User Logon

      Perform Immediately after User Logon

      Max delay for connectivity

      Allow additional dialogs to be displayed during Single Sign On

      Max delay with dialogs

      This network uses different VLAN for authentication with machine and user credentials

  4. Click OK. On the Security tab, click Properties.

  5. On the Protected EAP Properties dialog box, do the following:

    1. Select Validate server certificate.

    2. In Trusted Root Certification Authorities, select the Trusted Root Certification Authority (CA) that issued the server certificate to your Network Policy (NPS) Server.

      Note

      This setting limits the trusted root certification authorities (CAs) that clients trust to the selected values. If no trusted root CAs are selected, then clients will trust all trusted root CAs in their trusted root certification authority store.

    3. To specify that PEAP Fast Reconnect is enabled, select Enable Fast Reconnect.

    4. To specify that system health checks are preformed on clients to ensure they meet health requirements, before connections to the network are permitted, select Enable Quarantine checks.

    5. Click OK, to save the Protected EAP (PEAP) settings.

  6. Click OK to save the changes to the wired policy, and then close the Group Policy Management console.
Configuring a Smart Card or other certificate profile

This procedure provides the steps required to configure a PEAP-MS-CHAP v2 profile.

To configure a Smart Card or other certificate profile

  1. On the General tab, do the following:

    1. In Policy Name, type a name for the wired network policy.

    2. In Description, type a brief description of the policy.

    3. Ensure the user is notified that that Use Windows Wired Auto Config service for clients is selected.

      Note

      For more information about the settings on any tab, press F1 while viewing that tab.

  2. On the Security tab, do the following:

    1. Select Enable use of IEEE 802.1X authentication for network access.

    2. In Select a network authentication method, select Smart Card or other certificate.

    3. In Authentication mode, select User re-authentication.

    4. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed.

    5. To specify that user credentials are held in cache, select Cache user information for subsequent connections to this network.

  3. To configure Single Sign On or advanced 802.1X settings, click Advanced. On the Advanced tab, do the following:

    1. To configure advanced 802.1X settings, select Enforce advanced 802.1X settings, and then modify — only as necessary — the settings for: Max Eapol-Start Msgs, Held Period, Start Period, Auth Period, Eapol-Start Message.

    2. To configure Single Sign On, select Enable Single Sign On for this network, and then modify — as necessary — the settings for:

      Perform Immediately before User Logon

      Perform Immediately after User Logon

      Max delay for connectivity

      Allow additional dialogs to be displayed during Single Sign On

      Max delay with dialogs

      This network uses different VLAN for authentication with machine and user credentials

  4. Click OK. On the Security tab, click Properties.

  5. On the Smart Card or other Certificate Properties dialog box, configure the following:

    1. Select Validate server Certificate.

    2. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your Network Policy Server (NPS).

      Note

      This setting limits the trusted root CAs that clients trust to the selected values. If no trusted root CAs are selected, then clients will trust all trusted root CAs in their trusted root certification authority store.

    3. To specify that PEAP Fast Reconnect is enabled, select Enable Fast Reconnect.

    4. To specify that system health checks are preformed on clients to ensure they meet health requirements, before connections to the network are permitted, select Enable Quarantine checks.

    5. Click OK, to save the Protected EAP (PEAP) settings.

  6. Click OK to save the changes to the wired policy, and then close the Group Policy Management Console.


Network Policy Conditions Properties

Network policy conditions

Every network policy must have at least one configured condition. NPS provides many conditions groups that allow you to clearly define the properties that the connection request received by NPS must have in order to match the policy.

The available condition groups are:

  • Groups

  • HCAP

  • Day and time restrictions

  • Network Access Protection

  • Connection properties

  • RADIUS client properties

  • Gateway

Groups

Groups conditions specify user or computer groups that you configure in Active Directory Domain Services (AD DS) and to which you want the other rules of the network policy to apply when group members attempt to connect to the network.

  • Windows Groups

    Specifies that the connecting user or computer must belong to one of the specified groups.

  • Machine Groups

    Specifies that the connecting computer must belong to one of the specified groups.

  • User Groups

    Specifies that the connecting user must belong to one of the specified groups.

HCAP

Host Credential Authorization Protocol (HCAP) conditions are used only when you want to integrate your NPS Network Access Protection (NAP) solution with Cisco Network Admission Control. To use these conditions, you must deploy Cisco Network Admission Control and NAP. You must also deploy a HCAP server running both Internet Information Services (IIS) and NPS. For more information, see Host Credential Authorization Protocol.

Following are the HCAP conditions you can configure in network policy.

  • Location Groups

    Specifies the user's or computer's HCAP location group membership required to match this policy.

  • HCAP User Groups

    Specifies the user's HCAP user group membership required to match this policy.

Day and time restrictions

  • Day and Time Restrictions

    Allows you to specify, at a weekly interval, whether connections are allowed or denied on a specific set of days and times.

    For example, you can configure this condition to allow access to your network only between the hours of 8 A.M. and 5 P.M. Monday through Thursday. With this condition value, users whose connection requests match all conditions of the network policy cannot connect to the network on Fridays, Saturdays, Sundays, and during other weekdays between the hours of 5 P.M. and 8 A.M., but they can connect between Monday and Thursday between 8 A.M. and 5 P.M.

    Conversely, you can specify the days and times when connections to the network are denied. If you specify days and times when connections are denied, users are allowed access to your network on the unspecified days and times. For example, if you configure this condition to deny connections all day on Sunday, users cannot connect at any time on Sundays, but they can connect Monday through Saturday at any time.

    To configure the Day and Time Restrictions condition, obtain the properties of a network policy, click the Conditions tab, and then click Add. Scroll to and click Day and Time Restrictions, and then click Add. In Time of day constraints, click Permitted, click the grid pattern of days and times, and then use your mouse to select the days and times that you want to specify.

Note

You can designate specific days and times when network access is allowed only if you select Permitted. If you select Denied, network access is always denied.

Network Access Protection

Following are the NAP conditions that you can configure in network policy.

  • Identity Type

    Used for NAP DHCP and IPsec deployments to allow client health checks in circumstances where NPS does not receive an Access-Request message that contains a value for the User-Name attribute; in these circumstances, client health checks are performed but authentication and authorization are not performed.

RADIUS Access-Request messages typically include the User-Name attribute, which allows NPS to authenticate and authorize a connection request. When a value for the User-Name attribute is absent, NPS provides a default user name.

However, for scenarios such as NAP enforcement with DHCP or IPsec, where a client health check occurs without authentication or authorization (such as when a DHCP client renews an IP address lease) the User-Name attribute is not present and NPS does not provide a default user name.

When NPS receives a request for a client health check that does not include the User Name attribute and the Identity Type condition is configured with a value of Computer health check, the request matches the policy and, if all other conditions and constraints configured in the policy are also matched, the policy settings are applied.

In addition, in network policy constraints, you can enable the Perform machine health check only authentication method setting.

For more information, see Enable Client Health Checks for DHCP and IPsec NAP Deployments.

  • MS-Service Class

    Restricts the policy to clients that have received an IP address from a DHCP scope that matches the specified DHCP profile name. This condition is used only when you are deploying NAP with the DHCP enforcement method. To use the MS-Service Class attribute, in Specify the profile name that identifies your DHCP scope, type the name of an existing DHCP profile.

  • Health Policies

    Restricts the policy to clients that meet the health criteria specified in the health policy. For example, you might have two Health Policies that you have configured using the Windows SHV -- one health policy created for circumstances where client computers pass all health checks and one policy created for circumstances where client computers fail all health checks specified in the Windows SHV. If you select the health policy that designates that all client computers must pass all health checks, the SoH sent to NPS from NAP agent on the client computer must state that the client passed all health checks required by the Windows SHV in order for the conditions of the network policy to be met.

  • NAP-Capable Computers

    Restricts the policy to either clients that are capable of participating in NAP or clients that are not capable of participating in NAP. This capability is determined by whether the client sends a SoH to NPS.

  • Operating System

    Specifies the operating system (operating system version or service pack number), role (client or server), and architecture (x86, x64, or ia64) required for the computer configuration to match the policy.

  • Policy Expiration

    Specifies when the network policy expires; after the expiration date and time that you specify, the network policy is no longer evaluated by NPS. This condition is useful for circumstances where the network policy is designed with the NAP Enforcement setting that allows client computers full network access for a limited time. At the same time that the NAP Enforcement time setting expires, the network policy can also expire. In this circumstance, you should create a second network policy that enforces NAP after the expiration time of the first policy.

Connection properties

Following are the connection properties that you can configure in network policy.

  • Access Client IPv4 Address

    Specifies the IPv4 address of the access client that is required to match the conditions of the policy.

  • Access Client IPv6 Address

    Specifies the IPv6 address of the access client that is required to match the conditions of the policy.

  • Authentication Type

    Specifies the authentication methods that are required for the connection request to match the network policy.

  • Allowed EAP Types

    Specifies the EAP types that are required in order for the authentication method used by the client computer to match this policy. This condition is useful when connection request policy is configured with authentication. When authentication is configured in connection request policy, the authentication settings in network policy are overridden; however the use of the Allowed EAP Types condition causes NPS to verify the authentication method being used; if the specified EAP type is not being used, NPS does not use the network policy for authorization and continues to seek a policy whose conditions match the connection request.

  • Framed Protocol

    Restricts the policy to clients that specify a certain framing protocol for incoming packets, such as PPP or SLIP.

  • Service Type

    Restricts the policy to only clients specifying a certain type of service, such as Telnet or Point to Point Protocol connections.

  • Tunnel Type

    Restricts the policy to only clients that create a specific type of tunnel, such as PPTP or L2TP. The Tunnel Type attribute is typically used when you deploy virtual local area networks (VLANs). For more information, see VLAN Attributes Used in Network Policy.

RADIUS client properties

Following are the RADIUS client conditions that you can configure in network policy.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

  • Calling Station ID

    Specifies the network access server telephone number that was dialed by the dial-up access client.

  • Client Friendly Name

    Specifies the name of the RADIUS client that forwarded the connection request to the NPS server.

  • Client IPv4 Address

    Specifies the Internet Protocol (IP) version 4 address of the RADIUS client that forwarded the connection request to the NPS server.

  • Client IPv6 Address

    Specifies the Internet Protocol (IP) version 6 address of the RADIUS client that forwarded the connection request to the NPS server.

  • Client Vendor

    Specifies the name of the vendor or manufacturer of the RADIUS client that sends connection requests to the NPS server.

  • MS RAS Vendor

    Specifies the vendor identification number of the network access server that is requesting authentication.

Gateway

Following are the gateway properties that you can configure in network policy.

  • Called Station ID

    Allows you to specify the phone number of the network access server that sent the connection request to NPS. If you specify a NAS phone number and NPS receives a connection request from a NAS with a different phone number, the conditions of the policy are not met.

  • NAS Identifier

    Allows you to specify the name of the network access server that sent the connection request to NPS. If you specify a NAS name and NPS receives a connection request from a NAS with a different name, the conditions of the policy are not met.

  • NAS IPv4 Address

    Allows you to specify the IPv4 address of the network access server that sent the connection request to NPS. If you specify a NAS IPv4 address and NPS receives a connection request from a NAS with a different IPv4 address, the conditions of the policy are not met.

  • NAS IPv6 Address

    Allows you to specify the IPv6 address of the network access server that sent the connection request to NPS. If you specify a NAS IPv6 address and NPS receives a connection request from a NAS with a different IPv6 address, the conditions of the policy are not met.

  • NAS Port Type

    Allows you to specify the type of media used by the client computer to connect to the network. For example, if you specify Ethernet, the client computer must be accessing the network over the media type of Ethernet. If you specify a media type and the client computer is connecting to the network over a different media type, the conditions of the policy are not met. For example, if the designated media type is Wireless - IEEE 802.11 and the client computer is attempting to connect to the network with a media type of Virtual (VPN), the conditions of the policy are not met.


RADIUS Proxy

RADIUS proxy

Network Policy Server (NPS) can be used as a RADIUS proxy to provide the routing of RADIUS messages between RADIUS clients (access servers) and RADIUS servers that perform user authentication, authorization, and accounting for the connection attempt. When used as a RADIUS proxy, NPS is a central switching or routing point through which RADIUS access and accounting messages flow. NPS records information in an accounting log about the messages that are forwarded.

The following illustration shows NPS as a RADIUS proxy between RADIUS clients (access servers) and either RADIUS servers or another RADIUS proxy.

NPS as a RADIUS proxy

When NPS is used as a RADIUS proxy between a RADIUS client and a RADIUS server, RADIUS messages for network access connection attempts are forwarded in the following way:

  1. Access servers, such as dial-up network access servers, virtual private network (VPN) servers, and wireless access points, receive connection requests from access clients.

  2. The access server, configured to use RADIUS as the authentication, authorization, and accounting protocol, creates an Access-Request message and sends it to the NPS server that is being used as the NPS RADIUS proxy.

  3. The NPS RADIUS proxy receives the Access-Request message and, based on the locally configured connection request policies, determines where to forward the Access-Request message.

  4. The NPS RADIUS proxy forwards the Access-Request message to the appropriate RADIUS server.

  5. The RADIUS server evaluates the Access-Request message.

  6. If required, the RADIUS server sends an Access-Challenge message to the NPS RADIUS proxy, where it is forwarded to the access server. The access server processes the challenge with the access client and sends an updated Access-Request to the NPS RADIUS proxy, where it is forwarded to the RADIUS server.

  7. The RADIUS server authenticates and authorizes the connection attempt.

  8. If the connection attempt is both authenticated and authorized, the RADIUS server sends an Access-Accept message to the NPS RADIUS proxy, where it is forwarded to the access server.

    If the connection attempt is either not authenticated or not authorized, the RADIUS server sends an Access-Reject message to the NPS RADIUS proxy, where it is forwarded to the access server.

  9. The access server completes the connection process with the access client and sends an Accounting-Request message to the NPS RADIUS proxy. The NPS RADIUS proxy logs the accounting data and forwards the message to the RADIUS server.

  10. The RADIUS server sends an Accounting-Response to the NPS RADIUS proxy, where it is forwarded to the access server.

You can use NPS as a RADIUS proxy when:

  • You are a service provider who offers outsourced dial, VPN, or wireless network access services to multiple customers. Your network access servers send connection requests to the NPS RADIUS proxy. Based on the realm portion of the user name in the connection request, the NPS RADIUS proxy forwards the connection request to a RADIUS server that is maintained by the customer and can authenticate and authorize the connection attempt. For more information, see Realm Names.

  • You want to provide authentication and authorization for user accounts that are not members of either the domain in which the NPS server is a member or another domain that has a two-way trust with the domain in which the NPS server is a member. This includes accounts in untrusted domains, one-way trusted domains, and other forests. Instead of configuring your access servers to send their connection requests to an NPS RADIUS server, you can configure them to send their connection requests to an NPS RADIUS proxy. The NPS RADIUS proxy uses the realm name portion of the user name and forwards the request to an NPS server in the correct domain or forest. Connection attempts for user accounts in one domain or forest can be authenticated for network access servers in another domain or forest.

    NPS supports authentication across forests without a RADIUS proxy when the two forests contain only domains that consist of domain controllers running Microsoft® Windows Server® 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. The forest functional level must be Windows Server 2003, and there must be a two-way trust relationship between forests. If you use EAP-TLS with certificates as your authentication method, however, you must use a RADIUS proxy for authentication across forests that consist of Windows Server 2003 domains.

  • You want to perform authentication and authorization by using a database that is not a Windows account database. In this case, connection requests that match a specified realm name are forwarded to a RADIUS server, which has access to a different database of user accounts and authorization data. Examples of other user databases include Novell Directory Services (NDS) and Structured Query Language (SQL) databases.

  • You want to process a large number of connection requests. In this case, instead of configuring your RADIUS clients to attempt to balance their connection and accounting requests across multiple RADIUS servers, you can configure them to send their connection and accounting requests to an NPS RADIUS proxy. The NPS RADIUS proxy dynamically balances the load of connection and accounting requests across multiple RADIUS servers and increases the processing of large numbers of RADIUS clients and authentications per second.

  • You want to provide RADIUS authentication and authorization for outsourced service providers and minimize intranet firewall configuration. An intranet firewall is between your perimeter network (the network between your intranet and the Internet) and intranet. By placing a NPS server on your perimeter network, the firewall between your perimeter network and intranet must allow traffic to flow between the NPS server and multiple domain controllers. When replacing the NPS server with an NPS proxy, the firewall must allow only RADIUS traffic to flow between the NPS proxy and one or multiple NPS servers within your intranet.

See Also

  • Planning RADIUS Proxy Deployment


NAP Enforcement for IPsec Communications

NAP enforcement for IPsec communications

Network Access Protection (NAP) enforcement for Internet Protocol security (IPsec) policies for Windows Firewall is deployed with a health certificate server, a Health Registration Authority (HRA) server, a server running NPS, and an IPsec enforcement client. The health certificate server issues X.509 certificates to NAP clients when they are determined to be compliant. These certificates are then used to authenticate NAP clients when they initiate IPsec communications with other NAP clients on an intranet.

IPsec enforcement confines the communication on your network to compliant clients, and provides the strongest implementation of NAP. Because this enforcement method uses IPsec, you can define requirements for secure communications on a per-IP address or per-TCP/UDP port number basis.

Requirements

To deploy NAP with IPsec and HRA, you must configure the following:

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Enable the NAP IPsec enforcement client and the NAP service on NAP-capable client computers.

  • Install HRA on the local computer or on a remote computer.

  • Install and configure Active Directory® Certificate Services (AD CS) and Certificate Templates.

  • Configure Group Policy and any other settings required for your deployment.

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

If HRA is not installed on the local computer, you must also configure the following:

  • Install NPS on the computer that is running HRA.

  • Configure NPS on the remote HRA NPS server as a RADIUS proxy to forward connection requests to the local NPS server.

For more information about HRA, open the HRA console and press F1 to access the HRA Help content.


Configure Certificate Publishing in Active Directory Domain Services

A Windows Server–based certification authority (CA) can add certificates that have been issued to Active Directory subjects to the appropriate Active Directory object. This provides other users of Active Directory Domain Services (AD DS) with the ability to easily locate and use the subject's certificate. There are two settings (located on the General tab of the Template Properties dialog box) that affect the way this feature works:

  • Publish certificate in Active Directory. When a subject obtains a certificate based on this template, the issued certificate will be added to that subject's Active Directory object.

  • Do not automatically re-enroll if a duplicate certificate exists in Active Directory. When the subject attempts to enroll for a certificate based on this template, computers running Windows XP or later will check to see if a duplicate certificate exists in AD DS. If one does exist, autoenrollment will not submit a re-enrollment request. This allows certificates to be renewed but prevents multiple duplicate certificates from being issued.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure certificate publishing in AD DS

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. On the General tab, select the check box for the appropriate Active Directory setting, and then click Apply.

Additional references

  • Issuing Certificates Based on Certificate Templates


Remediation Server Groups

Remediation server groups

A remediation server group is a list of servers on the restricted network that provide resources required to bring noncompliant NAP-capable clients into compliance with administrator-defined client health policy.

A remediation server hosts the updates that NAP agent can use to bring noncompliant client computers into compliance with health policy, as defined in Network Policy Server (NPS). For example, a remediation server can host antivirus signatures. If health policy requires that client computers have the latest antivirus definitions installed, an antivirus system health agent (SHA), an antivirus system health validator (SHV), an antivirus policy server, and the remediation server used to host the antivirus signatures work together to update noncompliant computers.

See Also

  • Configure Remediation Server Groups


Submit a Basic User Certificate Request over the Web

Each CA that is installed on a computer running Windows Server 2003 has Web pages that users can access to submit basic and advanced certificate requests. By default, these pages are located at https://servername/certsrv, where servername is the name of the server hosting the Web pages.

Important

Windows Server 2003 CA Web pages must be updated before users can access these Web pages by using this version of Windows.

When you request certificates from a Windows-based stand-alone CA, you use the Certificate Services Web pages. Web pages can also be used to request certificates from enterprise CAs if you want to set optional request features that are not available in the Certificate Request Wizard, such as marking the keys as exportable, setting key length, choosing the hash algorithm, or saving the request to a file.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To submit a user certificate request over the Web

  1. Open Internet Explorer.

  2. In Internet Explorer, connect to https://servername/certsrv, where servername is the name of the server hosting the Web pages.

  3. Click Request a certificate.

  4. On Request a Certificate, select the type of certificate you want:

    1. If the CA is an enterprise CA, click User Certificate.

    2. If the CA is a standalone CA, select either Web Browser Certificate or E-Mail Protection Certificate.

  5. On the Identifying Information page, enter your identifying information for the certificate request, if needed.

  6. (Optional) Click More Options to specify the cryptographic service provider (CSP) and whether you want to enable strong private key protection. (This means that you will receive a prompt every time that the private key associated with the certificate is used.)

  7. Click Submit.

  8. Do one of the following:

    • If you see the Certificate Pending Web page, see Related Topics below for the procedure to check on a pending certificate.

    • If you see the Certificate Issued Web page, click Install this certificate.

  9. If you are finished using the Web pages, close Internet Explorer.

Additional considerations

  • In order for a user to obtain a certificate using Web enrollment, an administrator must set the appropriate permissions on the certificate templates on which the requested certificate is based.

  • If this is the first time you are accessing the Web server for a CA, you must add the server to the list of Trusted sites in Internet Explorer. Trusted sites can be added by selecting Internet Options on the Tools menu, clicking the Security tab, selecting the Trusted sites zone, and clicking Sites. In addition, the Web server for the CA must be configured to use HTTPS authentication.

Additional references

  • Request a Certificate Over the Web

  • Check on a Pending Certificate Request


Certificate Template General Properties

The General Properties tab contains validity and renewal information for certificates that will be issued based on a certificate template.

The default validity and renewal period settings for certificates issued by Active Directory Certificate Services (AD CS) are designed to meet most security needs. However, you might want to specify different validity and renewal settings, such as shorter lifetime or renewal periods for certificates that are used by certain user groups.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To modify the validity or renewal period for a certificate template

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. On the General tab, check the current validity period and renewal period values, modify them as needed, and then click Apply.

The Publish certificate in Active Directory option determines whether information about the certificate template will be made available throughout the enterprise.

The Do not automatically re-enroll if a duplicate certificate exists in Active Directory option is applied when the subject attempts to enroll for a certificate based on this template from a computer running Windows XP or later. With this option, certificate autoenrollment will not submit a re-enrollment request if a duplicate certificate exists in Active Directory Domain Services (AD DS). This allows certificates to be renewed but prevents multiple duplicate certificates from being issued.

The Smart card certificate keys option enables the existing key to be used if a new key cannot be created during renewal of a smart card certificate. This option helps prevent smart card certificate renewal failures that could result when a smart card runs out of disk space.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure certificate publishing in AD DS

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. On the General tab, select the appropriate Active Directory setting, and then click Apply.

Additional references

  • Configuring a Certificate Template


Enroll for Certificates on Behalf of Other Clients

It is not always possible for users to enroll for a certificate on their own behalf. This can be the case for a user smart card certificate. By default, only domain administrators are granted permission to request a certificate on behalf of another user. However, a user other than a domain administrator can be granted permission to become an enrollment agent. A user becomes an enrollment agent by enrolling for an Enrollment Agent certificate.

Important

Once someone has an Enrollment Agent certificate, that person can enroll for a certificate and generate a smart card on behalf of anyone in the organization. The resulting smart card could then be used to log on to the network and impersonate the real user. Because of the powerful capability of the Enrollment Agent certificate, it is strongly recommended that your organization maintain very strong security policies over who has one.

Membership in the Users group and an Enrollment Agent certificate are the minimum requirements to complete this procedure. Review the details in "Additional considerations" in this topic.

To enroll for a certificate on behalf of other users

  1. Open the Certificates snap-in for a user.

  2. Confirm that you are in Logical Stores View.

  3. In the console tree, expand the Personal store, and then click Certificates.

  4. On the Action menu, point to All Tasks, select Advanced Operations, and then click Enroll on behalf of to open the Certificate Enrollment Wizard. Click Next.

  5. Browse to the Enrollment Agent certificate that you will use to sign the certificate request that you are processing. Click Next.

  6. Select the type of certificate that you want to enroll for. When you are ready to request a certificate, click Enroll.

  7. After the Certificate Renewal Wizard has successfully finished, click Close.

Additional considerations

  • User certificates can be managed by a user or by an administrator. To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC

Additional references

  • Obtain a Certificate

  • Registration Authorities


Certificate Path Validation

As certificate use for secure communication and data protection is increasing, administrators can use certificate trust policy to enhance their control of certificate use and public key infrastructure performance by using certificate path validation options.

Certificate Path Validation settings in Group Policy allow administrators to:

  • Manage Trusted Root Certificates. This controls which root CA certificates and peer trust certificates in the user certificate and root certificate stores can be trusted.

  • Manage Trusted Publishers. This controls which code signing (Authenticode®) certificates can be accepted for use in the organization and blocks certificates that are not trusted according to policy

  • Manage Network Retrieval and Path Validation. This can compensate for situations where downloads of a certificate revocation list (CRL) fail because the CRL is too large, and network conditions are less than optimal.

  • Manage Revocation Checking Policy. Coordinates use of certificate revocation lists and online responders during revocation checking. This option also allows an administrator to extend the lifetime of responses received from an online responder or CRL.


Check on a Pending Certificate Request

When you submit a certificate request to a Windows-based enterprise CA, it is immediately processed and will either immediately fail or be granted, unless the certificate template has been configured to require approval by a certificate manager.

When you submit a certificate request to a Windows-based stand-alone CA, it will either be immediately processed or, by default, it will be considered pending until the administrator of the CA approves or rejects the request. In the case of a pending request, the certificate requester will have to use the Certificate Services Web pages to check the status of pending certificates.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To check on a pending certificate request

  1. Open Internet Explorer.

  2. In Internet Explorer, open https://servername/certsrv, where servername is the name of the Web server running Windows Server 2003 where the certification authority (CA) you want to access is located.

  3. Click View the status of a pending certificate request.

  4. If there are no pending certificate requests, you will see a message to that effect. Otherwise, select the certificate request you want to check, and then click Next.

  5. Check the pending certificate requests:

    • Still pending. You must wait for the administrator of the CA to issue the certificate. To remove the certificate request, click Remove.

    • Issued. To install the certificate, click Install this certificate.

    • Denied. Contact the administrator of the CA for further information.

  6. If you are finished using the Certificate Services Web pages, close Internet Explorer.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

If this is the first time you are accessing the Web server for a CA, you must add the server to the list of Trusted sites in Internet Explorer. Trusted sites can be added by selecting Internet Options on the Tools menu, clicking the Security tab, selecting the Trusted sites zone, and clicking Sites. In addition, the Web server for the CA must be configured to use HTTPS authentication.

Additional references

  • Request a Certificate Over the Web


Network Access Quarantine Control and NAP

Network Access Quarantine Control and NAP

Network Access Quarantine Control (NAQC) allows you to verify the configuration of client computers that are connecting to a server running Routing and Remote Access only at the moment when the access client is connecting to the network. The configuration of the client computer is verified by a script created by your organization administrator.

Network Access Protection (NAP) is a client health policy creation, enforcement, and remediation technology that is included in Windows Vista® and Windows Server® 2008. With NAP, you can establish health policies that define such things as software requirements, security update requirements, and required configuration settings for computers that connect to your network. The use of NAP rather than NAQC is recommended.

Important

If you deploy both NAP and NAQC on your network, you must create separate network policies. If you configure one network policy with both NAP settings and NAQC attributes, such as a Quarantine IP Filter and a Quarantine Session Timer, NPS applies NAQC settings rather than NAP settings.

The following table lists the differences between NAP and NAQC.

Feature | Available with NAP? | Available with NAQC?
Can deploy with VPN (Routing and Remote Access) | Yes | Yes
Can deploy with Internet Protocol security (IPsec) and Health Registration Authority (HRA) | Yes | No
Can deploy with 802.1X wired and wireless | Yes | No
Can deploy with Terminal Services Gateway (TS Gateway) | Yes | No
Can deploy with DHCP | Yes | No
Provides ongoing monitoring of client computer | Yes | No; client configuration is checked once, when client attempts network access
Provides integrated automatic remediation of noncompliant computers | Yes | No
Requires administrator to write script to check client configuration | No | Yes

See Also

  • Network Access Quarantine Control
  • Deploying Network Access Quarantine Control
  • Network Access Protection in NPS


Properties Cross-Certificates Tab

Cross-certificates are used to establish trust between separate certification hierarchies, such as in separate networks or portions of a network. In these cases, cross-certificates are typically configured to:

  • Define the namespaces for which certificates issued in one certification hierarchy can be used and accepted in the second hierarchy.

  • Specify the acceptable uses of certificates issued by a cross-certified CA.

  • Define the issuance practices that must be followed for a certificate issued by the cross-certified CA in order for them to be considered valid in the other hierarchy

  • Create a managed trust between separate certification hierarchies.

The Cross-Certificates tab can be used to add Cross-certificate download locations and to increase or decrease the interval between downloads of cross-certificates.

When cross-certificates are used, the information contained on the Cross-certificates tab describes which of these types of restrictions, if any, have been applied.

Cross certificates can be used in both intranet and extranet environments.


Key Usage

A certificate enables the subject to perform a specific task. To help control the usage of a certificate outside its intended purpose, restrictions are automatically placed on certificates. These restrictions can be applied by using the key usage extension.

Key usage is a restriction method that determines what a certificate can be used for. This allows the administrator to issue certificates that can only be used for specific tasks or certificates that be used for a broad range of functions. Key usage descriptions include "Digital signature" and "Allow key exchange only with key encryption."

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To modify key usage

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. On the Extensions tab, click Key Usage, and then click Edit.

  4. Select the key usage options that you want to add or remove, and then click OK twice.

    Note

    Not all key usage options can be modified on all certificate templates.

Certificate usage can also be managed by using the application policy extension. For more information, see Application Policy.

Additional references

  • Certificate Template Extensions


Create policies for 802.1X Wired or Wireless with a Wizard

Create policies for 802.1X wired or wireless with a wizard

You can use this procedure to create the connection request policies and network policies required to deploy either 802.1X authenticating switches or 802.1X wireless access points as RADIUS clients to the Network Policy Server (NPS) RADIUS server.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

This procedure explains how to start the New IEEE 802.1X Secure Wired and Wireless Connections wizard in Network Policy Server (NPS).

After you run the wizard, the following policies are created:

  • One connection request policy

  • One network policy

Running the New IEEE 802.1X Secure Wired and Wireless Connections wizard is not the only step required to deploy 802.1X authenticating switches and wireless access points as RADIUS clients to the NPS server. Both network access methods require that you deploy additional hardware and software components.

Note

You can run the New IEEE 802.1X Secure Wired and Wireless Connections wizard every time you need to create new policies for 802.1X access.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To create policies for 802.1X wired or wireless with a wizard

  1. Open the NPS console. If it is not already selected, click NPS (Local). If you are running the NPS MMC snap-in and want to create policies on a remote NPS server, select the server.

  2. In Getting Started and Standard Configuration, use the combination box to select RADIUS server for 802.1X Wireless or Wired Connections. The text and links below the text change to reflect your selection.

  3. Click Configure 802.1X using a wizard. The New IEEE 802.1X Secure Wired and Wireless Connections wizard opens.


View Certificate Revocation List Details

Certificate revocation lists (CRLs) are used to distribute information about revoked certificates to individuals, computers, and applications attempting to verify the validity of certificates.

The Revocation List tab lists the serial numbers of certificates that have been revoked and the date they were revoked. The Revocation entry field may also provide information about the reason a certificate was revoked.

The General tab provides additional information about the CRL itself, including the CA that issued the CRL, when the CRL was issued, the date the next CRL will be issued, and the name of the CRL Distribution Point (CDP).


NAP Clients

NAP Clients

You can use the topics in the following sections to configure NAP-capable client computers for use with Network Access Protection (NAP).

  • 802.1X Client Configuration with Group Policy

  • Enable Security Center in Group Policy

  • Enable the Network Access Protection Service on Clients

  • Enable and Disable NAP Enforcement Clients


Understanding How to Configure Health Policy

Understanding how to configure health policy

Network Access Protection (NAP) enforcement is accomplished by Network Policy Server (NPS) on a per-network policy basis. That is, you can create network policies that enforce NAP and you can create network policies that do not enforce NAP. In addition, you can create network policies that enforce NAP in different ways and for different NAP enforcement methods.

To configure NPS to enforce client health policies, you must configure the following:

  • System health validators (SHVs), which contain the settings that you can choose to enforce or not enforce. For example, in the Windows Security Health Validator (WSHV), you can choose whether to enforce client computer use of a firewall, antivirus software, and other settings.

  • Health policies, which contain the SHVs that you want to enforce with the health policy.

  • Network policy, which you create by adding one or more SHVs to the health policy. You can add the health policy to the network policy and enable NAP enforcement in the policy.

The basic steps for creating a network policy that enforces NAP are:

  • If required for your network configuration, install SHVs from other companies. Also install the corresponding system health agents (SHAs) on client computers.

  • Configure the SHVs that you want to use, whether they are non-Microsoft SHVs or the WSHV, which is included in Windows Server® 2008.

  • Add SHVs to a new or existing health policy.

  • Create a new network policy or open an existing policy.

  • In network policy conditions, add the health policy to the network policy.

Planning a network policy that enforces NAP

If you need a network policy that enforces NAP, you must determine:

  • The type of network access server, or RADIUS client, that the NAP-capable client computer uses to connect to the network.

  • The NAP enforcement client you want to use. The NAP enforcement client that you choose must match the connection method that the client uses to access the network. For example, if you deploy NAP with the DHCP enforcement method, you must use the DHCP enforcement client.

  • The Windows groups that contain the users and computers that you want to authorize to access your network.

  • The SHAs that are installed on the client computers and SHVs that are installed on the NPS server. These NAP components must be installed before you configure and enable a network policy that enforces a client health policy using the SHV.

See Also

  • NAP Components
  • Windows Security Health Validator


VLAN Attributes Used in Network Policy

VLAN attributes used in network policy

When you use network hardware, such as routers, switches, and access controllers that support virtual local area networks (VLANs), you can configure Network Policy Server (NPS) network policy to instruct the access servers to place members of Active Directory® groups on VLANs.

Before configuring network policy in NPS for VLANs, create groups of users in Active Directory Domain Services (AD DS) that you want to assign to specific VLANs. Then when you run the New Network Policy wizard, add the Active Directory group as a condition of the network policy.

You can create a separate network policy for each group that you want to assign to a VLAN. For more information, see Create a Group for a Network Policy.

When you configure network policy for use with VLANs, you must configure the RADIUS standard attributes Tunnel-Medium-Type, Tunnel-Pvt-Group-ID, and Tunnel-Type. Some hardware vendors also require the use of the RADIUS standard attribute Tunnel-Tag.

To configure these attributes in a network policy, use the New Network Policy wizard to create a network policy. You can add the attributes to the network policy settings while running the wizard or after you have successfully created a policy with the wizard.

Note

To add the attributes after you have created the network policy with the wizard, locate the policy in the NPS console and double-click the policy to open it. Click the Settings tab in the policy properties, ensure that RADIUS Attributes - Standard is selected, and then click Add. In the Add Attribute dialog box, add the following attributes.

  • Tunnel-Medium-Type. Select a value appropriate to the previous selections you made while running the New Network Policy wizard. For example, if the network policy you are configuring is a wireless policy, in Attribute Value, select 802 (Includes all 802 media plus Ethernet canonical format).

  • Tunnel-Pvt-Group-ID. Enter the integer that represents the VLAN number to which group members will be assigned. For example, if you want to create a Sales VLAN for your sales team by assigning team members to VLAN 4, type the number 4.

  • Tunnel-Type. Select the value Virtual LANs (VLAN).

  • Tunnel-Tag. Some hardware devices do not require this attribute. If your hardware device requires this attribute, obtain this value from your hardware documentation.

For more information, see Add a Network Policy.


Allow Subjects to Request a Certificate Based on a Template

Certificates can be made available to users for enrollment as users need them. This would require users to use the Certificate Request Wizard to request a certificate based on a certificate template. Before they can use the Certificate Request Wizard to obtain a certificate, you must enable the certificate template for these operations.

To properly configure subject enrollment, the administrator must plan the appropriate certificate template or templates to use. Several settings in the certificate template directly affect the behavior of certificate enrollment. For more information on these settings, see:

  • Issuance Requirements

  • Application Policy

  • Key Usage

  • Supersede Templates

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To allow subjects to request a certificate that is based on a template

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. On the Security tab, add the groups, computers, or users from which you want to allow certificate requests.

  4. In Group or user names, click one of the new objects, and then, on Permissions for ObjectName, under the Allow column, select the Read and Enroll check boxes.

  5. Repeat the previous step for each new object.

Additional references

  • Issuing Certificates Based on Certificate Templates


Connect to a Writable Domain Controller

If you have multiple domain controllers, all certificate templates may not be replicated on all domain controllers, including read-only domain controllers.

Note

Read-only domain controllers, introduced in Windows Server® 2008, are domain controllers that host a read-only copy of the domain database.

You can, however, retrieve or modify certificate templates from a specific writable domain controller.

Membership in Domain Admins or Enterprise Admins, or equivalent for the domain, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To access certificate templates on a writable domain controller

  1. Open the Certificate Templates snap-in.

  2. In the console tree, right-click Certificate Templates, and then click Connect to another writable domain controller.

  3. Verify the domain name, and click OK.

Additional references

  • Managing Certificate Templates

  • Configure Certificate Publishing in Active Directory Domain Services


Properties General Tab

The General tab can be used to provide a Friendly name and Description that can be used to differentiate between two certificates that are nearly identical, such as two unique signing certificates.

You can also use the General tab to Enable, Disable specific purposes or uses for the certificate.

Note

You can only add purposes that are permitted under the guidelines and restrictions imposed when the certificate was first issued.


Managing an Online Responder Array

When multiple Online Responders are used, they need to be organized into a logical framework called an Online Responder Array. Because Online Responders are designed to respond to individual certificate status requests, an Online Responder Array helps distribute status requests among multiple, geographically dispersed Online Responders.

One Online Responder in the Array must be designated as the Array controller. The configuration information for the Array controller determines the configuration options on other members of the Array.

Setting up an Array requires advance planning based on the following:

  • The number and location of the certification authorities (CAs) being supported by the Array.

  • The number of clients who will request certificates from the CAs and their locations.

  • The network connectivity between clients, CAs, and potential Online Responders.

  • The volume of certificate enrollments, certificate revocations, and certificate status requests that the organization's public key infrastructure (PKI) handles.

  • The need for redundancy in case individual Online Responders become unavailable.

Additional references

  • Checklist: Create an Online Responder Array

  • Add Array Members

  • Designate a Controller for the Array

  • Synchronize Members with an Array Configuration

  • Assess Array Member Status

  • Remove a Member from an Array


Cryptographic Service Providers

A cryptographic service provider (CSP) is the program that performs authentication, encoding, and encryption services that Windows-based applications access through the Microsoft Cryptography application programming interface (CryptoAPI). Each CSP provides a different implementation of the CryptoAPI. Some provide stronger cryptographic algorithms, while others use hardware components, such as smart cards.

What is a cryptographic service provider?

When you generate a request for a new certificate, the information in that request is first passed from the requesting program to CryptoAPI. CryptoAPI passes the proper data to a CSP that is installed on your computer or on a device that is accessible to your computer. If the CSP is software-based, it generates a public key and a private key, often referred to as a key pair, on your computer. If the CSP is hardware-based, such as a smart card CSP, it instructs a piece of hardware to generate the key pair.

After the keys are generated, a software-based CSP encrypts and then secures the private key. A smart card CSP stores the private key on a smart card. The smart card then controls access to the key.

The public key is sent to the certification authority, along with the certificate-requester information. After the CA verifies the certificate request according to its policies, it uses its own private key to create a digital signature in the certificate and then issue it to the requester. The CA presents the certificate to the certificate requester along with the option to install it in the appropriate certificate store on the computer or hardware device.

For more information, see Request a Certificate.

For more information, see Guidelines for Using Alternate Signature Formats.


Network Policy Constraints Properties

Network policy constraints

Constraints are additional network policy parameters that are optional. Constraints differ from network policy conditions in one substantial way: when a condition does not match a connection request, NPS continues to evaluate other configured network policies in search of a match for the connection request, but when a constraint does not match a connection request, NPS does not evaluate additional network policies; NPS rejects the connection request and the user or computer is denied network access.

Following are the constraints that you can configure in network policy.

  • Authentication methods

    Allows you to specify the authentication methods that are required for the connection request to match the network policy.

  • Idle timeout

    Allows you to specify the maximum time, in minutes, that the network access server can remain idle before the connection is disconnected.

  • Session timeout

    Allows you to specify the maximum amount of time, in minutes, that a user can be connected to the network.

  • Called station ID

    Allows you to specify the telephone number of the dial-up server that clients are allowed to use to access the network.

  • Day and time restrictions

    Allows you to specify when users are allowed to connect to the network.

  • NAS port type

    Allows you to specify the access media types that are allowed for users to connect to the network.


Make Issuance or Application Policy Critical

An object identifier must describe every application and issuance policy that you define. The inclusion of an issuance policy object identifier in an issued certificate indicates that the certificate was issued in a manner that meets the issuance requirements associated with the issuance policy object.

Issuance or application policies by default are not critical. Making them critical can help ensure that a certificate is not used improperly. However, it also increases the likelihood that the certificate may not be compatible with all applications.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To make issuance or application policy critical

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. On the Extensions tab, click Issuance Policies or Application Policies, and then click Edit.

  4. Select the Make this extension critical check box.

  5. Click OK.

Additional considerations

  • Clients must be re-enrolled to receive a certificate based on the changed template if they already have a valid certificate based on the old template. For more information, see Re-Enroll All Certificate Holders.

Additional references

  • Certificate Template Extensions

  • Object Identifiers

  • Issuance Requirements

  • Application Policy


Planning RADIUS Proxy Deployment

For information about planning the deployment of a RADIUS proxy, see the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=93778).


Manage Online Responder Security

There are three access control entries (ACEs) that can be used to control administrative access to an Online Responder; each can be set to Allow or Deny:

  • Read. Defines who can use the Online Responder snap-in to view information about the Online Responder.

  • Manage Online Responder. Defines who can use the Online Responder snap-in to modify the configuration of the Online Responder. These permissions should be granted very selectively.

  • Proxy Requests. Enables an Online Responder Web proxy to submit requests for certificate status to the Online Responder service.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To modify Online Responder security settings

  1. Open the Online Responder snap-in, right-click the Online Responder that you want to manage, and then click Properties.

  2. Click the Security tab.

  3. Add the user or group that you want to set permissions for, and then select the Allow or Deny check boxes for each ACE.

  4. Click OK.

Additional references

  • Managing a Revocation Configuration

  • Audit Revocation Configuration Changes

  • Manage Revocation Data by Using Local CRLs

  • Revocation Configuration


Health Policies

Health policies

Health policies consist of one or more system health validators (SHVs) and other settings that allow you to define client computer configuration requirements for the NAP-capable computers that attempt to connect to your network.

When NAP-capable clients attempt to connect to the network, the client computer sends a statement of health (SoH) to Network Policy Server (NPS). The SoH is a report of the client configuration state, and NPS compares the SoH to the requirements defined in health policy. If the client configuration state does not match the requirements defined in health policy, NPS takes one of the following actions, depending on how NAP is configured:

  • The connection request by the NAP client is rejected.

  • The NAP client is placed on a restricted network where it can receive updates from remediation servers that bring the client into compliance with health policy. After the client is compliant with health policy, it is allowed to connect.

  • The NAP client is allowed to connect to the network despite being noncompliant with health policy.

You can define client health policies in NPS by adding one or more SHVs to the health policy.

After a health policy is configured with one or more SHVs, you can add the health policy to the Health Policies condition of a network policy that you want to use to enforce NAP when client computers connect to your network.

Using multiple SHVs in a health policy

The Windows Security Health Validator (WSHV) is included by default in NPS. Other companies might also provide additional SHV and SHA pairs for their NAP-compatible products.

If you want to use a NAP-compatible product, you can follow the product's documentation to install the SHA on NAP-capable client computers, and then install the SHV on the NPS server. After you have installed the SHV on the NPS server, you can configure the SHV and then add the SHV to a health policy.

After your health policy is configured with the SHVs you want to use, you can add the health policy to the settings of a network policy.

See Also

  • Create a Health Policy
  • System Health Validators
  • Understanding How to Configure Health Policy


NPS CRL Check Registry Settings

NPS CRL check registry settings

You can use the following registry settings to change the way Network Policy Server (NPS) performs certificate revocation list (CRL) checks when EAP-TLS is used.

Caution

Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

All of the listed registry settings can be configured on NPS servers with the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13

Important

All of the following registry settings must be added as a DWORD type and have the valid values of 0 or 1.

IgnoreNoRevocationCheck

When set to 1, NPS allows EAP-TLS clients to connect even when NPS does not perform or cannot complete a revocation check of the certificate chain (excluding the root certificate) of the client. Typically, revocation checks fail because the certificate does not include CRL information.

IgnoreNoRevocationCheck is set to 0 (disabled) by default. An EAP-TLS client cannot connect unless the server completes a revocation check of the certificate chain (including the root certificate) of the client and verifies that none of the certificates has been revoked.

You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as might be the case with certificates issued by non-Microsoft certification authorities (CAs).

IgnoreRevocationOffline

When set to 1, NPS allows EAP-TLS clients to connect even when a server that stores a CRL is not available on the network.

IgnoreRevocationOffline is set to 0 by default. With this default setting, NPS does not allow clients to connect unless it can complete a revocation check of their certificate chain and verify that none of the certificates is revoked. When NPS cannot connect to a server that stores a revocation list, the certificate fails the revocation check and authentication fails.

Setting IgnoreRevocationOffline to 1 prevents certificate validation failure because poor network conditions prevented NPS from successfully completing a revocation check.

NoRevocationCheck

When set to 1, NPS prevents EAP-TLS from performing a revocation check of the certificate of the client. The revocation check verifies that the certificate of the client and the certificates in its certificate chain have not been revoked. NoRevocationCheck is set to 0 by default.

NoRootRevocationCheck

When set to 1, NPS prevents EAP-TLS from performing a revocation check of the root CA certificate of the client.

NoRootRevocationCheck is set to 0 by default. This entry only eliminates the revocation check of the root CA certificate of the client. A revocation check is still performed on the remainder of the certificate chain of the client.

You can use this entry to authenticate clients when the certificate does not include CRL distribution points. Also, this entry can prevent certification-related delays that occur when a certificate revocation list is offline or expired.


Export a Certificate

You can export a certificate in order to import a copy on a different computer or device or to store a copy in a secure location.

If you are exporting certificates to be imported onto a computer running Windows®,

PKCS #7 format is the preferred export format. This format preserves the chain of certification authorities, or the certification path, of any certificate that includes countersignatures associated with signatures.

If you are exporting certificates for import onto a computer running another operating system, it is possible that the PKCS #7 format is supported. If it is not supported, the DER Encoded Binary format or the Base64 Encoded format is provided for interoperability.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To export a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Do one of the following:

    • If you are in Logical Certificate Stores view mode, in the console tree, click Certificates.

    • If you are in Certificate Purpose view mode, in the console tree, click Purpose.

  3. In the details pane, click the certificate you want to export.

  4. On the Action menu, point to All Tasks, and then click Export.

  5. In the Certificate Export Wizard, click No, do not export the private key. (This option will appear only if the private key is marked as exportable and you have access to the private key.)

  6. Provide the following information in the Certificate Export Wizard:

    • Click the file format you want to use to store the exported certificate: a DER-encoded file, a Base64-encoded file, or a PKCS #7 file.

    • If you are exporting the certificate to a PKCS #7 file, you also have the option to include all certificates in the certification path.

  7. If required, In Password, type a password to encrypt the private key you are exporting. In Confirm password, type the same password again, and then click Next.

  8. In File name, type a file name and path for the PKCS #12 file that will store the exported certificate and private key. Click Next, and then click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • After the Certificate Export Wizard is finished, the certificate will remain in the certificate store in addition to being in the new file. If you want to remove the certificate from the certificate store, you must delete it.


Request a Certificate Using a PKCS #10 or PKCS #7 File

It is not always possible to submit a certificate request online to a certification authority. In these instances, you might still be able to submit a certificate request in the form of a PKCS #7 or PKCS #10 file. In general, you use a PKCS #10 file to submit a request for a new certificate and a PKCS #7 file to submit a request to renew an existing certificate.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To request a certificate uses a PKCS #10 or PKCS #7 file

  1. Open Internet Explorer.

  2. In Internet Explorer, connect to https://servername/certsrv, where servername is the name of the Web server where the web pages you want to access are located.

  3. Click Request a certificate, and then click advanced certificate request.

  4. Click Submit a certificate request using a base-64-encoded CMC or PKCS #10 file or submit a renewal request by using a base-64-encoded PKCS #7 file.

  5. Do one of the following:

    • In Notepad, click File, click Open, select the PKCS #10 or PKCS #7 file, click Edit, click Select all, click Edit, and then click Copy. On the Web page, click in the Saved request scroll box. Click Edit and then click Paste to paste the contents of the certificate request into the scroll box.

    • Click Browse for a file to insert to locate the file you want to use for the certificate request. If you get a warning about the ActiveX control, verify that the source of the control is trustworthy. If it is trustworthy, click Yes to allow it to run, and then click the Browse button. After locating and selecting the file you want to use for the certificate request, click Open. On the Web page, click Read! to paste the contents of the file into the scroll box.

  6. If you are connected to an enterprise CA, choose the certificate template you want to use.

  7. If you have any attributes to add to the certificate request, enter them into Additional Attributes.

  8. Click Submit.

  9. Do one of the following:

    • If you see the Certificate Pending Web page, see Check on a Pending Certificate Request.

    • If you see the Certificate Issued Web page, click Download certificate chain. Choose to save the file to your hard disk, and then import the certificate into your certificate store. For the procedure to import a certificate, see Import a Certificate.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • The component that enables Web enrollment in this version of Windows is different from the component that enables Web enrollment in Windows Server 2003 and Windows XP. Windows Server 2003 CA Web enrollment pages must be updated to support both this version of Windows and earlier clients. For more information, see the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=63591).

  • If this is the first time you are accessing the Web server for a CA, you must add the server to the list of Trusted sites in Internet Explorer. Trusted sites can be added by selecting Internet Options on the Tools menu, clicking the Security tab, selecting the Trusted sites zone, and clicking Sites. In addition, the Web server for the CA must be configured to use HTTPS authentication.

  • If you submit the request and immediately get a message asking you if you want to submit the request even though it does not contain a BEGIN or END tag, click OK.

Additional references

  • Check on a Pending Certificate Request

  • Import a Certificate

  • Export a Certificate

  • Save a Certificate Request in a File

  • Request a Certificate Over the Web


NPS CRL Checks

NPS CRL checks

By default, the server running Network Policy Server (NPS) checks for certificate revocation for all of the certificates in the certificate chain sent by the client computer during the EAP-TLS and PEAP-TLS authentication process. If certificate revocation fails for any of the certificates in the chain, the connection attempt is not authenticated and is denied.

Certificate revocation checking behavior for NPS can be modified with registry settings. For more information, see NPS CRL Check Registry Settings.

Because certificate revocation checking can prevent client access due to the unavailability or expiration of certificate revocation lists (CRLs) for each certificate in the certificate chain, design your public key infrastructure (PKI) for high availability of CRLs. For example, configure multiple CRL distribution points for each certification authority (CA) in the certificate hierarchy and configure publication schedules that ensure that the most current CRL is always available.

Certificate revocation checking is only as accurate as the last published CRL. For example, if a certificate is revoked, by default the new CRL containing the newly revoked certificate is not automatically published. CRLs are typically published based on a schedule that can be configured. This means that the revoked certificate can still be used to authenticate because the published CRL is not current; it does not contain the revoked certificate and can therefore still be used to create wireless connections. To prevent this from occurring, the network administrator must manually publish the new CRL with the newly revoked certificate.

By default, the NPS server uses the CRL distribution points in the certificates. However, it is also possible to store a local copy of the CRL on the NPS server. In this case, the local CRL is used during certificate revocation checking. If a new CRL is manually published to Active Directory® Domain Services (AD DS), the local CRL on the NPS server is not updated. The local CRL is updated when it expires. This can create a situation wherein a certificate is revoked, the CRL is manually published, but the NPS server still allows the connection because the local CRL has not yet been updated.

Important

When using certificates for computer-level or user-level network access authentication, ensure that the CRLs are published in a primary and at least one secondary location that are accessible by all computers, especially all NPS and other RADIUS servers. If the NPS-RADIUS servers attempt to perform CRL validation of the user or computer certificate, but cannot locate the CRLs, the NPS RADIUS servers reject all certificate-based connection attempts and authentication fails.

The certificate revocation check for a certificate can fail for the following reasons.

  • The certificate has been revoked.

  • The CRL for the certificate cannot be reached or is not available.

    CAs maintain CRLs and publish them to CRL distribution points. The CRL distribution points are included in the CRL Distribution Points property of the certificate. If the CRL distribution points cannot be contacted to check for certificate revocation, then the certificate revocation check fails.

    Additionally, if there are no CRL distribution points in the certificate, the NPS server cannot verify that the certificate has not been revoked and the certificate revocation check fails.

  • The publisher of the CRL did not issue the certificate.

    Included in the CRL is the publishing CA. If the publishing CA of the CRL does not match the issuing CA for the certificate for which certificate revocation is being checked, then the certificate revocation check fails.

  • The CRL is not current.

    Each published CRL has a range of valid dates. If the CRL Next update date has passed, the CRL is considered invalid and the certificate revocation check fails. New CRLs should be published before the expiration date of the last published CRL.


Credential Roaming

Credential roaming allows organizations to store certificates and private keys in Active Directory apart from application state or configuration information.

How credential roaming works

Credential roaming uses existing logon and auto-enrollment mechanisms and must be configured on a server running this version of Windows. These mechanisms make it possible to safely and securely download certificates and keys to a local computer whenever a user logs on and, if desired, remove them when the user logs off. In addition, the integrity of these credentials is maintained under any conditions, such as when certificates are updated and when users log on to more than one computer at a time.

The following steps describe how digital credential roaming works.

  1. A user logs on to a client computer that is connected to an Active Directory domain.

  2. As part of the logon process, credential roaming Group Policy is applied to the user’s computer.

  3. If this is the first time that credential roaming is being used, the certificates in the user's store on the client computer are copied to Active Directory.

  4. If the user already has certificates in Active Directory, the certificates in the user’s certificate store on the client computer are compared to the certificates stored for the user in Active Directory.

  5. If the certificates in the user's certificate store are current, then no further action is taken. However, if more recent certificates for the user are stored in Active Directory, then these credentials are copied to the client computer. If more recent certificates for the user are stored on the client computer, then these credentials are copied to Active Directory.

  6. If additional certificates are needed on the client, outstanding certificate auto-enrollment requests are processed.

    Note

    Newly issued certificates are stored in the certificate store on the client and replicated to Active Directory.

  7. Later, when the user logs on to another client computer connected to the domain, the same Group Policy is applied, and credentials are once again replicated from Active Directory. Credential roaming synchronizes and resolves any conflicts between certificates and private keys from any number of client computers that the user logs on to, as well as in Active Directory.

    Important

    In multi-domain environments and domains with multiple domain controllers, credentials may not be immediately available when a user logs on to the network using one domain controller shortly after being issued a certificate on a computer that validates the user's identity against a different domain controller. The credentials will only become available after replication has been completed between the two domains or domain controllers.

  8. On subsequent logons, the certificate in the local certificate and key stores are compared to the certificates and keys in Active Directory:

    • If the certificates and keys are current, no further action is taken.

    • If certificates and keys are not synchronized, they are synched.

    • If additional certificates or keys are needed, or if certificates and keys need to be renewed, auto-enrollment is used to contact the certification authority (CA), issuance and renewal take place, and the updated certificates and keys are replicated to Active Directory.

  9. When the user logs on to the other computer, the updated certificates and keys are replicated to the certificate and key stores on this computer as well.

  10. When the user’s certificate expires, the old certificate is automatically archived in the client's profile and in Active Directory.

Credential roaming is triggered any time a private key or certificate in the user’s local certificate store changes, whenever the user locks or unlocks the computer, and whenever Group Policy is refreshed.

All certificate-related communication between components on the local computer and between the local computer and Active Directory is signed and encrypted.


System Health Validators

System health validators

System health validators (SHVs) are server software counterparts to system health agents (SHAs). Each SHA on the client has a corresponding SHV in Network Policy Server (NPS). SHVs allow NPS to verify the statement of health (SoH) that is made by its corresponding SHA on the client computer.

SHVs contain the details of the required configuration settings on client computers. For example, the Windows Security Health Validator (WSHV) is the counterpart to the Windows Security Health Agent (WSHA) on client computers. WSHV allows you to create a policy for the way in which settings on NAP-capable client computers must be configured. If the settings on the client computer as reported in the SoH do not match the settings in the SHV on the NPS server, the client computer is not compliant with health policy.

To extend this example, if you configure the WSHV to use the setting A firewall is enabled for all network connections, the firewall software that is running on the client computer must be Windows Firewall software or other firewall software that is compatible with Windows Security Center. If the client computer is not running Windows Firewall or other firewall software that is compatible with Windows Security Center, NAP agent on the client computer sends a SoH to NPS that reports this fact. NPS compares the SoH to the configuration of the WSHV in NPS; NPS then determines that the client computer is not compliant with health policy.

See Also

  • Windows Security Health Validator
  • Understanding How to Configure Health Policy


Manage Revocation Checking Policy

Revocation of a certificate invalidates a certificate as a trusted security credential prior to the natural expiration of its validity period. A public key infrastructure (PKI) depends on distributed verification of credentials in which there is no need for direct communication with the central trusted entity that vouches for the credentials.

To effectively support certificate revocation, the client must determine whether the certificate is valid or has been revoked. To support a variety of scenarios, Certificate Services supports industry-standard methods of certificate revocation.

These include publication of certificate revocation lists (CRLs) and delta CRLs in several locations for clients to access, including the Active Directory directory service, Web servers, and network file shares. In Windows, revocation data can also be made available in a variety of settings through online certificate status protocol (OCSP) responses.

Note

CRLs are published to specified network locations on a periodic basis where they can be downloaded by requesting clients. OCSP responses are digitally-signed responses indicating whether an individual certificate has been revoked or suspended, of it its status is unknown. OCSP responders get their data from published CRLs, or they can be updated directly from the certificate status database of a certification authority (CA).

In addition, public key Group Policy allows administrators to enhance the use of CRLs and online responders, particularly in situations where extremely large CRLs or network conditions detract from performance.

Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To configure revocation settings on a local computer

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, click Local Group Policy Object Editor, click Add, and then click Finish.

  4. If you have no more snap-ins to add to the console, click OK.

  5. In the console tree, go to Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  6. Double-click Certificate Path Validation Settings, and then click the Revocation tab.

  7. Select the Define these policy settings check box, select the policy options you want, and then click OK to apply the new settings.

Domain Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To configure revocation settings for a domain

  1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the Group Policy Management Console (GPMC) was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  7. Double-click Certificate Path Validation Settings, and then click the Revocation tab.

  8. Select the Define these policy settings check box, select the policy options you want, and then click OK to apply the new settings.

Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To extend the validity period for CRL and OCSP responses for a local computer

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, click Local Group Policy Object Editor, click Add, and then click Finish.

  4. If you have no more snap-ins to add to the console, click OK.

  5. In the console tree, go to Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  6. Double-click Certificate Path Validation Settings, and then click the Revocation tab.

  7. Select the Define these policy settings check box, and then select the Allow CRL and OCSP responses to be valid longer than their lifetime check box.

  8. In the Default time the validity period can be extended box, and enter a value of time (in hours), and then click OK to apply the new settings.

Domain Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To extend the validity period for CRL and OCSP responses for a domain

  1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the GPMC was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  7. Double-click Certificate Path Validation Settings, and then click the Revocation tab.

  8. Select the Define these policy settings check box, and then select the Allow CRL and OCSP responses to be valid longer than their lifetime check box.

  9. In the Default time the validity period can be extended box, enter a value of time (in hours), and then click OK to apply the new settings.

Additional considerations

  • You must be an administrator to modify Group Policy settings.


Export a Certificate with the Private Key

In some cases you may want to export a certificate with its private key for safe keeping on removable media, or for use on a different computer. There are some restrictions to this procedure:

  • If a certificate was issued from a Windows Server 2003 certification authority, the private key for that certificate is only exportable if the certificate request was made via the Advanced Certificate Request certification authority Web page with the Mark keys as exportable check box selected, or if the certificate is for EFS (Encrypting File System) or EFS recovery.

  • Strong protection (also known as iteration count) is enabled by default in the Certificate Export Wizard when you export a certificate with its associated private key.

  • Strong protection is not compatible with older programs, so you need to clear the Enable strong protection option if you are going to use the private key with any browser earlier than Microsoft Internet Explorer 5.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To export a certificate with the private key

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Do one of the following:

    • If you are in Logical Certificate Stores view mode, in the console tree, click Certificates.

    • If you are in Certificate purpose view mode, in the console tree, click Purpose.

  3. In the details pane, click the certificate you want to export.

  4. On the Action menu, point to All Tasks, and then click Export.

  5. In the Certificate Export Wizard, click Yes, export the private key. (This option will appear only if the private key is marked as exportable and you have access to the private key.)

  6. Under Export File Format, do one or all of the following, and then click Next.

    • To include all certificates in the certification path, select the Include all certificates in the certification path if possible check box.

    • To enable strong protection, select the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) check box.

    • To delete the private key if the export is successful, select the Delete the private key if the export is successful check box.

  7. In Password, type a password to encrypt the private key you are exporting. In Confirm password, type the same password again, and then click Next.

  8. In File name, type a file name and path for the PKCS #12 file that will store the exported certificate and private key. Click Next, and then click Finish.

After the Certificate Export Wizard is finished, the certificate will remain in the certificate store in addition to being in the newly-created file. If you want to remove the certificate from the certificate store, you will need to delete it.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


Import a Certificate

You should only import certificates obtained from trusted sources. Importing an unreliable certificate could compromise the security of any system component that uses the imported certificate.

You can import a certificate into any logical or physical store. In most cases, you will import certificates into the Personal store or the Trusted Root Certification Authorities store, depending on whether the certificate is intended for you or if it is a root CA certificate.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To import a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree, click the logical store where you want to import the certificate.

  3. On the Action menu, point to All Tasks and then click Import to start the Certificate Import Wizard.

  4. Type the file name containing the certificate to be imported. (You can also click Browse and navigate to the file.)

  5. If it is a PKCS #12 file, do the following:

    • Type the password used to encrypt the private key.

    • (Optional) If you want to be able to use strong private key protection, select the Enable strong private key protection check box.

    • (Optional) If you want to back up or transport your keys at a later time, select the Mark key as exportable check box.

  6. Do one of the following:

    • If the certificate should be automatically placed in a certificate store based on the type of certificate, click Automatically select the certificate store based on the type of certificate.

    • If you want to specify where the certificate is stored, select Place all certificates in the following store, click Browse, and choose the certificate store to use.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • Enabling strong private key protection will ensure that you are prompted for a password every time the private key is used. This is useful if you want to make sure that the private key is not used without your knowledge.

  • The file from which you import certificates will remain intact after you have completed importing the certificates. You can use Windows Explorer to delete the file if it is no longer needed.


Request Certificates Using the Certificate Request Wizard

When you request certificates from a Windows-based enterprise certification authority (CA), you can use the Certificate Request Wizard located in the Certificates snap-in. This wizard guides you through the following steps:

  • Selecting the CA to which you will submit the request.

  • Selecting the appropriate certificate template to use for the new certificate.

    Certificate templates are predefined configurations that provide common settings for the certificate request. Certificate templates describe the purpose for which the requested certificate is to be used. The list of certificate templates that is available to you is determined by the certificate types that the CA is configured to issue and whether you have been granted the access rights to the certificate template by the system administrator.

  • (Optional) Using Advanced Options in the Certificate Request Wizard to select the cryptographic service provider (CSP) for the key pair associated with the certificate request.

For instructions about opening and using the Certificate Request Wizard, see Request a Certificate.

You can also use the Certificate Request Wizard to request a new certificate from an enterprise CA by using an existing key pair that is already associated with another certificate.

Additional references

  • Request a Certificate

  • Create a Custom Certificate Request

  • Save a Certificate Request in a File

  • Sign Certificate Requests

  • Obtain a Certificate


Manage Network Retrieval and Path Validation

To be effective, certificate-related data such as trusted root certificates, cross- certificates, and certificate revocation lists must be updated in a timely manner. Network retrieval and path validation settings allow administrators to:

  • Automatically update certificates in the Microsoft Root certificate Program

  • Configure retrieval timeout values for certificate revocation lists (CRLs) and path validation (larger default values may be useful if network conditions are not optimal)

  • Enable issuer certificate retrieval during path validation

  • Define how frequently cross-certificates are downloaded.

Managing CRL retrieval

Obtaining timely certificate-revocation data is an important element in secure certificate use. However, problems can arise if validation checking and retrieval of certificate revocation data and cross-certificates time out because more data is being transferred than originally anticipated.

Network retrieval options in public key Group Policy allow administrators to manage network retrieval timeout values.

Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To increase the retrieval timeout option for large CRLs for a local computer

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, click Local Group Policy Object Editor, click Add, and then click Finish.

  4. If you have no more snap-ins to add to the console, click OK.

  5. In the console tree, go to Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  6. Double-click Certificate Path Validation Settings, and then click the Network Retrieval tab.

  7. Select the Define these policy settings check box.

  8. Under Default retrieval timeout settings, enter a timeout value in the Default URL retrieval timeout (in seconds) box, and then click OK to apply the new settings.

Domain Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To increase the retrieval timeout option for large CRLs for a domain

  1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the Group Policy Management Console (GPMC) was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  7. Double-click Certificate Path Validation Settings, and then click the Network Retrieval tab.

  8. Select the Define these policy settings check box.

  9. Under Default retrieval timeout settings, enter a timeout value in the Default URL retrieval timeout (in seconds) box, and then click OK to apply the new settings.

Additional considerations

  • Group Policy options can only be changed by an administrator.


Configure 802.1X Wireless Clients Running Windows XP with Group Policy

Use the procedures in this topic to configure the Wireless Network (IEEE 802.11) Policies for client computers running Windows XP that connect to your wireless network through 802.1X authenticating wireless access points (APs).

This document provides the detailed steps to create and configure the Wireless Network (IEEE 802.11) Policies and wireless configuration profiles for wireless computers running Windows XP and Windows Server 2003.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

Configure wireless clients running Windows XP by using the Wireless Network (IEEE 802.11) Policies

You can use the Windows XP Wireless Network (IEEE 802.11) Policies to configure and manage wireless profiles for computers running Windows XP.

Similar to the wireless policy for computers running Windows Vista, you can configure and prioritize multiple profiles by using the wireless network policy for computers running Windows XP. However, unlike the wireless policy for Windows Vista, the wireless policy for Windows XP requires each profile to specify a unique SSID.

Using the Windows Server 2008 or Windows Vista Group Policy Management Console to configure wireless policies exposes the settings that enable you to configure Wi-Fi Protected Access version 2 (WPA2) on client computers running Windows XP with Service Pack 2 (SP2). This is not possible when using the GPMC in Windows Server 2003.

Note

You can use the Windows XP Wireless Network (IEEE 802.11) Policies to configure wireless computers running Windows Vista and Windows Server 2008. However, the only the Windows Vista Wireless Network (IEEE 802.11) Policies provides the configuration settings for the enhanced security and management features available in computers running Windows Vista and Windows Server 2008.
Opening the Wireless Network (IEEE 802.11) Policies properties

Use this procedure access the Wireless Network (IEE 802.11) Policy.

To open the Wireless Network (IEEE 802.11) Policies properties

  1. Open the Group Policy Management Console (GPMC).

  2. In Default Domain Policy, open Computer Configuration, open Windows Settings, open Security Settings, and then select Wireless Network (IEEE 802.11) Policies.

  3. If there is a Wireless Network Policy in the details pane, with the Type listed as XP, right-click that policy, and then click Properties, to access the properties of the wireless policy.

    Note

    The wireless policy is not necessarily listed as New Vista Wireless Network Policy in the details pane of the Group Policy Management Console. If the default policy name was previously changed from New Vista Wireless Network Policy to another name, the name change is reflected in the GPMC details pane.

  4. If there is not a Wireless Network Policy in the details pane, with the Type listed as XP, right-click Wireless Network (IEEE 802.11) Policies, and then click Create A New Windows XP Policy to activate and open the New XP Wireless Network Policy Properties.

    Note

    After the Windows Vista Wireless Policy is added, it is only listed in the GPMC details pane, when Wireless Network (IEEE 802.11) Policies is selected.

Configure wireless clients running Windows XP

The procedure in this section provide the steps to use the Windows XP Wireless Network (IEEE 802.11) Policies to configure wireless profiles that wireless clients running Windows XP will use to connect to your wireless network.

To configure wireless clients running Windows XP by using the Wireless Network (IEEE 802.11) Policies

  1. In Windows XP Wireless Network (IEEE 802.11) Policies Properties, on the General tab, do the following:

    1. In XP Policy Name, type a name for your wireless policy.

    2. In Description, type a brief description of the policy.

    3. In Networks to access, select either Any available network (wireless AP preferred) or Access Point (infrastructure) network only.

    4. Select Use Windows to configure wireless network settings for clients.

  2. On the Preferred Networks tab, click Add, and then select Infrastructure. On the Network Properties tab, configure the following:

    1. In Network Name (SSID), type the SSID for your network.

      Note

      The value you enter in this field must match the value configured on the access points you have deployed on your network.

    2. In Description, enter a description for the New Preferred Setting Properties.

    3. To specify that a network key is used for authentication to the wireless network, under Select the security methods for this network, in Authentication, select either WPA2 (preferred), or WPA. In Encryption, specify either AES or TKIP.

      Note

      In the Windows XP Wireless Network (IEEE 802.11) Policies, WPA2 and WPA correspond to the Windows Vista Wireless Network (IEEE 802.11) Policies WPA2-Enterprise and WPA-Enterprise settings, respectively.

      Note

      Selecting WPA2 exposes additional settings for Fast Roaming. The default settings for Fast Roaming are sufficient for most wireless deployments.

  3. Click the IEEE 802.1X tab. In EAP type, select one of the following:

    For deployments using PEAP-MS-CHAP v2, do the following:

    1. By default, Protected EAP (PEAP) is selected.

      The remaining default settings on the IEEE 802.1X tab are sufficient for most wireless deployments.

    2. Click Settings. In the Protected EAP Properties dialog box, do the following:

      Verify that Validate Server certificate is selected.

      In Select Authentication Method, select Secured password (EAP-MS-CHAP v2).

      In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your Network Policy Server (NPS).

      Note

      This setting limits the trusted root CAs that clients trust to the selected values. If no Trusted Root CAs are selected, then clients will trust all trusted root CAs in their trusted root certification authority store.

      To enable PEAP Fast Reconnect, ensure that Enable Fast Reconnect is selected.

    3. Click OK two times. The PEAP profile is listed under Networks. Click OK, and then close the Group Policy Management Console.

    For deployments using Smart Card or other certificates (EAP-TLS) do the following:

    1. Select Smart Card or other Certificate.

      The remaining default settings on the IEEE 802.1X tab are typically sufficient for wireless deployments.

    2. Click Settings. In the Smart Card or other Certificate Properties dialog box, do the following:

      For smart card deployments, select Use my smart card, for other certificate deployments, select Use a certificate on this computer.

      Verify that Validate Server certificate is selected.

      In Trusted Root Certification Authorities, select the trusted root CA that issued the server certificate to your Network Policy server.

      Note

      This setting limits the trusted root CAs that clients trust to the selected values. If no trusted root CAs are selected, then clients will trust all trusted root CAs in their trusted root certification authority store.

    3. Click OK two times. The EAP-TLS profile is listed under Networks. Click OK, and then close the Group Policy Management Console.


View Certificate Information

Users should think about which certificates to trust and accept, and which to distrust or ignore. When you double-click a certificate you can obtain a great deal of information about its characteristics and intended uses. This information is contained on three tabs: General, Details, and Certification Path.

General Tab

Details Tab

Certification Path Tab


Sign Certificate Requests

In some cases, certificate requests must be digitally signed by using a valid Enrollment Agent or Signing certificate before a certification authority (CA) will process the request.

Important

Once someone has an Enrollment Agent certificate, that person can enroll for a certificate and generate a smart card on behalf of anyone in the organization. The resulting smart card could then be used to log on to the network and impersonate the real user. Because of the powerful capability of the Enrollment Agent certificate, it is strongly recommended that your organization maintain very strong security policies over who has one.

One scenario to minimize risk of Enrollment Agent certificate misuse is to have one subordinate CA with very tight administrative controls in your organization that is only used to issue Enrollment Agent certificates. Once the initial Enrollment Agent certificates have been issued, the administrator of the CA can disable the issuance of Enrollment Agent certificates until it is needed again.

By restricting the administrators who can operate the CA service on the subordinate CA, the service can be kept online for the generation and distribution of certificate revocation lists (CRLs) if necessary.

Other CAs in the hierarchy can still issue Enrollment Agent certificates if their policy settings are changed, but you can determine whether inappropriate Enrollment Agent certificates are issued by checking the Issued Certificates log for each CA regularly.

Additional reference

  • Request Certificates Using the Certificate Request Wizard


Connection Request Policies

Connection Request Policies

Connection request policies are sets of conditions and settings that allow network administrators to designate which RADIUS servers perform the authentication and authorization of connection requests that the server running Network Policy Server (NPS) receives from RADIUS clients. Connection request policies can be configured to designate which RADIUS servers are used for RADIUS accounting.

Important

When you deploy Network Access Protection (NAP) using the VPN or 802.1X enforcement methods with PEAP authentication, you must configure PEAP authentication in connection request policy even when connection requests are processed locally.

You can create connection request policies so that some RADIUS request messages sent from RADIUS clients are processed locally (NPS is being used as a RADIUS server) and other types of messages are forwarded to another RADIUS server (NPS is being used as a RADIUS proxy).

With connection request policies, you can use NPS as a RADIUS server or as a RADIUS proxy, based on factors like the following:

  • The time of day and day of the week

  • The realm name in the connection request

  • The type of connection being requested

  • The IP address of the RADIUS client

RADIUS Access-Request messages are processed or forwarded by NPS only if the settings of the incoming message match at least one of the connection request policies configured on the NPS server. If the policy settings match and the policy requires that the NPS server process the message, NPS acts as a RADIUS server, authenticating and authorizing the connection request. If the policy settings match and the policy requires that the NPS server forwards the message, NPS acts as a RADIUS proxy and forwards the connection request to a remote RADIUS server for processing.

If the settings of an incoming RADIUS Access-Request message do not match at least one of the connection request policies, an Access-Reject message is sent to the RADIUS client and the user or computer attempting to connect to the network is denied access.

Configuration examples

The following configuration examples demonstrate how connection request policies can be used.

  • NPS as a RADIUS server

    The default connection request policy is the only configured policy. In this example, NPS is configured as a RADIUS server and all connection requests are processed by the local NPS server. The NPS server can authenticate and authorize users whose accounts are in the domain of the NPS server domain and in trusted domains.

  • NPS as a RADIUS proxy

    The default connection request policy is deleted, and two new connection request policies are created to forward requests to two different domains. In this example, NPS is configured as a RADIUS proxy. NPS does not process any connection requests on the local server. Instead, it forwards connection requests to NPS or other RADIUS servers that are configured as members of remote RADIUS server groups.

  • NPS as both RADIUS server and RADIUS proxy

    In addition to the default connection request policy, a new connection request policy is created that forwards connection requests to an NPS or other RADIUS server in an untrusted domain. In this example, the proxy policy appears first in the ordered list of policies. If the connection request matches the proxy policy, the connection request is forwarded to the RADIUS server in the remote RADIUS server group. If the connection request does not match the proxy policy but does match the default connection request policy, NPS processes the connection request on the local server. If the connection request does not match either policy, it is discarded.

  • NPS as RADIUS server with remote accounting servers

    In this example, the local NPS server is not configured to perform accounting and the default connection request policy is revised so that RADIUS accounting messages are forwarded to an NPS or other RADIUS server in a remote RADIUS server group. Although accounting messages are forwarded, authentication and authorization messages are not forwarded, and the local NPS server performs these functions for the local and all trusted domains.

  • NPS with Remote RADIUS to Windows User Mapping

    In this example, NPS acts as both a RADIUS server and as a RADIUS proxy for each individual connection request by forwarding the authentication request to a remote RADIUS server while using a local Windows user account for authorization. This configuration is implemented by configuring the Remote RADIUS to Windows User Mapping attribute as a condition of the connection request policy. (In addition, a user account must be created locally that has the same name as the remote user account against which authentication is performed by the remote RADIUS server.)

Conditions

Connection request policy conditions are one or more RADIUS attributes that are compared to the attributes of the incoming RADIUS Access-Request message. If there are multiple conditions, then all of the conditions in the connection request message and in the connection request policy must match in order for the policy to be enforced by NPS.

Following are the available condition attributes that you can configure in connection request policies.

The Connection Properties attribute group contains the following attributes.

  • Framed Protocol. Used to designate the type of framing for incoming packets. Examples are PPP, SLIP, Frame Relay, and X.25.

  • Service Type. Used to designate the type of service being requested. Examples include framed (for example, PPP connections) and login (for example, Telnet connections). For more information about RADIUS service types, see RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)."

  • Tunnel Type. Used to designate the type of tunnel that is being created by the requesting client. Tunnel types include the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol (L2TP).

The Day and Time Restrictions attribute group contains the Day and Time Restrictions attribute. With this attribute, you can designate the day of the week and the time of day of the connection attempt. The day and time is relative to the day and time of the NPS server.

The Gateway attribute group contains the following attributes.

  • Called Station ID. Used to designate the phone number of the network access server. This attribute is a character string. You can use pattern-matching syntax to specify area codes.

  • NAS Identifier. Used to designate the name of the network access server. This attribute is a character string. You can use pattern-matching syntax to specify NAS identifiers.

  • NAS IPv4 Address. Used to designate the Internet Protocol version 4 (IPv4) address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern-matching syntax to specify IP networks.

  • NAS IPv6 Address. Used to designate the Internet Protocol version 6 (IPv6) address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern-matching syntax to specify IP networks.

  • NAS Port Type. Used to designate the type of media used by the access client. Examples are analog phone lines (known as async), ISDN, tunnels or virtual private networks (VPNs), IEEE 802.11 wireless, and Ethernet switches.

The Machine Identity attribute group contains the Machine Identity attribute. With this attribute, you can specify the method with which clients are identified in the policy.

The RADIUS Client Properties attribute group contains the following attributes.

  • Calling Station ID. Used to designate the phone number used by the caller (the access client). This attribute is a character string. You can use pattern-matching syntax to specify area codes.

  • Client Friendly Name. Used to designate the name of the RADIUS client computer that is requesting authentication. This attribute is a character string. You can use pattern-matching syntax to specify client names.

  • Client IPv4 Address. Used to designate the IPv4 address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern-matching syntax to specify IP networks.

  • Client IPv6 Address. Used to designate the IPv6 address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern-matching syntax to specify IP networks.

  • Client Vendor. Used to designate the vendor of the network access server that is requesting authentication. A computer running the Routing and Remote Access service is the Microsoft NAS manufacturer. You can use this attribute to configure separate policies for different NAS manufacturers. This attribute is a character string. You can use pattern-matching syntax.

The User Name attribute group contains the User Name attribute. With this attribute, you can designate the user name, or a portion of the user name, that must match the user name supplied by the access client in the RADIUS message. This attribute is a character string that typically contains a realm name and a user account name. You can use pattern-matching syntax to specify user names.

Settings

Connection request policy settings are a set of properties that are applied to an incoming RADIUS message. Settings consist of the following groups of properties:

  • Authentication

  • Accounting

  • Attribute manipulation

  • Advanced

Authentication

With this setting, you can override the authentication settings that are configured in all network policies and you can designate the authentication methods and types that are required to connect to your network.

Important

If you configure an authentication method in connection request policy that is less secure than the authentication method you configure in network policy, the more secure authentication method that you configure in network policy will be overridden. For example, if you have one network policy that requires the use of PEAP-MS-CHAP v2, which is a password-based authentication method for secure wireless, and you also configure a connection request policy to allow unauthenticated access, no clients are required to authenticate using PEAP-MS-CHAP v2. In this example, all clients connecting to your network are granted unauthenticated access.

Accounting

With this setting, you can configure connection request policy to forward accounting information to a server running NPS or other RADIUS server in a remote RADIUS server group so that the remote RADIUS server group performs accounting.

Note

If you have multiple RADIUS servers and you want accounting information for all servers stored in one central RADIUS accounting database, you can use the connection request policy accounting setting in a policy on each RADIUS server to forward accounting data from all of the servers to one NPS or other RADIUS server that is designated as an accounting server.

Connection request policy accounting settings function independent of the accounting configuration of the local NPS server. In other words, if you configure the local NPS server to log RADIUS accounting information to a local file or to a Microsoft® SQL Server™ database, it will do so regardless of whether you configure a connection request policy to forward accounting messages to a remote RADIUS server group.

If you want accounting information logged remotely but not locally, you must configure the local NPS server to not perform accounting, while also configuring accounting in a connection request policy to forward accounting data to a remote RADIUS server group.

Attribute manipulation

You can configure a set of find-and-replace rules that manipulate the text strings of one of the following attributes:

  • User Name

  • Called Station ID

  • Calling Station ID

Find-and-replace rule processing occurs for one of the preceding attributes before the RADIUS message is subject to authentication and accounting settings. Attribute manipulation rules apply only to a single attribute. You cannot configure attribute manipulation rules for each attribute. In addition, the list of attributes that you can manipulate is a static list; you cannot add to the list of attributes available for manipulation.

Note

If you are using the MS-CHAP v2 authentication protocol, you cannot manipulate the User Name attribute if the connection request policy is used to forward the RADIUS message. The only exception occurs when a backslash (\) character is used and the manipulation only affects the information to the left of it. A backslash character is typically used to indicate a domain name (the information to the left of the backslash character) and a user account name within the domain (the information to the right of the backslash character). In this case, only attribute manipulation rules that modify or replace the domain name are allowed.

Forwarding request

You can set the following forwarding request options that are used for RADIUS Access-Request messages:

Authenticate requests on this server. With this setting, NPS uses a Windows NT 4.0 domain, Active Directory, or the local Security Accounts Manager (SAM) user accounts database to authenticate the connection request. This setting also specifies that the matching network policy configured in NPS, along with the dial-in properties of the user account, are used by NPS to authorize the connection request. In this case, the NPS server is configured to perform as a RADIUS server.

Forward requests to the following remote RADIUS server group. With this setting, NPS forwards connection requests to the remote RADIUS server group that you specify. If the NPS server receives a valid Access-Accept message that corresponds to the Access-Request message, the connection attempt is considered authenticated and authorized. In this case, the NPS server acts as a RADIUS proxy.

Accept users without validating credentials. With this setting, NPS does not verify the identity of the user attempting to connect to the network and NPS does not attempt to verify that the user or computer has the right to connect to the network. When NPS is configured to allow unauthenticated access and it receives a connection request, NPS immediately sends an Access-Accept message to the RADIUS client and the user or computer is granted network access. This setting is used for some types of compulsory tunneling where the access client is tunneled before the user's credentials are authenticated.

Note

This authentication option cannot be used when the authentication protocol of the access client is MS-CHAP v2 or EAP-TLS, both of which provide mutual authentication. In mutual authentication, the access client proves that it is a valid access client to the authenticating server (the NPS server), and the authenticating server proves that it is a valid authenticating server to the access client. When this authentication option is used, the Access-Accept message is returned. However, the authenticating server does not provide validation to the access client and mutual authentication fails.

Advanced

You can set advanced properties to specify the series of RADIUS attributes that are:

  • Added to the RADIUS response message when the NPS server is being used as a RADIUS authentication or accounting server.

    When there are attributes specified on both a network policy and the connection request policy, the attributes that are sent in the RADIUS response message are the combination of the two sets of attributes.

  • Added to the RADIUS message when the NPS server is being used as a RADIUS authentication or accounting proxy. If the attribute already exists in the message that is forwarded, it is replaced with the value of the attribute specified in the connection request policy.

In addition, some attributes that are available for configuration on the connection request policy Settings tab in the Advanced category provide specialized functionality. For example, you can configure the Remote RADIUS to Windows User Mapping attribute when you want to split the authentication and authorization of a connection request between two user accounts databases.

The Remote RADIUS to Windows User Mapping attribute specifies that Windows authorization occurs for users who are authenticated by a remote RADIUS server. In other words, a remote RADIUS server performs authentication against a user account in a remote user accounts database, but the local NPS server authorizes the connection request against a user account in a local user accounts database. This is useful when you want to allow visitors access to your network.

For example, visitors from partner organizations can be authenticated by their organization's RADIUS server, and can use a Windows user account at your organization to access a guest local area network (LAN) on your network.

Other attributes that provide specialized functionality are:

  • MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout. These attributes are used when you deploy Network Access Quarantine Control (NAQC) with your Routing and Remote Access VPN deployment.

  • Passport-User-Mapping-UPN-Suffix. This attribute allows you to authenticate connection requests with Windows Live™ ID user account credentials.

  • Tunnel-Tag. This attribute designates the VLAN ID number to which the connection should be assigned by the NAS when you deploy virtual local area networks (VLANs).

Default connection request policy

A default connection request policy is created when you install NPS. This policy has the following configuration:

  • Authentication is not configured.

  • Accounting is not configured to forward accounting information to a remote RADIUS server group.

  • Attribute is not configured with attribute manipulation rules that forward connection requests to remote RADIUS server groups.

  • Forwarding Request is configured so that connection requests are authenticated and authorized on the local NPS server.

  • Advanced attributes are not configured.

The default connection request policy uses NPS as a RADIUS server. To configure a server running NPS to act as a RADIUS proxy, you must also configure a remote RADIUS server group. You can create a new remote RADIUS server group while you are creating a new connection request policy with the New Connection Request Policy Wizard. You can either delete the default connection request policy or verify that the default connection request policy is the last policy processed.

Note

If NPS and the Routing and Remote Access service are installed on the same computer, and the Routing and Remote Access service is configured for Windows authentication and accounting, it is possible for Routing and Remote Access authentication and accounting requests to be forwarded to a RADIUS server. This can occur when Routing and Remote Access authentication and accounting requests match a connection request policy that is configured to forward them to a remote RADIUS server group.


Create a Health Policy

Create a health policy

You can create health policies in Network Policy Server (NPS) by naming the policy, setting the type of client system health validator (SHV) check, and adding one or more SHVs to the new health policy.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To create a health policy

  1. Open the NPS console.

  2. In the console tree, double-click Policies, right-click Health Policies, and then click New. The Create New Health Policy dialog box opens.

  3. In Create New Health Policy, on the Settings tab, in Policy Name, type a name for the health policy.

  4. On the Settings tab, in Client SHV checks, select one of the following.

    • Client passes all SHV checks. If this option is selected, the NAP-capable client computer configuration must match all SHVs that are configured in the policy.

    • Client fails all SHV checks. If this option is selected, NAP-capable client computer configuration must not match any SHVs that are configured in the policy.

    • Client passes one or more SHV checks. If this option is selected, NAP-capable client computer configuration must match at least one SHV configured in the policy.

    • Client fails one or more SHV checks. If this option is selected, NAP-capable client computer configuration must not match at least one SHV configured in the policy.

  5. In SHVs used in this health policy, click the SHVs that you want to include in the health policy. One or more SHVs must be selected.

  6. Click OK.


Certificate Template Extensions

A certification authority (CA) processes each certificate request by using a defined set of rules. Certificate templates can be customized with a number of extensions that regulate their use. These extensions can include:

  • Issuance policies. An issuance policy (also known as an enrollment or certificate policy) is a group of administrative rules that is implemented when issuing certificates. They are represented in a certificate by an object identifier (also known as an OID) that is defined at the CA. This object identifier is included in the issued certificate. When a subject presents its certificate, it can be examined by the target to verify the issuance policy and determine if that level of issuance policy is sufficient to perform the requested action. For more information, see Issuance Requirements.

  • Application policies. Application policies give you the important ability to decide which certificates can be used for certain purposes. This allows you to issue certificates widely without being concerned that they are misused for an unintended purpose. Application policies are sometimes called extended key usage or enhanced key usage. Because some implementations of public key infrastructure (PKI) applications cannot interpret application policies, both application policies and enhanced key usage sections appear in certificates issued by a Windows Server–based CA. For more information, see Application Policy.

  • Key usage. A certificate enables the subject to perform a specific task. To help control the usage of a certificate outside its intended purpose, restrictions are automatically placed on certificates. Key usage is a restriction method and determines what a certificate can be used for. This allows the administrator to issue certificates that can only be used for specific tasks or to issue certificates that can be used for a broad range of functions. For more information, see Key Usage.

  • Key archival. When subjects lose their private keys, any information that was persistently encrypted with the corresponding public key is inaccessible. To help prevent this, key archival allows you to encrypt and archive a subject's keys in the CA database when certificates are issued. If a subject loses its keys, the information can be retrieved from the database and provided to the subject. This allows the encrypted information to be recovered instead of lost. For more information, see Request Handling.

  • Basic constraints. Basic constraints are used to ensure that CA certificates are only used in certain applications. An example is the path length that can be specified as a basic constraint. A path length defines the number of CAs that is permitted below the current CA. This path length constraint ensures that CAs at the end of this path can only issue end-entity certificates, not CA certificates. For more information, see Basic Constraints.

  • OCSP No Revocation Checking. This extension appears only in the new OCSP Response Signing certificate template and duplicates derived from this template. It cannot be added to any other certificate templates. This extension instructs the CA to include the OCSP No Revocation Checking (id-pkix-ocsp-nocheck) extension in the issued certificate and not to include the authority information access and certificate revocation list (CRL) distribution point extensions in the certificate. This is because OCSP Response Signing certificates are not checked for revocation status. This extension only applies if the certificate request contains OCSP Response Signing in the enhanced key usage and application policies.

Additional references

  • Configuring a Certificate Template

  • Issuance Requirements

  • Application Policy

  • Key Usage

  • Basic Constraints

  • Make Issuance or Application Policy Critical


Add a Condition to a Network Policy

Add a condition to a network policy

After creating a network policy with the New Network Policy Wizard or by creating a custom policy, you can specify the conditions that connection requests must have in order to match the network policy; if the conditions configured in the policy match the connection request, Network Policy Server (NPS) applies the settings designated in the network policy to the connection.

With this procedure you can configure conditions in the groups Connection Properties, Day and Time Restrictions, Gateway, Groups, Network Access Protection, and RADIUS Client Properties.

Important

Before you configure the value for a condition in a network policy, you must know the value that the condition must have. For example, if you want to configure the NAS IPv6 Address condition, you must know the Internet Protocol version 6 (IPv6) address of the network access server, or RADIUS client, that creates the Access-Request messages received by NPS. In addition, there are different methods for configuring condition values, depending on the type of condition or type of value to be configured. Many conditions, such as the Connection Properties group of conditions, provide a list from which you can select one or more values by selecting check boxes. The Day and Time Restrictions condition provides an Edit button that allows you to configure restrictions in a new dialog box. Other conditions allow you to enter values in other ways.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To add a condition to a network policy using the Windows interface

  1. Open the Network Policy Server (NPS) Microsoft Management Console (MMC) snap-in, double-click Policies, and then click Network Policies.

  2. In the upper details pane, double-click the network policy to which you want to add a condition, and then click the Conditions tab.

  3. In Available Conditions, browse to the appropriate conditions group, and then click the condition you want to add to the policy.

  4. In the details pane, configure the value for the condition.

  5. Click Add, and then click OK.
Caution

If you do not click Add, the condition is not added to the network policy. You must click Add to complete this procedure.


Set Up Automatic Certificate Enrollment

Autoenrollment is a useful feature of Active Directory Certificate Services (AD CS). It allows the administrator to configure subjects to automatically enroll for certificates, retrieve issued certificates, and renew expiring certificates without requiring subject interaction. The subject does not need to be aware of any certificate operations, unless you configure the certificate template to interact with the subject.

To properly configure subject autoenrollment, the administrator must plan the appropriate certificate template or templates to use. Several settings in the certificate template directly affect the behavior of subject autoenrollment. For more information on these settings, see:

  • Issuance Requirements

  • Application Policy

  • Key Usage

  • Supersede Templates

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To set up automatic certificate enrollment

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. Click the various Properties tabs, including General, Request Handling, and Issuance Requirements, and modify them if necessary.

  4. On the Security tab, select a group or user name. Select the Allow check box next to Autoenroll, and then click Apply.

Additional references

  • Issuing Certificates Based on Certificate Templates


Renew a Certificate with a New Key

Renewing a certificate with a new key allows you to continue using an existing certificate and its associated data, while enhancing the strength of the key associated with the certificate. This can be desirable if using a new certificate would cause disruption and the existing certificate has not been compromised.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To renew a certificate with a new key

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Confirm that you are in Logical Stores View.

  3. In the console tree, expand the Personal store, and then click Certificates.

  4. In the details pane, click the certificate you are renewing.

  5. On the Action menu, point to All Tasks, and then click Renew Certificate with New Key to open the Certificate Renewal Wizard.

  6. In the Certificate Renewal Wizard, do one of the following:

    • Use the default values to renew the certificate.

    • (For advanced users only) Click Details and then Properties to provide your own certificate renewal settings. You need to know the cryptographic service provider (CSP) and the certification authority (CA) issuing the certificate.

      You need to select the key length (measured in bits) of the public key associated with the certificate

      You can also choose to enable strong private key protection. Enabling strong private key protection ensures that you are prompted for a password every time the private key is used. This is useful if you want to make sure that the private key is not used without your knowledge.

  7. When you are ready to request a certificate, click Enroll. After the Certificate Renewal Wizard has successfully finished, click Close.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC

  • Once renewed, the old certificate and key pair will be archived.

  • You can use this procedure to request certificates from an enterprise CA only. To request certificates from a stand-alone CA, you need to request certificates by means of Web pages. A Windows CA has its Web pages located at http://servername/Certsrv, where servername is the name of the server that hosts the CA.


Display Certificate Stores in Logical Store Mode

Logical certificate stores group certificates together in logical, functional categories for users, computers, and services. They provide pointers to the physical certificate stores. The use of logical certificate stores eliminates the need to store duplicates of common public key objects, such as trusted root certificates, CTLs, and CRLs for users, computers, and services.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To display certificate stores in Logical Store mode

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Open Certificates - Current.

  3. Right-click Certificates - Current, click View, and then click Options.

  4. Under Organize view mode by, click Logical certificate stores, and then click OK. The title Logical Store Name will appear at the top of the right-hand column when you click the top node the Certificates snap-in, enabling you to select the logical store whose certificates you want to view.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • When you look at the contents of a certificate store in Logical Store mode, you will occasionally see what appear to be two copies of the same certificate in the store. This occurs because the same certificate is stored in separate physical stores under a logical store. When the contents of the physical certificates stores are combined into one logical store view, both instances of the same certificate are displayed.

    You can verify this by setting the view option to show the physical certificate stores and then noting that the certificate is stored in separate physical stores under the same logical store. You can verify that it is the same certificate by comparing the serial numbers.


Automate Certificate Management

Managing certificates one at a time can be a laborious, if not impossible, task. Many organizations will manage certificates using Group Policy settings configured on a server and applied to clients in a domain, group, or organizational unit. The following options can be viewed on a client, although they are typically configured on a server.

Credential Roaming

Certificate Path Validation


Configure a Network Policy to Grant or Deny Access

Configure a network policy to grant or deny access

Network policies are used by Network Policy Server (NPS) and the Routing and Remote Access service to authorize connection requests.

Network policies contain overview properties that designate how the policy is to be used and interpreted. Access Permission allows you to configure whether user account dial-in properties in Active Directory® Domain Services (AD DS) are used to perform authorization. It also provides two possible network access values:

  • Grant access. If selected, connection requests whose properties match the conditions and constraints of the network policy are granted.

  • Deny access. If selected, connection requests whose properties match the conditions of the network policy are denied.

Note

By default, network policies created with the New Network Policy Wizard are configured to deny access. Therefore, Access Permission must be changed after running the wizard in order for the policy to grant access rather than deny access to the network.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure a network policy to grant or deny access

  1. Open the Network Policy Server (NPS) Microsoft Management Console (MMC) snap-in, double-click Policies, and then double-click Network Policies.

  2. In the details pane, double-click the network policy that you want to configure.

  3. In the network policy Properties dialog box, on the Overview tab, change Access Permission to either Grant access or Deny access.

See Also

  • Access Permission


Configuring a Certificate Template

When you create a new certificate template, it is also possible to customize its general properties, extensions, and other important characteristics.

  • Managing Certificate Templates

  • Certificate Template General Properties

  • Certificate Template Extensions

  • Request Handling

  • Cryptography

  • Supersede Templates

  • Subject Names


Enable Client Health Checks for DHCP and IPsec NAP Deployments

Enable client health checks

You can use this procedure to enable client health checks when you deploy Network Access Protection (NAP) with the Internet Protocol security (IPsec) and DHCP enforcement methods. Client health checks with these enforcement methods occur during the authorization process; however, these checks also occur at times when NPS does not perform the full authentication and authorization process. For example, when a DHCP client renews its IP address, a client health check is performed, but full authentication and authorization are not performed.

Important

The Perform machine health check only setting is provided for use with network policies that also enforce health policy for NAP. Do not use this setting on policies that do not enforce health policy for NAP.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To enable client health checks

  1. Open the Network Policy Server console, double-click Policies, and then double-click Network Policies.

  2. Double-click the policy for which you want to enable client health checks. The policy properties dialog box opens. Click the Constraints tab.

  3. In Constraints, ensure that Authentication Methods is selected.

  4. In the details pane, select the Perform machine health check only check box.

Additional considerations

For DHCP and IPsec NAP deployments, when NPS receives a request for a client health check that does not include the User Name attribute and the Identity Type condition is configured in NPS network policy with a value of Computer health check, the request matches the policy and, if all other conditions and constraints configured in the policy are also matched, the policy settings are applied.

For more information, see Network Policy Conditions Properties.


Audit Online Responder Operations

You can monitor the operations of an Online Responder by logging events to the Windows security event log. The Online Responder allows the configuration of the following audit events:

  • Start/Stop the Online Responder Service. Every Start/Stop event of the Online Responder service will be logged.

  • Changes to the Online Responder configuration. All Online Responder configuration changes, including audit settings changes, will be logged.

  • Changes to the Online Responder security settings. All changes to the Online Responder service request and management interfaces access control list (ACL) will be logged.

  • Requests submitted to the Online Responder. All requests processed by the Online Responder service will be logged. This option can create a high load on the service and should be evaluated on an individual basis. Note that only requests that require a signing operation by the Online Responder will generate and audit events; requests for previously cached responses will not be logged.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To enable auditing of Online Responder operations

  1. Open the Online Responder snap-in, and select the Online Responder.

  2. Click Responder Properties on the Action menu, or click Responder Properties in the Action pane.

  3. Click the Audit tab, select the Online Responder audit options that you want to have logged, and then click OK.

Audit events will be logged to the Windows security log only if the Audit object access policy is enabled.

You must be an administrator on the server hosting the Online Responder to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To enable the Audit object access policy

  1. Open the Local Group Policy Editor.

  2. Under Computer Configuration, expand Windows Settings, Security Settings, and Local Policies, and then click Audit Policy.

  3. Double-click the Audit object access policy.

  4. Select the Success and Failure check boxes, and click OK.

Additional references

  • Managing Online Responders

  • Audit Revocation Configuration Changes


Client Computer Configuration

Client Computer Configuration

The following topics provide information about configuring access clients for use with Network Policy Server (NPS).

  • 802.1X Client Configuration with Group Policy

  • Deploy Client Computer Certificates

  • NAP Clients


Managing a Revocation Configuration

A revocation configuration includes all of the settings that are needed to respond to certificate status requests that have been issued by using a specific certification authority (CA) key. These configuration settings include the CA certificate, the signing certificate for the Online Responder, and the type of revocation provider to use.

Procedures are available to complete the following revocation management tasks:

  • Audit Revocation Configuration Changes

  • Manage Online Responder Security

  • Manage Revocation Data by Using Local CRLs

  • Delete a Revocation Configuration


Basic Constraints

Certification authorities (CAs) must have a certificate before they can issue certificates. They use the private key associated with this certificate to digitally sign issued certificates. When a CA obtains a certificate from another CA, the parent CA may want to control whether that certificate can be used to issue certificates to other certificate servers. This is a basic constraint.

Basic constraints are used to ensure that a certificate is only used in certain applications. An example is the path length that can be specified as a basic constraint.

The following procedure only works with certificate templates that issue certificates that sign other certificates, such as cross-certified CAs and root CAs.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To change basic constraints

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

  3. On the Extensions tab, click Basic Constraints, and then click Edit.

  4. In Edit Basic Constraints Extension, provide the requested information.

Additional considerations

  • This procedure is applicable to version 2 and version 3 templates. For more information, see Certificate Template Versions.

Additional references

  • Certificate Template Extensions


Request Handling

The Request Handling tab defines the purpose of a certificate template, the supported cryptographic service providers (CSPs), minimum key length, exportability, autoenrollment settings, and whether strong private key protection should be required.

Certificate purpose

The certificate purpose defines the intended primary use of the certificate and can be one of four settings as described in the following table.

Setting | Purpose
Encryption | Contains cryptographic keys for encryption and decryption.
Signature | Contains cryptographic keys for signing data only.
Signature and encryption | Covers all primary uses of a certificate's cryptographic key, including encryption of data, decryption of data, initial logon, or digitally signing data.
Signature and smart card logon | Allows for initial logon with a smart card, and to digitally sign data; it cannot be used for data encryption.
Note

Key archival is only possible if the certificate purpose is set to Encryption or Signature and encryption.

Archive settings

Windows Server® 2008 and Windows Server 2003–based certification authorities (CAs) can archive a subject's keys in their databases when certificates are issued. If subjects lose their keys, the information can be retrieved from the database and securely provided to the subjects.

The key archival settings in the following table are defined in the Request Handling tab.

Setting | Purpose
Archive subject's encryption private key | If the issuing CA is configured for key archival, the subject's private key will be archived.
Allow private key to be exported | The subject's private key can be exported for backup or transportation.
Deleting revoked or expired certificates (do not archive) | If a certificate is renewed due to expiration or revocation, the previously issued certificate is removed from the subject's certificate store. By default, the certificate is archived.
Include symmetric algorithms allowed by the subject | When the subject requests the certificate, a list of supported symmetric algorithms can be supplied by the subject. This option allows the issuing CA to include those algorithms in the certificate, even if they are not recognized or supported by that server.

User input settings

The Request Handling tab also allows several user input settings described in this table to be defined for a certificate template.

Setting | Purpose
Enroll subject without requiring any user input | This option allows autoenrollment without any user interaction and is the default setting for both computer and user certificates.
Prompt the user during enrollment | By disabling this option, users do not have to provide any input for the installation of a certificate based on the certificate template.
Prompt the user during enrollment and require user input when the private key is used | This option enables the user to set a strong private key protection password on the user's private key when the key is generated and requires the user to use it whenever the certificate and private key are used.

Other version 3 request handling settings

The Request Handling tab for version 3 certificate templates has been updated to provide support for the new options available on the Cryptography tab, along with other changes. The options are listed in the following table.

Setting | Purpose
Use advanced Symmetric algorithm to send the key to the CA | This option allows the administrator to choose the Advanced Encryption Standard (AES) algorithm to encrypt private keys while they are transferred to the CA for key archival. If this option is selected, the client will use AES-256 symmetric encryption (along with the CA's exchange certificate for asymmetric encryption) to send the private key to the CA for archival. If this option is not selected, the 3DES symmetric algorithm is used. Because key archival is intended for encryption keys (not signing keys), this option is enabled only when the certificate purpose is set to Encryption.
Add Read permissions to Network Service on the private key | For computer certificate templates, this option grants Read permissions to Network Service for the certificate's private key on the computer to which the certificate is issued. This enables services such as the Online Responder and Internet Information Services (IIS) to use certificates and keys issued to the computer on which they run. In previous versions of Windows, these permissions had to be configured manually.

For more information about options associated with version 3 certificate templates, see Cryptography.

Other version 2 request handling settings

In addition to key archival settings, you can define general options that affect all certificates based on version 2 certificate templates. The options are listed in the following table.

Setting | Purpose
Minimum key size | This specifies the minimum size, in bits, of the key that will be generated for this certificate.
Cryptographic service providers | This is a list of cryptographic service providers (CSPs) that will be used to enroll certificates for the given template. Selecting one or more CSPs configures the certificate to only work with those CSPs. The CSP must be installed on the client computer for the CSP to be used during enrollment. If a specific CSP is chosen and not available on a client computer, enrollment will fail.

Additional references

  • Configuring a Certificate Template


Audit Revocation Configuration Changes

You can monitor changes to revocation configurations by logging events to the Windows security event log. The Online Responder allows the configuration of the following revocation configuration–related audit events:

  • Changes to the Online Responder configuration. All Online Responder configuration changes, including audit settings changes, will be logged.

  • Changes to the Online Responder security settings. All changes to the Online Responder service request and management interfaces access control list (ACL) will be logged.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To configure auditing of changes to revocation configurations

  1. Open the Online Responder snap-in, and select the Online Responder.

  2. Click Responder Properties on the Action menu, or click Responder Properties in the Action pane.

  3. Click the Audit tab, select the Online Responder audit options that you want to have logged, and then click OK.

Audit events will be logged to the Windows security log only if the Audit object access policy is enabled.

You must be an administrator on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To enable the Audit object access policy

  1. Open the Local Group Policy Editor.

  2. Under Computer Configuration, expand Windows Settings, Security Settings, and Local Policies, and then click Audit Policy.

  3. Double-click the Audit object access policy.

  4. Select the Success and Failure check boxes, and click OK.

Additional references

  • Managing a Revocation Configuration

  • Manage Online Responder Security

  • Manage Revocation Data by Using Local CRLs

  • Delete a Revocation Configuration

  • Audit Online Responder Operations


Add OCSP Locations to Issued Certificates

The location of an Online Responder is specified as a URL in the authority information access extension in a certificate. When a CA issues a certificate, it adds the authority information access extension to the certificate; when a client needs to check the revocation status of a certificate, it will send the certificate status request to this URL.

The OCSP Properties tab allows you to add Online Responder URLs to previously issued certificates that did not contain an authority information access extension. If an organization adds an Online Responder to an existing public key infrastructure (PKI), this setting allows you to use OCSP responses for existing certificates, eliminating the need to reissue the certificates. When you add an OCSP download location for a root or intermediate CA certificate, that location will be used to retrieve the OCSP response for all certificates issued by that particular CA.

Note

The OCSP download locations added through the OCSP Properties tab are checked before any download locations that already exist in a certificate. If you need to add a placeholder URL, use the following address: http://localhost.

Additional references

  • Managing Online Responders


Application Policy

Application policies give you the important ability to decide which certificates can be used for certain purposes. This allows you to issue certificates widely without being concerned that they are used for an unintended purpose.

Application policies are settings that inform a target that the subject holds a certificate that can be used to perform a specific task. They are represented in a certificate by an object identifier (also known as an OID) that is defined for a given application. This object identifier is included in the issued certificate. When a subject presents its certificate, the certificate can be examined by the relying party to verify the application policy and determine if the subject can perform the requested action.

Application policies are sometimes called extended key usage or enhanced key usage. Because some implementations of public key infrastructure (PKI) applications cannot interpret application policies, both application policies and enhanced key usage sections appear in certificates issued by a Windows Server–based certification authority (CA). The following table lists some commonly used application policies.

Purpose | Object Identifier
Client Authentication | 1.3.6.1.5.5.7.3.2
CA Encryption Certificate | 1.3.6.1.4.1.311.21.5
Smart Card Logon | 1.3.6.1.4.1.311.20.2.2
Document Signing | 1.3.6.1.4.1.311.10.3.12
File Recovery | 1.3.6.1.4.1.311.10.3.4.1
Key Recovery | 1.3.6.1.4.1.311.10.3.11
Microsoft Trust List Signing | 1.3.6.1.4.1.311.10.3.1
Qualified Subordination | 1.3.6.1.4.1.311.10.3.10
Root List Signer | 1.3.6.1.4.1.311.10.3.9

The ability to modify or create new application policies is only available with version 2 and version 3 certificate templates. For more information, see Default Certificate Templates.

Clients must be re-enrolled to receive a certificate based on a modified template if they already have a valid certificate based on the previous template. For more information about re-enrolling clients, see Re-Enroll All Certificate Holders.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To add an application policy

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

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

  4. In Edit Application Policies Extension, click Add.

  5. In Add Application Policy, click the application policy that you want to add, and then click OK.

The application policy that you want may not be available. In this case, you can create a new application policy.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To create an application policy

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.

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

  4. In Edit Application Policies Extension, click Add.

  5. In Add Application Policy, click New.

  6. Provide the requested information.

Additional references

  • Certificate Template Extensions

  • Make Issuance or Application Policy Critical


View the Certificates in a PKCS #7 file

If multiple certificates are exported and saved as PKCS #7 files, or if some time has passed since the file was created, it may not be obvious what certificates a PKCS #7 file contains. The following procedure allows you to inspect the certificates contained in a PKCS #7 file.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To view the certificates in a PKCS #7 file

  1. Open Windows Explorer.

  2. Locate the PKCS #7 file in which you want to view the certificates.

  3. In the details pane, right-click the PKCS #7 file and then click Open. Certificates.

  4. In the console tree, double-click the folder containing the PKCS #7 file, and then click Certificates. The certificates contained in the PKCS #7 file are displayed in the details pane.

Additional considerations

  • A PKCS #7 file typically has a .p7b file name extension, but this is not always the case. As with any other data file, the creator of the file has control over the name and whether or not the .p7b extension is used.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


View Certificates

Certificates can be issued and used for many purposes. It can be useful to examine certificate stores, certificate information and properties, and information about archived and revoked certificates.

  • Display Certificate Stores

  • View Certificate Information

  • View Certificate Properties

  • View the Certificates in a PKCS #7 file

  • Display Archived Certificates

  • View Certificate Revocation List Details


Certificate Validity Periods

The Certificates snap-in enables you to renew a certificate issued from a Windows enterprise certification authority before or after the end of its validity period by using the Certificate Renewal Wizard.

About certificate validity

Every certificate has a validity period. After the end of the validity period, the certificate is no longer considered an acceptable or usable credential.

You can renew the certificate either with the same key set that you used before, or with a new key set.

Before you renew a certificate, you must know the issuing certification authority.

  • Optionally, if you want a new public key and private key pair for the certificate, you must know the cryptographic service provider (CSP) that should be used to generate the key pair.

For more information, see Renew a Certificate with a New Key and Renew a Certificate with the Same Key.

In addition, you can renew certificates issued from both enterprise certification authorities and stand-alone certification authorities with the Certificate Services Web pages by pasting in the contents of a PKCS #7 file. For more information, see Request a Certificate Using a PKCS #10 or PKCS #7 File.


Delete a Certificate Template

You can delete a certificate template when you no longer want it to be available for use. When you delete a certificate template, certificates based on the template can no longer be issued. If you are using enterprise certification authorities (CAs), this will affect all CAs in a forest. Certificate templates cannot be recovered once they are deleted.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To delete a certificate template

  1. Open the Certificate Templates snap-in.

  2. Right-click the template you want to delete, and then click Delete.

  3. Click Yes to confirm that you want to delete the template.

Additional references

  • Managing Certificate Templates


Back Up a Certificate With Its Private Key

Certificates are important credentials. Their loss or corruption can cause serious harm. Such harm can come from delays in authenticating your identity to an inability to retrieve encrypted data. You can back up certificates to protect them from loss or corruption, or to move them to a different computer.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To export a certificate with the private key

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Do one of the following:

    • If you are in Logical Certificate Stores view mode, in the console tree, click Certificates.

    • If you are in Certificate purpose view mode, in the console tree, click Purpose.

  3. In the details pane, click the certificate you want to export.

  4. On the Action menu, point to All Tasks, and then click Export.

  5. In the Certificate Export Wizard, click Yes, export the private key. (This option will appear only if the private key is marked as exportable and you have access to the private key.)

  6. Under Export File Format, select one of the available certificate file-format options. Also, do one or all of the following, if available, and then click Next.

    • To include all certificates in the certification path, select the Include all certificates in the certification path if possible check box.

    • To include all extended properties of the certificate, select Export all extended properties.

    • To delete the private key if the export is successful, select the Delete the private key if the export is successful check box.

  7. If required, In Password, type a password to encrypt the private key you are exporting. In Confirm password, type the same password again, and then click Next.

  8. In File name, type a file name and path for the PKCS #12 file that will store the exported certificate and private key, click Next, and then click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • Strong protection (also known as iteration count) is enabled by default in the Certificate Export Wizard when you export a certificate with its associated private key.

  • Strong protection is not compatible with older applications.

  • After the Certificate Export Wizard is finished, the certificate will remain in the certificate store in addition to being in the newly-created file. If you want to remove the certificate from the certificate store, you will need to delete it.


Autoenroll for a Certificate from the Certificates Snap-in

Many organizations will use Group Policy to automatically enroll users, computers, or services for certificates. With automatic enrollment, a user might see a reminder with a prompt to complete the enrollment. However, there might also be times when a user or administrator wants to verify that all pending automatic enrollment requests are processed. The following procedure describes how to complete this task.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To process automatic enrollment for certificates for a local user or computer

  1. Open the Certificate snap-in for a user or computer.

  2. In the console tree, click Certificates - Current User or Certificates (Local Computer).

  3. On the Action menu, point to All Tasks, and then click Automatically Enroll Certificates.

  4. Click Next. Select the certificates that you want to obtain, and then click Enroll. When the enrollment process is complete, click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC

Additional references

  • Obtain a Certificate


Set Up and Use a Smart Card Enrollment Station

A smart card enrollment station allows a designated employee or agent to issue smart cards from one centralized workstation or from one of any number of designated workstations. Designating enrollment stations and agents simplifies the physical preparation of the card to be issued, reduces the chance for certificate service interruption, and prevents users and managers from validating their own identification and issuing their own certificates, especially for organizations or environments in which different levels of security and access exist.

Prepare a smart card certificate enrollment station

Before requesting smart card logon certificates for users:

  • The enrollment agent and smart card logon or smart card user certificates must be configured and enabled for the certification authority (CA).

  • If desired, enrollment agent restrictions must be configured.

  • The enrollment agent has to be enrolled on behalf of other users for the enrollment agent certificate.

  • On the computer that you will use to set up smart cards, follow the manufacturer's instructions to install a smart card reader.

The following procedures explain how to enroll for smart card certificates on behalf of other users and how to prepare the enrollment station once the Enrollment Agent certificate is available.

Membership in the Users group and an Enrollment Agent certificate are the minimum requirements to complete this procedure.

To enroll for a certificate on behalf of other users

  1. Open the Certificates snap-in for a user.

  2. To confirm that you are in Logical certificate stores view, right-click Certificates - Current User, point to View, click Options, verify that Logical certificate stores is selected, and then click OK.

  3. In the console tree, expand the Personal store, and then click Certificates.

  4. On the Action menu, point to All Tasks, click Advanced Operations, and then click Enroll on behalf of to open the Certificate Enrollment Wizard. Click Next.

  5. Browse to the Enrollment Agent certificate that you will use to sign the certificate request that you are processing. Click Next.

  6. Select the type of certificate that you want to enroll for. When you are ready to request a certificate, click Enroll.

  7. After the Certificate Enrollment Wizard has successfully finished, click Close.

To complete the following procedure, you must be logged on as a domain user with appropriate privileges to add snap-ins.

To prepare a smart card certificate enrollment station

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

  2. On the File menu, click Add/Remove Snap-in, and then click Add.

  3. In Snap-in, double-click Certificates.

  4. Click My user account, and then click Finish.

  5. Click Close, and then click OK.

  6. Double-click Certificates - Current User.

  7. In the console tree, click Personal.

  8. On the Action menu, point to All Tasks, and then click Request New Certificate.

  9. In the Certificate Enrollment Wizard, click the Enrollment Agent certificate template and provide the requested information.

  10. When prompted by the Certificate Enrollment Wizard, click Install Certificate.

Additional considerations

  • You can install the Enrollment Agent certificate on a smart card. To do this, you must use the smart card manufacturer's cryptographic service provider (CSP) when requesting the certificate. (In the Certificate Request Wizard, click Advanced Options to select a smart card CSP for the Enrollment Agent certificate.)

  • Once someone has an Enrollment Agent certificate, that person can enroll for a certificate and generate a smart card on behalf of anyone in the organization. The resulting smart card could then be used to log on to the network and impersonate the real user. Therefore, it is recommended that your organization maintain very strong security policies to restrict the use of Enrollment Agent certificates.

These tasks can be performed on any computer running Windows Vista or a Windows Server® 2008 member server that you want to use as a smart card certificate enrollment station.

Additional references

  • To configure an enrollment agent certificate template for issuance from a CA, see Managing Certificate Templates.

  • To configure a restricted enrollment agent, see Establish Restricted Enrollment Agents.


Configure Network Policies

Configure Network Policies

The following topics demonstrate how to configure network policies in NPS.

  • Add a Network Policy

  • Add a Condition to a Network Policy

  • Add a Constraint to a Network Policy

  • Add a Setting to a Network Policy

  • Configure a Network Policy to Grant or Deny Access

  • Create Policies for Dial-Up or VPN with a Wizard

  • Create policies for 802.1X Wired or Wireless with a Wizard


Create a Group for a Network Policy

You can use this procedure to create a user or computer group in Active Directory® Domain Services (AD DS) and then add the group as a condition in a Network Policy Server (NPS) network policy.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

Create a group for a network policy

To create a group for a network policy

  1. Open the Active Directory Users and Computers console, and then click the domain where you want to create a group.

  2. To create a group whose members are computers, in the details pane, right-click Computers, click New, and then click Group. To create a group whose members are users, in the details pane, right-click Users, click New, and then click Group. The New Object - Group dialog box opens.

  3. In New Object - Group, in Group name, type a name for the group.

  4. In Group scope, select Domain local, Global, or Universal.

  5. In Group type, ensure that Security is selected, and then click OK.

  6. Double-click either Computers or Users, depending on where you created your group, and then double-click the group you created to open group properties.

  7. In group properties, click the Members tab, and then click Add. The Select Users, Contacts, Computers, or Groups dialog box opens.

  8. In Select Users, Contacts, Computers, or Groups, in Enter the object names to select, type the object names that you want to add to the group, and then click OK twice.

  9. Open the Network Policy Server console and double-click Policies. Right-click Network Policies, and then click New. The New Network Policy wizard opens.

  10. Run the wizard, making selections appropriate to your deployment, until you reach the Specify Conditions page.

  11. In Specify Conditions, click Add. The Select condition dialog box opens. If you created a group of computers, click Machine Groups. If you created a group of users, click User Groups. Click Add. The Windows Groups dialog box opens. Click Add Groups.

  12. The Select Group dialog box opens. In Enter the object name to select, type the name of the group that you created in AD DS, and then click OK.

  13. Configure additional conditions for your deployment as needed, and then continue running the New Network Policy wizard until you have completed creating a new network policy.
Note

To add a group as a condition of an existing network policy, see Add a Condition to a Network Policy.


Install the Certificate Templates Snap-In

The Certificate Templates snap-in allows you to view and manage critical information about all the certificate templates in a domain.

Important fields in the Certificate Templates snap-in include:

  • Template Display Name. This field describes the purpose of the certificate. When an organization creates a custom certificate template, it may be useful to use a naming convention that helps administrators identify the certification authority (CA) or portion of the organization associated with the template.

  • Minimum Supported CAs. The configurable options in Windows-based certificate templates have been expanded from Windows 2000 to Windows Server 2003 and in Windows Server® 2008. Therefore, not all certificate templates are supported by all Windows Server–based CAs.

  • Version. If certificate template configurations evolve over time, the ability to track version information becomes important for compatibility and support.

You must be a local administrator to install the Certificate Templates snap-in and a member of Domain Admins to use the Certificate Templates snap-in. For more information, see Implement Role-Based Administration.

To install the Certificate Templates snap-in

  1. Click Start, click Run, and then type mmc.

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

  3. On the Add and Remove Snap-ins dialog box, double-click the Certificate Templates snap-in to add it to the list. Click OK.

By default, the Certificate Templates snap-in is installed automatically when a CA is installed on a server. The Certificate Templates snap-in can be installed on a different server by using Server Manager to install Active Directory Certificate Services (AD CS) tools.

You must be local administrator to install Remote Server Administration Tools. You must be a member of Domain Admins to access and administer certificate templates for a domain. For more information, see Implement Role-Based Administration.

To administer certificate templates from a remote server

  1. Open Server Manager.

  2. Under Features Summary, click Add Features.

  3. Expand Remote Server Administration Tools and Role Administration Tools.

  4. Select the Active Directory Certificate Services check box, click Next, and then click Install.

  5. When the installation process is finished, click Close.

  6. Click Start, type mmc, and press ENTER.

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

  8. Click the Certificate Templates snap-in, click Add, verify that the domain controller hosting the certificate templates you want to manage is selected, and then click OK.

You can use the Certificate Templates snap-in to manage certificate templates in a different domain.

You must be a domain or enterprise administrator for the other domain to complete this procedure. For more information, see Implement Role-Based Administration.

To manage certificate templates in a different domain

  1. Right-click the Certificate Templates snap-in, and click Connect to another writable domain controller.

  2. To type the name of a different domain, click Change. To select a different domain controller for the existing domain, click Select a Writable Domain Controller.

  3. If you have previously selected an alternate domain controller, you can revert to the original domain controller by clicking Default Writable Domain Controller.

Additional references

  • Managing Certificate Templates


Host Credential Authorization Protocol

Host Credential Authorization Protocol (HCAP)

Host Credential Authorization Protocol (HCAP) allows you to integrate your Microsoft Network Access Protection (NAP) solution with Cisco Network Admission Control. When you deploy HCAP with Network Policy Server (NPS) and NAP, NPS can perform the authorization of Cisco 802.1X access clients, including the enforcement of NAP health policy, while Cisco authentication, authorization, and accounting (AAA) servers perform authentication.

To deploy a HCAP server, you must do the following:

  1. Deploy NAP-capable client computers. Configure client computers to use Cisco EAP-FAST as the authentication method for network access.

  2. Using NAP deployment documentation, deploy NAP, which includes configuring client computers with system health agents (SHAs) and NPS servers with the corresponding system health validators (SHVs).

  3. Using Cisco deployment documentation, deploy Cisco Network Admission Control.

  4. Using the Add Roles wizard from Server Manager, install HCAP server. HCAP server is a role service of the Network Policy and Access Services server role. When you install HCAP server, the additional required components, Internet Information Services (IIS) and NPS, are installed on the same computer. In addition, a server certificate is autoenrolled to the server running IIS to allow Secure Sockets Layer (SSL) connections between IIS and the Cisco AAA server.

  5. Configure IIS to listen to specified IP addresses to allow Cisco AAA servers to send authorization requests.

  6. Configure the Cisco AAA server with the URL of the server running HCAP, NPS, and IIS so that the Cisco AAA server can send authorization requests to NPS.

  7. Configure NPS on the HCAP server as a RADIUS proxy to forward authorization requests to NPS servers that are members of one or more remote RADIUS server groups. Optionally, you can configure NPS on the HCAP server as a RADIUS server to process authorization requests locally.

  8. Configure NPS servers as RADIUS servers to perform authorization, which includes deploying NAP and creating health policy in NPS. If the NPS-HCAP server is a RADIUS proxy that forwards connection requests to NPS RADIUS servers in remote RADIUS server groups, you must configure the RADIUS proxy as a RADIUS client on each RADIUS server.

  9. On NPS RADIUS servers, configure network policy with NAP health policy. If desired, network policy conditions can include HCAP-Group-Name and HCAP-Location-Group for NAP interoperability with Cisco Network Admission Control. In addition, you can use the Extended State condition in network policy to specify the extended state of the client computer that is required to match the network policy. Extended states are elements of Cisco Network Admission Control, and include Transitional, Infected, and Unknown. By using this network policy condition, you can configure NPS to authorize or reject access based on whether the client computer is in one of these states.

Authentication and authorization process

After deploying both Cisco Network Admission Control and NPS with NAP, the authentication and authorization process works as follows:

  1. The client computer attempts to access the network. The client can attempt to connect through an 802.1X authenticating switch or through an 802.1X wireless access point that is configured as a RADIUS client to the Cisco AAA server. In addition, a router can send a connection request to the Cisco AAA server using Extensible Authentication Protocol (EAP) over User Datagram Protocol (UDP).

  2. After the Cisco AAA server receives the connection request from the network access server or router, the Cisco AAA server requests statement of health (SoH) data from the client by sending an EAP-Type Length Value (EAP-TLV).

  3. SHAs on the client computer report health status to NAP agent on the client, and NAP agent creates a SoH, which it sends to the Cisco AAA server.

  4. The Cisco AAA server forwards the SoH using HCAP to the NPS proxy or server along with the client computer's user ID, machine ID, and location.

  5. If the NPS-HCAP server is configured as a RADIUS proxy, NPS forwards the authorization request to the appropriate remote RADIUS server group. (This determination is made with the evaluation by NPS of the configured connection request policies.) If the NPS-HCAP server is configured as a RADIUS server, the NPS-HCAP server processes the authorization request.

  6. NPS evaluates the SoH against configured network policy and, if a matching network policy is found, creates a statement of health response (SoHR) to be sent back to the client. This, along with the NAP enforcement state and extended state information, is then sent back to the Cisco AAA server using HCAP.

  7. The Cisco AAA server evaluates the NAP enforcement state against Cisco Network Admission Control policy and determines the network access profile.

  8. The Cisco AAA server sends the network access profile to the network access server (the switch, AP, or router). The network access profile contains the information that instructs the network access server whether to allow full access, restrict access, or deny access to the client computer.

  9. The Cisco AAA server sends the SoHR back to the client computer.

  10. If the client configuration does not comply with health policy and the SoHR instructs the client to remediate, then the client attempts to take the required actions, such as downloading software updates or changing configuration settings. After remediation, the client attempts to access the network again, and the authentication and authorization process is repeated.

See Also

  • Network Access Protection in NPS
  • EAP Overview
  • RADIUS Clients
  • RADIUS Proxy
  • RADIUS Server


Delete a Revocation Configuration

Revocation configurations are versatile and can be modified at any time, unless the changes would conflict with settings on the Array controller. However, there may be times when you need to delete a revocation configuration. For example:

  • The CA certificate has expired and the revocation configuration is no longer needed.

  • The revocation configuration becomes corrupted and it would be easier to install a completely new revocation configuration in place of the corrupted revocation configuration.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To delete a revocation configuration for an Online Responder

  1. Open the Online Responder snap-in.

  2. In the console tree, click Revocation Configuration.

    A list of existing revocation configurations appear in the details pane.

  3. Right-click the revocation configuration that you want to delete, and then click Delete.

Additional references

  • Managing a Revocation Configuration

  • Audit Revocation Configuration Changes

  • Manage Online Responder Security

  • Manage Revocation Data by Using Local CRLs


Create Policies for Dial-Up or VPN with a Wizard

Create policies for dial-up or VPN with a wizard

You can use this procedure to create the connection request policies and network policies required to deploy either dial-up servers or virtual private network (VPN) servers as RADIUS clients to the NPS RADIUS server.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

This procedure explains how to start the New Dial-up or Virtual Private Network Connections wizard in NPS.

After you run the wizard, the following policies are created:

  • One connection request policy

  • One network policy

Running the New Dial-up or Virtual Private Network Connections wizard is not the only step required to deploy dial-up or VPN servers as RADIUS clients to the NPS server. Both network access methods require that you deploy additional hardware and software components.

Note

You can run the New Dial-up or Virtual Private Network Connections wizard every time you need to create new policies for dial-up servers and VPN servers.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To create policies for dial-up or VPN with a wizard

  1. Open the NPS console. If it is not already selected, click NPS (Local). If you are running the NPS MMC snap-in and want to create policies on a remote NPS server, select the server.

  2. In Getting Started and Standard Configuration, use the combination box to select RADIUS server for Dial-Up or VPN Connections. The text and links under the text change to reflect your selection.

  3. Click Configure VPN or Dial-Up with a wizard. The New Dial-up or Virtual Private Network Connections wizard opens.


NAP Enforcement for DHCP

NAP enforcement for DHCP

DHCP enforcement is deployed with a DHCP Network Access Protection (NAP) enforcement server component, a DHCP enforcement client component, and Network Policy Server (NPS). Using DHCP enforcement, DHCP servers and NPS can enforce health policy when a computer attempts to lease or renew an IP version 4 (IPv4) address. However, if client computers are configured with a static IP address or are otherwise configured to circumvent the use of DHCP, this enforcement method is not effective.

Note

Health validation data that is stored in DHCP is visible to other computers. However, the DHCP enforcement client sends a statement of health (SoH) only if the SoH is requested by the DHCP server.

Requirements

To deploy NAP with DHCP, you must configure the following:

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Enable the NAP DHCP enforcement client and the NAP service on NAP-capable client computers.

  • Install DHCP on the local computer or on a remote computer.

  • In the DHCP MMC snap-in, enable NAP for individual scopes or for all scopes configured on the DHCP server.

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

If DHCP is not installed on the local computer, you must also configure the following:

  • Install NPS on the computer that is running DHCP.

  • Configure NPS on the remote DHCP NPS server as a RADIUS proxy to forward connection requests to the local NPS server.


CA Certificates

Certification authority (CA) certificates are certificates that are issued by a CA to itself or to a second CA for the purpose of creating a defined relationship between the two CAs.

A certificate that is issued by a CA to itself is referred to as a trusted root certificate, because it is intended to establish a point of ultimate trust for a CA hierarchy.

Once the trusted root has been established, it can be used to authorize subordinate CAs to issue certificates on its behalf.

CA certificates can also be used to establish trust relationships between CAs in two different public key infrastructure (PKI) hierarchies.

In all of these cases, the CA certificate is critical to defining the certificate path and usage restrictions for all end-entity certificates issued for use in the PKI.

The appropriate configuration of CA certificates for the organization's needs is one of the most powerful tools that an organization has to implement appropriate PKI security. CA certificates contain special configuration data that regulate the CAs to which they are issued. These configuration options can:

  • Define the organizational namespace in which certificates issued by the subordinate CA can be issued and trusted.

  • Specify the acceptable uses of certificates issued by the subordinate CA.

  • Define the issuance guidelines that must be followed in order for a certificate issued by the subordinate CA to be considered valid.

  • Create a managed trust between separate certification hierarchies.


Learn More About Certificate Stores

Windows stores a certificate locally on the computer or device that requested it or, in the case of a user, on the computer or device that the user used to request it. The storage location is called the certificate store. A certificate store often has numerous certificates, possibly issued from a number of different certification authorities.

You can view certificates based on their purpose, such as Client Authentication, Code Signing, and so on; or based on logical roles, such as Personal, Trusted Publishers, Trusted Root Certification Authorities, and so on.

In addition, you can also use certificate store options to view archived certificates and the certificate stores storage structure.

Additional references

  • Display Certificate Stores in Logical Store Mode

  • Display Certificate Stores in Purpose Store Mode


802.1X Client Configuration with Group Policy

802.1X client configuration with Group Policy

  • Configure 802.1X Wired Clients Running Windows Vista with Group Policy

  • Configure 802.1X Wireless Clients Running Windows Vista with Group Policy

  • Configure 802.1X Wireless Clients Running Windows XP with Group Policy


Manage Trusted Root Certificates

Because of the growing variety of certificates in use today and the growing number of certificate issues, some organizations may want to manage certificate trust and prevent users in the domain from configuring their own set of trusted root certificates. In addition, some organizations may want to identify and distribute specific trusted root certificates to enable business scenarios where additional trust relationships are needed.

Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To manage trusted root certificates for a local computer

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, click Local Group Policy Object Editor, click Add, select the computer whose local Group Policy object (GPO) you want to edit, and then click Finish.

  4. If you have no more snap-ins to add to the console, click OK.

  5. In the console tree, go to Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  6. Double-click Certificate Path Validation Settings, and then click the Stores tab.

  7. Select the Define these policy settings check box.

  8. Under Per user certificate stores, clear the Allow user trusted root CAs to be used to validate certificates and Allow users to trust peer trust certificates check boxes.

  9. Under Root certificate stores, select the root CAs that the client computers can trust, and then click OK to apply the new settings.

Domain Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To manage trusted root certificates for a domain

  1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the Group Policy Management Console (GPMC) was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  7. Double-click Certificate Path Validation Settings, and then click the Stores tab.

  8. Select the Define these policy settings check box.

  9. Under Per user certificate stores, clear the Allow user trusted root CAs to be used to validate certificates and Allow users to trust peer trust certificates option in the Per User Certificate Stores check boxes.

  10. Under Root certificate stores, select the root CAs that the client computers can trust, and then click OK to apply the new settings.

Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To add certificates to the Trusted Root Certification Authorities store for a local computer

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, click Certificates, and then click Add.

  4. Under This snap-in will always manage certificates for, click Computer account, and then click Next.

  5. Click Local computer, and click Finish.

  6. If you have no more snap-ins to add to the console, click OK.

  7. In the console tree, double-click Certificates.

  8. Right-click the Trusted Root Certification Authorities store.

  9. Click Import to import the certificates and follow the steps in the Certificate Import Wizard.

Domain Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To add certificates to the Trusted Root Certification Authorities store for a domain

  1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the GPMC was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  7. Right-click the Trusted Root Certification Authorities store.

  8. Click Import and follow the steps in the Certificate Import Wizard to import the certificates.

Additional considerations

  • Group Policy options can only be changed by an administrator.


Add a New RADIUS Client

Use this procedure to add a network access server as a RADIUS client in the Network Policy Server (NPS) Microsoft Management Console (MMC) snap-in.

When you configure a network access server (NAS) as a RADIUS client in the NPS MMC snap-in, the RADIUS client forwards connection requests from access clients to the NPS server for authentication, authorization, and accounting.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

In addition to configuring a new RADIUS client, you must also configure the network access server so that it can communicate with NPS. For more information, see your NAS documentation.

To configure a new RADIUS client in NPS, you must run the New RADIUS Client Wizard. While following the steps in the New RADIUS Client Wizard:

  • If your access server supports use of the Message Authenticator attribute (also known as the signature attribute), in the New RADIUS Client Wizard, click Request must contain the Message Authenticator attribute. If the access server does not support the Message Authenticator attribute, do not select this option. Enabling the use of the Message Authenticator attribute provides additional security when PAP, CHAP, MS-CHAP, and MS-CHAP v2 are configured in network policies as authentication methods. EAP uses the Message Authenticator attribute by default and does not require that you enable it.

  • If you use NAS-specific network policies (for example, a network policy that contains vendor-specific attributes), click Client-Vendor, and then select the name of the NAS manufacturer. If you do not know the name of the NAS manufacturer or it is not in the list, select RADIUS Standard.

Note

If NPS receives an access request from a RADIUS proxy, it cannot detect the manufacturer of the NAS that originated the request. This can cause problems if you plan to use network policy conditions that are based on the client vendor and if you have at least one RADIUS client that is a RADIUS proxy. In this case, connection requests that are forwarded to NPS from the RADIUS proxy might not match any of the network policies, causing all connection requests to be denied. For this reason, when you use RADIUS proxies, you must configure at least one network policy that is not based on NAS-specific attributes, such as the vendor-specific attribute.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To add a new RADIUS client using the Windows interface

  1. Open the NPS MMC snap-in, and then double-click RADIUS Clients and Servers.

  2. Right-click RADIUS Clients, and then click New RADIUS Client.

  3. Follow the steps in the New RADIUS Client Wizard.


Manage Trusted Publishers

Software signing is being used by a growing number of software publishers and application developers to verify that their applications come from a trusted source. However, many users do not understand or pay little attention to the signing certificates associated with applications that they install.

The policy options in the Trusted Publishers tab of the Certificate Path Validation policy allows administrators to control which certificates can be accepted as coming from a trusted publisher.

Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To configure the Trusted Publishers policy for a local computer

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, click Local Group Policy Object Editor, click Add, and then click Finish.

  4. If you have no more snap-ins to add to the console, click OK.

  5. In the console tree, go to Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  6. Double-click Certificate Path Validation Settings, and then click the Trusted Publishers tab.

  7. Select the Define these policy settings check box, implement the changes you want, and then click OK to apply the new settings.

Domain Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To configure the Trusted Publishers policy for a domain

  1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the Group Policy Management Console (GPMC) was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  7. Double-click Certificate Path Validation Settings, and then click the Trusted Publishers tab.

  8. Select the Define these policy settings check box, implement the changes you want, and then click OK to apply the new settings.

Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To allow only administrators to manage certificates used for code signing for a local computer

  1. Click Start, click Start Search, type mmc, and then press ENTER.

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

  3. Under Available snap-ins, click Local Group Policy Object Editor, click Add, and then click Finish.

  4. If you have no more snap-ins to add to the console, click OK.

  5. In the console tree, go to Default Domain Policy or Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  6. Double-click Certificate Path Validation Settings, and then click the Trusted Publishers tab.

  7. Select the Define these policy settings check box.

  8. Under Trusted publisher management, click Allow only all administrators to manage Trusted Publishers, and then click OK to apply the new settings.

Domain Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To allow only administrators to manage certificates used for code signing for a domain

  1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the GPMC was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  7. Double-click Certificate Path Validation Settings, and then click the Trusted Publishers tab.

  8. Select the Define these policy settings check box, implement the changes you want, and then click OK to apply the new settings.

Additional considerations

  • Group Policy options can only be changed by an administrator.


Network Access Quarantine Control

Network Access Quarantine Control

Network Access Quarantine Control (NAQC) in Network Policy Server (NPS) provides phased network access for remote client computers by restricting them to a quarantine mode. After the client computer configuration is either brought into or determined to be in compliance with your organization’s network policy, quarantine restrictions, which consist of Quarantine IP-Filters and Session Timers, are removed and standard network policy is applied to the connection.

Note

Network policy in NPS was referred to as remote access policy in earlier product versions.

NAQC provides protection when users in your organization accidentally reconfigure key settings and do not restore them before connecting to your network. For example, a user might disable antivirus software that is required while connected to your network. Although NAQC does not protect against attackers, computer configurations for authorized users can be verified and, if necessary, corrected before they can access the network. A timer setting is also available, which you can use to specify an interval at which the connection is dropped if the client fails to meet configuration requirements.

You can use the Routing and Remote Access service to process the RADIUS options sent by NPS, complete any required client configuration work, and remove the quarantine condition (or drop the connection) based on success or failure.

Important

Network Access Quarantine Control is not the same as Network Access Protection (NAP).

Quarantine mode

Quarantine mode is a set of network restrictions that are configured in network policy and are implemented by the remote access server for each connection.

Note

You can configure network policy in either the Routing and Remote Access service console or the NPS console, depending on whether you are using NPS for your NAQC deployment.

You can use a Quarantine IP Filter to restrict access to a specified set of servers (for example, servers on a virtual LAN) and a Quarantine Session Timer to restrict the amount of time the client can remain connected in quarantine mode. You can set these filters in the NPS console.

Components of Network Access Quarantine Control

You can implement NAQC with one or more servers running Windows Server 2008 and Routing and Remote Access, one or more servers running Windows Server 2008 and NPS, a Connection Manager (CM) profile created with Connection Manager Administration Kit (CMAK), an administrator-provided script or the file quarchk.cmd, and two additional components: the notifier component and the listener component.

The notifier component is a program named rqc.exe that you can include in a CM profile. The listener component can be configured in the Services MMC snap-in after you install Routing and Remote Access.

Important

NPS is an optional component of NAQC. You can deploy NAQC without NPS if you choose to create network policy in Routing and Remote Access. This is practical if you only have one or two virtual private network (VPN) servers. If you have multiple VPN servers, however, it is recommended that you deploy a server running NPS and configure network policy in NPS. This allows you to configure network policy one time in NPS rather than multiple times, once on each VPN server.

You can add rqc.exe to the CM profile for installation on the client computer when the profile is installed. After the administrator-provided script has run successfully on the client computer, rqc.exe notifies the remote access server.

Note

After you install Routing and Remote Access and CMAK, rqc.exe and quarchk.cmd are located at %systemroot%\Program Files\CMAK\Support.

The listener component, named Remote Access Quarantine Agent service, is included when you install Routing and Remote Access. However, the Remote Access Quarantine Agent service is disabled by default. When you deploy NAQC, you must start the Remote Access Quarantine Agent service and change the startup type to automatic.

Note

To configure the Remote Access Quarantine Agent service, install Routing and Remote Access, and then open the Services MMC snap-in. Browse to and double-click the Remote Access Quarantine Agent service.

The Remote Access Quarantine Agent service receives notification from rqc.exe that either quarchk.cmd or the script on the client has successfully performed all configuration checks. After Remote Access Quarantine Agent service receives notification, it removes the client from quarantine mode, and the remote access server applies standard network policy to the client.

Caution

Placing all remote access clients in quarantine mode without a way to remove quarantine policy and apply full access policy might prevent all remote access clients from establishing network connections.

See Also

  • Network Access Protection in NPS
  • Deploying Network Access Quarantine Control
  • Network Access Quarantine Control and NAP


Revocation Configuration

Procedures are available to complete the following revocation management tasks:

  • Audit Revocation Configuration Changes

  • Manage Online Responder Security

  • Manage Revocation Data by Using Local CRLs

  • Delete a Revocation Configuration


Request a Certificate Over the Web

By default, every Windows Server 2003 certification authority (CA) has Web pages available for users and administrators. These can be used to perform a variety of tasks related to requesting certificates. These Web pages are located at http://servername/certsrv, where servername is the name of the server that hosts the CA. The certsrv portion of the URL should always be in lowercase letters; otherwise, users may have trouble checking and retrieving pending certificates.

Important

Windows Server 2003 CA Web pages must be updated before users can access these Web pages by using this version of Windows.

Additional references

If you have been granted access permissions, you can perform the tasks described in the following topics:

  • Submit a Basic User Certificate Request over the Web

  • Submit an Advanced Certificate Request over the Web

  • Request a Certificate Using a PKCS #10 or PKCS #7 File

  • Check on a Pending Certificate Request

  • For more information about updating Windows Server 2003 CA Web pages, search the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=46046) for keywords such as "Web enrollment," "Windows Server 2003 CA," or "Xenroll."

  • Obtain a Certificate


Submit an Advanced Certificate Request over the Web

The policy of a certification authority (CA) determines the types of certificates a user can request and the options they can configure. If enabled, you can use the Advanced Certificate Request Web page to set the following options for each certificate requested:

  • Certificate template (from an enterprise CA) or Type of certificate needed (from a stand-alone CA). Indicates what applications the public key in the certificate can be used for, such as client authentication or e-mail.

  • Cryptographic service provider (CSP). A CSP is responsible for creating keys, destroying them, and using them to perform a variety of cryptographic operations. Each CSP provides a different implementation of the CryptoAPI. Some provide stronger cryptographic algorithms, while others use hardware components, such as smart cards

  • Key size. The length, in bits, of the public key on the certificate. In general, longer keys are harder for a hostile user to break than shorter keys.

  • Hash algorithm. A good hash algorithm makes it computationally infeasible to construct two independent inputs that have the same hash. Typical hash algorithms include MD2, MD4, MD5, and SHA-1.

  • Key usage. How the private key can be used. Exchange means that the private key can be used to enable the exchange of sensitive information. Signature means that the private key can be used only to create a digital signature. Both means that the key can be used for both exchange and signature functions.

  • Create new key set or Use existing key set. You can use an existing public and private key pair stored on your computer or create a new public and private key pair for a certificate.

  • Enable strong private key protection . When you enable strong private key protection, you will be prompted for a password every time the private key needs to be used.

  • Mark keys as exportable. When you mark keys as exportable, you can save the public key and the private key to a PKCS #12 file. This is useful if you change computers and want to move the key pair, or if you want to remove the key pair and secure them in another location.

  • Store certificates in the local computer certificate store. Select this option if the computer will need access to the private key associated with the certificate when other users are logged on. Select this option when requesting certificates intended to be issued to computers (such as Web servers) instead of certificates issued to people.

  • Request format. This section can be used to select either PKCS#10 or CMC formats. If you want to submit the request later, you can also select Save request to file.

Important

Windows Server 2003 CA Web pages must be updated before users can access these Web pages by using this version of Windows.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To submit an advanced certificate request over the Web

  1. Open Internet Explorer.

  2. In Internet Explorer, connect to https://servername/certsrv, where servername is the name of the Web server running Windows Server 2003 where the certification authority that you want to access is located.

  3. Click Request a certificate.

  4. Click advanced certificate request.

  5. Click Create and submit a certificate request to this CA.

  6. Fill in any identifying information requested and any other options you require.

  7. Click Submit.

  8. Do one of the following:

    • If you see the Certificate Pending Web page, see Check on a Pending Certificate Request for the procedure to check on a pending certificate.

    • If you see the Certificate Issued Web page, click Install this certificate.

  9. If you are finished using the Certificate Services Web pages, close Internet Explorer.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • In order for a user to obtain a certificate using Web enrollment, an administrator must set the appropriate permissions on the certificate templates on which the requested certificate is based.

  • If this is the first time you are accessing the Web server for a CA, you must add the server to the list of Trusted sites in Internet Explorer. Trusted sites can be added by selecting Internet Options on the Tools menu, clicking the Security tab, selecting the Trusted sites zone, and clicking Sites. In addition, the Web server for the CA must be configured to use HTTPS authentication.

Additional references

  • Check on a Pending Certificate Request

  • Request a Certificate Over the Web


Network Policy Overview Properties

Network Policy Overview properties

On the Overview tab of a network policy or while running the New Network Policy wizard, you can configure the following:

  • Policy name. Type a friendly name for the network policy.

  • Policy State. Designate whether the policy is enabled or disabled.

  • Access Permission. Designate whether the policy grants or denies access. Also specify whether NPS should ignore the dial-in properties of user accounts in Active Directory Domain Services (AD DS) when using the policy to perform authorization for the connection attempt.

Note

If you have many user accounts in AD DS, it is recommended that you configure the dial-in properties of user accounts to control network access through network policy; however, you can accomplish the same result for individual policies by configuring them to ignore the dial-in properties of user accounts.

  • The network connection method used for the connection request:

    • Unspecified. If selected, NPS evaluates the network policy for all connection requests that originate from any type of network access server and for any connection method. This includes connections from Terminal Services Gateways, servers running Routing and Remote Access service that provide VPN and dial-up access, DHCP servers, 802.1X wireless access points, 802.1X authenticating switches, Health Registration Authority (HRA) servers, and Host Credential Authorization Protocol (HCAP) servers.

    • Remote Access Server (VPN-Dial-up). If specified, NPS evaluates the network policy for connection requests that originate from a computer running the Routing and Remote Access service configured as a dial-up or VPN server. If another dial-up or VPN server is used, the server must support the RADIUS protocol and the authentication protocols provided by NPS for dial-up and VPN connections.

    • Ethernet. If specified, NPS evaluates the network policy for all connection requests that originate from IEEE 802.1X authenticating switches.

    • Terminal Services Gateway. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Terminal Services Gateway (TS Gateway).

    • Wireless Access Point. If specified, NPS evaluates the network policy for connection requests that originate from IEEE 802.1X wireless access points that support the RADIUS protocol and Extensible Authentication Protocol (EAP).

    • Health Registration Authority. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Health Registration Authority (HRA).

    • HCAP server. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Host Credential Authorization Protocol (HCAP).

    • DHCP Server. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Dynamic Host Configuration Protocol (DHCP).


Configure Certificate Enrollment

Active Directory Certificate Services (AD CS) supports a variety of enrollment and renewal methods, such as the Certificate Request Wizard and AD CS Web enrollment. However, if you deploy non-Microsoft certification authorities or custom certificate enrollment and renewal applications, you must perform any configuration required for those services and applications.


Access Permission

Access permission

Access permission is configured on the Overview tab of each network policy and allows you to configure the policy to either grant or deny access to users if the conditions and constraints of the network policy are matched by the connection request. Access permission settings have the following effect:

  • Grant access. Access is granted if the connection request matches the conditions and constraints that are configured in the policy.

  • Deny access. Access is denied if the connection request matches the conditions and constraints that are configured in the policy.

Access permission is also granted or denied with the dial-in properties of each user account.

Note

User accounts and their properties, such as dial-in properties, are configured in either the Active Directory Users and Computers or the Local Users and Groups Microsoft Management Console (MMC) snap-in, depending on whether you have Active Directory Domain Services (AD DS) installed.

The user account setting Network Access Permission, which is configured on the dial-in properties of user accounts, overrides the network policy access permission setting. When network access permission on a user account is set to the Control access through NPS Network Policy option, the network policy access permission setting determines whether the user is granted or denied access.

When Network Policy Server (NPS) evaluates connection requests against configured network policies, it performs the following actions:

  • If the conditions of the first policy are not matched, NPS evaluates the next policy, and continues this process until either a match is found or all policies have been evaluated for a match.

  • If the conditions and constraints of a policy are matched, NPS either grants or denies access, depending on the value of the Access permission setting in the policy.

  • If the conditions of a policy match but the constraints in the policy do not match, NPS rejects the connection request.

  • If the conditions of all policies do not match, NPS rejects the connection request.

Ignore user account dial-in properties

You can configure NPS network policy to ignore the dial-in properties of user accounts by selecting or clearing the Ignore user account dial-in properties check box on the Overview tab of network policy. Normally when NPS performs authorization of a connection request, it checks the dial-in properties of the user account, where the network access permission setting value can affect whether the user is authorized to connect to the network. When you configure NPS to ignore the dial-in properties of user accounts during authorization, network policy settings determine whether the user is granted access to the network.

The dial-in properties of user accounts contain the following:

  • Network access permission

  • Caller-ID

  • Callback options

  • Static IP address

  • Static routes

To support multiple types of connections for which NPS provides authentication and authorization, it might be necessary to disable the processing of user account dial-in properties. This can be done to support scenarios in which specific dial-in properties are not required.

For example, the caller-ID, callback, static IP address, and static routes properties are designed for a client that is dialing into a network access server, not for clients that are connecting to wireless access points. A wireless access point that receives these settings in a RADIUS message from NPS might not be able to process them, which could cause the wireless client to be disconnected.

When NPS provides authentication and authorization for users who are both dialing in and accessing the organization network through wireless access points, the dial-in properties must be configured to support either dial-in connections (by setting dial-in properties) or wireless connections (by not setting dial-in properties).

You can use NPS to enable dial-in properties processing for the user account in some scenarios (such as dial-in) and to disable dial-in properties processing in other scenarios (such as 802.1X wireless and authenticating switch).

You can also use Ignore user account dial-in properties to manage network access control through groups and the access permission setting on the network policy. When you configure Ignore user account dial-in properties with the value of True (selected), network access permission on the user account is ignored.

The only disadvantage to this configuration is that you cannot use the additional user account dial-in properties of caller-ID, callback, static IP address, and static routes.


Configure Remediation Server Groups

Configure remediation server groups

Use this procedure to configure remediation server groups in Network Policy Server (NPS).

A remediation server group is a list of servers on the restricted network that noncompliant NAP clients can access for software updates. Use this procedure to configure a new remediation server group in the NPS console.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To create a new remediation server group using the Windows interface

  1. Open the NPS console.

  2. In the console tree, double-click Network Access Protection, right-click Remediation Server Groups, and then click New. The New Remediation Server Group dialog box opens.

  3. In Group name, type a name for the remediation server group, and then click Add.

  4. In Add New Server, in Friendly name, type a name for the server you want to add.

  5. In Add New Server, in IP address or DNS name, type the IP address or Fully Qualified Domain Name (FQDN) of the remediation server that you want to add. If you type the FQDN of the server, click Resolve to obtain the IP address of the server. Click OK.

  6. If you want to add more remediation servers to the remediation server group, repeat these steps for each server, and then click OK.


Default Certificate Templates

A number of preconfigured certificate templates that are designed to meet the needs of most organizations are included with Windows Server® 2008–based enterprise certification authorities (CAs). These templates are described in the following table.

Name | Description | Key usage | Subject type | Published to Active Directory Domain Services (AD DS)? | Template version
Administrator | Allows trust list signing and user authentication. | Signature and encryption | User | Yes | 1
Authenticated Session | Allows the subject to authenticate to a Web server. | Signature | User | No | 1
Basic EFS | Used by Encrypting File System (EFS) to encrypt data. | Encryption | User | Yes | 1
CA Exchange | Used to store keys that are configured for private key archival. | Encryption | Computer | No | 2
CEP Encryption | Allows the certificate holder to act as a registration authority for Simple Certificate Enrollment Protocol (SCEP) requests. | Encryption | Computer | No | 1
Code Signing | Used to digitally sign software. | Signature | User | No | 1
Computer | Allows a computer to authenticate itself on the network. | Signature and encryption | Computer | No | 1
Cross-Certification Authority | Used for cross-certification and qualified subordination. | Signature | Cross-certified CA | Yes | 2
Directory E-mail Replication | Used to replicate e-mail within AD DS. | Signature and encryption | DirEmailRep | Yes | 2
Domain Controller | Used by domain controllers as all-purpose certificates. | Signature and encryption | DirEmailRep | Yes | 1
Domain Controller Authentication | Used to authenticate Active Directory computers and users. | Signature and encryption | Computer | No | 2
EFS Recovery Agent | Allows the subject to decrypt files that were previously encrypted with EFS. | Encryption | User | No | 1
Enrollment Agent | Used to request certificates on behalf of another subject. | Signature | User | No | 1
Enrollment Agent (Computer) | Used to request certificates on behalf of another computer subject. | Signature | Computer | No | 1
Exchange Enrollment Agent (Offline request) | Used to request certificates on behalf of another subject and supply the subject name in the request. | Signature | User | No | 1
Exchange Signature Only | Used by Microsoft Exchange Key Management Service to issue certificates to Exchange users for digitally signing e-mail. | Signature | User | No | 1
Exchange User | Used by Microsoft Exchange Key Management Service to issue certificates to Exchange users for encrypting e-mail. | Encryption | User | Yes | 1
IPSEC | Used by Internet Protocol security (IPsec) to digitally sign, encrypt, and decrypt network communication. | Signature and encryption | Computer | No | 1
IPSEC (Offline request) | Used by IPsec to digitally sign, encrypt, and decrypt network communication when the subject name is supplied in the request. | Signature and encryption | Computer | No | 1
Kerberos Authentication | Used to authenticate Active Directory computers and users. | Signature and encryption | Computer | No | 2
Key Recovery Agent | Recovers private keys that are archived on the CA. | Encryption | Key recovery agent | No | 2
OCSP Response Signing | Used by an Online Responder to sign responses to certificate status requests. | Signature | Computer | No | 3
RAS and IAS Server | Enables remote access servers and Internet Authentication Service (IAS) servers to authenticate their identity to other computers. | Signature and encryption | Computer | No | 2
Root Certification Authority | Used to prove the identity of the root CA. | Signature | CA | No | 1
Router (Offline request) | Used by a router when requested through a SCEP request from a CA that holds a CEP Encryption certificate. | Signature and encryption | Computer | No | 1
Smartcard Logon | Allows the holder to authenticate by using a smart card. | Signature and encryption | User | No | 1
Smartcard User | Allows the holder to authenticate and protect e-mail by using a smart card. | Signature and encryption | User | Yes | 1
Subordinate Certification Authority | Used to prove the identity of the root CA. It is issued by the parent or root CA. | Signature | CA | No | 1
Trust List Signing | Allows the holder to digitally sign a trust list. | Signature | User | No | 1
User | Used by users for e-mail, EFS, and client authentication. | Signature and encryption | User | Yes | 1
User Signature Only | Allows users to digitally sign data. | Signature | User | No | 1
Web Server | Proves the identity of a Web server. | Signature and encryption | Computer | No | 1
Workstation Authentication | Enables client computers to authenticate their identity to servers. | Signature and encryption | Computer | No | 2

When you duplicate a version 1 or version 2 certificate template, you can make the duplicate a version 2 or version 3 template in order to configure the advanced options available with the later versions. However, version 3 certificate templates can only be issued by Windows Server 2008–based enterprise CAs and used by clients on computers running Windows Server 2008 or Windows Vista®. For more information, see Certificate Template Versions.

For information about configuration options for certificate templates, see Configuring a Certificate Template.

Additional references

  • Certificate Template Concepts


RADIUS Server

RADIUS server

Network Policy Server (NPS) can be used as a RADIUS server to perform authentication, authorization, and accounting for RADIUS clients. A RADIUS client can be either a network access server or a RADIUS proxy. When NPS is used as a RADIUS server, it provides the following:

  • A central authentication and authorization service for all access requests that are sent by RADIUS clients.

    NPS uses a Microsoft® Windows NT® Server 4.0 domain, an Active Directory® domain, or the local Security Accounts Manager (SAM) user accounts database to authenticate user credentials for connection attempts. NPS uses the dial-in properties of the user account and network policies to authorize a connection.

  • A central accounting recording service for all accounting requests that are sent by RADIUS clients.

    Accounting requests are stored in a local log file or Microsoft® SQL Server™ database for analysis.

The following illustration shows NPS as a RADIUS server for a variety of access clients, and also shows a RADIUS proxy. NPS uses an Active Directory® domain for user credential authentication of incoming RADIUS Access-Request messages.

NPS as a RADIUS server

When NPS is used as a RADIUS server, RADIUS messages provide authentication, authorization, and accounting for network access connections in the following way:

  1. Access servers, such as dial-up network access servers, VPN servers, and wireless access points, receive connection requests from access clients.

  2. The access server, configured to use RADIUS as the authentication, authorization, and accounting protocol, creates an Access-Request message and sends it to the NPS server.

  3. The NPS server evaluates the Access-Request message.

  4. If required, the NPS server sends an Access-Challenge message to the access server. The access server processes the challenge and sends an updated Access-Request to the NPS server.

  5. The user credentials are checked and the dial-in properties of the user account are obtained by using a secure connection to a domain controller.

  6. The connection attempt is authorized with both the dial-in properties of the user account and network policies.

  7. If the connection attempt is both authenticated and authorized, the NPS server sends an Access-Accept message to the access server.

    If the connection attempt is either not authenticated or not authorized, the NPS server sends an Access-Reject message to the access server.

  8. The access server completes the connection process with the access client and sends an Accounting-Request message to the NPS server, where the message is logged.

  9. The NPS server sends an Accounting-Response to the access server.

Note

The access server also sends Accounting-Request messages during the time in which the connection is established, when the access client connection is closed, and when the access server is started and stopped.

You can use NPS as a RADIUS server when:

  • You are using a Windows NT Server 4.0 domain, an Active Directory domain, or the local SAM user accounts database as your user account database for access clients.

  • You are using Routing and Remote Access on multiple dial-up servers, VPN servers, or demand-dial routers and you want to centralize both the configuration of network policies and connection logging for accounting.

  • You are outsourcing your dial-up, VPN, or wireless access to a service provider. The access servers use RADIUS to authenticate and authorize connections that are made by members of your organization.

  • You want to centralize authentication, authorization, and accounting for a heterogeneous set of access servers.

Note

In Internet Authentication Service (IAS) in the Windows Server® 2003 operating systems, network policies are referred to as remote access policies.


Delete a Certificate

Certificates can become obsolete for a number of reasons, such as when they are compromised, become corrupted, or are replaced by a new certificate. However, even when a certificate is deleted, the corresponding private key is not deleted.

Important

Before deleting a certificate, be sure that you will not need it later for purposes such as reading old documents that were encrypted with the certificate's private key.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

To delete a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Do one of the following:

    • If you are in Logical Certificate Stores view mode, in the console tree, click Certificates.

    • If you are in Certificate Purpose view mode, in the console tree, click Purpose.

  3. In the details pane, click the certificate you want to delete. (To select multiple certificates, hold down CTRL and click each certificate.)

  4. On the Action menu, click Delete.

  5. Click Yes if you are sure you want to permanently delete the certificate.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • In some instances, there is not a Certificates folder in the console tree. In that case, navigate in the console tree until the certificate you want appears in the details pane, and then continue with the procedure.

  • You might want to back up the certificate by exporting it before you delete it. For the procedure to export a certificate, see Back Up Certificates.


Remove a Certificate Template from a Certification Authority

At times it may be necessary to remove a certificate template from a certification authority (CA), such as to avoid confusion when a newer version of the certificate template is being added.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To remove a certificate template from a CA

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Certificate Templates.

  3. In the details pane, right-click the certificate template that you want to delete, and then click Delete.

Additional references

  • Deploying Certificate Templates


Find Certificates

From the certificates that appear in the Certificates snap-in, it may not always be an obvious task to find the ones you want. The Find Certificates dialog box allows you to locate certificates based on a number of parameters that can be as broad or narrow as necessary to complete your task.

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic..

To find a certificate

  1. Select the top node of the Certificates container for a user, computer, or service.

  2. On the Action menu, select Find Certificates.

  3. Fill in the requested information. For example, use:

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


Add a Network Policy

Add a network policy

Network Policy Server (NPS) uses network policies, formerly named remote access policies, and the dial-in properties of user accounts to determine whether a connection request should be authorized to connect to the network.

You can use this procedure to configure a new network policy in either the NPS snap-in or the Routing and Remote Access Service snap-in.

Performing authorization

When NPS performs the authorization of a connection request, it compares the request with each network policy in the ordered list of policies, starting with the first policy, and then moving down the list of configured policies. If NPS finds a policy whose conditions match the connection request, NPS uses the matching policy and the dial-in properties of the user account to perform authorization. If the dial-in properties of the user account are configured to grant access or control access through network policy and the connection request is authorized, NPS applies the settings that are configured in the network policy to the connection.

If NPS does not find a network policy that matches the connection request, the connection request is rejected unless the dial-in properties on the user account are set to grant access.

If the dial-in properties of the user account are set to deny access, the connection request is rejected by NPS.

Key settings

When you use the New Network Policy Wizard to create a network policy:

  • The value that you specify in Network connection method is used to automatically configure the Policy Type condition. If you keep the default value of Unspecified, the network policy that you create is evaluated by NPS for all network connection types through any kind of network access server. If you specify a network connection method, NPS evaluates the network policy only if the connection request originates from the type of network access server that you specify. For example, if you specify Terminal Services Gateway, NPS evaluates the network policy only for connection requests that originate from Terminal Services Gateway (TS Gateway).

  • On the Access Permission page, you must select Access granted if you want the policy to allow users to connect to your network. If you want the policy to prevent users from connecting to your network, select Access denied. If you want access permission to be determined by user account dial-in properties in Active Directory Domain Services (AD DS), you can select the Access is determined by User Dial-in properties check box.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To add a network policy using the Windows interface

  1. Open the NPS console and double-click Policies.

  2. In the console tree, right-click Network Policies, and click New. The New Network Policy wizard opens.

  3. Use the New Network Policy wizard to create a policy.


Assess Array Member Status

Although an Online Responder should perform reliably after it has been set up, it is important than an administrator regularly check the status of the Array and its members.

You can check the status of the Array and its members by using the Online Responder snap-in. Error and warning messages, if any, will appear in the status pane of the snap-in.

If you see an error message or warning message, you may need to check each member of the Array to find out if:

  • A network connection exists. If not, you need to decide how to reestablish connectivity.

  • The service is running. If not, the service needs to be restarted.

  • The certification authority (CA) or signing certificates are about to expire. If so, plan to renew them before they expire.

  • The CA or signing certificates have expired. If so, renew them immediately.

Additional references

  • Managing an Online Responder Array

  • Troubleshoot Online Responders


Managing Certificate Templates

The topics in this section describe how to complete the following basic certificate template management tasks.

  • Install the Certificate Templates Snap-In

  • Connect to a Writable Domain Controller

  • Upgrade Existing Templates

  • Create a New Certificate Template

  • Delete a Certificate Template

  • Configuring a Certificate Template

  • Deploying Certificate Templates

  • Issuing Certificates Based on Certificate Templates


Network Policy Settings Properties

Network policy settings

NPS applies the settings that are configured in the network policy to the connection if all of the conditions and constraints that are configured in the policy match the properties of the connection request.

The available groups of settings that you can configure are:

  • RADIUS attributes

  • Network Access Protection

  • Routing and Remote Access

  • IP filters

  • Encryption

  • IP settings

RADIUS Attributes

You can configure both RADIUS standard attributes and vendor-specific attributes (VSAs) as settings in network policy.

Important

If you plan to return to RADIUS clients any additional RADIUS attributes or VSAs with the responses to RADIUS requests, you must add the RADIUS attributes or VSAs to the appropriate network policy.

RADIUS attributes are described in Request for Comments (RFC) 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869, and RFC 3162. RFCs and Internet drafts for VSAs define additional RADIUS attributes.

Network Access Protection

You can specify how you want to enforce NAP, remediation server groups, troubleshooting URL, and autoremediation.
NAP Enforcement

You can use the following settings to designate how you want to enforce NAP:

  • If you select Allow full network access, NAP is not enforced for the network policy. All clients, including non-NAP capable clients and NAP-capable clients that are not compliant with health policy, can connect when the connection request matches the conditions and constraints of the policy.

  • If you select Allow full network access for a limited time, you can defer enforcement of health policy until the day and time that you specify. In the time period before the expiration date that you specify, all clients can connect when the connection request matches the conditions and constraints of the network policy. After the expiration date, compliant clients are allowed full network access; and non-compliant NAP clients are allowed access only to a restricted network, where remediation servers can provide clients with the updates they need in order to become compliant with health policy.

  • If you select Allow limited access, NAP is enforced. Compliant clients are allowed full network access, and non-compliant NAP clients are allowed access only to a restricted network, where remediation servers can provide clients with the updates they need in order to become compliant with health policy.

Important

If you deploy the NAP VPN enforcement method and you have configured NAP enforcement with the Allow full network access for a limited time option, VPN clients that are connected to the network when the expiration time is reached are automatically disconnected whether they are compliant or noncompliant with health policy. After the expiration date and time, VPN clients that attempt to connect to the network are placed on a restricted network if they are noncompliant with health policy, while compliant clients are allowed full network access.

Remediation Server Group and Troubleshooting URL. If you enable autoremediation in NAP Enforcement and you have configured one or more Remediation Server Groups in NPS Network Access Protection settings, you can specify the Remediation Server Group that clients can access for software updates.

When you deploy and enforce NAP, you can provide technical assistance and other information to users on a Web site that is located on the remediation network. If users have restricted access because their computers do not comply with health policy, Web resources can assist them in bringing their computers into compliance with policy. If you have deployed a Web server with Help content, you can supply users with the Web page URL with this network policy setting.

Autoremediation. You can configure autoremediation for client computers on the NAP enforcement page. When you configure autoremediation, clients that are not compliant with health policy are automatically updated and brought into compliance.

For example, if your Windows Security Health Validator (WSHV) designates that the client computer must have a firewall installed and enabled and antivirus software installed, enabled, and configured with the latest signature updates, autoremediation causes NAP agent on the client to enable the firewall if it is turned off and to download the most recent antivirus signature updates if they are not already installed on the client. If you enable autoremediation, be sure to also configure a Remediation Server Group so that client computers know where to find the updates they need when they are not in compliance with health policy.

Extended State

The NAP Extended State setting, along with Host Credential Authorization Protocol (HCAP) server, allows you to integrate your Microsoft Network Access Protection (NAP) solution with Cisco Network Admission Control. Do not configure the NAP Extended State setting in network policy unless you have also deployed Cisco Network Admission Control and HCAP server.

For more information, see Host Credential Authorization Protocol.

Timeout

Following are the timeout settings that you can configure in network policies.

Idle Timeout allows you to specify the maximum time, in minutes, that the network access server can remain idle before the connection is disconnected.

Session Timeout allows you to specify the maximum amount of time, in minutes, that a user can be connected to the network.

Routing and Remote Access

Following are the Routing and Remote Access settings that you can configure in network policies.

Multilink and Bandwidth Allocation Protocol (BAP) allows you to configure how multiple dial-up connections from one computer are managed and whether the number of connections should be reduced based on capacity.

IP Filters allows you to create IPv4 and IPv6 filters to control the IP traffic that the client computer can send or receive.

Encryption allows you to specify the encryption level required between the client computer and the server running Routing and Remote Access service. If you use non-Microsoft network access servers for VPN and dial-up connections, ensure that the encryption settings you select are supported by your servers.

IP Settings allows you to specify the client IP address assignment rules for the network policy.

See Also

  • Add a Setting to a Network Policy