Windows Server 2003 : Authorizing Remote Access Connections (part 2) - Understanding Remote Access Policies

Understanding Remote Access Policies

A remote access policy is a set of permissions or restrictions, read by a remote access authenticating server, that applies to remote access connections. Many remote access policies can be stored on an authenticating server at any given time, but only one policy can be applied to a connection. To determine which policy is applied, the conditions of each remote access policy are compared individually to the current remote access connection. Only the first matching policy is applied to the remote access connection; if no policy matches the connection, the connection is blocked.

You can view currently configured remote access policies in the Routing And Remote Access console by selecting the Remote Access Policies node in the console tree, as shown in Figure 2.

Figure 2. Viewing remote access policies

Remote access policies are unique to each local machine but not unique to Routing And Remote Access. Once created, they can be read either by Routing And Remote Access or by a RADIUS server configured on the local machine. Similarly, you cannot remove remote access policies simply by disabling Routing And Remote Access. They are written to the local hard disk and stored until they are specifically deleted either from the Routing And Remote Access console or from the Internet Authentication Service console (the administrative tool for RADIUS servers).

By default, two remote access policies are preconfigured in Windows Server 2003. The first default policy is Connections To Microsoft Routing And Remote Access Server. This policy is configured to match every remote access connection to the Routing And Remote Access service. When Routing And Remote Access is reading this policy, the policy naturally matches every incoming connection. However, when the policy is being read by a RADIUS server, network access might be provided by a non-Microsoft vendor; consequently, this policy will not match those connections.

The second default remote access policy is Connections To Other Access Servers. This policy is configured to match every incoming connection regardless of network access server type; however, because the first policy matches all connections to Routing And Remote Access, only connections to other remote access servers read and match the policy when the default policy order is not changed. Unless the first policy is deleted or the default policy order is rearranged, this second policy can be read only by RADIUS servers.

Policy Conditions

Each remote access policy is based on policy conditions that determine when the policy is applied. For example, a policy might include a condition that Windows-Groups matches DOMAIN1\Telecommuters; this policy would then match a connection whose user belongs to the Windows global security group Telecommuters. Figure 3 shows such a policy.

Clicking the Add button opens the Select Attribute dialog box, which allows you to add a new category for a remote access policy condition. For example, the NAS-IP-Address attribute allows a RADIUS server to distinguish remote access clients connecting through a particular remote access server (as distinguished by IP address). Figure 4 shows the Select Attribute dialog box and its associated set of configurable attributes.

By clicking the Add button in the Select Attribute dialog box, you can open a dialog box that allows you to configure the condition for a specific attribute. For example, if you click the Add button when the Authentication-Type attribute is selected, the Authentication-Type dialog box opens, as shown in Figure 5. This dialog box allows you to choose which remote access connections, as specified by authentication protocol, will match the policy. In the example given, the policy is configured to match unauthenticated connections. Similarly, you can specify the particular elements for any attribute you choose to serve as the conditions for a policy.

Remote Access Permission

Every remote access policy specifies whether the connection matching the policy is allowed or denied. These permission settings correspond to the Grant Remote Access Permission option and the Deny Remote Access Permission option, respectively, which can be seen in Figure 3. Remember that this setting is normally overridden by the Allow Access option (outside of Windows 2000 mixed-mode domains) or the Deny Access option in the dial-in properties for an individual user account.

Policy Profile

A remote access policy profile consists of a set of dial-up constraints and properties that can be applied to a connection. You can configure a remote access policy profile by clicking the Edit Profile button in the policy properties dialog box, shown in Figure 3. Clicking this button opens the Edit Dial-In Profile dialog box, shown in Figure 6. By default, the policy profile is not configured; consequently, no additional restrictions or properties are applied to the connection.

The following sections describe the six tabs found in the policy profile.

Dial-In Constraints Tab

This tab allows you to set the following dial-up constraints:

• Minutes Server Can Remain Idle Before It Is Disconnected

• Minutes Client Can Be Connected

• Allow Access Only On These Days And At These Times

• Allow Access Only To This Number

• Allow Access Only Through These Media

IP Tab

You can set IP properties that specify IP address assignment behavior. You have the following options:

• Server Must Supply An IP Address.

• Client May Request An IP Address.

• Server Settings Determine IP Address Assignment (the default setting).

• Assign A Static IP Address. The IP address assigned is typically used to accommodate vendor-specific attributes for IP addresses.

You can also use the IP tab to define IP packet filters that apply to remote access connection traffic. 

Multilink Tab

You can set Multilink properties that both enable Multilink and determine the maximum number of ports (modems) that a Multilink connection can use. Additionally, you can set Bandwidth Allocation Protocol (BAP) policies that both determine BAP usage and specify when extra BAP lines are dropped. The Multilink and BAP properties are specific to the Routing And Remote Access service. By default, Multilink and BAP are disabled.

The Routing And Remote Access service must have Multilink and BAP enabled for the Multilink properties of the profile to be enforced.

Authentication Tab

You can set authentication properties to both enable the authentication types that are allowed for a connection and specify the EAP type that must be used. Additionally, you can configure the EAP type. By default, MS-CHAP and MS-CHAP v2 are enabled. In Windows Server 2003, you can specify whether users can change their expired passwords by using MS-CHAP and MS-CHAP v2 (enabled by default).

The Routing And Remote Access service must have the corresponding authentication types enabled for the authentication properties of the profile to be enforced.

Encryption Tab

Windows Server 2003 supports two general methods for the encryption of remote access connection data: Rivest-Shamir Adleman (RSA) RC4, and Data Encryption Standard (DES). RSA RC4 is the family of algorithms used in MPPE, the encryption type used with the MS-CHAP or EAP-TLS authentication protocols in both dial-up and Point-to-Point Tunneling Protocol (PPTP)–based VPN connections. DES, meanwhile, is the general encryption scheme most commonly used with Internet Protocol Security (IPSec), the security standard used with the Layer 2 Tunneling Protocol (L2TP) authentication protocol in VPNs.

Both MPPE and IPSec support multiple levels of encryption, as shown in Table 1.

The settings on the Encryption tab in a remote access policy profile, shown in Figure 7, enable you to specify allowable encryption levels in a manner independent of encryption type. However, the nature of each encryption level varies with the encryption scheme used, as explained after the figure.

• Basic Encryption (MPPE 40-Bit) For dial-up and PPTP-based VPN connections, MPPE is used with a 40-bit key. For L2TP/IPSec VPN connections, 56-bit DES encryption is used.

• Strong Encryption (MPPE 56-Bit) For dial-up and PPTP VPN connections, MPPE is used with a 56-bit key. For L2TP/IPSec VPN connections, 56-bit DES encryption is used.

• Strongest Encryption (MPPE 128-Bit) For dial-up and PPTP VPN connections, MPPE is used with a 128-bit key. For L2TP/IPSec VPN connections, 168-bit triple DES encryption is used.

• No Encryption This option allows unencrypted connections matching the remote access policy conditions. To require encryption, clear this option.

Advanced Tab

You can set advanced properties to specify the series of RADIUS attributes that are sent back by the IAS server to be evaluated by the NAS server/ RADIUS client. These settings are used only by RADIUS servers and are not read by Routing And Remote Access.

Exploring Remote Access Authorization Scenarios

The following selection presents a summary of the remote access authorization process. In each scenario, authorization settings at the remote access server differ when User1, a member of the Telecommuters group, attempts to connect through a dial-up line. Figure 8 shows the order of remote access policies defined at the server.

For each of User1’s connection attempts, up to three sets of permissions and settings are applied, in the following order:

In scenario #1, shown in Figure 9, the remote access permission for User1’s account has been left at the default setting: Control Access Through Remote Access Policy. Consequently, the remote access permission specified in the first matching remote access policy is applied to the connection. The first matching remote access policy, named Telecommuters, is configured to allow remote access for the Telecommuters security group.

Figure 9. Remote access authorization scenario #1

Once the remote access permission of the Telecommuters policy is applied, the profile of the policy is verified. In this case, the Telecommuters policy profile permits access on all days except Sundays. The end result of these server settings is that User1 is permitted access unless the day is Sunday.

In scenario #2, shown in Figure 10, the remote access permission for User1’s account is again left at the default setting. As a result, the remote access policy again determines the remote access permission. In this case, however, the Telecommuters policy has been configured to deny access to the Telecommuters group. As a result, User1’s connection attempt is blocked, and the policy profile is not read.

Scenario #3 is illustrated in Figure 11. In this scenario, the remote access permission for User1’s account has been modified from the default setting to Allow Access. In this case, the remote access permission setting is ignored in the Telecommuters remote access policy. However, the policy profile is still read and applied. As a result, User1 is permitted remote access unless the day is Sunday.

In scenario #4, illustrated in Figure 12, the remote access permission for User1’s account has been modified from the default setting to Deny Access. As a result of this server setting, the remote access connection is blocked, and no remote access policy or accompanying profile is read.

In the final remote access authorization scenario, the remote access policies are deleted at the server. As a result, no matching policy can be applied to the inbound remote access connection. The connection request is thus denied regardless of the remote access permission for User1’s account, which in this case is set to Allow Access. Scenario #5 is illustrated in Figure 13.