IAS Authentication and Authorization

Article
12/09/2009

The NAS attempts to negotiate a connection with the remote access client by using the most secure protocol first and then the next most secure protocol, continuing to the least secure protocol. For example, a Windows 2000 remote access server tries to negotiate EAP, MS-CHAP v2, MS-CHAP, CHAP, SPAP, and lastly PAP.
The NAS forwards the authentication request to an IAS server in the form of a RADIUS Access-Request packet.
The IAS server verifies that the RADIUS Access-Request packet is sent from a configured RADIUS client by checking the source IP address. If the Access-Request packet was sent by a valid RADIUS client and digital signatures are enabled for the RADIUS client, the digital signature in the packet is checked using the shared secret. A shared secret is a text string that serves as a password between the RADIUS server and the RADIUS clients connected to it. Each IAS server must have a shared secret for each NAS or other IAS server that forwards RADIUS requests to it. There are a few rules to note when setting up a shared secret:
- It must be exactly the same at both servers.
- It is case-sensitive.
- It can contain any standard alphanumeric characters or any special characters.
If a digital signature is present, IAS verifies the signature. If the verification of the digital signature fails, IAS silently discards the packet. If digital signatures are enabled for the client and the digital signature is not present, IAS silently discards the packet. When the NAS does not receive a response within its time-out period, it retries and then disconnects the user. If the IAS server cannot connect to the domain controller or cannot find the domain controller to which the user belongs, it silently discards the packet. This allows an NAS to retransmit the request to the backup IAS server, which would then attempt to authenticate the user against the domain database.
The IAS server queries the Windows 2000-based domain controller, validating the user’s credentials.
If the user credentials are authentic, the IAS server evaluates the connection attempt against the configured remote access policies and the dial-in properties of the user’s account to determine whether to authorize the request. If the connection attempt matches the conditions of at least one policy and the combination of the user account dial-in properties, remote access policy properties, and remote access policy profile properties authorize the connection, IAS sends a RADIUS Access-Accept message to the NAS that sent the Access-Request message. The Access-Accept message authorizes the connection but also contains connection parameters based on the remote access policy profile settings and the dial-in properties of the user account. The NAS interprets this authorization data to determine the connection parameters that the IAS server has authorized.

If the user is not authentic or the user’s attempt to connect either does not match conditions in at least one policy or matches conditions in a policy that denies access, IAS sends a RADIUS Access-Reject message to the NAS, and the NAS disconnects the user.

IAS Authentication

IAS authentication involves verifying the credentials of the client computer that is initiating the connection against an authentication authority. For Windows 2000 IAS, the credentials of the initiating client are sent using a PPP authentication protocol and the authentication authority is a Windows 2000 or Windows NT domain controller.

Authentication Methods

There are a number of PPP authentication protocols that are supported by the RADIUS protocol. Each protocol has advantages and disadvantages in terms of security, usability, and breadth of support. The protocol used is determined by the configuration of the NAS device. See your NAS documentation if you are configuring a dial-up network. Consult your ISP if you are using one for dial-up access to your LAN.

The following sections cover the advantages and disadvantages of the authentication protocols currently supported by IAS. This information is also useful in configuring a specific authentication method for remote access.

Password Authentication Protocol

Password Authentication Protocol (PAP) relays a password as a string from the user’s computer to the NAS device. When the NAS forwards the password, it is encrypted using the RADIUS shared secret as an encryption key. PAP is the most flexible protocol because passing a plaintext password to the authentication server enables that server to compare the password with nearly any storage format. For example, UNIX passwords are stored as one-way encrypted strings that cannot be decrypted. PAP passwords can be compared to these strings by reproducing the encryption method.

Because it uses a plaintext version of the password, PAP has security vulnerabilities. Although the RADIUS protocol encrypts the password, it is transmitted as plaintext across the dial-up connection.

Enabling PAP

To enable PAP-based authentication, you must do the following:

Enable PAP as an authentication protocol on the remote access server. For information about a default setting on a specific NAS, see your NAS documentation. On the Routing and Remote Access service, PAP is disabled by default.
Enable PAP on the appropriate remote access policy (PAP is disabled by default).
Enable PAP on a remote access client.

Note: Enabling PAP as an authentication protocol means that user passwords are sent from a client to an NAS in plaintext form. The NAS encrypts the password using the shared secret and sends it in an Access-Request packet. Because a RADIUS proxy must encrypt the PAP password using the shared secret of its forwarding RADIUS server, a RADIUS proxy must decrypt the PAP password using the shared secret between the RADIUS proxy and the NAS. A malicious user at a RADIUS proxy can record user names and passwords for PAP connections. For this reason, the use of PAP is highly discouraged, especially for virtual private network connections.

Challenge Handshake Authentication Protocol

Challenge Handshake Authentication Protocol (CHAP) addresses the concern of sending passwords in plaintext. By using CHAP, the NAS sends a random number challenge to the user’s computer. The challenge and the user’s password are then hashed through Message Digest 5 (MD5). The client computer then sends the hash as a response to the NAS challenge and the NAS forwards both the challenge and response in the RADIUS Access-Request packet.

When the authenticating server receives the RADIUS packet, it uses the challenge and the user’s password to create its own version of the response. If the version of the server matches the response supplied by the user’s computer, then the access request is accepted.

CHAP responses cannot be reused because NAS devices send a unique challenge each time a client computer connects to them. Because the algorithm for calculating CHAP responses is well known, it is very important that passwords be carefully chosen and of sufficient length. CHAP passwords that are common words or names are vulnerable to discovery through dictionary attacks, which compare responses to the CHAP challenge with every entry in a dictionary. Passwords that are not sufficiently long can be discovered by brute force, which compares the CHAP response to sequential trials until a match to the user’s response is found.

Historically, CHAP has been the most common dial-up authentication protocol used. When the server does not store the same password that was used to calculate the CHAP response, it cannot calculate an equivalent response. Because standard CHAP clients use the plaintext version of the password to create the CHAP challenge response, passwords must be stored in plaintext on the server to calculate an equivalent response.

Although the IAS server supports CHAP, a Windows NT 4.0-based domain controller cannot validate CHAP requests without support for storing reversibly encrypted passwords. This support is available in Windows 2000. In Windows NT 4.0, CHAP support is available in Service Pack 3 and greater.

Enabling CHAP

To enable CHAP-based authentication, you must do the following:

Enable CHAP as an authentication protocol on the remote access server. For information about a default setting on a specific NAS, see your NAS documentation.
Enable CHAP on the appropriate remote access policy.
Enable storage of a reversibly encrypted form of the user’s password. On a Windows 2000-based stand-alone server, use Group Policy to enable storage of reversibly encrypted passwords for all users of the computer. For Windows 2000 domains, Group Policy can be used at the domain or Organizational Unit (OU) level. For information about enabling reversibly encrypted passwords, see Windows 2000 Server online Help.
Force a reset of user passwords so that the new passwords are in a reversibly encrypted form. When you enable passwords to be stored in a reversibly encrypted form, the current passwords are in a non-reversibly encrypted form and are not automatically changed. You must either reset user passwords or set user passwords to be changed at the next logon attempt. After the password is changed, it is stored in a reversibly encrypted form.

When you set user passwords to be changed at the next logon attempt, users must log on using a LAN connection and change their passwords before they log on with a remote access connection using CHAP. CHAP does not support password changing during the authentication process, causing a logon attempt to fail. An alternative for the remote access user is to temporarily log on using MS-CHAP to change the password.
Enable CHAP on the remote access client.

Microsoft Challenge Handshake Authentication Protocol

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), also known as MS-CHAP v1, is a variant of CHAP that does not require a plaintext version of the password on the authenticating server. In MS-CHAP, the challenge response is calculated with an MD4 hashed version of the password and the NAS challenge. This enables authentication over the Internet to a Windows 2000 domain controller.

MS-CHAP passwords are stored more securely at the server but have the same vulnerabilities to dictionary and brute force attacks as CHAP. When using MS-CHAP, it is important to ensure that passwords are well chosen (not found in a standard dictionary) and long enough that they cannot be readily calculated. Many organizations require passwords to be at least six characters long with upper and lower case characters and at least one numeral.

See your NAS documentation, or contact your ISP to determine whether MS-CHAP is supported.

Caution: Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Note: By default, MS-CHAP v1 for Windows 2000 supports LAN Manager authentication used by older Microsoft operating systems such as Windows NT 3.5 and Windows 95. You can prohibit the use of LAN Manager authentication with MS-CHAP v1 by setting Allow LM Authentication (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\RemoteAccess\Policy) to 0 on the IAS server.

If a user attempts authentication through MS-CHAP with an expired password, MS-CHAP prompts the user to change the password while connecting to the server. Other authentication protocols do not support this feature, effectively locking out the user with the expired password.

Enabling MS-CHAP

To enable MS-CHAP-based authentication, you must do the following:

Enable MS-CHAP as an authentication protocol on the remote access server. MS-CHAP is enabled by default on the Routing and Remote Access service. For information about default settings on other NASs, see your NAS documentation.
Enable MS-CHAP on the appropriate remote access policy. MS-CHAP is enabled by default.
Enable MS-CHAP on a remote access client.

Microsoft Challenge Handshake Authentication Protocol Version 2

Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) provides mutual authentication, stronger initial data encryption keys, and different encryption keys for sending and receiving. Windows 2000 servers offer MS-CHAP v2 before offering MS-CHAP v1. Additionally, updated Windows clients accept MS-CHAP v2 when it is offered.

MS-CHAP v2 is a one-way encrypted password, mutual-authentication process that works as follows:

The remote access server sends a challenge that consists of a session identifier and an arbitrary challenge string to the remote access client.
The remote access client sends a response that contains the following:
- The user name.
- An arbitrary peer challenge string.
- A one-way encryption of the received challenge string, the peer challenge string, the session identifier, and the user’s password.
The remote access server checks the response from the client and sends back a response containing:
- An indication of the success or failure of the connection attempt.
- An authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user’s password.
The remote access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the remote access client ends the connection.

If a user authenticates through MS-CHAP v2 and attempts to use an expired password, MS-CHAP v2 prompts the user to change the password while connecting to the server. Other authentication protocols do not support this feature, locking out the user with an expired password.

Enabling MS-CHAP v2

To enable authentication based on MS-CHAP v2, you must do the following:

Enable MS-CHAP v2 as an authentication protocol on the remote access server. MS-CHAP v2 is enabled by default on the Routing and Remote Access service. For information about default settings on other NASs, see your NAS documentation.
Enable MS-CHAP v2 on the appropriate remote access policy. MS-CHAP v2 is enabled by default.
Enable MS-CHAP v2 on the Windows 2000 remote access client.

Note: Windows 95 and Windows 98 support MS-CHAP v2 only for virtual private network (VPN) connections and not for dial-up connections.

Extensible Authentication Protocol

Extensible Authentication Protocol (EAP) is an extension to the Point-to-Point protocol (PPP) that works with dial-up, PPTP, and L2TP clients. EAP allows the addition of new authentication methods known as EAP types. Both the dial-up client and the remote access server must support the same EAP type for successful authentication to occur.

Windows 2000 includes an EAP infrastructure and two EAP types, EAP-MD5 CHAP and EAP-TLS. The IAS implementation in Windows 2000 can pass EAP messages to a RADIUS server (EAP-RADIUS).

EAP-MD5 CHAP

Message Digest 5 Challenge Handshake Authentication Protocol (EAP-MD5 CHAP) is an EAP type that uses the same challenge-handshake protocol as PPP-based CHAP, but the challenges and responses are sent as EAP messages. A typical use for EAP-MD5 CHAP is to authenticate the credentials of remote access clients by using user name and password security systems. You can also use EAP-MD5 CHAP to test EAP interoperability.

EAP-TLS

EAP-Transport Level Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. If you are using smart cards for remote access authentication, you must use the EAP-TLS authentication method. The EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and secured private key exchange between the remote access client and the authenticating server. EAP-TLS provides the strongest authentication and key exchange method. EAP-TLS is supported only on a remote access server that is running Windows 2000 and is a member of a Windows 2000 mixed-mode or native-mode domain.

EAP-RADIUS

EAP-RADIUS is not an EAP type. It is the passing of EAP messages of any EAP type by a remote access server to a RADIUS server for authentication. EAP messages sent between the remote access client and remote access server are encapsulated and formatted as RADIUS messages between the remote access server and the RADIUS server.

EAP-RADIUS is used in environments where RADIUS is used as the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each remote access server, only at the RADIUS server. A common use of EAP-RADIUS is to configure the remote access server both to use EAP and to use RADIUS as its authentication provider. When a connection is made, the remote access client negotiates the use of EAP with the remote access server. When the client sends an EAP message to the remote access server, the remote access server encapsulates the EAP message as a RADIUS message and sends it to its configured RADIUS server. The RADIUS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the remote access server. The remote access server then forwards the EAP message to the remote access client. In this configuration, the remote access server is only a pass-through device. All EAP message processing occurs at the remote access client and the RADIUS server.

Enabling EAP

To enable EAP-based authentication, you must do the following:

Enable EAP as an authentication protocol on the remote access server.
Enable EAP and, if needed, configure the EAP type on the appropriate remote access policy.
Enable and configure EAP on a remote access client.

In addition to the EAP types defined and supported in Windows 2000, new EAP authentication methods can be developed and included with the EAP Software Development Kit.

Authentication Configurations

The authenticating authority for IAS authentication is either the Windows 2000 local SAM, or a Windows 2000 or Windows NT 4.0 domain controller. This section describes IAS authentication features and behavior in different Windows domain configurations. This is useful when making decisions about specific domain configurations where IAS is deployed.

IAS can authenticate access requests received through the RADIUS protocol against Windows 2000 native-mode domains, Windows 2000 mixed-mode domains, Windows NT 4.0 domains, or a Windows 2000 local accounts database for a stand-alone IAS server. The IAS authentication features and capabilities available to administrators vary, depending on the mode of a specific domain against which users authenticate.

Windows 2000 Native-Mode Domains

Windows 2000 native mode provides the most flexibility in managing remote access through groups. From the remote access management perspective, the following benefits are available in the native-mode domain:

The full ability to manage remote access permissions through groups. An administrator can use the universal group feature to create a single policy for users in different domains. Nested groups can be used to organize extremely large numbers of users into smaller groups for simpler, more effective management.
The ability to connect a remote network to an office network. You can specify routes for the remote network through static routes assigned to the user account.
Support for user principal names. Users can have the same user principal name regardless of which domain they belong to, providing scalability required in organizations with a large number of domains.

The following is a list of authentication and remote management features available for an IAS server that is a member of a Windows 2000 native-mode domain.

Dial-in User Account Properties: All remote access permissions (including Allow access, Deny access, and Control access through Remote Access Policy), Caller-ID, Callback Options, Static IP Address, and Static Routes.
Support for user principal names and Universal Groups.
Support for EAP-TLS.
Ability to use the access-by-policy for a native-mode domain administrative model.

In order for the IAS server to access user account dial-in properties stored in Active Directory, IAS must run in the security context of a computer account that is a member of the RAS and IAS Servers security group. This assignment can be implemented through the Active Directory Users and Computers administrative tool, by either registering the IAS server in the Internet Authentication Service administrative tool or using the netsh ras add registeredserver command.

Windows 2000 Mixed-Mode Domains and Windows NT 4.0 Domains

Windows 2000 mixed-mode domains are used primarily for migration from Windows NT 4.0 to Windows 2000. For IAS, a mixed-mode domain functions exactly like a Windows NT 4.0 domain.

For an IAS server that is a member in a Windows 2000 mixed-mode domain, the following authentication and remote access management features are available:

Dial-in User Account Properties: Remote access permissions include only Allow access and Deny access. Missing the Control access through Remote Access Policy option makes it more difficult to use groups with policy-based management because the user’s remote access permission overrides remote access policy permissions. For more information about policy-based management in a mixed-mode domain, see the Remote Access Policies section.
Callback Options.

Similar to Windows 2000 native-mode domains, in order for the IAS server to access user account dial-in properties stored in Active Directory, IAS must run in the security context of a computer account that is a member of the RAS and IAS Servers security group. This assignment can be implemented through the Active Directory Users and Computers administrative tool, by either registering the IAS server in the Internet Authentication Service administrative tool or using the netsh ras add registeredserver command.

If the IAS server computer is a member of a Windows NT 4.0 domain but has to authenticate users against a trusted Active Directory domain, it cannot gain access to Active Directory because its computer account cannot become a member of the RAS and IAS Servers security group. In this case, you can verify that the Everyone group is added to the Pre-Windows 2000 Compatible Access group with the net localgroup “Pre-Windows 2000 Compatible Access” command. If not, issue the net localgroup “Pre-Windows 2000 Compatible Access” everyone /add command on a domain controller computer and then restart it.

Windows 2000 Stand-Alone Servers

Windows 2000 stand-alone servers can be used in very small networks with no domains. All user accounts and their properties need to be defined in the local accounts database.

The following authentication features are available for granting remote access permissions to an IAS server on a Windows 2000 stand-alone server:

Dial-in User Account Properties: Remote Access permission (includes Allow access, Deny access, and Control access through Remote Access Policy), Caller-ID, Callback Options, Static IP Address, and Static Routes.

Support for user principal names, Universal Groups, and EAP-TLS is not available to IAS running on a stand-alone Windows 2000 server. User account dial-in properties can be administered through either Network and Dial-up Connections or Local Users and Groups.

Cross-Forest Authentication

To enable a remote access server that is running Windows 2000 in a domain in one Active Directory forest to authenticate the remote access credentials for a user account in a domain in another Active Directory forest, you must use a RADIUS proxy between the remote access server and the IAS server. A RADIUS proxy is a RADIUS server that forwards RADIUS requests between RADIUS clients and RADIUS servers. The RADIUS proxy acts as a RADIUS server to RADIUS clients and a RADIUS client to RADIUS servers.

Figure 2 shows the use of a RADIUS proxy to provide authentication for connection attempts for user accounts in different Windows 2000 Active Directory forests:

Figure 2: The Use of a RADIUS Proxy to Provide Cross-Forest Authentication

In this configuration, RAS1 is a remote access server that is a member of the forest1.microsoft.com Active Directory forest and is configured as a RADIUS client to the RADIUS proxy. The RADIUS proxy is configured as a RADIUS client to both IAS1, the IAS server in the forest1.microsoft.com Active Directory forest, and IAS2, the IAS server in the forest2.microsoft.com Active Directory forest. When a remote access client connects to RAS1 and passes its user name of user@forest2.microsoft.com, the following process is used to authenticate and authorize the connection attempt:

RAS1 passes the user name of user@forest2.microsoft.com to the RADIUS proxy using a RADIUS Access-Request message.
The RADIUS proxy parses the user name and determines, based on the “forest2.microsoft.com” portion of the name, to forward the Access-Request to IAS2.
IAS2 authenticates and authorizes the connection attempt and sends a RADIUS Access-Accept message back to the RADIUS proxy.
The RADIUS proxy sends the Access-Accept message back to RAS1.

Windows 2000 does not support RADIUS proxy. RADIUS proxy is supported by the Internet Connection Services for Microsoft RAS, Commercial Edition for Windows NT Server 4.0, an upgrade to the Internet Connection Services for Microsoft RAS component of the Windows NT 4.0 Option Pack.

For more information on the Windows NT 4.0 Option Pack, see https://www.microsoft.com/ntserver/nts/downloads/recommended/NT4OptPk/default.asp. For more information on Internet Connection Services for Microsoft RAS, Commercial Edition, see https://www.microsoft.com/ISN/misc/icsoverview.asp. You can download Internet Connection Services for Microsoft RAS, Commercial Edition at https://www.microsoft.com/ISN/downloads.asp#2.

IAS Authorization

An administrator can use IAS to authorize attempts based on the user account properties and connection parameters. The following sections describe how IAS determines authorization for a connection request using the dial-in properties of a user account and remote access policies.

Remote Access Policies

In Windows NT 4.0, remote access privileges are granted based only 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 account and on remote access policies. Remote access policies are a set of conditions and connection parameters that are used to increase flexibility in granting remote access permissions and connection 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 based on the time of day and day of the week, the Windows 2000 group to which the remote access user belongs, 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 the remote access policies (subject to the conditions of the dial-in properties of the user account and the profile properties of the remote access policy). Otherwise, 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 either 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 IAS 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:

Install the Windows 2000 IAS as a 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 will be used by all Windows 2000 remote access servers.
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 is 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 Account

In Windows 2000, the user account 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, you can set the dial-in properties on the Dial-in tab on the user account in Local Users and Groups. For Active Directory-based servers, you can set the dial-in properties on the Dial-in tab on the user account in Active Directory Users and Computers administrative tool. 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 account in a Windows 2000 native-mode domain are shown in Figure 3:

Figure 3: The Dial-in Properties of a User Account

The dial-in properties of a Windows 2000 user account are:

Remote Access Permission (Dial-in or VPN)

You can 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, user account properties, and profile properties can still deny the connection attempt. The Control access through Remote Access Policy option is available only on user accounts in a Windows 2000 native-mode domain or for local accounts on stand-alone Windows 2000 Routing and Remote Access servers.

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. In a Windows 2000 mixed-mode domain, they 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

When 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, then the connection attempt is denied.

Caller ID must be supported by the caller, the phone system between the caller and the remote access server, and the remote access server. Caller ID on the remote access server consists of call answering equipment that supports the passing of caller ID information and the appropriate driver inside Windows 2000 that supports 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

When this property is enabled, the server calls the caller back while the connection is being established at a phone number set by either the caller or the administrator.
Assign a Static IP Address

When this property is enabled, you can assign a specific IP address to the user when a connection is made.
Apply Static Routes

When this property enabled, you can define 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.

For a user account in a Windows NT 4.0 domain or a Windows 2000 mixed-mode domain:

Only the Remote Access Permission (Dial-in or VPN) (Allow access and Deny access options) and Callback Options dial-in properties are available.
You can use the Windows NT 4.0 User Manager for Domains administrative tool to grant or deny dial-in access and set callback options.

If a user account is in a Windows 2000 native-mode domain, the callback number can be up to 128 characters. If a user account is on a remote access server running Windows 2000 as a stand-alone server, in a Windows NT 4.0 domain, or in a Windows 2000 mixed-mode domain, the callback number is from 24 through 48 characters, due to the compressed format for storing callback numbers. If an IAS server is a member of a Windows NT 4.0 domain or a Windows 2000 mixed-mode domain and queries a Windows 2000 native-mode domain for a user account’s dial-in properties, then the callback number can be truncated.

When a remote access server running Windows NT 4.0 uses a Windows 2000 native-mode 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 Deny access.

A remote access server running Windows NT 4.0 cannot use remote access policies. It is recommended that you upgrade a remote access server running Windows NT 4.0 to either Windows NT 4.0 with the Routing and Remote Access Service (RRAS) or Windows 2000, configuring the server for RADIUS authentication to take advantage of remote access policy authorization.

Remote Access Policy Settings

A remote access policy is a named rule that consists of these elements:

Conditions
Remote access permission
Profile

Figure 4 shows the properties for the default policy called Allow access if dial-in permission is enabled:

Figure 4: The Properties of a Remote Access Policy

Remote Access Policy 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.

Figure 5 lists the condition attributes:

Figure 5: The Attributes for Conditions of a Remote Access Policy

Table 1 lists the condition attributes that you can set for a remote access policy:

Table 1 - 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.

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.

Framed Protocol

The type of framing for incoming packets. Examples are PPP, AppleTalk, SLIP, Frame Relay, and X.25.

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 “async”), ISDN, and tunnels or virtual private networks (known as virtual).

Day and Time Restrictions

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. If the RADIUS client is an NAS, the NAS IP Address and the Client IP Address are the same. If the RADIUS client is a RADIUS proxy, the NAS IP Address and the Client IP Address are different.

Client IP Address

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.

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.

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.

Notes: If conditions that use an attribute designed for the IAS server are evaluated against a remote access server connection attempt, they do not 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 running Windows 2000 for the Windows Groups attribute. Examples of built-in groups include the Administrators and Power Users local groups.

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, then the connection attempt is rejected.

By default, Deny remote access permission is selected.

Remote Access Policy Profile Settings

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 these groups of properties:

Dial-in constraints
IP
Multilink
Authentication
Encryption
Advanced

Dial-In Constraints

Figure 6 shows the Dial-in Constraints tab for a remote access policy profile:

Figure 6: The Dial-in Constraints Tab for a Remote Access Policy Profile

You can set these dial-in constraints:

Idle disconnect time.

The amount of 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. This constraint corresponds to the RADIUS Idle-Timeout attribute.
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. This constraint corresponds to the RADIUS Session-Timeout attribute.
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, then 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, then the connection attempt is rejected. By default, this property is not set and the remote access server allows all dial-in numbers. This constraint corresponds to the RADIUS Calling-Station-Id attribute.
Dial-in media.

The specific types of media, such as modem (known as async), 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, then the connection attempt is rejected. By default, this property is not set and the remote access server allows all dial-in media types. This constraint corresponds to the RADIUS NAS-Port-Type attribute.

Figure 7 shows the IP tab for a remote access policy profile:

Figure 7: The IP Tab for a Remote Access Policy Profile

You can set IP properties to specify whether a specific IP address for a connection can be requested by the client. By default, the Windows 2000 Routing and Remote Access service automatically allocates an IP address and the client is not allowed to request a specific IP address. If you select Server must supply an IP address, the Framed-IP-Address RADIUS attribute is used set to the value of 0xFFFFFE. If you select Client may request an IP address, the Framed-IP-Address RADIUS attribute is used set to the value of 0xFFFFFF. If you select Server settings define policy, the Framed-IP-Address RADIUS attribute is not sent in the Access-Accept message.

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 has 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. Filtering of remote access policy profile applies to all connections that match the remote access policy.

Multilink

Figure 8 shows the Multilink tab for a remote access policy profile:

Figure 8: The Multilink Tab for a Remote Access Policy Profile

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.

The remote access server must have Multilink and BAP enabled in order for the Multilink properties of the profile to be enforced.

Authentication

Figure 9 shows the Authentication tab for a remote access policy profile:

Figure 9: The Authentication Tab for a Remote Access Policy Profile

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. In addition, you can configure the EAP type. By default, Microsoft Encrypted Authentication (MS-CHAP) and Microsoft Encrypted Authentication version 2 (MS-CHAP v2) 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

Figure 10 shows the Encryption tab for a remote access policy profile:

Figure 10: The Encryption Tab for a Remote Access Policy Profile

You can set encryption properties for these encryption strengths:

No Encryption

When selected, this option allows a non-encrypted connection. To require encryption, clear the No Encryption box.
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, 56-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. This option is available only after the Windows 2000 High Encryption Pack is installed.

Advanced

Figure 11 shows the Advanced tab for a remote access policy profile:

Figure 11: The Advanced Tab for a Remote Access Policy Profile

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 not used 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 Routing and Remote Access service 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 this 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 RADIUS 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 proprietary functionality supported by NAS vendors.

If you want to configure more than one VSA for a specific profile, you must arrange them in the correct order. If you are using filters and the order of the filters is important, you can use the arrow buttons to rearrange the attributes.

Example 1

The following example demonstrates the procedure of adding a Cisco VSA to a profile, illustrating 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 2138 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 this vendor, it 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 specific type of authorization. Attribute and value represent an appropriate attribute/value (AV) pair defined in the Cisco TACACS+ specification, allowing 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 do the following:

Click Start, point to Programs, point to Administrative Tools, and then click Internet Authentication Service.
In Internet Authentication Service, 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.
Click Select from the list, and then 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 ip:dns-servers=10.10.10.10

Example 2

The following example demonstrates the method for adding 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 multi-vendor 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 this vendor, it 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

Click Start, point to Programs, point to Administrative Tools, and then click Internet Authentication Service.
In Internet Authentication Service, 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 0x900f31302e31302e31302e31302e.

For more information about the proprietary attributes of U.S. Robotics, see your U.S. Robotics documentation.

Remote Access Policies Processing Logic

When a user attempts a connection, the connection attempt is accepted or rejected based on the following logic:

The first policy in the ordered list of remote access policies is checked. If there are no policies, then reject the connection attempt.
If all the conditions of the policy do not match the connection attempt, then go to next policy. If there are no more policies, then reject the connection attempt.
If all the conditions of the policy match the connection attempt, then check the remote access permission setting for the user attempting the connection.
- If Deny access is selected, then reject the connection attempt.
- If Allow access is selected, then 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, then reject the connection attempt.
  - If the connection attempt matches the settings of the user account properties and profile properties, then accept the connection attempt.
- If the remote access permission is not set to Allow access or Deny access, then 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, then reject the connection attempt.
  - If Grant remote access permission is selected, then 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, then reject the connection attempt.
    - If the connection attempt matches the settings of the user account properties and profile properties, then accept the connection attempt.

Figure 12 shows the processing logic of remote access policies:

Figure 12: Remote Access Policy Processing Logic

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 selected 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, then 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. Remote access permissions are either allowed or denied based on the remote access permission setting on the remote access policy.

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), then 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, then 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, then 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 and 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, then the connection is accepted.

This administrative model also applies to a remote access server that is running Windows 2000 and 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 create an explicit deny in this administrative model by enabling the Restrict Dial-in to this number only constraint and typing a number that does not correspond to any 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 access by policy in a Windows 2000 mixed-mode domain administrative model only if the RRAS servers are configured as RADIUS clients to a Windows 2000 IAS server. You cannot use 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 should be accepted and connection attempts that are accepted when they must be rejected. To troubleshoot these complex configurations, you can either apply the logic that the remote access server uses when processing connection attempts or enable authentication logging and check the authentication log.

For more information on scenarios using remote access policies, see Windows 2000 Server online help.

Remote Access Policy Management

Here are some design principles for the management of remote access policies:

Use as few remote access policies as possible.

Try to define the exact types of connections that you want to support in a simple list in terms of groups, connection types, and connection parameters.

Example: Employees are granted access with a 30-minute maximum connection time. Managers and executives are granted access with no maximum connection time. Contractors and vendors are not granted access.
Use Universal Groups to nest groups and minimize the number of remote access policies.

Example: Employees are in the separate groups Sales_Emp, Acct_Emp, R&D_Emp, and Admin_Emp. Create a universal group called Employees and add the Sales_Emp, Acct_Emp, R&D_Emp, and Admin_Emp groups to it.
When ordering groups, place the most specific policies at the top of the list and the most general policies at the bottom of the list. Because the first matching policy is the one that is applied to the connection attempt, if a more general policy is at the top of the list, the connection parameters of the more general policy are applied and the connection parameters of the more specific policy are not.

Example: Create a policy called Managers and Execs that specifies that all members of the Managers&Execs group be granted access with no maximum connection time. Create a policy called Employees that specifies that all members of the Employees universal group be granted access with a 30-minute maximum connection time. Create a policy called Contractors and Vendors that denies access to all members of the Contractors&Vendors group. Order the policies as follows:
1. Managers and Execs
2. Contractors and Vendors
3. Employees

Because managers and executives are also members of the Employees universal group (through their membership in the Sales_Emp, Acct_Emp, R&D_Emp, and Admin_Emp groups), if the Employees remote access policy is placed before the Managers and Execs policy, then the Employees policy is applied to the connection attempt first and the Managers and Execs policy is not applied. Managers and executives will get a 30-minute maximum connection time despite the fact that there is a remote access policy in place to give them an unlimited connection time.

Using the Default Remote Access Policy

The default remote access policy called Allow access if dial-in permission is set is only needed when you are using the access-by-user administrative model and want to grant default remote access policy-profile settings to incoming connections. The only condition on the default remote access policy is that the connection attempt must occur at any time on any day. Therefore, any connection attempt will match the conditions of the default remote access policy. Because the default remote access policy is the most general policy, if you have other more specific remote access policies, the default remote access policy should be the last policy in the list.

If you are using access by policy in a native-mode domain administrative model, the default remote access policy will deny all connections because the remote access permission on the default remote access policy is set to Deny remote access permission. Placing the default remote access policy at the end of the list has the same effect as removing it. In either case, the connection attempt is denied.

If you are using access by policy in a mixed-mode-domain administrative model, you must delete the default policy unless you want to grant remote access to all users using the default profile settings. In access by policy in a mixed-mode-domain administrative model, the remote access permission of all user accounts except for the Guest account and built-in accounts is set to Allow access. If you do not delete the default remote access policy, then all connection attempts using any user account are accepted. For network security reasons, this is rarely desirable. Therefore, by deleting the default remote access policy, you ensure that the only connections that are allowed are those for which specific remote access policies exist.

To recreate the default remote access policy:

Click Start, point to Programs, point to Administrative Tools, and then click Internet Authentication Service.
In Internet Authentication Service, right-click Remote Access Policies, and then click New Remote Access Policy.
In the Add Remote Access Policy wizard, do the following:
- In Policy friendly name, type a default name, and then click Next.
  
  When the Routing and Remote Access service is installed, the default remote access policy name is Allow access if dial-in permission is enabled, although you are not required to use this name.
- On the Conditions page, click Add, click Day-and-Time-Restrictions, click Add, and configure the attribute to permit all times on all days. Click OK, and then click Next.
- On the Permissions page, click Deny remote access permission, and then click Next.
- On the User profile page, click Finish. Do not make any changes to the user profile.

Copying policies from a remote access server to an IAS server

If you configure a Windows 2000 Routing and Remote Access server to use Windows authentication, it will use local remote access policies. If you later configure the Routing and Remote Access service to use RADIUS authentication, then the remote access policies on the IAS server are used. To transfer the configured remote access policies of the Routing and Remote Access server to the IAS server, perform this procedure:

At a command prompt on the Routing and Remote Access server, type netsh aaaa show config > path\file.ext. This stores the configuration settings, including registry settings, in a text file called file.ext. The path can be relative, absolute, or a UNC path.
Copy file.ext to the IAS server. At a command prompt on the IAS server, type netsh exec path\file.ext. A message appears indicating whether the update was successful.
Configure the Routing and Remote Access service for RADIUS authentication and accounting.

Settings Levels

With remote access permissions and connection parameters being configured on the user account, the IAS server, and the Routing and Remote Access server, it is important to understand the relationship between the different types of settings.

Configure dial-in properties of the user account to reflect the remote access policy administrative model and user account-specific properties such as Caller-ID, Callback Options, Static IP Address, and Static Routes. Setting the remote access permission to Allow access or Deny access will override the matching remote access policy permission. Setting the remote access permission to Control access through Remote Access Policy allows the matching remote access policy permission to determine the remote access permission.
Configure remote access policies on the IAS server that reflect the types of connections you will allow or reject and their associated connection parameters for all RADIUS clients (NASs) of the IAS server. The set of configured remote access policies on the IAS server is global to all RADIUS clients of the IAS server.
Configure Routing and Remote Access service properties to enable or disable all capabilities of the remote access server for all the types of connections that the remote access server supports. For example, a Windows 2000 Routing and Remote Access server can support dial-up remote access or demand-dial connections (using analog phone lines or ISDN) or VPN-based remote access or demand-dial connections (using PPTP or L2TP). When enabling authentication methods, enable all the types of authentication methods for all the types of clients connecting to the server. Be sure to include Windows 2000 and Windows 98 clients (MS-CHAP v1 and MS-CHAP v2), smart card-enabled Windows 2000 and Windows 98 clients (EAP), and third-party clients (CHAP and unauthenticated access).

When reconciling the settings of remote access policy profiles with the settings of the Routing and Remote Access service, it is important to understand the process from the perspective of Routing and Remote Access service design. When the remote access client attempts a connection, a PPP negotiation between the remote access client and the remote access server begins. The PPP negotiation consists of four phases:

PPP configuration
Authentication
Callback
Protocol Configuration

During Phase 1, an authentication protocol is negotiated by the PPP client and the Routing and Remote Access server, based on the preferred list of EAP, MS-CHAP v2, MS-CHAP v1, CHAP, SPAP, and PAP.

During Phase 2, the credentials of the PPP client are sent using the selected authentication protocol. The Routing and Remote Access server sends an Access-Request message to the IAS server. The Access-Request message contains a series of RADIUS attributes that describe the user and the parameters of the connection attempt.

The IAS server evaluates the contents of the Access-Request message against the settings of the RADIUS client, the user account dial-in properties, and the remote access policies. If the Access-Request message is authenticated and authorized, then the IAS server sends back an Access-Accept. If the Access-Request message is either not authenticated or not authorized, then the IAS server sends back an Access-Reject. If the Routing and Remote Access server receives an Access-Reject, then the connection attempt is rejected.

If the Routing and Remote Access server receives an Access-Accept, Phase 2 of the PPP authentication is completed. Phase 3 (Callback) and Phase 4 (Protocol Configuration) are attempted next. In Phase 4, network-layer protocols (such as IP) are configured, and compression and encryption are negotiated. It is during Phase 4 that a Routing and Remote Access server might reject the connection, even though the IAS server has returned an Access-Accept message.

For example, the remote access policy profile contains settings for IP-address-assignment behavior. By default, the Routing and Remote Access service does not allow clients to request their own IP addresses. Therefore, if the client requests its own IP address and matching policy profile setting on the IP tab is Server settings define policy, the Routing and Remote Access service rejects the connection. To allow the Routing and Remote Access service to allow clients to request their own IP address when the matching policy profile is set to Server settings define policy, set the following registry entry to 1: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess \Parameters\IP\AllowClientIPAddresses.

Another example is encryption. If the matching remote access policy profile settings require high encryption and the High Encryption Pack is not installed on the Routing and Remote Access server, then the connection attempt is rejected.

Reconciling authentication methods

When authentication methods are in conflict between the Routing and Remote Access server and the IAS server, the result is an Access-Reject message. If an authentication method is enabled on the Routing and Remote Access server, but not enabled on the matching remote access policy profile, then the IAS server returns an Access-Reject message. If an authentication method is not enabled on the Routing and Remote Access server, but is enabled on the matching remote access policy profile, then it is not offered as an authentication method during Phase 1 of PPP negotiation and does not become a connection parameter in the Access-Request message. Therefore, it does not match the profile settings of the matching policy and an Access-Reject message is sent.

However, during Phase 1 of PPP negotiation, a single PPP authentication protocol is chosen in the following order (or, in the case of EAP, EAP is chosen and an EAP type is chosen later):

EAP
MS-CHAP v2
MS-CHAP v1
CHAP
SPAP
PAP

Once the PPP authentication protocol is chosen, it is used during the authentication and authorization process. This behavior might cause confusion in the following example configuration:

A remote access client is configured to use either MS-CHAP v1 or MS-CHAP v2.
The Routing and Remote Access server is configured to allow MS-CHAP v1 and MS-CHAP v2.
A matching remote access policy is configured to allow only MS-CHAP v1.

This connection attempt would appear to be successful because MS-CHAP v1 is supported by the remote access client, the Routing and Remote Access server, and the IAS policy. However, when the remote access client attempts to connect, MS-CHAP v2 authentication is negotiated because it is higher in the list of preferred PPP authentication protocols. When the profile settings on the matching remote access policy are evaluated, the connection attempt is rejected.

The Routing and Remote Access server does not restart the PPP authentication process with the next authentication protocol in the list, MS-CHAP v1. Based on the receipt of the Access-Reject, it rejects the connection.

IAS Authentication and Authorization Process

The diagrams shown in Figures 13 and 14 below demonstrate the step-by-step IAS authentication and authorization process:

Figure 13: The IAS Authentication and Authorization Process (part 1)

Figure 14: The IAS Authentication and Authorization Process (part 2)

Note: The authentication and authorization process for the Routing and Remote Access service, when configured for Windows authentication, uses steps 4 through 14 of this process. In all steps, no RADIUS packets are sent. The authentication and authorization success and failure are the return values of functions called by the Routing and Remote Access service. Local event or authentication logging depends on the configured logging settings of the Routing and Remote Access service.

Validate RADIUS packet

The incoming Access-Request packet is validated for the source IP address, digital signature, valid attributes, and so on. If the RADIUS packet is not valid, an event is logged in the system-event log and the RADIUS Access-Request packet is discarded. An Access-Reject message is not sent.
Check for Auto Reject

Auto Reject is used to send an immediate Access-Reject packet when the User-Name attribute in the Access-Request packet matches a specific value. The periodic sending of an Access-Request packet and reception of an Access-Reject packet assures the RADIUS client that the RADIUS server is still present on the network. An Auto Reject Access-Request message requires special handling because it does not need to be evaluated for authentication and authorization. An authentication log entry is not created for Auto Reject requests. This is done to prevent Auto Reject messages from filling up the authentication log file.

To configure IAS for Auto Reject, configure the Ping User-Name registry setting (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IAS \Parameters) with the user name for Auto Reject packets. If the User-Name attribute of the Access-Request packet matches the Ping User-Name registry setting, an Access-Reject message is sent.
Apply realm-stripping rules

If the User-Name attribute in the Access-Request packet is not the Auto Reject name, then the user identity is determined. User identity is what IAS uses to identify the user for the purposes of authentication and authorization. Normally, the user identity is the string value of the User-Name RADIUS attribute. If the User-Name attribute is not present, the user identity is set to either the Guest account or the account specified by the Default User Identity registry value (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \RemoteAccess\Policy).

However, IAS can use any RADIUS attribute to identify the user. The attribute used is configurable by setting the User Identity Attribute registry setting (HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\RemoteAccess\Policy) to the number of the RADIUS attribute that is used for the user identity. By default, User Identity Attribute is set to 1, the value for the User-Name RADIUS attribute. For more information about the using the User Identity Attribute registry setting, see “Unauthenticated Access.”

Realm stripping rules are then applied, defining how the user identity is manipulated before the name is checked for existence. The realm stripping rules consist of an ordered set: <Original string to match>, <Replacement String>. IAS applies the realm stripping rules to the user identity in the configured order. For information about how to configure realm stripping and examples of using pattern syntax to create realm-stripping rules, see Windows 2000 Server online Help.
Perform name cracking

Name cracking is the resolution of the user identity to a user account. This is done by using user-principal names, Lightweight Directory Access Protocol (LDAP), distinguished names (DNA), Canonical Names, and so on. If a user principal name is encountered by IAS, IAS performs a query to the Active Directory global catalog in an attempt to resolve the name. To speed up this process, a copy of the global catalog should be located on a domain controller within the same site as the IAS server.

When the user identity does not contain a domain name, IAS supplies one. By default, the IAS-supplied domain name is the domain for which the IAS server is a member. You can specify the IAS-supplied domain name through the DefaultDomain registry setting (HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn).
Check for authentication plug-ins

The existence of authentication plug-ins is checked. Authentication plug-ins are optional components created with the IAS SDK. Each plug-in can return either Accept, Reject, or Continue. If an authentication plug-in returns an Accept, the user is considered to be authenticated and the account is validated. If the authentication plug-in returns a Reject, an Access-Reject packet is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings. If the authentication plug-in returns a Continue, then the next plug-in is checked. If there are no more plug-ins available, the user still needs to be authenticated.

The authentication plug-in can also return RADIUS attributes to be included in the Access-Accept packet.

If the authentication plug-in returns an Accept, remote access account lockout is not checked and step 6 is skipped.

Check for remote access account lockout

The IAS server registry is read for the remote access account lockout entry for the user account. If the account is locked out through remote access account lockout, IAS sends an Access-Reject message back to the NAS and logs an authentication event.

Note: Remote access account lockout is a security feature that is enabled through the Windows 2000 registry. Remote access account lockout is used to prevent dictionary attacks against user accounts. For more information about remote access account lockout, see the Security and IAS section. Remote access account lockout is not related to account lockout on the Windows 2000 user account and the implementation of account lockout policies through Windows 2000 Group Policy.

Check for MS-CHAP, CHAP, and PAP

If the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) versions 1 or 2, CHAP, or Password Authentication Protocol (PAP) are used to authenticate the remote access client, IAS consults an authentication module that is based on the authentication protocol to perform the authentication. The user’s credentials (user name and password) are authenticated against the user name and password of the accounts database (a domain or the local accounts database). The group membership of the user account is then determined. The exact method of authentication varies, depending on the authentication protocol.

If the authentication of the credentials is not successful, an Access-Reject packet is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

If either EAP or unauthenticated access is being used, then the user authentication process is bypassed. EAP authentication takes place later in this process. For unauthenticated access, no user authentication is performed.
Validate user account

Based on the user account determined through name cracking, the user account is validated to find out whether the account is locked out (which is not the same as remote access account lockout), whether the connection is occurring during the user account’s logon hours, is disabled, or has an expired password. If the user account is not valid, an Access-Reject packet is sent and the authentication-failure event is logged in the system event log or the IAS-authentication log, depending on the configured logging settings.
Perform policy evaluation

Remote access policies configured on the IAS server are evaluated to find a policy that matches the parameters of the connection. If a matching policy is not found, then an Access-Reject packet is sent and an event is logged. For more information about remote access policies and policy-evaluation logic, see the Remote Access Policies section.
Obtain dial-in properties and merge with profile settings

The dial-in properties for the user account associated with the connection and the profile properties from the matching policy are merged into a set of properties for the connection.
Check for EAP authentication

If EAP is the authentication protocol used for the connection attempt, EAP authentication occurs. The initial negotiation for EAP consists of selecting EAP as the PPP authentication protocol and negotiating an EAP type. Based on the EAP type, the profile settings for the matching policy are checked to ensure that the EAP type is allowed. If the EAP type is not allowed with the profile settings, an Access-Reject packet is sent and the authentication-failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

If the EAP type is allowed with the profile settings, EAP authentication for the EAP type occurs. IAS sends an EAP challenge to NAS asking it to start EAP negotiation. Communications between EAP dynamic-link libraries (DLLs) on the client and server are tunneled between the client and the IAS server using the RADIUS protocol. After this is process is complete, an EAP provider can return attributes that are sent back to the NAS in the Access-Accept packet. If EAP authentication fails, an Access-Reject packet is sent and the authentication-failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.
Check user properties and profile properties

The dial-in properties of the user account and the profile properties of the matching remote access policy are evaluated against the parameters of the connection attempt to ensure that it is allowed. If the connection attempt is not allowed, an Access-Reject packet is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.
Check for authorization plug-ins

The existence of authorization plug-ins is checked. Authorization plug-ins are optional components created with the IAS SDK. Each plug-in can return either a Reject or a Continue. If the authorization plug-in returns a Reject, an Access-Reject packet is sent and the authentication-failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings. If the authorization plug-in returns Continue, then the next plug-in is checked. If there are no more plug-ins, then the user is considered to be authorized. The authorization plug-in can also return RADIUS attributes to be included in the Access-Accept packet.
Send Access-Accept

If the dial-in properties of the user account, the profile properties of the matching remote access policy, and the conditions imposed by authorization plug-ins allow the connection attempt, an Access-Accept packet is sent back to the NAS. The packet contains the set of RADIUS attributes for the restrictions on the connection. An authentication-success event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

Unauthenticated Access

Unauthenticated access allows remote access users to be connected without checking their credentials. For example, IAS does not verify user name and password. The only user validation performed is authorization. Enabling unauthenticated access presents security risks that must be carefully considered.

This section discusses three scenarios of unauthenticated access:

Guest access.
Dialed Number Identification Service (DNIS) authorization.
Automatic Number Identification/Calling Line Identification (ANI/CLI) authorization.

Guest Access for PPP Connections

Guest access provides the ability to create a PPP connection without a user name and a password. Both the Routing and Remote Access service and IAS must be configured to support unauthenticated access. For the Windows 2000 Routing and Remote Access service, unauthenticated access is enabled from the Authentication tab in the server properties in the Routing and Remote Access administrative tool.

When a remote access server receives a connection attempt, it negotiates different authentication types enabled at the server with the user. If the client accepts one of the types, it sends the appropriate credentials for it. If the user refuses authentication, the Routing and Remote Access service checks its properties to verify if unauthenticated access is enabled and, if it is, forwards the Access-Request packet to IAS. This Access-Request packet does not contain a User-Name attribute or any other credentials.

When IAS receives the packet without a User-Name attribute, it assumes that the user wants to connect using Guest access. In this case, IAS uses the name of the Guest account in a domain as the user identity. It then evaluates policies in order to determine the correct profile. If a match is found, and unauthenticated access is enabled in the profile, other authorizations are validated and an Access-Accept packet is returned. The accounting log file logs the user identity and authentication type, which can be used to determine whether the user was logged on with Guest access.

Enabling Guest Access

To enable Guest access, perform these steps:

Enable unauthenticated access on the remote access server.
Enable unauthenticated access on the appropriate remote access policy.
Enable the Guest account.
Set the remote access permission on the Guest account to either Allow access or Control access through Remote Access Policy, depending on your remote access policy administrative model.

If you do not want to enable the Guest account, create a user account and perform step 4 above for the new user account. Then, set the Default User Identity registry value (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ RemoteAccess\Policy) on the authenticating server (either the remote access server or the IAS server) to the name of the account.

For more information about enabling authentication protocols, configuring authentication, and enabling a disabled user account, see Windows 2000 Server online Help.

Guest Access Example

During PPP negotiation, the client rejects all of the PPP authentication protocols of the NAS.
If the NAS is configured to allow unauthenticated access, the NAS sends an Access-Request packet without the User-Name attribute and password. For the Windows 2000 Routing and Remote Access service, unauthenticated access is enabled from the Authentication tab on the server properties in the Routing and Remote Access administrative tool.
The user identity is set to Guest (or the value of Default User Identity) because the User-Name attribute is not included in the Access-Request packet and, by default, the IAS user identity uses the User-Name attribute.
When the user identity is Guest and an unauthenticated connection attempt is made, the authentication and authorization process that was previously described is performed. If the connection attempt matches a policy with profile settings that enable unauthenticated access, and the Guest account is enabled and it has the appropriate remote access permission, IAS sends an Access-Accept packet to the NAS.

DNIS Authorization

Dialed Number Identification Service (DNIS) authorization is the authorization of a connection attempt based on the number called. This attribute is referred to as called station ID. DNIS identifies that number that was called to the receiver of the call and is provided by standard telecommunication companies. Based on the Called-Station-ID attribute, IAS can deliver different services to dial-up and remote access users.

Enabling DNIS Authorization

The following steps are required to enable DNIS authorization:

Enable unauthenticated access on the remote access server.
Create a remote access policy on the authenticating server (remote access server or IAS server) for DNIS-based authorization with the called-station-ID condition set to the phone number.
Enable unauthenticated access on the remote access policy for DNIS-based authorization.

ANI Authorization

ANI authorization is based on the number from which the user calls. This attribute is referred to as calling station ID or caller ID. Based on the calling-station-ID attribute, IAS can deliver different services to dial-up and remote access users.

Using ANI authorization is different from using the caller-ID dial-in property of a user account. ANI authorization is performed when the user does not provide a user name or password and refuses to use any valid authentication method. In this case, IAS receives calling-station-ID and no user name and password. To support ANI authorization, Active Directory must have user accounts with caller IDs as user names. This kind of authentication is used with cellular phones and by ISPs in Germany and Japan.

When using the caller ID property on a user account, the user types in standard credentials (such as a user name and password) and uses a valid authentication method to log on. IAS authenticates the user with the user name and password, and then compares the calling-station-ID attribute in the Access-Request to the caller-ID property of the user account to authorize the connection attempt.

Enabling ANI Authorization

Enable unauthenticated access on the remote access server.
Enable unauthenticated access on the appropriate remote access policy for ANI/CLI-based authentication.
Create a user account for each number that will be used to call in, for which you want to provide ANI/CLI authorization. The name of the user account must match the number from which the user is dialing. For example, if a user is dialing in from 555-0100, create a “5550100” user account.
Set the User Identity Attribute registry value (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ RemoteAccess\Policy) to 31 on the authenticating server.

This registry setting requires the authenticating server to use the calling number (RADIUS attribute 31, Calling-Station-ID) as the identity of the calling user. The user identity is set to the calling number only when there is no user name being supplied in the connection attempt.

To always use the calling number as the user identity, set the Override User-Name registry value (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ RemoteAccess\Policy) to 1 on the authenticating server.

However, if you set Override User-Name to 1 and the User Identity Attribute to 31, the authenticating server can perform only ANI/CLI-based authentication. Normal authentication by using authentication protocols such as MS-CHAP, CHAP, and EAP is disabled.

ANI Example

The following example describes how ANI/CLI authorization works for a client dialing in from the phone number 555-0100. A user account named “5550100” has been created.

During PPP negotiation, the client rejects all of the PPP authentication protocols of the NAS.
If the NAS is configured to allowed unauthenticated access, the NAS sends an Access-Request packet without the User-Name attribute and without a password.
Because the User-Name attribute is not included in the Access-Request packet and the IAS user identity is configured to use calling station ID, the user identity is set to “5550100”.
With the user identity of “5550100” and an unauthenticated connection attempt, the authentication and authorization process is performed as previously described. If the connection attempt matches a policy with profile settings enabling unauthenticated access and the “5550100” user account has the appropriate remote access permission, IAS sends an Access-Accept packet to the NAS.