NPS Best Practices
Applies To: Windows Server 2008
NPS best practices
This topic provides best practices for implementing and configuring NPS and is based on recommendations from Microsoft Product Support Services.
Before installing NPS, do the following:
Install and test each of your network access servers using local authentication methods before you make them RADIUS clients.
After you install and configure NPS, save the configuration by using the netsh nps show config > path\file.txt command. Save the NPS configuration with the netsh nps show config > path\file.txt command each time a change is made.
Do not install Windows Server® 2008, Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition on the same partition as Windows 2000. These operating systems use common files in the systemroot\Program Files folder to access the NPS database. If you decide to install Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition on the same partition as Windows 2000, NPS in Windows 2000 can no longer access remote access policies or remote access logging.
Do not configure a server running NPS or Routing and Remote Access as a member of a Windows NT Server 4.0 domain if your user accounts database is stored on a Windows Server 2008 or Windows Server 2003 domain controller in another domain. Doing this will cause Lightweight Directory Access Protocol (LDAP) queries from the NPS server to the domain controller to fail.
Instead, configure your server running NPS or Routing and Remote Access as a member of a Windows Server 2008 or Windows Server 2003 domain. An alternative is to configure a server running NPS as a proxy server that forwards authentication and accounting requests to another server running NPS that can access the user accounts database on the domain controller.
Network Access Protection
Following are the best practices for NAP deployment with NPS.
For the most secure and effective NAP deployment on your network, deploy strong enforcement methods, such as the Internet Protocol security (IPsec), 802.1X, and virtual private network (VPN) enforcement methods. Strong enforcement methods use certificate-based authentication methods and secure the channel between clients and servers through which the statement of health (SoH) and statement of health response (SoHR) are sent. For more information, see NAP Enforcement Methods.
Before you create health policies for your NAP deployments, if you are using non-Microsoft products that support NAP, install non-Microsoft system health agents (SHAs) on client computers. In addition, install the SHAs' corresponding system health validators (SHVs) on NPS servers. For more information, see NAP Components.
When you deploy NAP using the VPN or 802.1X enforcement methods with PEAP authentication, you must configure PEAP authentication in connection request policy even when connection requests are processed locally. For more information, see Connection Request Policies.
For a streamlined method of creating network policies, connection request policies, and health policies for your NAP deployment, use the New NAP Policies wizard. If you want to modify policies created using the wizard, open the policy in the NPS console and make required changes. For more information, see Create NAP Policies with a Wizard.
When you deploy NAP with the IPsec and DHCP enforcement methods, enable client health checks when you configure authentication. You should also configure the Identity Type condition in network policy with the value Computer health check. For more information, see Enable Client Health Checks for DHCP and IPsec NAP Deployments and Configure NAP Conditions in Network Policy.
Client computer configuration
Following are the best practices for client computer configuration.
Automatically configure all of your domain member 802.1X client computers using Group Policy. For more information, see 802.1X Client Configuration with Group Policy.
Automatically configure all of your domain member NAP-capable clients by importing NAP client configuration files into Group Policy.
Following are the best practices for authentication.
Use certificate-based authentication methods such as Protected Extensible Authentication Protocol (PEAP) and Extensible Authentication Protocol (EAP) for strong authentication. Do not use password-based authentication methods because they are vulnerable to a variety of attacks and are not secure. For more information, see Certificates and NPS.
Deploy your own certification authority (CA) with Active Directory® Certificate Services (AD CS) when you use strong certificate-based authentication methods, such as PEAP and EAP, that require the use of a server certificate on NPS servers. You can also use your CA to enroll computer certificates and user certificates. For more information, see Deploying Certificates for PEAP and EAP.
When you are administering a NPS server remotely, do not send sensitive or confidential data (for example, shared secrets or passwords) over the network in plaintext. There are two recommended methods for remote administration of NPS servers:
Use Terminal Services to access the NPS server.
When you use Terminal Services, data is not sent between client and server. Only the user interface of the server (for example, the operating system desktop and NPS console image) is sent to the Terminal Services client, which is named Remote Desktop Connection in Windows XP and Windows Vista®. The client sends keyboard and mouse input, which is processed locally by the server that has Terminal Services enabled. When Terminal Services users log on, they can view only their individual client sessions, which are managed by the server and are independent of each other. In addition, Remote Desktop Connection provides 128-bit encryption between client and server.
Use Internet Protocol security (IPsec) to encrypt confidential data.
You can use IPsec to encrypt communication between the NPS server and the remote client computer that is being used to administer it. To administer the server remotely, the Windows Server Administration Tools Pack must be installed on the client computer, and the NPS snap-in must be added to the Microsoft Management Console (MMC).
Your NPS server provides authentication, authorization, and accounting for connection attempts to your organization network. You can protect your NPS server and RADIUS messages from unwanted internal and external intrusion.
There are two types of accounting, or logging, in NPS:
Event logging for NPS. You can use event logging to record NPS events in the system and security event logs. This is used primarily for auditing and troubleshooting connection attempts.
Logging user authentication and accounting requests. You can log user authentication and accounting requests to log files in text format or database format, or you can log to a stored procedure in a SQL Server 2000 database. Request logging is used primarily for connection analysis and billing purposes, and is also useful as a security investigation tool, providing you with a method of tracking down the activity an attacker.
To make the most effective use of NPS logging:
Turn on logging (initially) for both authentication and accounting records. Modify these selections after you have determined what is appropriate for your environment.
Ensure that event logging is configured with a capacity that is sufficient to maintain your logs.
Back up all log files on a regular basis because they cannot be re-created when they are damaged or deleted.
Use the RADIUS Class attribute to both track usage and simplify the identification of which department or user to charge for usage. Although the automatically generated Class attribute is unique for each request, duplicate records might exist in cases where the reply to the access server is lost and the request is resent. You might need to delete duplicate requests from your logs to accurately track usage.
To provide failover and redundancy with SQL Server logging, place two computers running SQL Server on different subnets. Use the SQL Server Create Publication Wizard to set up database replication between the two servers. For more information, see SQL Server documentation.
For more information, see RADIUS Accounting.
To optimize NPS authentication and authorization response times and minimize network traffic, install NPS on a domain controller.
When universal principal names (UPNs) or Windows Server 2008 and Windows Server 2003 domains are used, NPS uses the global catalog to authenticate users. To minimize the time it takes to do this, install NPS on either a global catalog server or a server that is on the same subnet.
When you have remote RADIUS server groups configured and, in NPS Connection Request Policies, you clear the Record accounting information on the servers in the following remote RADIUS server group check box, these groups are still sent network access server (NAS) start and stop notification messages. This creates unnecessary network traffic. To eliminate this traffic, disable NAS notification forwarding for individual servers in each remote RADIUS server group by clearing the Forward network start and stop notifications to this server check box.
Using NPS in large organizations
If you are using remote access policies to restrict access for all but certain groups, create a universal group for all of the users for whom you want to allow access, and then create a remote access policy that grants access for this universal group. Do not put all of your users directly into the universal group, especially if you have a large number of them on your network. Instead, create separate groups that are members of the universal group, and add users to those groups.
Use a user principal name to refer to users whenever possible. A user can have the same user principal name regardless of domain membership. This practice provides scalability that might be required in organizations with a large number of domains.
If the NPS server is on a computer other than a domain controller and it is receiving a very large number of authentication requests per second, you can improve performance by increasing the number of concurrent authentications between the NPS server and the domain controller.
To do this, edit the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. Add a new value named MaxConcurrentApi and assign to it a value from 2 through 5. If you assign a value to MaxConcurrentApi that is too high, your NPS server might place an excessive load on your domain controller.
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.
To effectively balance the load of either a large number of authorizations or a large volume of RADIUS authentication traffic (such as a large wireless implementation using certificate-based authentication), install NPS as a RADIUS server on all of your domain controllers. Next, configure two or more NPS proxies to forward the authentication requests between the access servers and the RADIUS servers. Next, configure your access servers to use the NPS proxies as RADIUS servers.