New features for IAS
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
New features for IAS
The following are new features for IAS in Microsoft® Windows Server® 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition:
Support for RADIUS proxy
Support for mapping network authentication and authorization for IAS proxy
Support for IEEE 802.1x wireless and authenticating switches
Support for Protected Extensible Authentication Protocol (PEAP) for 802.11 wireless clients
Enhanced EAP configuration for remote access policies
Support for IAS Network Access Quarantine Control
Support for logging to an XML-compliant SQL server database
Ignoring the dial-in properties of user accounts
Support for configuring RADIUS clients by IP address range
Support for computer authentication
Support for checking user certificate purposes
Improved attribute manipulation
Support for the Authentication Type remote access policy condition
Improved support for the Class attribute
Each of these new features is described below.
Note
- 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 DNS query. With IAS in Windows Server 2003, Enterprise Edition, and 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.
Support for RADIUS proxy
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition include RADIUS proxy support in addition to RADIUS server 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.
IAS implements RADIUS proxy support through 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. For more information about how RADIUS proxies are used and when to use IAS as a RADIUS proxy, see IAS as a RADIUS proxy.
For more information about configuring IAS as a RADIUS proxy, see Deploying IAS as a RADIUS Proxy and Checklist: Configuring IAS to forward requests.
Support for mapping network authentication and authorization for IAS proxy
The proxy component of IAS supports the ability to separate the authentication and authorization of connection requests from access servers. 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. Alternate user authentication databases can be used but connection authorization and restrictions are still determined through local administration.
For example, a visitor from a partner company can be authenticated by using the partner company RADIUS server and user database. Authorization to access your network is accomplished based on connection request policy settings on your IAS server and a Windows account user 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.
For more information, see Mapping network authentication and authorization and Connection request policies.
Support for IEEE 802.1x wireless 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 point support
Wireless networking technology has become more widely used since the adoption of wireless industry standards such as IEEE 802.11 and 802.11b. You can use wireless networking to roam within a building or area and connect automatically to a network when you are in the vicinity of a wireless access point.
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 that is attached to the wireless access point. To provide their own authentication and authorization, each wireless access point should require a user account database with each user's authentication credentials and a set of rules by which authorization is granted. Because this is difficult to manage, some wireless access points are RADIUS clients that 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. Because of this, the authentication method that is used by the wireless node must allow for the determination of encryption keys that are used to encrypt data.
IAS supports wireless access authentication through the following:
The use of Extensible Authentication Protocol-Transport Level Security (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 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.
For more information about configuring IAS for wireless access authentication, see Checklist: Configuring the IAS server and wireless access points for wireless access and Wireless access.
For an example of a remote access policy for wireless clients, see Wireless access example.
Authenticating switch support
Network switches are a commonly used technology. 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. This can be a problem for switch ports in a conference room within an organization. A person from another organization can simply connect their 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 can be sent to and received from the network that is attached to the switch. To provide their own authentication and authorization, each switch is required to have a user account database with each user's authentication credentials and a set of rules by which authorization is granted. Because this is difficult to manage, newer switches can be RADIUS clients, using 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 switch's connection request and either grants the connection request or rejects it.
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 typically implemented.
IAS supports switch access authentication through the following:
EAP-TLS is used to provide computer or user certificate-based authentication.
The Ethernet port type is used when configuring the NAS-Port-Type condition of remote access policies. 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.
For more information about configuring IAS for switch access authentication, see Checklist: Configuring the IAS server for authenticated switch access and Ethernet switch access.
Support for Protected Extensible Authentication Protocol (PEAP) for 802.11 wireless clients
Protected Extensible Authentication Protocol (PEAP) provides protection for clients and authenticators (IAS or RADIUS servers) that are using EAP. The next generation of EAP, PEAP uses Transport Level 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 data traffic between the wireless client and the wireless access point. 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: EAP-MS-CHAPv2 or EAP-TLS. PEAP with EAP-MS-CHAPv2 (also known as PEAP-EAP-MS-CHAPv2), provides secure password authentication for wireless and authenticated switch clients. PEAP-EAP-MS-CHAPv2 can be used to complement the security of MS-CHAPv2 and does not require deployment of user or computer certificates. You can also use PEAP with EAP-TLS (also known as PEAP-EAP-TLS), which provides strong security through a public key infrastructure (PKI) with certificates, which is used for server authentication, and either smart cards or certificates for client and user authentication. When you use PEAP-EAP-TLS, client certificate information is encrypted, providing improved security over the use of EAP-TLS without PEAP.
The following table shows the strengths of PEAP-EAP-MS-CHAPv2 and how it compares to MS-CHAPv2:
| Feature/function | MS-CHAPv2 | PEAP-EAP-MS-CHAPv2 |
|---|---|---|
Provides client authentication using passwords |
Yes |
Yes |
Ensures that the server has access to credentials |
Yes |
Yes |
Authenticates the server |
No |
Yes |
Prevents wireless access point spoofing |
No |
Yes |
Prevents an unauthorized server from negotiating the least secure authentication method |
No |
Yes |
Uses TLS keys generated with a public key |
No |
Yes |
Provides end-to-end encryption |
No |
Yes |
Prevents dictionary or brute force attacks |
No |
Yes |
Prevents replay |
No |
Yes |
Allows chaining of authentication methods |
No |
Yes |
Requires client trust of certificates provided by the server |
No |
Yes |
For more information, see PEAP.
Enhanced EAP configuration for remote access policies
In Microsoft Windows 2000 Server, you can select only a single EAP type for 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 with EAP-MS-CHAPv2.
For more information, see Configure PEAP and EAP methods, PEAP, and EAP.
Support for IAS Network Access Quarantine Control
IAS Network Access Quarantine Control provides phased network access, which restricts the access of remote clients to quarantine mode until each client is either verified as meeting or configured according to organization network access policy. After the client computer configuration is verified as meeting organization network policy, the quarantine restrictions, which consist of Quarantine IP-Filters and Session Timers, are removed and standard remote access policy is applied to the connection.
For more information, see IAS Network Access Quarantine Control.
Support for logging to an XML-compliant SQL server database
You can use an XML-compliant database, such as Microsoft SQL server™ 2000, to log user authentication and accounting requests, which are received from one or more access servers, to a central data source. Log data is passed from IAS to a procedure stored in a database that supports both structured query language (SQL) and extensible markup language (XML).
For more information, see SQL Server database logging.
Ignoring the dial-in properties of user accounts
You can configure a RADIUS attribute on the profile properties of a remote access policy to ignore the dial-in properties of user accounts. The dial-in properties of the user account contain the following:
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, it might be necessary 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 network access server (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 through 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-in) 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. For more information, see Add RADIUS attributes to a remote access policy.
The Ignore-User-Dialin-Properties attribute is set to the following:
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 through groups and the remote access permission 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.
For more information about setting advanced attributes, see Add RADIUS attributes to a remote access policy.
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.
Support for configuring RADIUS clients by IP address range
For IAS in Windows 2000, you must specify a RADIUS client by IP address or by Domain Name System (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, numerous wireless access points can be placed on the same subnet. To simplify administration of RADIUS clients for this type of network configuration, IAS in Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition allows you to specify a RADIUS client by using an address range. All of the RADIUS clients in the range must use the same configuration and shared secret.
The 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 (CIDR) 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.
For more information, see Configure RADIUS Clients.
Support for computer authentication
Active Directory and IAS in Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition support the authentication of computer accounts by using standard user authentication methods such as Point-to-Point Protocol (PPP). This allows a computer and its computer certificate to be authenticated for wireless or authenticating switch access clients.
Support for 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 known as object identifiers or OIDs) of certificates in their Enhanced Key Usage (EKU) extensions. When EAP-TLS is used, 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 (the object identifier is 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 purpose is present in the VPN client certificate, authentication succeeds. For more information, see Network access authentication and certificates.
You can configure a list of object identifiers that are required to be present in the user certificate (which is offered by the access client). To do this, use the Allow certificates with these OIDs attribute on the Advanced tab in the properties of a remote access policy profile. No required object identifiers are specified by default. For more information, see Add RADIUS attributes to a remote access policy.
Improved 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. For more information, see Connection request policies.
Support for the Authentication Type remote access policy condition
In IAS for Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition; you can create remote access policies by using the Authentication Type condition. You can use it to specify connection constraints that are based on the authentication protocol or method that is used by the access client. For more information, see Elements of a remote access policy.
Improved support for the Class attribute
In Windows 2000, IAS automatically generates a value for the Class attribute and appends it to the existing value of the Class attribute received in the RADIUS request message. 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. For more information, see Add RADIUS attributes to a remote access policy.
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 is generated by IAS.