(0) exportieren Drucken
Alle erweitern

Core Network Companion Guide: Server Certificate Deployment

Letzte Aktualisierung: Juni 2012

Betrifft: Windows Server 2012

The Windows Server 2012 Core 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 core network by providing instructions for deploying server certificates for computers that are running Network Policy Server (NPS), Routing and Remote Access Service (RRAS), or both.

TipTipp
This guide is available in Word format at the Microsoft Download Center (http://go.microsoft.com/fwlink/p/?linkid=255200).

This guide contains the following sections.

This is a companion guide to the Windows Server 2012 Core Network Guide. To deploy server certificates with this guide, you must first do the following.

  • Deploy a core network using the Core Network Guide, or already have the technologies provided in the Core Network Guide installed and functioning correctly on your network. These technologies include TCP/IP v4, DHCP, Active Directory Domain Services (AD DS), DNS, NPS, and Web Server (IIS).

    noteHinweis
    The Windows Server 2012 Core Network Guide is available in the Windows Server 2012 Technical Library (http://go.microsoft.com/fwlink/?LinkId=154884).

    The Core Network Guide is also available in Word format at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=157742).

This guide provides instructions for deploying server certificates to servers running NPS, RRAS, or both, by using AD CS in Windows Server 2012.

Server certificates are required when you deploy certificate-based authentication methods with Extensible Authentication Protocol (EAP) and Protected EAP (PEAP) for network access authentication.

Deploying server certificates with Active Directory Certificate Services (AD CS) for EAP and PEAP certificate-based authentication methods provides the following benefits:

  • Binding the identity of the server running NPS or the RRAS server to a private key

  • A cost-effective and secure method for automatically enrolling certificates to domain member NPS and RRAS servers

  • An efficient method for managing certificates and certification authorities (CAs)

  • Security provided by certificate-based authentication

  • The ability to expand the use of certificates for additional purposes

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

ImportantWichtig
This guide, which provides instructions for deploying server certificates using an online Enterprise Root certification authority (CA), is designed for small organizations that have limited computing resources. For security reasons - if your organization has the computing resources - it is recommended that you deploy an offline Enterprise Root CA in a two tier public key infrastructure (PKI). For more information, see Additional Resources.

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's network.

Following are the requirements for using certificates:

  • To deploy server certificates by using autoenrollment, AD CS requires the Windows Server 2012 Standard, Enterprise, or Datacenter operating systems. AD DS must be installed before AD CS is installed. Although AD CS can be deployed on a single server, many deployments involve multiple servers configured as CAs.

  • To provide computers with access to the Authority Information Access (AIA) and certificate revocation list (CRL) that is generated by your certification authority, you must have a Web server that is properly configured according to the instructions in this guide.

  • To deploy PEAP or EAP for virtual private networks (VPNs), you must deploy RRAS 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 Remote Desktop Gateway (RD Gateway), you must deploy RD Gateway and NPS.

    noteHinweis
    In previous versions of Windows Server, Remote Desktop Services was named Terminal Services.

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

  • To deploy certificate-based authentication methods that require certificates for user and computer authentication in addition to requiring certificates for server authentication, such as EAP with Transport Layer Security (EAP-TLS) or PEAP-TLS, you must also deploy user or computer certificates through autoenrollment or by using smart cards.

This guide does not provide comprehensive instructions for designing and deploying a public key infrastructure (PKI) by using AD CS. It is recommended that you review AD CS documentation and PKI design documentation before deploying the technologies in this guide. For more information, see the Additional Resources section later in this document.

This guide does not provide instructions on how to install Web Server (IIS) or Network Policy Server technologies on server computers; those instructions are provided in the Core Network Guide.

This guide also does not provide detailed instructions for deploying the network access technologies for which server certificates can be used.

Following are technology overviews for EAP, PEAP, and AD CS.

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 an increasing 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 exact authentication scheme to be used is negotiated by the access client and the authenticator - the network access server or the Remote Authentication Dial-In User Service (RADIUS) server.

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

ImportantWichtig
Strong EAP types, such as those that are based on certificates, offer better security 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 2012 includes an EAP infrastructure, 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 EAP types that are supported by Windows Server 2012 are:

  • Transport Layer Security (TLS). EAP-TLS requires the use of computer certificates or user certificates, in addition to server certificates that are enrolled to computers running NPS.

  • Microsoft Challenge-Handshake Authentication Protocol, version 2 (MS-CHAP v2). This EAP type is a password-based authentication protocol. When used within EAP as the authentication method EAP-MS-CHAP v2, NPS and RRAS servers provide a server certificate as proof of identity to client computers, while users prove their identity with a user name and password.

  • Tunneled Transport Layer Security (TTLS). EAP-TTLS is new in Windows Server 2012 and is not available in other versions of Windows Server. EAP-TTLS is a standards-based EAP tunneling method that supports mutual authentication. EAP-TTLS provides a secure tunnel for client authentication using EAP methods and other legacy protocols. EAP-TTLS also provides you with the ability to configure EAP-TTLS on client computers for network access solutions in which non-Microsoft Remote Authentication Dial In User Service (RADIUS) servers that support EAP-TTLS are used for authentication.

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.

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 other 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-capable wireless access points

  • 802.1X-capable authenticating switches

  • Computers running Windows Server 2012 or Windows Server 2008 R2 and RRAS that are configured as VPN servers

  • Computers running Windows Server 2012 or Windows Server 2008 R2 and RD Gateway

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 NPS or other 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 NPS or other 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.

AD CS in Windows Server 2012 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.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft