deploying ias

C H A P T E R 7Servers running the Internet Authentication Service (IAS) component of the Microsoft® Windows® Server 2003 operating system perform centralized authentication, authorization, auditing, and accounting for many types of network access, including dial-up, virtual private network (VPN), wireless, and 802.1X authenticating switch access. IAS is the Microsoft implementation of the Remote Authentication Dial-In User Service (RADIUS) protocol. A number of design, implementation, and deployment issues must be considered when rolling out a scalable and robust IAS solution.

Information about deploying remote access clients can be found in other chapters in this book.

In This Chapter

Overview of IAS Deployment...............................................................................318Designing IAS......................................................................................................326Designing an Optimized IAS Solution..................................................................341Creating a Remote Access Policy Strategy..........................................................349Securing Your Remote Access Strategy..............................................................357Implementing Your IAS Solution..........................................................................366Additional Resources...........................................................................................377

Related Information

For information about Windows Server 2003 Internet Authentication Service (IAS), see the Networking Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

For information about Windows Server 2003 Routing and Remote Access, see the Internetworking Guide of the Windows Server 2003 Resource Kit (or see the Internetworking Guide on the Web at http://www.microsoft.com/reskit).

For information about Windows Server 2003 Routing and Remote Access deployment, see “Deploying Dial-Up and VPN Remote Access Servers,” “Deploying Remote Access Clients Using Connection Manager,” and “Connecting Remote Sites” in this book.

Deploying IAS

318 Chapter 7 Deploying IAS

Overview of IAS DeploymentYou can use IAS to provide authentication and authorization for dial-up, VPN, wireless, and authenticating switch access to your network. For example, organizations that outsource network access and perform joint ventures with other organizations require the authentication of user accounts from outside of the private network. In addition, organizations that provide outsourcing services, such as Internet service providers (ISPs), require remote user connection accounting so that they can charge subscribers.

Windows Server 2003 IAS enables you to centralize authorization, authentication, and accounting for remote access clients, enhancing the security of your network. Windows Server 2003 IAS works with other standards-based implementations of the Remote Authentication Dial-In User Service (RADIUS) protocol, so that you can use it with any standards-compliant RADIUS client, server, or proxy server.

Windows Server 2003 IAS is included in Microsoft® Windows® Server 2003, Standard Edition; Windows® Server 2003, Enterprise Edition; and Windows® Server 2003, Datacenter Edition. IAS is not provided with Microsoft® Windows® Server 2003, Web Edition. In addition, Windows Server 2003, Standard Edition, limits some IAS features. For more information, see “IAS Concepts” later in this chapter.

Windows Server 2003 IAS provides the following solutions for organizations that require secure network access:

Compatibility with RADIUS servers and clients from any vendor that meets the specifications outlined in RFCs 2865, 2866, and 2869.

Integration with the Active Directory®. IAS allows you to take advantage of Active Directory for user authentication, authorization, and client configuration, thus reducing management costs.

Use of standards-based strong authentication methods for network access.

Management of network access that is outsourced to an ISP. IAS allows you to create an agreement between your organization and the ISP in which the ISP can charge a roaming user’s department for that employee’s network usage. In this way, each employee does not need to submit an expense statement or create a roaming account to connect to the corporate network remotely.

Dynamic key management for wireless access points as a means to increase network security.

Additional Resources 319

IAS Deployment ProcessThe process of deploying IAS involves deciding what role IAS will play in your network infrastructure, configuring connection request and remote access policies to allow users to access the network, and securing and optimizing the design. Figure 7.1 shows the IAS deployment process.

Figure 7.1 Deploying IAS


IAS ConceptsIAS implements the Internet Engineering Task Force (IETF) standard Remote Authentication Dial-In User Service (RADIUS) protocol, specified in RFCs 2865, 2866, and 2869, which enables the use of a homogeneous or heterogeneous network of dial-up, VPN, wireless, or authenticating switch equipment. When a remote client tries to connect to an access server configured to use the RADIUS protocol, the access server sends the connection request to the IAS server by using the RADIUS protocol. When an IAS server is a member of an Active Directory® domain, IAS uses the directory service as its user account database and is part of a single sign-on solution. The same set of credentials is used for network access control (authenticating and authorizing access to a network) and to log on to an Active Directory domain.

In addition, the IAS server can accept or reject the request based on conditions that you specify in the remote access policies. Remote access policies are an ordered set of rules that define how connections are either authorized or rejected. For each rule, there are one or more conditions, a set of profile settings, and a remote access permission setting. Access to the network resources can be controlled by applying policies to users or groups of users. For more information about using remote access policies to grant access, see “Remote access policies” in Help and Support Center for Windows Server 2003.

When using 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. However, when using Windows Server 2003, Standard Edition, you can configure IAS with a maximum of 50 RADIUS clients and a maximum of two 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.

RADIUS is a client/server protocol that requires a RADIUS client and a RADIUS server to provide network access. An access server or a RADIUS proxy is a RADIUS client, and the computer making the determination of authentication and authorization is a RADIUS server.


Figure 7.2 shows a typical IAS architecture. An access client contacts an IAS RADIUS proxy located at an ISP by using a local telephone connection. The IAS proxy examines the user name, which contains two elements – the identification of the user account name and the identification of the user account location (also known as a realm). Based on the realm portion of the user name in the connection request, the IAS RADIUS proxy forwards the connection request to a RADIUS server on a private network, which authenticates and authorizes the connection attempt with the Active Directory user accounts database and user account properties.

Figure 7.2 IAS Architecture

For more information about Internet Authentication Service (IAS), see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit) and “Internet Authentication Service” in Help and Support Center for Windows Server 2003.

For more information about realm names, see “Realm names” in Help and Support Center for Windows Server 2003.

A general understanding of the following topics is also essential to proper IAS deployment:

Remote access.

The Windows Server 2003 implementation of remote access.

Any network access mechanism your users require, such as dial-up, VPN, wireless, or authenticating switch access.

Network security.

Active Directory.

Authentication.

Accounting.

For more information about any of these topics, see the Windows Server 2003 Resource Kit and Help and Support Center for Windows Server 2003.


New in Windows Server 2003

Windows Server 2003 IAS includes the following new features:

Support for RADIUS proxy. With RADIUS proxy support, you can use IAS as a RADIUS message router or forwarder between access servers and other IAS servers. Based on attributes in the incoming RADIUS message, the RADIUS proxy forwards the message to a specific RADIUS server or client.

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. 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” in Help and Support Center for Windows Server 2003.

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 authenticating switch access. For more information about configuring IAS for wireless access authentication, see “Checklists: Configuring IAS for wireless access” and ”Wireless access” in Help and Support Center for Windows Server 2003.

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 Extensible Authentication Protocol (EAP). The next generation of EAP, PEAP uses Transport Layer Security (TLS) to create end-to-end communication between client and authenticator after the identity of the authenticator is verified. For more information, see “PEAP” in Help and Support Center for Windows Server 2003.

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. In Windows Server 2003 IAS, this limitation is removed. 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 Microsoft Challenge Handshake Authentication Protocol version 2 (EAP-MS-CHAPv2). For more information, see “EAP” and “Configure PEAP and EAP methods” in Help and Support Center for Windows Server 2003.


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” in Help and Support Center for Windows Server 2003.

Support for logging to MSDE 2000 and SQL Server 2000 databases. You can use an XML-compliant database, such as Microsoft® SQL Server™ 2000 and SQL Server Desktop Engine (MSDE 2000), to log user authentication requests, periodic data, and accounting requests received from one or more access servers. For more information, see “SQL Server database logging” in Help and Support Center for Windows Server 2003.

Support for 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. 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 more information, see “New features for IAS” in Help and Support Center for Windows Server 2003.

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, creating a circumstance where use of an IP address range simplifies configuration and administration. In Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, IAS allows you to specify a RADIUS client by using an IP address range. All of the RADIUS clients in the range must use the same configuration and shared secret. For more information, see “Configure RADIUS clients” in Help and Support Center for Windows Server 2003.

Support for 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 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 orOIDs) of certificates in their Enhanced Key Usage (EKU) extensions. You can configure a list of object identifiers that are required to be present in the user certificate. For more information, see “Network access authentication and certificates” and “Add RADIUS attributes to a remote access policy” in Help and Support Center for Windows Server 2003.

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, you can manipulate the User-Name, Called-Station-ID, and Calling-Station-ID RADIUS attributes. For more information, see “Connection request policies” in Help and Support Center for Windows Server 2003.

Support for the Authentication Type remote access policy condition. You can create remote access policies by using the Authentication Type condition in IAS for Windows Server 2003. You can use the Authentication Type condition 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” in Help and Support Center for Windows Server 2003.

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 the Generate-Class-Attribute setting 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 is generated by IAS. For more information, see “Add RADIUS attributes to a remote access policy” in Help and Support Center for Windows Server 2003.


IAS Terms and Definitions

This section provides brief definitions of important IAS terms. For more information, see the sources mentioned in “Additional Resources” later in this chapter, or Help and Support Center for Windows Server 2003.

A component of Windows Server 2003 that performs centralized authentication, authorization, auditing, and accounting for a variety of different types of network access, including dial-up, VPN, wireless, and authenticating switch access.

A protocol, specified in RFCs 2138 and 2139, that enables use of a homogeneous or heterogeneous network of dial-up or VPN equipment.

A server that implements the RADIUS protocol. A RADIUS server performs authentication, authorization, and accounting on behalf of a RADIUS client.

A network access server that uses a RADIUS server to perform authentication, authorization, and accounting for its access clients.

A server that forwards incoming RADIUS messages to specific RADIUS servers for additional processing, based on RADIUS attributes in the incoming RADIUS message. An IAS server can act as a RADIUS server for some requests and a RADIUS proxy for others.

The process of performing identity verification of the entities that communicate over a network; for example, the process that verifies the identity of a user who logs on to a computer either locally, at a computer’s keyboard, or remotely, by means of a network connection.

The process that determines what a user is permitted to do on a computer system or network. For remote access or demand-dial routing connections, the verification that the connection attempt is allowed. Authorization occurs after successful authentication. With IAS, you can manage authorization using remote access policies and Active Directory user account properties.

The process that tracks the activities of users by recording selected types of events in the security log of a computer.

A method of tracking account activity information such as logon and logoff records, to help maintain records for billing purposes. With IAS, you can also track authentication information, such as each accept, reject, and automatic account lockout.

Internet Authentication Service (IAS)Remote Authentication Dial-In User Service (RADIUS) protocolRADIUS serverRADIUS clientRADIUS proxyAuthenticationAuthorizationAuAccountin


Designing IASAfter taking an inventory of your network environment, the first step in designing an IAS solution is to determine the role of the IAS server. For example, determine whether you need the IAS server to authenticate the connection request that it receives, forward the request to another IAS server for authentication, or perform a mixture of both functions depending on context. Finally, an important step in the design process is to configure IAS to work with different types of clients.

Figure 7.3 shows the process for designing IAS.

Figure 7.3 Designing IAS


Inventory Your Current EnvironmentWhen beginning your design process, make sure to have specifications about your current network environment available for use. Specifically, your hardware and software inventory and a map of network topology can be very helpful in reducing time spent during the design phase. For more information about creating those documents, see “Planning for Deployment” in Planning, Testing, and Piloting Deployment Projects of this kit.

Determine the Role of the IAS ServerYou can configure your IAS server to act as a RADIUS server, a RADIUS proxy, or both, depending on where you want network access requests to be authenticated.

RADIUS server

If you want your IAS server to authenticate the connection requests that it receives, rather than forwarding connection requests to another IAS server, use the IAS server as a RADIUS server. For example, if your access servers connect directly to your network, then the IAS server is configured as a RADIUS server to authenticate the connection.

Figure 7.4 shows an IAS server configured as a RADIUS server. An access client connects to an access server. The access server sends a connection request to an IAS RADIUS server located on the corporate network, which authenticates and authorizes the connection attempt.

Figure 7.4 IAS Configured as a RADIUS Server


RADIUS proxy

If you want an IAS server to forward connection requests to another IAS server, use IAS as a RADIUS proxy. Use the RADIUS proxy capabilities in the following situations.

Using IAS proxy at a third-party ISPYou are an ISP providing outsourced network connection services to multiple customers. Your network access servers send connection requests to the IAS RADIUS proxy. Based on the realm portion of the user name in the connection request, the IAS RADIUS proxy forwards the connection request to a RADIUS server maintained by the customer that can authenticate and authorize the connection attempt.

Figure 7.5 shows an IAS server configured as a RADIUS proxy. An access client contacts an access server at an ISP. The ISP access server sends a connection request to an IAS RADIUS proxy. Based on the realm portion of the user name in the connection request, the IAS RADIUS proxy forwards the connection request to a RADIUS server located on the corporate network, which authenticates and authorizes the connection attempt.

Figure 7.5 IAS Configured as a RADIUS Proxy at a Third-Party ISP

Using IAS proxy with multiple forestsYou have multiple forests and want to perform cross-forest authentication with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS). Rather than configuring your access servers to send their connection requests to an IAS RADIUS server, configure them to send their connection requests to an IAS RADIUS proxy.


Figure 7.6 shows an IAS server configured as a RADIUS proxy forwarding RADIUS messages to RADIUS servers in multiple forests. The IAS RADIUS proxy uses the domain name portion of the user name and forwards the request to an IAS server in each forest.

Figure 7.6 IAS as a RADIUS Proxy with Multiple Forests

Using IAS proxy for load balancingYou want to increase the capacity for connection requests. In this case, rather than configure your access servers to attempt to load balance across multiple RADIUS servers, configure them to send their connection requests to an IAS RADIUS proxy. The IAS RADIUS proxy can load balance across multiple RADIUS servers and scale up to large numbers of RADIUS clients and authentications per second.


Figure 7.7 shows an access server forwarding a request to a RADIUS proxy to load balance to multiple RADIUS servers. The remote client connects to a RADIUS client, such as an access server. The access server sends the authentication request to the RADIUS proxy, which load balances the request across different IAS servers.

Figure 7.7 Load Balancing

RADIUS server and proxy

If you need your IAS server to authenticate some requests and forward other requests, use IAS as both a RADIUS server and a RADIUS proxy. For example, if you are performing cross-forest authentication, use your IAS server as a RADIUS server to authenticate users in the same forest, and use it as a RADIUS proxy to forward authentication requests to another IAS server for users in another forest.

Figure 7.8 shows an IAS server configured to be both a RADIUS server and a RADIUS proxy. The remote client connects to an IAS server configured as both a RADIUS server and a RADIUS proxy. Based on the realm portion of the access client user name, the IAS server determines whether to authenticate the request directly or forward the authentication request on to another IAS server in a different forest.

Figure 7.8 IAS Configured as Both a RADIUS Server and a RADIUS Proxy


Design IAS as a RADIUS ServerDesigning IAS as a RADIUS server involves some or all of the following tasks:

Determining the IAS server domain membership

Planning for RADIUS clients

Planning authentication

Determining compatibility with third-party access servers

Adding RADIUS or vendor-specific attributes (VSAs) to the remote access policy

Installing a backup IAS server

For more information about configuring IAS as a RADIUS server, see “Deploying IAS as a RADIUS Server” later in this chapter and “IAS as a RADIUS server” in Help and Support Center for Windows Server 2003.

Determine IAS Server Domain Membership

You must determine which domain the IAS server computer will belong to. In multiple-domain environments, an IAS server can authenticate user credentials for user accounts in the domain in which it is a member and for user accounts in all domains that have a two-way trust relationship with the domain in which it is a member. For increased performance, install IAS on the domain controllers in the domain that will authenticate the users. If you install IAS on a domain controller, you do not have to add the domain controller computer account to the RAS and IAS Servers group of the domain.

For more information about configuring IAS servers, see “Implementing Your IAS Solution” later in this chapter.

Plan for RADIUS Clients

A RADIUS client can be an access server (for example, a dial-up or VPN server, a wireless access point, or an Ethernet authenticating switch) or a RADIUS proxy. IAS supports all access servers and RADIUS proxies that comply with RFC 2865, Remote Authentication Dial-in User Service (RADIUS).

Configure each access server or RADIUS proxy that sends RADIUS request messages to the IAS server as a RADIUS client. For each RADIUS client, you can configure a friendly name, an IP address or DNS name, the client vendor, the shared secret, and whether the RADIUS Message-Authenticator attribute is used.

You can specify IP addresses or DNS names for RADIUS clients. In most cases, it is better to specify RADIUS clients with IP addresses. When you use IP addresses, IAS is not required to resolve host names at startup and starts more quickly as a result. This is especially beneficial if your network contains a large number of RADIUS clients. You can use DNS names to specify RADIUS clients when you require something other than administrative flexibility (for example, the ability to map multiple RADIUS client IP addresses to a single DNS name).


If you are using Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, you can specify a RADIUS client by using an IP address range. All of the RADIUS clients in the range must use the same configuration and shared secret. This configuration is useful, for example, if you place many wireless access points on the same subnet.

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. For more information, see “Configure RADIUS clients” in Help and Support Center for Windows Server 2003.

Plan Authentication

When designing network authentication solutions, protecting the authentication channel can prevent potential security attacks.

Most password-based authentication methods, such as CHAP and MS-CHAP, do not provide privacy-protected channels to guard against offline dictionary attacks by hackers that intercept authentication traffic on the network. Because of this, ensure that password-based authentication methods are always deployed with protection from IPSec or PEAP.

EAP-TLSCertificate-based authentication methods are much more secure than password-based authentication methods. Use certificate-based authentication methods, such as PEAP and EAP, in all possible circumstances because they protect the authentication channel and provide strong security. EAP-TLS is designed, in part, to protect against spoofing or other attacks and can be deployed without protection from IPSec or PEAP. EAP-TLS requires a public key infrastructure (PKI) and is an authentication method that can be used with all connection types supported by IAS (wireless, authenticating switch, VPN, and dial-up).

By using Group Policy in Windows Server 2003, you can easily distribute certificates to clients and servers with auto-enrollment. For the maximum strength user credentials, deploy EAP-TLS with a smart cards. Smart cards provide maximum strength with two-factor authentication. Certificates installed in the computer certificate store (without smart cards) offer single-factor authentication.

PEAPPEAP uses Secure Sockets Layer (SSL) technology to privacy-protect authentication communications, and to key the encryption of link layer network connections. You can deploy PEAP with either EAP-MS-CHAPv2 or EAP-TLS as the authentication type. PEAP-EAP-MS-CHAPv2 is a secure password authentication method recommended for wireless deployments. However, PEAP is not available for VPN or dial-up connections.

PEAP provides protection for the EAP method negotiation that occurs between client and server through a TLS channel. This helps prevent an attacker from injecting packets between the client and the access server to cause the negotiation of a less secure EAP method.


Clients using PEAP as the authentication method have the ability to authenticate the IAS or RADIUS server. Because the server also authenticates the client, mutual authentication occurs.

PEAP fast reconnect, which reduces the delay in time between an authentication request by a client and the response by the IAS or RADIUS server, allows wireless clients to move between wireless access points without repeated requests for authentication. This reduces resource requirements for both client and server, and allows users to move between access points without reentering credentials.

If you deploy PEAP, do not deploy the same authentication type both inside of the PEAP Transport Layer Security (TLS) channel and outside of the PEAP TLS channel. For example, do not deploy both PEAP-EAP-TLS and EAP-TLS on the same network. You can deploy different authentication types inside and outside the TLS channel. For example, you can deploy PEAP-EAP-MS-CHAPv2 and EAP-TLS on the same network.

Authentication and PPP and PPTP ConnectionsFor dial-up Point-to-Point Protocol (PPP) or Point-to-Point Tunneling Protocol (PPTP) VPN connections, it is recommended that you use EAP-TLS with smart cards or certificates as the authentication method.

For L2TP/IPSec VPN connections, you can use MS-CHAPv2 as the authentication method. Internet Protocol security (IPSec) uses computer certificates to establish a secure channel before authentication proceeds, providing the necessary protection for authentication and other communication.

When planning authentication:

For wireless connections, you can configure all the connection properties on the client (including authentication methods) using Windows Server 2003 Group Policy. For example, you can configure wireless connections to specific networks to require use of EAP-TLS.

You can use Connection Manager Administration Kit (CMAK) to create a Connection Manager profile for installation on client computers. With Connection Manager, you can manage the client connection properties (including authentication methods) used for access to your network.

Configure remote access policies at the IAS server to only allow the authentication methods you want to allow per connection type, such as dial-up or VPN. .

For more information, see “Authentication methods” and “Public key infrastructure” in Help and Support Center for Windows Server 2003.

Add RADIUS or VSA Attributes to Remote Access Policy

If you plan to return additional RADIUS attributes or VSAs with the responses to RADIUS requests, you must add the RADIUS attributes or VSAs to the appropriate remote access policy.


Install Backup IAS Servers

To provide fault tolerance for RADIUS-based authentication and accounting, you must always use at least two IAS servers working together in the same location. One IAS server is used as the primary RADIUS server, and the other is used as a backup. RADIUS proxies are configured to use both IAS servers. When the primary IAS server becomes unavailable, the RADIUS proxies automatically use the backup IAS server instead.

Design IAS as a RADIUS ProxyDesigning IAS as a RADIUS proxy involves some or all of the following tasks:

Planning the connection request policy

Adding RADIUS and VSA attributes

Planning for load balancing and failure detection

Installing backup IAS proxies

For more information about configuring IAS as a RADIUS proxy, see “Deploying IAS as a RADIUS Proxy” later in this chapter and “Deploying IAS as a RADIUS proxy” in Help and Support Center for Windows Server 2003.

Plan the connection request policyThe default connection request policy Use Windows authentication for all users is configured for IAS when it is used as a RADIUS server. To create a connection request policy to use IAS as a RADIUS proxy, complete the following steps:

1. Create a remote RADIUS server group on the domain that will authenticate the users.

2. Create a connection request policy that forwards authentication requests to the remote RADIUS server group.

3. Either delete the default connection request policy, or set the new connection request policy first in the order before the default connection request policy so that it is evaluated first.

Add RADIUS attributes and VSAsIf you plan to return additional RADIUS attributes and VSAs with RADIUS requests, you must add the RADIUS attributes and VSAs to the appropriate connection request policy.

Plan for load balancing and failure detectionWhen you configure multiple servers in a remote RADIUS server group, you can configure settings that determine how the IAS proxy server balances the load of authentication and accounting requests over the RADIUS servers in the group. You can use additional settings to configure IAS to detect and recover from the failure of a remote RADIUS server group member.

For more information about load balancing for remote RADIUS server group members, see “Configure the load balancing properties of a group member” in Help and Support Center for Windows Server 2003.


Install backup RADIUS proxiesTo provide fault tolerance for RADIUS-based authentication and accounting, you must always use at least two IAS proxy servers. One IAS server is used as the primary RADIUS proxy, and the other is used as a backup. RADIUS clients (access servers or other RADIUS proxies) are configured on both IAS proxy servers. In addition, configure both the primary and backup IAS proxy servers on each RADIUS client. When the primary IAS proxy becomes unavailable, the access servers automatically use the backup RADIUS server instead.

For more information about synchronizing the configuration of multiple IAS servers, see “Managing multiple IAS servers” in Help and Support Center for Windows Server 2003.

Designing Support for Client AccessAfter you have designed your IAS infrastructure and determined what role IAS will play in your network, you must consider what types of network and remote access clients you will need to support. For each type, your IAS server configuration will differ, and you will need to make different planning decisions.

Windows Server 2003 IAS supports the following forms of network access:

Dial-up remote

VPN

Wireless

Authenticating switch

Designing Support for Dial-up Access

Windows Server 2003 has extensive support for remote access technology to connect dial-up and other types of remote clients to corporate networks or to the Internet. For information about how to plan, design, and implement Windows Server 2003 components (such as Routing and Remote Access Service and Connection Manager) in an enterprise environment, see “Deploying Remote Access Clients Using Connection Manager ” in this book.

NoteYou can use the Routing and Remote Access service included with Windows Server 2003 or the Microsoft® Windows® 2000 operating system to provide network access. However, you can also use third-party network access servers with Windows Server 2003 IAS. To ensure that the third-party access server works with Windows Server 2003 IAS, check with the manufacturer to confirm that the product supports RFCs 2865, 2866, and 2869.


IAS supports both voluntary and compulsory tunneling. Table 7.1 describes the differences between both types of tunneling and when you might use each type.

Table 7.1 Comparison of Voluntary and Compulsory Tunneling

Tunnel Type When to Use It Which IAS Components to Use

Voluntary tunneling

Use this option if your clients need to choose their tunneling location themselves.

For example, the user dials in to an ISP. At the client’s request, the ISP creates a tunnel to the corporation. The user can alternatively request a tunnel to somewhere else, such as the Internet.

The ISP uses IAS as a RADIUS proxy to forward the request to the corporate IAS server.

The corporation uses IAS as a RADIUS server to authorize and authenticate the request.

Either the ISP or the corporation can use a third-party RADIUS server.

Compulsory tunneling

Use this option if you want to use one tunnel for many clients.

For example, if a corporation has clients in geographically dispersed locations, it can contract with an ISP to deploy regional tunnel servers. Any client can dial in to any of the tunnel servers, which then creates a compulsory tunnel to the corporation. Compulsory tunneling is typically used for dial-up clients, but can also be used for VPN clients.

The ISP uses IAS as a RADIUS server to authorize the request.

The corporation uses IAS as a RADIUS server to authorize and authenticate the request.

Either the ISP or the corporation can use a third-party RADIUS server.

Voluntary Tunneling

In voluntary tunneling, during the authorization phase, the corporate IAS server restricts the client connection to use a specificVPN protocol (PPTP or L2TP/IPSec) if an administrator has configured remote access policies to restrict connections to those using the specified protocol. The designated protocol must be installed on the client or the connection attempt is rejected. After the access request is authenticated and authorized, the client establishes a VPN tunnel to the corporate access server.

A user or client computer can issue a VPN request to configure and create a voluntary tunnel. In this case, the user’s computer is a tunnel endpoint that acts as the tunnel client. Voluntary tunneling occurs when a workstation or router uses tunneling client software to create a VPN connection to the target tunnel server. In order to accomplish this, the appropriate tunneling protocol must be installed on the client computer. In a dial-up situation, which is the most common use, the client must establish a dial-up connection to the internetwork before the client can set up a tunnel. A good example of this is the dial-up Internet user, who must dial an ISP and obtain an Internet connection before a tunnel over the Internet is created.

Voluntary tunneling is not different from other types of network access, and IAS can be used for authentication, authorization, and accounting.


Compulsory Tunneling

Compulsory tunneling is the creation of a secure tunnel by another computer or network device on the client computer’s behalf. Compulsory tunnels are configured and created automatically for users without their knowledge or intervention. With a compulsory tunnel, the user’s computer is not a tunnel endpoint. Another device between the user’s computer and the tunnel server is the tunnel endpoint, which acts as the tunnel client.

The computer or network device that provides the tunnel for the client computer is known as a front-end processor (FEP) in PPTP, an L2TP access concentrator (LAC) in L2TP, or an IP security gateway in IPSec. The term FEP is used to describe tunnel creation functionality, regardless of the protocol used. To perform its function, the FEP must have the appropriate tunneling protocol installed and must be capable of establishing the tunnel when the client computer attempts a connection. In Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; and Windows 2000, the Routing and Remote Access service cannot be used as a FEP.

An organization can contract with an ISP to deploy a nationwide set of FEPs. These FEPs can establish tunnels across the Internet to a VPN server that is connected to the organization private network, thereby consolidating calls from geographically diverse locations into a single Internet connection at the organization network.

There are two types of compulsory tunneling. In the first type, the tunnel is created before the access client is authenticated. Based on the realm name or the caller ID of the access client, the FEP sends an Access-Request message to an IAS server. The IAS server sends back an immediate Access-Accept message with RADIUS attributes for the tunnel creation without performing authentication and authorization. After the tunnel is created, the access client authenticates against the tunnel server.

In the second type of compulsory tunneling, the tunnel is created after the access client is authenticated by the FEP. In this case, the FEP sends the Access-Request message with the client credentials to an IAS server. The IAS server authenticates and authorizes the connection attempt and returns RADIUS attributes in the Access-Accept message, which specify to the NAS how to initiate a tunnel to a VPN server. The tunnel endpoint (the VPN server at which the tunnel is terminated), can be changed on the basis of conditions in a remote access policy. For example, the tunnel endpoint can be changed on the basis of the user name or the user account group membership. Controlling compulsory tunnels with remote access policies provides more flexibility than static tunneling (which requires a dedicated access server) or realm-based tunneling (which requires all users in a specific realm to use the same tunnel settings).

For more information, see “IAS and tunnels” in Help and Support Center for Windows Server 2003.


Designing Support for VPN AccessDepending on the credentials of the authenticating user, you can configure IAS to direct the traffic from a VPN client through a tunnel to specific parts of the enterprise network. Both voluntary and compulsory tunneling can be used for outsourced VPN access.

Special Considerations for VPN Access

Consider the following access server compatibility issues:

IAS can provide compulsory tunneling connection attributes for network access servers (NASs) that support compulsory tunneling. However, the Windows Server 2003 Routing and Remote Access service does not support compulsory tunneling.

VPN servers running the Microsoft® Windows NT® version 4.0 operating system must also be running Routing and Remote Access Service (RRAS) if you want to configure them as RADIUS clients.

For more information about Internet Authentication Service, including the authorization and authentication process used in voluntary and compulsory tunneling, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

For information about the RADIUS attributes used with compulsory tunneling, see “Compulsory tunnels” in Help and Support Center for Windows Server 2003.

Designing Support for Wireless AccessWireless networking technology is becoming more widespread with the adoption of industry standards such as IEEE 802.11 and 802.11b. Wireless networking allows a user to roam around a building or campus and automatically connect to the network after the user is in proximity to a wireless access point (wireless AP).

You can use IAS to support wireless access in the following scenarios:

Wireless LAN access

Outsourced wireless access


Countering Wireless Security Risks

While providing convenience, wireless networking technologies and wireless APs represent 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.

IAS provides enhanced security for wireless access. To counter the first security risk, you can set up the wireless access point as a RADIUS client, and then configure it to send access requests and accounting messages to a central RADIUS server running IAS.

To counter the second security risk, you can encrypt the data sent between the wireless devices and the wireless access points. The authentication method used by the wireless client must be able to use encryption keys.

Special Considerations for Wireless Access

If you will be supporting wireless access, include the following elements in your design:

An authentication mechanism. With wireless access, you can use Protected Extensible Authentication Protocol (PEAP), EAP-TLS, or unauthenticated wireless access. For more information on PEAP, see “PEAP” in Help and Support Center for Windows Server 2003.

Certificates and a certification authority, if you are deploying authentication methods that use certificates on both the client and server, such as EAP-TLS. For more information, see “Integrate IAS with the Certificate Infrastructure” later in this chapter.

The Wireless-IEEE 802.11 and Wireless-Other port types for 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 specifically designed for wireless devices.

The Ignore-User-Dialin-Properties attribute in the profile settings of a remote access policy. The dial-in properties of the user account are designed for clients dialing into an access server, not for clients connecting to a wireless port or authenticating switch. You can disable them on the remote access policy. For more information about profile settings, see “Dial-in properties of a user account” in Help and Support Center for Windows Server 2003.


Designing Support for Authenticating Switch AccessA network switch filters 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 it. This can create a security risk, especially for switch ports in a conference room of an organization, which might be accessed by visitors or employees of partner organizations.

Securing Authenticating Switch Access with IAS

To prevent physical layer access to the network, use authenticating switches as RADIUS clients and use the industry-standard RADIUS protocol to send access 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 determining whether to grant authorization.

If you need to grant access to different types of users for different parts of your network, you can use authenticating switch access. For example, a corporate conference room has a virtual local area network (VLAN) for visitors. A visitor logging on without presenting credentials is granted access to the conference room VLAN. At the same time, an employee logging on with appropriate credentials is granted access to the entire corporate network. Thus, administrators can use IAS with authenticating switch access to secure parts of the network from malicious users and from inexperienced users who might inadvertently cause errors in network configuration. You can also use VLANS with IAS for wireless access configurations.

Because the data sent between the node and the authenticating switch physically travels on a dedicated wire, encryption of the data is not required or typically implemented.

Special Considerations for Authenticating Switch Access

If you will be supporting authenticating switch access, include the following elements in your design:

An authentication mechanism. You can use EAP-TLS or secure password-based authentication by using PEAP-EAP-MS-CHAPv2. For more information, see “Select Authentication Protocols” later in this chapter.

Certificates and a certification authority, if you are deploying authentication methods that use certificates on both the client and server, such as EAP-TLS. For more information, see “Integrate IAS with the Certificate Infrastructure” later in this chapter.

The use of the Ethernet port type for the NAS-Port-Type condition of remote access policies. By using this port type, you can create a separate remote access policy that contains connection parameters specifically designed for nodes connecting to the network through an authenticating switch. For more information, see “Elements of a remote access policy” in Help and Support Center for Windows Server 2003.

The Ignore-User-Dialin-Properties attribute in the profile settings of a remote access policy. The dial-in properties of the user account are designed for clients dialing into an access server, not for clients dialing into a wireless port or authenticating switch. You can disable them on the remote access policy. For more information, see “Dial-in properties of a user account” in Help and Support Center for Windows Server 2003.


Designing an Optimized IAS SolutionOptimize your IAS design by planning how to scale your IAS servers, whether or not to add IAS servers, where to place your IAS servers, and other steps as illustrated in Figure 7.9.

Figure 7.9 Designing an Optimized IAS Solution

IAS RADIUS clients and servers require minimal management and administration. However, over time, changes in the number of access clients, changes in WAN technology, and other factors can reduce the performance of IAS.


You can optimize IAS performance by positioning your IAS servers strategically. Use the following guidelines when deciding where to position your IAS servers:

Locate IAS servers in the same domain with the server that provides remote user account authentication.

Locate IAS on a domain controller and store the user account database in Active Directory.

In addition, the following factors can negatively impact IAS performance:

The current load of the domain controller.

The resolution of user principal names, resulting in an additional remote procedure call (RPC) query against the computer that contains the global catalog.

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

The type of hardware in use.

Network latency between:

The IAS server and the domain controller.

The IAS server and the computer that contains the global catalog.

The IAS server and the access server.

You can optimize the performance of an IAS solution by scaling IAS to meet increasing demands in your organization and by including more than one RADIUS client and server in your network design.

Scale an IAS Server to Optimize PerformanceIAS servers can accommodate a large volume of accounts and authentications per second. For this reason, they perform well in large organizations. A single IAS server can often meet the dial-up and VPN connection needs for an entire network. However, if you have more complex network access needs, you might need to scale even a single IAS server. For example, certificate-based authentication can generate a large volume of authentication traffic that is transmitted every time a client logs onto the network. If you use certificate-based authentication, you must scale IAS to meet all of your Internet authentication needs.

For more information about scaling IAS, see “Deploying IAS as a RADIUS proxy” in Help and Support Center for Windows Server 2003.


Add IAS Servers to Optimize AvailabilityIt is important to prevent an IAS server from becoming a single point of failure.

To prevent an IAS server from becoming a single point of failure, deploy IAS servers either in pairs (a primary and a backup IAS server) to provide fault tolerance, or in multiples, to balance the load of a large volume of authentication and accounting requests. Add at least two additional IAS servers per forest.

The level of availability that you need to provide depends on the following:

How likely it is that a network link will fail

How important it is to provide uninterrupted authentication to your clients at all times

Balance your need for availability against your need to minimize the costs of the hardware investment. Keep in mind that you can add IAS to existing domain controllers.

When you deploy more than one IAS server, make sure to design your IAS servers to use RADIUS proxies for load balancing and synchronization of the server configurations.

Use Load Balancing with Multiple IAS ServersIf you add multiple IAS servers for performance reasons, you must load balance the servers. You can load balance and provide failover at each access server by configuring the access server to send queries to multiple RADIUS servers in a specified order of importance. You can also load balance by using IAS as a RADIUS proxy server that forwards connection requests to IAS servers in groups called remote RADIUS server groups. These configurations are useful for the following:

Organizations that use EAP-TLS for authentication, which increases the load on RADIUS proxies and servers. For example, ISPs and corporations that want to provide wireless or authenticating switch access often use EAP-TLS.

Organizations that need to sustain continuous service availability.

ISPs that outsource VPN access for other organizations. The outsourced VPN services can generate a large volume of authentication traffic.

You can use RADIUS proxies to balance the load of a large volume of authentication traffic. Without RADIUS proxies, each network access server balances its RADIUS requests across multiple RADIUS servers and detects unavailable RADIUS servers.

When RADIUS proxies are in place, the load of authentication, authorization, and accounting traffic is distributed across all of the IAS servers in the organization. Additionally, there is a consistent scheme for failure detection and RADIUS server failover.


Duplicate IAS Server ConfigurationsWhen you deploy more than one IAS server to provide the same authentication, authorization, and accounting service to RADIUS clients and proxies, you must copy the configuration of one IAS server computer to the other IAS servers. To duplicate the configuration of one IAS server to multiple IAS servers, use the IAS snap-in. This duplication method is useful when the number of configuration changes is small or if you are duplicating the configuration to only a few IAS servers. You can use the snap-in to manage both local and remote IAS servers. If you make a configuration change to one IAS server, you must make the same configuration change to all of the IAS servers that provide the same service.

To duplicate one IAS server configuration when there are a large number of configuration changes or a larger number of IAS servers, you can copy the configuration of one IAS server to another IAS server in the following way:

Make configuration changes on the primary IAS server.

On the primary IAS server, use the netsh aaaa dump command to export the configuration of one IAS server to a Netsh script file. The dump command displays the configuration of the IAS database file (Ias.mdb) as a Netsh command script that you can use to duplicate the configuration of the server on which the command is executed. The Netsh command script contains the configuration of the IAS server, including the registry keys and database file (Ias.mdb), in a compressed text format as a large data block. This large data block is used by the set config command within the script to import the configuration of a saved data block into an existing IAS database on the same or another computer, which you can perform by using the netsh exec command. To save the Netsh command script to a file, type: netsh aaaa show config > Path\File.txt

On the target computers, use the netsh exec command to import the primary IAS server configuration to the other IAS servers.

By using these two Netsh commands, you can automate the process in a simple batch file or script for multiple IAS servers.

Use this method to manage RADIUS and remote access policy configurations in a large enterprise network.

The netsh aaaa commands also provide a way to export and import individual aspects of the IAS server configuration rather than the entire configuration. For example, you can export and import only the remote access policies, or you can export and import only the RADIUS clients configured on a server.

For more information, see “Netsh” and “Netsh commands for AAAA” in Help and Support Center for Windows Server 2003.


Optimize RADIUS Client PerformanceBecause RADIUS clients, such as VPN servers and dial-up access servers, manage access client connections, their performance directly affects access client performance. Providing highly available RADIUS clients ensures that access clients can reliably connect to the network and can always be authenticated by IAS.

You can optimize performance for access clients that are using all types of connections by doing any of the following:

Upgrading the hardware of existing RADIUS clients. Choose this option if your hardware is outdated, and it is cost effective to upgrade it.

Replacing existing RADIUS clients with higher-performance servers. Choose this option if you cannot upgrade the hardware of your existing resources.

Adding RADIUS clients. Choose this option if your hardware is up-to-date, but you require more fault tolerance. Be sure to register redundant RADIUS clients with the IAS servers to ensure proper authentication and accounting.

You can optimize the performance of RADIUS clients that support dial-up connections by assigning remote access clients different primary and backup telephone numbers. This ensures that the remote access clients connect to different RADIUS clients. Choose this option if you require additional load balancing.

Optimize Authentication and AccountingRADIUS servers provide authentication and accounting for RADIUS clients, and interact with the authentication servers. As a result, RADIUS server performance and availability impacts authentication and accounting performance.

To optimize authentication in your network, ensure that all redundant IAS servers use the same user account database, thereby ensuring that the user accounts are available for authentication. Also, specify that RADIUS clients use the redundant IAS servers to ensure proper authentication and accounting.


In larger organizations with complex forest or domain topologies, use IAS as a RADIUS proxy to forward authentication requests to remote RADIUS server groups. You can also designate remote RADIUS server groups to process only accounting requests, freeing the servers performing authentication from handling accounting traffic.

To optimize authentication and accounting performance in your IAS design, take the following actions:

Run IAS on the same computer as the domain controller. This speeds IAS access to the Active Directory user accounts database when IAS is performing user authentication and authorization.

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

Reduce the number of user accounts in each domain by redesigning your domain topology.

Add IAS proxy servers to load balance authentication and accounting between servers in remote RADIUS server groups.

Upgrade the hardware resources of the existing IAS servers.

Replace existing IAS servers with higher performance servers.

Reduce the level of detail recorded in IAS accounting. IAS accounting can record user authentication requests, accounting requests, and periodic data. Make sure you are logging only the amount of information you need to troubleshoot network access.

If you configure IAS accounting for SQL Server logging, install SQL Server Desktop Engine (MSDE 2000) on the IAS server, and log to MSDE 2000 instead of directly to SQL Server 2000 running on another computer. This configuration assists in preventing logging failure due to network hardware failure or heavy network traffic. Use a custom application, service, or component to periodically publish the accounting logs from the MSDE 2000 database on each IAS server to the master SQL Server 2000 database.

For wireless deployments, use PEAP-EAP-MS-CHAPv2 with fast reconnect. PEAP uses cached TLS keys during re-authentication with access points configured as RADIUS clients of a single IAS server. Cached authentication is critical for wireless deployments because wireless clients authenticate each time they move to and associate with a new access point. In addition to improving performance, PEAP fast reconnect significantly reduces the latency of authentication and the public key operation overhead on both the client and the RADIUS server.


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

For more information, see “Remote access logging” in Help and Support Center for Windows Server 2003.

Optimize IAS Deployment in Large OrganizationsYou can optimize IAS performance in large organizations by doing the following:

If you are using remote access policies to restrict access for all but certain groups, create a universal group for all of the users to whom you want to allow access, and create a remote access policy that grants access for that universal group. If you have a large number of users on your network, create global groups within the universal group, and add the users to the global groups.

Use IAS as a proxy server and configure connection request policies to distribute authentication requests to remote RADIUS server groups based on the realm name portion of the user name. In this manner you can load balance traffic based on domain membership, and authentication requests are sent to a remote RADIUS server group that resides in the same domain where the user account is located.

Install IAS as a dedicated RADIUS server. If you choose not to run the IAS server on a domain controller with a global catalog, you can run it on a computer that has other services running on it, as long as the services are not resource-intensive.

CautionDo not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference on the Windows Server 2003 Deployment Kit companion CD or at http://www.microsoft.com/reskit.


In very large environments (such as an ISP with millions of remote access users and extremely heavy load conditions) that must process a large number of both authentication requests and accounting packets per second, you can optimize IAS performance by doing the following:

Using a faster domain controller to yield better throughput. The number of authentications per second depends on the hardware used for the domain controller.

Using separate IAS servers for authentication and accounting. IAS proxy servers can send all accounting requests to a specific remote RADIUS server group, while sending authentication requests to other groups. For more information, see “Configure accounting” in Help and Support Center for Windows Server 2003.

Running the IAS server on a domain controller with a global catalog. Choose this option if you have a high-latency connection between your IAS server and your domain controller, or between your IAS server and your global catalog, but you do not have problems with your IAS performance.

Increasing the number of concurrent authentication calls in progress at one time by using the MaxConcurrentApi registry entry. Keep in mind that if you assign too high a value to this registry entry, your IAS server can place an excessive load on your domain controller. Values from 2 to 5 provide the best performance.

For more information about the MaxConcurrentApi registry entry, see the Registry Reference on the Windows Server 2003 Deployment Kit companion CD or at http://www.microsoft.com/reskit.


Creating a Remote Access Policy StrategyRemote clients connect to the network by using remote access policies. Plan an authorization method for security, and then plan your user groups and user accounts. Next, create your remote access policies to centralize management. Figure 7.10 illustrates this process.

Figure 7.10 Creating a Remote Access Policy Strategy

CautionDo not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Referenceon the Windows Server 2003 Deployment Kit companion CD or at http://www.microsoft.com/reskit.


Establish a Remote Client Access Authorization MethodYou can use remote access policies to authorize remote client access either by group or by user.

If you authorize access by group, you can restrict network access based on an account’s group membership. For example, you can create one group for wireless users and another group for dial-in users, and create separate remote access policies for each group by using the Windows-Groups attribute (condition) of the remote access policy.

To authorize access by group in a Windows Server 2003 or a Windows 2000 native domain, set the remote access permission on every user account to Control access through Remote Access Policy. Remote access permissions are then determined by the remote access permission setting on the remote access policy.

For more information, see “Remote access policies” in Help and Support Center for Windows Server 2003.

Plan Remote Access Policy GroupsYou can manage remote access authorization by user or by group. By using the Active Directory Users and Computers snap-in, you can create groups to which specific IAS remote access policies are applied, allowing you to grant different types of remote access to different groups. The functional level of the domain impacts the type of group that you can use.

In Windows Server 2003 domains or Windows 2000 native-mode domains, you can use universal and global groups as follows:

Universal groups can include groups and accounts from any Windows Server 2003 or Windows 2000 domain in the domain tree or forest and can be granted permissions in any domain in the domain tree or forest.

Global groups can include groups and accounts only from the domain in which the group is defined and can be granted permissions in any domain in the forest.

In Windows Server 2003 interim domains or Windows 2000 mixed-mode domains, you can use only global groups. Domain local groups cannot be used because they are created in a single domain, are visible only in that domain, and can be assigned permissions only to resources within that domain.

For more information about remote access policies, see “Remote access policies” in Help and Support Center for Windows Server 2003.

For more information about functional levels, see “Domain and forest functionality” in Help and Support Center for Windows Server 2003.


Plan the User AccountsIn Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, the user account for a stand-alone server or server running Active Directory contains a set of dial-in properties that are used when performing authorization (allowing or denying a connection attempt made by a user). On a stand-alone server, you can set the dial-in properties on the Dial-in tab in the user account in the Local Users and Groups dialog box. On a server running Active Directory, you can set the dial-in properties on the Dial-in tab in the user account in the Active Directory Users and Computers snap-in. On these servers, you cannot use the Windows NT 4.0 User Manager for Domains administrative tool.

In Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition, you can configure a RADIUS attribute to ignore the dial-in properties of user and computer accounts in the profile properties of a remote access policy. 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 and is accomplished by configuring the Ignore-User-Dialin-Properties attribute on the Advanced tab of the profile settings for a remote access policy.

Computer accounts also have dial-in properties that are similar to user accounts. Therefore computers can be authenticated as if they were users when an IEEE 802.1X Ethernet client uses EAP-TLS and an installed computer certificate to authenticate itself to an Ethernet switch. Note that the Ignore-User-Dialin-Properties attribute disables the use of all dial-in properties for the user account. Specific dial-in properties cannot be individually disabled.

For more information about planning user accounts, see “Dial-in properties of a user account” in Help and Support Center for Windows Server 2003.

Configure Remote Access PoliciesYou can create multiple remote access policies to accommodate the individual security requirements of your remote connections. For example, you can use remote access policies to grant or deny authorization according to the time of day and the day of the week, the Windows Server 2003 or Windows 2000 Server group to which the remote access user belongs, the type of connection being requested (dial-up networking or VPN connection), and so on. You can also configure settings within the remote access policies that limit the maximum session time, specify the authentication and encryption strengths, set Bandwidth Allocation Protocol (BAP) policies, and so forth.

Remote access policies are applied in the order in which they are listed. When a policy is found that contains conditions that match the connection attempt, access is granted or denied, regardless of the conditions specified by the other policies later in the list. Therefore, it is a good idea to list more specific remote access policies before general remote access policies.


If you do not implement any remote access policies, all connection attempts fail.

Before you configure remote access policies, you must make decisions about the following:

Whether to use Network Access Quarantine Control for VPN and dial-up connections.

Whether to use custom or common policies. When you use the New Remote Access Policy Wizard in the IAS snap-in, you can choose to create a common or a custom policy. For a common policy, you must configure an access method, whether to grant access permissions by user or by group, authentication methods, and levels of allowed encryption (depending on the access method selected). For a custom policy, you must configure a set of policy conditions, whether remote access permission for the policy is granted or denied, and remote access policy profile settings. For more information, see “Add a remote access policy” in Help and Support Center for Windows Server 2003.

The groups and users to which the remote access policies apply.

Whether the remote access policy grants or denies access to the users or the group.

The restrictions that are placed on the users or the group.

For more information about Internet Authentication Service, including remote access policies, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Using Network Access Quarantine ControlNetwork Access Quarantine Control provides phased network access for client computers that connect to the network by using VPN or dial-up remote access. By using connection request policies and remote access policies, you can apply the MS-Quarantine-IPFilter attribute, the MS-Quarantine-Session-Timeout attribute, or both attributes to restrict clients to quarantine mode. During quarantine mode, an administrator-provided network policy requirements script is run on the client computer. After the client computer configuration is either brought into or determined to be in accordance with your organization’s network policy, quarantine mode is removed by the network access server, and standard remote access policy is applied to the connection.

You can implement Network Access Quarantine Control with one or more servers running Windows Server 2003 and the Routing and Remote Access service, one or more servers running Windows Server 2003 and IAS, a Connection Manager (CM) profile created with Connection Manager Administration Kit (CMAK), an administrator-provided script, and two additional components: the notifier component and the listener component. You can create your own notifier and listener components, or you can use Rqs.exe (a listener component) and Rqc.exe (a notifier component), which are available in the Windows Deployment and Resource Kits.

For more information, see “Deploying Dial-up and VPN Remote Access Servers” and “Deploying Remote Access Clients Using Connection Manager” in this book.


Using Common vs. Custom PoliciesYou must decide whether to use common or custom policies:

A common policy includes typical settings for a particular access method.

A custom policy includes a detailed configuration of a particular access method.

Create Specifications for a Common Policy

To create a common or custom policy, you must specify the following:

An access method. The access method is used to configure the access server Port Type condition automatically. You can choose one of the following four access methods:

VPN access

Dial-up access

Wireless access

Ethernet switch access

Whether to grant access permissions by user or by group. If you choose to grant access by group, the Windows-Groups condition is automatically set to the chosen groups.

Authentication methods. For more information about how to configure authentication methods, see “Configure authentication” in Help and Support Center for Windows Server 2003.

Levels of allowed encryption (depending on the access method chosen). For more information about how to configure encryption, see “Configure encryption” in Help and Support Center for Windows Server 2003.

When you create a common policy, the remote access permission is always set to Grant remote access permission.

Create Specifications for a Custom Policy

For each custom policy, create detailed specifications for the following elements:

Conditions. Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt.

Remote access permission. Specify whether the permission is granted or denied if the conditions of a remote access policy are met.

Profile. Specify the remote access policy profile properties to set dial-in constraints and other restrictions.


For specific information about settings for each element, see Help and Support for Windows Server 2003 or the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

ConditionsSpecify the remote access conditions for each policy. Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt. In order for the connection attempt to match the policy, all conditions must match the settings of the connection attempt. Remote access policy profile settings are applied only if the connection attempt matches the policy. Thus, remote access policies are applied only if the connection attempt matches all of the conditions of the policy.

PermissionSpecify whether the permission is granted or denied if the conditions of a remote access policy are met. You use the Grant remote access permission option or the Deny remote access permission option to set remote access permission for a policy.

During the authorization process, the dial-in properties of user accounts are evaluated before remote access policy is applied. If the dial-in properties for the user account are set to Deny access, the connection attempt is rejected and remote access policies are not evaluated. When dial-in properties for the user account are set to Control access through Remote Access Policy, the remote access policy alone determines whether the user is granted access.

When the dial-in properties for the user account are set to Grant access, remote access policies are evaluated next. In this circumstance it is possible for the user to be denied access by settings in the remote access policy. For example, if the remote access policy is configured to allow the user to connect only between the hours of 8 AM and 5 PM and the user is attempting to connect at 6 PM, the connection attempt fails due to the settings in the remote access policy.

ProfileSpecify the remote access policy profile properties to set dial-in constraints and other restrictions. These properties are applied to a connection after the connection is authorized, whether the connection has been authorized through the user account permission setting or the remote access policy.

NoteNot all network access servers send all of the RADIUS attributes. Consult the documentation for your network access server to see which attributes it sends.


You can use these properties to specify the series of RADIUS attributes that are sent back to the RADIUS client by the IAS server, including any vendor-specific attributes you are using. For more information about VSAs, see “Configuring IAS for Compatibility with a Third-Party Access Server” later in this chapter.

Apply Policies to Users and Groups

If you are controlling remote client access by means of groups, you must determine which groups the policies that you create will apply to. If you are using nested groups, make sure that policies configured for the parent group do not conflict with policies configured for the nested group.

If you are controlling remote client access by means of the access-by-user administrative model, you must establish the criteria that you use to determine whether the policy is applied; for example, you can use the client name, client IP address, access server IP address, or any other condition attribute.

Two of the attributes, NAS-Port-Type and Tunnel-Type, deserve special mention because they are used to support VPN, wireless, and authenticating switch access clients:

The NAS-Port-Type attribute. This attribute allows you to specify the type of physical port that is used by the access server originating the request.

The Tunnel-Type attribute. This attribute allows you to specify the type of tunnel that the access server can create. You can specify either Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP).

For a detailed list of condition attributes, see “Connection request policies” in Help and Support Center for Windows Server 2003 and the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Determine Which Restrictions to ApplyYou can specify dial-in conditions or any other profile property to restrict access. For a detailed list of profile properties that can be used to restrict access, see “Introduction to remote access policies” in Help and Support Center for Windows Server 2003 or the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

To achieve the highest level of security possible, begin by granting the least amount of access possible and increase access only when necessary.

NoteElements of a remote access policy correspond to RADIUS attributes that are used during RADIUS-based authentication. For an IAS server, verify that the network access servers that you use are sending the RADIUS attributes that correspond to the configured remote access policy conditions and profile settings. If an access server does not send a RADIUS attribute that corresponds to a remote access policy condition or profile setting, then all RADIUS authentications from that access server are denied.


Configure Client-Specific Remote Access PoliciesDifferent types of remote access clients need different settings in their remote access policies. The following sections describe design considerations for creating the different types of policies.

Configure Remote Access Policies for VPN Clients

For VPN clients, use the Tunnel-Type attribute to specify the type of tunnel that is created by the requesting client. Tunnel types include the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol (L2TP), which are used by remote access clients and demand-dial routers running Windows XP; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; and Windows 2000. You can use this condition to specify profile settings, such as authentication methods or encryption strengths for a specific type of tunneling technology.

Configure Remote Access Policies for Wireless Access Clients

For wireless access clients, create a wireless remote access policy, and then add the condition NAS-Port-Type with the values Wireless-IEEE 802.11 and Wireless-Other.

For more information, see “Wireless access example” in Help and Support Center for Windows Server 2003.

Configure Remote Access Policies for Authenticating Switch Access Clients

For authenticating switch access clients, specify the use of the Ethernet port type for the NAS-Port-Type attribute. By using this port type, you create a separate remote access policy that contains connection parameters specifically designed for authenticating switch nodes.

Configure a Quarantine Remote Access PolicyWhen deploying Network Access Quarantine Control, create a new policy called Quarantine Remote Access Policy, and then choose whether to quarantine clients with IP filters, whether to apply a session timer when clients connect to VPN or dial-up servers, or whether to apply both attributes to the connections. Specify the use of the MS-Quarantine-IPFilter attribute if you want to apply IP filters that restrict client access to the network. Specify the use of the MS-Quarantine-Session-Timeout attribute if you want to set a restriction on the amount of time the client network policy requirements script has to notify the access server that it has run successfully. When you create a Quarantine Remote Access Policy, position it as the first remote access policy so that it is evaluated before other policies.

Quarantine IP filters and session timers are for use only with the Windows Server 2003 Routing and Remote Access service.

For more information, see “Deploying Dial-up and VPN Remote Access Servers” and “Deploying Remote Access Clients Using Connection Manager” in this book.


Securing Your Remote Access StrategyYou can use IAS authentication, authorization, and accounting to secure your remote access solutions. You can also implement security precautions to protect your IAS server and IAS-related traffic. Figure 7.11 illustrates this process.

Figure 7.11 Securing Your Remote Access Strategy


Select Authentication ProtocolsWindows Server 2003 IAS can perform authentication on behalf of any access server that is configured as a RADIUS client. You can use one of a number of protocols to authenticate dial-up, VPN, wireless, and authenticating switch users before allowing them access to the network.

Before you deploy IAS, determine which authentication protocols you will use to authenticate remote access clients. Use the most secure protocols that your network access servers and clients can support. If you need a high degree of security, you can configure IAS to accept only a few very secure authentication protocols. Alternatively, if your organization requires more flexibility, you can configure IAS to accept less secure authentication protocols when attempts to use more secure authentication protocols are unsuccessful.

Table 7.2 lists the authentication protocols that IAS supports and summarizes the conditions for which each protocol is used and the requirements for each protocol.

Table 7.2 Authentication Protocols That IAS Supports

ProtocolType of

Authentication

Protocol Characteristics Protocol Requirements

Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)

Certificate-based

Works for dial-up, VPN, wireless access, and authenticating switch access.

Provides authentication by means of a registry-based user certificate or a smart card.

Provides mutual authentication.

Generates cryptographic keys, which are needed for wireless LAN connections and for dial-up and VPN connections that use Microsoft Point-to-Point Encryption (MPPE).

Enables uninterrupted transfer between wireless access points (user does not need to re-enter credentials when moving between access points).

Enables unauthenticated access for visitors.

IAS must be a member of a Windows 2000 or Windows Server 2003 domain.

Both client and server must support this protocol.

The IAS server must have a certificate installed in the certificate store. The certificate must contain the Server Authentication purpose in EKU extensions. The certificate must meet all other certificate requirements.

The client computer or user certificate must contain the Client Authentication purpose in EKU extensions. The certificate must meet all other certificate requirements. The certificate can be installed in the client computer certificate store or on a smart card.

(continued)


Table 7.2 Authentication Protocols That IAS Supports (continued)

ProtocolType of

Authentication


Protected Extensible Authentication Protocol (PEAP)

Certificate and password-based (depending upon the selected authentication method)

Currently for 802.1X wireless and authenticating switch clients only.

PEAP does not specify an authentication method, but provides a secure “wrapper” for other EAP authentication protocols, such as EAP-MS-CHAPv2, that operate within the outer TLS-encrypted channel provided by PEAP.

Enables uninterrupted transfer between wireless access points (user does not need to re-enter credentials when moving between access points).

Does not allow unauthenticated access for visitors.


The IAS server must have a certificate installed in the certificate store. The certificate must contain the Server Authentication purpose in EKU extensions. The certificate must meet all other certificate requirements.

Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2)

Password-based


Generates cryptographic keys, which are needed for dial-up and VPN connections that use MPPE.

Enables you to change passwords.

Works for dial-up and VPN access.


EAP-MSCHAPv2

Password-based


Generates cryptographic keys, which are needed for dial-up and VPN connections that use MPPE.


IAS must be a member of a Windows 2000 or Windows Server 2003 domain.


(continued)



ProtocolType of

Authentication


Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)

Password-based

Provides encrypted authentication for Microsoft® Windows® 98, Microsoft® Windows® Millennium Edition operating system, or Microsoft Windows NT 4.0 (with the latest dial-up networking upgrade).

Generates cryptographic keys, which are needed for dial-up and VPN connections that use Microsoft Point-to-Point Encryption (MPPE).



Extensible Authentication Protocol-Message Digest 5 (EAP-MD5)

Password-based

Provides less security than EAP-TLS.

Does not generate cryptographic keys.

Works for dial-up and authenticating switch–based access, but not wireless or PPTP-based VPN access.

Requires a reversibly encrypted password to be stored in the account database (local Security Accounts Manager (SAM) or domain).

IAS can be a member of a Windows NT 4.0 domain, a Windows 2000 domain, or a Windows Server 2003 domain.


Challenge Handshake Authentication Protocol (CHAP)

Password-based

Provides encrypted authentication for a combination of different operating systems, such as Macintosh or UNIX operating systems.

Does not generate cryptographic keying material.

Requires a reversibly encrypted password to be stored in the account database (local SAM or domain).

Both client and server must support this protocol and reversibly encrypted passwords.

(continued)



ProtocolType of

Authentication


Password Authentication Protocol (PAP)

Password-based

Provides unencrypted authentication. Use only if clients do not support other protocols.



Unauthenticated Access

Grants access when the remote access client does not supply authentication credentials.



Before the IAS server can access Active Directory–based domains to authenticate user credentials and user access account properties, the IAS server must be registered in those domains.

Integrate IAS with the Certificate InfrastructureWhether you need a certificate infrastructure for IAS depends on whether you are using EAP-TLS as your authentication protocol. If you are using EAP-TLS, you need a certificate infrastructure for your clients. Otherwise, you do not.

A certificate infrastructure consists of the following components:

One or more certificate servers

An IAS server with a certificate

Clients with certificates

For more information about how to design a certificate infrastructure, see “Designing a Public Key Infrastructure” in Designing and Deploying Directory and Security Services of this kit.


When planning how to distribute certificates to clients, decide the following:

Whether to use a computer certificate or a user certificate. Computer certificates are available in Windows Server 2003 and Windows 2000. Use them for servers and for computers on a LAN that do not often move. User certificates are new for Windows Server 2003. Use them for roaming users, such as wireless users.

How to install the certificate. After the certification authority (CA) is configured, you can install a certificate in three ways. Table 7.3 shows each method and when to use it.

Table 7.3 Selecting a Certificate Installation Method

Installation Method When to Use

By using Group Policy to configure auto-enrollment of computer certificates to computers in a Windows Server 2003 domain.

Use this method if you have large numbers of domain member clients that you need to enroll. In this case, setting up a group policy takes less time than manually obtaining certificates.

This method has the advantage that after auto-enrollment is configured and enabled, all domain member computers receive computer certificates when Group Policy is refreshed next, whether the refresh is triggered manually with the gpupdate command, or by logging on to the domain.

If you use auto-enrollment for user certificates, any user with a valid password can obtain a certificate. This makes your certificate authentication the same as password-based authentication.

By using Certificate Manager to obtain a computer certificate.

Use this method if you have only a few computers, such as IAS servers.

By using Microsoft Internet Explorer and Web-based enrollment.

Use this method if the client is not a member of the domain.

Use this method or smart cards for user certificates.

For specific information about how to perform these steps, see “Computer certificates for certificate-based authentication” in Help and Support Center for Windows Server 2003.

For more information about certificate enrollment methods and domain membership, see “Network access authentication and certificates” in Help and Support Center for Windows Server 2003.


Install Computer Certificates for IAS ServersIf you are using PEAP-EAP-MS-CHAPv2 or EAP-TLS, you must install a computer certificate on your IAS servers. That certificate must be issued from a CA that can follow a certificate chain to a root CA that is trusted by the access clients. Likewise, the IAS server must trust the root CA of the CA that issued the user or computer certificate to the access client.

You can install multiple computer certificates on the IAS servers and configure separate remote access policies to use different computer certificates. However, you can select only a single certificate for all remote access policies that specify authentication by using EAP-TLS.

The server certificate must also contain the Server Authentication purpose in Enhanced Key Usage extensions, and meet other certificate requirements for PEAP and EAP authentication.

To install a certificate on the IAS server, you can use Group Policy and auto-enrollment, the CA Web enrollment tool provided with Certificate Services for Windows Server 2003, or you can request a certificate by using the Certificates snap-in.

For more information about certificate requirements for PEAP and EAP, see “Network access authentication and certificates” in Help and Support Center for Windows Server 2003.

Install Computer Certificates for Access ClientsIn addition to adding a certificate to your IAS servers, you must add a certificate to any computer that uses EAP-TLS or PEAP-EAP-TLS authentication. The certificate must be issued from a certification authority (CA) that can follow a certificate chain to a root CA that is trusted by the IAS server.

The computer certificate must also contain the Client Authentication purpose in Enhanced Key Usage extensions and meet other certificate requirements for PEAP and EAP authentication.

For more information about creating a certificate infrastructure, see “Designing a Public Key Infrastructure” in Designing and Deploying Directory and Security Services of this kit.

Secure the IAS RADIUS Server and RADIUS ProxyIt is important to secure your IAS server. Regardless of whether you configure your IAS server as a RADIUS server or a RADIUS proxy, you must apply a number of basic security precautions.

Use strong shared secretsRADIUS supports a simple password called a secret. Configure strong shared secrets to prevent dictionary attacks, and change them frequently. RADIUS secrets are combined with a 16-byte random number and then passed through a one-way Message Digest 5 (MD5) hash to create a 16-byte encryption value. The 16-byte encryption value is stored with the password entered by the remote access user.


Include RADIUS secrets in your remote access design when you are mutually authenticating RADIUS computers and you encrypt the remote user password. It is best to specify RADIUS secrets that are at least 16 characters in length and that include uppercase letters, lowercase letters, numbers, and punctuation.

Use the Message-Authenticator attributeUse the Message-Authenticator attribute (also known as a digital signature or the signature attribute) for connection requests that use the PAP, CHAP, MS-CHAP, and MS-CHAPv2 authentication protocols. This attribute ensures that an incoming RADIUS Access-Request message was sent from a RADIUS client configured with the correct shared secret. You must enable the use of the Message-Authenticator attribute on both the IAS server (as part of the configuration of the RADIUS client) and the RADIUS client (the network access server or RADIUS proxy). Ensure that the RADIUS client supports the Message-Authenticator attribute before you enable the attribute. The Message-Authenticator attribute is always used with EAP, regardless of whether it is enabled on the IAS server and access server.

Configure your Internet firewallIn the most common configuration, the Internet firewall is situated on your perimeter network between your secure network and the Internet. The perimeter network (also known as a screened subnet) is an IP network segment that contains resources (such as Web and VPN servers) that are available to Internet users. In this configuration, the IAS server is an intranet resource that is connected to the perimeter network.

If your IAS server is on a perimeter network, configure your Internet firewall to allow RADIUS messages to pass between your IAS server and RADIUS clients on the Internet. You might need to configure an additional firewall that is placed between your perimeter network and your intranet, which allows traffic to flow between the IAS server on the perimeter network and domain controllers on the intranet.

If your IAS server is on the perimeter network, it might use either of the following to contact a domain controller on the intranet:

An interface on the perimeter network and an interface on the intranet (IP routing is not enabled).

A single interface on the perimeter network. In this configuration, IAS communicates with intranet domain controllers through another firewall that connects the perimeter network to the intranet.

For more information about Internet firewalls, see “Deploying ISA Server” in this book.

Enable remote access account lockoutEnable remote access account lockout to protect against online dictionary attacks. Remote access account lockout disables network access for user accounts after a configured number of failed connection attempts has been reached.


Remote access account lockout can also be used to prevent a malicious user from intentionally locking out a domain account by attempting to make multiple dial-up or VPN connections with the wrong password. You can set the number of failed attempts for remote access account lockout to a number that is lower than the number of logon retries for domain account lockout. By doing this, remote access account lockout occurs before domain account lockout, which prevents the domain account from being intentionally locked out.

For more information about account lockout, see “Remote access account lockout” in Help and Support Center for Windows Server 2003.

Protect Against Access Server VulnerabilitiesSome access servers expose the network to unwanted visitors who can gain access to your network. For example, intruders might connect to an authenticating switch accessible from a conference room network port, set up their own access server to connect to your network, and access your resources. To protect against this form of attack, configure mutual authentication by using PEAP-EAP-MS-CHAPv2 or EAP-TLS as the authentication method for network access connections. For more information about configuring mutual authentication, see “PEAP” in Help and Support Center for Windows Server 2003.

Authenticating RADIUS clients and RADIUS servers also protects against this type of network attack. You can use three methods to authenticate RADIUS clients and RADIUS servers.

RADIUS shared secretsInclude RADIUS shared secrets in your network access design. Specify RADIUS secrets that are at least 22 characters in length and consist of a random sequence of uppercase letters, lowercase letters, numbers, and punctuation.

Secure RADIUS traffic with IPSecSecuring RADIUS traffic with Internet Protocol security (IPSec) provides you with the ability to secure RADIUS servers against unwanted traffic by filtering on specific network adapters (allowing or blocking specific protocols) and enabling you to choose source IP addresses from which traffic is allowed. For organizational units, you can create IPSec policies, which are stored in Active Directory, or you can create local policies on RADIUS servers, and then apply the local policies to specific computers. If you create IPSec policies for an organizational unit, the policy is applied by using Group Policy.

You can enable IPSec between IAS proxies and IAS servers, or between RADIUS clients and IAS servers.

For more information about securing RADIUS traffic with IPSec, see “Securing RADIUS traffic with IPSec” in Help and Support Center for Windows Server 2003.

VPN tunnelsAll RADIUS computers that require authorization support VPNs.


Implementing Your IAS SolutionDeploying IAS involves configuring IAS as a RADIUS server or proxy, optimizing your IAS configuration to best meet your needs, and configuring compatibility with third-party access servers. Figure 7.12 illustrates this process.

Figure 7.12 Implementing Your IAS Solution


Deploying IAS as a RADIUS ServerDeploying IAS as a RADIUS server on your network involves configuring Active Directory, configuring the primary and backup IAS servers, and configuring the access servers. Figure 7.13 illustrates this process.

Figure 7.13 Deploying IAS as a RADIUS Server


Configure User Accounts and GroupsTo configure user accounts and groups, do the following:

1. Ensure that all users that are making remote access connections have a corresponding user account.

2. Set the remote access permission on user accounts to Grant access or Deny access to manage network access by user. Or, to manage network access by group, set the remote access permission on user accounts to Control access through Remote Access Policy.

3. Organize remote access users into the appropriate universal and nested groups in order to take advantage of group-based remote access policies.

4. If you are using CHAP, enable support for reversibly encrypted passwords in the appropriate domains. You can configure reversibly encrypted passwords by using Group Policy. For more information, see “Enable reversibly encrypted passwords in a domain” in Help and Support Center for Windows Server 2003.

5. If you are using certificate-based authentication, configure the domain in which IAS server computers will be members for the auto-enrollment of certificates. With Windows Server 2003, you can auto-enroll both user and computer certificates.

For more information about configuring user accounts for IAS, see “Dial-up and VPN remote access” in Help and Support Center for Windows Server 2003.

For more information about reversibly encrypted passwords, see “Enable reversibly encrypted passwords in a domain” in Help and Support Center for Windows Server 2003.


Configure the Primary IAS Server on a Domain ControllerTo configure the primary IAS server on a domain controller, do the following:

1. On the domain controller, install IAS by using Add/Remove Windows Components. For more information, see “Install IAS” in Help and Support Center for Windows Server 2003.

2. Configure the IAS server to read the properties of user accounts in the domain. For more information, see “Enable the IAS server to read user accounts in Active Directory” in Help and Support Center for Windows Server 2003.

3. If the IAS server authenticates connection attempts for user accounts in other domains, use the Active Directory Domains and Trusts snap-in to verify that these domains have a two-way trust with the domain in which the IAS server is a member. Next, configure the IAS server to read the properties of user accounts in other domains by adding the IAS server to the RAS and IAS Servers security group on all domain controllers with user account databases to be accessed by the IAS server. For more information, see “Enable the IAS server to read user accounts in Active Directory” in Help and Support Center for Windows Server 2003.

4. Enable file logging for accounting and authentication events. You can log session information to text files in either IAS format or database-compatible format, or you can log to a server running SQL Server 2000 or later. In addition, you can configure which information you want to log. For more information, see “Remote access logging” in Help and Support Center for Windows Server 2003.

5. If needed, configure additional User Datagram Protocol (UDP) ports for authentication and accounting messages that are sent by RADIUS clients. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.

6. Add the access servers as RADIUS clients of the IAS server. Verify that you are configuring the correct name or IP address and shared secrets. Enable the use of the Message-Authenticator attribute, but only when it is also supported by the RADIUS client.

7. Create remote access policies that reflect your network access usage scenarios.

8. If you have created new remote access policies, either delete the default remote access policies or move them so that they are the last policies to be evaluated.

For more information about configuring IAS, see “Dial-up and VPN remote access” in Help and Support Center for Windows Server 2003.


Configure the Secondary IAS Server on a Different Domain ControllerTo configure the secondary IAS server on a different domain controller, do the following:

1. On the other domain controller in the same domain, install IAS by using Add/Remove Windows Components. For more information, see “Install IAS” in Help and Support Center for Windows Server 2003.

2. Configure the secondary IAS server to read the properties of user accounts in the domain by adding the IAS server to the RAS and IAS Servers security group. For more information, see “Enable the IAS server to read user accounts in Active Directory” in Help and Support Center for Windows Server 2003.

3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server is a member. Next, configure the secondary IAS server to read the properties of user accounts in other domains by adding the IAS server to the RAS and IAS Servers security group in those domains. For more information, see “Enable the IAS server to read user accounts in Active Directory” in Help and Support Center for Windows Server 2003.

4. Copy the configuration of the primary IAS server to the secondary IAS server.

For more information about copying IAS configuration, see “Copy the IAS configuration to another server” in Help and Support Center for Windows Server 2003.

Configure RADIUS Clients for Use with IAS ServersTo configure each RADIUS client to use the primary and secondary IAS servers for authentication, authorization, and accounting of remote access connections, do the following:

If the RADIUS client is a computer running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition, Windows Server 2003, Datacenter Edition; or Windows 2000 and the Routing and Remote Access service, use the Routing and Remote Access snap-in to configure the RADIUS client to use the primary and secondary IAS servers as RADIUS servers. For more information about configuring the RADIUS client, see “Use RADIUS authentication” and “Use RADIUS accounting” in Help and Support Center for Windows Server 2003.

If the RADIUS client is a computer running Windows NT 4.0 and the Routing and Remote Access Service (RRAS), see Windows NT 4.0 Help for information about how to configure RRAS to use the primary and secondary IAS servers as RADIUS servers for RADIUS authentication.

If the RADIUS client is a third-party network access server, see the documentation for the NAS to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS servers).


Deploying IAS as a RADIUS ProxyDeploying IAS as a RADIUS proxy on your network involves configuring the primary and secondary IAS proxies, configuring the Internet firewalls, and configuring for compatibility with third-party access servers. Figure 7.14 illustrates this process.

Figure 7.14 Deploying IAS as a RADIUS Proxy


Configure the Primary IAS ProxyTo configure the primary IAS proxy in the perimeter network, do the following:

1. On a computer running Windows Server 2003, Standard Edition or Windows Server 2003, Enterprise Edition in the perimeter network, install IAS by using Add/Remove Windows Components. For more information, see “Install IAS” in Help and Support Center for Windows Server 2003. The computer on which IAS is installed does not need to be dedicated to forwarding RADIUS messages. You can install IAS on a computer running other services, such as a DHCP server, a file server, or a DNS server.

2. If needed, configure additional UDP ports for RADIUS messages that are sent by the RADIUS proxies. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.

3. Add the RADIUS proxies as RADIUS clients of the IAS server. Verify that you are configuring the correct name or IP address and shared secrets.

4. Create a remote RADIUS server group that contains the IAS servers in your organization.

5. Create a connection request policy that forwards RADIUS request messages based on the realm name of your organization. For more information about realm names, see “Realm names” in Help and Support Center for Windows Server 2003.

6. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server group and where the realm name matches the realm name of the user accounts in your organization. Clear the check box that removes the realm name for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS servers within your intranet.

7. Delete the default connection request policy named Use Windows authentication for all users.

For more information about configuring IAS proxies in the perimeter network, see “Outsourced dial and a proxy in the perimeter network” in Help and Support Center for Windows Server 2003.

Configure the Secondary IAS ProxyTo configure the secondary IAS proxy in the perimeter network, do the following:

1. On another computer running Windows Server 2003, Standard Edition or Windows Server 2003, Enterprise Edition in the perimeter network, install IAS by using Add/Remove Windows Components. For more information, see “Install IAS” in Help and Support Center for Windows Server 2003.


2. Using Netsh, copy the configuration of the primary IAS proxy to the secondary IAS proxy in the perimeter network.

For more information about copying IAS configuration, see “Copy the IAS configuration to another server” in Help and Support Center for Windows Server 2003.

Configure the Intranet and Internet FirewallsTo support RADIUS traffic, you must take two steps. First, configure the Internet firewall to allow RADIUS traffic between the IAS proxies on the perimeter network and the RADIUS clients on the Internet. Then configure the intranet firewall to allow RADIUS traffic between the IAS proxies on the perimeter network and the IAS servers on the intranet.

Filters on the Internet Interface

Configure the following input packet filters on the Internet interface of the firewall to allow the following types of traffic:

Destination IP address of the IAS server’s perimeter network interface and UDP destination port of 1812 (0x714).

This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the IAS server. This is the default UDP port used by IAS as defined in RFC 2856. If you are using a different port, substitute that port number for 1812, as used in this example.


This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the IAS server. This is the default UDP port used by IAS as defined in RFC 2857. If you are using a different port, substitute that port number for 1813, as used in this example.

Configure the following output filters on the Internet interface of the firewall to allow the following types of traffic:

Source IP address of the IAS server’s perimeter network interface and UDP source port of 1812 (0x714).

This filter allows RADIUS authentication traffic from the IAS server to Internet-based RADIUS clients. This is the default UDP port used by IAS as defined in RFC 2856. If you are using a different port, substitute that port number for 1812, as used in this example.


This filter allows RADIUS accounting traffic from the IAS server to Internet-based RADIUS clients. This is the default UDP port used by IAS as defined in RFC 2857. If you are using a different port, substitute that port number for 1813, as used in this example.


Filters on the Perimeter Network Interface

Configure the following input filters on the perimeter network interface of the firewall to allow the following types of traffic:


This filter allows RADIUS authentication traffic from the IAS server to Internet-based RADIUS clients. This is the default UDP port used by IAS as defined in RFC 2856. If you are using a different port, substitute that port number for 1812, as used in this example.


This filter allows RADIUS accounting traffic from the IAS server to Internet-based RADIUS clients. This is the default UDP port used by IAS as defined in RFC 2857. If you are using a different port, substitute that port number for 1813, as used in this example.

Configure the following output packet filters on the perimeter network interface of the firewall to allow the following types of traffic:


This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the IAS server. This is the default UDP port used by IAS as defined in RFC 2856. If you are using a different port, substitute that port number for 1812, as used in this example.


This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the IAS server. This is the default UDP port used by IAS as defined in RFC 2857. If you are using a different port, substitute that port number for 1813, as used in this example.

For added security, if you know the IP address of each RADIUS client sending the packets through the firewall, you can configure more specific filters for traffic between the IP address of the RADIUS client and the IP address of the IAS server on the perimeter network.

For more information about configuring packet filters, see “Manage Packet Filters” and “Apply packet filters for business partner extranet” in Help and Support Center for Windows Server 2003.


Configure RADIUS Clients for Use with IAS ProxiesTo configure each RADIUS client to use the primary and secondary IAS proxies, do the following:

If the RADIUS client is a computer running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; or Windows 2000 and the Routing and Remote Access service, use the Routing and Remote Access snap-in to configure the RADIUS client to use the primary and secondary IAS servers.

If the RADIUS client is a computer running Windows NT 4.0 and the Routing and Remote Access Service (RRAS), see Windows NT 4.0 Help for information about how to configure RRAS to use the primary and secondary IAS proxies as RADIUS servers.

If the RADIUS client is a third-party network access server, see the documentation for the NAS to determine how to configure it as a RADIUS client with two RADIUS servers.

For more information about configuring RADIUS accounting and authentication, see “Use RADIUS accounting” and “Use RADIUS authentication” in Help and Support Center for Windows Server 2003.

Configuring IAS for Compatibility with Third-Party Access ServersIf you are using Windows Server 2003 IAS with a third-party access server, you might need to configure the IAS server to prevent it from sending the class attribute. Specifically, if the IAS server sends the class attribute, some network access servers require the use of certain vendor-specific attributes to be included in the class attribute.

Alternatively, you can configure vendor-specific attributes and custom attributes to enable compatibility with a third-party access server.

For more information about how to configure the class attribute, see “Add RADIUS attributes to a remote access policy” in Help and Support Center for Windows Server 2003. For more information about configuring IAS for compatibility with a third-party access server, see “IAS as a RADIUS server design considerations” in Help and Support Center for Windows Server 2003.


Configure Vendor-Specific AttributesIAS allows administrators to associate specific RADIUS attributes with each remote access policy. These attributes are described in RFC 2865. In addition to the standard RADIUS attributes, some access server manufacturers use vendor-specific attributes (VSAs) to provide functionality that is not supported in standard attributes.

If your access server manufacturer uses VSAs, you might need to associate those VSAs with remote access protocols so that your access server processes authentication requests properly. IAS enables you to create or edit VSAs to take advantage of proprietary functionality supported by some access server vendors.

To provide access server–specific support, you can add vendor-specific attributes to remote access policies. IAS includes VSAs from some vendors in its dictionary. You cannot add other VSAs to the dictionary.

To configure IAS to support vendor-specific attributes, complete the following steps:

1. Determine which vendor-specific attributes the access server requires. The third-party access server manufacturer documentation provides information about the individual attributes that must be specified.

2. Determine which attributes are standard RADIUS attributes and which require the addition of vendor-specific RADIUS attributes (attribute type 26). For more information, see “Interpreting IAS-formatted log files” in Help and Support Center for Windows Server 2003.

3. Specify the attribute values for the VSAs in the IAS remote access policy. When you add VSAs to the remote access policy profile to support proprietary functionality for your access point, you must determine whether the VSA conforms to the format recommended in RFC 2865. If it does, you must specify a network access vendor by either name or vendor code, a vendor-assigned attribute number, the attribute format (that is, the type of data, such as string or hexadecimal), and the attribute value. If it does not, you must specify a network access vendor by either name or vendor code and a hexadecimal attribute value that represents the attribute data. For more information, see “Vendor-specific attribute overview” in Help and Support Center for Windows Server 2003.

Configure Custom AttributesThe IAS Software Development Kit (SDK), part of the Windows Server 2003 SDK, allows you to configure your IAS server to send custom attributes to the access server in addition to standard attributes. This enables you to build your own extension to the IAS snap-in.

For more information about configuring custom attributes, see the Software Development Kit (SDK) information in the MSDN Library link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.


Additional ResourcesThese resources contain additional information and tools related to this chapter.

Related Information The Networking Guide of the Windows Server 2003 Resource Kit (or see he Networking

Guide on the Web at http://www.microsoft.com/reskit) for more information about Internet Authentication Service.

“Deploying Remote Access Clients Using Connection Manager” in this book.

“Designing a Public Key Infrastructure” in Designing and Deploying Directory and Security Services of this kit for more information about how to design a certificate infrastructure.

“Deploying Dial-Up and VPN Remote Access Servers” in this book.

“Deploying a Wireless LAN” in this book for information about deploying wireless access clients.

RFC 2865: Remote Authentication Dial In User Service (RADIUS).

RFC 2866: RADIUS Accounting.

RFC 2869: RADIUS Extensions.

Related Help TopicsFor best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set search options. Under Help Topics, select the Search in title only checkbox.

“Internet Authentication Service” in Help and Support Center for Windows Server 2003.

“Remote access policies” in Help and Support Center for Windows Server 2003.

“IAS as a RADIUS server” in Help and Support Center for Windows Server 2003.

“Deploying IAS as a RADIUS proxy” in Help and Support Center for Windows Server 2003.

“Compulsory tunnels” in Help and Support Center for Windows Server 2003 for information about the RADIUS attributes used with compulsory tunneling.

“Computer certificates for certificate-based authentication” in Help and Support Center for Windows Server 2003.

“Dial-up and VPN remote access” in Help and Support Center for Windows Server 2003 for more information about configuring user accounts for IAS.

“Copy the IAS configuration to another server” in Help and Support Center for Windows Server 2003 for more information about copying IAS configuration.


“Outsourced dial and a proxy in the perimeter network” in Help and Support Center for Windows Server 2003 for more information about configuring IAS proxies in the perimeter network.

“Add RADIUS attributes to a remote access policy” in Help and Support Center for Windows Server 2003 for more information about how to configure the class attribute.

“Manage packet filters” in Help and Support Center for Windows Server 2003 for more information about configuring packet filters.

“Use RADIUS accounting” and “Use RADIUS authentication” in Help and Support Center for Windows Server 2003 for more information about configuring RADIUS accounting and authentication.

“Managing multiple IAS servers” in Help and Support Center for Windows Server 2003 for more information about synchronizing the configuration of multiple IAS servers.

“Configure accounting” in Help and Support Center for Windows Server 2003 for more information about using separate IAS servers for authentication and accounting.

“Configure authentication” in Help and Support Center for Windows Server 2003.

“Configure encryption” in Help and Support Center for Windows Server 2003.

“PEAP” in Help and Support Center for Windows Server 2003.

“Network access authentication and certificates” in Help and Support Center for Windows Server 2003 for more information about certificate enrollment methods and domain membership

deploying ias

Documents