AAA Infrastructure

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:

• Authenticate the credentials of VPN clients

• Authorize the VPN connection

• Record the VPN connection creation and termination for accounting purposes

The AAA infrastructure consists of:

• The VPN server computer

• A RADIUS server computer (optional)

• A domain controller

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:

• IAS performs the authentication of the VPN connection by communicating with a domain controller using a secure RPC channel. IAS performs authorization of the connection attempt through the dial-in properties of the user account and remote access policies configured on the IAS server.

• IAS logs all RADIUS accounting 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 Internet Authentication Service snap-in.

• IAS for Windows Server 2003 also has a new structured query language/Extensible Markup Language (SQL-XML) logging feature that allows logging to be ported to an XML-formatted message and sent to a centralized SQL or Microsoft Data Engine (MSDE) server for consolidated logging. This is an extremely powerful new feature if you have multiple RADIUS/VPN/Wireless 802.1x reporting servers to maintain because it allows all logs to be centrally gathered and analyzed in an SQL database.

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

• Permission

• Profile settings

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:

• NAS-Port-Type. By setting the NAS-Port-Type condition to Virtual (VPN), you can specify all VPN connections.

• Tunnel-Type. By setting the Tunnel-Type to Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP), you can specify different policies for PPTP and L2TP connections.

• Windows-Groups. By setting the Windows-Groups to the appropriate groups, you can grant or deny access based on group membership.

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:

• Dial-in constraints can be used to define how long the connection can exist or be idle before being terminated by the VPN server.

• Through the use of IP packet filters, IP settings can define the specific types of IP traffic that are allowed for remote access VPN connections. With profile packet filters, you can configure the IP traffic that is allowed to be received from remote access clients (Input Filters) or sent to remote access clients (Output Filters) on an exception basis: either all traffic except traffic specified by filters, or no traffic except traffic specified by filters. Remote access policy profile filtering applies to all remote access connections that match the remote access policy.

• Authentication settings can define which authentication protocols the VPN client must use to send its credentials and the configuration of EAP types, such as EAP-TLS.

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:

• Packets originated from the remote access client computer

• Packets sent to the remote access client computer by other computers

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:

• Allow Access

• Deny Access

• Control Access Through Remote Access Policy

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:

• If you have multiple VPN servers and you want to centralize AAA service or a heterogeneous mixture of dial-up and VPN equipment, use a RADIUS server and configure the VPN server for the RADIUS authentication and accounting providers. Using IAS on Windows Server 2003 as the RADIUS server will also allow for SQL-XML logging to handle central analysis and monitoring of the AAA logs.

• If your user account database is a Windows domain, use IAS as your RADIUS server. If you use IAS, install IAS on a domain controller for best performance. Install at least two IAS servers for fail-over and fault tolerance of AAA services.

• Whether you configure them locally or on an IAS server, use remote access policies to authorize VPN connections and specify connection constraints. For example, use remote access policies to grant access based on group membership, to enforce the use of encryption and a specific encryption strength, to specify the use of EAP-TLS, or to limit traffic using IP packet filtering.

• To prevent VPN clients from forwarding routed traffic, configure remote access policy-profile packet filters to discard all traffic on VPN connections except traffic to and from VPN clients. Also, use quarantine features to check for routing enablement on the clients and to turn off the routing on the clients prior to granting access to the network.

• For a large Active Directory domain, nest global groups within universal groups to manage access based on group membership.

• Sensitive fields of RADIUS messages, such as the user password and encryption keys, are encrypted with the RADIUS shared secret configured on the VPN server and the RADIUS server. Make the shared secret a long (22 characters or longer), random sequence of letters, numbers, and symbols. An example of a strong shared secret is 8d#>9fq4bV)H7%a3^jfDe2. To further protect RADIUS traffic, use Windows Server 2003 IPSec policies to provide data confidentiality for all traffic using the RADIUS UDP destination ports (1812 and 1645 for RADIUS authentication traffic, and 1813 and 1646 for RADIUS accounting traffic).