Deploying Virtual Private Networks with Microsoft Windows Server 2003 (Technical Reference)

The authentication, authorization, and accounting (AAA) infrastructure is a vital part of the VPN infrastructure because it is the system that keeps security running on the remote access solution. AAA controls all access to the gateway and handles all single sign-on and resource access issues. AAA infrastructure exists to:

The AAA infrastructure consists of:

As previously discussed, a Windows Server 2003 VPN server can be configured with either Windows or RADIUS as its authentication or accounting provider. RADIUS provides a centralized AAA service when you have multiple VPN servers or a mix of heterogeneous dial-up and VPN equipment. RADIUS is the preferred choice when multiple technologies need authentication services. For instance, if you are running VPN services and wireless 802.1x services on your corporate network, RADIUS can handle the AAA services for both systems simultaneously—thus giving single sign-on to both systems and making them use one common authentication service.

When you configure Windows as the authentication provider, the VPN server performs the authentication of the VPN connection by communicating with a domain controller. The VPN server does this by using a secure remote procedure call (RPC) channel and authorizing the connection attempt through the dial-in properties of the user account and locally configured remote access policies.

When you configure RADIUS as the authentication provider, the VPN server relies on a RADIUS server to perform both the authentication and authorization. When a VPN connection is attempted, the VPN client credentials and other connection parameters are used to create a RADIUS Access-Request message that is sent to the configured RADIUS server. If the connection attempt is both authenticated and authorized, the RADIUS server sends back a RADIUS Access-Accept message. If the connection attempt is either not authenticated or not authorized, the RADIUS server sends back a RADIUS Access-Reject message.

When you configure Windows as the accounting provider, the VPN server logs VPN connection information in a local log file (SystemRoot\System32\LogFiles\Logfile.log by default) based on settings configured on the properties of the Local File object in the Remote Access Logging folder in the Routing And Remote Access snap-in.

When you configure RADIUS as the authentication provider, the VPN server sends RADIUS accounting messages for VPN connections on a RADIUS server, which records the accounting information.

If you are using RADIUS and a Windows domain as the user account database with which to verify user credentials and obtain dial-in properties, we recommend that you use IAS. IAS is a full-featured RADIUS server (for Windows 2000 Server and Windows Server 2003) that is tightly integrated with Active Directory and the Routing And Remote Access service. IAS for Windows Server 2003 also supports a RADIUS proxy.

When IAS is used as the RADIUS server:

Remote Access Policies

Remote access policies are an ordered set of rules that define how connections are either accepted or rejected. For connections that are accepted, remote access policies can also define connection restrictions. For each rule, there are one or more conditions, a set of profile settings, and a remote access permission setting. Connection attempts are evaluated against the remote access policies in order, trying to determine whether the connection attempt matches all the conditions of each policy. If the connection attempt does not match all the conditions of any policy, the connection attempt is rejected.

If a connection matches all the conditions of a remote access policy and is granted remote access permission, the remote access policy profile specifies a set of connection restrictions. The dial-in properties of the user account also provide a set of restrictions. Where applicable, user account connection restrictions override the remote access policy profile connection restrictions.

Remote access policies consist of the following elements:

Conditions

Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt. If there are multiple conditions, all of the conditions must match the settings of the connection attempt in order for it to match the policy. For VPN connections, you commonly use the following conditions:

Permission

You can use the permission setting to either grant or deny remote access for the connection attempt if the remote access permission of the user account is set to Control Access Through Remote Access Policy. Otherwise, the remote access permission setting on the user account determines the remote access permission.

Profile Settings

A remote access policy profile is a set of properties that are applied to a connection when it is authorized. For VPN connections, you can use the following profile settings:

Encryption settings can define whether encryption is required and, if so, the encryption strength. For encryption strengths, Windows Server 2003 supports Basic (40-bit MPPE for PPTP and 56-bit Data Encryption Standard [DES] for L2TP), Strong (56-bit MPPE for PPTP and 56-bit DES for L2TP), or Strongest (128-bit MPPE for PPTP and 3DES for L2TP).

The Diffie-Hellman key strength can be used at the default 1024-bit strength or, by using a registry setting on the server, you can use 2048-bit strength.

Note

2048-bit strength should be used only in special circumstances because there can be a significant performance hit on the server when using that high of a bit strength.

With the inclusion of the NAT-T hotfix for Window 2000 and Windows XP, 2048-bit strength is enabled by default on the client. Windows Server 2003 will use 1024-bit strength by default and will use 2048-bit strength only if the [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\NegotiateDH2048 following registry key is set to 1 (data type is DWORD).

For example, you can create a Windows group named VPNUsers whose members are the user accounts of the users creating remote access VPN connections across the Internet. Then you can create a policy with two conditions: NAS-Port-Type is set to Virtual (VPN), and Windows-Group is set to VPNUsers. Finally, you would configure the profile for the policy for a specific authentication method and encryption strength.

Preventing Traffic Routed from VPN Clients

Once a VPN client successfully establishes a PPTP or L2TP connection, by default any packet sent over the connection is received by the VPN server and forwarded. Packets sent over the connection can include:

When the remote access client computer makes the VPN connection, by default it creates a default route so that all traffic that matches the default route is sent over the VPN connection. If other computers are forwarding traffic to the remote access VPN client, treating the remote access client computer as a router, that traffic is also forwarded across the VPN connection. This is a security problem because the VPN server has not authenticated the computer that is forwarding traffic to the remote access VPN client. The computer forwarding traffic to the remote access VPN client computer has the same network access as the authenticated remote access VPN client computer. As mentioned earlier, this is the security risk of split-tunneling. One way to prevent this is to make sure routing is turned off on the client systems during quarantine checks. If grouting cannot be turned off for functional application requirements, you should configure remote access policy packet filters on the remote access policy that is used for your VPN connections. Doing this will prevent unauthorized access to the intranet.

For the Input Filters, set the filter action to Permit Only The Packets Listed Below and configure a single filter with the settings listed in Table 5-2.

Table 5-2: Input Filter Settings

IP Packet Filter Field

Setting

Source Address

User’s Address

Source Network Mask

User’s Mask

Destination Address

Any

Destination Network Mask

Any

Protocol

Any

For the Output Filters, set the filter action to Permit Only The Packets Listed Below and configure a single filter with the settings listed in Table 5-3.

Table 5-3: Output Filter Settings

IP Packet Filter Field

Setting

Source Address

Any

Source Network Mask

Any

Destination Address

User’s Address

Destination Network Mask

User’s Mask

Protocol

Any

Note

Although the Routing And Remote Access snap-in displays User’s Address and User’s Mask, the actual filter that is created for each remote access client is for the client’s assigned IP address and a subnet mask of 255.255.255.255. The default policy named Connections To Microsoft Routing And Remote Access Server has the input packet filters previously described already configured.

With this set of IP packet filters, the VPN server discards all traffic sent across the VPN connection except traffic that either originated from or is sent to authenticated remote access VPN clients.

Windows Domain User Accounts and Groups

Windows NT 4.0 domains, mixed-mode Active Directory domains, and native-mode Active Directory domains contain the user accounts and groups used by the Routing And Remote Access service and IAS to authenticate and authorize VPN connection attempts. User accounts contain the user name and a form of the user’s password that can be used for validation of the VPN client’s user credentials. Additional account properties determine whether the user account is enabled or disabled, locked out, or permitted to log on only during specific hours. If a user account is disabled, locked out, or not permitted to log on during the time of the VPN connection, the VPN connection attempt is rejected.

User accounts also contain dial-in settings. The dial-in setting most relevant for VPN connections is the remote access permission setting, which has the following values:

The Allow Access and Deny Access settings explicitly allow or deny remote access and are equivalent to the remote access permission setting of Windows NT 4.0 domain accounts. When you use the Control Access Through Remote Access Policy setting, the remote access permission is determined by the remote access permission setting of the matching remote access policy. If the user account is in a mixed- mode domain, the Control Access Through Remote Access Policy setting is not available and you must manage remote access permission on a per-user basis. If the user account is in a native-mode domain, the Control Access Through Remote Access Policy setting is available and you can manage remote access permission on a per-user basis or by using groups.

When using groups to manage access, you can use your existing groups and create remote access policies that either allow or reject access or restrict access based on the group name. For example, the Employees group might have no VPN remote access restrictions; however, the Contractors group might be allowed to create VPN connections only during business hours. Alternately, you can create groups based on the type of connection being made. For example, you can create a VPNUsers group and add as members all the user accounts allowed to create VPN connections.

Both the Routing And Remote Access service and IAS can use Active Directory user principal names (UPNs) and universal groups. In a large domain with thousands of users, create a universal group for all users for whom you want to allow access, and then create a remote access policy that grants access for this universal group. Do not put all your user accounts directly into the universal group, especially if you have a large number of them on your network. Instead, create separate global groups that are members of the universal group, and add users to those global groups.

Design Point: AAA Infrastructure

Consider the following when configuring the AAA infrastructure for remote access VPN connections:

Категории