70-240 in 15 minutes a week: Windows 2000 Remote Access

Sunday Oct 28th 2001 by ServerWatch Staff

Article 23 in Dan DiNicolo's 70-240 in 15 minutes a week series covers remote access in Windows 2000. The article takes a look at configuring the remote access portion of Routing and Remote Access, including configuration of dial-in and VPN services, as well as remote access policies and profiles.

by Dan DiNicolo

Welcome to article number 23 in my 70-240 in 15 minutes a week series. This week's article covers remote access in Windows 2000. This includes a look at configuring the remote access portion of Routing and Remote Access, including configuration of dial-in and VPN services, as well as remote access policies and profiles. This article again falls under the Networking Services portion of the series.

The material to be covered in this article includes:

- Routing and Remote Access Overview
- Configuring Dial-in services
- Configuring VPN services
- DHCP Relay Agent
- Remote Access Policies

Routing and Remote Access Overview

One of the most powerful new tools included with Windows 2000 Server is the Routing and Remote Access (RRAS) tool. The capabilities included with RRAS include the ability to configure Windows 2000 as a basic router (running routing protocols such as RIP and OSPF), a demand-dial router (via a standard dial-up or ISDN interface), a traditional remote access server (using dial-in PSTN or ISDN connections), a VPN server (allowing PPTP or L2TP connections), or a combination of the above. The remote access capabilities in RRAS are the focus of this article, with routing functionality to be covered in the next article in the series. This article will also cover some of the more advanced remote access capabilities, including the ability to configure remote access policies (which allow a much more granular way of granting access).

Prior to configuring Routing and Remote Access in Windows 2000, you will need to ensure that the service is both installed and enabled. Use the RRAS administrative tool to enable Routing and Remote Access, as shown below.

Choosing 'Configure and Enable Routing and Remote Access' will open the Routing and Remote Access Wizard, which allows you to easily configure your services for any of the services listed below, while still offering you the ability to configure the services manually (the last option), as shown below. Note that the downwards-pointing red arrow designates that the service is not running.

While the wizard provides a quick and easy way to get RRAS up and running, I suggest that you also attempt the manual configuration of the services to get a better idea of what is involved in setting each up.

Configuring Dial-in Services

Just as Windows NT Server 4.0 was often used for its RAS server capabilities, Windows 2000 continues the tradition, making it significantly easier in my opinion. Getting started will involve familiarizing yourself with the interface, which can be a little tricky at first look. Always start by accessing the properties of the RRAS server, which allow you to control whether the server will act as a router or as a remote access server, both of which will be chosen by default. The General tab of the server's properties is shown below:

To make this server a dial-in or VPN server only, the second option (Remote access server) must be chosen. The other options on this property sheet will be explored shortly.

For the purpose of configuring RRAS to support remote access, the second area that you'll need to look at is 'Ports', as shown below.

Note that both hardware ports (such as the 2 modem ports and the parallel port shown above) are listed, as well as 'virtual' ports, or those associated with allowing incoming VPN connections (also called WAN Miniports). In order to configure a port to allow (or disallow) an incoming connection, right click 'Ports' and choose Properties. After doing this, choose the appropriate device (a modem in this case, since we're exploring dial-in connections) and choose the 'Configure' option. This will access the port configuration, as shown below:

If the device is only meant to be used for inbound or outbound connections, be sure to check or uncheck the appropriate boxes shown above. Note that you can also provide the phone number for this connection (which can subsequently be used in remote access policies) as well as the maximum number of ports (since some devices, such as WAN Miniports can support multiple ports).

Right-clicking on a particular port, such as my modem port in the 'Ports' list, allows me to check the status of a given port.

Note that the device is awaiting an incoming connection, and as such is in a 'Listening' state. If a connection has been made on this port, you could then view statistics, error information, as well as network address information for the connection. You can also use the disconnect button to manually disconnect a session if necessary.

Although the default server properties may work perfectly in allowing you to provide dial-in service, you should be familiar with the remaining property sheets, since the security and connectivity implications may be important. The four remaining property sheets include Security, IP, PPP, and Event Logging.

The Security property sheet allows you to configure which authentication and accounting providers will be used by the server. By default, both options are set to 'Windows' although RADIUS authentication and accounting is also available. RADIUS will be explored in my next article. Beyond simply choosing which authentication method to use, you can also choose the appropriate protocols to be used, as shown below:

Note that EAP, MS-CHAP v2, MS-CHAP, CHAP, SPAP, and PAP are all supported, as well as the ability to allow unauthenticated access (which I would not suggest for obvious reasons). By default, MS-CHAP v2 and MS-CHAP are chosen, the default protocols used by most Windows clients. The order in which the authentication methods are listed above also constitutes the order of preference in which they will be used. For example, if my remote access server supports only MS-CHAP v2 and MS-CHAP as listed above, and my client supports only MS-CHAP, then the client will connect using MS-CHAP, since this is the highest common denominator between the two. If, however, my client only supported CHAP, its connection would be denied, since my server does not support CHAP-based authentication. You should be careful with the authentication protocols allowed, specifically limiting your server to only those you require. Allowing PAP authentication could lead to security issues, since this type of authentication transmits the username and password in clear text.

The IP tab allows you to control settings relating to whether the system can act as an IP router, as well as how remote clients are assigned IP addresses. In particular, you can assign addresses from an existing DHCP server on your network, or from a static pool of addresses specifically for the purpose of remote access. Both options are shown below:

Note that IP is not the only protocol that can be used for the purpose of remote access connectivity - IPX, AppleTalk, and NetBEUI connections are also supported. If you decide to use DHCP in conjunction in order to allocate IP addressing information to clients, you should note that they would only receive the basic configuration information - IP address and subnet mask - unless you also configure the RRAS server as DHCP relay agent. If this is done, the client will receive all network parameters, including the address of the WINS and DNS servers, for example. The DHCP Relay agent configuration will be considered later in the article.

The PPP tab allows you to control basic PPP parameters, including whether you wish to allow Multilink connections (where a client can aggregate multiple physical connections into a single logical connection). If you do choose to allow Multilink, you can also control whether or not the Bandwidth Allocation Protocol (BAP) can also be used, which makes Multilink dynamic, allowing you to control under which circumstances links get dropped according to usage. Link Control Protocol (LCP) extensions control the configuration of the Data Link connection after the PPP parameters have been negotiated. This is necessary to enable if you wish to support callback on your RAS server. Finally, the software compression setting enables data sent over the PPP connection to be compressed.

The final tab, Event Logging (shown below), controls the level of PPP logging associated with the server. If you choose to enable PPP logging (which is beneficial when attempting to troubleshoot PPP connection problems), connection attempt information will be logged to the %systemroot%\Tracing folder, into a file called ppp.log. Note that logging can have a negative impact on system performance, and that enabling it will require that the RRAS service be stopped and restarted.

Configuring VPN services

For the purpose of authentication protocols, IP address assignment, and so forth, the VPN ports use the exact same server properties as those used by dial-in clients, so I will not repeat them here. Because of this, I will only cover settings relating specifically to the configuration of VPN ports in this section. 

You probably noticed that by default there were 10 VPN ports automatically configured when RRAS was started, providing 5 PPTP and 5 L2TP ports by default. Since a VPN connection will be coming in over a network card, in theory the number of possible incoming connections is only limited by the processing capabilities of the system, and not by physical ports. However, the maximum number of ports supported is 30,000 for a given type (such a PPTP WAN Miniports for example).

Note that you cannot change the number of ports to 0, even though the system suggests this is possible. At a minimum, you must have one of each port type available. The reason I mention this is because you will need to configure how many of each type of port you wish to have available for connections, as well as which protocol they will use. If you had chosen to use PPTP for VPN connections for example, it would make sense not to allow incoming connections via L2TP. This would be controlled not by setting the number of L2TP ports to 0, but instead by configuring the L2TP WAN Miniport properties to not allow incoming connections, as shown below:

So why would you choose PPTP over L2TP or vice versa? The answer depends on the level of security you require, as well as the security mechanisms that your network supports. For example, PPTP supports only user-level authentication, meaning that any connection using PPTP that has the correct username/password combination will be allowed. In contrast, L2TP requires 2 levels of authentication - first the machine is authenticated (via a machine certificate that would need to be pre-installed either via group policy or using certificate services) and then the user is authenticated using PPP. This allows a higher degree of security, since both the user and machine must be validated. The downside is the extra effort involved with using L2TP, as well as the fact that only Windows 2000 has built-in L2TP and IPSec capabilities among Microsoft operating systems.

DHCP Relay Agent

A DHCP Relay Agent should be configured on you RRAS server if you wish for remote access clients to obtain complete IP settings via DHCP. If you choose to have clients obtain settings from DHCP without setting up a Relay Agent, then the client will only obtain an IP address and subnet mask from the server, regardless of which options may exist. The traditional use of a DHCP Relay Agent was to act similar to a BOOTP Forwarder, a system that allows DHCP broadcasts to be directed to a DHCP server that may exist on another subnet. If DHCP Relay Agents (or equivalent) are not used, then a DHCP server must exist on the same subnet as the client, which may not be practical. 

In RRAS, a DHCP Relay Agent is configured under the IP Routing section. By accessing the DHCP Relay Agent properties, you can configure to which servers DHCP requests will be forwarded by this agent, as shown below.

Note also that by double-clicking on any interfaces in the DHCP Relay Agent interfaces, you can configure both the Hop-count Threshold (which controls the maximum number of relay agents that will handles a request), as well as the Boot Threshold (the number of seconds that the relay agent will wait prior to relaying requests) for the agent. The default value in both cases is 4.

Remote Access Policies

Perhaps the biggest single new feature in Windows 2000 RRAS is the ability to control access in a more granular fashion using Remote Access policies. Unlike group policy settings that are stored in Active Directory, RAS policies are stored on the RAS server on which they are created. Essentially, RAS policies allow you to control who can (or can't) connect to the server (using groups), the properties of the connection (which can be different for different users), how long they can connect for, the protocols they must use, and so forth. Furthermore, there can be multiple policies per server, such that completely different policies apply to different groups of users. It is important to understand how these policies work, the elements involved, and why you would configure settings in a certain way.

Remote Access Policies are found in the section with the same name in the RRAS tool, as shown below. Note that by default a single policy, called 'Allow access if dial-in permission is enabled' exists by default.

This is important to note. If no policies exist in this list, then ALL remote access connection attempts to this RAS server will be denied. The default policy is very simple. Basically, it allows you remote access if your user account settings are set to 'Allow access', while all other connection attempts are denied. This very basic policy effectively emulates the way remote access settings worked in Windows NT 4.0 - either you are allowed access, or you're not.

Windows 2000 Remote Access Policies are really made up of three distinct parts, and each must be considered when designing these policies. The three parts to RAS policy are the evaluation of:

1. Policy Conditions
2. Permissions
3. Profile

This part can be a little confusing, so stay with me. Basically, the first thing that gets evaluated is the policy conditions, which you must meet in order for a policy to apply to you. As an example, I might make it such that a policy I create applies to the group called 'Sales'. If this were the only policy that existed, and you were not part of Sales, then you would not be able to connect to this RAS server. Policy conditions are the basic parameters that must be met in order to be allowed to make a connection to the server. Double-clicking on a policy will show you the conditions of that policy, and whether meeting those conditions allow or deny you access, as shown below:

Example of settings that can be used as conditions include Windows group membership, days and times, the phone number dialed by the user, and so forth (see the screen shot below for other condition possibilities.

The most important thing to remember is that the conditions of a policy are looked at according to their order in the list of policies. That means that if you don't meet the conditions of the first policy, then the second policy is looked at, then the third, and so forth. However, as soon as you meet the conditions of a policy, that is the last policy evaluated. So, if 13 policies exist, and you meet the conditions of the 2nd, the remaining policies will not be evaluated, even if they were to give you a higher level of access. Remember that if you do not meet the conditions of any policy, then you are automatically denied access.

Permissions are evaluated once you meet the conditions of a policy. Permissions are the settings with respect to dial-in configured on your user account. Three settings exist: Allow Access, Deny Access, and Control Access through Remote Access Policy. If your account permissions are set to Allow Access, then the Profile settings are applied (as will be discussed in a moment). If your account permissions are set to Deny Access, then you are automatically denied access. If your account is set to Control Access through Remote Access Policy, then whether or not you are allowed to connect is controlled via whether you meet the conditions and profile settings. By default, if your domain is in mixed mode, all users are set to deny access. Once the domain is switched to native mode, all accounts are switched to Control Access through Remote Access Policy. This last setting offers the most flexibility, since multiple users could be granted access at once simply by setting up a policy that gives access to all users in the Sales group, which is obviously easier than setting the properties on many accounts individually.

If your permissions allow you access, the final level of evaluation involves the application of profile settings. Profile settings are controlled via the 'Edit Profile' button in the properties of a policy. Quite simply, they constitute the settings you are given if you meet the conditions and have the permission use remote access. For example, you might be given a 2-hour connection time, be disconnected if idle for 30 minutes, and be required to use strong encryption. If for any reason you are not able to meet the requirements outlined in the profile, you are also denied access. While you should take the time to go through profile settings yourself (there are too many to describe here), you should be aware that they are categorized according to Dial-in Constraints, IP settings, Multilink properties, Authentication settings, Encryption settings, and Advanced settings (which can vary based on the dial-in equipment). The screenshot below outlines the Dial-in Constraints tab.

As you can see, controlling remote access in Windows 2000 is a much more granular task than in Windows NT. However, it is also provides for different levels of access for different groups of users, which makes it much more flexible. Remember the order of policy evaluation as I've outlined, and I'm sure you'll be fine on the exam.

That does it for this week. I had originally intended to also include a look at RADIUS in this article, but that will now be included in the next article, which will also cover the routing portion of Routing and Remote Access. I want to thank everyone for their continuing support of the series, and I hope you'll consider posting your technical questions to my message board (please don't email me technical questions, as I will have to refer you to the board, which will provide maximum benefit to others who are also studying). As always, I look forward to your questions, comments, and feedback. There are only a few short months left to write the 70-240 exam - time to get back into study mode after a long (and hopefully fun) summer.

Best of luck with your studies this week.


Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved