Dela via

Best Practices for NPS

  • Artikel

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

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

Installation

Before installing NPS, do the following:

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

  • After you install and configure NPS, save the configuration by using the netsh nps export command. Use this command to save the NPS configuration to an XML file every time a configuration change is made.

  • If you install additional Extensible Authentication Protocol (EAP) types on your NPS server, ensure that you document the server configuration in case you need to rebuild the server or duplicate the configuration on other NPS servers.

  • If you install additional system health validators (SHVs) on your NPS server, ensure that you document the server configuration in case you need to rebuild the server or duplicate the configuration on other NPS servers.

  • Do not install Windows Server 2008 on the same partition with another version of Windows Server.

  • Do not configure a server running NPS or the Routing and Remote Access service as a member of a Windows NT Server 4.0 domain if your user accounts database is stored on a domain controller running Windows Server 2008 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 domain. An alternative is to configure a server running NPS as a RADIUS proxy server that forwards authentication and accounting requests from the Windows NT Server 4.0 domain to an NPS server in the Windows Server 2008 domain.

Client computer configuration

Following are the best practices for client computer configuration:

  • Automatically configure all of your domain member 802.1X client computers by using Group Policy.

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

Authentication

Following are the best practices for authentication:

  • Use authentication methods, such as Protected Extensible Authentication Protocol (PEAP) and Extensible Authentication Protocol (EAP), that provide authentication types, such as Transport Layer Security (EAP-TLS and PEAP-TLS) and Microsoft Challenge Handshake Authentication Protocol version two (PEAP-MS-CHAP v2), that support the use of certificates for strong authentication. Do not use password-based authentication methods because they are vulnerable to a variety of attacks and are not secure.

  • Use PEAP, which is required for all Network Access Protection (NAP) enforcement methods. Determine the PEAP authentication types that you want to use, such as PEAP-TLS and PEAP-MS-CHAP v2, and then plan and deploy your public key infrastructure (PKI) to ensure that all computers and users can enroll the certificates required by the authentication types.

  • Deploy a certification authority (CA) by using Active Directory® Certificate Services (AD CS) if you use strong certificate-based authentication methods that require the use of a server certificate on NPS servers. You can also use your CA to deploy computer certificates to domain member computers and user certificates to members of the Users group in Active Directory.

Security issues

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.

When you are administering an 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 Remote Desktop Connection to access the NPS server.

    When Remote Desktop Connection 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.

    If you manage one or more remote NPS servers from a local NPS server by using the NPS Microsoft Management Console (MMC) snap-in, you can use IPsec to encrypt communication between the local NPS server and the remote NPS server.

Accounting

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

  • Event logging for NPS. You can use event logging to record NPS events in the system and security event logs. Recording NPS events to the security event log is a new feature in Windows Server 2008, and much more information is logged for NPS than in previous operating system versions for Internet Authentication Service (IAS). This information 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, SQL Server 2005, or SQL Server 2008 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 activity after an attack.

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 recreated after they are damaged or deleted.

  • For billing purposes, 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 when 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.

  • If you use SQL Server logging, ensure that you store credentials and other connection properties in a secure location. This information is not exported to file when you use the netsh nps export command.

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

Important

If your NPS server is configured to log accounting data but cannot write to the configured data store (a log file, a SQL Server database, or both), NPS discards all connection requests and authentication fails. In this circumstance, users cannot access the network by using connections through RADIUS clients. This ensures that accounting data is accurate.

Optimizing NPS

Following are ways to tune NPS performance:

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

  • Disable start and stop notification forwarding from network access servers (NASs) to individual servers in each remote RADIUS server group if you are not forwarding accounting requests to the group. For more information, see Disable NAS Notification Forwarding.

Using NPS in large organizations

Following are ways to use NPS in large organizations:

  • If you are using network policies to restrict network access for all but specific groups, create a universal group for all of the users for whom you want to allow access, and then create a network policy that grants access for members of 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 then add users to those groups.

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

  • If NPS 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 NPS and the domain controller. For more information, see Increase the Number of NPS Concurrent Authentications.

Note

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

Network Access Protection (NAP)

When NAP is deployed, NPS acts as a NAP policy server, performing client health checks against configured health policies. 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 Internet Protocol security (IPsec), 802.1X, and virtual private network (VPN) enforcement methods. Strong enforcement methods use certificate-based authentication and secure the channel between clients and servers through which the statement of health (SoH) and statement of health response (SoHR) are sent. The DHCP enforcement method is the least secure enforcement method and should be deployed only in circumstances where secure transmission of the SoH and SoHR are not required.

  • When you deploy the IPsec enforcement method, enable pass-through authentication in Internet Information Services (IIS). Enabling pass-through authentication ensures that only domain member computers can obtain a health certificate and communicate with other domain member computers.

  • 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 corresponding system health validators (SHVs) for the SHAs on NPS servers.

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

  • 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 by using the wizard, open the policy in the NPS console and make required changes.

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

  • To deploy NAP with the DHCP enforcement method, you must install both NPS and DHCP on the same computer.