Export (0) Print
Expand All
2 out of 2 rated this helpful - Rate this topic

Foundation Network Companion Guide: Deploying Computer and User Certificates

Updated: March 14, 2008

Applies To: Windows Server 2008

This is a companion guide to the Windows Server 2008 Foundation Network Guide, which is available at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=105231) and in the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=106252).

The Windows Server 2008 Foundation Network Guide provides instructions for planning and deploying the core components required for a fully functioning network and a new Active Directory® domain in a new forest.

This guide explains how to build on the foundation network by providing instructions for deploying client computer and user certificates with Active Directory Certificate Services (AD CS).

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

When you deploy Extensible Authentication Protocol with Transport Layer Security (EAP-TLS) or Protected EAP with TLS (PEAP-TLS), certificates are required for the authentication of servers, clients, and users during network connection attempts through network access servers such as 802.1X authenticating switches and wireless access points, virtual private network (VPN) servers, and computers running Windows Server® 2008 and Terminal Services Gateway (TS Gateway).

noteNote
All of these network access servers are also called Remote Authentication Dial-In User Service (RADIUS) clients, because they use the RADIUS protocol to send connection requests to RADIUS servers. RADIUS servers process the connection requests and perform authentication and authorization. The RADIUS server and proxy in Windows Server® 2008 is Network Policy Server (NPS). In Windows Server 2008, NPS replaces Internet Authentication Service (IAS).

Deploying certificates with AD CS for EAP and PEAP certificate-based authentication methods provides the following benefits:

  • Security provided with certificate-based authentication, which binds the identity of the server running NPS, RRAS server, user, or client computer to a private key

  • A cost-effective and secure method for managing certificates, allowing you to automatically enroll, renew, and revoke certificates to domain member computers and domain users

  • An efficient method for managing certification authorities (CAs)

  • The ability to deploy other types of certificates that are used for purposes other than computer, user, or server authentication. For example, you can deploy certificates that provide users with the ability to digitally sign e-mail, or you can issue certificates used for software code signing.

This guide provides instructions for deploying client computer and user certificates to domain member computers and domain users by using AD CS.

This guide is designed for network and system administrators who have followed the instructions in the Windows Server 2008 Foundation Network Guide to deploy a foundation network, or for those who have previously deployed the core technologies included in the foundation network, including Active Directory Domain Services (AD DS), Domain Name Service (DNS), Dynamic Host Configuration Protocol (DHCP), TCP/IP, NPS, and Windows Internet Name Service (WINS) (optional).

It is recommended that you review the design and deployment guides for each of the technologies that are used in this deployment scenario. These guides can help you determine whether this deployment scenario provides the services and configuration that you need for your organization network.

Following are the requirements for deploying client computer and user certificates using autoenrollment:

  • AD DS is installed, as are other network technologies, according to the instructions in the Windows Server 2008 Foundation Network Guide, which is available for download at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=105231) and in the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=106252).

  • To perform autoenrollment of client computer and user certificates, your CA must be running the Windows Server 2008 Enterprise operating system or the Windows Server 2008 Datacenter operating system and must be an issuing CA. Although AD CS can be deployed on a single server, many deployments use multiple servers configured as CAs.

  • To deploy EAP-TLS or PEAP-TLS, you must enroll server certificates to NPS servers and to computers running Windows Server 2008 and Routing and Remote Access service (RRAS), if you are using RRAS servers as virtual private network (VPN) servers. This guide assumes that you have autoenrolled server certificates in accordance with the Windows Server 2008 Foundation Network Companion Guide: Deploying Server Certificates, which is available at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=108259) and in the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=108258).

noteNote
If you deploy one or more RRAS servers as VPN servers and you do not have NPS installed, network policies and the authentication methods included in these policies are configured individually per RRAS server, which can be time-consuming and can create opportunities for configuration errors. When you install NPS, you can configure RRAS servers as RADIUS clients in NPS, and then use NPS to centrally manage all policies and authentication methods used per policy.

  • To deploy PEAP or EAP for VPN, you must deploy Routing and Remote Access configured as a VPN server. The use of NPS is optional; however, if you have multiple VPN servers, using NPS is recommended for ease of administration and for the RADIUS accounting services that NPS provides.

  • To deploy PEAP or EAP for TS Gateway, you must deploy TS Gateway and NPS.

  • To deploy PEAP or EAP for 802.1X secure wired or wireless, you must deploy NPS and additional hardware, such as 802.1X authenticating switches or wireless access points.

This guide does not provide information about the following:

  • How to deploy client computer and user certificates with smart cards.

  • How to deploy server certificates with autoenrollment.

  • How to design and deploy a public key infrastructure (PKI) by using AD CS. It is recommended that you review AD CS design and deployment documentation before deploying the technologies in this guide. For more information, see Additional Resources.

  • How to deploy the network access technologies for which server certificates can be used. There might be other companion guides available that provide instructions for deploying these network access solutions. You might also want to review the NPS documentation for this information.

Following are technology overviews for client computer and user certificates, EAP, PEAP, and AD CS.

AD CS in Windows Server 2008 provides customizable services for creating and managing the X.509 certificates that are used in software security systems that employ public key technologies. Organizations can use AD CS to enhance security by binding the identity of a person, device, or service to a corresponding public key. AD CS also includes features that allow you to manage certificate enrollment and revocation in a variety of scalable environments.

When you deploy EAP-TLS or PEAP-TLS, you can deploy computer certificates for client computer authentication, user certificates for user authentication, or both.

noteNote
EAP does not provide mechanisms that perform dual authentication — that is, the authentication of both the computer being used to access the network and the user who is attempting to connect. For this reason, you are not required to issue both computer and user certificates when you deploy EAP and PEAP with certificate-based authentication types.

There are two methods for deploying client computer and user certificates:

  • Using smart cards. When you deploy certificates using smart cards, you must purchase additional hardware to imprint certificates on user identification or other cards that your employees use to log on to the network. In addition, users must be supplied with smart card readers, which are used to read the certificate that is imprinted on the smart card when they log on. This guide does not provide information about how to deploy client computer and user certificates with smart cards.

  • Using autoenrollment. When you deploy certificates using autoenrollment, you configure the CA to automatically enroll certificates to computers that are members of the Domain Computers group and to users who are members of the Domain Users group. No additional hardware is required to autoenroll certificates, because the certificates are stored on the computer that is connecting to the network. When a computer receives a computer or user certificate from the CA, the certificate is stored locally in a data store named the certificate store.

ImportantImportant
You should enroll certificates only to the computers and users to whom you want to grant network access through RADIUS clients. You do not have to autoenroll certificates to all members of the Domain Users and Domain Computers groups. Instead, you can issue certificates to subsets of the Domain Users and Domain Computers groups, such as to the Sales team or the Accounting department. To enroll certificates to other groups, create the groups and then add members to the groups in Active Directory Users and Computers. In the Certificate Templates snap-in, remove the Domain Users or Domain Computers groups from the access control list (ACL) on the certificate templates (the User template and the Workstation Authentication template, respectively), and then add the groups that you created to the template.

Computers running the Windows operating system have a certificate store where certificates that are installed on the computer are kept. This store contains multiple folders, where certificates of different types are stored. For example, the certificate store contains a Trusted Root Certification Authorities store where the certificates from all trusted root CAs are kept.

When your organization deploys a PKI and installs a private trusted root CA using AD CS, the 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 folder in the Current User and the Local Computer certificate stores. After this occurs, the domain member computers trust certificates that are issued by the trusted root CA.

Similarly, when you autoenroll computer certificates to domain member client computers, the certificate is kept in the Personal certificate store for the Local Computer; and when you autoenroll certificates to users, the user certificate is kept in the Personal certificate store for the Current User.

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 the 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.

With EAP, an arbitrary authentication mechanism is used to verify the identities of the client and server that are establishing a network access connection. The authentication scheme to be used is negotiated by the access client and the authenticator (the network access server or the RADIUS server).

For successful authentication to occur, both the network access client and the authenticator (such as the server running NPS) must support the same EAP type.

ImportantImportant
Strong EAP types (such as those that are based on certificates) offer better protection against brute-force attacks, dictionary attacks, and password guessing attacks than password-based authentication protocols (such as CHAP or MS-CHAP, version 1).

Windows Server 2008 includes an EAP infrastructure, two EAP types, and the ability to pass EAP messages to a RADIUS server (EAP-RADIUS) such as NPS.

By using EAP, you can support additional authentication schemes, known as EAP types. The following EAP types are included in Windows Server 2008:

  • Transport Layer Security (TLS). EAP-TLS requires the use of computer certificates, user certificates, or both, in addition to server certificates that are enrolled to computers running NPS. If you deploy Routing and Remote Access as a VPN server, VPN servers must also enroll server certificates.

  • Microsoft Challenge-Handshake Authentication Protocol, version 2 (MS-CHAP v2).

In addition, you can install other non-Microsoft EAP modules on the server running NPS or Routing and Remote Access to provide other EAP authentication types. In most cases, if you install additional EAP types on servers, you must also install matching EAP client authentication components on client computers so that the client and server can successfully negotiate an authentication method to use for connection requests.

The following are the general steps for deploying EAP-TLS:

  • Deploy network access servers (RADIUS clients) that are both EAP and RADIUS compliant

  • Autoenroll server certificates to servers running NPS and, if applicable, Routing and Remote Access VPN servers

  • Autoenroll computer certificates, user certificates, or both, to domain member computers and users, respectively, or to other groups that you have created.

  • Configure network access servers as RADIUS clients in NPS.

  • Configure EAP authentication in NPS or RRAS network policy.

  • Ensure that client computers support EAP. By default, Windows Vista® and Windows XP support EAP.

Group Policy in Windows Server 2008 is an infrastructure used to deliver and apply one or more desired configurations or policy settings to a set of targeted users and computers within an Active Directory environment. This infrastructure consists of a Group Policy engine and multiple client-side extensions (CSEs) responsible for reading policy settings on target client computers. Group Policy is used in this scenario to enroll and distribute certificates to users, computers, or both.

PEAP uses TLS to create an encrypted channel between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, such as a server running NPS or another Remote Authentication Dial-In User Service (RADIUS) server.

PEAP does not specify an authentication method, but it provides additional security for other EAP authentication protocols (such as EAP-MSCHAP v2) that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for access clients that are connecting to your organization's network through the following types of network access servers:

  • 802.1X wireless access points

  • 802.1X authenticating switches

  • Computers running Windows Server 2008 and Routing and Remote Access that are configured as VPN servers

  • Computers running Windows Server 2008 and TS Gateway

noteNote
If you plan to deploy Network Access Protection (NAP), you must use PEAP as the authentication method for your deployment with NPS.

To enhance the EAP protocols and network security, PEAP provides:

  • A TLS channel that provides protection for the EAP method negotiation that occurs between the client and server. This TLS channel helps prevent an attacker from injecting packets between the client and the network access server to cause the negotiation of a less secure EAP type. The encrypted TLS channel also helps prevent denial of service attacks against the server running NPS.

  • Support for the fragmentation and reassembly of messages, which allows the use of EAP types that do not provide this functionality.

  • Clients with the ability to authenticate the server running NPS or another RADIUS server. Because the server also authenticates the client, mutual authentication occurs.

  • Protection against the deployment of an unauthorized wireless access point at the moment when the EAP client authenticates the certificate provided by the server running NPS. In addition, the TLS master secret that is created by the PEAP authenticator and the client is not shared with the access point. Because of this, the access point cannot decrypt the messages that are protected by PEAP.

  • PEAP fast reconnect, which reduces the delay between an authentication request by a client and the response by the server running NPS or another RADIUS server. Fast reconnect also allows wireless clients to move between access points that are configured as RADIUS clients to the same RADIUS server without repeated requests for authentication. This reduces resource requirements for the client and the server, and it minimizes the number of times that users are prompted for credentials.

ImportantImportant
To deploy PEAP-TLS, autoenroll server certificates to servers running NPS and, if applicable, RRAS VPN servers. Also autoenroll computer certificates, user certificates, or both to domain member computers and users, respectively. Configure PEAP authentication in NPS or RRAS network policy.

The following are the general steps for deploying PEAP-TLS:

  • Deploy network access servers (RADIUS clients) that are both EAP and RADIUS compliant.

  • Autoenroll server certificates to servers running NPS and, if applicable, RRAS VPN servers.

  • Autoenroll computer certificates, user certificates, or both, to domain member computers and users, respectively, or to other groups that you have created.

  • Configure network access servers as RADIUS clients in NPS.

  • Configure EAP authentication in NPS or RRAS network policy.

  • Ensure that client computers support EAP. By default, Windows Vista® and Windows XP support EAP.

For NPS resources in addition to this guide, see Network Policy Server in the Windows Server 2008 Technical library (http://go.microsoft.com/fwlink/?LinkId=104545).

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.