Although Windows Integrated Authentication is generally the
preferred authentication method for Windows Servers, in some situations, it
just won’t do. If users are connecting to your network from a remote location,
such as a dial-in connection, a VPN, or a wireless network, you may find
yourself having to authenticate those users via a RADIUS server.

RADIUS, or Remote Authentication Dial-In User Service, has
been around in one form or another for a long time and is generally the
authentication mechanism used by Internet service providers. Microsoft included
a RADIUS server in Windows 2000, but changed its name to Internet
Authentication Service (IAS) in Windows Server 2003.

IAS is relatively easy to configure, and there are ways to
tighten security on IAS authentication. In this article, I’ll explain how IAS
works and how you can configure it for optimum performance and security.

A crash course in IAS

Before I show you how to optimally configure IAS, it’s
important that you understand what IAS is and how it works. The trickiest part
is getting the terminology down. In a RADIUS environment, you have a remote
client that needs access to a resource on a private network. In Microsoft-speak,
these remote clients are known as access clients.

Before an access client can connect to the private network, you
must have a mechanism through which the connection is to be made. This
mechanism can be a dial-in server, a VPN server, or even a wireless access
point. Regardless of what device is being used, it’s referred to as the access
server (RADIUS client). The reason for this bizarre name is because the access
clients are treating the device as a server through which they are connecting.
The device must then communicate with the RADIUS server. The device is acting
as a server to the access clients, but is acting as a client to the RADIUS
server, hence the name access server (RADIUS client).

In a simple IAS implementation, the next component in the
chain is the IAS server itself (Microsoft tends to use the term RADIUS server interchangeably). The IAS server is the mechanism that
actually processes the requests made by access clients. Processing these
requests is based on rules. When the IAS server receives a request, it compares
the request to the rules and then issues an Access-Accept or an Access-Reject
message that is sent back to the access client. Even if the IAS server sent an
access client an Access-Accept message, the message could contain connection
restrictions.

Although the IAS server actually makes the Access-Accept or
Access-Reject decision, it still needs to consult a database to determine
whether the user’s credentials are valid. Out of the box, IAS can use several databases
for this purpose. The supported databases are the local Security Accounts
Manager (SAM), a Windows NT 4.0 domain, or Active Directory. Generally, these
database types can be used if the IAS server is a member of the same domain as
the server with the database, or if a two-way trust exists between the domain
containing the database and the domain containing the IAS server. Forest-level
trusts are also supported, but only in Windows Server 2003 environments.

The final RADIUS component you need to be aware of is a
RADIUS proxy, which can be used in large environments with multiple RADIUS servers.
For example, suppose an organization had a single VPN connection, but had
multiple RADIUS servers connecting to multiple private network segments. In
such a case, a RADIUS proxy would be used to route RADIUS messages between the
access client and the appropriate RADIUS server.

Obviously, IAS has several components. Just in case you
aren’t completely clear as to what a certain component is or does, I’ve created
the illustration shown in Figure A
to help you out.

Figure A

This is how the various RADIUS components work together.

Best practices for deploying RADIUS

The first best practice is to build your network one step at
a time, testing between each step. For example, suppose you’re planning on
using RADIUS to authenticate users who access your network through a wireless
access point. You should test the access server before you put the RADIUS
server in place. Since the access server is a wireless access point, just
connect the access point to your network for a few minutes and make sure that a
wireless client can pass through the access point and gain access to your
network.

I’m sure there are some who probably disagree with me on
this particular point because of security reasons. I admit that in normal, day-to-day
situations, it’s a bad idea to connect a wireless access point directly to your
network without having some sort of authentication mechanism in place. At the
same time, though, I’ve lost count of the number of times I’ve seen a bad Wi-Fi
card or had an access point that just didn’t want to cooperate.

Your life will be a lot easier if you can verify that the
wireless hardware is working properly before you put RADIUS in place. Unless
you work for the Pentagon or something, plugging up an access point just long
enough to verify connectivity shouldn’t cause a major security problem.

Multiboot problems

You should run only Windows Server 2003 on your RADIUS server.
I recently heard about someone who had been running RADIUS on Windows 2000
Server for quite some time with no problems. His company was pressuring him to
upgrade the RADIUS server to Windows Server 2003. However, the RADIUS server
had worked so well under Windows 2000 that he decided to create a parallel
Windows installation for Windows Server 2003 rather than overwrite his Windows
2000 configuration.

Although the Windows 2003 installation worked as intended, he
decided to go back to using Windows 2000 Server. Since he had set up the server
using a dual boot configuration, he simply booted the server into Windows 2000
and expected everything to work as it had previously. However, RADIUS no longer
worked because most RADIUS system files are stored in the system’s Program
Files folder. When Windows 2003 was installed, the Windows 2003 RADIUS files
overwrote the Windows 2000 RADIUS files, even though the operating system
itself was installed in a separate folder.

I tend to discourage people from using multiboot
configurations because you never know when something like this will happen. If
you find yourself in a situation where you absolutely must install Windows 2000
Server and Windows Server 2003 onto the same machine, there’s a solution: Install
the two operating systems onto two separate volumes.

Accounts database location

As I mentioned earlier, an IAS server can use the local SAM,
a Windows NT 4.0 domain, or Active Directory. The catch, however, is that you
can’t just choose a database type indiscriminately. The biggest limitation you’ll
run into is that if your IAS server is a member of a Windows NT 4.0 domain, you
canï¿?t use a Windows Server 2003 Active Directory database from a different
domain as your accounts database. If you try to do that, the LDAP queries from
the IAS server to Active Directory will fail because of limitations related to
Windows NT.

The best solution is to place the IAS server in a Windows
Server 2003 domain. If that isnï¿?t an option, and you absolutely must have the
IAS server in a Windows NT domain, you can put a RADIUS proxy server in the
Windows NT domain and use it to forward requests to an IAS server in the
Windows 2003 domain.

Normally, Microsoft recommends not running any unnecessary
software on your domain controllers for security and performance reasons. If
the IAS server is in the same domain as the accounts database, however, IAS
will actually perform better if you promote the IAS server to domain controller
status. Thatï¿?s because IAS will be able to make a local query to the accounts
database rather than having to send the query to a separate domain controller.
Designating the server as a Global Catalog Server will also help to boost
performance.

I’m not sure how I feel about running IAS directly on a
domain controller because of potential security issues. This recommendation comes
straight from Microsoft.
If you want the performance benefit but are concerned about security, you might
consider creating a special domain just for IAS.

Back up the RADIUS configuration

Once IAS is up and running, you should back up the IAS configuration.
You can do this by backing up the server along with the System State
information, but itï¿?s also possible to back up only the IAS information by
using the NETSH program. To do so, enter the following command:

NETSH aaaa show config
>path\filename.txt

This will create a text file with the name you specify. The
text file contains all of the configuration information related to IAS. You
should create a new text file whenever you make a change to the IAS
configuration. If you ever need to restore your IAS configuration, you can use
the following command:

NETSH set config [
type={server_settings | clients | connection_request_policies | logging |
remote_access_policies}blob=path\filename.txt

Security best practices

Much of the security associated with RADIUS comes down to
the use of shared secrets. A shared secret is basically an encryption key that
is known to the RADIUS client, the access client, and the RADIUS server (or RADIUS
proxy). The shared secret is used to encrypt authentication credentials and
data.

There are a lot of security tips that I could give you regarding
shared secrets, but the most important is that you shouldnï¿?t use the Password
Authentication Protocol (PAP) in conjunction with RADIUS.

RADIUS is designed so that not every connection uses the
same shared secret. For example, an access client may use one shared secret to
communicate with a RADIUS proxy. The RADIUS proxy might then use a different
shared secret to communicate with the RADIUS server. At first, you might think
that using multiple shared secrets increases security, but itï¿?s actually the
reason you shouldnï¿?t use PAP.

An access client uses a shared secret to securely transmit a
password to a RADIUS proxy. If the RADIUS proxy uses a different shared secret
to communicate with the RADIUS server, the proxy must decrypt the password and encrypt
it with the alternate shared secret. Because of the way PAP works, it’s
possible for a malicious user to intercept encrypted passwords at the RADIUS
proxy while they are momentarily decrypted. As an alternative to PAP, Microsoft
recommends using MS-CHAP version 2, MS-CHAP, or CHAP.

Of course, using a solid protocol is only half the battle.
It’s equally important to use a secure shared secret. Setting up a secure
shared secret is like creating a secure password. Ideally, you want to use a
random combination of uppercase letters, lowercase letters, numbers, and
symbols. As with passwords, you’ll also want to change your shared secret
often.

One area in which a shared secret differs from a password is
in length. Passwords are generally considered secure if they’re at least eight
characters long. Shared secrets, however, are not considered secure unless they’re
at least 22 characters long. For maximum security, you can make a shared secret
up to 128 characters long.

One last detail you need to now about shared secrets is that
you can define access clients by IP address or by fully qualified domain name.
If you use a fully qualified domain name, and it maps to multiple IP addresses,
only the first address is used.

Microsoft discourages defining access clients by using an IP
address range because all clients within that range must use the same shared
secret.