Security

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.

Data Encryption

Data encryption converts data sent between the remote access client and the remote access server into a form that is unreadable to eavesdroppers. 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

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 the Windows 2000  Internetworking Guide .

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 processes.

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 callers phone line, the phone system, the remote access servers 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 a 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, might 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.

Remote access account lockout variables include the following:

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

The 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 Remote Authentication Dial-In User Service (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 users account name:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\domain name: user name

Note

The remote access account lockout feature is not related to the Account locked out setting on the Account tab on the properties of a user account and the administration of account lockout policies using Windows 2000 group policies.

For information about how to establish secure remote access connections or for more information about VPN connections, see Windows 2000 Professional Help.

Remote Access Tunneling Protocols

Windows 2000 uses the Point-to-Point Tunneling Protocol (PPTP), Layer Two Tunneling Protocol (L2TP), and Internet Protocol security (IPSec) to create VPNs. For more detailed information about VPNs and their protocols, see the Microsoft Windows 2000 Server Resource Kit Internetworking Guide .

PPTP

The ** Point-to-Point Tunneling Protocol (PPTP) encapsulates Point-to-Point Protocol (PPP) frames into IP datagrams for transmission over an IP-based internetwork, such as the Internet or a private intranet. PPTP is documented in RFC 2637.

The PPTP uses a TCP connection known as the PPTP control connection to create, maintain, and terminate the tunnel and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames as tunneled data. The contents of the encapsulated PPP frames can be encrypted or compressed or both.

PPTP assumes the availability of an IP internetwork between a PPTP client (a VPN client using the PPTP tunneling protocol) and a PPTP server (a VPN server using the PPTP tunneling protocol). The PPTP client might already be attached to an IP internetwork that can reach the PPTP server, or the PPTP client might have to dial into a network access server (NAS) to establish IP connectivity as in the case of dial-up Internet users.

Authentication that occurs during the creation of a PPTP-based VPN connection uses the same authentication mechanisms as PPP connections, such as Extensible Authentication Protocol (EAP), Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP), CHAP, Shiva Password Authentication Protocol (SPAP), and Password Authentication Protocol (PAP). PPTP inherits encryption or compression, or both, of PPP payloads from PPP. For Windows 2000, either EAP-Transport Level Security (EAP-TLS) or MS-CHAP must be used in order for the PPP payloads to be encrypted using Microsoft Point-to-Point Encryption (MPPE).

MPPE provides only link encryption, not end-to-end encryption. End-to-end encryption is data encryption between the client application and the server hosting the resource or service being accessed by the client application. If end-to-end encryption is required, IPSec can be used to encrypt IP traffic from end-to-end after the PPTP tunnel is established.

L2TP

Layer Two Tunneling Protocol (L2TP) is a combination of PPTP and Layer 2 Forwarding (L2F), a technology proposed by Cisco Systems, Inc. Rather than having two incompatible tunneling protocols competing in the marketplace and causing customer confusion, the Internet Engineering Task Force (IETF) mandated that the two technologies be combined into a single tunneling protocol that represents the best features of PPTP and L2F. L2TP is documented in RFC 2661.

L2TP encapsulates PPP frames to be sent over IP, X.25, Frame Relay, or ATM networks. Currently, only L2TP over IP networks is defined. When sent over an IP internetwork, L2TP frames are encapsulated as User Datagram Protocol (UDP) messages. L2TP can be used as a tunneling protocol over the Internet or over private intranets.

L2TP assumes the availability of an IP internetwork between a L2TP client (a VPN client using the L2TP tunneling protocol and IPSec) and a L2TP server (a VPN server using the L2TP tunneling protocol and IPSec). The L2TP client might already be attached to an IP internetwork that can reach the L2TP server, or the L2TP client might have to dial into a NAS to establish IP connectivity as in the case of dial-up Internet users.

Authentication that occurs during the creation of L2TP tunnels must use the same authentication mechanisms as PPP connections such as EAP, MS-CHAP, CHAP, SPAP, and PAP.

For Internet-based L2TP servers, the L2TP server is an L2TP-enabled dial-up server with one interface on the external network, the Internet, and a second interface on the target private network.