Security and IAS
On This Page
This section discusses security issues to consider when deploying IAS.
Secure Authentication Methods
The mixture of access server clients in your network determines the authentication methods that you must use. Most access server clients use some form of password-based authentication. Password-based authentications are inherently weak and are subject to dictionary attacks. Dictionary attacks can be made more difficult by imposing strong password policies on your network. A strong password is a long password that contains a mixture of upper and lower-case letters, numbers, and punctuation. The most secure method of authentication is EAP-TLS, when used in conjunction with smart cards. However, EAP-TLS and smart cards require a public key infrastructure (PKI).
To use the most secure authentication methods, perform the following as needed:
Disable PAP and SPAP. Both PAP and SPAP are disabled by default on the profile of a remote access policy.
Disable CHAP. CHAP is disabled by default on the profile of a remote access policy.
Disable LAN Manager authentication for MS-CHAP v1. LAN Manager authentication for MS-CHAP v1 is enabled by default for older Microsoft access server clients. Set the registry value Allow LM Authentication (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\RemoteAccess\Policy) to 0 on the IAS server.
Disable MS-CHAP v1. MS-CHAP v1 is enabled by default on the profile of a remote access policy. Before disabling MS-CHAP v1, ensure that all of your access server clients are capable of using MS-CHAP v2. Previous versions of Windows, such as Windows 95 or Windows NT 4.0, require the latest service packs and dial-up networking updates.
Enable MS-CHAP v2. MS-CHAP v2 is enabled by default on the profile of a remote access policy.
Enable EAP-TLS. EAP-TLS is not enabled by default on the profile of a remote access policy. You must enable it and configure which computer certificate is used during the EAP-TLS negotiation.
A shared secret is a password used between a RADIUS server and a RADIUS client to mutually verify identity. Both the RADIUS server and the RADIUS client must be configured with the same shared secret for successful communication to occur. The shared secret can be up to 128 bytes long, is case-sensitive, and can contain alphanumeric and special characters. To protect your RADIUS communications from dictionary and denial-of-service attacks, make the shared secrets a long (more than 16 characters) sequence of random letters, numbers, and punctuation marks.
When you configure IAS for a RADIUS client, you configure the IP address of the RADIUS client. If an incoming RADIUS message does not originate from at least one of the IP addresses of the configured RADIUS clients, then IAS automatically discards the message, providing protection for an IAS server. However, source IP addresses can be spoofed (substituted).
To provide protection from spoofed RADIUS messages and RADIUS message tampering, each RADIUS message can be further protected by including the RADIUS signature attribute, referred to as the Message-Authenticator attribute and described in the Internet draft “RADIUS Extensions.”
The contents of the RADIUS Message-Authenticator attribute are an MD-5 hash of the entire RADIUS message using the shared secret as a key. If the RADIUS Message-Authenticator attribute is present, it is verified. If it fails verification, the RADIUS message is discarded. If the client settings require the Message-Authenticator attribute and it is not present, the RADIUS message is discarded.
A RADIUS proxy can be used to provide cross-forest authentication. The use of the PAP authentication protocol in conjunction with a RADIUS proxy is highly discouraged. PAP provides for the plaintext passing a user password between the PPP client and the NAS (the RADIUS client). Between the NAS and the RADIUS proxy, the PAP password is encrypted using the shared secret of the NAS and the RADIUS proxy. However, in order to forward the Access-Request to the appropriate RADIUS server that is providing authentication, the user’s password must be decrypted and then re-encrypted using the shared secret of the RADIUS proxy and the RADIUS server that is providing authentication. While the user’s password is decrypted, it exists in plaintext form. It is possible for a malicious process on a RADIUS proxy to record user passwords while they are in decrypted form, compromising the security of user credentials.
A firewall is a router or a computer deployed between the Internet and a perimeter network (also called a demilitarized zone or DMZ), which is a network segment that contains computers that can be directly accessed from the Internet. The firewall is designed to provide protection for the computers on the perimeter network by filtering the traffic between them and the Internet.
If you use a firewall and one of the private computers on the perimeter network is an IAS server, you must configure the firewall with packet filters to allow RADIUS traffic between the IAS server and the Internet.
For example, if the IAS server on the perimeter network is using the public IP address of 126.96.36.199 and UDP ports 1812 (for RADIUS authentication) and 1813 (for RADIUS accounting), you should configure the firewall with packet filters that allow the following IAS traffic:
Traffic from the Internet to the perimeter network
To the destination of 188.8.131.52 and with a UDP destination port of 1812
To the destination of 184.108.40.206 and with a UDP destination port of 1813
Traffic from the perimeter network to the Internet
From the source of 220.127.116.11 and with a UDP source port of 1812
From the source of 18.104.22.168 and with a UDP source port of 1813
Note that these filters do not specify the inbound source or outbound destinations corresponding to the RADIUS clients on the Internet. You can create more specific filters that allow RADIUS traffic from your RADIUS clients only; however, this requires two filters (one for inbound traffic and one for outbound) for each RADIUS client on the Internet.
Remote Access Account Lockout
You can use the account-lockout feature to specify the number of times a PPP authentication fails against a valid user account before the user is denied access. Account lockout is especially important for remote access virtual private network (VPN) connections over the Internet. Malicious users on the Internet can attempt to access an organization’s intranet by sending credentials (valid user name and guessed password) during the VPN connection authentication process. During a dictionary attack, the malicious user sends hundreds or thousands of credentials by using a list of passwords based on common words or phrases.
When account lockout is enabled, a dictionary attack is thwarted after a specified number of failed attempts. As the network administrator, you must decide between two account lockout variables:
The number of failed attempts before future attempts are denied
After each failed attempt, a failed-attempts counter for the user account is incremented. If the user account's failed attempts counter reaches the configured maximum, then future attempts to connect are denied.
A successful authentication resets the failed-attempts counter when its value is less than the configured maximum. In other words, the failed-attempts counter resets to zero after a successful authentication.
How often the failed-attempts counter is reset
The failed-attempts counter is periodically reset to zero. If an account is locked out after the maximum number of failed attempts, the failed attempts counter is automatically reset to zero after the reset time.
You enable the account-lockout feature by changing settings in the Windows 2000 registry on the computer that provides the authentication. If the remote access server is configured for Windows authentication, modify the registry on the remote access server computer. If the remote access server is configured for RADIUS authentication and Windows 2000 Internet Authentication Service (IAS) is being used, modify the registry on the IAS server computer.
To enable account lockout, you must set the MaxDenials entry in the registry to one or greater. MaxDenials is the maximum number of failed attempts before the account is locked out. You can set the MaxDenials entry in the following registry subkey:
By default, MaxDenials is set to zero, which means that account lockout is disabled.
To modify the amount of time before the failed attempts counter is reset, you must set the ResetTime (mins) entry in the registry to the required number of minutes. You can set the ResetTime (mins) entry in the following registry subkey:
By default, ResetTime (mins) is set to a hexadecimal value of 0xb40, or 2,880 minutes (48 hours).
Manually Resetting an Account That Is Locked Out
In order to manually reset a user account that has been locked out before the failed attempts counter is automatically reset, delete the following registry subkey that corresponds to the user's account name:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\domain name:user name
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.
Notes: The remote access account lockout is not related to the Account locked out setting on the Account tab on the properties of a user account.
The account-lockout feature does not distinguish between malicious users who attempt to access your intranet and authentic users who attempt remote access but have forgotten their current passwords. Users who have forgotten their current password typically try the passwords that they remember and, depending on the number of attempts and the MaxDenials setting, might have their accounts locked out.
If you enable the account-lockout feature, a malicious user can deliberately force an account to be locked out by attempting multiple authentications with the user account until the account is locked out, thereby preventing the authentic user from being able to log on.