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.