Share via

What Is IAS?

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

 

In this section

  • Components of an IAS infrastructure

  • IAS Features

  • New IAS Features Supported by Microsoft Windows Server 2003

Internet Authentication Service (IAS) is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy. RADIUS is an industry standard for the client-server protocol. For more information about RADIUS, see RFC 2865, “Remote Authentication Dial-In User Service (RADIUS)” and RFC 2866, “RADIUS Accounting.” For information about standards that apply to IAS in Windows Server 2003, see RFC 2868, “RADIUS Attributes for Tunnel Protocol Support” and RFC 2869, “RADIUS Extensions.”

As a RADIUS server, IAS performs centralized connection authentication, authorization, accounting, and auditing (AAAA) for many types of network access including wireless, authenticating switch, and remote access dial-up and virtual private network (VPN) connections.

As a RADIUS proxy, IAS provides the routing of RADIUS messages between RADIUS clients (access servers), RADIUS proxies, and the RADIUS servers that perform AAAA for the connection attempt. When used as a RADIUS proxy, IAS is a central switching or routing point through which RADIUS access and accounting messages flow. Using IAS, you can centrally manage AAAA for organizations of all sizes, including small businesses, medium organizations, enterprise-level organizations, and Internet Service Providers (ISPs). IAS provides you with the ability to secure and manage network access across a variety of network access scenarios such as the following:

  • Employees connecting to your organization network through dial-up, VPN, wireless, and wired connections, using a variety of devices, including organization computers, personal digital assistants, and non-domain member computers, such as employee-owned devices.

  • Employees connecting to other networks, including the Internet and business partner networks.

  • Business partners connecting to your organization network.

IAS enables the use of a heterogeneous or homogenous set of wireless, switch, remote access, or VPN equipment. IAS also supports the use of both certificate-based and password-based authentication protocols, and provides three forms of logging, including the ability to leverage the advantages of logging to a relational database with Structured Query Language (SQL) Server logging. In addition, you can outsource your remote-access infrastructure to a service provider while retaining control over user authentication, authorization, and accounting, thereby keeping sensitive organization information private and more secure on your network.

When an IAS server is a member of an Active Directory domain, IAS uses the Microsoft Active Directory directory service as its user account database and is part of a single sign-on solution. With single sign-on, users supply account credentials (user name and password or a certificate) only once during the authentication and authorization process; these credentials are then used to log on to an Active Directory domain and for network access control (authenticating and authorizing access to a network).

When IAS remote access policies are configured with Protected Extensible Authentication Protocol (PEAP) and a PEAP type as the authentication method for wireless connections, PEAP fast reconnect allows users to roam with portable devices between wireless access points without re-entering user account credentials each time the portable device associates with a new wireless access point.

You can configure IAS in Windows Server 2003, Standard Edition, with a maximum of 50 RADIUS clients and a maximum of 2 remote RADIUS server groups. You can define a RADIUS client using a fully qualified domain name or an IP address, but you cannot define groups of RADIUS clients by specifying an IP address range. If the fully qualified domain name of a RADIUS client resolves to multiple IP addresses, the IAS server uses the first IP address returned in the Domain Name System (DNS) query. With IAS in Microsoft Windows Server 2003, Enterprise Edition, and Microsoft Windows Server 2003, Datacenter Edition, you can configure an unlimited number of RADIUS clients and remote RADIUS server groups. In addition, you can configure RADIUS clients by specifying an IP address range. IAS is not included on computers running the Windows Server 2003, Web Edition, operating system.

Components of an IAS infrastructure

There are five components to an IAS or RADIUS infrastructure: access clients, access servers (RADIUS clients), IAS servers (RADIUS servers), IAS proxies (RADIUS proxies), and user account databases. A RADIUS infrastructure is used to perform authentication, authorization and accounting of user network access attempts. Authentication is the process of verifying the credentials of the users attempting to connect to a network. The authorization process determines whether users have permission to connect to the network, and the conditions under which permission has been granted. Accounting is an option that provides record keeping of successful or failed connection attempts.

The following figure, “Components of an IAS Infrastructure,” illustrates the relationships between the five components of an IAS infrastructure.

Components of an IAS Infrastructure

Components of an IAS Infrastructure

Access Clients

An access client is a device that requires some level of access to a larger network. Examples of access clients are dial-up or VPN clients, wireless clients, or LAN clients connected to an authenticating switch.

Access Servers Used as RADIUS Clients

An access server is a device that provides some level of access to a larger network. An access server using a RADIUS infrastructure is also a RADIUS client, sending connection requests and accounting messages to a RADIUS server. Examples of access servers follow:

  • NASs that provide remote access connectivity to an organization network or the Internet. An example is a computer running Windows Server 2003 or Microsoft Windows 2000 that also runs the Routing and Remote Access service, providing either traditional dial-up or VPN remote access to an organization’s intranet.

  • Wireless access points that provide physical layer access to an organization’s network, using wireless-based transmission and reception technologies.

  • Switches that provide physical layer access to an organization’s network, using traditional LAN technologies such as Ethernet.

IAS Servers Used as RADIUS Servers

An IAS or RADIUS server is a device that receives and processes connection requests or accounting messages sent by RADIUS clients or RADIUS proxies. In the case of connection requests, the RADIUS server processes the list of RADIUS attributes in the connection request. Based on a set of rules and the information in the user account database, the RADIUS server authenticates and authorizes the connection and sends back either an Access-Accept message or an Access-Reject message. The Access-Accept message can contain connection restrictions that the access server implements the duration of the connection.

IAS Proxies and RADIUS Proxies

An IAS or RADIUS proxy is a device that forwards or routes RADIUS connection requests and accounting messages between RADIUS clients (and RADIUS proxies) and RADIUS servers (or RADIUS proxies). The RADIUS proxy uses information within the RADIUS message, such as the User-Name or Called-Station-ID RADIUS attributes, to route the RADIUS message to the appropriate RADIUS server.

A RADIUS proxy can be used as a forwarding point for RADIUS messages when the authentication, authorization, and accounting must occur at multiple RADIUS servers in different organizations.

User Accounts Databases

The user account database is the list of user accounts and their properties that can be checked by a RADIUS server to verify authentication credentials and user account properties containing authorization and connection parameter information.

The user account databases that IAS can use are the local Security Accounts Manager (SAM), a Microsoft Windows NT Server 4.0 domain, or the Active Directory directory service and user accounts database included with Windows Server 2003 and Windows 2000. For Active Directory, IAS can provide authentication and authorization for user or computer accounts in the domain in which the IAS server is a member, two-way trusted domains, and trusted forests with domain controllers running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition.

If the user accounts for authentication reside in a different type of database, IAS can be configured as a RADIUS proxy to forward the authentication request to a RADIUS server that does have access to the user account database. Different databases for Active Directory include untrusted forests, untrusted domains, or one-way trusted domains.

IAS Features

IAS in Windows Server 2003 has an extensive set of features. The core IAS features were introduced in Windows 2000 Server operating system; and new IAS features have been added to Windows Server 2003.

Core IAS Features

Core IAS features offer advantages such as multiple authentication methods and centralized administration for access servers*.*

Authentication Methods

The protection of user account credentials during the authentication of users attempting connections is an important security concern. IAS supports a variety of authentication protocols and allows you to use arbitrary authentication methods to meet your requirements for authentication.

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

  • EAP and PEAP. An Internet standards-based infrastructure that allows the addition of arbitrary authentication methods, such as smart cards, certificates, one-time passwords, and token cards. A specific authentication method that uses the EAP infrastructure is an EAP type. IAS includes support for EAP-Message Digest 5 (MD5) and EAP-Transport Layer Security (EAP-TLS), as well as PEAP-MS-CHAP v2 and PEAP-TLS.

Various Authorization Methods

IAS supports a number of authorization methods and allows you to add custom methods that meet your authorization requirements. The supported authorization methods are:

  • Dialed Number Identification Service (DNIS). The authorization of a connection attempt that is based on the number called. DNIS supplies the number that was called to the call receiver and is provided by most standard telephone companies.

  • Automatic Number Identification/Calling Line Identification (ANI/CLI). The authorization of a connection attempt that is based on the phone number of the caller. ANI/CLI service supplies the number of the caller to the call receiver and is provided by most standard telephone companies.

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

Centralized user Authentication and Authorization

To authenticate a connection request, IAS validates the connection credentials against user and computer accounts in the local SAM, a Windows NT Server 4.0 domain, or an Active Directory domain. For an Active Directory domain, IAS supports the use of Active Directory user principal names and universal groups.

To authorize a connection request, IAS uses the dial-in properties of the user account that correspond to both the connection credentials and remote access policies. One of the elements of authorization is remote access permission, which can be set both on the user or computer account and the remote access policy. Although it is relatively easy to manage remote access permission for each user account, this approach does not scale well as an organization grows. Remote access policies provide a more powerful and flexible way to manage remote access permission.

With remote access policies, you can authorize network access based on various conditions, including:

  • User account membership in a group.

  • The time of day or day of the week.

  • The type of media by which the user is connecting (for example, wireless, Ethernet switch, modem, or VPN).

  • The phone number that the user calls.

  • The access server from which the request arrives.

By configuring profile settings on remote access policies, you can control many connection parameters, including:

  • The use of specific authentication methods.

  • The idle time-out.

  • The maximum time of a single session.

  • The number of links in a multilink session.

  • The use of encryption and its strength.

  • The use of packet filters to control what the remote access user can access when connected to the network. For example, you can use filters to control which IP addresses, hosts, and ports the user is allowed to use in sending or receiving packets.

  • The creation of a compulsory tunnel that forces all packets from that connection to be securely tunneled through the Internet and then terminated in a private network.

  • The virtual local area network identifier for wireless or Ethernet connections.

Heterogeneous Access Servers

IAS supports NASs that are compliant with RADIUS RFCs 2865 and 2866. In addition to dial-up access servers, IAS also supports the following:

  • Wireless access points. By using remote access policies and the Wireless-IEEE 802.11 port type condition, IAS can be used as a RADIUS server for wireless access points that use RADIUS for authentication and authorization of wireless nodes.

  • Authenticating switches. By using remote access policies and the Ethernet port type condition, IAS can be used as a RADIUS server for Ethernet network switches that use RADIUS for authentication and authorization of switch nodes.

  • Computers running Windows Server 2003 or Windows 2000 and the Routing and Remote Access service. A computer running the Routing and Remote Access service can be configured as a dial-up server, a VPN server, or a VPN router for dial-up or persistent site-to-site (also known as router-to-router) connections between networks. IAS and the Routing and Remote Access service use the same remote access policies and log files. This integration provides a consistent implementation for both IAS and the Routing and Remote Access service. It enables you to deploy Routing and Remote Access at small sites without the requirement of a separate, centralized IAS server. It also provides the ability to scale to a centralized remote access management model whenever you have multiple Routing and Remote Access servers in your organization. IAS, in conjunction with Routing and 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 and large site can be exported to the independent Routing and Remote Access server in a small site.

Note

  • A site-to-site VPN connection is typically used to connect remote offices together when both routers are connected to the Internet by permanent wide area network (WAN) links, such as T1 or Frame Relay. In this configuration, the VPN connection is always available. However, when a permanent WAN link is not possible or practical, you can configure a dial-up site-to-site VPN connection.
Centralized Administration for All Access Servers

Support for the RADIUS standard allows IAS to control connection parameters for any NAS that implements RADIUS. The RADIUS standard also allows individual access server vendors to create proprietary extensions called vendor-specific attributes (VSAs). IAS has incorporated the extensions from a number of vendors in its dictionary of attributes. In circumstances where an attribute is not included in the IAS dictionary of attributes, additional VSAs can be created and added to the profile of individual remote access policies.

Outsourced Dial-Up and Wireless Network Access

Outsourced dialing (also known as wholesale dialing) provides a contract between an organization and an ISP. The ISP allows employees of the organization to connect to its network before the VPN tunnel to the private network of the organization is established. When an employee of the organization connects to the network access server of the ISP, the authentication and records of usage are forwarded to the IAS server at the organization. The IAS server enables the organization to control user authentication, track usage, and determine which employees are allowed to access the network of the ISP.

The advantages of outsourced dialing are the potential financial and administrative savings. By using an ISP’s hardware and wide area network (WAN) links instead of purchasing and installing your own, you might save a great deal on infrastructure costs. If traveling or remotely located employees dial in to an ISP that has worldwide connections, making a local rather than a long distance connection, you might significantly decrease your long-distance phone bill. And by moving support requirements to the provider, you might eliminate administrative costs.

You can also outsource wireless access. A vendor can provide wireless access in a remote location and use IAS as a RADIUS proxy to forward your employee connection requests to a RADIUS server on your network for authentication and authorization.

Centralized, Scalable Auditing and Usage Accounting

You can use IAS as a RADIUS server to centralize the accounting data from many NASs, and you can use IAS SQL Server logging to further centralize accounting data by configuring multiple IAS servers to log to the same database on a computer running SQL Server 2000. Support for the RADIUS standard allows IAS to collect the usage (accounting) records sent by many access servers configured as RADIUS clients to the IAS server. 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 text-based log-file format that can be directly imported into a database, as well as SQL Server logging, where IAS passes accounting data to the SQL Server Desktop Engine (MSDE 2000) or SQL Server 2000 in XML format. After the accounting data in the database is collected, it can be queried and analyzed by non-Microsoft data-analysis software.

IAS Integration with the Routing and Remote Access Service

The Routing and Remote Access service can be 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 achieve the optimum level of integration in Windows Server 2003 or Windows 2000 environments and to take advantage of centralized remote access policies.

For example, in a small network environment or 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 of different types of access servers deployed worldwide, centralized authentication and accounting using IAS can be beneficial. However, if a small remote office is configured with a low bandwidth connection to the global organization with the centralized IAS server, the Routing and Remote Access service servers at the branch office can be configured with Windows authentication and accounting and the remote access policy configuration can be copied from a central location to the remote access servers of the remote office.

IAS and the Routing and Remote Access service share the same remote access policies and authentication capabilities. When the Routing and Remote Access service is configured for Windows authentication, local remote access policies are used, and logging is recorded in a local file by default. You can also configure the Routing and Remote Access service to log accounting data to a database on a computer running Microsoft SQL Server 2000.

When the Routing and Remote Access service is configured as a RADIUS client to an IAS server, the remote access policies of the IAS server are used and logging is recorded in a local file on the IAS server or, when IAS SQL Server logging is configured on the IAS server, to a SQL Server 2000 database.

Because the policies within IAS at a central large site can be exported to the independent remote access server in a small site, a consistent implementation across IAS and the Routing and Remote Access service is provided. It allows you to deploy the Routing and Remote Access service at 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 the need arises to do so. 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.

Graphical User Interface

You can configure IAS by using the IAS Microsoft Management Console (MMC) snap-in, which enables you to configure local or remote IAS servers. You can add multiple IAS servers to a single snap-in, providing ease of management for many servers using one interface. If you install the Windows Server 2003 Administrative Tools Pack on a computer running Microsoft Windows XP Professional, you can use the IAS snap-in from the client computer to manage your IAS servers.

Remote Monitoring

You can monitor IAS by using Windows Server 2003–based tools, such as Event Viewer, Performance Logs and Alerts, and Simple Network Management Protocol (SNMP). You can also use Network Monitor to capture RADIUS messages for detailed traffic analysis and troubleshooting.

Scalable Configurations

You can scale IAS to network configurations of varying size, from stand-alone servers for small networks to large corporate and ISP networks. As your network grows, you can add access servers, IAS proxy servers, and IAS servers to scale up and out, exporting and importing server configurations to minimize administrative overhead. IAS logging to SQL Server databases also provides the ability to scale the logging of network session information.

Import and Export of Configuration to Manage Multiple IAS Servers

An IAS server configuration can be exported in part or total by using the Netsh commands for network access authentication, authorization, accounting, and auditing. For example, you can export the full configuration of an IAS server using the netsh aaaa show config command at the command prompt, or you can export only the remote access policies of the server using the netsh aaaa show remote_acces_policies command.

Note

  • The configuration of IAS servers running operating systems in the Windows 2000 Server family can be imported into products in the Windows Server 2003 family with netsh AAAA commands. The reverse, however, is not possible.

New IAS Features Supported by Windows Server 2003

In response to advancements in the RADIUS protocol and network access technologies, new features have been added to IAS in Windows Server 2003. For example, IAS in Windows Server 2003 provides support for: RADIUS proxy, mapping network authentication and authorization for IAS proxy. Support for IEEE 802.1X wireless and authenticating switches and PEAP for 802.11 wireless clients has also been added.

RADIUS Proxy

In addition to RADIUS server support, Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition provide RADIUS proxy support. With RADIUS proxy support, you can use IAS as a RADIUS message router or forwarder. Based on attributes in the incoming RADIUS message, the RADIUS proxy forwards the message to a specific RADIUS server or client.

You can configure IAS as a RADIUS proxy by using connection request processing and remote RADIUS server groups. Connection request processing is a set of rules that determine how an incoming connection request is processed: It is either authenticated and authorized by the IAS server (when the IAS server is being used as a RADIUS server), or it is forwarded to another RADIUS server for authentication and authorization (when the IAS server is being used as a RADIUS proxy). When IAS is being used as a proxy, it forwards the connection request to a member of a remote RADIUS server group.

By correctly configuring connection request processing rules and remote RADIUS server groups, an IAS server can be used as a RADIUS server for some requests and a RADIUS proxy for others. The IAS proxy also provides the ability to balance RADIUS requests across multiple RADIUS servers, to detect both which RADIUS servers are no longer available and when they become available again.

Mapping Network Authentication and Authorization for IAS Proxy

When you map a user account in a remote user accounts database to a user account in a local user accounts database, the proxy component of IAS can separate the authentication and authorization of connection requests. IAS sends the authentication request to the remote IAS server and processes the authorization request locally. The IAS proxy can forward password-based user credentials to an external RADIUS server for authentication, and perform authorization against a user account in an Active Directory domain and a locally configured remote access policy.

Note

  • Members of a remote RADIUS server group can be IAS servers that authenticate connection requests by using Active Directory or they can be third-party RADIUS servers that can perform authentication by using other user account databases. Regardless of the user accounts database or RADIUS server used with account mapping, authorization is performed on the local IAS proxy.

To configure IAS to split authentication and authorization between two different IAS servers and user accounts databases, you can map the realm portion of a user name to a remote RADIUS server for authentication, even if that RADIUS server is located on another private network.

For example, IAS can authenticate a visitor from a partner organization by using the partner organization RADIUS server and user accounts database. IAS then authorizes access to your network by using connection request policy settings on your IAS server and a Windows user accounts database in an Active Directory domain that is established for visitor accounts.

You can configure the proxy component with the Remote-RADIUS-to-Windows-User-Mapping attribute in the advanced properties of a connection request policy.

IEEE 802.1X Wireless Access Points and Authenticating Switches

IAS provides authentication, authorization, and accounting for connections that use the link-layer standard IEEE 802.1X for wireless and switch access.

Wireless access points

Wireless networking technology has become more widely used since the adoption of wireless industry standards such as IEEE 802.11b, 802.11a, and 802.11g. You can use wireless networking to roam within a building or area and connect automatically to a network when you are within range of a wireless access point beacon.

While providing convenience, wireless networking technologies and wireless access points have the following security risks:

  • Anyone who has a compatible wireless network adapter can gain access to the network.

  • Wireless networking signals use radio waves to send and receive information. Anyone within an appropriate distance to a wireless access point can detect and receive all data sent to and from the wireless access point.

To counter the first security risk, wireless access points must require authentication and authorization of the wireless node before data can be sent to and received from the network to which the wireless access point is attached. To provide their own authentication and authorization, each wireless access point should require a user account database with each user’s account credentials and a set of rules by which authorization is granted.

Because maintaining separate user accounts databases for each wireless access point is difficult to manage, it is recommended that you use wireless access points that function as RADIUS clients, and use the industry standard RADIUS protocol to send connection request and accounting messages to a central RADIUS server. The RADIUS server has access to a user account database and a set of rules for granting authorization. The RADIUS server processes the wireless access point’s connection request and either accepts or rejects the connection request.

To counter the second security risk, the data sent between the wireless nodes and the wireless access points must be encrypted. Therefore, the authentication method that the wireless node uses must allow for the determination of encryption keys that are used to encrypt data.

IAS supports wireless access authentication by means of the following:

  • The use of PEAP with MS-CHAP v2 for secure password-based authentication and fast reconnect when users roam with wireless computers between wireless access points that are configured as RADIUS clients to the same RADIUS server.

  • The use of EAP-TLS to provide certificate-based authentication and the management of encryption keys that are used to encrypt data sent between wireless access points and wireless nodes.

  • The use of the Wireless-IEEE 802.11 and Wireless-Other port types when configuring the NAS-Port-Type condition of remote access policies. By using these port types, you can create a separate remote access policy that contains connection parameters and encryption settings that are specifically designed for wireless nodes.

  • By providing a means to grant guest access for a wireless client that does not have a certificate installed or a set of valid account name/password credentials.

Authenticating switch support

A network switch provides selective filtering of the traffic received on each port of the switch and allows better traffic management by segmenting a network. A typical switch, however, sends and receives packets to any node that is connected to the switch, and does not perform any authentication to verify that the user has permission to access the network. This can be a problem, for example, if switch ports are installed in a conference room. A person from another organization can simply connect a network adapter to the switch port and gain instant access to the network.

To prevent physical layer access to the network, newer switches can be configured to require switch node authentication and authorization before data is sent to or received from the network node that is attached to the switch. To provide its own authentication and authorization, each switch is required to have a user account database. This database contains each users authentication credentials and a set of rules by which authorization is granted. Multiple individual databases are difficult to manage; however, newer switches can serve as a RADIUS client, using the industry-standard RADIUS protocol to send connection requests and accounting messages to a central RADIUS server. The RADIUS server has access to a user account database and a set of rules for granting authorization. The RADIUS server processes the connection request from the switch and either accepts or rejects the request.

Typically, as the data sent to and from the switch node travels on the wire between the switch node and the switch, encryption of the sent data is neither required nor implemented.

IAS supports switch access authentication by the following means:

  • EAP-TLS provides computer or user certificate-based authentication.

  • The NAS-Port-Type condition of remote access policies is configured for the Ethernet port type. By using this port type, you can create a separate remote access policy containing connection parameters that are specifically designed for switch nodes.

Virtual local area network (VLAN) switching is used on the basis of whether or not the switch access client is authenticated.

PEAP for 802.11 Wireless Clients

PEAP provides protection for clients and authenticators (IAS or RADIUS servers) that are using EAP. The next generation of EAP and PEAP uses Transport Layer Security (TLS) to create end-to-end communication between client and authenticator after the identity of the authenticator is verified.

PEAP creates a session key that is used to derive keys for the encryption of authentication traffic between the wireless client and the IAS server. It also provides smooth and efficient roaming between wireless access points that are configured as RADIUS clients on the same IAS server.

You can use PEAP with two different authentication types: PEAP-MS-CHAP v2 or PEAP-TLS. PEAP-MS-CHAP v2 provides secure password authentication for 802.1X wireless and authenticating switch clients. PEAP-MS-CHAP v2 can be used to complement the security of MS-CHAP v2, and it does not require deployment of user or computer certificates on the client computer. A server certificate is required on the IAS server. With PEAP-MS-CHAP v2, you can obtain a server certificate from a third party certification authority, such as Verisign, instead of deploying your own public key infrastructure (PKI).

You can also use PEAP-TLS, which provides strong security by means of a PKI with certificates. A computer certificate installed on the IAS server is used to authenticate the IAS server and a locally-installed computer and user certificate or a smart card on the wireless client is used to authenticate the wireless client. When you use PEAP-TLS, client certificate information is encrypted, providing improved security over the use of EAP-TLS without PEAP.

Note

  • When you deploy both PEAP and EAP unprotected by PEAP on the same network, do not use the same EAP authentication type with and without PEAP for the same network access type. For example, if you deploy PEAP-TLS on your wireless network, do not also deploy EAP-TLS. Deploying authentication methods with the same type (one with and the other without the protection of PEAP) for the same network access type creates a security issue.

Enhanced EAP Configuration for Remote Access Policies

In Microsoft Windows 2000 Server, you can select only a single EAP type when configuring the kind of authentication allowed by a remote access policy. All connections matching the conditions of the policy must use this single EAP type, which is selected in the policy profile settings. Additionally, the configuration of an EAP type is global for all of the remote access policies configured on the IAS server. This can cause problems when you want to either individually configure the properties for EAP types for each policy or select multiple EAP types by group or for a specific kind of network connection.

In Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, these limitations are removed for IAS.

For example, you can select different computer certificates for VPN connections and EAP-TLS authentication for wireless connections, or you can select multiple EAP types for wireless connections in the circumstance where some of your wireless clients use EAP-TLS authentication, and some of them use PEAP-MS-CHAP v2.

Network Access Quarantine Control

Network Access Quarantine Control provides phased network access, which restricts remote clients to quarantine mode until each client is either verified as meeting or configured according to organization network access policy. Quarantine mode is applied by a VPN server running Windows Server 2003 and the Routing and Remote Access service. Quarantine mode is created using a session timer, or an IP filter, or both. The IP filter and session timer are configured in a remote access policy in the IAS snap-in. After the client computer configuration is verified as meeting organization network policy by an administrator-provided script that runs on the client, the quarantine restrictions are removed from the to the connection. To deploy this feature, you must use Connection Manager Administration Kit, the Routing and Remote Access service, and additional components deployed on clients and access servers.

Logging to a SQL Server Database

You can use Microsoft SQL Server 2000 to log IAS accounting information, such as user authentication requests, accounting requests, and periodic data, to a database that warehouses data from multiple IAS servers. To diminish cost and increase logging performance, you can install the Microsoft SQL Server Desktop Engine (MSDE 2000) on each IAS server, and then periodically publish records from the MSDE 2000 database on each IAS server to the central database on the SQL Server, providing comprehensive data views for troubleshooting network access authentication and report creation.

Ignoring the Dial-In Properties of User Accounts

To ignore the dial-in properties of user accounts, you can configure a RADIUS attribute on the profile properties of a remote access policy. The dial-in properties of the user account contain the following properties:

  • Remote access permission

  • Caller-ID

  • Callback options

  • Static IP address

  • Static routes

To support multiple types of connections for which IAS provides authentication and authorization, you might need to disable the processing of user account dial-in properties. This can be done to support scenarios in which specific dial-in properties are not required.

For example, the caller-ID, callback, static IP address, and static routes properties are designed for a client that is dialing into a NAS, not for wireless access points. A wireless access point that receives these settings in a RADIUS message might not be able to process them, which could cause the wireless client to be disconnected. When IAS provides authentication and authorization for users who are both dialing in and accessing the organization network by means of wireless technology, the dial-in properties must be configured to support either dial-in connections (by setting dial-in properties) or wireless connections (by not setting dial-in properties).

You can use IAS to enable dial-in properties processing for the user account in some scenarios (such as dial-up connections) and to disable dial-in properties processing for user account dial-in properties in other scenarios (such as wireless and authenticating switch). This is accomplished by configuring the Ignore-User-Dialin-Properties attribute on the Advanced tab of the profile settings for a remote access policy.

The Ignore-User-Dialin-Properties attribute is set to the following options:

  • To enable user account dial-in properties processing, delete the Ignore-User-Dialin-Properties attribute or set it to False. For example, for a remote access policy that is designed for dial-in connections, no additional configuration is required.

  • To disable user account dial-in properties processing, set the Ignore-User-Dialin-Properties attribute to the value of True. For example, this is set for the remote access policy that is designed for wireless or authenticating switch connections. When the dial-in properties of the user account are ignored, remote access permission is determined by the remote access permission setting in the remote access policy.

You can also use this attribute to manage network access control by means of groups and the remote access permissions on the remote access policy. By setting the Ignore-User-Dialin-Properties attribute to the value of True, the remote access permission on the user account is ignored. The disadvantage to using the Ignore-User-Dialin-Properties attribute in this way is that you cannot use the additional dial-in properties of caller-ID, callback, static IP address, and static routes.

Note

  • The Ignore-User-Dialin-Properties attribute disables the use of all dial-in properties for the user account. Specific dial-in properties cannot be selectively disabled.

Configuring RADIUS Clients by IP Address Range

For IAS in Windows 2000, you must specify a RADIUS client by IP address or by DNS name. In addition, you must configure each RADIUS client separately, even if you have a number of RADIUS clients on the same subnet. While this is not an issue for typical dial-in or VPN access server configurations, wireless access points are frequently deployed in large numbers on the same subnet, and configuring each wireless access point as a RADIUS client at the RADIUS server can be time consuming.

In Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition, you can use IAS to specify a group of RADIUS clients by using an IP address range. This simplifies the configuration of multiple RADIUS clients that are on the same network segment, or that are configured on a virtual local area network (VLAN). When you configure RADIUS clients by IP address range, all RADIUS clients in the range must be identically configured and use the same shared secret.

When you configure RADIUS clients using this method, the IP address range for RADIUS clients is expressed in the network prefix length notation w.x.y.z/p, where w.x.y.z is the dotted decimal notation of the address prefix and p is the prefix length (the number of high order bits that define the network prefix). This is also known as Classless Inter-Domain Routing notation. An example is 192.168.21.0/24. To convert from subnet mask notation to network prefix length notation, p is the number of high-order bits set to one in the subnet mask.

Note

  • You cannot configure RADIUS clients by using the IP address range in IAS for Windows Server 2003, Standard Edition.

Computer Authentication

In Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, Active Directory and IAS support the authentication of computer accounts by using standard user authentication methods, such as PPP. This allows a computer and its computer certificate to be authenticated for wireless or authenticating switch access clients.

Checking User Certificate Purposes

To enforce the use of specific types of user certificates for specific connection types, you can configure IAS to check the purposes, also called object identifiers (OIDs), of certificates in their Enhanced Key Usage (EKU) extensions when the client computer supplies the certificate as proof of identity.

When PEAP-TLS or EAP-TLS are configured as authentication methods for a remote access policy in IAS, the access client can send a smart card certificate or a user certificate from the client computer certificate store during the authentication process.

Because smart card certificates are more secure than certificates from the client computer certificate store, you might want to ensure that remote access VPN connections use a smart card certificate for user authentication instead of a locally-installed user certificate. In this case, you can configure a remote access policy to require that the user certificate EKU extensions contain the Smart Card Logon purpose object identifier (1.3.6.1.4.1.311.20.2.2). When the VPN client offers the smart card certificate for user authentication, the IAS server checks the EKU extensions according to remote access policy. Because the Smart Card Logon object identifier is present in the VPN client certificate, authentication succeeds.

You can configure more than one object identifier that is required to be present in the user certificate, which the access client offers to IAS. To configure more than one object identifier, use the Allow certificates with these OIDs attribute on the Advanced tab in the properties of a remote access policy profile. No required OIDs are specified by default.

Improved Support for Attribute Manipulation

In Windows 2000, you can use IAS to manipulate the contents of the User-Name RADIUS attribute. Using connection request policies in IAS for Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, you can manipulate the User-Name, Called-Station-ID, and Calling-Station-ID RADIUS attributes.

Authentication Type Remote Access Policy Condition

You can create remote access policies by using the Authentication Type condition. You can use Authentication Type to specify connection constraints that are based on the authentication protocol or method that is used for authentication by the access client.

Improved Support for the Class Attribute

In Windows 2000, IAS generates a value for the Class attribute and appends it to the existing value of the Class attribute received in the RADIUS request message by NASs that send the Class attribute. The result is the Class attribute in the RADIUS response message. In Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition:

  • You can disable the automatic generation of a value for the Class attribute by using Generate-Class-Attribute on the Advanced tab in the properties of a remote access policy profile. Automatic generation of a value for the Class attribute is disabled by default.

  • Instead of appending the generated value of the Class attribute to the existing Class attribute, IAS creates a separate Class attribute. The RADIUS response message contains both the original Class attribute and the second Class attribute that IAS generates.

Note

  • To provide the best session correlation for applications that query the accounting log, it is recommended that you use NASs that are capable of sending the Class attribute.