In part two of this
tutorial, we considered using a managed RADIUS <DEFINE: RADIUS> service
to support 802.1X Access Control for Wireless LANs. Here, we conclude our three-part
tutorial by illustrating what it takes to configure an in-house RADIUS Server
for authenticating wireless users.
Choosing A RADIUS Server Package
It’s important to choose the right flavor of RADIUS Server to meet your business
needs. Some RADIUS Servers are general-purpose products that support different
kinds of Network Access Servers, while others are narrowly-focused on wireless
LANs. Some are simplified for small single-network use, while others are scalable,
distributed systems designed for large ISPs and carriers.
For example, Funk Software packages its
RADIUS engine in several formats:
- Odyssey, for corporate WLANs using 802.1X port access control
- Steel-Belted RADIUS (SBR) Enterprise, for both remote access and
WLAN - SBR Global Enterprise Edition, for companies with many sites
- SBR Service Provider Edition, for ISP remote access
- SBR EAP Expansion Module, adds 802.1X to SBR/SPE
- SBR Hotspot Edition, for browser-based and 802.1X authentication
If your company already has a RADIUS Server for remote access authentication,
you may be able to leverage that Server to add WLAN authentication. Or you might
install a new RADIUS Server for WLAN authentication only, with the option to
forward Access-Requests from your new server to your existing server.
If you’re starting fresh, then consider whether LAN authentication is all that
you’ll need. 802.1X can be used to control access in both wireless and wired
LANs, but do you also need to authenticate remote access users — for example,
teleworkers and travelers who access your network from the Internet over VPN
tunnels? Obviously you don’t have to use the same RADIUS Server for both, but
doing so might be more economical.
If you’re a hotspot operator, you probably already use RADIUS to account for
subscribers who log into your Web portal. 802.1X rarely appears in hotspots
today, but that may change soon. If Microsoft has its way, hotspot operators
will run Windows
Provisioning System (WPS) on Windows 2003 Servers to configure stations
for 802.1X, making login more transparent. T-Mobile
is now testing 802.1X with WPS in some of its hotspots, and hopes to roll this
upgrade out in 2Q04. Windows XP stations equipped with the WPS patch will be
able to use transparent 802.1X login, while others will still authenticate interactively
using browsers. Until demand for 802.1X in hotspots is clear, operators may
want to sit tight, letting enterprises cut their teeth on 802.1X first.
Also consider whether your RADIUS Server will be supporting access points (APs)
at a single site or multiple sites. If multiple sites, consider running RADIUS
Servers at each location to distribute load and optimize performance. Those
RADIUS Servers may operate independently, but can rely upon a common (replicated)
user database — for example, your Windows domain. Alternatively, you could
create a hierarchy of RADIUS Servers where site servers relay Access-Requests
to a central server, co-located with your user database. A centralized approach
can pose performance and reliability concerns, but may be necessary if you can’t
replicate your user database to every site.
In-House Server Example: Funk Odyssey
After you’ve selected a RADIUS Server product, it’s time for installation and
configuration. Set-up details vary from product to product. For example, most
are software installed on off-the-shelf hardware of your choosing, but some
are pre-loaded appliances. Some RADIUS Servers are configured largely through
text files, while others sport graphical dashboards. Even though these details
differ, the tasks that must be completed are fairly consistent:
- Get the RADIUS service up and running.
- Issue a certificate to your RADIUS Server.
- Configure your RADIUS Server to accept selected
EAP Types. - Specify criteria used to map station identities
to users and groups. - Integrate your RADIUS Server with user databases
and other Servers. - Enable communication between your APs and
your RADIUS Server. - Launch a few 802.1X sessions to test your
RADIUS Server. - Review logs and accounting records to verify
that your Server is operational.
To illustrate, let’s take a look at one RADIUS Server focused exclusively on
WLAN authentication: Funk Odyssey.
Odyssey Server software must be installed on a PC running Windows XP Pro or
Windows 2000. Odyssey must be the only program listening to the RADIUS ports,
usually UDP/1812 (authentication) and 1813 (accounting). These ports can be
changed but must match those configured into all of your Access Points. Odyssey
runs as a service that starts automatically. All configuration changes are made
through a Windows MMC snap-in called the Odyssey Server Administrator (see Figure 1).
Start by issuing a digital certificate to your Odyssey Server. This server
certificate will be used whenever a TLS (SSL) tunnel is launched, letting stations
authenticate your Server. If you don’t have a Certificate Authority (CA), certificates
can be purchased from a managed PKI service like Verisign
or SeqID ProviderTrust.
Funk supplies a test certificate generator which can be used to create a server
certificate for Odyssey trials but not for production use.
The certificate must be installed in the Server’s Local Computer’s Personal
Certificate Store, then is bound to Odyssey using the TLS Settings panel. TLS
security parameters can also be configured — for example, choosing acceptable
key exchange, encryption, and message integrity algorithms. You must then select
one or more EAP Types
to be used with 802.1X, defined in priority order. The Server illustrated in
Figure 1 will first try to authenticate stations using EAP-TLS. If that fails,
it will try EAP-TTLS, then LEAP.
When EAP-TLS is used, the RADIUS Server must know which user certificates to
trust (see Figure 2).
The Server can trust all certificates issued by a given CA, or it can be more
selective — for example, trusting only certificates issued to subjects in a
specified domain (e.g., anyuser@mycompany.com). But trusting a user certificate
is not enough — the Server must map the station’s identity to a user database
that determines whether access is allowed. This can be based on part or all
of the Subject’s Common Name (CN) or SubjectAltName in the user’s certificate.
Because all permitted mappings will be tried when authenticating via EAP-TLS,
it is best to minimize selected options.
Next, the RADIUS server must be configured with policies that determine which
users and groups are permitted to access the WLAN, along with session parameters
like timeout (see Figure 3).
This step depends upon the EAP Type and user database or external authentication
server to be consulted.
For example, Odyssey is optimized to authenticate WLAN users against login
names and passwords stored in Windows user databases (i.e., Active Directory
or NT Domain). Odyssey policies therefore explicitly allow or deny access by
Windows User and Group names known to the Odyssey Server. When using EAP-TLS,
these names are presented in user certificates; when using PEAP or EAP-TTLS,
they are delivered over TLS tunnels that carry an authentication protocol like
MS-CHAPv2. As shown in Figure 3, the
Server can be configured to handle requests locally or forward them to another
domain.
RADIUS Access-Requests that should be forwarded to another domain are relayed
to another RADIUS Server (see Figure 4).
Larger networks may have multiple RADIUS Servers to balance load or serve as
stand-bys. Separate RADIUS Servers may be designated to handle Access-Requests
from users in different domains — for example, to authenticate roaming users
against their home network’s user database.
Requests can also be forwarded it is necessary to consult another kind of user
database. For example, Odyssey can be configured to forward requests to a Funk
SBR/Enterprise Server to authenticate against records stored in an LDAP directory,
SQL or ODBC database, or RSA ACE/Server. Integration with existing user databases
and external authentication servers should be considered when choosing your
RADIUS Server so that your solution can reach all required data with optimum
performance and reliability.
Before you can test your RADIUS Server, it must be configured to communicate
with your WLAN’s Access Points. The Server must be given the IP address(es)
of every AP and a shared secret used to authenticate communication with that
AP (see Figure 5).
At the opposite end, each AP must be configured with the RADIUS Server’s domain
name or IP address, authentication and accounting port numbers, and the same
shared secret. Configuration differs slightly for each AP; Funk offers several
Quick Start Guides
to illustrate common enterprise APs like the Proxim AP-2000 and Cisco Aironet
340/350/1200. Wireless APs and cards that have been tested with Odyssey are
enumerated on Funk’s
Website. For best results, use a supported combo, but you may also be able
to use an AP or card that’s not yet been tested.
An extra step is needed when Network Address Translation (NAT) exists between
the AP and RADIUS Server. For example, your APs may be located on the far side
of a wireless gateway that NATs traffic from the wireless LAN. In that case,
define static NAT bindings for each AP so that they can be individually authenticated
by your RADIUS Server. You may also need to modify gateway or firewall rules
so that RADIUS flows between these endpoints.
Stations on your WLAN can launch test sessions to validate your RADIUS Server
configuration. To trouble-shoot and diagnose problems, consult the RADIUS Server’s
logfile. Traffic analyzers on wireless and wired LAN segments can also prove
helpful in determining where messages are being blocked or where 802.1X authentication
is failing. Problems may include mismatched IPs/ports/secrets (dropped packets
from between the AP and RADIUS Server), Server authentication failure (TLS session
rejected), and user authentication failure (802.1X ends with RADIUS Access-Reject).
Diagnosing the failure reason may require digging into the RADIUS Server’s log,
since much of the exchange is encrypted. A RADIUS test client like the one freely
available from IEA
Software can also be helpful.
Conclusion
In this article, we’ve illustrated just one RADIUS Server. Product user interfaces
and features differ, but we hope this example gives you a feel for what it takes
to set up a RADIUS Server for use with 802.1X. To learn more about setting up
this and other RADIUS Servers, consult the vendor Web sites listed in part two of this
tutorial.
As we have seen, there are many ways to add RADIUS authentication to your WLAN,
ranging from managed services to shareware to commercial products, small and
large. Acronyms and security jargon make 802.1X port access control somewhat
daunting. We hope that this tutorial helps to demystify the role of RADIUS and
provides a starting point for using 802.1X to keep wireless intruders away.
