Elements of Secure Remote Access

Article
09/11/2008

Because remote access is designed to transparently connect a remote access client to a network and its potentially sensitive data, security of remote access connections is an important consideration. Windows 2000 remote access offers a wide range of security features including secure user authentication, mutual authentication, data encryption, callback, and caller ID.

Secure User Authentication

Secure user authentication is obtained through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using either the Extensible Authentication Protocol (EAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 1 and version 2, Challenge Handshake Authentication Protocol (CHAP), or Shiva Password Authentication Protocol (SPAP) authentication protocols. The remote access server can be configured to require a secure authentication method. If the remote access client cannot perform the required secure authentication, the connection is denied.

Mutual Authentication

Mutual authentication is obtained by authenticating both ends of the connection through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using either the EAP-Transport Level Security (EAP-TLS) or MS-CHAP version 2 authentication protocols. During mutual authentication, the remote access client authenticates itself to the remote access server, and then the remote access server authenticates itself to the remote access client.

It is possible for a remote access server to not request authentication from the remote access client. However, in the case of a Windows 2000 remote access client configured for only MS-CHAP version 2 or only EAP-TLS, the remote access client will force the mutual authentication of the client and server. If the remote access server does not respond to the authentication request, the connection is terminated by the client.

Data Encryption

Data encryption encrypts the data sent between the remote access client and the remote access server. Remote access data encryption only provides data encryption on the communications link between the remote access client and the remote access server. If end-to-end encryption is needed, use IPSec to create an encrypted end-to-end connection after the remote access connection has been made.

note-icon

Note

IPSec can also be used for encrypting a Layer Two Tunneling Protocol (L2TP) virtual private network connection. For more information, see "Virtual Private Networking" in this book.

Data encryption on a remote access connection is based on a secret encryption key known to the remote access server and remote access client. This shared secret key is generated during the user authentication process.

Data encryption is possible over dial-up remote access links when using the PPP remote access protocol and the EAP-TLS or MS-CHAP authentication protocols. The remote access server can be configured to require data encryption. If the remote access client cannot perform the required encryption, the connection attempt is rejected.

Windows 2000, Microsoft® Windows NT® 4.0, Windows 98, and Windows 95 remote access clients and remote access servers support the Microsoft Point-to-Point Encryption Protocol (MPPE). MPPE uses the Rivest-Shamir-Adleman (RSA) RC4 stream cipher and either 40-bit, 56-bit, or 128-bit secret keys. MPPE keys are generated from the MS-CHAP and EAP-TLS user authentication process.

Callback

With callback, the remote access server calls the remote access client after the user credentials have been verified. Callback can be configured on the server to call the remote access client back at a number specified by the user of the remote access client during the time of the call. This allows a traveling user to dial-in and have the remote access server call them back at their current location, saving phone charges. Callback can also be configured to always call the remote access client back at a specific location, which is the secure form of callback.

Caller-ID

Caller-ID can be used to verify that the incoming call is coming from a specified phone number. Caller-ID is configured as part of the dial-in properties of the user account. If the Caller-ID number of the incoming connection for that user does not match the configured Caller-ID, the connection is denied.

Caller-ID requires that the caller's phone line, the phone system, the remote access server's phone line, and the Windows 2000 driver for the dial-up equipment all support Caller-ID. If a Caller-ID is configured for a user account and the Caller-ID is not being passed from the caller to the Routing and Remote Access service, then the connection is denied.

Caller-ID is a feature designed to provide a higher degree of security for network that support telecommuters. The disadvantage of configuring Caller-ID is that the user can only dial-in from a single phone line.

Remote Access Account Lockout

The remote access account lockout feature is used to specify how many times an remote access authentication fails against a valid user account before the user is denied remote access. Remote 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 intranet by sending credentials (valid user name, 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. With remote access account lockout enabled, a dictionary attack is thwarted after a specified number of failed attempts.

The remote access 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, may have their accounts locked out.

If you enable the remote access 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.

As the network administrator, you must decide on two remote access 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, 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 does not accumulate beyond a successful authentication.
How often the failed attempts counter is reset.
You must periodically reset the failed attempts counter to prevent inadvertent lockouts due to normal mistakes by users when typing in their passwords.

Remote access account lockout feature is configured 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 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \RemoteAccess\Parameters\AccountLockout) to 1 or greater. MaxDenials is the maximum number of failed attempts before the account is locked out. By default, MaxDenials is set to 0, 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 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \RemoteAccess\Parameters\AccountLockout) to the required number of minutes. By default, ResetTime (mins) is set to 0xb40, or 2,880 minutes (48 hours).

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