In the Windows & .NET Magazine article, "A Secure Wireless Network Is Possible," May 2004, InstantDoc ID 42273, I show you how to use a Windows Server 2003 computer and your existing Windows 2000 Server Active Directory (AD) domain to set up a secure remote access VPN for remote users. In this article, I show you how to achieve granular control over which accounts in AD can remotely access your LAN through your Windows 2003 VPN server and how they can gain such access.
In Windows 2003 and Win2K Server, you can define remote access policies, which let you use criteria such as group membership to control who can access your network through a remote system. For instance, you can easily create a remote access policy that gives all members of the SalesReps group remote access without requiring you to modify each user account. Remote access policies also let you control access to specific parts of the network, depending on user characteristics such as group membership, client OS type, and media access control (MAC) address. For example, if your Oracle consultant needs remote access to your Oracle server, you can create a remote access policy that lets the consultant connect to your VPN server but restricts his or her communications to only the Oracle server.
To use remote access policies to control remote access to your LAN, you need at least one VPN server, which can be a Windows 2003 system, a Win2K Server system, or a Windows NT Server system that has RRAS installed. If you want to use Layer Two Tunneling Protocol (L2TP) as your VPN protocol, your VPN server must run Windows 2003 or Win2K Server; if you want to use L2TP over a Network Address Translation (NAT) boundary, your VPN server must run Windows 2003.
To configure all your VPN servers to enforce the same policies, you use Internet Authentication Service. IAS is a component of Windows 2003 and Win2K Server that provides Remote Authentication Dial-In User Service (RADIUS) server functionality. If you deploy an IAS server and configure all your VPN servers as its RADIUS clients, the IAS server applies the same remote access policies to connections that originate from all your VPN servers. Technically, Win2K VPN servers let you use remote access policies without an IAS server; however, when you do so, you lose the ability to centrally manage remote access policies when you have more than one VPN server. In Windows 2003, Microsoft removed standalone remote access policy functionality from the OS; you must configure a VPN server as a RADIUS client of an IAS server to take advantage of remote access policies. Web Figure 1 (http://www.winnetmag.com/windowssecurity, InstantDoc ID 43452) shows the components of the VPN-IAS scenario that we'll use to set up remote access.
The IAS server can authenticate connection requests against its local SAM, any trusted NT domain, or an AD domain. You reap more centralized management and integration capabilities when you configure IAS to authenticate against a domain, especially an AD domain. By authenticating against a domain, you don't have to give each user an additional account for remote access; users simply use their regular domain account. Win2K's IAS suffices for most remote access VPN requirements. Most of Windows 2003's new IAS features relate to supporting 802.1x for Wireless Application Protocol (WAP) and authenticated switches. Therefore, if your remote access needs are oriented toward wireless users, Windows 2003 IAS is the better choice.
Although our remote access scenario has multiple VPN servers to ensure availability, the IAS server still presents a single point of failure. To reduce the risk of IAS server failure, you can deploy a second IAS server and copy to it the first IAS server's configuration. To copy the configuration, run the command
netsh aaaa show config > path\iasconfig.txt
which exports your main IAS server's configuration into a text file. (You must type the command on one line.) The aaaa show config string shows IAS's authentication, authorization, accounting, and auditing database (ias.mdb), which Netsh redirects to the text file. (For information about the Netsh command, see "Resources" at http://www.winnetmag.com/windows
security, InstantDoc ID 43452.) The iasconfig.txt file now contains your entire IAS configuration, including remote access policies, the connection-request policy, registry settings, and the logging configuration. Copy the file to the destination IAS server, and on that server run the command
netsh exec path\iasconfig.txt
Then, configure each VPN server as a RADIUS client of both IAS servers. If your first IAS server fails, your VPN servers will automatically fall back to the other IAS server. As I explain in "A Secure Wireless Network Is Possible," RADIUS client configuration is usually a two-part process in which you configure a VPN server to use an IAS server, then configure the IAS server to recognize the VPN server as a RADIUS client. When you copy the configuration of one IAS server to another, the configuration includes RADIUS client information. Therefore, you only have to make each VPN server aware of the second IAS server. The second IAS server already has your VPN servers configured as RADIUS clients.
A word about editions: Windows 2003, Web Edition can function as a VPN server but supports only one connection at a time; it can't function as an IAS server. Windows 2003, Standard Edition, Windows 2003, Enterprise Edition, and Windows 2003, Datacenter Edition can be IAS servers and VPN servers. As a VPN server, Windows 2003 Standard supports as many as 1000 VPN clients; as an IAS server, it supports as many as 50 RADIUS clients. Windows 2003 Enterprise and Windows 2003 Datacenter support an unlimited number of VPN and RADIUS clients.
How Remote Access Policies Work
To configure remote access policies, you use the Microsoft Management Console (MMC) Internet Authentication Server snap-in either on the IAS server or on a workstation. An IAS server contains a list of one or more remote access policies, as Figure 1 shows. Each remote access policy has an order number, a list of conditions, a profile, and a remote access permission setting.
Double-clicking a policy in the details pane displays a Properties page similar to the one in Web Figure 2. The Policy conditions section lists the criteria by which IAS chooses which remote access policy to apply to a connection request. You can configure conditions that catch connection requests based on criteria such as group membership, days of the week, and hours of the day. You can select a radio button at the bottom of the Properties page to configure a policy to grant or deny remote access permission according to those conditions. When a remote access policy grants remote access permission, IAS applies the remote access policy profile's policies to a connection request after the request receives its initial authorization. Settings in the policy's profile might result in the connection request ultimately being denied or might have subsequent effects on the connection, such as constraints over the length of time it can remain open or the type of traffic allowed over the connection.
When an Internet user tries to connect to your VPN server, the VPN server contacts the IAS server with the connection request's information. The IAS server determines which remote access policy to apply to this connection request. To do so, IAS processes each policy according to its relative order numbers, from lowest to highest, and compares the connection request information to the policy's conditions.
Web Table 1 describes the types of conditions that you can specify in a remote access policy. If the connection request matches all the specified conditions, IAS selects that policy and doesn't process the rest of the remote access policies. In other words, IAS applies the first remote access policy whose conditions match the connection request. When the policy specifies Deny remote access permission, the IAS server replies to the VPN server accordingly (i.e., denies access to the connecting user). When the policy specifies Grant remote access permission, IAS authenticates the user according to the authentication methods in the policy's profile; I explain how to set up those methods in a moment. When the user's credentials authenticate him or her successfully, the IAS server tells the VPN server to allow the connection and to enforce any limitations defined in the remote access policy's profile. (For more information about profile settings, see the Web-exclusive sidebar "Remote Access Policy Profile Settings," http://www.winnetmag.com/windowssecurity, InstantDoc ID 43455.)
Remote Access Policy Setup
We're ready to set up remote access policies to fit the requirements of the fictitious Acme organization, which we'll assume has already set up a VPN server and an IAS server. Acme allows remote access to two sets of employees: All users have remote access to a server running Microsoft Exchange Server, and telecommuters have full access to the Acme network. Additionally, Acme has an extranet server through which it shares information with business partners, who aren't allowed to access the extranet between 12:00 a.m. and 3:00 a.m. while Acme's systems are updating. Finally, Acme retains a consulting firm, MTG, to provide ongoing Oracle Financials consulting. The consultants can access only Acme's test Oracle system.
Our first step is to create a group in AD for each set of users: Telecommuters, BusinessPartners, and MTGConsultants. We don't need to create a new group for the Exchange users; for our purposes, the Domain Users group will work. Populate each group with the appropriate users. Then, open the Internet Authentication Service snap-in. We'll start by creating the policy for remote access to Exchange:
1.In the Internet Authentication Service window, right-click Remote Access Policies and select New Remote Access Policy.
2.Click Next on the first page of the New Remote Access Policy Wizard, then enter Grant Domain Users remote access to Exchange server and click Next.
3.On the Access Method page, select VPN access. (This page also lets you use IAS to control access to wireless Access Points—APs—and even to switches that support RADIUS authentication.) Click Next.
4.On the User or Group Access page, select Group, which displays the Select Groups window. By default, this window focuses on your local computer's SAM. The group we want to specify is in AD, so click Locations, select your domain, then click OK.
5.Back at the wizard, click Add and enter
Click OK, then Next. On the Authentication Methods page, MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) should already be selected and is appropriate for all our remote access policies. Remember that in "A Secure Wireless Network Is Possible," we configured the VPN server to accept only L2TP/IPSec connections. By the time user authentication occurs over an L2TP/IPSec connection, both computers have already established a mutually authenticated and encrypted connection, so the user-level authentication protocol you select isn't important in this case.
6.Click Next to display the Policy Encryption Level page, which Figure 2, page 12, shows. You can select any combination of Basic, Strong, and Strongest encryption. In our scenario, in which users are limited to connecting through L2TP/IPSec, Basic and Strong require 56-bit Data Encryption Standard (DES) encryption for the IPSec connection. The only other encryption option that Windows supports for IPSec is Triple DES (3DES), which you can specify by selecting Strongest. The VPN server will accept all the encryption levels you enable on this page. The only disadvantage to disabling everything but Strongest is that you place an additional load on the VPN server's CPU, which must encrypt and decrypt traffic for all concurrent connections. The Strongest selection should make little difference to the client because it's encrypting and decrypting traffic only for itself.
7.Click Next, then click Finish.
Our first remote access policy is nearly finished. However, we also want this policy to limit connections to the Exchange server. For an Exchange server whose IP address is 10.42.42.101, follow these steps:
1. Double-click the Grant members of "RemoteExchangeAccess" policy you just created and click Edit profile to display the Edit Dial-in Profile page. The Authentication and Encryption tabs display the settings that you specified in the wizard.
2. At the Edit Dial-in Profile page that Web Figure 3 shows, click the IP tab. You'll see the Inbound Filters dialog box that Web Figure 4 shows. Select the Permit only the packets listed below radio button and click OK. We'll disable all traffic except for traffic to and from computers in the extranet that correspond to the 10.42.43.* subnet.
3.Click Input Filters, which displays the Edit IP Filter dialog box. Select the Destination network check box and type 10.42.42.101 for the IP address. Because we're limiting traffic to a specific address instead of an entire subnet, type 255.255.255.255 for the subnet mask; otherwise, Windows will reject the filter. The Protocol drop-down list lets you limit traffic to specific IP protocols, such as TCP and UDP, then further limit traffic to specific TCP/UDP port numbers.
4.Click OK. Your policy should now look like the one that Web Figure 4 shows.
5.Click OK to close the Inbound Filters window.
6.Back on the IP tab, click Output Filters, then click New. Select Source Network and enter the same IP address and subnet that you used for the inbound filter.
7.Click OK twice to close the policy.
Follow the same procedure for the rest of the remote access policies. For the Telecommuters policy, don't specify any IP filters that will let users access any part of the network. For the BusinessPartners policy, enter 10.42.43.0 as the IP address for both the inbound and outbound filters and 255.255.255.0 as the subnet mask. For the MTGConsultants policy, configure filters to let the consultants access only the Oracle server's IP address.
Now we need to sequence our remote access policies correctly. Remember that IAS selects the first policy whose conditions match the connection request and applies only that policy. The only policy for which sequence really matters is Grant members of "RemoteExchangeAccess". This policy must come after the others because it's based on the Domain Users group, to which all employees belong. If we sequenced Grant members of "RemoteExchangeAccess" as the first policy, everyone who connected would receive access to just the Exchange server. When members of Telecommuters connected, Windows would find Grant members of "RemoteExchangeAccess", see that the Telecommuter member was a member of Domain Users, apply that policy, and stop looking at the other policies. Likewise, consultants and business partners could access the Exchange server—which they shouldn't be able to access—but not the extranet. To change a remote access policy's sequence, right-click the policy in the Internet Authentication Service snap-in window and select Move Up or Move Down to move the policy up or down in the sequence.
Ready, Set, Connect!
Our remote access policies are now ready to go. We have one more consideration, however. By default, the remote access permission that's defined in the user account's dial-in properties takes precedence over the remote access permission that's defined in the remote access policies. You'll need to edit the user's dial-in properties to give priority to the remote access policies' permissions. The Web-exclusive sidebar "Modifying User Dial-In Properties to Work with Remote Access Policies" (http://www.winnetmag.com/windowssecurity, InstantDoc ID 43456) explains how to do this.
Remote access policies give you a flexible and powerful way to centrally control remote access to your LAN and even limit access to specific areas within your LAN according to group membership and other criteria. Such policies are a much better way to control remote access than are individual user configurations because Windows automatically applies the rules you define in the policies to new user accounts and adjusts permissions as group memberships change.