Security information for IAS

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Security information for IAS

It is important to follow best practices for security when using IAS servers on your network. For more information, see Best practices for security.

Following is security information for IAS 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-EAP-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.

• The 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 use of the MD5 hashing algorithm to encrypt the User-Password and other attributes, such as Tunnel-Password and MS-CHAP-MPPE-Keys. RFC 2865 notes the potential need for evaluating the threat environment and determining whether additional security should be used.

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

  Recommendations:

  • Use IPSec to provide additional security for RADIUS clients and servers. For more information, see Securing 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 Message Authenticator attribute and Configure the Message Authenticator attribute and shared secret.

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 IAS server and your RADIUS clients from dictionary attacks. For more information, see Shared secrets.

• 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 Level Security (EAP-TLS) when used in conjunction with smart cards. However, EAP-TLS and smart cards require a public key infrastructure (PKI), which can be complicated to deploy.

  Recommendations:

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

  • Make sure that Password Authentication Protocol (PAP), Shiva Password Authentication Protocol (SPAP), and Challenge Handshake Authentication Protocol (CHAP) are disabled. PAP, SPAP, and CHAP are disabled by default on the profile of a remote access policy.

  • Disable Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). MS-CHAP is enabled by default on the profile of a remote access 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 not running Windows Server 2003 , you will need the latest service packs and dial-up networking updates in order to support MS-CHAP v2.

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

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

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy

    Caution

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

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

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

  Recommendations:

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

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

    Caution

  • Incorrectly editing the registry may 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 problems are encountered after manual changes have been applied.

  Notes

  • Remote access account lockout is not related to the Account locked out setting on the Account tab in the properties of a user account.

  • 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 mistyped their current passwords. Depending on the number of attempts and the MaxDenials setting in the registry, these users might have their accounts locked out.

• Moving IAS log files from the default location results in unprotected log files.

  When IAS logging is enabled, log files are located by default in the systemroot\System32\LogFiles folder. By default, the access control list on the LogFiles folder provides the best security for the IAS log files. The access control list is a list of users and groups that can access the folder. In addition, each user or group is assigned specific permissions that determine what actions the user or group can take with the folder. For more information, see Access Control.

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

  Recommendations:

  • If you move the IAS log files to another folder, create an access control list 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 IAS log files in any personal folders, in My Documents, or in any subfolder of My Documents.

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

  • Use file-level auditing for individual IAS log files to track the users and groups that access them. For more information, see Apply or modify auditing policy settings for a local file or folder.

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

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

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

  Recommendations:

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

  For more information about logging IAS data to a SQL Server database, see SQL Server database logging and Configure log file properties.

For additional information about security considerations and best practices, consult the following resources:

• Securing IAS

• IAS as a RADIUS server security considerations

• IAS Best Practices

• IAS as a RADIUS proxy security considerations

• Remote Access Logging

• Event Viewer

• Security issues for VPN

• Security information for remote access

• Security information for routing

Note

• You can configure IAS in Windows Server 2003, Standard Edition, with a maximum of 50 RADIUS clients and a maximum of 2 remote RADIUS server groups. You can define a RADIUS client 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 IAS server uses the first IP address returned in the DNS query. With IAS in Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, 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.