Network Policy Server (NPS) Technical Reference for Windows Server 2008 through Windows Server 2012 R2

Microsoft CorporationAuthors: James McIllece, Joseph DaviesTechnical Contributors: IAS and NPS PM, Developer, and Test teams, with special thanks to Ashwin PalekarApplies To: Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, and Windows Server 2008

Abstract

Network Policy Server (NPS) is a networking component of Windows Server® 2012 R2, Windows Server 2012, Windows Server 2008 R2, and Windows Server 2008 that 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 a server running NPS as a RADIUS proxy to forward connection requests to NPS or other Remote Authentication Dial-In User Service (RADIUS) servers that you configure in remote RADIUS server groups.

The Network Policy Server (NPS) Technical Reference provides a detailed description of NPS, including how NPS works, and the tools and settings you can use to deploy, administer, and troubleshoot NPS.

Notes:

Network Access Protection (NAP), Health Registration Authority (HRA), and Host Credential Authorization Protocol (HCAP) were deprecated in Windows Server 2012 R2, and are not available in Windows Server 2016. If you have a NAP deployment using operating systems earlier than Windows Server 2016, you cannot migrate your NAP deployment to Windows Server 2016.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2005 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.

ContentsNetwork Policy Server (NPS) Technical Reference for Windows Server 2008 through Windows Server 2012 R2.......................................................................................................................................................1

Network Policy Server Technical Reference................................................................................................6

Windows Server Editions and NPS.........................................................................................................6

Windows Server 2008, 2008 R2, 2012, and 2012 R2 Enterprise and Datacenter Editions..................7

Windows Server 2008, 2008 R2, 2012, and 2012 R2 Standard Editions.............................................7

Windows Web Server..........................................................................................................................7

What Is Network Policy Server (NPS)?.........................................................................................................7

Components of a RADIUS Infrastructure.................................................................................................8

Access clients.......................................................................................................................................9

Access servers used as RADIUS clients...............................................................................................10

NPS servers used as RADIUS servers..................................................................................................10

NPS proxies and RADIUS proxies.......................................................................................................10

User accounts databases...................................................................................................................10

NPS as a RADIUS Server and Proxy........................................................................................................11

RADIUS server....................................................................................................................................11

RADIUS proxy.....................................................................................................................................11

RADIUS clients...................................................................................................................................14

New Features and Name Changes for NPS............................................................................................14

NPS functionality in Windows Server 2008 and later............................................................................15

Additional features of NPS.................................................................................................................16

Name changes from Windows Server 2003...........................................................................................21

NPS Terminology...................................................................................................................................22

Planning NPS as a RADIUS proxy............................................................................................................25

Plan NPS server configuration...........................................................................................................26

Plan RADIUS clients............................................................................................................................27

Plan remote RADIUS server groups...................................................................................................28

Plan attribute manipulation rules for message forwarding...............................................................29

Plan connection request policies.......................................................................................................30

Plan NPS accounting..........................................................................................................................31

Planning NPS as a RADIUS server...........................................................................................................31

Plan NPS server configuration...........................................................................................................32

Plan RADIUS clients............................................................................................................................33

Plan the use of authentication methods............................................................................................34

Plan network policies.........................................................................................................................36

Plan NPS accounting..........................................................................................................................37

Components of NPS...............................................................................................................................40

Configuration.....................................................................................................................................41

NPS logging........................................................................................................................................42

RADIUS Clients and Servers...............................................................................................................42

RADIUS client properties...................................................................................................................44

Remote RADIUS Server Groups.........................................................................................................46

Policies...................................................................................................................................................47

Connection Request Policies..............................................................................................................47

Network Policies................................................................................................................................56

Network Access Protection (NAP).........................................................................................................72

Accounting.............................................................................................................................................80

How Network Policy Server Works............................................................................................................80

NPS Architecture...................................................................................................................................80

Network Policy Server components...................................................................................................81

External Dependencies......................................................................................................................83

RADIUS extension DLLs and NPS architecture...................................................................................84

NPS Extensions..................................................................................................................................84

NPS Protocols........................................................................................................................................86

Authentication Protocols...................................................................................................................87

RADIUS Protocol..............................................................................................................................121

RADIUS Attributes............................................................................................................................126

NPS Processes and Interactions.......................................................................................................130

Connection Request Processing.......................................................................................................142

NPS Authorization Process...............................................................................................................155

RADIUS Authentication Process Overview.......................................................................................166

RRAS authentication and authorization...........................................................................................171

NPS RADIUS Proxy Message Processing...........................................................................................171

NAP Health Policy Server Message Processing................................................................................174

NPS Accounting...................................................................................................................................179

NPS log file.......................................................................................................................................180

NPS events and Event Viewer..........................................................................................................180

Interpret IAS Format Log Files.........................................................................................................181

Interpret NPS Database Format Log Files........................................................................................191

NPS SQL Server Logging...................................................................................................................206

Network Policy Server Tools and Settings................................................................................................219

NPS Tools.............................................................................................................................................219

NPS console.....................................................................................................................................219

NPS MMC snap-in............................................................................................................................220

Netsh commands for NPS................................................................................................................220

Network Monitor.............................................................................................................................220

NPS API sets.....................................................................................................................................220

NPS Settings.........................................................................................................................................221

NPS Server Registration in Active Directory.....................................................................................221

NPS Ports.........................................................................................................................................222

Connecting to a remote SQL server.................................................................................................222

NPS Firewall Settings.......................................................................................................................222

NPS Message-Authenticator Attribute.............................................................................................228

NPS Shared Secrets..........................................................................................................................228

NPS Reason Codes...........................................................................................................................230

NPS Registry Entries.........................................................................................................................239

Network Policy Server Technical ReferenceNetwork Policy Server (NPS) is a networking component of Windows Server®  that 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 a server running NPS as a RADIUS proxy to forward connection requests to NPS or other Remote Authentication Dial-In User Service (RADIUS) servers that you configure in remote RADIUS server groups.

The Network Policy Server (NPS) Technical Reference provides a detailed description of NPS, including how NPS works, and the tools and settings you can use to deploy, administer, and troubleshoot NPS.

In Windows Server, Network Policy Server (NPS) is included in the Network Policy and Access Services (NPAS) server role.

The NPAS server role is a logical grouping in the Add Roles installation wizard of the following network access technologies:

Network Policy Server (NPS)

Routing and Remote Access service (RRAS)

Health Registration Authority (HRA)

Host Credential Authorization Protocol (HCAP)

These technologies are the role services of the NPAS server role. When you install the NPAS server role, you can install one or more role services while running the Add Roles Wizard. The Add Roles Wizard is accessible in both Initial Configuration Tasks and Server Manager in the Windows Server 2008 through Windows Server 2012 R2 graphical user interface.

Note In Windows Server 2008, Network Policy Server (NPS) replaces the Internet Authentication Service (IAS) component of Windows Server 2003.

Windows Server Editions and NPS

NPS provides different functionality depending on the edition of Windows Server that you install.

Windows Server 2008, 2008 R2, 2012, and 2012 R2 Enterprise and Datacenter Editions

With NPS in Enterprise and Datacenter versions of the operating systems, you can configure an unlimited number of RADIUS clients and remote RADIUS server groups. In addition, you can configure RADIUS clients by specifying an IP address range.

Windows Server 2008, 2008 R2, 2012, and 2012 R2 Standard Editions

With NPS in Standard editions of the operating systems, you can configure a maximum of 50 RADIUS clients and a maximum of 2 remote RADIUS server groups. You can define a RADIUS client by using a fully qualified domain name or an IP address, but you cannot define groups of RADIUS clients by specifying an IP address range. If the fully qualified domain name of a RADIUS client resolves to multiple IP addresses, the NPS server uses the first IP address returned in the Domain Name System (DNS) query.

Windows Web Server

NPS is not included in this edition of Windows Server.

What Is Network Policy Server (NPS)?In this section

Components of a RADIUS Infrastructure

NPS as a RADIUS Server and Proxy

New Features and Name Changes for NPS

NPS Terminology

Planning NPS as a RADIUS proxy

Planning NPS as a RADIUS server

Components of NPS

When you provide your organization’s employees and their computers with network connectivity through network access servers, such as virtual private network (VPN) servers, wireless access points, and dial-up servers, you can use NPS to create, centrally manage, and enforce the

network access policies that determine whether users and computers can or cannot access the network.

During a connection attempt, users and computers typically provide account credentials in the form of a user name and password or a certificate. NPS can examine these credentials and use them to verify the identity of – or authenticate – the user or computer before allowing network access. NPS can also determine whether the user or computer has permission to access the network by authorizing the connection request against user account properties, network policies that you have created, or both.

NPS provides you with the advantage of configuring network policies at one server (the server running NPS) that are applied at many servers (the network access servers). For example, if you have 10 wireless access points and are not using NPS, you must configure access policies 10 times; but if you use NPS, you must configure each policy only one time.

By using NPS, you can centrally manage network access for organizations of all sizes, including small businesses, medium organizations, enterprise-level organizations, and Internet service providers (ISPs). NPS provides you with the ability to secure and manage network access across a variety of network access scenarios such as the following:

Employees connecting to your organization network through dial-up, VPN, wireless, Terminal Services Gateway (TS Gateway), and wired connections, using a variety of devices, including organization computers, personal digital assistants, and non-domain member computers, such as employee-owned devices.

Employees connecting to other networks, including the Internet and business partner networks.

Business partners connecting to your organization network.

The underlying protocol that provides NPS with the ability to communicate with such a broad range of network access servers is the Remote Authentication Dial-In User Service (RADIUS) protocol.

Components of a RADIUS InfrastructureNetwork Policy Server (NPS) is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy. NPS and network access servers use the RADIUS protocol to securely transmit RADIUS messages.

The RADIUS protocol is used solely between RADIUS servers and proxies, such as servers and proxies running NPS, and RADIUS-compliant network access servers. A fully functioning RADIUS infrastructure also contains components that do not use the RADIUS protocol, however, such as access clients and user accounts databases.

Note RADIUS is an industry standard. For more information about RADIUS, see RFC 2865, “Remote Authentication Dial-In User Service (RADIUS),” and RFC 2866, “RADIUS Accounting.” For information about standards that apply to NPS in Windows Server 2008, see RFC 2868, “RADIUS Attributes for Tunnel Protocol Support,” and RFC 2869, “RADIUS Extensions.”

There are five components to an NPS or RADIUS infrastructure: access clients, access servers (RADIUS clients), NPS servers (RADIUS servers), NPS proxies (RADIUS proxies), and user account databases. A RADIUS infrastructure is used to perform authentication, authorization and accounting of user network access attempts. Authentication is the process of verifying the credentials of the users attempting to connect to a network. The authorization process determines whether users have permission to connect to the network, and the conditions under which permission has been granted. Accounting is an option that provides record keeping of successful or failed connection attempts.

The following figure, “Components of an NPS Infrastructure,” illustrates the relationships between the five components of an NPS infrastructure.

Components of an NPS Infrastructure

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 local area network (LAN) clients connected to an authenticating switch.

Note

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

Access servers used as 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.

NPS servers used as RADIUS servers

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

NPS proxies and RADIUS proxies

An NPS or RADIUS proxy is a device that forwards or routes RADIUS connection requests and accounting messages between RADIUS clients and RADIUS servers. 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.

User accounts 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 Server 4.0 domain; the Active Directory directory service and user accounts database included with Windows Server 2003 and Windows 2000; and the user accounts database provided with Active Directory Domain Services (AD DS) in Windows Server 2008 through Windows Server 2016.

When NPS is a domain member of an AD DS domain, NPS can provide authentication and authorization for user or computer accounts that exist in the following locations:

In the domain in which the NPS server is a member.

In domains for which there is a two-way trust with the NPS server domain.

In trusted forests with domain controllers running Windows Server 2008 through Windows Server 2016 and AD DS.

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 Active Directory include untrusted forests, untrusted domains, or one-way trusted domains.

NPS as a RADIUS Server and ProxyRADIUS servers process connection requests, whereas RADIUS proxies forward connection requests to other RADIUS servers for processing. You can configure a server running NPS to act as a RADIUS server, a RADIUS proxy, or both.

RADIUS server

When you deploy NPS as a RADIUS server, NPS receives connection requests from network access servers, and then processes the requests. NPS performs centralized connection authentication, authorization, and accounting for many types of network access.

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 SAM to authenticate user credentials for a connection attempt. 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 RADIUS clients send. Accounting requests are stored in a local log file or a SQL server database for analysis.

RADIUS proxy

As a RADIUS proxy, NPS provides the routing of RADIUS messages between RADIUS clients (access servers), other RADIUS proxies, and the RADIUS servers that perform AAAA 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.

Note

When you configure NPS as a RADIUS proxy, network access servers are configured as RADIUS clients on the RADIUS proxy. In other words, connection requests originate at and are sent by RADIUS clients to the RADIUS proxy. Because the RADIUS proxy forwards these connection requests to remote RADIUS servers for processing, the proxy is acting as a RADIUS client to the remote RADIUS server.

The following illustration shows NPS as a RADIUS proxy between RADIUS clients (access servers) and either RADIUS servers or another RADIUS proxy.

You can use NPS as a RADIUS proxy when:

You are a service provider who offers outsourced dial-up, VPN, or wireless network access services to multiple customers. Your 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 the section Realm Names later in this guide.

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 Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. The forest functional level must be Windows Server 2008 or Windows Server 2003, and there must be a two-way trust relationship between forests. If you use EAP-TLS or PEAP-TLS with certificates as your authentication method, you must use a RADIUS proxy for authentication across forests that consist of Windows Server 2016 through 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 an NPS server on your perimeter network, the firewall between your perimeter network and intranet must allow traffic to flow between the NPS server and multiple domain controllers. 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.

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

NPS can be used as a RADIUS server or proxy with any network access servers that are compliant with RADIUS RFCs 2865 and 2866. Network access servers are also called RADIUS clients.

NPS enables the use of a heterogeneous or homogenous set of wireless, switch, remote access, or VPN equipment. You can use NPS to authenticate and authorize network connection requests when you deploy the following types of network access servers and technologies:

Wired access with 802.1X-secured and RADIUS-compliant authenticating switches

Wireless access with 802.1X-secured and RADIUS-compliant wireless access points

Dial-up access with a computer running an operating system from Windows Server 2008 to Windows Server 2016 and Remote Access configured as a dial-up server, or other dial-up servers that are RADIUS-compliant

Terminal or remote desktop services access with a computer running Windows Server 2008 through Windows Server 2016, and either Terminal Services Gateway (TS Gateway) or Remote Desktop Gateway, depending on the operating system

VPN access with a computer running Windows Server 2008 to Windows Server 2016 and Remote Access configured as a VPN server, or other VPN servers that are RADIUS-compliant.

New Features and Name Changes for NPSNetwork Policy Server (NPS) provides the following features that were introduced in Windows Server 2008 R2, and which are available in all later versions of the operating system.

NPS templates and Templates Management. NPS templates allow you to create NPS server configuration elements, such as RADIUS clients or shared secrets, that you can reuse on the local server running NPS and export for use on other NPS servers. Templates Management provides a node in the NPS console where you can create,

modify, and save templates. In addition, you can export templates for use on other NPS servers, or import templates into Templates Management for use on the local computer.

RADIUS accounting improvements. These improvements include a new accounting configuration wizard that allows you to easily configure SQL Server logging, text file logging, or combinations of these two logging types. In addition, you can use the wizard to automatically configure an NPS database on a local or remote SQL Server.

Full support for international, non-English character sets using UTF-8 encoding. In compliance with the Internet Engineering Task Force (IETF) request for comments (RFC) 2865, NPS processes the value of the User-Name attribute in a connection request using 8-bit Unicode Transformation Format (UTF-8) encoding. The User-Name attribute includes the user or computer identity and the realm. Optionally, the following registry key can be used to cause NPS to process the value of the User-Name attribute in American Standard Code for Information Interchange (ASCII) format if the registry key DWORD value is set to 1: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EapHost\Configuration\IdentityEncodingFormat

NPS functionality in Windows Server 2008 and laterNPS provides the following new functionality in Windows Server 2008 and later versions of the operating system up to and including Windows Server 2012 R2:

Network Access Protection (NAP). A client health policy creation, enforcement, and remediation technology that is included in the Windows Vista operating system 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.

Important. NAP is not available in Windows Server 2016.

Network shell (Netsh) commands for NPS. A comprehensive command set that allows you to manage all aspects of NPS using commands at the netsh prompt and in scripts and batch files. The Network Shell (Netsh) Technical Reference is available for download in Windows Help format from the Microsoft TechNet Gallery at Netsh Technical Reference.

New Windows interface. Windows interface improvements, including policy creation wizards for NAP, network policy, and connection request policy; and wizards designed specifically for deployments of 802.1X wired and wireless and VPN and dial-up connections.

Support for Internet Protocol version 6 (IPv6). NPS can be deployed in IPv6-only environments, IPv4-only environments, and in mixed environments where both IPv4 and

IPv6 are used.

Integration with Cisco Network Admission Control (NAC). With Host Credential Authorization Protocol (HCAP) and NPS, you can integrate Network Access Protection (NAP) with Cisco NAC. NPS provides the Extended State and Policy Expiration attributes in network policy for Cisco integration.

Attributes to identify access clients. The operating system and access client conditions allow you to create network access policies that apply to clients you specify and to clients running operating system versions you specify.

Integration with Server Manager. NPS is integrated with Server Manager, which allows you to manage multiple technologies from one Windows interface location.

Network policies that match the network connection method. You can create network policies that are applied only if the network connection method, such as VPN, TS Gateway, or DHCP, matches the policy. This allows NPS to process only the policies that match the type of RADIUS client used for the connection.

Common Criteria support. NPS can be deployed in environments where support for Common Criteria is required. For more information, see the Common Criteria portal at http://go.microsoft.com/fwlink/?LinkId=95567.

NPS extension library. NPS provides extensibility that enables non-Microsoft organizations and companies to implement custom RADIUS solutions by authoring NPS extension dynamic-link libraries (DLLs). NPS recovers from failures in non-Microsoft extension DLLs.

XML NPS configuration import and export. You can export an NPS server configuration to an XML file and then, on another NPS server, import the NPS server configuration from the XML file. These procedures are performed using the netsh NPS commands.

EAPHost and EAP policy support. NPS supports EAPHost, which is also available in Windows Vista. EAPHost is a Windows service that implements RFC 3748 and supports all RFC-compliant EAP methods, including expanded EAP types. EAPHost also supports multiple implementations of the same EAP method. NPS administrators can configure network policy and connection request policy based on EAPHost EAP methods.

Additional features of NPS

Following are additional features provided by NPS.

NPS server administration

After you install NPS, you can administer NPS servers:

Locally, by using the NPS Microsoft Management Console (MMC) snap-in, the static NPS console in Administrative Tools, or the network shell (Netsh) commands for NPS.

From a remote NPS server, by using the NPS MMC snap-in, the Netsh commands for NPS, or Remote Desktop Connection.

From a remote workstation, by using Remote Desktop Connection.

Authentication methods

The protection of user account credentials during the authentication of users attempting connections is an important security concern. NPS supports a variety of authentication protocols and allows you to use arbitrary authentication methods to meet your requirements for authentication:

Password-based Point-to-Point Protocol (PPP) authentication protocols. PPP is a set of industry-standard framing and authentication protocols that enables remote access solutions to be interoperable in a multivendor network. NPS supports the authentication protocols within PPP, such as Password Authentication Protocol, CHAP, Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v1), MS-CHAP version 2 (MS-CHAP v2), and Extensible Authentication Protocol (EAP).

Extensible Authentication Protocol (EAP) and Protected EAP (PEAP). EAP is an Internet standards–based infrastructure that allows the addition of arbitrary authentication methods, such as smart cards, certificates, one-time passwords, and token cards. A specific authentication method that uses the EAP infrastructure is an EAP type. NPS includes support for EAP-Transport Layer Security (EAP-TLS), as well as PEAP-MS-CHAP v2 and PEAP-TLS.

Authorization methods

NPS supports a number of authorization methods and allows you to add custom methods that meet your authorization requirements. The supported authorization methods are:

Dialed Number Identification Service (DNIS). The authorization of a connection attempt that is based on the number called. DNIS supplies the number that was called to the call receiver and is provided by most standard telephone companies.

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

Guest authorization. The authorization of a connection when the caller does not send a user name or password during the authentication process. If unauthenticated access is enabled, the Guest account is used by default as the identity of the caller.

In addition, you can configure authorization by user with Active Directory Domain Services (AD DS) user and computer account dial-in properties or authorization by group using NPS network policy.

Centralized user authentication and authorization

To authenticate a connection request, NPS validates the connection credentials against user and computer accounts in the local computer security accounts manager (SAM) database (also called Local Users and Groups), a Windows NT Server 4.0 domain, or an Active Directory domain. For an Active Directory domain, NPS supports the use of Active Directory user principal names (UPNs) and universal groups.

To authorize a connection request, NPS uses the dial-in properties of the user account that correspond to both the connection credentials and network policies.

One of the elements used during authorization is the Network Access Permission setting, which can be set both on the user or computer account and in the network policy. Although it is relatively easy to manage network access permission for each user account, this approach does not scale well as an organization grows. NPS network policies provide a more powerful and flexible way to manage network access permission.

With network policies, you can authorize network access based on various conditions, including:

User account membership in a group.

The time of day, the day of the week, or both.

The type of media by which the user is connecting (for example, wireless, Ethernet switch, modem, or VPN).

The phone number that the user calls.

The access server from which the request arrives.

In network policies you can control many connection parameters, including:

The use of specific authentication methods.

The idle time-out.

The maximum time of a single session.

The number of links in a multilink session.

The use of encryption and its strength.

The use of packet filters to control what resources the connecting user can access. For example, you can use filters to control which IP addresses, hosts, and ports the user is allowed to use in sending or receiving packets.

The creation of a compulsory tunnel that forces all packets from that connection to be securely tunneled through the Internet and then terminated in a private network.

The virtual local area network identifier for wireless or Ethernet connections.

Centralized administration for all access servers

Support for the RADIUS standard allows NPS to control connection parameters for any network access server (NAS) that implements RADIUS. The RADIUS standard also allows individual access server vendors to create proprietary extensions called vendor-specific attributes (VSAs).

NPS has incorporated the extensions from a number of vendors in its dictionary of attributes. In circumstances where an attribute is not included in the NPS dictionary of attributes, you can create and add new VSAs to the profile of individual network policies.

Outsourced dial-up and wireless network access

Outsourced dialing (also known as wholesale dialing) provides a contract between an organization and an ISP. The ISP allows employees of the organization to connect to its network before the VPN tunnel to the private network of the organization is established.

When an employee of the organization connects to the network access server of the ISP, the authentication and records of usage are forwarded to the NPS server at the organization. The NPS server enables the organization to control user authentication, track usage, and determine which employees are allowed to access the network of the ISP.

The advantages of outsourced dialing are the potential financial and administrative savings. By using an ISP’s hardware and wide area network (WAN) links instead of purchasing and installing your own, you might save a great deal on infrastructure costs. If traveling or remotely located employees dial in to an ISP that has worldwide connections, making a local rather than a long distance connection, you might significantly decrease your long-distance phone bill. And by moving support requirements to the provider, you might eliminate administrative costs.

You can also outsource wireless access. A vendor can provide wireless access in a remote location and use NPS as a RADIUS proxy to forward your employee connection requests to a RADIUS server on your network for authentication and authorization.

Logging to a SQL Server database

You can use Microsoft SQL Server to log NPS accounting information, such as user authentication requests, accounting requests, and periodic data, to a database that warehouses data from multiple NPS servers.

You can configure NPS RADIUS accounting to record accounting information to a stored procedure in a Microsoft SQL Server 2000 or later database.

NPS integration with RRAS

You can configure RRAS to use Windows authentication and accounting or to use RADIUS authentication and accounting. When RADIUS authentication or accounting is selected, any RFC-compliant RADIUS server can be used to provide authentication and authorization for connection requests; using an NPS server is recommended, however, to achieve the optimum level of integration with RRAS in Windows Server 2003 and later environments.

NPS and the Routing and Remote Access service share the same network policies and authentication capabilities. When the Routing and Remote Access service is configured for Windows authentication, local RRAS network policies are used, and logging is recorded in a local file by default. You can also configure the Routing and Remote Access service to log accounting data to a database on a computer running Microsoft SQL Server.

When the Routing and Remote Access service is configured as a RADIUS client to an NPS server, the network policies of the NPS server are used and logging is recorded in a local file on the NPS server or, when NPS SQL Server logging is configured on the NPS server, to a SQL Server database.

Because the policies within NPS at a central large site can be exported to the independent remote access server in a small site, a consistent implementation across NPS and the Routing and Remote Access service is provided. It allows you to deploy the Routing and Remote Access service at small sites without the need for a separate, centralized NPS server; it also provides the capability to scale up to a centralized remote access management model when the need arises to do so. In this case, NPS in conjunction with remote access servers implements a single point of administration for remote access to your network for outsourced-dial, demand-dial, and VPN access.

Scalable configurations

You can scale NPS to network configurations of varying size, from stand-alone servers for small networks to large corporate and ISP networks. As your network grows, you can add access servers, NPS proxy servers, and NPS servers to scale up and out, exporting and importing server configurations to minimize administrative overhead. NPS logging to SQL Server databases also provides the ability to scale the logging of network session information.

Mapping network authentication and authorization for NPS proxy

When you map a user account in a remote user accounts database to a user account in a local user accounts database, the proxy component of NPS can separate the authentication and authorization of connection requests. NPS sends the authentication request to the remote NPS server while also processing the authorization request locally. The NPS proxy can forward password-based user credentials to an external RADIUS server for authentication, and perform

authorization against a user account in an Active Directory domain and a locally configured network policy.

Note

Members of a remote RADIUS server group can be NPS servers that authenticate connection requests by using Active Directory or they can be third-party RADIUS servers that can perform authentication by using other user account databases. Regardless of the user accounts database or RADIUS server used with account mapping, authorization is performed on the local NPS proxy.

To configure NPS to split authentication and authorization between two different NPS servers and user accounts databases, you can map the realm portion of a user name to a remote RADIUS server for authentication, even if that RADIUS server is located on another private network.

For example, NPS can authenticate a visitor from a partner organization by using the partner organization RADIUS server and user accounts database. NPS then authorizes access to your network by using connection request policy settings on your NPS server and a Windows user accounts database in an Active Directory domain that is established for visitor accounts.

You can configure the proxy component with the Remote-RADIUS-to-Windows-User-Mapping attribute in the advanced properties of a connection request policy.

Name changes from Windows Server 2003 Internet Authentication Service (IAS) in Windows Server 2003 is named Network Policy

Server (NPS) in Windows Server 2008 and later versions of the operating system.

IAS remote access policies in Windows Server 2003 are named network policies in NPS in Windows Server 2008 and later versions of the operating system.

The Remote Access Permission setting in user account dial-in properties in the Active Directory Users and Computers MMC snap-in is named Network Access Permission in Windows Server 2008 AD DS, and in later versions of the operating system.

The Control access through Remote Access Policy setting in user account dial-in properties in Active Directory Users and Computers is named Control access through NPS Network Policy in Windows Server 2008 AD DS, and in later versions of the operating system.

NPS TerminologyThe following section provides common RADIUS, NPS, and other terms and their definitions.

Access client. A computer or other device, such as a personal digital assistant (PDA), that initiates a connection attempt to a network by contacting a RADIUS client.

Authentication. The process of verifying the identity of a user or computer. NPS authenticates users and computers by verifying their supplied credentials (a user name and password or a certificate) against the credentials in the user account database.

Authorization. The process of determining whether a user or computer has permission to access the network. NPS authorizes users and computers by using user account dial-in properties in AD DS, with network policies, or by using both user account dial-in properties and network policies.

Certificate. A digitally-signed statement that binds the value of a public key to the identity of the person, device, or service that holds the corresponding private key. Most certificates in common use are based on the X.509v3 certificate standard. Because certificates are generally used to establish identity and create trusts for the secure exchange of information, certification authorities (CAs) can issue certificates to people, to devices (such as computers), and to services running on computers (such as IPsec).

Certificate store. A location on a computer hard drive that contains, or stores, certificates that are issued to the computer, user, or to services running on the computer. In Windows Vista and Windows Server 2008, the certificate store can be viewed by using the Certificates Microsoft Management Console (MMC) snap-in.

Connection request. A RADIUS Access-Request message that contains RADIUS attributes and other information and is sent by a RADIUS client to either a RADIUS proxy or a RADIUS server. RADIUS clients, or network access servers, create connection requests when users, computers, and other devices contact the RADIUS client in an effort to gain access to their network.

Connection request policy. A set 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 NPS receives from RADIUS clients. Connection request policies can be configured to designate which RADIUS servers are used for RADIUS accounting. If you configure authentication in a connection request policy, the settings override authentication settings in all network policies.

Important

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

Extensible Authentication Protocol (EAP). An extension of Point-to-Point Protocol (PPP) that allows 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.

Message-Authenticator attribute. An attribute that contains the encrypted shared secret that is configured on both a RADIUS client and on the NPS server to provide protection from spoofed Access-Request messages and RADIUS message tampering. 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.

Network Access Protection (NAP). 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.

Network access server (NAS). A computer or other device, such as a wireless access point, dedicated VPN device, or authenticating switch, that serves as a gateway between access clients and a network. When a NAS is compliant with the RADIUS protocol, is also called a RADIUS client.

Network policy. A set 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. Network policy settings are applied to the connection when they are returned in an Access-Accept message to the RADIUS client from the NPS server.

NPS dictionary. A read-only list of vendor-specific attributes that is stored by NPS in dnary.xml.

Protected EAP (PEAP) . 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 an NPS server or RADIUS server. PEAP does not specify an authentication method, but provides additional security for other EAP authentication protocols, such as EAP-MS-CHAP v2, that can operate through the TLS encrypted channel provided by PEAP.

Remote Authentication Dial-In User Service (RADIUS). 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, accounting, and auditing services for network administrators that deploy local or remote access to their networks.

RADIUS Access-Accept message. A message created by a RADIUS server that is sent to a RADIUS client. The Access-Accept message tells the RADIUS client that the user or computer

can access the network, and can include NPS network policy settings that allow the RADIUS client to start delivery of service to the access client.

RADIUS Access-Challenge message. A message created by a RADIUS server that is sent to a RADIUS client when the RADIUS server requires more information than was provided in the original Access-Request message.

RADIUS Access-Reject message. A message created by a RADIUS server that is sent to a RADIUS client when the RADIUS server is rejecting a connection attempt. Connection requests can result in an Access-Reject if no network policy matches the connection request, if the user’s or computer’s identity cannot be verified, if the user or computer is not authorized to access the network, or for many other reasons.

RADIUS Access-Request message. A message created by a RADIUS client that contains such attributes as the port ID the user is accessing and the results of the authentication process, such as the user name, the challenge string, and the response of the access client. Also called a connection request.

RADIUS accounting. Part of the RADIUS protocol that allows you to log user authentication and accounting requests to a local file or to a SQL Server database. Accounting logs are used for billing, security, and troubleshooting purposes.

RADIUS Accounting-Request message. A message created by a RADIUS client that is sent to a RADIUS server that contains accounting information for service that is provided to an access client or user. If the RADIUS server is configured to do so, the accounting information can be recorded in an accounting log. NPS provides the ability to log accounting information in a local text file or in a SQL Server database.

RADIUS Accounting-Response message. A message that is created by a RADIUS server that is sent to a RADIUS client upon receipt of an Accounting-Request message and successful recording of the accounting data.

RADIUS attributes. Containers that include a Type, a Length, and a Value that hold information that is sent in RADIUS messages between RADIUS clients and RADIUS servers. One RADIUS message can include multiple RADIUS attributes, each of which holds a specific type of information for which the attribute was designed. For example, the Calling-Station-ID attribute can include a value that is the telephone number from which a dial-up networking session was initiated. A dial-in server that is configured as a RADIUS client can send the Calling-Station-ID attribute, along with other attributes and information, in an Access-Request RADIUS message to a RADIUS server. The RADIUS standard attributes are described in Request for Comments (RFC) 2865 and RFC 2866.

RADIUS client. A network access server — such as a dial-up server, VPN server, TS Gateway server, RADIUS proxy, 802.1X-capable switch, or wireless access point — that is compliant with the RADIUS protocol and uses the RADIUS protocol to communicate with RADIUS servers.

RADIUS proxy. A RADIUS client that is compliant with the RADIUS protocol and that can receive and forward RADIUS messages between other RADIUS clients and RADIUS servers. RADIUS proxies can be configured to forward connection requests to multiple sets of remote RADIUS servers, and are used for load balancing and to provide network access for users whose accounts are located in remote or untrusted domains and forests.

RADIUS server. An authenticating server that is compliant with the RADIUS protocol, and that processes connection requests that it receives from RADIUS clients and RADIUS proxies.

Remote RADIUS server group. A collection of one or more RADIUS servers that is configured on a RADIUS proxy. The RADIUS proxy forwards connection requests to members of remote RADIUS server groups for processing.

Shared secret. A password that is configured on both a RADIUS server and its configured RADIUS clients that assists these entities in verifying the identity of the device with which they are communicating. When the Message-Authenticator attribute is used during the authentication process, the shared secret is encrypted and used as proof of identity during communication between the RADIUS client and server.

User accounts database. 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. User accounts databases can also include accounts for computers and other devices.

Vendor specific attribute (VSA). A RADIUS attribute that is created and supported only by specific RADIUS client manufacturers. 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.

Planning NPS as a RADIUS proxyWhen you deploy Network Policy Server (NPS) as a Remote Authentication Dial-In User Service (RADIUS) proxy, NPS receives connection requests from RADIUS clients, such as network access servers or other RADIUS proxies, and then forwards these connection requests to servers running NPS or other RADIUS servers. You can use these planning guidelines to simplify your RADIUS deployment.

These planning guidelines do not include circumstances in which you want to deploy NPS as a RADIUS server. When you deploy NPS as a RADIUS server, NPS performs authentication, authorization, and accounting for connection requests for the local domain and for domains that trust the local domain.

Before you deploy NPS as a RADIUS proxy on your network, use the following guidelines to plan your deployment:

Plan NPS server configuration.

Plan RADIUS clients.

Plan remote RADIUS server groups.

Plan attribute manipulation rules for message forwarding.

Plan connection request policies.

Plan NPS accounting.

Plan NPS server configuration

When you use NPS as a RADIUS proxy, NPS forwards connection requests to an NPS server or other RADIUS servers for processing. Because of this, the domain membership of the NPS proxy is irrelevant. The proxy does not need to be registered in Active Directory Domain Services (AD DS) because it does not need access to the dial-in properties of user accounts. In addition, you do not need to configure network policies on an NPS proxy because the proxy does not perform authorization for connection requests. The NPS proxy can be a domain member or it can be a stand-alone server with no domain membership.

NPS must be configured to communicate with RADIUS clients, also called network access servers, by using the RADIUS protocol. In addition, you can configure the types of events that NPS records in the event log and you can enter a description for the server.

Key steps

During the planning for NPS proxy configuration, the following steps can be used:

Determine the RADIUS ports that the NPS proxy uses to receive RADIUS messages from RADIUS clients and to send RADIUS messages to members of remote RADIUS server groups. The default User Datagram Protocol (UDP) ports are 1812 and 1645 for RADIUS authentication messages and UDP ports 1813 and 1646 for RADIUS accounting messages.

If the NPS proxy is configured with multiple network adapters, determine the adapters over which you want RADIUS traffic to be allowed.

Determine the types of events that you want NPS to record in the Event Log. You can log rejected connection requests, successful connection requests, or both.

Determine whether you are deploying more than one NPS proxy. To provide fault tolerance, use at least two NPS proxies. One NPS proxy is used as the primary RADIUS proxy and the other is used as a backup. Each RADIUS client is then configured on both NPS proxies. If the primary NPS proxy becomes unavailable, RADIUS clients then send Access-Request messages to the alternate NPS proxy.

Plan the script used to copy one NPS proxy configuration to other NPS proxies to save on administrative overhead and to prevent the incorrect configuration of a server. NPS provides the Netsh commands that allow you to copy all or part of an NPS proxy configuration for import onto another NPS proxy. You can run the commands manually at the Netsh prompt. However, if you save your command sequence as a script, you can run the script at a later date if you decide to change your proxy configurations.

Plan RADIUS clients

RADIUS clients are network access servers, such as wireless access points, virtual private network (VPN) servers, 802.1X-capable switches, and dial-up servers. RADIUS proxies, which forward connection request messages to RADIUS servers, are also RADIUS clients. NPS supports all network access servers and RADIUS proxies that comply with the RADIUS protocol, as described in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," and RFC 2866, "RADIUS Accounting."

In addition, both wireless access points and switches must be capable of 802.1X authentication. If you want to deploy Extensible Authentication Protocol (EAP) or Protected Extensible Authentication Protocol (PEAP), access points and switches must support the use of EAP.

To test basic interoperability for PPP connections for wireless access points, configure the access point and the access client to use Password Authentication Protocol (PAP). Use additional PPP-based authentication protocols, such as PEAP, until you have tested the ones that you intend to use for network access.

Key steps

During the planning for RADIUS clients, the following steps can be used:

Document the vendor-specific attributes (VSAs) you must configure in NPS. If your NASs require VSAs, log the VSA information for later use when you configure your network policies in NPS.

Document the IP addresses of RADIUS clients and your NPS proxy to simplify the configuration of all devices. When you deploy your RADIUS clients, you must configure them to use the RADIUS protocol, with the NPS proxy IP address entered as the authenticating server. And when you configure NPS to communicate with your RADIUS clients, you must enter the RADIUS client IP addresses into the NPS snap-in.

Create shared secrets for configuration on the RADIUS clients and in the NPS snap-in. You must configure RADIUS clients with a shared secret, or password, that you will also enter into the NPS snap-in while configuring RADIUS clients in NPS.

Plan remote RADIUS server groups

When you configure a remote RADIUS server group on an NPS proxy, you are telling the NPS proxy where to send some or all connection request messages that it receives from network access servers and NPS proxies or other RADIUS proxies.

You can use NPS as a RADIUS proxy to forward connection requests to one or more remote RADIUS server groups, and each group can contain one or more RADIUS servers. When you want the NPS proxy to forward messages to multiple groups, configure one connection request policy per group. The connection request policy contains additional information, such as attribute manipulation rules, that tell the NPS proxy which messages to send to the remote RADIUS server group specified in the policy.

You can configure remote RADIUS server groups by using the Netsh commands for NPS, by configuring groups directly in the NPS snap-in under Remote RADIUS Server Groups, or by running the New Connection Request Policy wizard.

Key steps

During the planning for remote RADIUS server groups, the following steps can be used:

Determine the domains that contain the RADIUS servers to which you want the NPS proxy to forward connection requests. These domains contain the user accounts for users that connect to the network through the RADIUS clients you deploy.

Determine whether you need to add new RADIUS servers in domains where RADIUS is not already deployed.

Document the IP addresses of RADIUS servers that you want to add to remote RADIUS server groups.

Determine how many remote RADIUS server groups you need to create. In some cases, it is best to create one remote RADIUS server group per domain, and then add the RADIUS servers for the domain to the group. However, there might be cases in which you have a large amount of resources in one domain, including a large number of users with user accounts in the domain, a large number of domain controllers, and a large number of RADIUS servers. Or your domain might cover a large geographical area, causing you to have network access servers and RADIUS servers in locations that are distant from each other. In these and possibly other cases, you can create multiple remote RADIUS server groups per domain.

Create shared secrets for configuration on the NPS proxy and on the remote RADIUS servers.

Plan attribute manipulation rules for message forwarding

Attribute manipulation rules, which are configured in connection request policies, allow you to identify the Access-Request messages that you want to forward to a specific remote RADIUS server group.

You can configure NPS to forward all connection requests to one remote RADIUS server group without using attribute manipulation rules.

If you have more than one location to which you want to forward connection requests, however, you must create a connection request policy for each location, then configure the policy with the remote RADIUS server group to which you want to forward messages as well as with the attribute manipulation rules that tell NPS which messages to forward.

You can create rules for the following attributes:

Called-Station-ID. The phone number of the network access server (NAS). The value of this attribute is a character string. You can use pattern-matching syntax to specify area codes.

Calling-Station-ID. The phone number used by the caller. The value of this attribute is a character string. You can use pattern-matching syntax to specify area codes.

User-Name. The user name that is provided by the access client and that is included by the NAS in the RADIUS Access-Request message. The value of this attribute is a character string that typically contains a realm name and a user account name.

To correctly replace or convert realm names in the user name of a connection request, you must configure attribute manipulation rules for the User-Name attribute on the appropriate connection request policy.

Key steps

During the planning for attribute manipulation rules, the following steps can be used:

Plan message routing from the NAS through the proxy to the remote RADIUS servers to verify that you have a logical path with which to forward messages to the RADIUS servers.

Determine one or more attributes that you want to use for each connection request policy.

Document the attribute manipulation rules that you plan to use for each connection request policy, and match the rules to the remote RADIUS server group to which messages are forwarded.

Plan connection request policies

The default connection request policy is configured for NPS when it is used as a RADIUS server. Additional connection request policies can be used to define more specific conditions, create attribute manipulation rules that tell NPS which messages to forward to remote RADIUS server groups, and to specify advanced attributes. Use the New Connection Request Policy Wizard to create either common or custom connection request policies.

Key steps

During the planning for connection request policies, the following steps can be used”

Delete the default connection request policy on each server running NPS that functions solely as a RADIUS proxy.

Plan additional conditions and settings that are required for each policy, combining this information with the remote RADIUS server group and the attribute manipulation rules planned for the policy.

Design the plan to distribute common connection request policies to all NPS proxies. Create policies common to multiple NPS proxies on one NPS server, and then use the Netsh commands for NPS to import the connection request policies and server configuration on all other proxies.

Plan NPS accounting

When you configure NPS as a RADIUS proxy, you can configure it to perform RADIUS accounting by using NPS format log files, database-compatible format log files, or NPS SQL Server logging.

You can also forward accounting messages to a remote RADIUS server group that performs accounting by using one of these logging formats.

Key steps

During the planning for NPS accounting, the following steps can be used:

Determine whether you want the NPS proxy to perform accounting services or to forward accounting messages to a remote RADIUS server group for accounting.

Plan to disable local NPS proxy accounting if you plan to forward accounting messages to other servers.

Plan connection request policy configuration steps if you plan to forward accounting messages to other servers. If you disable local accounting for the NPS proxy, each connection request policy that you configure on that proxy must have accounting message forwarding enabled and configured properly.

Determine the logging format that you want to use: IAS format log files, database-compatible format log files, or NPS SQL Server logging.

Planning NPS as a RADIUS serverWhen you deploy Network Policy Server (NPS) as a Remote Authentication Dial-In User Service (RADIUS) server, NPS performs authentication, authorization, and accounting for connection requests for the local domain and for domains that trust the local domain. You can use these planning guidelines to simplify your RADIUS deployment.

These planning guidelines do not include circumstances in which you want to deploy NPS as a RADIUS proxy. When you deploy NPS as a RADIUS proxy, NPS forwards connection requests to a server running NPS or other RADIUS servers in remote domains, untrusted domains, or both.

Before you deploy NPS as a RADIUS server on your network, use the following guidelines to plan your deployment:

Plan NPS server configuration.

Plan RADIUS clients.

Plan the use of authentication methods.

Plan network policies.

Plan NPS accounting.

Plan NPS server configuration

You must decide in which domain the NPS server is a member. For multiple-domain environments, an NPS server can authenticate credentials for user accounts in the domain of which it is a member and for all domains that trust the local domain of the NPS server. To allow the NPS server to read the dial-in properties of user accounts during the authorization process, you must add the computer account of the NPS server to the RAS and NPS servers group for each domain.

After you have determined the domain membership of the NPS server, the server must be configured to communicate with RADIUS clients, also called network access servers, by using the RADIUS protocol. In addition, you can configure the types of events that NPS records in the event log and you can enter a description for the server.

Key steps

During the planning for NPS server configuration, the following steps can be used:

Determine the RADIUS ports that the NPS server uses to receive RADIUS messages from RADIUS clients. The default ports are UDP ports 1812 and 1645 for RADIUS authentication messages and ports 1813 and 1646 for RADIUS accounting messages.

If the NPS server is configured with multiple network adapters, determine the adapters over which you want RADIUS traffic to be allowed.

Determine the types of events that you want NPS to record in the Event Log. You can log rejected authentication requests, successful authentication requests, or both types of requests.

Determine whether you are deploying more than one NPS server. To provide fault tolerance for RADIUS-based authentication and accounting, use at least two NPS servers. One NPS server is used as the primary RADIUS server and the other is used as a backup. Each RADIUS client is then configured on both NPS servers. If the primary NPS server becomes unavailable, RADIUS clients then send Access-Request messages to the alternate NPS server.

Plan the script used to copy one NPS server configuration to other NPS servers to save on administrative overhead and to prevent the incorrect cofiguration of a server. NPS provides the Netsh commands that allow you to copy all or part of an NPS server configuration for import onto another NPS server. You can run the commands manually at the Netsh prompt. However, if you save your command sequence as a script, you can run the script at a later date if you decide to change your server configurations.

Plan RADIUS clients

RADIUS clients are network access servers, such as wireless access points, virtual private network (VPN) servers, 802.1X-capable switches, and dial-up servers. RADIUS proxies, which forward connection request messages to RADIUS servers, are also RADIUS clients. NPS supports all network access servers and RADIUS proxies that comply with the RADIUS protocol as described in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," and RFC 2866, "RADIUS Accounting."

Important

Access clients, such as client computers, are not RADIUS clients. Only network access servers and proxy servers that support the RADIUS protocol are RADIUS clients.

In addition, both wireless access points and switches must be capable of 802.1X authentication. If you want to deploy Extensible Authentication Protocol (EAP) or Protected Extensible Authentication Protocol (PEAP), access points and switches must support the use of EAP.

To test basic interoperability for PPP connections for wireless access points, configure the access point and the access client to use Password Authentication Protocol (PAP). Use additional PPP-based authentication protocols, such as PEAP, until you have tested the ones that you intend to use for network access.

Key steps

During the planning for RADIUS clients, the following steps can be used:

Document the vendor-specific attributes (VSAs) you must configure in NPS. If your network access servers require VSAs, log the VSA information for later use when you configure your network policies in NPS.

Document the IP addresses of RADIUS clients and your NPS server to simplify the configuration of all devices. When you deploy your RADIUS clients, you must configure them to use the RADIUS protocol, with the NPS server IP address entered as the authenticating server. And when you configure NPS to communicate with your RADIUS clients, you must enter the RADIUS client IP addresses into the NPS snap-in.

Create shared secrets for configuration on the RADIUS clients and in the NPS snap-in. You must configure RADIUS clients with a shared secret, or password, that you will also enter into the NPS snap-in while configuring RADIUS clients in NPS.

Plan the use of authentication methods

NPS supports both password-based and certificate-based authentication methods. However, not all network access servers support the same authentication methods. In some cases, you might want to deploy a different authentication method based on the type of network access.

For example, you might want to deploy both wireless and VPN access for your organization, but use a different authentication method for each type of access: EAP-TLS for VPN connections, due to the strong security that EAP with Transport Layer Security (EAP-TLS) provides, and PEAP-MS-CHAP v2 for 802.1X wireless connections.

PEAP with Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) provides a feature named fast reconnect that is specifically designed for use with portable computers and other wireless devices. 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. This provides a better experience for wireless users and allows them to move between access points without having to retype their credentials.

Because of fast reconnect and the security that PEAP-MS-CHAP v2 provides, PEAP-MS-CHAP v2 is a logical choice as an authentication method for wireless connections.

For VPN connections, EAP-TLS is a certificate-based authentication method that provides strong security that protects network traffic even as it is transmitted across the Internet from home or mobile computers to your organization VPN servers.

Certificate-based authentication methods

Certificate-based authentication methods have the advantage of providing strong security; and they have the disadvantage of being more difficult to deploy than password-based authentication methods.

Both PEAP-MS-CHAP v2 and EAP-TLS are certificate-based authentication methods, but there are many differences between them and the way in which they are deployed.

EAP-TLS

EAP-TLS uses certificates for both client and server authentication, and requires that you deploy a public key infrastructure (PKI) in your organization. Deploying a PKI can be complex, and requires a planning phase that is independent of planning for the use of NPS as a RADIUS server.

With EAP-TLS, the NPS server enrolls a server certificate from a certification authority (CA), and the certificate is saved on the local computer in the certificate store. During the authentication process, server authentication occurs when the NPS server sends its server certificate to the access client to prove its identity to the access client. The access client examines various certificate properties to determine whether the certificate is valid and is appropriate for use during server authentication. If the server certificate meets the minimum server certificate requirements and is issued by a CA that the access client trusts, the NPS server is successfully authenticated by the client.

Similarly, client authentication occurs during the authentication process when the client sends its client certificate to the NPS server to prove its identity to the NPS server. The NPS server examines the certificate, and if the client certificate meets the minimum client certificate requirements and is issued by a CA that the NPS server trusts, the access client is successfully authenticated by the NPS server.

Although it is required that the server certificate is stored in the certificate store on the NPS server, the client or user certificate can be stored in either the certificate store on the client or on a smart card.

For this authentication process to succeed, it is required that all computers have your organization's CA certificate in the Trusted Root Certification Authorities certificate store for the Local Computer and the Current User.

PEAP-MS-CHAP v2

PEAP-MS-CHAP v2 uses a certificate for server authentication and password-based credentials for user authentication. Because certificates are used only for server authentication, you are not required to deploy a PKI in order to use PEAP-MS-CHAP v2. When you deploy PEAP-MS-CHAP v2, you can obtain a server certificate for the NPS server in one of the following two ways:

You can install Active Directory Certificate Services (AD CS), and then autoenroll certificates to NPS servers. If you use this method, you must also enroll the CA certificate to client computers connecting to your network so that they trust the certificate issued to the NPS server.

You can purchase a server certificate from a public CA such as VeriSign. If you use this method, make sure that you select a CA that is already trusted by client computers. To determine whether client computers trust a CA, open the Certificates Microsoft Management Console (MMC) snap-in on a client computer, and then view the Trusted Root Certification Authorities store for the Local Computer and for the Current User. If there is a certificate from the CA in these certificate stores, the client computer trusts the CA and will therefore trust any certificate issued by the CA.

During the authentication process with PEAP-MS-CHAP v2, server authentication occurs when the NPS server sends its server certificate to the client computer. The access client examines various certificate properties to determine whether the certificate is valid and is appropriate for use during server authentication. If the server certificate meets the minimum server certificate requirements and is issued by a CA that the access client trusts, the NPS server is successfully authenticated by the client.

User authentication occurs when a user attempting to connect to the network types password-based credentials and tries to log on. NPS receives the credentials and performs authentication and authorization. If the user is authenticated and authorized successfully, and if the client computer successfully authenticated the NPS server, the connection request is granted.

Key steps

During the planning for the use of authentication methods, the following steps can be used:

Identify the types of network access you plan to offer, such as wireless, VPN, 802.1X-capable switch, and dial-up access.

Determine the authentication method or methods that you want to use for each type of access. It is recommended that you use the certificate-based authentication methods that provide strong security; however, it might not be practical for you to deploy a PKI, so other authentication methods might provide a better balance of what you need for your network.

If you are deploying EAP-TLS, plan your PKI deployment. This includes planning the certificate templates you are going to use for server certificates and client computer certificates. It also includes determining how to enroll certificates to domain member and non-domain member computers, and determining whether you want to use smart cards.

If you are deploying PEAP-MS-CHAP v2, determine whether you want to install AD CS to issue server certificates to your NPS servers or whether you want to purchase server certificates from a public CA, such as VeriSign.

Plan network policies

Network policies are used by NPS to determine whether connection requests received from RADIUS clients are authorized. NPS also uses the dial-in properties of the user account to make an authorization determination.

Because network policies are processed in the order in which they appear in the NPS snap-in, plan to place your most restrictive policies first in the list of policies. For each connection request, NPS attempts to match the conditions of the policy with the connection request properties. NPS examines each network policy in order until it finds a match. If it does not find a match, the connection request is rejected.

Key steps

During the planning for network policies, the following steps can be used:

Determine the preferred NPS processing order of network policies, from most restrictive to least restrictive.

Determine the policy state. The policy state can have the value of enabled or disabled. If the policy is enabled, NPS evaluates the policy while performing authorization. If the policy is not enabled, it is not evaluated.

Determine the policy type. You must determine whether the policy is designed to grant access when the conditions of the policy are matched by the connection request or whether the policy is designed to deny access when the conditions of the policy are matched by the connection request. For example, if you want to explicitly deny wireless access to the members of a Windows group, you can create a network policy that specifies the group, the wireless connection method, and that has a policy type setting of Deny access.

Determine whether you want NPS to ignore the dial-in properties of user accounts that are members of the group on which the policy is based. When this setting is not enabled, the dial-in properties of user accounts override settings that are configured in network policies. For example, if a network policy is configured that grants access to a user but the dial-in properties of the user account for that user are set to deny access, the user is denied access. But if you enable the policy type setting Ignore user account dial-in properties, the same user is granted

access to the network.

Determine whether the policy uses the policy source setting. This setting allows you to easily specify a source for all access requests. Possible sources are a Terminal Services Gateway (TS Gateway), a remote access server (VPN or dial-up), a DHCP server, a wireless access point, and a Health Registration Authority server. Alternatively, you can specify a vendor-specific source.

Determine the conditions that must be matched in order for the network policy to be applied.

Determine the settings that are applied if the conditions of the network policy are matched by the connection request.

Determine whether you want to use, modify, or delete the default network policies.

Plan NPS accounting

NPS provides the ability to log RADIUS accounting data, such as user authentication and accounting requests, in three formats: IAS format, database-compatible format, and Microsoft SQL Server logging. IAS format and database-compatible format create log files on the local NPS server in text file format. SQL Server logging provides the ability to log to a SQL Server 2000 or SQL Server 2005 XML-compliant database, extending RADIUS accounting to leverage the advantages of logging to a relational database.

Key steps

During the planning for NPS accounting, the following steps can be used:

Determine whether you want to store NPS accounting data in log files or in a SQL Server database.

NPS accounting using local log files

Recording user authentication and accounting requests in log files is used primarily for connection analysis and billing purposes, and is also useful as a security investigation tool, providing you with a method for tracking the activity of a malicious user after an attack.

Key steps

During the planning for NPS accounting using local log files, the following steps can be used:

Determine the text file format that you want to use for your NPS log files.

Choose the type of information that you want to log. You can log accounting requests, authentication requests, and periodic status.

Determine the hard disk location where you want to store your log files.

Design your log file backup solution. The hard disk location where you store your log files should be a location that allows you to easily back up your data. In addition, the hard disk location should be protected by configuring the access control list (ACL) for the folder where the log files are stored.

Determine the frequency at which you want new log files to be created. If you want log files to be created based on the file size, determine the maximum file size allowed before a new log file is created by NPS.

Determine whether you want NPS to delete older log files if the hard disk runs out of storage space.

Determine the application or applications that you want to use to view accounting data and produce reports.

NPS SQL Server logging

NPS SQL Server logging is used when you need session state information, for report creation and data analysis purposes, and to centralize and simplify management of your accounting data. NPS provides the ability to use SQL Server logging to record user authentication and accounting requests received from one or more network access servers to a data source on a computer running the Microsoft SQL Server Desktop Engine (MSDE 2000), SQL Server 2000, or SQL Server 2005. Accounting data is passed from NPS in XML format to a stored procedure in the database, which supports both structured query language (SQL) and XML (SQLXML). Recording user authentication and accounting requests in an XML-compliant SQL Server database enables multiple NPS servers to have one data source.

Key steps

During the planning for NPS accounting by using NPS SQL Server logging, the following steps can be used:

Determine whether you or another member of your organization has SQL Server 2000 or SQL Server 2005 relational database development experience and you understand how to use these products to create, modify, administer, and manage SQL Server databases.

Determine whether SQL Server is installed on the NPS server or on a remote computer.

Design the stored procedure that you will use in your SQL Server database to process incoming XML files that contain NPS accounting data.

Design the SQL Server database replication structure and flow.

Determine the application or applications that you want to use to view accounting data and produce reports.

Plan to use network access servers that send the Class attribute in all accounting-requests. The Class attribute is sent to the RADIUS client in an Access-Accept message, and is useful for correlating Accounting-Request messages with authentication sessions. If the Class attribute is sent by the network access server in the accounting request messages, it can be used to match the accounting and authentication records. The combination of the attributes Unique-Serial-Number, Service-Reboot-Time, and Server-Address must be a unique identification for each authentication that the server accepts.

Plan to use network access servers that support interim accounting.

Plan to use network access servers that send Accounting-on and Accounting-off messages.

Plan to use network access servers that support the storing and forwarding of accounting data. Network access servers that support this feature can store accounting data when the network access server cannot communicate with the NPS server. When the NPS server is available, the network access server forwards the stored records to the NPS server, providing increased reliability in accounting over network access servers that do not provide this feature.

Plan to always configure the Acct-Interim-Interval attribute in network policies. The Acct-Interim-Interval attribute sets the interval (in seconds) between each interim update that the network access server sends. According to RFC 2869, the value of the Acct-Interim-Interval attribute must not be smaller than 60 seconds, or one minute, and should not be smaller than 600 seconds, or 10 minutes. For more information, see RFC 2869, "RADIUS Extensions."

Ensure that logging of periodic status is enabled on your NPS servers.

Components of NPSThe following sections describe Network Policy Server (NPS) components that you can use to deploy NPS as a RADIUS server, RADIUS proxy, or as a NAP health policy server. You can configure these components by using the NPS console, the NPS Microsoft Management Console (MMC) snap-in, or the Netsh commands for NPS.

In this section

RADIUS Clients and Servers

Policies

Network Access Protection (NAP)

Accounting

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, 802.1X-capable switch, remote access dial-up, and virtual private network (VPN) connections. When you use a server running 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.

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.

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.

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.

Note 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 by using advanced configuration, open the NPS console and then click the arrow next to Advanced Configuration to expand this section.

The following advanced configuration items are provided:

Configure RADIUS server

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

Configure RADIUS proxy

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

Configure NAP policy server

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

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.

RADIUS Clients and Servers

In this section

RADIUS Clients

Remote RADIUS Server Groups

All network access servers from which you want NPS to receive connection requests must be configured in the NPS console as RADIUS clients. When you configure RADIUS clients in the NPS console, you are enabling NPS to receive connection requests from the network access servers. In addition, you must separately configure the physical network access servers to send connection requests to the NPS server.

If you configure the NPS server as a RADIUS proxy, NPS forwards connection requests to other RADIUS servers for processing. These RADIUS servers, which can be NPS servers or other RADIUS servers, must be configured in the NPS console as members of a remote RADIUS server group. When you configure RADIUS servers as members of a remote RADIUS server group in the NPS console, you are enabling NPS to forward connection requests to the remote RADIUS servers. In addition, you must separately configure the physical RADIUS servers to receive connection requests from the NPS proxy server.

The following topics provide more detail about RADIUS clients and remote RADIUS server groups.

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 portable computers and other computers running client

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

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

RADIUS client examples

Examples of network access servers are:

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

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

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

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

RADIUS Access-Request messages

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

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

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

NPS as a RADIUS client

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

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

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

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

RADIUS client properties

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

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

Client name

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

IP address

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

Client-Vendor

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

Shared secret

A text string that is used as a password between RADIUS clients, RADIUS servers, and RADIUS proxies. When the Message Authenticator attribute is used, the shared secret is

also used as the key to encrypt RADIUS messages. This string must be configured on the RADIUS client and in the NPS snap-in.

Message Authenticator attribute

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

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

Client is NAP-capable

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

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

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, configure a remote RADIUS server group first, and then 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.

PoliciesIn this section

Connection Request Policies

Network Policies

Health Policies

NPS evaluates each policy type in the following manner:

Connection request policies. Evaluation is performed on the policies in the order in which they appear in the NPS console.

Network policies. Evaluation is performed on the policies in the order in which they appear in the NPS console.

Health policies. Evaluation is performed only when a health policy is configured as a condition of a network policy that matches the connection request.

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 (NAS). 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:

Required Authentication Methods

Forwarding Connection Request

Specify a Realm Name

RADIUS Attributes

Required Authentication Methods

On the Settings tab of a connection request policy, in Required Authentication Methods, you can select Authentication Methods and then, in the details pane, enable the Override network policy authentication settings check box. If you enable this check box, 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 is 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 then 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.

Allowing unauthenticated access

If you choose to override the authentication settings that are configured in all network policies and to enable the connection request policy authentication setting Allow clients to connect without negotiating an authentication method, it is recommended that you also configure the connection request policy with the Authenticate requests on this server setting, as follows:

1. On the connection request policy Settings tab, in Forwarding Connection Request, click Authentication.

2. In the details pane of the NPS console, ensure that Authenticate requests on this server is selected.

With Authenticate requests on this server enabled, NPS logs client and connection request properties when clients connect; without this property enabled, access clients can connect to the network without authentication and client properties are not logged.

Forwarding Connection Request

In Forwarding Connection Request, you can select either Authentication or Accounting to specify whether NPS forwards the authentication request or accounting request to a remote RADIUS server group or whether NPS processes the authentication or accounting request locally. Authentication requests and accounting requests do not have to be processed by the same NPS server, even if the authentication and accounting requests are part of the same connection request. For example, if you configure Authentication to forward requests to a remote RADIUS server group, you can also configure Accounting to be processed locally or forwarded to a different remote RADIUS server group than the server used for the authentication request.

By using the Authentication setting, you can configure NPS to process authentication requests locally or, if you enable Forward requests to the following remote RADIUS server group for authentication, you can select or create a remote RADIUS server group to which the local NPS server forwards authentication requests.

You can specify the following forwarding request settings 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 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 setting cannot be used when the authentication protocol of the access client is MS-CHAP v2, PEAP-MS-CHAP v2, PEAP-TLS, or EAP-TLS, all 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 setting is used, the Access-Accept message is returned. However, the authenticating server does not provide validation to the access client and mutual authentication fails, resulting in a failed connection request.

By using the Accounting setting, you can configure NPS 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 independently from 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. Because of this, if you configure both local logging and a connection request policy to forward accounting requests, accounting information is logged on the local server and on the remote server.

If you want accounting information logged remotely but not locally, you must configure the local NPS server not to perform accounting, while also configuring accounting in a connection request policy to forward accounting data to a remote RADIUS server group.

Specify a Realm Name

You can use this setting to 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.

RADIUS Attributes

In RADIUS Attributes, you can select Standard or Vendor Specific to add attributes to the connection request policy settings. You can 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 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 that contain 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).

Adding a custom vendor-specific attribute (VSA)

If your RADIUS client requires a VSA that is not in the list of VSAs provided in the NPS console, you can create a custom VSA by using the parameters supplied by the RADIUS client vendor. To create a custom VSA in the settings of a connection request policy, open the policy, click Settings, click Vendor Specific, and then, in the details pane, click Add. In the Add Vendor-Specific Attribute dialog box, click Vendor, click Custom, and then click Add. Configure your VSA according to the RADIUS client vendor requirements.

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.

Network Policies

A network policy is a set 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 a server running Network Policy Server (NPS) performs client health checks during the authorization process.

In this section

Overview Properties

Access Permission

Conditions Properties

Constraints Properties

Settings Properties

When processing connection requests as a RADIUS server, NPS performs both authentication and authorization for the connection request. During the authentication process, NPS verifies the identity of the user or computer that is connecting to the network. During the authorization process, NPS determines whether the user or computer is allowed to access the network.

To make this determination, NPS uses network policies that are configured in the NPS Microsoft Management Console (MMC) snap-in. NPS also examines the dial-in properties of the user account in Active Directory Domain Services (AD DS) to perform authorization.

Note In Internet Authentication Service (IAS) in the Windows Server 2003 operating systems, network policies were called remote access policies.

Network policies can be viewed as rules. Each rule has a set of conditions and settings. NPS compares the conditions of the rule to the properties of connection requests. If a match occurs between the rule and the connection request, the settings defined in the rule are applied to the connection.

When multiple network policies are configured in NPS, they are an ordered set of rules. NPS checks each connection request against the first rule in the list, then the second, and so on, until a match is found.

Each network policy has a Policy State setting that allows you to enable or disable the policy. When you disable a network policy, NPS does not evaluate the policy when authorizing connection requests.

Important If you want NPS to evaluate a network policy when performing authorization for connection requests, you must configure the Policy State setting by selecting the Policy enabled check box.Network policy properties

There are four categories of properties for each network policy:

Overview

These properties allow you to specify whether the policy is enabled, whether the policy grants or denies access, and whether a specific network connection method, or type of network access server, is required for connection requests. Overview properties also allow you to specify whether the dial-in properties of user accounts in AD DS are ignored. If you select this option, only the settings in the network policy are used by NPS to determine whether the connection is authorized.

Conditions

These properties allow you to specify the conditions that the connection request must have in order to match the network policy; if the conditions configured in the policy match the connection request, NPS applies the settings designated in the network policy to the connection. For example, if you specify the 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.

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.

Settings

These properties allow you to specify the settings that NPS applies to the connection request if all of the network policy conditions for the policy are matched.

When you add a new network policy by using the NPS 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.

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 you want the server running Network Policy Server (NPS) to ignore the dial-in properties of user accounts in Active Directory Domain Services (AD DS) when using the policy to perform authorization for a connection attempt. For more information, see Access Permission.

Note If you have many user accounts in AD DS, it is recommended that you configure the dial-in properties of user accounts so that network access is controlled 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.

Network connection method. When used for most or all network policies, this setting allows NPS to filter policies and to process only relevant policies when it receives a connection request from a specific type of network access server. For example, if NPS receives a connection request from an Ethernet switch, it will not process network policies for Routing and Remote Access service (RRAS) servers or Terminal Services Gateway (TS Gateway) servers, but it will evaluate policies for Ethernet switches. (If NPS does not find an Ethernet policy that matches the connection request, NPS then evaluates policies with a Type of network access server value of Unspecified.) Choose from the following network connection methods:

o 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 TS Gateway servers, RRAS servers that provide VPN and dial-up access, DHCP servers, 802.1X wireless access points, 802.1X-capable switches, Health Registration Authority (HRA) servers, and Host Credentials Authorization Protocol (HCAP) servers.

Important When you configure network policies for wireless access points, you must use a Type of network access server value of Unspecified.

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

o Ethernet. If specified, NPS evaluates the network policy for all connection requests that originate from IEEE 802.1X-capable switches.

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

o Health Registration Authority. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Health Registration Authority (HRA).

o HCAP server. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Host Credentials Authorization Protocol (HCAP).

o DHCP Server. If specified, NPS evaluates the network policy for connection requests that originate from servers that are running Dynamic Host Configuration Protocol (DHCP).

Conditions Properties

Every network policy must have at least one configured condition. NPS provides many condition 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.

Following are the Groups conditions you can configure in a network policy:

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 Credentials 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 an HCAP server running both Internet Information Services (IIS) and NPS.

Following are the HCAP conditions you can configure in a 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

Following is the day and time restriction condition that you can configure in a network policy:

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

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 by using the Windows Security Health Validator (WSHV) — 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 WSHV. If you select the health policy that designates that all client computers must pass all health checks, the statement of health (SoH) sent to NPS from the 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, service pack number, or both), role (client or server), and architecture (x86, x64, or ia64) required for the computer configuration to match the policy. In the Windows interface, in the Operating System Properties dialog box, both Operating System Version and Service Pack (SP) Number have default values of five zeroes, a decimal point, and then five zeroes (00000.00000). This value equals zero (0). To edit these fields, you must place the cursor to the left of the character (0) that you want to replace, and then type the new number. For example, to enter an Operating System Version of 6.1, place the cursor after the fourth zero, and then type 61.

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, 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 a 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 the policy. This condition is useful when connection request policy is configured with authentication. When authentication is configured in a connection request policy, the authentication settings in the 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).

RADIUS client properties

Following are the RADIUS client conditions that you can configure in a network policy:

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

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 a 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 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 by using a media type of Virtual (VPN), the conditions of the policy are not met.

Constraints Properties

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

Settings Properties

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:

Network Access Type

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 by using 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 must have antivirus software installed, enabled, and configured with the latest signature updates, autoremediation causes the 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 a Host Credentials Authorization Protocol (HCAP) server, allows you to integrate your 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 an HCAP server.

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.

Health Policies

Health policies consist of one or more system health validators (SHVs) and other settings that allow you to define client computer configuration requirements for the Network Access Protection (NAP)-capable computers that attempt to connect to your network.

When NAP-capable clients attempt to connect to the network, the client computer sends a statement of health (SoH) to Network Policy Server (NPS). The SoH is a report of the client configuration state, and NPS compares the SoH to the requirements defined in health policy. If the client configuration state does not match the requirements defined in health policy, NPS takes one of the following actions, depending on how NAP is configured:

The connection request by the NAP client is rejected.

The NAP client is placed on a restricted network where it can receive updates from remediation servers that bring the client into compliance with health policy. After the client is compliant with health policy, it is allowed to connect.

The NAP client is allowed to connect to the network despite being noncompliant with health policy.

You can define client health policies in NPS by adding one or more SHVs to the health policy.

After a health policy is configured with one or more SHVs, you can add the health policy to the Health Policies condition of a network policy that you want to use to enforce NAP when client computers connect to your network.

Using multiple SHVs in a health policy

The Windows Security Health Validator (WSHV) is included by default in NPS. Other companies might also provide additional SHV and system health agent (SHA) pairs for their NAP-compatible products.

If you want to use a NAP-compatible product, you can follow the product's documentation to install the SHA on NAP-capable client computers, and then install the SHV on the server running NPS. After you have installed the SHV on the NPS server, you can configure the SHV and then add the SHV to a health policy.

After your health policy is configured with the SHVs you want to use, you can add the health policy to the settings of a network policy.

Network Access Protection (NAP)In this section

System Health Validators

Remediation Server Groups

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.

When you deploy NAP, a server running Network Policy Server (NPS) serves as a health policy server. You create health policies in NPS that specify the required configuration of NAP-capable computers that connect to your network, and then configure one or more network policies with the health policy. NPS then performs health checks while processing the network policy and performing authorization.

Note In Windows Server 2003, network policies were named remote access policies.

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 NPS servers 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 customers of the software vendor 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.

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, the NAP agent on the client computer sends a SoH to

NPS that reports this fact. NPS compares the SoH to the configuration of the WSHV in NPS; NPS then determines that the client computer is not compliant with health policy.

WSHV settings

The Windows Security Health Validator (WSHV) provides the following settings that you can configure based on the requirements of your deployment.

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 WSHA on the client computer.

If you select A firewall is enabled for all network connections, WSHA on the client computer checks if firewall software is running on the client computer, and then takes the following actions:

If the client computer is not running firewall software, the client computer is restricted to a remediation network until firewall software is installed and running.

If the only firewall software running on the client computer is a firewall that is not compliant with Windows Security Center, WSHA reports to the Network Access Protection (NAP) service that no firewall is enabled, and the client computer is restricted to a remediation network.

Important If you select A firewall is enabled for all network connections and client computers are not running Windows Firewall or other Windows Security Center-compliant firewall software, client computers cannot connect to your network.

If you do not select A firewall is enabled for all network connections, WSHA on the client computer 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 enabled, 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 updating is enabled, you enable NAP autoremediation, and WSHA on the client computer reports that Microsoft Update Services is not enabled, then WSHV directs WSHA on the client computer to enable Microsoft Update Services and to configure Microsoft Update Services to automatically download and install updates.

Note

You can configure autoremediation by using the NAP Client Management MMC snap-in.

Security Update Protection

Do not configure Security Update Protection in your WSHV policy unless client computers on your network are running Windows Update Agent. In addition, client computers that are running

Windows Update Agent must be registered with a server running Windows Server Update Service (WSUS).

Important

If these conditions are not met and you configure Security Update Protection in your WSHV policy, the policy cannot be enforced by WSHA on the client computer. 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 as follows:

If the client checked the WSUS server for updates 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 checked the WSUS server for updates 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 check for security updates, does not download 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.

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

AccountingThere 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. By default, local file logging in database-compatible format is enabled.

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

Used to allow multiple servers running NPS to record accounting data to one data source. Also provides the advantages of using a relational database. By default, SQL Server logging is not enabled.

Important To deploy NPS SQL Server logging, you must first deploy and configure a compatible version of Microsoft SQL Server.

How Network Policy Server WorksIn this section

NPS Architecture

NPS Protocols

NPS Processes and Interactions

NPS Accounting

NPS ArchitectureThe following illustration depicts NPS architecture, including the components upon which NPS has external dependencies.

Network Policy Server components

The following sections provide additional information about the components in the NPS architecture.

 Component Description

Network access servers

RADIUS-compliant network access servers, such as VPN servers, 802.1X wireless access points and authenticating switches, and dial-up servers that send connection requests to the NPS server using the RADIUS protocol. Network access servers are also called RADIUS clients.

Remote Authentication Dial-In User Service (RADIUS) protocol

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, accounting, and auditing services for network administrators that deploy local or remote access to their networks.

RADIUS messages Access-Request and other RADIUS messages that are sent between network access servers and the NPS server using the RADIUS protocol.

Local Microsoft components

When additional components, such as RRAS, TS Gateway, DHCP, and HCAP are installed on the local NPS server, the components use IAS Helper (Iashlpr.dll) to exchange information with NPS. If these components are not installed on the local computer but are installed on remote computers, IAS Helper is not used; instead, the RADIUS protocol is used to exchange information with the local NPS server.

NPS server

A computer running Windows Server 2008 and Network Policy Server that accepts connection requests from configured RADIUS clients and either processes or forwards the requests, depending on how NPS is configured. In addition, NPS can make determinations about client health through configured health policies if Network Access Protection (NAP) is deployed.

NPS serviceA service that runs within Svchost.exe and can be configured by using the Services MMC snap-in. By default, the service runs automatically at system startup after you install NPS.

NPS policy engine

The NPS policy engine processes connection requests when NPS is configured as a RADIUS proxy, RADIUS server, and NAP policy server. Depending on the NPS configuration, NPS can forward a connection request, perform authentication and authorization for a connection request against the AD DS user accounts database or SAM database, or verify the client computer configuration of a NAP-capable client.

SDO Layer - Read Only

The NPS service loads its own copy of the Server Data Objects (SDO) dynamic link libraries (DLLs); the NPS service reads information from the SDO layer, but does not write information to the SDO layer.

NPS MMC snap-in/console

You can use the NPS console or the NPS MMC snap-in to configure NPS using the Windows interface.

SDO Layer - Read-Write

The NPS MMC console/snap-in loads its own copy of the SDO DLLs, and both reads information from and writes information to the SDO Layer. The SDO API makes it possible to programmatically configure and administer a computer running Windows Server 2008 and NPS. For more information, see Server Data Objects.

Netsh NPS A context of the Netsh command-line tool that you can use to configure NPS by using the command line, batch files, or scripts.

SDO Layer - Read-Write

Netsh NPS loads its own copy of the SDO DLLs, and both reads information from and writes information to the SDO Layer.

IAShost.exe

A process of NPS that hosts the DataStore Component Object Model (COM) server. At runtime, there is a single instance of IAShost.exe to which other components, such as the NPS service, the NPS MMC, and Netsh NPS, read and write NPS configuration data.

DataStore COM server

A service within IAShost.exe that manages read operations from Dnary.xml and both read and write operations to IAS.xml. By using the Distributed COM (DCOM) interface, the following components use the DataStore COM server to access the NPS server configuration: the NPS service on the local computer; the Netsh commands for NPS on the local computer; the NPS console or MMC snap-in on the local computer; and the NPS MMC snap-in on remote NPS servers. For more information, see DCOM Technical Overview.

IAS.xml

An extensible markup language (XML) file stored on the local hard drive that contains NPS configuration information. IAShost.exe reads information from and writes information to IAS.xml. By default, the IAS.xml file location is %windir%\System32\ias.

Dnary.xml

Dnary.xml is an extensible markup language (XML) file stored on the local hard drive that contains the NPS library of RADIUS attributes. IAShost.exe reads information from Dnary.xml. By default, the Dnary.xml file location is %windir%\System32\ias.

Local log file

When the NPS accounting configuration specifies the recording of accounting data in a local log file (either database-compatible format or IAS format), the text file is stored on the local hard drive. By default, the local log file location is %windir%\system32\LogFiles

External Dependencies

NPS has the following dependencies on external components. The dependency does not exist, however, unless NPS is configured to use the external resource. For example, NPS is not dependent on SQL Server unless NPS is configured to use SQL Server logging.

 Component DescriptionLDAP queries When an NPS server is a member of an Active Directory domain, Lightweight

Directory Access Protocol (LDAP) queries are sent to global catalog servers when NPS performs authentication against the Active Directory Domain Services (AD DS) user account database. Query results are then sent back to

NPS.

If an NPS server is not a domain member, authentication is performed against the local SAM database rather than against a domain controller.

AD DSNPS performs authentication against the credentials stored in the AD DS user accounts database during the authentication process, and checks user account dial-in properties during the authorization process.

NAPNetwork Access Protection allows NPS to function as a health policy server, verifying that NAP-capable computers connecting to the network are compliant with health policy.

QSHVHost QSHVHost is a NAP component required to facilitate communication between NPS and other NAP components.

EAPWhen EAP authentication is configured in a connection request policy or network policy and the Access-Request matches a policy, NPS uses EAP authentication to verify the identity of the access client or user.

EAPHost

When configured to use EAP authentication, NPS uses EAPHost during the authentication process. In Windows Server 2008 and Windows Vista, EAPHost updates the EAP implementation in Windows for the latest Internet standards and provides a new modular architecture to extend Windows with EAP authentication methods and supplicants.

Accounting data (XML document)

When NPS is configured to use SQL Server logging, it sends accounting data in an XML document to the SQL Server database for processing and storage in the database.

SQL ServerThe SQL Server database is configured with a stored procedure that receives and processes the incoming XML document from NPS, in addition to a database where the NPS data is stored.

RADIUS extension DLLs and NPS architecture

When you incorporate RADIUS extension DLLs into the NPS architecture, you are modifying the NPS policy engine in such a way that Access-Request messages are processed in a different manner. The primary differences are:

If you install an authentication extension DLL, NPS calls the DLL before performing authentication and authorization.

If you install an authorization extension DLL, NPS performs authentication and authorization before calling the authorization DLL.

NPS Extensions

This section describes how to implement DLLs to extend the functionality of NPS. It describes the interaction between NPS and the DLLs, and presents some design considerations regarding the DLLs.

NPS provides two extension points, one for authentication and the other for authorization. Authentication refers to verifying the identity of the user. Authorization refers to determining what services the network should provide to the user. The two extension points correspond to Authentication Extension DLLs and Authorization Extension DLLs. Each extension point can support multiple DLLs.

NPS provides both authentication and authorization services. Authentication Extension DLLs are called by NPS prior to the built-in NPS authentication and authorization. Authorization Extension DLLs are called after NPS authentication and authorization.

Notes

If an Authentication Extension DLL returns ACCEPT, the packet skips the NPS authentication and goes directly to NPS authorization.

When multiple Authentication Extension DLLs are present, the rest of the Extension DLLs might be skipped as well..

If an Authentication Extension DLL returns CONTINUE, the packet goes to NPS authentication, and then to NPS authorization.

When multiple Authentication Extension DLLs are present, the rest of the Authentication Extension DLLs are invoked before NPS authentication.

The following topics describe the Extension DLLs in more detail:

Setting Up the Extension DLLs Invoking the Extension DLLs User Identification Attributes

The following diagram illustrates the flow of packets through an NPS RADIUS server that is expanded using Extension DLLs.

NPS ProtocolsAuthentication protocols are used to transmit user or computer logon credentials. If you configure NPS to process some or all of the connection requests that it receives from RADIUS clients, the authentication protocols that you have configured in network policy or connection request policy are used to transmit user or computer credentials so that NPS can verify the identity of the user or computer that is attempting to access the network.

NPS uses the RADIUS protocol to communicate with RADIUS clients and other RADIUS servers.

These protocols are detailed in the following sections.

In this section

Authentication Protocols

RADIUS Protocol

Authentication Protocols

In this section

Certificate-based Authentication Protocols

Password-based Authentication Protocols

Unauthenticated Access

When users attempt to connect to your network through network access servers, 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.

Authentication protocols allow the transmission of these credentials from the computer or user who is proving their identity to the authenticator that is verifying their identity. Authentication methods typically use an authentication protocol that is negotiated by the Remote Authentication Dial-In User Service (RADIUS) server and the access client during the connection establishment process.

Each authentication protocol has advantages and disadvantages in terms of security, usability, and breadth of support. The authentication protocol used to transmit credentials is determined by the configuration of the following RADIUS infrastructure components: the access client, the RADIUS client, and the RADIUS server.

Note NPS also supports unauthenticated connections, although in most circumstances unauthenticated access is not recommended for security reasons.

You can configure NPS to accept the use of multiple authentication protocols. You can also configure your RADIUS clients to attempt to negotiate a connection by using 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 by using Extensible Authentication Protocol (EAP) first, then MS-CHAP v2, then MS-CHAP v1 , then CHAP, 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.

Note Before deploying authentication with NPS, consult your RADIUS client documentation to determine the authentication methods that are supported by the device.

In addition, you can use network policies to implement different authentication methods depending on the type of access client that is being authenticated. For example, you can create two network policies, one for VPN clients and one for wireless clients—each of which uses a different authentication method. The network policy for VPN clients can be configured to use EAP-TLS with smart cards or certificates as the authentication method and authentication type, while the network policy for wireless clients can be configured to use PEAP-MS-CHAP v2, which provides secure password authentication.

Authentication methods

Some authentication methods implement the use of 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 then NPS verifies the credentials against the user accounts database.

Other authentication methods implement the use of certificate-based credentials for the user, the client computer, the NPS server, or some combination of these types of certificates. Certificate-based authentication methods provide stronger security than password-based authentication methods.

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

The following sections provide additional information on the authentication methods and protocols available for use with NPS.

Certificate-based Authentication Protocols

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.

In this section

Extensible Authentication Protocol

Protected Extensible Authentication Protocol

Certificate Templates and Requirements

Mapping with Certificate-Based Authentication

Two authentication methods, when configured with certificate-based authentication types, use certificates: Extensible Authentication Protocol (EAP) and Protected EAP (PEAP). By using EAP, you can configure the authentication type Transport Layer Security (EAP-TLS), and with PEAP you can configure the authentication types TLS (PEAP-TLS) and Microsoft Challenge Handshake Authentication Protocol version 2 (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 virtual private network (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 (AD CS) 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 deployments and Active Directory replication

Some authentication methods, such as PEAP and EAP, 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, a restart of the computer is required. After the computer restarts and you log on to the domain, Group Policy is applied. If you have previously configured the auto-enrollment 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 to determine whether or not to issue a certificate to the client or server that has requested it. If Active Directory replication of 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 Active Directory replication of 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. This circumstance has the following effect:

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 by using any network access servers that are configured as RADIUS clients in NPS where the required authentication method is either EAP-TLS or PEAP-EAP-TLS. For example, if you have deployed RADIUS clients that are 802.1X wireless access points and you are using PEAP-EAP-TLS as your authentication method, client computers that do not have a client computer certificate cannot be authenticated and cannot access network resources.

If a domain member NPS server cannot enroll a server certificate, the NPS server cannot be successfully authenticated by client computers when they are attempting to connect to the network by using any network access servers that are configured as RADIUS clients in NPS where the required authentication method is EAP-TLS, PEAP-EAP-TLS, or PEAP-MS-CHAP v2, and where clients have the Validate server certificate setting enabled. These authentication methods provide mutual authentication, where both the access client and the NPS server authenticate each other, 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 that it receives where these authentication methods are required will 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 in such a manner that you diminish the possibility that slow replication might negatively impact your network access authentication infrastructure.

Extensible Authentication Protocol

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.

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. Default support for MD5-Challenge is not provided in Windows Server 2008, but can be enabled (see KB922574). EAP types

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 PEAP-MS-CHAP v2 by default. You can plug in other EAP modules to the server running Routing and Remote Access to provide other EAP types.

EAP-TLS

EAP-Transport Layer 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 stand-alone server or as a member of a workgroup does not support EAP-TLS.

Using RADIUS as a transport for EAP

Using RADIUS as a transport for EAP is the passing of EAP messages of any EAP type by a RADIUS client to a RADIUS server for authentication. For example, EAP messages are sent by a remote access client to a network access server that is configured as a RADIUS client. The network access server encapsulates and formats the EAP messages as RADIUS messages, and then sends them to 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 then sends it to its configured NPS server. The NPS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the network access server. The network access server then forwards the EAP message to the remote access client. In this configuration, the network access server is only a pass-through device. All processing of EAP messages occurs at the remote access client and the NPS server.

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

To enable EAP-based authentication

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

2. In NPS, on the Constraints tab of the appropriate network policy, enable EAP and configure the EAP type.

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

Protected Extensible Authentication Protocol

PEAP is part of the Extensible Authentication Protocol (EAP) protocols. Protected Extensible Authentication Protocol (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-Microsoft Challenge Handshake Protocol version 2 (MS-CHAP v2), that can operate through the TLS-encrypted channel provided by PEAP. PEAP is used as an authentication method for access clients connecting to your organization network through the following types of network access servers:

802.1X wireless access points

802.1X-capable 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 sending 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 an NPS server or other RADIUS server. Because the server also authenticates the client, mutual authentication occurs.

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

PEAP fast reconnect, which reduces the delay between an authentication request by a client and the response by the NPS server 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 compares MS-CHAP v2 to PEAP-MS-CHAP v2.

Function MS-CHAP v

2 PEAP-MS-CHAP

v2

Provides client authentication by using passwords Yes YesEnsures that the server has access to credentials Yes YesAuthenticates the server Yes YesPrevents wireless access point spoofing No YesPrevents an unauthorized server from negotiating the least secure authentication method No Yes

Uses TLS keys generated with a public key No YesProvides end-to-end encryption No YesPrevents dictionary or brute force attacks No YesPrevents replay attacks No YesAllows chaining of authentication methods No YesRequires 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.

Establish a TLS-encrypted channel

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

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

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

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

Establish 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 by 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 server or other RADIUS server is required to have a certificate. The NPS server certificate is used by the NPS server during the authentication process to prove its identity to PEAP clients.

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

The server certificate used by NPS can be issued by either 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.

Note

PEAP-MS-CHAP v2 authentication protocol provided in NPS supports password change during the authentication process. However, password change scenarios are supported only when NPS is able to communicate directly with a writable domain controller in your network for the password change transactions. Password change scenarios are not supported if NPS is configured to communicate with a Read-only domain controller (RODC) in your network.

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 personal identification number (PIN) or credentials, respectively.

The following table shows behavior of PEAP fast reconnect when using 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.

The following table shows behavior of PEAP fast reconnect when using 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 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.

Certificate Templates and Requirements

In this section

Server Certificate Requirements

Computer and User Certificate Requirements

Enrolling Certificates with Templates

When you use Extensible Authentication Protocol (EAP) with a strong EAP type, such as Transport Layer Security (TLS) with smart cards or certificates, both the client and the server use certificates to prove their identities to each other. This process is called mutual authentication. Certificates must meet specific 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 Application Policies extensions, also called Enhanced Key Usage (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 Application Policies 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 Application Policies extensions of the certificate or authentication will fail.

The Certificate Templates Microsoft Management Console (MMC) snap-in allows customization of the certificates that are issued by Active Directory Certificate Services (AD CS). Customization possibilities include both how certificates are issued and what the certificates contain, including their purposes. In the Certificate Templates snap-in, you can use a default template, such as the Computer template, to define the template that the certification authority (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 Network Policy Server (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 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 an organization deploys its own public key infrastructure (PKI), and then installs 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 then the domain member computers store the CA certificate in their local Trusted Root Certification Authorities certificate store. 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 by 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 their local 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 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. 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.

For PEAP-MS-CHAP v2, The CA 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 by using 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

Yes. You can configure AD CS to autoenroll server

Yes. In addition to using AD CS for server

The NPS server sends the server

store of the NPS server.

certificates to members of the RAS and IAS servers group in Active Directory Domain Services (AD DS).

certificates, you can purchase server certificates from other CAs that client computers already trust.

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.

Wireless clients

How certificates are used to authenticate wireless clients varies depending on the authentication method. 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 by 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. During PEAP-MS-CHAP v2 authentication, the NPS server supplies a certificate to provide proof of its identity to the connecting client. If the Validate server certificate option is configured on the Windows Vista® or Windows XP Professional client, the client uses the certificate to authenticate the NPS server. User authentication is then performed with password-based credentials rather than with a certificate. This use of password-based rather than certificate-based credentials eliminates some of the difficulty of deploying secure authentication for wireless client computers.

Server Certificate Requirements

All certificates that are used for network access authentication with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) and Protected Extensible Authentication Protocol (PEAP) must meet the requirements for X.509 certificates and work for connections that use Secure Sockets Layer/Transport Layer Security (SSL/TLS) as specified below. If you configure your server certificate according to this information, your server certificates will also meet the requirements for PEAP and EAP.

Note Use the Certificate Templates Microsoft Management Console (MMC) snap-in and a copy of the RAS and IAS Servers certificate template to configure server certificates for use with EAP and

PEAP.

While configuring a copy of the RAS and IAS Servers certificate template, ensure that the following is true:

The Subject name field contains a value. If you issue a certificate to your NPS server that has a blank subject name, the certificate is not available for selection when you're configuring authentication in NPS network policy and connection request policy.

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

The NPS server or virtual private network (VPN) server certificate is configured with the Server Authentication purpose in Application Policies extensions (also called Enhanced Key Usage (EKU) extensions). The object identifier for Server Authentication is 1.3.6.1.5.5.7.3.1.

The server certificate is configured with a required Rivest-Shamir-Adleman (RSA) algorithm value.

The Subject Alternative Name (SubjectAltName) extension, if used, must contain the Domain Name System (DNS) name of the server.

Computer and User Certificate Requirements

All certificates that are used for network access authentication with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) and Protected Extensible Authentication Protocol (PEAP) must meet the requirements for X.509 certificates and work for connections that use Secure Sockets Layer/Transport Layer Security (SSL/TLS) as specified below. If you configure your computer and user certificates according to this information, your certificates will also meet the requirements for PEAP and EAP.

Note Use the Certificate Templates MMC snap-in and copies of the User certificate template and the Workstation Authentication certificate template to configure user and computer certificates for use with EAP and PEAP.

While configuring copies of the User certificate template and the Workstation Authentication certificate template, ensure that the following is true:

The Subject name field contains a value. If you issue a certificate that has a blank subject name, the certificate cannot be used for authentication.

The certificate chains to a trusted root certification authority (CA) and does not fail any of the checks that are performed by CryptoAPI and that are specified in Network Policy Server (NPS) network policy. Because you are issuing certificates from your own enterprise root CA, computer and user certificates issued by the CA automatically chain to the CA. Domain member computers have the CA certificate in the Trusted Root Certification Authorities folder in both the Local Computer and Current User certificate stores, which means that they trust the CA.

The user or computer certificate is configured with the Client Authentication purpose in Application Policies extensions (also called Enhanced Key Usage (EKU) extensions). The object identifier for Client Authentication is 1.3.6.1.5.5.7.3.2. By default, the User and Workstation Authentication certificate templates contain this purpose in Application Policies extensions.

For user certificates, the Subject Alternative Name (SubjectAltName) extension, if used, contains the user principal name (UPN). By default, the User certificate template is configured with the UPN.

For computer certificates, the SubjectAltName extension, if used, contains the fully qualified domain name (FQDN) of the computer, which is also called the DNS name. By default, the Workstation Authentication certificate template is not configured with this value and must be reconfigured to meet this requirement.

Enrolling Certificates with Templates

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, whereas an administrator must enroll certificates for non-domain member computers by using the Active Directory Certificate Services (AD CS) Web enrollment tool or a floppy disk or compact disc.

Domain member certificate enrollment

If your virtual private network (VPN) server, Network Policy 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 Active Directory Domain Services (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 Microsoft Management Console (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 by using one of the following methods:

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

An administrator must save a computer or user certificate to a floppy disk or portable USB drive, and then 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 Layer Two Tunneling Protocol/Internet Protocol security (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, Enhanced Key Usage (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 Certificate Services or Active Directory Certificate Services, 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, Internet Authentication Service (IAS), or NPS server, domain member

Computer Server Authentication Autoenrollment

Request a certificate by using the Certificates snap-in

VPN server with site-to-site connection, domain member

Computer

Server Authentication and Client Authentication

Autoenrollment

Request a certificate by using the Certificates snap-in

Client running Windows Vista or Windows XP, domain member

Computer Client Authentication Autoenrollment

Request a certificate by using the Certificates snap-in

VPN, IAS, or NPS server, non-domain member

Computer Server Authentication

CA Web enrollment tool

Install from a floppy disk or portable USB drive

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 or portable USB drive

Client running Windows Vista or Windows XP, non-domain member

Computer Client Authentication

CA Web enrollment tool

Install from a floppy disk or portable USB drive

User, domain user User Client Authentication Autoenrollment

Use a smart card or the CA Web enrollment tool

If your enterprise 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 Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2

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

 Object and domain Certificate Certificate Preferred Alternate

membership template purpose certificate enrollment

method

certificate enrollment

method

VPN, IAS, or NPS server, domain member

RAS and IAS Server

Server Authentication Autoenrollment

Request a certificate by using the Certificates snap-in

Client running Windows Vista or Windows XP, domain member

Workstation Authentication

Client Authentication Autoenrollment

Request a certificate by using 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 or portable USB drive

Client running Windows Vista or Windows XP, non-domain member

Workstation Authentication

Client Authentication

CA Web enrollment tool

Install from a floppy disk or portable USB drive

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 the Certificate Templates snap-in, 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 the Active Directory Users and Computers snap-in, create a new global or universal group for NPS servers.

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

3. In the Certificate Templates snap-in, 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.

Mapping with Certificate-Based Authentication

Certificate-based authentication is more secure than password-based authentication. In addition, when you map certificates to user accounts instead of using password-based authentication methods, an authentication request is not forwarded to the partner organization Remote Authentication Dial-In User Service (RADIUS) server and user account database. For these reasons, certificate mapping enhances security and can significantly reduce logon time for users.

A certificate is mapped to a user account in one of two ways: a single certificate is mapped to a single user account (one-to-one mapping) or multiple certificates are mapped to one user account (many-to-one mapping).

One-to-One Mapping

For one-to-one mapping of certificates to visitor user accounts, you must perform the following tasks:

Create a user account for each visitor.

Because the user account itself is not mapped to the user account at the partner organization, the user account names do not have to exactly match the user account names in the partner organization user accounts database. Configuring the local account with the same user name, however, can make it easier to configure realm manipulation rules.

Map the certificate to a user account.

Perform cross-certification or authorize the partner organization certification authority (CA) as a qualified subordinate CA by using a computer running Windows Server 2008 and Active Directory Certificate Services (AD CS) or Windows Server 2003, Enterprise Edition, and Certificate Services.

Performing cross-certification or authorizing the partner organization CA as a qualified subordinate CA is recommended for domains with a Windows Server 2008 or Windows Server 2003 domain functional level and clients running Windows Vista or Windows XP. If your domains are Windows 2000 native, it is recommended that you use a certificate trust list (CTL) instead.

Configure your NPS server or NPS proxy server

Because authentication requests are not forwarded to external RADIUS servers when authentication is performed with mapped certificates, you are not required to use NPS as a proxy server.

Configure a connection request policy for visitor access by using the New Connection Request Policy Wizard.

Create a realm manipulation rule to map the partner organization realm name, which is contained in the user certificate, to the local user account of the user.

For example, if user@example.com is mapped to user@microsoft.com, the realm manipulation rule must replace “@example.com” with “@microsoft.com” by using regular expressions.

Configure a network policy for visitor access.

Ensure that network access servers (NASs) are configured as RADIUS clients to this NPS server.

When visitors log on to your network, they do so through NASs, such as wireless access points (APs). These APs must be configured as RADIUS clients to your NPS proxy server or NPS server.

Many-to-One Mapping

Many-to-one certificate mapping allows you to map many certificates to one user account. After you have trusted the enterprise root CA of a partner organization, you can map all certificates issued by the partner organization CA to one account that you create in your local domain. This solution provides ease of management for many users, and eliminates the need to create an individual user account for every visitor to your organization.

For many-to-one mapping of certificates, you must perform the following steps:

Perform cross-certification or authorize the partner organization CA as a qualified subordinate CA by using a computer running Windows Server 2008 and AD CS or Windows Server 2003, Enterprise Edition, and Certificate Services.

Performing cross-certification or authorizing the partner organization CA as a qualified subordinate CA is recommended for domains with a Windows Server 2008 or Windows Server 2003 domain functional level and clients running Windows Vista or Windows XP. If your domains are Windows 2000 native, it is recommended that you use a certificate trust list (CTL) instead.

Create one user account and map the partner organization certificates to the account.

Configure your NPS server or NPS proxy server

Because authentication requests are not forwarded to external RADIUS servers when

authentication is performed with mapped certificates, you are not required to use NPS as a proxy server.

Configure a connection request policy for visitor access by using the New Connection Request Policy Wizard.

Create a realm manipulation rule to map the partner organization realm name, which is contained in the user's certificate, to the user's local user account.

For example, if user@tailspintoys.com is mapped to user@microsoft.com, the realm manipulation rule must replace @tailspintoys.com with “@microsoft.com” by using pattern-matching syntax.

Ensure that NASs are configured as RADIUS clients to this NPS server.

Configure a network policy for visitor access.

When visitors log on to your network, they do so through NASs, such as wireless APs. These APs must be configured as RADIUS clients to your NPS proxy server or NPS server.

Note For strong security between your NPS proxy server and your partner organization RADIUS servers, you can use Internet Protocol security (IPsec).

Password-based Authentication Protocols

Password-based authentication methods 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.

In this section

Microsoft Challenge Handshake Authentication Protocol v2

Microsoft Challenge Handshake Authentication Protocol v1

Challenge Handshake Authentication Protocol

Shiva Password Authentication Protocol

Password Authentication Protocol

Microsoft Challenge Handshake Authentication Protocol v2

Version 2 of 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 issues of MS-CHAP version 1, as shown 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 password.

With 40-bit encryption, the cryptographic key is based on the user 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 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 (NAS) or the server running Network Policy Server (NPS) — 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:

o The user name.

o An arbitrary peer challenge string.

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

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

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

o An authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user 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

Following are additional things to consider before deploying MS-CHAP v2:

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

Note Password change scenarios are supported only when NPS is able to communicate directly with a writable domain controller in your network for the password change transactions. Password change scenarios are not supported if NPS is configured to communicate with a Read-only domain controller (RODC) in your network.

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.

Microsoft Challenge Handshake Authentication Protocol v1

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 (NAS) or the server running Network Policy Server (NPS) — 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 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. 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

Following are additional things to consider before deploying MS-CHAP:

By default in Windows Server 2008, 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, see NPS: LAN Manager Authentication.

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

Challenge Handshake Authentication Protocol

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 (NASs) and clients. A server running Routing and Remote Access supports CHAP so that access clients that require CHAP can be 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 password.

You can enable storage of a reversibly encrypted form of the user password per user account or enable storage for all accounts in a domain.

4. Force a reset of the user 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. After the password is changed, it is stored in a reversibly encrypted form.

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 they attempt to log on by using a remote access connection and CHAP. You cannot change passwords during the authentication process by using CHAP because 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

Following are additional things to consider before deploying CHAP:

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

Verify that your NAS supports CHAP 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 CHAP.

Shiva Password Authentication Protocol

Shiva Password Authentication Protocol (SPAP) is a reversible encryption mechanism employed by Shiva. A computer running Windows XP Professional, when connecting to a Shiva LAN Rover, uses SPAP, as does a Shiva client that connects to a server running Routing and Remote Access. This form of authentication is more secure than plaintext but less secure than Challenge Handshake Authentication Protocol (CHAP) or Microsoft Challenge Handshake Authentication Protocol (MS-CHAP).

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

1. Enable SPAP as an authentication protocol on the RADIUS client. SPAP is disabled by default.

2. Enable SPAP on the appropriate network policy. SPAP is disabled by default.

3. Enable SPAP on the access client.

Important When you enable SPAP as an authentication protocol, the same user password is always sent in the same reversibly-encrypted form. This makes SPAP authentication susceptible to replay attacks, where an attacker captures the packets of the authentication process and replays the responses to gain authenticated access to your network. The use of SPAP is discouraged, especially for virtual private network connections.Additional considerations

Following are additional things to consider before deploying SPAP:

If your password expires, SPAP cannot change passwords during the authentication process.

Make sure your network access server (NAS) supports SPAP 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 SPAP.

Password Authentication Protocol

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 (NAS) 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 Network Policy Server (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 virtual private network connections.Additional considerations

Following are additional things to consider before deploying PAP:

If you deploy a dial-up server, by disabling the support for PAP on the NAS 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 NAS 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. There are some situations where unauthenticated access is useful, although in most cases it is not recommended that you deploy unauthenticated access to 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 Network Policy Server (NPS).

If you permit unauthenticated access on your network, clients can connect without being authenticated if the authentication protocols configured on the access client do not match the authentication protocols that are configured on the network access server (NAS). In this case, the use of a common authentication protocol is not negotiated and the access client does not send a user name and password. This circumstance creates a severe security problem and unauthenticated access should not be allowed on most networks.

In the circumstances where you must use unauthenticated access, you can use one of the following solutions:

Dialed Number Identification Service (DNIS) authorization

Automatic Number Identification/Calling Line Identification (ANI/CLI) authentication

Guest authentication

The following sections provide detail on each of these access methods.

DNIS authorization

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 standard telephone companies. For example, you can allow all connections that connect through a specific 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

Following are additional things to consider before deploying DNIS:

If your phone service or hardware does not support DNIS, the passing of the number that was called, you can manually set the phone number of the port.

NPS does not support proxied DNIS access requests.

ANI/CLI authentication

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

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 do not take effect until the Routing and Remote Access service (RRAS) or the NPS service is restarted.

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

By default, AD DS includes a user account called Guest. By default, this account is disabled, but 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 the Active Directory Users and Computers snap-in.

4. Set the remote access permission on the Guest account to either Allow access or Control access through NPS Network Policy depending on your network access 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 network 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 do not take effect until the Routing and Remote Access service

or the Network Policy Server service are restarted.Caution

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

RADIUS Protocol

RADIUS is an industry standard protocol described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2865, “Remote Authentication Dial-in User Service (RADIUS),” and RFC 2866, “RADIUS Accounting.” RADIUS is used to provide authentication, authorization, and accounting services.

In this section

RADIUS Attributes

Vendor-Specific Attributes

During the network connection attempt by a client computer or other device, a RADIUS client, such as a virtual private network (VPN) server 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.

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

RADIUS messages are sent as User Datagram Protocol (UDP) messages. UDP port 1812 is used for RADIUS authentication messages and UDP port 1813 is used for RADIUS accounting messages. Some older network access servers (NASs) might use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages.

NPS can receive RADIUS messages on any configurable set of ports. By default, NPS monitors for, receives, and sends RADIUS traffic on the following UDP ports: 1812 and 1645 for RADIUS authentication messages and 1813 and 1646 for RADIUS accounting messages. Exactly one RADIUS message is encapsulated in the UDP payload.

RADIUS message format

The following section provides information that might be useful for the following:

Understanding a Network Monitor capture.

Understanding the different message formats for analyzing the accounting log.

Entering vendor-specific attribute (VSA) numbers.

General packet structure

The figure, “General Structure of RADIUS Packet,” provides a summary of the data structure of a RADIUS packet. The RADIUS client or server sends the fields from top to bottom, or from the Code field in vertical order to the Attributes field.

General Structure of RADIUS Packet

Code field

The Code field is 1 byte long and indicates the type of RADIUS message. A message with a Code field that is not valid is silently discarded. The defined values for the RADIUS Code field are listed in the following table.

 Codes (Decimal) Packets 1 Access-Request2 Access-Accept3 Access-Reject4 Accounting-Request5 Accounting-Response11 Access-Challenge12 Status-Server (experimental)13 Status-Client (experimental)255 Reserved

Identifier field

The Identifier field is 1 byte long and is used to match a request with its corresponding response.

Length field

The Length field is two octets long and indicates the entire length of the RADIUS message, including the Code, Identifier, Length, and Authenticator fields, and the RADIUS attributes. The Length field can vary from 20 to 4,096 bytes.

Authenticator field

The Authenticator field is 16 octets long and contains the information that the RADIUS client and server use to verify that the message came from a computer that is configured with a common shared secret.

Attributes section

The Attributes section of the RADIUS message contains one or more RADIUS attributes, which carry the specific authentication, authorization, information, and configuration details for RADIUS messages.

RADIUS message example

A Windows Server 2003 Point-to-Point Tunneling Protocol (PPTP) client attempts a remote access connection to a Windows Server 2003 VPN server. The VPN server is at the IP address 10.10.210.13, and the NPS server is at the IP address 10.10.210.12.

Access-Request message

The following Network Monitor capture display shows the Access-Request message sent by the VPN server to the NPS server.

+ IP: ID = 0x850; Proto = UDP; Len: 248+ UDP: Src Port: Unknown, (1327); Dst Port: Unknown (1812); Length = 228 (0xE4) RADIUS: Message Type: Access Request(1) RADIUS: Message Type = Access Request RADIUS: Identifier = 2 (0x2) RADIUS: Length = 220 (0xDC) RADIUS: Authenticator = 8A 6F DC 03 23 5F 4B 62 CA 40 92 38 DC 75 CB 74 RADIUS: Attribute Type: NAS IP Address(4) RADIUS: Attribute type = NAS IP Address RADIUS: Attribute length = 6 (0x6) RADIUS: NAS IP address = 10.10.210.13 RADIUS: Attribute Type: Service Type(6) RADIUS: Attribute type = Service Type RADIUS: Attribute length = 6 (0x6)

RADIUS: Service type = Framed RADIUS: Attribute Type: Framed Protocol(7) RADIUS: Attribute type = Framed Protocol RADIUS: Attribute length = 6 (0x6) RADIUS: Framed protocol = PPP RADIUS: Attribute Type: NAS Port(5) RADIUS: Attribute type = NAS Port RADIUS: Attribute length = 6 (0x6) RADIUS: NAS port = 32 (0x20) RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 12 (0xC) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = _ RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 18 (0x12) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = MSRASV5.00 RADIUS: Attribute Type: NAS Port Type(61) RADIUS: Attribute type = NAS Port Type RADIUS: Attribute length = 6 (0x6) RADIUS: NAS port type = Virtual RADIUS: Attribute Type: Tunnel Type(64) RADIUS: Attribute type = Tunnel Type RADIUS: Attribute length = 6 (0x6) RADIUS: Tag = 0 (0x0) RADIUS: Tunnel type = Point-to-Point Tunneling Protocol(PPTP) RADIUS: Attribute Type: Tunnel Media Type(65) RADIUS: Attribute type = Tunnel Media Type RADIUS: Attribute length = 6 (0x6) RADIUS: Tag = 0 (0x0) RADIUS: Tunnel media type = IP (IP version 4) RADIUS: Attribute Type: Calling Station ID(31) RADIUS: Attribute type = Calling Station ID RADIUS: Attribute length = 14 (0xE) RADIUS: Calling station ID = 10.10.14.226 RADIUS: Attribute Type: Tunnel Client Endpoint(66) RADIUS: Attribute type = Tunnel Client Endpoint RADIUS: Attribute length = 14 (0xE) RADIUS: Tunnel client endpoint = 10.10.14.226 RADIUS: Attribute Type: User Name(1) RADIUS: Attribute type = User Name RADIUS: Attribute length = 18 (0x12) RADIUS: User name = NTRESKIT\johndoe RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 24 (0x18) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = _+-_e_$+fN<N RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 58 (0x3A) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = _4

The RADIUS attributes sent by the VPN server include the framed protocol, the service type, the class, various tunnel attributes for the PPTP connection, and a series of vendor-specific attributes (VSA)s for Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP v1) authentication. For more information about Microsoft vendor-specific RADIUS attributes, see RFC 2548.

Access-Accept message

The following Network Monitor output shows the Access-Accept message sent by the NPS server to the VPN server.

+ IP: ID = 0xB18; Proto = UDP; Len: 248+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (1327); Length = 228 (0xE4) RADIUS: Message Type: Access Accept(2) RADIUS: Message Type = Access Accept RADIUS: Identifier = 2 (0x2) RADIUS: Length = 220 (0xDC) RADIUS: Authenticator = 52 E19 98 2E F8 E2 D3 B7 3B E1 24 5B 72 55 9E RADIUS: Attribute Type: Framed Protocol(7) RADIUS: Attribute type = Framed Protocol RADIUS: Attribute length = 6 (0x6) RADIUS: Framed protocol = PPP RADIUS: Attribute Type: Service Type(6) RADIUS: Attribute type = Service Type RADIUS: Attribute length = 6 (0x6) RADIUS: Service type = Framed RADIUS: Attribute Type: Class(25) RADIUS: Attribute type = Class RADIUS: Attribute length = 32 (0x20) RADIUS: Class = <$_@ RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 42 (0x2A) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = _$_DZ,Sc7__:+RW_t-qxF (-+�%p6 RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 42 (0x2A) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = _$_ RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 51 (0x33) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = _- RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 21 (0x15) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string =

The RADIUS attributes sent by the NPS server include the user name, the service type, the framed protocol, the service class, and a series of VSAs for MS-CHAP v1 authentication.

RADIUS Attributes

RADIUS attributes are containers that include a type, a length, and a value that hold information that is sent in RADIUS messages between RADIUS clients and RADIUS servers. One RADIUS message can include multiple RADIUS attributes, each of which holds a specific type of information for which the attribute was designed. For example, the Calling-Station-ID attribute can include a value that is the telephone number from which a dial-up networking session was initiated. A dial-in server that is configured as a RADIUS client can send the Calling-Station-ID attribute, along with other attributes and information, in an Access-Request RADIUS message to a RADIUS server.

The following figure shows the structure of each RADIUS attribute. RADIUS attributes use the common Type-Length-Value format that is used by other protocols.

Type field

The Type field is 1 byte long and indicates the specific type of RADIUS attribute.

Length field

The Length field is one byte long and indicates the length of the attribute, including the Type, Length, and Value fields.

Value field

The Value field is zero or more octets and contains information specific to the attribute. The format and length of the Value field is based on the type of RADIUS attribute. Note that value 26 is reserved for vendor-specific attributes (VSAs).

RADIUS standard attribute types

The RADIUS standard attributes are listed in the following table. For information about other RADIUS attributes and their use, see Internet Engineering Task Force (IETF) Request for Comments (RFCs) 2865 and 2866.

Type Value Attribute Name Type Value Attribute Name

1 User-Name 45 Acct-Authentic

2 User-Password 46 Acct-Session-Time3 CHAP-Password 47 Acct-Input-Packets4 NAS-IP-Address 48 Acct-Output-Messages5 NAS-Port 49 Acct-Terminate-Cause6 Service-Type 50 Acct-Multi-Session-Id7 Framed-Protocol 51 Acct-Link-Count8 Framed-IP-Address 52 Acct-Input-Gigawords9 Framed-IP-Netmask 53 Acct-Output-Gigawords10 Framed-Routing 55 Event-Timestamp11 Filter-ID 60 CHAP-Challenge12 Framed-MTU 61 NAS-Port-Type13 Framed-Compression 62 Port-Limit14 Login-IP-Host 63 Login-LAT-Port15 Login-Service 64 Tunnel-Type16 Login-TCP-Port 65 Tunnel-Medium-Type18 Reply-Message 66 Tunnel-Client-Endpt19 Callback-Number 67 Tunnel-Server-Endpt20 Callback-Id 68 Acct-Tunnel-Connection22 Framed-Route 69 Tunnel-Password23 Framed-IPX-Network 70 ARAP-Password24 State 71 ARAP-Features25 Class 72 ARAP-Zone-Access26 Vendor-Specific 73 ARAP-Security27 Session-Time-out 74 ARAP-Security-Data28 Idle-Time-out 75 Password-Retry29 Termination-Action 76 PROMPT30 Called-Station-Id 77 Connect-Info31 Calling-Station-Id 78 Configuration-Token32 NAS-Identifier 79 EAP-Message33 Proxy-State 80 Message-Authenticator34 Login-LAT-Service 81 Tunnel-Pvt-Group-ID35 Login-LAT-Node 82 Tunnel-Assignment-ID36 Login-LAT-Group 83 Tunnel-Preference

37 Framed-AppleTalk-Link 84 ARAP-Challenge-Response

38 Framed-AppleTalk-Network 85 Acct-Interim-Interval39 Framed-AppleTalk-Zone 86 Acct-Tunnel-Packets-Lost40 Acct-Status-Type 87 NAS-Port-Id41 Acct-Delay-Time 88 Framed-Pool42 Acct-Input-Octets 90 Tunnel-Client-Auth-ID43 Acct-Output-Octets 91 Tunnel-Server-Auth-ID

44 Acct-Session-Id    

The RADIUS standard attributes are described in Request for Comments (RFC) 2865 and RFC 2866.

Vendor-Specific Attributes

Network Policy Server (NPS) allows you to add vendor-specific attributes (VSAs) to individual network policies, providing you with the ability to deploy new Remote Authentication Dial-In User Service (RADIUS) client products that have proprietary functionality that are not defined in Request for Comments (RFC) 2865.

NPS includes VSAs from a number of vendors in its multivendor dictionary. However, over time vendors create new products that use VSAs, and the multivendor dictionary cannot be updated frequently in an efficient manner.

You can add attributes that are not in the NPS multivendor dictionary as Vendor-Specific attributes (RADIUS standard attribute type 26) on the Settings tab of a network policy. To use attribute type 26 to create a custom attribute, an administrator must know the VSA format and the exact information to enter. The VSA formats are documented in the following section. For information about what values to enter, see your network access server (NAS) documentation. The following figure shows the VSA structure.

Type value

The Type value is one byte long and is set to 26 (0x1A) to indicate a VSA.

Length value

The Length value is one byte long and is set to the number of bytes in the VSA.

Vendor-ID value

Vendor-ID is 4 octets long. The high-order octet is 0, and the low-order is 3 octets. Together, they make up the Structure and Identification of Management Information (SMI) Network Management Private Enterprise Code of the vendor.

String field

The String field in the VSA consists of one or more octets. To conform to the recommendation of RFC 2865, the String field should consist of the fields as shown in the following figure.

Vendor Type value

The Vendor Type value is used to indicate a specific VSA for the vendor.

Vendor Length value

The Vendor Length value is set to the number of bytes in the string.

Attribute-Specific field

The Attribute-Specific field contains the data for the specific vendor attribute.

Vendors who do not conform to RFC 2865 use attribute type 26 to identify a VSA, but do not use the Vendor Type, Vendor Length, and Attribute-Specific fields within the String field.

When adding a VSA for a particular NAS, you must know whether the attribute conforms to RFC 2865. For information about whether your NAS uses the VSA format documented in the figure earlier in this section, see your NAS documentation.

Note

While you configure a custom VSA, if the VSA format conforms to RFC 2865, use the Yes. It conforms option and then configure the attribute with the vendor-assigned attribute number, attribute format, and attribute value as defined in NAS documentation. If the VSA format does not conform to RFC 2865, choose No. It does not conform, and then configure the attribute with the hexadecimal attribute value, which includes the string of the VSA format (everything after Vendor-ID) as defined in NAS documentation.

For a complete list of Microsoft VSAs that you can use with NPS, see sections 2.2.1.1 through 2.2.1.28 of Microsoft Vendor-Specific Attributes (VSAs) in the Microsoft Developer Network Library at http://go.microsoft.com/fwlink/?LinkId=125707.

NPS Processes and Interactions

In this section

Incoming RADIUS Message Validation

Network Access Quarantine Control in NPS

NPS and Tunneling

NPS Certificate Revocation List (CRL) Checks

Processing a User Name Without a Domain Name

Connection Request Processing

NPS Authorization Process

RADIUS Authentication Process Overview

Incoming RADIUS Message Validation

The following sections provide information about how Network Policy Server (NPS) validates incoming Remote Authentication Dial-In User Service (RADIUS) messages under various circumstances.

NPS server validation of RADIUS messages

For RADIUS messages for which NPS is acting as RADIUS server, NPS performs the following validation checks:

1. NPS verifies that the RADIUS message was sent from a configured RADIUS client by checking the source IP address of the RADIUS message.

If the message is not from a configured RADIUS client, it is silently discarded and an event is logged in the system event log.

2. NPS checks to ensure that the message type is valid for the port on which it was received and then checks the structure of the RADIUS message. Items checked include valid values of the Code field, the size of the RADIUS message, and the size of the RADIUS attributes in the RADIUS message. NPS also checks whether or not the attributes themselves are the expected data type. If the attribute is not the expected data type, or if the RADIUS message is malformed, the message is discarded and an event is logged in the system event log.

3. The User-Name attribute is checked for the value of the Ping User-Name registry setting. If there is a match between the value of the User-Name attribute and the value of the Ping User-Name registry setting, NPS sends an Access-Reject for authentication

requests and an accounting response for accounting requests.

4. If the Message-Authenticator attribute is present, its value is validated by using the shared secret. A shared secret is a text string that serves as a password between a RADIUS server and a RADIUS client. If the Message-Authenticator attribute is required but missing, or verification of its value fails, the message is silently discarded, and an event is logged in the system event log.

NPS proxy validation of RADIUS request messages

For RADIUS request messages for which NPS is acting as RADIUS proxy, NPS performs the following validation checks:

1. NPS verifies that the RADIUS message was sent from a configured RADIUS client by checking the source IP address of the RADIUS message.

If the message is not from a configured RADIUS client, it is silently discarded, and an event is logged in the system event log.

2. NPS checks to ensure that the message type is valid for the port on which it was received and then checks the structure of the RADIUS message. Items checked include valid values of the Code field, the size of the RADIUS message, and the size of the RADIUS attributes in the RADIUS message.

If the RADIUS message is malformed, it is silently discarded and an event is logged in the system event log.

3. NPS checks for the presence of the Proxy-State attribute and whether the value of the Proxy-State attribute corresponds to an active proxy session in the proxy session table. If the RADIUS message does not contain a valid Proxy-State attribute, it is silently discarded and an event is logged in the system event log.

4. If the Message-Authenticator attribute is present, its value is validated using the shared secret. If the Message-Authenticator attribute is required but missing, or verification of its value fails, the message is silently discarded, and an event is logged in the system event log.

NPS proxy validation of RADIUS response messages

For RADIUS response messages for which NPS is acting as RADIUS proxy, NPS performs the following validation checks:

1. NPS verifies that the RADIUS message was sent from a configured remote RADIUS server by checking the source IP address of the RADIUS message.

If the message is not from a configured remote RADIUS server, it is silently discarded and an event is logged in the system event log.

2. NPS checks to ensure that the message type is valid for the port on which it was received and then checks the structure of the RADIUS message. Items checked include valid values of the Code field, the size of the RADIUS message, and the size of the RADIUS attributes in the RADIUS message.

If the RADIUS message is malformed, it is silently discarded, and an event is logged in the system event log.

3. NPS checks for the presence of the Proxy-State attribute and whether the value of the Proxy-State attribute corresponds to an active proxy session in the proxy session table. If the RADIUS message does not contain a valid Proxy-State attribute, it is silently discarded and an event is logged in the system event log.

4. NPS checks the IP source address and UDP source port of the message against the matching entry in the proxy session table to verify that the message was sent from the remote RADIUS server to which the initial request was sent.

5. The value of the Authenticator field is checked.

If the RADIUS message contains an Authenticator field that is not valid, it is silently discarded and an event is logged in the system event log. This is typically caused by mismatched shared secrets between the NPS server and the remote RADIUS server that sends the RADIUS message.

6. If the Message-Authenticator attribute is present, its value is validated using the shared secret. If the Message-Authenticator attribute is required but missing, or verification of its value fails, the message is silently discarded, and an event is logged in the system event log.

Network Access Quarantine Control in NPS

Network Access Quarantine Control (NAQC) in Network Policy Server (NPS) provides phased network access for remote virtual private network (VPN) 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 IP filters and session timers, are removed and standard network policy is applied to the connection.

NAQC provides protection when VPN 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 (RRAS) to process the Remote Authentication Dial-In User Service (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.

Understanding NAQC and NAP

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

NAQC is used only for VPN connections when you deploy VPN with RRAS in Windows Server 2008 or Windows Server 2003. In addition, to deploy NAQC, you must write and distribute a script that runs on VPN client computers and that verifies the client computer configuration.

NAP can be deployed with many different enforcement methods, including 802.1X, Internet Protocol security (IPsec), Terminal Services Gateway TS Gateway), RRAS, and Dynamic Host Configuration Protocol (DHCP) enforcement. NAP requires multiple deployment actions, however it does not require that you write scripts that run on client computers. For more information, see 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.

By configuring the MS-Quarantine-IPFilter attribute in network policy settings, you can use a quarantine IP Filter to restrict access to a specified set of servers (for example, servers on a virtual LAN). In addition, by configuring the MS-Quarantine-Session-Timeout attribute in network policy settings, you can use a quarantine session timer to restrict the amount of time that the VPN client can remain connected in quarantine mode.

To configure the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout attributes

1. In the NPS console, double-click Policies, click Network Policies, and then, in the details pane, double-click the network policy that you want to configure.

2. In policy Properties, click the Settings tab.

3. In RADIUS Attributes, click Vendor Specific, and then click Add. The Add Vendor Specific Attribute dialog box opens.

4. In Add Vendor Specific Attribute, in Vendor, select Microsoft, and then browse to the attribute that you want to configure.

Note In the NPS console, there is also a Microsoft vendor-specific attribute named MS-Quarantine-User-Class. This attribute is not for use with NAQC; it is used when you deploy the DHCP enforcement method of NAP. Do not use the MS-Quarantine-User-Class attribute when you deploy NAQC.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 profile created with Connection Manager Administration Kit (CMAK), an administrator-provided script or the Quarchk.cmd file, and two additional NAQC components: the notifier component and the listener component.

The notifier component is a program named Rqc.exe that you can include in a Connection Manager profile. The listener component can be configured in the Services Microsoft Management Console (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 Connection Manager 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 the 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 its 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 the 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.

For more information, see Deploying Network Access Quarantine Control in NPS Help in the Windows Server 2008 Technical Library at http://go.microsoft.com/fwlink/?LinkId=119931.

NPS and Tunneling

The entire process of packet encapsulation, transmission, and de-encapsulation is called tunneling. More specifically, tunneling is a method of using an internetwork infrastructure of one protocol to transfer a payload. Sometimes, the payload consists of the frames (or packets) of another protocol. Instead of being sent as the originating host produces it, the frame is encapsulated with an additional header. The additional header provides routing information so that the encapsulated payload can traverse an intermediate internetwork (also known as a transit internetwork). The encapsulated packets are then routed between tunnel endpoints over the transit internetwork. After the encapsulated payload packets reach their destination on the transit internetwork, the frame is de-encapsulated and forwarded to its final destination.

The logical path in the transit internetwork through which the encapsulated packets travel is called a tunnel.

With remote access virtual private network (VPN) connections, there are two types of tunneling: Voluntary and compulsory.

Voluntary tunneling

When a client computer is configured with the appropriate tunneling protocol, the user or client computer can issue a VPN request to create and configure a voluntary tunnel from the client computer to the VPN server. In this case, the user’s computer is a tunnel endpoint that acts as the tunnel client, and the VPN server is the tunnel server.

A simple example of voluntary tunneling occurs when a user with a dial-up connection to the Internet through an Internet service provider (ISP) connects to an organization VPN server that is also connected to the Internet. In this scenario, the user has two separate accounts, each account having its own set of credentials:

A set of credentials for an account with an ISP

A set of credentials for an account with the organization

To connect to the organization VPN server, the client computer uses a dial-up modem to attempt to connect to the ISP dial-up server. The user supplies his ISP account credentials, is authenticated by the ISP Remote Authentication Dial-IN User Service (RADIUS) server against the ISP user accounts database, and is authorized by the ISP RADIUS server to connect to the ISP and the Internet.

After the dial-up connection is established and the client computer is on the Internet, the user initiates a VPN connection to his organization VPN server. The VPN server is configured as a RADIUS client to an NPS server at the organization. The user supplies organization account credentials for the connection attempt, and the organization NPS server uses the credentials to authenticate and authorize the user against an Active Directory Domain Services (AD DS) user accounts database. After the user is authenticated and authorized, the VPN tunnel is established and the user can access organization resources.

In another example, NPS is used in an outsourced bulk-dial scenario for voluntary tunneling. In the outsourced bulk dial scenario, an ISP is providing both dial-up and non-dedicated broadband digital subscriber line (DSL) Internet access for all the employees of an organization. Rather than providing the ISP with a copy of its user accounts database, the organization and the ISP use a server running NPS as a RADIUS proxy so that users, when connecting to the ISP, can be authenticated and authorized using the organization RADIUS servers and AD DS user accounts database on the organization network. This provides strong security and prevents exposure of sensitive information contained in the user accounts database to the ISP and its employees.

When the organization employee attempts to connect to the organization VPN server, the following process occurs:

1. The client computer establishes the dial-up or DSL connection to the ISP network access server (NAS).

2. Based on the connection parameters, the NAS sends an Access-Request message to an NPS server that is configured as a RADIUS proxy.

3. The RADIUS proxy processes the Access-Request message and determines where to send it based on the realm portion of the User-Name attribute. The RADIUS proxy forwards the Access-Request message to the organization NPS server, which is accessible on the Internet through a firewall configured to allow traffic on the default RADIUS UDP ports of 1812 (authentication) and 1813 (accounting).

4. The organization NPS server authenticates and authorizes the connection attempt of the client computer and sends an Access-Accept message back to the RADIUS proxy.

5. The RADIUS proxy forwards the Access-Accept message to the ISP NAS, and then the ISP NAS connects the client computer to the Internet.

6. After it is on the Internet, the client computer initiates a VPN tunnel connection with the organization VPN tunnel server on the Internet.

7. Based on the tunnel connection parameters, the tunnel server sends an Access-Request message to the organization NPS server.

8. The organization NPS server authenticates and authorizes the connection attempt of the tunnel client and sends an Access-Accept message back to the tunnel server.

9. The tunnel server completes the tunnel creation, and then the tunnel client can send packets to the organization intranet through the tunnel across the Internet.

The following figure illustrates the establishment of a voluntary VPN tunnel by a dial-up client.

Voluntary tunneling is not different from other types of network access, and NPS can be used for authentication, authorization, and accounting when the tunnel server is configured as a RADIUS client to the NPS server.

Compulsory tunneling

Compulsory tunneling is the creation of a secure tunnel by another computer or network device on behalf of the client computer. Compulsory tunnels are configured and created automatically for the user without their knowledge or intervention. With a compulsory tunnel, the user’s computer is not a tunnel endpoint. Another device between the user’s computer and the tunnel server — the dial-up access server dialed by the client — is the tunnel endpoint, acting as the tunnel client.

A number of vendors that sell dial-up access servers have implemented the ability to create a tunnel on behalf of a dial-up client. The computer or network device providing the tunnel for the client computer is known as a Front End Processor (FEP) in PPTP, an Access Concentrator in Layer Two Tunneling Protocol (L2TP), or an IP Security Gateway in Internet Protocol security (IPsec).

In this section, “How NPS Works,” the acronym FEP describes this functionality, regardless of the tunneling protocol. To carry out its function, the FEP must have the appropriate tunneling protocol installed and must be capable of establishing the tunnel when the client computer attempts a connection.

An organization can contract with an ISP to deploy a nationwide set of FEPs. These FEPs can establish tunnels across the Internet to a tunnel server connected to the private network of the organization, thereby consolidating calls from geographically diverse locations into a single Internet connection at the organization network.

The following figure shows the outsourced bulk-dial scenario for compulsory tunneling.

In the outsourced bulk-dial scenario for compulsory tunneling, a dial-up client establishes a dial-up connection to an ISP that is providing tunneled access across the Internet for all the employees of an organization. Based on the dial-up connection parameters, the ISP NAS sends an Access-Request message to an NPS server. The ISP NPS server authorizes, but does not authenticate, the tunnel connection. The ISP NPS server sends an Access-Accept message to the ISP NAS with a series of VPN tunnel attributes. The ISP NAS then acts as a tunnel client and creates a VPN tunnel to the VPN server of the organization that faces the Internet.

Note Typically, NPS provides both authentication and authorization. However, it is common for the ISP NPS server to provide only authorization when the dial-in user is authenticated by the organization NPS server.

The ISP NAS then sends a PPP message to the dial-up client to restart the authentication process so that the dial-up user can be authenticated by the organization NPS server through the tunnel. The dial-up client sends the authentication information to the ISP NAS, which encapsulates the user account credentials and sends them through the tunnel to the organization tunnel server.

After the user account credentials are received by the tunnel server, the tunnel server sends an Access-Request message to the organization NPS server. The organization NPS server authenticates and authorizes the connection of the dial-up client to the tunnel server and sends an

Access-Accept message to the tunnel server. The tunnel server then completes the connection to the dial-up client.

All data that is sent by the dial-up client is automatically sent through the tunnel to the tunnel server by the ISP NAS.

This configuration is known as compulsory tunneling because the client is compelled to use the tunnel created by the FEP. After the initial connection is made, all network traffic to and from the client is automatically sent through the tunnel.

In addition, you can configure NPS to instruct an FEP to tunnel different remote access clients to different tunnel servers.

Unlike the separate tunnels created for each voluntary client, a compulsory tunnel between the FEP and organization VPN server can be shared by multiple dial-up clients. When a second client dials into the same access server (the FEP) to reach a destination for which a tunnel already exists, the data traffic for the new client is carried over the existing VPN tunnel.

The following RADIUS attributes are used to carry the tunneling information from the NPS server to the NAS.

Used in authorization only:

Tunnel-Assignment-ID

Tunnel-Client-Auth-ID

Tunnel-Password

Tunnel-Preference

Tunnel-Pvt-Group-ID

Tunnel-Server-Auth-ID

Used in authorization and accounting:

Tunnel-Client-Endpt

Tunnel-Medium-Type (X.25, ATM, Frame Relay, IP, and so on)

Tunnel-Server-Endpt

Tunnel-Type (such as PPTP and L2TP)

Used for accounting only:

Acct-Tunnel-Connection

The Windows Server 2003 or Windows 2000 Routing and Remote Access service cannot be used as a FEP for compulsory tunneling.

NPS Certificate Revocation List (CRL) Checks

By default, the NPS server checks for certificate revocation for all the certificates in the certificate chain sent by the client computer during the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) and Protected Extensible Authentication Protocol (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.

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 configurable schedule. 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, which 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 re-published, but the NPS server still allows the connection because the local CRL has not yet been updated.

The certificate revocation check for a certificate can fail because of the following issues.

The certificate has been revoked

The issuer of the certificate has explicitly revoked the certificate.

The certificate revocation list (CRL) for the certificate is not reachable or available

CAs maintain CRLs and publish them to specific 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 not valid and the certificate revocation check fails. New CRLs must be published before the expiration date of the last published CRL.

Processing a User Name Without a Domain Name

While processing connection requests, Network Policy Server (NPS) examines the user name portion of the Access-Request message to determine whether a domain name has been specified. If a domain name is specified and NPS is registered to access the user accounts database in the designated domain, NPS proceeds with processing the connection request.

Note To be registered in a domain, the NPS server must be a member of the RAS and IAS Servers security group for the Active Directory Domain Services (AD DS) domain.

Some network access servers delete or modify the domain name as specified by the user. As a 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 Remote Authentication Dial-In User Service (RADIUS) servers to change the user name into the correct format with the accurate domain name.

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.

Connection Request Processing

In this section

Load Balancing with NPS Proxy

Realm Names

Using Pattern-Matching Syntax in NPS

To determine whether a specific connection attempt request or an accounting message received from a Remote Authentication Dial-In User Service (RADIUS) client must be processed locally or forwarded to another RADIUS server, the NPS server uses connection request processing. Connection request processing is a combination of the following:

Connection request policies that determine, for any incoming RADIUS request message, whether the message is processed locally or forwarded to another RADIUS server.

Remote RADIUS server groups that contain one or more RADIUS servers to which RADIUS request messages are forwarded.

If connection request policy is configured to forward connection requests to members of a remote RADIUS server group, NPS is configured as a RADIUS proxy.

NPS Proxy Process Overview

When NPS is a RADIUS proxy between a RADIUS client and a RADIUS server, the messages that RADIUS sends for network access are forwarded as follows:

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

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

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

11. The RADIUS server sends an Accounting-Response to the NPS RADIUS proxy, where it is forwarded to the access server.

The following sections provide information about how an NPS RADIUS proxy changes each type of RADIUS message when it forwards the message.

Access-Request messages

Forwarding a RADIUS Access-Request message from a RADIUS client to a RADIUS server results in the following changes to the RADIUS Access-Request message:

Attribute manipulation rules are applied and the RADIUS attribute is modified according to the configured find and replace rules.

All RADIUS message fields for which the RADIUS shared secret is used are recalculated. The recalculation is performed by using the shared secret of the NPS RADIUS proxy and the remote RADIUS server to which the message is being forwarded. These RADIUS attributes include the Message Authenticator (also known as the Signature attribute), User-Name, Tunnel-Password, and MS-CHAP-MPPE-Keys. Additionally, the Authenticator field in the RADIUS header is recalculated.

If the Access-Request message contains a Proxy-State attribute indicating that the message has been forwarded by another RADIUS proxy, the contents of the Proxy-State attribute are saved in a proxy session table and the Proxy-State attribute is rewritten with a value determined by the NPS RADIUS proxy. The new value of the Proxy-State attribute is stored in a proxy session table.

When forwarding the Access-Request message, any additional RADIUS attributes that are configured in connection request policy Settings are stored in the proxy session table. These attributes are not actually added to the Access-Request message but are saved for the response to the Access-Request message.

Access-Accept messages

The Proxy-State attribute in the Access-Accept message is used to find the corresponding entry in the proxy session table. The entry in the proxy session table indicates the IP address of the client to which the message is forwarded, the Proxy-State attribute of the original Access-Request message, and any additional RADIUS attributes to add. If an entry is not found, the Access-Accept message is discarded.

Forwarding a RADIUS Access-Accept message from a RADIUS server to a RADIUS client results in the following changes to the RADIUS Access-Accept message:

All RADIUS message fields for which the RADIUS shared secret is used are recalculated by using the shared secret of the NPS RADIUS proxy and the RADIUS client to which the message is being forwarded. These RADIUS attributes include the Message Authenticator (also known as the Signature attribute), Tunnel-Password, and MS-CHAP-MPPE-Keys. Additionally, the Authenticator field in the RADIUS header is recalculated.

If the proxy session table entry contains an original Proxy-State attribute, the Proxy-State attribute in the Access-Accept message is replaced with the original Proxy-State attribute of the Access-Request message.

If the proxy session table entry contains any additional RADIUS attributes, these RADIUS attributes are added to the Access-Accept message. If any of these RADIUS attributes are already present, their values are overwritten with new values.

Access-Reject messages

The Proxy-State attribute in the Access-Reject message is used to find the corresponding entry in the proxy session table. The entry in the proxy session table indicates the IP address of the client to which the message is to be forwarded, the Proxy-State attribute of the original Access-Request message, and any additional RADIUS attributes to add. If an entry is not found, the Access-Reject message is discarded.

Forwarding a RADIUS Access-Reject message from a RADIUS server to a RADIUS client results in the following changes to the RADIUS Access-Reject message:

All RADIUS message fields for which the RADIUS shared secret is used are recalculated by using the shared secret of the NPS RADIUS proxy and the RADIUS client to which the message is being forwarded. These RADIUS attributes include the Message Authenticator (also known as the Signature attribute), Tunnel-Password, and MS-CHAP-MPPE-Keys. Additionally, the Authenticator field in the RADIUS header is recalculated.

If the proxy session table entry contains an original Proxy-State attribute, the Proxy-State attribute in the Access-Reject message is replaced with the Proxy-State attribute of the

original Access-Request message.

If the proxy session table entry contains any additional RADIUS attributes, these RADIUS attributes are added to the Access-Reject message. If any of these RADIUS attributes are already present, their values are overwritten with new values.

Accounting-Request messages

When an NPS RADIUS proxy forwards a RADIUS Accounting-Request message from a RADIUS client to a RADIUS server, it results in the following changes:

Attribute manipulation rules are applied and the RADIUS attribute is modified according to the configured find and replace rules.

All RADIUS message fields for which the RADIUS shared secret are used are recalculated by using the shared secret of the NPS RADIUS proxy and the remote RADIUS server to which the message is being forwarded. These RADIUS attributes include the Message Authenticator (also known as the Signature attribute) and User-Name. Additionally, the Authenticator field in the RADIUS header is recalculated.

If the Accounting-Request message contains a Proxy-State attribute indicating that the message has been forwarded by another RADIUS proxy, the contents of the Proxy-State attribute are saved in a proxy session table and the Proxy-State attribute is rewritten with a value determined by the NPS RADIUS proxy. The new value of the Proxy-State attribute is stored in a proxy session table.

When forwarding the Accounting-Request message, the set of additional RADIUS attributes as configured on the Advanced tab from the profile settings of the matching connection request policy is stored in the proxy session table. These attributes are not actually added to the Accounting-Request message but are saved for the response to the Accounting-Request message.

Accounting-Response messages

The Proxy-State attribute in the Accounting-Response message is used to find the corresponding entry in the proxy session table. The entry in the proxy session table indicates the IP address of the client to which the message is to be forwarded, the Proxy-State attribute of the original Accounting-Request message, and any additional RADIUS attributes to add. If an entry is not found, the Accounting-Response message is discarded.

When an NPS RADIUS proxy forwards a RADIUS Accounting-Response message from a RADIUS server to a RADIUS client, it results in the following changes to the RADIUS Accounting-Response message:

All RADIUS message fields for which the RADIUS shared secret is used are recalculated by using the shared secret of the NPS RADIUS proxy and the RADIUS client to which the message is being forwarded, such as the Message Authenticator (also known as the Signature attribute). Additionally, the Authenticator field in the RADIUS header is recalculated.

If the proxy session table entry contains an original Proxy-State attribute, the Proxy-State attribute in the Accounting-Response message is replaced with the original Proxy-State attribute of the Accounting-Request message.

If the proxy session table entry contains additional RADIUS attributes, these RADIUS attributes are added to the Accounting-Response message. If any of these RADIUS attributes are already present, their values are overwritten with new values.

When you configure connection request policies so that connection requests are forwarded to members of a remote RADIUS server group, you can use regular expressions and realm names for the configuration process. The following sections provide additional information.

Load Balancing with NPS Proxy

Remote Authentication Dial-In User Service (RADIUS) clients, which are network access servers such as virtual private network (VPN) servers and wireless access points, create connection requests and send them to RADIUS servers such as NPS. In some cases, an NPS server might receive too many connection requests at one time, resulting in degraded performance or an overload. When an NPS server is overloaded, it is a good idea to add more NPS servers to your network and to configure load balancing. When you evenly distribute incoming connection requests among multiple NPS servers to prevent the overloading of one or more NPS servers, it is called load balancing.

Load balancing is particularly useful for:

Organizations that use Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) or Protected Extensible Authentication Protocol (PEAP)-TLS for authentication. Because these authentication methods use certificates for server authentication and for either user or client computer authentication, the load on RADIUS proxies and servers is heavier than when password-based authentication methods are used.

Organizations that need to sustain continuous service availability.

Internet service providers (ISPs) that outsource VPN access for other organizations. The outsourced VPN services can generate a large volume of authentication traffic.

There are two methods you can use to balance the load of connection requests sent to your NPS servers:

Configure your network access servers to send connection requests to multiple RADIUS servers. For example, if you have 20 wireless access points and two RADIUS servers, configure each access point to send connection requests to both RADIUS servers. You can load balance and provide failover at each network access server by configuring the access server to send connection requests to multiple RADIUS servers in a specified order of priority. This method of load balancing is usually best for small organizations that do not deploy a large number of RADIUS clients.

Use NPS configured as a RADIUS proxy to load balance connection requests between multiple NPS servers or other RADIUS servers. For example, if you have 100 wireless access points, one NPS proxy, and three RADIUS servers, you can configure the access points to send all traffic to the NPS proxy. On the NPS proxy, configure load balancing so that the proxy evenly distributes the connection requests between the three RADIUS servers. This method of load balancing is best for medium and large organizations that have many RADIUS clients and servers.

In many cases, the best approach to load balancing is to configure RADIUS clients to send connection requests to two NPS proxy servers, and then configure the NPS proxies to load balance among RADIUS servers. This approach provides both failover and load balancing for NPS proxies and RADIUS servers.

RADIUS server priority and weight

During the NPS proxy configuration process, you can create remote RADIUS server groups and then add RADIUS servers to each group. To configure load balancing, you must have more than one RADIUS server per remote RADIUS server group. While adding group members, or after creating a RADIUS server as a group member, you can access the Add RADIUS server dialog box to configure the following items on the Load Balancing tab:

Priority. Priority specifies the order of importance of the RADIUS server to the NPS proxy server. Priority level must be assigned a value that is an integer, such as 1, 2, or 3. The lower the number, the higher priority the NPS proxy gives to the RADIUS server. For example, if the RADIUS server is assigned the highest priority of 1, the NPS proxy sends connection requests to the RADIUS server first; if servers with priority 1 are not available, NPS then sends connection requests to RADIUS servers with priority 2, and so on. You can assign the same priority to multiple RADIUS servers, and then use the Weight setting to load balance between them.

Weight. NPS uses this Weight setting to determine how many connection requests to send to each group member when the group members have the same priority level. Weight setting must be assigned a value between 1 and 100, and the value represents a percentage of 100 percent. For example, if the remote RADIUS server group contains

two members that both have a priority level of 1 and a weight rating of 50, the NPS proxy forwards 50 percent of the connection requests to each RADIUS server.

Advanced settings. These failover settings provide a way for NPS to determine whether the remote RADIUS server is unavailable. If NPS determines that a RADIUS server is unavailable, it can start sending connection requests to other group members. With these settings you can configure the number of seconds that the NPS proxy waits for a response from the RADIUS server before it considers the request dropped; the maximum number of dropped requests before the NPS proxy identifies the RADIUS server as unavailable; and the number of seconds that can elapse between requests before the NPS proxy identifies the RADIUS server as unavailable.

Configuring NPS proxy load balancing

Before configuring load balancing, create a deployment plan that includes how many remote RADIUS server groups you require, which servers are members of each particular group, and the Priority and Weight setting for each server.

Note The steps that follow assume that you have already deployed and configured RADIUS servers.

To configure NPS to act as a proxy server and forward connection requests from RADIUS clients to remote RADIUS servers, you must take the following actions:

1. Deploy your RADIUS clients (VPN servers, dial-up servers, Terminal Services Gateway servers, 802.1X authenticating switches, and 802.1X wireless access points) and configure them to send connection requests to your NPS proxy servers.

2. On the NPS proxy, configure the network access servers as RADIUS clients.

3. On the NPS proxy, create one or more remote RADIUS server groups. During this process, add RADIUS servers to the remote RADIUS server groups.

4. On the NPS proxy, for each RADIUS server that you add to a remote RADIUS server group, click the RADIUS server Load Balancing tab, and then configure Priority, Weight, and Advanced settings.

5. On the NPS proxy, configure connection request policies to forward authentication and accounting requests to remote RADIUS server groups. You must create one connection request policy per remote RADIUS server group.

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 Pattern-Matching Syntax 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 Remote Authentication Dial-In User Service (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 /zo*/ matches either "z" or

times. "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 of using pattern-matching syntax to specify 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.

o Find: @microsoft\.com

o Replace:

To replace user@example.microsoft.com with example.microsoft.com\user

o Find: (.*)@(.*)

o Replace: $2\$1

To replace domain\user with specific_domain\user

o Find: (.*)\\(.*)

o Replace: specific_domain\$2

To replace user with user@specific_domain

o Find: $

o 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 an NPS server 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 Domain Name System (DNS) or Active Directory Domain Services (AD DS) domain wcoast.microsoft.com. Using the supplied pattern, the NPS proxy can route messages based on domain network basic input/output system (NetBIOS) name or UPN suffix.

NetBIOS name UPN suffix Pattern WCOAST wcoast.microsoft.com ^wcoast\\|@wcoast\.microsoft\.com$

NPS Authorization Process

In this section

Authorization by User and Group

Dial-In Properties of Accounts

MAC Address Authorization

Network Policies and Authorization

Network Policy Server (NPS) grants or denies network access authorization on the basis of the following configurable items:

The dial-in properties of Security Accounts Manager (SAM) database or Active Directory Domain Services (AD DS) user and computer accounts

NPS network policies

Note For convenience in this document, in discussions of authorization, the dial-in properties of user and computer accounts are frequently referred to only as user accounts.

Network policies allow you to grant or deny network access for users and computers that are members of Windows groups; this authorization management method is called Authorization by Group.

Alternately, the Network Access Permission setting on the dial-in properties of each user and computer account in AD DS allows you to grant or deny network access for individual users and computers. This authorization management method is called Authorization by User.

Important By using the Network Access Permission setting Control access through NPS Network Policy, AD DS also allows you to designate that network access permission is granted based solely on network policy settings.

When NPS receives a connection request from a Remote Authentication Dial-In User Service (RADIUS) client, NPS accepts or rejects the connection request based on the following:

The first policy in the ordered list of network policies is checked. If there are no network policies configured in NPS, the connection request is rejected.

If all the conditions of the policy do not match the connection request, NPS moves on to and evaluates the next policy. If there are no more policies, NPS rejects the connection request.

If all the conditions of the policy match the connection request, NPS checks the value of the Ignore-User-Dialin-Properties attribute (which is configurable as a property on the

Overview tab) of the network policy.

If the Ignore-User-Dialin-Properties attribute is set to False, NPS checks the Network Access Permission setting in user account dial-in properties for the user attempting the connection:

o If Deny access is selected, NPS rejects the connection request.

o If Allow access is selected, NPS applies the user account properties and network policy constraints:

If the connection request does not match the settings of the user account properties and network policy constraints, NPS rejects the connection request.

If the connection request matches the settings of the user account properties and network policy constraints, NPS accepts the connection request.

If Network Access Permission is not set to Allow access or Deny access, the network access permission is set to Control access through NPS Network Policy. In that case, NPS evaluates the Access Permission setting (which is configurable as a property on the Overview tab) of the network policy:

o If Deny access is selected, NPS rejects the connection request.

o If Grant access is selected, NPS applies the user account properties and network policy constraints:

If the connection request does not match the settings of the user account properties and network policy constraints, NPS rejects the connection request.

If the connection request matches the settings of the user account properties and network policy constraints, NPS accepts the connection request.

If the Ignore-User-Dialin-Properties attribute is set to True, NPS checks the Access Permission setting of the network policy:

o If Deny access is selected, reject the connection request.

o If Grant access is selected, NPS applies the network policy constraints:

If the connection request does not match the settings of the network policy constraints, NPS rejects the connection request.

If the connection request matches the network policy constraints, NPS accepts the connection request.

Authorization by User and Group

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.

Important 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 Network Policy Server (NPS) to authorize a connection request occurs as follows:

1. 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:

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

o If the network access permission setting of the user account is set to deny access, NPS rejects the connection request.

2. If the connection request does not match all conditions of the first network policy, NPS processes the next network policy.

3. 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 Active Directory Domain Services (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:

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

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

o If the Access Permission setting is configured to deny access, NPS rejects the connection request.

2. If the connection request does not match all conditions of the first network policy, NPS processes the next network policy.

3. If the connection request does not match all conditions of any network policy, NPS rejects the connection request.

Dial-In Properties of Accounts

In Windows Server 2008, accounts in the Security Accounts Manager (SAM) database for a stand-alone server or in the user accounts database for an Active Directory Domain Services (AD DS)-based server contain a set of dial-in properties that are used when allowing or denying a connection attempt made by a user or computer. For a stand-alone server, the dial-in properties are available on the Dial-in tab of the user or computer object in the Local Users and Groups Microsoft Management Console (MMC) snap-in. For an AD DS-based server, the dial-in properties are available on the Dial-in tab of the user or computer account in the Active Directory Users and Computers snap-in.

The dial-in properties for an account are the following:

Network Access Permission

Use this property to set whether network access is explicitly allowed, denied, or determined by Network Policy Server (NPS) network policies. If access is explicitly allowed, network policy conditions or other account properties can override the setting.

Note By default, the Administrator and Guest accounts are set to Control access through NPS Network Policy or Control access through Remote Access Policy on a stand-alone Routing and Remote Access service (RRAS) server or in a Windows 2000 or later domain. In addition, new accounts created on a stand-alone RRAS server or in a Windows 2000 or later domain are set to Control access through NPS Network Policy or Control access through Remote Access Policy. Verify Caller ID

When Caller ID is enabled, the server verifies the caller's phone number..

Caller ID must be supported by the caller, the phone system between the caller and the remote access server, and the remote access server. On a computer running the Routing and Remote Access service, caller ID support consists of call answering equipment that provides caller ID information and the appropriate Windows driver to pass the information to the Routing and Remote Access service.

The connection attempt is denied if:

The caller's phone number does not match the configured phone number

The caller ID phone number is configured for a user, but you the passing of caller ID information from the caller to the Routing and Remote Access service is not supported.

Callback Options

If this property is enabled, the server calls the caller back during the connection establishment at a phone number set by the caller or a specific phone number set by the administrator.

Assign a Static IP Address

If this property is enabled, the administrator assigns a specific IP address to the user when the connection is made.

Apply Static Routes

If this property is enabled, the administrator defines a series of static IP routes that are added to the routing table of the remote access server when a connection is made. This setting is designed for accounts that Windows Server 2008, Windows Server 2003, or Windows 2000 routers use for demand-dial routing.

Note You can configure NPS network policy to ignore the dial-in properties of user and computer accounts by selecting or clearing the Ignore user account dial-in properties check box on the Overview tab of a network policy. MAC Address Authorization

Media access control (MAC) address authorization functions in the same way as automatic number identification (ANI) authorization, but it is used for wireless clients and clients connecting to your network by using an 802.1X authenticating switch.

MAC address authorization is based on the MAC address of the network adapter installed in the access client computer. Like ANI authorization, MAC address authorization uses the Calling-Station-ID attribute instead of user name and password or certificate-based credentials to identify the user during the connection attempt.

MAC address authorization is performed when the user does not type in any user name or password, and refuses to use any valid authentication method. In this case, Network Policy Server (NPS) receives the Calling-Station-ID attribute, and no user name and password. To support MAC address authorization, Active Directory Domain Services (AD DS) must have user accounts that contain MAC addresses as user names.

MAC address authorization is enabled when you do the following:

1. Enable MAC address authorization on access servers, such as wireless access points (APs).

2. Enable unauthenticated access on the appropriate NPS network policy for MAC address-based authentication, and enable Password Authentication Protocol (PAP).

3. In the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, create a user account for each MAC address for which you want to provide MAC address authorization. The name of the user account must match the MAC address of the network adapter installed in the computer from which the user is connecting. The format of the password assigned to the account is determined by the network access server vendor. Review the network access server documentation to determine the appropriate password.

4. Set the User Identity Attribute registry value to 31 on the NPS server. This registry value location is: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\

Policy

5. To always use the MAC address as the user identity, on the NPS server set the Override User-Name registry value to 1. This registry value location is: HKLM\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.Network Policies and Authorization

A network policy is an ordered set of rules that defines how connections are either authorized or rejected. For each rule, there are one or more conditions that must match the connection request for the policy to apply. In addition, each network policy contains constraints, settings, and an Access Permission property.

Note If Network Policy Server (NPS) authorizes a connection, restrictions specified in the dial-in properties of the user or computer account override the network policy constraints, where applicable.

Network policies validate several connection settings before authorizing the connection, including the following:

Access permission

Group membership

Type of connection

Time of day

Authentication methods

Access server identity

Access client phone number or media access control (MAC) address

Whether account dial-in properties are ignored

Whether unauthenticated access is allowed

After the connection is authorized, network policies can also be used to specify connection settings, including the following:

Idle time-out time

Maximum session time

Encryption strength

IP packet filters

IP address for PPP connections

Static routes

The following settings can also affect connection restrictions:

Group membership

Type of connection

Time of day

Authentication methods

Identity of the access server

Access client phone number or MAC address

It is important to remember that connection requests are accepted only if the properties of the connection request matches all of the conditions and constraints of at least one of the configured network policies (subject to the conditions of the dial-in properties of the account). If the connection request does not match at least one of the network policies, the connection attempt is rejected regardless of the dial-in properties of the user account.

Note Network policies are administered in the NPS snap-in or the Routing and Remote Access snap-in (when RRAS is configured for Windows authentication).Network policy configuration issues

Following are several issues that might impact your configuration of NPS, depending on your network and needs:

Some elements of a network policy correspond to RADIUS attributes that are used during RADIUS-based authentication. For network policies on an NPS server, verify that the network access servers (NASs) used are sending RADIUS attributes that correspond to the configured network policy conditions and settings. If a NAS does not send a RADIUS attribute that corresponds to a network policy condition or setting, then all RADIUS

authentication requests from that NAS are denied.

You can only use the Generate-Session-Time-out attribute if your user account database is a Security Accounts Manager (SAM) database or is the user account database for an Active Directory Domain Services (AD DS) domain. If the value of Generate-Session-Time-out is set to True, make sure the ForceLogoff value for a SAM database is set to 0. In the Local Security Settings console, ForceLogoff is changed to zero when Network security: Force logoff when logon hours expire is enabled.

If you are using Wired Equivalent Privacy (WEP) encryption, you can configure wireless connection policy so that wireless clients using WEP periodically reauthenticate. This ensures that the client WEP encryption keys are changed often enough to provide adequate security for the wireless connection. To configure reauthentication, set the session time-out in your network policy or connection request policy for wireless connections (by using the Session-Time-out attribute) to the required interval (for example, 10 minutes). Additionally, configure the value of the Termination-Action attribute to RADIUS-Request. If the Termination-Action attribute is not set to RADIUS-Request, wireless APs might end the connection during reauthentication. For more information, see your hardware documentation.

Important It is recommended that you use Wi-Fi Protected Access (WPA) or Wi-Fi Protected Access 2 (WPA2) rather than WEP for wireless deployments.

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.

RADIUS Authentication Process Overview

This section contains overview information about the Remote Authentication Dial-In User Service (RADIUS) authentication process, from when a RADIUS client sends an Access-Request message to a RADIUS server to when the RADIUS server sends the Access-Accept or Access-Reject message. In addition, detail about how Network Policy Server (NPS) processes Access-Request messages under different configurations is provided.

The RADIUS authentication process begins when a user attempts to access a network by using a computer or other device, such as a personal digital assistant (PDA), through a network access server (NAS) that is configured as a RADIUS client to a RADIUS server.

For example, when the user sends credentials by using Challenge Handshake Authentication Protocol (CHAP), the RADIUS client creates a RADIUS Access-Request message containing such attributes as the Port ID the user is accessing and the results of the CHAP authentication process (the user name, the challenge string, and the response of the access client).

The RADIUS Access-Request message is sent from the RADIUS client to the RADIUS server. If a response is not received within a specific length of time, the request is re-sent. The RADIUS

client can also be configured to forward requests to an alternate server or servers in the event that the primary server is unreachable. An alternate server can be used either after a specified number of non-responses from the primary server, or the RADIUS client can take turns sending the connection request to both the alternate and primary RADIUS server.

Note If you are using the Routing and Remote Access service (RRAS), you can add and prioritize multiple RADIUS servers using a scoring mechanism. If a primary RADIUS server does not respond within three seconds, RRAS automatically switches to the RADIUS server with the next highest score.

After the RADIUS server receives the request, it validates the sending RADIUS client. Validation occurs by verifying that the RADIUS Access-Request message is sent from a RADIUS client that is configured on the RADIUS server. If the Access-Request message is sent by a valid RADIUS client, and if the Message-Authenticator attribute is required for the RADIUS client, the value of the Message-Authenticator attribute is verified by using the RADIUS shared secret. If the Message-Authenticator attribute is either missing or contains an incorrect value, the RADIUS message is silently discarded — that is, the message is discarded without logging an event in the Event Log or making an entry in the NPS accounting log. If the RADIUS client is valid, the RADIUS server consults a database of users to find the user whose name matches the User-Name attribute in the connection request. The user account contains a list of requirements that must be met to allow access for the user. This list of requirements can include verification of the password, and it can also specify whether the user is allowed access.

If any condition of authentication or authorization is not met, the RADIUS server sends a RADIUS Access-Reject message in response, indicating that this user request is not valid.

If all conditions are met, the list of configuration settings for the user is placed into a RADIUS Access-Accept message that is sent back to the RADIUS client. These settings include a list of RADIUS attributes and all necessary values to deliver the desired service. For Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP) service types, this can include values such as encryption types, the Class attribute, Maximum Transmission Unit (MTU), and the desired compression and packet filter identifiers.

Access-Request Message Processing

The following sections detail how Network Policy Server (NPS) processes Access-Request messages when it is configured as a Remote Authentication Dial-In User Service (RADIUS) server, a RADIUS proxy, and a Network Access Protection (NAP) policy server.

In this section

NPS RADIUS Server Message Processing

NPS RADIUS Proxy Message Processing

NAP Health Policy Server Message Processing

NPS RADIUS Server Message Processing

This section provides information about how Network Policy Server (NPS) processes an incoming Access-Request message when NPS is configured as a Remote Authentication Dial-In User Service (RADIUS) server.

When you configure NPS as a RADIUS server, Access-Request messages are processed locally. In this process, NPS does the following:

1. Validates the RADIUS message. The incoming Access-Request message is validated for source IP address, the digital signature, valid attributes, and so on. If the RADIUS message is not valid, an event is logged in the system event log and the RADIUS Access-Request message is discarded. An Access-Reject message is not sent.

2. Checks for Auto Reject. Auto Reject, also called Ping User-Name for the corresponding registry entry, is used to send an immediate Access-Reject message when the User-Name attribute in the Access-Request message matches the registry entry value.

Some RADIUS clients (RADIUS proxy servers and network access servers) periodically send artificial authentication and accounting requests, called ping requests, to verify that the NPS server is present on the network. These ping requests include fictional user names and do not represent an actual connection request by a real user or computer. When NPS processes these requests, the event and accounting logs become filled with access reject records, making it difficult to keep track of records for valid connection attempts by real users. When you configure a registry entry for Ping User-Name, NPS matches the registry entry value against the value of the User-Name attribute in ping requests that other servers make. If the registry entry and the user name value match, NPS automatically rejects the request and does not create an event or accounting log entry.

3. Performs connection request policy evaluation. If no connection request policies are matched, an event is logged in the system event log and the RADIUS Access-Request message is discarded.

4. Applies realm stripping rules. NPS determines or defines the domain name and the user identity for the Access-Request message. If the User-Name attribute in the Access-Request message is not the Auto Reject name, then the user identity is determined. User identity is how NPS identifies the user for the purposes of authentication and authorization. Typically, the user identity is the string value of the User-Name RADIUS attribute. If the User-Name attribute is not present, the user identity is set to the Guest account or the account specified by the Default User Identity registry entry.

NPS can use any RADIUS attribute to identify the user. The RADIUS attribute that NPS uses to identify the user is configurable by setting the User Identity Attribute registry

entry.

5. Determines authentication server. NPS determines whether to authenticate locally or forward to a remote RADIUS server group (When NPS is configured as a RADIUS server, the message is authenticated locally and is not forwarded.)

6. Performs name cracking. Name cracking is the resolution of the user identity to a user account by using user principal names (UPNs), Lightweight Directory Access Protocol (LDAP), distinguished names (DNAs), canonical names, and so on. If a user principal name is encountered by NPS, NPS performs a query to the Active Directory Domain Services (AD DS) global catalog in an attempt to resolve the name. To speed up this process, a copy of the global catalog must be located on a domain controller within the same site as the NPS server.

When the user identity does not contain a domain name, NPS supplies a domain name. By default, the NPS-supplied domain name is the domain for which the NPS server is a member. You can specify the NPS-supplied domain by means of the DefaultDomain registry entry.

7. Checks for authentication plug-ins. Authentication plug-ins are optional components created by using the NPS software development kit (SDK); each plug-in can return Accept, Reject, or Continue. If an authentication plug-in returns an Accept, the user is authenticated and the account is validated. If the authentication plug-in returns a Reject, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings. If the authentication plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user still needs to be authenticated.

The authentication plug-in can also return RADIUS attributes to be included in the Access-Accept message.

8. Checks for remote access account lockout. The registry on the NPS server is read for remote access account lockout entry for the user account. If the account is locked out, NPS sends an Access-Reject message and logs an authentication event.

9. Checks for PAP, CHAP, MS-CHAP. If Password Authentication Protocol (PAP), CHAP, Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP v1), or MS-CHAP v2 are used to authenticate the remote access client, NPS consults an authentication sub-module based on the authentication protocol to perform the authentication. The user credentials (user name and password) are authenticated against the user name and password of the accounts database (either a domain or the local accounts database), and the group membership of the user account is determined. The exact method of authentication varies depending on the authentication protocol.

If the authentication of the credentials is not successful, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

If either Extensible Authentication Protocol (EAP) or unauthenticated access is being used, then the user authentication process is bypassed. EAP authentication takes place later in this process. For unauthenticated access, no user authentication is performed.

10. Validates user account. Based on the user or computer account determined by name cracking, the user account is validated to discover whether the account is locked out (which is not the same as remote access account lockout), whether the account is disabled, and whether the user account password has expired. If the user account is not valid, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

11. Performs network policy evaluation. Network policies configured on the NPS server are evaluated to find a policy that matches the parameters of the connection. If a matching policy is not found, an Access-Reject message is sent and an event is logged.

12. Checks user properties and network policy properties. If the Ignore-User-Dialin-Properties attribute is set to 0, the dial-in properties of the user account and the properties of the matching network policy are evaluated against the parameters of the connection attempt to ensure that the connection attempt is allowed. If the Ignore-User-Dialin-Properties attribute is set to 1, the properties from the matching network policy become the set of properties for the connection.

If the connection attempt is not allowed, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

13. Checks for EAP authentication. If EAP is the authentication protocol used for the connection attempt, EAP authentication takes place. The initial negotiation for EAP consists of selecting EAP as the authentication protocol and negotiating an EAP type with the access client. Based on the EAP type, the settings for the matching network policy are checked to ensure that the EAP type is allowed. If the EAP type is not allowed, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS accounting log, depending on the configured logging settings.

If the EAP type is allowed by network policy settings, EAP authentication for the EAP type occurs. NPS sends an EAP challenge to the NAS requesting it to start EAP negotiation. Communications between EAP modules on a RADIUS client and server are tunneled using the RADIUS protocol. After negotiation is complete, an EAP provider can return attributes that are sent back to the NAS in the Access-Accept message. If EAP authentication fails, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

14. Checks for authorization plug-ins. Authorization plug-ins are optional components created by using the NPS software development kit (SDK). Each plug-in can return either Reject or Continue. If the authorization plug-in returns a Reject, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings. If the authorization plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user is authorized.

The authorization plug-in can also return RADIUS attributes to be included in the Access-Accept message.

15. Sends an Access-Accept. If the dial-in properties of the user account, the properties of the matching network policy, and the conditions imposed by authorization plug-ins allow the connection attempt, an Access-Accept message is sent back to the NAS. Included with the Access-Accept message is the set of RADIUS attributes for the restrictions on the connection. In addition, an authentication success event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

After NPS sends the Access-Accept message, the NAS completes the connection process with the access client and sends an Accounting-Request message to the NPS server, where the message is logged in Internet Authentication Service (IAS) format, database-compatible format, or to a SQL Server database. The NPS server then sends an Accounting-Response to the NAS to verify that it has received and recorded accounting data for the connection.

Note The NAS also sends Accounting-Request messages when the connection is being established, when the NAS connection is closed, and when the access server is started and stopped.

RRAS authentication and authorization

The authentication and authorization process for the Routing and Remote Access service (RRAS), when configured for Windows authentication, requires steps 6 through 15 of this process. The authentication and authorization success and failure are the return values of functions called by the Routing and Remote Access service. Local event or authentication logging depends on the configured logging settings of the Routing and Remote Access service.

NPS RADIUS Proxy Message Processing

This section provides information about how Network Policy Server (NPS) processes an incoming Access-Request message when NPS is configured as a Remote Authentication Dial-In User Service (RADIUS) proxy.

When you configure NPS as a RADIUS proxy, Access-Request messages that the proxy receives from RADIUS clients are forwarded to a remote RADIUS server for processing.

When you map external user accounts to a local Windows user account, authentication is performed remotely and authorization is performed locally. In this process, NPS does the following tasks:

1. Validates the RADIUS message. The incoming Access-Request message is validated for source IP address, the digital signature, valid attributes, and so on. If the RADIUS message is not valid, an event is logged in the system event log and the RADIUS Access-Request message is discarded. An Access-Reject message is not sent.

2. Checks for Auto Reject. Auto Reject, also called Ping User-Name for the corresponding registry entry, is used to send an immediate Access-Reject message when the User-Name attribute in the Access-Request message matches the registry entry value.

Some RADIUS clients (RADIUS proxy servers and network access servers) periodically send artificial authentication and accounting requests, called ping requests, to verify that the NPS server is present on the network. These ping requests include fictional user names and do not represent an actual connection request by a real user or computer. When NPS processes these requests, the event and accounting logs become filled with access reject records, making it difficult to keep track of records for valid connection attempts by real users. When you configure a registry entry for Ping User-Name, NPS matches the registry entry value against the value of the User-Name attribute in ping requests that other servers make. If the registry entry and the user name value match, NPS automatically rejects the request and does not create an event or accounting log entry.

3. Performs connection request policy evaluation. Connection request policies configured on the NPS server are evaluated to find a policy that matches the parameters of the connection. If a policy is found that matches the connection request, the name of the remote RADIUS server group to which the Access-Request should be forwarded is injected into the message.

If a matching policy is not found, an Access-Reject message is sent and an event is logged.

4. Applies realm stripping rules. NPS determines or defines the domain name and the user identity for the Access-Request message. If the User-Name attribute in the Access-Request message is not the Auto Reject name, then the user identity is determined. User identity is the value that NPS uses to identify the user for the purposes of authentication and authorization. Typically, the user identity is the string value of the User-Name RADIUS attribute. If the User-Name attribute is not present, the user identity is set to the Guest account or the account specified by the Default User Identity registry entry.

NPS can use any RADIUS attribute to identify the user. The RADIUS attribute that NPS uses to identify the user is configurable by setting the User Identity Attribute registry entry.

5. Determines whether to authenticate locally or forward to a remote RADIUS server group. Based on the realm portion of the user name, the NPS proxy determines whether to forward the message or continue to process it locally.

6. Checks for authentication plug-ins. Authentication plug-ins are optional components created by using the NPS SDK; each plug-in can return Accept, Reject, or Continue. If an authentication plug-in returns an Accept, the user is authenticated and the account is validated. If the authentication plug-in returns a Reject, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings. If the authentication plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user still needs to be authenticated.

The authentication plug-in can also return RADIUS attributes to be included in the Access-Accept message.

7. Forwards the Access-Request message to a remote RADIUS server group. NPS creates a RADIUS message, which includes the attributes received from the RADIUS client, with the exception of the Proxy-State attribute. NPS forwards the message to the remote RADIUS server group specified in the request. When a valid reply is received from the remote server, attributes from the RADIUS message are merged with the attributes in the request. Attributes returned by the remote RADIUS server are not added if the same attribute has already been added by the connection request policy. In other words, local settings override remote settings.

8. Maps a remote user account to a local Windows account. If the NPS proxy server is configured to map an external user account to a local Windows account, and if the remote RADIUS server has performed authentication and returned an Access-Accept, mapping of the accounts is performed.

If mapping is not configured, the NPS proxy proceeds to step 12 in this process, Checks for authorization plug-ins.

9. Validates user account. Based on the user or computer account determined by means of name cracking, the user account is validated to check whether the account is locked out (which is not the same as remote access account lockout), whether the account is disabled, and whether the user account password has expired. If the user account is not valid, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

10. Performs network policy evaluation. Network policies configured on the NPS server are evaluated to find a policy that matches the parameters of the connection. If a matching policy is not found, an Access-Reject message is sent and an event is logged.

11. Checks user properties and network policy properties. If the Ignore-User-Dialin-Properties attribute is set to 0, the dial-in properties of the user account and the properties

of the matching network policy are evaluated against the parameters of the connection attempt to ensure that the connection attempt is allowed. If the Ignore-User-Dialin-Properties attribute is set to 1, the properties from the matching policy become the set of properties for the connection.

If the connection attempt is not allowed, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

12. Checks for authorization plug-ins. Authorization plug-ins are optional components created by using the NPS SDK. Each plug-in can return either Reject or Continue. If an authorization plug-in is installed and it returns a Reject, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings. If the authorization plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user is authorized.

An authorization plug-in can also return RADIUS attributes to be included in the Access-Accept message.

13. Sends an Access-Accept. If the dial-in properties of the user account, the properties of the matching network policy, and the conditions imposed by authorization plug-ins allow the connection attempt, an Access-Accept message is sent back to the NAS. Included with the Access-Accept message is the set of RADIUS attributes for the restrictions on the connection. In addition, an authentication success event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

NAP Health Policy Server Message Processing

This section provides information about how Network Policy Server (NPS) processes an incoming Access-Request message when NPS is configured as a Network Access Protection (NAP) policy server.

When you configure NPS as a NAP policy server, Access-Request messages are processed locally. In this process, NPS does the following:

1. Validates the RADIUS message. The incoming Access-Request message is validated for source IP address, the digital signature, valid attributes, and so on. If the RADIUS message is not valid, an event is logged in the system event log and the RADIUS Access-Request message is discarded. An Access-Reject message is not sent.

2. Checks for Auto Reject. Auto Reject, also called Ping User-Name for the corresponding registry entry, is used to send an immediate Access-Reject message when the User-Name attribute in the Access-Request message matches the registry entry value.

Some RADIUS clients (RADIUS proxy servers and network access servers) periodically

send artificial authentication and accounting requests, called ping requests, to verify that the NPS server is present on the network. These ping requests include fictional user names and do not represent an actual connection request by a real user or computer. When NPS processes these requests, the event and accounting logs become filled with access reject records, making it difficult to keep track of records for valid connection attempts by real users. When you configure a registry entry for Ping User-Name, NPS matches the registry entry value against the value of the User-Name attribute in ping requests that other servers make. If the registry entry and the user name value match, NPS automatically rejects the request and does not create an event or accounting log entry.

3. Performs connection request policy evaluation. If no connection request policies are matched, an event is logged in the system event log and the RADIUS Access-Request message is discarded.

4. Applies realm stripping rules. NPS determines or defines the domain name and the user identity for the Access-Request message. If the User-Name attribute in the Access-Request message is not the Auto Reject name, then the user identity is determined. User identity is how NPS identifies the user for the purposes of authentication and authorization. Typically, the user identity is the string value of the User-Name RADIUS attribute. If the User-Name attribute is not present, the user identity is set to the Guest account or the account specified by the Default User Identity registry entry.

NPS can use any RADIUS attribute to identify the user. The RADIUS attribute that NPS uses to identify the user is configurable by setting the User Identity Attribute registry entry.

5. Determines authentication server. NPS determines whether to authenticate locally or forward to a remote RADIUS server group (When NPS is configured as a NAP policy server, the message is authenticated locally and is not forwarded.)

6. Performs user name cracking. Name cracking is the resolution of the user identity to a user account by using user principal names (UPNs), Lightweight Directory Access Protocol (LDAP), distinguished names (DNAs), canonical names, and so on. If a user principal name is encountered by NPS, NPS performs a query to the Active Directory Domain Services (AD DS) global Ccatalog in an attempt to resolve the name. To speed up this process, a copy of the global catalog must be located on a domain controller within the same site as the NPS server.

When the user identity does not contain a domain name, NPS supplies a domain name. By default, the NPS-supplied domain name is the domain for which the NPS server is a member. You can specify the NPS-supplied domain by means of the DefaultDomain registry entry.

7. Evaluates EAP authentication configured in connection request policy. If connection request policy is configured with an Extensible Authentication Protocol (EAP) authentication method, this setting overrides all authentication settings in all network

policies.

8. Requests the client Statement of Health (SoH). NPS requests the SoH from the NAP-capable client.

9. Performs computer name cracking. NPS resolves the computer identity to a computer account in Active Directory Domain Services.

10. Checks for authentication plug-ins. Authentication plug-ins are optional components created by using the NPS software development kit (SDK); each plug-in can return Accept, Reject, or Continue. If an authentication plug-in returns an Accept, the user is authenticated and the account is validated. If the authentication plug-in returns a Reject, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings. If the authentication plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user still needs to be authenticated.

The authentication plug-in can also return RADIUS attributes to be included in the Access-Accept message.

11. Checks for remote access account lockout. The registry on the NPS server is read for remote access account lockout entry for the user account. If the account is locked out, NPS sends an Access-Reject message and logs an authentication event.

12. Checks for PAP, CHAP, MS-CHAP. If Password Authentication Protocol (PAP), CHAP, Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP v1), or MS-CHAP v2 are used to authenticate the remote access client, NPS consults an authentication sub-module based on the authentication protocol to perform the authentication. The user credentials (user name and password) are authenticated against the user name and password of the accounts database (either a domain or the local accounts database), and the group membership of the user account is determined. The exact method of authentication varies depending on the authentication protocol.

If the authentication of the credentials is not successful, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

If either EAP or unauthenticated access is being used, then the user authentication process is bypassed. EAP authentication takes place later in this process. For unauthenticated access, no user authentication is performed.

13. Validates the user or computer account. Based on the user or computer account determined by name cracking, the account is validated to discover whether it is locked out (which is not the same as remote access account lockout), whether the account is disabled, and whether the user account password has expired. If the account is not valid, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging

settings.

14. Performs network policy-to-connection request matching. NPS evaluates the ordered list of network policies until it finds one whose conditions exactly match the connection request. When starting this process, NPS first evaluates the policies that match the network connection type, if there are any. For example, if the connection request is received from a Terminal Services Gateway (TS Gateway) server, NPS first evaluates network policies whose network connection type is TS Gateway.

If no match is found, and if there are policies with a network connection type of Unspecified, NPS evaluates these policies next. If a matching policy is found, NPS adds the network policy settings to the connection request. If a matching policy is not found, an Access-Reject message is sent and an event is logged.

15. Performs health policy evaluation. If NPS matches the connection request to a network policy that is configured with a health policy, the health policy is evaluated against the SoH and the health of the NAP-capable client is determined. NPS enforces NAP based on the settings in the health policy.

16. Performs network policy constraints processing. Network policy constraints are processed by NPS. If all constraints do not match the connection request, NPS sends an Access-Reject message, and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings. In this circumstance, NPS does not evaluate additional policies.

17. Checks user account properties and network policy authorization properties. If the Ignore-User-Dialin-Properties attribute is set to 0, the dial-in properties of the user account and the properties of the matching network policy are evaluated against the parameters of the connection attempt to ensure that the connection attempt is allowed. If the Ignore-User-Dialin-Properties attribute is set to 1 (True), NPS does not evaluate the dial-in properties of the user account in AD DS and the properties from the matching network policy are the only properties used to authorize the connection.

If the connection attempt is not allowed, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

18. Checks for EAP authentication. If EAP is the authentication protocol used for the connection attempt, EAP authentication takes place. The initial negotiation for EAP consists of selecting EAP as the authentication protocol and negotiating an EAP type with the access client. Based on the EAP type, the settings for the matching connection request policy or network policy are checked to ensure that the EAP type is allowed. If the EAP type is not allowed, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS accounting log, depending on the configured logging settings.

If the EAP type is allowed by connection request policy or network policy settings, EAP

authentication for the EAP type occurs. NPS sends an EAP challenge to the NAS requesting it to start EAP negotiation. Communications between EAP modules on a RADIUS client and server are tunneled using the RADIUS protocol. After negotiation is complete, an EAP provider can return attributes that are sent back to the NAS in the Access-Accept message. If EAP authentication fails, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

19. Checks for authorization plug-ins. Authorization plug-ins are optional components created by using the NPS software development kit (SDK). Each plug-in can return either Reject or Continue. If the authorization plug-in returns a Reject, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings. If the authorization plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user is authorized.

The authorization plug-in can also return RADIUS attributes to be included in the Access-Accept message.

20. Sends an Access-Accept message. If the dial-in properties of the user account, the properties of the matching network policy, and the conditions imposed by authorization plug-ins allow the connection attempt, an Access-Accept message is sent back to the NAS. Included with the Access-Accept message are NPS settings and the set of RADIUS attributes for the restrictions on the connection. In addition, an authentication success event is logged in either the system event log or the NPS authentication log, depending on the configured logging settings.

After NPS sends the Access-Accept message, the NAS completes the connection process with the access client and sends an Accounting-Request message to the NPS server, where the message is logged in Internet Authentication Service (IAS) format, database-compatible format, or to a SQL Server database. The NPS server then sends an Accounting-Response to the NAS to verify that it has received and recorded accounting data for the connection.

Note The NAS also sends Accounting-Request messages when the connection is being established, when the access client connection is closed, and when the NAS is started and stopped.

NPS AccountingNetwork Policy Server (NPS) supports Remote Authentication Dial-In User Service (RADIUS) accounting, which you can use to track network usage for auditing and billing purposes. Accounting data can also be queried to assist with network access troubleshooting.

In this section

Interpret IAS Format Log Files

Interpret NPS Database Format Log Files

Interpret Windows System Health Validator Entries in Log Files

NPS SQL Server Logging

RADIUS accounting provides the following benefits:

Real-time data collection.

Accounting data can be collected from a central location.

Non-Microsoft products can be used to analyze RADIUS accounting data to provide charge-back, troubleshooting, performance, and exception reports.

When configured for accounting, NPS can log accounting data to a log file or to a SQL Server database.

When a RADIUS client is configured to use RADIUS accounting, at the start of service delivery it generates an Accounting-Start message describing the type of service being delivered and the user it is being delivered to. The message is then sent to the RADIUS Accounting server, which sends back an acknowledgment to the RADIUS client. At the end of service delivery, the client generates an Accounting-Stop message describing the type of service that was delivered and optional statistics, such as elapsed time, input and output octets, or input and output packets. It then sends that data to the RADIUS accounting server, which sends back an acknowledgment to the RADIUS client.

The Accounting-Request message (whether for the Start or Stop message) is submitted to the RADIUS accounting server through the network. If no response is returned within a length of time, the request is re-sent a number of times. The client can also forward requests to an alternate server or servers in the event that the primary server is unreachable. An alternate server can be used either after a number of tries to the primary server fail, or in a round-robin fashion. If the RADIUS accounting server cannot successfully record the accounting message, it does not send an Accounting-Response acknowledgment to the RADIUS client. For example, when the log file is full, NPS starts discarding accounting messages. This prompts the RADIUS client to switch to the backup RADIUS accounting server.

NPS log file

NPS can create a log file based on the data returned by the network access servers (NASs). This information is useful for keeping track of usage and correlating authentication information with accounting records (for example, to discover missing records or instances of over-billing).

NPS supports two formats of the log file: Internet Authentication Service (IAS) format and database-compatible format. Database format allows you to keep track of a predetermined set of attributes, and IAS format is more detailed and can contain information about all attributes. Use database-compatible format if you want to import the data directly into a database. IAS format can be used if you need to record more detailed information than the database log format allows.

Note The NPS log file contains all the NPS user-related events. NPS service and system-related events are recorded in the Event log files.

NPS events and Event Viewer

By using the event logs in Event Viewer, you can monitor NPS errors and other events that you configure NPS to record.

NPS records connection request failure events in the System event log by default. Connection request failure events consist of requests that are rejected or are 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 Microsoft Management Console (MMC) snap-in.

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 not valid.

The Message-Authenticator attribute (also known as a digital signature) sent by the client is not valid.

NPS was unable to locate the domain of the user name.

NPS was unable to connect to the domain of the user name.

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 secure channel (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 by using encryption.

Logging of client certificate validation failures is a secure channel event, and is not enabled on the NPS server by default. You can enable the logging of additional secure channel events.

Interpret IAS Format Log Files

In the Windows NT 4.0 version of Internet Authentication Service (IAS), log files are formatted by using a method in which attributes are logged as attribute-value pairs. This formatting is supported by Network Policy Server (NPS) in Windows Server 2008 and by IAS in Windows Server 2003 and Windows 2000 Server. The logs that use this format are referred to as IAS format log files. However, in Windows Server 2008, Windows Server 2003, and Windows 2000, this format supports the inclusion of additional information in the log file:

In addition to accounting messages (Accounting-On, Accounting-Off, Accounting-Start, Accounting-Stop, and Accounting-Interim), the NPS server also logs authentication messages (Access-Request, Access-Accept, and Access-Reject).

All string attributes that contain either unprintable characters or delimiters are printed in hexadecimal format (for example, 0x026).

If NPS receives an attribute (RADIUS-standard or vendor-specific) that is not defined in the NPS dictionary, it is logged as a string.

Note Unless you have migration, compatibility, or other issues that require you to use IAS format, use the database-compatible format or SQL Server logging. Although a database-compatible log file contains a smaller subset of attributes, it contains the attributes required to support most tracking and accounting activities.Entries recorded in IAS format log files

The following is an example entry (Access-Request) from an IAS format log file.

10.10.10.10,client,06/04/1999,14:42:19,NPS,CLIENTCOMP,6,2,7,1,5,9,61,5,64,1,65,1,31,1

The format of this record, which is the same for all records in your log file, includes a header, followed by the attribute-value pairs for all attributes that are contained in the packet.

The first six record fields make up the header and are described in the following table.

 Value shown in example Attribute ID Data

type Represents

10.10.10.10 NAS-IP-Address

IAS Header Text The IP address of the network access

server (NAS) that is sending the request.

client User-Name IAS Header Text The user name that is requesting access.

06/04/1999 Record-Date IAS Header Time The date that the log is written.

14:42:19 Record-Time IAS Header Time The time that the log is written.

NPS Service-Name

IAS Header Text The name of the service that is running on

the RADIUS server.

CLIENTCOMP Computer-Name

IAS Header Text The name of the RADIUS server.

Beyond the header, RADIUS attributes and values are listed in pairs in the following format:

<AttributeNumber1>,<ValueForAttributeNumber1>,<AttributeNumber2>,<ValueForAttributeNumber2>

For example, the two fields after the header contain a 6 and a 2, which can be interpreted as follows:

The number 6 represents the RADIUS ID for the Service-Type.

The number 2 represents the attribute value for the Service-Type. The RADIUS protocol specifies the following values for the Service-Type attribute:

o 1 = Login

o 2 = Framed

o 3 = Callback Login

o 4 = Callback Framed

o 5 = Outbound o 6 = Administrative

o 7 = NAS Prompt

o 8 = Authenticate Only

o 9 = Callback NAS Prompt

The value of this attribute is 2 (Framed).

This attribute-value pair is interpreted as Service-Type = Framed, which indicates to the NPS server to provide a framed protocol for the user – for example, Point-to-Point Protocol (PPP) or Serial Line Internet Protocol (SLIP).

The following table describes the RADIUS attributes, listed in numerical order, which can be found in an IAS format log file. Unlike database import log files, which use a fixed sequence of attributes, the sequence of the attributes in IAS format log files depends upon the sequence used by the network access server (NAS). For additional information about the sequence of these records, see the documentation for the NAS.

Additional information

This table does not cover vendor-specific attributes (VSAs). For more information about VSAs that are supported by your NAS, see your NAS documentation.

The entries in the ID column that begin with "IAS" are NPS/IAS-specific attributes. They are not found in the RADIUS protocol.

 Attribute ID Data type Represents

User-Name 1 Text The user identity, as specified by the user.NAS-IP-Address 4 Text The IP address of the NAS originating the request.

NAS-Port 5 Number The physical port number of the NAS originating the request.

Service-Type 6 Number The type of service that the user has requested.Framed-Protocol 7 Number The protocol to be used.

Framed-IP-Address 8 Text The framed IP address to be configured for the user.

Framed-IP-Netmask 9 Text The IP netmask to be configured for the user.

Framed-Routing 10 Number The routing method to be used by the user.

Filter-ID 11 Text The name of the filter list for the user requesting authentication.

Framed-MTU 12 Number The maximum transmission unit (MTU) to be configured for the user.

Framed-Compression 13 Number The compression protocol to be used.

Login-IP-Host 14 Number The IP address of the host to which the user should be connected.

Login-Service 15 Number The service that connects the user to the login host.Login-TCP-Port 16 Number The TCP port to which the user is to be connected.

Reply-Message 18 Text The message displayed to the user when an authentication request is accepted.

Callback-Number 19 Text The callback phone number.

Callback-ID 20 Text The name of a location to be called by the access server when performing callback.

Framed-Route 22 Text The routing information that is configured on the access client.Framed-IPX-Network 23 Number The Internetwork Packet Exchange (IPX) network number to

be configured on the NAS for the user.Class 25 Text The attribute sent to the client in an Access-Accept packet,

which is useful for correlating Accounting-Request packets with authentication sessions. The format is:

Type contains the value 25 (1 octet).

Length contains a value of 20 or greater (1 octet).

Checksum contains an Adler-32 checksum that is computed over the remainder of the Class attribute (4 octets).

Vendor-ID contains the ID of the NAS vendor (4 octets). The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the vendor in network byte order, as

defined in "Private Enterprise Numbers" at http://go.microsoft.com/fwlink/?LinkId=131594.

Version contains the value of 1 (2 octets).

Server-Address contains the IP address of the RADIUS server that issued the Access-Challenge message. For multihomed servers, this is the address of the network interface that received the original Access-Request message (2 octets).

Service-Reboot-Time specifies the time at which the first serial number was returned (8 octets).

Unique-Serial-Number contains a unique number to distinguish an individual connection attempt (8 octets).

String contains information that is used to classify accounting records for additional analysis (0 or more octets). In NPS, the Class attribute is copied into the String field.

The Class attribute is used to match the accounting and authentication records if it is sent by the NAS in the Accounting-Request message. The combination of Serial-Number, Service-Reboot-Time, and Server-Address must be a unique identification for each authentication that the RADIUS server performs.

Vendor-Specific 26 Text The attribute that is used to support proprietary NAS features.Session-Timeout 27 Number The length of time (in seconds) before a session is terminated.

Idle-Timeout 28 Number The length of idle time (in seconds) before a session is terminated.

Termination-Action 29 Number The action that the NAS is to take when service is completed.

Called-Station-ID 30 Text The phone number that is dialed by the user.

Calling-Station-ID 31 Text The phone number from which the call originated.

NAS-Identifier 32 Text The string that identifies the NAS originating the request.Login-LAT-Service 34 Text The host with which the user is to be connected by Local Area

Transport (LAT).Login-LAT-Node 35 Text The node with which the user is to be connected by LAT.

Login-LAT-Group 36 Text The LAT group codes for which the user is authorized.

Framed-AppleTalk-Link 37 Number The AppleTalk network number for the serial link to the user

(this is used only when the user is a router).Framed-AppleTalk-Network

38 Number The AppleTalk network number that the NAS must query for existence in order to allocate the user AppleTalk node.

Framed-AppleTalk-Zone 39 Text The AppleTalk default zone for the user.

Acct-Status-Type 40 Number The number that specifies whether an accounting packet starts or

stops a bridging, routing, or Terminal Services session.Acct-Delay-Time 41 Number The length of time (in seconds) for which the NAS has been

sending the same accounting packet.Acct-Input-Octets 42 Number The number of octets received by NPS during the session.

Acct-Output-Octets 43 Number The number of octets sent by NPS during the session.

Acct-Session-ID 44 Text The unique numeric string that identifies the server session.

Acct-Authentic 45 Number The number that specifies which server has authenticated an incoming call.

Acct-Session-Time 46 Number The length of time (in seconds) for which the session has been

active.Acct-Input-Packets 47 Number The number of packets received by NPS during the session.

Acct-Output-Packets 48 Number The number of packets sent by NPS during the session.

Acct-Terminate-Cause 49 Number The reason that a connection was terminated by NPS.

Acct-Multi-SSN-ID 50 Text The unique numeric string that identifies the multilink session.

Acct-Link-Count 51 Number The number of links in a multilink session.

Event-Timestamp 55 Time The date and time that this event occurred on the NAS.

NAS-Port-Type 61 Number The type of physical port that is used by the NAS originating the request.

Port-Limit 62 Number The maximum number of ports that the NAS provides to the user.

Login-LAT-Port 63 Number The port with which the user is connected by LAT.Tunnel-Type 64 Number The tunneling protocols to be used.

Tunnel-Medium-Type 65 Number

The transport medium to use when creating a tunnel for protocols. For example, L2TP packets can be sent over multiple link layers.

Tunnel-Client-Endpt 66 Text The IP address of the tunnel client.

Tunnel-Server-Endpt 67 Text The IP address of the tunnel server.

Acct-Tunnel-Connection 68 Text An identifier assigned to the tunnel.

Password-Retry 75 Number The number of times a user can try to be authenticated before the NAS terminates the connection.

Prompt 76 NumberA number that indicates to the NAS whether or not it should (Prompt=1) or should not (Prompt=0) echo the user response as it is typed.

Connect-Info 77 TextInformation that is used by the NAS to specify the type of connection made. Typical information includes connection speed and data encoding protocols.

Configuration-Token 78 Text The type of user profile to be used (sent from a RADIUS proxy

server to a RADIUS client) in an Access-Accept packet.Tunnel-Pvt-Group-ID 81 Text The group ID for a specific tunneled session.

Tunnel-Assignment-ID 82 Text The tunnel to which a session is to be assigned.

Tunnel-Preference 83 Number

A number that indicates the preference of the tunnel type, as indicated by the Tunnel-Type attribute when multiple tunnel types are supported by the NAS.

Acct-Interim-Interval 85 Number The length of interval (in seconds) between each interim update

sent by the NAS.

Ascend107 to 255

Text The vendor-specific attributes for Ascend. For more information, see the Ascend documentation.

Client-IP-Address

IAS 4108 Text The IP address of the RADIUS client.

NAS-Manufacturer

IAS 4116 Number The manufacturer of the NAS.

MS-CHAP-Error

IAS 4121 Number The error data that describes a Microsoft Challenge Handshake

Authentication Protocol (MS-CHAP) transaction.Authentication-Type

IAS 4127 Number The authentication scheme that is used to verify the user.

Client-Friendly-Name

IAS 4128 Text The friendly name for the RADIUS client.

SAM-Account-Name

IAS 4129 Text The user account name in the Security Accounts Manager

(SAM) database.Fully-Qualified-User-Name

IAS 4130 Text The user name in canonical format.

EAP-Friendly-Name

IAS 4132 Text The friendly name that is used with Extensible Authentication

Protocol (EAP).

Packet-Type IAS 4136 Number

The type of packet, which can be:

1 = Accept-Request

2 = Access-Accept

3 = Access-Reject

4 = Accounting-Request

Reason-Code IAS 4142

Number The reason for rejecting a connection request:

00 = Success

01 = Internal error

02 = Access denied

03 = Malformed request

04 = Global catalog unavailable

05 = Domain unavailable

06 = Server unavailable

07 = No such domain

08 = No such user

16 = Authentication failure

17 = Password change failure

18 = Unsupported authentication type

19 = No reversibly encrypted password is stored for the user account

32 = Local users only

33 = Password must be changed

34 = Account disabled

35 = Account expired

36 = Account locked out

37 = Logon hours are not valid

38 = Account restriction

48 = Did not match network policy

49 = Did not match connection request policy

64 = Dial-in locked out

65 = Dial-in disabled

66 = Authentication type is not valid

67 = Calling station is not valid

68 = Dial-in hours are not valid

69 = Called station is not valid

70 = Port type is not valid

71 = Restriction is not valid

80 = No record

96 = Session timed out

97 = Unexpected request

NP-Policy-Name

IAS 4149 Text The friendly name of a network policy.

Attributes that are not recorded in IAS format log files

Although most attributes sent by access servers are logged in IAS format log files, some attributes are not logged because they contain sensitive information. For example, user passwords are not logged for security reasons. The following table lists some of the attributes that are not logged.

 Attribute name ID/Description User-Password 2CHAP-Password 3

State 24Proxy-State 33CHAP-Challenge 60Tunnel-Password 69EAP-Message 79Signature 80MS-CHAP-Challenge Microsoft vendor-specific attributeMS-CHAP-Response Microsoft vendor-specific attributeMS-CHAP-CPW-1 Microsoft vendor-specific attributeMS-CHAP-CPW-2 Microsoft vendor-specific attributeMS-CHAP-LM-Enc-PW Microsoft vendor-specific attributeMS-CHAP-NT-Enc-PW Microsoft vendor-specific attributeMS-CHAP-MPPE-Keys Microsoft vendor-specific attributeMS-MPPE-Send-Key Microsoft vendor-specific attributeMS-MPPE-Recv-Key Microsoft vendor-specific attributeMS-Filter Microsoft vendor-specific attributeMS-CHAP2-Response Microsoft vendor-specific attributeMS-CHAP2-Success Microsoft vendor-specific attributeMS-CHAP2-CPW Microsoft vendor-specific attribute

Interpret NPS Database Format Log Files

Unlike IAS-formatted log files, database-compatible log files present the data in a standard sequence and use a structure that is identical, regardless of the format used by the network access server (NAS) that sends the data. This consistent sequence and structure helps simplify accounting and authentication records. Data can be easily exported to a database.

Note Although NPS supports both IAS-formatted and database-compatible log files, use the database-compatible log format in most instances because it supports tools compliant with Open Database Connectivity (ODBC).Entries recorded in database-compatible log files

The following are example entries (Access-Request and Access-Accept) from a database-compatible log file.

Note In the examples below, "IAS" refers to Internet Authentication Service. In Windows Server 2008. NPS replaces IAS. In NPS accounting data, the term IAS refers to the Network Policy Server service.

This is the first example:

"CLIENTCOMP","IAS",03/07/2008,13:04:33,1,"client",,,,,,,,,9,"10.10.10.10","npsclient",,,,,,,1,,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

This is the second example:

"CLIENTCOMP","IAS",03/07/2008,13:04:33,2,,"npsclientdc/Users/client",,,,,,,,9,"10.10.10.10","npsclient",,,,,,2,1,"Allow access if dial-in permission is enabled",0,"311 1 10.10.10.11 03/07/2008 20:04:30 1",,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

The following table shows the attributes that can be contained in a record in the database-compatible log file, the sequence in which they are recorded, and how the preceding examples are interpreted.

Additional information

A blank field in the first column of the table indicates that the network access server did not include a value with the attribute in the packets for the preceding example entries.

The Data type column identifies the data type (text, number, or time) for each attribute. When you create a database into which log files are imported, you must define each field for the data type of the attribute value that will be imported into it. In database-compatible log files, text values (such as strings, octet strings, and IP addresses) are always surrounded by double quotes. If the double quotes appear within the string, then they are replaced with a double set of double quotes.

This table shows the values for the example entries of an IAS-internal attribute.

 Value shown in example Attribute Data

type Description

"CLIENTCOMP"

ComputerName Text The name of the server where the packet was

received (this is an IAS-internal attribute).

"IAS" ServiceName TextThe name of the service that generated the record—IAS or the Routing and Remote Access service (this is an IAS-internal attribute).

03/07/2008 Record-Date Time The date at the NPS or Routing and Remote Access server (this is an IAS-internal attribute).

13:04:33 Record-Time Time The time at the NPS or Routing and Remote Access server (this is an IAS-internal attribute).

1 Packet-Type Number The type of packet, which can be:

1 = Access-Request

2 = Access-Accept

3 = Access-Reject

4 = Accounting-Request

This is an IAS-internal attribute."client" User-Name Text The user identity, as specified by the user.

 

Fully-Qualified-Distinguished-Name

Text The user name in canonical format (this is an IAS-internal attribute).

  Called-Station-ID Text The phone number dialed by the user.

  Calling-Station-ID Text The phone number from which the call originated.

  Callback-Number Text The callback phone number.

  Framed-IP-Address Text The framed address to be configured for the user.

  NAS-Identifier Text The text that identifies the network access server originating the request.

  NAS-IP-Address Text The IP address of the network access server

originating the request.

  NAS-Port Number The physical port number of the network access server originating the request.

9 Client-Vendor Number The manufacturer of the network access server (this is an IAS-internal attribute).

"10.10.10.10" Client-IP-Address Text The IP address of the RADIUS client (this is an IAS-

internal attribute).

"npsclient" Client-Friendly-Name Text The friendly name for the RADIUS client (this is an

IAS-internal attribute).

  Event-Timestamp Time The date and time that this event occurred on the

network access server.

  Port-Limit Number The maximum number of ports that the network access server provides to the user.

  NAS-Port-Type Number The type of physical port that is used by the network

access server originating the request.

  Connect-Info Text

Information that is used by the network access server to specify the type of connection made. Typical information includes connection speed and data encoding protocols.

  Framed-Protocol Number The protocol to be used.

  Service-Type Number The type of service that the user has requested.

1 Authentication-Type Number

The authentication scheme, which is used to verify the user and can be:

1 = PAP

2 = CHAP

3 = MS-CHAP

4 = MS-CHAP v2

5 = EAP

7 = None

8 = Custom

This is an IAS-internal attribute.

  Policy-Name Text

The friendly name of the network policy that either granted or denied access. This attribute is logged in Access-Accept and Access-Reject messages. If a user is rejected because none of the network policies matched, then this attribute is blank.

0 Reason-Code Number The reason for rejecting a user, which can be:

0 = IAS_SUCCESS

1 = IAS_INTERNAL_ERROR

2 = IAS_ACCESS_DENIED

3 = IAS_MALFORMED_REQUEST

4 = IAS_GLOBAL_CATALOG_UNAVAILABLE

5 = IAS_DOMAIN_UNAVAILABLE

6 = IAS_SERVER_UNAVAILABLE

7 = IAS_NO_SUCH_DOMAIN

8 = IAS_NO_SUCH_USER

16 = IAS_AUTH_FAILURE

17 = IAS_CHANGE_PASSWORD_FAILURE

18 = IAS_UNSUPPORTED_AUTH_TYPE

32 = IAS_LOCAL_USERS_ONLY

33 = IAS_PASSWORD_MUST_CHANGE

34 = IAS_ACCOUNT_DISABLED

35 = IAS_ACCOUNT_EXPIRED

36 = IAS_ACCOUNT_LOCKED_OUT

37 = IAS_INVALID_LOGON_HOURS

38 = IAS_ACCOUNT_RESTRICTION

48 = IAS_NO_POLICY_MATCH

64 = IAS_DIALIN_LOCKED_OUT

65 = IAS_DIALIN_DISABLED

66 = IAS_INVALID_AUTH_TYPE

67 = IAS_INVALID_CALLING_STATION

68 = IAS_INVALID_DIALIN_HOURS

69 = IAS_INVALID_CALLED_STATION

70 = IAS_INVALID_PORT_TYPE

71 = IAS_INVALID_RESTRICTION

80 = IAS_NO_RECORD

96 = IAS_SESSION_TIMEOUT

97 = IAS_UNEXPECTED_REQUEST

This is an IAS-internal attribute.

  Class Text The attribute that is sent to the client in an Access-Accept packet.

  Session-Timeout Number The length of time (in seconds) before the session is

terminated.

  Idle-Timeout Number The length of idle time (in seconds) before the session is terminated.

  Termination-Action Number The action that the network access server takes when

service is completed.

  EAP-Friendly-Name Text

The friendly name of the EAP-based authentication method that was used by the access client and NPS server during the authentication process. For example, if the client and server use Extensible Authentication Protocol (EAP) and the EAP type MS-CHAP v2, the value of EAP-Friendly-Name is “Microsoft Secured Password (EAP-MSCHAPv2)."

  Acct-Status-Type Number

The number that specifies whether an accounting packet starts or stops a bridging, routing, or Terminal Server session.

  Acct-Delay-Time Number

The length of time (in seconds) for which the network access server has been sending the same accounting packet.

  Acct-Input-Octets Number The number of octets received during the session.

  Acct-Output-Octets Number The number of octets sent during the session.

  Acct-Session-Id Text The unique numeric string that identifies the server

session.

  Acct-Authentic Number The number that specifies which server authenticated an incoming call.

  Acct-Session-Time Number The length of time (in seconds) for which the session

has been active.

  Acct-Input-Packets Number The number of packets received during the session.

  Acct-Output-Packets Number The number of packets sent during the session.

 Acct-Terminate-Cause

Number The reason that a connection was terminated.

  Acct-Multi-Ssn-ID Text The unique numeric string that identifies the

multilink session.

  Acct-Link-Count Number The number of links in a multilink session.

  Acct-Interim-Interval Number The length of interval (in seconds) between each

interim update that the network access server sends.

  Tunnel-Type Number The tunneling protocol to be used.

  Tunnel-Medium-Type Number

The medium to use when creating a tunnel for protocols. For example, L2TP packets can be sent over multiple link layers.

  Tunnel-Client-Endpt Text The IP address of the tunnel client.

  Tunnel-Server-Endpt Text The IP address of the tunnel server.

  Acct-Tunnel-Conn Text An identifier assigned to the tunnel.

  Tunnel-Pvt-Group-ID Text The group ID for a specific tunneled session.

  Tunnel-Assignment-ID Text The tunnel to which a session is assigned.

  Tunnel-Preference Number

The preference of the tunnel type, as indicated with the Tunnel-Type attribute when multiple tunnel types are supported by the access server.

  MS-Acct-Auth-Type Number A Routing and Remote Access service attribute. For

more information, see RFC 2548.

  MS-Acct-EAP-Type Number A Routing and Remote Access service attribute. For

more information, see RFC 2548.

  MS-RAS-Version Text A Routing and Remote Access service attribute. For

more information, see RFC 2548.

  MS-RAS-Vendor Number A Routing and Remote Access service attribute. For

more information, see RFC 2548.

  MS-CHAP-Error Text A Routing and Remote Access service attribute. For

more information, see RFC 2548.

  MS-CHAP-Domain Text A Routing and Remote Access service attribute. For

more information, see RFC 2548.

 MS-MPPE-Encryption-Types

Number A Routing and Remote Access service attribute. For more information, see RFC 2548.

 MS-MPPE-Encryption-Policy

Number A Routing and Remote Access service attribute. For more information, see RFC 2548.

  Proxy-Policy-Name Text The name of the connection request policy that

matched the connection request.

  Provider-Type Number

Specifies the location where authentication occurs. Possible values are 0, 1, and 2. A value of 0 indicates that no authentication occurred. A value of 1 indicates that authentication occurs on the local NPS server. A value of 2 indicates that the connection request is forwarded to a remote RADIUS server for authentication.

  Provider-Name Text

A string value that corresponds to Provider-Type. Possible values are "None" for a Provider-Type value of 0, "Windows" for a Provider-Type value of 1, and "Radius Proxy" for Provider-Type value of 2.

  Remote-Server-Address

IP address

The IP address of the remote RADIUS server to which the connection request was forwarded for authentication.

"CLIENTCOMP"

MS-RAS-Client-Name Text

The name of the remote access client. The Vendor-Length of the Value field, including the vendor ID, vendor-type, vendor-length, and value, must be at least 7 and less than 40.

Value, which specifies the computer name of the endpoint that is requesting network access, is sent in ASCII format and is null terminated.

The valid character set for the computer name includes letters, numbers, and the following symbols: ! @ # $ % ^ & ‘ ) ( . - _ { } ~.

  MS-RAS-Client-Version Number

The operating system version that is installed on the remote access client. The Vendor-Length of the Value field, including the vendor ID, vendor-type, vendor-length, and value, must be at least 7.

Value, which specifies the version of the operating system on a remote access client, is a string that is in network byte order.

Entries recorded in DTS Compliant log files

ODBC and IAS legacy file types contain a subset of the information that NPS sends to its SQL Server database. In Windows Server 2008 R2, a new log file type, called DTS Compliant is available. The DTS Compliant file type’s XML format is identical to the XML format that NPS uses to import data into its SQL Server database. Therefore, the DTS Compliant file format provides a more efficient and complete transfer of data into the standard SQL Server database for NPS.

You can interpret the DTS Compliant log files using the table of the IAS-internal attributes that is listed above. However, note that the NPS log files in Windows Server 2008 R2 can contain additional information. For example, since in Windows Server 2008 R2 you can specify multiple configurations for System Health Validators (SHVs), NPS log files in Windows Server 2008 R2 contain SHV configuration details that are specific for any particular event. (For more information about multiple SHV configurations in Windows Server 2008 R2, see “Security Health Validators in Windows Server 2008 R2” in Choose a Compliance Strategy (http://go.microsoft.com/fwlink/?LinkID=182634).

The following is an example entry (Access-Accept) from a DTS Compliant log file.

<Event>                <Timestamp data_type="4">12/22/2009 15:06:56.609</Timestamp>                 <Computer-Name data_type="1">NAP-IAS2</Computer-Name>                <Event-Source data_type="1">IAS</Event-Source>                <Acct-Session-Id data_type="2">B3BA359F48CEDE4E9F78E5B3158F3B877E744D735B83CA01</Acct-Session-Id>                <Class data_type="1">311 1 2001:4898:b0:3007:492e:957a:d44d:7093 12/16/2009 04:32:04 145361</Class>                <MS-Extended-Quarantine-State data_type="0">0</MS-Extended-Quarantine-State>                <MS-Quarantine-State data_type="0">0</MS-Quarantine-State>                <Client-IPv6-Address data_type="5">2001:4898:b0:3007:6cc0:9514:d2ff:cdcf</Client-IPv6-Address>                <Client-Vendor data_type="0">0</Client-Vendor>                <Client-Friendly-Name data_type="1">NAP-HRA2</Client-Friendly-Name>                <Proxy-Policy-Name data_type="1">HRA</Proxy-Policy-Name>                <Provider-Type data_type="0">1</Provider-Type>                <Quarantine-Session-Id data_type="1">{9F35BAB3-CE48-4EDE-9F78-E5B3158F3B87} - 2009-12-22 23:06:53.319Z</Quarantine-Session-Id>                <Machine-Inventory data_type="1">6.1.7600 0.0 x86 Workstation</Machine-Inventory>                <Fully-Qualified-Machine-Name data_type="1">CONTOSO\CLIENT1</Fully-Qualified-Machine-Name>                <Authentication-Type data_type="0">7</Authentication-Type>                <System-Health-Result data_type="1">Windows Security Health Validator:Compliant:No Data:None[]:(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - )</System-Health-Result>                <System-Health-ResultEx data_type="1">                                <SHV-Name data_type="1">Windows Security Health Validator</SHV-Name>                                <Config-ID data_type="0">0</Config-ID>                                <Config-Friendly-Name data_type="1"></Config-Friendly-Name>                                <Health-Result data_type="1">Compliant</Health-Result>                                <Extended-Isolation-State data_type="1">No Data</Extended-Isolation-State>                                <Failure-Category data_type="1">None</Failure-Category>                                <Failure-Category-String data_type="1"></Failure-Category-String>                                <Compliance-Results data_type="1"></Compliance-Results>                </System-Health-ResultEx>                <NP-Policy-Name data_type="1">ias2-HRA-NAPSTIR-Red-Compliant</NP-Policy-Name>                <Quarantine-Update-Non-Compliant data_type="0">0</Quarantine-Update-Non-Compliant>                <Framed-Protocol data_type="0">1</Framed-Protocol>                <Service-Type data_type="0">2</Service-Type>                <Packet-Type data_type="0">2</Packet-Type>                <Reason-Code data_type="0">0</Reason-Code>

</Event>

The following table shows how the SHV information in this example entry can be interpreted.

 Tag and value Description <System-Health-Result data_type="1">Windows Security Health Validator:Compliant:No Data:None[]:(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - )</System-Health-Result>

Specifies the SHV details. There can be one or several System-Health-Result tags in an NPS log file entry.

<SHV-Name data_type="1">Windows Security Health Validator</SHV-Name>

Specifies the particular SHV that was used in the event.

<Config-ID data_type="0">0</Config-ID>Specifies the SHV configuration that was used in the event.

<Config-Friendly-Name data_type="1"></Config-Friendly-Name>

Specifies the friendly name of the SHV used in the event.

<Health-Result data_type="1">Compliant</Health-Result>Specifies the health state of the NAP client computer (compliant or noncompliant).

Interpret Windows System Health Validator Entries in Log Files

When NPS is configured as a Network Access Protection (NAP) policy server, and one or more health policies are configured with the Windows Security Health Validator (WSHV), NPS logs statement of health responses (SoHRs) in the NPS log file or to a Microsoft® SQL Server™ database, depending on your accounting configuration.

You can use the information in this topic to interpret WSHV entries in NPS accounting logs.

Diagnostic codes

The WSHV entries contain elements that correspond to components that might be installed or enabled on client computers, such as firewalls, antivirus applications, and Windows Automatic Updates.

The WSHV log file entries always present the WSHV list of elements as diagnostic codes, and these codes are always presented in the following order:

1. Firewall (On/Off)

2. Antivirus - On/Off

3. Antivirus - Up-to-date status

4. Antispyware - On/Off

5. Antispyware - Up-to-date status

6. Automatic Updates (On/Off)

7. Security Updates - Compliance code

8. Security Updates - Severity

9. Security Updates - Legitimate Source (Windows Update, Windows Server Update Services, or Microsoft Update)

For item 9 above, the following codes are possible values in the log file.

Update source Diagnostic code

Windows Update 0x00004000Windows Server Update Services (WSUS) 0x00010000Microsoft Update 0x00020000

Note

If the configuration allows the receipt of updates from more than one source, the log file entry combines the codes. For example, if both Windows Update and Microsoft Update are legitimate sources, the log file code is 0x00024000.

When each of the other eight elements is evaluated as compliant by NPS, the diagnostic code is 0x0. When an element of the SHV is compliant, the corresponding component on the client computer is either on, as in the case of a firewall application, or it is up-to-date, as in the case of Windows Automatic Updates or signatures for an antispyware application. If the Windows SHV is not configured to enforce any specific element, such as Firewall or Security Updates, log entries for the element are not relevant and should be ignored.

The Security Updates element provides a severity rating. To interpret the severity rating when reviewing the NPS log file, you can use the following severity levels.

Severity level Code in NPS log

Unspecified 0x0040Low 0x0080Moderate 0x0100Important 0x0200Critical 0x0400

Error codes

On the client computer, the NAP agent can receive errors from the Windows System Health Agent, which monitors the components on the client operating system, such as firewalls and antivirus applications. When the NAP agent sends a statement of health (SoH) to NPS, the statement contains information about errors on the client computer.

In turn, NPS records the error in the NPS log file.

The following table provides the possible error codes that can be logged by NPS.

Error code Description

0xC0FF0001E_MSSHV_PRODUCT_NOT_ENABLED

A system health component is not enabled.

0xC0FF0002E_MSSHAV_PRODUCT_NOT_INSTALLED

A system health component is not installed.

0xC0FF0003E_MSSHAV_WSC_SERVICE_DOWN

The Windows Security Center service is not running.

0xC0FF0004E_MSSHV_PRODUCT_NOT_UPTODATE

The signatures for a specific system health component are not up to date.

0x00FF0008

E_MSSHAV_WUA_SERVICE_NOT_STARTED_SINCE_BOOT

The Windows Server Update Services has not started. An administrator must try to start the service manually.

0xC0FF000C

E_MSSHAV_NO_WUS_SERVER

The Windows Update Agent on this computer is not configured to synchronize with a Windows Server Update Services server. An administrator must configure the Windows Update Agent service. Click the Try again button after configuration is done for the changes to take effect.

0xC0FF000D

E_MSSHAV_NO_CLIENT_ID

Windows failed to determine the Windows Server Update Services client ID of this computer.

0xC0FF000E

E_MSSHAV_WUA_SERVICE_DISABLED

The Windows Update Agent service has been disabled or not configured to start automatically. An administrator must enable the service.

0xC0FF000F E_MSSHAV_WUA_COMM_FAILURE

The periodic scan of this computer for security updates failed. An administrator must ensure that a Windows Server Update Services server is available and that the Windows Update Agent on this computer is configured to synchronize with the server.

0xC0FF0010

E_MSSHAV_UPDATES_INSTALLED_REQUIRE_REBOOT

Security updates have been installed and require this computer to be restarted. Please close all applications and restart this computer.

0xC0FF0012

E_MSSHV_WUS_SHC_FAILURE

The NPS server failed to validate the security update status of this computer. An administrator must ensure that a Windows Server Update Services server is available and that the Windows Update Agent on this computer is configured to synchronize with the server.

0xC0FF0014E_MSSHV_UNKNOWN_CLIENT

Unknown client

0xC0FF0017

E_MSSHV_INVALID_SOH

The Windows Security Health Validator did not process the latest Statement of Health (SoH) because the SoH is not valid.

0xC0FF0018

E_MSSHAV_WSC_SERVICE_NOT_STARTED_SINCE_BOOT

The Windows Security Center service has not started. An administrator must try to start the service manually.

0xC0FF0047E_MSSHV_THIRD_PARTY_PRODUCT_NOT_ENABLED

A third-party system health component is not enabled.

0xC0FF0048

E_MSSHV_THIRD_PARTY_PRODUCT_NOT_UPTODATE

The signatures for a specific third-party system health component are not up to date.

0xC0FF004EL

E_MSSHAV_BAD_UPDATE_SOURCE_MU

This computer is not configured to receive security updates from a source approved for this network. An administrator must configure the Windows Update Agent service to receive updates from Microsoft Update.

0xC0FF004FL

E_MSSHAV_BAD_UPDATE_SOURCE_WUMU

This computer is not configured to receive security updates from a source approved for this network. An administrator must configure the Windows Update Agent service to receive updates from Windows Update or Microsoft Update.

0xC0FF0050L E_MSSHAV_BAD_UPDATE_SOURCE_MUWSUS

This computer is not configured to receive security updates from a source approved for this network. An administrator must configure the Windows Update Agent service to receive updates from Windows Server Update Services or Microsoft Update.

0xC0FF0051L

E_MSSHAV_NO_UPDATE_SOURCE

The Windows Update Agent on this computer is not configured to receive security updates. An administrator must configure the Windows Update Agent service. The NAP agent might have to be restarted for changes to take effect.

Determining the client operating system

When you review Windows SHV entries in the NPS log file, you can determine whether the client computer is running Windows Vista or Windows XP in one of two ways:

1. Examine the field OS-Version in the NPS log.

2. Count the number of diagnostic codes recorded in the log file. If the client computer is running Windows Vista, NPS logs all eight diagnostic codes. If the client computer is running Windows XP, NPS logs only six diagnostic codes because the monitoring of antispyware status is not supported in WSHV for Windows XP.

Example log file entries

The first example log file entry depicts an entry for a client computer running Windows Vista that is not configured to synchronize with a Windows Server Update Services server. The text in italics is added to clarify the meaning of the diagnostic codes and does not normally appear in NPS log entries.

First example log file entry

Machine testclient was quarantined. OS-Version = 6.0.5495 0.0 x86 Workstation Fully-Qualified-Machine-Name = <undetermined> Fully-Qualified-User-Name = <undetermined> NAS-IP-Address = <not present> NAS-IPv6-Address = fe80::e1dc:49f:af27:d0c1 NAS-Identifier = testserver Called-Station-Identifier = <not present> Calling-Station-Identifier = <not present> Account-Session-Identifier = F1290E5E59241D44A57539224835F0FDC46427E9FBCAC601 Proxy-Policy-Name = Use Windows authentication for all users Policy-Name = Access Denied Quarantine-Session-Identifier ={5E0E29F1-2459-441D-A575-39224835F0FD} - 2006-08-28 23:44:32.391Z Quarantine-Help-URL = <undetermined>

Quarantine-System-Health-Result =Windows Security Health Validator NonCompliant None (0x0-) Firewall is compliant (0x0-) Anti Virus is compliant (0x0-) Anti Virus signatures are compliant (0x0-) Anti Spyware is compliant (0x0-) Anti Spyware signatures are compliant (0x0-) Automatic Update is compliant (0xc0ff000c-The Windows Update Agent on this computer is notconfigured to synchronize with a Windows Server Update Servicesserver. An administrator must configure the Windows Update Agentservice. Please click the 'try again' button after configuration isdone for the changes to take effect.) Diagnostic code for Security Updates from Diagnostic Code table (0x40-) Unspecified Severity Level from Severity level table (0x00004000-) Legitimate update source is Windows Update

Second example log file entry

The second example log file entry depicts an entry for a client computer running Windows Vista that is configured to use the Windows Security Center for the firewall, antivirus, antispyware and Automatic Updates. Because Windows Security Center is disabled, as is detailed in the log file entry, the diagnostic codes for the Windows SHV do not have meaning and should be ignored.

Machine testclient was quarantined. OS-Version = 6.0.5495 0.0 x86 Workstation Fully-Qualified-Machine-Name = <undetermined> Fully-Qualified-User-Name = <undetermined> NAS-IP-Address = <not present> NAS-IPv6-Address = fe80::e1dc:49f:af27:d0c1 NAS-Identifier = testserver Called-Station-Identifier = <not present> Calling-Station-Identifier = <not present> Account-Session-Identifier = 32049473A12646448AB5DCFD9BF69271B0477E2E58CCC601 Proxy-Policy-Name = Use Windows authentication for all users Policy-Name = Access Denied Quarantine-Session-Identifier = {73940432-26A1-4446-8AB5-DCFD9BF69271} - 2006-08-30 17:17:33.585Z Quarantine-Help-URL = <undetermined> Quarantine-System-Health-Result = Windows Security Health ValidatorNonCompliantNone(0xc0ff0003-The Windows Security Center service is not running.)(0x0-)(0x0-)(0xc0ff0003-The Windows Security Center service is not running.)(0x0-)(0xc0ff0003-The Windows Security Center service is not running.)(0xc0ff000c-The Windows Update Agent on this computer is not configured to synchronize with a Windows Server Update Services server. An administrator

must configure the Windows Update Agent service. Please click the 'try again' button after configuration is done for the changes to take effect.)(0x40-)

NPS SQL Server Logging

You can use SQL Server logging to record user Remote Authentication Dial-In User Service (RADIUS) authentication and accounting requests received from one or more network access servers (NASs) to a data source on a computer running Microsoft SQL Server. Accounting data is passed from Network Policy Server (NPS) in eXtensible Markup Language (XML) format to a stored procedure in a SQL Server database. SQL Server databases support both SQL and XML (SQLXML).

Advantages of SQL Server logging

Logging to a SQL Server relational database instead of a standard text file — that is, either Internet Authentication Service (IAS) format or database-compatible format — has many advantages, including the following:

Relationships between data tables enable the flexible creation of dynamic data views by using queries and reports.

SQL Server has high-speed optimizations that can effectively support very large, multiple-terabyte-sized databases.

Multiple bulk copy operations can be performed concurrently against a single table in SQL Server to speed data entry.

The Transact-SQL BACKUP and RESTORE statements are optimized to read through a database serially and write in parallel to multiple backup devices. In addition, SQL Server supports differential backups, which replicate only the data changed after the last backup.

You can configure SQL Server logging to provide failover and redundancy, and multiple NPS servers can log to the same database, providing ease of administration.

Data from multiple NPS servers can be stored in the same database, providing a centralized data source for many NPS servers and the ability to achieve a more comprehensive data view for applications that query the database, such as Help desk applications.

Note When you configure NPS to log accounting information to a database on a remote SQL server, you must also create a firewall exception on the SQL Server to allow the incoming connection from the NPS server. By default, SQL Server listens for incoming connections on TCP port 1433. For more information, see INF: TCP Ports Needed for Communication to SQL Server

Through a Firewall.

In addition, you can improve logging performance and, in some circumstances, reduce the cost of deploying SQL Server logging by using SQL Server Express databases installed on each NPS server.

The following sections describe key logging concepts such as requests logged by NPS, NPS log file contents, and how NPS creates an XML document from accounting and authentication data when you deploy SQL Server logging.

Data logged by NPS

By default, NPS does not log any data until you configure it to do so. When you configure SQL Server logging, all required attributes, accounting, and authentication data that is normally logged in either IAS format or database-compatible format is logged to the SQL Server database.

Initially, it is recommended that you enable the logging of accounting and user authentication requests. You can refine your logging settings after you determine your required data.

Requests logged by NPS

You can log the following information in a SQL Server database:

Accounting-on requests, which are sent by the RADIUS client to indicate that it is online and ready to accept connections.

Accounting-off requests, which are sent by the RADIUS client to indicate that it is going offline.

Accounting-start requests, which are sent by the RADIUS client (after the user is authenticated and authorized by the NPS server) to indicate the start of a user session.

Accounting-stop requests, which are sent by the RADIUS client to indicate the end of a user session.

Accounting interim requests, which are sent periodically by some RADIUS clients during a user session, and which can be logged by NPS. This type of request can be used when the Acct-Interim-Interval RADIUS attribute is configured to support periodic requests in network policy settings on the NPS server. The RADIUS client must support the use of accounting interim requests if you want the interim requests to be logged on the NPS server. If the RADIUS client does not send accounting interim requests, they are not logged.

Authentication requests, which are sent by the RADIUS client on behalf of the connecting user. These entries in the log contain only incoming attributes.

Authentication accepts and rejects, which are sent by NPS to the RADIUS client, indicating whether the user is accepted or rejected. These entries contain only outgoing attributes.

NPS log file contents

Unlike database-compatible format log files, which use a fixed sequence of attributes, the sequence of the attributes in a SQL Server log file depends upon the sequence used by the RADIUS client. For more information about the sequence of these records, see the documentation for your RADIUS client.

Required database fields for session correlation

When you create the fields in the tables of your SQL Server databases, you must provide all fields that allow applications to query the database, correlate related fields, and return a cohesive view of each session in the query results. This is called session correlation. At a minimum, to provide session correlation, you must log the values of the following NPS attributes as accounting data in the SQL Server databases:

NAS-IP-Address

NAS-Identifier (You need both NAS-IP-Address and NAS-Identifier because the RADIUS client can send one or the other.)

Class

Acct-Session-Id

Acct-Multi-Session-Id

Packet-Type

Acct-Status-Type

Acct-Interim-Interval

NAS-Port

Event-Timestamp

Configuring accounting to provide the best session correlation

When you use an application to query your SQL Server database, it is important that sufficient data is logged to provide the application with the ability to correlate related fields and

information into a cohesive view of any particular user session. To provide the best session correlation, take the following actions:

Use RADIUS clients that send the Class attribute in all Accounting-Request messages. The Class attribute is sent to the RADIUS client in an Access-Accept message, and is useful for correlating Accounting-Request messages with authentication sessions.

If the Class attribute is sent by the RADIUS client in the Accounting-Request messages, it can be used to match the accounting and authentication records. The combination of the attributes Unique-Serial-Number, Service-Reboot-Time, and Server-Address must be a unique identification for each authentication that the server accepts.

Use RADIUS clients that support interim accounting.

Use NASs that send Accounting-on and Accounting-off messages.

Use RADIUS clients that support the storing and forwarding of accounting data. RADIUS clients that support this feature can store accounting data in circumstances when it cannot communicate with the NPS server. When the NPS server is available, the RADIUS client forwards the stored records to the NPS server, providing increased reliability in accounting over RADIUS clients that do not provide this feature.

Always configure the Acct-Interim-Interval attribute in network policies. The Acct-Interim-Interval attribute sets the interval (in seconds) between each interim update that the NAS sends. You can add the Acct-Interim-Interval attribute on the Settings tab of the network policy. According to RFC 2869, the value of the Acct-Interim-Interval attribute must not be smaller than 60 seconds, or one minute, and cannot be larger than 600 seconds, or 10 minutes. For more information, see RFC 2869 "RADIUS Extensions."

Ensure that logging of periodic status is enabled on your NPS servers.

How NPS creates an XML document from accounting and authentication data

If you select SQL Server logging in the NPS Microsoft Management Console (MMC) snap-in, attribute-value pairs are converted to XML format.

When NPS creates an XML document from attributes, accounting, and authentication data, the XML document includes the attribute ID or name, the attribute value, and the data type of the attribute value. In SQL Server logging, there are five data types for attribute values:

Non-negative integers (data_type=0)

Strings (data_type=1)

Hexadecimal numbers (data_type=2)

IPv4 addresses (data_type=3)

Date and time (data_type=4)

The following example XML document created by NPS includes the attribute name (User-Name), the attribute value (DOMAIN\username), and the data type (1), indicating a value data type of string:

<Event>    <User-Name data_type="1">DOMAIN\username</User-Name></Event>

The next example XML document created by NPS includes the attribute name (NAS-IP-Address), the attribute value (192.168.0.1), and the data type (3), indicating a value data type of IP address:

<Event>    <NAS-IP-Address data_type="3">192.168.0.1</NAS-IP-Address></Event>

The next example XML document created by NPS includes the attribute name (Provider-Type), the attribute value (1), and the data type (0), indicating a value data type of non-negative integers:

<Event>    <Provider-Type data_type="0">1</Provider-Type></Event>

The last example XML document created by NPS includes the three previous examples combined into one XML document:

<Event>    <User-Name data_type="1">DOMAIN\username</User-Name>    <NAS-IP-Address data_type="3">192.168.0.1</NAS-IP-Address>    <Provider-Type data_type="0">1</Provider-Type></Event>

Following is an example of a typical XML document sent by NPS configured for SQL Server logging:

    <Event><Computer-Name data_type="1">MYNAS</Computer-Name><Event-Source data_type="1">NPS</Event-Source><Acct-Session-Id data_type="1">10</Acct-Session-Id><NAS-IP-Address data_type="3">10.10.1.1</NAS-IP-Address><Service-Type data_type="0">2</Service-Type><Framed-Protocol data_type="0">1</Framed-Protocol><NAS-Port data_type="0">7</NAS-Port><NAS-Port-Type data_type="0">5</NAS-Port-Type><Tunnel-Type data_type="0">1</Tunnel-Type>

<Tunnel-Medium-Type data_type="0">1</Tunnel-Medium-Type><Calling-Station-Id data_type="1">10.10.1.2</Calling-Station-Id><Tunnel-Client-Endpt data_type="1">10.10.1.2</Tunnel-Client-Endpt><User-Name data_type="1">MYDOMAIN\Administrator</User-Name><Client-IP-Address data_type="3">10.10.1.1</Client-IP-Address><Client-Vendor data_type="0">0</Client-Vendor><Client-Friendly-Name data_type="1">MYNAS</Client-Friendly-Name><MS-RAS-Vendor data_type="0">311</MS-RAS-Vendor><MS-RAS-Version data_type="1">MSRASV5.20</MS-RAS-Version><MS-RAS-Client-Version data_type="1">MSRASV5.20</MS-RAS-Client-Version><MS-RAS-Client-Name data_type="1">MSRAS-0-MYCLIENT</MS-RAS-Client-Name><Provider-Type data_type="0">1</Provider-Type><Class data_type="1">311 1 192.168.0.123 02/20/2003 19:03:02 9</Class><SAM-Account-Name data_type="1">MYDOMAIN\Administrator</SAM-Account-Name><Fully-Qualified-User-Name data_type="1">MYDOMAIN\Administrator</Fully-Qualified-User-Name><Authentication-Type data_type="0">4</Authentication-Type><Packet-Type data_type="0">1</Packet-Type><Reason-Code data_type="0">0</Reason-Code>    </Event>SQL ProgrammabilityNote Internet Authentication Service (IAS) was renamed Network Policy Server (NPS) starting with Windows Server 2008. The content of this topic applies to both IAS and NPS. Throughout the text, NPS is used to refer to all versions of the service, including the versions originally referred to as IAS.

NPS supports SQL Server logging.

By default, logging is disabled for NPS. To enable it, run the Network Policy Server snap-in (nps.msc) and follow the instructions on the Accounting page.

Sample Stored ProcedureNote A stored procedure in the SQL Server database that is called by NPS must be named report_event, or the NPS SQL Server logging will fail.

The following sample creates an NPS database within the SQL Server 2000 database environment and processes XML documents sent by the NPS servers configured to log to this SQL Server.

In this sample, the NAP-specific information, which is available only from NPS servers running on Windows Server 2008 or later, is stored in the MS_Quarantine_State column. The stored procedure report_event retrieves the values for this column from the XML element './MS-Quarantine-State'. The allowed values for the MS_Quarantine_State column are 0 (Full Access), 1 (Quarantined), and 2 (Probation).

IF EXISTS (SELECT name FROM master.dbo.sysdatabases WHERE name = N'NPSODBC') DROP DATABASE [NPSODBC]GO

CREATE DATABASE [NPSODBC] ON (NAME = N'NPSODBC_Data', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL\data\NPSODBC_Data.MDF' , SIZE = 1, FILEGROWTH = 10%)

LOG ON (NAME = N'NPSODBC_Log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL\data\NPSODBC_Log.LDF' , SIZE = 1, FILEGROWTH = 10%) COLLATE SQL_Latin1_General_CP1_CI_ASGO

exec sp_dboption N'NPSODBC', N'autoclose', N'false'GO

exec sp_dboption N'NPSODBC', N'bulkcopy', N'false'GO

exec sp_dboption N'NPSODBC', N'trunc. log', N'false'GO

exec sp_dboption N'NPSODBC', N'torn page detection', N'true'GO

exec sp_dboption N'NPSODBC', N'read only', N'false'GO

exec sp_dboption N'NPSODBC', N'dbo use', N'false'GO

exec sp_dboption N'NPSODBC', N'single', N'false'GO

exec sp_dboption N'NPSODBC', N'autoshrink', N'false'GO

exec sp_dboption N'NPSODBC', N'ANSI null default', N'false'GO

exec sp_dboption N'NPSODBC', N'recursive triggers', N'false'GO

exec sp_dboption N'NPSODBC', N'ANSI nulls', N'false'GO

exec sp_dboption N'NPSODBC', N'concat null yields null', N'false'GO

exec sp_dboption N'NPSODBC', N'cursor close on commit', N'false'GO

exec sp_dboption N'NPSODBC', N'default to local cursor', N'false'GO

exec sp_dboption N'NPSODBC', N'quoted identifier', N'false'GO

exec sp_dboption N'NPSODBC', N'ANSI warnings', N'false'GO

exec sp_dboption N'NPSODBC', N'auto create statistics', N'true'GO

exec sp_dboption N'NPSODBC', N'auto update statistics', N'true'GO

if( ( (@@microsoftversion / power(2, 24) = 8) and (@@microsoftversion & 0xffff >= 724) ) or ( (@@microsoftversion / power(2, 24) = 7) and (@@microsoftversion & 0xffff >= 1082) ) ) exec sp_dboption N'NPSODBC', N'db chaining', N'false'GO

use [NPSODBC]GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[report_event]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)drop procedure [dbo].[report_event]GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[accounting_data]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)drop table [dbo].[accounting_data]GO

if exists (select * from dbo.systypes where name = N'ipaddress')exec sp_droptype N'ipaddress'GO

setuserGO

EXEC sp_addtype N'ipaddress', N'nvarchar (15)', N'not null'GO

setuserGO

CREATE TABLE [dbo].[accounting_data] ( [id] [int] IDENTITY (1, 1) NOT NULL , [timestamp] [datetime] NOT NULL , [Computer_Name] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [Packet_Type] [int] NOT NULL , [User_Name] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [F_Q_User_Name] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Called_Station_Id] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Calling_Station_Id] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Callback_Number] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Framed_IP_Address] [ipaddress] NULL ,

[NAS_Identifier] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [NAS_IP_Address] [ipaddress] NULL , [NAS_Port] [int] NULL , [Client_Vendor] [int] NULL , [Client_IP_Address] [ipaddress] NULL , [Client_Friendly_Name] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Event_Timestamp] [datetime] NULL , [Port_Limit] [int] NULL , [NAS_Port_Type] [int] NULL , [Connect_Info] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Framed_Protocol] [int] NULL , [Service_Type] [int] NULL , [Authentication_Type] [int] NULL , [NP_Policy_Name] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Reason_Code] [int] NULL , [Class] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Session_Timeout] [int] NULL , [Idle_Timeout] [int] NULL , [Termination_Action] [int] NULL , [EAP_Friendly_Name] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Acct_Status_Type] [int] NULL , [Acct_Delay_Time] [int] NULL , [Acct_Input_Octets] [int] NULL , [Acct_Output_Octets] [int] NULL , [Acct_Session_Id] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Acct_Authentic] [int] NULL , [Acct_Session_Time] [int] NULL , [Acct_Input_Packets] [int] NULL , [Acct_Output_Packets] [int] NULL , [Acct_Terminate_Cause] [int] NULL , [Acct_Multi_Session_Id] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Acct_Link_Count] [int] NULL , [Acct_Interim_Interval] [int] NULL , [Tunnel_Type] [int] NULL , [Tunnel_Medium_Type] [int] NULL , [Tunnel_Client_Endpoint] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Tunnel_Server_Endpoint] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Acct_Tunnel_Connection] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Tunnel_Pvt_Group_Id] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Tunnel_Assignment_Id] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Tunnel_Preference] [int] NULL , [MS_Acct_Auth_Type] [int] NULL , [MS_Acct_EAP_Type] [int] NULL , [MS_RAS_Version] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[MS_RAS_Vendor] [int] NULL , [MS_CHAP_Error] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [MS_CHAP_Domain] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [MS_MPPE_Encryption_Types] [int] NULL , [MS_MPPE_Encryption_Policy] [int] NULL , [Proxy_Policy_Name] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Provider_Type] [int] NULL , [Provider_Name] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Remote_Server_Address] [ipaddress] NULL , [MS_RAS_Client_Name] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [MS_RAS_Client_Version] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,/* The following column stores the NAP-specific information, available from NPS starting with Windows Server 2008. The allowed values are: 0 (Full Access), 1 (Quarantined), and 2 (Probation).*/ [MS_Quarantine_State] [int] NULL ) ON [PRIMARY]GO

SET QUOTED_IDENTIFIER ON GOSET ANSI_NULLS OFF GO

CREATE PROCEDURE dbo.report_event @doc ntextAS

SET NOCOUNT ON

DECLARE @idoc intEXEC sp_xml_preparedocument @idoc OUTPUT, @doc

/* All RADIUS attributes written to the ODBC format logfile are declared here. One additional attribute is added: @record_timestamp. The value of @record_timestamp is the UTC time the record was inserted in the database.

Refer to IAS-Formatted Log Files in Online Help on www.technet.com for information on interpreting these values.*/

DECLARE @record_timestamp datetime

SET @record_timestamp = GETUTCDATE()

INSERT accounting_data

SELECT @record_timestamp, Computer_Name, Packet_Type, [User_Name], F_Q_User_Name, Called_Station_Id, Calling_Station_Id, Callback_Number, Framed_IP_Address, NAS_Identifier, NAS_IP_Address, NAS_Port, Client_Vendor, Client_IP_Address, Client_Friendly_Name, Event_Timestamp, Port_Limit, NAS_Port_Type, Connect_Info, Framed_Protocol, Service_Type, Authentication_Type, NP_Policy_Name, Reason_Code, Class, Session_Timeout, Idle_Timeout, Termination_Action, EAP_Friendly_Name, Acct_Status_Type, Acct_Delay_Time, Acct_Input_Octets, Acct_Output_Octets, Acct_Session_Id, Acct_Authentic, Acct_Session_Time, Acct_Input_Packets, Acct_Output_Packets, Acct_Terminate_Cause, Acct_Multi_Session_Id, Acct_Link_Count, Acct_Interim_Interval, Tunnel_Type, Tunnel_Medium_Type, Tunnel_Client_Endpoint, Tunnel_Server_Endpoint, Acct_Tunnel_Connection, Tunnel_Pvt_Group_Id, Tunnel_Assignment_Id, Tunnel_Preference, MS_Acct_Auth_Type, MS_Acct_EAP_Type, MS_RAS_Version, MS_RAS_Vendor, MS_CHAP_Error, MS_CHAP_Domain,

MS_MPPE_Encryption_Types, MS_MPPE_Encryption_Policy, Proxy_Policy_Name, Provider_Type, Provider_Name, Remote_Server_Address, MS_RAS_Client_Name, MS_RAS_Client_Version,/* NAP-specific information, available from NPS starting with Windows Server 2008. */ MS_Quarantine_StateFROM OPENXML(@idoc, '/Event')WITH ( Computer_Name nvarchar(255) './Computer-Name', Packet_Type int './Packet-Type', [User_Name] nvarchar(255) './User-Name', F_Q_User_Name nvarchar(255) './Fully-Qualifed-User-Name', Called_Station_Id nvarchar(255) './Called-Station-Id', Calling_Station_Id nvarchar(255) './Calling-Station-Id', Callback_Number nvarchar(255) './Callback-Number', Framed_IP_Address nvarchar(15) './Framed-IP-Address', NAS_Identifier nvarchar(255) './NAS-Identifier', NAS_IP_Address nvarchar(15) './NAS-IP-Address', NAS_Port int './NAS-Port', Client_Vendor int './Client-Vendor', Client_IP_Address nvarchar(15) './Client-IP-Address', Client_Friendly_Name nvarchar(255) './Client-Friendly-Name', Event_Timestamp datetime './Event-Timestamp', Port_Limit int './Port-Limit', NAS_Port_Type int './NAS-Port-Type', Connect_Info nvarchar(255) './Connect-Info', Framed_Protocol int './Framed-Protocol', Service_Type int './Service-Type', Authentication_Type int './Authentication-Type', NP_Policy_Name nvarchar(255) './NP-Policy-Name', Reason_Code int './Reason-Code', Class nvarchar(255) './Class', Session_Timeout int './Session-Timeout', Idle_Timeout int './Idle-Timeout', Termination_Action int './Termination-Action', EAP_Friendly_Name nvarchar(255) './EAP-Friendly-Name', Acct_Status_Type int './Acct-Status-Type', Acct_Delay_Time int './Acct-Delay-Time', Acct_Input_Octets int './Acct-Input-Octets', Acct_Output_Octets int './Acct-Output-Octets', Acct_Session_Id nvarchar(255) './Acct-Session-Id', Acct_Authentic int './Acct-Authentic', Acct_Session_Time int './Acct-Session-Time', Acct_Input_Packets int './Acct-Input-Packets', Acct_Output_Packets int './Acct-Output-Packets', Acct_Terminate_Cause int './Acct-Terminate-Cause', Acct_Multi_Session_Id nvarchar(255) './Acct-Multi-Session-Id', Acct_Link_Count int './Acct-Link-Count', Acct_Interim_Interval int './Acct-Interim-Interval', Tunnel_Type int './Tunnel-Type',

Tunnel_Medium_Type int './Tunnel-Medium-Type', Tunnel_Client_Endpoint nvarchar(255) './Tunnel-Client-Endpt', Tunnel_Server_Endpoint nvarchar(255) './Tunnel-Server-Endpt', Acct_Tunnel_Connection nvarchar(255) './Acct-Tunnel-Connection', Tunnel_Pvt_Group_Id nvarchar(255) './Tunnel-Pvt-Group-Id', Tunnel_Assignment_Id nvarchar(255) './Tunnel-Assignment-Id', Tunnel_Preference int './Tunnel-Preference', MS_Acct_Auth_Type int './MS-Acct-Auth-Type', MS_Acct_EAP_Type int './MS-Acct-EAP-Type', MS_RAS_Version nvarchar(255) './MS-RAS-Version', MS_RAS_Vendor int './MS-RAS-Vendor', MS_CHAP_Error nvarchar(255) './MS-CHAP-Error', MS_CHAP_Domain nvarchar(255) './MS-CHAP-Domain', MS_MPPE_Encryption_Types int './MS-MPPE-Encryption-Types', MS_MPPE_Encryption_Policy int './MS-MPPE-Encryption-Policy', Proxy_Policy_Name nvarchar(255) './Proxy-Policy-Name', Provider_Type int './Provider-Type', Provider_Name nvarchar(255) './Provider-Name', Remote_Server_Address nvarchar(15) './Remote-Server-Address', MS_RAS_Client_Name nvarchar(255) './MS-RAS-Client-Name', MS_RAS_Client_Version nvarchar(255) './MS-RAS-Client-Version',/* NAP-specific information, available from NPS starting with Windows Server 2008. */ MS_Quarantine_State int './MS-Quarantine-State' )

EXEC sp_xml_removedocument @idoc

SET NOCOUNT OFFGOSET QUOTED_IDENTIFIER OFF GOSET ANSI_NULLS ON GO

Network Policy Server Tools and SettingsYou can use Network Policy Server (NPS) tools, such as the NPS console and the Network Shell (Netsh) commands for NPS, to configure your servers running NPS.

NPS settings include port settings, the use of the Message-Authenticator attribute, and shared secrets.

In this section

NPS Tools

NPS Settings

NPS ToolsYou can use the following tools to configure, manage, monitor, and develop applications for your servers running Network Policy Server (NPS).

NPS console

After you have installed NPS, you can manage the local NPS server by using the NPS console. The NPS console is opened in the Administrative Tools folder of the Start menu.

NPS MMC snap-in

You can manage a local NPS server and one or more remote NPS servers from the NPS Microsoft Management Console (MMC) snap-in on the local NPS server. The MMC is opened by typing MMC in the Run dialog box that is opened on the Start menu. After the MMC is open you can add the NPS snap-in to the console.

Netsh commands for NPS

You can use commands in the Netsh Network Policy Server (NPS) context to configure all aspects of NPS. The Netsh commands for NPS provide the same functionality as the NPS console, and the commands can be run manually at the Netsh command prompt or automatically in scripts and batch files.

You can download the Network Shell (Netsh) Technical Reference in Windows Help format from the Microsoft TechNet Gallery at https://gallery.technet.microsoft.com/Netsh-Technical-Reference-c46523dc?redir=0.

Network Monitor

Network Monitor is a protocol analyzer that allows you to capture, view, and analyze network traffic.

The Network Monitor tool can be used to capture the Remote Authentication Dial-In User Service (RADIUS) messages being sent and received for detailed analysis.

To view RADIUS messages, configure Network Monitor with a display filter to display only RADIUS messages by disabling all protocols except the RADIUS protocol.

To download Network Monitor, see Network Monitor 3.4 Downloads at https://blogs.technet.microsoft.com/netmon/p/downloads/.

NPS API sets

NPS includes two application programming interface (API) sets: NPS Extensions API and Server Data Objects (SDO) API. Both NPS Extensions API and SDO API are also supported by the precursor of NPS, Internet Authentication Service (IAS).

NPS Extensions API can be used to extend the authentication, authorization, and accounting methods offered by NPS and previously by IAS.

Server Data Objects API can be used to manipulate the network policy configuration on a computer that runs NPS or IAS.

For more developer information related to NPS, see the following topics on the Microsoft Developer Network (MSDN):

Network Policy Server at http://go.microsoft.com/fwlink/?LinkId=119325

Extensible Authentication Protocol at http://go.microsoft.com/fwlink/?LinkId=119326

Extensible Authentication Protocol Host at http://go.microsoft.com/fwlink/?LinkId=119329

MS-CHAP Password Management API at http://go.microsoft.com/fwlink/?LinkId=119330

Network Access Protection at http://go.microsoft.com/fwlink/?LinkId=119332

NPS SettingsThe following sections provide information about Network Policy Server (NPS) features and settings.

In this section

NPS Server Registration in Active Directory

NPS Ports

NPS Firewall Settings

NPS Message-Authenticator Attribute

NPS Shared Secrets

NPS Reason Codes

NPS Registry Entries

NPS Server Registration in Active Directory

To enable Network Policy Server (NPS) to read user account information in Active Directory Domain Services (AD DS) during the authentication and authorization processes, you must register the server running NPS in AD DS.

The NPS server is registered in AD DS when it is added as a member of the RAS and IAS Servers security group.

You can add the NPS server to this AD DS group in the local domain using the Register server in Active Directory command on the Action menu of the NPS console or NPS Microsoft Management Console (MMC) snap-in.

Note

You can also add the NPS server to the RAS and IAS Servers security group by using the netsh nps add registeredserver command.

To add the NPS server to the RAS and IAS Servers security group in a remote domain or forest, open the Active Directory Users and Computers MMC snap-in, browse to the security group, and then add the NPS server as a member.

NPS Ports

By default, Network Policy Server (NPS) listens for Remote Authentication Dial-In User Service (RADIUS) traffic on the following User Datagram Protocol (UDP) ports.

 RADIUS Traffic Type UDP Port Authentication traffic 1812Accounting traffic 1813Authentication traffic 1645Accounting traffic 1646

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. If you do not use the RADIUS default port numbers, you must configure exceptions on the firewall of the local computer to allow RADIUS traffic on the new ports.

Connecting to a remote SQL server

When you configure NPS to log accounting information to a database on a remote SQL Server, you must also create a firewall exception on the SQL Server to allow the incoming connection from the NPS server. By default, SQL Server listens for incoming connections on TCP port

1433. For more information, see INF: TCP Ports Needed for Communication to SQL Server Through a Firewall.

NPS Firewall Settings

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 Remote Authentication Dial-In User Service (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 with Advanced Security (WFAS) on the local server running Network Policy Server (NPS).

Firewalls running on other computers or hardware devices.

WFAS 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 WFAS 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 WFAS 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 (NASs) 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.

Other firewalls

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

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

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

A single interface on the perimeter network. In this configuration, NPS communicates with 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, on 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, virtual private network (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, on its intranet interface), to allow the forwarding of RADIUS messages between the NPS server on the perimeter network and domain controllers on the intranet. Additional filters can allow the passing of traffic to Web, VPN, and other types of servers on the perimeter network.

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

Filters on the perimeter network interface

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

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

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

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

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

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

Filters on the intranet interface

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

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

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

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

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

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

NPS Message-Authenticator Attribute

When you add one or more Remote Authentication Dial-In User Service (RADIUS) clients in the NPS Microsoft Management Console (MMC) snap-in, you configure the IP address of one RADIUS client or, if you are using Windows Server 2008 Enterprise or Windows Server 2008 Datacenter, you configure multiple RADIUS clients using an IP address range. If an incoming RADIUS Access-Request message does not originate from an IP address of a configured RADIUS client, Network Policy Server (NPS) automatically discards the message, providing protection for a server running NPS. However, source IP addresses can be spoofed (substituted with other IP addresses) by malicious users.

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

Key facts about the Message-Authenticator attribute:

The RADIUS Message-Authenticator attribute is a Message Digest 5 (MD5) hash of the entire RADIUS message.

The shared secret configured on the NPS server and the RADIUS client is used as the key.

If the RADIUS Message-Authenticator attribute is present, it is verified by NPS. If the Access-Request message fails verification, the message is discarded by the NPS server.

If the RADIUS client settings require the Message-Authenticator attribute and it is not present, the RADIUS message is discarded.

Note With NPS in Windows Server 2008, all Extensible Authentication Protocol (EAP) and Protected Extensible Authentication Protocol (PEAP) authentication methods use the Message-Authenticator attribute by default.

NPS Shared Secrets

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

A Remote Authentication Dial-In User Service (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 portable computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X-capable switches, virtual private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS servers such as Network Policy Server (NPS) servers.

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 network access server (NAS).

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. Make sure your shared secrets contain characters from each of the following three groups:

 Group Examples Letters (uppercase and lowercase) A, B, C and a, b, cNumerals 0, 1, 2, 3Symbols (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 by using 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.

NPS Reason Codes

When Network Policy Server (NPS) writes an event to either the security or system event log, the event can contain a reason code. Reason codes provide specific information about the cause for the event being written to the log. The following sections provide information about NPS reason codes.

In this section

NPS Reason Codes 0 Through 37

NPS Reason Codes 38 Through 257

NPS Reason Codes 258 Through 282

NPS Reason Codes 283 Through 303

NPS Reason Codes 0 Through 37

Network Policy Server (NPS) provides reason codes to identify changes, problems, and status via events in Event Viewer while NPS is running. You can use the following reason code definitions to look up reason codes and clarify their meaning.

Note

There are intentional gaps in the numeric sequence of reason codes. For example, the reason codes 38 and 48 exist, but there are currently no reason codes that correspond to the numbers 39 through 47.

Following are some of the reason codes provided by NPS.

Reason Code

Description

0 The connection request was successfully authenticated and authorized by Network Policy Server.

1 The connection request failed due to a Network Policy Server error.2 There are insufficient access rights to process the request.

3 The Remote Authentication Dial-In User Service (RADIUS) Access-Request message that NPS received from the network access server was malformed.

4The NPS server was unable to access the Active Directory Domain Services (AD DS) global catalog. Because of this, authentication and authorization for the connection request cannot be performed, and access is denied.

5The Network Policy Server was unable to connect to a domain controller in the domain where the user account is located. Because of this, authentication and authorization for the connection request cannot be performed, and access is denied.

6

The NPS server is unavailable. This issue can occur if the NPS server is running low on or is out of random access memory (RAM). It can also occur if the NPS server fails to receive the name of a domain controller, if there is a problem with the Security Accounts Manager (SAM) database on the local computer, or in circumstances where there is a Windows NT directory service (NTDS) failure.

7 The domain that is specified in the User-Name attribute of the RADIUS message does not exist.

8 The user account that is specified in the User-Name attribute of the RADIUS message does not exist.

9 An Internet Authentication Service (IAS) extension dynamic link library (DLL) that is installed on the NPS server discarded the connection request.

10 An IAS extension dynamic link library (DLL) that is installed on the NPS server has failed and cannot perform its function.

16 Authentication failed due to a user credentials mismatch. Either the user name provided does not match an existing user account or the password was incorrect.

17 The user's attempt to change their password has failed.

18 The authentication method used by the client computer is not supported by Network Policy Server for this connection.

19

Challenge Handshake Authentication Protocol (CHAP) is being used as the authentication method for the connection request, however CHAP is not configured to store a reversibly encrypted form of user passwords.

With CHAP, reversibly encrypted password storage is required. You can enable reversibly encrypted password storage per user account or for all accounts in a domain using Group Policy. To enable reversibly encrypted password storage for a user account, obtain the properties of a user account in AD DS, click the Account tab, and then select the Store password using reversible encryption check box.

To allow reversibly encrypted password storage for all user accounts in the domain, add the Group Policy Management Editor snap-in to the Microsoft Management Console (MMC) and enable the default domain policy setting Store password using reversible encryption at the following path: Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies | Password Policies.

20The client attempted to use LAN Manager authentication, which is not supported by Network Policy Server. To enable the use of LAN Manager authentication, see NPS: LAN Manager Authentication.

21 An IAS extension dynamic link library (DLL) that is installed on the NPS server rejected the connection request.

22 Network Policy Server was unable to negotiate the use of an Extensible Authentication Protocol (EAP) type with the client computer.

23An error occurred during the Network Policy Server use of the Extensible Authentication Protocol (EAP). Check EAP log files for EAP errors. By default, these log files are located at %windir%\System32\Logfiles.

32

NPS is joined to a workgroup and performs the authentication and authorization of connection requests using the local Security Accounts Manager database, however the Access-Request message contains a domain user name. NPS does not have access to a domain user accounts database. The connection request was denied.

33 The user that is attempting to connect to the network must change their password.34 The user account that is specified in the RADIUS Access-Request message is disabled.35 The user account that is specified in the RADIUS Access-Request message is expired.

36

The user's authentication attempts have exceeded the maximum allowed number of failed attempts specified by the Account lockout threshold setting in Account Lockout Policy in Group Policy. To unlock the account, obtain the user account properties in the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, click the Account tab, and then click Unlock account.

37

According to AD DS user account logon hours, the user is not permitted to access the network on this day and time. To change the account logon hours, obtain the user account properties in the Active Directory Users and Computers snap-in, click the Account tab, and then click Logon Hours. In the Logon Hours dialog box, configure the days and times when the user is permitted to access the network.

NPS Reason Codes 38 Through 257

Network Policy Server (NPS) provides reason codes to identify changes, problems, and status via events in Event Viewer while NPS is running. You can use the following reason code definitions to look up reason codes and clarify their meaning.

Note

There are intentional gaps in the numeric sequence of reason codes. For example, the reason codes 38 and 48 exist, but there are currently no reason codes that correspond to the numbers 39 through 47.

Following are some of the reason codes provided by NPS.

Reason code

Description

38

Authentication failed due to a user account restriction or requirement that was not followed. For example, the user account settings might require the use of a password but the user attempted to log on with a blank password. To resolve this issue, check the user account properties for restrictions, and then either remove or modify the restrictions or inform the user of the requirements for network access.

48 The connection request did not match a configured network policy, so the connection request was denied by Network Policy Server.

49 The connection request did not match a configured connection request policy, so the connection request was denied by Network Policy Server.

64

Remote Access Account Lockout is enabled, and the user's authentication attempts have exceeded the designated lockout count because the credentials they supplied (user name and password) are not valid. When the lockout count for a user account is reset to 0 due to either a successful authentication or an automatic reset, the registry subkey for the user account is deleted. To manually reset a user account that has been locked out before the failed attempts counter is automatically reset, delete the following registry subkey that corresponds to the user's account name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\domain name:user name

65

The Network Access Permission setting in the dial-in properties of the user account is set to Deny access to the user.

To change the Network Access Permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, click the Dial-in tab, and then change Network Access Permission.

66 Authentication failed. Either the client computer attempted to use an authentication method that is not enabled on the matching network policy or the client computer attempted to authenticate as Guest, but guest authentication is not enabled. To resolve

this issue, ensure that all client computers are configured to use one or more authentication methods that are allowed by matching network policies.

67NPS denied the connection request because the value of the Calling-Station-ID attribute in the Access-Request message did not match the value of Verify Caller ID in user account dial-in properties in the Active Directory Users and Computers snap-in.

68The user or computer does not have permission to access the network on this day at this time. To change the day and time when the user is permitted to connect to the network, change the Day and Time Restrictions in the constraints of the matching network policy.

69The telephone number of the network access server does not match the value of the Calling-Station-ID attribute that is configured in the constraints of the matching network policy. NPS denied the Access-Request message.

70The network access method used by the access client to connect to the network does not match the value of the NAS-Port-Type attribute that is configured in the constraints of the matching network policy. NPS denied the Access-Request message.

72

The user password has expired or is about to expire and the user must change their password, however Authentication Methods in network policy constraints are not configured to allow the user to change their password.

To allow the user to change their password, open the properties of the matching network policy, click the Constraints tab, click Authentication Methods, and then in the details pane select the appropriate authentication method and User can change password after it has expired check box.

73

The purposes that are configured in the Application Policies extensions, also called Enhanced Key Usage (EKU) extensions, section of the user or computer certificate are not valid or are missing. The user or computer certificate must be configured with the Client Authentication purpose in Application Policies extensions. The object identifier for Client Authentication is 1.3.6.1.5.5.7.3.2.

To correct this problem, you must reconfigure the certificate template with the Client Authentication purpose in Application Policies extensions, revoke the old certificate, and enroll a new certificate that is configured correctly.

80 NPS attempted to write accounting data to the data store (a log file on the local computer or a SQL Server database), but failed to do so for unknown reasons.

96 Authentication failed due to an Extensible Authentication Protocol (EAP) session timeout; the EAP session with the access client was incomplete.

97The authentication request was not processed because it contained a Remote Authentication Dial-In User Service (RADIUS) message that was not appropriate for the secure authentication transaction.

112

The local NPS proxy server forwarded a connection request to a remote RADIUS server, and the remote server rejected the connection request. Check the event log on the remote RADIUS server to determine the reason that the connection request was rejected.

113The local NPS proxy attempted to forward a connection request to a member of a remote RADIUS server group that does not exist. To resolve this issue, configure a valid remote RADIUS server group.

115 The local NPS proxy did not forward a RADIUS message because it is not an accounting request or a connection request.

116

The local NPS proxy server cannot forward the connection request to the remote RADIUS server because either the proxy cannot open a Windows socket over which to send the connection request, or the proxy server attempted to send the connection request but received Windows sockets errors that prevented successful completion of the send operation.

117The remote RADIUS server did not respond to the local NPS proxy within an acceptable time period. Verify that the remote RADIUS server is available and functioning properly.

118

The local NPS proxy server received a RADIUS message that is malformed from a remote RADIUS server, and the message is unreadable. This issue can also be caused if a connection request contains more than the expected number of User-Name attributes, or if the User-Name attribute value is not valid, such as if the value has zero length or if it contains characters that are not valid.

256The certificate provided by the user or computer as proof of their identity is a revoked certificate. Because of this, the user or computer was not authenticated, and NPS rejected the connection request.

257Due to a missing dynamic link library (DLL) or exported function, NPS cannot access the certificate revocation list to verify whether the user or client computer certificate is valid or is revoked.

NPS Reason Codes 258 Through 282

Network Policy Server (NPS) provides reason codes to identify changes, problems, and status via events in Event Viewer while NPS is running. You can use the following reason code definitions to look up reason codes and clarify their meaning.

Note

There are intentional gaps in the numeric sequence of reason codes. For example, the reason codes 38 and 48 exist, but there are currently no reason codes that correspond to the numbers 39 through 47.

Following are some of the reason codes provided by NPS.

Reason code

Description

258 NPS cannot access the certificate revocation list to verify whether the user or client computer certificate is valid or is revoked. Because of this, authentication failed.

259The certification authority that manages the certificate revocation list is not available. NPS cannot verify whether the certificate is valid or is revoked. Because of this, authentication failed.

260

The Extensible Authentication Protocol (EAP) message has been altered so that the Message Digest 5 (MD5) hash of the entire Remote Authentication Dial-In User Service (RADIUS) message does not match, or the message has been altered at the Schannel level.

261NPS cannot contact Active Directory Domain Services (AD DS) or the local user accounts database to perform authentication and authorization. The connection request is denied for this reason.

262 NPS discarded the RADIUS message because it is incomplete and the signature was not verified.

263 NPS did not receive complete credentials from the user or computer. The connection request is denied for this reason.

264 The Security Support Provider Interface (SSPI) called by EAP reports that the system clocks on the NPS server and the access client are not synchronized.

265 The certificate that the user or client computer provided to NPS as proof of identity chains to an enterprise root certification authority that is not trusted by the NPS server.

266 NPS received a message that was either unexpected or incorrectly formatted. NPS discarded the message for this reason.

267

The certificate provided by the connecting user or computer is not valid because it is not configured with the Client Authentication purpose in Application Policies or Enhanced Key Usage (EKU) extensions. NPS rejected the connection request for this reason.

268 The certificate provided by the connecting user or computer is expired. NPS rejected the connection request for this reason.

269The Security Support Provider Interface (SSPI) called by EAP reports that the NPS server and the access client cannot communicate because they do not possess a common algorithm.

270Based on the matching NPS network policy, the user is required to log on with a smart card, but they have attempted to log on by using other credentials. NPS rejected the connection request for this reason.

271 The connection request was not processed because the NPS server was in the process of shutting down or restarting when it received the request.

272The certificate that the user or client computer provided to NPS as proof of identity maps to multiple user or computer accounts rather than one account. NPS rejected the connection request for this reason.

273Authentication failed. NPS called Windows Trust Verification Services, and the trust provider is not recognized on this computer. A trust provider is a software module that implements the algorithm for application-specific policies regarding trust.

274

Authentication failed. NPS called Windows Trust Verification Services, and the trust provider does not support the specified action. Each trust provider provides its own unique set of action identifiers. For information about the action identifiers supported by a trust provider, see the documentation for that trust provider.

275 Authentication failed. NPS called Windows Trust Verification Services, and the trust provider does not support the specified form. A trust provider is a software module that implements the algorithm for application-specific policies regarding trust. Trust

providers support subject forms that describe where the trust information is located and what trust actions to take regarding the subject.

276 Authentication failed. NPS called Windows Trust Verification Services, but the binary file that calls EAP cannot be verified and is not trusted.

277 Authentication failed. NPS called Windows Trust Verification Services, but the binary file that calls EAP is not signed, or the signer certificate cannot be found.

278 Authentication failed. The certificate that was provided by the connecting user or computer is expired.

279

Authentication failed. The certificate is not valid because the validity periods of certificates in the chain do not match. For example, the following End Certificate and Issuer Certificate validity periods do not match: End Certificate validity period: 2007-2010; Issuer Certificate validity period: 2006-2008.

280 Authentication failed. The certificate is not valid and was not issued by a valid certification authority (CA).

281Authentication failed. The path length constraint in the certification chain has been exceeded. This constraint restricts the maximum number of CA certificates that can follow this certificate in the certificate chain.

282 Authentication failed. The certificate contains a critical extension that is unrecognized by NPS.

NPS Reason Codes 283 Through 303

Network Policy Server (NPS) provides reason codes to identify changes, problems, and status via events in Event Viewer while NPS is running. You can use the following reason code definitions to look up reason codes and clarify their meaning.

Note

There are intentional gaps in the numeric sequence of reason codes. For example, the reason codes 38 and 48 exist, but there are currently no reason codes that correspond to the numbers 39 through 47.

Following are some of the reason codes provided by NPS.

Reason code

Description

283 Authentication failed. The certificate does not contain the Client Authentication purpose in Application Policies extensions, and cannot be used for authentication.

284 Authentication failed. The certificate is not valid because the certificate issuer and the parent of the certificate in the certificate chain are required to match but do not match.

285 Authentication failed. NPS cannot locate the certificate, or the certificate is incorrectly formed and is missing important information.

286 Authentication failed. The certificate provided by the connecting user or computer is

issued by a certification authority (CA) that is not trusted by the NPS server.

287 Authentication failed. The certificate provided by the connecting user or computer does not chain to an enterprise root CA that NPS trusts.

288 Authentication failed due to an unspecified trust failure.

289 Authentication failed. The certificate provided by the connecting user or computer is revoked and is not valid.

290 Authentication failed. A test or trial certificate is in use, however the test root CA is not trusted, according to local or domain policy settings.

291

Authentication failed because NPS cannot locate and access the certificate revocation list to verify whether the certificate has or has not been revoked. This issue can occur if the revocation server is not available or if the certificate revocation list cannot be located in the revocation server database.

292 Authentication failed. The value of the User-Name attribute in the connection request does not match the value of the common name (CN) property in the certificate.

293

Authentication failed. The certificate provided by the connecting user or computer is not valid because it is not configured with the Client Authentication purpose in Application Policies or Enhanced Key Usage (EKU) extensions. NPS rejected the connection request for this reason.

294

Authentication failed because the certificate was explicitly marked as untrusted by the Administrator. Certificates are designated as untrusted when they are imported into the Untrusted Certificates folder in the certificate store for the Current User or Local Computer in the Certificates Microsoft Management Console (MMC) snap-in.

295 Authentication failed. The certificate provided by the connecting user or computer is issued by a CA that is not trusted by the NPS server.

296

Authentication failed. The certificate provided by the connecting user or computer is not valid because it is not configured with the Client Authentication purpose in Application Policies or Enhanced Key Usage (EKU) extensions. NPS rejected the connection request for this reason.

297 Authentication failed. The certificate provided by the connecting user or computer is not valid because it does not have a valid name.

298Authentication failed. Either the certificate does not contain a valid user principal name (UPN) or the value of the User-Name attribute in the connection request does not match the certificate.

299 Authentication failed. The sequence of information provided by internal components or protocols during message verification is incorrect.

300 Authentication failed. The certificate is malformed and Extensible Authentication Protocl (EAP) cannot locate credential information in the certificate.

301 NPS terminated the authentication process. NPS received a cryptobinding type length value (TLV) from the access client that is not valid. This issue occurs when an attempt to breach your network security has occurred and a man-in-the-middle (MITM) attack is in progress. During MITM attacks on your network, attackers use unauthorized computers to intercept traffic between your legitimate hosts while posing as one of the legitimate hosts. The attacker's computer attempts to gain data from your other network resources. This enables the attacker to use the unauthorized computer to

intercept, decrypt, and access all network traffic that would otherwise go to one of your legitimate network resources.

302NPS terminated the authentication process. NPS did not receive a required cryptobinding type length value (TLV) from the access client during the authentication process.

NPS Registry Entries

The following registry settings can be configured to customize NPS behavior under specific circumstances.

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.In this section

NPS: Account Lockout

NPS CRL Check Registry Settings

NPS: Default Domain

NPS: Default User Identity

NPS: LAN Manager Authentication

NPS: MaxConcurrentApi

NPS: Override User-Name

NPS: Ping User-Name

NPS: SCHANNEL

NPS: User Identity Attribute

NPS: Account Lockout

You can use remote access account lockout to specify how many times a network access authentication attempt fails against a valid user account before the user is denied access. Remote access account lockout is especially important for remote access virtual private network (VPN) connections over the Internet. An attacker on the Internet can attempt to access an organization intranet by sending credentials (valid user name, guessed password) during the VPN connection authentication process. During a dictionary attack, the attacker sends hundreds or thousands of credentials by using a list of passwords based on common words or phrases.

Important Remote access account lockout settings are universally applied to connection requests. When you configure remote access account lockout with a MaxDenials value other than 0, Network Policy Server (NPS) uses that lockout setting when evaluating connection requests from all Remote Authentication Dial-In User Service (RADIUS) clients regardless of type. This includes connection requests from 802.1X authenticating switches and wireless access points, Terminal Services Gateway (TS Gateway) servers, and Routing and Remote Access service (RRAS) servers configured as VPN and dial-up servers.

When remote access account lockout is enabled, a dictionary attack is thwarted after a specified number of failed attempts. As the network administrator, you must decide on two remote access account lockout variables:

The number of failed attempts before future attempts are denied.

After each failed attempt, a failed attempts counter for the user account is incremented. If the user account’s failed attempts counter reaches the configured maximum, future attempts to connect are denied.

A successful authentication resets the failed attempts counter when its value is less than the configured maximum. In other words, the failed attempts counter does not accumulate beyond a successful authentication.

The frequency with which the failed attempts counter is reset.

The failed attempts counter is periodically reset to 0. If an account is locked out after the maximum number of failed attempts, the failed attempts counter is automatically reset to 0 after the reset time.

Note If you’re using RRAS and the RRAS server is configured for Windows Authentication, modify the registry on the RRAS server. If the RRAS server is configured for RADIUS authentication, modify the registry on the NPS server.

Enable the remote access account lockout feature by changing the following settings in the registry on the computer that provides authentication services for connection requests.

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.

Registry path

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\

To enable remote access account lockout

Set the MaxDenials entry in the registry to 1 or greater. MaxDenials is the maximum number of failed attempts before the account is locked out.

By default, MaxDenials is set to 0, which means that remote access account lockout is disabled.

To modify the amount of time before the failed attempts counter is reset

Set the ResetTime (mins) entry in the registry to the required number of minutes.

By default, ResetTime (mins) is set to 0xb40, or 2,880 minutes (48 hours).

To manually reset a user account that has been locked out before the failed attempts counter is automatically reset

Delete the following registry entry that corresponds to the user’s account name:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\domain name:user name

When the lockout count for a user account is reset to 0 due to either a successful authentication or an automatic reset, the registry subkey for the user account is deleted.

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.

NPS: Default Domain

You can use this registry setting to provide Network Policy Server (NPS) with a domain name for use during the authentication and authorization of connection requests.

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.

Configuring the Default Domain Name

While processing connection requests, NPS examines the User-Name portion of the Access-Request message to determine whether a domain name has been specified. If a domain name is specified and NPS is configured to access the user accounts database in the designated domain, NPS proceeds with processing the connection request.

Note

Some network access servers delete or modify the domain name as specified by the user. As a result, the network access request is authenticated against the default domain, which might not be the domain for the user account. To resolve this problem, configure your Remote Authentication Dial-In User Service (RADIUS) servers to change the user name into the correct format with the accurate domain name.

When NPS cannot properly parse the domain identity from the user name attribute in the connection request or the user name does not contain a domain, NPS takes the following actions:

1. If the NPS server is not a member of a domain, NPS authenticates the user against the local Security Accounts Manager (SAM) database.

2. If the NPS server is a member of a domain, NPS checks the DefaultDomain registry entry. If a value is specified for DefaultDomain, NPS authenticates the user against the domain specified in the registry entry.

3. If the NPS server is a member of a domain and a value for the DefaultDomain registry entry is not specified, NPS authenticates the user against the domain to which the NPS server is joined.

Creating the DefaultDomain Registry Key

You must create the new registry key at the following path.

Registry path

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

To specify the NPS-supplied domain

By default, the NPS-supplied domain name is the domain of which the NPS server is a member. You can specify a different NPS-supplied domain by browsing to the registry path in Registry Editor and then adding a new key named DefaultDomain. Next, add a new string value to DefaultDomain that is the domain name you require.

NPS: Default User Identity

You can use the Default User Identity registry setting to provide Network Policy Server (NPS) with a standard user account with which to perform authentication and authorization when the user name is not present in the connection request.

Registry path

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy

User identity is the means by which NPS identifies the user for the purposes of authentication and authorization. Normally, the user identity is the string value of the User-Name Remote Authentication Dial-In User Service (RADIUS) attribute. If the User-Name attribute is not present, or is present but equals null, the user identity is set to the Guest account or the account specified by the Default User Identity registry value.

NPS: LAN Manager Authentication

Although the use of Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) or LAN Manager authentication is not recommended for security reasons, you can enable LAN Manager authentication by using this registry setting to support older Microsoft Windows operating systems on your network.

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.

Registry path

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy

By default, MS-CHAP for Windows Server 2008 does not support LAN Manager authentication.

Although the use of MS-CHAP or LAN Manager authentication is not recommended for security reasons, you might need to deploy one or both of these authentication methods to support legacy clients. If you deploy MS-CHAP with change password capability enabled in Internet Authentication Service (IAS), you must also deploy LAN Manager authentication.

To enable LAN Manager authentication

If you want to enable the use of LAN Manager authentication with MS-CHAP for older Windows operating systems such as Windows NT 3.5 and Windows 95, you must set Allow LM Authentication to 1 on the authenticating server.

To disable LAN Manager authentication

LAN Manager authentication is disabled by default. However, if you have previously enabled it and want to disable it again, set Allow LM Authentication to 0.

NPS: MaxConcurrentApi

You can use this registry setting to alter the number of concurrent authentications performed between the NPS server and a domain controller when NPS is not installed on a domain controller.

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.

Registry path

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters

If NPS is installed on a computer other than a domain controller and NPS 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 increase concurrent authentication

Add a new entry named MaxConcurrentApi to this registry key and assign to it a value from 2 through 5.

NPS: Override User-Name

You can use this registry setting when you deploy Routing and Remote Access service (RRAS) as a dial-up server and you want to use the calling number as the user identity.

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.

Registry path

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy

To always use the calling number as the user identity, set the value of the Override User-Name registry entry to 1 on the authenticating server.

Note

If you set Override User-Name to 1 and the User Identity Attribute to 31, the authenticating server can perform only Automatic Number Identification/Calling Line Identification (ANI/CLI)-based authentication. Normal authentication by using authentication protocols, such as Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) and Extensible Authentication Protocol (EAP), is disabled.

NPS: Ping User-Name

Some Remote Authentication Dial-In User Service (RADIUS) clients — RADIUS proxy servers and network access servers (NASs) — periodically send artificial connection requests, known as ping requests, to servers running Network Policy Server (NPS) and other RADIUS servers in order to verify that the NPS and RADIUS servers are available. These ping requests contain a fictional user name. When NPS processes these requests they are all rejected, and the event and accounting logs become filled with access reject records, making it more difficult to keep track of valid records.

You can configure a Ping User-Name registry entry that specifies the fictional user name (or a user name pattern, with variables, that matches the fictional user name) that is sent by RADIUS clients. When a registry entry for Ping User-Name is configured, NPS matches the registry entry value against the user name value when it receives ping requests. In this circumstance, NPS rejects the authentication requests without processing them. NPS does not record accounting data for connection requests that contain the fictional user name in any log files, which makes the event log easier to interpret.

Note

The Ping User-Name registry entry is not created by default when NPS is installed. You must add Ping User-Name to the registry. You can add an entry to the registry by using Registry Editor.

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.

Registry path

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IAS\Parameters\

To add Ping User-Name to the registry

When you add the Ping User-Name entry to the registry, you must supply values for Name, Type, and Data, as shown in the following table.

Name Type Data

Ping User-Name REG_SZ User name

To indicate one or more user names for a Ping User-Name value, you can enter name patterns (regular expressions) in Data. For example, to indicate one user name of a domain user, you can enter the following regular expression in Data, ^<domain>\\<username>$, or to indicate one user name of a local user, you can enter the following regular expression ^<Machine Name>\\<User Name>$. Or if you want to indicate all domain user names starting with “Test”, you can use the following name pattern, ^<domain>\\Test or \\Test (the latter will apply to any user in the form <domain>\\Test<optional suffix>). For more information about building regular expressions, see Regular Expressions (Visual Studio) (http://go.microsoft.com/fwlink/?LinkID=184811).

NPS: SCHANNEL

You can use this registry setting to enable the logging of client certificate validation failures, which are secure channel (Schannel) events.

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.

Registry path

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

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 NPS server by default.

To enable secure channel events

You can enable additional secure channel event logging by changing the registry key value from 1 (REG_DWORD type, data 0x00000001) to 3 (REG_DWORD type, data 0x00000003).

Note

The logging of rejected or discarded authentication events is enabled by default.

NPS: User Identity Attribute

When you deploy the Routing and Remote Access service (RRAS) as a dial-up server, you can use the User Identity Attribute registry setting to instruct Network Policy Server (NPS) to use the value of the Calling-Station-ID attribute, which is a Remote Authentication Dial-In User Service (RADIUS) attribute, as the identity of the calling user.

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.

Registry path

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy

The RADIUS attribute that NPS uses to identify the user is configurable by setting the User Identity Attribute registry setting.

You can change the value of this entry to the number of the RADIUS attribute that is used for the user identity. To assign the Calling-Station-ID attribute value, change the entry value to 31. By default, User Identity Attribute is set to 1, the RADIUS type value for the User-Name RADIUS 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.