Internet Authentication Service for Windows 2000

This paper describes the Internet Authentication Service (IAS) in Microsoft® Windows® 2000, the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server. RADIUS is an industry standard protocol to authenticate, authorize, and account for access server connections. IAS can be used as a RADIUS server to any device, typically a network access server (NAS), which supports RADIUS, including the Windows 2000 Routing and Remote Access service. IAS can be used in a variety of scenarios, including centralized authentication and accounting for an organization's remote access infrastructure, outsourced corporate access using third party dial-up service providers, and centralized authentication and accounting for an Internet service provider (ISP). This paper is written for network architects and system administrators using or considering the use of RADIUS and IAS in their network infrastructure.

On This Page

Introduction IAS Authentication and Authorization IAS Accounting IAS Configuration IAS Scenarios Security and IAS Performance and IAS Troubleshooting IAS Appendix A – Frequently Asked Questions Appendix B – The RADIUS Protocol Appendix C – Differences Between Windows NT 4.0 IAS and Windows 2000 IAS Appendix D – Using Pattern Matching Syntax for Realm Replacement Appendix E – IAS Events in the Windows 2000 System Event Log Appendix F – IAS Registry Settings Appendix G – Performance Monitor Counters and SNMP MIBs Summary

Introduction

Microsoft® Windows® 2000 Internet Authentication Service (IAS) is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server. IAS performs centralized connection authentication, authorization, and accounting for dial-up and virtual private network (VPN) remote access and for router-to-router connections. It can be used in conjunction with Windows 2000 Routing and Remote Access service. IAS enables the use of a single- or multiple-vendor network of remote access or VPN equipment.

Internet service providers (ISPs) and corporations maintaining remote access for their employees are faced with the increasing challenge of managing all remote access from a single point of administration, regardless of the type of remote access equipment employed. The RADIUS standard supports this functionality in both homogeneous and heterogeneous environments. RADIUS is a client-server protocol that enables remote access equipment acting as RADIUS clients to submit authentication and accounting requests to a RADIUS server.

The RADIUS server has access to user account information and can check remote access authentication credentials. If the user's credentials are authentic and the connection attempt is authorized, then the RADIUS server authorizes the user's access based on specified conditions and logs the remote access connections in an accounting log.

The use of RADIUS allows the remote access user authentication, authorization, and accounting data to be maintained in a central location, rather than on each network access server (NAS). Users connect to RADIUS-compliant NASs, such as a Windows 2000–based computer that is running the Routing and Remote Access service. The NASs then forward authentication requests to the centralized IAS server.

For more information about the RADIUS protocol, see Appendix B.

With IAS, organizations can also outsource remote access infrastructure to ISPs while retaining control over user authentication, authorization, and accounting.

Different types of IAS configurations can be created for using Internet technology, such as:

• Dial-up access to your network.

• Internet access.

• Outsourced corporate access through service providers.

IAS Overview

RADIUS is an industry standard protocol, described in RFC 2138, "Remote Authentication Dial-in User Service (RADIUS)," and RFC 2139, "RADIUS Accounting," for providing authentication, authorization, and accounting services. A RADIUS client, typically a dial-up server used by an Internet service provider (ISP), sends user and connection information to a RADIUS server. The RADIUS server authenticates and authorizes the RADIUS client request.

The Windows 2000 Routing and Remote Access service includes a RADIUS client so that a Windows 2000 remote access server can be used by ISPs or corporate remote access users who use RADIUS for authentication or accounting.

You can configure the Windows 2000 remote access server authentication and accounting providers separately. A Windows 2000 remote access server can use Windows authentication as its authentication provider and RADIUS as its accounting provider. You can configure multiple RADIUS servers so that when the primary RADIUS server becomes unavailable, secondary RADIUS servers are automatically used.

Windows 2000 IAS features include:

• Centralized PPP-based connection authentication and authorization.

• Centralized administration of dial-up and VPN connections.

• Centralized auditing and usage accounting.

• Integration with Windows 2000 Routing and Remote Access service.

• Outsourced dialing.

• Easy administration.

• Scalability.

• Extensibility.

Centralized PPP-based Connection Authentication and Authorization

The authentication of users attempting connections is an important security concern. Because IAS supports a variety of authentication protocols, you can use arbitrary authentication methods to meet your authentication requirements.

The following section describes the authentication methods supported in Windows 2000.

• IAS supports the authentication protocols within the Point-to-Point Protocol (PPP), such as Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) versions 1 and 2, and Extensible Authentication Protocol (EAP). PPP is a set of industry-standard framing and authentication protocols that enables remote access solutions to be interoperable in a multi-vendor network.

• EAP is an infrastructure that allows the addition of arbitrary authentication methods such as smart cards, certificates, one-time passwords, and token cards.

• Dialed Number Identification Service (DNIS) is an authorization method based on the number called by the user.

• Automatic Number Identification/Calling Line Identification (ANI/CLI) is an authorization method based on the number from which the user calls. ANI is also known as caller ID.

• Guest authentication is an authorization method through which the caller does not send a user name or password during the authentication process. If unauthenticated access is enabled, the Guest account is used as the identity of the caller by default.

To grant the connecting user-appropriate access to the network, IAS authenticates users in Windows 2000 Active Directory™ service domains, Microsoft® Windows NT® 4.0 domains, or the local Security Accounts Manager (SAM) in Windows 2000. IAS supports new features in Active Directory, such as user principal names and universal groups.

Remote access policies are a set of conditions that network administrators can use to get more flexibility in granting remote access. They provide flexibility in controlling who is allowed to connect to your network. Although it is simple to manage remote access permission for each user account, this approach can become unwieldy as your organization grows. Remote access policies provide a more powerful and flexible way to manage remote access permission.

You can use remote access policies to control remote access based on a variety of conditions, such as:

• User membership in a Windows security group.

• The connection time of day or day of the week.

• The type of media through which the user is connecting (for example, ISDN, modem, or a VPN tunnel).

• The type of VPN tunneling protocol used (Point-to-Point Tunneling Protocol or Layer Two Tunneling Protocol).

• The phone number the user calls.

• The phone number from which the user calls.

Each remote access policy contains a profile of a setting from which you can control connection parameters. For example, you can:

• Permit or deny the use of certain authentication methods.

• Control the amount of time the connection can be idle.

• Control the maximum time of a single session.

• Control the number of links in a Multilink session.

• Control encryption settings.

• Add packet filters, controlling what the user can access when connected to the network. For example, you can use filters to control from which IP addresses, hosts, and ports the user is allowed to send or receive packets.

• Create a mandatory tunnel that forces all packets from that connection to be securely tunneled through the Internet and terminated in a private network.

• Allow users to request a specific IP address or specify that the remote access server must assign an IP address.

Centralized Administration of Dial-up and VPN Connections

Support for the RADIUS standard allows IAS to control connection parameters for any network access server that implements that standard. The RADIUS standard also allows individual remote access vendors to create proprietary extensions called vendor-specific attributes. IAS has the extensions from a number of vendors incorporated into its multi-vendor dictionary.

Centralized Auditing and Usage Accounting

Support for the RADIUS standard allows IAS to collect the usage (accounting) records sent by a NAS at a single point. IAS logs audit information (for example, authentication Accepts and Rejects) and usage information (for example, logon and logoff records) to log files. IAS supports a log file format that can be directly imported into a database. The data in the database can be analyzed by using other data-analysis software.

Integration with Windows 2000 Routing and Remote Access Service

The Windows 2000 Routing and Remote Access service is configured to use Windows authentication and accounting or to use RADIUS authentication and accounting. When RADIUS authentication or accounting is selected, any RFC-compliant RADIUS server can be used. However, using an IAS server is recommended to take advantage of centralized remote access policies.

For example, in a small network environment or in branch offices with a small number of remote access servers and no requirements for centralized management of remote access, the Routing and Remote Access service can be configured to use Windows authentication and accounting.

In a global enterprise with large numbers or remote access servers deployed worldwide, centralized authentication and accounting using IAS can be beneficial. However, if a small branch office has a high latency connection to the global enterprise with the centralized IAS server, the Windows authentication and accounting configuration can be copied from a central location to the remote access servers of the branch office.

IAS and the Routing and Remote Access service share the same remote access policies, authentication, and accounting-logging capabilities. When the Routing and Remote Access service is configured for Windows authentication, local policies and logging are used. When the Routing and Remote Access service is configured as a RADIUS client to an IAS server, the policies and logging of the IAS server are used.

This integration provides consistent implementation across IAS and the Routing and Remote Access service. You can deploy the Routing and Remote Access service in small sites without the need for a separate, centralized IAS server. It also provides the capability to scale up to a centralized remote access management model when you have multiple remote access servers in your organization. In this case, IAS, in conjunction with remote access servers, implements a single point of administration for remote access to your network for outsourced-dial, demand-dial, and VPN access. The policies within IAS at a central large site can be exported to the independent remote access server in a small site.

Outsourced Dialing

Outsourced dialing involves a contract between an organization or private company and an ISP in which the ISP allows the organization's employees to connect to the ISP's network before establishing the VPN tunnel to the organization's private network. When an employee connects to the ISP's remote access server, the authentication and usage records are forwarded to the IAS server at the organization. The IAS server allows the organization to control user authentication, track usage, and manage which employees are allowed to gain access to the ISP's network.

The advantage of outsourcing is the potential savings. For example, by using an ISP's routers, network access servers, and T1 lines, you can save a great deal on hardware and other costs related to infrastructure. You can also decrease the cost of your long-distance phone bill by dialing into a local ISP with worldwide connections. By handing off support to the provider, you can eliminate a large amount of your administrative budget.

Easy Administration

IAS is easy to administer with the following tools:

• Graphical User Interface.

  IAS provides a graphical user interface snap-in that enables you to configure local or remote IAS servers.

• Remote Administration.

  The Internet Authentication Service administrative tool can be used to administer local or remote IAS servers from a central location.

• Remote Monitoring.

  You can monitor IAS by using Windows 2000–based tools, such as Event Viewer or System Monitor, or by using Simple Network Management Protocol (SNMP).

• Import/Export of Configuration to Manage Multiple IAS Servers.

  IAS server configuration settings can be exported to a file and then imported to another IAS server. For more information, see the section on Remote Access Policy Management.

Scalability

You can use IAS in a variety of network configurations of varying size, from stand-alone servers for small networks to large corporate and ISP networks.

To provide fault tolerance for RADIUS authentication and accounting, two IAS servers—a primary server and a backup server—are used. The primary IAS server handles all RADIUS requests until it becomes unavailable. When the primary server becomes unavailable, the RADIUS client automatically uses the backup IAS server.

In very high volume configurations, multiple servers running IAS using an IP load-balancing scheme act as the primary IAS server. An IP load-balancing cluster dynamically balances the load of RADIUS requests across the multiple servers in the cluster.

Extensibility

IAS functionality can be extended through the IAS Software Development Kit (SDK) and the EAP Software Development Kit, available in the Windows 2000 Software Development Kit.

IAS SDK can be used to implement additional features. You can extend IAS functionality to:

• Return custom attributes to the network access server (NAS) in addition to those returned by IAS, enabling you to build your own plug-in for assigning IP addresses.

• Control the number of simultaneous end-user network sessions.

• Extend the remote access authorizations currently provided by IAS.

• Import usage and audit data directly into an Open Database Connectivity (ODBC)-compliant database.

• Create custom (non-EAP) authentication methods for IAS.

The EAP SDK provides the capability to implement arbitrary authentication methods. For more information on the IAS and EAP SDKs, see the Windows 2000 Software Development Kit.

IAS Authentication and Authorization

In the process of identifying dial-up users and admitting them to a secure network or site, different servers handle different parts of the task. An NAS operates as a client of an IAS server. The client passes user information to designated IAS servers, and then acts on the response.

The IAS server receives user connection requests, authenticates the user, authorizes the connection attempt, and then returns all configuration information necessary for the RADIUS client to deliver service to the user. Figure 1 illustrates the standard IAS authentication and authorization process:

Figure 1: The IAS Authentication Process

When a user attempts to connect to a network through a dial-up connection or virtual private network, the authentication request is processed as follows:

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

2. 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.

3. 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.

4. The IAS server queries the Windows 2000-based domain controller, validating the user's credentials.

5. 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:

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

2. Enable PAP on the appropriate remote access policy (PAP is disabled by default).

3. 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:

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

2. Enable CHAP on the appropriate remote access policy.

3. 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.

4. 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.

5. 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:

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

2. Enable MS-CHAP on the appropriate remote access policy. MS-CHAP is enabled by default.

3. 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:

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

2. 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:

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

2. Enable MS-CHAP v2 on the appropriate remote access policy. MS-CHAP v2 is enabled by default.

3. 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:

1. Enable EAP as an authentication protocol on the remote access server.

2. Enable EAP and, if needed, configure the EAP type on the appropriate remote access policy.

3. 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:

1. RAS1 passes the user name of user@forest2.microsoft.com to the RADIUS proxy using a RADIUS Access-Request message.

2. 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.

3. IAS2 authenticates and authorizes the connection attempt and sends a RADIUS Access-Accept message back to the RADIUS proxy.

4. 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.

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:

1. Install the Windows 2000 IAS as a RADIUS server on a computer.

2. Configure IAS with RADIUS clients that correspond to each of the Windows 2000 remote access or VPN servers.

3. On the IAS server, create the central set of policies that will be used by all Windows 2000 remote access servers.

4. 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 day of the week and the time of day of the connection attempt of the server.
Client IP Address	The IP address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern matching syntax to specify IP networks. 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.
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.

IP

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:

1. Click Start, point to Programs, point to Administrative Tools, and then click Internet Authentication Service.

2. In Internet Authentication Service, click Remote Access Policies.

3. Right-click the policy for which you want to configure a vendor-specific attribute, and then click Properties.

4. Click Edit Profile, click the Advanced tab, and then click Add.

5. In the list of available RADIUS attributes, double-click Vendor-Specific.

6. Click Add.

7. Click Select from the list, and then click Cisco.

8. Click Yes. It conforms, and then click Configure Attribute.

9. In Vendor-assigned attribute number, type 1.

10. In Attribute format, click String.

11. 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

1. Click Start, point to Programs, point to Administrative Tools, and then click Internet Authentication Service.

2. In Internet Authentication Service, click Remote Access Policies

3. Right-click the policy for which you want to configure a vendor-specific attribute, and then click Properties.

4. Click Edit Profile, click the Advanced tab, and then click Add.

5. In the list of available RADIUS attributes, double-click Vendor-Specific, and then click Add.

6. Click Select from the list, and then click US Robotics.

7. Click No. It does not conform, and then click Configure Attribute.

8. 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:

1. The first policy in the ordered list of remote access policies is checked. If there are no policies, then reject the connection attempt.

2. 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:

1. Access by user.

2. Access by policy in a Windows 2000 native-mode domain.

3. 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:

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

2. Explicit deny

   The remote access permission for the user account is set to Deny access.

3. 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:

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

2. 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.

3. 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:

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

2. 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.

3. 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:

1. Click Start, point to Programs, point to Administrative Tools, and then click Internet Authentication Service.

2. 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:

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

2. 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.

3. 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:

1. PPP configuration

2. Authentication

3. Callback

4. 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):

1. EAP

2. MS-CHAP v2

3. MS-CHAP v1

4. CHAP

5. SPAP

6. 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.

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

2. 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.

3. 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.

4. 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).

5. 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.

6. 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.

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

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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:

1. Guest access.

2. Dialed Number Identification Service (DNIS) authorization.

3. 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:

1. Enable unauthenticated access on the remote access server.

2. Enable unauthenticated access on the appropriate remote access policy.

3. Enable the Guest account.

4. 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

1. During PPP negotiation, the client rejects all of the PPP authentication protocols of the NAS.

2. 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.

3. 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.

4. 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:

1. Enable unauthenticated access on the remote access server.

2. 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.

3. 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

1. Enable unauthenticated access on the remote access server.

2. Enable unauthenticated access on the appropriate remote access policy for ANI/CLI-based authentication.

3. 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.

4. 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.

1. During PPP negotiation, the client rejects all of the PPP authentication protocols of the NAS.

2. 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.

3. 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".

4. 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.

IAS Accounting

IAS supports RADIUS accounting, which an administrator can use to track network usage for auditing and billing purposes. RADIUS accounting provides these benefits:

• Real-time data collection.

• Accounting data can be collected at the centralized place.

• Other products can be used to analyze RADIUS accounting data and provide charge-back, performance, and exception reports.

When a client is configured to use RADIUS accounting, it generates an Accounting-Start packet describing the type of service being delivered and the user to whom it is being delivered at the start of service delivery. The packet is sent to the RADIUS accounting server, which returns an acknowledgment verifying that it has been received. At the end of service delivery, the client generates an Accounting-Stop packet describing the type of service that was delivered and some optional statistics, such as elapsed time, input and output octets, and input and output packets. It then sends that data to the RADIUS accounting server, which returns an acknowledgment that the packet has been received.

The Accounting-Request packet (whether for Accounting-Start or Accounting-Stop) is submitted to the RADIUS accounting server through the network. If no response is returned within a specified period of time, the request is resent several times. The client can also forward requests to an alternate server or servers, in the event that the primary server is unavailable. An alternate server can be used either after a number of failed attempts to the primary server or in a round-robin fashion. If the RADIUS accounting server is unable to successfully record the accounting packet, it does not send an Accounting-Response acknowledgment to the client. For example, when the log file is completely filled, IAS starts discarding accounting packets, prompting the NAS to switch to the backup IAS server.

IAS Log File

IAS can create a log file based on the data returned by the network access servers. This information is useful for keeping track of usage and for correlating authentication information with accounting records (for example, to discover missing records).

IAS supports two formats of the log file:

• Database format.

  You can use database format to keep track of a predetermined set of attributes. Use the database format if you want to import the data directly into a database.

• IAS format.

  You can use the IAS format if you want to record more detailed information than the database log format allows. IAS format can contain information about all attributes.

Note: The IAS log file contains all IAS user-related events. IAS service and system-related events are recorded in the Windows 2000 system event log.

For more information on the format of the IAS log files, see Windows 2000 Server Help.

IAS Configuration

The configuration of IAS consists of these settings:

• Global properties for the IAS server, which are independent of RADIUS clients.

• RADIUS clients, involving one client for each NAS that is sending RADIUS packets to the IAS server.

• Remote access policies, consisting of the list of policies to allow or reject all connection types for all RADIUS clients of the IAS server.

• Remote access logging, which consists of the types of events to be logged, the log file format, and log file settings.

Beyond the configuration of IAS, this section also includes information on how to configure the Windows 2000 Routing and Remote Access service as a RADIUS client to an IAS server.

Note: All of the instructions below begin from the Internet Authentication Service administrative tool.

IAS Properties

To configure global properties of an IAS server, right-click Internet Authentication Service, and then click Properties.

Service Tab

Figure 15 shows the Service tab for an IAS server:

Figure 15: The Service tab for the Properties of an IAS Server

The Service tab is used to:

• Type a name of the server to distinguish it from other IAS servers. The default name is IAS.

• Enable or disable the logging of rejected or discarded authentication requests in the Windows 2000 system event log. This option is enabled by default.

• Enable or disable the logging of successful authentication requests in the Windows 2000 system event log. This option is enabled by default.

RADIUS Tab

Figure 16 shows the RADIUS tab for an IAS server:

Figure 16: The RADIUS tab for the Properties of an IAS Server

The RADIUS tab is used to do the following:

• Enumerate the list of UDP ports over which RADIUS authentication messages are sent and received. By default, IAS uses UDP ports 1812 and 1645. UDP port 1812 is the reserved RADIUS-authentication port described in RFC 2138. UDP port 1645 is used by earlier RADIUS clients.

• Enumerate the list of UDP ports over which RADIUS accounting messages are sent and received. By default, IAS uses UDP ports 1813 and 1646. UDP port 1813 is the reserved RADIUS accounting port described in RFC 2139. UDP port 1646 is used by earlier RADIUS clients.

Realms Tab

Figure 17 shows the Realms tab for an IAS server:

Figure 17: The Realms tab for the Properties of an IAS Server

The Realms tab is used to configure a prioritized list of find-and-replace rules to manipulate realm names before name-cracking and authentication. Pattern-matching syntax is used to specify the strings to find and replace. For more information on pattern matching syntax, see Appendix D. Find-and-replace rules can be added, edited, and removed. The rules are applied to the incoming user name in the order in which they are listed. Use the Move Up and Move Down buttons to specify the order.

Clients

To add a new RADIUS client for the IAS server, right-click Clients, and then click New Client. The IAS New Client wizard will guide you through the procedure. To modify an existing client's properties, right-click the client name and then click Properties.

Figure 18 shows the properties of a RADIUS client:

Figure 18: The Properties of a RADIUS Client

The Settings tab is used to:

• Specify a friendly name for the RADIUS client. This name does not have to correspond to the DNS, NetBIOS, or computer name of the RADIUS client.

• Specify either the IP address or the DNS name of the RADIUS client. If you specify the DNS name, you can verify that the name is being resolved to the correct address. If the DNS name is associated with multiple IP addresses, you can choose the address to use.

• Specify the vendor of the RADIUS client. Select RADIUS standard for a vendor-independent client. For a Windows 2000 Routing and Remote Access server, select Microsoft.

• Specify whether the client must always include the RADIUS signature attribute (also known as a digital signature) in Access-Request messages for connection requests using the PAP, CHAP, MS-CHAP v1, and MS-CHAP v2 authentication protocols. With EAP, the signature attribute is always required. If you enable this, you must ensure that the RADIUS client is configured to always send the signature attribute. Otherwise, IAS will discard the Access-Request upon receipt.

• Specify and verify the shared secret. The shared secret is a password used between IAS and this specific RADIUS client to mutually verify identity. Both IAS and the RADIUS client must be configured with the same shared secret for successful communication to occur. The shared secret can be up to 128 bytes long, is case-sensitive, and can contain alphanumeric and special characters. To protect your IAS server and your RADIUS clients from dictionary and denial-of-service attacks, make the shared secret a long (more than 16 characters) sequence of random letters, numbers, and punctuation.

Remote Access Logging

Remote access logging in the Internet Authentication Service administrative tool is used to configure log file settings. To access the properties for local logging, click Remote Access Logging, right-click Local File, and then click Properties.

Settings Tab

Figure 19 shows the Settings tab in Local File Properties:

Figure 19: The Settings Tab for the Local File Properties in Remote Access Logging

The Settings tab is used to:

• Enable or disable the logging of accounting requests in the IAS log file. Accounting requests include Accounting-On, Accounting-Off, Accounting-Start, and Accounting-Stop messages. IAS logs only accounting requests sent by the RADIUS client. If the RADIUS client is not configured for RADIUS accounting, then accounting requests for that client are not logged. This setting is not enabled by default.

• Enable or disable the logging of authentication requests in the IAS log file. This setting is not enabled by default.

• Enable or disable the logging of interim accounting requests in the IAS log file. This setting is not enabled by default.

Local File Tab

Figure 20 shows the Local File tab in Local File Properties:

Figure 20: The Local File Tab for the Local File Properties in Remote Access Logging

The Local File tab is used to:

• Specify the log file format. The database-compatible format is an ODBC-compatible format that is typically selected when you want to move the log file information to a database program. The IAS format is an ID-value paired format that provides information on all RADIUS attributes in the RADIUS message. By default, IAS format is selected.

• Specify the duration of the log file or its maximum size. By default, Unlimited file size is selected.

• Specify the location of the IAS log file.

For more information about log file format, see Windows 2000 Server Help.

Configuring Windows 2000 Routing and Remote Access Service for RADIUS

On a Routing and Remote Access server, RADIUS authentication and accounting is configured from the Security tab on the properties of a Routing and Remote Access server (right-click the server name in the Routing and Remote Access administrative tool, and then click Properties).

Figure 21 shows the Security tab for the Routing and Remote Access server properties:

Figure 21: The Security Tab for the Routing and Remote Access Server Properties

To configure the Routing and Remote Access server for RADIUS authentication, select RADIUS Authentication in Authentication provider. To configure the Routing and Remote Access server for RADIUS accounting, select RADIUS Accounting in Accounting provider.

Figure 22 shows the authentication settings for a RADIUS server:

Figure 22: The Settings for RADIUS Server Authentication

The Add/Edit RADIUS Server dialog box is used to do the following:

• Specify the DNS name or IP address of the RADIUS server.

• Specify the shared secret.

• Specify the amount of time in seconds to wait for a response from this RADIUS server before trying another RADIUS server.

• Specify the initial responsiveness score of this RADIUS server.

• Specify the UDP port used by the Routing and Remote Access service for sending and receiving RADIUS authentication messages.

• Specify whether the Routing and Remote Access server must always include the RADIUS signature attribute in Access-Request messages for PAP, CHAP, MS-CHAP v1, and MS-CHAP v2. With EAP, the signature attribute is always required. If you enable this, you must ensure that the RADIUS server is configured to always receive the signature attribute. This is the RADIUS client setting that corresponds to the IAS RADIUS client setting called Client must always send the signature attribute in the request.

Figure 23 shows the settings for a RADIUS server for accounting:

Figure 23: The Settings for RADIUS Server Accounting

The Add/Edit RADIUS Server dialog box is used to:

• Specify the DNS name or IP address of the RADIUS server.

• Specify the shared secret.

• Specify the amount of time in seconds to wait for a response from this RADIUS server before trying another RADIUS server.

• Specify the initial responsiveness score of this RADIUS server.

• Specify the UDP port used by the Routing and Remote Access service for sending and receiving RADIUS accounting messages.

• Specify whether the Routing and Remote Access server sends the RADIUS Accounting-On and Accounting-Off messages when the Routing and Remote Access service is started and stopped.

IAS Scenarios

IAS is deployed in these common scenarios:

• Dial-up corporate access.

• Outsourced corporate access through service providers.

• Internet access.

Dial-up Corporate Access

This section describes how IAS can be set up to support remote authenticated dial-up connections to the corporation. This scenario shows a typical setup and configuration for a corporation with clients requiring access to the corporate network.

This section covers the following:

• Corporate characteristics and requirements for authentication.

• Network components installed to support this corporate environment.

• The remote user authentication process to be implemented in this scenario.

• The setup of the network components required to support this authentication process.

• Implementation and administration considerations.

Characteristics and Requirements

The corporation used in this scenario has a large primary location with multiple sales locations. All locations require secure access to the corporate network. The corporation requires a reliable method to authenticate remote users in an environment that has the following characteristics:

• The corporate network uses Active Directory to control user access.

• Sales locations have demand-dial connections to the corporate network.

• Remote management of network servers is required.

• Access capabilities are not identical for all employees, and access is given to specific employees based on the group to which they belong (for example, corporate employees are granted remote access, but contract employees are not).

• Users must be able to access the network when dialing in from home and during travel.

Note: This scenario covers only IAS setup and some basic steps for configuring Windows 2000 Routing and Remote Access. For more information, see Remote Access Scenarios in Windows 2000 Server Help.

Network Components

IAS servers are set up on the corporate network to authenticate remote users. The following components are installed to support this scenario:

• In the corporate network:

  • A primary IAS server and a backup IAS server running Windows 2000 Server and connected to the local area network (LAN). The IAS server is used as the RADIUS server, performing authentication, authorization, accounting, and auditing of the remote access users.

  • Active Directory domain controllers running Windows 2000 Server and connected to the LAN. Active Directory contains the user accounts and groups used to set up remote access policies for remote users.

  • Network access servers (NASs) running the Routing and Remote Access service component of Windows 2000 Server and connected to the LAN. The NAS operates as a RADIUS client and is responsible for passing user information to the appropriate RADIUS servers (in this scenario, IAS), and then acting on the response.

    Note: This scenario uses Routing and Remote Access servers as the NASs. If you use other RADIUS-compatible NASs (such as CISCO, Ascend, or US Robotics), then you need to change the configuration to reflect their use.

• For each remote dial-up user:

  • A computer with a modem (or other supported communications device) and connection software configured to support standard dial-up access capabilities using Point-to-Point Protocol (PPP).

Authentication Process for This Scenario

The network components determine the authentication process. Using the setup and configuration as specified in this scenario, accounting and authentication are accomplished as follows:

• When the NAS is started, an Accounting-On packet is sent.

• When a remote user dials up the corporation, the process illustrated in Figure 24 occurs, and all requests and responses are logged:

  

  Figure 24: The Authentication Process for a Dial-up Corporate Access Scenario

  1. The user dials the corporate number, reaching the NAS.

  2. The NAS sends the RADIUS authentication request to the IAS server.

  3. IAS forwards the authentication request to the domain controller, where the user credentials are checked.

  4. IAS uses the remote access policies and the user attributes to determine if dial-up access is allowed.

     Note: IAS requires permission to read the attributes from the user account. This permission is given if the server is a member of the built-in RAS and IAS Servers security group.

  5. If a remote access policy is matched, and the profile does not reject the user, then IAS sends an Access-Accept packet.

     The user is granted access based on the connection settings specified in the Access-Accept packet. The NAS then assigns an IP address and other parameters to the client and starts routing the packets sent to and received from the client.

     • The NAS sends an Accounting-Start packet to the IAS server, indicating that the user session has started.

     • During the session, interim accounting packets are sent.

     • When the user disconnects, the NAS sends an Accounting-Stop packet to the IAS server, indicating the end of the user session.

Setup

To set up IAS to support this scenario, complete these steps:

1. Verify that the domain controllers have been configured to support the remote users.

2. Install and configure IAS.

3. Copy the IAS configuration from the primary IAS server to the backup IAS server.

4. Register the primary and backup IAS servers with Active Directory.

5. Verify the configuration of RADIUS accounting and authentication on the NASs.

6. Verify the connection capabilities of the remote users.

The following information provides details about each of these setup steps and the requirements for their completion:

Step 1: Verify that the domain controllers have been configured to support the remote users.

Verify that the remote users are in the appropriate universal and nested groups, that the computer running IAS has permission to read the user accounts in the domain, and that the user names and passwords are valid by testing their ability to log on to the LAN.

Note: If you specify support for CHAP, you need to configure support for reversibly encrypted passwords. For more information, see Windows 2000 Server online Help.

Step 2: Install and configure IAS.

To set up the primary IAS server in the corporate network, do the following:

1. Verify that the IAS server is a member of the forest against which it will authenticate remote users (a trust relationship is required for this, and all domains in Active Directory forests automatically have trust relationships with each other). If IAS and the user account are not in the same forest, the domain for the user account must have a trust relationship with the domain in which IAS is a member. For more information on trust relationships, see Understanding Domain Trusts in Windows 2000 Server Help.

2. Log on with Local Administrative credentials.

3. If you did not select IAS as an optional component when you installed Windows 2000 Server, install it using Add/Remove Programs in Control Panel.

4. Click Start, point to Programs, point to Administrative Tools, and then click Internet Authentication Service.

   In the Internet Authentication Service console, right-click Internet Authentication Service and then click Properties to configure the properties for the primary IAS server:

   • On the Service tab, select both options for event logs.

   • On the RADIUS tab, specify the RADIUS authentication and RADIUS accounting UDP ports to be used, and then click OK.

     Note: These ports must be the same as those used by the NASs. The current RADIUS standards are UDP ports 1812 (for RADIUS authentication) and 1813 (for RADIUS accounting). The default values are set to the commonly used values: UDP ports 1812 and 1645 for authentication and 1813 and 1646 for accounting. If you are unsure of your port settings, see your vendor-specific documentation for the NAS.

   • Realm names are not used in this example and information is not required on the Realms tab.

5. Configure IAS support for the RADIUS clients. To do this, in the console tree, right-click Clients, click New Client, and then follow the directions to add and specify information about each RADIUS client (each NAS), specifying the Friendly name, Protocol (specified as Radius), Client address, Client-Vendor information (specified as RADIUS Standard), and the Shared secret.

   Notes: Ensure that the shared secrets for both authentication and accounting in IAS match those specified for the NASs.

   Before enabling the option to check digital signatures, ensure that the NAS supports the sending of a digital signature for authentication types other than Extensible Authentication Protocol (EAP). For EAP, digital signature is always checked and you do not have to select the digital signature option.

6. Set up remote access policies. Because permanent and contract employees have different access restrictions, set up separate policies for each:

Set up the policy for permanent employees by doing the following:

1. In the Internet Authentication Service console tree, right-click Remote Access Policies, and then click New Remote Access Policy.

2. In the Add Remote Access Policy dialog box, specify a name for the policy. For this scenario, you can enter Permanent employees, and then click Next.

3. In the next dialog box, click Add to specify a condition for this policy.

4. In the Select Attribute dialog box, under Attribute types, select Windows-Groups, and click Add twice. Then select the name of the groups to which this policy is to be applied (such as Permanent employees group), click Add, and then click OK twice.

5. In the Add Remote Access Policy dialog box, click Next.

6. Click Grant remote access permission, and then click Next.

7. Click Edit Profile.

8. In the Edit Dial-in Profile dialog box, on the Authentication tab, select MS-CHAP and MS-CHAP v2 as the authentication methods, and then click OK. Use the defaults for all other settings in the profile.

9. Click Finish.

Set up a remote access policy for contract employees that is the same as for permanent employees, except that it includes a condition that limits the hours of permitted access. To set up this policy, repeat the steps that you used to set up the policy for permanent employees, but specify the name of the policy as Contract Employees and then use the following steps to restrict access hours:

1. In the details pane of the Internet Authentication Service console tree, double click Contract Employees.

2. In the Contract Employees Properties dialog box, click Add to add another condition.

3. In the Select Attribute dialog box, select Day-And-Time-Restrictions, and then click Add.

   In the Time of day constraints dialog box, select the hours of access (for example, 7 AM to 7 PM on weekdays only), select Permitted, and then click OK twice.

   • To ensure that your configured policies do not conflict with the default policy (Allow access if dial-up permission is enabled), delete the default policy.

Configure logging for user authentication and accounting.

Although you can specify the basic logging configuration in IAS, you might want to create additional programs to use the logging data for accounting and troubleshooting. For example, you can set up a program to track departmental usage of remote access capabilities. For this scenario, consider the following when configuring logging:

• You should use the database-import log format for your log files to facilitate incorporation and use of the data in your own programs. If you select this format, you can use a database program to directly analyze the log file for usage, access, and report generation.

• You should specify that all types of requests received by the server (including authentication, accounting, and periodic updates) be logged. If you determine later that not all of this logging information is required, you can change your selection.

Step 3: Copy the IAS configuration from the primary IAS server to the backup IAS server.

Copy the client configurations, remote access policies, and logging configuration to the backup IAS server. For more information on copying the IAS configuration from one server to another, see the Remote access Policy Management section.

Step 4: Register the primary and backup IAS servers with Active Directory.

To authenticate users, the primary and backup IAS servers must be registered on the domain controllers in Active Directory in the built-in groups as members of the RAS and IAS Servers security group. Add the IAS servers by doing the following:

1. Log on to the server using domain administrator credentials.

2. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

3. In the console tree, click Users.

4. In the details pane, right-click RAS and IAS Servers.

5. In the RAS and IAS Servers Properties dialog box, on the Members tab, add each of the IAS servers.

Note: You can also use the netsh ras register server [domain] [server] command for server registration.

Step 5: Verify the configuration of RADIUS accounting and authentication on the NASs.

To ensure that the RADIUS accounting and authentication configuration has been appropriately configured on each NAS using Windows 2000 Server Routing and Remote Access, and to verify that the configuration matches that of IAS (as specified in Steps 2 and 3), do the following:

1. Log on to the server using domain administrator credentials.

2. Click Start, point to Programs, point to Administrative Tools, and then click Routing and Remote Access.

   For each NAS on which you have installed Routing and Remote Access, right-click the server name, click Properties, and then check the following information:

   • On the General tab, verify that Remote access server is selected.

     On the Security tab, verify the following:

     • RADIUS Authentication is selected and is configured with the names of the primary and backup IAS servers, each with the appropriate shared secret and port. Be certain that MS-CHAP v2 and MS-CHAP are selected under Authentication Methods.

     • RADIUS Accounting is selected and is configured with the names of the primary and backup IAS servers, each with the appropriate shared secret and port, and with the Send RADIUS Accounting-On and Accounting-Off messages option selected.

     On the IP tab, verify that the following are selected:

     • Enable IP routing.

     • Allow IP-based remote access and demand-dial connections.

     • Dynamic Host Configuration Protocol (DHCP).

Step 6: Verify the connection capabilities of the remote users.

The final step in setting up IAS is to verify that the remote dial-up users can use Network and Dial-up Connections to access the corporate network.

Implementation and Administration Considerations

Depending on the size of your corporation, a single IAS server is probably sufficient. In many cases, the IAS server can be installed on the same computer as the domain controller.

Note: This scenario provides a basic implementation plan for a corporate environment. You can adjust the number of servers and other implementation decisions to support the requirements of your environment.

All IAS administration can be managed remotely.

If remote access policies need to be updated, update the policies on the primary IAS server, and then copy the configuration to the other IAS servers.

Outsourced Corporate Access Through Service Providers

This section describes how IAS can be set up to support a corporation that has outsourced its remote dial-up access to an Internet service provider (ISP). In this scenario, the corporation has implemented a wholesale access agreement with the ISP and has a configuration that enables its corporate employees to access the corporate network by connecting to the ISP's worldwide Points of Presence (POPs).

This section covers the following:

• Corporate characteristics and requirements for authentication using outsourced dial-up access.

• Network components installed to support outsourced dial-up access in this corporate environment.

• The remote user authentication process to be implemented using this scenario.

• The configuration of the network components required to support this authentication process.

• Implementation and administration considerations, including considerations for initiating ISP support for dial-up access.

Characteristics and Requirements

The corporation in this scenario has a large corporate location with remote users, each, each of whom requires secure access to the corporate network. The corporation has determined that it is more cost-effective to provide remote access by outsourcing the remote corporate access. The corporation requires a reliable method to authenticate remote users in an environment that has these characteristics:

• The corporate network uses Active Directory to control user access.

• Access capabilities are not identical for all employees, and access is given to specific employees based on the group to which they belong (for example, corporate employees are granted access, but contract employees are not).

• The corporation has a large number of remote users who require a secure method for accessing the corporate network.

• Members of the marketing and sales team travel internationally and require global access using local dial-up connections to minimize long distance charges.

• The encryption and authentication requirements for the Internet connection are less stringent than those for the VPN connection. For example, in this scenario, the Internet connection uses CHAP and no encryption, but the VPN connection uses smart card and Extensible Authentication Protocol (EAP) with 128-bit encryption.

• Users must be able to access the network when dialing in from home and during travel.

• The ISP providing outsourced support for remote access has a large number of POPs worldwide, all of which must provide corporate users with secure access to the corporate network.

Note: This scenario includes only IAS setup and does not cover the complete configuration of all remote access and VPN components.

Network Components

In this scenario, a primary IAS server and a backup IAS server are set up on the corporate network to authenticate remote users. The following components are installed to support this scenario:

• In the corporate network:

  • A primary IAS server and a backup IAS server that are running Windows 2000 Server and are connected to the corporate local area network (LAN) and the Internet. The IAS server serves as the RADIUS server, performing authentication, authorization, accounting, and auditing of remote access users.

  • Active Directory domain controllers that are running Windows 2000 Server and connected to the LAN. Active Directory contains the user accounts and groups used to set up remote access policies for remote users.

  • PPTP servers running Windows 2000 Server with Routing and Remote Access service enabled, configured to accept PPTP connections, and connected to the LAN and through a leased line to the Internet. The PPTP server has a network address on both the Internet and the private LAN and is used to provide users with VPN connections to the corporate network.

    Note: PPTP is a protocol for creating a secure connection. PPTP can encapsulate Point-to-Point Protocol (PPP) packets within Internet Protocol (IP) packets and forward them over any IP network, including the Internet.

• At the ISP:

  • Network access servers (NASs) running Windows 2000 Server. The NAS operates as a RADIUS client. In this scenario, requests reach IAS through the RADIUS proxy server at the ISP and are routed to the corporate server. You can use any RADIUS-compatible NAS (such as Windows 2000 Routing and Remote Access service, Cisco, U.S. Robotics, Ascend, or others.

  • A RADIUS proxy server that acts as a RADIUS client to other servers.

• For each remote dial-up user:

  • A computer that has a modem, or other supported communications device, and connection software and is configured to support standard dial-up access capabilities using PPP and VPN connections. In this scenario, Connection Manager service profiles are used to enable single-logon access through the ISP, using dial-up and VPN connections.

    Note: To use Connection Manager, the service profile must be delivered, installed, and set up on all computers requiring remote access. Connection Manager service profiles are created using the Connection Manager Administration Kit (CMAK) wizard. For more information on how to create, deliver, and set up Connection Manager service profiles, see Connection Manager Administration Kit in Windows 2000 Server Help.

  • Smart card access capabilities.

Authentication Process for This Scenario

The network components determine the authentication process. Using the setup and configuration as specified in this scenario, accounting and authentication occur as follows:

• When the NAS is started, an Accounting-On packet is sent. If the RADIUS proxy server is appropriately configured to forward Accounting-On packets, the packet is forwarded to the IAS server at the corporation, where it is logged.

• When a remote user dials in to the ISP, the process illustrated in Figure 25 takes place, and all requests and responses are logged:

  

  Figure 25: The Authentication Process for an Outsourced Corporate Access Scenario

  1. The user selects the present location and a local or other appropriate phone number (POP) for the ISP from the phone book in the Connection Manager service profile. Using CHAP authentication, the user connects to the ISP's NAS. Appended to the user name is a realm name, either specified by the user or automatically appended by Connection Manager. This name is used by the NAS to route the authentication and accounting requests to the IAS server in the corporate network.

  2. The NAS sends the RADIUS authentication request to the RADIUS proxy server.

  3. The RADIUS proxy server uses the realm name to route the request to the corporation's IAS server. This request may be routed through multiple RADIUS proxies (belonging to another ISP or a roaming consortium of ISPs) before reaching the corporate IAS server. IAS applies all realm-stripping rules for the user name.

     Note: When the user principal name is received from the user, IAS queries the global catalog and maps the user principal name suffix to a fully qualified domain name (FQDN).

  4. IAS forwards the authentication request to the domain controller, where the user credentials are checked.

  5. IAS evaluates the remote access policies and the user attributes to determine if dial-up access is allowed.

     Note: IAS requires permission to read the attributes from the user account. This permission is provided when the server is a member of the built-in RAS and IAS Servers security group.

  6. If a remote access policy is matched and the profile does not reject the user, then IAS sends an Access-Accept packet.

  7. The RADIUS proxy server forwards the Access-Accept packet.

  8. The user is granted access, based on the connection settings specified in the Access-Accept packet.

  9. The NAS assigns an IP address and other parameters to the client to start routing the packets sent to and received from the client.

  10. Connection Manager then initiates a tunnel to the PPTP server in the corporate network.

  11. The PPTP server sends an authentication request for this user to the IAS server, verifying VPN access capabilities.

  12. The IAS server receives the request and forwards the packet to the domain controller. Again, the user credentials are checked, the remote access policies and user attributes are evaluated, and the user is granted VPN access based on the connection settings specified in the Access-Accept packet.

      The PPTP server sends an Accounting-Start message to the RADIUS server.

      • During the session, interim accounting packets are sent by both the NAS and PPTP server.

      • When the user disconnects, the PPTP server sends an Accounting-Stop packet to the IAS server, indicating the end of the user session.

Setup

To set up IAS to support this scenario, complete the following steps:

1. Verify that the firewall is appropriately set up to support IAS.

2. Verify that the domain controllers have been configured to support the remote users.

3. Install and configure IAS.

4. Copy the IAS configuration from the primary IAS server to the backup IAS server.

5. Register the primary and backup IAS servers with Active Directory.

6. Verify that the PPTP servers are appropriately set up to support RADIUS accounting and authentication and properly configured for VPN connections.

7. Verify the configuration of RADIUS accounting and authentication on the ISP's RADIUS proxy server.

8. Verify connection capabilities for remote users.

The following information provides details about each of these setup steps and about the requirements for their completion.

Step 1: Verify that the firewall is appropriately set up to support IAS.

For information on how to set up the firewall, see the section on Security and IAS.

Step 2: Verify that the domain controllers have been configured to support the remote users.

Verify that groups have been created for the users (in this scenario, with permanent and contract employees in separate groups), the remote users are in the appropriate universal and nested groups, the computer running IAS has permission to read the user accounts in the domain, and the user names and passwords are valid on the LAN. Because you are using groups, verify that remote access permission is set to Control access through Remote Access Policy in the user account. Also verify that Active Directory is in native mode and, for permanent employees using CHAP authentication, that reversibly encrypted password storage has been enabled.

Notes: If you specify support for CHAP, you need to configure support for reversibly encrypted passwords.

Step 3: Install and configure IAS.

To set up the primary IAS server, do the following:

1. Verify that the server running IAS is a member of the forest against which it will authenticate remote users (because a trust relationship is required for this, and all domains in Active Directory forests automatically have trust relationships with each other). If IAS and the user account are not in the same forest, then the domain for the user account must have a trust relationship with the domain of which IAS is a member. For more information on trust relationships, see Understanding Domain Trusts in Windows 2000 Server Help.

2. Log on to the server with administrative credentials.

3. If you did not select IAS as an optional component when you installed Windows 2000 Server, install it using Add/Remove Programs in Control Panel.

4. Click Start, point to Programs, point to Administrative Tools, and then click Internet Authentication Service.

   In the Internet Authentication Service console, right-click Internet Authentication Service, and then click Properties to configure these properties for the primary IAS server:

   • On the Service tab, select both options for event logs.

   • On the RADIUS tab, specify the RADIUS authentication and RADIUS accounting UDP ports to be used, and then click OK.

     Note: These ports must be the same as those used by the servers. The most current RADIUS standards are UDP ports 1812 (for RADIUS authentication) and 1813 (for RADIUS accounting). The default values are set to the commonly used values: UDP ports 1812 and 1645 for authentication and 1813 and 1646 for accounting. If you are unsure of your port settings, see your vendor-specific documentation for the NAS.

   • If the realm names used at the ISPs to access the corporate network are different from those required to access corporate domains, specify rules for manipulating the realm names on the Realms tab.

5. Set up IAS support for the RADIUS clients. In the Internet Authentication Service console tree, right-click Clients, click New Client, and then follow the directions to add and include information about each RADIUS client (including the corporate network's PPTP and ISP's RADIUS proxy servers). Specify the Friendly name, Protocol (specified as Radius), Client address, Client-Vendor information (specified as RADIUS Standard), and the Shared secret.

   Notes: Ensure that the authentication and accounting shared secrets in IAS match those specified for the NASs.

   Before enabling the option for checking digital signatures, ensure that the NAS supports sending a digital signature for authentication types other than Extensible Authentication Protocol (EAP). For EAP, the digital signature option is always checked.

   Configure remote access policies to support permanent employee access through outsourced dial-up connection. To configure these policies, do the following:

   • Configure a remote access policy for smart card access that uses 128-bit encryption. In Internet Authentication Service console tree, right-click Remote Access Policies, and then click New Remote Access Policy. Use the New Remote Access Policy wizard to do the following:

     • Specify a Policy friendly name of Smart Card Access (or another, if preferred), and then click Next.

     • To add a condition, click Add, select Windows-Groups, click Add, click Add again, select the name of the group (such as Permanent corporate employees), click Add, and then click OK twice.

     • To add a second condition, click Add, select NAS-Port-Type, click Add, select Virtual (VPN), click Add, click OK, and then click Next.

     • Select Grant remote access permission, and then click Next.

     • Click Edit profile and then, on the Authentication tab, select Extensible Authentication Protocol, select Smart card or other certificate (TLS), and then click Configure.

     • In the Smart card or Other Certificate (TLS) Properties dialog box, select the machine certificate you want to use, and then click OK.

     • Click Finish to save the settings for this policy.

     Set up a remote access policy for permanent employees. In Internet Authentication Service console tree, right-click Remote Access Policies, click New Remote Access Policy. Use the New Remote Access Policy wizard to do the following:

     • Specify the Policy friendly name, Permanent employees (or another, if preferred), and then click Next.

     • To add a condition, click Add, select Windows-Groups, click Add, select the name of the group (such as Permanent corporate employees), click Add, click OK twice, and then click Next.

     • Click Grant remote access permission, and then click Next.

     • Click Edit Profile and then, on the Authentication tab, select CHAP as the authentication method, and then click OK.

     • Click Finish to save the settings for this policy.

     Note: Because an access policy granting access is only defined for permanent employees, contract employees (who are in a different group) are denied access.

   • To ensure that the policies you configured do not conflict with the default policy (Allow access if dial-up permission is enabled), delete the default policy.

6. Configure logging for user authentication and accounting.

Although you can specify the basic logging configuration in IAS, you might want to create additional programs to use the logging data for accounting and troubleshooting. For example, you can set up a program to track departmental usage of remote access capabilities. For this scenario, consider the following when configuring logging:

• You should use the database-import log format for your log files to facilitate incorporation and use of the data in your own programs. If you select this format, you can use a database program to analyze your log files for usage, access, and report generation.

• You should specify that all three types of authentication and accounting requests received by the server be logged.

Step 4: Copy the IAS configuration from the primary IAS server to the backup IAS server.

Copy the IAS configuration, including IAS properties, client configurations, remote access policies, and logging configuration to the backup IAS server.

Step 5: Register the primary and backup IAS servers with Active Directory.

To be able to authenticate users, the primary and backup IAS servers must be registered as members of the RAS and IAS Servers security group on the domain controllers in Active Directory in the built-in groups. Add the IAS servers by doing the following:

1. Log on to the server using domain-administrator credentials.

2. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

3. In the console tree, click Users.

4. In the details pane, right-click RAS and IAS Servers.

5. In the RAS and IAS Servers Properties dialog box, on the Members tab, add each of the IAS servers.

Note: You can also use the netsh ras register server [domain] [server] command for server registration.

Step 6: Verify that the PPTP servers are appropriately set up to support RADIUS accounting and authentication and are properly configured for VPN connections

To ensure that RADIUS accounting and authentication configuration has been appropriately set up on each PPTP server using the appropriate remote access software, and to verify that the configuration matches that of IAS (ensuring that IAS is configured as the authentication and accounting provider), do the following:

1. Log on to the server using domain administrator credentials.

2. Click Start, point to Programs, point to Administrative Tools, and then click Routing and Remote Access.

   For each PPTP server on which you have installed Routing and Remote Access, right-click the server name, click Properties, and then check the following:

   • On the General tab, verify that Remote access server is selected.

     On the Security tab, verify the following:

     • RADIUS Authentication is selected and is configured with the names of the primary and backup IAS servers, each with the appropriate shared secret and port. Be certain that EAP is selected under Authentication Methods.

     • RADIUS Accounting is selected and configured with the names of the primary and backup IAS servers, each with the appropriate shared secret and port, and with the Send RADIUS Accounting On and Accounting Off messages option selected.

     On the IP tab, verify that the following are selected:

     • Enable IP routing.

     • Allow IP-based remote access and demand-dial connections.

     • Dynamic Host Configuration Protocol (DHCP).

   • On the PPP tab, verify that all options are selected.

Verify that the PPTP servers are properly configured for VPN connections.

Step 7. Verify the configuration of RADIUS accounting and authentication on the ISP's RADIUS proxy server.

1. Provide realm information to the ISP and verify that realm handling is appropriately configured on the RADIUS proxy server.

2. Provide the shared secret to the ISP for configuration of the RADIUS proxy server and verify that the server is appropriately configured to handle the shared secret.

3. Ask the ISP which attributes are sent in requests and what should be returned in the response.

4. Ask whether the ISP's RADIUS proxy server supports digital signatures. If they do, ensure that the profile is set up to require it.

5. Check with the ISP to find out what hardware they use.

Step 8: Verify connection capabilities for remote users.

The final step in setting up IAS is to verify that the remote VPN users can use Connection Manager to access the corporate network.

1. Verify that Connection Manager service profiles have been provided to users.

2. Verify smart card access.

3. After the service profiles are installed, verify that the phone numbers used to connect to the NASs are set up correctly and that the realm name is handled appropriately.

Implementation and Administration Considerations

All IAS administration can be managed remotely.

• If remote access policies need to be updated, update the policies on the primary IAS server and then copy the IAS configuration to the other IAS servers.

• Network access servers can be updated remotely.

• Remote usage can be tracked on the corporate network.

This scenario provides a basic implementation plan for outsourced dial-up access for a corporate environment. When implementing IAS, you can adjust this scenario to support the requirements of your environment. Depending on the size of your corporation, a single IAS server is probably sufficient. In many cases, the IAS server can be installed on the same computer as the domain controller.

Internet Access

This section describes how IAS can be set up to support customer-authenticated dial-up connections to an Internet service provider (ISP). This scenario shows a typical setup and configuration for an ISP with customers who require access to the Internet.

This section covers the following:

• ISP characteristics and requirements for authentication.

• Network components installed to support this ISP environment.

• The customer authentication process to be implemented using this scenario.

• The setup of the network components required to support this authentication process.

• Implementation and administration considerations.

Characteristics and Requirements

The ISP in this scenario has a single data center that supports a large number of users and NASs that are distributed with multiple Points of Presence (POPs). The ISP requires a reliable method to authenticate users in an environment that has these characteristics:

• The ISP uses Active Directory to control user access.

• The ISP offers two service plans. There is a basic unlimited access plan for users with dial-up modems and a premium plan that provides support for ISDN connections. Access is given to users based on the plan for which they sign up, which determines group membership.

• Users must be able to access the network using local access numbers for each of the ISP's POPs.

Note: This scenario covers only how to set up IAS and some basic steps for configuring Windows 2000 Routing and Remote Access service.

Network Components

In this scenario, IAS servers are set up on the corporate network to authenticate users connecting through any POP that has been configured on any of the ISP's network access servers (NASs). The following components are installed to support this scenario:

• At the ISP:

  • A primary IAS server and a backup IAS server running Windows 2000 Server. The IAS servers are used as the RADIUS servers, performing authentication, authorization, accounting, and auditing of all users.

  • Active Directory domain controllers running Windows 2000 Server. Active Directory contains the user accounts and groups used to set up remote access policies for all users.

  • Network access servers (NASs) running the Routing and Remote Access service component of Windows 2000 Server and connected to the LAN. The NAS operates as a RADIUS client and is used to pass user information to the appropriate RADIUS servers (in this scenario, IAS), acting on the response.

    Note: This scenario uses Routing and Remote Access servers as the NASs. If you use other RADIUS-compatible NASs (such as CISCO, Ascend, or US Robotics), you must change the configuration to reflect the use of the other NASs.

• For each individual user of the basic plan (no ISDN support):

  • A computer configured to support standard dial-up capabilities using Point-to-Point Protocol (PPP). In this scenario, a Connection Manager service profile is used to enable access to the Internet through the ISP POPs.

• For each individual user of the premium plan (with ISDN support):

  • A computer configured to support standard dial-up capabilities as well as ISDN direct access capabilities using PPP. The same Connection Manager service profile used for the basic plan is used to enable access through ISDN because the service profile contains both dial-up and ISDN POPs. Connection Manager makes the appropriate POPs available based on the type of connection device the user selects.

Note: To use Connection Manager, the service profile must be delivered, installed, and set up on all computers requiring remote access. Connection Manager service profiles are created with the Connection Manager Administration Kit (CMAK) wizard. For more information on how to create, deliver, and set up Connection Manager service profiles, see Connection Manager Administration Kit in Windows 2000 Server Help.

Authentication Process for This Scenario

The network components determine the authentication process. Using the setup and configuration as specified in this scenario, accounting and authentication are accomplished as follows:

• When the NAS is started, an Accounting-On packet is sent.

• When a remote user connects to one of the ISP POPs, the process illustrated in Figure 26 occurs and all requests and responses are logged:

  

  Figure 26: The Authentication Process for an Outsourced Corporate Access Scenario

  1. The user selects the present location and an appropriate phone number (POP) for the ISP from the phone book in the Connection Manager service profile.

  2. The NAS sends the RADIUS authentication request to the IAS server.

  3. IAS forwards the authentication request to the domain controller at that location and the user credentials are checked.

  4. IAS evaluates the remote access policies and user attributes to determine if dial-up access is allowed.

     Note: IAS requires permission to read the attributes from the user account. This permission is granted if the server is a member of the built-in RAS and IAS Servers security group.

  5. If a remote access policy is matched and the profile does not reject the user, then IAS sends an Access-Accept packet.

     The user is granted access based on the connection settings specified in the Access-Accept packet. The NAS then assigns an IP address and other parameters to the client and starts routing the packets sent to and received from the client.

     • The NAS sends an Accounting-Start packet to the IAS server, indicating that the user session has started.

     • During the session, interim accounting packets are sent.

     • When the user disconnects, the NAS sends an Accounting-Stop packet to the IAS server, indicating the end of the user session.

Setup

To set up IAS to support this scenario, complete these steps:

1. Verify that the domain controllers have been configured to support remote users.

2. Install and configure IAS.

3. Copy the IAS configuration from the primary IAS server to the backup IAS server.

4. Register the primary and backup IAS servers with Active Directory.

5. Verify the configuration of RADIUS accounting and authentication on the NASs.

6. Verify connection capabilities for remote users.

The following information covers each step and the requirements to complete them.

Step 1: Verify that the domain controllers have been configured to support remote users.

Verify that the users are configured with user principal names and are in the appropriate universal and nested groups. Make sure that the computer running IAS has permission to read the user accounts in the domain. In this scenario, you can set up two universal groups (one for users of the basic plan and one for users of the premium ISDN plan). Because of the large number of potential users, you can create global groups, nested in the universal groups, and put users in the sub-groups (not directly in the universal groups). Verify that the user names and passwords are valid on the LAN.

Verify that CHAP and MS-CHAP are supported on the domain controllers.

Notes: The user principal names created for the users should contain the @ (at sign) followed by the ISP's name (for example, Username@ISPName).

To support CHAP, you need to configure support for reversibly encrypted passwords and enable plaintext passwords.

Step 2: Install and configure IAS.

To set up the primary IAS server, do the following:

1. Verify that the server running IAS is a member of the forest against which it will authenticate remote users (since a trust relationship is required for this, and all domains in Active Directory forests automatically have trust relationships with each other). If IAS and the user account are not in the same forest, then the domain for the user account must have a trust relationship with the domain of which IAS is a member. For more information on trust relationships, see Understanding Domain Trusts in Windows 2000 Server Help.

2. Log on with Local Administrative credentials.

3. If you did not select IAS as an optional component when you installed Windows 2000 Server, install it using Add/Remove Programs in Control Panel.

4. Click Start, point to Programs, point to Administrative Tools, and then click Internet Authentication Service.

   In the Internet Authentication Service console, right-click Internet Authentication Service and then click Properties to configure the properties for the primary IAS server:

   • On the Service tab, select both options for event logs (you can later clear any options that are not useful in your environment).

   • On the RADIUS tab, specify the RADIUS authentication and RADIUS accounting UDP ports to be used, and then click OK.

     Note: These ports must be the same as those used by the NASs. The most current RADIUS standards are UDP ports 1812 (for RADIUS authentication) and 1813 (for RADIUS accounting). The default values are set to the commonly used values: UDP ports 1812 and 1645 for authentication and 1813 and 1646 for accounting. If you are unsure of your port settings, see your vendor-specific documentation for the NAS.

   • Realm names are not used in this example and information is not required on the Realms tab.

5. Set up IAS support for the RADIUS clients. In the Internet Authentication Service console tree, right-click Clients, and click New Client. Then follow the directions to add and specify information about each RADIUS client (NAS), specifying the Friendly name, Protocol (specified as RADIUS), Client address, Client-Vendor information (specified as RADIUS Standard), and the Shared secret.

   Notes: Ensure that the authentication and accounting shared secrets in IAS match those specified for the NASs.

   Before enabling the option to check digital signatures, ensure that the NAS supports sending a digital signature for authentication types other than Extensible Authentication Protocol (EAP).

   For EAP, digital signatures are always used and you do not have to select the digital signature option.

   Set up the remote access policies. Because most basic plans for ISPs do not include ISDN access, you should set up two groups. One should support multi-link connections (for premium plans) and one should not (for a basic plan).

   • Set up a remote access policy for the basic plan (non-ISDN users) by doing the following:

     • In the Internet Authentication Service console tree, right-click Remote Access Policies, and then click New Remote Access Policy.

     • Using the Add Remote Access Policy wizard, specify a Policy friendly name for the policy (for this scenario, you can enter Basic Plan), and then click Next.

     • In the next dialog box, click Add, select Windows-Groups, click Add, click Add again, select the groups to which this policy applies (such as Basic Plan users), click Add, click OK twice, and then click Next.

     • Click Grant remote access permission, and then click Next.

     • Click Edit Profile.

     • On the Authentication tab, select CHAP, MS-CHAP, and MS-CHAP v2 as the authentication methods.

     • On the Dial-in Constraints tab, select Async and Sync, and then click OK.

     • Click Finish.

   • Set up a remote access policy for the premium plan that is the same as for the basic plan, except that it supports ISDN access. To set up this policy, repeat the steps that you used to set up the policy for the basic plan, but specify the name of the policy as Premium Plan, and select the Windows-Groups that contain the users who will have ISDN access. On the Dial-in Constraints tab, check all of the ISDN options (in addition to the options selected for the basic plan).

   • To ensure that the policies you configured do not conflict with the default policy (Allow access if dial-up permission is enabled), delete the default policy.

6. Configure logging for user authentication and accounting.

   Although you can specify the basic logging configuration in IAS, you might want to create additional programs to use the logging data for accounting and troubleshooting. For example, you can set up a program to track departmental usage of remote access capabilities. For this scenario, consider the following when configuring logging:

   • You should use the database-import log format for your log files to facilitate incorporation and use of the data in your own programs. If you select this format, you can use a database program to analyze log file usage, access, and report generation.

   • You should specify that all types of requests received by the server (including authentication, accounting, and periodic updates) be logged.

Step 3: Copy the IAS configuration from the primary IAS server to the backup IAS server.

Copy the client configurations, remote access policies, and logging configuration to the backup IAS server.

Step 4: Register the primary and backup IAS servers with Active Directory

To authenticate users, the primary and backup IAS servers must be registered on the domain controllers in Active Directory in the built-in groups as members of the RAS and IAS Servers security group. Add the IAS servers by doing the following:

1. Log on to the server using domain administrator credentials.

2. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

3. In the console tree, click Users.

4. In the details pane, right-click RAS and IAS Servers.

5. In the RAS and IAS Servers Properties dialog box, on the Members tab, add each of the IAS servers.

Note: You can also use the netsh ras register server [domain] [server] command for server registration.

Step 5: Verify the configuration of RADIUS accounting and authentication on the NASs.

To ensure that RADIUS accounting and authentication configuration has been correctly configured on each NAS using Windows 2000 Server Routing and Remote Access service, and to verify that the configuration matches that of IAS (as specified in Steps 2 and 3), do the following:

1. Log on to the server using domain administrator credentials.

2. Click Start, point to Programs, point to Administrative Tools, and then click Routing and Remote Access.

   For each NAS on which you have installed Routing and Remote Access service, right-click the server name, click Properties, and then check the following information:

   • On the General tab, verify that Remote access server is selected.

     On the Security tab, verify the following:

     • RADIUS Authentication is selected and is configured with the names of the primary and backup IAS servers. Verify that each IAS server is configured with the appropriate shared secret and port, and that CHAP, MS-CHAP v2 and MS-CHAP are selected under Authentication Methods.

     • RADIUS Accounting is selected and is configured with the names of the primary and backup IAS servers, each with the appropriate shared secret and port, and with the Send RADIUS Accounting On and Accounting Off messages option selected.

     On the IP tab, verify that the following are selected:

     • Enable IP routing.

     • Allow IP-based remote access and demand-dial connections.

     • Dynamic Host Configuration Protocol (DHCP).

Step 6: Verify connection capabilities for remote users.

The final step in setting up IAS is to verify that the remote dial-up users can use Network and Dial-up Connections to access the ISP.

Implementation and Administration Considerations

Depending on the size of your corporation, a single IAS server is probably sufficient. In many cases, the IAS server can be installed on the same computer as the domain controller.

Note: This scenario provides a basic implementation plan for a corporate environment. Tailor the number of servers and other implementation decisions to support the requirements of your environment.

If remote access policies need to be updated, update the policies on the primary IAS server, and then copy the IAS configuration to the other IAS servers.

Security and IAS

This section discusses security issues to consider when deploying IAS.

Secure Authentication Methods

The mixture of access server clients in your network determines the authentication methods that you must use. Most access server clients use some form of password-based authentication. Password-based authentications are inherently weak and are subject to dictionary attacks. Dictionary attacks can be made more difficult by imposing strong password policies on your network. A strong password is a long password that contains a mixture of upper and lower-case letters, numbers, and punctuation. The most secure method of authentication is EAP-TLS, when used in conjunction with smart cards. However, EAP-TLS and smart cards require a public key infrastructure (PKI).

To use the most secure authentication methods, perform the following as needed:

1. Disable PAP and SPAP. Both PAP and SPAP are disabled by default on the profile of a remote access policy.

2. Disable CHAP. CHAP is disabled by default on the profile of a remote access policy.

3. Disable LAN Manager authentication for MS-CHAP v1. LAN Manager authentication for MS-CHAP v1 is enabled by default for older Microsoft access server clients. Set the registry value Allow LM Authentication (HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services\RemoteAccess\Policy) to 0 on the IAS server.

4. Disable MS-CHAP v1. MS-CHAP v1 is enabled by default on the profile of a remote access policy. Before disabling MS-CHAP v1, ensure that all of your access server clients are capable of using MS-CHAP v2. Previous versions of Windows, such as Windows 95 or Windows NT 4.0, require the latest service packs and dial-up networking updates.

5. Enable MS-CHAP v2. MS-CHAP v2 is enabled by default on the profile of a remote access policy.

6. Enable EAP-TLS. EAP-TLS is not enabled by default on the profile of a remote access policy. You must enable it and configure which computer certificate is used during the EAP-TLS negotiation.

Shared Secrets

A shared secret is a password used between a RADIUS server and a RADIUS client to mutually verify identity. Both the RADIUS server and the RADIUS client must be configured with the same shared secret for successful communication to occur. The shared secret can be up to 128 bytes long, is case-sensitive, and can contain alphanumeric and special characters. To protect your RADIUS communications from dictionary and denial-of-service attacks, make the shared secrets a long (more than 16 characters) sequence of random letters, numbers, and punctuation marks.

Signature Attributes

When you configure IAS for a RADIUS client, you configure the IP address of the RADIUS client. If an incoming RADIUS message does not originate from at least one of the IP addresses of the configured RADIUS clients, then IAS automatically discards the message, providing protection for an IAS server. However, source IP addresses can be spoofed (substituted).

To provide protection from spoofed RADIUS messages and RADIUS message tampering, each RADIUS message can be further protected by including the RADIUS signature attribute, referred to as the Message-Authenticator attribute and described in the Internet draft "RADIUS Extensions."

The contents of the RADIUS Message-Authenticator attribute are an MD-5 hash of the entire RADIUS message using the shared secret as a key. If the RADIUS Message-Authenticator attribute is present, it is verified. If it fails verification, the RADIUS message is discarded. If the client settings require the Message-Authenticator attribute and it is not present, the RADIUS message is discarded.

RADIUS Proxies

A RADIUS proxy can be used to provide cross-forest authentication. The use of the PAP authentication protocol in conjunction with a RADIUS proxy is highly discouraged. PAP provides for the plaintext passing a user password between the PPP client and the NAS (the RADIUS client). Between the NAS and the RADIUS proxy, the PAP password is encrypted using the shared secret of the NAS and the RADIUS proxy. However, in order to forward the Access-Request to the appropriate RADIUS server that is providing authentication, the user's password must be decrypted and then re-encrypted using the shared secret of the RADIUS proxy and the RADIUS server that is providing authentication. While the user's password is decrypted, it exists in plaintext form. It is possible for a malicious process on a RADIUS proxy to record user passwords while they are in decrypted form, compromising the security of user credentials.

Firewalls

A firewall is a router or a computer deployed between the Internet and a perimeter network (also called a demilitarized zone or DMZ), which is a network segment that contains computers that can be directly accessed from the Internet. The firewall is designed to provide protection for the computers on the perimeter network by filtering the traffic between them and the Internet.

If you use a firewall and one of the private computers on the perimeter network is an IAS server, you must configure the firewall with packet filters to allow RADIUS traffic between the IAS server and the Internet.

For example, if the IAS server on the perimeter network is using the public IP address of 131.107.255.17 and UDP ports 1812 (for RADIUS authentication) and 1813 (for RADIUS accounting), you should configure the firewall with packet filters that allow the following IAS traffic:

• Traffic from the Internet to the perimeter network

  To the destination of 131.107.255.17 and with a UDP destination port of 1812

  To the destination of 131.107.255.17 and with a UDP destination port of 1813

• Traffic from the perimeter network to the Internet

  From the source of 131.107.255.17 and with a UDP source port of 1812

  From the source of 131.107.255.17 and with a UDP source port of 1813

Note that these filters do not specify the inbound source or outbound destinations corresponding to the RADIUS clients on the Internet. You can create more specific filters that allow RADIUS traffic from your RADIUS clients only; however, this requires two filters (one for inbound traffic and one for outbound) for each RADIUS client on the Internet.

Remote Access Account Lockout

You can use the account-lockout feature to specify the number of times a PPP authentication fails against a valid user account before the user is denied access. Account lockout is especially important for remote access virtual private network (VPN) connections over the Internet. Malicious users on the Internet can attempt to access an organization's intranet by sending credentials (valid user name and guessed password) during the VPN connection authentication process. During a dictionary attack, the malicious user sends hundreds or thousands of credentials by using a list of passwords based on common words or phrases.

When account lockout is enabled, a dictionary attack is thwarted after a specified number of failed attempts. As the network administrator, you must decide between two account lockout variables:

• The number of failed attempts before future attempts are denied

  After each failed attempt, a failed-attempts counter for the user account is incremented. If the user account's failed attempts counter reaches the configured maximum, then future attempts to connect are denied.

  A successful authentication resets the failed-attempts counter when its value is less than the configured maximum. In other words, the failed-attempts counter resets to zero after a successful authentication.

• How often the failed-attempts counter is reset

  The failed-attempts counter is periodically reset to zero. If an account is locked out after the maximum number of failed attempts, the failed attempts counter is automatically reset to zero after the reset time.

You enable the account-lockout feature by changing settings in the Windows 2000 registry on the computer that provides the authentication. If the remote access server is configured for Windows authentication, modify the registry on the remote access server computer. If the remote access server is configured for RADIUS authentication and Windows 2000 Internet Authentication Service (IAS) is being used, modify the registry on the IAS server computer.

To enable account lockout, you must set the MaxDenials entry in the registry to one or greater. MaxDenials is the maximum number of failed attempts before the account is locked out. You can set the MaxDenials entry in the following registry subkey:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RemoteAccess \Parameters\AccountLockout

By default, MaxDenials is set to zero, which means that account lockout is disabled.

To modify the amount of time before the failed attempts counter is reset, you must set the ResetTime (mins) entry in the registry to the required number of minutes. You can set the ResetTime (mins) entry in the following registry subkey:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RemoteAccess \Parameters\AccountLockout

By default, ResetTime (mins) is set to a hexadecimal value of 0xb40, or 2,880 minutes (48 hours).

Manually Resetting an Account That Is Locked Out

In order to manually reset a user account that has been locked out before the failed attempts counter is automatically reset, delete the following registry subkey that corresponds to the user's account name:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RemoteAccess \Parameters \AccountLockoutdomain name:user name

When the lockout count for a user account is reset to zero, due to either a successful authentication or an automatic reset, the registry subkey for the user account is deleted.

Notes: The remote access account lockout is not related to the Account locked out setting on the Account tab on the properties of a user account.

The account-lockout feature does not distinguish between malicious users who attempt to access your intranet and authentic users who attempt remote access but have forgotten their current passwords. Users who have forgotten their current password typically try the passwords that they remember and, depending on the number of attempts and the MaxDenials setting, might have their accounts locked out.

If you enable the account-lockout feature, a malicious user can deliberately force an account to be locked out by attempting multiple authentications with the user account until the account is locked out, thereby preventing the authentic user from being able to log on.

Performance and IAS

This section contains recommendations on fine-tuning IAS and monitoring its performance. It also includes sample performance information that can be helpful in determining your IAS server performance and health conditions.

Consider these points when fine-tuning the performance of an IAS server:

• If IAS authenticates users against a Windows 2000-based domain controller that is running in native mode, the domain controller should also contain the global catalog.

• High-latency connections between either the NAS and IAS server or the IAS server and the domain controller can negatively impact authentication times, causing retries and time-outs.

In very large ISP environments (millions of remote access users) with extremely heavy load conditions, where a large number of both authentication requests and accounting packets are being handled within seconds, the following items should be considered:

• Typically, the number of authentications per second that you get depends on the hardware used for the domain controller. Using a faster domain controller should yield a better throughput.

• Using separate IAS servers for authentication and accounting.

• Running the IAS server on a domain controller with a global catalog. This would minimize network latency and may improve throughput.

• Using the MaxConcurrentApi registry entry (HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Netlogon Parameters) to tune the number of concurrent authentication calls in progress at one time between the IAS server and the domain controller, achieving better throughput.

• Deploying multiple IAS servers and using an IP load balancing scheme to point NASs to a single IP address that represents a pool of IAS servers. However, EAP is a stateful protocol and might not work with all IP load-balancing schemes.

Monitoring IAS Server Performance and Health

The RADIUS authentication protocol distinguishes between the client and server functions. In RADIUS authentication, clients send Access-Request packets, and servers reply with Access-Accept, Access-Reject, and Access-Challenge packets. Typically, NAS devices perform the client function and implement the RADIUS authentication client MIB (management information database), and RADIUS authentication servers perform the server function and implement the RADIUS authentication server MIB.

The two most commonly used counters for IAS performance monitoring are:

• Access Requests per second.

• Accounting Requests per second.

For more information about SNMP MIBs supported by IAS, see Appendix G.

Capacity Planning

IAS can scale to large numbers of accounts and authentications per second. Table 2 shows how IAS can scale using faster hardware.

Table 2 Scaling with Faster Hardware

Type of organization	Authentications/second for typical use	Hardware configuration
Small to medium-sized organizations with less than 1000 users	1	Minimum hardware recommended for Windows 2000 Server
Large organizations with 50,000 users	10	Minimum hardware recommended for Windows 2000 Server
ISPs with 2 million users	50	200 MHz Pentium II or higher.
ISPs with 20 million users	300	4-processor Xeon or higher.

Table 3 lists performance numbers that can be used as guidelines for the throughput of a single IAS server.

Table 3 Performance Guidelines for a Single IAS Server

Hardware	Authentication methods	Maximum authentications/second
Minimum hardware recommended for Windows 2000 Server and a remote Active Directory domain controller	CHAP, MS-CHAP v1, MS-CHAP v2	50
200 MHz Pentium II and a remote Active Directory domain controller	CHAP, MS-CHAP v1, MS-CHAP v2	200
4-proccessor Xeon and a remote Active Directory domain controller	CHAP, MS-CHAP v1, MS-CHAP v2	700

Instead of using a single faster computer, you can also increase IAS authentications per second by using multiple computers. For example, you can use an IP load-balancing scheme to balance the load between multiple IAS servers. Before you attempt to scale IAS up with a single faster computer or out by using multiple computers, determine whether the IAS computer is the bottleneck. At the peak number of authentications per second, use Windows 2000 Performance Logs and Alerts to track CPU utilization. If IAS server CPU utilization at the maximum number of authentications per second is high, you can improve performance by scaling up or out. If use of the IAS server CPU at the maximum number of authentications per second is not high, then the following methods might improve IAS performance:

1. Run IAS on the same computer as the domain controller.

2. Run IAS on the same computer that contains the global catalog.

3. If it is not possible to run IAS on the same computer as the domain controller or the computer that contains the global catalog, verify that you have an efficient domain and site topology.

4. Use the MaxConcurrentApi registry entry (HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Netlogon Parameters) to increase the number of multiplexed connections to the domain controller.

Here are some factors that commonly affect IAS performance:

1. Network latency between the IAS server computer and the domain controller computer.

2. Network latency between the IAS server computer and the Global Catalog computer.

3. Performance and the current load of the domain controller computer.

4. The resolution of user principal names, resulting in an additional Remote Procedure Call (RPC) query to the Global Catalog computer.

5. EAP-based authentication methods, involving multiple challenge-response exchanges.

6. The number of user accounts in the domain.

Troubleshooting IAS

A common problem with IAS is that a connection attempt is rejected when it should be accepted. Unfortunately, there are a large number of causes for this problem. However, there are a variety of troubleshooting tools that you can use to determine the cause. Also included in this section is a troubleshooting checklist to help you systematically determine the cause of most authentication failures.

Troubleshooting Tools

Windows 2000 includes the following troubleshooting tools for determining the cause of a failed connection attempt:

• Event logging

• Microsoft Network Monitor

• Remote access logging

Event Logging

Based on the Service tab settings on the properties of the IAS server in the Internet Authentication Service administrative tool, rejected, discarded, and successful authentication attempts can be logged in the Windows 2000 system event log. To troubleshoot IAS problems based on the events in the Windows 2000 system event log, see Appendix E.

Microsoft Network Monitor

Beyond checking basic IAS configuration, Microsoft Network Monitor can be used to capture the RADIUS packets for additional analysis. When you use Network Monitor for IAS troubleshooting, consider the following:

• Network Monitor must be installed on a computer that is running IAS.

• If you use Network Monitor in a switched network environment, you see only the traffic addressed to the computer that is running Network Monitor.

Network Monitor capture files of RADIUS traffic between IAS and an NAS can be saved as files and sent to Microsoft or a NAS manufacturer for analysis. For more information about installing Network Monitor and using it to capture RADIUS traffic, see Windows 2000 Server online Help.

Remote Access Logging

Based on the Service tab settings found in Local File in Remote Access Logging in the Internet Authentication Service administrative tool, authentication, and accounting requests can be written to the IAS log. From the Local File tab, you can determine the name and location of the IAS log file. Using Windows Explorer, open the IAS log file and view the entries to help determine the cause of the connection attempt failure.

Viewing the IAS log can be very useful in troubleshooting remote access policies. If you have multiple remote access policies configured, you can use the IAS log to determine the name of the remote access policy that either accepted or rejected the connection attempt.

For more information on IAS log file format, see Windows 2000 Server Help.

Troubleshooting Checklist

Refer to the following list when troubleshooting a failed connection attempt with IAS.

• Are the user credentials correct?

  The user might have entered the wrong user name, domain name, or password. Check the user's Windows 2000 user name and account password to make sure they are typed correctly and that the account is valid for the domain that IAS is authenticating the user against. IAS can only authenticate user credentials for accounts in the domain in which the IAS server computer is a member and in trusted domains.

• Are the realm rules configured correctly?

  Realm replacement might be set up incorrectly or in the wrong order, so that after the realm replacement rules are evaluated, the domain controller cannot recognize the domain name or the user name. Verify the realm replacement rules. For more information about realm names or configuring realm replacement, see Windows 2000 Server Help.

• Is the domain name correct?

  If the IAS server is a member of a domain and the User-Name attribute does not contain a domain name, the domain name of the IAS server is used. To use a domain name that is different from that of the IAS server, set the DefaultDomain registry value to the name of the domain that you want to use on the IAS server. For more information on IAS registry settings, see Appendix F.

  Some NASs automatically strip the domain name from the user name before forwarding it to a RADIUS server. Turn off the feature that strips the domain name from the user name. For more information, see your NAS documentation.

• Are remote access policies configured correctly?

  A remote access policy might be rejecting the connection. Check the list of policies to make sure that you have not excluded users who must be granted access. Check the IAS log to see which remote access policy rejected the connection and then investigate the conditions, remote access permissions, and profile settings to determine the cause of the rejection. Make the appropriate changes to your remote access policies to accept the connection attempt.

• Are the configured remote access policies in the right order?

  Remote access policies might be in the wrong order. Authorization is granted or denied by the first policy whose conditions match the connection attempt. Use the Move Up and Move Down buttons to manipulate policy order. More specific policies should be at the top of the list and more general policies should be at the bottom.

• Is caller ID configured on the user account?

  If caller ID is configured on the user account, verify that the configured number matches the number from which the PPP client is calling.

• Is the authentication method of the PPP client supported by IAS?

  The PPP client might be trying to authenticate by using an authentication method that is not supported by the IAS server. By default, IAS supports MS-CHAP v2, MS-CHAP v1, CHAP, SPAP, PAP, EAP-MD5 CHAP, and EAP-TLS. For example, the PPP client might be using an EAP type that has not been installed on the IAS server.

• Is remote access account lockout enabled?

  If remote access account lockout is enabled, previous failed access attempts might have caused the user account to be locked out. If so, manually reset the account and increase the dial-in lockout count. For more information on remote access account lockout, see the section on Security and IAS.

• What is the remote access permission of the user account?

  The user account might have the remote access permission set to Deny access. If the remote access permission is set to Control access through Remote Access Policy, verify that the remote access permission of the first matching remote access policy is set to Grant remote access permission.

• Is the IAS-server computer a member of the correct domain?

  If the IAS server is not a member of a domain, then it will authenticate only against the account in the local user database. Add the IAS server to the appropriate Active Directory or Windows NT 4.0 domain.

• Can the IAS server communicate with the NAS?

  There might be a communication problem between the IAS server and the NAS. Use the ping command to verify that IP communication can occur between the IAS server and the NAS. Verify that there are no firewalls or other types of packet filtering that are preventing the forwarding of RADIUS traffic between the IAS server and the NAS. If no RADIUS-message information appears in the IAS log, check the Windows 2000 event log to see whether the attempt times out.

• Can the IAS server communicate with the Global Catalog server?

  There might be a communication problem between the IAS server and the Global Catalog server. The Global Catalog server is used during name cracking to resolve the user identity to a user account. Use the ping command to verify that IP communication can occur between the IAS server and the Global Catalog server. Verify that there are no firewalls or other types of packet filtering that are preventing the flow of traffic between the IAS server and the Global Catalog server.

• Can the IAS server communicate with the domain controller?

  There might be a communication problem between the IAS server and the domain controller. The domain controller is used during user credential validation to verify that the supplied credentials match those of the user account. Use the ping command to verify that IP communication can occur between the IAS server and the domain controller. Verify that there are no firewalls or other types of packet filtering that are preventing the flow of traffic between the IAS server and the domain controller.

• Are you using CHAP?

  If you are using CHAP, verify that the Active Directory domain of the user account is configured to use plaintext passwords. Also, verify that the user's password has been changed after the Active Directory domain of the user account has been configured to use plaintext passwords.

• Are the IAS server and the NAS using an identical shared secret?

  Determine whether the IAS server and the NAS are using the same shared secret. Note that shared secrets are case-sensitive.

• Does your NAS support non-alphanumeric characters in the shared secret?

  Some NASs do not recognize all of the characters that IAS accepts for a shared secret. You can test this by temporarily changing the shared secret to one with only alphanumeric characters.

• Is the IAS server discarding the packets from the NAS?

  The NAS might be sending packets that do not correspond to the format expected by the IAS server. Enable the logging of rejected and discarded requests and then check the Windows 2000 system-event log to see if unexpected or malformed packets are being received. If this is the case, you might need to set some vendor-specific attributes in the matching remote access policy profile. Consult your NAS documentation to determine the types of vendor-specific attributes that need to be configured on the IAS server.

• Is the IAS server a member of the correct domain?

  Verify the domain of which the IAS server is a member. If the domain is correct, verify that there is a trust relationship between the domain of the user credential and the domain to which the IAS server belongs. If the domain of the user credential is in another Active Directory forest, you must configure a RADIUS proxy between the NAS and the IAS servers of each forest.

• For a Windows 2000 domain, is the IAS-server computer account a member of the RAS and IAS Servers security group?

  In order to be able to access user account properties in a domain, the computer account of the IAS server must be a member of the RAS and IAS Servers security group of that domain. This can be assigned through the Active Directory Users and Computers administrative tool, by registering the IAS server in the Internet Authentication Service administrative tool, or by using the netsh ras add registeredserver command.

• Are you requiring the signature attribute in each RADIUS request message?

  Verify that the NAS is sending the signature attribute in each RADIUS request message. If it is not, the IAS server will discard all RADIUS request messages that do not have the signature attribute.

• Is the PPP client using high encryption?

  To use high encryption (128-bit MPPE or 3-DES), the High Encryption Pack must be installed on the PPP client, the Routing and Remote Access server, and the IAS server. Additionally, the matching remote access policy profile must have the Strongest encryption type enabled.

• Does your NAS require the Framed-Routing attribute?

  Your NAS might require framed routing. By default, the Framed-Routing attribute is not sent in the Access-Accept message.

  To enable the Framed-Routing attribute, complete the following steps:

  1. In the Internet Authentication Service administrative tool, click Remote Access Policies, and then double-click the policy that applies to the users who cannot log on.

  2. Click Edit Profile, click the Advanced tab, and then click Add.

  3. In the list of available RADIUS attributes, double-click Framed-Routing.

  4. In Attribute value, click None.

  5. Click OK to save changes to the profile, and then click OK to save changes to the policy.

• Does your NAS require Van Jacobsen TCP/IP compression?

  Your NAS might require Van Jacobsen TCP/IP compression. To configure IAS to work with Van Jacobsen TCP/IP header compression, complete the following steps:

  1. In the Internet Authentication Service administrative tool, click Remote Access Policies, and then double-click the policy that applies to the users who cannot log on.

  2. Click Edit Profile, click the Advanced tab, and then click Add.

  3. In the list of available RADIUS attributes, double-click Framed-Compression.

  4. In Attribute value, click Van Jacobsen TCP/IP header compression, and then click OK.

  5. Click OK to save changes to the profile, and then click OK to save changes to the policy.

• Does your NAS require the Framed-MTU attribute?

  If Framed MTU is set on the NAS and not on IAS, users are not able to log on. Check your Framed MTU settings on IAS, and make sure that they match the settings on your NAS.

  To change Framed MTU settings, complete the following steps:

  1. In the Internet Authentication Service administrative tool, click Remote Access Policies, and then double-click the policy that applies to the users who cannot log on.

  2. Click Edit Profile, click the Advanced tab, and then click Add.

  3. In the list of available RADIUS attributes, double-click Framed-MTU.

  4. Click Attribute value, and then type the value that matches the settings for your NAS.

  5. Click OK to save changes to the profile, and then click OK to save changes to the policy.

• Is the IAS server computer multi-homed?

  If the IAS server computer is returning the Access-Accept message using a different network adapter from the one on which the Access-Request message was received, the NAS may not recognize the message and discard it. In this case, you can add persistent static IP routes to the routing table of the IAS server computer so that the Access-Accept messages to the NAS are sent out on the same interface on which the Access-Request messages are received.

• Are you using a RADIUS proxy?

  If a request is returned through a RADIUS proxy, the proxy might not support certain extensions that are necessary to support some features. For example:

  • If you want your users to use EAP authentication, the RADIUS proxy must support digital signatures (according to RADIUS extensions).

  • If you want your users to connect using compulsory tunnels, the RADIUS proxy must support encryption of the tunnel password.

  • If you want connections to use Microsoft Encryption, the RADIUS proxy must support encryption of MPPE keys.

See your RADIUS proxy documentation to make sure that it supports the extensions necessary for the features that you want to use.

Appendix A – Frequently Asked Questions

1. What is IAS?

   Internet Authentication Service (IAS) is the Microsoft Windows 2000 implementation of a Remote Authentication Dial-in User Service (RADIUS) server. RADIUS provides an industry-standard method to authenticate, authorize, and provide accounting for remote access and router-to-router connections. IAS can be used as a RADIUS server to any device, typically a network access server (NAS) that supports RADIUS.

2. What platforms does IAS run on?

   IAS runs on any version of Windows 2000 Server (including Advanced Server and Datacenter Server) and is included with the operating system. IAS does not support a RADIUS-proxy capability and can only use Windows 2000 local Security Accounts Manager (SAM) or a Windows NT 4.0 or Windows 2000 domain controller for authentication.

   There are two versions of a Microsoft RADIUS server for Windows NT Server 4.0:

   1. The first version is named Internet Connection Services for Microsoft Remote Access Server and is included in the Windows NT 4.0 Option Pack. You can download the Windows NT 4.0 Option Pack from https://www.microsoft.com/ntserver/nts/downloads/recommended/NT4OptPk/default.asp

   2. The second version is named Internet Connection Services for Microsoft RAS, Commercial Edition. It is an upgrade of the version supplied with the Windows NT 4.0 Option Pack. Internet Connection Services for Microsoft RAS, Commercial Edition provides a RADIUS proxy capability and support for different authentication mechanisms such as the Microsoft Membership System database, ODBC compliant databases, and local flat file.

      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.

3. Does IAS work with all Network Access Servers (NASs)?

   Yes. Any NAS, VPN server, or device that supports RFCs 2138 and 2139 will work with IAS. Check your NAS documentation to determine RFC 2138 and 2139 compliance.

4. What is new in IAS, the Windows 2000 versions of the RADIUS server?

   There are several enhancements in Windows 2000 IAS that make it more scalable, robust, and secure than the versions made available for Windows NT 4.0. Here are some of the new features in Windows 2000:

   • Support for new authentication protocols and methods such as Extensible Authentication Protocol (EAP), Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), Dialed Number Identification Service (DNIS) authorization, Automatic Number Identification (ANI) authorization, and unauthenticated access.

   • Centralized authorization of connection attempts based on remote access policies.

   • Multi-vendor dictionary.

   • Centralized auditing and accounting that supports multilingual log files.

   • Remote monitoring and administration of your IAS servers.

   • Scalability to up to millions of users.

   • Enhanced Software Development Kit (SDK) to create custom EAP modules, authentication modules, or authorization modules.

5. Why should I use IAS over other RADIUS servers?

   IAS has the following features:

   • Support for new authentication protocols and methods, such as Extensible Authentication Protocol (EAP), Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), Dialed Number Identification Service (DNIS) authorization, Automatic Number Identification (ANI) authorization, and unauthenticated access.

   • Support for CHAP.

   • Local or remote graphical-user-interface configuration.

   • Integration with Windows 2000, including the use of user accounts, groups of Windows NT or Windows 2000 domains, and the Windows 2000 Event Log.

   • Detailed authentication and accounting logging.

   • Scalability to the largest ISPs.

   • Support for RFC-based RADIUS SNMP MIBs.

   • Flexible remote access policies to provide centrally managed authorization and connection-parameter enforcement.

   • Multi-vendor dictionary that allows the creation of custom vendor-specific attributes.

   • Authentication and authorization capabilities, extended through the IAS SDK.

6. Can IAS authenticate user accounts in NetWare Directory Services (NDS)?

   No. IAS in Windows 2000 authenticates only user accounts that reside in a local SAM, a Windows NT 4.0 domain, or a Windows 2000 domain.

   To authenticate user accounts in an NDS tree, you will either have to use a RADIUS proxy to forward the authentication request to a RADIUS server that supports NDS authentication or create an IAS authentication module using the IAS SDK that authenticates the user credentials using an NDS tree. A computer using the Internet Connection Services for Microsoft RAS, Commercial Edition and Windows NT 4.0 could be used as the RADIUS proxy. If there is a method for submitting user authentications to NDS through an ODBC interface, then you can use the Internet Connection Services for Microsoft RAS, Commercial Edition and Windows NT 4.0 as the RADIUS server that is providing the authentication.

7. Does IAS support callback?

   If you configure the Set by Caller callback option on the dial-in properties of the user account, IAS returns the Service-Type=Callback-Framed attribute. This behavior is not clearly specified in the RADIUS RFCs and some NASs might not support this option. See your NAS documentation for more information.

   If you configure the Always Callback to option on the dial-in properties of the user account and configure a phone number, IAS returns the Service-Type=Callback-Framed and Callback-Number="configured number" attributes. IAS conforms to the recommendation of the RFC, but some NASs might not. See your NAS documentation for more information.

8. Can I use IAS to authenticate Web users?

   No. Most Web servers, including all versions of the Microsoft Internet Information Server, do not use RADIUS to authenticate Web users.

9. Does Microsoft support a RADIUS client?

   Yes. Both the Windows NT 4.0 Routing and Remote Access Service (RRAS) and the Windows 2000 Routing and Remote Access service can be configured as a RADIUS client to any RADIUS server.

10. Can my users change their passwords remotely once the passwords have expired?

    Yes, provided that the dial-in client supports password changes during authentication, the client is using an authentication method that supports password changes (such as MS-CHAP or MS-CHAP v2), and the user account is in either the local SAM or a Windows NT 4.0 or Windows 2000 domain.

11. Does IAS support RADIUS proxying?

    No. However, RADIUS proxying is supported by the Internet Connection Services for Microsoft RAS, Commercial Edition for Windows NT 4.0.

12. Can IAS scale to millions of users?

    Yes. IAS can be used in many different environments, from the small business all the way up to the largest ISP. For more information, see the section on Performance and IAS.

13. Is IAS a single point of failure?

    No. Typical RADIUS configurations use a primary RADIUS server and a backup RADIUS server that are configured with the same set of policies. RADIUS clients are configured for both the primary and backup RADIUS servers. If the primary RADIUS server becomes unavailable, RADIUS clients begin using the backup.

14. Does IAS support the ability to control the number of concurrent logon sessions?

    No. However, you can write an authorization module using the IAS SDK to support this feature.

15. Does IAS support Security Dynamics token cards?

    Yes, both EAP-based and non-EAP-based Security Dynamics token cards are supported. The Windows 2000 Server Resource Kit contains an EAP module for EAP-based Security Dynamics token card authentication. Non-EAP-based Security Dynamics token-card authentication can be supported by developing an authentication module using the IAS SDK.

16. Does IAS support the Challenge Handshake Authentication Protocol (CHAP) for both Windows NT 4.0 and Windows 2000 domains?

    Yes.

17. Does IAS work in a Windows NT 4.0 domain?

    Yes. IAS works in a Windows NT 4.0 domain, Windows 2000 native mode, and Windows 2000 mixed-mode domains.

18. Does IAS support authentication against the Microsoft Membership System or a U2 Web database?

    No.

19. Will IAS work with my NAS if the attributes for my NAS are not in the IAS multi-vendor dictionary?

    Yes. If there is an attribute that your NAS requires, you can configure a custom vendor-specific attribute (VSA) on the Advanced tab of the profile for the matching remote access policy. Check your NAS documentation for the correct format of these attributes.

20. How can I manage the configuration of remote access policies from a central location?

    Remote access policies are stored locally on the IAS server. All RADIUS clients of the IAS server are subject to the same set of policies. You can copy the configuration of one IAS server, including policies, with the following procedure:

    1. At a command prompt, type netsh aaaa show config > path\file.ext . This stores the configuration settings, including registry settings, in a text file. The path can be relative, absolute, or a UNC path.

    2. Copy the file you created to the destination computer and, at a command prompt on the destination computer, type netsh exec path\file.ext . A message appears indicating whether the update was successful.

21. How can I use the Light Directory Access Protocol (LDAP) to access the per-user attributes in Active Directory?

    There is a published Application Program Interface (API) called MPR that you can use to do this.

22. How can I set a static IP address for each of my users?

    You can set a static IP address using the Assign a Static IP Address option in the Dial-in properties of a user account. This option can only be set on user accounts in a local SAM for a stand-alone IAS server or on user accounts in a Windows 2000 native mode domain.

23. How do I read the IAS log files?

    The file formats for the IAS log files are documented in Windows 2000 Server online Help. The Windows 2000 Server Resource Kit includes iasparse.exe, a command–line utility used to parse and read IAS log files, and TRU Access Manager Limited Edition, a network accounting application developed by Telco Research.

24. Along with RFCs 2138 and 2139, there are several addendum drafts that describe compulsory tunneling, signature attributes, and EAP. Are these supported in IAS?

    Yes. The drafts describe several RADIUS attributes that were introduced by the IETF after the release of RFCs 2138 and 2139. Selected attributes from these drafts are supported.

25. Which NASs were tested with IAS?

    Interoperability testing was done on NASs from Cisco, Lucent (Ascend Communications), 3-Com (US Robotics), the Windows NT 4.0 Routing and Remote Access Service (RRAS), and the Windows 2000 Routing and Remote Access service.

26. How many IAS servers do I need?

    This depends on the number of authentication requests you anticipate. IAS can perform hundreds of authentication requests per second on single server. Using that as a guideline, you can make a better determination of the number of servers you will need. For more information, see the section on Performance and IAS.

27. Can I manage my IAS servers from my laptop, which is running Windows 2000 Professional?

    Yes. You can install the Administration Tools on your laptop running Windows 2000 Professional and administer all of your IAS servers with the Internet Authentication Service administrative tool.

28. How does unauthenticated access work?

    Unauthenticated access does not require the user to provide a user name, password, or domain. If you enable unauthenticated access, IAS uses the Windows 2000 Guest account to authenticate and authorize the user's connection attempt. The Guest account must be enabled and the remote access permission must be set to either Allow access or Control access through Remote Access Policy.

29. Do I have to install IAS on a domain controller?

    No. IAS can be installed on a computer that is a domain member. IAS performs authentication of domain credentials of incoming Access-Request messages using a secure communications channel with a domain controller.

30. How does IAS perform authentication?

    The IAS server receives the user credentials from the NAS in the RADIUS Access-Request message. If there is a domain included in the user credentials, then IAS will look up the user's account in that domain. The domain must be either a trusted domain or the domain in which the IAS server is a member. Otherwise, the connection attempt is rejected.

    If the user credentials do not specify a domain, the IAS server determines the default domain from the registry. If the default domain is not specified in the registry, the IAS server uses the domain of which it is a member. If the IAS server is not a member of a domain, it attempts to authenticate the user credentials through the local SAM.

31. How do remote access policies work in IAS?

    Remote access policies provide the authorization of the connection attempt. Once the user credentials have been authenticated, IAS evaluates the parameters of the connection attempt against the set of configured remote access policies. If the connection attempt matches a remote access policy (meets all of the conditions of the policy); has remote access permission; and meets all of the conditions of the account, the dial-in properties of the user account, and the remote access policy-profile settings, the connection attempt is accepted.

    If the connection attempt does not match any remote access policy, does not have remote access permission, or fails to meet all of the conditions of the account and dial-in properties of the user account and the remote access policy profile settings, the connection attempt is rejected.

    A connection attempt must be both authenticated and authorized before it is accepted.

32. How many remote access policies do I need?

    IAS supports having dozens of policies. However, in most cases, only a handful of policies are needed to provide authorization. If you are using Windows groups to grant access and determine connection parameters, use universal groups and group nesting to reduce the number of policies. If you have unique needs outside of the policies in IAS, you can use the IAS SDK to write your own authorization module.

33. What are the minimum hardware requirements for IAS?

    The minimum hardware requirements for IAS are the same as those for Windows 2000 Server: a Pentium 133 MHz (or equivalent) computer with 128MB of RAM.

34. Where can I learn more about IAS?

    Windows 2000 Server Help contains conceptual, deployment, troubleshooting, and procedure information on IAS. Chapter 8 of the Windows 2000 Server Resource Kit Internetworking Guide, called Internet Authentication Service, contains additional technical details for IAS.

Appendix B – The RADIUS Protocol

An understanding of the RADIUS protocol is helpful in doing the following:

• Interpreting a Network Monitor capture.

• Understanding the different packet formats when analyzing the accounting log.

• Entering vendor-specific attribute numbers.

RADIUS packets sent to the RADIUS server are sent as User Datagram Protocol (UDP) messages using UDP port 1812 for RADIUS authentication messages and UDP port 1813 for RADIUS accounting messages. Some earlier network access servers use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages. By default, IAS supports the receiving of RADIUS messages on both sets of UDP ports. One RADIUS packet is encapsulated in the UDP payload.

General Packet Structure

Figure 27 shows the general structure of a RADIUS packet:

Figure 27: The General Structure of a RADIUS Packet

Code

The Code field is one byte long and indicates the RADIUS packet type. A packet with an invalid Code field is silently discarded. The defined values for the RADIUS Code field are listed in Table 4.

Table 4 Values for the RADIUS Code Field

Codes (decimal)	Packets
1	Access-Request
2	Access-Accept
3	Access-Reject
4	Accounting-Request
5	Accounting-Response
11	Access-Challenge
12	Status-Server (experimental)
13	Status-Client (experimental)
255	Reserved

Identifier

The Identifier field is one byte long and is used to match a request with its corresponding response.

Length

The Length field is two octets long and indicates the entire length of the packet and RADIUS message, including the Code, Identifier, Length, and Authenticator fields, and the RADIUS attributes. The Length field can vary from 20 through 4,096 bytes.

Authenticator

The Authenticator field is 16 octets long and contains the information that the RADIUS client and server use to authenticate each other.

Attributes

The Attributes section of the RADIUS packet contains one or more RADIUS attributes, which carry the specific authentication, authorization, information, and configuration details for RADIUS packets. For attributes that have multiple instances, the order of the attributes must be preserved. Otherwise, attribute types do not need to have their order preserved.

RADIUS Attributes

Figure 28 shows the structure of each RADIUS attribute. RADIUS attributes use the common Type-Length-Value format used by other protocols:

Figure 28: The RADIUS Attribute Structure

Type

The Type field is one byte long and indicates the specific type of RADIUS attribute. Some of the attributes are listed in Table 5. For information about other RADIUS attributes and their use, see RFCs 2138 and 2139.

Table 5 RADIUS Attribute Types

Type values	Description
1	User-Name
2	User-Password
3	CHAP-Password
4	NAS-IP-Address
5	NAS-Port
6	Service-Type
7	Framed-Protocol
8	Framed-IP-Address
9	Framed-IP-Netmask
10	Framed-Routing
11	Filter-ID
12	Framed-MTU
13	Framed-Compression
19	Reply-Message
24	State
25	Class
26	Vendor-Specific
27	Session-Timeout
28	Idle-Timeout
29	Termination-Action
32	NAS-Identifier
61	NAS-Port-Type
62	Port-Limit

Type values 192 through 223 are reserved for experimental use, values 224 through 240 are reserved for implementation-specific use, and values 241 through 255 are reserved and must not be used. Value 26 is reserved for vendor-specific attributes (VSAs).

Length

The Length field indicates the length of the attribute, including the Type, Length, and Value fields.

Value

The Value field is zero or more octets and contains information specific to the attribute. The format and length of the Value field is based on the type of RADIUS attribute.

Vendor-Specific Attributes

VSAs are available to allow vendors to support their own proprietary attributes that are not covered by RFC 2138. IAS includes VSAs from a number of vendors in its multi-vendor dictionary. This list evolves over time, and new attributes and vendors are always being added.

To accommodate attributes that are not in the IAS multi-vendor dictionary, you can add them through IAS as Vendor-Specific (attribute type 26) in the Advanced tab of a remote access policy profile. To use attribute type 26, you need to know the VSA format and other required information. The VSA formats are documented in the following section. For the other required information, see your NAS documentation.

The structure of the vendor-specific attribute is shown in Figure 29:

Figure 29: The Vendor-Specific Attribute Structure

Type

The Type value is set to 26 (0x1A) to indicate a VSA.

Length

The Length value is set to the number of bytes in the VSA.

Vendor ID

The vendor ID is four octets long. The high-order octet is 0 (0x00), and the low-order three octets are the Structure and Identification of Management Information (SMI) Network Management Private Enterprise Code of the vendor.

String

The String field is the VSA, consisting of one or more octets. To conform to RFC 2138, the String field should consist of the fields shown in Figure 30:

Figure 30: The String Field Structure

Vendor Type

The Type value is used to indicate a specific VSA for the vendor.

Vendor Length

The Type value is set to the number of bytes in the string.

Attribute-Specific

The Attribute-Specific field contains the data for the specific vendor attribute.

Vendors that do not conform to RFC 2138 use the attribute type 26 to identify a vendor-specific attribute, but do not use the Vendor Type, Vendor Length, and Attribute-Specific fields within the String field. In this case, the vendor-specific attribute format appears as shown in Figure 29.

When adding a VSA for a specific NAS as type 26, you need to know whether the attribute conforms to RFC 2138. For information about whether your NAS uses the VSA format documented in Figure 30, see your NAS documentation.

VSAs are configured from the Vendor-Specific Attribute Information dialog box when adding a Vendor-Specific Attribute from the Advanced tab of a remote access policy profile. If the VSA format conforms to RFC 2138, you can configure the attribute with the vendor-assigned attribute number, format, and value, as defined in NAS documentation. If the VSA format does not conform to RFC 2138, you can configure the attribute with the hexadecimal attribute value, which includes the string of the VSA format (everything after Vendor-ID) as defined in NAS documentation.

RADIUS Packet Example

A Windows 2000 PPTP client attempts a remote access connection to a Windows 2000 VPN server. The VPN server has an IP address of 10.10.210.13 and the IAS server has an IP address of 10.10.210.12.

Access-Request Packet

The following Network Monitor trace shows the Access-Request packet sent by the VPN server to the IAS server.

+ IP: ID = 0x850; Proto = UDP; Len: 248
+ UDP: Src Port: Unknown, (1327); Dst Port: Unknown (1812); Length = 228 (0xE4)
  RADIUS: Message Type: Access Request(1)
      RADIUS: Message Type = Access Request
      RADIUS: Identifier = 2 (0x2)
      RADIUS: Length = 220 (0xDC)
      RADIUS: Authenticator = 8A 6F DC 03 23 5F 4B 62 CA 40 92 38 DC 75
                              CB 74
      RADIUS: Attribute Type: NAS IP Address(4)
          RADIUS: Attribute type = NAS IP Address
          RADIUS: Attribute length = 6 (0x6)
          RADIUS: NAS IP address = 10.10.210.13
      RADIUS: Attribute Type: Service Type(6)
          RADIUS: Attribute type = Service Type
          RADIUS: Attribute length = 6 (0x6)
          RADIUS: Service type = Framed
      RADIUS: Attribute Type: Framed Protocol(7)
          RADIUS: Attribute type = Framed Protocol
          RADIUS: Attribute length = 6 (0x6)
          RADIUS: Framed protocol = PPP
      RADIUS: Attribute Type: NAS Port(5)
          RADIUS: Attribute type = NAS Port
          RADIUS: Attribute length = 6 (0x6)
          RADIUS: NAS port = 32 (0x20)
      RADIUS: Attribute Type: Vendor Specific(26)
          RADIUS: Attribute type = Vendor Specific
          RADIUS: Attribute length = 12 (0xC)
          RADIUS: Vendor ID = 311 (0x137)
          RADIUS: Vendor string =
      RADIUS: Attribute Type: Vendor Specific(26)
          RADIUS: Attribute type = Vendor Specific
          RADIUS: Attribute length = 18 (0x12)
          RADIUS: Vendor ID = 311 (0x137)
          RADIUS: Vendor string = MSRASV5.00
      RADIUS: Attribute Type: NAS Port Type(61)
          RADIUS: Attribute type = NAS Port Type
          RADIUS: Attribute length = 6 (0x6)
          RADIUS: NAS port type = Virtual
      RADIUS: Attribute Type: Tunnel Type(64)
          RADIUS: Attribute type = Tunnel Type
          RADIUS: Attribute length = 6 (0x6)
          RADIUS: Tag = 0 (0x0)
          RADIUS: Tunnel type = Point-to-Point Tunneling Protocol(PPTP)
      RADIUS: Attribute Type: Tunnel Media Type(65)
          RADIUS: Attribute type = Tunnel Media Type
          RADIUS: Attribute length = 6 (0x6)
          RADIUS: Tag = 0 (0x0)
          RADIUS: Tunnel media type = IP (IP version 4)
      RADIUS: Attribute Type: Calling Station ID(31)
          RADIUS: Attribute type = Calling Station ID
          RADIUS: Attribute length = 14 (0xE)
          RADIUS: Calling station ID = 10.10.14.226
      RADIUS: Attribute Type: Tunnel Client Endpoint(66)
          RADIUS: Attribute type = Tunnel Client Endpoint
          RADIUS: Attribute length = 14 (0xE)
          RADIUS: Tunnel client endpoint = 10.10.14.226
      RADIUS: Attribute Type: User Name(1)
          RADIUS: Attribute type = User Name
          RADIUS: Attribute length = 18 (0x12)
          RADIUS: User name = NTRESKIT\user1
      RADIUS: Attribute Type: Vendor Specific(26)
          RADIUS: Attribute type = Vendor Specific
          RADIUS: Attribute length = 24 (0x18)
          RADIUS: Vendor ID = 311 (0x137)
          RADIUS: Vendor string =  |+-_|e $+fN<N
      RADIUS: Attribute Type: Vendor Specific(26)
          RADIUS: Attribute type = Vendor Specific
          RADIUS: Attribute length = 58 (0x3A)
          RADIUS: Vendor ID = 311 (0x137)
          RADIUS: Vendor string =  4

The RADIUS attributes sent by the VPN server include the user name, the service types, the framed protocol, various tunnel attributes for the PPTP connection, and a series of vendor-specific attributes for MS-CHAP authentication. For more information about Microsoft VSAs, see RFC 2548.

Access-Accept Packet

The following Network Monitor trace shows the Access-Accept packet sent by the IAS server to the VPN server.

+ IP: ID = 0xB18; Proto = UDP; Len: 248
+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (1327); Length = 228 (0xE4)
  RADIUS: Message Type: Access Accept(2)
      RADIUS: Message Type = Access Accept
      RADIUS: Identifier = 2 (0x2)
      RADIUS: Length = 220 (0xDC)
      RADIUS: Authenticator = 52 E2 19 98 2E F8 E2 D3 B7 3B E1 24 5B 72
                              55 9E
      RADIUS: Attribute Type: Framed Protocol(7)
          RADIUS: Attribute type = Framed Protocol
          RADIUS: Attribute length = 6 (0x6)
          RADIUS: Framed protocol = PPP
      RADIUS: Attribute Type: Service Type(6)
          RADIUS: Attribute type = Service Type
          RADIUS: Attribute length = 6 (0x6)
          RADIUS: Service type = Framed
      RADIUS: Attribute Type: Class(25)
          RADIUS: Attribute type = Class
          RADIUS: Attribute length = 32 (0x20)
          RADIUS: Class = <$ @
      RADIUS: Attribute Type: Vendor Specific(26)
          RADIUS: Attribute type = Vendor Specific
          RADIUS: Attribute length = 42 (0x2A)
          RADIUS: Vendor ID = 311 (0x137)
          RADIUS: Vendor string =  $ DZ|,Sc7 _:+RW_t-qxF| (-+|%p6
      RADIUS: Attribute Type: Vendor Specific(26)
          RADIUS: Attribute type = Vendor Specific
          RADIUS: Attribute length = 42 (0x2A)
          RADIUS: Vendor ID = 311 (0x137)
          RADIUS: Vendor string =  $
      RADIUS: Attribute Type: Vendor Specific(26)
          RADIUS: Attribute type = Vendor Specific
          RADIUS: Attribute length = 51 (0x33)
          RADIUS: Vendor ID = 311 (0x137)
          RADIUS: Vendor string =  -
      RADIUS: Attribute Type: Vendor Specific(26)
          RADIUS: Attribute type = Vendor Specific
          RADIUS: Attribute length = 21 (0x15)
          RADIUS: Vendor ID = 311 (0x137)
          RADIUS: Vendor string =

The RADIUS attributes sent by the IAS server include the user name, the service type, the framed protocol, the service class, and a series of vendor-specific attributes for MS-CHAP authentication.

Appendix C – Differences Between Windows NT 4.0 IAS and Windows 2000 IAS

An earlier version of IAS was released with the Windows NT 4.0 Option Pack. The following section describes the differences between the two versions.

Windows NT 4.0 IAS Behavior

• If no domain name is specified during authentication, the IAS server authenticates the user against only the local SAM database.

• IAS does not use callback permissions for all user accounts.

• IAS log files are written in ASCII.

Windows 2000 IAS Behavior

• IAS resolves a user name with no domain specified by using the following sequence:

  1. IAS determines a default domain from the registry by using the DefaultDomain registry setting, if one is specified there.

  2. If the IAS server is a member of a domain, IAS authenticates the user against that domain.

  3. If the IAS server is not a member of a domain, IAS authenticates the user against the local SAM database.

• IAS uses the callback permissions for all user accounts.

• IAS log files are multi-language and are written in UTF-8.

Appendix D – Using Pattern Matching Syntax for Realm Replacement

Windows 2000 supports the use of the pattern matching syntax that is widely used in UNIX environments. You can use this syntax to specify the conditions of remote access policy attributes and RADIUS realms. Table 6 describes the special characters that you can use and includes examples.

Table 6 Special Characters for Pattern Matching Syntax

Character	Description
\	Marks the next character as special. For example, /n/ matches the character "n". The sequence /\n/ matches a line feed or newline character.
^	Matches the beginning of input or line.
$	Matches the end of input or line.
*	Matches the preceding character zero or more times. For example, /zo*/ matches either "z" or "zoo."
+	Matches the preceding character one or more times. For example, /zo+/ matches "zoo" but not "z."
?	Matches the preceding character zero or one time. For example, /a?ve?/ matches the "ve" in "never."
.	Matches any single character except a newline character.
(pattern)	Matches a pattern and remembers the match. For example, use "\(" or "\)" to match parentheses characters ( ).
x|y	Matches either x or y. For example, /z|food?/ matches "zoo" or "food."
{n}	Matches exactly n times (n is a nonnegative integer). For example, /o{2}/ does not match the "o" in "Bob," but matches the first two o's in "foooood."
{n,}	Matches at least n times (n is a nonnegative integer). For example, /o{2,}/ does not match the "o" in "Bob" but matches all the o's in "foooood." /o{1,}/ is equivalent to /o+/.
{n,m}	Matches at least n and at most m times (m and n are nonnegative integers). For example, /o{1,3}/ matches the first three o's in "fooooood."
[xyz]	A character set. Matches any one of the enclosed characters. For example, /[abc]/ matches the "a" in "plain."
[^xyz]	A negative character set. Matches any character not enclosed. For example, /[^abc]/ matches the "p" in "plain."
\b	Matches a word boundary, such as a space. For example, /ea*r\b/ matches the "er" in "never early."
\B	Matches a nonword boundary. For example, /ea*r\B/ matches the "ear" in "never early."
\d	Matches a digit character (equivalent to [0-9]).
\D	Matches a nondigit character (equivalent to [^0-9]).
\f	Matches a form-feed character. Matches a line feed character. Matches a carriage return character.
\n
\r
\s	Matches any white space including space, tab, form-feed, and so on. Equivalent to [ \f\n\r\t\v].
\S	Matches any non-white-space character (equivalent to [^ \f\n\r\t\v]).
\t	Matches a tab character.
\v	Matches a vertical tab character.
\w	Matches any word character including underscore (equivalent to [A-Za-z0-9_]).
\W	Matches any nonword character excluding an underscore (equivalent to [^A-Za-z0-9_]).
\num	?num, where num is a positive integer. A reference back to remembered matches. \1 replaces what is stored in the first remembered match. This option can be used only in the Replace text box when configuring realms with Internet Authentication Service.
/n/	?n, where n is an octal, hexadecimal, or decimal escape value. Allows embedding of ASCII codes into regular expressions.

Examples: Remote Access Policy Attributes

The following examples describe the use of the pattern-matching syntax to specify remote access policy attributes:

• To specify all phone numbers within a fixed area code:

  For example, to specify all numbers in the 899 area code, the syntax is 899.*

• To specify a range of IP addresses:

  For example, to specify all IP addresses that begin with 192.168.1, the syntax is 192\.168\.1\..+

Examples: RADIUS Realm Name Replacement

The following examples describe the use of the pattern matching syntax to replace realm names in IAS properties, on the Realms tab, in Find and Replace:

• To remove the realm portion of the user name:

  In the outsourced dial scenario, the Internet service provider (ISP) might require a realm to route the authentication request to the Internet Authentication Service (IAS) server. Windows 2000 might not recognize the realm, which should be removed (by leaving Replace blank) before authenticating the user.

  Find: @microsoft\\.com

  Replace:

• To replace user@domain.microsoft.com with domain.microsoft.com\user:

  Find: (.*)@(.*)

  Replace: $2\$1

• To replace domain\user with specific_domain\user

  Find: {.*}\\{.*}

  Replace: specific_domain\\$2

• To replace user with user@specific_domain

  Find: $

  Replace: @specific\_domain

For information on how to configure realm replacement in IAS, see Windows 2000 Server Help.

Appendix E – IAS Events in the Windows 2000 System Event Log

When event logging is enabled from the Service tab in the properties of an IAS server, the events listed in Table 7 can be used to troubleshoot problems with your IAS or NAS configuration.

Table 7 IAS Events in the Windows 2000 System Event Log

Event log message	Meaning
"Unknown user name or bad password." "The specified user does not exist." "The specified domain does not exist."	The user might have typed the wrong user name or password. Check the user's Windows 2000 user name and account password to make sure they are typed correctly and that the account is valid for the domain IAS is authenticating the user against. Realm replacement might be set up incorrectly, or in the wrong order, so that the domain controller cannot recognize the user name. Adjust the realm replacement rules. For more information about realm names or configuring realm replacement, see Windows 2000 Server Help. If the remote access server is a member of a domain and the user response does not contain a domain name, the domain name of the remote access server is used. To use a domain name that is different from that of the IAS server, on the computer that is running IAS, set the following registry value to the name of the domain that you want to use: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RasMan \PPP\ControlProtocols\BuiltIn\DefaultDomain Some NASs automatically strip the domain name from the user name before forwarding the user name to a RADIUS server. Turn off the feature that strips the domain name from the user name. For more information, see your NAS documentation. The user might be using CHAP, but Active Directory might not be configured to use plaintext passwords. To use CHAP authentication with IAS, configure the dial-in profile for a user or group to use CHAP. The NAS and the user's dialing program (such as Connection Manager) must also be configured to use CHAP authentication. You must also enable CHAP on the domain controller.
"The authentication type is not supported on this system."	The user is trying to authenticate by using an authentication method that is not supported on this computer. For example, the user might be using an EAP type that has not been installed. Modify the dial-in profile to allow the protocol in question.
"The user's information did not match a remote access policy." "The user is not allowed dial-in access to the network." "User attempted an unauthorized authentication method." "User tried to connect from an unauthorized calling station." "User tried to dial-in outside of permitted hours." "User tried to connect by calling an unauthorized NAS phone number." "User tried to connect using an invalid port type." "A constraint defined in the remote access policy failed."	A remote access policy might be denying access to the user. Check the policy list to make sure that you have not excluded users who must be granted access. Check the event log to see if the user is trying to connect with parameters that are not permitted by a remote access policy (for example, during an unauthorized time period, using an unauthorized port type, calling from an unauthorized phone number, or calling an unauthorized NAS phone number). You might have to revise the remote access policies accordingly to grant the user access. Remote access policies might be in the wrong order. Authorization is granted or denied by the first policy whose conditions match the connection attempt. Use the Move Up button to move the policy that grants access to the users who are having trouble so that it is higher in the list.
"The user has exceeded the dial-in lockout count."	If remote access account lockout is enabled, previous failed access attempts might have caused the user account to be locked out. If so, increase the dial-in lockout count.
"The user's account is currently locked out and might not be logged on to." "The user's account is locked out and cannot be validated." "The user is not allowed dial-in access to the network."	The user might be denied dial-in access. Check the user's information on the domain controller (or in Local Users and Groups) to verify that dial-in access is granted for the user. If dial-in access is denied, this overrides any remote access policy that grants access.
"The current configuration supports only local user accounts."	IAS is set up to authenticate against the local SAM, and the user is not a member of the local user database. In this case, add the IAS server to Active Directory.
"The user's account domain is unreachable." "The server is unavailable." "The specified domain did not exist." "IAS could not access the Global Catalog."	There might be a communication problem between the NAS and IAS, or between IAS and the domain controller or Global Catalog server. Use the ping command to check the communication with the domain controller or Global Catalog server. If ping works, try to connect to the server by using the command net use \\servername\share. If no packet information appears in the IAS log, check the Windows 2000 event log to see whether the attempt times out.

Appendix F – IAS Registry Settings

DefaultDomain

Location:HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RasMan \PPP\ControlProtocols\BuiltIn

Data type: REG_SZ

Range: n/a

Default value: The computer name or member domain of the IAS server.

Description: Specifies the domain used to validate a logon when no domain is specified in the Access-Request message. This entry applies to networked computers running Windows 2000 Server only. By default, the system uses the name of the primary domain of the local computer. However, you can add this entry to the registry to override the default value and force the system to use the specified domain.

Allow LM Authentication

Location: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RemoteAccess\Policy

Data type: REG_DWORD

Range: 0-1

Default: 1

Present by default: No

Description: Determines whether LAN Manager (LM) Challenge/Response authentication is enabled (=1) or disabled (=0). IAS and the Routing and Remote Access service typically use Windows Challenge/Response authentication, version 2 (known as NTLMv2) because it provides more robust password protection. However, LAN Manager authentication support is available to maintain compatibility with servers running earlier operating systems that do not support NTLMv2 authentication.

When enabled, LAN Manager authentication is supported. The PPP clients of earlier Microsoft operating systems such as Windows NT 3.5, Windows 95, or Windows 98 will be able to connect. However, use of LAN Manager authentication makes authentication more vulnerable to malicious attacks that take advantage of the weaker protocol.

When disabled, LAN Manager authentication is not supported. As a result, the PPP clients of earlier Microsoft operating systems, such as Windows NT 3.5, Windows 95, and Windows 98, will not be able to connect.

Default User Identity

Location: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RemoteAccess\Policy

Data type: REG_SZ

Range: NA

Default value: The name of the guest account for the domain

Present by default: No

Description: Specifies the name used for Guest access to the network. By default, if a request for Guest access does not include the name of a user account, then the system uses the Guest account for the local computer or for the domain. However, you can add this entry to the registry to specify an alternate Guest account.

The account specified in this entry is used for Guest accounts instead of the default when:

• The value of Override User-Name is 0.

• User Identity Attribute does not appear in the registry.

• The RADIUS attribute specified in the value of User Identity Attribute does not appear in the request.

Override User-Name

Location: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RemoteAccess\Policy

Data type: REG_DWORD

Range: 0-1

Default value: 0

Present by default: No

Description: Directs IAS to use the RADIUS attribute specified in the value of the User Identity Attribute registry setting to identify an account for purposes of authentication and accounting. The specified attribute is used instead of the user account name, even when a valid user account name appears in the request.

When Override User Name is set to 0, IAS uses the value of the RADIUS User-Name attribute for authentication and accounting. When Override User Name is set to 1, IAS uses the attribute specified in the value of User Identity Attribute.

RADIUS attributes are defined in RFC 2138. To find a list of RADIUS attributes, see RFC 2138, or see Remote Access RADIUS Attributes in Windows 2000 Server Help.

Caution: If the value of this entry is 1, and User Identity Attribute does not appear in the registry with a valid value, IAS does not authenticate any users.

User Identity Attribute

Location: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RemoteAccess\Policy

Data type: REG_DWORD

Range: 0-255

Default value: 1

Present by default: No

Description: Specifies an alternate RADIUS attribute by a number that is used to identify a user account in Active Directory for authentication and authorization. By default, the value of the alternate attribute specified here is used only when the access request does not include a user name (that is, when the request does not include a valid RADIUS User-Name attribute).

However, if the value of Override User-Name is 1, IAS must use the attribute specified in the value of this entry to identify the account, even when the request includes a valid User-Name attribute.

To specify an attribute, enter the RADIUS attribute number for the attribute in decimal integers. For example, to identify users by their caller ID or Automatic Number Identification (ANI), add this entry to the registry and set its value to 31, the RADIUS attribute number for Calling-Station-ID.

Note: If the attribute specified in this entry is not included in the request, IAS uses the value of the RADIUS User-Name attribute. If it is not present or valid, IAS uses the account specified in the value of Default User Identity, if available. Otherwise, the system uses the Guest account for the local computer or the domain.

RADIUS attributes are defined in RFC 2138. To find a list of RADIUS attributes, see RFC 2138, or see Remote Access RADIUS Attributes in Windows 2000 Server Help.

Allow SNMP Set

Location: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \IAS\Parameters

Data type: REG_DWORD

Range: 0-1

Default value: 0

Present by default: No

Description: Determines whether IAS accepts (=1) or rejects (=0) incoming Simple Network Management Protocol (SNMP) Set messages. This entry applies only when SNMP is being used to monitor IAS.

Set messages change or update values in an SNMP MIB. IAS accepts these messages only when an agent has permission to write to the MIB.

Set messages are prohibited by default, but you can add this entry to the registry to permit the IAS to accept Set messages.

Ping User-Name

Location: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \IAS\Parameters

Data type: REG_SZ

Range: n/a

Default value: n/a

Present by default: No

Description: Specifies a user name (or user-name pattern with variables) that the Internet Authentication Service (IAS) recognizes as a fictitious name. As a result, IAS rejects authentication requests and responds to all accounting requests from this user. Additionally, IAS does not record transactions involving this user in any log files.

Proxy servers implementing the RADIUS protocol and NASs periodically send authentication and accounting requests (ping requests) to verify that the server is responsive. These ping requests include fictional user names.

This entry helps IAS recognize the fictitious name or naming scheme used in ping requests. This method is likely to improve IAS performance and make the event log easier to interpret.

To indicate more than one user name, enter a name pattern, such as a DNS name including wildcard characters. For help with patterns, see Appendix D.

Appendix G – Performance Monitor Counters and SNMP MIBs

You can monitor the health and performance of an IAS server using either Windows 2000 Performance Monitor or the Windows 2000 SNMP agent and the built-in support for industry-standard RADIUS MIBs.

Performance Monitor Objects and Counters

Windows 2000 Performance Monitor allows you to monitor the health of your IAS server through a series of counters for the following performance-monitor objects:

• IAS Accounting Clients Object.

• IAS Accounting Server Object.

• IAS Authentication Clients Object.

• IAS Authentication Server Object.

IAS Accounting Clients Object

The IAS Accounting Clients performance object is installed by the Internet Authentication Service (IAS). IAS uses the Remote Authentication Dial-In User Service (RADIUS) protocol to perform remote authentication. IAS performance objects report activity for servers or clients, including user authentication, authorization, and accounting.

When selecting counters for this object, note that each client represents a separate instance.

Table 8 Counters for the IAS Accounting Clients Object

Counter name	Description	Counter type
Accounting-Requests	Shows the number of packets received from this client on the accounting port.	PERF_COUNTER_RAWCOUNT
Accounting-Requests/sec	Shows the rate, in seconds, at which packets were received from this client on the accounting port.	PERF_COUNTER_COUNTER
Accounting-Responses	Shows the number of RADIUS Accounting-Response packets sent to this client.	PERF_COUNTER_RAWCOUNT
Accounting-Responses/sec	Shows the rate, in seconds, at which duplicate RADIUS Accounting-Request packets were received from this client.	PERF_COUNTER_COUNTER
Bad Authenticators	Shows the number of packets that contained invalid signature attributes.	PERF_COUNTER_RAWCOUNT
Bad Authenticators/sec	Shows the rate, in seconds, at which packets that contained invalid signature attributes were received.	PERF_COUNTER_COUNTER
Dropped Packets	Shows the number of incoming packets silently discarded for a reason other than being malformed, bad authenticators, or unknown types.	PERF_COUNTER_RAWCOUNT
Dropped Packets/sec	Shows the rate in seconds at which incoming packets were silently discarded for a reason other than being malformed, bad authenticators, or unknown types.	PERF_COUNTER_COUNTER
Duplicate Accounting-Requests	Shows the number of duplicate RADIUS Accounting-Request packets received from this client.	PERF_COUNTER_RAWCOUNT
Duplicate Accounting-Requests/sec	Shows the rate, in seconds, at which duplicate RADIUS Accounting-Request packets were received from this client.	PERF_COUNTER_COUNTER
Malformed Packets	Shows the number of malformed packets received. Bad authenticators or unknown types are not included.	PERF_COUNTER_RAWCOUNT
Malformed Packets/sec	Shows the rate, in seconds, at which malformed packets were received.	PERF_COUNTER_COUNTER
No Record	Shows the number of RADIUS Accounting-Request packets that were received and responded to, but not recorded.	PERF_COUNTER_RAWCOUNT
No Record/sec	Shows the rate, in seconds, at which RADIUS Accounting-Request packets were received and responded to, but not recorded.	PERF_COUNTER_COUNTER
Packets Received	Shows the number of packets received.	PERF_COUNTER_RAWCOUNT
Packets Received/sec	Shows the rate, in seconds, at which packets were received.	PERF_COUNTER_COUNTER
Packets Sent	Shows the number of packets sent.	PERF_COUNTER_RAWCOUNT
Packets Sent/sec	Shows the rate, in seconds, at which packets were sent.	PERF_COUNTER_COUNTER
Unknown Type	Shows the number of packets of unknown type that were received. An unknown type is a RADIUS packet that contains an unrecognized entry in the Code field, used to identify the packet type. IAS does not support packets of unknown type.	PERF_COUNTER_RAWCOUNT
Unknown Type/sec	Shows the rate, in seconds, at which packets of unknown type were received.	PERF_COUNTER_COUNTER

IAS Accounting Server Object

The IAS Accounting Server performance object is installed by IAS. IAS uses the RADIUS protocol to perform remote authentication. IAS performance objects report activity for servers or clients, including user authentication, authorization, and accounting.

When selecting counters for this object, note that each client represents a separate instance.

Table 9 Counters for the IAS Accounting Server Object

Counter name	Description	Counter type
Accounting-Requests	Shows the number of packets received from this client on the accounting port.	PERF_COUNTER_RAWCOUNT
Accounting-Requests/sec	Shows the rate, in seconds, at which packets were received from this client on the accounting port.	PERF_COUNTER_COUNTER
Accounting-Responses	Shows the number of RADIUS Accounting-Response packets sent to this client.	PERF_COUNTER_RAWCOUNT
Accounting-Responses/sec	Shows the rate, in seconds, at which RADIUS Accounting-Response packets were sent to this client.	PERF_COUNTER_COUNTER
Bad Authenticators	Shows the number of packets that contained invalid signature attributes.	PERF_COUNTER_RAWCOUNT
Bad Authenticators/sec	Shows the rate, in seconds, at which packets that contained invalid signature attributes were received.	PERF_COUNTER_COUNTER
Dropped Packets	Shows the number of incoming packets that were silently discarded for a reason other than being malformed, bad authenticators, or unknown types.	PERF_COUNTER_RAWCOUNT
Dropped Packets/sec	Shows the rate, in seconds, at which incoming packets were silently discarded for a reason other than being malformed, bad authenticators, or unknown types.	PERF_COUNTER_COUNTER
Duplicate Accounting-Requests	Shows the number of duplicate RADIUS Accounting-Request packets that were received from this client.	PERF_COUNTER_RAWCOUNT
Duplicate Accounting-Requests/sec	Shows the rate, in seconds, at which duplicate RADIUS Accounting-Request packets were received from this client.	PERF_COUNTER_COUNTER
Invalid Requests	Shows the number of packets received from unknown addresses.	PERF_COUNTER_RAWCOUNT
Invalid Requests/sec	Shows the rate, in seconds, at which packets were received from unknown addresses.	PERF_COUNTER_COUNTER
Malformed Packets	Shows the number of malformed packets received. Bad authenticators or unknown types are not included.	PERF_COUNTER_RAWCOUNT
Malformed Packets/sec	Shows the rate, in seconds, at which malformed packets were received. Bad authenticators or unknown types are not included.	PERF_COUNTER_COUNTER
No Record	Shows the number of RADIUS Accounting-Request packets that were received and responded to, but not recorded.	PERF_COUNTER_RAWCOUNT
No Record/sec	Shows the rate in seconds at which RADIUS Accounting-Request packets were received and responded to, but not recorded.	PERF_COUNTER_COUNTER
Packets Received	Shows the number of packets received.	PERF_COUNTER_RAWCOUNT
Packets Received/sec	Shows the rate, in seconds, at which packets were received.	PERF_COUNTER_COUNTER
Packets Sent	Shows the number of packets sent.	PERF_COUNTER_RAWCOUNT
Packets Sent/sec	Shows the rate, in seconds, at which packets were sent.	PERF_COUNTER_COUNTER
Server Reset Time	Shows the time elapsed, in hundredths of a second, since the server configuration was reset.	PERF_COUNTER_RAWCOUNT
Server Up Time	Shows the time elapsed, in hundredths of a second, since the server process was started.	PERF_COUNTER_RAWCOUNT
Unknown Type	Shows the number of packets of unknown type that were received.	PERF_COUNTER_RAWCOUNT
Unknown Type/sec	Shows the rate, in seconds, at which packets of unknown type were received.	PERF_COUNTER_COUNTER

IAS Authentication Clients Object

The IAS Authentication Clients performance object is installed by IAS. IAS uses the RADIUS protocol to perform remote authentication. IAS performance objects report activity for servers or clients, including user authentication, authorization, and accounting.

When selecting counters for this object, note that each client represents a separate instance.

Table 10 Counters for the IAS Accounting Server Object

Counter name	Description	Counter type
Access-Accepts	The number of RADIUS Access-Accept packets sent to this client.	PERF_COUNTER_RAWCOUNT
Access-Accepts/sec	The number of RADIUS Access-Accept packets per second sent to this client.	PERF_COUNTER_COUNTER
Access-Challenges	The number of RADIUS Access-Challenge packets sent to this client.	PERF_COUNTER_RAWCOUNT
Access-Challenges/sec	The number of RADIUS Access-Challenge packets per second sent to this client.	PERF_COUNTER_COUNTER
Access-Rejects	The number of RADIUS Access-Reject packets sent to this client.	PERF_COUNTER_RAWCOUNT
Access-Rejects/sec	The number of RADIUS Access-Reject packets per second sent to this client.	PERF_COUNTER_COUNTER
Access-Requests	The number of packets received on the authentication port from this client.	PERF_COUNTER_RAWCOUNT
Access-Requests/sec	The number of packets per second received on the authentication port from this client.	PERF_COUNTER_COUNTER
Bad Authenticators	The number of packets that contained invalid signature attributes.	PERF_COUNTER_RAWCOUNT
Bad Authenticators/sec	The number of packets per second that contained invalid signature attributes.	PERF_COUNTER_COUNTER
Dropped Packets	The number of incoming packets silently discarded for a reason other than being malformed, bad authenticators, or unknown types.	PERF_COUNTER_RAWCOUNT
Dropped Packets/sec	The number of incoming packets per second silently discarded for a reason other than being malformed, bad authenticators, or unknown types.	PERF_COUNTER_COUNTER
Duplicate Access-Requests	The number of duplicate RADIUS Access-Request packets received from this client.	PERF_COUNTER_RAWCOUNT
Duplicate Access-Requests/sec	The number of duplicate RADIUS Access-Request packets per second received from this client.	PERF_COUNTER_COUNTER
Malformed Packets	The number of malformed packets received. Bad authenticators or unknown types are not included.	PERF_COUNTER_RAWCOUNT
Malformed Packets/sec	The number of malformed packets per second received. Bad authenticators or unknown types are not included.	PERF_COUNTER_COUNTER
Packets Received	The number of packets received.	PERF_COUNTER_RAWCOUNT
Packets Received/sec	The number of packets per second received.	PERF_COUNTER_COUNTER
Packets Sent	The number of packets sent.	PERF_COUNTER_RAWCOUNT
Packets Sent/sec	The number of packets sent per second.	PERF_COUNTER_COUNTER
Unknown Type	The number of packets of unknown type that were received.	PERF_COUNTER_RAWCOUNT
Unknown Type/sec	The number of packets per second of unknown type that were received.	PERF_COUNTER_COUNTER

IAS Authentication Server Object

The IAS Authentication Server performance object is installed by IAS. IAS uses the RADIUS protocol to perform remote authentication. IAS performance objects report activity for servers or clients, including user authentication, authorization, and accounting.

When selecting counters for this object, note that each client represents a separate instance.

Table 11 Counters for the IAS Accounting Server Object

Counter name	Description	Counter type
Access-Accepts	Shows the number of RADIUS Access-Accept packets sent to this client.	PERF_COUNTER_RAWCOUNT
Access-Accepts/sec	Shows the rate, in seconds, at which RADIUS Access-Accept packets were sent to this client.	PERF_COUNTER_COUNTER
Access-Challenges	Shows the number of Access-Challenge packets sent to this client.	PERF_COUNTER_RAWCOUNT
Access-Challenges/sec	Shows the rate at which Access-Challenge messages are being processed.	PERF_COUNTER_COUNTER
Access-Rejects	Shows the number of RADIUS Access-Reject packets sent to this client.	PERF_COUNTER_RAWCOUNT
Access-Rejects/sec	Shows the rate at which Access-Reject messages are being processed.	PERF_COUNTER_COUNTER
Access-Requests	Shows the number of packets that were received on the authentication port from this client.	PERF_COUNTER_RAWCOUNT
Access-Requests/sec.	Shows the rate, in seconds, at which packets were received on an authentication port from this client.	PERF_COUNTER_COUNTER
Bad Authenticators	Shows the total number of packets that contained invalid signature attributes.	PERF_COUNTER_RAWCOUNT
Bad Authenticators/sec	Shows the rate in seconds at which packets that contained invalid signature attributes were received.	PERF_COUNTER_COUNTER
Dropped Packets	Shows the number of incoming packets dropped for reasons other than being malformed, bad authenticators, or unknown types.	PERF_COUNTER_RAWCOUNT
Dropped Packets/sec	Shows the rate, in seconds, at which packets were dropped for reasons other than being malformed, bad authenticators, or of an unknown type.	PERF_COUNTER_COUNTER
Duplicate Access-Requests	Shows the number of duplicate RADIUS Access-Request packets received from this client.	PERF_COUNTER_RAWCOUNT
Duplicate Access-Requests/sec	Shows the rate, in seconds, at which duplicate RADIUS Access-Request packets were received from this client.	PERF_COUNTER_COUNTER
Invalid Requests	Shows the number of packets received from unknown addresses.	PERF_COUNTER_RAWCOUNT
Invalid Requests/sec	Shows the rate, in seconds, at which packets were received from unknown addresses.	PERF_COUNTER_COUNTER
Malformed Packets	Shows the number of malformed packets received. Bad authenticators or unknown types are not included.	PERF_COUNTER_RAWCOUNT
Malformed Packets/sec	Shows the rate, in seconds, at which malformed packets were received. Bad authenticators or unknown types are not included.	PERF_COUNTER_COUNTER
Packets Received	Shows the number of packets received.	PERF_COUNTER_RAWCOUNT
Packets Received/sec	Shows the rate, in seconds, at which packets were received.	PERF_COUNTER_COUNTER
Packets Sent	Shows the number of packets sent.	PERF_COUNTER_RAWCOUNT
Packets Sent/sec	Shows the rate, in seconds, at which packets were sent.	PERF_COUNTER_COUNTER
Server Reset Time	Shows the time elapsed, in hundredths of a second, since the server configuration was reset.	PERF_COUNTER_RAWCOUNT
Server Up Time	Shows the time elapsed, in hundredths of a second, since the server process was started.	PERF_COUNTER_RAWCOUNT
Unknown Type	Shows the number of packets received that were of an unknown type.	PERF_COUNTER_RAWCOUNT
Unknown Type/sec	Shows the rate, in seconds, at which packets of an unknown type were received.	PERF_COUNTER_COUNTER

SNMP MIBS

Windows 2000 supports objects in the following MIBs:

• RADIUS Accounting Server MIB: RFC 2621.

• RADIUS Accounting Client MIB: RFC 2620.

• RADIUS Authentication Server MIB: RFC 2919.

• RADIUS Authentication Client MIB: RFC 2618.

SNMP MIB support for RADIUS objects is installed when IAS is installed. For details about the objects within each MIB, see the appropriate RFC.

Summary

This paper discussed Windows 2000 Internet Authentication Service (IAS). IAS is the Microsoft implementation of a RADIUS server. IAS provides an industry standard method to authenticate, authorize, and provide accounting for any device acting as a RADIUS client. IAS can be used in a variety of scenarios including centralized authentication and accounting for an organization's remote access infrastructure, outsourced corporate access using third-party dial-up service providers, and centralized authentication and accounting for an Internet service provider (ISP). IAS can scale to suit almost any organization's authentication and accounting requirements using either faster computers or multiple computers using an IP load-balancing scheme.

For More Information

For the latest information on Windows 2000 Server, check out our Web site at https://www.microsoft.com/windows2000.