Exploring RADIUS Server Scenarios
The basic purpose of a
RADIUS server is to centralize remote access authentication,
authorization, and logging. RADIUS is useful, for example, in large
organizations such as ISPs that need to manage many remote access
connections to separate remote access servers.
Figure 4
illustrates such a scenario, in which dial-up users connect to an ISP
in four different cities. The network access servers, running Routing
And Remote Access, forward remote access requests to a RADIUS server by
means of the RADIUS protocol. The RADIUS server then communicates with
the domain controller for user authentication. After user
authentication, remote access policies defined on the RADIUS server are
applied to the connection. If the remote access connection is
authorized, the RADIUS server communicates with the network access
server to allow network access. If not, network access is denied.
RADIUS servers also
enable smaller organizations to centralize remote access management when
a variety of remote access methods are supported, such as VPN,
wireless, and dial-up. By deploying a central point of authorization,
the organization can direct separate, medium-specific access requests
toward a single set of remote access policies, as shown in Figure 2.
Finally,
although in a traditional implementation the RADIUS server is deployed
on a separate computer, the RADIUS server can also be deployed on a
network access server. In this scenario, network access requests
reaching the external interface of the server are handled by the Routing
And Remote Access service. The Routing And Remote Access service then
forwards these remote access requests to the IAS service, which is
associated with the internal IP address of the same computer. This IAS
service acts as a RADIUS server not only for RADIUS requests originating
from the local machine, but also for RADIUS requests originating from
other network access servers throughout the network. Figure 3 illustrates this scenario.
Exploring RADIUS Proxy Scenarios
In
Windows Server 2003, you can also deploy the IAS service as a RADIUS
proxy. In this type of implementation, network access servers are
configured to forward authentication and accounting to an IAS server,
which is then configured as a RADIUS proxy to forward these messages to a
RADIUS server group.
A RADIUS server group
is a group of one or more RADIUS servers for which network access
requests are load balanced dynamically by the RADIUS proxy. Each RADIUS
server group represents a distinct set of remote access policies for a
domain, forest, or organization. Separate RADIUS server groups can be
defined for separate forests, Kerberos realms, or untrusted domains. Connection request policies
can be defined at the RADIUS proxy to sort network access requests
according to attribute-matching conditions (such as a specific user or
realm name) and relay these requests to the appropriate RADIUS server
group.
Figure 4 illustrates IAS deploying a RADIUS proxy between RADIUS clients (access servers) and a single RADIUS server group.
The following list describes a few of the scenarios in which RADIUS proxies are designed to be implemented:
You are a
service provider that offers outsourced network access services to
multiple customers. Through connection request policies, the RADIUS
proxy can read the realm name attribute in various connection requests
and route these requests to the appropriate customer’s RADIUS server.
You
want to provide authentication and authorization for user accounts that
are not members of a domain trusted by the IAS server domain. Through
connection request policies, the RADIUS proxy can read the realm name
attribute in various connection requests and route these requests to the
appropriate domain’s RADIUS server.
You
want to process a large number of connection requests as efficiently as
possible. For this task, the RADIUS proxy dynamically balances the load
of connection and accounting requests across multiple RADIUS servers
and improves processing efficiency.
