Network Policy Server

Network Policy Server

Network Policy Server (NPS) allows you to create and enforce organization-wide network access policies for client health, connection request authentication, and connection request authorization. In addition, you can use NPS as a Remote Authentication Dial-In User Service (RADIUS) proxy to forward connection requests to a server running NPS or other RADIUS servers that you configure in remote RADIUS server groups.

NPS allows you to centrally configure and manage network access authentication, authorization, and client health policies with the following three features:

  • RADIUS server. NPS performs centralized authentication, authorization, and accounting for wireless, authenticating switch, remote access dial-up and virtual private network (VPN) connections. When you use NPS as a RADIUS server, you configure network access servers, such as wireless access points and VPN servers, as RADIUS clients in NPS. You also configure network policies that NPS uses to authorize connection requests, and you can configure RADIUS accounting so that NPS logs accounting information to log files on the local hard disk or in a Microsoft SQL Server database. For more information, see RADIUS Server.

  • RADIUS proxy. When you use NPS as a RADIUS proxy, you configure connection request policies that tell the NPS server which connection requests to forward to other RADIUS servers and to which RADIUS servers you want to forward connection requests. You can also configure NPS to forward accounting data to be logged by one or more computers in a remote RADIUS server group. For more information, see RADIUS Proxy.

  • Network Access Protection (NAP) policy server. 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. NPS also acts as a RADIUS server when configured with NAP, performing authentication and authorization for connection requests. You can configure NAP policies and settings in NPS, including system health validators (SHVs), health policy, and remediation server groups that allow client computers to update their configuration to become compliant with your organization's network policy. For more information, see Network Access Protection in NPS.

You can configure NPS with any combination of the preceding features. For example, you can configure one NPS server to act as a NAP policy server using one or more enforcement methods, while also configuring the same NPS server as a RADIUS server for dial-up connections and as a RADIUS proxy to forward some connection requests to members of a remote RADIUS server group for authentication and authorization in another domain.

Configuration

To configure NPS as a RADIUS server or a NAP policy server, you can use either standard configuration or advanced configuration in the NPS console or in Server Manager. To configure NPS as a RADIUS proxy, you must use advanced configuration.

Standard configuration

With standard configuration, wizards are provided to help you configure NPS for the following scenarios:

  • NAP policy server

  • RADIUS server for dial-up or VPN connections

  • RADIUS server for 802.1X wireless or wired connections

To configure NPS using a wizard, open the NPS console, select one of the preceding scenarios, and then click the link that opens the wizard.

Advanced configuration

When you use advanced configuration, you manually configure NPS as a RADIUS server, NAP policy server, or RADIUS proxy. Some wizards are provided to assist you with policy and NAP configuration; however, these wizards are opened from the NPS folder tree in the NPS console rather than from the Getting Started section in the details pane of the console.

To configure NPS by using advanced configuration, open the NPS console, and then click the arrow next to Advanced Configuration to expand this section.

The following advanced configuration items are provided.
Configure RADIUS server

To configure NPS as a RADIUS server, you must configure RADIUS clients, network policy, and RADIUS accounting.

The following Help sections provide the information you need to deploy NPS as a RADIUS server:

  • RADIUS Server

  • Network Policies

  • RADIUS Client

  • RADIUS Accounting

Configure NAP policy server

To deploy NAP, you must configure NAP components in addition to configuring RADIUS clients and network policy.

The following Help sections provide the information you need to deploy NPS as a NAP policy server:

  • Network Access Protection in NPS

  • Network Policies

  • Health Policies

  • Connection Request Policies

  • RADIUS Client

Configure RADIUS proxy

To configure NPS as a RADIUS proxy, you must configure RADIUS clients, remote RADIUS server groups, and connection request policies.

The following Help sections provide the information you need to deploy NPS as a RADIUS proxy:

  • RADIUS Proxy

  • RADIUS Client

  • Connection Request Processing

  • Remote RADIUS Server Groups

NPS logging

NPS logging is also called RADIUS accounting. Configure NPS logging to your requirements whether NPS is used as a RADIUS server, proxy, NAP policy server, or any combination of the three configurations.

To configure NPS logging, you must configure which events you want logged and viewed with Event Viewer, and then determine which other information you want to log. In addition, you must decide whether you want to log user authentication and accounting information to text log files stored on the local computer or to a SQL Server database on either the local computer or a remote computer.

The following Help sections provide the information you need to deploy RADIUS accounting:

  • Configure Log File Properties

  • Configure SQL Server Logging in NPS


Network Policy Server Overview

Network Policy Server (NPS) allows you to centrally configure and manage network policies with the following three features: Remote Authentication Dial-In User Service (RADIUS) server, RADIUS proxy, and Network Access Protection (NAP) policy server.

RADIUS server and proxy

NPS can be used as a RADIUS server, a RADIUS proxy, or both.

RADIUS server

NPS is the Microsoft implementation of the RADIUS standard specified by the Internet Engineering Task Force (IETF) in RFCs 2865 and 2866. As a RADIUS server, NPS performs centralized connection authentication, authorization, and accounting for many types of network access, including wireless, authenticating switch, dial-up and virtual private network (VPN) remote access, and router-to-router connections.

NPS enables the use of a heterogeneous set of wireless, switch, remote access, or VPN equipment. You can use NPS with the Routing and Remote Access service, which is available in Microsoft Windows 2000, Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition.

When a server running NPS is a member of an Active Directory® Domain Services (AD DS) domain, NPS uses the directory service as its user account database and is part of a single sign-on solution. The same set of credentials is used for network access control (authenticating and authorizing access to a network) and to log on to an AD DS domain.

Internet service providers (ISPs) and organizations that maintain network access have the increased challenge of managing all types of network access from a single point of administration, regardless of the type of network access equipment used. The RADIUS standard supports this functionality in both homogeneous and heterogeneous environments. RADIUS is a client-server protocol that enables network access equipment (used as RADIUS clients) to submit authentication and accounting requests to a RADIUS server.

A RADIUS server has access to user account information and can check network access authentication credentials. If user credentials are authenticated and the connection attempt is authorized, the RADIUS server authorizes user access on the basis of specified conditions, and then logs the network access connection in an accounting log. The use of RADIUS allows the network access user authentication, authorization, and accounting data to be collected and maintained in a central location, rather than on each access server.

For more information, see RADIUS Server.

RADIUS proxy

As a RADIUS proxy, NPS forwards authentication and accounting messages to other RADIUS servers.

With NPS, organizations can also outsource remote access infrastructure to a service provider while retaining control over user authentication, authorization, and accounting.

NPS configurations can be created for the following scenarios:

  • Wireless access

  • Organization dial-up or virtual private network (VPN) remote access

  • Outsourced dial-up or wireless access

  • Internet access

  • Authenticated access to extranet resources for business partners

For more information, see RADIUS Proxy.

RADIUS server and RADIUS proxy configuration examples

The following configuration examples demonstrate how you can configure NPS as a RADIUS server and a RADIUS proxy.

NPS as a RADIUS server. In this example, NPS is configured as a RADIUS server, the default connection request policy is the only configured policy, 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 and in trusted domains.

NPS as a RADIUS proxy. In this example, the NPS server is configured as a RADIUS proxy that forwards connection requests to remote RADIUS server groups in two untrusted domains. The default connection request policy is deleted, and two new connection request policies are created to forward requests to each of the two untrusted domains. In this example, NPS does not process any connection requests on the local server.

NPS as both RADIUS server and RADIUS proxy. In addition to the default connection request policy, which designates that connection requests are processed locally, a new connection request policy is created that forwards connection requests to an NPS or other RADIUS server in an untrusted domain. This second policy is named the Proxy policy. 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 a 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 server 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 domain 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 on the RADIUS server that has the same name as the remote user account against which authentication is performed by the remote RADIUS server.)

NAP policy server

NAP is included in Windows Vista®, Windows® 7, Windows Server® 2008, and Windows Server® 2008 R2, and helps protect access to private networks by ensuring that client computers are configured in accordance with organization network health policies before they are allowed to connect to network resources. In addition, client computer compliance with health policy is monitored by NAP while the computer is connected to the network. By using NAP autoremediation, noncompliant computers can be automatically updated to bring them into compliance with health policy so that they can connect to the network.

System administrators define network health policies and create these policies by using NAP components that are provided in NPS and, depending on your NAP deployment, by other companies.

Health policies can include such things as software requirements, security update requirements, and required configuration settings. NAP enforces health policies by inspecting and assessing the health of client computers, restricting network access when client computers are deemed unhealthy, and remediating unhealthy client computers for full network access.

For more information, see Network Access Protection in NPS.

See Also

  • RADIUS Accounting


NPS and Firewalls

Firewalls can be configured to allow or block types of IP traffic to and from the computer or device on which the firewall is running. If firewalls are not properly configured to allow RADIUS traffic between RADIUS clients, RADIUS proxies, and RADIUS servers, network access authentication can fail, preventing users from accessing network resources.

Two types of firewalls might need to be configured to allow RADIUS traffic:

  • Windows Firewall on the local server running Network Policy Server (NPS).

  • Firewalls running on other computers or hardware devices.

Windows Firewall on the local NPS server

By default, NPS sends and receives RADIUS traffic by using User Datagram Protocol (UDP) ports 1812, 1813, 1645, and 1646. Windows Firewall on the NPS server is automatically configured with exceptions, during the installation of NPS, to allow this RADIUS traffic to be sent and received.

Therefore, if you are using the default UDP ports, you do not need to change the Windows Firewall configuration to allow RADIUS traffic to and from NPS servers.

In some cases, you might want to change the ports that NPS uses for RADIUS traffic. If you configure NPS and your network access servers to send and receive RADIUS traffic on ports other than the defaults, you must do the following:

  • Remove the exceptions that allow RADIUS traffic on the default ports.

  • Create new exceptions that allow RADIUS traffic on the new ports.

For more information, see Configure NPS UDP Port Information.

Other firewalls

In the most common configuration, the firewall is connected to the Internet and the NPS server is an intranet resource that is connected to the perimeter network.

To reach the domain controller within the intranet, the NPS server might have:

  • An interface on the perimeter network and an interface on the intranet (IP routing is not enabled).

  • A single interface on the perimeter network. In this configuration, NPS communicates with domain controllers through another firewall that connects the perimeter network to the intranet.

Configuring the Internet firewall

The firewall that is connected to the Internet must be configured with input and output filters on its Internet interface (and, optionally, its network perimeter interface), to allow the forwarding of RADIUS messages between the NPS server and RADIUS clients or proxies on the Internet. Additional filters can be used to allow the passing of traffic to Web servers, VPN servers, and other types of servers on the perimeter network.

Separate input and output packet filters can be configured on the Internet interface and the perimeter network interface.

Filters on the Internet interface

Configure the following input packet filters on the Internet interface of the firewall to allow the following types of traffic:

  • Destination IP address of the perimeter network interface and UDP destination port of 1812 (0x714) of the NPS server.

    This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the NPS server. This is the default UDP port that is used by NPS, as defined in RFC 2865. If you are using a different port, substitute that port number for 1812.

  • Destination IP address of the perimeter network interface and UDP destination port of 1813 (0x715) of the NPS server.

    This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the NPS server. This is the default UDP port that is used by NPS, as defined in RFC 2866. If you are using a different port, substitute that port number for 1813.

  • (Optional) Destination IP address of the perimeter network interface and UDP destination port of 1645 (0x66D) of the NPS server.

    This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the NPS server. This is the UDP port that is used by older RADIUS clients.

  • (Optional) Destination IP address of the perimeter network interface and UDP destination port of 1646 (0x66E) of the NPS server.

    This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the NPS server. This is the UDP port that is used by older RADIUS clients.

Configure the following output filters on the Internet interface of the firewall to allow the following types of traffic:

  • Source IP address of the perimeter network interface and UDP source port of 1812 (0x714) of the NPS server.

    This filter allows RADIUS authentication traffic from the NPS server to Internet-based RADIUS clients. This is the default UDP port that is used by NPS, as defined in RFC 2865. If you are using a different port, substitute that port number for 1812.

  • Source IP address of the perimeter network interface and UDP source port of 1813 (0x715) of the NPS server.

    This filter allows RADIUS accounting traffic from the NPS server to Internet-based RADIUS clients. This is the default UDP port that is used by NPS, as defined in RFC 2866. If you are using a different port, substitute that port number for 1813.

  • (Optional) Source IP address of the perimeter network interface and UDP source port of 1645 (0x66D) of the NPS server.

    This filter allows RADIUS authentication traffic from the NPS server to Internet-based RADIUS clients. This is the UDP port that is used by older RADIUS clients.

  • (Optional) Source IP address of the perimeter network interface and UDP source port of 1646 (0x66E) of the NPS server.

    This filter allows RADIUS accounting traffic from the NPS server to Internet-based RADIUS clients. This is the UDP port that is used by older RADIUS clients.

Filters on the perimeter network interface

Configure the following input filters on the perimeter network interface of the firewall to allow the following types of traffic:

  • Source IP address of the perimeter network interface and UDP source port of 1812 (0x714) of the NPS server.

    This filter allows RADIUS authentication traffic from the NPS server to Internet-based RADIUS clients. This is the default UDP port that is used by NPS, as defined in RFC 2865. If you are using a different port, substitute that port number for 1812.

  • Source IP address of the perimeter network interface and UDP source port of 1813 (0x715) of the NPS server.

    This filter allows RADIUS accounting traffic from the NPS server to Internet-based RADIUS clients. This is the default UDP port that is used by NPS, as defined in RFC 2866. If you are using a different port, substitute that port number for 1813.

  • (Optional) Source IP address of the perimeter network interface and UDP source port of 1645 (0x66D) of the NPS server.

    This filter allows RADIUS authentication traffic from the NPS server to Internet-based RADIUS clients. This is the UDP port that is used by older RADIUS clients.

  • (Optional) Source IP address of the perimeter network interface and UDP source port of 1646 (0x66E) of the NPS server.

    This filter allows RADIUS accounting traffic from the NPS server to Internet-based RADIUS clients. This is the UDP port that is used by older RADIUS clients.

Configure the following output packet filters on the perimeter network interface of the firewall to allow the following types of traffic:

  • Destination IP address of the perimeter network interface and UDP destination port of 1812 (0x714) of the NPS server.

    This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the NPS server. This is the default UDP port that is used by NPS, as defined in RFC 2865. If you are using a different port, substitute that port number for 1812.

  • Destination IP address of the perimeter network interface and UDP destination port of 1813 (0x715) of the NPS server.

    This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the NPS server. This is the default UDP port that is used by NPS, as defined in RFC 2866. If you are using a different port, substitute that port number for 1813.

  • (Optional) Destination IP address of the perimeter network interface and UDP destination port of 1645 (0x66D) of the NPS server.

    This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the NPS server. This is the UDP port that is used by older RADIUS clients.

  • (Optional) Destination IP address of the perimeter network interface and UDP destination port of 1646 (0x66E) of the NPS server.

    This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the NPS server. This is the UDP port that is used by older RADIUS clients.

For added security, you can use the IP addresses of each RADIUS client that sends the packets through the firewall to define filters for traffic between the client and the IP address of the NPS server on the perimeter network.

Configuring the intranet firewall

The firewall that is connected to the intranet must be configured with input and output filters on its perimeter network interface (and, optionally, its intranet interface), to allow the forwarding of RADIUS messages between the NPS server on the perimeter network and domain controllers on the intranet. Additional filters can allow the passing of traffic to Web, VPN, and other types of servers on the perimeter network.

Separate input and output packet filters can be configured on the perimeter network interface and the intranet interface.

Filters on the perimeter network interface

Configure the following input packet filters on the perimeter network interface of the intranet firewall to allow the following types of traffic:

  • Source IP address of the perimeter network interface of the NPS server.

    This filter allows traffic from the NPS server on the perimeter network.

Configure the following output filters on the perimeter network interface of the intranet firewall to allow the following types of traffic:

  • Destination IP address of the perimeter network interface of the NPS server.

    This filter allows traffic to the NPS server on the perimeter network.

Filters on the intranet interface

Configure the following input filters on the intranet interface of the firewall to allow the following types of traffic:

  • Destination IP address of the perimeter network interface of the NPS server.

    This filter allows traffic to the NPS server on the perimeter network.

Configure the following output packet filters on the intranet interface of the firewall to allow the following types of traffic:

  • Source IP address of the perimeter network interface of the NPS server.

    This filter allows traffic from the NPS server on the perimeter network.


NPS Templates

Network Policy Server (NPS) templates allow you to create configuration elements, such as Remote Authentication Dial-In User Service (RADIUS) clients or shared secrets, that you can reuse on the local NPS server and export for use on other NPS servers.

NPS templates are designed to reduce the amount of time and cost that it takes to configure NPS on one or more servers. The following NPS template types are available for configuration in Templates Management:

  • Shared Secrets

  • RADIUS Clients

  • Remote RADIUS Servers

  • IP Filters

  • Health Policies

  • Remediation Server Groups

Configuring a template is different than configuring the NPS server directly. Creating a template does not affect the NPS server's functionality. It is only when you select the template in the appropriate location in the NPS console that the template affects the NPS server functionality.

For example, if you configure a RADIUS client in the NPS console under RADIUS Clients and Servers, you have altered the NPS server configuration and taken one step in configuring NPS to communicate with one of your network access servers. (The next step would be to configure the NAS to communicate with NPS.) However, if you configure a new RADIUS Clients template in the NPS console under Templates Management rather than creating a new RADIUS client under RADIUS Clients and Servers, you have created a template, but you have not altered the NPS server functionality yet. To alter the NPS server functionality, you must select the template from the correct location in the NPS console.

Creating templates

To create a template, right-click a template type, such as IP Filters, and then click New. A new template properties dialog box opens that allows you to configure your template.

Using templates locally

You can use a template that you've created in Templates Management by navigating to a location in the NPS console where the template can be applied. For example, if you create a new Shared Secrets template that you want to apply to a RADIUS client configuration, in RADIUS Clients and Servers and RADIUS Clients, open the RADIUS client properties, and then in Select an existing Shared Secrets template, select the template you created from the list of templates.


Policies in NPS

Network Policy Server (NPS) provides three types of policies:

  • Connection request policies. Sets of conditions and settings that specify which RADIUS servers perform the authentication, authorization, and accounting of connection requests received by the NPS server 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.

  • Network policies. Sets of conditions, constraints, and settings that specify who is authorized to connect to the network and the circumstances under which they can or cannot connect. When you deploy NAP, health policy is added to the network policy configuration so that NPS performs client health checks during the authorization process.

  • Health policies. 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. Health policies are used only with NAP.

Important

These policies are different from and unrelated to Group Policy.

See Also

  • Connection Request Policies
  • Health Policies
  • Network Policies


Register the NPS Server in Active Directory Domain Services

When Network Policy Server (NPS) is a member of an Active Directory® Domain Services (AD DS) domain, NPS performs authentication by comparing user credentials that it receives from network access servers with the credentials that are stored for the user account in AD DS. In addition, NPS authorizes connection requests by using network policy and by checking user account dial-in properties in AD DS.

For NPS to have permission to access user account credentials and dial-in properties in AD DS, the server running NPS must be registered in AD DS.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To register the NPS server in the default domain by using the NPS console

  1. Log on to the NPS server by using an account that has administrative credentials for the domain.

  2. Open the NPS console.

  3. Right-click NPS (Local), and then click Register server in Active Directory. When the Register Network Policy Server in Active Directory dialog box appears, click OK.
To register the NPS server in the default domain using the netsh command

  1. Log on to the NPS server by using an account that has administrative credentials for the domain.

  2. Open Command Prompt.

  3. At the command prompt, type netsh ras add registeredserver, and then press ENTER.
To register the NPS server in the default domain using Active Directory Users and Computers

  1. Log on to the NPS server by using an account that has administrative credentials for the domain.

  2. Open the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in.

  3. In the console tree, click the Users folder in the appropriate domain.

  4. In the details pane, right-click RAS and IAS Servers, and then click Properties.

  5. In the RAS and IAS Servers Properties dialog box, on the Members tab, add each of the NPS servers.

    You can also add the NPS server to the RAS and IAS Servers group by using the Dsmod tool.
To register the NPS server in another domain using Active Directory Users and Computers

  1. Log on to the NPS server by using an account that has administrative credentials for the domain.

  2. Open the Active Directory Users and Computers snap-in.

  3. In the console tree, click the Users folder in the appropriate domain.

  4. In the details pane, right-click RAS and IAS Servers, and then click Properties.

  5. In the RAS and IAS Servers Properties dialog box, on the Members tab, add each of the NPS servers.

    You can also add the NPS server to the RAS and IAS Servers group by using the Dsmod tool.
To register the NPS server in another domain by using the netsh command

  1. Log on to the NPS server by using an account that has administrative credentials for the domain.

  2. Open Command Prompt.

  3. At the command prompt, type netsh ras add registeredserver Domain NPSServer, where Domain is the Domain Name System (DNS) name of the domain and NPSServer is the name of the NPS server computer.
Note

To open Active Directory Users and Computers, click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers.

Note

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


Certificate Requirements for PEAP and EAP

All certificates that are used for network access authentication with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Protected Extensible Authentication Protocol-Transport Layer Security (PEAP-TLS), and PEAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) must meet the requirements for X.509 certificates and work for connections that use Secure Socket Layer/Transport Level Security (SSL/TLS). Both client and server certificates have additional requirements.

Minimum server certificate requirements

With PEAP-MS-CHAP v2, PEAP-TLS, or EAP-TLS as the authentication method, the NPS server must use a server certificate that meets the minimum server certificate requirements.

Client computers can be configured to validate server certificates by using the Validate server certificate option on the client computer or in Group Policy.

The client computer accepts the authentication attempt of the server when the server certificate meets the following requirements:

  • The Subject name contains a value. If you issue a certificate to your server running Network Policy Server (NPS) that has a blank Subject name, the certificate is not available to authenticate your NPS server. To configure the certificate template with a Subject name:

    1. Open Certificate Templates.

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

    3. Click the Subject Name tab, and then click Build from this Active Directory information.

    4. In Subject name format, select a value other than None.

  • The computer certificate on the server chains to a trusted root certification authority (CA) and does not fail any of the checks that are performed by CryptoAPI and that are specified in the remote access policy or network policy.

  • The computer certificate for the NPS server or VPN server is configured with the Server Authentication purpose in Extended Key Usage (EKU) extensions. (The object identifier for Server Authentication is 1.3.6.1.5.5.7.3.1.)

  • The server certificate is configured with a required algorithm value of RSA. To configure the required cryptography setting:

    1. Open Certificate Templates.

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

    3. Click the Cryptography tab. In Algorithm name, click RSA. Ensure that Minimum key size is set to 2048.

  • The Subject Alternative Name (SubjectAltName) extension, if used, must contain the DNS name of the server. To configure the certificate template with the Domain Name System (DNS) name of the enrolling server:

    1. Open Certificate Templates.

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

    3. Click the Subject Name tab, and then click Build from this Active Directory information.

    4. In Include this information in alternate subject name, select DNS name.

When using PEAP and EAP-TLS, NPS servers display a list of all installed certificates in the computer certificate store, with the following exceptions:

  • Certificates that do not contain the Server Authentication purpose in EKU extensions are not displayed.

  • Certificates that do not contain a Subject name are not displayed.

  • Registry-based and smart card-logon certificates are not displayed.

Minimum client certificate requirements

With EAP-TLS or PEAP-TLS, the server accepts the client authentication attempt when the certificate meets the following requirements:

  • The client certificate is issued by an enterprise CA or mapped to a user or computer account in Active Directory® Domain Services (AD DS).

  • The user or computer certificate on the client chains to a trusted root CA, includes the Client Authentication purpose in EKU extensions (the object identifier for Client Authentication is 1.3.6.1.5.5.7.3.2), and fails neither the checks that are performed by CryptoAPI and that are specified in the remote access policy or network policy nor the Certificate object identifier checks that are specified in IAS remote access policy or NPS network policy.

  • The 802.1X client does not use registry-based certificates that are either smart card-logon or password-protected certificates.

  • For user certificates, the Subject Alternative Name (SubjectAltName) extension in the certificate contains the user principal name (UPN). To configure the UPN in a certificate template:

    1. Open Certificate Templates.

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

    3. Click the Subject Name tab, and then click Build from this Active Directory information.

    4. In Include this information in alternate subject name, select User principal name (UPN).

  • For computer certificates, the Subject Alternative Name (SubjectAltName) extension in the certificate must contain the fully qualified domain name (FQDN) of the client, which is also called the DNS name. To configure this name in the certificate template:

    1. Open Certificate Templates.

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

    3. Click the Subject Name tab, and then click Build from this Active Directory information.

    4. In Include this information in alternate subject name, select DNS name.

With PEAP-TLS and EAP-TLS, clients display a list of all installed certificates in the Certificates snap-in, with the following exceptions:

  • Wireless clients do not display registry-based and smart card-logon certificates.

  • Wireless clients and VPN clients do not display password-protected certificates.

  • Certificates that do not contain the Client Authentication purpose in EKU extensions are not displayed.


EAP Overview

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

EAP and NPS

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 server running Network Policy Server (NPS), 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 Challenge Handshake Authentication Protocol (CHAP) or Microsoft Challenge Handshake Authentication Protocol (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 Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) and PEAP-MS-CHAP v2 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 token card 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-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 Remote Authentication Dial-In User Service (RADIUS), and that are members of a domain. A network access server running as a stand-alone server or as 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.

To enable EAP 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 in the constraints of the appropriate network policy.

  3. Enable and configure EAP on the remote access client. For more information, see your access client documentation.


PEAP Overview

Protected Extensible Authentication Protocol (PEAP) is part of the Extensible Authentication Protocol (EAP) protocols.

PEAP uses Transport Layer Security (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 Network Policy Server (NPS) or other Remote Authentication Dial-In User Service (RADIUS) server.

PEAP and NPS

PEAP does not specify an authentication method, but provides additional security for other EAP authentication protocols, such as Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (EAP-MS-CHAP v2), that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for access clients connecting to your organization network through the following types of network access servers:

  • 802.1X wireless access points

  • 802.1X authenticating switches

  • Virtual private network (VPN) servers running Windows Server® 2008 or Windows Server® 2008 R2 and the Routing and Remote Access service

  • Computers running Windows Server 2008 and Terminal Services Gateway (TS Gateway) or Windows Server® 2008 R2 and Remote Desktop Gateway (RD Gateway).

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

  • A TLS channel that provides protection for the EAP method negotiation that occurs between 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 NPS server.

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

  • Clients with the ability to authenticate the NPS server 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 NPS server. In addition, the TLS master secret created by the PEAP authenticator and client is not shared with the access point. Because of this, the access point cannot decrypt the messages 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. PEAP 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 both client and server, and minimizes the number of times that users are prompted for credentials.

The following table lists the strengths of PEAP-MS-CHAP v2 and compares it to MS-CHAP v2.

Feature/function | MS-CHAP v2 | PEAP-MS-CHAP v2
Provides client authentication using passwords. | Yes | Yes
Ensures that the server has access to credentials. | Yes | Yes
Authenticates the server. | Yes | Yes
Prevents wireless access point spoofing. | No | Yes
Prevents an unauthorized server from negotiating the least secure authentication method. | No | Yes
Uses TLS keys generated with a public key. | No | Yes
Provides end-to-end encryption. | No | Yes
Prevents dictionary or brute force attacks. | No | Yes
Prevents replay attacks. | No | Yes
Allows chaining of authentication methods. | No | Yes
Requires client trust of certificates provided by the server. | No | Yes

PEAP authentication process

There are two stages in the PEAP authentication process between the PEAP client and the authenticator. The first stage establishes a secure channel between the PEAP client and the authenticating server. The second stage provides EAP authentication between the PEAP client and authenticator.

TLS encrypted channel

In the first stage of PEAP authentication, the TLS channel is created between the PEAP client and the NPS server. The following steps illustrate how this TLS channel is created for wireless PEAP clients.

  1. The PEAP client associates with a wireless access point that is configured as a RADIUS client to a server running NPS. An IEEE 802.11-based association provides an Open System or Shared Key Authentication before a secure association is created between the PEAP client and the access point.

  2. After the IEEE 802.11-based association is successfully established between the client and access point, the TLS session is negotiated with the access point.

  3. After computer-level authentication is successfully completed between the wireless PEAP client and the NPS server, the TLS session is negotiated between them. The key that is derived during this negotiation is used to encrypt all subsequent communication, including network access authentication that allows the user to connect to the organization network.

EAP-authenticated communication

Complete EAP communication, including EAP negotiation, occurs through the TLS channel and is the second stage of PEAP authentication. The following steps extend the previous example and illustrate how wireless clients complete authentication with the NPS server using PEAP.

After the TLS channel is created between the NPS server and the PEAP client, the client passes the credentials (user name and password or a user or computer certificate) to the NPS server through the encrypted channel.

The access point only forwards messages between wireless client and RADIUS server; the access point (or a person monitoring it) cannot decrypt these messages because it is not the TLS endpoint.

The NPS server authenticates the user and client computer with the authentication type that is selected for use with PEAP. The authentication type can be either EAP-TLS (smart card or other certificate) or EAP-MS-CHAP v2 (secure password).

Note

You can configure PEAP as the authentication method in NPS network policy.

EAP types

You can choose between two EAP types, also called authentication types, for use with PEAP: EAP-MS-CHAP v2 or EAP-TLS. EAP-MS-CHAP v2 uses password-based credentials (user name and password) for user authentication, and a certificate in the server computer certificate store for server authentication. EAP-TLS uses either certificates installed in the client computer certificate store or a smart card for user and client computer authentication, and a certificate in the server computer certificate store for server authentication.

PEAP with EAP-MS-CHAP v2

PEAP with EAP-MS-CHAPv2 (PEAP-MS-CHAP v2) is easier to deploy than EAP-TLS because user authentication is accomplished by using password-based credentials (user name and password) instead of certificates or smart cards. Only the NPS server or other RADIUS server is required to have a certificate. The NPS server certificate is used by the NPS server during the authentication process to prove its identity to PEAP clients.

Successful PEAP-MS-CHAP v2 authentication requires that the client trust the NPS server after examining the server certificate. For the client to trust the NPS server, the certification authority (CA) that issued the server certificate must have its own different certificate in the Trusted Root Certification Authorities certificate store on client computers.

The server certificate used by NPS can be issued by either the trusted root CA of your organization or by a public CA, such as VeriSign or Thawte, that is already trusted by the client computer.

Note

PEAP-MS-CHAP v2 provides greatly improved security over MS-CHAP v2 by providing key generation with TLS and by using mutual authentication, which prevents an unauthorized server from negotiating the least secure authentication method with the PEAP client.

PEAP with EAP-TLS

When you deploy a public key infrastructure (PKI) with Active Directory Certificate Services (AD CS), you can use PEAP with EAP-TLS (PEAP-TLS). Certificates provide a much stronger authentication method than the methods that use password-based credentials. PEAP-TLS uses certificates for server authentication and either smart cards, which contain an embedded certificate, or certificates enrolled to client computers that are stored on the local computer in the certificate store, for user and client computer authentication. To use PEAP-TLS, you must deploy a PKI.

PEAP fast reconnect

PEAP fast reconnect enables wireless clients to move between wireless access points on the same network without being reauthenticated each time they associate with a new access point.

Wireless access points are configured as RADIUS clients to RADIUS servers. If a wireless client roams between access points that are configured as clients to the same RADIUS server, the client is not required to be authenticated with each new association. When a client moves to an access point that is configured as a RADIUS client to a different RADIUS server, although the client is reauthenticated, this process occurs much more efficiently and quickly.

PEAP fast reconnect reduces the response time for authentication between client and authenticator because the authentication request is forwarded from the new access point to the NPS server that originally performed authentication and authorization for the client connection request. Because both the PEAP client and NPS server use previously cached TLS connection properties (the collection of which is named the TLS handle), the NPS server can quickly determine that the client connection is a reconnect.

The client can cache TLS handles for multiple PEAP authenticators. If the original NPS server is unavailable, full authentication must occur between the client and the new authenticator. The TLS handle for the new PEAP authenticator is cached by the client. For smart cards or PEAP-MS-CHAP v2 authentication, the user is asked to supply the PIN or credentials, respectively.
With PEAP-MS-CHAP v2 authentication:

When the new access point is a client to the same RADIUS server | When the new access point is a client to a new RADIUS server
The user is not prompted for credentials each time the client computer associates with a new access point. | The user is prompted for credentials on this initial association. The next time the client computer associates with an access point that is a client to this server, user credentials are not required.
The RADIUS server is not required to provide a certificate. | The RADIUS server provides a certificate on this initial association so that the wireless client can authenticate to the RADIUS server. The next time the client computer associates with an access point that is a client to this server, the server is not required to be reauthenticated.
With PEAP-TLS authentication:

When the new access point is a client to the same RADIUS server | When the new access point is a client to a new RADIUS server
The client and server are not required to exchange certificates. | The client and server exchange certificates on this initial association. The next time the client computer associates with an access point that is a client to this server, certificates are not exchanged.
The user is not prompted for a smart card personal identification number (PIN) each time the client computer associates with a new access point. | The user is prompted for a smart card PIN on this initial association. The next time the client computer associates with an access point that is a client to this server, the user is not prompted for the PIN.

To enable PEAP fast reconnect:

  • Both the PEAP client (802.11 wireless client) and PEAP authenticator (RADIUS server) must have fast reconnect enabled.

  • All access points to which the PEAP client roams must be configured as RADIUS clients to a RADIUS server (the PEAP authenticator) for which PEAP is configured as the authentication method for wireless connections.

  • All access points to which the PEAP client associates must be configured to prefer the same RADIUS server (PEAP authenticator) to avoid being prompted for credentials from every RADIUS server. If the access point cannot be configured to prefer a RADIUS server, you can configure an NPS RADIUS proxy with a preferred RADIUS server.

Additional information
  • PEAP does not support guest authentication.

  • When you deploy both PEAP and EAP unprotected by PEAP, do not use the same EAP authentication type with and without PEAP. For example, if you deploy PEAP-TLS, do not also deploy EAP-TLS without PEAP. Deploying authentication methods with the same type creates a security vulnerability.


Deploying Certificates for PEAP and EAP

You can use the following sections to deploy your own certification authority (CA) with Active Directory® Certificate Services (AD CS) and to automatically enroll certificates to servers running Network Policy Server (NPS), domain member client computers, and domain users.

  • Deploy Client Computer Certificates

  • Deploy User Certificates

  • Deploy a CA and NPS Server Certificate


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 group and the Domain Admins group of the root domain is the minimum required to complete this procedure.

Important

If you have already deployed server certificates using the steps provided in NPS Server Certificate: Configure the Template and Autoenrollment, you do not need to perform steps 13 through 20 of this procedure. These steps are used to configure computer certificate autoenrollment, and they are the same steps found in the aforementioned topic.

To configure the certificate template and autoenrollment

  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. The Add or Remove Snap-ins dialog box opens.

  3. In Available snap-ins, double-click Certification Authority. Select the certification authority (CA) that you want to manage by using 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.

  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 box 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. The Add or Remove Snap-ins dialog box opens.

  15. In the Add or Remove Snap-ins dialog box, in Available snap-ins, double-click Group Policy Management Editor. The Select Group Policy Object wizard opens. Click Browse, and then select Default Domain Policy. Click OK, click Finish, and then click OK again.

  16. Double-click Default Domain Policy. Open Computer Configuration, then Policies, then Windows Settings, then Security Settings, and then Public Key Policies.

  17. In the details pane, double-click Certificate Services Client - Auto-Enrollment. The Certificate Services Client - Auto-Enrollment Properties dialog box opens.

  18. In the Certificate Services Client - Auto-Enrollment 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, restart the client computer or, at the command prompt, run gpupdate.


Deploy User Certificates

You can use this procedure to configure the certificate template that Active Directory® Certificate Services (AD CS) uses as the basis for user certificates that are enrolled to members of the domain users group.

Membership in both the Enterprise Admins group and the Domain Admins group of the root domain is the minimum required to complete this procedure.

To configure the certificate template and autoenrollment

  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. The Add or Remove Snap-ins dialog box opens.

  3. In Available snap-ins, double-click Certification Authority. Select the certification authority (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 User 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.

  9. Click the Security tab. In Group or user names, click Domain Users.

  10. In Permissions for Domain Users, 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 box 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 User, 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. The Add or Remove Snap-ins dialog box opens.

  15. In the Add or Remove Snap-ins dialog box, in Available snap-ins, double-click Group Policy Management Editor. The Select Group Policy Object wizard opens. Click Browse, and then select Default Domain Policy. Click OK, click Finish, and then click OK again.

  16. Click Default Domain Policy. Open User Configuration, then Policies, then Windows Settings, then Security Settings, and then Public Key Policies.

  17. In the details pane, double-click Certificate Services Client - Auto-Enrollment. The Certificate Services Client - Auto-Enrollment Properties dialog box opens.

  18. In the Certificate Services Client - Auto-Enrollment 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 users automatically enroll a user certificate when Group Policy is refreshed. To refresh Group Policy, restart the client computer or, at the command prompt, run gpupdate.

Ensure that all appropriate domain system containers are configured for autoenrollment of user certificates either through the inheriting of Group Policy settings of a parent system container or through explicit configuration.


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:

  1. Install the AD CS server role. This step is required only if you have not already deployed a certification authority (CA) on your network.

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

  3. 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 issuing CA 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 Extensible Authentication Protocol-Transport Layer Security (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 by using one of the following methods:

  • Manually import an 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 EAP or Protected EAP (PEAP) authentication because the private keys of the certificate 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 Microsoft Management Console (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


NPS Server Certificate: 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 group and the Domain Admins group of the root domain 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 Domain Admins group.

  2. Click Start, click Administrative Tools, and then click Server Manager. The Server Manager console opens. In the left pane, click Roles, and then in the details pane, 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 Introduction to Active Directory Certificate Services page, review the provided information, and then click Next.

  7. On the Select Role Services page, ensure that Certification Authority is selected, select any additional role services that you require, and then click Next.

  8. On the Specify Setup Type page, ensure that Enterprise is selected, and then click Next.

  9. On the Specify CA Type page, click Root CA, and then click Next.

  10. On the Set Up Private Key page, ensure that Create a new private key is selected, and then click Next.

  11. On the Configure Cryptography for CA page, keep the default settings or change them according to your requirements. Note that the default Key character length is 2048, which is twice as large as previous default key character lengths of 1024. Depending on your network size and traffic, you might want to adjust the size of the key character length. Click Next.

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

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

  14. 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 by using access control lists (ACLs) that prevent unauthorized users or computers from accessing the CA database and log files. Click Next, and then click Finish or continue with the installation of any additional role services you selected.


NPS Server Certificate: Configure the 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 that are enrolled to servers running Network Policy Server (NPS).

Membership in both the Enterprise Admins and the Domain Admins group of the root domain 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. 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.

  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. The Enable Certificate Templates dialog box opens.

  12. In Enable Certificate Templates, 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 Servers, 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. The Add or Remove Snap-ins dialog box opens.

  15. In Available snap-ins, double-click Group Policy Management Editor. The Select Group Policy Object wizard opens. Click Browse, and then select the Default Domain Policy. Click OK, click Finish, and then click OK again.

  16. Double-click Default Domain Policy. Open Computer Configuration, Policies, Windows Settings, Security Settings, and then select Public Key Policies.

  17. In the details pane, double-click Certificate Services Client - Auto-Enrollment. The Certificate Services Client - Auto-Enrollment Properties dialog box opens.

  18. In the Certificate Services Client - Auto-Enrollment 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, servers running NPS automatically enroll a server certificate when Group Policy is refreshed. To refresh Group Policy, restart the server or, at the command prompt, run gpupdate.

See Also

  • NPS Server Certificate: CA Installation


Checklists for NPS

Checklists for Network Policy Server (NPS)

The following checklists provide the steps required to deploy NPS as a Remote Authentication Dial-In User Service (RADIUS) server, RADIUS proxy, and Network Access Protection (NAP) policy server.

  • Checklist: Configure NPS for 802.1X Authenticating Switch Access

  • Checklist: Configure NPS for Dial-Up and VPN Access

  • Checklist: Configure NPS as a RADIUS Proxy

  • Checklist: Configure NPS for Secure Wireless Access

  • Checklist: Configure Network Access Protection (NAP)


Checklist: Configure NPS for 802.1X Authenticating Switch Access

This checklist provides the tasks required to deploy 802.1X authenticating switches with Network Policy Server (NPS).

Task | Reference
Install and configure 802.1X authenticating switches on your network. | RADIUS Server for 802.1X Wireless or Wired Connections and your hardware documentation
Determine the authentication method you want to use. | RADIUS Server for 802.1X Wireless or Wired Connections; Certificate Requirements for PEAP and EAP; EAP Overview; PEAP Overview; and your hardware documentation
Autoenroll a server certificate to servers running NPS or, if you are using Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) only, optionally purchase a server certificate rather than deploying your own CA. | Deploy a CA and NPS Server Certificate and Obtaining and Installing a VeriSign WLAN Server Certificate for PEAP-MS-CHAP v2 Wireless Authentication on the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkId=33675.
If you are using Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) or PEAP-TLS without smart cards, autoenroll user certificates, computer certificates, or both user and computer certificates, to domain member client computers. | Deploy Client Computer Certificates; Deploy User Certificates
Configure 802.1X wired access clients by using the Group Policy Management extension, Wired Network (IEEE 802.3) Policies. | Configure 802.1X Wired Access Clients by using Group Policy Management
Configure 802.1X authenticating switches as Remote Authentication Dial-In User Service (RADIUS) clients in NPS. | Add a New RADIUS Client and RADIUS Client
Create a user group in Active Directory® Domain Services (AD DS) that contains the users who are allowed to access the network through the switches. | Create a Group for a Network Policy
In NPS, configure one or more network policies for 802.1X switch access. | Add a Network Policy; Create policies for 802.1X Wired or Wireless with a Wizard; and Network Policies


Checklist: Configure NPS for Dial-Up and VPN Access

This checklist provides the tasks required to deploy dial-up and virtual private network (VPN) servers with Network Policy Server (NPS).

Task | Reference
Install and configure dial-up and VPN servers. | RADIUS Server for Dial-Up or VPN Connections and your hardware documentation
Determine the authentication method that you want to use. | RADIUS Server for Dial-Up or VPN Connections; Certificate Requirements for PEAP and EAP; and your hardware documentation
Autoenroll a server certificate to servers running NPS or, if you are using Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) only, purchase a server certificate. | Deploy a CA and NPS Server Certificate and Obtaining and Installing a VeriSign WLAN Server Certificate for PEAP-MS-CHAP v2 Wireless Authentication on the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkId=33675
If you are using Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) or PEAP-TLS without smart cards, autoenroll user certificates, computer certificates, or both user and computer certificates, to domain users and domain member client computers. | Deploy Client Computer Certificates and Deploy User Certificates
Configure dial-up and VPN servers as Remote Authentication Dial-In User Service (RADIUS) clients in NPS. | Add a New RADIUS Client and RADIUS Client
Create a user group in Active Directory® Domain Services (AD DS) that contains the users who are allowed to access the network through the VPN servers. | Create a Group for a Network Policy
In NPS, configure one or more network policies for dial-up and VPN servers. | Add a Network Policy; Create Policies for Dial-Up or VPN with a Wizard; and Network Policies


Checklist: Configure NPS as a RADIUS Proxy

The following checklist provides the tasks required to configure Network Policy Server (NPS) as a Remote Authentication Dial-In User Service (RADIUS) proxy that forwards connection requests to other RADIUS servers for authentication and authorization.

Important

Client computers, such as wireless portable 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-capable 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.

Task | Reference
Configure network access servers as RADIUS clients in NPS. | Add a New RADIUS Client; RADIUS Client
On the NPS proxy server, use the New Remote RADIUS Server Group Wizard to create a remote server group with one or more RADIUS servers to which RADIUS messages are forwarded. Configure RADIUS ports and shared secrets that are common to both the NPS proxy server and the RADIUS servers (to which requests are forwarded). | Add a Remote RADIUS Server Group and Remote RADIUS Server Groups
On the NPS proxy server, use the New Connection Request Policy Wizard to create a connection request policy to forward connection requests and accounting information to the remote RADIUS server group. | Add a Connection Request Policy and Connection Request Policies
Configure logging methods for user authentication and accounting requests. | RADIUS Accounting and Configure Log File Properties
Register the NPS proxy servers in Active Directory® Domain Services (AD DS) domains. | Register the NPS Server in Active Directory Domain Services
Configure the NPS proxy servers as RADIUS clients on the RADIUS servers (to which requests are forwarded). | Add a New RADIUS Client and your hardware documentation


Checklist: Configure NPS for Secure Wireless Access

This checklist provides the tasks required to deploy 802.1X wireless access points with Network Policy Server (NPS).

Task | Reference
Install and configure 802.1X wireless access points on your network. | RADIUS Server for 802.1X Wireless or Wired Connections and your hardware documentation
Determine the authentication method you want to use. | RADIUS Server for 802.1X Wireless or Wired Connections; Certificate Requirements for PEAP and EAP; EAP Overview; PEAP Overview; and your hardware documentation
Autoenroll a server certificate to servers running NPS or purchase a server certificate. | Deploy a CA and NPS Server Certificate and Obtaining and Installing a VeriSign WLAN Server Certificate for PEAP-MS-CHAP v2 Wireless Authentication on the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkId=33675
If you are using Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) or Protected Extensible Authentication Protocol-Transport Layer Security (PEAP-TLS) without smart cards, autoenroll client or computer certificates to domain member client computers. | Deploy Client Computer Certificates and Deploy User Certificates
Configure 802.1X wireless access clients by using the Group Policy Management extension, Wireless Network (IEEE 802.11) Policies. | Configure 802.1X Wireless Access Clients by using Group Policy Management
Configure 802.1X wireless access points as Remote Authentication Dial-In User Service (RADIUS) clients in NPS. | Add a New RADIUS Client and RADIUS Client
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; and Network Policies


Checklist: Configure Network Access Protection (NAP)

Network Access Protection information is available in the Networking section of the Windows Server® 2008 and Windows Server® 2008 R2 Technical Library on the Web. For more information, see Networking at http://go.microsoft.com/fwlink/?LinkId=139900.


Configure NPS UDP Port Information

You can use the following procedure to configure the ports that Network Policy Server (NPS) uses for Remote Authentication Dial-In User Service (RADIUS) authentication and accounting traffic.

By default, NPS listens for RADIUS traffic on ports 1812, 1813, 1645, and 1646 for both Internet Protocol version 6 (IPv6) and IPv4 for all installed network adapters.

Note

If you uninstall either IPv4 or IPv6 on a network adapter, NPS does not monitor RADIUS traffic for the uninstalled protocol.

The port values of 1812 for authentication and 1813 for accounting are RADIUS standard ports defined by the Internet Engineering Task Force (IETF) in RFCs 2865 and 2866. However, by default, many access servers use ports 1645 for authentication requests and 1646 for accounting requests. No matter which port numbers you decide to use, make sure that NPS and your access server are configured to use the same ones.

Important

If you do not use the RADIUS default port numbers, you must configure exceptions on the firewall for the local computer to allow RADIUS traffic on the new ports. For more information, see NPS and Firewalls.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure NPS UDP port information

  1. Open the NPS console.

  2. Right-click Network Policy Server, and then click Properties.

  3. Click the Ports tab, and then examine the settings for ports. If your RADIUS authentication and RADIUS accounting UDP ports vary from the default values provided (1812 and 1645 for authentication, and 1813 and 1646 for accounting), type your port settings in Authentication and Accounting.

  4. To use multiple port settings for authentication or accounting requests, separate the port numbers with commas.

See Also

  • Configure NPS on a Multihomed Computer


Configure NPS on a Multihomed Computer

When you use multiple network adapters in a server running Network Policy Server (NPS), you can configure the following:

  • The network adapters that do and do not send and receive Remote Authentication Dial-In User Service (RADIUS) traffic.

  • On a per-network adapter basis, whether NPS monitors RADIUS traffic on Internet Protocol version 4 (IPv4), IPv6, or both IPv4 and IPv6.

  • The UDP port numbers over which RADIUS traffic is sent and received on a per-protocol (IPv4 or IPv6), per-network adapter basis.

By default, NPS listens for RADIUS traffic on ports 1812, 1813, 1645, and 1646 for both IPv6 and IPv4 for all installed network adapters. Because NPS automatically uses all network adapters for RADIUS traffic, you only need to specify the network adapters that you want NPS to use for RADIUS traffic when you want to prevent NPS from using a specific network adapter.

Note

If you uninstall either IPv4 or IPv6 on a network adapter, NPS does not monitor RADIUS traffic for the uninstalled protocol.

On an NPS server that has multiple network adapters installed, you might want to configure NPS to send and receive RADIUS traffic only on the adapters you specify.

For example, one network adapter installed in the NPS server might lead to a network segment that does not contain RADIUS clients, while a second network adapter provides NPS with a network path to its configured RADIUS clients. In this scenario, it is important to direct NPS to use the second network adapter for all RADIUS traffic.

In another example, if your NPS server has three network adapters installed, but you only want NPS to use two of the adapters for RADIUS traffic, configure port information for the two adapters only. By excluding port configuration for the third adapter, you prevent NPS from using the adapter for RADIUS traffic.

Using a network adapter

To configure NPS to listen for and send RADIUS traffic on a network adapter, use the following syntax on the Properties dialog box of Network Policy Server in the NPS console:

  • IPv4 traffic syntax: IPAddress:UDPport, where IPAddress is the IPv4 address that is configured on the network adapter over which you want to send RADIUS traffic, and UDPport is the RADIUS port number that you want to use for RADIUS authentication or accounting traffic.

  • IPv6 traffic syntax: [IPv6Address]:UDPport, where the brackets around IPv6Address are required, IPv6Address is the IPv6 address that is configured on the network adapter over which you want to send RADIUS traffic, and UDPport is the RADIUS port number that you want to use for RADIUS authentication or accounting traffic.

The following characters can be used as delimiters for configuring IP address and UDP port information:

  • Address/port delimiter: colon (:)

  • Port delimiter: comma (,)

  • Interface delimiter: semicolon (;)

Configuring network access servers

Make sure that your network access servers are configured with the same RADIUS UDP port numbers that you configure on your NPS servers. The RADIUS standard UDP ports defined in RFCs 2865 and 2866 are 1812 for authentication and 1813 for accounting; however, some access servers are configured by default to use UDP port 1645 for authentication requests and UDP port 1646 for accounting requests.

Important

If you do not use the RADIUS default port numbers, you must configure exceptions on the firewall for the local computer to allow RADIUS traffic on the new ports. For more information, see NPS and Firewalls.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To specify the network adapter and UDP ports that NPS uses for RADIUS traffic

  1. Open the NPS console.

  2. Right-click Network Policy Server, and then click Properties.

  3. Click the Ports tab, and prepend the IP address for the network adapter you want to use for RADIUS traffic to the existing port numbers. For example, if you want to use the IP address 192.168.1.2 and RADIUS ports 1812 and 1645 for authentication requests, change the port setting from 1812,1645 to 192.168.1.2:1812,1645.

    If your RADIUS authentication and RADIUS accounting UDP ports are different from the default values, change the port settings accordingly.

  4. To use multiple port settings for authentication or accounting requests, separate the port numbers with commas.

See Also

  • Configure NPS UDP Port Information


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


802.1X Client Configuration with Group Policy

You can use the procedures in the first section to access Group Policy extensions for wired and wireless policies. You can select from the other two sections for procedures to configure clients by using the Wired Network (IEEE 802.3) Policies and Wireless Network (IEEE 802.11) Policies extensions of Group Policy Management.

  • Access Group Policy Extensions for 802.1X Wired and Wireless

  • Configure 802.1X Wired Access Clients by using Group Policy Management

  • Configure 802.1X Wireless Access Clients by using Group Policy Management


Access Group Policy Extensions for 802.1X Wired and Wireless

This section provides procedures about how to activate and open Wired Network (IEEE 802.3) Policies and Wireless Network (IEEE 802.11) Policies and then access those policies for viewing or modification.

If you have already activated the policy that you want to access, you need only to follow the procedures in the topic Open Wired or Wireless Network Policies for Editing. Otherwise, you must follow the steps in the first two procedures to open the correct Group Policy object (GPO), and then activate the policy, before you can open the policy that you want to access.

  • Open or Add and Open a Group Policy Object

  • Activate Default Wired or Wireless Network Policies

  • Open Wired or Wireless Network Policies for Editing


Open or Add and Open a Group Policy Object

By default, Group Policy Management is installed on computers running Windows Server 2008 when the Active Directory Domain Services (AD DS) server role is installed. This procedure describes how to open Group Policy Management on your domain controller running Windows Server 2008. The procedure then describes how to either open an existing domain-level Group Policy object (GPO) for editing, or create a new domain GPO and open it for editing.

Membership in Domain Admins, or equivalent, is the minimum required to perform this procedure.

To open or add and open a Group Policy object

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

  2. In the left pane, double-click your forest. For example, double-click Forest: example.com.

  3. In the left pane, double-click Domains, and then double-click the domain that contains the GPO you want to manage. For example, double-click example.com.

  4. Do one of the following:

    • To open an existing domain-level GPO for editing, double click the domain that contains the GPO that you want to manage, right-click the domain policy you want to manage, and then click Edit.

    • To create a new Group Policy object and open for editing, right-click the domain for which you want to create a new GPO, and then click Create a GPO in this domain, and link it here.

      In New GPO, in Name, type a name for the new GPO, and then click OK.

      Right-click your new GPO, and then click Edit. Group Policy Management Editor opens.


Activate Default Wired or Wireless Network Policies

Use this procedure to activate default Wired Network (IEEE 802.3) Policies or Wireless Network (IEEE 802.11) Policies by using the Group Policy Management Editor (GPME).

You do not need to follow this procedure for wired or wireless network policies that are already activated.

Note

After you activate a wired or wireless policy, it is only accessible in the details pane of the GPME when you select the corresponding wired or wireless policy node. This state remains until the wired or wireless policy is deleted, at which time it returns to its inactive state.

Membership in Domain Admins, or equivalent, is the minimum required to perform this procedure.

To activate default wired or wireless network policies

  1. On your domain controller running Windows Server 2008, do one of the following:

    • If Group Policy Management Editor is already open, proceed to step 2.

    • If GPME is not already open, do the following:

      1. Click Start, point to Administrative Tools, and then click Group Policy Management. The Group Policy Management Microsoft Management Console (MMC) opens.

      2. In the left pane, double-click your forest. For example, double-click Forest: example.com.

      3. In the left pane, double-click Domains, and then double-click the domain that contains the Group Policy object (GPO) you want to manage. For example, double-click example.com.

      4. Right-click the domain-level GPO you want to manage, and then click Edit. Group Policy Management Editor opens.

  2. In Group Policy Management Editor, in the left pane, double-click Computer Configuration, double-click Windows Settings, and then double-click Security Settings.

  3. In Security Settings, right-click either Wired Network (IEEE 802.3) Policies or Wireless Network (IEEE 802.11) Policies, and then click the appropriate option from the following list:

    • For Wired Network (IEEE 802.3) Policies, click Create a New Wired Network Policy for Windows Vista and Later Releases.

    • For Wireless Network (IEEE 802.11) Policies for computers running Windows® 7 and Windows Vista®, click Create a New Wireless Network Policy for Windows Vista and Later Releases.

    • For Wireless Network (IEEE 802.11) Policies for computers running Windows XP, click Create a new XP Wireless Policy.

  4. The Properties dialog box for the policy you selected opens. Click OK. The default policy you selected is activated and listed in the details pane of Group Policy Management Editor.

To access the properties of a policy, in the details pane, right-click the policy that you want, and then click Properties.


Open Wired or Wireless Network Policies for Editing

You can use this procedure to open activated policies by using the Wireless Network (IEEE 802.11) Policies extension of Group Policy Management.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To open an activated policy by using Wireless Network (IEEE 802.11) Policies

  1. On your domain controller running Windows Server 2008 do one of the following:

    • If Group Policy Management Editor is already open, proceed to step 2.

    • If Group Policy Management Editor is not already open, do the following:

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

      2. In the left pane, double-click your forest. For example, double-click Forest: example.com.

      3. In the left pane, double-click Domains, and then double-click the domain that contains the Group Policy object (GPO) you want to manage. For example, double-click example.com.

      4. Right-click the GPO you want to manage, and then click Edit. For example, right-click Default Domain Policy, and then click Edit. Group Policy Management Editor opens.

        Note

        The GPO that you select must be the same GPO that you specified when you activated the Wireless Network (IEEE 802.11) Policies.

  2. In Group Policy Management Editor, in the left pane, open Computer Configuration, open Policies, open Windows Settings, open Security Settings, and then select either Wired Network (IEEE 802.3) Policies or Wireless Network (IEEE 802.11) Policies, depending on which policies you want to configure.

  3. In the details pane, right-click one of the following, and then click Properties:

    • New Wired Network Policy for computers running Windows 7, Windows Vista, or Windows XP with Service Pack 3 that use 802.1X authenticated wired connections on your network.

    • New Wireless Network Policy for computers running Windows 7 or Windows Vista that use 802.1X authenticated wireless connections on your network.

    • New XP Wireless Network Policy for computers running Windows XP that use 802.1X authenticated wireless connections on your network.

    The properties dialog box for the policy you selected opens.

The wired and wireless network policies are not necessarily named New Wired Network Policy, New Wireless Network Policy or New XP Wireless Network Policy in the details pane of the Group Policy Management Editor. If the default policy name was previously changed to another name, the name change is reflected in the Group Policy Management Editor details pane. However, Wireless Network (IEEE 802.11) policies are differentiated with the Type specified as either Vista or XP.


Configure 802.1X Wired Access Clients by using Group Policy Management

You can use the procedures in this section to configure Wired Network (IEEE 802.3) Policies for client computers running Windows® 7, Windows Vista®, and Windows XP with Service Pack 3 that connect to your wired Ethernet network by using 802.1X authenticating switches.

By default, you can use Wired Network (IEEE 802.3) Policies, which is a Group Policy extension, to configure the following 802.1X authentication on your wired access client computers:

  • Extensible Authentication Protocol (EAP) with Transport Layer Security (TLS), for authentication using smart cards or other certificates.

  • Protected EAP (PEAP)–TLS, for authentication using smart cards or other certificates.

  • PEAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), for authentication using secure passwords.

The following sections provide procedures about how to configure Wired Network (IEEE 802.3) Policies for computers running Windows® 7, Windows Vista®, and Windows XP with Service Pack 3:

  • Configure 802.1X Wired Access Clients for PEAP-MS-CHAP v2 Authentication

  • Configure 802.1X Wired Access Clients for PEAP-TLS Authentication

  • Configure 802.1X Wired Access Clients for EAP-TLS Authentication

Membership in Domain Admins, or equivalent, is the minimum required to complete these procedures.

Note

For information about activating or opening Wired Network (IEEE 802.3) Policies, see Access Group Policy Extensions for 802.1X Wired and Wireless.


Configure 802.1X Wired Access Clients for PEAP-MS-CHAP v2 Authentication

Use this procedure to configure a Protected Extensible Authentication Protocol–Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) profile for client authentication by using secured passwords.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

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.

    4. To permit users with computers running Windows 7 to enter and store their domain credentials (username and password), which the computer can then use to log on to the network (even though the user is not actively logged on), in Windows 7 Policy Settings, select Enable Explicit Credentials.

    5. To specify the duration for which computers running Windows 7 are prohibited from making auto connection attempts to the network, select Enable Block Period, and then in Block Period (minutes), specify the number of minutes for which you want the block period to apply. The valid range of minutes is 1–60.

      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 Microsoft: Protected EAP (PEAP).

    3. In Authentication mode, select from the following, depending on your needs: User or Computer authentication (recommended), Computer authentication, User authentication, Guest authentication. By default, User or Computer authentication is selected.

    4. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed. By default, the value is set to “1.”

    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

      • This network uses different VLAN for authentication with machine and user credentials

  4. Click OK. The Advanced Security Settings dialog box closes, returning you to the Security tab. On the Security tab, click Properties. The Protected EAP Properties dialog box opens.

  5. In the Protected EAP Properties dialog box, do the following:

    1. Select Validate server certificate.

    2. To specify which Remote Authentication Dial-In User Service (RADIUS) servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server certificate. Use semicolons to specify multiple RADIUS server names.

    3. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your server running 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 trust all trusted root CAs in their trusted root certification authority store.

    4. For improved security and a better user experience, select Do not prompt user to authorize new servers or trusted certification authorities.

    5. In Select Authentication Method, select Secured Password (EAP-MSCHAP v2).

    6. To specify that PEAP Fast Reconnect is enabled, select Enable Fast Reconnect.

    7. To specify that Network Access Protection (NAP) performs system health checks on clients to ensure they meet health requirements, before connections to the network are permitted, select Enforce Network Access Protection.

    8. To require cryptobinding Type-Length-Value (TLV), select Disconnect if server does not present cryptobinding TLV.

    9. To configure your clients so that they do not send their identity in plaintext before the client has authenticated the RADIUS server, select Enable Identity Privacy, and in Anonymous Identity, type a name or value, or leave the field empty.

      For example, if Enable Identity Privacy is enabled, and you use “guest” as the anonymous identity value, the identity response for a user with identity alice@realm is guest@realm. If you select Enable Identity Privacy but do not provide an anonymous identity value, the identity response is @realm.

    10. Click OK, to save the Protected EAP Properties settings, and then click OK again to save the policy.


Configure 802.1X Wired Access Clients for PEAP-TLS Authentication

Use this procedure to configure a Protected Extensible Authentication Protocol-Transport Layer Security (PEAP-TLS) profile for client authentication by using smart cards or other certificates.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure a profile for PEAP-TLS 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.

    4. To permit users with computers running Windows 7 to enter and store their domain credentials (username and password), which the computer can then use to log on to the network (even though the user is not actively logged on), in Windows 7 Policy Settings, select Enable Explicit Credentials.

    5. To specify the duration for which computers running Windows 7 are prohibited from making auto connection attempts to the network, select Enable Block Period, and then in Block Period (minutes), specify the number of minutes for which you want the block period to apply. The valid range of minutes is 1–60.

      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 Microsoft: Protected EAP (PEAP).

    3. In Authentication mode, select from the following, depending on your needs: User or Computer authentication, Computer authentication, User authentication, Guest authentication. By default, User or Computer authentication is selected.

    4. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed. By default, the value is set to “1.”

    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

      • This network uses different VLAN for authentication with machine and user credentials

  4. Click OK. The Advanced Security Settings dialog box closes, returning you to the Security tab. On the Security tab, click Properties. The Protected EAP Properties dialog box opens.

  5. In the Protected EAP Properties dialog box, do the following:

    1. Select Validate server certificate.

    2. To specify which Remote Authentication Dial-In User Service (RADIUS) servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server’s certificate. Use semicolons to specify multiple RADIUS server names.

    3. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your servers running 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 trust all trusted root CAs in their trusted root certification authority store.

    4. For improved security and a better user experience, select Do not prompt user to authorize new servers or trusted certification authorities.

    5. In Select Authentication Method, select Smart Card or other certificate.

    6. To enable PEAP fast reconnect, select Enable Fast Reconnect.

    7. To specify that Network Access Protection (NAP) performs system health checks on clients to ensure they meet health requirements, before connections to the network are permitted, select Enforce Network Access Protection.

    8. To require cryptobinding Type-Length Value (TLV), select Disconnect if server does not present cryptobinding TLV.

    9. To configure your clients so that they do not send their identity in plaintext before the client has authenticated the RADIUS server, select Enable Identity Privacy, and then in Anonymous Identity, type a name or value, or leave the field empty.

      For example, if Enable Identity Privacy is enabled, and you use “guest” as the anonymous identity value, the identity response for a user with identity alice@realm is guest@realm. If you select Enable Identity Privacy, but do not provide an anonymous identity value, the identity response is @realm.

    10. To configure PEAP-TLS properties, click Configure, and then in Smart Card or other Certificate Properties, configure the following items according to your needs:

      • In When connecting, select either Use my smart card, or select both Use a certificate on this computer and Use simple certificate selection (Recommended).

      • To require that access clients validate the NPS server certificate, select Validate server certificate.

      • To specify which RADIUS servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server’s certificate. Use semicolons to specify multiple RADIUUS server names.

      • In Trusted Root Certification Authorities, select the CA that issued NPS server certificates on your network.

      • To specify that clients use an alternate name for the access attempt, select Use a different user name for the connection.

      • To prevent users from being prompted to trust a server certificate if that certificate is incorrectly configured, is not already trusted, or both, select Do not prompt user to authorize new servers or trusted certification authorities. (Recommended)

      • Click OK to close the Smart card or other Certificate Properties dialog box, and then click OK again to close the Protected EAP (PEAP) Properties dialog box. This returns you to the New Wired Network Policy Properties dialog box.


Configure 802.1X Wired Access Clients for EAP-TLS Authentication

Use this procedure to configure an Extensible Authentication Protocol–Transport Layer Security (EAP-TLS) profile for authentication that uses smart cards or other certificates.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure an EAP-TLS profile for 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.

    4. To permit users with computers running Windows 7 to enter and store their domain credentials (username and password), which the computer can then use to log on to the network (even though the user is not actively logged on), in Windows 7 Policy Settings, select Enable Explicit Credentials.

    5. To specify the duration for which computers running Windows 7 are prohibited from making auto connection attempts to the network, select Enable Block Period, and then in Block Period (minutes), specify the number of minutes for which you want the block period to apply. The valid range of minutes is 1-60.

      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 from the following, depending on your needs: User or Computer authentication, Computer authentication, User authentication, Guest authentication. By default, User or Computer authentication is selected.

    4. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed. By default, the value is set to “1.”

    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

      • This network uses different VLAN for authentication with machine and user credentials

  4. Click OK. The Advanced Security Settings dialog box closes, returning you to the Security tab. On the Security tab, click Properties. The Smart Card or other Certificate Properties dialog box opens.

  5. On the Smart Card or other Certificate Properties dialog box, do the following:

    1. In When connecting, select either Use my smart card, or select both Use a certificate on this computer and Use simple certificate selection (Recommended).

    2. Select Validate server certificate.

    3. To specify which Remote Authentication Dial-In User Service (RADIUS) servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server’s certificate. Use semicolons to specify multiple RADIUS server names.

    4. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your server running 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.

    5. To specify that clients use an alternate name for the access attempt, select Use a different user name for the connection.

    6. For improved security and a better user experience, select Do not prompt user to authorize new servers or trusted certification authorities.

    7. Click OK to save the Smart Card or other Certificate Properties settings. Click OK again to return to the New Wired Network Policy Properties dialog box.


Configure 802.1X Wireless Access Clients by using Group Policy Management

You can use the procedures in this section to configure Wireless Network (IEEE 802.11) Policies for client computers running Windows® 7, Windows Vista®, and Windows XP with Service Pack 3 (SP3) that connect to your wireless network by using 802.1X-capable wireless access points (APs).

By default, you can use the two wireless Group Policy Management extensions — Windows Vista New Wireless Network (IEEE 802.11) Policies and Wireless XP Network (IEEE 802.11) Policies — to configure the following 802.1X authentication:

  • Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), for authentication using smart cards or other certificates.

  • Protected EAP-TLS (PEAP–TLS), for authentication using smart cards or other certificates.

  • PEAP-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2), for authentication using secure passwords.

You can configure computers running Windows 7, and Windows Vista by using the New Wireless Network Policy. You can use the New XP Wireless Policy to configure computers running Windows XP. Because there are separate policies for configuring computers running Windows XP and for computers running Windows Vista and later versions of Windows, the procedures to configure 802.1X authentication for 802.1X wireless access clients by using Group Policy Management are separated into two sections:

  • Configure 802.1X Wireless Access Clients running Windows 7 and Windows Vista

  • Configure 802.1X Wireless Access Clients running Windows XP

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

Note

For information about activating or opening the Wireless Network (IEEE 802.11) Policies, see Access Group Policy Extensions for 802.1X Wired and Wireless.


Configure 802.1X Wireless Access Clients running Windows 7 and Windows Vista

Use the procedures in this section to configure the New Wireless Network Policy for client computers running Windows® 7 and Windows Vista® that connect to your wireless network by using 802.1X-capable wireless access points (APs).

Membership in Domain Admins, or equivalent, is the minimum required to complete these procedures.

  • Configure Wireless Clients running Windows 7 and Windows Vista for PEAP-MS-CHAP v2 Authentication

  • Configure Wireless Clients running Windows 7 and Windows Vista for PEAP-TLS Authentication

  • Configure Wireless Clients running Windows 7 and Windows Vista for EAP-TLS Authentication

  • Configure Network Permissions and Connection Preferences


Configure Wireless Clients running Windows 7 and Windows Vista for PEAP-MS-CHAP v2 Authentication

Use this procedure to configure a Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) wireless profile.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure a PEAP-MS-CHAP v2 wireless profile for computers running Windows 7 and Windows Vista

  1. Open the New Wireless Network (IEEE 802.11) Policies Properties dialog box.

  2. On the General tab, in Policy Name, type a new name for your policy, or leave the default.

  3. In Description, type a description of your policy.

  4. Select Use Windows to configure wireless network settings for clients to specify that WLAN AutoConfig is used to configure wireless network adapter settings.

  5. On the General tab, do one of the following:

    • To add and configure a new profile, click Add, and then select Infrastructure.

    • To edit an existing profile, select the profile you want to modify, and then click Edit.

  6. On the Connection tab, in Profile Name, if you are adding a new profile, type a name for the profile. If you are editing a profile that is already added, use the existing profile name, or modify the name as needed.

  7. In Network Name(s) (SSID), type the service set identifier (SSID) for your wireless APs, and then click Add.

    If your deployment uses multiple SSIDs and each wireless AP uses the same wireless security settings, repeat this step to add the SSID for each wireless AP to which you want this profile to apply.

    If your deployment uses multiple SSIDs and the security settings for each SSID do not match, configure a separate profile for each group of SSIDs that use the same security settings. For example, if you have one group of wireless APs configured to use WPA2-Enterprise and AES, and another group of wireless APs to use WPA-Enterprise and TKIP, configure a profile for each group of wireless APs.

  8. To specify that wireless clients automatically connect to wireless APs for which the SSID is specified in Network Name(s) (SSID), select Connect automatically when this network is in range.

  9. To specify that wireless clients connect to networks in order of preference, select Connect to a more preferred network if available.

  10. If you deployed wireless access points that are configured to suppress the broadcast beacon, select Connect even if the network is not broadcasting.

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

  11. Click the Security tab. In Select the security methods for this network, in Authentication, select WPA2-Enterprise if it is supported by your wireless AP and wireless client network adapters. Otherwise, select WPA-Enterprise.

    Note

    Selecting WPA2 exposes settings for Fast Roaming that are not displayed if WPA is selected. The default settings for Fast Roaming are sufficient for most wireless deployments.

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

  13. In Select a network authentication method, select Microsoft: Protected EAP (PEAP).

  14. In Authentication mode, select from the following, depending on your needs: User or Computer authentication, Computer authentication, User authentication, Guest authentication. By default, User or Computer authentication is selected.

  15. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed. By default, the value is set to “1.”

  16. To specify that user credentials are held in cache, select Cache user information for subsequent connections to this network.

  17. Click Advanced, and then configure the following:

    1. To configure advanced 802.1X settings, in IEEE 802.1X, select Enforce advanced 802.1X settings, and then configure the following settings, depending on your needs: Max Eapol-Start Msgs, Held Period, Start Period, and Auth Period.

      When the advanced 802.1X settings are enforced, the default values are sufficient for most wireless deployments.

    2. To enable Single Sign On, select Enable Single Sign On for this network.

    3. To specify when Single Sign On occurs, select either Perform immediately before User Logon or Perform immediately after User Logon, depending on your needs.

      The remaining default values in Single Sign On are sufficient for typical wireless deployments.

    4. To specify the maximum amount of time, in seconds, in which 802.1X authentication must complete and authorize network access, in Max delay for connectivity (seconds), enter a value, depending on your needs.

    5. To allow dialogs during Single Sing On, select Allow additional dialogs to be displayed during Single Sign On.

    6. To specify that wireless computers are placed on one virtual local area network (VLAN) at startup, and then transitioned to a different network after the user logs on to the computer, select This network uses different VLAN for authentication with machine and user credentials.

    7. To enable Fast Roaming, in Fast Roaming, select Enable Pairwise Master Key (PMK) Caching. The default values for PMK Time to Live (minutes) and Number of entries in PMK Cache are typically sufficient for Fast Roaming.

    8. Select This network uses pre-authentication, if your wireless AP is configured for pre-authentication. The default value of 3 is typically sufficient for Maximum Pre-authentication attempts.

    9. To specify that cryptography adheres to the FIPS 140-2 certified mode, select Perform cryptography in FIPS 140-2 certified mode.

  18. Click OK to save your settings and return to the Security tab.

  19. Click Properties. The Protected EAP Properties dialog box opens.

  20. In Protected EAP Properties, verify that Validate server certificate is selected.

  21. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your server running Network Policy Server (NPS).

    Note

    This setting limits the trusted root CAs that clients trust to the selected CAs. If no trusted root CAs are selected, then clients trust all root CAs listed in their trusted root certification authority store.

  22. To specify which Remote Authentication Dial-In User Service (RADIUS) servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server certificate. Use semicolons to specify multiple RADIUS server names.

  23. For improved security and a better user experience, select Do not prompt user to authorize new servers or trusted certification authorities.

  24. In Select Authentication Method, select Secured Password (EAP-MS-CHAP v2).

  25. To enable PEAP Fast Reconnect, select Enable Fast Reconnect.

  26. To specify that Network Access Protection (NAP) performs system health checks on clients to ensure they meet health requirements, before connections to the network are permitted, select Enforce Network Access Protection.

  27. To require cryptobinding Type-Length-Value (TLV), select Disconnect if server does not present cryptobinding TLV.

  28. To configure your clients so that they will not send their identity in plaintext before the client has authenticated the RADIUS server, select Enable Identity Privacy, and then in Anonymous Identity, type a name or value, or leave the field empty.

    For example, if Enable Identity Privacy is enabled and you use “guest” as the anonymous identity value, the identity response for a user with identity alice@realm is guest@realm. If you select Enable Identity Privacy but do not provide an anonymous identity value, the identity response is @realm.

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

  30. Click OK to save your settings and close the Security tab, and then click OK again to close Vista Wireless Network Policy.


Configure Wireless Clients running Windows 7 and Windows Vista for PEAP-TLS Authentication

Use this procedure to configure a Protected Extensible Authentication Protocol–Transport Layer Security (TLS) profile for authentication using smart cards or other certificates.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure a PEAP-TLS wireless profile for computers running Windows 7 and Windows Vista

  1. Open the New Wireless Network (IEEE 802.11) Policies Properties dialog box.

  2. On the General tab, in Policy Name, type a new name for your policy, or leave the default.

  3. In Description, type a description of your policy.

  4. Select Use Windows to configure wireless network settings for clients to specify that WLAN AutoConfig is used to configure wireless network adapter settings.

  5. On the General tab, do one of the following:

    • To add and configure a new profile, click Add, and then select Infrastructure.

    • To edit an existing profile, select the profile you want to modify, and then click Edit.

  6. On the Connection tab, in Profile Name, if you are adding a new profile, type a name for the profile. If you are editing a profile that is already added, use the existing profile name, or modify the name as needed.

  7. In Network Name(s) (SSID), type the service set identifier (SSID) for your wireless APs, and then click Add.

    If your deployment uses multiple SSIDs and each wireless AP uses the same wireless security settings, repeat this step to add the SSID for each wireless AP to which you want this profile to apply.

    If your deployment uses multiple SSIDs and the security settings for each SSID do not match, configure a separate profile for each group of SSIDs that use the same security settings. For example, if you have one group of wireless APs configured to use WPA2-Enterprise and AES, and another group of wireless APs to use WPA-Enterprise and TKIP, configure a profile for each group of wireless APs.

  8. To specify that wireless clients automatically connect to wireless APs for which the SSID is specified in Network Name(s) (SSID), select Connect automatically when this network is in range.

  9. To specify that wireless clients connect to networks in order of preference, select Connect to a more preferred network if available.

  10. If you deployed wireless access points that are configured to suppress the broadcast beacon, select Connect even if the network is not broadcasting.

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

  11. Click the Security tab. In Select the security methods for this network, in Authentication, select WPA2-Enterprise if it is supported by your wireless AP and wireless client network adapters. Otherwise, select WPA-Enterprise.

    Note

    Selecting WPA2 exposes settings for Fast Roaming that are not displayed if WPA is selected. The default settings for Fast Roaming are sufficient for most wireless deployments.

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

  13. In Select a network authentication method, select Microsoft: Protected EAP (PEAP).

  14. In Authentication mode, select from the following, depending on your needs: User or Computer authentication, Computer authentication, User authentication, Guest authentication. By default, User or Computer authentication is selected.

  15. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed. By default, this value is set to “1.”

  16. To specify that user credentials are held in cache, select Cache user information for subsequent connections to this network.

  17. Click Advanced, and then configure the following:

    1. To configure advanced 802.1X settings, in IEEE 802.1X, select Enforce advanced 802.1X settings, and then configure the following settings, depending on your needs: Max Eapol-Start Msgs, Held Period, Start Period, and Auth Period.

      When the advanced 802.1X settings are enforced, the default values are sufficient for most wireless deployments.

    2. To enable Single Sign On, select Enable Single Sign On for this network.

    3. To specify when Single Sign On occurs, select either Perform immediately before User Logon or Perform immediately after User Logon, depending on your needs.

      The remaining default values in Single Sign On are sufficient for typical wireless deployments.

    4. To specify the maximum amount of time, in seconds, in which 802.1X authentication must complete and authorize network access, in Max delay for connectivity (seconds), enter a value, depending on your needs.

    5. To allow dialogs during Single Sing On, select Allow additional dialogs to be displayed during Single Sign On.

    6. To specify that wireless computers are placed on one virtual local area network (VLAN) at startup, and then transitioned to a different network after the user logs on to the computer, select This network uses different VLAN for authentication with machine and user credentials.

    7. To enable Fast Roaming, in Fast Roaming, select Enable Pairwise Master Key (PMK) Caching. The default values for PMK Time to Live (minutes) and Number of entries in PMK Cache are typically sufficient for Fast Roaming.

    8. Select This network uses pre-authentication, if your wireless AP is configured for pre-authentication. The default value of 3 is typically sufficient for Maximum Pre-authentication attempts.

    9. To specify that cryptography adheres to the FIPS 140-2 certified mode, select Perform cryptography in FIPS 140-2 certified mode.

  18. Click OK to save your settings and return to the Security tab.

  19. Click Properties. The Protected EAP Properties dialog box opens.

  20. In Protected EAP Properties, verify that Validate server certificate is selected.

  21. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your server running Network Policy Server (NPS).

    Note

    This setting limits the trusted root CAs that clients trust to the selected CAs. If no trusted root CAs are selected, then clients trust all root CAs listed in their trusted root certification authority store.

  22. To specify which Remote Authentication Dial-In User Service (RADIUS) servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server certificate. Use semicolons to specify multiple RADIUS server names.

  23. For improved security and a better user experience, select Do not prompt user to authorize new servers or trusted certification authorities.

  24. In Select Authentication Method, select Smart Card or other certificate.

  25. To enable PEAP Fast Reconnect, select Enable Fast Reconnect.

  26. To specify that Network Access Protection (NAP) performs system health checks on clients to ensure they meet health requirements, before connections to the network are permitted, select Enforce Network Access Protection.

  27. To require cryptobinding Type-Length-Value (TLV), select Disconnect if server does not present cryptobinding TLV.

  28. To configure your clients so that they will not send their identity in plaintext before the client has authenticated the RADIUS server, select Enable Identity Privacy, and then in Anonymous Identity, type a name or value, or leave the field empty.

    For example, if Enable Identity Privacy is enabled and you use “guest” as the anonymous identity value, the identity response for a user with identity alice@realm is guest@realm. If you select Enable Identity Privacy but do not provide an anonymous identity value, the identity response is @realm.

  29. Click Configure. In the Smart Card or other Certificate Properties dialog box, in When connecting, select either Use my smart card or select both Use a certificate on this computer and Use simple certificate selection (Recommended).

  30. To require that access clients validate the NPS server certificate, select Validate server certificate.

  31. To specify which RADIUS servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server’s certificate. Use semicolons to specify multiple RADIUUS server names.

  32. In Trusted Root Certification Authorities, select the CA that issued certificates to your NPS servers.

  33. To specify that clients use an alternate name for the access attempt, select Use a different user name for the connection.

  34. To prevent users from being prompted to trust a server certificate if that certificate is incorrectly configured, is not already trusted, or both, select Do not prompt user to authorize new servers or trusted certification authorities. (Recommended)

  35. Click OK to close the Smart card or other Certificate Properties dialog box, and then click OK again to close the Protected EAP (PEAP) Properties dialog box, returning you to New Wireless Network Policy Properties.


Configure Wireless Clients running Windows 7 and Windows Vista for EAP-TLS Authentication

Use this procedure to configure an Extensible Authentication Protocol–Transport Layer Security (EAP-TLS) profile for authentication using smart cards or other certificates.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure an EAP-TLS wireless profile for computers running Windows Vista

  1. Open the New Wireless Network (IEEE 802.11) Policies Properties dialog box.

  2. On the General tab, in Policy Name, type a new name for your policy, or leave the default.

  3. In Description, type a description of your policy.

  4. Select Use Windows to configure wireless network settings for clients to specify that WLAN AutoConfig is used to configure wireless network adapter settings.

  5. On the General tab, do one of the following:

    • To add and configure a new profile, click Add, and then select Infrastructure.

    • To edit an existing profile, select the profile you want to modify, and then click Edit.

  6. On the Connection tab, in Profile Name, if you are adding a new profile, type a name for the profile. If you are editing a profile that is already added, use the existing profile name, or modify the name as needed.

  7. In Network Name(s) (SSID), type the service set identifier (SSID) for your wireless APs, and then click Add.

    If your deployment uses multiple SSIDs and each wireless AP uses the same wireless security settings, repeat this step to add the SSID for each wireless AP to which you want this profile to apply.

    If your deployment uses multiple SSIDs and the security settings for each SSID do not match, configure a separate profile for each group of SSIDs that use the same security settings. For example, if you have one group of wireless APs configured to use WPA2-Enterprise and AES, and another group of wireless APs to use WPA-Enterprise and TKIP, configure a profile for each group of wireless APs.

  8. To specify that wireless clients automatically connect to wireless APs for which the SSID is specified in Network Name(s) (SSID), select Connect automatically when this network is in range.

  9. To specify that wireless clients connect to networks in order of preference, select Connect to a more preferred network if available.

  10. If you deployed wireless access points that are configured to suppress the broadcast beacon, select Connect even if the network is not broadcasting.

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

  11. Click the Security tab. In Select the security methods for this network, in Authentication, select WPA2-Enterprise if it is supported by your wireless AP and wireless client network adapters. Otherwise, select WPA-Enterprise.

    Note

    Selecting WPA2 exposes settings for Fast Roaming that are not displayed if WPA is selected. The default settings for Fast Roaming are sufficient for most wireless deployments.

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

  13. In Select a network authentication method, select Microsoft: Smart card or other certificate.

  14. In Authentication mode, select from the following, depending on your needs: User or Computer authentication, Computer authentication, User authentication, Guest authentication. By default, User or Computer authentication is selected.

  15. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed. By default, the value is set to “1.”

  16. To specify that user credentials are held in cache, select Cache user information for subsequent connections to this network.

  17. Click Advanced, and then configure the following:

    1. To configure advanced 802.1X settings, in IEEE 802.1X, select Enforce advanced 802.1X settings, and then configure the following settings, depending on your needs: Max Eapol-Start Msgs, Held Period, Start Period, and Auth Period.

      When the advanced 802.1X settings are enforced, the default values are sufficient for most wireless deployments.

    2. To enable Single Sign On, select Enable Single Sign On for this network.

    3. To specify when Single Sign On occurs, select either Perform immediately before User Logon or Perform immediately after User Logon, depending on your needs.

      The remaining default values in Single Sign On are sufficient for typical wireless deployments.

    4. To specify the maximum amount of time, in seconds, in which 802.1X authentication must complete and authorize network access, in Max delay for connectivity (seconds), enter a value, depending on your needs.

    5. To allow dialogs during Single Sing On, select Allow additional dialogs to be displayed during Single Sign On.

    6. To specify that wireless computers are placed on one virtual local area network (VLAN) at startup, and then transitioned to a different network after the user logs on to the computer, select This network uses different VLAN for authentication with machine and user credentials.

    7. To enable Fast Roaming, in Fast Roaming, select Enable Pairwise Master Key (PMK) Caching. The default values for PMK Time to Live (minutes) and Number of entries in PMK Cache are typically sufficient for Fast Roaming.

    8. Select This network uses pre-authentication, if your wireless AP is configured for pre-authentication. The default value of 3 is typically sufficient for Maximum Pre-authentication attempts.

    9. To specify that cryptography adheres to the FIPS 140-2 certified mode, select Perform cryptography in FIPS 140-2 certified mode.

  18. Click Properties. In the Smart Card or other Certificate Properties dialog box, in When connecting, select either Use my smart card or select both Use a certificate on this computer and Use simple certificate selection (Recommended).

  19. To require that access clients validate the Network Policy Server (NPS) server certificate, select Validate server certificate.

  20. To specify which Remote Authentication Dial-In User Service (RADIUS) servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server certificate. Use semicolons to specify multiple RADIUS server names.

  21. In Trusted Root Certification Authorities, select the CA that issued certificates to your servers running NPS.

  22. To specify that clients use an alternate name for the access attempt, select Use a different user name for the connection.

  23. For improved security and a better user experience, select Do not prompt user to authorize new servers or trusted certification authorities.

  24. Click OK to close the Smart card or other Certificate Properties dialog box, and return to the New Wireless Network Policy Properties dialog box.


Configure Network Permissions and Connection Preferences

You can use this procedure to specify the following:

  • To configure the preferred order in which wireless computers running Windows® 7 and Windows Vista try to connect to wireless networks.

  • To specify by name wireless networks to which wireless computers running Windows 7 and Windows Vista allowed or denied connections.

  • To specify whether users with computers running Windows 7 or Windows Vista can view wireless networks that are enumerated in the deny list.

  • To configure Windows 7 specific wireless settings for Hosted Network and Explicit Credentials.

Membership in Domain Admins, or equivalent, is the minimum requirement to complete these procedures.

To configure network permissions

  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, and then click the up arrow or the down arrow to move the profile to the location you want in the list.

  2. Open the Windows Vista Wireless Policy.

  3. On the Network Permissions tab, click Add. The New Permissions Entry dialog box opens.

  4. On the New Permission Entry dialog box, configure the following:

    1. In Network Name (SSID), type the service set identifier (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 either Allow or Deny, and then click OK. The New Permissions Entry dialog box closes, returning you to the Network Permissions tab.

  5. On the Network Permissions tab, to allow or prevent wireless clients from connecting to ad-hoc networks, either clear or select Prevent connections to ad-hoc networks.

  6. To allow or prevent wireless clients from connecting to infrastructure networks, either clear or select Prevent connections to infrastructure networks.

  7. To enable or prevent wireless networks from displaying in the Connect to a network dialog box, either select or clear Allow user to view denied networks.

  8. To allow users to create wireless profiles, select Allow everyone to create all user profiles.

  9. To specify that only wireless profiles that are created by using Group Policy Management can be used to connect to allowed networks, select Only use Group Policy profiles for allowed networks.

  10. To block users from hosting a wireless network on computers running Windows 7 that are equipped with wireless network adapters support the Soft Access Point and Virtual Wi-Fi capability, select Disallow Hosted Network.

  11. To permit users with computers running Windows 7 to enter and store their domain credentials (username and password), which the computer can then use to log on to the network (even though the user is not actively logged on), in Windows 7 Policy Settings, select Enable Explicit Credentials.

  12. To specify the duration for which computers running Windows 7 are prohibited from making auto connection attempts to the network, select Enable Block Period, and in Block Period (minutes), specify the number of minutes for which you want the block period to apply. The valid range of minutes is 1-60.

    Note

    For more information about the settings on any tab, press F1 while viewing that tab.

  13. Click OK to save the settings, and close the Network Permissions tab.


Configure 802.1X Wireless Access Clients running Windows XP

The procedures in this section provide the steps to use the New Windows XP Wireless Network Policy to configure wireless profiles that wireless clients running Windows XP will use to connect to your wireless network.

Similar to the New Wireless Network Policy for computers running Windows Vista, you can use the New XP Wireless Network Policy to 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 service set identifier (SSID).

Membership in Domain Admins, or equivalent, is the minimum required to complete these procedures.

  • Configure Wireless Clients running Windows XP for PEAP-MS-CHAP v2 Authentication

  • Configure Wireless Clients running Windows XP for PEAP-TLS Authentication

  • Configure Wireless Clients running Windows XP for EAP-TLS Authentication


Configure Wireless Clients running Windows XP for PEAP-MS-CHAP v2 Authentication

Use this procedure to configure a Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) wireless configuration profile for wireless computers running Windows XP and Windows Server 2003.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure a PEAP-MS-CHAP v2 wireless profile for computers running Windows XP

  1. Open Windows XP Wireless Network (IEEE 802.11) Policies Properties dialog box.

    On the General tab, do the following:

    1. In XP Policy Name, type a name for your wireless policy.

    2. In Description, type a description of the policy.

    3. In Networks to access, select either Any available network (access point preferred) or Access point (infrastructure) networks only.

    4. Select Use Windows WLAN AutoConfig service 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 service set identifier (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. If you deployed wireless access points that are configured to suppress the broadcast beacon, select Connect even if the network is not broadcasting.

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

    4. In Select the security methods for this network, in Authentication, select either WPA2 (preferred), or WPA. In Encryption, specify either AES or TKIP.

      Note

      In 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. WPA-PSK and WPA2-PSK are for networks that do not use 802.1X authentication. Do not use them for 802.1X authenticated wireless access deployments.

      Note

      Selecting WPA2 exposes settings for Fast Roaming that are not displayed if WPA is selected. The default settings for Fast Roaming are sufficient for most wireless deployments.

  3. Click the IEEE 802.1X tab. In EAP type, by default, Protected EAP (PEAP) is selected.

    The remaining default settings on the IEEE 802.1X tab are sufficient for most wireless deployments.

  4. Click Settings. In the Protected EAP Properties dialog box, do the following:

    1. Select Validate server certificate.

    2. To specify which Remote Authentication Dial-In User Service (RADIUS) servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server certificate. Use semicolons to specify multiple RADIUS server names.

    3. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your server running 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 trust all trusted root CAs in their trusted root certification authority store.

    4. For improved security and a better user experience, select Do not prompt user to authorize new servers or trusted certification authorities.

    5. In Select Authentication Method, select Secured Password (EAP-MSCHAP v2).

    6. To enable PEAP Fast Reconnect, select Enable Fast Reconnect.

    7. To specify that Network Access Protection (NAP) performs system health checks on clients to ensure they meet health requirements, before connections to the network are permitted, select Enforce Network Access Protection.

    8. To require cryptobinding Type-Length-Value (TLV), select Disconnect if server does not present cryptobinding TLV.

    9. To configure your clients so that they will not send their identity in plaintext before the client has authenticated the RADIUS server, select Enable Identity Privacy, and then in Anonymous Identity, type a name or value, or leave the field empty.

      For example, if Enable Identity Privacy is enabled and you use “guest” as the anonymous identity value, the identity response for a user with identity alice@realm is guest@realm. If you select Enable Identity Privacy but do not provide an anonymous identity value, the identity response is @realm.

  5. Click OK to save the Protected EAP Properties settings, and then click OK again to save the policy.


Configure Wireless Clients running Windows XP for PEAP-TLS Authentication

Use this procedure to configure a Protected Extensible Authentication Protocol-Transport Layer Security (PEAP-TLS) wireless profile for wireless computers running Windows XP and Windows Server 2003.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure a PEAP-TLS wireless profile for computers running Windows XP

  1. Open New XP Wireless Network (IEEE 802.11) Policies Properties dialog box.

    On the General tab, do the following:

    1. In XP Policy Name, type a name for your wireless policy.

    2. In Description, type a description of the policy.

    3. In Networks to access, select either Access point (infrastructure) networks only or Any available network (access point preferred).

    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 service set identifier (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. In Select the security methods for this network, in Authentication, select either WPA2 (preferred), or WPA. In Encryption, specify either AES or TKIP.

      Note

      In 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, by default, Protected EAP (PEAP) is selected.

    The remaining default settings on the IEEE 802.1X tab are sufficient for most wireless deployments.

  4. Click Settings. In the Protected EAP Properties dialog box, do the following:

    1. Select Validate server certificate.

    2. To specify which Remote Authentication Dial-In User Service (RADIUS) servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server certificate. Use semicolons to specify multiple RADIUS server names.

    3. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your server running 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.

    4. For improved security and a better user experience, select Do not prompt user to authorize new servers or trusted certification authorities.

    5. In Select Authentication Method, select Smart Card or other certificate.

    6. To enable PEAP fast reconnect, select Enable Fast Reconnect.

    7. To specify that Network Access Protection (NAP) performs system health checks on clients to ensure they meet health requirements, before connections to the network are permitted, select Enforce Network Access Protection.

    8. To require cryptobinding Type-Length Value (TLV), select Disconnect if server does not present cryptobinding TLV.

    9. To configure your clients so that they will not send their identity in plaintext before the client has authenticated the RADIUS server, select Enable Identity Privacy, and then in Anonymous Identity, type a name or value, or leave the field empty.

      For example, if Enable Identity Privacy is enabled and you use “guest” as the anonymous identity value, the identity response for a user with identity alice@realm is guest@realm. If you select Enable Identity Privacy but do not provide an anonymous identity value, the identity response is @realm.

    10. To configure PEAP-TLS properties, click Configure, and then in Smart Card or other Certificate Properties, configure the following items according to your needs:

      • In When connecting, select either Use my smart card, or select both Use a certificate on this computer and Use simple certificate selection (Recommended).

      • To require that access clients validate the NPS server certificate, select Validate server certificate.

      • To specify which RADIUS servers your wired access clients must use for authentication and authorization, in Connect to these servers, type then name of each RADIUS server, exactly as it appears in the subject field of the server’s certificate. Use semicolons to specify multiple RADIUUS server names.

      • In Trusted Root Certification Authorities, select the CA that issued NPS server certificates on your network.

      • To specify that clients use an alternate name for the access attempt, select Use a different user name for the connection.

      • To prevent users from being prompted to trust a server certificate if that certificate is incorrectly configured, is not already trusted, or both, select Do not prompt user to authorize new servers or trusted certification authorities. (Recommended)

      • Click OK to close the Smart card or other Certificate Properties dialog box, and then click OK again to close the Protected EAP (PEAP) Properties dialog box, returning you to the New Vista Wired Network Policy Properties dialog box.


Configure Wireless Clients running Windows XP for EAP-TLS Authentication

Use this procedure to configure an Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) 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.

To configure an EAP-TLS wireless profile for computers running Windows XP

  1. Open the Windows XP Wireless Network (IEEE 802.11) Policies Properties dialog box.

    On the General tab, do the following:

    1. In XP Policy Name, type a name for your wireless policy.

    2. In Description, type a description of the policy.

    3. In Networks to access, select either Any available network (access point 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 service set identifier (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. In Select the security methods for this network, in Authentication, select either WPA2 (preferred), or WPA. In Encryption, specify either AES or TKIP.

      Note

      In 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 Smart Card or other Certificate.

    The remaining default settings on the IEEE 802.1X tab are typically sufficient for wireless deployments.

  4. Click Settings. In the Smart Card or other Certificate Properties dialog box, do the following:

    1. In When connecting, select either Use my smart card, or select both Use a certificate on this computer and Use simple certificate selection (Recommended).

    2. Verify that Validate Server certificate is selected.

    3. In Trusted Root Certification Authorities, select the trusted root certification authority (CA) that issued the server certificate to your server running 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 trust all trusted root CAs in their trusted root certification authority store.

    4. To specify that clients use an alternate name for the access attempt, select Use a different user name for the connection.

    5. For improved security and a better user experience, select Do not prompt user to authorize new servers or trusted certification authorities.

  5. Click OK two times. The EAP-TLS profile is listed under Networks. Click OK, and then close the Group Policy Management Console.


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®, Windows Server® 2008, Windows® 7, and Windows Server® 2008 R2. By using 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. By using the NAP API set, you can add components to NAP clients and to servers running Network Policy Server (NPS) that check computer 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 computer 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 and Windows 7 as part of the operating system. The corresponding Windows Security Health Validator (WSHV) is included in Windows Server 2008 and Windows Server 2008 R2 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 deployed by customers of the software vendor.

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 by 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 can 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 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 the configuration state of a client computer 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 health status of the client computer is encapsulated in an 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.

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 by using 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-side 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

By using 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 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.

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.


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 Network Access Protection (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 system health agent (SHA) pairs for their NAP-compatible products.

If you want to use a NAP-compatible product, you can follow the documentation for that product about how to install the SHA on NAP-capable client computers, and then install the SHV on the server running NPS. 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.


Remediation Server Groups

A remediation server group is a list of servers on the restricted network that provide resources required to bring noncompliant Network Access Protection (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.


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 Network Access Protection (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 server running NPS, 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, the 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.


System Health Validator Settings

System health validator (SHV) settings allow you to configure the system health requirements for Network Access Protection (NAP) client computers. If an SHV is designed to work with a health requirement server, you might configure some or all SHV settings on this server. To configure SHV settings on Network Policy Server (NPS), click Configure in the SHV properties window to open the SHV configuration dialog box.

If an SHV supports the storing of multiple configurations, you can create additional SHV settings for use with your health policies.

Additional references

  • System Health Validator Error Codes


System Health Validator Error Codes

System health validator (SHV) error codes can be returned for an SHV when the associated system health agent (SHA) on a Network Access Protection (NAP) client computer requests access to the network. If an error code is returned, you can choose whether to evaluate the NAP client computer as compliant or noncompliant with health requirements. By default, all error codes are set to noncompliant.

The following is a description of available error codes:

  • SHV unable to contact required services. This error can occur if Network Policy Server (NPS) loses connectivity to a health requirement server, such as an antivirus signature server.

  • SHA unable to contact required services. This error can occur if the SHA is unable to successfully read the client configuration.

  • SHA not responding to NAP Client. This error can occur if an SHA is not properly initialized and registered.

  • SHV not responding. This error can occur if the performance of an SHV is degraded (for example, if NPS is out of memory).

  • Vendor specific error code received. This error can occur if NPS receives an error code that is unique to the SHA or SHV vendor. Some vendors might return this code when NPS is unable to contact a health requirement server.

Additional references

  • System Health Validator Settings


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 then 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 performs no checks, and 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, 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 then 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 that are not configured in Windows Firewall can cause a loss of functionality on the client computer. 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, 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 performs no checks, and 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 performs no checks, and 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 performs no checks, and 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 performs no checks, and 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, 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 then 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 by using the NAP Client Management Microsoft Management Console (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 by 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

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, WSHA restricts client computers to a remediation network, and the clients 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 a client computer does not have these updates, it 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 a client computer does not have these updates, it 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, or Critical. If a client computer does not have these updates, it 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, or Critical. If a client computer does not have these updates, it 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 a client computer does not have the most recent updates, it 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 at the 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 Enforcement Methods

Network Policy Server (NPS) enforces Network Access Protection (NAP) health policies for the following network technologies:

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

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

  • Remote Desktop Gateway connections by using Remote Desktop Services, which in previous product versions was named Terminal Services. For more information, see NAP Enforcement for Remote Desktop 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.


NAP Enforcement for 802.1X

Network Access Protection (NAP) enforcement for 802.1X port-based network access control is deployed by using a server running Network Policy Server (NPS) and an Extensible Authentication Protocol (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 network access by the client 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 by using 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 by 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 Protected Extensible Authentication Protocol-Transport Layer Security (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 Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (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 by 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.


NAP Enforcement for DHCP

Dynamic Host Configuration Protocol (DHCP) enforcement is deployed with a DHCP Network Access Protection (NAP) enforcement server component, a DHCP enforcement client component, and Network Policy Server (NPS). By using DHCP NAP 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 by 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 Microsoft Management Console (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.


NAP Enforcement for IPsec Communications

Network Access Protection (NAP) enforcement for Internet Protocol security (IPsec) policies for Windows Firewall is deployed by using a health certificate server, a Health Registration Authority (HRA) server, a server running Network Policy Server (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 by 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 Remote Authentication Dial-In User Service (RADIUS) proxy to forward connection requests to the local NPS server.

For more information about HRA, open the HRA console, and then press F1 to access the HRA Help content.


NAP Enforcement for Remote Desktop Gateway

Remote Desktop Gateway (RD Gateway) is a role service of the Remote Desktop Services server role that is available in Windows Server® 2008 R2.

Note

In Windows Server 2008 R2, Remote Desktop Services replaces Terminal Services in Windows Server® 2008.

By using RD 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 Remote Desktop clients can be enforced and monitored with Network Access Protection (NAP).

NAP enforcement for RD Gateway is deployed with a server running Network Policy Server (NPS) and a RD Gateway server.

Requirements

To deploy NAP with RD Gateway, you must configure the following:

  • Install and configure RD Gateway. When you run the Add Roles Wizard to install the RD Gateway role service, you must select Remote Desktop. Later, on the Select Role Services page, you can select the RD Gateway role service for installation.

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually by 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 Protected Extensible Authentication Protocol-Transport Layer Security (PEAP-TLS) or Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) with smart cards or certificates, deploy a public key infrastructure (PKI) with Active Directory® Certificate Services (AD CS).

  • If you are using Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (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 RD Gateway server using the RD Gateway Manager snap-in.

  • Enable the NAP RD Gateway enforcement client, the EAP enforcement client, and the NAP service on NAP-capable client computers.


NAP Enforcement for VPN

Network Access Protection (NAP) enforcement for virtual private networking (VPN) is deployed by using a VPN enforcement server component and a VPN enforcement client component. By using this enforcement method, VPN servers can enforce health policy when client computers attempt to connect to the network by using a VPN connection. VPN enforcement provides strong limited network access for all computers accessing the network by using 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 the Routing and Remote Access service as a VPN server. Configure your server running Network Policy Server (NPS) as the primary Remote Authentication Dial-In User Service (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 by 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 Protected Extensible Authentication Protocol-Transport Layer Security (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 Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (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.


RADIUS

This section contains the following topics:

  • RADIUS Accounting

  • RADIUS Clients and Servers

  • RADIUS Proxy

  • RADIUS Server


RADIUS Accounting

There are three types of logging for Network Policy Server (NPS):

  • Event logging.

    Used primarily for auditing and troubleshooting connection attempts. You can configure NPS event logging by obtaining the NPS server properties in the NPS console.

  • Logging user authentication and accounting requests to a local file.

    Used primarily for connection analysis and billing purposes. Also useful as a security investigation tool because it provides you with a method of tracking the activity of a malicious user after an attack. You can configure local file logging using the Accounting Configuration wizard.

  • Logging user authentication and accounting requests to a Microsoft® SQL Server™ XML-compliant database.

    Used to allow multiple servers running NPS to have one data source. Also provides the advantages of using a relational database. You can configure SQL Server logging by using the Accounting Configuration wizard.

Accounting Configuration wizard

By using the Accounting Configuration wizard in the NPS console, you can configure the following four accounting settings:

  • SQL logging only. By using this setting, you can configure a data link to a SQL Server that allows NPS to connect to and send accounting data to the SQL server. In addition, the wizard can configure the database on the SQL Server to ensure that the database is compatible with NPS SQL server logging.

  • Text logging only. By using this setting, you can configure NPS to log accounting data to a text file.

  • Parallel logging. By using this setting, you can configure the SQL Server data link and database. You can also configure text file logging so that NPS logs simultaneously to the text file and the SQL Server database.

  • SQL logging with backup. By using this setting, you can configure the SQL Server data link and database. In addition, you can configure text file logging that NPS uses if SQL Server logging fails.

In addition to these settings, both SQL Server logging and text logging allow you to specify whether NPS continues to process connection requests if logging fails. You can specify this Failover setting in local file logging properties, in SQL Server logging properties, and while you are running the Accounting Configuration wizard.

See Also

  • Configure Log File Properties
  • Configure SQL Server Logging in NPS


Configure Log File Properties

You can configure Network Policy Server (NPS) to perform Remote Authentication Dial-In User Service (RADIUS) accounting for user authentication requests, Access-Accept messages, Access-Reject messages, accounting requests and responses, and periodic status updates. You can use this procedure to configure the log files in which you want to store the accounting data.

To prevent the log files from filling the hard drive, it is strongly recommended that you keep them on a partition that is separate from the system partition. The following provides more information about configuring accounting for NPS:

  • To send the log file data for collection by another process, you can configure NPS to write to a named pipe. To use named pipes, set the log file folder to \\.\pipe or \\ComputerName\pipe. The named pipe server program creates a named pipe called \\.\pipe\iaslog.log to accept the data. In the Local file properties dialog box, in Create a new log file, select Never (unlimited file size) when you use named pipes.

  • The log file directory can be created by using system environment variables (instead of user variables), such as %systemdrive%, %systemroot%, and %windir%. For example, the following path, using the environment variable %windir%, locates the log file at the system directory in the subfolder \System32\Logs (that is, %windir%\System32\Logs\).

  • Switching log file formats does not cause a new log to be created. If you change log file formats, the file that is active at the time of the change will contain a mixture of the two formats (records at the start of the log will have the previous format, and records at the end of the log will have the new format).

  • If RADIUS accounting fails due to a full hard disk drive or other causes, NPS stops processing connection requests, preventing users from accessing network resources.

  • NPS provides the ability to log to a Microsoft® SQL Server™ database in addition to, or instead of, logging to a local file.

Membership in the Domain Admins group is the minimum required to perform this procedure.

To configure NPS log file properties

  1. Open the NPS console or the NPS Microsoft Management Console (MMC) snap-in.

  2. In the console tree, click Accounting.

  3. In the details pane, in Log File Properties, click Change Log File Properties. The Log File Properties dialog box opens.

  4. In Log File Properties, on the Settings tab, in Log the following information, ensure that you choose to log enough information to achieve your accounting goals. For example, if your logs need to accomplish session correlation, select all check boxes.

  5. In Logging failure action, select If logging fails, discard connection requests if you want NPS to stop processing Access-Request messages when log files are full or unavailable for some reason. If you want NPS to continue processing connection requests if logging fails, do not select this check box.

  6. In the Log File Properties dialog box, click the Log File tab.

  7. On the Log File tab, in Directory, type the location where you want to store NPS log files. The default location is the systemroot\System32\LogFiles folder.

    Note

    If you do not supply a full path statement in Log File Directory, the default path is used. For example, if you type NPSLogFile in Log File Directory, the file is located at %systemroot%\System32\NPSLogFile.

  8. In Format, click DTS Compliant. If you prefer, you can instead select a legacy file format, such as ODBC (Legacy) or IAS (Legacy).

  9. In Create a new log file, to configure NPS to start new log files at specified intervals, click the interval that you want to use:

    • For heavy transaction volume and logging activity, click Daily.

    • For lesser transaction volumes and logging activity, click Weekly or Monthly.

    • To store all transactions in one log file, click Never (unlimited file size).

    • To limit the size of each log file, click When log file reaches this size, and then type a file size, after which a new log is created. The default size is 10 megabytes (MB).

  10. If you want NPS to delete old log files to create disk space for new log files when the hard disk is near capacity, ensure that When disk is full delete older log files is selected. This option is not available, however, if the value of Create a new log file is Never (unlimited file size). Also, if the oldest log file is the current log file, it is not deleted.


Configure SQL Server Logging in NPS

Use this procedure to log Remote Authentication Dial-In User Service (RADIUS) accounting data to a local or remote database running Microsoft® SQL Server™.

You can configure Network Policy Server (NPS) to perform RADIUS accounting for user authentication requests, Access-Accept messages, Access-Reject messages, accounting requests and responses, and periodic status updates. You can use this procedure to configure logging properties and the connection to the server running SQL Server that stores your accounting data.

Note

NPS formats accounting data as an XML document that it sends to the report_event stored procedure in the SQL Server database that you designate in NPS. For SQL Server logging to function properly, you must have a stored procedure named report_event in the SQL Server database that can receive and parse the XML documents from NPS.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To configure SQL Server logging in NPS

  1. Open the NPS console or the NPS Microsoft Management Console (MMC) snap-in.

  2. In the console tree, click Accounting.

  3. In the details pane, in SQL Server Logging Properties, click Change SQL Server Logging Properties. The SQL Server Logging Properties dialog box opens.

  4. In Log the following information, select the information that you want to log:

    1. To log all accounting requests, click Accounting requests.

    2. To log authentication requests, click Authentication requests.

    3. To log periodic accounting status, click Periodic accounting status.

    4. To log periodic status, such as interim accounting requests, click Periodic status.

  5. To configure the number of concurrent sessions allowed between the server running NPS and the SQL Server, type a number in Maximum number of concurrent sessions.

  6. To configure the SQL Server data source, in SQL Server Logging, click Configure. The Data Link Properties dialog box opens. On the Connection tab, specify the following:

    • To specify the name of the server on which the database is stored, type or select a name in Select or enter a server name.

    • To specify the authentication method with which to log on to the server, click Use Windows NT integrated security. Or, click Use a specific user name and password, and then type credentials in User name and Password.

    • To allow a blank password, click Blank password.

    • To store the password, click Allow saving password.

    • To specify which database to connect to on the computer running SQL Server, click Select the database on the server, and then select a database name from the list.

  7. To test the connection between NPS and SQL Server, click Test Connection.


RADIUS Clients and Servers

In the NPS console, if you click RADIUS Clients and Servers, you can then choose to configure either RADIUS clients or Remote RADIUS Server Groups.

For more information about RADIUS clients, see RADIUS Client.

For more information about remote RADIUS server groups, see Remote RADIUS Server Groups.

For information about configuring NPS as a RADIUS server, see RADIUS Server.


RADIUS Client

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 portable 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-capable 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 New RADIUS Client

Use this procedure to add a network access server as a Remote Authentication Dial-In User Service (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 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 portable 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-capable 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 the documentation of your NAS manufacturer.

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 NAS 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 NAS does not support the Message-Authenticator attribute, do not select this setting. Enabling the use of the Message-Authenticator attribute provides additional security when Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and MS-CHAP v2 are configured in network policies as authentication methods. Extensible Authentication Protocol (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

  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.


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-up, VPN, or wireless network access services to multiple customers. Your NASs 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.

  • 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 NASs in another domain or forest.

  • 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 an 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. By 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.


Connection Request Processing

You can use connection request processing to specify where the authentication of connection requests is performed - on the local computer or at a remote RADIUS server that is a member of a remote RADIUS server group.

If you want the local server running Network Policy Server (NPS) to perform authentication for connection requests, you can use the default connection request policy without additional configuration. Based on the default policy, NPS authenticates users and computers that have an account in the local domain and in trusted domains.

If you want to forward connection requests to a remote NPS or other RADIUS server, create a remote RADIUS server group and then configure a connection request policy that forwards requests to that remote RADIUS server group. With this configuration, NPS can forward authentication requests to any RADIUS server, and users with accounts in untrusted domains can be authenticated.

The following illustration shows the path of an Access-Request message from a network access server to a RADIUS proxy, and then on to a RADIUS server in a remote RADIUS server group. On the RADIUS proxy, the network access server is configured as a RADIUS client; and on each RADIUS server, the RADIUS proxy is configured as a RADIUS client.

RADIUS clients and servers
Note

The network access servers that you use with NPS can be gateway devices that are compliant with the RADIUS protocol, such as 802.1X wireless access points and authenticating switches, servers running Routing and Remote Access that are configured as VPN or dial-up servers, Remote Desktop Gateway (RD°Gateway) servers, and other devices.

If you want NPS to process some authentication requests locally while forwarding other requests to a remote RADIUS server group, configure more than one connection request policy.

To configure a connection request policy that specifies which NPS or RADIUS server group processes authentication requests, see Connection Request Policies.

To specify NPS or other RADIUS servers to which authentication requests are forwarded, see Remote RADIUS Server Groups.


Connection Request Policies

Connection request policies are sets of conditions and settings that allow network administrators to designate which Remote Authentication Dial-In User Service (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) by using the virtual private network (VPN) or 802.1X enforcement methods with Protected Extensible Authentication Protocol (PEAP) authentication, you must configure PEAP authentication in the 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 such as 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 domain 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 Point-to-Point Protocol (PPP), Serial Line Internet Protocol (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), Integrated Services Digital Network (ISDN), tunnels or virtual private networks (VPNs), IEEE 802.11 wireless, and Ethernet switches.

The Machine Identity attribute group contains the Machine Identity attribute. By using 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. By using 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

By using 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 Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (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 by using PEAP-MS-CHAP v2. In this example, all clients connecting to your network are granted unauthenticated access.

Accounting

By using this setting, you can configure connection request policy to forward accounting information to an 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. By using 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. By using 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. By using 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 user credentials are authenticated.

Note

This authentication option cannot be used when the authentication protocol of the access client is MS-CHAP v2 or Extensible Authentication Protocol-Transport Layer Security (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 own partner organization RADIUS server, and then 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 by using 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.


Add a Connection Request Policy

Connection request policies are sets of conditions and settings that allow network administrators to designate which Remote Authentication Dial-In User Service (RADIUS) servers perform the authentication and authorization of connection requests that the server running Network Policy Server (NPS) receives from RADIUS clients.

The default connection request policy uses NPS as a RADIUS server and processes all authentication requests locally.

To configure a server running NPS to act as a RADIUS proxy and forward connection requests to other NPS or RADIUS servers, you must configure a remote RADIUS server group in addition to adding a new connection request policy that specifies conditions and settings that the connection requests must match.

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.

If you do not want the NPS server to act as a RADIUS server and process connection requests locally, you can delete the default connection request policy.

If you want the NPS server to act as both a RADIUS server, processing connection requests locally, and as a RADIUS proxy, forwarding some connection requests to a remote RADIUS server group, add a new policy using the following procedure and then verify that the default connection request policy is the last policy processed.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To add a new connection request policy

  1. Open the NPS console, and then double-click Policies.

  2. In the console tree, right-click Connection Request Policies, and then click New Connection Request Policy.

  3. Use the New Connection Request Policy Wizard to configure your connection request policy and, if not previously configured, a remote RADIUS server group.


Remote RADIUS Server Groups

When you configure Network Policy Server (NPS) as a Remote Authentication Dial-In User Service (RADIUS) proxy, you use NPS to forward connection requests to RADIUS servers that are capable of processing the connection requests because they can perform authentication and authorization in the domain where the user or computer account is located. For example, if you want to forward connection requests to one or more RADIUS servers in untrusted domains, you can configure NPS as a RADIUS proxy to forward the requests to the remote RADIUS servers in the untrusted domain.

To configure NPS as a RADIUS proxy, you must create a connection request policy that contains all of the information required for NPS to evaluate which messages to forward and where to send the messages.

When you configure a remote RADIUS server group in NPS and you configure a connection request policy with the group, you are designating the location where NPS is to forward connection requests.

Configuring RADIUS servers for a group

A remote RADIUS server group is a named group that contains one or more RADIUS servers. If you configure more than one server, you can specify load balancing settings to either determine the order in which the servers are used by the proxy or to distribute the flow of RADIUS messages across all servers in the group to prevent overloading one or more servers with too many connection requests.

Each server in the group has the following settings:

  • Name or address

    Each group member must have a unique name within the group. The name can be an IP address or a name that can be resolved to its IP address.

  • Authentication and accounting

    You can forward authentication requests, accounting requests, or both to each remote RADIUS server group member.

  • Load balancing

    A priority setting is used to indicate which member of the group is the primary server (the priority is set to 1). For group members that have the same priority, a weight setting is used to calculate how often RADIUS messages are sent to each server. You can use additional settings to configure the way in which the NPS server detects when a group member first becomes unavailable and when it becomes available after it has been determined to be unavailable.

After a remote RADIUS server group is configured, it can be specified in the authentication and accounting settings of a connection request policy. Because of this, you can configure a remote RADIUS server group first. Next, you can configure the connection request policy to use the newly configured remote RADIUS server group. Alternatively, you can use the New Connection Request Policy Wizard to create a new remote RADIUS server group while you are creating the connection request policy.

Note

Remote RADIUS server groups are unrelated to and separate from Windows groups and Network Access Protection (NAP) remediation server groups.


Add a Remote RADIUS Server Group

You can use this procedure to add a new remote RADIUS server group in the Network Policy Server (NPS) snap-in.

When you configure NPS as a RADIUS proxy, you create a new connection request policy that NPS uses to determine which connection requests to forward to other RADIUS servers. In addition, the connection request policy is configured by specifying a remote RADIUS server group that contains one or more RADIUS servers, which tells NPS where to send the connection requests that match the connection request policy.

Note

You can also configure a new remote RADIUS server group during the process of creating a new connection request policy.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To add a remote RADIUS server group

  1. Open the NPS console.

  2. In the console tree, double-click RADIUS Clients and Servers, right-click Remote RADIUS Server Groups, and then click New.

  3. The New Remote RADIUS Server Group dialog box opens. In Group name, type a name for the remote RADIUS server group.

  4. In RADIUS Servers, click Add. The Add RADIUS Servers dialog box opens. Type the IP address of the RADIUS server that you want to add to the group, or type the Fully Qualified Domain Name (FQDN) of the RADIUS server, and then click Verify.

  5. In Add RADIUS Servers, click the Authentication/Accounting tab. In Shared secret and Confirm shared secret, type the shared secret. You must use the same shared secret when you configure the local computer as a RADIUS client on the remote RADIUS server.

  6. If you are not using Extensible Authentication Protocol (EAP) for authentication, click Request must contain the message authenticator attribute. EAP uses the Message-Authenticator attribute by default.

  7. Verify that the authentication and accounting port numbers are correct for your deployment.

  8. If you use a different shared secret for accounting, in Accounting, clear the Use the same shared secret for authentication and accounting check box, and then type the accounting shared secret in Shared secret and Confirm shared secret.

  9. If you do not want to forward network access server start and stop messages to the remote RADIUS server, clear the Forward network access server start and stop notifications to this server check box.


RADIUS Server

Network Policy Server (NPS) can be used as a Remote Authentication Dial-In User Service (RADIUS) server to perform authentication, authorization, and accounting for RADIUS clients. A RADIUS client can be an access server, such as a dial-up server or wireless access point, 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 Services (AD DS) 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 a 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 AD DS 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 AD DS 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.


RADIUS Server for 802.1X Wireless or Wired Connections

When you deploy 802.1X wired or wireless access with Network Policy Server (NPS) as a Remote Authentication Dial-In User Service (RADIUS) server, you must take the following steps:

  • Install and configure network access servers (NASs) as RADIUS clients.

  • Deploy components for authentication methods.

  • Configure NPS as a RADIUS server.

Install and configure network access servers (RADIUS clients)

To deploy 802.1X wireless access, you must install and configure wireless access points. To deploy 802.1X wired access, you must install and configure 802.1X authenticating switches.

Important

Client computers, such as wireless portable 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-capable 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 both cases, these network access servers must meet the following requirements:

  • Support for Institute of Electrical and Electronics Engineers (IEEE) standard 802.1X authentication

  • Support for RADIUS authentication and RADIUS accounting

If you use billing or accounting applications that require session correlation, the following are required:

  • Support for the Class attribute as defined by the Internet Engineering Task Force (IETF) in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," to allow session correlation for RADIUS authentication and accounting records. For session correlation, when you configure RADIUS accounting at your NPS server or proxy, you must log all accounting data that allow applications (such as billing applications) to query the database, correlate related fields, and return a cohesive view of each session in the query results. At a minimum, to provide session correlation, you must log the following NPS accounting data: NAS-IP-Address; NAS-Identifier (you need both NAS-IP-Address and NAS-Identifier because the access server can send either attribute); Class; Acct-Session-Id; Acct-Multi-Session-Id; Packet-Type; Acct-Status-Type; Acct-Interim-Interval; NAS-Port; and Event-Timestamp.

  • Support for accounting interim requests, which are sent periodically by some network access servers (NASs) during a user session, that can be logged. This type of request can be used when the Acct-Interim-Interval RADIUS attribute is configured to support periodic requests in the remote access profile on the NPS server. The NAS must support the use of accounting interim requests if you want the interim requests to be logged on the NPS server.

If you use virtual local area networks (VLANs), the NASs must support VLANs.

For wide area network (WAN) environments, network access servers should provide the following:

  • Support for dynamic retransmit timeout (RTO) estimation or exponential backoff to handle congestion and delays in a WAN environment.

In addition, there are filtering features that the network access servers should support to provide enhanced security for the network. These filtering options include:

  • DHCP filtering. The NASs must filter on IP ports to prevent the transmission of Dynamic Host Configuration Protocol (DHCP) broadcast messages if the client is a DHCP server. The network access servers must block the client from sending IP packets from port 68 to the network.

  • DNS filtering. The NASs must filter on IP ports to prevent a client from performing as a DNS server. The NASs must block the client from sending IP packets from port 53 to the network.

If you are deploying wireless access points, support for Wi-Fi Protected Access (WPA) is preferred. WPA is supported by Windows Vista® and Windows XP with Service Pack 2. To deploy WPA, also use wireless network adapters that support WPA.

Deploy components for authentication methods

For 802.1X wireless and wired, you can use the following authentication methods:

  • Extensible Authentication Protocol (EAP) with Transport Layer Security (TLS), also called EAP-TLS.

  • Protected EAP (PEAP) with Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), also called PEAP-MS-CHAP v2.

  • PEAP with EAP-TLS, also called PEAP-TLS.

For EAP-TLS and PEAP-TLS, you must deploy a public key infrastructure (PKI) by installing and configuring Active Directory® Certificate Services (AD CS) to issue certificates to domain member client computers and NPS servers. These certificates are used during the authentication process as proof of identity by both clients and NPS servers. If preferred, you can deploy smart cards rather than using client computer certificates. In this case, you must issue smart cards and smart card readers to organization employees.

For PEAP-MS-CHAP v2, you can deploy your own certification authority (CA) with AD CS to issue certificates to NPS servers or you can purchase server certificates from a public trusted root CA that clients trust, such as VeriSign.

For more information, see EAP Overview and PEAP Overview.

Configure NPS as a RADIUS server

When you configure NPS as a RADIUS server, you must configure RADIUS clients, network policy, and RADIUS accounting.

Configure RADIUS clients

There are two stages to configuring RADIUS clients:

  • Configure the physical RADIUS client, such as the wireless access point or authenticating switch, with information that allows the network access server to communicate with NPS servers. This information includes configuring the IP address of your NPS server and the shared secret in the access point or switch user interface.

  • In NPS, add a new RADIUS client. On the NPS server, add each access point or authenticating switch as a RADIUS client. NPS allows you to provide a friendly name for each RADIUS client, as well as the IP address of the RADIUS client and the shared secret.

For more information, see Add a New RADIUS Client.

Configure 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 connect.

For more information, see Network Policies.

Configure RADIUS accounting

RADIUS accounting allows you to record user authentication and accounting requests in a local log file or to a Microsoft® SQL Server® database on the local computer or a remote computer.

For more information, see RADIUS Accounting.

See Also

  • RADIUS Client
  • Network Policies
  • RADIUS Accounting


RADIUS Server for Dial-Up or VPN Connections

When you deploy dial-up or virtual private network (VPN) connections with Network Policy Server (NPS) as a RADIUS server, you must take the following steps:

  • Install and configure network access servers (NASs) as RADIUS clients.

  • Deploy components for authentication methods.

  • Configure NPS as a RADIUS server.

Install and configure network access servers (RADIUS clients)

To deploy dial-up access, you must install and configure Routing and Remote Access as a dial-up server. To deploy VPN access, you must install and configure Routing and Remote Access as a VPN server.

Important

Client computers, such as wireless portable 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-capable 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.

You can install Routing and Remote Access on the local NPS server or on a remote computer.

Deploy components for authentication methods

For VPN, you can use the following authentication methods:

  • Extensible Authentication Protocol (EAP) with Transport Layer Security (TLS), known as EAP-TLS.

  • Protected EAP (PEAP) with Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), known as PEAP-MS-CHAP v2.

  • PEAP with Transport Layer Security (TLS), known as PEAP-TLS.

For EAP-TLS and PEAP-TLS, you must deploy a public key infrastructure (PKI) by installing and configuring Active Directory® Certificate Services (AD CS) to issue certificates to domain member client computers and NPS servers. These certificates are used during the authentication process as proof of identity by both clients and NPS servers. If preferred, you can deploy smart cards rather than using client computer certificates. In this case, you must issue smart cards and smart card readers to organization employees.

For PEAP-MS-CHAP v2, you can deploy your own certification authority (CA) with AD CS to issue certificates to NPS servers or you can purchase server certificates from a public trusted root CA that clients trust, such as VeriSign.

For more information, see EAP Overview and PEAP Overview.

Configure NPS as a RADIUS server

When you configure NPS as a RADIUS server, you must configure RADIUS clients, network policy, and RADIUS accounting.

Configure RADIUS clients

There are two stages to configuring RADIUS clients:

  • Configure the physical RADIUS client, such as the VPN server or dial-up server, with information that allows the network access server to communicate with NPS servers. This information includes configuring your NPS server IP address and the shared secret in the user interface of the VPN server or dial-up server.

  • In NPS, add a new RADIUS client. On the NPS server, add each VPN server or dial-up server as a RADIUS client. NPS allows you to provide a friendly name for each RADIUS client, as well as the IP address of the RADIUS client and the shared secret.

For more information, see Add a New RADIUS Client.

Configure 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 connect.

For more information, see Network Policies.

Configure RADIUS accounting

RADIUS accounting allows you to record user authentication and accounting requests in a local log file or to a Microsoft® SQL Server® database on the local computer or on a remote computer.


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 Network Policy Server (NPS) performs client health checks during the authorization process.

When processing connection requests as a Remote Authentication Dial-In User Service (RADIUS) 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 (NAS), 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.

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

  • 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 denies the connection request without evaluating additional network policies.

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

When you add a new network policy by using the NPS snap-in, you must use the New Network Policy Wizard. After you have created a network policy by using the wizard, you can customize the policy by double-clicking the policy in the NPS snap-in to obtain the policy properties.


Access Permission

Access permission is configured on the Overview tab of each network policy in Network Policy Server (NPS). It 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 based on 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 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 a 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 (NAS), 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 can 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 select the Ignore user account dial-in properties check box, 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.


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.

To create a group for a network policy

  1. Open the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, and then click the domain where you want to create a group.

  2. Do one of the following:

    • 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 NPS console, and then 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.

  12. Click Add. The Windows Groups dialog box opens. Click Add Groups.

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

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


Configure Network Policies

The following topics demonstrate how to configure network policies in NPS.

  • Add 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


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 that are using any kind of network access server (NAS).

    • 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 Remote Desktop Gateway, NPS evaluates the network policy only for connection requests that originate from Remote Desktop Gateway (RD 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

  1. Open the NPS console, and then 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.


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 NPS console, 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


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 Remote Authentication Dial-In User Service (RADIUS) clients to the Network Policy Server (NPS) RADIUS server.

Important

Client computers, such as wireless portable 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-capable 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 open 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, 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.


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 Remote Authentication Dial-In User Service (RADIUS) clients to the Network Policy Server (NPS) RADIUS server.

Important

Client computers, such as wireless portable 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-capable 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 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, 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.


Host Credential Authorization Protocol

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.

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

Additional references

For more information, see Network Access Protection at http://go.microsoft.com/fwlink/?LinkID=56443 and http://go.microsoft.com/fwlink/?LinkId=128799.