Deploying IAS

C H A P T E R 7
Deploying IAS
Servers 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........................................................................... ......62
Designing IAS............................................................................................ ............70
Designing an Optimized IAS Solution........................................... .........................85
Creating a Remote Access Policy Strategy.................................... ........................93
Securing Your Remote Access Strategy.............................................. .................101
Implementing Your IAS Solution.............................................. ............................110
Additional Resources.............................................................................. .............121
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.
62 Chapter 7 Deploying IAS
Overview of IAS Deployment

You 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 63
IAS Deployment Process

The 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 Concepts
IAS 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 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.
Internet Authentication Service (IAS) 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.
Remote Authentication Dial-In User Service (RADIUS) protocol A protocol, specified in RFCs
2138 and 2139, that enables use of a homogeneous or heterogeneous network of dial-up or VPN equipment.
RADIUS serverA server that implements the RADIUS protocol. A RADIUS server performs
authentication, authorization, and accounting on behalf of a RADIUS client.
RADIUS client
A network access server that uses a RADIUS server to perform authentication,
authorization, and accounting for its access clients.
RADIUS proxyA 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.
Authentication
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.
Authorization
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.
Auditing
The process that tracks the activities of users by recording selected types of events in the
security log of a computer.
Accounting
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.
Designing IAS
After 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 Environment

When 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 Server

You 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 ISP
You 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 forests

You 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 balancing

You 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 Server

Designing 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
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-TLS
Certificate-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.
PEAP
PEAP 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 Connections
For 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
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 Proxy

Designing 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 policy
The 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 VSAs
If 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 detection
When 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 proxies

To 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 Access

After 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
Note
You 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.
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.
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
When to Use It Which IAS Components to
Tunnel Type
Use
Voluntary Use this option if your clients The ISP uses IAS as a
tunneling need to choose their RADIUS proxy to forward the
tunneling location request to the corporate IAS
themselves. server.
For example, the user dials in The corporation uses IAS as
to an ISP. At the client’s a RADIUS server to
request, the ISP creates a authorize and authenticate
tunnel to the corporation. The the request.
user can alternatively request Either the ISP or the
a tunnel to somewhere else, corporation can use a third-
such as the Internet. party RADIUS server.
Compulsory Use this option if you want to The ISP uses IAS as a
tunneling use one tunnel for many RADIUS server to authorize
clients. the request.
For example, if a corporation The corporation uses IAS as
has clients in geographically a RADIUS server to
dispersed locations, it can authorize and authenticate
contract with an ISP to deploy the request.
regional tunnel servers. Any Either the ISP or the
client can dial in to any of the corporation can use a third-
tunnel servers, which then party RADIUS server.
creates a compulsory tunnel
to the corporation.
Compulsory tunneling is
typically used for dial-up
clients, but can also be used
for VPN clients.
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 Access

Depending 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
Designing Support for Wireless Access

Wireless 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 Access

A 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
• 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

Solution
Optimize 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

Performance
IAS 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
Add IAS Servers to Optimize Availability

It 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

Servers
If 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 Configurations

When 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 Performance

Because 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 Accounting

RADIUS 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.
Caution
Do 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.
For more information, see “Remote access logging” in Help and Support Center for Windows Server 2003.
Optimize IAS Deployment in Large

Organizations
You 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.
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
• 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
Caution
Do 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
Creating a Remote Access Policy

Strategy
Remote 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
Establish a Remote Client Access

Authorization Method
You 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 Groups

You 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 more information about functional levels, see “Domain and forest functionality” in Help and Support Center
Plan the User Accounts

In 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
Configure Remote Access Policies

You 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
• 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 Control

Network 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 Policies

You 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
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).
Note
Not all network access servers send all of the RADIUS attributes.
Consult the documentation for your network access server to see
which attributes it sends.
Conditions
Specify 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.
Permission
Specify 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.
Profile
Specify 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.
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.
Note
Elements of a remote access policy correspond to RADIUS attributes
that are used during RADIUS-based authentication. For an IAS server,
verify that the network access servers that you use are sending the
RADIUS attributes that correspond to the configured remote access
policy conditions and profile settings. If 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.
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
Determine Which Restrictions to Apply

You 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
To achieve the highest level of security possible, begin by granting the least amount of access possible and
increase access only when necessary.
Configure Client-Specific Remote Access Policies

Different 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 Policy

When 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

Strategy
You 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 Protocols

Windows 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
Type of
Protocol Authentic Protocol Characteristics Protocol Requirements
ation
Extensible Certificate Works for dial-up, VPN, IAS must be a member
Authentication -based wireless access, and of a Windows 2000 or
Protocol- authenticating switch Windows Server 2003
Transport Layer access. domain.
Security (EAP- Provides authentication Both client and server
TLS) by means of a registry- must support this
based user certificate or protocol.
a smart card. The IAS server must
Provides mutual have a certificate
authentication. installed in the
Generates cryptographic certificate store. The
keys, which are needed certificate must contain
for wireless LAN the Server
connections and for Authentication purpose
dial-up and VPN in EKU extensions. The
connections that use certificate must meet
Microsoft Point-to-Point all other certificate
Encryption (MPPE). requirements.
Enables uninterrupted The client computer or
transfer between user certificate must
wireless access points contain the Client
(user does not need to Authentication purpose
re-enter credentials in EKU extensions. The
when moving between certificate must meet
access points). all other certificate
requirements. The
Enables unauthenticated
certificate can be
access for visitors.
installed in the client
computer certificate
store or on a smart
card.
(continued)
Table 7.2 Authentication Protocols That IAS Supports (continued)

Type of
ation
Protected Certificate Currently for 802.1X Both client and server
Extensible and wireless and must support this
Authentication password authenticating switch protocol.
Protocol -based clients only. The IAS server must
(PEAP) (dependin PEAP does not specify have a certificate
g upon an authentication installed in the
the method, but provides a certificate store. The
selected secure “wrapper” for certificate must contain
authentic other EAP the Server
ation authentication Authentication purpose
method) protocols, such as EAP- in EKU extensions. The
MS-CHAPv2, that certificate must meet
operate within the outer all other certificate
TLS-encrypted channel requirements.
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.
Microsoft Password Provides mutual Both client and server
Challenge -based authentication. must support this
Handshake Generates cryptographic protocol.
Authentication keys, which are needed
Protocol for dial-up and VPN
version 2 (MS- connections that use
CHAPv2) MPPE.
Enables you to change
passwords.
Works for dial-up and
VPN access.
EAP- Password Provides mutual IAS must be a member
MSCHAPv2 -based authentication. of a Windows 2000 or
Generates cryptographic Windows Server 2003
keys, which are needed domain.
for dial-up and VPN Both client and server
connections that use must support this
MPPE. protocol.
passwords.
(continued)

Type of
Protocol Authentica Protocol Characteristics Protocol Requirements
tion
Microsoft Password- Provides encrypted Both client and server
Challenge based authentication for must support this
Handshake Microsoft® protocol.
Authentication Windows® 98,
Protocol (MS- Microsoft®
CHAP) 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).
passwords.
Extensible Password- Provides less security Requires a reversibly
Authentication based than EAP-TLS. encrypted password to
Protocol- Does not generate be stored in the
Message cryptographic keys. account database
Digest 5 (EAP- (local Security
Works for dial-up and
MD5) Accounts Manager
authenticating switch–
(SAM) or domain).
based access, but not
wireless or PPTP-based IAS can be a member
VPN access. of a Windows NT 4.0
domain, a
Windows 2000 domain,
or a Windows
Server 2003 domain.
Both client and server
must support this
protocol.
Challenge Password- Provides encrypted Requires a reversibly
Handshake based authentication for a encrypted password to
Authentication combination of different be stored in the
Protocol operating systems, such account database
(CHAP) as Macintosh or UNIX (local SAM or domain).
operating systems. Both client and server
Does not generate must support this
cryptographic keying protocol and reversibly
material. encrypted passwords.
(continued)

Type of
ation
Password Password Provides unencrypted Both client and server
Authentication -based authentication. Use only must support this
Protocol (PAP) if clients do not support protocol.
other protocols.
Does not generate
cryptographic keying
material.
Unauthenticate Grants access when the Both client and server
d Access remote access client must support this
does not supply protocol.
authentication
credentials.
Does not generate
cryptographic keying
material.
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

Infrastructure
Whether 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 Use this method if you have large numbers of
configure auto-enrollment domain member clients that you need to enroll. In
of computer certificates to this case, setting up a group policy takes less time
computers in a Windows than manually obtaining certificates.
Server 2003 domain. 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 Use this method if you have only a few computers,
Manager to obtain a such as IAS servers.
computer certificate.
By using Microsoft Use this method if the client is not a member of the
Internet Explorer and Web- domain.
based enrollment. 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 Servers

If 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 Clients

In 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 Proxy
It 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 secrets
RADIUS 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 attribute
Use 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 firewall
In 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 lockout
Enable 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
Protect Against Access Server Vulnerabilities

Some 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 secrets
Include 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 IPSec
Securing 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
VPN tunnels
All RADIUS computers that require authorization support VPNs.
Implementing Your IAS Solution

Deploying 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 Server

Deploying 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 Groups

To 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
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 Controller

To 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
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
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
Configure the Secondary IAS Server on a Different Domain

Controller
To 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
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
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
Configure RADIUS Clients for Use with IAS Servers

To 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 Proxy

Deploying 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 Proxy

To 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
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 Proxy

To 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
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
Configure the Intranet and Internet Firewalls

To 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.
port of 1813 (0x715).
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
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.
(0x715).
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
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:
(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.
(0x715).
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
Configure the following output packet filters on the perimeter network interface of the firewall to allow the
following types of traffic:
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
port of 1813 (0x715).
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
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 Proxies

To 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 Servers
If 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
Configure Vendor-Specific Attributes

IAS 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
Configure Custom Attributes

The 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 Resources
These 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 Topics
For 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
• “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

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Deploying IAS

Hochgeladen von

Copyright:

Verfügbare Formate

C H A P T E R 7

Overview of IAS Deployment

IAS Deployment Process

New in Windows Server 2003

IAS Terms and Definitions

Inventory Your Current Environment

Determine the Role of the IAS Server

Using IAS proxy with multiple forests

Using IAS proxy for load balancing

RADIUS server and proxy

Design IAS as a RADIUS Server

Determine IAS Server Domain Membership

Plan for RADIUS Clients

Add RADIUS or VSA Attributes to Remote Access Policy

Install Backup IAS Servers

Design IAS as a RADIUS Proxy

Install backup RADIUS proxies

Designing Support for Client Access

Designing Support for Dial-up Access

Designing Support for VPN Access

Special Considerations for VPN Access

Designing Support for Wireless Access

Countering Wireless Security Risks

Special Considerations for Wireless Access

Designing Support for Authenticating Switch Access

Securing Authenticating Switch Access with IAS

Special Considerations for Authenticating Switch Access

Designing an Optimized IAS

Scale an IAS Server to Optimize

Add IAS Servers to Optimize Availability

Use Load Balancing with Multiple IAS

Duplicate IAS Server Configurations

Optimize RADIUS Client Performance

Optimize Authentication and Accounting

• Use the MaxConcurrentApi registry entry

Optimize IAS Deployment in Large

Creating a Remote Access Policy

Establish a Remote Client Access

Plan Remote Access Policy Groups

Plan the User Accounts

Configure Remote Access Policies

Using Network Access Quarantine Control

Using Common vs. Custom Policies

Create Specifications for a Common Policy

Create Specifications for a Custom Policy

Apply Policies to Users and Groups

Determine Which Restrictions to Apply

Configure Client-Specific Remote Access Policies

Configure Remote Access Policies for VPN Clients

Configure Remote Access Policies for Wireless Access Clients

Configure Remote Access Policies for Authenticating Switch Access

Configure a Quarantine Remote Access Policy

Securing Your Remote Access

Select Authentication Protocols

Table 7.2 Authentication Protocols That IAS Supports (continued)

Table 7.2 Authentication Protocols That IAS Supports (continued)

Table 7.2 Authentication Protocols That IAS Supports (continued)

Integrate IAS with the Certificate

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

Install Computer Certificates for IAS Servers

Install Computer Certificates for Access Clients

Secure the IAS RADIUS Server and

Protect Against Access Server Vulnerabilities