Internet Authentication Service
Internet Authentication Service |
|
In Windows NT 4.0, remote access privileges were granted based solely on a
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 (
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
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.
Note
Windows 2000 supports customized authorization through the use of the Software Development Kit.
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:
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.
In Windows 2000, the user object for a stand-alone or Active Directory–based server contains a set of
The
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.
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.
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.
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.
If this property is enabled, the administrator assigns a specific IP address to the user when the connection is made.
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:
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
User accounts upgraded to Windows 2000 that were configured with
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.
A remote access policy is a named rule that consists of the following elements:
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.
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.
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:
You can set the following
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.
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.
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.
The specific phone number that a caller must call for a connection to be allowed. If the
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
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.
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.
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 (
The remote access server must have the corresponding authentication types enabled in order for the authentication properties of the profile to be enforced.
You can set encryption properties for the following encryption strengths:
When selected, this option allows an unencrypted connection. To require encryption, clear the No Encryption option.
For
For
For
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.
A default remote access policy named Allow access if
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.
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.
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:
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
ip:dns-servers=10.10.10.10
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:
To specify an IP address of 10.10.10.10 for a primary DNS/NBNS server
0x900f31302e31302e31302e31302e
For more information about the proprietary attributes of U.S. Robotics, see your U.S. Robotics documentation.
When a user attempts a connection, the connection attempt is accepted or rejected based on the following:
In Windows 2000, there are three primary models for administering remote access permissions and connection settings:
In the access-by-user administrative model, remote access permissions are determined by the remote access permission on the
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:
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
The remote access permission for the user account is set to Deny access.
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.
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:
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
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.
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
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.
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
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:
The connection attempt matches the conditions of a policy subject to the settings of the profile and the
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
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
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.