Creating Remote Access Policies

Microsoft adds to RAS a potent new weapon for securing connections

A long time ago (at least 5 or 6 years), two great figures were locked in battle over a prize known as "server market share." Whoever held the bigger share would be adored by many and accorded great riches from the mystical land known as Wall Street. At that time, Novell had the bigger share—and Microsoft wanted it.

If you've been in the industry long enough to remember the early days of Windows NT, you know that one way Microsoft was able to get a foot in the door (of even some of the most die-hard Novell shops) was by adding NT services that other platforms didn't have. One of the most popular of these "freebies" was RAS. At that time, RAS's closest competitors were proprietary hardware devices and Novell NetWare Connect, which had high per-port licensing fees.

NT slowly wormed its way into organizations—free services filling one customer need at a time. Unfortunately, many of the freebies haven't matured as much as NT has over the years. Although RAS has gotten a bit better with each NT revision, it has fallen short in some areas that are important to enterprise environments, particularly in the area of managing who can connect to a RAS server and when. NT RAS ties in with domain security and account policies, but administrators often want a greater degree of control over their dial-in users. To address this situation, Microsoft added to Windows 2000 Server remote access policies that RAS can apply against incoming connections.

RAS and Remote Access Policies
Before you get into the nuts and bolts of creating RAS policies for your system, you must understand the primary components of a policy and know how Win2K applies policies to users who try to connect to your server. RAS policies in Win2K Server consist of three primary components. The first component is one or more conditions, such as the time of day or the originating phone number of an incoming connection. The second component grants or denies permission, depending on the condition. And the third component is a profile of settings to apply to the connection if permission is granted.

When a connection comes in to your RAS server, the RAS server begins a series of steps to determine whether it should allow the connection into your network and how it should handle the connection. To make these determinations, the RAS server follows a well-defined procedure that isn't apparent from the standard Win2K interfaces. For example, you can't tell from the standard interfaces whether the grant or deny option for the remote access policy overrides the user-defined settings, or vice versa. Fortunately, Microsoft has documented the logic in its online Help, so I can summarize the procedure for you.

The RAS server begins by comparing the conditions of the first remote access policy defined on your system with the incoming connection. If RAS finds a match, it applies the policy to the incoming connection. Otherwise, RAS looks for a match with the second policy on the list, then the third policy on the list, and so on. Even if you've just built a new RAS server and haven't defined any policies, your system has an Allow access if dial-in permission is enabled policy. Win2K automatically builds this policy for you as a default because RAS rejects all connections to your system if it can't find any matching policies. The condition associated with this policy lets anyone connect to your system on days of the week that end in "y." Because the default policy is so permissive, I recommend moving it to the bottom of your list of policies or deleting it altogether. Deleting this policy tells your RAS server to deny all that is not explicitly allowed—a good security precaution for any administrator to take.

When the RAS server finds a policy whose conditions match the incoming connection, it takes one of three actions: The server allows access, denies access, or controls access through a remote access policy. You determine the action by using the options on the Dial-in tab of a user's Properties dialog box, which Figure 1 shows. For a standalone server, you access the dialog box through Computer Management on the Administrative Tools menu; for a server that is part of a domain, you access the dialog box through the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. Obviously, if you select the Deny access option for a user, the RAS server rejects the connection attempt. But if you choose to allow access or to control access through a remote access policy, things are a bit trickier.

If you select Allow access, the RAS server verifies the dial-in properties defined for the user. If the properties match the policy conditions, the RAS server allows the connection; otherwise, it rejects the connection. For example, you might specify in user Mary's dial-in properties that calls should come only from her home number, 703-555-1212. If Mary calls from any other number, the RAS server will reject her connection.

If you select the Control access through Remote Access Policy option for a user (available only in native mode Win2K domains or on standalone servers), RAS determines whether the Grant remote access permission option in the remote access policy is selected; if it is, RAS grants the user access (finally).

Got all that straight? I had to use a pen and paper to draw the flow chart that Figure 2, page 84, shows to make sure I understood the procedure correctly. Now that you know how RAS determines when to apply a policy, let's take a look at some of the things you can do with a remote access policy.

Setting a Maximum Connection Time
RAS policies open up a new realm of possibilities for managing inbound connections. Unlike earlier versions of RAS—which have all the technological complexity of a light switch (i.e., allow access or deny access)—Win2K RAS lets you control connection times, limit or deny access based on Caller ID information, enforce varying encryption strengths, and more.

To show how a RAS policy lets you set a maximum connection time, let's consider a hypothetical user. Mary is a great sales representative for your company. She keeps her customers happy and always meets her quarterly goals. However, Mary causes you one problem—when she's working at home on her laptop, she often forgets that she's dialed into the RAS server and leaves her system logged on for hours at a time (sometimes overnight). Of course, this oversight ties up one of your phone lines, and after several occasions when the company CEO can't dial in, you've been told to fix the problem.

After talking to Mary, you determine that when she's at a customer location, she should be able to dial in to the server for as long as necessary. But when she's calling from home, you want to limit her connection time to a maximum of 1 hour. You can start defining a remote access policy to enforce these guidelines by opening the MMC Routing and Remote Access snap-in (under Administrative Tools on the Start menu) and expanding the items listed under the server.

Right-click the Remote Access Policies item, select New, then select Remote Access Policy, as Figure 3 shows. A useful wizard takes you through the steps of defining a policy for your system. The wizard first prompts you for a description of the policy. Make the description detailed so that later, when you see the policies listed in the Routing and Remote Access snap-in, you can distinguish between them. After you enter a name for your new policy, click Next to continue to the next wizard step.

Remember that remote access policies are made up of three components: conditions, permissions, and profiles. Step 2 of the wizard lets you add conditions under which the policy applies. You can add multiple conditions, but keep in mind that all of the conditions must be true for RAS to apply the policy. Click Add to see a list of attributes that you can select, as Figure 4 shows.

If you want to find out what number Mary is calling from, select the Calling-Station-Id attribute. To use this attribute, you must have all the necessary Caller ID equipment and services in place at your location, including Caller ID service on your phone line and a Caller ID-capable modem with the correct driver on your system. When you click Add, you're prompted for a word or a wildcard to match. Enter Mary's phone number—let's say it's 703-555-1212—in this field. However, if you wanted to use a wildcard to allow callers only from a specific area code, you could enter 703* to apply the remote access policy to any caller from the 703 area code.

After you enter Mary's phone number, you see it listed as one of the conditions for the policy. You could add more conditions at this point, but you don't need to, so you can continue to Step 3 of the wizard. Step 3 lets you define whether to allow or deny the user access to your system based on the policy. To allow access to users who match the condition defined in Step 2, select the Grant remote access permission option.

In the final wizard step, you specify the behavior of connections that meet the remote access policy's conditions. Click Edit profile to open the dialog box that Figure 5 shows. From this property window, you can control various connection parameters, including valid connection times and timeouts, IP packet filtering, and encryption requirements. Move through the tabs to look at the options. To set the RAS server to terminate Mary's connection after 1 hour, select the Dial-in Constraints tab's Restrict maximum session to check box, and enter the value 60.

After you edit the policy profile, click Finish to apply the remote access policy to your RAS server. Then, check that the main window of the Routing and Remote Access snap-in lists your new remote access policy.

To make sure that the RAS server tests connections against your new policy first (instead of against the default "allow everyone" policy), right-click the new policy and select Move Up. This action moves your new policy to the top of the list and changes the order number to 1.

You have now restricted Mary from staying logged on to RAS for more than 1 hour when she's dialing in from her home number. Actually, your policy prevents anyone who signs in from Mary's home phone number from staying online for longer than 1 hour because RAS can't check for a username within a policy. If you wanted to go a step further and restrict only Mary's access from the phone number, you could define a user group in which she was the only member and set an additional condition on the policy to check for group membership. The policy would still apply to Mary, but other users would fail the group membership condition, and the policy would ignore them.

One RAS Server for Both VPN and Dial-in
But enough picking on Mary. Win2K RAS policies solve another problem by giving you the ability to vary authentication and encryption levels based on the type of incoming connection.

Earlier RAS versions allow only one authentication or encryption type for the entire server. This limitation becomes a problem when organizations with regular dial-in users try to implement VPN on the same RAS server. VPN implementation procedures on an NT RAS server dictate that the server deny connections that don't use strong encryption and authentication protocols. Most dial-in users don't want to enable the encryption options in their connection properties, so the RAS server (correctly) rejects their connection attempts.

Many organizations end up building two NT RAS servers: one to handle dial-in connections, and a second to handle VPN connections. But in Win2K, remote access policies let you require strong authentication and encryption only for VPN connection types. Creating a VPN policy is actually quite simple.

To specify the condition that the remote access policy should check, select Tunnel-Type at the Select Attribute screen that Figure 4 shows. You'll see a list of tunneling protocols; choose the appropriate ones (Win2K Server supports PPTP and Layer 2 Tunneling Protocol—L2TP—natively). Next, grant permission to connections that use one of your selected tunneling protocols. Finally, edit the policy profile to apply the necessary authentication and encryption types for your VPN connections. For example, you'll want to reject connections from systems that don't use encryption, so clear the No Encryption check box, as Figure 6 shows.

With your VPN policy in place, regular dial-in users can connect to your RAS server without encryption. However, tunneling (PPTP and L2TP) connections must have an encrypted channel or RAS will drop them.

I've given you two ideas for remote access policies, and you'll no doubt think of many other uses for this RAS enhancement. The list of attributes in Figure 4 might provide more inspiration.

Policies are a welcome addition to Win2K Server and give organizations a far greater degree of control over who enters their network how, when, and for how long. Remote access policies make RAS a more potent weapon in Microsoft's ongoing battle for server market share.