Remote Access Policies
In Windows NT 4.0, remote access privileges were granted based solely on a dial-in permission assigned to a user. In Windows 2000, remote access connections are granted based on the dial-in properties of a user object and remote access policies. Remote access policies are a set of conditions and connection parameters that administrators can use to get more flexibility in granting remote access permissions and usage. Remote access policies are stored on the local computer and are shared between the Routing and Remote Access service and IAS.
By using remote access policies, an administrator can specify remote access permissions by the time of day and day of the week, by the Windows 2000 group to which the remote access user belongs, by the type of connection being requested (dial-in or virtual private network connection), and so on. You can configure settings that limit the maximum session time, specify the authentication and encryption methods, set Bandwidth Allocation Protocol (BAP) policies, and so on.
It is important to remember that a remote connection is accepted only if the settings of the connection attempt match at least one of remote access policies (subject to the conditions of the dial-in properties of the user object and the profile properties of the remote access policy). If the settings of the connection attempt do not match at least one of the remote access policies, the connection attempt is rejected regardless of the dial-in properties of the user account.
For Windows 2000 IAS servers, remote access policies are administered from the Routing and Remote Access administrative tool (when configured for Windows authentication) or the Internet Authentication Service administrative tool.
.gif "note-icon")
Note
Windows 2000 supports customized authorization through the use of the Software Development Kit.
Local vs. Centralized Policy Management
Because remote access policies are stored locally on either a remote access server or an IAS server, for centralized management of a single set of remote access policies for multiple remote access or VPN servers, you must do the following steps:
Install the Windows 2000 Internet Authentication Service (IAS) as a Remote Authentication Dial-In User Service (RADIUS) server on a computer.
Configure IAS with RADIUS clients that correspond to each of the Windows 2000 remote access or VPN servers.
On the IAS server, create the central set of policies that all Windows 2000 remote access servers are using.
Configure each of the Windows 2000 remote access servers as a RADIUS client to the IAS server.
After you configure a Windows 2000 remote access server as a RADIUS client to an IAS server, the local remote access policies stored on the remote access server are no longer used.
Centralized management of remote access policies are also used when you have remote access servers that are running Windows NT 4.0 with the Routing and Remote Access Service (RRAS). You can configure the server that is running Windows NT 4.0 with RRAS as a RADIUS client to an IAS server. You cannot configure a remote access server that is running Windows NT 4.0 without RRAS to take advantage of centralized remote access policies.
Dial-in Properties of a User Object
In Windows 2000, the user object for a stand-alone or Active Directory–based server contains a set of dial-in properties that are used when allowing or denying a connection attempt made by a user. For a stand-alone server, the dial-in properties are available on the Dial-in tab of the user object in the local User Manager. For an Active Directory–based server, the dial-in properties are available on the Dial-in tab of the user object in Active Directory Users and Computers snap-in. The Windows NT 4.0 User Manager for Domains administrative tool cannot be used for Active Directory–based servers.
The dial-in properties for a user object are the following:
Remote Access Permission (Dial-in or VPN)
Use this property to set whether remote access is explicitly allowed, denied, or determined through remote access policies. If access is explicitly allowed, remote access policy conditions or user object or profile properties can override the setting. The Control access through Remote Access Policy option is available only on user objects for stand-alone Windows 2000 Routing and Remote Access service servers or members of a native Windows 2000 domain. This option is not available in Windows Server 2003, operating in mixed mode.
By default, the Administrator and Guest accounts on a stand-alone remote access server or in a Windows 2000 native-mode domain are set to Control access through Remote Access Policy and for a Windows 2000 mixed-mode domain are set to Deny access . New accounts created on a stand-alone remote access server or in a Windows 2000 native-mode domain are set to Control access through Remote Access Policy . New accounts created in a Windows 2000 mixed-mode domain are set to Deny access .Verify Caller ID
If this property is enabled, the server verifies the caller's phone number. If the caller's phone number does not match the configured phone number, the connection attempt is denied.
Caller ID must be supported by the caller, the phone system between the caller and the Routing and Remote Access service server, as well as by the Routing and Remote Access service server. Caller ID on the Routing and Remote Access service server consists of call answering equipment that supports the passing of Caller ID information and appropriate driver inside Windows 2000 that support the passing of Caller ID information to the Routing and Remote Access service.
If you configure a Caller ID phone number for a user and you do not have support for the passing of Caller ID information all the way from the caller to the Routing and Remote Access service, the connection attempt is denied.Callback Options
If this property is enabled, the server calls the caller back during the connection establishment at a phone number set by the caller or a specific phone number set by the administrator.Assign a Static IP Address
If this property is enabled, the administrator assigns a specific IP address to the user when the connection is made.Apply Static Routes
If this property enabled, the administrator defines a series of static IP routes that are added to the routing table of the remote access server when a connection is made. This setting is designed for user accounts that Windows 2000 routers use for demand-dial routing.
If a Windows 2000 Routing and Remote Access service server is a member of a Windows NT 4.0 domain or a Windows 2000 mixed domain, then:
Only the Remote Access Permission (Allow access and Deny access options) and Callback Options dial-in properties are available.
The User Manager for Domains administrative tool can be used to grant or deny dial-in access and set callback options.
If the Windows 2000 Routing and Remote Access service server is a stand-alone server or a member of a Windows 2000 native domain, the callback number can be of unlimited size. If a Windows 2000 Routing and Remote Access service server is a member of a Windows NT 4.0 domain or a Windows 2000 mixed domain, the callback number can only be 128 characters long. Callback numbers that are long than 128 characters are truncated during a callback connection attempt, which results in a failed callback connection.
When a Windows NT 4.0 RAS server uses a native 2000 domain to obtain the dial-in properties of a user account, the Control access through Remote Access Policy option is interpreted as Deny access . Callback settings are interpreted correctly.
User accounts upgraded to Windows 2000 that were configured with dial-in permission enabled are set to Allow access . User accounts upgraded to Windows 2000 that were configured with dial-in permission disabled are set to Control access through Remote Access Policy .
A Windows NT 4.0 RAS server does not use remote access policies. It is recommended that you upgrade Windows NT 4.0 RAS servers to take advantage of remote access policies.
Elements of a Remote Access Policy
A remote access policy is a named rule that consists 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 the connection attempt to match the policy.
Table 8.3 shows the condition attributes that you can set for a remote access policy.
Table 8.3 Condition Attributes for a Remote Access Policy
Attribute Name |
Description |
|---|---|
NAS IP Address |
The IP address of the network access server (NAS). This attribute is a character string. You can use pattern matching syntax to specify IP networks. This attribute is designed for the IAS server. |
Service Type |
The type of service being requested. Examples include framed (such as PPP connections) and login (such as Telnet connections). For more information about RADIUS service types, see RFC 2138. This attribute is designed for the IAS server. |
Framed Protocol |
The type of framing for incoming packets. Examples are PPP, AppleTalk, SLIP, Frame Relay, and X.25. This attribute is designed for the IAS server. |
Called Station ID |
The phone number of the NAS. This attribute is a character string. You can use pattern matching syntax to specify area codes. In order to receive called station ID information during a call, the phone line, the hardware, and the Windows 2000 driver for the hardware must support the passing of the called ID. Otherwise, the called station ID is manually set for each port. |
Calling Station ID |
The phone number used by the caller. This attribute is a character string. You can use pattern matching syntax to specify area codes. |
NAS Port Type |
The type of media used by the caller. Examples are analog phone lines (also known as "asynch"), ISDN, and tunnels or virtual private networks (known as virtual). |
Day and Time Restrictions |
The day of the week and the time of day of the connection attempt of the server. |
Client IP Address |
The IP address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern matching syntax to specify IP networks. This Attribute is designed for the IAS server. |
NAS Manufacturer |
The vendor of NAS requesting authentication. The Windows 2000 remote access server is the Microsoft RAS NAS manufacturer. You can use this Attribute to configure separate policies for different NAS manufacturers who are RADIUS clients to an IAS server. This Attribute is designed for the IAS server. |
Client Friendly Name |
The name of the RADIUS client computer that is requesting authentication. This Attribute is a character string. You can use pattern matching syntax to specify client names. This Attribute is designed for the IAS server. |
Windows Groups |
The names of the Windows groups to which the user attempting the connection belongs. There is no condition attribute for a specific user name. It is not necessary to have a separate remote access policy for each group. Instead, you can use nested groups to consolidate group membership and delegate administration of group membership. For a Windows 2000 native mode domain-based remote access or IAS server, it is recommended that you use universal groups. |
Tunnel Type |
The type of tunnel being created by the requesting client. Tunnel types include the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol (L2TP) used by Windows 2000 remote access clients and demand-dial routers. You can use this condition to specify profile settings such as authentication methods or encryption strengths for a specific type of tunneling technology. |
Note
If conditions that use an Attribute designed for the IAS server are evaluated against a remote access server connection attempt, the result is no match and the policy is not applied.
Not all network access servers send all of the IAS server-specific attributes.
You cannot use the built-in local groups of a stand-alone remote access server that is running Windows 2000 for the Windows Groups attribute.
Remote Access Permission
If all the conditions of a remote access policy are met, remote access permission is either granted or denied. Use the Grant remote access permission option or the Deny remote access permission option to set remote access permission for a policy.
Remote access permission is also granted or denied for each user account. The user remote access permission overrides the policy remote access permission. When remote access permission on a user account is set to the Control access through Remote Access Policy option, the policy remote access permission determines whether the user is granted access.
Granting access through the user account permission setting or the policy permission setting is only the first step in accepting a connection. The connection attempt is then subjected to the settings of the user account properties and the policy profile properties. If the connection attempt does not match the settings of the user account properties or the profile properties, the connection attempt is rejected.
By default, the Deny remote access permission policy permission is selected.
Profile
A remote access policy profile is a set of properties that are applied to a connection when the connection is granted remote access permission, either through the user account permission setting or the policy permission setting. A profile consists of the following groups of properties:
Dial-in constraints
IP
Multilink
Authentication
Encryption
Advanced
Dial-In Constraints
You can set the following dial-in constraints:
Idle disconnect time
The time after which a connection is disconnected when there is no activity. By default, this property is not set and the remote access server does not disconnect an idle connection.Maximum session length
The maximum amount of time that a connection is connected. The connection is disconnected by the remote access server after the maximum session length. By default, this property is not set and the remote access server has no maximum session limit.Day and time limits
The days of the week and hours of each day that a connection is allowed. If the day and time of the connection attempt do not match the configured day and time limits, the connection attempt is rejected. By default, this property is not set and the remote access server has no day or time limits. The remote access server does not disconnect active connections that are connected at a time when connection attempts are not allowed.Dial-in number
The specific phone number that a caller must call for a connection to be allowed. If the dial-in number of the connection attempt does not match the configured dial-in number, the connection attempt is rejected. By default, this property is not set and the remote access server allows all dial-in numbers.Dial-in media
The specific types of media, such as modem (known as asynch), ISDN, or virtual private network (known as virtual) that a caller must use for a connection to be allowed. If the dial-in medium of the connection attempt does not match the configured dial-in media, the connection attempt is rejected. By default, this property is not set and the remote access server allows all dial-in media types.
IP
You can set IP properties to specify whether a particular IP address for a connection can be requested by the client. By default, the remote access server automatically allocates an IP address and the client is not allowed to request a specific IP address.
You can also use the IP properties to define remote access policy profile filtering. To define the allowed traffic across the connection after the connection had been made, you can configure IP packet filters for remote access policy profiles. You can use profile packet filters to configure IP traffic that is allowed out of the connection (to client) or into the connection (from client) 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 connections that match the remote access policy.
Multilink
You can set Multilink properties that enable Multilink and determine the maximum number of ports that a Multilink connection can use. Additionally, you can set Bandwidth Allocation Protocol (BAP) policies that determine BAP usage and when extra BAP lines are dropped. The Multilink and BAP properties are specific to Microsoft Windows 2000 remote access. By default, Multilink and BAP are disabled.
The remote access server must have Multilink and BAP enabled in order for the Multilink properties of the profile to be enforced.
Authentication
You can set authentication properties to enable the types of authentication that are allowed for a connection and specify the EAP type that must be used. Additionally, you can configure the EAP type. By default, Microsoft Encrypted Authentication (MS-CHAP) and Microsoft Encrypted Authentication version 2 (MS-CHAPv2) are enabled.
The remote access server must have the corresponding authentication types enabled in order for the authentication properties of the profile to be enforced.
Encryption
You can set encryption properties for the following encryption strengths:
No Encryption
When selected, this option allows an unencrypted connection. To require encryption, clear the No Encryption option.Basic
For dial-up and PPTP-based VPN connections, Microsoft Point-to-Point Encryption (MPPE) with a 40-bit key is used. For L2TP over IPSec-based VPN connections, 40-bit DES encryption is used.Strong
For dial-up and PPTP-based VPN connections, MPPE with a 56-bit key is used. For L2TP over IPSec-based VPN connections, 56-bit DES encryption is used.Strongest
For dial-up and PPTP-based VPN connections, MPPE with a 128-bit key is used. For L2TP over IPSec-based VPN connections, triple DES (3DES) encryption is used.
Advanced
You can set advanced properties to specify the series of RADIUS Attributes that are sent back to the RADIUS client by the IAS server. RADIUS Attributes are specific to performing RADIUS authentication and are ignored by the remote access server. By default, Framed-Protocol is set to PPP and Service-Type is set to Framed.
The only attributes that are used by the remote access server are Account-Interim-Interval , Framed-Protocol , Framed-MTU , Reply-Message , and Service-Type .
Default Remote Access Policy
A default remote access policy named Allow access if dial-in permission is enabled is created. The default policy has the following configuration:
The Day-and-Time-Restrictions condition is set to all times and all days.
Permission is set to Deny remote access permission.
All profile properties are set to default values.
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 a NAS does not send a RADIUS attribute that corresponds to a remote access policy condition or profile setting, all RADIUS authentications from that NAS are denied.
Vendor Profiles
Some vendors use vendor-specific attributes (VSAs) to provide functionality that is not supported in standard attributes. IAS enables you to create or modify vendor-specific attributes to take advantage of the proprietary functionality that is supported by some NAS vendors.
If you need to configure more than one VSA for a specific profile, you must arrange them in the appropriate order. If you are using filters and the order of the filters is important, use the arrow buttons to rearrange the attributes.
Example 1
The following example demonstrates the procedure of adding a Cisco VSA to a profile. The example illustrates only the mechanism of adding a standard-conforming VSA to a profile. Cisco VSAs are readily available through the IAS multi-vendor dictionary.
Cisco vendor-specific attributes conform to the RADIUS RFC for Vendor-Specific Attributes (type 26). The following information is for a Cisco attribute to specify a primary DNS server:
Vendor ID: 9. This is the unique ID for Cisco. When you specify that vendor, this is automatically supplied.
Vendor Type: 1. This is the vendor-type number for vendor-specific attributes that take the attribute-value pair form, referred to in Cisco documentation as "cisco-avpair."
Data Type: String.
Format: If the attribute is mandatory, the format is: <protocol>: attribute=value
If the attribute is optional, the attribute-value pair is separated by an asterisk (*) instead of an equal sign (=). In this example, <protocol> is a value of the Cisco "protocol" attribute for a particular type of authorization. "Attribute" and "value" represent an appropriate attribute/value (AV) pair defined in the Cisco TACACS+ specification. This allows the full set of features available for TACACS+ authorization to also be used for RADIUS.
The Cisco attribute used to specify a primary DNS server appears as follows:
ip:dns-servers=10.10.10.10
To add the vendor-specific attribute to a dial-in profile
In IAS, click Remote Access Policies .
Right-click the policy for which you want to configure a vendor-specific attribute, and then click Properties .
Click Edit Profile , click the Advanced tab, and then click Add .
In the list of available RADIUS attributes, double-click Vendor-Specific .
Click Add .
In Network access server vendor , click Cisco .
Click Yes, It conforms , and then click Configure Attribute . In Vendor-assigned attribute number , type 1 .
In Attribute format , click String .
In Attribute value , type the following:
ip:dns-servers=10.10.10.10
Example 2
The following example demonstrates how to add a 3Com/U.S. Robotics VSA to a profile.
Note
Example 2 is included only to illustrate the mechanism of adding a standard nonconforming VSA to a profile. 3Com/U.S. Robotics VSAs are readily available through the IAS multivendor dictionary.
U.S. Robotics vendor-specific attributes do not conform to the recommended format for Vendor-Specific Attributes (type 26) in RADIUS RFC 2138. Therefore, all U.S. Robotics VSAs must be entered in hexadecimal format.
The following information is for a U.S. Robotics attribute to specify a primary DNS/NBNS server:
Vendor ID: 429. This is the unique ID for U.S. Robotics. When you specify that vendor, this ID is automatically supplied.
Indicator: 0x900F
Data Type: String
Format: The VSA must be entered in hexadecimal format.
To specify an IP address of 10.10.10.10 for a primary DNS/NBNS server
In IAS, click Remote Access Policies .
Right-click the policy for which you want to configure a vendor-specific attribute, and then click Properties .
Click Edit Profile , click the Advanced tab, and then click Add .
In the list of available RADIUS attributes, double-click Vendor-Specific , and then click Add .
Click Select from the list, and then click US Robotics .
Click No . It does not conform, and then click Configure Attribute .
In Hexadecimal attribute value, type the following:
0x900f31302e31302e31302e31302e
For more information about the proprietary attributes of U.S. Robotics, see your U.S. Robotics documentation.
Accepting a Connection Attempt
When a user attempts a connection, the connection attempt is accepted or rejected based on the following:
The first policy in the ordered list of remote access policies is checked. If there are no policies, reject the connection attempt.
If all the conditions of the policy do not match the connection attempt, go to next policy. If there are no more policies, reject the connection attempt.
If all the conditions of the policy match the connection attempt, check the remote access permission setting for the user attempting the connection. For example:
If Deny access is selected, reject the connection attempt.
If Allow access is selected, apply the user account properties and profile properties.
If the connection attempt does not match the settings of the user account properties and profile properties, reject the connection attempt.
If the connection attempt matches the settings of the user account properties and profile properties, accept the connection attempt.
If the remote access permission is not set to Allow access or Deny access , the remote access permission must be set to Control access through Remote Access Policy . Therefore, check the remote access permission setting of the policy.
If Deny remote access permission is selected, reject the connection attempt.
If Grant remote access permission is selected, apply the user account properties and profile properties.
If the connection attempt does not match the settings of the user account properties and profile properties, reject the connection attempt.
If the connection attempt matches the settings of the user account properties and profile properties, accept the connection attempt.
Remote Access Policy Administrative Models
In Windows 2000, there are three primary models for administering remote access permissions and connection settings:
Access by user.
Access by policy in a Windows 2000 native-mode domain.
Access by policy in a Windows 2000 mixed-mode domain.
Access by User
In the access-by-user administrative model, remote access permissions are determined by the remote access permission on the Dial-in tab of the user account. You enable or disable remote access permission on a per-user basis by setting the remote access permission to either Allow access or Deny access .
The remote access permission setting on the remote access policy is effectively overridden if the user account's remote access permission is set to either Allow access or Deny access . However, you can modify remote access policy conditions and profile properties to enforce connection settings, such as encryption requirements and idle time-outs.
You can administer access-by-user remote access with multiple remote access policies. Each remote access policy has its own profile settings. You must configure these settings carefully because a connection attempt might be rejected even when the remote access permission on the user account is set to Allow access . If a connection attempt matches the conditions of a policy but does not match the profile settings or does not match any of the remote access policies, the connection attempt is rejected.
In the access-by-user administrative model, you can control three behaviors:
Explicit allow
The remote access permission for the user account is set to Allow access and the connection attempt matches the conditions of a policy subject to the settings of the profile and the dial-in properties of the user account.Explicit deny
The remote access permission for the user account is set to Deny access.Implicit deny
The connection attempt does not match the conditions of any remote access policies.
In Windows 2000, the access-by-user administrative model is equivalent to administering remote access on a Windows NT 4.0 RAS server.
You can use the access-by-user administrative model on a stand-alone remote access server, a remote access server that is a member of a Windows 2000 native-mode domain, a remote access server that is a member of a Windows 2000 mixed-mode domain, or a remote access server that is a member of a Windows NT 4.0 domain. You can also use the access-by-user administrative model if you have Windows NT 4.0 RAS or IAS servers.
Access by Policy in a Windows 2000 Native-Mode Domain
In the access-by-policy administrative model for a Windows 2000 native-mode domain, the remote access permission on every user account is set to Control access through Remote Access Policy and remote access permissions are determined by the remote access permission setting on the remote access policy. Therefore, the remote access permission setting on the remote access policy determines whether remote access permission is allowed or denied.
In the access-by-policy administrative model for a Windows 2000 native-mode domain, you can control three behaviors:
Explicit allow
The remote access permission on the remote access policy is set to Grant remote access permission and the connection attempt matches the conditions of the policy subject to the settings of the profile and the dial-in properties of the user account.Explicit deny
The remote access permission on the remote access policy is set to Deny remote access permission and the connection attempt matches the conditions of the policy.Implicit deny
The connection attempt does not match the conditions of any remote access policies.
If you use this administrative model and do not add any remote access policies and do not change the default remote access policy (named Allow access if dial-in permission is enabled ), no users are allowed remote access. By default, the remote access permission on the default remote access policy is set to Deny remote access permission . If you change the setting to Grant remote access permission , all users are allowed remote access.
The access-by-policy administrative model for a Windows 2000 native-mode domain also applies to stand-alone remote access servers that are not a member of a domain.
You cannot use the access-by-policy administrative model for a Windows 2000 native-mode domain if you have Windows NT 4.0 RAS or IAS servers.
If you use the access-by-policy administrative model for a Windows 2000 native-mode domain and do not use groups to specify which users get access, verify that the Guest account is disabled and its remote access permission is set to Deny access .
Access by Policy in a Windows 2000 Mixed-Mode Domain
In the access-by-policy administrative model for a Windows 2000 mixed-mode domain, the remote access permission on every user account is set to Allow access , the default remote access policy is deleted, and separate remote access policies are created to define the types of connections that are allowed. On a remote access server that is running Windows 2000 that is a member of a Windows 2000 mixed-mode domain, the Control access through Remote Access Policy option is not available for remote access permission on the user account. If a connection attempt matches the conditions of a policy subject to the profile and user account dial-in settings, the connection is accepted.
This administrative model also applies to a remote access server that is running Windows 2000 that is a member of a Windows NT 4.0 domain.
In the access-by-policy administrative model for a Windows 2000 mixed-mode domain, you can control three behaviors:
Explicit allow
The connection attempt matches the conditions of a policy subject to the settings of the profile and the dial-in properties of the user account.Explicit deny
The connection attempt matches the conditions of a policy but not the settings of the profile. You can do an explicit deny in this administrative model by enabling the Restrict Dial-in to this number only dial-in constraint and typing a number that does not correspond to any dial-in number being used by the remote access server.Implicit deny
The connection attempt does not match the conditions of any remote access policies.
If you do not delete the default remote access policy named Allow access if dial-in permission is enabled , all users can obtain a remote access connection.
If you have Windows NT 4.0 Routing and Remote Access service (RRAS) servers, you can use the access-by-policy only in a Windows 2000 mixed-mode domain administrative model if the RRAS servers are configured as RADIUS clients to a Windows 2000 IAS server. You cannot use the access-by-policy in a Windows 2000 mixed-mode domain administrative model for Windows NT 4.0 RAS servers.
Note
The administrative models described here are recommended ways of controlling remote access. You can administer remote access through a mixture of these models. However, you must do so carefully to produce the intended results. Improper configuration might lead to connection attempts that are rejected when they must be accepted and connection attempts that are accepted when they must be rejected. To troubleshoot these complex configurations, you can apply the logic the remote access server uses when processing connection attempts or enable authentication logging and check the authentication log.
For more information about remote access policies and scenarios using remote access policies, see Windows 2000 Server Help.