Certificates and NPS

Article
07/03/2012

Applies To: Windows Server 2008

Certificates and NPS

Certificates are digital documents that are issued by certification authorities (CAs), such as Active Directory® Certificate Services (AD CS) or the Verisign public CA. Certificates can be used for many purposes, such as code signing and securing e-mail communication, but with Network Policy Server (NPS), certificates are used for network access authentication.

Certificates are used for network access authentication because they provide strong security for authenticating users and computers and eliminate the need for less secure password-based authentication methods.

Two authentication methods, when configured with certificate-based authentication types, use certificates: EAP and PEAP. With EAP, you can configure the authentication type TLS (EAP-TLS), and with PEAP you can configure the authentication types TLS (PEAP-TLS) and MS-CHAP v2 (PEAP-MS-CHAP v2). These authentication methods always use certificates for server authentication. Depending on the authentication type configured with the authentication method, certificates might also be used for user authentication and client computer authentication.

Note

The use of certificates for authentication of VPN connections is the strongest form of authentication available in Windows Server® 2008. You must use certificate-based authentication for VPN connections based on Layer Two Tunneling protocol over Internet protocol security (L2TP/IPsec). Point-To-Point Tunneling protocol (PPTP) connections do not require certificates, although you can configure PPTP connections to use certificates for computer authentication when you use EAP-TLS as the authentication method. For wireless clients, PEAP with EAP-TLS and smart cards or certificates is the recommended authentication method.

You can deploy certificates for use with NPS by installing and configuring the Active Directory Certificate Services server role. For more information, see the AD CS documentation.

Certificate types

When you use certificate-based authentication methods, it is important to understand the following types of certificates and how they are used.

CA certificate

When present on client and server computers, tells the client or server that it can trust other certificates, such as certificates used for client or server authentication, that are issued by this CA. This certificate is required for all deployments of certificate-based authentication methods.
Client computer certificate

Issued to client computers by a CA and used when the client computer needs to prove its identity to a server running NPS during the authentication process.
Server certificate

Issued to NPS servers by a CA and used when the NPS server needs to prove its identity to client computers during the authentication process.
User certificate

Issued to individuals by a CA and typically distributed as a certificate that is embedded on a smart card. The certificate on the smart card is used, along with a smart card reader that is attached to the client computer, when individuals need to prove their identity to NPS servers during the authentication process.

Certificate-based authentication methods

When you use EAP with a strong EAP type (such as TLS with smart cards or certificates), both the client and the server use certificates to verify their identities to each other. This process is called mutual authentication. Certificates must meet certain requirements to allow the server and the client to use them for mutual authentication.

One such requirement is that the certificate is configured with one or more purposes in EKU extensions that correlate to the certificate use. For example, a certificate used for the authentication of a client to a server must be configured with the Client Authentication purpose. Similarly, a certificate used for the authentication of a server must be configured with the Server Authentication purpose. When certificates are used for authentication, the authenticator examines the client certificate, seeking the correct purpose object identifier in EKU extensions. For example, the object identifier for the Client Authentication purpose is 1.3.6.1.5.5.7.3.2. When a certificate is used for client computer authentication, this object identifier must be present in the EKU extensions of the certificate or authentication will fail.

Certificate Templates is a Microsoft Management Console (MMC) snap-in that is provided to allow customization of the certificates that are issued by AD CS. Customization possibilities include both how certificates are issued and what the certificates contain, including their purposes. In Certificate Templates, you can use a default template, such as the Computer template, to define the template that the CA uses to assign certificates to computers. You can also create a certificate template and assign purposes in EKU extensions to the certificate. By default, the Computer template includes the Client Authentication purpose and the Server Authentication purpose in EKU extensions.

The certificate template that you create can include any purpose for which the certificate will be used. For example, if you use smart cards for authentication, you can include the Smart Card Logon purpose in addition to the Client Authentication purpose.You can configure NPS to check certificate purposes before granting network authorization. NPS can check additional EKUs and Issuance Policy purposes (also known as certificate policies).

Note

Some non-Microsoft CA software might contain a purpose named All, which represents all possible purposes. This is indicated by a blank (or null) EKU extension. Although All is intended to mean "all possible purposes," the All purpose cannot be substituted for the Client Authentication purpose, the Server Authentication purpose, or any other purpose related to network access authentication.

Understanding authentication with certificates

When a certificate is provided to a client or server computer as proof of identity, the authenticator must examine the certificate to determine its validity, whether it is configured with the purpose for which it is being used, and to find out whether the certificate was issued by a CA that the authenticator trusts.

Assuming that a certificate is configured properly and is valid, the most important aspect of the authentication process is the check by the authenticator that it trusts the CA that issued the certificate.

If the authenticator trusts the CA and the certificate is valid and configured properly according to the minimum server and client certificate requirements, authentication succeeds. If the authenticator does not trust the CA, authentication fails.

How trust is established

Windows-based computers keep certificates in a certificate store on the local computer. There is a certificate store for the Local Computer, for the Current User, and for individual Services, such as Network Connections, Automatic Updates, and Computer Browser. In each certificate store there is a folder named Trusted Root Certification Authorities that contains certificates from every CA that is trusted, whether they are public or private CAs.

To determine trust, the authenticator checks the Trusted Root Certification Authorities certificate store for either the Current User or Local Computer.

If the CA that issued the client, user, or server certificate being used for authentication has a certificate in the Trusted Root Certification Authorities certificate store on the local computer, the authenticator trusts the certificate. If the issuing CA does not have a CA certificate in the Trusted Root Certification Authorities certificate store on the local computer, the authenticator does not trust the certificate.

Important

The CA certificate must be present in the Trusted Root Certification Authorities certificate store on the local computer, whether that computer is a client or a server, for other certificates issued by the CA to be trusted.

Public CAs

Some of these trusted root CA certificates, which are issued by public trusted root certification authorities, are included by default in all installations of Windows; they are included on the product installation compact disc or they are present on computers sold by original equipment manufacturers (OEMs) that provide computers that have Windows installed on them.

For example, in the certificate store on computers running Windows XP, in the Trusted Root Certification Authorities folder, there are CA certificates from the Verisign Trust Network CA, the Thawte Premium Server CA, and the Microsoft Root Certification Authority. If a computer running Windows XP is presented with a certificate that was issued by one of these CAs and the certificate is configured properly and is valid, the computer running Windows XP trusts the certificate.

You can purchase additional certificates from many companies, such as Verisign and Thawte, to use in your authentication infrastructure. For example, when you deploy PEAP-MS-CHAP v2 and the Validate server certificate setting is enabled on the client, the client computer authenticates the NPS server using the NPS server certificate. If you do not want to deploy your own CA and issue your own server certificates to NPS servers, you can purchase a server certificate from a company whose CA is already trusted by client computers.

Private CAs

When organizations deploy their own public key infrastructure (PKI) and install a private trusted root CA, their CA automatically sends its certificate to all domain member computers in the organization. The domain member client and server computers store the CA certificate in the Trusted Root Certification Authorities certificate store. After this occurs, the domain member computers trust certificates that are issued by the organization trusted root CA.

For example, if you install AD CS, the CA sends its certificate to the domain member computers in your organization and they store the CA certificate in the Trusted Root Certification Authorities certificate store on the local computer. If you also configure and autoenroll a server certificate for your NPS servers and then deploy PEAP-MS-CHAP v2 for wireless connections, all domain member wireless client computers can successfully authenticate your NPS servers using the NPS server certificate because they trust the CA that issued the NPS server certificate.

Note

Non-domain member computers must have the private CA certificate manually installed in the Trusted Root Certification Authorities certificate store for them to trust certificates, such as NPS server certificates, that are issued by the private CA.

Required certificates

The following table identifies the certificates that are required to successfully deploy each of the certificate-based authentication methods.

Certificate	Required for EAP-TLS and PEAP-TLS?	Required for PEAP-MS-CHAP v2?	Details
CA certificate in the Trusted Root Certification Authorities certificate store for the Local Computer and Current User.	Yes. The CA certificate is enrolled automatically for domain member computers. For non-domain member computers, the certificate must be manually imported into the certificate store.	Yes. This certificate is enrolled automatically for domain member computers. For non-domain member computers, the certificate must be manually imported into the certificate store.	For PEAP-MS-CHAP v2, this certificate is required for mutual authentication between client and server.
Client computer certificate in the certificate store of the client.	Yes. Client computer certificates are required unless user certificates are distributed on smart cards. Client certificates are enrolled automatically for domain member computers. For non-domain member computers, the certificate must be manually imported or obtained with the Web enrollment tool.	No. User authentication is performed with password-based credentials, not certificates.	If you deploy user certificates on smart cards, client computers do not need client certificates.
Server certificate in the certificate store of the NPS server.	Yes. You can configure AD CS to autoenroll server certificates to members of the RAS and IAS servers group in Active Directory Domain Services (AD DS).	Yes. In addition to using AD CS for server certificates, you can purchase server certificates from other CAs that client computers already trust.	The NPS server sends the server certificate to the client computer; the client computer uses the certificate to authenticate the NPS server.
User certificate on a smart card.	No. This certificate is required only if you choose to deploy smart cards rather than autoenrolling client computer certificates.	No. User authentication is performed with password-based credentials, not certificates.	For EAP-TLS and PEAP-TLS, if you do not autoenroll client computer certificates, user certificates on smart cards are required.

Important

IEEE 802.1X authentication provides authenticated access to 802.11 wireless networks and to wired Ethernet networks. 802.1X provides support for secure EAP types, such as TLS with smart cards or certificates. You can configure 802.1X with EAP-TLS in a variety of ways. If the Validate server certificate option is configured on the client, the client authenticates the server by using its certificate. Client computer and user authentication can be accomplished using certificates from the client certificate store or a smart card, providing mutual authentication. With wireless clients, PEAP-MS-CHAP v2 can be used as the authentication method. PEAP-MS-CHAP v2 is a password-based user authentication method that uses TLS with server certificates. During PEAP-MS-CHAP v2 authentication, the IAS or RADIUS server supplies a certificate to validate its identity to the client (if the Validate server certificate option is configured on the Windows Vista® and Windows XP Professional client). Client computer and user authentication is accomplished with passwords, which eliminates some of the difficulty of deploying certificates to wireless client computers.

Enrolling certificates to domain and non-domain member computers

The domain membership of computers for which you want to enroll certificates affects the certificate enrollment method that you can choose. Certificates for domain member computers can be enrolled automatically, while an administrator must enroll certificates for non-domain member computers using the AD CS Web enrollment tool or a floppy disk or compact disc.

Domain member certificate enrollment

If your VPN server, NPS server, or client running Windows 2000, Windows XP, or Windows Vista is a member of a domain running Windows Server 2008 or Windows Server 2003 and AD DS, you can configure the autoenrollment of computer and user certificates. After autoenrollment is configured and enabled, all domain member computers receive computer certificates when Group Policy is next refreshed, whether the refresh is triggered manually with the gpupdate command or by logging on to the domain.

If your computer is a member of a domain where AD DS is not installed, you can install computer certificates manually by requesting them through the Certificates MMC snap-in.

Note

Computers running Windows 2000 can autoenroll computer certificates only.

Non-domain member certificate enrollment

Certificate enrollment for computers that are not domain members cannot be performed with autoenrollment. When a computer is joined to a domain, a trust is established that allows autoenrollment to occur without administrator intervention. When a computer is not joined to a domain, trust is not established and a certificate is not issued. Trust must be established using one of the following methods:

An administrator (who is, by definition, trusted) must request a computer or user certificate using the CA Web enrollment tool.
An administrator must save a computer or user certificate to a floppy disk and install it on the non-domain member computer. Or, when the computer is not accessible to the administrator (for example, a home computer connecting to an organization network with an L2TP/IPsec VPN connection), a domain user whom the administrator trusts can install the certificate.
An administrator can distribute a user certificate on a smart card (computer certificates are not distributed on smart cards).

Many network infrastructures contain VPN and NPS servers that are not domain members. For example, a VPN server in a perimeter network might not be a domain member for security reasons. In this case, a computer certificate with the Server Authentication purpose contained in the EKU extensions must be installed on the non-domain member VPN server before it can successfully negotiate L2TP/IPsec-based VPN connections with clients. If the non-domain member VPN server is used as an endpoint for a VPN connection with another VPN server, EKU extensions must contain both the Server Authentication and Client Authentication purposes.

If you are running an enterprise certification authority (CA) on a computer running Windows Server 2008 or Windows Server 2003, Standard Edition, you can use the following table to determine the best certificate enrollment method for your requirements:

Object and domain membership	Certificate template	Certificate purposes	Preferred certificate enrollment method	Alternate certificate enrollment method
VPN, IAS, or NPS server, domain member	Computer	Server Authentication	Autoenrollment	Request a certificate with the Certificates snap-in
VPN server with site-to-site connection, domain member	Computer	Server Authentication and Client Authentication	Autoenrollment	Request a certificate with the Certificates snap-in
Windows Vista or Windows XP client, domain member	Computer	Client Authentication	Autoenrollment	Request a certificate with the Certificates snap-in
VPN, IAS, or NPS server, non-domain member	Computer	Server Authentication	CA Web enrollment tool	Install from a floppy disk
VPN server with site-to-site connection, non-domain member	Computer	Server Authentication and Client Authentication	CA Web enrollment tool	Install from a floppy disk
Windows Vista or Windows XP client, non-domain member	Computer	Client Authentication	CA Web enrollment tool	Install from a floppy disk
User, domain user	User	Client Authentication	Autoenrollment	Use a smart card or the CA Web enrollment tool

If your CA is on a computer running one of the following operating systems, the RAS and IAS servers and Workstation Authentication templates are available for use:

Windows Server 2003, Enterprise Edition
Windows Server 2003, Datacenter Edition
Windows Server 2003, Enterprise Edition for Itanium-based Systems
Windows Server 2003, Datacenter Edition for Itanium-based Systems
Windows Server 2003, Enterprise x64 Edition
Windows Server 2003, Datacenter x64 Edition
Windows Server 2008

Use the following table to determine when to use these templates.

Object and domain membership	Certificate template	Certificate purpose	Preferred certificate enrollment method	Alternate certificate enrollment method
VPN, IAS, or NPS server, domain member	RAS and IAS server	Server Authentication	Autoenrollment	Request a certificate with the Certificates snap-in
Windows Vista or Windows XP client, domain member	Workstation Authentication	Client Authentication	Autoenrollment	Request a certificate with the Certificates snap-in
VPN, IAS, or NPS server, non-domain member	RAS and IAS server	Server Authentication	CA Web enrollment tool	Install from a floppy disk
Windows Vista or Windows XP client, non-domain member	Workstation Authentication	Client Authentication	CA Web enrollment tool	Install from a floppy disk

Important

If your server running NPS is not a domain controller but is a member of a domain with a Windows 2000 mixed functional level, you must add the server to the access control list (ACL) of the RAS and IAS server certificate template. You must also configure the correct permissions for autoenrollment. There are different procedures for adding single servers and groups of servers to the ACL.

To add an individual server to the ACL for the RAS and IAS server certificate template

In Certificate Templates, select the template RAS and IAS server, and then add the NPS server to the template Security properties.
After you have added your NPS server to the ACL, grant Read, Enroll, and Auto-enroll permissions.

To manage a group of servers, add the servers to a new global or universal group, and then add the group to the ACL of the certificate template

In Active Directory Users and Computers, create a new global or universal group for NPS servers.
Add to the group all computers that are NPS servers, are not domain controllers, and are members of a domain with a Windows 2000 mixed functional level.
In Certificate Templates, select the RAS and IAS server template, and then add the group you created to the template Security properties.
Grant Read, Enroll, and Auto-enroll permissions.

Share via

Certificates and NPS