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.