SolutionBase: Best practices for implementing RADIUS

Using a RADIUS server can help make it easy to authenticate remote users. What's not so easy is properly configuring RADIUS. These best practices can help.

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.