Microsoft introduced Remote Access Services (RAS) early in the Windows NT product cycle, adding routing capability through an add-on service for Windows NT. Windows 2000 integrates these services in a single Routing and Remote Access Service (RRAS) that provides excellent utility for routing, remote access, and integration with other Windows 2000 services, as well as third-party platforms. In this series of Drill Downs I’ll take a close, detailed look at RRAS in Windows 2000 Server, starting with an overview of what the service can do.

Overview of Windows 2000 RRAS
Remote Access Services (RAS) enables a Windows 2000 computer to dial and access remote networks, the Internet, and even individual servers or client workstations. RAS is the mechanism you use, for example, to dial out from a Windows 2000 computer to access an Internet service provider or a remote LAN. Windows 2000 RAS supports several connection options including modem, ISDN, infrared connections, parallel and serial port direct connections, X.25, and Asynchronous Transfer Mode (ATM). Windows 2000’s support for tunneling protocols such as PPTP and L2TP enables clients to establish a secure connection to a remote network through a public network such as the Internet.

The RAS component in Windows 2000 also enables a computer running Windows 2000 Server to function as a dial-up server, allowing clients to dial into the server to access local server resources, such as files and printers. Depending on the configuration of the server, clients can also gain access to the network on which the server resides, accessing LAN resources just as if the client were connected locally to the LAN. Windows 2000 Server supports an unlimited number of concurrent connections, subject to hardware considerations such as server capacity, number of physical connections (available modems, for example), and so on. Windows 2000 Professional computers can also serve as RAS servers but only for one connection at a time. A Windows 2000 remote access server supports the same connection options for incoming connections as the outgoing connection options mentioned previously. You can also use Windows 2000 RRAS to support incoming Terminal Services client connections.

Windows 2000 RRAS also enables a Windows 2000 server to function as a router. Windows 2000 RRAS supports both unicast and multicast protocols, as well as packet filtering, connection sharing, demand-dial routing, and encrypted authentication for secure router-to-router connections. A key advantage to using Windows 2000 RRAS for routing services is its integration with other Windows 2000 services, such as Active Directory (AD) and Kerberos authentication, DHCP, and so on. Integration with AD enables user accounts and remote access policies and settings such as callback, access permissions, and so on to be replicated across the domain for redundancy. AD integration also can simplify management by providing a single point of administration and enabling you to delegate remote access administrative authority over specific services or Organizational Units (OUs).

Windows 2000 RRAS offers several authentication options. By supporting Remote Authentication Dial-In User Service (RADIUS)—either through a non-Windows 2000 RADIUS server or through the Windows 2000 Internet Authentication Services (IAS)—Windows 2000 RRAS enables you to rely on Windows 2000 for routing services while offloading authentication and accounting to a RADIUS server. Windows 2000 also supports a broad range of authentication protocols including MS-CHAP, EAP, CHAP, SPAP, and PAP. You’ll find good network protocol support in RRAS with TCP/IP, IPX/SPX, NetBEUI, and AppleTalk enabling Macintosh, NetWare, and UNIX clients to connect to a Windows 2000 RRAS server in addition to Microsoft clients.

New features in Windows 2000
Windows 2000’s RRAS integrates all the features in Windows NT RAS and the Routing and Remote Access Service and adds several more features to improve performance, integration, and security. One of the most important additions is the integration of RRAS into Active Directory. You gain the advantage of AD’s replication, enabling replication of client account properties throughout the directory. Administration is easier too, thanks to the ability to browse multiple RRAS servers through AD and manage those servers through the RRAS console, an MMC snap-in (Figure A).

Figure A
Like other Windows 2000 services, RRAS provides an MMC snap-in that lets you manage all RRAS server properties.

The Windows 2000 RRAS service adds support for both Bandwidth Allocation Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP), which work in concert to support multilink connections. Multilink enables Windows 2000 to bundle multiple connections to provide an aggregate bandwidth equaling the sum of the individual connections. Aggregate two 56-Kbps dial-up connections, for example, and you get a theoretical connection of 112 Kbps (although the resulting connection is limited by the FCC-imposed limit on 56 Kbps connections, line quality, and other factors). BACP enables Windows 2000 to dynamically allocate and de-allocate connections based on bandwidth utilization.

As bandwidth use increases, Windows 2000 can automatically dial additional connections to accommodate the increase. When bandwidth demand decreases, Windows 2000 can automatically drop connections. Managing the number of connections in this way can realize a significant cost savings. You can apply BAP/BACP policies through remote access policies, tailoring those policies to OUs, groups, or individual accounts.

Support for MS-CHAP version 2 is another addition in Windows 2000 RRAS. MS-CHAP stands for Microsoft Challenge Handshake Authentication Protocol, and version 2 offers improved security primarily aimed at Virtual Private Network (VPN) connections. MS-CHAP version 2 integrates several changes for improved security:

  • Stronger encryption: Previous versions of MS-CHAP used 40-bit encryption and the user’s password to create the cryptographic key for each session. This resulted in the same key being used for each session unless the password changed. Version 2 uses an arbitrary challenge string along with the user’s password to create the session key. The use of the arbitrary challenge string results in a unique key for each session even if the user’s password remains unchanged.
  • Mutual authentication: This feature provides for two-way authentication between the remote client and the RRAS server. Bidirectional authentication not only allows the server to authenticate the client’s logon request but also enables the client to authenticate the server’s authority to service its authentication request.
  • Improved transmission security: Windows 2000 RRAS uses separate cryptographic keys for incoming and outgoing data, providing enhanced transmission security.
  • LAN Manager coding no longer supported: MS-CHAP version 2 drops support for LAN Manager response coding and password encoding, for improved security.

Another new feature in Windows 2000’s RRAS is support for Extensible Authentication Protocol (EAP), which enables additional authentication methods to be supported without changes to the operating system or RRAS. The server and client negotiate the authentication method. Protocols currently supported by Windows 2000 include EAP-MD5 CHAP, EAP-TLS, and RADIUS. We’ll take a look at each of these a little later.

As hinted at previously, Windows 2000 RRAS supports RADIUS for authenticating clients. RRAS can authenticate access against a Windows 2000 server running the Internet Authentication Service (IAS) included with Windows 2000 Server or any server running a standards-based version of RADIUS, including UNIX hosts. Support for RADIUS enables a Windows 2000 RRAS server to authenticate clients that connect through RADIUS-based devices such as modem pools. The RRAS server can handle RADIUS authentication itself if IAS is installed on the server or redirect authentication to another server, whether that server is running Windows 2000 IAS or other RADIUS implementation (including UNIX platforms). One of the primary advantages to using RADIUS—other than integration with existing hardware or authentication servers—is the capabilities provided by RADIUS for accounting. Several third-party utilities exist that provide rich account management through integration of the RADIUS logs with database utilities for SQL and other database platforms.

Security and administration are important areas of improvement in Windows 2000 RRAS. You can apply remote access settings such as callback, connect time restrictions, allowed session limits, authentication methods, and other properties at the user account level as shown in Figure B. A better method, however, is to use remote access policies to apply remote access settings on a group or OU basis. Windows 2000 RRAS also supports account lockout, which helps prevent dictionary attacks by locking the account after an administrator-defined number of bad logon attempts. You can also specify the length of time the account is locked out before it is re-enabled.

Figure B
You can apply remote access settings at the user account level, but remote access policies provide better administrative control, enabling you to define settings at the group or OU level.

One final improvement in Windows 2000 RRAS is the addition of support for AppleTalk over PPP, enabling Macintosh clients to connect to a Windows 2000 RRAS server using native Macintosh protocols.

Managing RRAS through the MMC
As with other Windows 2000 services, you manage RRAS through an MMC console snap-in. The RRAS console enables you to fully manage local and remote RRAS servers (subject to access and security restrictions). The console provides a wizard to help you configure the server according to its primary function, whether Internet connection server, VPN server, remote access server, or router. You can configure the server manually and fine-tune the configuration to accommodate changes or settings not available through the wizard. You also use the RRAS console to configure remote access policies.

Exploring RAS protocols and connection types
Windows 2000 RRAS provides support for several protocols and connection types, giving you quite a bit of flexibility in designing your remote access structure to accommodate security needs, network topology, or remote server capability. Windows 2000 supports Serial Line Interface Protocol (SLIP) for dial-out connection to remote servers that support SLIP (such as older UNIX-based servers), but it doesn’t support SLIP for incoming connections.

Probably the most common connection protocol in use today, and one you’ll likely use, is Point-to-Point Protocol, or PPP. This successor to SLIP offers better reliability and performance and provides good cross-platform support. Windows 2000 supports PPP for both incoming and outgoing connections, enabling clients to use TCP/IP, IPX, or NetBEUI as the network protocol. Macintosh clients can connect to a Windows 2000 RRAS server using TCP/IP or AppleTalk. PPP supports a good selection of authentication protocols, offering options that can accommodate both client capability and security needs.

Windows 2000 RRAS supports the Microsoft RAS protocol, a proprietary Microsoft protocol for DOS, Windows for Workgroups, Windows NT 3.1, and LAN Manager remote access. Microsoft RAS protocol requires that the client use NetBEUI as the network protocol, with the RAS server functioning as a NetBIOS gateway supporting NetBEUI, NetBIOS over TCP/IP, and NetBIOS over IPX. Since NetBEUI will likely go away in the next OS release, you should rely on one of the other protocols instead of Microsoft RAS.

As mentioned previously, Windows 2000 RRAS also supports Point-to-Point Multilink Protocol (PPMP) and Bandwidth Allocation Protocol (BAP). These protocols enable Windows 2000 to bundle multiple connections to achieve an aggregate bandwidth. For example, you can use multilink to combine both B channels of an ISDN connection to achieve an effective throughput twice what you’d get with a single channel (or even do the same thing with two DSL circuits). BAP lets Windows 2000 dynamically manage the connection, adding or dropping connections as needed according to bandwidth utilization.

For situations requiring secure connections, Windows 2000 supports Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP). Both protocols provide a means for encapsulating and encrypting data packets for secure transmission across public networks such as the Internet. You might use PPTP or L2TP to connect through the Internet to a VPN server on your LAN, for example, giving you secure dial-up access to your LAN. Why not just dial directly into the LAN? Connection costs are a primary reason. The LAN might be located outside your local calling area, requiring a toll call to connect. But connection cost isn’t the only factor. If the LAN already has a direct connection to the Internet, you avoid the need to install and support dial-up equipment on the LAN side, plus you eliminate a potential security risk—unauthorized clients bypassing the firewall or proxy server to gain access to your LAN through the dial-up back door.

PPTP doesn’t use encryption by default but can use Microsoft Point-to-Point Encryption (MPPE) to encrypt the PPP frames with encryption keys generated with MS-CHAP or EAP-TLS authentication. Since PPTP encapsulates the data unencrypted by default, you’ll need to specifically use MS-CHAP or EAP-TLS if you want your PPTP connection to be truly secure.

Where additional security is needed, you can use L2TP rather than PPTP. L2TP relies on IP Security (IPSec) to provide encryption of encapsulated data rather than MPPE. While this requires that both source and destination routers support L2TP and IPSec, it provides a higher degree of security than PPTP. You’ll learn more about PPTP and L2TP—including how they relate to VPN connections—later in this series of Drill Downs.

Windows 2000 RRAS also offers good network protocol support for RRAS connections, supporting TCP/IP, IPX, NetBEUI, and AppleTalk. For TCP/IP connections, RRAS can allocate IP addresses and related settings to incoming connections either through DHCP or a static address pool. The RRAS service also allows clients to request a predefined IP address. Unless you’re configuring a router or remote access server for only Microsoft clients that don’t require Internet connectivity or supporting only NetWare clients, you’re probably going to settle on TCP/IP as the protocol of choice.

If you do need to support NetWare clients that use IPX, you can do so through the RRAS service. IPX support enables a Windows 2000 RRAS server to function as a remote access server for NetWare IPX clients and also serve as an IPX router to route RIP, SAP, and NetBIOS traffic. In addition to the IPX protocol, the client must be running a NetWare network client, such as the Client for NetWare on Windows 2000 Professional computers or Gateway Service for NetWare on a Windows 2000 Server computer.

NetBEUI is a good solution for remote access to small LANs and where dial-up traffic does not require routing (since NetBEUI is a non-routable protocol). NetBEUI is much easier to configure than TCP/IP and therefore results in lower administrative overhead. Support for the AppleTalk protocol enables Macintosh clients to access network resources shared by other AppleTalk clients on the LAN, including those shared through Services for Macintosh or by other local Macintosh clients.

Enabling RRAS
When you install Windows 2000 Server, Setup automatically installs the RRAS service but doesn’t enable it. This means you don’t have to install the service but you do need to enable and configure it according to the functions you want the RRAS server to perform. The server can handle incoming remote access connections, outgoing remote access connections, function as a router, or any combination of the three.

The first step in getting the RRAS server up and running is to ensure the connections are in place. For incoming connections, this could mean installing additional network interfaces, modems, multiport cards, standalone modem pools, and so on, depending on the types of clients you need to support. The same is true for outgoing RAS connections, but this typically involves only adding a network interface or installing a modem, ISDN adapter, DLS equipment, and so on. Configuring connections for routers typically means adding a network interface where appropriate and configuring its protocol settings.

Once the interfaces or remote access hardware is in place and tested, your next step is to enable and begin configuring the RRAS server. You’ll find the Routing and Remote Access console in the Administrative Tools folder. In the left pane, right-click the server and choose Configure And Enable Routing And Remote Access to start the Routing And Remote Access Server Setup Wizard. The wizard lets you choose between four different types of servers or configure the server manually. You have full control over settings after installation and can modify settings as needed if you choose to let the wizard configure the server for you. You can also configure the server manually, and then run the wizard at a later time if you want to change the server’s role, although you’ll lose most of your manually configured settings when you do so and you’ll have to reapply them through the wizard. If you configure the server using the wizard and then decide you want to start over from scratch, you can disable and then re-enable the service to start with a clean slate. In the RRAS console, right-click the server and choose Disable Routing And Remote Access, and after the service stops, run the wizard again to configure the service.

What’s next
At this point you have a basic background in the Windows 2000 Routing and Remote Access service with a look at many of its requirements and capabilities. In the next Drill Down in the series you’ll start looking at specific implementations for the Windows 2000 RRAS service, starting with network address translation (NAT), which enables a Windows 2000 RRAS server to function as a gateway between a private network and the Internet.

Jim Boyce is a former contributing editor and monthly columnist for WINDOWS Magazine. Jim has authored and co-authored over 40 books about computer software and hardware. He has been involved with computers since the late 1970s as a programmer and systems manager in a variety of capacities. He has a wide range of experience in the MS-DOS, Windows, Windows NT, Windows 2000, and UNIX environments. In addition to a full-time writing career, Jim is a founding partner and vice president of Minnesota Webworks, a Midwest-based Web development firm.

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.