Security Information for NPS

Applies To: Windows Server 2008

Security information for NPS

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

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

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

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

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

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


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

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

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

  2. Use cryptographically strong Request Authenticators.

  3. Require the use of strong user passwords.

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

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

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

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


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

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

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

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

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



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

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

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


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



Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.

Additional information
  • Remote access account lockout is not related to the Account locked out setting on the Account tab in the properties of a user account in Active Directory Domain Services (AD DS).

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

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

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

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


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

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

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

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

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

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

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


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

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