Exam 70-124: Objective 4.4: Configuring a Remote Access Server

In the chapter introduction, we spent a little time discussing the challenges associated with the highly diverse and mobile user populations many companies are struggling to deal with today. From the CEO who travels frequently to an executive round table in Paris, the salesperson who needs to check pricing from a customer's office, or the systems engineer who needs to verify a router configuration and doesn't want to drive to the office at 3:00 a.m., employees have varied and legitimate needs for accessing the corporate network remotely. One service that Microsoft's Windows 2000 Server operating system provides that can help you deal with these challenges is the RRAS, which can be used to create an RAS.

Head of the Class…
RAS versus RRAS: What's the Difference?

One of the more confusing terminologies associated with Windows 2000's remote access capabilities is RAS (Remote Access Server) and RRAS. This is particularly confusing because the predecessor to RRAS was RAS (Remote Access Services). RAS is also the generic industry terminology to identify any server that supports dial-in network access. In any discussions of Windows 2000's remote access capabilities, the term RAS should be interpreted as the dial-in portion of the RRAS suite of services. RRAS includes not only the dial-in capabilities of its predecessors but also the added VPN functionality discussed later in the chapter.

Why would you want to deploy an RAS server in 2003? Everyone is doing it with VPN these days, right? Wrong. Although there is a huge demand for VPN capabilities, there is still a large requirement for the older dial-in technology. RAS servers are used in many businesses for providing inexpensive access to the network, by companies that don't have Internet connections (although this list is growing smaller and smaller), in places where the overhead associated with supporting a VPN solution is not practical and in many cases as a backup access method in case there is an issue with the primary VPN service. It has been said by many industry insiders that the RAS server is dead, but it will be quite some time before you see it go the way of the card punch. RAS servers are a proven technology that is relatively inexpensive, highly reliable, and, with the Windows 2000 RRAS, very easy to configure. In fact, let's take a look at setting up a RAS server using the Windows 2000 RRAS.

Installing and Configuring the Remote Access Server

Before we get into Exercise 9.01 on setting up your Windows 2000 Server as a dial-in server, there is one thing that is very important to understand about enabling the RRAS so that you can set up the your RAS. Unlike previous incarnations of the Windows server operating system, in which the Remote Access Services were an option, the RRAS is an integral part of the Windows 2000 Server operating system and is installed as part of the installation of Windows 2000 Server. For that reason we will jump right into the topic of configuring the RAS.

Exercise 9.01: Configuring the Routing and Remote Access Service for Dial-In Access

1. Click Start | Programs | Administrative Tools | Routing and Remote Access to open the Routing and Remote Access console (see Figure 9.1).

   
   Figure 9.1: The Routing and Remote Access Console

2. Within the Routing and Remote Access console, select Configure and Enable Routing and Remote Access from the Action menu (see Figure 9.2).

   
   Figure 9.2: The Action Menu of the Routing and Remote Access Console

3. The Routing and Remote Access Server Setup wizard opens (see Figure 9.3). Select Next to continue the configuration process.

   
   Figure 9.3: The Routing and Remote Access Server Setup Wizard

4. From the Common Configurations screen (see Figure 9.4), select Remote access server and select Next to continue.

   
   Figure 9.4: Common Configurations

5. From the Remote Client Protocols screen (see Figure 9.5), ensure that TCP/IP is one of the listed protocols (it is included by default), and select Next to continue.

   
   Figure 9.5: Remote Client Protocols

6. If the AppleTalk protocol is one of the protocols listed on your server, as it is in this exercise, the Macintosh Guest Authentication dialog box will be displayed (see Figure 9.6). This step is included in the exercise to remind you that selecting Allow unauthenticated access for all remote clients is a very bad idea unless you have no need for security on your network. You should always force username and password authentication for remote users. Select Next to proceed.

   
   Figure 9.6: Macintosh Guest Authentication

7. The IP Address Assignment screen (see Figure 9.7) is used to determine how IP addresses will be assigned to remote users. If you select the Automatically option, the server will request IP addresses from the network DHCP server in blocks of 10 addresses and hand them out to remote users. Select the From a specified range of addresses option, and select Next to continue.

   
   Figure 9.7: IP Address Assignment

8. The Address Range Assignment screen (see Figure 9.8) is used to assign a block of addresses to your RAS server. Select New to open the New Address Range screen (see Figure 9.9) and create a pool of addresses. You can use the addresses in the example or make up your own. If you are working in a production environment, be sure to get your address assignments from the networking administrators. Select OK to add the address range to the list. Figure 9.10 shows the newly created address range. Select Next to continue the configuration process.

   
   Figure 9.8: Address Range Assignment

   
   Figure 9.9: New Address Range

   
   Figure 9.10: Address Range Assignment with the Newly Created Address Pool

9. The Managing Multiple Remote Access Servers screen opens (see Figure 9.11). This option is used if you want to have multiple RAS servers authenticate against a central RADIUS authentication database. Select No, I don't want to set up this server to use RADIUS now and select Next to continue.

   
   Figure 9.11: Managing Multiple Remote Access Servers

10. You are now at the last screen (see Figure 9.12) for configuring your RAS server. To complete the process, select Finish. You will see the Completing Initialization message shown in Figure 9.13 while the system completes the configuration of the service. Once this process completes, that message will close, and the RAS server is configured. If you select Display Help about managing a remote access server when I close this wizard, as is selected in the example, you will get the Routing and Remote Access help file (see Figure 9.14), which contains some excellent information on the specifics of the service.

    
    Figure 9.12: Managing Multiple Remote Access Servers

    
    Figure 9.13: Initializing the Routing and Remote Access Service

    
    Figure 9.14: Help Screens

Notes from the Underground…
Identify Remote Users

You should always assign unique address ranges to your remote access users so that they can be easily distinguished from LAN users. Doing so not only allows you to easily segregate network access if some areas of your network need to be secured from remote users; it also allows a remote user to be easily identified in log files and on intrusion detection systems. If you configure your remote access server to distribute addresses automatically, you have no easy way of differentiating a remote user from a local user. The remote access server will pull a block of addresses from your DHCP server and will take the next 10 addresses available; these are addresses from the same IP scope from which your LAN users are getting their addresses.

An attacker would be able to take advantage of this configuration by masquerading as a local user and forcing you to spend extra time tracking them down. To identify an attacker in this scenario, you would need to go to the DHCP server and check the log for the name of the system that was using the address at the time of the attack, then go to the remote access server to determine which account or connection was assigned the address. To make matters worse, if the time synchronization between your servers is not accurate, you might have no way to track an IP address back to its true source. As is usually the case, the manual configuration option is the more secure option. It takes longer, but it gives you much better capabilities for tracking down IP addresses on the network.

Working with RAS Ports

Now that you have successfully configured your RAS server, we need to dig a little deeper into the underlying port configuration, where you can configure the authentication methods and other important security parameters related to dial-in access. Exercise 9.02 walks you through the configuration of the modem ports on your Windows 2000 RAS server.

Note 

You need to have a modem or modems configured on your test system in order to complete Exercise 9.02.

Exercise 9.02: Configuring Routing and Remote Access Service Modem Ports

1. Click Start | Programs | Administrative Tools | Routing and Remote Access to open the Routing and Remote Access console (see Figure 9.15). This console now shows an active server and all the associated options.

   
   Figure 9.15: Routing and Remote Access Console Configured for Use

2. Within the Routing and Remote Access console, select Ports in the right-hand pane, and select Properties from the Action menu (see Figure 9.16).

   
   Figure 9.16: Opening the Port Properties

3. The Port Properties screen (see Figure 9.17) opens. This screen displays all the ports currently configured for use by the RRAS. Since we are working with modem ports for this exercise, select a modem port and select Configure to continue.

   
   Figure 9.17: Port Properties

4. From the Configure Device screen (see Figure 9.18), select Remote access connections (inbound only). This choice makes the port available for dial-in use. The other parameters on this screen would be used if the server were going to be used as a demand-dial router, which is out of scope for this exercise. Select OK to assign this port for use for remote access connections.

   
   Figure 9.18: Configuring a Device Port for Inbound Remote Access Connections

5. In Figure 9.19 you can see that the modem port you selected has been assigned to the RAS service. Select OK to return to the Routing and Remote Access console.

   
   Figure 9.19: The Modem Port Has Been Assigned to RAS

6. To check the status of the port, double-click the Ports icon in the Routing and Remote Access console. Each available port is displayed (see Figure 9.20). Double-click the name of the modem you configured in the first portion of this exercise.

   
   Figure 9.20: Configuring a Device Port for Inbound Remote Access Connections

7. The Port Status screen (see Figure 9.21) displays many useful statistics when a session is in progress, including how long the user has been connected, how much traffic has passed across the line, and the session addressing information. Select Close to return to the Routing and Remote Access console to complete this exercise.

   
   Figure 9.21: Checking the Port Status

Head of the Class…
Why Do We Need to Worry About an RAS Server? No One Uses Them Anymore, Right?

It is a common misconception that in this age of high-speed broadband Internet access and VPNs, the RAS server has gone the way of the dinosaur. This is not true. The reason Microsoft insists on your understanding how to securely configure a RAS server under Windows 2000 is that although the RAS server's role has changed, it is still an important component of most corporate remote access environments. The usual complaint about RAS servers is that they are just too slow. Usually you hear this from the director who just got his cable modem installed. Furthermore, the rapidly approaching ubiquity of broadband Internet access solutions does make a compelling argument for shifting your remote access solutions away from modem-based RAS to an Internet-based VPN solution. But let's talk about reality for a moment. Why does an RAS server still make sense?

First, what are your plans for the day that your Internet router decides to stop routing? You can always spend thousands of dollars in load balancing, redundant Internet connections, and hot spare equipment, or you can put in a low-cost RAS server to accommodate your remote users until your Internet connection is back up and running.

Another good reason for a RAS solution is that you don't need firewalls and intrusion detection systems (IDS) in order to support modem-based remote access. Although it's true that most companies today have some level of security on the corporate Internet connection, what about the remote users? Are you ready to roll out firewalls and IDSs to all your remote users? One of the favorite tricks for bypassing a corporate firewall is to compromise one of the remote clients, load a Trojan horse remote control program on it, and then wait for remote users to establish a VPN connection to the internal network. Once your unsuspecting employee has carried the attacker across the network threshold, you have handed the attacker a high-speed open door to start attacking your internal systems.

A final reason that we keep discussing RAS servers whenever we talk about remote access is that they are still useful for low-bandwidth applications. Do you need a 6 Mbps Internet connection if what you want to do is Telnet to a router to check processor utilization? The answer is no. So in some environments you will see the legacy RAS servers being reutilized as network management devices, used by engineers for managing network environments remotely.

All that being said, there are many compelling reasons (which we discuss a little later in the chapter) for implementing a VPN solution for remote access. But don't plan on retiring your RAS server just yet—you might find it has not outlived its usefulness after all.