Lesson 1: Planning Remote Access Security | MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)

Allowing remote access to your network enables your organization's employees to access corporate information from anywhere in the world. It empowers users in remote offices to access valuable network resources as if they were in the main office. However, allowing remote access introduces an entirely new set of security risks. Your job as a security professional is to configure dial-up and VPN connections so that they allow only carefully defined traffic to flow between offices and users without exposing sensitive data or granting unauthorized access.

After this lesson, you will be able to

Plan the components involved in remote access security

Estimated lesson time: 30 minutes

Choosing Between Dial-Up and VPN Solutions

Windows 2000 offers two methods for remote users to connect to the local network: dial-up remote access, where the user connects to the network by using a modem, or VPN, where the user connects through a tunnel that's running over an existing network connection. The existing network connection may be the local network or an Internet connection.

Dial-up connections offer access to the greatest number of users because the client requires only a modem and a phone number to connect to a remote access server. The client connects to the remote access server over the Public Switched Telephone Network (PSTN) and establishes a virtual circuit to a listening port on the remote access server, as shown in Figure 13.2.

click to view at full size.

Figure 13.2 Remote access over a PSTN

In addition to the virtual circuit, the client and server negotiate link control protocol (LCP) parameters that define the authentication protocol and other connection parameters.

Dial-up access is most often used when the dial-up connections are to local phone numbers or toll-free numbers. Dial-up connections are also used to initially access the Internet when establishing VPN connections.

An existing Internet Protocol (IP) connection must exist before you can establish a VPN. The VPN client connects to a listening Transmission Control Protocol (TCP) port on the remote access server using a tunneling protocol such as L2TP or PPTP, as shown in Figure 13.3.

click to view at full size.

Figure 13.3 Remote access over a VPN

The figure shows that the VPN connection (item 2) requires an existing connection to an IP network (item 1). The connection could be either a dedicated connection, such as a T1 link at the office, or a dial-up connection to an Internet Service Provider (ISP) by the remote access client.

VPN access is commonly implemented to reduce the costs associated with support modem pools for an organization and the long distance costs associated with remote employees.

Making the Decision

Table 13.1 shows important factors you should consider when choosing between a dial-up or VPN solution for remote access to a network.

Table 13.1 Choosing Between Dial-Up and VPN Access

Use	Under the Following Circumstances
Dial-up access	Your organization maintains an existing modem pool. Most remote connections to the network are through local access numbers and don't require long distance or toll-free charges. Your organization requires an alternative connection method between offices if a dedicated network link fails.
VPN access	Your organization wants to outsource modem support to an ISP. Users have existing Internet access. Your organization wants to reduce the costs associated with long distance and toll-free numbers. Your organization requires faster access speeds than are possible with dial-up networking solutions.

Use

Under the Following Circumstances

Dial-up access

Your organization maintains an existing modem pool.

Most remote connections to the network are through local access numbers and don't require long distance or toll-free charges.

Your organization requires an alternative connection method between offices if a dedicated network link fails.

VPN access

Your organization wants to outsource modem support to an ISP.

Users have existing Internet access.

Your organization wants to reduce the costs associated with long distance and toll-free numbers.

Your organization requires faster access speeds than are possible with dial-up networking solutions.

Applying the Decision

Hanson Brothers requires a combination of dial-up and VPN support for the scenarios presented in this chapter's case study.

Hanson Brothers will provide both dial-up and VPN access to their employees. Providing both forms of access ensures that users with modems and users with high-speed Internet connections can connect to their local office.

The computer connecting to the stock application from Adventure Works requires a dial-up connection. A dial-up connection will allow Hanson Brothers to restrict the connection to a specific phone number.

Finally, the new office in Montréal will require a VPN solution to provide connectivity to the corporate office in Warroad. For redundancy, Hanson Brothers could create a demand-dial connection between the two offices that use telephone lines in case either of the ISP connections at the Warroad or Montréal offices are unavailable. The demand-dial connection would be established only if the VPN were unavailable. Packets destined to the other network would initiate the dial-up connection if the VPN were unavailable.

Planning Remote Access Authentication

When a remote user connects to the network, the user must provide credentials to authenticate with the network.

Windows 2000 RRAS supports the following authentication methods:

Password Authentication Protocol (PAP). PAP offers the most flexibility among the authentication protocols because it's supported by almost all dial-up network services. The danger is that PAP sends the user password as a plaintext string. Accordingly, the use of PAP isn't recommended under any circumstances in security-aware networks.
Shiva Password Authentication Protocol (SPAP). SPAP uses a reversible encryption method supported by Shiva remote access servers and Windows 2000 remote access servers. The encryption algorithms are stronger than those used in PAP, but SPAP doesn't provide protection against server impersonation.
Challenge Handshake Authentication Protocol (CHAP). CHAP sends the password and a challenge from the server through a hashing algorithm. The recipient identifies the user, obtains the password from the directory, and performs the same hashing algorithm against the challenge and password. If the results match, the user is authenticated.

IMPORTANT
CHAP authentication requires that the user's password be stored in plaintext or in reversibly encrypted format at the domain controller for comparison purposes. When this attribute is set, the storage of the plaintext password format doesn't take place until the user changes the password after the attribute is enabled.

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). MS-CHAP increases security by dropping the requirement to store the user's password in a plaintext format at the domain controller. MS-CHAP creates the challenge response by passing the challenge and the user's password through the Message Digest v4 (MD4) hashing algorithm rather than the MD5 algorithm. Because the algorithm is well known, MS-CHAP is also vulnerable to dictionary attacks if short passwords or passwords that are found in a dictionary are used. MS-CHAP uses Microsoft Point-to-Point Encryption (MPPE) Protocol to encrypt all data transmitted between the remote access client and the Network Access Server (NAS).
Microsoft Challenge Handshake Authentication Protocol Version 2 (MS-CHAPv2). MS-CHAPv2 improves security by supporting mutual authentication, stronger data encryption keys, and separate encryption keys for sending and receiving data.
Extensible Authentication Protocol (EAP). EAP provides extensions to dial-up and VPN connections. These extensions provide two-factor authentication by using devices such as smart cards to provide network credentials. EAP uses Transport Layer Security (TLS) to secure the authentication process. EAP provides mutual authentication, negotiation of encryption methods, and secured key exchange between the NAS and the remote access client. EAP requires that both the remote access client and the NAS run Windows 2000 and that a Public Key Infrastructure (PKI) is deployed to provide certificates for both the NAS and the remote access clients.

The Advantage of Two-Factor Authentication
Two-factor authentication adds security to the authentication process by requiring two forms of identification when users are authenticating with the network. For example, smart cards require you to have the physical smart card and know the PIN to access the private key on the smart card. If you don't have both the smart card and the PIN, you can't authenticate with the network.

NOTE
The same authentication protocols are available for both dial-up and VPN scenarios.

Making the Decision

When choosing between remote access authentication protocols, consider the desired level of security and the type of remote access clients that your solution must support. Table 13.2 lists the design decisions you need to consider when choosing whether to implement a remote access authentication protocol.

Table 13.2 Choosing Remote Access Authentication Protocols

Use	Under the Following Conditions	Level of Protection
PAP	No other authentication methods are possible for the remote access connection. All connections are dial-up connections. No VPN connections are supported. Remote access clients don't support any other authentication methods.	Low
SPAP	You're using Shiva Remote Access servers as NASs. You don't require strong encryption methods for access.	Low
CHAP	Your organization doesn't consider the storage of passwords in reversible encrypted format on the domain controller a security risk. Remote access clients are a mix of Microsoft and other operating systems.	Medium
MS-CHAP	You don't wish to store passwords in reversible encrypted format. You only need to support Microsoft operating systems for dial-up and VPN connectivity. You require encryption of data between the remote access client and the NAS.	Medium
MS-CHAPv2	You're using Windows 2000– and Windows NT 4.0–based clients for both dial-up and VPN authentication. You're using Windows 95 and Windows 98 clients for VPN authentication only. Your organization requires mutual authentication of the remote access client and the NAS. You require encryption of data between the remote access client and the NAS.	High
EAP-TLS	Your organization wants to implement two-factor authentication for dial-up and VPN access. You're using only Windows 2000 or other operating systems that support smart card authentication. You require encryption of data between the remote access client and the NAS. You have a PKI deployed within your organization. Your organization requires mutual authentication of remote access client and NAS to prevent impersonation of either the user or the NAS.	High

NOTE
If you choose multiple authentication protocol support, the authentication protocol that provides the highest level of security supported by both the NAS and the remote access client will automatically be selected by the initial negotiation process.

Applying the Decision

To provide the strongest form of authentication acceptable to both the remote client and the RRAS server, configure the RRAS server to support MS-CHAP and MS-CHAPv2. While it would be best to support only MS-CHAPv2, Windows 98 clients require MS-CHAP to provide authentication for dial-up connections. Windows 98–based clients only support MS-CHAPv2 for VPN connections. To ensure security, you should enforce strong passwords for all user accounts. Strong passwords help prevent successful dictionary attacks.

Hanson Brothers will implement strong encryption of the user account and password on the remote access connection from Adventure Works. Strong encryption requires you to use MS-CHAPv2 or EAP. Because the Windows NT 4.0 client doesn't support smart card authentication, MS-CHAPv2 is the only authentication protocol that meets this objective.

Because Montréal's third-party firewall won't support PPTP or L2TP/IPSec, IPSec tunnel mode is the only choice for connecting the Montréal office securely to the Warroad office over the Internet. The Montréal office won't be able to implement user authentication for the VPN connection between the offices because IPSec tunnel mode doesn't support user authentication.

Planning Dial-Up Protocols

You must configure remote access clients and NASs to support a dial-up remote access protocol when using dial-up connections. Windows 2000 supports three remote access protocols for dial-up connectivity:

Point-to-Point Protocol (PPP). PPP has the ability to negotiate security requirements between a remote access client and a NAS. PPP offers support for multiple protocols (NetBEUI, IPX/SPX, and TCP/IP) and interoperability with other operating systems.
Serial Line Internet Protocol (SLIP). SLIP is an older dial-up framing protocol that uses plaintext authentication and supports only TCP/IP protocol connections. Because of the use of plaintext authentication, only Windows 2000 remote access clients can use SLIP. RRAS can't use SLIP to authenticate remote access connections.
Asynchronous NetBEUI (AsyBEUI). AsyBEUI, also known as Microsoft RAS protocol, was used by Windows NT 3.1, Windows for Workgroups, MS-DOS, and LAN Manager. Use this protocol only to support these down-level remote access clients.

Making the Decision

Table 13.3 shows the design decisions you need to make for choosing remote access protocols supported by Windows 2000.

Table 13.3 Choosing a Remote Access Protocol

Use	Under the Following Conditions
PPP	You need to deploy remote access services for Windows 95, Windows 98, Windows NT 3.5, Windows NT 3.51, Windows NT 4.0, Windows 2000, and most third-party dialers. You require negotiation of authentication protocols and remote access session characteristics, such as requiring mutual authentication or encryption of transmitted data.
SLIP	Your remote access clients must connect to third-party NAS's that support only SLIP communications.
AsyBEUI	Your organization must support Windows NT 3.1, Windows for Workgroups, MS-DOS, or LAN Manager–based remote access clients.

Applying the Decision

Hanson Brothers will use Windows 2000 RRAS to provide remote user and office connectivity. Because all connecting computers use Windows 98, Windows NT 4.0, or Windows 2000, PPP meets all needs for connectivity.

Because it uses plaintext password transmission, SLIP is supported only for remote access clients. Because there are no UNIX remote access servers involved in the design, you don't need to configure the remote access clients to support SLIP connections. Likewise, there are no Windows NT 3.1, Windows for Workgroups, MS-DOS, or LAN Manager clients. Therefore, you don't need to support AsyBEUI remote access connections.

Planning VPN Protocols

Windows 2000 supports VPN solutions for both client-to-server and network-to-network connectivity. For client-to-server connections, Windows 2000 supports both PPTP and L2TP/IPSec solutions. In addition, Windows 2000 supports IPSec tunnel solutions for providing network-to-network connectivity. The design decisions don't vary for client-to-network and network-to-network scenarios, although network-to-network solutions can include IPSec tunnel mode.

Analyzing VPN Protocol Selections

As mentioned earlier, there are three protocols for VPN connections: PPTP, L2TP/IPSec, and IPSec tunnel mode. The following sections provide an analysis of each VPN protocol choice.

Point to Point Tunneling Protocol (PPTP)

PPTP is supported by Windows 95, Windows 98, Windows NT 4.0, and Windows 2000 remote access clients. Like all VPN protocols, PPTP requires an IP connection to exist before the VPN can be established. PPTP uses MPPE to provide encryption of the transmitted data. MPPE can use 40-bit, 56-bit, or 128-bit encryption keys.

NOTE
MPPE using 128-bit encryption requires the Windows High Encryption Pack to be installed on Windows 2000–based computers. For legacy clients, the strong encryption patch must be installed. Strong encryption is available only to nonembargoed countries.

PPTP is commonly used to meet the following requirements:

If support for down-level clients is needed. Windows 95, Windows 98, and Windows NT 4.0 clients support PPTP only as a VPN protocol.
If the VPN must cross a firewall or perimeter network that performs Network Address Translation (NAT). PPTP is the only VPN protocol that can pass through NAT because the fields modified by the NAT process aren't protected by the MPPE encryption.
If your organization requires the authentication only of the user account, not the machine account. PPTP doesn't support the authentication of the computers used in the remote access connection. If MS-CHAPv2 is used, then the user account and the computer account of the remote access server are authenticated, but the computer account of the remote access client computer isn't authenticated.

What About the Security Weaknesses Related to PPTP?
The original implementation of PPTP used MS-CHAP as the authentication protocol. If a remote access client used weak user passwords, it was possible to determine the password by using a dictionary attack. The latest update to PPTP has added support for MS-CHAPv2 and EAP authentication to reduce the risk of password determination.

Configuring the tunnel server to allow only MS-CHAPv2 or EAP connections reduces the risk of weak passwords being determined by a dictionary attack. If weak passwords are a major concern, ensure that all remote access clients use Windows 2000 and issue smart cards to use EAP authentication.

If PPTP packets must pass through a firewall, you must configure the firewall to allow the PPTP packets to pass through the firewall. PPTP packets have a destination port of TCP port 1723 and use protocol ID 47 (Generic Routing Encapsulation or GRE).

Layer Two Tunneling Protocol over IPSec (L2TP/IPSec)

L2TP is an alternate method of providing VPN access to the network. As with PPTP, you can use L2TP to provide both client-to-server and server-to-server access. L2TP and PPTP have three major differences:

L2TP doesn't include an encryption mechanism. To provide encryption, IPSec is automatically used to negotiate a security association between the two computers using the L2TP tunnel. Unlike other IPSec security associations, the L2TP security association isn't defined in the IPSec configuration for the computer's local policy.
L2TP provides two forms of authentication. L2TP provides user authentication using standard dial-up authentication protocols, including MS-CHAP, MS-CHAPv2, and EAP. In addition, IPSec provides machine authentication.
L2TP can't pass through a firewall or perimeter server performing NAT. NAT modifies the IP address and port information in an IP packet. Because these fields are protected by the IPSec encryption, the packets are discarded at the receiving tunnel server because the contents of the packets are modified. You must place the tunnel server accepting L2TP connections on a network segment where NAT isn't applied to incoming and outgoing packets.

NOTE
L2TP is a proposed Internet standard defined in Request for Comment (RFC) 2661. You can obtain a copy of this RFC by going to http://www.ietf.org/rfc and searching for "RFC 2661."

If L2TP/IPSec packets must pass through a firewall, you must configure the firewall to allow IPSec packets destined to the tunnel server to pass through the firewall. The IPSec packets are destined to UDP port 500 on the tunnel server using IPSec Encapsulating Security Payload (ESP) protocol that is identified by protocol ID 50. You don't configure the firewall to pass L2TP packets (destined to UDP port 1701), because the packets are still encrypted when they pass through the firewall.

IPSec Tunnel Mode

IPSec tunnel mode uses Encapsulated Security Payloads (ESPs) to encrypt all traffic passing between the tunnel endpoints. The original IP packets are encrypted within the IPSec tunnel mode packet as they are transmitted across the unsecured network. The data is decrypted when it reaches the endpoint nearest the destination computer. You must consider the following factors when investigating an IPSec tunnel mode solution for network connectivity:

IPSec tunnel mode is a highly interoperable solution. If you need to provide secure interoffice connectivity with third-party firewalls, routers or gateways that don't support L2TP/IPSec or PPTP VPN tunneling technology, consider deploying IPSec tunnel mode as a VPN solution.
IPSec doesn't provide user authentication of the two endpoints involved in the IPSec tunnel. IPSec tunnel mode only provides machine authentication of the tunnel endpoints.
IPSec tunnel mode doesn't support client-to-network VPN access. IPSec tunnel mode is supported only for network-to-network connectivity.
NOTE
IPSec tunnel mode doesn't provide end-to-end encryption of data. The data is only encrypted as it passes between the tunnel endpoints. You can provide end-to-end encryption by configuring IPSec transport mode to be passed through the IPSec tunnel.
IPSec supports certificate-based authentication, Kerberos, and preshared key authentication for IPSec connections. If the connection is between organizations, consider using a preshared key or certificate-based authentication. Preshared keys are viable provided that you configure security associations to accept only connections from the other tunnel endpoint.
Tunnel server placement can prevent IPSec tunnel mode communications. Don't place the tunnel servers behind firewalls or perimeter servers that perform NAT. You must place the tunnel servers on network segments where NAT doesn't take place for incoming or outgoing packets.

Making the Decision

Table 13.4 shows the design factors you should consider when choosing a VPN protocol.

Table 13.4 Selecting a VPN Protocol

Choose This VPN Protocol	When These Circumstances Exist
PPTP	You require client-to-gateway or network-to-network connectivity. The VPN must pass through a firewall or perimeter server that performs NAT. You require VPN support for legacy Windows clients.
L2TP	You require client-to-gateway or network-to-network connectivity. Computer certificates are deployed to all client computers requiring L2TP connections. You require authentication of the user accounts and authentication of the machine accounts. The tunnel server isn't located behind a firewall or perimeter server performing NAT. You plan to implement an IPSec-protected tunnel with the least amount of configuration.
IPSec tunnel mode	You require only network-to-network connectivity. Only machine authentication is required for the tunnel endpoints. If using certificate-based authentication, the certificates are issued from trusted CAs. If using preshared keys, the IPSec security associations are configured to only allow connections from the tunnel endpoints.

Choose This VPN Protocol

When These Circumstances Exist

PPTP

You require client-to-gateway or network-to-network connectivity.

The VPN must pass through a firewall or perimeter server that performs NAT.

You require VPN support for legacy Windows clients.

L2TP

You require client-to-gateway or network-to-network connectivity.

Computer certificates are deployed to all client computers requiring L2TP connections.

You require authentication of the user accounts and authentication of the machine accounts.

The tunnel server isn't located behind a firewall or perimeter server performing NAT.

You plan to implement an IPSec-protected tunnel with the least amount of configuration.

IPSec tunnel mode

You require only network-to-network connectivity.

Only machine authentication is required for the tunnel endpoints.

If using certificate-based authentication, the certificates are issued from trusted CAs.

If using preshared keys, the IPSec security associations are configured to only allow connections from the tunnel endpoints.

If IPSec tunnel mode packets must pass through a firewall, you must configure the firewall to allow packets destined to UDP port 500 on the tunnel server. An additional packet filter must be added to restrict connections to using ESP packets (protocol ID 50).

Applying the Decision

Figure 13.4 shows how the Montréal office would connect to the Warroad office.

click to view at full size.

Figure 13.4 VPN solution for connecting the Montréal office to the Warroad office

You must configure the external firewall at the Warroad office not to perform NAT. This is required because the third-party firewall at the Montréal office doesn't support PPTP. IPSec tunnel mode can't pass through a firewall if NAT is performed on incoming traffic. To ensure that IPSec tunnel mode works, use an IP address range in the DMZ that's a public network address range.

NOTE
RFC 1918 describes the three pools of IP addresses reserved for private network usage. The ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. You can obtain a copy of this RFC by going to http://www.ietf.org/rfc and searching for "RFC 1918."

For employees connecting to the network, you could use either PPTP or L2TP/IPSec. Although the scenario doesn't mention certificates being issued to the computers, it's possible to use L2TP/IPSec in the future based on the network configuration.

You must configure the connection between the Montréal office and the Warroad office to use IPSec tunnel mode because the third-party firewall at the Montréal office doesn't support PPTP or L2TP IPSec. IPSec tunnel mode allows full connectivity between the offices but requires additional configuration.

Because the third-party firewall doesn't support certificate-based authentication, you must configure a preshared key for use by the Windows 2000 tunnel server at the Warroad office and the third-party firewall at the Montréal office. To secure the preshared key, configure IPSec filters to allow only IPSec connections using the preshared key from the other tunnel endpoint. This configuration ensures that if the preshared key is compromised, an attacker will be unable to establish an IPSec tunnel mode connection to the network because the attacker won't be connecting from the correct IP address.

Planning Integration with Windows NT 4.0 Remote Access Service (RAS) Servers

If your network contains a mix of Windows NT 4.0 RAS servers and Windows 2000 remote access servers, you must make special considerations to allow authentication of clients connecting to the Windows NT 4.0 RAS servers.

Windows NT 4.0 RAS servers determine whether a connecting user has dial-in permissions by connecting to a domain controller with a NULL session. A NULL session is a security risk because it doesn't provide credentials for the connection. If you allow NULL sessions on the network, anyone connected to the network can query Active Directory directory service without the default security mechanisms in place.

If you don't allow NULL sessions, a remote access client being authenticated by a Windows NT 4.0 RAS server may face the following authentication results:

If the Windows NT 4.0 RAS server connects to a Windows NT 4.0 BDC in a mixed-mode network, authentication will succeed because the Windows NT 4.0 BDC supports NULL sessions.
If the Windows NT 4.0 RAS server is a Windows NT 4.0 BDC in a mixed-mode network, authentication will succeed because the BDC can determine dial-in permissions by looking at its versions of the domain database.
If the Windows NT 4.0 RAS server connects to a Windows 2000 domain controller, the authentication will fail or succeed depending on the membership of the Pre–Windows 2000 Compatible Access security group. If the group contains the Everyone group, authentication will succeed because members of the Pre–Windows 2000 Compatible Access security group can query the domain controller with a NULL session. If the Pre–Windows 2000 Compatible Access security group doesn't contain the Everyone group, the authentication attempt will fail.

The membership of the Pre–Windows 2000 Compatible Access security group is determined by the user creating a new domain in the forest. When you run the Active Directory Installation Wizard (Dcpromo.exe), you're asked if you want to provide support for Windows NT 4.0 RAS servers. If you enable this support, the Everyone group is added to the membership of the Pre–Windows 2000 Compatible Access security group.

IMPORTANT
You can add the Everyone group to the Pre–Windows 2000 Compatible Access security group by using the command NET LOCALGROUP "PRE–WINDOWS 2000 COMPATIBLE ACCESS"/ADD EVERYONE. You can't add the Everyone group in Active Directory Users And Computers to the domain–local group.

Due to the security implications of allowing unsecured queries to Active Directory, your migration plan should include the early migration of remote access servers to Windows 2000. Once all remote access servers are upgraded to Windows 2000, remove the Everyone group from the Pre–Windows 2000 Compatible Access membership.

Making the Decision

When Windows NT 4.0 RAS servers exist on the network, add the following items to your remote access design:

If the Windows NT 4.0 remote access server isn't a BDC, ensure that the membership of the Pre–Windows 2000 Compatible Access group contains the Everyone group.
Upgrade the Windows NT 4.0 remote access servers to Windows 2000 as soon as possible or decommission the Windows NT 4.0 remote access servers and replace the servers with Windows 2000 servers running RRAS.
Remove the Everyone group from the Pre–Windows 2000 Compatible Access group once all Windows NT 4.0 remote access servers are removed from the network or upgraded to Windows 2000.

Applying the Decision

There are no Windows NT 4.0 servers running remote access services in the Hanson Brothers network. To prevent excess rights from being granted to the network, inspect the membership of the Pre–Windows 2000 Compatible Access security group. If the Everyone group is a member, simply delete the group from the existing membership.

Lesson Summary

The decision to allow users to remotely connect to your organization's network requires careful planning to ensure that security is maintained. Make sure that you identify how the users will remotely connect to the network so that you can include authentication, protocol, and integration decisions in your remote access design.