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 RADIUS proxy to forward connection requests to 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 connection authentication, authorization, and accounting for wireless, authenticating switch, and 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.

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

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

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 NPS 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. 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 individually configure NPS features to configure NPS as a RADIUS server, NAP policy server, or RADIUS proxy. 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 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 Clients

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

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 Clients

  • Connection Request Processing

  • Remote RADIUS Server Groups

NPS logging

NPS logging is also called RADIUS accounting, and should be configured 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 the events logged and viewed with Event Viewer and determine 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 know to deploy RADIUS accounting.

  • RADIUS Accounting

  • NPS Events and Event Viewer

See Also

  • Network Policy Server Overview
  • NPS Best Practices
  • Checklists for NPS
  • General NPS Information
  • Network Access Protection in NPS
  • RADIUS Proxy
  • RADIUS Server


Network Policy Server Overview

Network Policy Server overview

Network Policy Server (NPS) allows you to centrally configure and manage network policies with the following three features: 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 a Remote Authentication Dial-In User Service (RADIUS) server. 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 an NPS server is a member of an Active Directory® 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 Active Directory 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 the user's credentials are authentic and the connection attempt is authorized, the RADIUS server authorizes the user's access on the basis of specified conditions and 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. NPS supports the Internet Engineering Task Force (IETF) standards for RADIUS described in RFCs 2865 and 2866.

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

Different NPS configurations can be created for the following solutions:

  • 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 different untrusted domains. 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, 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 RADIUS server with remote accounting servers. In this example, the local NPS server is not configured to perform accounting and the default connection request policy is revised so that RADIUS accounting messages are forwarded to an NPS or other RADIUS server in a remote RADIUS server group. Although accounting messages are forwarded, authentication and authorization messages are not forwarded, and the local NPS server performs these functions for the local and all trusted domains.

NPS with Remote RADIUS to Windows User mapping. In this example, NPS acts as both a RADIUS server and as a RADIUS proxy for each individual connection request by forwarding the authentication request to a remote RADIUS server while using a local Windows user account for authorization. This configuration is implemented by configuring the Remote RADIUS to Windows User Mapping attribute as a condition of the connection request policy. (In addition, a user account must be created locally that has the same name as the remote user account against which authentication is performed by the remote RADIUS server.)

NAP policy server

NAP is included in Windows Vista® and in Windows Server® 2008 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 administrator-defined health policy is monitored by NAP while the computer is connected to the network. 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 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 Best Practices

NPS best practices

This topic provides best practices for implementing and configuring NPS and is based on recommendations from Microsoft Product Support Services.

Installation suggestions

Before installing NPS, do the following:

  • Install and test each of your network access servers using local authentication methods before you make them RADIUS clients.

  • After you install and configure NPS, save the configuration by using the netsh nps show config > path\file.txt command. Save the NPS configuration with the netsh nps show config > path\file.txt command each time a change is made.

  • Do not install Windows Server® 2008, Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition on the same partition as Windows 2000. These operating systems use common files in the systemroot\Program Files folder to access the NPS database. If you decide to install Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition on the same partition as Windows 2000, NPS in Windows 2000 can no longer access remote access policies or remote access logging.

  • Do not configure a server running NPS or Routing and Remote Access as a member of a Windows NT Server 4.0 domain if your user accounts database is stored on a Windows Server 2008 or Windows Server 2003 domain controller in another domain. Doing this will cause Lightweight Directory Access Protocol (LDAP) queries from the NPS server to the domain controller to fail.

    Instead, configure your server running NPS or Routing and Remote Access as a member of a Windows Server 2008 or Windows Server 2003 domain. An alternative is to configure a server running NPS as a proxy server that forwards authentication and accounting requests to another server running NPS that can access the user accounts database on the domain controller.

Network Access Protection

Following are the best practices for NAP deployment with NPS.

  • For the most secure and effective NAP deployment on your network, deploy strong enforcement methods, such as the Internet Protocol security (IPsec), 802.1X, and virtual private network (VPN) enforcement methods. Strong enforcement methods use certificate-based authentication methods and secure the channel between clients and servers through which the statement of health (SoH) and statement of health response (SoHR) are sent. For more information, see NAP Enforcement Methods.

  • Before you create health policies for your NAP deployments, if you are using non-Microsoft products that support NAP, install non-Microsoft system health agents (SHAs) on client computers. In addition, install the SHAs' corresponding system health validators (SHVs) on NPS servers. For more information, see NAP Components.

  • When you deploy 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. For more information, see Connection Request Policies.

  • For a streamlined method of creating network policies, connection request policies, and health policies for your NAP deployment, use the New NAP Policies wizard. If you want to modify policies created using the wizard, open the policy in the NPS console and make required changes. For more information, see Create NAP Policies with a Wizard.

  • When you deploy NAP with the IPsec and DHCP enforcement methods, enable client health checks when you configure authentication. You should also configure the Identity Type condition in network policy with the value Computer health check. For more information, see Enable Client Health Checks for DHCP and IPsec NAP Deployments and Configure NAP Conditions in Network Policy.

Client computer configuration

Following are the best practices for client computer configuration.

  • Automatically configure all of your domain member 802.1X client computers using Group Policy. For more information, see 802.1X Client Configuration with Group Policy.

  • Automatically configure all of your domain member NAP-capable clients by importing NAP client configuration files into Group Policy.

Authentication

Following are the best practices for authentication.

  • Use certificate-based authentication methods such as Protected Extensible Authentication Protocol (PEAP) and Extensible Authentication Protocol (EAP) for strong authentication. Do not use password-based authentication methods because they are vulnerable to a variety of attacks and are not secure. For more information, see Certificates and NPS.

  • Deploy your own certification authority (CA) with Active Directory® Certificate Services (AD CS) when you use strong certificate-based authentication methods, such as PEAP and EAP, that require the use of a server certificate on NPS servers. You can also use your CA to enroll computer certificates and user certificates. For more information, see Deploying Certificates for PEAP and EAP.

Security issues

When you are administering a NPS server remotely, do not send sensitive or confidential data (for example, shared secrets or passwords) over the network in plaintext. There are two recommended methods for remote administration of NPS servers:

  • Use Terminal Services to access the NPS server.

    When you use Terminal Services, data is not sent between client and server. Only the user interface of the server (for example, the operating system desktop and NPS console image) is sent to the Terminal Services client, which is named Remote Desktop Connection in Windows XP and Windows Vista®. The client sends keyboard and mouse input, which is processed locally by the server that has Terminal Services enabled. When Terminal Services users log on, they can view only their individual client sessions, which are managed by the server and are independent of each other. In addition, Remote Desktop Connection provides 128-bit encryption between client and server.

  • Use Internet Protocol security (IPsec) to encrypt confidential data.

    You can use IPsec to encrypt communication between the NPS server and the remote client computer that is being used to administer it. To administer the server remotely, the Windows Server Administration Tools Pack must be installed on the client computer, and the NPS snap-in must be added to the Microsoft Management Console (MMC).

Your NPS server provides authentication, authorization, and accounting for connection attempts to your organization network. You can protect your NPS server and RADIUS messages from unwanted internal and external intrusion.

Accounting

There are two types of accounting, or logging, in NPS:

  • Event logging for NPS. You can use event logging to record NPS events in the system and security event logs. This is used primarily for auditing and troubleshooting connection attempts.

  • Logging user authentication and accounting requests. You can log user authentication and accounting requests to log files in text format or database format, or you can log to a stored procedure in a SQL Server 2000 database. Request logging is used primarily for connection analysis and billing purposes, and is also useful as a security investigation tool, providing you with a method of tracking down the activity an attacker.

To make the most effective use of NPS logging:

  • Turn on logging (initially) for both authentication and accounting records. Modify these selections after you have determined what is appropriate for your environment.

  • Ensure that event logging is configured with a capacity that is sufficient to maintain your logs.

  • Back up all log files on a regular basis because they cannot be re-created when they are damaged or deleted.

  • Use the RADIUS Class attribute to both track usage and simplify the identification of which department or user to charge for usage. Although the automatically generated Class attribute is unique for each request, duplicate records might exist in cases where the reply to the access server is lost and the request is resent. You might need to delete duplicate requests from your logs to accurately track usage.

  • To provide failover and redundancy with SQL Server logging, place two computers running SQL Server on different subnets. Use the SQL Server Create Publication Wizard to set up database replication between the two servers. For more information, see SQL Server documentation.

For more information, see RADIUS Accounting.

Performance-tuning NPS

  • To optimize NPS authentication and authorization response times and minimize network traffic, install NPS on a domain controller.

  • When universal principal names (UPNs) or Windows Server 2008 and Windows Server 2003 domains are used, NPS uses the global catalog to authenticate users. To minimize the time it takes to do this, install NPS on either a global catalog server or a server that is on the same subnet.

  • When you have remote RADIUS server groups configured and, in NPS Connection Request Policies, you clear the Record accounting information on the servers in the following remote RADIUS server group check box, these groups are still sent network access server (NAS) start and stop notification messages. This creates unnecessary network traffic. To eliminate this traffic, disable NAS notification forwarding for individual servers in each remote RADIUS server group by clearing the Forward network start and stop notifications to this server check box.

Using NPS in large organizations

  • If you are using remote access policies to restrict access for all but certain groups, create a universal group for all of the users for whom you want to allow access, and then create a remote access policy that grants access for this universal group. Do not put all of your users directly into the universal group, especially if you have a large number of them on your network. Instead, create separate groups that are members of the universal group, and add users to those groups.

  • Use a user principal name to refer to users whenever possible. A user can have the same user principal name regardless of domain membership. This practice provides scalability that might be required in organizations with a large number of domains.

  • If the NPS server is on a computer other than a domain controller and it is receiving a very large number of authentication requests per second, you can improve performance by increasing the number of concurrent authentications between the NPS server and the domain controller.

    To do this, edit the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. Add a new value named MaxConcurrentApi and assign to it a value from 2 through 5. If you assign a value to MaxConcurrentApi that is too high, your NPS server might place an excessive load on your domain controller.

Caution

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

Note

To effectively balance the load of either a large number of authorizations or a large volume of RADIUS authentication traffic (such as a large wireless implementation using certificate-based authentication), install NPS as a RADIUS server on all of your domain controllers. Next, configure two or more NPS proxies to forward the authentication requests between the access servers and the RADIUS servers. Next, configure your access servers to use the NPS proxies as RADIUS servers.


Checklists for NPS

Checklists for Network Policy Server (NPS)

The following checklists provide the steps required to deploy NPS as a RADIUS server, RADIUS proxy, and 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

Configure NPS for 802.1X authenticating switch access

This checklist provides the steps 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 NPS servers or, if you are using 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 (http://go.microsoft.com/fwlink/?LinkId=33675)
If you are using 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 clients using Group Policy. | Configure 802.1X Wired Clients Running Windows Vista with Group Policy
Configure 802.1X authenticating switches as RADIUS clients in NPS. | Add a New RADIUS Client; RADIUS Clients
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; Network Policies


Checklist: Configure NPS for Dial-Up and VPN Access

Checklist: Configuring NPS for dial-up and VPN access

This checklist provides the steps required to deploy dial-up and 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 NPS servers or, if you are using 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 (http://go.microsoft.com/fwlink/?LinkId=33675)
If you are using 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 and Deploy User Certificates
Configure dial-up and VPN servers as RADIUS clients in NPS. | Add a New RADIUS Client and RADIUS Clients
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 dial-up and VPN servers. | Add a Network Policy; Create Policies for Dial-Up or VPN with a Wizard; Network Policies


Checklist: Configure NPS as a RADIUS Proxy

Checklist: Configuring NPS as a RADIUS proxy

The following checklist provides the steps required to configure NPS as a RADIUS proxy that forwards connection requests to other RADIUS servers for authentication and authorization.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

Task | Reference
Configure network access servers as RADIUS clients in NPS. | Add a New RADIUS Client; RADIUS Clients
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® 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 manufacturer's documentation


Checklist: Configure NPS for Secure Wireless Access

Configure NPS for Secure Wireless access

This checklist provides the steps 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 NPS servers 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 (http://go.microsoft.com/fwlink/?LinkId=33675)
If you are using EAP-TLS or 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 clients using Group Policy. | Configure 802.1X Wireless Clients Running Windows Vista with Group Policy
Configure 802.1X wireless access points as RADIUS clients in NPS. | Add a New RADIUS Client and RADIUS Clients
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)

Configure Network Access Protection (NAP)

Following are checklist topics that assist you in deploying Network Access Protection (NAP) with NPS.

  • Checklist: Configure NAP Enforcement for 802.1X Wired

  • Checklist: Configure NAP Enforcement for 802.1X Wireless

  • Checklist: Configure NAP Enforcement for DHCP

  • Checklist: Configure NAP Enforcement for TS Gateway

  • Checklist: Configure NAP Enforcement for VPN


Checklist: Configure NAP Enforcement for 802.1X Wired

Configure NAP Enforcement for 802.1X Wired

This checklist provides the steps required to deploy 802.1X authenticating switches with Network Policy Server (NPS) and Network Access Protection (NAP).

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 whether you want to use PEAP-MS-CHAP v2 or PEAP-TLS as the authentication method. | RADIUS Server for 802.1X Wireless or Wired Connections; Certificate Requirements for PEAP and EAP; PEAP Overview; and your hardware documentation
Autoenroll a server certificate to NPS servers or, if you are using PEAP-MS-CHAP v2, 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 (http://go.microsoft.com/fwlink/?LinkId=33675)
If you are using 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 and Deploy User Certificates
Configure 802.1X wired clients using Group Policy. | Configure 802.1X Wired Clients Running Windows Vista with Group Policy
Configure 802.1X authenticating switches as RADIUS clients in NPS. | Add a New RADIUS Client and RADIUS Clients
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
On NAP-capable client computers, enable the Network Access Protection service and change the startup type to automatic. | Enable the Network Access Protection Service on Clients
On NAP-capable client computers, enable the EAP enforcement client. | Enable and Disable NAP Enforcement Clients
If you are using the Windows Security Health Validator (WSHV) in your NAP deployment, enable Security Center on NAP-capable clients using Group Policy. | Enable Security Center in Group Policy
In NPS, if your NAP deployment requires it, configure the WSHV. | Windows Security Health Validator
Install and configure other system health agents (SHAs) and system health validators (SHVs). | System Health Validators
In NPS, configure health policies, connection request policies, and network policies that enforce NAP for 802.1X wired access. | Create NAP Policies with a Wizard
In NPS, if you are deploying remediation servers so that clients can automatically update their configuration in compliance with health policy, configure Remediation Server Groups. | Configure Remediation Server Groups


Checklist: Configure NAP Enforcement for 802.1X Wireless

Configure NAP Enforcement for 802.1X Wireless

This checklist provides the steps required to deploy 802.1X wireless access points with Network Policy Server (NPS) and Network Access Protection (NAP).

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 whether you want to use PEAP-MS-CHAP v2 or PEAP-TLS as the authentication method. | RADIUS Server for 802.1X Wireless or Wired Connections; Certificate Requirements for PEAP and EAP; PEAP Overview; and your hardware documentation.
Autoenroll a server certificate to NPS servers or, if you are using PEAP-MS-CHAP v2, 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 (http://go.microsoft.com/fwlink/?LinkId=33675)
If you are using 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 and Deploy User Certificates
Configure 802.1X wireless clients using Group Policy. | Configure 802.1X Wireless Clients Running Windows Vista with Group Policy
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
On NAP-capable client computers, enable the Network Access Protection service and change the startup type to automatic. | Enable the Network Access Protection Service on Clients
On NAP-capable client computers, enable the EAP enforcement client. | Enable and Disable NAP Enforcement Clients
If you are using the Windows Security Health Validator (WSHV) in your NAP deployment, enable Security Center on NAP-capable clients using Group Policy. | Enable Security Center in Group Policy
In NPS, configure 802.1X wireless access points as RADIUS clients. | Add a New RADIUS Client and RADIUS Clients
In NPS, configure the WSHV or install and configure other system health agents (SHAs) and system health validators (SHVs). | System Health Validators and Windows Security Health Validator
In NPS, configure health policies, connection request policies, and network policies that enforce NAP for 802.1X wireless access. | Create a Health Policy and Create NAP Policies with a Wizard
In NPS, if you are deploying remediation servers so that clients can automatically update their configuration in compliance with health policy, configure Remediation Server Groups. | Configure Remediation Server Groups


Checklist: Configure NAP Enforcement for DHCP

Configure NAP enforcement for DHCP

This checklist provides the steps required to deploy DHCP servers with Network Policy Server (NPS) and Network Access Protection (NAP).

Task | Reference
Install the DHCP server role on the local or a remote computer. | NAP Enforcement for DHCP and DHCP documentation
If DHCP is installed on a remote computer with NPS, configure NPS as a RADIUS proxy. 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
In the DHCP MMC snap-in, enable NAP for individual scopes or for all scopes configured on the DHCP server. | Enable DHCP Scopes for NAP
On the DHCP-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 the DHCP-NPS proxy servers as RADIUS clients on the local RADIUS server (to which requests are forwarded). | Add a New RADIUS Client
If you want to perform authorization by group, create a user group in Active Directory® Domain Services (AD DS) that contains the users who are allowed to obtain an IP address from DHCP servers. | Create a Group for a Network Policy
On NAP-capable client computers, enable the Network Access Protection service and change the startup type to automatic. | Enable the Network Access Protection Service on Clients
On NAP-capable client computers, enable the DHCP enforcement client. | Enable and Disable NAP Enforcement Clients
If you are using the Windows Security Health Validator (WSHV) in your NAP deployment, enable Security Center on NAP-capable clients using Group Policy. | Enable Security Center in Group Policy
In NPS, if you are deploying remediation servers so that clients can automatically update their configuration in compliance with health policy, configure Remediation Server Groups. | Configure Remediation Server Groups
In NPS, configure the WSHV or install and configure other system health agents (SHAs) and system health validators (SHVs). | System Health Validators and Windows Security Health Validator
In NPS, configure health policies, connection request policies, and network policies that enforce NAP for DHCP. | Create a Health Policy and Create NAP Policies with a Wizard
Ensure that NPS network policy constraints allow computer health checks. | Enable Client Health Checks for DHCP and IPsec NAP Deployments


Checklist: Configure NAP Enforcement for TS Gateway

Configure NAP enforcement for Terminal Services Gateway

This checklist provides the steps required to deploy Terminal Services Gateway (TS Gateway) with Network Policy Server (NPS) and Network Access Protection (NAP).

Task | Reference
Install the Terminal Server role and configure TS Gateway. | Terminal Services Gateway documentation
Determine whether to use PEAP-MS-CHAP v2 or PEAP-TLS as the authentication method. | RADIUS Server for 802.1X Wireless or Wired Connections; Certificate Requirements for PEAP and EAP; PEAP Overview; and your hardware documentation
Autoenroll a server certificate to NPS servers or, if you are using PEAP-MS-CHAP v2, 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 (http://go.microsoft.com/fwlink/?LinkId=33675)
If you are using 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 and Deploy User Certificates
Configure computers running TS Gateway as RADIUS clients in NPS. | Add a New RADIUS Client; RADIUS Clients
If you want to perform authorization by group, create a user group in Active Directory® Domain Services (AD DS) that contains the users who are allowed to access the network through the TS Gateway server. | Create a Group for a Network Policy
On NAP-capable client computers, enable the Network Access Protection service and change the startup type to automatic. | Enable the Network Access Protection Service on Clients
On NAP-capable client computers, enable the EAP enforcement client and the TS Gateway enforcement client. | Enable and Disable NAP Enforcement Clients
If you are using the Windows Security Health Validator (WSHV) in your NAP deployment, enable Security Center on NAP-capable clients using Group Policy. | Enable Security Center in Group Policy
In NPS, configure the WSHV or install and configure other system health agents (SHAs) and system health validators (SHVs). | System Health Validators and Windows Security Health Validator
In NPS, configure health policies, connection request policies, and network policies that enforce NAP for TS Gateway access. | Create a Health Policy and Create NAP Policies with a Wizard
In NPS, if you are deploying remediation servers so that clients can automatically update their configuration in compliance with health policy, configure Remediation Server Groups. | Configure Remediation Server Groups


Checklist: Configure NAP Enforcement for VPN

Configure NAP enforcement for VPN

This checklist provides the steps required to deploy computers with Routing and Remote Access Service installed and configured as VPN servers with Network Policy Server (NPS) and Network Access Protection (NAP).

Task | Reference
If you want to perform authorization by group, create a user group in Active Directory® Domain Services (AD DS) that contains the users who are allowed to access the network through VPN servers. | Create a Group for a Network Policy
Determine the authentication method you want to use. | RADIUS Server for Dial-Up or VPN Connections and Certificate Requirements for PEAP and EAP
Autoenroll a server certificate to NPS and VPN servers or, if you are using PEAP-MS-CHAP v2 and you do not want to deploy your own CA, 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 (http://go.microsoft.com/fwlink/?LinkId=33675)
If you are using 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 and Deploy User Certificates
In NPS, configure VPN servers as RADIUS clients and on the VPN server, configure the NPS server as the primary RADIUS server. | Add a New RADIUS Client; RADIUS Clients; and Routing and Remote Access Service documentation in Windows Server® 2008
If you are using the Windows Security Health Validator (WSHV) in your NAP deployment, enable Security Center on NAP-capable clients using Group Policy. | Enable Security Center in Group Policy
In NPS, if your NAP deployment requires it, configure the WSHV. | Windows Security Health Validator
If you are using non-Microsoft products that are compatible with NAP, deploy non-Microsoft system health agents (SHAs) on client computers and their corresponding system health validators (SHVs) on the NPS server. | System Health Validators and product documentation
If you want to provide client computers with automatic updates using autoremediation, deploy and configure Remediation Server Groups in NPS. | Configure Remediation Server Groups and Remediation Server Groups
On the NPS server, configure health policies, connection request policies, and network policies that enforce NAP for VPN connections. | Create NAP Policies with a Wizard
On client computers, manually configure a VPN connection to the VPN server or install a Connection Manager profile that you created with Connection Manager Administration Kit (CMAK). | Routing and Remote Access Service, Network and Sharing Center, and Connection Manager Administration Kit (CMAK) documentation in Windows Server 2008
On NAP-capable client computers, enable the Network Access Protection service and change the startup type to automatic. | Enable the Network Access Protection Service on Clients
On NAP-capable client computers, enable the Remote Access and EAP enforcement clients. | Enable and Disable NAP Enforcement Clients


Client Computer Configuration

Client Computer Configuration

The following topics provide information about configuring access clients for use with Network Policy Server (NPS).

  • 802.1X Client Configuration with Group Policy

  • Deploy Client Computer Certificates

  • NAP Clients


802.1X Client Configuration with Group Policy

802.1X client configuration with Group Policy

  • Configure 802.1X Wired Clients Running Windows Vista with Group Policy

  • Configure 802.1X Wireless Clients Running Windows Vista with Group Policy

  • Configure 802.1X Wireless Clients Running Windows XP with Group Policy


Configure 802.1X Wired Clients Running Windows Vista with Group Policy

Use the procedures in this topic to configure the Wired Network (IEEE 802.3) Policies for client computers running Windows Vista® that connect to your wired Ethernet network through 802.1X authenticating switches.

This document provides the detailed steps to create and configure the Wired Network (IEEE 802.3) Policies and wired configuration profile for computers running Windows Vista.

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

Configure 802.1X Wired Clients by using Wired Network (IEEE 802.3) Policies

This document provides the detailed steps to add and configure the Wired Network (IEEE 802.3) Policies, and to configure a configuration profile for computers running Windows Vista. For example, you can configure a profile to use smart cards or Protected Extensible Authentication Protocol Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2), and enable Single Sign On for computers connecting to the wired network through an 802.1X authenticating switch.

Note

You can use the Windows Vista Wired Network (IEEE 802.3) Policies to configure computers running Windows Vista and Windows Server 2008. You cannot use this policy to configure computers running Windows XP. Computers running Windows XP cannot interpret settings in a Windows Vista Wired Network (IEEE 802.3) Policies.

You can use these features to configure security and authentication settings, manage wireless profiles, and specify permissions for wireless networks that are not configured as preferred networks.
Opening the Wired Network (IEEE 802.3) Policies properties

Use this procedure to access the Wired Network (IEE 802.3) Policy.

To open the Wired Network (IEEE 802.3) Policies properties

  1. Open the Group Policy Management Console (GPMC).

  2. In Default Domain Policy, open Computer Configuration, open Windows Settings, open Security Settings, and then select Wired Network (IEEE 802.3) Policies.

    • If there is an activated Windows Vista wired network policy in the details pane:

      Right-click the New Vista Wired Network Policy, and then click Properties, to access the properties of the wired network policy.

      Note

      The wired policy is not necessarily listed as New Vista Wired Network Policy in the details pane of the GPMC. If the default policy name was previously changed from New Vista Wired Network Policy to another name, the name change is reflected in the GPMC details pane.

    • If there is not an activated Windows Vista wired policy in the details pane:

      Right-click Wired Network (IEEE 802.3) Policies, and then click Create A New Windows Vista Policy to activate and open the New Vista Wired Network Policy Properties.

      Note

      After the Windows Vista Wired Policy is added, it is only listed in the GPMC details pane when Wireless Network (IEEE 802.11) Policies is selected.

Configure wired clients running Windows Vista by using the Wired Network (IEEE 802.3) Policies

This section contains procedures that will demonstrate the features provided in the Wired Network (IEEE 802.3) Policies for Windows Vista. You can use these features to configure security and authentication settings for computers running Windows Vista that are connecting to your network through an 802.1X authenticating switch.
Configuring a PEAP-MS-CHAP v2 profile

This procedure provides the steps required to configure a PEAP-MS-CHAP v2 profile.

To configure a profile for PEAP-MS-CHAP v2 wired connections

  1. On the General tab, do the following:

    1. In Policy Name, type a name for the wired network policy.

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

    3. Ensure that Use Windows Wired Auto Config service for clients is selected.

      Note

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

  2. On the Security tab, do the following:

    1. Select Enable use of IEEE 802.1X authentication for network access.

    2. In Select a network authentication method, select Protected EAP (PEAP).

    3. In Authentication mode, select User re-authentication.

    4. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed.

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

  3. To configure Single Sign On or advanced 802.1X settings, click Advanced. On the Advanced tab, do the following:

    1. To configure advanced 802.1X settings, select Enforce advanced 802.1X settings, and then modify — only as necessary — the settings for: Max Eapol-Start Msgs, Held Period, Start Period, Auth Period, Eapol-Start Message.

    2. To configure Single Sign On, select Enable Single Sign On for this network, and then modify — as necessary — the settings for:

      Perform Immediately before User Logon

      Perform Immediately after User Logon

      Max delay for connectivity

      Allow additional dialogs to be displayed during Single Sign On

      Max delay with dialogs

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

  4. Click OK. On the Security tab, click Properties.

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

    1. Select Validate server certificate.

    2. In Trusted Root Certification Authorities, select the Trusted Root Certification Authority (CA) that issued the server certificate to your Network Policy (NPS) Server.

      Note

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

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

    4. To specify that system health checks are preformed on clients to ensure they meet health requirements, before connections to the network are permitted, select Enable Quarantine checks.

    5. Click OK, to save the Protected EAP (PEAP) settings.

  6. Click OK to save the changes to the wired policy, and then close the Group Policy Management console.
Configuring a Smart Card or other certificate profile

This procedure provides the steps required to configure a PEAP-MS-CHAP v2 profile.

To configure a Smart Card or other certificate profile

  1. On the General tab, do the following:

    1. In Policy Name, type a name for the wired network policy.

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

    3. Ensure the user is notified that that Use Windows Wired Auto Config service for clients is selected.

      Note

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

  2. On the Security tab, do the following:

    1. Select Enable use of IEEE 802.1X authentication for network access.

    2. In Select a network authentication method, select Smart Card or other certificate.

    3. In Authentication mode, select User re-authentication.

    4. In Max Authentication Failures, specify the maximum number of failed attempts allowed before the user is notified that authentication has failed.

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

  3. To configure Single Sign On or advanced 802.1X settings, click Advanced. On the Advanced tab, do the following:

    1. To configure advanced 802.1X settings, select Enforce advanced 802.1X settings, and then modify — only as necessary — the settings for: Max Eapol-Start Msgs, Held Period, Start Period, Auth Period, Eapol-Start Message.

    2. To configure Single Sign On, select Enable Single Sign On for this network, and then modify — as necessary — the settings for:

      Perform Immediately before User Logon

      Perform Immediately after User Logon

      Max delay for connectivity

      Allow additional dialogs to be displayed during Single Sign On

      Max delay with dialogs

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

  4. Click OK. On the Security tab, click Properties.

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

    1. Select Validate server Certificate.

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

      Note

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

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

    4. To specify that system health checks are preformed on clients to ensure they meet health requirements, before connections to the network are permitted, select Enable Quarantine checks.

    5. Click OK, to save the Protected EAP (PEAP) settings.

  6. Click OK to save the changes to the wired policy, and then close the Group Policy Management Console.


Configure 802.1X Wireless Clients Running Windows Vista with Group Policy

Use the procedures in this topic to configure the Wireless Network (IEEE 802.11) Policies for client computers running Windows Vista® that connect to your wireless network through 802.1X authenticating wireless access points (APs).

This document provides the detailed steps to create and configure the Windows Vista Wireless Network (IEEE 802.11) Policies and wireless configuration profiles for wireless computers running Windows Vista.

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

Configure wireless clients running Windows Vista by using the Wireless Network (IEEE 802.11) Policies

The New Vista Wireless Network (IEEE 802.11) Policies enables you to configure, prioritize and manage multiple wireless profiles that each use different profile names and different wireless settings, while using the same Service Set Identifier (SSID). For example, you can configure two (or more) profiles using the same SSID; one profile to use Smart Cards and one profile to use Protected Extensible Authentication Protocol Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2), or one using Wi-Fi Protected Access version 2 (WPA2)-Enterprise and one using WPA-Enterprise. The ability to configure mixed-mode deployments using a common SSID is one of the enhancements in the Wireless Network (IEEE 802.11) Policies for Windows Vista.

Note

You can use the Windows Vista Wireless Network (IEEE 802.11) Policies to configure wireless computers running Windows Vista and Windows Server 2008. You cannot use this policy to configure computers running Windows XP. Computers running Windows XP cannot interpret settings in a Windows Vista Wireless Network (IEEE 802.11) Policies.

You can use these features to configure security and authentication settings, manage wireless profiles, and specify permissions for wireless networks that are not configured as preferred networks.
Opening the Wireless Network (IEEE 802.11) Policies properties

Use this procedure to access the Wireless Network (IEEE 802.11) Policies.

To open the Wireless Network (IEEE 802.11) Policies properties

  1. Open the Group Policy Management Console (GPMC).

  2. In Default Domain Policy, open Computer Configuration, open Windows Settings, open Security Settings, and then select Wireless Network (IEEE 802.11) Policies.

    • If there is a Wireless Network Policy shown in the details pane, with the Type listed as Vista, right-click that policy, and then click Properties, to access the properties of the wireless policy.

      Note

      The wireless policy is not necessarily listed as New Vista Wireless Network Policy in the details pane of the GPMC. If the default policy name was previously changed from New Vista Wireless Network Policy to another name, the name change is reflected in the GPMC details pane.

    • If there is not a Wireless Network Policy shown in the details pane, with the Type listed as Vista, right-click Wireless Network (IEEE 802.11) Policies, and then click Create A New Windows Vista Policy to activate and open New Vista Wireless Network Policy Properties.

      Note

      After the Windows Vista wireless policy is added, it is only listed in the GPMC details pane, when Wireless Network (IEEE 802.11) Policies is selected.

Configure PEAP-MS-CHAP v2 and EAP-TLS wireless infrastructure profiles

The procedures in this section provide the steps to configure the Windows Vista Wireless Network (IEEE 802.11) Policies to create one or more wireless profiles that wireless clients running Windows Vista will use to connect to your wireless network. The first procedure provides the steps to use Windows Vista Wireless Network (IEEE 802.11) Policies to configure a wireless profile for PEAP-MS-CHAP v2. The second procedure provides the steps to use Windows Vista Wireless Network (IEEE 802.11) Policies to configure a wireless profile for EAP-TLS.

Note

PEAP-MS-CHAPv2 is easier to deploy than other authentication methods, such as Extensible Authentication Protocol-Transport Layer Security (EAP-TLS). PEAP does not require the deployment of a public key infrastructure (PKI); only a Remote Authentication Dial-In User Service (RADIUS) server is required to provide a certificate. Additionally, PEAP does not require the deployment of an infrastructure, such as smart cards or another type of client certificates, to validate connecting clients.

Configuring a PEAP-MS-CHAP v2 wireless profile

This procedure provides the steps required to configure a PEAP-MS-CHAP v2 wireless profile.

To configure a PEAP-MS-CHAP v2 wireless profile

  1. In Windows Vista Wireless Network (IEEE 802.11) Policies Properties, on the General tab, do one of the following:

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

    • To modify an existing profile, select the profile, and then click Edit.

    Note

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

  2. On the Connection tab, do the following:

    1. In Profile Name, type a name for this wireless profile.

    2. In Network Name(s) (SSID), type the SSID that corresponds to the SSID configured on your wireless APs, and then click Add.

    3. If present, select NEWSSID, and then click Remove.

    4. If your wireless access point is configured to suppress its broadcast beacon, select Connect even if the network is not broadcasting.

      Note

      Enabling this option can create a security risk because wireless clients will probe for and attempt connections to any wireless network. By default, this setting is not enabled.

  3. Click the Security tab, click Advanced, and then configure the following:

    1. To configure advanced 802.1X settings, in IEEE 802.1X, select Enforce advanced 802.1X settings.

      Note

      When the advanced 802.1X settings are enforced, the default values for Max Eapol-Start Msgs, Held Period, Start Period, and Auth Period are sufficient for most wireless deployments.

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

      Note

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

    3. In Fast Roaming, select This network uses pre-authentication, if your wireless AP is configured for pre-authentication.

  4. Click OK to return to the Security tab, and then configure the following:

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

    2. In Encryption, select AES, if it is supported by your wireless AP and wireless client network adapters. Otherwise, select TKIP.

      Note

      The settings for both Authentication and Encryption must match the settings configured on your wireless AP. On the Security tab, the default settings for Authentication Mode, Max Authentication Failures, and Cache user information for subsequent connections to this network are sufficient for most wireless deployments.

  5. In Select a network authentication method, select Protected EAP (PEAP), and then click Properties. In the Protected EAP Properties dialog box, configure the following:

    1. Verify that Validate server certificate is selected.

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

      Note

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

    3. In the Select Authentication Method list, select Secured password (EAP-MS-CHAP v2).

    4. Select Enable Fast Reconnect.

    5. Clear Enable Quarantine checks.

  6. Click Configure. In the EAP MSCHAPv2 Properties dialog box, verify Automatically use my Windows logon name and password (and domain if any) is selected, click OK, and then click OK to close Protected EAP Properties.

  7. Click OK to close the Security tab.
Configuring an EAP-TLS wireless profile

This procedure provides the steps required to configure an EAP-TLS wireless profile.

To configure an EAP-TLS wireless profile

  1. In Windows Vista Wireless Network (IEEE 802.11) Policies Properties, on the General tab, click Add, and then select Infrastructure.

    Note

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

  2. On the Connection tab, do the following:

    1. In Profile Name, type a name for the EAP-based profile.

    2. In Network Name(s) (SSID), type the SSID that corresponds to the SSID configured on your wireless APs, and then click Add.

    3. If present, select NEWSSID, and then click Remove.

    4. If your wireless access point is configured to suppress its broadcast beacon, select Connect even if the network is not broadcasting.

      Note

      Enabling this option can create a security risk because wireless clients will probe for and attempt connections to any wireless network. By default, this setting is not enabled.

  3. Select the Security tab, click Advanced, and then configure the following:

    1. To configure advanced 802.1X settings, in IEEE 802.1X, select Enforce advanced 802.1X settings.

      Note

      When the advanced 802.1X settings are enforced, the default values for Max Eapol-Start Msgs, Held period, Start Period, and Auth Period are sufficient for most wireless deployments.

    2. In Single Sign On, select Enable Single Sign On for this network.

      Note

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

    3. In Fast Roaming, select This network uses pre-authentication if your wireless AP is configured for pre-authentication.

  4. Click OK to return to the Security tab, and then configure the following:

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

    2. In Encryption, select AES (preferred) if it is supported by your wireless AP and wireless client network adapters. Otherwise, select TKIP.

      Note

      The settings for both Authentication and Encryption must match the settings configured on your wireless AP. On the Security tab, the default settings for Authentication Mode, Max Authentication Failures, and Cache user information for subsequent connections to this network are sufficient for most wireless deployments.

  5. In Select a network authentication method, select Smart Card or other certificate (EAP-TLS). On the Security tab, click Properties, and then configure the following:

    1. In When connecting, verify that Use a certificate on this computer and Use simple certificate selection are selected.

    2. Verify that Validate server certificate is selected.

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

      Note

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

  6. Click OK to close Smart Card or other Certificate Properties, and then click OK again to close the EAP Profile.

Configuring connection preference order for wireless networks

Wireless clients running Windows Vista attempt to connect to wireless networks in the order specified in Windows Vista Wireless Policy. This procedure demonstrates how to specify the order of wireless profiles to which domain clients running Windows Vista will attempt to connect.

To specify the order of wireless networks

  1. Open the Windows Vista Wireless Network (IEEE 802.11) Policies Properties. On the General tab, in Connect to available networks in the order of profiles listed below, select any profile, then click the "up arrow" or the "down arrow" to move the profile to the desired location in the list.

  2. Click OK to save the change, and then close the Windows Vista Wireless Policy.

Defining network permissions

You can configure the following on the Network Permissions tab to specify network permissions:

  • To block your domain members running Windows Vista from gaining access to ad hoc networks, select Prevent connections to ad-hoc networks.

  • To block your domain members running Windows Vista from gaining access to infrastructure networks, select Prevent connections to infrastructure networks.

  • To allow your domain members running Windows Vista to view network types (ad hoc or infrastructure) to which they are denied access, select Allow user to view denied networks.

    Note

    The Remove button on the Network Permissions tab allows you to remove only those networks that you have defined by using the Add feature. Networks that are defined on the General tab, in Connect to available networks in the order of profiles listed below, cannot be removed from the permissions list.
Adding wireless networks to the Deny list

For a variety of reasons, you might want to block managed wireless computers from connecting to other wireless networks that are within range of the organization’s wireless network. For example, an adjoining building might have a wireless AP broadcasting, which can be seen on your network wireless client computers running Windows Vista.

This procedure demonstrates how to use the Windows Vista Wireless Network (IEEE 802.11) Policies to allow or deny permissions for wireless networks.

To add a wireless network to the Deny list

  1. Open the Windows Vista Wireless Policy.

  2. On the Network Permissions tab, click Add.

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

    1. In Network Name (SSID) type the SSID of a wireless network.

    2. In Network Type, select Infrastructure or Ad-hoc.

      Note

      If you are unsure whether the broadcasting network is an infrastructure or ad hoc network, you can configure a network permission entry for both types.

    3. In Permission, select Deny.

  4. Click OK. On the Network Permissions tab, select Allow user to view denied networks, and then click OK.
To prevent users from viewing blocked networks

To prevent users from seeing broadcasting networks to which you want to deny access. This procedure demonstrates how to prevent your wireless clients from displaying wireless networks to which you have denied access.

To prevent users from viewing networks in the Deny list

  1. Open the Windows Vista Wireless Policy.

  2. On the Network Permissions tab, clear the Allow user to view denied networks check box, and then click OK.
Exporting wireless profiles

In addition to creating a backup of configured profiles, the export and import features are used to support independent hardware vendor (IHV) extensibility. An administrator can include IHV-specific connectivity or security settings in an Extensible Markup Language (XML) profile and then import this profile to wireless Group Policy. Because these settings do not display onscreen in Windows Vista, importing them is the only way that a profile can include these settings in wireless Group Policy.

This procedure demonstrates how to export a wireless profile.

To export a wireless profile

  1. In Windows Vista Wireless Network (IEEE 802.11) Policies Properties, on the General tab, in Connect to available networks in the order of profiles listed below, select the profile you want to export, and then click Export.

  2. In the Save exported profile as dialog box, verify that Save as type is (*.xml), and then click Save.

    Note

    By default, the profile is saved as an XML file in the Documents folder of the current user. The profile name is automatically provided in its file name. If you specify a different name for the exported file, such as "Backup.xml," when imported the profile will appear in "Connect to available networks" in the order of profiles listed below with the original profile name and the original SSID.
Importing a wireless profile

This procedure demonstrates how to import a wireless profile. You can use the import feature to restore profiles that have been deleted. You can also use the import feature to restore a profile that was changed after a backup copy was exported.

To import a wireless profile

  1. In Windows Vista Wireless Network (IEEE 802.11) Policies Properties, on the General tab, in Connect to available networks in the order of profiles listed below, click Import.

  2. In Import a profile, navigate to the profile that you want to import, and then click Open.

    Note

    By default, the Open to import a profile dialog box opens the most recent directory that has been accessed using the import and export features.

  3. Select the profile, and then click Open.


Configure 802.1X Wireless Clients Running Windows XP with Group Policy

Use the procedures in this topic to configure the Wireless Network (IEEE 802.11) Policies for client computers running Windows XP that connect to your wireless network through 802.1X authenticating wireless access points (APs).

This document provides the detailed steps to create and configure the Wireless Network (IEEE 802.11) Policies and wireless configuration profiles for wireless computers running Windows XP and Windows Server 2003.

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

Configure wireless clients running Windows XP by using the Wireless Network (IEEE 802.11) Policies

You can use the Windows XP Wireless Network (IEEE 802.11) Policies to configure and manage wireless profiles for computers running Windows XP.

Similar to the wireless policy for computers running Windows Vista, you can configure and prioritize multiple profiles by using the wireless network policy for computers running Windows XP. However, unlike the wireless policy for Windows Vista, the wireless policy for Windows XP requires each profile to specify a unique SSID.

Using the Windows Server 2008 or Windows Vista Group Policy Management Console to configure wireless policies exposes the settings that enable you to configure Wi-Fi Protected Access version 2 (WPA2) on client computers running Windows XP with Service Pack 2 (SP2). This is not possible when using the GPMC in Windows Server 2003.

Note

You can use the Windows XP Wireless Network (IEEE 802.11) Policies to configure wireless computers running Windows Vista and Windows Server 2008. However, the only the Windows Vista Wireless Network (IEEE 802.11) Policies provides the configuration settings for the enhanced security and management features available in computers running Windows Vista and Windows Server 2008.
Opening the Wireless Network (IEEE 802.11) Policies properties

Use this procedure access the Wireless Network (IEE 802.11) Policy.

To open the Wireless Network (IEEE 802.11) Policies properties

  1. Open the Group Policy Management Console (GPMC).

  2. In Default Domain Policy, open Computer Configuration, open Windows Settings, open Security Settings, and then select Wireless Network (IEEE 802.11) Policies.

  3. If there is a Wireless Network Policy in the details pane, with the Type listed as XP, right-click that policy, and then click Properties, to access the properties of the wireless policy.

    Note

    The wireless policy is not necessarily listed as New Vista Wireless Network Policy in the details pane of the Group Policy Management Console. If the default policy name was previously changed from New Vista Wireless Network Policy to another name, the name change is reflected in the GPMC details pane.

  4. If there is not a Wireless Network Policy in the details pane, with the Type listed as XP, right-click Wireless Network (IEEE 802.11) Policies, and then click Create A New Windows XP Policy to activate and open the New XP Wireless Network Policy Properties.

    Note

    After the Windows Vista Wireless Policy is added, it is only listed in the GPMC details pane, when Wireless Network (IEEE 802.11) Policies is selected.

Configure wireless clients running Windows XP

The procedure in this section provide the steps to use the Windows XP Wireless Network (IEEE 802.11) Policies to configure wireless profiles that wireless clients running Windows XP will use to connect to your wireless network.

To configure wireless clients running Windows XP by using the Wireless Network (IEEE 802.11) Policies

  1. In Windows XP Wireless Network (IEEE 802.11) Policies Properties, on the General tab, do the following:

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

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

    3. In Networks to access, select either Any available network (wireless AP preferred) or Access Point (infrastructure) network only.

    4. Select Use Windows to configure wireless network settings for clients.

  2. On the Preferred Networks tab, click Add, and then select Infrastructure. On the Network Properties tab, configure the following:

    1. In Network Name (SSID), type the SSID for your network.

      Note

      The value you enter in this field must match the value configured on the access points you have deployed on your network.

    2. In Description, enter a description for the New Preferred Setting Properties.

    3. To specify that a network key is used for authentication to the wireless network, under Select the security methods for this network, in Authentication, select either WPA2 (preferred), or WPA. In Encryption, specify either AES or TKIP.

      Note

      In the Windows XP Wireless Network (IEEE 802.11) Policies, WPA2 and WPA correspond to the Windows Vista Wireless Network (IEEE 802.11) Policies WPA2-Enterprise and WPA-Enterprise settings, respectively.

      Note

      Selecting WPA2 exposes additional settings for Fast Roaming. The default settings for Fast Roaming are sufficient for most wireless deployments.

  3. Click the IEEE 802.1X tab. In EAP type, select one of the following:

    For deployments using PEAP-MS-CHAP v2, do the following:

    1. By default, Protected EAP (PEAP) is selected.

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

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

      Verify that Validate Server certificate is selected.

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

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

      Note

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

      To enable PEAP Fast Reconnect, ensure that Enable Fast Reconnect is selected.

    3. Click OK two times. The PEAP profile is listed under Networks. Click OK, and then close the Group Policy Management Console.

    For deployments using Smart Card or other certificates (EAP-TLS) do the following:

    1. Select Smart Card or other Certificate.

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

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

      For smart card deployments, select Use my smart card, for other certificate deployments, select Use a certificate on this computer.

      Verify that Validate Server certificate is selected.

      In Trusted Root Certification Authorities, select the trusted root CA that issued the server certificate to your Network Policy server.

      Note

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

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


General NPS Information

General NPS information

General NPS information includes content that is not specific to how you deploy NPS and the features you decide to use. For example, you can configure RADIUS accounting whether you deploy NPS as a RADIUS server, a RADIUS proxy, or as a NAP policy server.

For more information, see the following sections.

  • Configure NPS on a Multihomed Computer

  • Configure NPS to Use the Security Accounts Manager Database

  • Configure NPS UDP Port Information

  • Policies in NPS

  • RADIUS Protocol and Components

  • Register the NPS Server in Active Directory Domain Services

  • NPS Authentication Methods

  • RADIUS Accounting

  • RADIUS Clients

  • Securing NPS


Configure NPS to Use the Security Accounts Manager Database

Configure NPS to use the SAM database

When you install Network Policy Server (NPS) as a member server in an Active Directory® domain, it is configured by default to use the Active Directory user accounts database to authenticate and authorize connection requests.

In some cases, you might want to use the local Security Accounts Manager (SAM) database instead of the Active Directory user accounts database for the authentication and authorization of connection requests.

If the NPS server is not joined to a domain, NPS uses the SAM database by default.

Note

The SAM database is also called Local Users and Groups. You can manage user accounts for Local Users and Groups by using the Computer Management console on the local computer. To open Computer Management, click Start, click Administrative Tools, and then click Computer Management.

To configure a domain-member NPS server to use the SAM database on the local computer, configure the following registry key with the name of the local computer:

System\CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn\DefaultDomain

For example, if the name of your NPS server is NPS-01, configure the default domain registry key with the string value NPS-01.

Caution

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


Policies in NPS

Policies in NPS

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

Connection request policies. Sets of conditions and settings that allow network administrators to designate which RADIUS servers perform the authentication and authorization of connection requests that the NPS server receives from RADIUS clients. Connection request policies can be configured to designate which RADIUS servers are used for RADIUS accounting.

Important

When you deploy Network Access Protection (NAP) using the VPN or 802.1X enforcement methods with PEAP authentication, you must configure PEAP authentication in connection request policy even when connection requests are processed locally.

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.

Network policies. 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 NAP, health policy is added to the network policy configuration so that NPS performs client health checks during the authorization process.

Important

These policies are different from and unrelated to Group Policy.

See Also

  • Connection Request Policies
  • Health Policies
  • Network Policies
  • Create NAP Policies with a Wizard


RADIUS Protocol and Components

RADIUS protocol and components

Remote Authentication Dial-In User Service (RADIUS) is an industry standard protocol described in Request for Comments (RFC) 2865, "Remote Authentication Dial-in User Service (RADIUS)," and RFC 2866, "RADIUS Accounting." RADIUS is used to provide network authentication, authorization, and accounting services.

Note

Network Policy Server (NPS) is a RADIUS server that complies with industry standards.

RADIUS attributes are described in RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869, and RFC 3162. RFCs and Internet drafts for vendor-specific attributes (VSAs), such as RFC 2548, "Microsoft Vendor-specific RADIUS Attributes," define additional RADIUS attributes.

RADIUS infrastructure components

The following components are part of the RADIUS authentication, authorization, and accounting infrastructure:

  • Access clients

  • Access servers (RADIUS clients)

  • RADIUS proxies

  • RADIUS servers

  • User account databases

These components are shown in the following illustration.

Access clients

An access client is a device that requires some level of access to a larger network. Examples of access clients are dial-up or virtual private network (VPN) clients, wireless clients, or LAN clients connected to a switch.

Access servers (RADIUS clients)

An access server is a device that provides some level of access to a larger network. An access server using a RADIUS infrastructure is also a RADIUS client, sending connection requests and accounting messages to a RADIUS server. The following are examples of access servers:

  • Network access servers that provide remote access connectivity to an organization network or the Internet. An example is a computer running Windows Server® 2003 and the Routing and Remote Access service and providing either traditional dial-up or virtual private network (VPN) services to an organization's intranet.

  • Wireless access points that provide physical layer access to an organization's 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.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

RADIUS proxies

A RADIUS proxy is a device that forwards or routes RADIUS connection requests and accounting messages between RADIUS clients (and RADIUS proxies) and RADIUS servers (or RADIUS proxies). The RADIUS proxy uses information within the RADIUS message, such as the User-Name or Called-Station-ID RADIUS attributes, to route the RADIUS message to the appropriate RADIUS server.

A RADIUS proxy can be used as a forwarding point for RADIUS messages when the authentication, authorization, and accounting must occur at multiple RADIUS servers in different organizations.

RADIUS servers

A RADIUS server is a device that receives and processes connection requests or accounting messages sent by RADIUS clients or RADIUS proxies. In the case of connection requests, the RADIUS server processes the list of RADIUS attributes in the connection request. Based on a set of rules and the information in the user account database, the RADIUS server either authenticates and authorizes the connection and sends back an Access-Accept message or sends back an Access-Reject message. The Access-Accept message can contain connection restrictions that are implemented by the access server for the duration of the connection.

User account databases

The user account database is the list of user accounts and their properties that can be checked by a RADIUS server to verify authentication credentials and user account properties containing authorization and connection parameter information.

The user account databases that NPS can use are the local Security Accounts Manager (SAM), a Microsoft Windows NT 4.0 domain, or Active Directory® Domain Services (AD DS). For AD DS, NPS can provide authentication and authorization for user or computer accounts in the domain in which the NPS server is a member, two-way trusted domains, and trusted forests with domain controllers running Windows Server® 2008; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition.

If the user accounts for authentication reside in a different type of database, NPS can be configured as a RADIUS proxy to forward the authentication request to a RADIUS server that does have access to the user account database. Different databases for AD DS include untrusted forests, untrusted domains, or one-way trusted domains.

RADIUS protocol

A RADIUS client (typically a dial-up server, VPN server, 802.1X authenticating switch, or wireless access point) sends user credentials and connection parameter information in the form of a RADIUS message to a RADIUS server. The RADIUS server authenticates and authorizes the RADIUS client request, and sends back a RADIUS message response. RADIUS clients also send RADIUS accounting messages to RADIUS servers. Additionally, the RADIUS standards support the use of RADIUS proxies. A RADIUS proxy is a computer that forwards RADIUS messages between RADIUS-enabled computers.

RADIUS messages are sent as User Datagram Protocol (UDP) messages. Only one RADIUS message is included in the UDP payload of a RADIUS packet.

UDP port 1812 is used for RADIUS authentication messages and UDP port 1813 is used for RADIUS accounting messages. Some network access servers might use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages. By default, NPS supports receiving RADIUS messages destined to both sets of UDP ports.

RFCs 2865 and 2866 define the following RADIUS message types:

  • Access-Request

    Sent by a RADIUS client to request authentication and authorization for a connection attempt.

  • Access-Accept

    Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is authenticated and authorized.

  • Access-Reject

    Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is rejected. A RADIUS server sends this message if either the credentials are not authentic or the connection attempt is not authorized.

  • Access-Challenge

    Sent by a RADIUS server in response to an Access-Request message. This message is a challenge to the RADIUS client that requires a response.

  • Accounting-Request

    Sent by a RADIUS client to specify accounting information for a connection that was accepted.

  • Accounting-Response

    Sent by the RADIUS server in response to the Accounting-Request message. This message acknowledges the successful receipt and processing of the Accounting-Request message.

A RADIUS message consists of a RADIUS header and zero or more RADIUS attributes. Each RADIUS attribute specifies a piece of information about the connection attempt. For example, there are RADIUS attributes for the user name, the user password, the type of service requested by the user, and the IP address of the access server. RADIUS attributes are used to convey information between RADIUS clients, RADIUS proxies, and RADIUS servers. For example, the list of attributes in the Access-Request message includes information about the user credentials and the parameters of the connection attempt. In contrast, the Access-Accept message includes information about the type of connection that can be made, connection constraints, and any VSAs.

See Also

  • Configure NPS UDP Port Information
  • Configure NPS on a Multihomed Computer


Register the NPS Server in Active Directory Domain Services

Register the NPS server in Active Directory Domain Services

When Network Policy Server (NPS) is a member of an Active Directory® 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 Active Directory Domain Services (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 NPS server 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 using Network Policy Server

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

  2. Open Network Policy Server.

  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 with an account that has administrative credentials for the domain.

  2. Open Command Prompt.

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

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

  2. Open Active Directory Users and Computers.

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

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

  5. In the RAS and NPS 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 NPS Servers group with the Dsmod tool.
To register the NPS server in another domain using Active Directory Users and Computers

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

  2. Open Active Directory Users and Computers.

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

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

  5. In the RAS and NPS 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 NPS Servers group with the Dsmod tool.

    After you register the server in AD DS, you can verify the security settings.
To register the NPS server in another domain using the netsh command

  1. Log on to the NPS server with 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 DNS domain 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.

See Also

  • Configure NPS to Use the Security Accounts Manager Database


Configure NPS UDP Port Information

Configure NPS UDP port information

You can use the following procedure to configure the ports that Network Policy Server (NPS) uses for 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 values of 1812 for authentication and 1813 for accounting are RADIUS standard ports defined 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 using the Windows interface

  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

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 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 an adapter for RADIUS traffic.

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 an adapter 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, you should 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:

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


NPS Authentication Methods

Authentication methods

When users attempt to connect to your network through network access servers (also called RADIUS clients), such as wireless access points, 802.1X authenticating switches, dial-up servers, and virtual private network (VPN) servers, Network Policy Server (NPS) authenticates and authorizes the connection request before allowing or denying access.

Because authentication is the process of verifying the identity of the user or computer attempting to connect to the network, NPS must receive proof of identity from the user or computer in the form of credentials.

Some authentication methods use password-based credentials. For example, Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) requires that users type in a user name and password. These credentials are then passed to the NPS server by the network access server, and NPS verifies the credentials against the user accounts database.

Other authentication methods use certificate-based credentials for the user, the client computer, the NPS server, or some combination. Certificate-based authentication methods provide strong security and are recommended over password-based authentication methods.

When you deploy NPS, you can specify the type of authentication method that is required for access to your network.

See Also

  • Password-Based Authentication Methods
  • Certificates and NPS
  • EAP Overview
  • PEAP Overview


Password-Based Authentication Methods

Password-based authentication methods

Each authentication method has advantages and disadvantages in terms of security, usability, and breadth of support. Password-based authentication methods, however, do not provide strong security and their use is not recommended. It is recommended that you use a certificate-based authentication method for all network access methods that support the use of certificates. This is especially true for wireless connections, for which the use of PEAP-MS-CHAP v2 or PEAP-TLS is recommended.

The authentication method to use is determined by the configuration of the network access server, the client computer, and network policy on the server running Network Policy Server (NPS). Consult your access server documentation to determine which authentication methods are supported.

You can configure NPS to accept multiple authentication methods. You can also configure your network access servers, also called RADIUS clients, to attempt to negotiate a connection with client computers by requesting the use of the most secure protocol first, and then the next most secure, and so on, down to the least secure. For example, the Routing and Remote Access service tries to negotiate a connection using EAP first, then MS-CHAP v2, then MS-CHAP, then CHAP, then SPAP, and then PAP. When EAP is chosen as the authentication method, the negotiation of the EAP type occurs between the access client and the NPS server.

MS-CHAP version 2

Version 2 of the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v2) provides stronger security for network access connections than its predecessor, MS-CHAP. MS-CHAP v2 solves some of the issues of MS-CHAP version 1, as described in the following table.

MS-CHAP version 1 issue | MS-CHAP version 2 solution
LAN Manager encoding of the response used for backward compatibility with older Microsoft remote access clients is cryptographically weak. | MS-CHAP v2 no longer allows LAN Manager-encoded responses.
LAN Manager encoding of password changes is cryptographically weak. | MS-CHAP v2 no longer allows LAN Manager-encoded password changes.
Only one-way authentication is possible. The remote access client cannot verify that it is dialing in to its organization's remote access server or a masquerading remote access server. | MS-CHAP v2 provides two-way authentication, also known as mutual authentication. The remote access client receives verification that the remote access server that it is dialing in to has access to the user's password.
With 40-bit encryption, the cryptographic key is based on the user's password. Each time the user connects with the same password, the same cryptographic key is generated. | With MS-CHAP v2, the cryptographic key is always based on the user's password and an arbitrary challenge string. Each time the user connects with the same password, a different cryptographic key is used.
A single cryptographic key is used for data sent in both directions on the connection. | With MS-CHAP v2, separate cryptographic keys are generated for transmitted and received data.

MS-CHAP v2 is a one-way encrypted password, mutual authentication process that works as follows:

  1. The authenticator (the network access server or the NPS server) sends a challenge to the access client that consists of a session identifier and an arbitrary challenge string.

  2. The access client sends a response that contains:

    • The user name.

    • An arbitrary peer challenge string.

    • A one-way encryption of the received challenge string, the peer challenge string, the session identifier, and the user's password.

  3. The authenticator checks the response from the client and sends back a response containing:

    • An indication of the success or failure of the connection attempt.

    • An authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user's password.

  4. The access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the access client terminates the connection.

Enabling MS-CHAP v2

To enable MS-CHAP v2-based authentication, you must do the following:

  1. Enable MS-CHAP v2 as an authentication protocol on the network access server.

  2. Enable MS-CHAP v2 on the appropriate network policy.

  3. Enable MS-CHAP v2 on the access client.

Additional considerations

  • MS-CHAP (version 1 and version 2) is the only password-based authentication protocol that supports password change during the authentication process.

  • Make sure your network access server supports MS-CHAP v2 before you enable it on a network policy on an NPS server. For more information, see your NAS documentation.

MS-CHAP

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), also known as MS-CHAP version 1, is a nonreversible, encrypted password authentication protocol. The challenge handshake process works as follows:

  1. The authenticator (the network access server or the NPS server) sends a challenge to the access client that consists of a session identifier and an arbitrary challenge string.

  2. The access client sends a response that contains the user name and a nonreversible encryption of the challenge string, the session identifier, and the password.

  3. The authenticator checks the response and, if valid, the user's credentials are authenticated.

If you use MS-CHAP as the authentication protocol, then you can use Microsoft Point-to-Point Encryption (MPPE) to encrypt the data sent on the PPP or PPTP connection.

MS-CHAP version 2 provides stronger security for network access connections than MS-CHAP. You should consider using MS-CHAP version 2 instead of MS-CHAP.

Enabling MS-CHAP

To enable MS-CHAP-based authentication, you must do the following:

  1. Enable MS-CHAP as an authentication protocol on the network access server.

  2. Enable MS-CHAP on the appropriate network policy in NPS.

  3. Enable MS-CHAP on the access client.

Additional considerations

  • By default, this implementation of MS-CHAP v1 does not support LAN Manager authentication. If you want to allow the use of LAN Manager authentication with MS-CHAP v1 for older operating systems such as Windows NT 3.5x and Windows 95, you must set the following registry value to 1 on the NPS server:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Allow LM Authentication

  • If MS-CHAP v1 is used as the authentication protocol, a 40-bit encrypted connection cannot be established if the user's password is larger than 14 characters. This behavior affects both dial-up and VPN-based remote access and demand-dial connections.

Caution

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

CHAP

The Challenge Handshake Authentication Protocol (CHAP) is a challenge-response authentication protocol that uses the industry-standard Message Digest 5 (MD5) hashing scheme to encrypt the response. CHAP is used by various vendors of network access servers and clients. A server running Routing and Remote Access supports CHAP so that access clients that require CHAP are authenticated. Because CHAP requires the use of a reversibly encrypted password, you should consider using another authentication protocol, such as MS-CHAP version 2.

To enable CHAP-based authentication, you must do the following:

  1. Enable CHAP as an authentication protocol on the network access server.

  2. Enable CHAP on the appropriate network policy in NPS.

  3. Enable storage of a reversibly encrypted form of the user's password.

    You can enable its storage per user account or for all accounts in a domain.

  4. Force a reset of the user's password so that the new password is in a reversibly encrypted form.

    When you enable passwords to be stored in a reversibly encrypted form, the current passwords are not in a reversibly encrypted form and are not automatically changed. You must either manually change user passwords or set user passwords to be changed the next time each user logs on.

    If you set user passwords to be changed the next time a user logs on, the user must log on by using a LAN connection and change the password before the user attempts to log on with a remote access connection by using CHAP. You cannot change passwords during the authentication process by using CHAP; the logon attempt fails. One workaround for the remote access user is to temporarily log on by using MS-CHAP to change the password.

  5. Enable CHAP on the access client.

Additional considerations

  • When users' passwords expire, CHAP does not provide the ability for them to change passwords during the authentication process.

  • Verify that your network access server supports CHAP before you enable it on a network policy on a server running NPS. For more information, see your NAS documentation.

  • You cannot use Microsoft Point-to-Point Encryption (MPPE) with CHAP.

PAP

Password Authentication Protocol (PAP) uses plaintext passwords and is the least secure authentication protocol. It is typically negotiated if the access client and network access server cannot negotiate a more secure authentication method.

To enable PAP-based authentication, you must do the following:

  1. Enable PAP as an authentication protocol on the network access server.

  2. Enable PAP on the appropriate network policy in NPS.

  3. Enable PAP on the access client.

Important

When you enable PAP as an authentication protocol, user passwords are sent in plaintext form. Anyone capturing the packets of the authentication process can easily read the password and use it to gain unauthorized access to your intranet. The use of PAP is highly discouraged, especially for VPN connections.

Additional considerations

  • If you deploy a dial-up server, by disabling the support for PAP on the network access server you ensure that plaintext passwords are never sent by dial-up clients. Disabling support for PAP increases authentication security, but remote access clients who only support PAP cannot connect.

  • When users' passwords expire, PAP does not provide the ability for them to change passwords during the authentication process.

  • Make sure your network access server supports PAP before you enable it on a network policy on an NPS server. For more information, see your NAS documentation.

  • You cannot use Microsoft Point-to-Point Encryption (MPPE) with PAP.

Unauthenticated access

With unauthenticated access, user credentials (a user name and password) are not required. Although there are some situations in which unauthenticated access is useful, in most cases it is not recommended on your organization network.

When you enable unauthenticated access, users are allowed access to your network without sending user credentials. In addition, unauthenticated access clients do not negotiate the use of a common authentication protocol during the connection establishment process and do not send a user name or password to NPS.

When you must use unauthenticated access, you can use one of the following solutions:

  • DNIS authorization

  • ANI/CLI authentication

  • Guest authentication

DNIS authorization

Dialed Number Identification Service (DNIS) enables the authorization of a connection attempt by NPS based on the number that the client computer called to initialize the connection. DNIS identifies the number that was called to the receiver of the call and is provided by most telephone companies. For example, you can allow all connections that connect through a specified toll-free number. To identify DNIS-based connections and apply the appropriate connection settings, you must do the following:

  1. Enable unauthenticated access on the network access server.

  2. Create a network policy on the NPS server for DNIS-based authorization with the Called-Station-Id condition set to the phone number that client computers must call to initiate the connection.

  3. Enable unauthenticated access on the network policy in NPS for DNIS-based authorization.
Additional considerations
  • If your phone service or hardware does not support DNIS, you can manually set the phone number of the port.

  • NPS does not support proxied DNIS access requests.

ANI/CLI authentication

Automatic Number Identification/Calling Line Identification (ANI/CLI) authentication is the authentication of a connection attempt based on the phone number of the caller. ANI/CLI service returns the number of the caller to the receiver of the call and is provided by most telephone companies.

ANI/CLI authentication is different from caller ID authorization. In caller ID authorization, the caller sends a valid user name and password. The caller ID that is configured for the dial-in property on the user account must match the connection attempt; otherwise, the connection attempt is rejected. With ANI/CLI authentication, a user name and password are not sent.

To identify ANI/CLI-based connections and apply the appropriate connection settings, you must do the following:

  1. Enable unauthenticated access on the network access server.

  2. Enable unauthenticated access on the appropriate network policy in NPS for ANI/CLI-based authentication.

  3. Create a user account in Active Directory® Domain Services (AD DS) or the local Security Accounts Manager (SAM) database on the NPS server for each number that will be calling and for which you want to provide ANI/CLI authentication. The name of the user account must match the number that the user is dialing from. For example, if a user is dialing in from 555-0100, create a "5550100" user account. In addition, the password for the user account must be null.

  4. Set the following registry value to 31 on the NPS server:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\User Identity Attribute

    This registry setting tells the authenticating server to use the calling number (RADIUS attribute 31, Calling-Station-ID) as the identity of the calling user. The user identity is set to the calling number only when there is no user name being supplied in the connection attempt.

    To always use the calling number as the user identity, set the following registry value to 1 on the authenticating server:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Override User-Name

    However, if you set Override User-Name to 1 and the User Identity Attribute to 31, the authenticating server can only perform ANI/CLI-based authentication. Normal authentication by using authentication protocols such as MS-CHAP, CHAP, and EAP is disabled.

Note

Changes to the registry settings will not take effect until the Routing and Remote Access service or the Network Policy Server service are restarted.

Caution

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

Guest authentication

AD DS includes a user account called Guest, which is disabled by default. If you want to provide unauthenticated access, you can enable the Guest account. With guest authentication, during the authentication process, the user does not provide a user name or password. If unauthenticated access is enabled, by default the Guest account is used as the identity of the caller.

To enable Guest account access, you must do the following:

  1. Enable unauthenticated access on the network access server.

  2. Enable unauthenticated access on the appropriate network policy in NPS.

  3. Enable the Guest account in Active Directory Users and Computers.

  4. Set the network access permission on the Guest account to either Allow access or Control access through NPS Network Policy, depending on your network policy administrative model.

If you want to enable a Guest account that is not named Guest, create a user account and set the remote access permission to either Allow access or Control access through NPS Network Policy. Then, set the following registry value on the authenticating server (either the remote access server or the NPS server) to the name of the account:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Default User Identity

Note

Changes to the registry settings will not take effect until the Routing and Remote Access service or the Network Policy Server service are restarted.

Caution

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


Certificates and NPS

Certificates and NPS

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

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

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

Note

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

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

Certificate types

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

  • CA certificate

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

  • Client computer certificate

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

  • Server certificate

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

  • User certificate

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

Certificate-based authentication methods

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

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

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

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

Note

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

Understanding authentication with certificates

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

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

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

How trust is established

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

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

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

Important

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

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

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

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

Private CAs

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

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

Note

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

Required certificates

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

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

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

Enrolling certificates to domain and non-domain member computers

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

Domain member certificate enrollment

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

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

Note

Computers running Windows 2000 can autoenroll computer certificates only.

Non-domain member certificate enrollment

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

  • An administrator (who is, by definition, trusted) must request a computer or user certificate using the CA Web enrollment tool.

  • An administrator must save a computer or user certificate to a floppy disk and install it on the non-domain member computer. Or, when the computer is not accessible to the administrator (for example, a home computer connecting to an organization network with an L2TP/IPsec VPN connection), a domain user whom the administrator trusts can install the certificate.

  • An administrator can distribute a user certificate on a smart card (computer certificates are not distributed on smart cards).

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

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

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

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

  • Windows Server 2003, Enterprise Edition

  • Windows Server 2003, Datacenter Edition

  • Windows Server 2003, Enterprise Edition for Itanium-based Systems

  • Windows Server 2003, Datacenter Edition for Itanium-based Systems

  • Windows Server 2003, Enterprise x64 Edition

  • Windows Server 2003, Datacenter x64 Edition

  • Windows Server 2008

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

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

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

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

  1. In Certificate Templates, select the template RAS and IAS server, and then add the NPS server to the template Security properties.

  2. After you have added your NPS server to the ACL, grant Read, Enroll, and Auto-enroll permissions.
To manage a group of servers, add the servers to a new global or universal group, and then add the group to the ACL of the certificate template

  1. In Active Directory Users and Computers, create a new global or universal group for NPS servers.

  2. Add to the group all computers that are NPS servers, are not domain controllers, and are members of a domain with a Windows 2000 mixed functional level.

  3. In Certificate Templates, select the RAS and IAS server template, and then add the group you created to the template Security properties.

  4. Grant Read, Enroll, and Auto-enroll permissions.

See Also

  • Certificate Deployments and Active Directory Replication
  • Certificate Requirements for PEAP and EAP
  • EAP Overview
  • PEAP Overview
  • NPS CRL Checks


Certificate Deployments and Active Directory Replication

Certificate deployments and Active Directory replication

Some authentication methods, such as PEAP and EAP when configured with certificate-based authentication types, can use certificates for authentication of computers and users. Latency in Active Directory® replication might temporarily affect the ability of a client or server to obtain a certificate from a certification authority (CA). If a computer configured to use certificates for authentication cannot enroll a certificate, authentication fails.

This latency in Active Directory replication can affect your network access authentication infrastructure because the certificates used for client and server authentication are issued by CAs to domain member computers. In the moments after you have joined a client or server computer to the domain, it is possible that the only Active Directory global catalog server that has a record of the client or server computer's domain membership is the domain controller that handled the join request.

After a computer is joined to the domain, you must reboot the computer. After the computer starts and you log on to the domain, Group Policy is applied. If you have previously configured the autoenrollment of client computer certificates or, for NPS servers, server certificates, this is the moment at which the new domain member computer requests a certificate from a CA.

Note

You can manually refresh Group Policy by logging on to the domain or by running the gpupdate command.

The CA, in turn, checks Active Directory Domain Services (AD DS) to determine whether it should issue a certificate to the client or server that has requested it. If the computer account has replicated across the domain, the CA can determine whether the client or server has the security permissions required to enroll a certificate. If the computer account has not replicated across the domain, however, the CA might not be able to verify that the client or server has the security permissions to enroll a certificate.

If this occurs, the CA does not enroll a certificate to the client or server computer.

  • If a domain member client computer cannot enroll a client computer certificate, the client computer cannot be successfully authenticated by NPS servers when attempting to connect to the network through any network access servers that are configured as RADIUS clients in NPS where the required authentication method is either EAP-TLS or PEAP-TLS. For example, if you have deployed RADIUS clients that are 802.1X wireless access points and you are using PEAP-TLS as your authentication method, client computers that do not have a client computer certificate cannot be successfully authenticated and cannot use network resources through a wireless connection.

  • If a domain member NPS server computer cannot enroll a server certificate, the NPS server cannot be successfully authenticated by client computers when they are attempting to connect to the network through any network access servers that are configured as RADIUS clients in NPS where the required authentication method is EAP-TLS, PEAP-TLS, or PEAP-MS-CHAP v2, and where clients are configured with the Validate server certificate setting enabled. These authentication methods provide mutual authentication and the NPS server must have a server certificate to be successfully authenticated by client computers. If the NPS server does not have a server certificate, all connection requests where these authentication methods are required fail because client computers are unable to authenticate the NPS server.

For this reason, when you deploy certificate-based authentication methods, it is recommended that you design Active Directory replication times and the deployment of subordinate CAs to reduce the possibility that slow replication might negatively impact your network access authentication infrastructure.


Certificate Requirements for PEAP and EAP

Certificate requirements

All certificates that are used for network access authentication with EAP-TLS and PEAP must meet the requirements for X.509 certificates and work for connections that use Secure Sockets Layer-Transport Level Security (SSL/TLS). Both client and server certificates have additional requirements.

Minimum server certificate requirements

Clients can be configured to validate server certificates by using the Validate server certificate option. With PEAP-MS-CHAP v2, PEAP-TLS, or EAP-TLS as the authentication method, the client accepts the authentication attempt of the server when the certificate meets the following requirements:

  • The Subject name contains a value. If you issue a certificate to your NPS server that has a blank Subject, 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 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 NPS or VPN server computer certificate is configured with the Server Authentication purpose in 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 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.

With 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

EAP and NPS

Extensible Authentication Protocol (EAP) extends Point-to-Point Protocol (PPP) by allowing arbitrary authentication methods that use credential and information exchanges of arbitrary lengths. EAP was developed in response to demand for authentication methods that use security devices, such as smart cards, token cards, and crypto calculators. EAP provides an industry-standard architecture for supporting additional authentication methods within PPP.

By using EAP, you can support additional authentication schemes, known as EAP types. These schemes include token cards, one-time passwords, public key authentication using smart cards, and certificates. EAP, in conjunction with strong EAP types, is a critical technology component for secure virtual private network (VPN) connections, 802.1X wired connections, and 802.1X wireless connections. Both the network access client and the authenticator, such as the NPS server, must support the same EAP type for successful authentication to occur.

Important

Strong EAP types, such as those based on certificates, offer better security against brute-force or dictionary attacks and password guessing than password-based authentication protocols, such as CHAP or MS-CHAP.

With EAP, an arbitrary authentication mechanism authenticates a remote access connection. The authentication scheme to be used is negotiated by the remote access client and the authenticator (either the network access server or the Remote Authentication Dial-In User Service [RADIUS] server). Routing and Remote Access includes support for EAP-TLS and MD5-Challenge by default. You can plug in other EAP modules to the server running Routing and Remote Access to provide other EAP methods.

EAP allows for an open-ended conversation between the remote access client and the authenticator. The conversation consists of authenticator requests for authentication information and the responses by the remote access client. For example, when EAP is used with security token cards, the authenticator can separately query the remote access client for a name, PIN, and card token value. As each query is asked and answered, the remote access client passes through another level of authentication. When all questions have been answered satisfactorily, the remote access client is authenticated.

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

EAP infrastructure

EAP is a set of internal components that provide architectural support for any EAP type in the form of a plug-in module. For successful authentication, both the remote access client and authenticator must have the same EAP authentication module installed. You can also install additional EAP types. The components for an EAP type must be installed on every network access client and every authenticator.

Note

The Windows Server 2003 operating systems provide two EAP types: MD5-Challenge and EAP-TLS. MD5-Challenge is not supported in Windows Server 2008.

EAP-TLS

EAP-Transport Level Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. If you are using smart cards for remote access authentication, you must use the EAP-TLS authentication method. The EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and encrypted key determination between the remote access client and the authenticator. EAP-TLS provides the strongest authentication and key determination method.

Note

During the EAP-TLS authentication process, shared secret encryption keys for Microsoft Point-to-Point Encryption (MPPE) are generated.

EAP-TLS is supported only on servers that are running Routing and Remote Access, that are configured to use Windows Authentication or RADIUS, and that are members of a domain. A network access server running as a standalone server or a member of a workgroup does not support EAP-TLS.

Using RADIUS as a transport for EAP

Using RADIUS as a transport for EAP is the passing of EAP messages of any EAP type by a RADIUS client to a RADIUS server for authentication. For example, for a network access server that is configured for RADIUS authentication, the EAP messages sent between the remote access client and network access server are encapsulated and formatted as RADIUS messages between the network access server and the RADIUS server. When you use EAP over RADIUS, it is called EAP-RADIUS.

EAP-RADIUS is used in environments where RADIUS is used as the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each network access server, only at the RADIUS server. In the case of an NPS server, you only need to install EAP types on the NPS server.

In a typical use of EAP-RADIUS, a server running Routing and Remote Access is configured to use EAP and to use an NPS server for authentication. When a connection is made, the remote access client negotiates the use of EAP with the network access server. When the client sends an EAP message to the network access server, the network access server encapsulates the EAP message as a RADIUS message and sends it to its configured NPS server. The NPS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the network access server. The network access server then forwards the EAP message to the remote access client. In this configuration, the network access server is only a pass-through device. All processing of EAP messages occurs at the remote access client and the NPS server.

Routing and Remote Access can be configured to authenticate locally, or to a RADIUS server. If Routing and Remote Access is configured to authenticate locally, all EAP methods will be authenticated locally. If Routing and Remote Access is configured to authenticate to a RADIUS server, all EAP messages will be forwarded to the RADIUS server with EAP-RADIUS.

Enabling EAP

To enable EAP-based authentication

  1. Enable EAP as an authentication protocol on the network access server. For more information, see your network access server documentation.

  2. Enable EAP and, if needed, configure the EAP type to the constraints on the appropriate network policy. For more information, see Add a Constraint to a Network Policy.

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

See Also

  • NPS CRL Checks
  • NPS CRL Check Registry Settings


PEAP Overview

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

PEAP and NPS

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 does not specify an authentication method, but provides additional security for other EAP authentication protocols, such as EAP-MSCHAP v2, that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for access clients connecting to your organization network through the following types of network access servers:

  • 802.1X wireless access points

  • 802.1X authenticating switches

  • Computers running Windows Server® 2008 and Routing and Remote Access configured as virtual private network (VPN) servers

  • Computers running Windows Server 2008 and Terminal Services Gateway (TS 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 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. 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 machine-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 with password-based credentials (user name and password) instead of certificates or smart cards. Only the NPS 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 your organization's trusted root CA or 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 new PEAP authenticator's TLS handle 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.

See Also

  • NPS CRL Checks
  • NPS CRL Check Registry Settings


NPS CRL Checks

NPS CRL checks

By default, the server running Network Policy Server (NPS) checks for certificate revocation for all of the certificates in the certificate chain sent by the client computer during the EAP-TLS and PEAP-TLS authentication process. If certificate revocation fails for any of the certificates in the chain, the connection attempt is not authenticated and is denied.

Certificate revocation checking behavior for NPS can be modified with registry settings. For more information, see NPS CRL Check Registry Settings.

Because certificate revocation checking can prevent client access due to the unavailability or expiration of certificate revocation lists (CRLs) for each certificate in the certificate chain, design your public key infrastructure (PKI) for high availability of CRLs. For example, configure multiple CRL distribution points for each certification authority (CA) in the certificate hierarchy and configure publication schedules that ensure that the most current CRL is always available.

Certificate revocation checking is only as accurate as the last published CRL. For example, if a certificate is revoked, by default the new CRL containing the newly revoked certificate is not automatically published. CRLs are typically published based on a schedule that can be configured. This means that the revoked certificate can still be used to authenticate because the published CRL is not current; it does not contain the revoked certificate and can therefore still be used to create wireless connections. To prevent this from occurring, the network administrator must manually publish the new CRL with the newly revoked certificate.

By default, the NPS server uses the CRL distribution points in the certificates. However, it is also possible to store a local copy of the CRL on the NPS server. In this case, the local CRL is used during certificate revocation checking. If a new CRL is manually published to Active Directory® Domain Services (AD DS), the local CRL on the NPS server is not updated. The local CRL is updated when it expires. This can create a situation wherein a certificate is revoked, the CRL is manually published, but the NPS server still allows the connection because the local CRL has not yet been updated.

Important

When using certificates for computer-level or user-level network access authentication, ensure that the CRLs are published in a primary and at least one secondary location that are accessible by all computers, especially all NPS and other RADIUS servers. If the NPS-RADIUS servers attempt to perform CRL validation of the user or computer certificate, but cannot locate the CRLs, the NPS RADIUS servers reject all certificate-based connection attempts and authentication fails.

The certificate revocation check for a certificate can fail for the following reasons.

  • The certificate has been revoked.

  • The CRL for the certificate cannot be reached or is not available.

    CAs maintain CRLs and publish them to CRL distribution points. The CRL distribution points are included in the CRL Distribution Points property of the certificate. If the CRL distribution points cannot be contacted to check for certificate revocation, then the certificate revocation check fails.

    Additionally, if there are no CRL distribution points in the certificate, the NPS server cannot verify that the certificate has not been revoked and the certificate revocation check fails.

  • The publisher of the CRL did not issue the certificate.

    Included in the CRL is the publishing CA. If the publishing CA of the CRL does not match the issuing CA for the certificate for which certificate revocation is being checked, then the certificate revocation check fails.

  • The CRL is not current.

    Each published CRL has a range of valid dates. If the CRL Next update date has passed, the CRL is considered invalid and the certificate revocation check fails. New CRLs should be published before the expiration date of the last published CRL.


NPS CRL Check Registry Settings

NPS CRL check registry settings

You can use the following registry settings to change the way Network Policy Server (NPS) performs certificate revocation list (CRL) checks when EAP-TLS is used.

Caution

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

All of the listed registry settings can be configured on NPS servers with the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13

Important

All of the following registry settings must be added as a DWORD type and have the valid values of 0 or 1.

IgnoreNoRevocationCheck

When set to 1, NPS allows EAP-TLS clients to connect even when NPS does not perform or cannot complete a revocation check of the certificate chain (excluding the root certificate) of the client. Typically, revocation checks fail because the certificate does not include CRL information.

IgnoreNoRevocationCheck is set to 0 (disabled) by default. An EAP-TLS client cannot connect unless the server completes a revocation check of the certificate chain (including the root certificate) of the client and verifies that none of the certificates has been revoked.

You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as might be the case with certificates issued by non-Microsoft certification authorities (CAs).

IgnoreRevocationOffline

When set to 1, NPS allows EAP-TLS clients to connect even when a server that stores a CRL is not available on the network.

IgnoreRevocationOffline is set to 0 by default. With this default setting, NPS does not allow clients to connect unless it can complete a revocation check of their certificate chain and verify that none of the certificates is revoked. When NPS cannot connect to a server that stores a revocation list, the certificate fails the revocation check and authentication fails.

Setting IgnoreRevocationOffline to 1 prevents certificate validation failure because poor network conditions prevented NPS from successfully completing a revocation check.

NoRevocationCheck

When set to 1, NPS prevents EAP-TLS from performing a revocation check of the certificate of the client. The revocation check verifies that the certificate of the client and the certificates in its certificate chain have not been revoked. NoRevocationCheck is set to 0 by default.

NoRootRevocationCheck

When set to 1, NPS prevents EAP-TLS from performing a revocation check of the root CA certificate of the client.

NoRootRevocationCheck is set to 0 by default. This entry only eliminates the revocation check of the root CA certificate of the client. A revocation check is still performed on the remainder of the certificate chain of the client.

You can use this entry to authenticate clients when the certificate does not include CRL distribution points. Also, this entry can prevent certification-related delays that occur when a certificate revocation list is offline or expired.


Deploying Certificates for PEAP and EAP

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 a CA and NPS Server Certificate

  • Deploy Client Computer Certificates

  • Deploy User Certificates


Deploy Client Computer Certificates

Deploy client computer certificates

You can use this procedure to configure the certificate template that Active Directory® Certificate Services (AD CS) uses as the basis for computer certificates that are enrolled to domain member client computers.

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

To configure the certificate template and auto-enrollment

  1. On the computer where Active Directory Certificate Services is installed, click Start, click Run, type mmc, and then click OK.

  2. On the File menu, click Add/Remove Snap-in, and then click Add. The Add or Remove Snap-ins dialog box opens.

  3. In Available snap-ins, double-click Certification Authority. Select the CA that you want to manage with the snap-in, and then click Finish. The Certification Authority dialog box closes, returning to the Add or Remove Snap-ins dialog box.

  4. In Available snap-ins, double-click Certificate Templates, and then click OK.

  5. In the console tree, click Certificate Templates. All of the certificate templates are displayed in the details pane.

  6. In the details pane, click the Workstation Authentication template.

  7. On the Action menu, click Duplicate Template. The Duplicate Template dialog box opens. Select the template version appropriate for your deployment, and then click OK. The new template properties dialog box opens.

  8. On the General tab, in Display Name, type a new name for the certificate template or keep the default name. Select the Publish Certificate in Active Directory check box.

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

  10. In Permissions for Domain Computers, under Allow, select the Enroll and Autoenroll permission check boxes, and then click OK.

  11. Double-click Certification Authority, double-click the CA name, and then click Certificate Templates. On the Action menu, point to New, and then click Certificate Template to Issue. The Enable Certificate Templates dialog opens.

  12. Click the name of the certificate template you just configured, and then click OK. For example, if you did not change the default certificate template name, click Copy of Workstation Authentication, and then click OK.

  13. On the computer where Active Directory Domain Services (AD DS) is installed, click Start, click Run, type mmc, and then click OK.

  14. On the File menu, click Add/Remove Snap-in, and then click Add. The Add or Remove Snap-ins dialog opens.

  15. In Available snap-ins, double-click Group Policy Management Console. The Select Group Policy Object wizard opens. Click Browse, and then select the appropriate Group Policy object (the default object is Default Domain Policy). Click OK, click Finish, and then click OK again.

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

  17. Double-click Certificate Services Client - Auto-Enrollment. The Properties dialog box opens.

  18. In the Properties dialog box, in Configuration Model, select Enabled.

  19. Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box.

  20. Select the Update certificates that use certificate templates check box, and then click OK.

Additional considerations

After you complete this procedure, domain member client computers automatically enroll a client computer certificate when Group Policy is refreshed. To refresh Group Policy, reboot the client computer or, at the command prompt, run gpupdate.


Deploy User Certificates

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 domain users.

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

To configure the certificate template and auto-enrollment

  1. On the computer where Active Directory Certificate Services is installed, click Start, click Run, type mmc, and then click OK.

  2. On the File menu, click Add/Remove Snap-in, and then click Add. The Add or Remove Snap-ins dialog box opens.

  3. In Available snap-ins, double-click Certification Authority. Select the certification authority (CA) that you want to manage with the snap-in, and then click Finish. The Certification Authority dialog box closes, returning to the Add or Remove Snap-ins dialog box.

  4. In Available snap-ins, double-click Certificate Templates, and then click OK.

  5. In the console tree, click Certificate Templates. All of the certificate templates are displayed in the details pane.

  6. In the details pane, click the 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. Select the Publish Certificate in Active Directory check box.

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

  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 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, and then click Add. 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 Console. The Select Group Policy Object wizard opens. Click Browse, and then select the appropriate Group Policy object (for example, Default Domain Policy). Click OK, click Finish, and then click OK again.

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

  17. Double-click Certificate Services Client - Auto-Enrollment. The Certificate Services Client - Auto-Enrollment Properties dialog box opens.

  18. On the Define Policy Settings tab, 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, reboot 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

Deploy a CA and NPS server certificate

You can use these procedures to install Active Directory® Certificate Services (AD CS) and enroll a server certificate to servers running Network Policy Server (NPS). If you deploy certificate-based authentication, servers running NPS must have a server certificate. During the authentication process, these servers send their server certificate to client computers as proof of identity.

The process of configuring NPS server certificate enrollment occurs in three stages:

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

  • Configure a server certificate template and autoenrollment. The CA issues certificates based on a certificate template, so you must configure the template for the NPS server certificate before the CA can issue a certificate. When you configure autoenrollment, all servers running NPS on your network will automatically receive a server certificate when Group Policy on the server running NPS is refreshed. If you add more servers later, they will automatically receive a server certificate, too.

  • Refresh Group Policy on servers running NPS. When Group Policy is refreshed, the servers running NPS receive two certificates. One certificate is the server certificate based on the template that you configured in the previous step. This certificate is used by NPS to prove its identity to client computers that attempt to connect to your network. The other certificate is the CA's certificate, which is automatically installed on the servers running NPS in the Trusted Root Certification Authorities certificate store. NPS uses this certificate to determine whether to trust certificates it receives from other computers. For example, if you deploy EAP-TLS, client computers use a certificate to prove their identities to the server running NPS. When the server receives a certificate from a client computer, trust for the certificate is established because the server running NPS finds the issuing CA certificate in its own Trusted Root Certification Authorities certificate store.

Rather than autoenrolling an NPS server certificate, you might want to enroll the certificate using one of the following methods:

  • Manually import a NPS server certificate from floppy disk or compact disc into the NPS certificate store.

  • Use the Certificate Services Web enrollment tool to obtain the NPS server certificate.

Because the NPS server certificate is a computer certificate, you must import the certificate into the certificate store for the Local Computer rather than for the Current User.

Caution

If the NPS server certificate is erroneously installed in the Current User certificate store, NPS cannot use the certificate for PEAP or EAP authentication because the certificate's private keys have an incorrectly configured access control list (ACL) that prevents key access by the local system. You can verify the location of the NPS server certificate by using the Certificates MMC snap-in. If the NPS server certificate is in the incorrect location, do not attempt to drag and drop the certificate from the Current User to the Local Computer certificate store. The private keys for the certificate will still have an incorrectly configured ACL. Instead, revoke the certificate using AD CS and issue a new server certificate to the server running NPS.

To deploy a CA and autoenroll NPS server certificates, perform the following procedures:

  • NPS Server Certificate: CA Installation

  • NPS Server Certificate: Configure the Template and Autoenrollment


NPS Server Certificate: CA Installation

CA installation

You can use this procedure to install Active Directory® Certificate Services (AD CS) so that you can enroll a server certificate to servers running Network Policy Server (NPS). If you deploy certificate-based authentication, NPS servers must have a server certificate. During the authentication process, NPS servers send their server certificate to client computers as proof of identity.

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

To install Active Directory Certificate Services

  1. Log on as a member of both the Enterprise Admins group and the root domain's Domain Admins group.

  2. Click Start, and then click Server Manager. The Server Manager console opens. In Roles Summary, click Add roles.

  3. The Add Roles wizard opens. Click Next.

  4. On the Select Server Roles page, in Roles, select Active Directory Certificate Services, and then click Next twice.

  5. On the Select Role Services page, in Role services, click Certification Authority, and then click Next.

  6. On the Specify Setup Type page, click Enterprise, and then click Next.

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

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

  9. On the Configure Cryptography for CA page, keep the default settings, and then click Next.

  10. On the Configure CA Name page, keep the suggested common name for the CA or change the name according to your requirements, and then click Next.

  11. On the Set Validity Period page, in Select validity period for the certificate generated for this CA, type the number and select the time value (Years, Months, Weeks, or Days) that determines the date upon which certificates issued by the CA will expire. The default setting of five years is recommended. Click Next.

  12. On the Configure Certificate Database page, in Certificate database location and Certificate database log location, specify the folder location for these items. If you specify locations other than the default locations, ensure that the folders are secured with access control lists (ACLs) that prevent unauthorized users or computers from accessing the CA database and log files. Click Next, and then click Finish.


NPS Server Certificate: Configure the Template and Autoenrollment

Configure the server certificate template and autoenrollment

You can use this procedure to configure the certificate template that Active Directory® Certificate Services (AD CS) uses as the basis for server certificates enrolled to servers running Network Policy Server (NPS).

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

To configure the certificate template and auto-enrollment

  1. On the computer where Active Directory Certificate Services is installed, click Start, click Run, type mmc, and then click OK.

  2. On the File menu, click Add/Remove Snap-in, and then click Add. The Add or Remove Snap-ins dialog box opens.

  3. In Available snap-ins, double-click Certification Authority. Select the CA that you want to manage, and then click Finish. The Certification Authority dialog box closes, returning to the Add or Remove Snap-ins dialog box.

  4. In Available snap-ins, double-click Certificate Templates, and then click OK.

  5. In the console tree, click Certificate Templates. All of the certificate templates are displayed in the details pane.

  6. In the details pane, click the RAS and IAS Server template.

  7. On the Action menu, click Duplicate Template. In the Duplicate Template dialog box, select the template version appropriate for your deployment, and then click OK. The new template properties dialog box opens.

  8. On the General tab, in Display Name, type a new name for the certificate template or keep the default name. Select the Publish Certificate in Active Directory check box.

  9. Click the Security tab. In Group or user names, click RAS and IAS servers.

  10. In Permissions for RAS and IAS servers, under Allow, select the Enroll and Autoenroll permission check boxes, and then click OK.

  11. Double-click Certification Authority, double-click the CA name, and then click Certificate Templates. On the Action menu, point to New, and then click Certificate Template to Issue.

  12. Click the name of the certificate template you just configured, and then click OK. For example, if you did not change the default certificate template name, click Copy of RAS and IAS Server, and then click OK.

  13. On the computer where Active Directory Domain Services is installed, click Start, click Run, type mmc, and then click OK.

  14. On the File menu, click Add/Remove Snap-in, and then click Add. The Add or Remove Snap-ins dialog box opens.

  15. In Available snap-ins, double-click Group Policy Management Console. The Select Group Policy Object wizard opens. Click Browse, and then select the appropriate Group Policy object (the default object is Default Domain Policy). Click OK, click Finish, and then click OK again.

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

  17. Double-click Certificate Services Client - Auto-Enrollment. The Properties dialog box opens.

  18. In Configuration Model, select Enabled.

  19. Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box.

  20. Select the Update certificates that use certificate templates check box, and then click OK.

Additional considerations

After you complete this procedure, servers running NPS automatically enroll a server certificate when Group Policy is refreshed. To refresh Group Policy, reboot the server or, at the command prompt, run gpupdate.

See Also

  • NPS Server Certificate: CA Installation


RADIUS Accounting

RADIUS accounting

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

  • Event logging.

    Used primarily for auditing and troubleshooting connection attempts.

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

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

See Also

  • NPS Events and Event Viewer
  • Configure Log File Properties
  • Configure SQL Server Logging in NPS


Configure Log File Properties

Configure log file properties

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 the log files where 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 you are administering a server running NPS remotely, you cannot browse the directory structure. If you need to log accounting information to a remote server, specify the log file name by typing a Universal Naming Convention (UNC) name, such as \\MyLogServer\LogShare.

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

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.

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

To configure log file properties using the Windows interface

  1. Open the Network Policy Server MMC snap-in.

  2. In the console tree, click Accounting.

  3. In the details pane, in Local File Logging, click Configure Local File Logging. The Local File Logging dialog box opens.

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

  5. In Format, click Database-compatible. Or, to keep your log files in IAS format, click IAS.

  6. 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).

  7. To configure NPS to automatically delete log files when the disk is full, click When disk is full delete older log files. 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 RADIUS accounting data to a local or remote database running Microsoft® SQL Server™.

Configure SQL Server logging in NPS

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 using the Windows interface

  1. Open the Network Policy Server MMC snap-in.

  2. In the console tree, click Accounting.

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

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

    • To log all accounting requests, click Accounting requests.

    • To log authentication requests, click Authentication requests.

    • 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 database, type a number in Maximum number of concurrent sessions.

  6. To configure the SQL Server data source, 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 the server running NPS and the computer running SQL Server, click Test Connection.


NPS Events and Event Viewer

NPS events and Event Viewer

Using the event logs in Event Viewer, you can monitor Network Policy Server (NPS) errors and other events that you configure NPS to record.

NPS records connection request failure events in the System and Security event logs by default. Connection request failure events consist of requests that are rejected or discarded by NPS. Other NPS authentication events are recorded in the Event Viewer system log on the basis of the settings that you specify in the NPS snap-in. Some events that might contain sensitive data are recorded in the Event Viewer security log.

Connection request failure events

Although NPS records connection request failure events by default, you can change the configuration according to your logging needs.

Connection requests are rejected or ignored for a variety of reasons, including the following:

  • The RADIUS message is not formatted according to RFCs 2865 or 2866.

  • The RADIUS client is unknown.

  • The RADIUS client has multiple IP addresses and sent the request on an address other than the one defined in NPS.

  • The shared secret is invalid.

  • The message authenticator (also known as a digital signature) sent by the client is invalid.

  • NPS was unable to locate the user name's domain.

  • NPS was unable to connect to the user name's domain.

  • NPS was unable to access the user account in the domain.

When NPS rejects a connection request, the information in the event text includes the user name, access server identifiers, the authentication type, the name of the first matching network policy, the reason for the rejection, and other information.

Connection request success events

Although NPS records connection request success events by default, you can change the configuration according to your logging needs.

When NPS accepts a connection request, the information in the event text includes the user name, access server identifiers, the authentication type, and the name of the first matching network policy.

Caution

Logging connection request successes can result in the recording of large volumes of data. If you choose to log successful connection request events, use event logging options in Event Viewer to manage the Event Viewer logs.

Logging Schannel events

Secure channel (Schannel) is a security support provider (SSP) that supports a set of Internet security protocols, such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS). These protocols provide identity authentication and secure, private communication through encryption.

Logging of client certificate validation failures is a secure channel event, and is not enabled on the server running NPS by default. You can enable additional secure channel events by changing the following registry key value from 1 (REG_DWORD type, data 0x00000001) to 3 (REG_DWORD type, data 0x00000003):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging

Caution

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


Configure NPS Event Logging

Use this procedure to configure Network Policy Server (NPS) to record connection request failure and success events in the Event Viewer system log.

Configure NPS event logging

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

To configure NPS event logging using the Windows interface

  1. Open the Network Policy Server (NPS) snap-in.

  2. Right-click NPS (Local), and then click Properties.

  3. On the General tab, select each required option, and then click OK.


RADIUS Clients

RADIUS clients

A network access server (NAS) is a device that provides some level of access to a larger network. A NAS using a RADIUS infrastructure is also a RADIUS client, sending connection requests and accounting messages to a RADIUS server for authentication, authorization, and accounting.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

To deploy NPS as a RADIUS server, a RADIUS proxy, or a Network Access Protection (NAP) policy server, you must configure RADIUS clients in NPS.

RADIUS client examples

Examples of network access servers are:

  • Network access servers that provide remote access connectivity to an organization network or the Internet. An example is a computer running the Windows Server® 2008 operating system and the Routing and Remote Access service that provides either traditional dial-up or virtual private network (VPN) remote access services to an organization intranet.

  • Wireless access points that provide physical layer access to an organization network using wireless-based transmission and reception technologies.

  • Switches that provide physical layer access to an organization's network, using traditional LAN technologies, such as Ethernet.

  • RADIUS proxies that forward connection requests to RADIUS servers that are members of a remote RADIUS server group that is configured on the RADIUS proxy.

RADIUS Access-Request messages

RADIUS clients either create RADIUS Access-Request messages and forward them to a RADIUS proxy or RADIUS server, or they forward Access-Request messages to a RADIUS server that they have received from another RADIUS client but have not created themselves.

RADIUS clients do not process Access-Request messages by performing authentication, authorization, and accounting. Only RADIUS servers perform these functions.

NPS, however, can be configured as both a RADIUS proxy and a RADIUS server simultaneously, so that it processes some Access-Request messages and forwards other messages.

NPS as a RADIUS client

NPS acts as a RADIUS client when you configure it as a RADIUS proxy to forward Access-Request messages to other RADIUS servers for processing. When you use NPS as a RADIUS proxy, the following general configuration steps are required:

  1. Network access servers, such as wireless access points and VPN servers, are configured with the IP address of the NPS proxy as the designated RADIUS server or authenticating server. This allows the network access servers, which create Access-Request messages based on information they receive from access clients, to forward messages to the NPS proxy.

  2. The NPS proxy is configured by adding each network access server as a RADIUS client. This configuration step allows the NPS proxy to receive messages from the network access servers and to communicate with them throughout authentication. In addition, connection request policies on the NPS proxy are configured to specify which Access-Request messages to forward to one or more RADIUS servers. These policies are also configured with a remote RADIUS server group, which tells NPS where to send the messages it receives from the network access servers.

  3. The NPS or other RADIUS servers that are members of the remote RADIUS server group on the NPS proxy are configured to receive messages from the NPS proxy. This is accomplished by configuring the NPS proxy as a RADIUS client.

RADIUS client properties

When you add a RADIUS client to the NPS configuration through the NPS snap-in or through the use of the netsh commands for NPS, you are configuring NPS to receive RADIUS Access-Request messages from either a network access server or a RADIUS proxy.

When you configure a RADIUS client in NPS, you can designate the following properties:

  • Client name

    A friendly name for the RADIUS client, which makes it easier to identify when using the NPS snap-in or netsh commands for NPS.

  • IP address

    The Internet Protocol version 4 (IPv4) address or the Domain Name System (DNS) name of the RADIUS client.

  • Client-Vendor

    The vendor of the RADIUS client. Otherwise, you can use the RADIUS standard value for Client-Vendor.

  • Shared secret

    A text string that is used as a password between RADIUS clients, RADIUS servers, and RADIUS proxies. When the Message Authenticator attribute is used, the shared secret is also used as the key to encrypt RADIUS messages. This string must be configured on the RADIUS client and in the NPS snap-in.

  • Message Authenticator attribute

    Described in RFC 2869, "RADIUS Extensions," a Message Digest 5 (MD5) hash of the entire RADIUS message. If the RADIUS Message Authenticator attribute is present, it is verified. If it fails verification, the RADIUS message is discarded. If the client settings require the Message Authenticator attribute and it is not present, the RADIUS message is discarded. Use of the Message Authenticator attribute is recommended.

    Note

    The Message Authenticator attribute is required and enabled by default when you use EAP authentication.

  • Client is NAP-capable

    A designation that the RADIUS client is compatible with Network Access Protection (NAP), and NPS sends NAP attributes to the RADIUS client in the Access-Accept message.


Add a New RADIUS Client

Use this procedure to add a network access server as a RADIUS client in the Network Policy Server (NPS) Microsoft Management Console (MMC) snap-in.

When you configure a network access server (NAS) as a RADIUS client in the NPS MMC snap-in, the RADIUS client forwards connection requests from access clients to the NPS server for authentication, authorization, and accounting.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

In addition to configuring a new RADIUS client, you must also configure the network access server so that it can communicate with NPS. For more information, see your NAS documentation.

To configure a new RADIUS client in NPS, you must run the New RADIUS Client Wizard. While following the steps in the New RADIUS Client Wizard:

  • If your access server supports use of the Message Authenticator attribute (also known as the signature attribute), in the New RADIUS Client Wizard, click Request must contain the Message Authenticator attribute. If the access server does not support the Message Authenticator attribute, do not select this option. Enabling the use of the Message Authenticator attribute provides additional security when PAP, CHAP, MS-CHAP, and MS-CHAP v2 are configured in network policies as authentication methods. EAP uses the Message Authenticator attribute by default and does not require that you enable it.

  • If you use NAS-specific network policies (for example, a network policy that contains vendor-specific attributes), click Client-Vendor, and then select the name of the NAS manufacturer. If you do not know the name of the NAS manufacturer or it is not in the list, select RADIUS Standard.

Note

If NPS receives an access request from a RADIUS proxy, it cannot detect the manufacturer of the NAS that originated the request. This can cause problems if you plan to use network policy conditions that are based on the client vendor and if you have at least one RADIUS client that is a RADIUS proxy. In this case, connection requests that are forwarded to NPS from the RADIUS proxy might not match any of the network policies, causing all connection requests to be denied. For this reason, when you use RADIUS proxies, you must configure at least one network policy that is not based on NAS-specific attributes, such as the vendor-specific attribute.

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

To add a new RADIUS client using the Windows interface

  1. Open the NPS MMC snap-in, and then double-click RADIUS Clients and Servers.

  2. Right-click RADIUS Clients, and then click New RADIUS Client.

  3. Follow the steps in the New RADIUS Client Wizard.


Securing NPS

Securing NPS

Network Policy Server (NPS) assists you with network security by providing strong authentication methods that allow you to authenticate and authorize users and computers. You can use Network Access Protection (NAP) to verify, monitor, and remediate client computer configurations.

In addition to these features, the following topics provide additional information about how to secure NPS.

  • Network Access Quarantine Control

  • NPS and Firewalls

  • Secure RADIUS Traffic with IPsec

  • Security Information for NPS

  • Shared Secrets for NPS and RADIUS Clients

  • Using the Message Authenticator Attribute


NPS and Firewalls

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 over User Datagram Protocol (UDP) ports 1812, 1813, 1645, and 1646, and 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 through the default ports.

  • Create new exceptions that allow RADIUS traffic through 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 another 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 intranet 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 in 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.


Secure RADIUS Traffic with IPsec

Secure RADIUS traffic with IPsec

Internet Protocol security (IPsec) provides you with the ability to secure RADIUS servers against unwanted traffic by filtering on network adapters (allowing or blocking specified protocols) and enabling you to choose source IP addresses from which traffic is allowed. For organizational units, you can create IPsec policies, which are stored in Active Directory® Domain Services (AD DS). Or, you can create local policies on RADIUS servers, and apply these policies to specified computers. If you create IPsec policies for an organizational unit, the policy is applied through Group Policy.

Before you create IPsec filters, determine the type of traffic that you want to allow for each RADIUS server. Filters that are too strict might block acceptable network traffic. For example, if Network Policy Server (NPS) is installed on a domain controller and all IP traffic, except RADIUS traffic, is blocked on all ports, user queries for Active Directory objects on default global catalog port 3268 will fail. Conversely, IP filters that are too general expose the RADIUS server to unwanted traffic.

RADIUS messages are sent with the User Datagram Protocol (UDP). UDP port 1812 is used for RADIUS authentication messages and UDP port 1813 is used for RADIUS accounting messages. When you create inbound and outbound filters with IPsec, UDP traffic must be allowed on these ports. However, some network access servers might use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages. By default, NPS supports both sets of ports. If your network access servers use UDP ports 1645 and 1646, you can create IPsec filters that allow traffic on these ports.


Security Information for NPS

Security information for NPS

Following is security information for Network Policy Server (NPS) and related protocols:

Deployments of PEAP and EAP unprotected by PEAP should not use the same authentication type

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 with EAP-TLS (PEAP-TLS), do not also deploy EAP-TLS without PEAP. Deploying authentication methods with the same type, one with and the other without the protection of PEAP, creates a security vulnerability.

RADIUS User-Password hiding mechanism might not provide sufficient security for passwords

The RADIUS hiding mechanism uses the RADIUS shared secret, the Request Authenticator, and the Message-Digest algorithm 5 (MD5) hashing algorithm to encrypt the User-Password and other attributes, such as Tunnel-Password and MS-CHAP-MPPE-Keys. RFC 2865 notes the potential need for evaluating the threat environment and determining whether additional security should be used.

You can provide additional protection for hidden attributes by using Internet Protocol security (IPsec) with Encapsulating Security Payload (ESP) and an encryption algorithm, such as Triple DES (3DES), to provide data confidentiality for the entire RADIUS message.

Recommendations

Use IPsec to provide additional security for RADIUS clients and servers. For more information, see Secure RADIUS Traffic with IPsec.

If you are using IPsec with ESP and an encryption algorithm is not available, do the following:

  1. Require the use of the Message Authenticator attribute for all Access-Request messages. For more information, see Using the Message Authenticator Attribute.

  2. Use cryptographically strong Request Authenticators.

  3. Require the use of strong user passwords.

  4. Use authentication counting and account lockout to help prevent a dictionary attack against a user password.

  5. Use a long shared secret with a random sequence of letters, numbers, and punctuation. Change it often to help protect your NPS server and your RADIUS clients from dictionary attacks.

Many authentication methods are too weak to provide adequate security for most organizations

Many organizations use authentication methods that expose their network to a variety of security attacks. The most secure method of authentication is Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) when used in conjunction with smart cards. However, EAP-TLS and smart cards require a public key infrastructure (PKI), which can be complicated to deploy.

Recommendations

  • When you use password-based authentication, enforce strong password policies on your network to make dictionary attacks more difficult.

  • Make sure that Password Authentication Protocol (PAP), Shiva Password Authentication Protocol (SPAP), and Challenge Handshake Authentication Protocol (CHAP) are disabled. PAP, SPAP, and CHAP are disabled by default in new NPS network policies.

  • Disable Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). MS-CHAP is enabled by default in network policy. Before you disable MS-CHAP, ensure that all of the clients of your access server are capable of using MS-CHAP version 2 (MS-CHAP v2). If your server is running a version of Windows earlier than Windows Server 2003, you will need the latest service packs and dial-up networking updates in order to support MS-CHAP v2.

  • If you are running earlier versions of Windows and you do not disable MS-CHAP, disable Microsoft LAN Manager authentication for MS-CHAP. LAN Manager authentication for MS-CHAP is enabled by default on clients running earlier versions of Windows. In Windows Server 2008, LAN manager authentication is disabled by default.

  • To disable LAN Manager authentication, set the registry value Allow LM Authentication to 0 at the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy

Caution

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

Remote access account lockout can cause authorized users to be denied network access

If a malicious user attempts a dictionary attack with an authorized user logon name when remote access account lockout is enabled, both the malicious user and the authorized user are locked out of the account until the configured Account lockout threshold is reached.

Recommendations

When the lockout count for a user account is reset to zero, due to either a successful authentication or an automatic reset, the registry subkey for the user account is deleted. To manually unlock a user account (before the Account lockout threshold is automatically reset), you can delete the following registry subkey that corresponds to the user's account name:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\DomainName:UserName

Caution

Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
Additional information
  • Remote access account lockout is not related to the Account locked out setting on the Account tab in the properties of a user account in Active Directory Domain Services (AD DS).

  • With remote access account lockout, there is no distinction between malicious users who attempt to access your intranet and authentic users who attempt remote access but have forgotten or repeatedly incorrectly typed their current passwords. Depending on the number of attempts and the MaxDenials setting in the registry, these users might have their accounts locked.

Moving NPS log files from the default location results in unprotected log files

When NPS logging is enabled, log files are located by default in the %systemroot%\System32\LogFiles folder. By default, the access control list (ACL) on the LogFiles folder provides the best security for the NPS log files. The ACL is a list of users and groups who can access the folder. In addition, each user or group is assigned permissions that determine which actions the user or group can take with the folder.

If you change the location of the NPS log files, however, the new folder location is not protected with the usual ACL by default. This creates a security risk.

Recommendations

  • If you move the NPS log files to another folder, create an ACL that contains only the Local System account and the Administrators group. In addition, ensure that the new log file folder does not inherit permissions from any other folder.

  • Do not store NPS log files in any personal folders, in My Documents, or in any subfolder of My Documents.

  • Store NPS log files on a computer that is physically secured and protected from unauthorized access.

  • Use file-level auditing for individual NPS log files to track the users and groups who access them.

  • Do not move or map the NPS log files to a remote storage device or an external drive for which no ACL can be created. Also, do not move or copy NPS log files to an anonymous FTP site or any other unprotected location.

NPS server log data is sent in plaintext to remote computers running SQL server

If your NPS server is configured to log user authentication and accounting requests to a remote computer running Microsoft® SQL Server™, the log data is sent unencrypted over the network, posing a high security risk.

Recommendations

Establish an encrypted connection at the computer running SQL Server for communication with the NPS server. For more information, see the SQL Server documentation.

For more information about logging NPS data to a SQL Server database, see Configure SQL Server Logging in NPS.


Shared Secrets for NPS and RADIUS Clients

Shared secrets

A shared secret is a text string that serves as a password between:

  • A RADIUS client and RADIUS server.

  • A RADIUS client and a RADIUS proxy.

  • A RADIUS proxy and a RADIUS server.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

For a configuration that uses a RADIUS client, a RADIUS proxy, and a RADIUS server, the shared secret that is used between the RADIUS client and the RADIUS proxy can be different from the shared secret used between the RADIUS proxy and the RADIUS server.

Shared secrets are used to verify that RADIUS messages, with the exception of the Access-Request message, are sent by a RADIUS-enabled device that is configured with the same shared secret. Shared secrets also verify that the RADIUS message has not been modified in transit (message integrity). The shared secret is also used to encrypt some RADIUS attributes, such as User-Password and Tunnel-Password. To provide verification for Access-Request messages, you can enable use of the RADIUS Message Authenticator attribute for both the RADIUS client configured on the server running NPS and the access server.

When creating and using a shared secret:

  • Use the same case-sensitive shared secret on both RADIUS devices.

  • If you specify RADIUS clients by using an IP address range, all RADIUS clients within the address range must use the same shared secret.

  • Use a different shared secret for each RADIUS server-RADIUS client pair.

  • Generate a random sequence at least 22 characters long.

  • Use any standard alphanumeric and special characters.

  • Make the shared secret up to 128 characters in length. To protect your NPS server and your RADIUS clients from brute force attacks, use long shared secrets (more than 22 characters).

  • Make the shared secret a random sequence of letters, numbers, and punctuation and change it often to protect your NPS server and your RADIUS clients from dictionary attacks. Shared secrets should contain characters from each of the following three groups:

Group | Examples
Letters (uppercase and lowercase) | A, B, C and a, b, c
Numerals | 0, 1, 2, 3
Symbols (all characters not defined as letters or numerals) | Exclamation point (!), asterisk (*), colon (:)

The stronger your shared secret, the more secure are the attributes (for example, those used for passwords and encryption keys) that are encrypted with it. An example of a strong shared secret is 8d#>9jq4rV)H7%a3-zM13sW.

Note

When Password Authentication Protocol (PAP) is used between an access client and an access server (a RADIUS client), the access server encrypts the PAP password by using the shared secret and sends it in an Access-Request packet. If the access server sends the Access-Request message to a RADIUS proxy, the RADIUS proxy must first decrypt the PAP password with the shared secret that was used between the RADIUS proxy and the access server. Next, it encrypts the PAP password with the shared secret that was used between the RADIUS proxy and the RADIUS server before forwarding the Access-Request message. Because a malicious user or process at a RADIUS proxy can record user names and passwords for PAP connections after they are decrypted but before they are encrypted, the use of PAP is highly discouraged.


Using the Message Authenticator Attribute

Message Authenticator attribute

When you configure a RADIUS client in Network Policy Server (NPS), you configure the IP address of the client. If an incoming RADIUS Access-Request message does not originate from at least one of the IP addresses of configured clients, NPS discards the message, providing protection for the NPS server. However, source IP addresses can be spoofed.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

To provide protection from spoofed Access-Request messages and RADIUS message tampering, each RADIUS message can be additionally protected with the RADIUS Message Authenticator attribute, which is described in RFC 2869, "RADIUS Extensions."

Enabling the use of the Message Authenticator attribute provides additional security when PAP, CHAP, MS-CHAP, and MS-CHAP v2 are used for authentication. EAP uses the Message Authenticator attribute by default. Therefore, when you use EAP as an authentication method, you do not have to enable the use of the Message Authenticator attribute.

See Also

  • RADIUS Clients


Network Access Quarantine Control

Network Access Quarantine Control

Network Access Quarantine Control (NAQC) in Network Policy Server (NPS) provides phased network access for remote client computers by restricting them to a quarantine mode. After the client computer configuration is either brought into or determined to be in compliance with your organization’s network policy, quarantine restrictions, which consist of Quarantine IP-Filters and Session Timers, are removed and standard network policy is applied to the connection.

Note

Network policy in NPS was referred to as remote access policy in earlier product versions.

NAQC provides protection when users in your organization accidentally reconfigure key settings and do not restore them before connecting to your network. For example, a user might disable antivirus software that is required while connected to your network. Although NAQC does not protect against attackers, computer configurations for authorized users can be verified and, if necessary, corrected before they can access the network. A timer setting is also available, which you can use to specify an interval at which the connection is dropped if the client fails to meet configuration requirements.

You can use the Routing and Remote Access service to process the RADIUS options sent by NPS, complete any required client configuration work, and remove the quarantine condition (or drop the connection) based on success or failure.

Important

Network Access Quarantine Control is not the same as Network Access Protection (NAP).

Quarantine mode

Quarantine mode is a set of network restrictions that are configured in network policy and are implemented by the remote access server for each connection.

Note

You can configure network policy in either the Routing and Remote Access service console or the NPS console, depending on whether you are using NPS for your NAQC deployment.

You can use a Quarantine IP Filter to restrict access to a specified set of servers (for example, servers on a virtual LAN) and a Quarantine Session Timer to restrict the amount of time the client can remain connected in quarantine mode. You can set these filters in the NPS console.

Components of Network Access Quarantine Control

You can implement NAQC with one or more servers running Windows Server 2008 and Routing and Remote Access, one or more servers running Windows Server 2008 and NPS, a Connection Manager (CM) profile created with Connection Manager Administration Kit (CMAK), an administrator-provided script or the file quarchk.cmd, and two additional components: the notifier component and the listener component.

The notifier component is a program named rqc.exe that you can include in a CM profile. The listener component can be configured in the Services MMC snap-in after you install Routing and Remote Access.

Important

NPS is an optional component of NAQC. You can deploy NAQC without NPS if you choose to create network policy in Routing and Remote Access. This is practical if you only have one or two virtual private network (VPN) servers. If you have multiple VPN servers, however, it is recommended that you deploy a server running NPS and configure network policy in NPS. This allows you to configure network policy one time in NPS rather than multiple times, once on each VPN server.

You can add rqc.exe to the CM profile for installation on the client computer when the profile is installed. After the administrator-provided script has run successfully on the client computer, rqc.exe notifies the remote access server.

Note

After you install Routing and Remote Access and CMAK, rqc.exe and quarchk.cmd are located at %systemroot%\Program Files\CMAK\Support.

The listener component, named Remote Access Quarantine Agent service, is included when you install Routing and Remote Access. However, the Remote Access Quarantine Agent service is disabled by default. When you deploy NAQC, you must start the Remote Access Quarantine Agent service and change the startup type to automatic.

Note

To configure the Remote Access Quarantine Agent service, install Routing and Remote Access, and then open the Services MMC snap-in. Browse to and double-click the Remote Access Quarantine Agent service.

The Remote Access Quarantine Agent service receives notification from rqc.exe that either quarchk.cmd or the script on the client has successfully performed all configuration checks. After Remote Access Quarantine Agent service receives notification, it removes the client from quarantine mode, and the remote access server applies standard network policy to the client.

Caution

Placing all remote access clients in quarantine mode without a way to remove quarantine policy and apply full access policy might prevent all remote access clients from establishing network connections.

See Also

  • Network Access Protection in NPS
  • Deploying Network Access Quarantine Control
  • Network Access Quarantine Control and NAP


Deploying Network Access Quarantine Control

Deploying Network Access Quarantine Control

To deploy Network Access Quarantine Control (NAQC), you must complete the following steps:

  • Install and configure Routing and Remote Access as a virtual private network (VPN) server.

  • Install Network Policy Server (NPS) if you have multiple VPN servers. (This step is optional.) Configure all VPN servers as RADIUS clients in NPS, register the NPS server in Active Directory® Domain Services (AD DS), if applicable, and configure Accounting to your requirements. Also, configure VPN servers to forward connection requests to your NPS server. Use an identical shared secret on VPN and NPS servers to allow secure communications between the servers.

  • If you want to customize the checks performed on the client computer, create a client-side script that validates client configuration information. If you do not want to create a client-side script, you can use quarchk.cmd, which is installed on the server when you install Connection Manager Administration Kit (CMAK). Quarchk.cmd is located in the folder %systemroot%\Program Files\CMAK\Support.

  • Create a Connection Manager (CM) profile with CMAK. While running the wizard, enter settings that are appropriate for your deployment and ensure that you take the following steps:

    • On the Add Custom Actions wizard page, in Action type, select Post-connect, and then click New. In New Custom Action, in Description, type a name for the post-connect action.

    • In New Custom Action, in Program to run, click Browse to add either your custom client-side script or quarchk.cmd. To locate quarchk.cmd, in Browse, ensure that All files (*.*) is selected, click quarchk.cmd, and then click Open.

    • In New Custom Action, in Parameters, add the following parameters:

      %ServiceDir% %ServiceName% RASQuarantineConfigPassed %Domain% %USERNAME% 7250

    • Click OK, and continue running the CMAK wizard, configuring settings per your requirements, until you reach the Install Additional Files with the Connection Manager Profile page. Click Add. In Browse, click rqc.exe, and then click Open.

  • Distribute the CM profile for installation on remote access client computers.

  • On VPN servers, start the Remote Access Quarantine Agent service and change the startup type to automatic. This step enables the listener component of NAQC.

  • Configure one quarantine network policy on VPN or NPS servers using the following instructions as a guideline.

Note

The registry key RASQuarantineConfigPassed is located in the RQS entry on the server running Routing and Remote Access at the following registry path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RQS (AllowedSet).

Network policy

On your VPN servers or NPS servers, you must create a quarantine network policy for VPN connections. It is recommended that you grant VPN access to users who are members of an Active Directory group. Therefore, before creating the network policy in NPS or Routing and Remote Access, create a VPN users group in AD DS. When you run the New Network Policy wizard, you can then select the Active Directory group that you created.

The notification and listener components of NAQC use port 7250 by default. When you create the quarantine policy, you must configure Inbound Filters (also called Input Filters) to allow network traffic on port 7250, or the notification component (Rqc.exe), which runs on client computers, cannot notify the remote access server listener component (Remote Access Quarantine Agent service) that the script has run successfully. You can specify another port, but if so, you must also configure the listener and notification components to use this new port.

In addition, you must configure the network policy settings with Quarantine IP Filters or Quarantine Session Timers, depending on your deployment of NAQC.

How the network policy works

When the connection is made from the VPN client to the VPN server, the access server or NPS server compares the connection request to the configured network policies until it finds a policy whose conditions and constraints match the connection request. If conditions do not match, the network policy is not used, and the next network policy is evaluated. If constraints do not match, the connection is rejected.

If the connection request matches the quarantine policy and the user is authenticated and authorized to connect to the network, the access server implements the restrictions (Quarantine IP Filters and Quarantine Session Timers) that exist in the network policy on the access server or that are returned by NPS in the Access-Accept message.

Important

Notification by the client to the server running Routing and Remote Access that the administrator-provided script or quarchk.cmd has run successfully is not secure and can be spoofed by a malicious user. NAQC is intended only to help verify a managed client computer configuration.

See Also

  • Network Access Quarantine Control
  • Network Access Quarantine Control and NAP


Network Access Quarantine Control and NAP

Network Access Quarantine Control and NAP

Network Access Quarantine Control (NAQC) allows you to verify the configuration of client computers that are connecting to a server running Routing and Remote Access only at the moment when the access client is connecting to the network. The configuration of the client computer is verified by a script created by your organization administrator.

Network Access Protection (NAP) is a client health policy creation, enforcement, and remediation technology that is included in Windows Vista® and Windows Server® 2008. With NAP, you can establish health policies that define such things as software requirements, security update requirements, and required configuration settings for computers that connect to your network. The use of NAP rather than NAQC is recommended.

Important

If you deploy both NAP and NAQC on your network, you must create separate network policies. If you configure one network policy with both NAP settings and NAQC attributes, such as a Quarantine IP Filter and a Quarantine Session Timer, NPS applies NAQC settings rather than NAP settings.

The following table lists the differences between NAP and NAQC.

Feature | Available with NAP? | Available with NAQC?
Can deploy with VPN (Routing and Remote Access) | Yes | Yes
Can deploy with Internet Protocol security (IPsec) and Health Registration Authority (HRA) | Yes | No
Can deploy with 802.1X wired and wireless | Yes | No
Can deploy with Terminal Services Gateway (TS Gateway) | Yes | No
Can deploy with DHCP | Yes | No
Provides ongoing monitoring of client computer | Yes | No; client configuration is checked once, when client attempts network access
Provides integrated automatic remediation of noncompliant computers | Yes | No
Requires administrator to write script to check client configuration | No | Yes

See Also

  • Network Access Quarantine Control
  • Deploying Network Access Quarantine Control
  • Network Access Protection in NPS


Vendor-Specific Attributes in NPS

Vendor specific attributes

In addition to the RADIUS standard attributes, which are described in Request for Comments (RFC) 2865 and RFC 2866, you can configure vendor-specific attributes (VSAs) in Network Policy Server (NPS) network policy and connection request policy that are returned to RADIUS clients in RADIUS response messages.

VSAs allow RADIUS client vendors, such as the manufacturers of wireless access points, 802.1X authenticating switches, and devices that act as virtual private network (VPN) servers, to support their own proprietary RADIUS attributes that are not included in the RFCs. NPS includes VSAs from a number of vendors in its dictionary; however, the NPS dictionary does not include VSAs for all vendors.

Some network access server (NAS) manufacturers use VSAs to provide functionality that is not supported in RADIUS standard attributes. NPS enables you to create or edit VSAs to take advantage of proprietary functionality supported by some NAS vendors.

Note

For more information about vendor-specific functionality and the VSAs that you can configure, see your access server documentation.

Before adding a VSA, check the list of attributes in the NPS dictionary. If the required VSA is present, use it. If not, you can add the VSA to the settings of the network policy.

VSA format

If you want to add VSAs to the settings of a network policy, you must first determine whether the VSA conforms to the format that is recommended in RFC 2865. The way in which you add the VSA to the network policy differs, depending on whether the VSA conforms to the RFC.

If the VSA format does conform to the RFC, you must specify:

  • A network access vendor by either name or vendor code.

  • A vendor-assigned attribute number.

  • The attribute format (that is, the type of data, such as string or hexadecimal).

  • The attribute value.

If the VSA format does not conform to the RFC, you must specify:

  • A network access vendor by either name or vendor code.

  • A hexadecimal attribute value that represents the attribute data.

See Also

  • Configure a Custom VSA
  • Custom VSA Example


Configure a Custom VSA

You can use this procedure to create a custom vendor-specific attribute (VSA) that conforms or does not conform to the RADIUS Request For Comments (RFC) specification for vendor-specific attributes.

Note

The RADIUS dictionary of attributes contains many attributes from a variety of vendors. Before creating a custom attribute, verify that the attribute does not already exist in the dictionary of attributes. To view the dictionary, open a network policy, click the Settings tab, and then click either RADIUS Standard or Vendor Specific. To view the attribute list, click Add.

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

Configure a custom VSA

To configure a custom vendor-specific attribute

  1. Open the Network Policy Server console, double-click Policies, and then double-click Network Policies. Double-click the policy to which you want to add a custom VSA. The policy properties dialog box opens.

  2. In policy properties, click Settings, and then click Vendor Specific. In the details pane, click Add. The Add Vendor Specific Attribute dialog box opens.

  3. In Vendor, select Custom, and then click Add. The Attribute Information dialog box opens.

  4. Click Add. The Vendor-Specific Attribute Information dialog box opens. In Specify network access server vendor, choose an item in Select from list, or click Enter Vendor Code, and then type the vendor code supplied by your device manufacturer.

  5. Select whether the custom attribute conforms to the RADIUS RFC by clicking either Yes, it conforms, or No, it does not conform.

  6. Click Configure Attribute. Depending on your selection in the previous step, either the Configure VSA (non-RFC Compliant) or Configure VSA (RFC Compliant) dialog box opens. Configure the VSA using values supplied by your hardware manufacturer.

See Also

  • Vendor-Specific Attributes in NPS
  • Custom VSA Example


Custom VSA Example

Custom VSA example

This topic provides an example of how to configure a custom vendor-specific attribute (VSA) that conforms to the format for vendor-specific attributes (type 26) that is specified in RFC 2865.

The following table lists the values that are used to configure a Cisco VSA to specify a primary DNS server with an IP address of 10.10.10.10.

Information | Description
Vendor ID | This is the unique ID for Cisco. When you select Cisco as the network access server vendor, this ID (9) is automatically supplied.
Cisco-assigned attribute number | This is the vendor-type number (1) for VSAs that take the attribute-value pair form, specified in Cisco documentation as cisco-avpair.
Syntax | If the attribute is mandatory, the syntax is Protocol:Attribute = Value. If the attribute is optional, the attribute-value pair is separated by an asterisk (*) instead of an equal sign (=). In this example, Protocol is a value of the Cisco protocol attribute for a type of authorization. Attribute and Value represent an appropriate attribute/value (AV) pair defined in the Cisco TACACS+ specification. This allows the full set of features available for TACACS+ authorization to be used for RADIUS. The Cisco format, used to specify a primary DNS server, is ip:dns-servers=10.10.10.10.

Configuring the custom VSA

To configure the custom VSA and specify the primary DNS server of 10.10.10.10, configure an RFC-compliant VSA.

To configure the custom VSA

  1. Open the Network Policy Server console, double-click Policies, and then double-click Network Policies. Double-click the policy to which you want to add a custom VSA. The policy properties dialog box opens.

  2. In policy properties, click Settings, and then click Vendor Specific. In the details pane, click Add. The Add Vendor Specific Attribute dialog box opens.

  3. In Vendor, select Custom, and then click Add. The Attribute Information dialog box opens.

  4. Click Add. The Vendor-Specific Attribute Information dialog box opens. In Specify network access server vendor, in Select from list, select Cisco.

  5. In Specify whether the attribute conforms to the RADIUS RFC specification for vendor specific attributes, click Yes, it conforms.

  6. Click Configure Attribute. The Configure VSA (RFC Compliant) dialog box opens.

  7. In Vendor-assigned attribute number, type 1.

  8. In Attribute format, select String.

  9. In Attribute Value, type ip:dns-servers=10.10.10.10.

See Also

  • Vendor-Specific Attributes in NPS
  • Configure a Custom VSA


Network Access Protection in NPS

Network Access Protection in NPS

Network Access Protection (NAP) is a client health policy creation, enforcement, and remediation technology that is included in Windows Vista® and Windows Server® 2008. With NAP, you can establish health policies that define such things as software requirements, security update requirements, and required configuration settings for computers that connect to your network.

NAP enforces health policies by inspecting and assessing the health of client computers, restricting network access when client computers are noncompliant with health policy, and remediating noncompliant client computers to bring them into compliance with health policy before they are granted full network access. NAP enforces health policies on client computers that are attempting to connect to a network; NAP also provides ongoing health compliance enforcement while a client computer is connected to a network.

NAP is an extensible platform that provides an infrastructure and an application programming interface (API) set for adding components to NAP clients and servers running Network Policy Server (NPS) that check a computer's health, enforce network health policy, and remediate noncompliant computers to bring them into compliance with health policy.

By itself, NAP does not provide components to verify or remediate a computer's health. Other components, known as system health agents (SHAs) and system health validators (SHVs), provide client computer health state inspection and reporting, validation of client computer health state compared to health policy, and configuration settings to help the client computer become compliant with health policy.

The Windows Security Health Agent (WSHA) is included in Windows Vista as part of the operating system. The corresponding Windows Security Health Validator (WSHV) is included in Windows Server 2008 as part of the operating system. By using the NAP API set, other products can also implement SHAs and SHVs to integrate with NAP. For example, an antivirus software vendor can use the API set to create a custom SHA and SHV. These components can then be integrated into the NAP solutions that software vendor's customers deploy.

If you are a network or system administrator planning to deploy NAP, you can deploy NAP with the WSHA and WSHV that are included with the operating system. You can also check with other software vendors to find out if they provide SHAs and SHVs for their products.

NAP overview

Most organizations create network policies that dictate the type of hardware and software that can be deployed on the organization network. These policies frequently include rules for how client computers can be configured before connecting to the network. For example, many organizations require that client computers run antivirus software with recent antivirus updates installed, and that client computers have a software firewall installed and enabled before connecting to the organization network. A client computer that is configured according to the organization network policy can be viewed as compliant with policy, while a computer that is not configured according to the organization network policy can be viewed as noncompliant with policy.

NAP allows you to use NPS to create policies that define client computer health. NAP also allows you to enforce the client health policies you create, and to automatically update, or remediate, NAP-capable client computers to bring them into compliance with client health policy. NAP provides continuous detection of client computer health to guard against cases in which a client computer is compliant when it connects to the organization network but becomes noncompliant while connected.

NAP provides complementary client computer and organization network protection by ensuring that computers connecting to the network comply with organization network and client health policies. This protects the network from harmful elements introduced by client computers, such as computer viruses, and it also protects client computers from harmful elements that could be introduced by the network to which it is connecting.

In addition, NAP autoremediation reduces the amount of time that noncompliant client computers are prevented from accessing organization network resources. When autoremediation is configured and clients are in a noncompliant state, NAP client components can rapidly update the computer using resources you supply on a remediation network, allowing the now-compliant client to be more quickly authorized by NPS to connect to the network.

NPS and NAP

NPS provides the ability to act as a NAP policy server for all NAP enforcement methods.

When you configure NPS as a NAP policy server, NPS evaluates statements of health (SoH) sent by NAP-capable client computers that want to connect to the network. You can configure NAP policies in NPS that allow client computers to update their configuration to become compliant with your organization's network policy.

Client computer health

Health is defined as information about a client computer that NAP uses to determine whether to allow or deny client access to a network. An assessment of client computer health status represents a client computer's configuration state in comparison to the state that is required by health policy.

Example measurements of health include:

  • The operational status of Windows Firewall. Is the firewall enabled or disabled?

  • The update status of antivirus signatures. Are the antivirus signatures the most recent ones available?

  • The installation status of security updates. Are the most recent security updates installed on the client?

The client computer's health status is encapsulated in a SoH, which is issued by NAP client components. NAP client components send the SoH to NAP server components for evaluation to determine whether the client is compliant and can be granted full network access.

NAP allows administrators to ensure ongoing compliance with health policies, and, optionally, to limit the access of noncompliant computers until their health state can be brought into compliance with health policy.

In NAP terminology, verifying that a computer meets your defined health requirements is called health policy validation. NPS performs health policy validation for NAP.

How NAP enforcement works

NAP enforces health policies with client-side components that inspect and assess the health of client computers, server-side components that restrict network access when client computers are deemed noncompliant, and both client and server-side components that assist in remediating noncompliant client computers for full network access.

Key processes of NAP

To help protect network access, NAP relies on three processes: policy validation, NAP enforcement and network restriction, and remediation and ongoing compliance.

Policy validation

With NPS, you can create client health policies using SHVs that allow NAP to detect, enforce, and remediate client computer configurations.

WSHA and WSHV provide the following functionality for NAP-capable computers:

  • The client computer has firewall software installed and enabled.

  • The client computer has antivirus software installed and running.

  • The client computer has current antivirus updates installed.

  • The client computer has antispyware software installed and running.

  • The client computer has current antispyware updates installed.

  • Microsoft Update Services is enabled on the client computer.

In addition, if NAP-capable client computers are running Windows Update Agent and are registered with a Windows Server Update Service (WSUS) server, NAP can verify that the most recent software security updates are installed based on one of four possible values that match security severity ratings from the Microsoft Security Response Center (MSRC).

When you create policies that define the client computer health status, policies are validated by NPS. The NAP client-side components send a SoH to the NPS server during the network connection process. NPS examines the SoH and compares it to health policies.

NAP enforcement and network restriction

NAP denies noncompliant client computers access to the network or allows them access only to a special restricted network called a remediation network. A remediation network provides client computers with access to remediation servers, which provide software updates, and to any other key NAP services, such as Health Registration Authority (HRA) servers, that are required to bring noncompliant NAP clients into compliance with health policy.

The NAP enforcement setting in NPS network policy allows you to use NAP to limit the network access or observe the state of NAP-capable client computers that do not comply with your network health policy.

You can choose to restrict access, defer restriction of access, or allow access with network policy settings. For more information, see Network Policy Settings Properties.

Remediation

Noncompliant client computers that are put into a restricted network might undergo remediation. Remediation is the process of automatically updating a client computer so that it meets current health policies. For example, a restricted network might contain a File Transfer Protocol (FTP) server that automatically updates the virus signatures of noncompliant client computers that have outdated signatures.

Ongoing compliance

NAP can enforce health compliance on client computers that are already connected to the network. This functionality is useful for ensuring that a network is protected on an ongoing basis as health policies change and the health of client computers change. For example, NAP determines that the client computer is in a noncompliant state if a health policy requires that Windows Firewall is turned on and an administrator inadvertently turns the firewall off on a client computer. NAP will then disconnect the client computer from the organization network and connect the client computer to the remediation network until Windows Firewall is turned back on.

You can use NAP settings in NPS network policies to configure autoremediation so that NAP client components automatically attempt to update the client computer when it is not compliant. As with NAP enforcement settings, autoremediation is configured in network policy settings.

See Also

  • NAP Components
  • Health Policies
  • NAP Enforcement Methods
  • Remediation Server Groups
  • Windows Security Health Validator
  • Network Access Quarantine Control
  • Create NAP Policies with a Wizard


Create NAP Policies with a Wizard

Create NAP policies with a wizard

You can use this procedure to create the health policies, connection request policies, and network policies required to deploy Network Access Protection (NAP) with Network Policy Server (NPS).

This procedure explains how to start the New Network Access Protection Policies wizard. When you run the wizard, you first choose the network connection method that you have deployed, such as Terminal Services Gateway (TS Gateway) or 802.1X wireless, and then enter the information required for the wizard to create all of the NPS policies for that connection method.

Note

In this context, network connection method is synonymous with NAP enforcement method.

After you run the wizard, the following policies are created:

  • Two health policies: compliant and noncompliant.

  • One connection request policy.

  • Three network policies: compliant, noncompliant, and non-NAP capable.

Running the New Network Access Protection Policies wizard is not the only step required to deploy NAP. Each network connection method requires that you deploy hardware and software components for your NAP deployment.

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

To create NAP policies with a wizard

  1. Open the NPS console. If it is not already selected, click NPS (Local). If you are running the NPS MMC snap-in and want to create NAP policies on a remote NPS server, select the server.

  2. In Getting Started and Standard Configuration, select Network Access Protection (NAP) policy server. The text and links below the text change to reflect your selection.

  3. Click Configure NAP with a wizard. The New Network Access Protection Policies wizard opens.

See Also

  • NAP Enforcement Methods
  • Health Policies
  • Connection Request Policies
  • Network Policies
  • Network Access Protection in NPS


Enable Client Health Checks for DHCP and IPsec NAP Deployments

Enable client health checks

You can use this procedure to enable client health checks when you deploy Network Access Protection (NAP) with the Internet Protocol security (IPsec) and DHCP enforcement methods. Client health checks with these enforcement methods occur during the authorization process; however, these checks also occur at times when NPS does not perform the full authentication and authorization process. For example, when a DHCP client renews its IP address, a client health check is performed, but full authentication and authorization are not performed.

Important

The Perform machine health check only setting is provided for use with network policies that also enforce health policy for NAP. Do not use this setting on policies that do not enforce health policy for NAP.

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

To enable client health checks

  1. Open the Network Policy Server console, double-click Policies, and then double-click Network Policies.

  2. Double-click the policy for which you want to enable client health checks. The policy properties dialog box opens. Click the Constraints tab.

  3. In Constraints, ensure that Authentication Methods is selected.

  4. In the details pane, select the Perform machine health check only check box.

Additional considerations

For DHCP and IPsec NAP deployments, when NPS receives a request for a client health check that does not include the User Name attribute and the Identity Type condition is configured in NPS network policy with a value of Computer health check, the request matches the policy and, if all other conditions and constraints configured in the policy are also matched, the policy settings are applied.

For more information, see Network Policy Conditions Properties.


Enable DHCP Scopes for NAP

Enable DHCP scopes for NAP

When you deploy the DHCP enforcement method for Network Access Protection (NAP), you must choose whether to enable NAP on individual scopes on your DHCP server or to enable NAP on all DHCP scopes on a DHCP server.

Enabling NAP for individual scopes is recommended if you have a limited number of subnets and scopes that support the subnets.

If you have a large number of subnets, it is recommended that you enable NAP for all scopes on a DHCP server.

To configure DHCP scopes for NAP, do one of the following:

  • To enable NAP for all scopes on a DHCP server, obtain the Internet Protocol version 4 (IPv4) properties of the server, click the Network Access Protection tab, and configure NAP.

  • To enable NAP for individual scopes on a DHCP server, obtain the scope properties, click the Network Access Protection tab, and configure NAP.


Host Credential Authorization Protocol

Host Credential Authorization Protocol (HCAP)

Host Credential Authorization Protocol (HCAP) allows you to integrate your Microsoft Network Access Protection (NAP) solution with Cisco Network Admission Control. When you deploy HCAP with Network Policy Server (NPS) and NAP, NPS can perform the authorization of Cisco 802.1X access clients, including the enforcement of NAP health policy, while Cisco authentication, authorization, and accounting (AAA) servers perform authentication.

To deploy a HCAP server, you must do the following:

  1. Deploy NAP-capable client computers. Configure client computers to use Cisco EAP-FAST as the authentication method for network access.

  2. Using NAP deployment documentation, deploy NAP, which includes configuring client computers with system health agents (SHAs) and NPS servers with the corresponding system health validators (SHVs).

  3. Using Cisco deployment documentation, deploy Cisco Network Admission Control.

  4. Using the Add Roles wizard from Server Manager, install HCAP server. HCAP server is a role service of the Network Policy and Access Services server role. When you install HCAP server, the additional required components, Internet Information Services (IIS) and NPS, are installed on the same computer. In addition, a server certificate is autoenrolled to the server running IIS to allow Secure Sockets Layer (SSL) connections between IIS and the Cisco AAA server.

  5. Configure IIS to listen to specified IP addresses to allow Cisco AAA servers to send authorization requests.

  6. Configure the Cisco AAA server with the URL of the server running HCAP, NPS, and IIS so that the Cisco AAA server can send authorization requests to NPS.

  7. Configure NPS on the HCAP server as a RADIUS proxy to forward authorization requests to NPS servers that are members of one or more remote RADIUS server groups. Optionally, you can configure NPS on the HCAP server as a RADIUS server to process authorization requests locally.

  8. Configure NPS servers as RADIUS servers to perform authorization, which includes deploying NAP and creating health policy in NPS. If the NPS-HCAP server is a RADIUS proxy that forwards connection requests to NPS RADIUS servers in remote RADIUS server groups, you must configure the RADIUS proxy as a RADIUS client on each RADIUS server.

  9. On NPS RADIUS servers, configure network policy with NAP health policy. If desired, network policy conditions can include HCAP-Group-Name and HCAP-Location-Group for NAP interoperability with Cisco Network Admission Control. In addition, you can use the Extended State condition in network policy to specify the extended state of the client computer that is required to match the network policy. Extended states are elements of Cisco Network Admission Control, and include Transitional, Infected, and Unknown. By using this network policy condition, you can configure NPS to authorize or reject access based on whether the client computer is in one of these states.

Authentication and authorization process

After deploying both Cisco Network Admission Control and NPS with NAP, the authentication and authorization process works as follows:

  1. The client computer attempts to access the network. The client can attempt to connect through an 802.1X authenticating switch or through an 802.1X wireless access point that is configured as a RADIUS client to the Cisco AAA server. In addition, a router can send a connection request to the Cisco AAA server using Extensible Authentication Protocol (EAP) over User Datagram Protocol (UDP).

  2. After the Cisco AAA server receives the connection request from the network access server or router, the Cisco AAA server requests statement of health (SoH) data from the client by sending an EAP-Type Length Value (EAP-TLV).

  3. SHAs on the client computer report health status to NAP agent on the client, and NAP agent creates a SoH, which it sends to the Cisco AAA server.

  4. The Cisco AAA server forwards the SoH using HCAP to the NPS proxy or server along with the client computer's user ID, machine ID, and location.

  5. If the NPS-HCAP server is configured as a RADIUS proxy, NPS forwards the authorization request to the appropriate remote RADIUS server group. (This determination is made with the evaluation by NPS of the configured connection request policies.) If the NPS-HCAP server is configured as a RADIUS server, the NPS-HCAP server processes the authorization request.

  6. NPS evaluates the SoH against configured network policy and, if a matching network policy is found, creates a statement of health response (SoHR) to be sent back to the client. This, along with the NAP enforcement state and extended state information, is then sent back to the Cisco AAA server using HCAP.

  7. The Cisco AAA server evaluates the NAP enforcement state against Cisco Network Admission Control policy and determines the network access profile.

  8. The Cisco AAA server sends the network access profile to the network access server (the switch, AP, or router). The network access profile contains the information that instructs the network access server whether to allow full access, restrict access, or deny access to the client computer.

  9. The Cisco AAA server sends the SoHR back to the client computer.

  10. If the client configuration does not comply with health policy and the SoHR instructs the client to remediate, then the client attempts to take the required actions, such as downloading software updates or changing configuration settings. After remediation, the client attempts to access the network again, and the authentication and authorization process is repeated.

See Also

  • Network Access Protection in NPS
  • EAP Overview
  • RADIUS Clients
  • RADIUS Proxy
  • RADIUS Server


NAP Components

NAP components

Network Access Protection (NAP) consists of multiple client and server components. There are common NAP components that are used in all NAP deployments and there are components that are used only for specific deployments, depending on the NAP enforcement method or methods that you choose.

NAP enforcement methods are any of several network access technologies that work in conjunction with Network Access Protection to enforce health policies. The enforcement methods are Dynamic Host Configuration Protocol (DHCP), Internet Protocol security (IPsec), virtual private networking (VPN), Terminal Services Gateway (TS Gateway), and Extensible Authentication Protocol (EAP), which you can use for 802.1X-based wireless and wired connections that are authenticated by an NPS server.

Common NAP components

Common NAP components consist of both client and server components and are used by all NAP enforcement methods.

Client components

A NAP-capable client is a computer that has the NAP components installed and can verify its health state by sending a statement of health (SoH) to Network Policy Server (NPS).

Following are the NAP-capable client computer components of the NAP infrastructure.

  • Statement of health (SoH)

    A declaration from a client computer that asserts its health status. System health agents (SHAs) create statements of health (SoHs) and send them to a corresponding system health validator (SHV) on an NPS server.

  • System health agent (SHA)

    A component that checks the state of the client computer to determine whether the settings monitored by the SHA are up-to-date and configured correctly. For example, the Windows Security Health Agent (WSHA) can monitor Windows Firewall, whether antivirus software is installed, enabled, and updated, whether antispyware software is installed, enabled, and updated, and whether Microsoft Update Services is enabled and the computer has the most recent security updates from Microsoft Update Services. There might also be SHAs (and corresponding system health validators) available from other companies that provide different functionality.

  • NAP agent

    A client-side service that collects and manages health information. Processes statements of health from the various system health agents and reports client health to the NAP administration server.

  • Enforcement client

    Client software that integrates with network access technologies, such as DHCP, VPN, and IPsec. To use NAP, at least one NAP enforcement client must be installed and enabled on client computers. Individual NAP enforcement clients are enforcement method-specific and are described in the following section. The NAP enforcement client requests access to a network, communicates a client computer's health status to the NAP server that is providing the network access, such as the NPS server, and communicates the restricted status of the client computer to other components of the NAP client architecture.

Server components

Following are the server components of the NAP infrastructure.

  • Remediation server

    Hosts the updates that NAP agent can use to bring noncompliant client computers into compliance. For example, a remediation server can host antivirus signatures. If health policy requires that NAP client computers have the latest antivirus definitions installed, an antivirus SHA, an antivirus SHV, an antivirus policy server, and the remediation server used to host the antivirus signatures work in concert to update noncompliant computers.

  • System health validators (SHVs)

    Server software counterparts to SHAs. Each SHA on the client has a corresponding SHV in NPS. NPS uses SHVs to verify the statement of health that is made by its corresponding SHA on the client computer.

    SHAs and SHVs are matched to each other, along with a corresponding policy server (used by a SHV to determine the current conditions for system health) and perhaps a remediation server.

    A SHV can also detect that no SoH has been received (such as the case in which the SHA has never been installed, or has been damaged or removed). If the SoH does not meet the defined policy, the SHV sends a statement of health response (SoHR) message to the SHA.

    One network might have more than one kind of SHV. If it does, the NPS server must coordinate the output from all of the SHVs and determine whether to limit the access of a noncompliant computer. This requires careful planning when defining health policies for your environment and evaluating how different SHVs interact.

    The Windows Security Health Validator (WSHV) can verify a SoH from the WSHA on a client computer. There might also be SHVs (and corresponding SHAs) available from other companies that provide different functionality.

  • Health policies

    Rules created by configuring individual SHVs and adding them to a health policy, and then configuring policy conditions. Health policies are then implemented and enforced by NPS when you add them to the settings of a network policy.

  • Statement of health response (SoHR)

    The validation of a SoH. If the client computer is noncompliant, the SoHR contains remediation instructions that the SHAs on the client use to bring the client computer configuration into compliance with health policy.

    Each type of SoH stores different kinds of information about system health status, and SoHR messages store different kinds of information about how to become compliant with the health policy requirements that are configured in NPS.

Enforcement method-specific components

Following are the enforcement method-specific components of the NAP infrastructure.

  • Enforcement technology

    One of five network access technologies that can be configured to enforce NAP policies.

  • Enforcement server

    A component on a NAP server that is typically matched with a NAP enforcement client and that restricts a client computer’s network access based on its health compliance. There are several NAP enforcement servers: one for DHCP address configurations, one for VPN connections, one for IPsec-protected communication, one for Terminal Services Gateway (TS Gateway), and one for Extensible Authentication Protocol (EAP), which you can use for 802.1X-based connections that are authenticated by an NPS server.

See Also

  • Network Access Protection in NPS
  • NAP Enforcement Methods
  • Windows Security Health Validator


Health Policies

Health policies

Health policies consist of one or more system health validators (SHVs) and other settings that allow you to define client computer configuration requirements for the NAP-capable computers that attempt to connect to your network.

When NAP-capable clients attempt to connect to the network, the client computer sends a statement of health (SoH) to Network Policy Server (NPS). The SoH is a report of the client configuration state, and NPS compares the SoH to the requirements defined in health policy. If the client configuration state does not match the requirements defined in health policy, NPS takes one of the following actions, depending on how NAP is configured:

  • The connection request by the NAP client is rejected.

  • The NAP client is placed on a restricted network where it can receive updates from remediation servers that bring the client into compliance with health policy. After the client is compliant with health policy, it is allowed to connect.

  • The NAP client is allowed to connect to the network despite being noncompliant with health policy.

You can define client health policies in NPS by adding one or more SHVs to the health policy.

After a health policy is configured with one or more SHVs, you can add the health policy to the Health Policies condition of a network policy that you want to use to enforce NAP when client computers connect to your network.

Using multiple SHVs in a health policy

The Windows Security Health Validator (WSHV) is included by default in NPS. Other companies might also provide additional SHV and SHA pairs for their NAP-compatible products.

If you want to use a NAP-compatible product, you can follow the product's documentation to install the SHA on NAP-capable client computers, and then install the SHV on the NPS server. After you have installed the SHV on the NPS server, you can configure the SHV and then add the SHV to a health policy.

After your health policy is configured with the SHVs you want to use, you can add the health policy to the settings of a network policy.

See Also

  • Create a Health Policy
  • System Health Validators
  • Understanding How to Configure Health Policy


Create a Health Policy

Create a health policy

You can create health policies in Network Policy Server (NPS) by naming the policy, setting the type of client system health validator (SHV) check, and adding one or more SHVs to the new health policy.

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

To create a health policy

  1. Open the NPS console.

  2. In the console tree, double-click Policies, right-click Health Policies, and then click New. The Create New Health Policy dialog box opens.

  3. In Create New Health Policy, on the Settings tab, in Policy Name, type a name for the health policy.

  4. On the Settings tab, in Client SHV checks, select one of the following.

    • Client passes all SHV checks. If this option is selected, the NAP-capable client computer configuration must match all SHVs that are configured in the policy.

    • Client fails all SHV checks. If this option is selected, NAP-capable client computer configuration must not match any SHVs that are configured in the policy.

    • Client passes one or more SHV checks. If this option is selected, NAP-capable client computer configuration must match at least one SHV configured in the policy.

    • Client fails one or more SHV checks. If this option is selected, NAP-capable client computer configuration must not match at least one SHV configured in the policy.

  5. In SHVs used in this health policy, click the SHVs that you want to include in the health policy. One or more SHVs must be selected.

  6. Click OK.


System Health Validators

System health validators

System health validators (SHVs) are server software counterparts to system health agents (SHAs). Each SHA on the client has a corresponding SHV in Network Policy Server (NPS). SHVs allow NPS to verify the statement of health (SoH) that is made by its corresponding SHA on the client computer.

SHVs contain the details of the required configuration settings on client computers. For example, the Windows Security Health Validator (WSHV) is the counterpart to the Windows Security Health Agent (WSHA) on client computers. WSHV allows you to create a policy for the way in which settings on NAP-capable client computers must be configured. If the settings on the client computer as reported in the SoH do not match the settings in the SHV on the NPS server, the client computer is not compliant with health policy.

To extend this example, if you configure the WSHV to use the setting A firewall is enabled for all network connections, the firewall software that is running on the client computer must be Windows Firewall software or other firewall software that is compatible with Windows Security Center. If the client computer is not running Windows Firewall or other firewall software that is compatible with Windows Security Center, NAP agent on the client computer sends a SoH to NPS that reports this fact. NPS compares the SoH to the configuration of the WSHV in NPS; NPS then determines that the client computer is not compliant with health policy.

See Also

  • Windows Security Health Validator
  • Understanding How to Configure Health Policy


Windows Security Health Validator

Windows Security Health Validator

The Windows Security Health Validator (WSHV) provides settings that you can configure based on the requirements of your deployment.

WSHV settings

You can configure the following WSHV settings for your policy.

Firewall

To use the setting A firewall is enabled for all network connections, the firewall software that is running on the client computer must be Windows Firewall software or other firewall software that is compatible with Windows Security Center.

Firewall software that is not compatible with Windows Security Center cannot be managed or detected by Windows Security Health Agent (WSHA) on the client computer.

If you select A firewall is enabled for all network connections, WSHA on the client computer checks if firewall software is running on the client computer and takes the following actions.

  • If the client computer is not running firewall software, the client computer is restricted to a remediation network until firewall software is installed and running.

  • If the only firewall software running on the client computer is a firewall that is not compliant with Windows Security Center, WSHA reports to the Network Access Protection (NAP) service that no firewall is enabled, and the client computer is restricted to a remediation network.

Important

If you select A firewall is enabled for all network connections and client computers are not running Windows Firewall or other Windows Security Center-compliant firewall software, client computers cannot connect to your network.

If you do not select A firewall is enabled for all network connections, WSHA on the client computer does not attempt to enable firewall software or restrict client computers to a remediation network if they are not running firewall software. Because of this, client computers that are not running firewall software are not prevented from connecting to your network.

Autoremediation

If you select A firewall is enabled for all network connections, you enable NAP autoremediation, and WSHA on the client computer reports that no firewall is enabled, either because there is no firewall or the firewall software on the client computer is not compatible with Windows Security Center, then WSHV directs WSHA on the client computer to turn on Windows Firewall.

Important

If autoremediation is enabled and client computers are running firewall software that is not compliant with Windows Security Center and it is not detected by WSHA, WSHA on the client computer turns on Windows Firewall on the client computer, resulting in the client computer running two different firewalls simultaneously. Any exceptions configured on the noncompliant firewall are not configured in Windows Firewall, which could cause a loss of functionality on the client computer, depending on how it is configured. For this reason, it is not recommended for client computers to run two different firewalls simultaneously.

Virus protection

If you select An antivirus application is on, WSHA on the client computer verifies that antivirus software is running on the client computer. If the client computer is not running antivirus software, the client computer is restricted to a remediation network until antivirus software is installed and running.

The antivirus software that is running on the client computer must be compatible with Windows Security Center. Antivirus software that is not compatible with Windows Security Center cannot be managed or detected by WSHA on the client computer. If the only antivirus software running on the client computer is an antivirus application that is not compliant with Windows Security Center, the WSHA reports to WSHV that no antivirus is enabled, and the client computer is restricted to a remediation network.

If you select Antivirus is up to date, WSHA on the client computer verifies that the antivirus definitions for your antivirus applications are the most current versions and are up-to-date.

To verify that antivirus software is running and that antivirus definitions are the most recent updates available, you must select both An antivirus application is on and Antivirus is up to date.

If you do not select An antivirus application is on, WSHA on the client computer does not attempt to detect whether client computers are running antivirus software. Because of this, client computers that are not running antivirus software are not prevented from connecting to your network.

If you do not select both An antivirus application is on and Antivirus is up to date, WSHA on the client computer does not attempt to detect whether client computers are running antivirus software with the most recent antivirus definitions. Because of this, client computers that are not running antivirus software or that are running antivirus software with out-of-date antivirus definitions are not prevented from connecting to your network.

Spyware protection

If you select An antispyware application is on, WSHA on the client computer verifies that antispyware software is running on the client computer. If the client computer is not running antispyware software, the client computer is restricted to a remediation network until antispyware software is installed and running.

The antispyware software that is running on the client computer must be Windows Defender or other antispyware software that is compatible with Windows Security Center.

Antispyware software that is not compatible with Windows Security Center cannot be managed or detected by WSHA on the client computer. If the only antispyware software running on the client computer is an antispyware application that is not compatible with Windows Security Center, the WSHA reports to WSHV that no antispyware is enabled, and the client computer is restricted to a remediation network.

If you select Antispyware is up to date, WSHA on the client computer verifies that the antispyware definitions for your antispyware applications are the most current versions and are up-to-date.

To verify that antispyware software is running and that antispyware definitions are the most recent updates available, you must select both An antispyware application is on and Antispyware is up to date.

If you do not select An antispyware application is on, WSHA on the client computer does not attempt to detect whether client computers are running antispyware software. Because of this, client computers that are not running antispyware software are not prevented from connecting to your network.

If you do not select both An antispyware application is on and Antispyware is up to date, WSHA on the client computer does not attempt to detect whether client computers are running antispyware software with the most recent antispyware definitions. Because of this, client computers that are not running antispyware software or that are running antispyware software with out-of-date antispyware definitions are not prevented from connecting to your network.

Autoremediation

If you select An antispyware application is on, you enable NAP autoremediation, and WSHA on the client computer reports that no antispyware is enabled, either because there is no antispyware or the antispyware software on the client computer is not compatible with Windows Security Center, then WSHV directs WSHA on the client computer to turn on Windows Defender.

Important

If autoremediation is enabled and client computers are running antispyware software that is not compliant with Windows Security Center and the antispyware is not detected by WSHA, WSHA on the client computer turns on Windows Defender on the client computer, resulting in the client computer running two different antispyware applications simultaneously.

Note

You can configure autoremediation using the NAP Client Management MMC snap-in.

Automatic updating

If you select Automatic Updating is on, and Microsoft Update Services is not enabled on the client computer, WSHA restricts the client computer to a remediation network until Microsoft Update Services is enabled.

Microsoft Update Services is enabled when one of the following settings is selected on the client computer:

  • Install updates automatically (recommended)

  • Download updates, but let me choose whether to install them

  • Check for updates, but let me choose whether to download and install them

Autoremediation

If you select Automatic updates are enabled, you enable NAP autoremediation, and WSHA on the client computer reports that Microsoft Update Services is not enabled, then WSHV directs WSHA on the client computer to enable Microsoft Update Services and to configure Microsoft Update Services to automatically download and install updates.

Note

You can configure autoremediation using the NAP Client Management MMC snap-in.

Security update protection

Do not configure Security Update Protection in your WSHV policy unless client computers on your network are running Windows Update Agent. In addition, client computers that are running Windows Update Agent must be registered with a server running Windows Server Update Service (WSUS).

Important

Do not configure Security Update Protection in your WSHV policy unless client computers are running Windows Update Agent and they are registered with a WSUS server. If these conditions are not met and you configure Security Update Protection in your WSHV policy, the policy cannot be enforced by WSHA on the client computer. Because of this, WSHA restricts client computers to a remediation network and they cannot connect to your network.

If client computers are running Windows Update Agent and are registered with a WSUS server, you can configure Security Update Protection for your WSHV policy.

In that case, if you select Enforce quarantine for missing security updates and the most recent security updates are not installed, WSHA restricts the client computer to a remediation network until the most recent software security updates are installed.

You can configure Security Update Protection with several possible values that match security severity ratings from the Microsoft Security Response Center (MSRC). These values are:

  • Critical only. If selected, client computers are required to have all security updates with an MSRC severity rating of Critical. If client computers do not have these updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

  • Important and above. This is the default setting. If selected, client computers are required to have all security updates with an MSRC severity rating of Important or Critical. If client computers do not have these updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

  • Moderate and above. If selected, client computers are required to have all security updates with an MSRC severity rating of Moderate, Important, and Critical. If client computers do not have these updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

  • Low and above. If selected, client computers are required to have all security updates with an MSRC severity rating of Low, Moderate, Important, and Critical. If client computers do not have these updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

  • All. If selected, client computers are required to have all security updates, regardless of their severity rating by the MSRC. If client computers do not have the most recent updates, the client computer is restricted to a remediation network until the updates are downloaded and installed.

After you configure the security update severity rating level, you can specify the minimum number of hours allowed since the client has checked the WSUS server for new security updates. The default value for the minimum synchronization time is 22 hours.

When a client computer first attempts to connect to a NAP-enabled network and the Security Update Protection setting is configured in the WSHV policy, WSHA determines whether to restrict the client computer to a remediation network based on the most recent time that the client computer checked the WSUS server for security updates. WSHA determines whether to restrict the client to a remediation network in the following way.

  • If the client check for updates occurred at an interval greater than the WSHV-configured minimum number of hours allowed between checks, the client computer is restricted to a remediation network. After the client checks for updates and downloads and installs any recent updates, the client is allowed full network access.

  • If the client check for updates occurred at an interval that is equal to or less than the WSHV-configured minimum number of hours allowed between checks, the client computer is not restricted to a remediation network.

Note

WSHA on the client computer only performs this check the first time that the client computer attempts to connect to the network. If the client computer remains connected to the network for longer than the configured minimum synchronization time, WSHA does not trigger a check for security updates, does not trigger download of updates, and does not restrict the client computer to a remediation network.

Autoremediation

For autoremediation to work with the Security Update Protection setting enabled and configured in your WSHV policy, the following must be true:

  • Client computers on your network are running Windows Update Agent.

  • Client computers that are running Windows Update Agent are registered with a WSUS server.

  • Autoremediation is configured and enabled.

If these conditions are met, WSHA on the client computer checks with the WSUS server to discover the most recent security updates. If WSHA discovers that the most recent security updates of the configured MSRC severity rating are not installed on the client computer, WSHA downloads and installs the most recent security updates.


Understanding How to Configure Health Policy

Understanding how to configure health policy

Network Access Protection (NAP) enforcement is accomplished by Network Policy Server (NPS) on a per-network policy basis. That is, you can create network policies that enforce NAP and you can create network policies that do not enforce NAP. In addition, you can create network policies that enforce NAP in different ways and for different NAP enforcement methods.

To configure NPS to enforce client health policies, you must configure the following:

  • System health validators (SHVs), which contain the settings that you can choose to enforce or not enforce. For example, in the Windows Security Health Validator (WSHV), you can choose whether to enforce client computer use of a firewall, antivirus software, and other settings.

  • Health policies, which contain the SHVs that you want to enforce with the health policy.

  • Network policy, which you create by adding one or more SHVs to the health policy. You can add the health policy to the network policy and enable NAP enforcement in the policy.

The basic steps for creating a network policy that enforces NAP are:

  • If required for your network configuration, install SHVs from other companies. Also install the corresponding system health agents (SHAs) on client computers.

  • Configure the SHVs that you want to use, whether they are non-Microsoft SHVs or the WSHV, which is included in Windows Server® 2008.

  • Add SHVs to a new or existing health policy.

  • Create a new network policy or open an existing policy.

  • In network policy conditions, add the health policy to the network policy.

Planning a network policy that enforces NAP

If you need a network policy that enforces NAP, you must determine:

  • The type of network access server, or RADIUS client, that the NAP-capable client computer uses to connect to the network.

  • The NAP enforcement client you want to use. The NAP enforcement client that you choose must match the connection method that the client uses to access the network. For example, if you deploy NAP with the DHCP enforcement method, you must use the DHCP enforcement client.

  • The Windows groups that contain the users and computers that you want to authorize to access your network.

  • The SHAs that are installed on the client computers and SHVs that are installed on the NPS server. These NAP components must be installed before you configure and enable a network policy that enforces a client health policy using the SHV.

See Also

  • NAP Components
  • Windows Security Health Validator


Configure NAP Conditions in Network Policy

Configure NAP conditions in network policy

You can use this procedure to configure Network Access Protection (NAP) conditions in Network Policy Server (NPS) network policy.

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

To configure NAP conditions in network policy

To configure NAP conditions in network policy using the Windows interface

  1. Open the NPS console, double-click Policies, click Network Policies, and then double-click the policy you want to configure.

  2. In policy Properties, click the Conditions tab, and then click Add. In Select condition, scroll to the Network Access Protection group of conditions.

  3. If you want to configure the Identity Type condition, click Identity Type, and then click Add. In Specify the method in which clients are identified in this policy, select the items appropriate for your deployment, and then click OK.

    The Identity Type condition is used for the DHCP and Internet Protocol security (IPsec) enforcement methods to allow client health checks when NPS does not receive an Access-Request message that contains a value for the User-Name attribute; in this case, client health checks are performed, but authentication and authorization are not performed.

  4. If you want to configure the MS-Service Class condition, click MS-Service Class, and then click Add. In Specify the profile name that identifies your DHCP scope, type the name of an existing DHCP profile, and then click Add.

    The MS-Service Class condition restricts the policy to clients that have received an IP address from a DHCP scope that matches the specified DHCP profile name. This condition is used only when you are deploying NAP with the DHCP enforcement method.

  5. If you want to configure the Health Policies condition, click Health Policies, and then click Add. In Health Policies, choose an existing health policy, and then click OK. If you have not yet configured health policies, click New, and then configure a new health policy.

    The Health Policies condition restricts the policy to clients that meet the health criteria in the policy that you specify.

  6. If you want to configure the NAP-capable Computers condition, click NAP-capable Computers, and then click Add. In Specify the computers required to match this policy, click either Only computers that are NAP-capable or Only computers that are not NAP-capable, and then click OK.

    The NAP-capable Computers condition restricts the policy to either clients that are capable of participating in NAP or clients that are not capable of participating in NAP. This capability is determined by whether the client sends a statement of health (SoH) to NPS.

  7. If you want to configure the Operating System condition, click Operating System, and then click Add. In Operating System Properties, click Add, and then specify the operating system settings that are required to match the policy.

    The Operating System condition specifies the operating system (operating system version or service pack number), role (client or server), and architecture (x86, x64, or ia64) required for the computer configuration to match the policy.

  8. If you want to configure the Policy Expiration condition, click Policy Expiration, and then click Add. In Policy Expiration, configure the date and time when you want the network policy to expire, and then click OK.

    The Policy Expiration condition specifies when the network policy expires; after the expiration date and time that you specify, the network policy is no longer evaluated by NPS.

See Also

  • Network Policy Conditions Properties


Configure NAP Settings in Network Policy

Configure NAP settings in network policy

You can use this procedure to configure Network Access Protection (NAP) settings in Network Policy Server (NPS) network policy.

Important

The NAP Extended State setting, along with Host Credential Authorization Protocol (HCAP) server, allows you to integrate your Microsoft NAP solution with Cisco Network Admission Control. Do not configure the NAP Extended State setting in network policy unless you have also deployed Cisco Network Admission Control and HCAP server.

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

To configure NAP settings in NPS network policy

  1. Open the NPS console, double-click Policies, click Network Policies, and then double-click the policy you want to configure.

  2. In policy Properties, click the Settings tab.

  3. Locate the settings group Network Access Protection, click NAP Enforcement or Extended State, and then configure the settings according to the requirements of your NAP deployment.

See Also

  • Network Policy Settings Properties
  • Host Credential Authorization Protocol


NAP Clients

NAP Clients

You can use the topics in the following sections to configure NAP-capable client computers for use with Network Access Protection (NAP).

  • 802.1X Client Configuration with Group Policy

  • Enable Security Center in Group Policy

  • Enable the Network Access Protection Service on Clients

  • Enable and Disable NAP Enforcement Clients


Enable and Disable NAP Enforcement Clients

Enable and Disable NAP Enforcement Clients

You can use this procedure to enable or disable one or more NAP enforcement clients, including the DHCP enforcement client, the Remote Access enforcement client, the EAP enforcement client, the Internet Protocol security (IPsec) enforcement client, and the Terminal Services Gateway (TS Gateway) enforcement client, on NAP-capable computers.

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

To enable and disable NAP enforcement clients

  1. To open the NAP client configuration console, click Start, click All Programs, click Accessories, click Run, type NAPCLCFG.MSC, and click OK.

  2. Click Enforcement Clients. In the details pane, right-click the enforcement client that you want to enable or disable, and then click Enable or Disable.


Enable Security Center in Group Policy

You can use this procedure to install Group Policy Management and enable Security Center on NAP-capable clients using Group Policy. Security Center is required for some Network Access Protection (NAP) deployments that use Windows Security Health Validator (WSHV).

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

Install Group Policy Management

  1. Click Start, and then click Server Manager. Server Manager opens.

  2. In the left pane, click Features, and in the details pane, in Features Summary, click Add Features. The Add Features Wizard opens.

  3. In Select Features, in Features, select Group Policy Management, and then click Next.

  4. In Confirm Installation Selections, click Install.

  5. In Installation Results, review the information, and then click Close.
To enable Security Center in Group Policy

  1. Click Start, and in Start Search, type gpmc.msc, and then press ENTER. The Group Policy Management console opens.

  2. In the left pane, double-click your forest.

  3. Double-click, Domains, and then double-click the domain that contains the Group Policy that you want to manage.

  4. Right-click Default Domain Policy, and then click Edit.

  5. In the console tree, double-click Computer Configuration, double-click Administrative Templates, double-click Windows Components, and then double-click Security Center.

  6. Double-click Turn on Security Center (Domain PCs only), click Enabled, and then click OK.


Enable the Network Access Protection Service on Clients

You can use this procedure to enable and configure the Network Access Protection (NAP) service on NAP-capable client computers. You must enable this service when you deploy NAP.

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

To enable the Network Access Protection service on clients

  1. Click Start, Control Panel, System and Maintenance, Administrative Tools, and then double-click Services.

  2. In the services list, scroll down to and double-click Network Access Protection Agent.

  3. In the Network Access Protection Agent Properties dialog box, change Startup Type to Automatic, and then click OK.


NAP Enforcement Methods

NAP enforcement methods

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

  • Internet Protocol security (IPsec) policies for Windows Firewall on client computers. For NAP IPsec enforcement, the IPsec enforcement client must be installed on client computers. For more information, see NAP Enforcement for IPsec Communications.

  • 802.1X port-based wired and wireless network access control. For more information, see NAP Enforcement for 802.1X.

  • Dynamic Host Configuration Protocol (DHCP) Internet Protocol version 4 (IPv4) address lease and renewal. For more information, see NAP Enforcement for DHCP.

  • Terminal Server Gateway (TS Gateway) connections with Terminal Services. For more information, see NAP Enforcement for Terminal Services Gateway.

  • Virtual private networks (VPN) with Routing and Remote Access. For more information, see NAP Enforcement for VPN.

Using multiple enforcement methods

Each of these NAP enforcement methods has strengths and weaknesses. By combining enforcement methods, you can eliminate most of the weaknesses of your NAP deployment. Deploying multiple NAP enforcement methods, however, can make your NAP implementation more complex to manage.

See Also

  • Network Access Protection in NPS
  • NAP Components
  • Windows Security Health Validator


NAP Enforcement for 802.1X

NAP enforcement for 802.1X

Network Access Protection (NAP) enforcement for 802.1X port-based network access control is deployed with a server running Network Policy Server (NPS) and an EAP host enforcement client component. With 802.1X port-based enforcement, the NPS server instructs an 802.1X authenticating switch or an 802.1X compliant wireless access point to place noncompliant 802.1X clients on a remediation network. The NPS server limits the client's network access to the remediation network by applying IP filters or a virtual LAN identifier to the connection. 802.1X enforcement provides strong network restriction for all computers accessing the network through 802.1X-capable network access servers.

Requirements for 802.1X wired

To deploy NAP with 802.1X wired, you must configure the following:

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Install and configure 802.1X authenticating switches.

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

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

  • If you are using PEAP-TLS or EAP-TLS with smart cards or certificates, deploy a public key infrastructure (PKI) with Active Directory® Certificate Services (AD CS).

  • If you are using PEAP-MS-CHAP v2, issue server certificates with either AD CS or purchase server certificates from another trusted root certification authority (CA).

Requirements for 802.1X wireless

To deploy NAP with 802.1X wireless, you must configure the following:

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Install and configure 802.1X wireless access points.

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

  • Configure the WSHV or install and configure other SHAs and SHVs, depending on your NAP deployment.


NAP Enforcement for DHCP

NAP enforcement for DHCP

DHCP enforcement is deployed with a DHCP Network Access Protection (NAP) enforcement server component, a DHCP enforcement client component, and Network Policy Server (NPS). Using DHCP enforcement, DHCP servers and NPS can enforce health policy when a computer attempts to lease or renew an IP version 4 (IPv4) address. However, if client computers are configured with a static IP address or are otherwise configured to circumvent the use of DHCP, this enforcement method is not effective.

Note

Health validation data that is stored in DHCP is visible to other computers. However, the DHCP enforcement client sends a statement of health (SoH) only if the SoH is requested by the DHCP server.

Requirements

To deploy NAP with DHCP, you must configure the following:

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Enable the NAP DHCP enforcement client and the NAP service on NAP-capable client computers.

  • Install DHCP on the local computer or on a remote computer.

  • In the DHCP MMC snap-in, enable NAP for individual scopes or for all scopes configured on the DHCP server.

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

If DHCP is not installed on the local computer, you must also configure the following:

  • Install NPS on the computer that is running DHCP.

  • Configure NPS on the remote DHCP NPS server as a RADIUS proxy to forward connection requests to the local NPS server.


NAP Enforcement for IPsec Communications

NAP enforcement for IPsec communications

Network Access Protection (NAP) enforcement for Internet Protocol security (IPsec) policies for Windows Firewall is deployed with a health certificate server, a Health Registration Authority (HRA) server, a server running NPS, and an IPsec enforcement client. The health certificate server issues X.509 certificates to NAP clients when they are determined to be compliant. These certificates are then used to authenticate NAP clients when they initiate IPsec communications with other NAP clients on an intranet.

IPsec enforcement confines the communication on your network to compliant clients, and provides the strongest implementation of NAP. Because this enforcement method uses IPsec, you can define requirements for secure communications on a per-IP address or per-TCP/UDP port number basis.

Requirements

To deploy NAP with IPsec and HRA, you must configure the following:

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Enable the NAP IPsec enforcement client and the NAP service on NAP-capable client computers.

  • Install HRA on the local computer or on a remote computer.

  • Install and configure Active Directory® Certificate Services (AD CS) and Certificate Templates.

  • Configure Group Policy and any other settings required for your deployment.

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

If HRA is not installed on the local computer, you must also configure the following:

  • Install NPS on the computer that is running HRA.

  • Configure NPS on the remote HRA NPS server as a RADIUS proxy to forward connection requests to the local NPS server.

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


NAP Enforcement for Terminal Services Gateway

NAP enforcement for Terminal Services Gateway

Terminal Services Gateway (TS Gateway) is a new role service available in Windows Server® 2008. With TS Gateway, authorized users can connect from any Internet-connected device to terminal servers and remote desktops on your organization network. In addition, the health state of client computers that are Terminal Services clients can be enforced and monitored with Network Access Protection (NAP).

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

Requirements

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

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

  • In NPS, configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

  • If you are using PEAP-TLS or EAP-TLS with smart cards or certificates, deploy a public key infrastructure (PKI) with Active Directory® Certificate Services (AD CS).

  • If you are using PEAP-MS-CHAP v2, issue server certificates with either AD CS or purchase server certificates from a trusted root certification authority (CA).

  • Enable NAP health policy checks on the TS Gateway server using the TS Gateway Manager snap-in.

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


NAP Enforcement for VPN

NAP enforcement for VPN

Network Access Protection (NAP) enforcement for virtual private networking (VPN) is deployed with a VPN enforcement server component and a VPN enforcement client component. Using this enforcement method, VPN servers can enforce health policy when client computers attempt to connect to the network using a VPN connection. VPN enforcement provides strong limited network access for all computers accessing the network through a VPN connection.

Note

VPN enforcement is different from Network Access Quarantine Control, which is a feature in Windows Server® 2003 and Internet Security and Acceleration (ISA) Server 2004.

Requirements

To deploy NAP with VPN, you must configure the following:

  • Install and configure Routing and Remote Access as a VPN server. Configure your server running Network Policy Server (NPS) as the primary RADIUS server in Routing and Remote Access.

  • In NPS, configure VPN servers as RADIUS clients. Also configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Enable the NAP Remote Access and EAP enforcement clients on NAP-capable client computers.

  • Enable the NAP service on NAP-capable client computers.

  • Configure the Windows Security Health Validator (WSHV) or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

  • If you are using PEAP-TLS or EAP-TLS with smart cards or certificates, deploy a public key infrastructure (PKI) with Active Directory® Certificate Services (AD CS).

  • If you are using PEAP-MS-CHAP v2, issue server certificates with either AD CS or purchase server certificates from a trusted root certification authority (CA).

Additional considerations

If you deploy the NAP VPN enforcement method and you have configured NAP enforcement with the Allow full network access for a limited time option, VPN clients that are connected to the network when the expiration time is reached are automatically disconnected whether they are compliant or noncompliant with health policy.

After the expiration date and time, VPN clients that attempt to connect to the network are placed on a restricted network if they are noncompliant with health policy, while compliant clients are allowed full network access.


Remediation Server Groups

Remediation server groups

A remediation server group is a list of servers on the restricted network that provide resources required to bring noncompliant NAP-capable clients into compliance with administrator-defined client health policy.

A remediation server hosts the updates that NAP agent can use to bring noncompliant client computers into compliance with health policy, as defined in Network Policy Server (NPS). For example, a remediation server can host antivirus signatures. If health policy requires that client computers have the latest antivirus definitions installed, an antivirus system health agent (SHA), an antivirus system health validator (SHV), an antivirus policy server, and the remediation server used to host the antivirus signatures work together to update noncompliant computers.

See Also

  • Configure Remediation Server Groups


Configure Remediation Server Groups

Configure remediation server groups

Use this procedure to configure remediation server groups in Network Policy Server (NPS).

A remediation server group is a list of servers on the restricted network that noncompliant NAP clients can access for software updates. Use this procedure to configure a new remediation server group in the NPS console.

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

To create a new remediation server group using the Windows interface

  1. Open the NPS console.

  2. In the console tree, double-click Network Access Protection, right-click Remediation Server Groups, and then click New. The New Remediation Server Group dialog box opens.

  3. In Group name, type a name for the remediation server group, and then click Add.

  4. In Add New Server, in Friendly name, type a name for the server you want to add.

  5. In Add New Server, in IP address or DNS name, type the IP address or Fully Qualified Domain Name (FQDN) of the remediation server that you want to add. If you type the FQDN of the server, click Resolve to obtain the IP address of the server. Click OK.

  6. If you want to add more remediation servers to the remediation server group, repeat these steps for each server, and then click OK.


RADIUS Proxy

RADIUS proxy

Network Policy Server (NPS) can be used as a RADIUS proxy to provide the routing of RADIUS messages between RADIUS clients (access servers) and RADIUS servers that perform user authentication, authorization, and accounting for the connection attempt. When used as a RADIUS proxy, NPS is a central switching or routing point through which RADIUS access and accounting messages flow. NPS records information in an accounting log about the messages that are forwarded.

The following illustration shows NPS as a RADIUS proxy between RADIUS clients (access servers) and either RADIUS servers or another RADIUS proxy.

NPS as a RADIUS proxy

When NPS is used as a RADIUS proxy between a RADIUS client and a RADIUS server, RADIUS messages for network access connection attempts are forwarded in the following way:

  1. Access servers, such as dial-up network access servers, virtual private network (VPN) servers, and wireless access points, receive connection requests from access clients.

  2. The access server, configured to use RADIUS as the authentication, authorization, and accounting protocol, creates an Access-Request message and sends it to the NPS server that is being used as the NPS RADIUS proxy.

  3. The NPS RADIUS proxy receives the Access-Request message and, based on the locally configured connection request policies, determines where to forward the Access-Request message.

  4. The NPS RADIUS proxy forwards the Access-Request message to the appropriate RADIUS server.

  5. The RADIUS server evaluates the Access-Request message.

  6. If required, the RADIUS server sends an Access-Challenge message to the NPS RADIUS proxy, where it is forwarded to the access server. The access server processes the challenge with the access client and sends an updated Access-Request to the NPS RADIUS proxy, where it is forwarded to the RADIUS server.

  7. The RADIUS server authenticates and authorizes the connection attempt.

  8. If the connection attempt is both authenticated and authorized, the RADIUS server sends an Access-Accept message to the NPS RADIUS proxy, where it is forwarded to the access server.

    If the connection attempt is either not authenticated or not authorized, the RADIUS server sends an Access-Reject message to the NPS RADIUS proxy, where it is forwarded to the access server.

  9. The access server completes the connection process with the access client and sends an Accounting-Request message to the NPS RADIUS proxy. The NPS RADIUS proxy logs the accounting data and forwards the message to the RADIUS server.

  10. The RADIUS server sends an Accounting-Response to the NPS RADIUS proxy, where it is forwarded to the access server.

You can use NPS as a RADIUS proxy when:

  • You are a service provider who offers outsourced dial, VPN, or wireless network access services to multiple customers. Your network access servers send connection requests to the NPS RADIUS proxy. Based on the realm portion of the user name in the connection request, the NPS RADIUS proxy forwards the connection request to a RADIUS server that is maintained by the customer and can authenticate and authorize the connection attempt. For more information, see Realm Names.

  • You want to provide authentication and authorization for user accounts that are not members of either the domain in which the NPS server is a member or another domain that has a two-way trust with the domain in which the NPS server is a member. This includes accounts in untrusted domains, one-way trusted domains, and other forests. Instead of configuring your access servers to send their connection requests to an NPS RADIUS server, you can configure them to send their connection requests to an NPS RADIUS proxy. The NPS RADIUS proxy uses the realm name portion of the user name and forwards the request to an NPS server in the correct domain or forest. Connection attempts for user accounts in one domain or forest can be authenticated for network access servers in another domain or forest.

    NPS supports authentication across forests without a RADIUS proxy when the two forests contain only domains that consist of domain controllers running Microsoft® Windows Server® 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. The forest functional level must be Windows Server 2003, and there must be a two-way trust relationship between forests. If you use EAP-TLS with certificates as your authentication method, however, you must use a RADIUS proxy for authentication across forests that consist of Windows Server 2003 domains.

  • You want to perform authentication and authorization by using a database that is not a Windows account database. In this case, connection requests that match a specified realm name are forwarded to a RADIUS server, which has access to a different database of user accounts and authorization data. Examples of other user databases include Novell Directory Services (NDS) and Structured Query Language (SQL) databases.

  • You want to process a large number of connection requests. In this case, instead of configuring your RADIUS clients to attempt to balance their connection and accounting requests across multiple RADIUS servers, you can configure them to send their connection and accounting requests to an NPS RADIUS proxy. The NPS RADIUS proxy dynamically balances the load of connection and accounting requests across multiple RADIUS servers and increases the processing of large numbers of RADIUS clients and authentications per second.

  • You want to provide RADIUS authentication and authorization for outsourced service providers and minimize intranet firewall configuration. An intranet firewall is between your perimeter network (the network between your intranet and the Internet) and intranet. By placing a NPS server on your perimeter network, the firewall between your perimeter network and intranet must allow traffic to flow between the NPS server and multiple domain controllers. When replacing the NPS server with an NPS proxy, the firewall must allow only RADIUS traffic to flow between the NPS proxy and one or multiple NPS servers within your intranet.

See Also

  • Planning RADIUS Proxy Deployment


Planning RADIUS Proxy Deployment

For information about planning the deployment of a RADIUS proxy, see the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=93778).


Realm Names

Realm names

The User-Name RADIUS attribute is a character string that typically contains a user account location and a user account name. The user account location is also called the realm or realm name, and is synonymous with the concept of domain, including DNS domains, Active Directory® domains, and Windows NT 4.0 domains. For example, if a user account is located in the user accounts database for a domain named example.com, then example.com is the realm name.

In another example, if the User-Name RADIUS attribute contains the user name user1@example.com, user1 is the user account name and example.com is the realm name. Realm names can be presented in the user name as a prefix or as a suffix:

  • Example\user1. In this example, the realm name Example is a prefix; and it is also the name of a Windows NT 4.0 domain.

  • user1@example.com. In this example, the realm name example.com is a suffix; and it is either a DNS domain name or the name of an Active Directory domain.

You can use realm names configured in connection request policies while designing and deploying your RADIUS infrastructure to ensure that connection requests are routed from RADIUS clients, also called network access servers, to RADIUS servers that can authenticate and authorize the connection request.

When NPS is configured as a RADIUS server with the default connection request policy, NPS processes connection requests for the domain in which the NPS server is a member and for trusted domains.

To configure NPS to act as a RADIUS proxy and forward connection requests to untrusted domains, you must create a new connection request policy. In the new connection request policy, you must configure the User Name attribute with the realm name that will be contained in the User-Name attribute of connection requests that you want to forward. You must also configure the connection request policy with a remote RADIUS server group. The connection request policy allows NPS to calculate which connection requests to forward to the remote RADIUS server group based on the realm portion of the User-Name attribute.

Acquiring the realm name

The realm name portion of the user name is provided when the user types password-based credentials during a connection attempt or when a Connection Manager (CM) profile on the user's computer is configured to provide the realm name automatically.

You can designate that users of your network provide their realm name when typing their credentials during network connection attempts.

For example, you can require users to type their user name, including the user account name and the realm name, in User name in the Connect dialog box when making a dial-up or virtual private network (VPN) connection.

In addition, if you create a custom dialing package with the Connection Manager Administration Kit (CMAK), you can assist users by adding the realm name automatically to the user account name in CM profiles that are installed on users' computers. For example, you can specify a realm name and user name syntax in the CM profile so that the user only has to specify the user account name when typing credentials. In this circumstance, the user does not need to know or remember the domain where their user account is located.

During the authentication process, after users type their password-based credentials, the user name is passed from the access client to the network access server. The network access server constructs a connection request and includes the realm name within the User-Name RADIUS attribute in the Access-Request message that is sent to the RADIUS proxy or server.

If the RADIUS server is an NPS server, the Access-Request message is evaluated against the set of configured connection request policies. Conditions on the connection request policy can include the specification of the contents of the User-Name attribute.

You can configure a set of connection request policies that are specific to the realm name within the User-Name attribute of incoming messages. This allows you to create routing rules that forward RADIUS messages with a specific realm name to a specific set of RADIUS servers when NPS is used as a RADIUS proxy.

Attribute manipulation rules

Before the RADIUS message is either processed locally (when NPS is being used as a RADIUS server) or forwarded to another RADIUS server (when NPS is being used as a RADIUS proxy), the User-Name attribute in the message can be modified by attribute manipulation rules. You can configure attribute manipulation rules for the User-Name attribute by selecting User name on the Conditions tab in the properties of a connection request policy. NPS attribute manipulation rules use regular expression syntax.

You can configure attribute manipulation rules for the User-Name attribute to change the following:

  • Remove the realm name from the user name (also known as realm stripping).

    For example, the user name user1@example.com is changed to user1.

  • Change the realm name but not its syntax.

    For example, the user name user1@example.com is changed to user1@wcoast.example.com.

  • Change the syntax of the realm name.

    For example, the user name example\user1 is changed to user1@example.com.

After the User-Name attribute is modified according to the attribute manipulation rules that you configure, additional settings of the first matching connection request policy are used to determine whether:

  • The NPS server processes the Access-Request message locally (when NPS is being used as a RADIUS server).

  • The NPS server forwards the message to another RADIUS server (when NPS is being used as a RADIUS proxy).

Caution

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

Note

When the user name does not contain a domain name, NPS supplies one. By default, the NPS-supplied domain name is the domain of which the NPS server is a member. You can specify the NPS-supplied domain name through the following registry setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn\DefaultDomain

Some non-Microsoft network access servers delete or modify the domain name as specified by the user. As the result, the network access request is authenticated against the default domain, which might not be the domain for the user's account. To resolve this problem, configure your RADIUS servers to change the user name into the correct format with the accurate domain name.


Using Regular Expressions in NPS

Using regular expressions in NPS

Network Policy Server (NPS) in Windows Server® 2008 supports the use of regular expressions for pattern matching. You can use this syntax to specify the conditions of network policy attributes and RADIUS realms.

Pattern-matching reference

You can use the following table as a reference source when creating regular expressions with pattern-matching syntax.

Character | Description | Example
\ | Marks the next character as a character to match. | /n/ matches the character "n". The sequence /\n/ matches a line feed or newline character.
^ | Matches the beginning of the input or line. |
$ | Matches the end of the input or line. |
* | Matches the preceding character zero or more times. | /zo*/ matches either "z" or "zoo."
+ | Matches the preceding character one or more times. | /zo+/ matches "zoo" but not "z."
? | Matches the preceding character zero or one times. | /a?ve?/ matches the "ve" in "never."
. | Matches any single character except a newline character. |
( pattern ) | Matches pattern and remembers the match. To match ( ) (parentheses), use "\(" or "\)". |
x | y | Matches either x or y. | /z|food?/ matches "zoo" or "food."
{ n } | Matches exactly n times (n is a nonnegative integer). | /o{2}/ does not match the "o" in "Bob," but matches the first two instances of the letter o in "foooood."
{ n ,} | Matches at least n times (n is a nonnegative integer). | /o{2,}/ does not match the "o" in "Bob" but matches all of the instances of the letter o in "foooood." /o{1,}/ is equivalent to /o+/.
{ n , m } | Matches at least n and at most m times (m and n are nonnegative integers). | /o{1,3}/ matches the first three instances of the letter o in "fooooood."
[ xyz ] | Matches any one of the enclosed characters (a character set). | /[abc]/ matches the "a" in "plain."
[^ xyz ] | Matches any characters that are not enclosed (a negative character set). | /[^abc]/ matches the "p" in "plain."
\b | Matches a word boundary (for example, a space). | /ea*r\b/ matches the "er" in "never early."
\B | Matches a nonword boundary. | /ea*r\B/ matches the "ear" in "never early."
\d | Matches a digit character (equivalent to [0-9]). |
\D | Matches a nondigit character (equivalent to [^0-9]). |
\f | Matches a form feed character. |
\n | Matches a line feed character. |
\r | Matches a carriage return character. |
\s | Matches any white space character including space, tab, and form feed (equivalent to [ \f\n\r\t\v]). |
\S | Matches any non-white space character (equivalent to [^ \f\n\r\t\v]). |
\t | Matches a tab character. |
\v | Matches a vertical tab character. |
\w | Matches any word character, including underscore (equivalent to [A-Za-z0-9_]). |
\W | Matches any nonword character, excluding underscore (equivalent to [^A-Za-z0-9_]). |
\ num | Refers to remembered matches (?num, where num is a positive integer). For example, \1 replaces what is stored in the first remembered match. This option can be used only in the Replace text box when configuring attribute manipulation. |
/ n / | Allows the insertion of ASCII codes into regular expressions (?n, where n is an octal, hexadecimal, or decimal escape value). |

Examples for network policy attributes

The following examples describe the use of the pattern-matching syntax to specify network policy attributes:

  • To specify all phone numbers within the 899 area code, the syntax is:

    899.*

  • To specify a range of all IP addresses that begin with 192.168.1, the syntax is:

    192\.168\.1\..+

Examples for manipulation of the realm name in the User Name attribute

The following examples describe the use of the pattern-matching syntax to manipulate realm names for the User Name attribute, which is located on the Attribute tab in the properties of a connection request policy.

  • To remove the realm portion of the User Name attribute

    In an outsourced dial-up scenario in which an Internet service provider (ISP) routes connection requests to an organization NPS server, the ISP RADIUS proxy might require a realm name to route the authentication request. However, the NPS server might not recognize the realm name portion of the user name. Therefore, the realm name must be removed by the ISP RADIUS proxy before it is forwarded to the organization NPS server.

    • Find: @microsoft\.com

    • Replace:

  • To replace user@example.microsoft.com with example.microsoft.com\user

    • Find: (.*)@(.*)

    • Replace: $2\$1

  • To replace domain\user with specific_domain\user

    • Find: (.*)\\(.*)

    • Replace: specific_domain\$2

  • To replace user with user@specific_domain

    • Find: $

    • Replace: @specific_domain

Example for RADIUS message forwarding by a proxy server

You can create routing rules that forward RADIUS messages with a specified realm name to a set of RADIUS servers when NPS is used as a RADIUS proxy. Following is a recommended syntax for routing requests based on realm name.

NetBIOS name | Pattern
WCOAST | ^wcoast\\

In the following example, wcoast.microsoft.com is a unique user principal name (UPN) suffix for the DNS or Active Directory domain wcoast.microsoft.com. Using the supplied pattern, the NPS proxy can route messages based on domain NetBIOS name or UPN suffix.

NetBIOS name | UPN suffix | Pattern
WCOAST | wcoast.microsoft.com | ^wcoast\\|@wcoast\.microsoft\.com$

Ping user-name

Some RADIUS proxy servers and network access servers periodically send authentication and accounting requests (known as ping requests) to verify that the NPS server is present on the network. These ping requests include fictional user names. When NPS processes these requests, the event and accounting logs become filled with access reject records, making it more difficult to keep track of valid records.

When you configure a registry entry for ping user-name, NPS matches the registry entry value against the user name value in ping requests by other servers. A ping user-name registry entry specifies the fictional user name (or a user name pattern, with variables, that matches the fictional user name) sent by RADIUS proxy servers and network access servers. When NPS receives ping requests that match the ping user-name registry entry value, NPS rejects the authentication requests without processing the request. NPS does not record transactions involving the fictional user name in any log files, which makes the event log easier to interpret.

Note

Ping user-name is not installed by default. You must add ping user-name to the registry. You can add an entry to the registry using Registry Editor.

Caution

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

Adding ping user-name to the registry

Ping user-name can be added to the following registry key as a string value by a member of the local Administrators group:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IAS\Parameters

Name | Type | Data
ping user-name | REG_SZ | User name
Note

To indicate more than one user name for a ping user-name value, enter a name pattern, such as a DNS name, including wildcard characters, in Data.


Connection Request Processing

Connection request processing

You can use connection request processing to specify where the authentication of connection requests is performed. If you want the local server running Network Policy Server (NPS) to perform authentication for connection requests, you can use the default 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, Terminal Services Gateway (TS°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, start with Connection Request Policies.

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

See Also

  • Connection Request Policies
  • Remote RADIUS Server Groups


Connection Request Policies

Connection Request Policies

Connection request policies are sets of conditions and settings that allow network administrators to designate which RADIUS servers perform the authentication and authorization of connection requests that the server running Network Policy Server (NPS) receives from RADIUS clients. Connection request policies can be configured to designate which RADIUS servers are used for RADIUS accounting.

Important

When you deploy Network Access Protection (NAP) using the VPN or 802.1X enforcement methods with PEAP authentication, you must configure PEAP authentication in connection request policy even when connection requests are processed locally.

You can create connection request policies so that some RADIUS request messages sent from RADIUS clients are processed locally (NPS is being used as a RADIUS server) and other types of messages are forwarded to another RADIUS server (NPS is being used as a RADIUS proxy).

With connection request policies, you can use NPS as a RADIUS server or as a RADIUS proxy, based on factors like the following:

  • The time of day and day of the week

  • The realm name in the connection request

  • The type of connection being requested

  • The IP address of the RADIUS client

RADIUS Access-Request messages are processed or forwarded by NPS only if the settings of the incoming message match at least one of the connection request policies configured on the NPS server. If the policy settings match and the policy requires that the NPS server process the message, NPS acts as a RADIUS server, authenticating and authorizing the connection request. If the policy settings match and the policy requires that the NPS server forwards the message, NPS acts as a RADIUS proxy and forwards the connection request to a remote RADIUS server for processing.

If the settings of an incoming RADIUS Access-Request message do not match at least one of the connection request policies, an Access-Reject message is sent to the RADIUS client and the user or computer attempting to connect to the network is denied access.

Configuration examples

The following configuration examples demonstrate how connection request policies can be used.

  • NPS as a RADIUS server

    The default connection request policy is the only configured policy. In this example, NPS is configured as a RADIUS server and all connection requests are processed by the local NPS server. The NPS server can authenticate and authorize users whose accounts are in the domain of the NPS server domain and in trusted domains.

  • NPS as a RADIUS proxy

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

  • NPS as both RADIUS server and RADIUS proxy

    In addition to the default connection request policy, a new connection request policy is created that forwards connection requests to an NPS or other RADIUS server in an untrusted domain. In this example, the proxy policy appears first in the ordered list of policies. If the connection request matches the proxy policy, the connection request is forwarded to the RADIUS server in the remote RADIUS server group. If the connection request does not match the proxy policy but does match the default connection request policy, NPS processes the connection request on the local server. If the connection request does not match either policy, it is discarded.

  • NPS as RADIUS server with remote accounting servers

    In this example, the local NPS server is not configured to perform accounting and the default connection request policy is revised so that RADIUS accounting messages are forwarded to an NPS or other RADIUS server in a remote RADIUS server group. Although accounting messages are forwarded, authentication and authorization messages are not forwarded, and the local NPS server performs these functions for the local and all trusted domains.

  • NPS with Remote RADIUS to Windows User Mapping

    In this example, NPS acts as both a RADIUS server and as a RADIUS proxy for each individual connection request by forwarding the authentication request to a remote RADIUS server while using a local Windows user account for authorization. This configuration is implemented by configuring the Remote RADIUS to Windows User Mapping attribute as a condition of the connection request policy. (In addition, a user account must be created locally that has the same name as the remote user account against which authentication is performed by the remote RADIUS server.)

Conditions

Connection request policy conditions are one or more RADIUS attributes that are compared to the attributes of the incoming RADIUS Access-Request message. If there are multiple conditions, then all of the conditions in the connection request message and in the connection request policy must match in order for the policy to be enforced by NPS.

Following are the available condition attributes that you can configure in connection request policies.

The Connection Properties attribute group contains the following attributes.

  • Framed Protocol. Used to designate the type of framing for incoming packets. Examples are PPP, SLIP, Frame Relay, and X.25.

  • Service Type. Used to designate the type of service being requested. Examples include framed (for example, PPP connections) and login (for example, Telnet connections). For more information about RADIUS service types, see RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)."

  • Tunnel Type. Used to designate the type of tunnel that is being created by the requesting client. Tunnel types include the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol (L2TP).

The Day and Time Restrictions attribute group contains the Day and Time Restrictions attribute. With this attribute, you can designate the day of the week and the time of day of the connection attempt. The day and time is relative to the day and time of the NPS server.

The Gateway attribute group contains the following attributes.

  • Called Station ID. Used to designate the phone number of the network access server. This attribute is a character string. You can use pattern-matching syntax to specify area codes.

  • NAS Identifier. Used to designate the name of the network access server. This attribute is a character string. You can use pattern-matching syntax to specify NAS identifiers.

  • NAS IPv4 Address. Used to designate the Internet Protocol version 4 (IPv4) address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern-matching syntax to specify IP networks.

  • NAS IPv6 Address. Used to designate the Internet Protocol version 6 (IPv6) address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern-matching syntax to specify IP networks.

  • NAS Port Type. Used to designate the type of media used by the access client. Examples are analog phone lines (known as async), ISDN, tunnels or virtual private networks (VPNs), IEEE 802.11 wireless, and Ethernet switches.

The Machine Identity attribute group contains the Machine Identity attribute. With this attribute, you can specify the method with which clients are identified in the policy.

The RADIUS Client Properties attribute group contains the following attributes.

  • Calling Station ID. Used to designate the phone number used by the caller (the access client). This attribute is a character string. You can use pattern-matching syntax to specify area codes.

  • Client Friendly Name. Used to designate the name of the RADIUS client computer that is requesting authentication. This attribute is a character string. You can use pattern-matching syntax to specify client names.

  • Client IPv4 Address. Used to designate the IPv4 address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern-matching syntax to specify IP networks.

  • Client IPv6 Address. Used to designate the IPv6 address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern-matching syntax to specify IP networks.

  • Client Vendor. Used to designate the vendor of the network access server that is requesting authentication. A computer running the Routing and Remote Access service is the Microsoft NAS manufacturer. You can use this attribute to configure separate policies for different NAS manufacturers. This attribute is a character string. You can use pattern-matching syntax.

The User Name attribute group contains the User Name attribute. With this attribute, you can designate the user name, or a portion of the user name, that must match the user name supplied by the access client in the RADIUS message. This attribute is a character string that typically contains a realm name and a user account name. You can use pattern-matching syntax to specify user names.

Settings

Connection request policy settings are a set of properties that are applied to an incoming RADIUS message. Settings consist of the following groups of properties:

  • Authentication

  • Accounting

  • Attribute manipulation

  • Advanced

Authentication

With this setting, you can override the authentication settings that are configured in all network policies and you can designate the authentication methods and types that are required to connect to your network.

Important

If you configure an authentication method in connection request policy that is less secure than the authentication method you configure in network policy, the more secure authentication method that you configure in network policy will be overridden. For example, if you have one network policy that requires the use of PEAP-MS-CHAP v2, which is a password-based authentication method for secure wireless, and you also configure a connection request policy to allow unauthenticated access, no clients are required to authenticate using PEAP-MS-CHAP v2. In this example, all clients connecting to your network are granted unauthenticated access.

Accounting

With this setting, you can configure connection request policy to forward accounting information to a server running NPS or other RADIUS server in a remote RADIUS server group so that the remote RADIUS server group performs accounting.

Note

If you have multiple RADIUS servers and you want accounting information for all servers stored in one central RADIUS accounting database, you can use the connection request policy accounting setting in a policy on each RADIUS server to forward accounting data from all of the servers to one NPS or other RADIUS server that is designated as an accounting server.

Connection request policy accounting settings function independent of the accounting configuration of the local NPS server. In other words, if you configure the local NPS server to log RADIUS accounting information to a local file or to a Microsoft® SQL Server™ database, it will do so regardless of whether you configure a connection request policy to forward accounting messages to a remote RADIUS server group.

If you want accounting information logged remotely but not locally, you must configure the local NPS server to not perform accounting, while also configuring accounting in a connection request policy to forward accounting data to a remote RADIUS server group.

Attribute manipulation

You can configure a set of find-and-replace rules that manipulate the text strings of one of the following attributes:

  • User Name

  • Called Station ID

  • Calling Station ID

Find-and-replace rule processing occurs for one of the preceding attributes before the RADIUS message is subject to authentication and accounting settings. Attribute manipulation rules apply only to a single attribute. You cannot configure attribute manipulation rules for each attribute. In addition, the list of attributes that you can manipulate is a static list; you cannot add to the list of attributes available for manipulation.

Note

If you are using the MS-CHAP v2 authentication protocol, you cannot manipulate the User Name attribute if the connection request policy is used to forward the RADIUS message. The only exception occurs when a backslash (\) character is used and the manipulation only affects the information to the left of it. A backslash character is typically used to indicate a domain name (the information to the left of the backslash character) and a user account name within the domain (the information to the right of the backslash character). In this case, only attribute manipulation rules that modify or replace the domain name are allowed.

Forwarding request

You can set the following forwarding request options that are used for RADIUS Access-Request messages:

Authenticate requests on this server. With this setting, NPS uses a Windows NT 4.0 domain, Active Directory, or the local Security Accounts Manager (SAM) user accounts database to authenticate the connection request. This setting also specifies that the matching network policy configured in NPS, along with the dial-in properties of the user account, are used by NPS to authorize the connection request. In this case, the NPS server is configured to perform as a RADIUS server.

Forward requests to the following remote RADIUS server group. With this setting, NPS forwards connection requests to the remote RADIUS server group that you specify. If the NPS server receives a valid Access-Accept message that corresponds to the Access-Request message, the connection attempt is considered authenticated and authorized. In this case, the NPS server acts as a RADIUS proxy.

Accept users without validating credentials. With this setting, NPS does not verify the identity of the user attempting to connect to the network and NPS does not attempt to verify that the user or computer has the right to connect to the network. When NPS is configured to allow unauthenticated access and it receives a connection request, NPS immediately sends an Access-Accept message to the RADIUS client and the user or computer is granted network access. This setting is used for some types of compulsory tunneling where the access client is tunneled before the user's credentials are authenticated.

Note

This authentication option cannot be used when the authentication protocol of the access client is MS-CHAP v2 or EAP-TLS, both of which provide mutual authentication. In mutual authentication, the access client proves that it is a valid access client to the authenticating server (the NPS server), and the authenticating server proves that it is a valid authenticating server to the access client. When this authentication option is used, the Access-Accept message is returned. However, the authenticating server does not provide validation to the access client and mutual authentication fails.

Advanced

You can set advanced properties to specify the series of RADIUS attributes that are:

  • Added to the RADIUS response message when the NPS server is being used as a RADIUS authentication or accounting server.

    When there are attributes specified on both a network policy and the connection request policy, the attributes that are sent in the RADIUS response message are the combination of the two sets of attributes.

  • Added to the RADIUS message when the NPS server is being used as a RADIUS authentication or accounting proxy. If the attribute already exists in the message that is forwarded, it is replaced with the value of the attribute specified in the connection request policy.

In addition, some attributes that are available for configuration on the connection request policy Settings tab in the Advanced category provide specialized functionality. For example, you can configure the Remote RADIUS to Windows User Mapping attribute when you want to split the authentication and authorization of a connection request between two user accounts databases.

The Remote RADIUS to Windows User Mapping attribute specifies that Windows authorization occurs for users who are authenticated by a remote RADIUS server. In other words, a remote RADIUS server performs authentication against a user account in a remote user accounts database, but the local NPS server authorizes the connection request against a user account in a local user accounts database. This is useful when you want to allow visitors access to your network.

For example, visitors from partner organizations can be authenticated by their organization's RADIUS server, and can use a Windows user account at your organization to access a guest local area network (LAN) on your network.

Other attributes that provide specialized functionality are:

  • MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout. These attributes are used when you deploy Network Access Quarantine Control (NAQC) with your Routing and Remote Access VPN deployment.

  • Passport-User-Mapping-UPN-Suffix. This attribute allows you to authenticate connection requests with Windows Live™ ID user account credentials.

  • Tunnel-Tag. This attribute designates the VLAN ID number to which the connection should be assigned by the NAS when you deploy virtual local area networks (VLANs).

Default connection request policy

A default connection request policy is created when you install NPS. This policy has the following configuration:

  • Authentication is not configured.

  • Accounting is not configured to forward accounting information to a remote RADIUS server group.

  • Attribute is not configured with attribute manipulation rules that forward connection requests to remote RADIUS server groups.

  • Forwarding Request is configured so that connection requests are authenticated and authorized on the local NPS server.

  • Advanced attributes are not configured.

The default connection request policy uses NPS as a RADIUS server. To configure a server running NPS to act as a RADIUS proxy, you must also configure a remote RADIUS server group. You can create a new remote RADIUS server group while you are creating a new connection request policy with the New Connection Request Policy Wizard. You can either delete the default connection request policy or verify that the default connection request policy is the last policy processed.

Note

If NPS and the Routing and Remote Access service are installed on the same computer, and the Routing and Remote Access service is configured for Windows authentication and accounting, it is possible for Routing and Remote Access authentication and accounting requests to be forwarded to a RADIUS server. This can occur when Routing and Remote Access authentication and accounting requests match a connection request policy that is configured to forward them to a remote RADIUS server group.


Add a Connection Request Policy

Add a connection request policy

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

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 during the process of 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 using the Windows interface

  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

Remote RADIUS server groups

When you configure Network Policy Server (NPS) as a 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

    For more information, see RADIUS Protocol and Components, Shared Secrets for NPS and RADIUS Clients, and RADIUS Clients.

  • 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

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 with 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 using the Windows interface

  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

RADIUS server

Network Policy Server (NPS) can be used as a RADIUS server to perform authentication, authorization, and accounting for RADIUS clients. A RADIUS client can be either a network access server or a RADIUS proxy. When NPS is used as a RADIUS server, it provides the following:

  • A central authentication and authorization service for all access requests that are sent by RADIUS clients.

    NPS uses a Microsoft® Windows NT® Server 4.0 domain, an Active Directory® domain, or the local Security Accounts Manager (SAM) user accounts database to authenticate user credentials for connection attempts. NPS uses the dial-in properties of the user account and network policies to authorize a connection.

  • A central accounting recording service for all accounting requests that are sent by RADIUS clients.

    Accounting requests are stored in a local log file or Microsoft® SQL Server™ database for analysis.

The following illustration shows NPS as a RADIUS server for a variety of access clients, and also shows a RADIUS proxy. NPS uses an Active Directory® domain for user credential authentication of incoming RADIUS Access-Request messages.

NPS as a RADIUS server

When NPS is used as a RADIUS server, RADIUS messages provide authentication, authorization, and accounting for network access connections in the following way:

  1. Access servers, such as dial-up network access servers, VPN servers, and wireless access points, receive connection requests from access clients.

  2. The access server, configured to use RADIUS as the authentication, authorization, and accounting protocol, creates an Access-Request message and sends it to the NPS server.

  3. The NPS server evaluates the Access-Request message.

  4. If required, the NPS server sends an Access-Challenge message to the access server. The access server processes the challenge and sends an updated Access-Request to the NPS server.

  5. The user credentials are checked and the dial-in properties of the user account are obtained by using a secure connection to a domain controller.

  6. The connection attempt is authorized with both the dial-in properties of the user account and network policies.

  7. If the connection attempt is both authenticated and authorized, the NPS server sends an Access-Accept message to the access server.

    If the connection attempt is either not authenticated or not authorized, the NPS server sends an Access-Reject message to the access server.

  8. The access server completes the connection process with the access client and sends an Accounting-Request message to the NPS server, where the message is logged.

  9. The NPS server sends an Accounting-Response to the access server.

Note

The access server also sends Accounting-Request messages during the time in which the connection is established, when the access client connection is closed, and when the access server is started and stopped.

You can use NPS as a RADIUS server when:

  • You are using a Windows NT Server 4.0 domain, an Active Directory domain, or the local SAM user accounts database as your user account database for access clients.

  • You are using Routing and Remote Access on multiple dial-up servers, VPN servers, or demand-dial routers and you want to centralize both the configuration of network policies and connection logging for accounting.

  • You are outsourcing your dial-up, VPN, or wireless access to a service provider. The access servers use RADIUS to authenticate and authorize connections that are made by members of your organization.

  • You want to centralize authentication, authorization, and accounting for a heterogeneous set of access servers.

Note

In Internet Authentication Service (IAS) in the Windows Server® 2003 operating systems, network policies are referred to as remote access policies.


Planning RADIUS Server Deployment

For information about planning the deployment of a RADIUS server, see the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=93778).


RADIUS Server for 802.1X Wireless or Wired Connections

RADIUS server for 802.1X wireless or wired connections

When you deploy 802.1X wired or wireless access with NPS as a RADIUS server, you must take the following steps:

  • Install and configure network access servers (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 laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

In both cases, these network access servers must meet the following requirements:

  • Support for 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 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 access servers 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 access server 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 network access servers 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 network access servers must filter on IP ports to prevent the transmission of 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 network access servers must filter on IP ports to prevent a client from performing as a DNS server. The network access servers 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 Certificates and NPS, 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 or a remote computer.

For more information, see RADIUS Accounting.

See Also

  • Planning RADIUS Server Deployment
  • RADIUS Clients
  • Network Policies
  • RADIUS Accounting


RADIUS Server for Dial-Up or VPN Connections

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 (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 laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

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 Certificates and NPS, 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 your NPS server IP address 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 or a remote computer.

For more information, see RADIUS Accounting.


Network Policies

Network Policies

Network policies are sets of conditions, constraints, and settings that allow you to designate who is authorized to connect to the network and the circumstances under which they can or cannot connect. When you deploy Network Access Protection (NAP), health policy is added to the network policy configuration so that NPS performs client health checks during the authorization process.

When processing connection requests as a RADIUS server, Network Policy Server (NPS) performs both authentication and authorization for the connection request. During the authentication process, NPS verifies the identity of the user or computer that is connecting to the network. During the authorization process, NPS determines whether the user or computer is allowed to access the network.

To make this determination, NPS uses network policies that are configured in the NPS Microsoft Management Console (MMC) snap-in. NPS also examines the dial-in properties of the user account in Active Directory Domain Services (AD DS) to perform authorization.

Note

In Internet Authentication Service (IAS) in the Windows Server® 2003 operating systems, network policies were called remote access policies.

Network policies can be viewed as rules. Each rule has a set of conditions and settings. NPS compares the conditions of the rule to the properties of connection requests. If a match occurs between the rule and the connection request, the settings defined in the rule are applied to the connection.

When multiple network policies are configured in NPS, they are an ordered set of rules. NPS checks each connection request against the first rule in the list, then the second, and so on, until a match is found.

Each network policy has a Policy State setting that allows you to enable or disable the policy. When you disable a network policy, NPS does not evaluate the policy when authorizing connection requests.

Important

If you want NPS to evaluate a network policy when performing authorization for connection requests, you must configure the Policy State setting by selecting the Policy enabled check box.

Network policy properties

There are four categories of properties for each network policy:

  • Overview

    These properties allow you to specify whether the policy is enabled, whether the policy grants or denies access, and whether a specific network connection method, or type of network access server, is required for connection requests. Overview properties also allow you to specify whether the dial-in properties of user accounts in AD DS are ignored. If you select this option, only the settings in the network policy are used by NPS to determine whether the connection is authorized. For more information, see Network Policy Overview Properties.

  • Conditions

    These properties allow you to specify the conditions that the connection request must have in order to match the network policy; if the conditions configured in the policy match the connection request, NPS applies the settings designated in the network policy to the connection. For example, if you specify the network access server IPv4 address (NAS IPv4 Address) as a condition of the network policy and NPS receives a connection request from a NAS that has the specified IP address, the condition in the policy matches the connection request. For more information, see Network Policy Conditions Properties.

  • Constraints

    Constraints are additional parameters of the network policy that are required to match the connection request. If a constraint is not matched by the connection request, NPS automatically rejects the request. Unlike the NPS response to unmatched conditions in the network policy, if a constraint is not matched, NPS does not evaluate additional network policies; the connection request is just denied. For more information, see Network Policy Constraints Properties.

  • Settings

    These properties allow you to specify the settings that NPS applies to the connection request if all of the network policy conditions for the policy are matched. For more information, see Network Policy Settings Properties.

When you add a new network policy using the NPS MMC snap-in, you must use the New Network Policy Wizard. After you have created a network policy using the wizard, you can customize the policy by double-clicking the policy in NPS to obtain the policy properties.


Access Permission

Access permission

Access permission is configured on the Overview tab of each network policy and allows you to configure the policy to either grant or deny access to users if the conditions and constraints of the network policy are matched by the connection request. Access permission settings have the following effect:

  • Grant access. Access is granted if the connection request matches the conditions and constraints that are configured in the policy.

  • Deny access. Access is denied if the connection request matches the conditions and constraints that are configured in the policy.

Access permission is also granted or denied with the dial-in properties of each user account.

Note

User accounts and their properties, such as dial-in properties, are configured in either the Active Directory Users and Computers or the Local Users and Groups Microsoft Management Console (MMC) snap-in, depending on whether you have Active Directory Domain Services (AD DS) installed.

The user account setting Network Access Permission, which is configured on the dial-in properties of user accounts, overrides the network policy access permission setting. When network access permission on a user account is set to the Control access through NPS Network Policy option, the network policy access permission setting determines whether the user is granted or denied access.

When Network Policy Server (NPS) evaluates connection requests against configured network policies, it performs the following actions:

  • If the conditions of the first policy are not matched, NPS evaluates the next policy, and continues this process until either a match is found or all policies have been evaluated for a match.

  • If the conditions and constraints of a policy are matched, NPS either grants or denies access, depending on the value of the Access permission setting in the policy.

  • If the conditions of a policy match but the constraints in the policy do not match, NPS rejects the connection request.

  • If the conditions of all policies do not match, NPS rejects the connection request.

Ignore user account dial-in properties

You can configure NPS network policy to ignore the dial-in properties of user accounts by selecting or clearing the Ignore user account dial-in properties check box on the Overview tab of network policy. Normally when NPS performs authorization of a connection request, it checks the dial-in properties of the user account, where the network access permission setting value can affect whether the user is authorized to connect to the network. When you configure NPS to ignore the dial-in properties of user accounts during authorization, network policy settings determine whether the user is granted access to the network.

The dial-in properties of user accounts contain the following:

  • Network access permission

  • Caller-ID

  • Callback options

  • Static IP address

  • Static routes

To support multiple types of connections for which NPS provides authentication and authorization, it might be necessary to disable the processing of user account dial-in properties. This can be done to support scenarios in which specific dial-in properties are not required.

For example, the caller-ID, callback, static IP address, and static routes properties are designed for a client that is dialing into a network access server, not for clients that are connecting to wireless access points. A wireless access point that receives these settings in a RADIUS message from NPS might not be able to process them, which could cause the wireless client to be disconnected.

When NPS provides authentication and authorization for users who are both dialing in and accessing the organization network through wireless access points, the dial-in properties must be configured to support either dial-in connections (by setting dial-in properties) or wireless connections (by not setting dial-in properties).

You can use NPS to enable dial-in properties processing for the user account in some scenarios (such as dial-in) and to disable dial-in properties processing in other scenarios (such as 802.1X wireless and authenticating switch).

You can also use Ignore user account dial-in properties to manage network access control through groups and the access permission setting on the network policy. When you configure Ignore user account dial-in properties with the value of True (selected), network access permission on the user account is ignored.

The only disadvantage to this configuration is that you cannot use the additional user account dial-in properties of caller-ID, callback, static IP address, and static routes.


Create a Group for a Network Policy

You can use this procedure to create a user or computer group in Active Directory® Domain Services (AD DS) and then add the group as a condition in a Network Policy Server (NPS) network policy.

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

Create a group for a network policy

To create a group for a network policy

  1. Open the Active Directory Users and Computers console, and then click the domain where you want to create a group.

  2. To create a group whose members are computers, in the details pane, right-click Computers, click New, and then click Group. To create a group whose members are users, in the details pane, right-click Users, click New, and then click Group. The New Object - Group dialog box opens.

  3. In New Object - Group, in Group name, type a name for the group.

  4. In Group scope, select Domain local, Global, or Universal.

  5. In Group type, ensure that Security is selected, and then click OK.

  6. Double-click either Computers or Users, depending on where you created your group, and then double-click the group you created to open group properties.

  7. In group properties, click the Members tab, and then click Add. The Select Users, Contacts, Computers, or Groups dialog box opens.

  8. In Select Users, Contacts, Computers, or Groups, in Enter the object names to select, type the object names that you want to add to the group, and then click OK twice.

  9. Open the Network Policy Server console and double-click Policies. Right-click Network Policies, and then click New. The New Network Policy wizard opens.

  10. Run the wizard, making selections appropriate to your deployment, until you reach the Specify Conditions page.

  11. In Specify Conditions, click Add. The Select condition dialog box opens. If you created a group of computers, click Machine Groups. If you created a group of users, click User Groups. Click Add. The Windows Groups dialog box opens. Click Add Groups.

  12. The Select Group dialog box opens. In Enter the object name to select, type the name of the group that you created in AD DS, and then click OK.

  13. Configure additional conditions for your deployment as needed, and then continue running the New Network Policy wizard until you have completed creating a new network policy.
Note

To add a group as a condition of an existing network policy, see Add a Condition to a Network Policy.


Network Access Authorization

Network access authorization

Network access authorization is granted or denied on the basis of both Active Directory® user account dial-in properties and network policies that are configured in Network Policy Server (NPS).

Network policies allow you to grant or deny network access for users and computers that are members of Windows groups, while the network access permission setting on the dial-up properties of each user account in Active Directory Domain Services (AD DS) allows you to grant or deny network access for individual users. AD DS also allows you to designate that network access permission is granted based on network policy settings.

When designing your authorization scheme, you must determine whether you want to manage authorization by user or by group.

Authorization by user

If you are managing authorization by user, set the network access permission on the user or computer account to either Grant access or Deny access and, optionally, create different network policies based on different types of connections.

For example, you might want to create one network policy that is used for virtual private network (VPN) connections and a different network policy that is used for wireless connections.

Managing authorization by user is recommended only when you have a small number of user or computer accounts to manage.

If you are managing authorization by user, the basic process used by NPS to authorize a connection request occurs as follows:

  • If NPS finds that the connection request matches all of the conditions of the network policy, it checks the network access permission setting of the user account.

  • If the network access permission setting of the user account is set to grant access, NPS applies the network policy and user account connection settings to the connection, which is granted.

  • If the network access permission setting of the user account is set to deny access, NPS rejects the connection request.

  • If the connection request does not match all conditions of the first network policy, NPS processes the next network policy.

  • If the connection request does not match all conditions of any network policy, NPS rejects the connection request.

Authorization by group

If you are managing authorization by group, set the network access permission on the user account to Control access through NPS Network Policy and create network policies that are based on different types of connections and on Windows group membership.

For example, you might want to create one network policy for dial-up connections for employees (members of the Employees group that you have created in AD DS) and a different network policy for dial-up connections for contractors (members of the Contractors group that you have created in AD DS).

If you are managing authorization by group, the basic process used by NPS to authorize a connection request occurs as follows:

  • If NPS finds that the connection request matches all of the conditions of the network policy, it checks the Access Permission setting of the network policy.

  • If the Access Permission setting is configured to grant access, NPS applies the network policy and user account connection settings to the connection, which is granted.

  • If the Access Permission setting is configured to deny access, NPS rejects the connection request.

  • If the connection request does not match all conditions of the first network policy, NPS processes the next network policy.

  • If the connection request does not match all conditions of any network policy, NPS rejects the connection request.


Network Policy Conditions Properties

Network policy conditions

Every network policy must have at least one configured condition. NPS provides many conditions groups that allow you to clearly define the properties that the connection request received by NPS must have in order to match the policy.

The available condition groups are:

  • Groups

  • HCAP

  • Day and time restrictions

  • Network Access Protection

  • Connection properties

  • RADIUS client properties

  • Gateway

Groups

Groups conditions specify user or computer groups that you configure in Active Directory Domain Services (AD DS) and to which you want the other rules of the network policy to apply when group members attempt to connect to the network.

  • Windows Groups

    Specifies that the connecting user or computer must belong to one of the specified groups.

  • Machine Groups

    Specifies that the connecting computer must belong to one of the specified groups.

  • User Groups

    Specifies that the connecting user must belong to one of the specified groups.

HCAP

Host Credential Authorization Protocol (HCAP) conditions are used only when you want to integrate your NPS Network Access Protection (NAP) solution with Cisco Network Admission Control. To use these conditions, you must deploy Cisco Network Admission Control and NAP. You must also deploy a HCAP server running both Internet Information Services (IIS) and NPS. For more information, see Host Credential Authorization Protocol.

Following are the HCAP conditions you can configure in network policy.

  • Location Groups

    Specifies the user's or computer's HCAP location group membership required to match this policy.

  • HCAP User Groups

    Specifies the user's HCAP user group membership required to match this policy.

Day and time restrictions

  • Day and Time Restrictions

    Allows you to specify, at a weekly interval, whether connections are allowed or denied on a specific set of days and times.

    For example, you can configure this condition to allow access to your network only between the hours of 8 A.M. and 5 P.M. Monday through Thursday. With this condition value, users whose connection requests match all conditions of the network policy cannot connect to the network on Fridays, Saturdays, Sundays, and during other weekdays between the hours of 5 P.M. and 8 A.M., but they can connect between Monday and Thursday between 8 A.M. and 5 P.M.

    Conversely, you can specify the days and times when connections to the network are denied. If you specify days and times when connections are denied, users are allowed access to your network on the unspecified days and times. For example, if you configure this condition to deny connections all day on Sunday, users cannot connect at any time on Sundays, but they can connect Monday through Saturday at any time.

    To configure the Day and Time Restrictions condition, obtain the properties of a network policy, click the Conditions tab, and then click Add. Scroll to and click Day and Time Restrictions, and then click Add. In Time of day constraints, click Permitted, click the grid pattern of days and times, and then use your mouse to select the days and times that you want to specify.

Note

You can designate specific days and times when network access is allowed only if you select Permitted. If you select Denied, network access is always denied.

Network Access Protection

Following are the NAP conditions that you can configure in network policy.

  • Identity Type

    Used for NAP DHCP and IPsec deployments to allow client health checks in circumstances where NPS does not receive an Access-Request message that contains a value for the User-Name attribute; in these circumstances, client health checks are performed but authentication and authorization are not performed.

RADIUS Access-Request messages typically include the User-Name attribute, which allows NPS to authenticate and authorize a connection request. When a value for the User-Name attribute is absent, NPS provides a default user name.

However, for scenarios such as NAP enforcement with DHCP or IPsec, where a client health check occurs without authentication or authorization (such as when a DHCP client renews an IP address lease) the User-Name attribute is not present and NPS does not provide a default user name.

When NPS receives a request for a client health check that does not include the User Name attribute and the Identity Type condition is configured with a value of Computer health check, the request matches the policy and, if all other conditions and constraints configured in the policy are also matched, the policy settings are applied.

In addition, in network policy constraints, you can enable the Perform machine health check only authentication method setting.

For more information, see Enable Client Health Checks for DHCP and IPsec NAP Deployments.

  • MS-Service Class

    Restricts the policy to clients that have received an IP address from a DHCP scope that matches the specified DHCP profile name. This condition is used only when you are deploying NAP with the DHCP enforcement method. To use the MS-Service Class attribute, in Specify the profile name that identifies your DHCP scope, type the name of an existing DHCP profile.

  • Health Policies

    Restricts the policy to clients that meet the health criteria specified in the health policy. For example, you might have two Health Policies that you have configured using the Windows SHV -- one health policy created for circumstances where client computers pass all health checks and one policy created for circumstances where client computers fail all health checks specified in the Windows SHV. If you select the health policy that designates that all client computers must pass all health checks, the SoH sent to NPS from NAP agent on the client computer must state that the client passed all health checks required by the Windows SHV in order for the conditions of the network policy to be met.

  • NAP-Capable Computers

    Restricts the policy to either clients that are capable of participating in NAP or clients that are not capable of participating in NAP. This capability is determined by whether the client sends a SoH to NPS.

  • Operating System

    Specifies the operating system (operating system version or service pack number), role (client or server), and architecture (x86, x64, or ia64) required for the computer configuration to match the policy.

  • Policy Expiration

    Specifies when the network policy expires; after the expiration date and time that you specify, the network policy is no longer evaluated by NPS. This condition is useful for circumstances where the network policy is designed with the NAP Enforcement setting that allows client computers full network access for a limited time. At the same time that the NAP Enforcement time setting expires, the network policy can also expire. In this circumstance, you should create a second network policy that enforces NAP after the expiration time of the first policy.

Connection properties

Following are the connection properties that you can configure in network policy.

  • Access Client IPv4 Address

    Specifies the IPv4 address of the access client that is required to match the conditions of the policy.

  • Access Client IPv6 Address

    Specifies the IPv6 address of the access client that is required to match the conditions of the policy.

  • Authentication Type

    Specifies the authentication methods that are required for the connection request to match the network policy.

  • Allowed EAP Types

    Specifies the EAP types that are required in order for the authentication method used by the client computer to match this policy. This condition is useful when connection request policy is configured with authentication. When authentication is configured in connection request policy, the authentication settings in network policy are overridden; however the use of the Allowed EAP Types condition causes NPS to verify the authentication method being used; if the specified EAP type is not being used, NPS does not use the network policy for authorization and continues to seek a policy whose conditions match the connection request.

  • Framed Protocol

    Restricts the policy to clients that specify a certain framing protocol for incoming packets, such as PPP or SLIP.

  • Service Type

    Restricts the policy to only clients specifying a certain type of service, such as Telnet or Point to Point Protocol connections.

  • Tunnel Type

    Restricts the policy to only clients that create a specific type of tunnel, such as PPTP or L2TP. The Tunnel Type attribute is typically used when you deploy virtual local area networks (VLANs). For more information, see VLAN Attributes Used in Network Policy.

RADIUS client properties

Following are the RADIUS client conditions that you can configure in network policy.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

  • Calling Station ID

    Specifies the network access server telephone number that was dialed by the dial-up access client.

  • Client Friendly Name

    Specifies the name of the RADIUS client that forwarded the connection request to the NPS server.

  • Client IPv4 Address

    Specifies the Internet Protocol (IP) version 4 address of the RADIUS client that forwarded the connection request to the NPS server.

  • Client IPv6 Address

    Specifies the Internet Protocol (IP) version 6 address of the RADIUS client that forwarded the connection request to the NPS server.

  • Client Vendor

    Specifies the name of the vendor or manufacturer of the RADIUS client that sends connection requests to the NPS server.

  • MS RAS Vendor

    Specifies the vendor identification number of the network access server that is requesting authentication.

Gateway

Following are the gateway properties that you can configure in network policy.

  • Called Station ID

    Allows you to specify the phone number of the network access server that sent the connection request to NPS. If you specify a NAS phone number and NPS receives a connection request from a NAS with a different phone number, the conditions of the policy are not met.

  • NAS Identifier

    Allows you to specify the name of the network access server that sent the connection request to NPS. If you specify a NAS name and NPS receives a connection request from a NAS with a different name, the conditions of the policy are not met.

  • NAS IPv4 Address

    Allows you to specify the IPv4 address of the network access server that sent the connection request to NPS. If you specify a NAS IPv4 address and NPS receives a connection request from a NAS with a different IPv4 address, the conditions of the policy are not met.

  • NAS IPv6 Address

    Allows you to specify the IPv6 address of the network access server that sent the connection request to NPS. If you specify a NAS IPv6 address and NPS receives a connection request from a NAS with a different IPv6 address, the conditions of the policy are not met.

  • NAS Port Type

    Allows you to specify the type of media used by the client computer to connect to the network. For example, if you specify Ethernet, the client computer must be accessing the network over the media type of Ethernet. If you specify a media type and the client computer is connecting to the network over a different media type, the conditions of the policy are not met. For example, if the designated media type is Wireless - IEEE 802.11 and the client computer is attempting to connect to the network with a media type of Virtual (VPN), the conditions of the policy are not met.


Network Policy Constraints Properties

Network policy constraints

Constraints are additional network policy parameters that are optional. Constraints differ from network policy conditions in one substantial way: when a condition does not match a connection request, NPS continues to evaluate other configured network policies in search of a match for the connection request, but when a constraint does not match a connection request, NPS does not evaluate additional network policies; NPS rejects the connection request and the user or computer is denied network access.

Following are the constraints that you can configure in network policy.

  • Authentication methods

    Allows you to specify the authentication methods that are required for the connection request to match the network policy.

  • Idle timeout

    Allows you to specify the maximum time, in minutes, that the network access server can remain idle before the connection is disconnected.

  • Session timeout

    Allows you to specify the maximum amount of time, in minutes, that a user can be connected to the network.

  • Called station ID

    Allows you to specify the telephone number of the dial-up server that clients are allowed to use to access the network.

  • Day and time restrictions

    Allows you to specify when users are allowed to connect to the network.

  • NAS port type

    Allows you to specify the access media types that are allowed for users to connect to the network.


Network Policy Overview Properties

Network Policy Overview properties

On the Overview tab of a network policy or while running the New Network Policy wizard, you can configure the following:

  • Policy name. Type a friendly name for the network policy.

  • Policy State. Designate whether the policy is enabled or disabled.

  • Access Permission. Designate whether the policy grants or denies access. Also specify whether NPS should ignore the dial-in properties of user accounts in Active Directory Domain Services (AD DS) when using the policy to perform authorization for the connection attempt.

Note

If you have many user accounts in AD DS, it is recommended that you configure the dial-in properties of user accounts to control network access through network policy; however, you can accomplish the same result for individual policies by configuring them to ignore the dial-in properties of user accounts.

  • The network connection method used for the connection request:

    • Unspecified. If selected, NPS evaluates the network policy for all connection requests that originate from any type of network access server and for any connection method. This includes connections from Terminal Services Gateways, servers running Routing and Remote Access service that provide VPN and dial-up access, DHCP servers, 802.1X wireless access points, 802.1X authenticating switches, Health Registration Authority (HRA) servers, and Host Credential Authorization Protocol (HCAP) servers.

    • Remote Access Server (VPN-Dial-up). If specified, NPS evaluates the network policy for connection requests that originate from a computer running the Routing and Remote Access service configured as a dial-up or VPN server. If another dial-up or VPN server is used, the server must support the RADIUS protocol and the authentication protocols provided by NPS for dial-up and VPN connections.

    • Ethernet. If specified, NPS evaluates the network policy for all connection requests that originate from IEEE 802.1X authenticating switches.

    • Terminal Services Gateway. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Terminal Services Gateway (TS Gateway).

    • Wireless Access Point. If specified, NPS evaluates the network policy for connection requests that originate from IEEE 802.1X wireless access points that support the RADIUS protocol and Extensible Authentication Protocol (EAP).

    • Health Registration Authority. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Health Registration Authority (HRA).

    • HCAP server. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Host Credential Authorization Protocol (HCAP).

    • DHCP Server. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Dynamic Host Configuration Protocol (DHCP).


Network Policy Settings Properties

Network policy settings

NPS applies the settings that are configured in the network policy to the connection if all of the conditions and constraints that are configured in the policy match the properties of the connection request.

The available groups of settings that you can configure are:

  • RADIUS attributes

  • Network Access Protection

  • Routing and Remote Access

  • IP filters

  • Encryption

  • IP settings

RADIUS Attributes

You can configure both RADIUS standard attributes and vendor-specific attributes (VSAs) as settings in network policy.

Important

If you plan to return to RADIUS clients any additional RADIUS attributes or VSAs with the responses to RADIUS requests, you must add the RADIUS attributes or VSAs to the appropriate network policy.

RADIUS attributes are described in Request for Comments (RFC) 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869, and RFC 3162. RFCs and Internet drafts for VSAs define additional RADIUS attributes.

Network Access Protection

You can specify how you want to enforce NAP, remediation server groups, troubleshooting URL, and autoremediation.
NAP Enforcement

You can use the following settings to designate how you want to enforce NAP:

  • If you select Allow full network access, NAP is not enforced for the network policy. All clients, including non-NAP capable clients and NAP-capable clients that are not compliant with health policy, can connect when the connection request matches the conditions and constraints of the policy.

  • If you select Allow full network access for a limited time, you can defer enforcement of health policy until the day and time that you specify. In the time period before the expiration date that you specify, all clients can connect when the connection request matches the conditions and constraints of the network policy. After the expiration date, compliant clients are allowed full network access; and non-compliant NAP clients are allowed access only to a restricted network, where remediation servers can provide clients with the updates they need in order to become compliant with health policy.

  • If you select Allow limited access, NAP is enforced. Compliant clients are allowed full network access, and non-compliant NAP clients are allowed access only to a restricted network, where remediation servers can provide clients with the updates they need in order to become compliant with health policy.

Important

If you deploy the NAP VPN enforcement method and you have configured NAP enforcement with the Allow full network access for a limited time option, VPN clients that are connected to the network when the expiration time is reached are automatically disconnected whether they are compliant or noncompliant with health policy. After the expiration date and time, VPN clients that attempt to connect to the network are placed on a restricted network if they are noncompliant with health policy, while compliant clients are allowed full network access.

Remediation Server Group and Troubleshooting URL. If you enable autoremediation in NAP Enforcement and you have configured one or more Remediation Server Groups in NPS Network Access Protection settings, you can specify the Remediation Server Group that clients can access for software updates.

When you deploy and enforce NAP, you can provide technical assistance and other information to users on a Web site that is located on the remediation network. If users have restricted access because their computers do not comply with health policy, Web resources can assist them in bringing their computers into compliance with policy. If you have deployed a Web server with Help content, you can supply users with the Web page URL with this network policy setting.

Autoremediation. You can configure autoremediation for client computers on the NAP enforcement page. When you configure autoremediation, clients that are not compliant with health policy are automatically updated and brought into compliance.

For example, if your Windows Security Health Validator (WSHV) designates that the client computer must have a firewall installed and enabled and antivirus software installed, enabled, and configured with the latest signature updates, autoremediation causes NAP agent on the client to enable the firewall if it is turned off and to download the most recent antivirus signature updates if they are not already installed on the client. If you enable autoremediation, be sure to also configure a Remediation Server Group so that client computers know where to find the updates they need when they are not in compliance with health policy.

Extended State

The NAP Extended State setting, along with Host Credential Authorization Protocol (HCAP) server, allows you to integrate your Microsoft Network Access Protection (NAP) solution with Cisco Network Admission Control. Do not configure the NAP Extended State setting in network policy unless you have also deployed Cisco Network Admission Control and HCAP server.

For more information, see Host Credential Authorization Protocol.

Timeout

Following are the timeout settings that you can configure in network policies.

Idle Timeout allows you to specify the maximum time, in minutes, that the network access server can remain idle before the connection is disconnected.

Session Timeout allows you to specify the maximum amount of time, in minutes, that a user can be connected to the network.

Routing and Remote Access

Following are the Routing and Remote Access settings that you can configure in network policies.

Multilink and Bandwidth Allocation Protocol (BAP) allows you to configure how multiple dial-up connections from one computer are managed and whether the number of connections should be reduced based on capacity.

IP Filters allows you to create IPv4 and IPv6 filters to control the IP traffic that the client computer can send or receive.

Encryption allows you to specify the encryption level required between the client computer and the server running Routing and Remote Access service. If you use non-Microsoft network access servers for VPN and dial-up connections, ensure that the encryption settings you select are supported by your servers.

IP Settings allows you to specify the client IP address assignment rules for the network policy.

See Also

  • Add a Setting to a Network Policy


VLAN Attributes Used in Network Policy

VLAN attributes used in network policy

When you use network hardware, such as routers, switches, and access controllers that support virtual local area networks (VLANs), you can configure Network Policy Server (NPS) network policy to instruct the access servers to place members of Active Directory® groups on VLANs.

Before configuring network policy in NPS for VLANs, create groups of users in Active Directory Domain Services (AD DS) that you want to assign to specific VLANs. Then when you run the New Network Policy wizard, add the Active Directory group as a condition of the network policy.

You can create a separate network policy for each group that you want to assign to a VLAN. For more information, see Create a Group for a Network Policy.

When you configure network policy for use with VLANs, you must configure the RADIUS standard attributes Tunnel-Medium-Type, Tunnel-Pvt-Group-ID, and Tunnel-Type. Some hardware vendors also require the use of the RADIUS standard attribute Tunnel-Tag.

To configure these attributes in a network policy, use the New Network Policy wizard to create a network policy. You can add the attributes to the network policy settings while running the wizard or after you have successfully created a policy with the wizard.

Note

To add the attributes after you have created the network policy with the wizard, locate the policy in the NPS console and double-click the policy to open it. Click the Settings tab in the policy properties, ensure that RADIUS Attributes - Standard is selected, and then click Add. In the Add Attribute dialog box, add the following attributes.

  • Tunnel-Medium-Type. Select a value appropriate to the previous selections you made while running the New Network Policy wizard. For example, if the network policy you are configuring is a wireless policy, in Attribute Value, select 802 (Includes all 802 media plus Ethernet canonical format).

  • Tunnel-Pvt-Group-ID. Enter the integer that represents the VLAN number to which group members will be assigned. For example, if you want to create a Sales VLAN for your sales team by assigning team members to VLAN 4, type the number 4.

  • Tunnel-Type. Select the value Virtual LANs (VLAN).

  • Tunnel-Tag. Some hardware devices do not require this attribute. If your hardware device requires this attribute, obtain this value from your hardware documentation.

For more information, see Add a Network Policy.


Configure Network Policies

Configure Network Policies

The following topics demonstrate how to configure network policies in NPS.

  • Add a Network Policy

  • Add a Condition to a Network Policy

  • Add a Constraint to a Network Policy

  • Add a Setting to a Network Policy

  • Configure a Network Policy to Grant or Deny Access

  • Create Policies for Dial-Up or VPN with a Wizard

  • Create policies for 802.1X Wired or Wireless with a Wizard


Add a Network Policy

Add a network policy

Network Policy Server (NPS) uses network policies, formerly named remote access policies, and the dial-in properties of user accounts to determine whether a connection request should be authorized to connect to the network.

You can use this procedure to configure a new network policy in either the NPS snap-in or the Routing and Remote Access Service snap-in.

Performing authorization

When NPS performs the authorization of a connection request, it compares the request with each network policy in the ordered list of policies, starting with the first policy, and then moving down the list of configured policies. If NPS finds a policy whose conditions match the connection request, NPS uses the matching policy and the dial-in properties of the user account to perform authorization. If the dial-in properties of the user account are configured to grant access or control access through network policy and the connection request is authorized, NPS applies the settings that are configured in the network policy to the connection.

If NPS does not find a network policy that matches the connection request, the connection request is rejected unless the dial-in properties on the user account are set to grant access.

If the dial-in properties of the user account are set to deny access, the connection request is rejected by NPS.

Key settings

When you use the New Network Policy Wizard to create a network policy:

  • The value that you specify in Network connection method is used to automatically configure the Policy Type condition. If you keep the default value of Unspecified, the network policy that you create is evaluated by NPS for all network connection types through any kind of network access server. If you specify a network connection method, NPS evaluates the network policy only if the connection request originates from the type of network access server that you specify. For example, if you specify Terminal Services Gateway, NPS evaluates the network policy only for connection requests that originate from Terminal Services Gateway (TS Gateway).

  • On the Access Permission page, you must select Access granted if you want the policy to allow users to connect to your network. If you want the policy to prevent users from connecting to your network, select Access denied. If you want access permission to be determined by user account dial-in properties in Active Directory Domain Services (AD DS), you can select the Access is determined by User Dial-in properties check box.

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

To add a network policy using the Windows interface

  1. Open the NPS console and double-click Policies.

  2. In the console tree, right-click Network Policies, and click New. The New Network Policy wizard opens.

  3. Use the New Network Policy wizard to create a policy.


Add a Condition to a Network Policy

Add a condition to a network policy

After creating a network policy with the New Network Policy Wizard or by creating a custom policy, you can specify the conditions that connection requests must have in order to match the network policy; if the conditions configured in the policy match the connection request, Network Policy Server (NPS) applies the settings designated in the network policy to the connection.

With this procedure you can configure conditions in the groups Connection Properties, Day and Time Restrictions, Gateway, Groups, Network Access Protection, and RADIUS Client Properties.

Important

Before you configure the value for a condition in a network policy, you must know the value that the condition must have. For example, if you want to configure the NAS IPv6 Address condition, you must know the Internet Protocol version 6 (IPv6) address of the network access server, or RADIUS client, that creates the Access-Request messages received by NPS. In addition, there are different methods for configuring condition values, depending on the type of condition or type of value to be configured. Many conditions, such as the Connection Properties group of conditions, provide a list from which you can select one or more values by selecting check boxes. The Day and Time Restrictions condition provides an Edit button that allows you to configure restrictions in a new dialog box. Other conditions allow you to enter values in other ways.

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

To add a condition to a network policy using the Windows interface

  1. Open the Network Policy Server (NPS) Microsoft Management Console (MMC) snap-in, double-click Policies, and then click Network Policies.

  2. In the upper details pane, double-click the network policy to which you want to add a condition, and then click the Conditions tab.

  3. In Available Conditions, browse to the appropriate conditions group, and then click the condition you want to add to the policy.

  4. In the details pane, configure the value for the condition.

  5. Click Add, and then click OK.
Caution

If you do not click Add, the condition is not added to the network policy. You must click Add to complete this procedure.


Add a Constraint to a Network Policy

Add a constraint to a network policy

You can use this procedure to add a constraint to an existing network policy.

Constraints are additional network policy parameters that are optional. Constraints differ from network policy conditions in one substantial way: when a condition does not match a connection request, NPS continues to evaluate other configured network policies in search of a match for the connection request, but when a constraint does not match a connection request, NPS does not evaluate additional network policies, NPS rejects the connection request and the user or computer is denied network access.

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

To add a constraint to a network policy

  1. Open the Network Policy Server (NPS) Microsoft Management Console (MMC) snap-in, double-click Policies, and then click Network Policies.

  2. In the upper details pane, double-click the network policy to which you want to add a constraint, and then click the Constraints tab.

  3. In Constraints, click the constraint that you want to add to the policy.

  4. In the details pane, configure the value for the constraint, and then click OK.


Add a Setting to a Network Policy

Add a setting to a network policy

You can use this procedure to add a setting to an existing network policy.

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

To add a setting to a network policy

  1. Open the NPS console, and then double-click Policies.

  2. Click Network Policies, and then double-click the policy that you want to configure.

  3. In Settings, click the setting that you want to configure, and then provide the value for the setting.

See Also

  • Network Policy Settings Properties


Configure a Network Policy to Grant or Deny Access

Configure a network policy to grant or deny access

Network policies are used by Network Policy Server (NPS) and the Routing and Remote Access service to authorize connection requests.

Network policies contain overview properties that designate how the policy is to be used and interpreted. Access Permission allows you to configure whether user account dial-in properties in Active Directory® Domain Services (AD DS) are used to perform authorization. It also provides two possible network access values:

  • Grant access. If selected, connection requests whose properties match the conditions and constraints of the network policy are granted.

  • Deny access. If selected, connection requests whose properties match the conditions of the network policy are denied.

Note

By default, network policies created with the New Network Policy Wizard are configured to deny access. Therefore, Access Permission must be changed after running the wizard in order for the policy to grant access rather than deny access to the network.

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

To configure a network policy to grant or deny access

  1. Open the Network Policy Server (NPS) Microsoft Management Console (MMC) snap-in, double-click Policies, and then double-click Network Policies.

  2. In the details pane, double-click the network policy that you want to configure.

  3. In the network policy Properties dialog box, on the Overview tab, change Access Permission to either Grant access or Deny access.

See Also

  • Access Permission


Create Policies for Dial-Up or VPN with a Wizard

Create policies for dial-up or VPN with a wizard

You can use this procedure to create the connection request policies and network policies required to deploy either dial-up servers or virtual private network (VPN) servers as RADIUS clients to the NPS RADIUS server.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

This procedure explains how to start the New Dial-up or Virtual Private Network Connections wizard in NPS.

After you run the wizard, the following policies are created:

  • One connection request policy

  • One network policy

Running the New Dial-up or Virtual Private Network Connections wizard is not the only step required to deploy dial-up or VPN servers as RADIUS clients to the NPS server. Both network access methods require that you deploy additional hardware and software components.

Note

You can run the New Dial-up or Virtual Private Network Connections wizard every time you need to create new policies for dial-up servers and VPN servers.

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

To create policies for dial-up or VPN with a wizard

  1. Open the NPS console. If it is not already selected, click NPS (Local). If you are running the NPS MMC snap-in and want to create policies on a remote NPS server, select the server.

  2. In Getting Started and Standard Configuration, use the combination box to select RADIUS server for Dial-Up or VPN Connections. The text and links under the text change to reflect your selection.

  3. Click Configure VPN or Dial-Up with a wizard. The New Dial-up or Virtual Private Network Connections wizard opens.


Create policies for 802.1X Wired or Wireless with a Wizard

Create policies for 802.1X wired or wireless with a wizard

You can use this procedure to create the connection request policies and network policies required to deploy either 802.1X authenticating switches or 802.1X wireless access points as RADIUS clients to the Network Policy Server (NPS) RADIUS server.

Important

Client computers, such as wireless laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

This procedure explains how to start the New IEEE 802.1X Secure Wired and Wireless Connections wizard in Network Policy Server (NPS).

After you run the wizard, the following policies are created:

  • One connection request policy

  • One network policy

Running the New IEEE 802.1X Secure Wired and Wireless Connections wizard is not the only step required to deploy 802.1X authenticating switches and wireless access points as RADIUS clients to the NPS server. Both network access methods require that you deploy additional hardware and software components.

Note

You can run the New IEEE 802.1X Secure Wired and Wireless Connections wizard every time you need to create new policies for 802.1X access.

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

To create policies for 802.1X wired or wireless with a wizard

  1. Open the NPS console. If it is not already selected, click NPS (Local). If you are running the NPS MMC snap-in and want to create policies on a remote NPS server, select the server.

  2. In Getting Started and Standard Configuration, use the combination box to select RADIUS server for 802.1X Wireless or Wired Connections. The text and links below the text change to reflect your selection.

  3. Click Configure 802.1X using a wizard. The New IEEE 802.1X Secure Wired and Wireless Connections wizard opens.