Share via

IAS as a RADIUS server security considerations

  • Article

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

IAS as a RADIUS server security considerations

Consider the following security issues when deploying IAS as a RADIUS server:

  • Shared secrets

    Configure strong shared secrets and change them frequently to prevent dictionary attacks. Strong shared secrets are a long (more than 22 characters) sequence of random letters, numbers, and punctuation. For more information, see Shared secrets.

  • Message Authenticator attribute

    To ensure that an incoming RADIUS Access-Request message, for connection requests that use the PAP, CHAP, MS-CHAP, and MS-CHAP v2 authentication protocols, was sent from a RADIUS client configured with the correct shared secret, you can use the RADIUS Message Authenticator attribute (also known as a digital signature or the signature attribute). You must enable the use of the Message Authenticator attribute on both the IAS server (as part of the configuration of the RADIUS client in Internet Authentication Service) and the RADIUS client (the access server or RADIUS proxy). Ensure that the RADIUS client supports the Message Authenticator attribute before enabling it. The Message Authenticator attribute is always used with EAP without having to enable it on the IAS server and access server. For more information, see Edit RADIUS client configuration.

    For information about enabling the RADIUS Message Authenticator attribute for your access server, see the appropriate access server documentation. For the Routing and Remote Access service, the use of the RADIUS Message Authenticator attribute is enabled from the properties of a RADIUS server when you configure the RADIUS authentication provider. For more information, see Use RADIUS authentication.

  • Firewall configuration

    If your IAS server is on a perimeter network (also known as a demilitarized zone or DMZ), configure your Internet firewall (between your perimeter network and the Internet) to allow RADIUS messages to pass between your IAS server and RADIUS clients on the Internet. You might need to configure an additional firewall that is placed between your perimeter network and your intranet, to allow traffic to flow between the IAS server on the perimeter network and domain controllers on the intranet. For more information, see IAS and firewalls.

  • Authentication protocols

    IAS supports several different authentication protocols. The order of authentication protocols, from the most secure to the least secure, is: PEAP-EAP-TLS (for wireless clients and authenticated switch clients only), EAP-TLS, PEAP-EAP-MS-CHAPv2 (for wireless clients and authenticated switch clients only), MS-CHAP v2, MS-CHAP, EAP-MD5, CHAP, and PAP. Microsoft recommends using only the strongest authentication protocols required for your configuration. For password-based authentication protocols, strong password policies must be enforced to protect from dictionary attacks. The use of PAP is not recommended unless it is required. For more information, see Authentication methods.

  • Remote access account lockout

    To provide protection for online dictionary attacks launched against access servers by using known user names, you can enable remote access account lockout. Remote access account lockout disables remote access for user accounts after a configured number of failed connection attempts has been reached. For more information, see Remote access account lockout.

    Remote access account lockout can also be used to prevent a malicious user from intentionally locking out a domain account by attempting multiple dial-up or VPN connections with the wrong password. You can set the number of failed attempts for remote access account lockout to a number that is lower than the logon retries for domain account lockout. By doing this, remote access account lockout occurs before domain account lockout, which prevents the domain account from being intentionally locked out.

  • Certificate-based authentication

    When you use the EAP-TLS authentication protocol, you must install a computer certificate on the IAS server. For client and user authentication, you can either install a certificate on the client computer or use smart cards. Before certificate enrollment occurs, the certificate must be designed with the correct requirements and purposes. For more information, see Network access authentication and certificates and Computer certificates for certificate-based authentication.

  • Authentication of wireless clients using Protected Extensible Authentication Protocol (PEAP)

    You can use PEAP with EAP-TLS (also known as PEAP-EAP-TLS) to deploy a certificates with PEAP. PEAP with EAP-MS-CHAPv2 (also known as PEAP-EAP-MS-CHAPv2) provides secure password authentication. PEAP-EAP-TLS uses a public key infrastructure (PKI) with certificates for server authentication and either smart cards or certificates for client and user authentication. When you use PEAP-EAP-TLS, client certificate information is encrypted.

    Although using PEAP-EAP-TLS with smart cards for certificate deployment is the most secure authentication method, the complexity and cost of deploying certificates to wireless and authenticated switch clients might not be practical for your organization. PEAP-EAP-MS-CHAPv2 balances security with deployment cost and complexity. Unlike MS-CHAPv2, PEAP-EAP-MS-CHAPv2 is a mutual authentication method that uses Transport Level Security (TLS) to create an end-to-end encrypted connection between client and authenticator. The client authenticates the server by using the server's certificate and the server authenticates the client with password-based credentials. For an example of a remote access policy using PEAP, see Wireless access with secure password authentication.

  • Registration of the IAS server in Active Directory

    Before the IAS server can access Active Directory domains to authenticate user credentials and user access account properties, the IAS server must be registered in those domains. For more information, see Enable the IAS server to read user accounts in Active Directory.

  • Using IPSec filters to lock down IAS servers

    You can configure IPSec filters on a granular level to allow specific traffic in and out of network interfaces on RADIUS servers. These filters can be applied to organizational units and stored in Active Directory, or they can be created and applied to individual servers. For more information, see Securing RADIUS traffic with IPSec.

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.