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.

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.
  
  

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.

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.

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.

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.
  
  

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.
  
  

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.
  
  

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

Outsourced Dial-Up and Wireless Network Access

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.

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.

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.

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.

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.

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.
  
  

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.

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.

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

Authenticating switch support

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.
  
  

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

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.

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.
  
  

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.
  
  

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.

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.

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.

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.

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.