Creating a Remote Access Policy Strategy

Remote clients connect to the network by using remote access policies. Plan an authorization method for security, and then plan your user groups and user accounts. Next, create your remote access policies to centralize management. Figure 7.10 illustrates this process.

Figure 7.10: Creating a Remote Access Policy Strategy

Establish a Remote Client Access Authorization Method

You can use remote access policies to authorize remote client access either by group or by user.

If you authorize access by group, you can restrict network access based on an account's group membership. For example, you can create one group for wireless users and another group for dial-in users, and create separate remote access policies for each group by using the Windows-Groups attribute (condition) of the remote access policy.

To authorize access by group in a Windows Server 2003 or a Windows 2000 native domain, set the remote access permission on every user account to Control access through Remote Access Policy. Remote access permissions are then determined by the remote access permission setting on the remote access policy.

For more information, see "Remote access policies" in Help and Support Center for Windows Server 2003.

Plan Remote Access Policy Groups

You can manage remote access authorization by user or by group. By using the Active Directory Users and Computers snap-in, you can create groups to which specific IAS remote access policies are applied, allowing you to grant different types of remote access to different groups. The functional level of the domain impacts the type of group that you can use.

In Windows Server 2003 domains or Windows 2000 native-mode domains, you can use universal and global groups as follows:

• Universal groups can include groups and accounts from any Windows Server 2003 or Windows 2000 domain in the domain tree or forest and can be granted permissions in any domain in the domain tree or forest.

• Global groups can include groups and accounts only from the domain in which the group is defined and can be granted permissions in any domain in the forest.

In Windows Server 2003 interim domains or Windows 2000 mixed-mode domains, you can use only global groups. Domain local groups cannot be used because they are created in a single domain, are visible only in that domain, and can be assigned permissions only to resources within that domain.

For more information about remote access policies, see "Remote access policies" in Help and Support Center for Windows Server 2003.

For more information about functional levels, see "Domain and forest functionality" in Help and Support Center for Windows Server 2003.

Plan the User Accounts

In Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, the user account for a stand-alone server or server running Active Directory contains a set of dial-in properties that are used when performing authorization (allowing or denying a connection attempt made by a user). On a stand-alone server, you can set the dial-in properties on the Dial-in tab in the user account in the Local Users and Groups dialog box. On a server running Active Directory, you can set the dial-in properties on the Dial-in tab in the user account in the Active Directory Users and Computers snap-in. On these servers, you cannot use the Windows NT 4.0 User Manager for Domains administrative tool.

In Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition, you can configure a RADIUS attribute to ignore the dial-in properties of user and computer accounts in the profile properties of a remote access policy. To support multiple types of connections for which IAS provides authentication and authorization, it might be necessary to disable the processing of user account dial-in properties. This can be done to support scenarios in which specific dial-in properties are not required and is accomplished by configuring the Ignore-User-Dialin-Properties attribute on the Advanced tab of the profile settings for a remote access policy.

Computer accounts also have dial-in properties that are similar to user accounts. Therefore computers can be authenticated as if they were users when an IEEE 802.1X Ethernet client uses EAP-TLS and an installed computer certificate to authenticate itself to an Ethernet switch. Note that the Ignore-User-Dialin-Properties attribute disables the use of all dial-in properties for the user account. Specific dial-in properties cannot be individually disabled.

For more information about planning user accounts, see "Dial-in properties of a user account" in Help and Support Center for Windows Server 2003.

Configure Remote Access Policies

You can create multiple remote access policies to accommodate the individual security requirements of your remote connections. For example, you can use remote access policies to grant or deny authorization according to the time of day and the day of the week, the Windows Server 2003 or Windows 2000 Server group to which the remote access user belongs, the type of connection being requested (dial-up networking or VPN connection), and so on. You can also configure settings within the remote access policies that limit the maximum session time, specify the authentication and encryption strengths, set Bandwidth Allocation Protocol (BAP) policies, and so forth.

Remote access policies are applied in the order in which they are listed. When a policy is found that contains conditions that match the connection attempt, access is granted or denied, regardless of the conditions specified by the other policies later in the list. Therefore, it is a good idea to list more specific remote access policies before general remote access policies.

If you do not implement any remote access policies, all connection attempts fail.

Before you configure remote access policies, you must make decisions about the following:

• Whether to use Network Access Quarantine Control for VPN and dial-up connections.

• Whether to use custom or common policies. When you use the New Remote Access Policy Wizard in the IAS snap-in, you can choose to create a common or a custom policy. For a common policy, you must configure an access method, whether to grant access permissions by user or by group, authentication methods, and levels of allowed encryption (depending on the access method selected). For a custom policy, you must configure a set of policy conditions, whether remote access permission for the policy is granted or denied, and remote access policy profile settings. For more information, see "Add a remote access policy" in Help and Support Center for Windows Server 2003.

• The groups and users to which the remote access policies apply.

• Whether the remote access policy grants or denies access to the users or the group.

• The restrictions that are placed on the users or the group.

For more information about Internet Authentication Service, including remote access policies, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Using Network Access Quarantine Control

Network Access Quarantine Control provides phased network access for client computers that connect to the network by using VPN or dial-up remote access. By using connection request policies and remote access policies, you can apply the MS-Quarantine-IPFilter attribute, the MS-Quarantine-Session-Timeout attribute, or both attributes to restrict clients to quarantine mode. During quarantine mode, an administrator-provided network policy requirements script is run on the client computer. After the client computer configuration is either brought into or determined to be in accordance with your organization's network policy, quarantine mode is removed by the network access server, and standard remote access policy is applied to the connection.

You can implement Network Access Quarantine Control with one or more servers running Windows Server 2003 and the Routing and Remote Access service, one or more servers running Windows Server 2003 and IAS, a Connection Manager (CM) profile created with Connection Manager Administration Kit (CMAK), an administrator-provided script, and two additional components: the notifier component and the listener component. You can create your own notifier and listener components, or you can use Rqs.exe (a listener component) and Rqc.exe (a notifier component), which are available in the Windows Deployment and Resource Kits.

For more information, see "Deploying Dial-up and VPN Remote Access Servers" and "Deploying Remote Access Clients Using Connection Manager" in this book.

Using Common vs. Custom Policies

You must decide whether to use common or custom policies:

• A common policy includes typical settings for a particular access method.

• A custom policy includes a detailed configuration of a particular access method.

Create Specifications for a Common Policy

To create a common or custom policy, you must specify the following:

• An access method. The access method is used to configure the access server Port Type condition automatically. You can choose one of the following four access methods:

  • VPN access

  • Dial-up access

  • Wireless access

  • Ethernet switch access

• Whether to grant access permissions by user or by group. If you choose to grant access by group, the Windows-Groups condition is automatically set to the chosen groups.

• Authentication methods. For more information about how to configure authentication methods, see "Configure authentication" in Help and Support Center for Windows Server 2003.

• Levels of allowed encryption (depending on the access method chosen). For more information about how to configure encryption, see "Configure encryption" in Help and Support Center for Windows Server 2003.

When you create a common policy, the remote access permission is always set to Grant remote access permission.

Create Specifications for a Custom Policy

For each custom policy, create detailed specifications for the following elements:

• Conditions. Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt.

• Remote access permission. Specify whether the permission is granted or denied if the conditions of a remote access policy are met.

• Profile. Specify the remote access policy profile properties to set dial-in constraints and other restrictions.

For specific information about settings for each element, see Help and Support for Windows Server 2003 or the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Note

Not all network access servers send all of the RADIUS attributes. Consult the documentation for your network access server to see which attributes it sends.

Conditions

Specify the remote access conditions for each policy. Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt. In order for the connection attempt to match the policy, all conditions must match the settings of the connection attempt. Remote access policy profile settings are applied only if the connection attempt matches the policy. Thus, remote access policies are applied only if the connection attempt matches all of the conditions of the policy.

Permission

Specify whether the permission is granted or denied if the conditions of a remote access policy are met. You use the Grant remote access permission option or the Deny remote access permission option to set remote access permission for a policy.

During the authorization process, the dial-in properties of user accounts are evaluated before remote access policy is applied. If the dial-in properties for the user account are set to Deny access, the connection attempt is rejected and remote access policies are not evaluated. When dial-in properties for the user account are set to Control access through Remote Access Policy, the remote access policy alone determines whether the user is granted access.

When the dial-in properties for the user account are set to Grant access, remote access policies are evaluated next. In this circumstance it is possible for the user to be denied access by settings in the remote access policy. For example, if the remote access policy is configured to allow the user to connect only between the hours of 8 AM and 5 PM and the user is attempting to connect at 6 PM, the connection attempt fails due to the settings in the remote access policy.

Profile

Specify the remote access policy profile properties to set dial-in constraints and other restrictions. These properties are applied to a connection after the connection is authorized, whether the connection has been authorized through the user account permission setting or the remote access policy.

You can use these properties to specify the series of RADIUS attributes that are sent back to the RADIUS client by the IAS server, including any vendor-specific attributes you are using. For more information about VSAs, see "Configuring IAS for Compatibility with a Third-Party Access Server" later in this chapter.

Note

Elements of a remote access policy correspond to RADIUS attributes that are used during RADIUS-based authentication. For an IAS server, verify that the network access servers that you use are sending the RADIUS attributes that correspond to the configured remote access policy conditions and profile settings. If an access server does not send a RADIUS attribute that corresponds to a remote access policy condition or profile setting, then all RADIUS authentications from that access server are denied.

Apply Policies to Users and Groups

If you are controlling remote client access by means of groups, you must determine which groups the policies that you create will apply to. If you are using nested groups, make sure that policies configured for the parent group do not conflict with policies configured for the nested group.

If you are controlling remote client access by means of the access-by-user administrative model, you must establish the criteria that you use to determine whether the policy is applied; for example, you can use the client name, client IP address, access server IP address, or any other condition attribute.

Two of the attributes, NAS-Port-Type and Tunnel-Type, deserve special mention because they are used to support VPN, wireless, and authenticating switch access clients:

• The NAS-Port-Type attribute. This attribute allows you to specify the type of physical port that is used by the access server originating the request.

• The Tunnel-Type attribute. This attribute allows you to specify the type of tunnel that the access server can create. You can specify either Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP).

For a detailed list of condition attributes, see "Connection request policies" in Help and Support Center for Windows Server 2003 and the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Determine Which Restrictions to Apply

You can specify dial-in conditions or any other profile property to restrict access. For a detailed list of profile properties that can be used to restrict access, see "Introduction to remote access policies" in Help and Support Center for Windows Server 2003 or the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

To achieve the highest level of security possible, begin by granting the least amount of access possible and increase access only when necessary.

Configure Client-Specific Remote Access Policies

Different types of remote access clients need different settings in their remote access policies. The following sections describe design considerations for creating the different types of policies.

Configure Remote Access Policies for VPN Clients

For VPN clients, use the Tunnel-Type attribute to specify the type of tunnel that is created by the requesting client. Tunnel types include the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol (L2TP), which are used by remote access clients and demand-dial routers running Windows XP; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; and Windows 2000. You can use this condition to specify profile settings, such as authentication methods or encryption strengths for a specific type of tunneling technology.

Configure Remote Access Policies for Wireless Access Clients

For wireless access clients, create a wireless remote access policy, and then add the condition NAS-Port-Type with the values Wireless-IEEE 802.11 and Wireless-Other.

For more information, see "Wireless access example" in Help and Support Center for Windows Server 2003.

Configure Remote Access Policies for Authenticating Switch Access Clients

For authenticating switch access clients, specify the use of the Ethernet port type for the NAS-Port-Type attribute. By using this port type, you create a separate remote access policy that contains connection parameters specifically designed for authenticating switch nodes.

Configure a Quarantine Remote Access Policy

When deploying Network Access Quarantine Control, create a new policy called Quarantine Remote Access Policy, and then choose whether to quarantine clients with IP filters, whether to apply a session timer when clients connect to VPN or dial-up servers, or whether to apply both attributes to the connections. Specify the use of the MS-Quarantine-IPFilter attribute if you want to apply IP filters that restrict client access to the network. Specify the use of the MS-Quarantine-Session-Timeout attribute if you want to set a restriction on the amount of time the client network policy requirements script has to notify the access server that it has run successfully. When you create a Quarantine Remote Access Policy, position it as the first remote access policy so that it is evaluated before other policies.

Quarantine IP filters and session timers are for use only with the Windows Server 2003 Routing and Remote Access service.

For more information, see "Deploying Dial-up and VPN Remote Access Servers" and "Deploying Remote Access Clients Using Connection Manager" in this book.