Give your users one less password to memorize
Wouldn’t it be cool if your users had to remember only one username and password? Just think how many fewer Help desk tickets you would receive.
As we've moved from Workgroups to NT Domains, Active Directory (AD), and “integrated services” such as Microsoft Exchange and SQL Server, the number of user accounts and passwords has declined. But many non-Microsoft technologies have authentication mechanisms that are separate from AD. One example is a virtual private network (VPN) connection using Cisco’s PIX/ASA firewall; these user accounts and passwords are stored locally on the firewall by default.
However, you can add Microsoft's free Remote Authentication Dial-In User Service (RADIUS) authentication to your firewall without altering your current VPN setup and give your users at least one less password to remember. Here's how.
Setting up the VPN Gateway
For this article, I used a Cisco PIX 515 with 64M of memory and16M of Flash running Cisco PIX Security Appliance Software 8.0(3) though Netgear and SonicWall, among others, also offer VPN gateways. I installed and used Cisco’s free Adaptive Security Device Manager (ASDM) 6.0(2), which gives you anytime-anywhere access to manage Cisco security appliances and firewalls.
Cisco is discontinuing the PIX 500 series and recommends moving to its ASA 5500 series instead. (See Cisco’s website for more information.) Since the ASA is nearly identical to the PIX, except with more bells and whistles, the RADIUS setup is the same as it is with the PIX setup. To authenticate other brands of VPN devices, you’ll need to check out the documentation of your specific model, but the RADIUS configuration that I describe below should be similar.
Just like a medical doctor, I live by the mantra “Do No Harm.” So it’s important that I add RADIUS authentication to my firewall without breaking or altering the current VPN setup. I want users to be able to continue using the current setup while I add new functionality. To simplify the RADIUS setup, I highly recommend using the GUI instead of the command line. I also recommend documenting every setting, IP address, and Secret Key—this will help you if you need to troubleshoot in the future.
To keep track of the settings, I created a document called Radius Settings (see the PDF titled “Radius Settings.”) The top half of the document shows you how the Tunnel Group and Pre-shared key values relate to the Cisco VPN Client. The bottom half shows how to configure PIX/ASA and Server 2008/Windows 2003 to point to each other for RADIUS authentication.
If you find that your setup isn’t working correctly, refer to this document and verify that you are referencing the correct Pre-Shared Key, Password, Server Secret Key, and Shared Secret. Just by looking at the names, you can see how it would be easy to accidentally use the wrong information.
The first step in setting up your VPN gateway is to log on to ASDM as a privileged user. For this example, I simply used the “Enable” password. ASDM takes a few seconds to read the configuration from the firewall, then it's ready to go.
Click Wizards, IPsec VPN Wizard, which Figure 1 shows, to get the process started. Click Remote Access on the screen that follows, then click Next. I prefer the free Cisco VPN client over the built-in Windows client, so I leave the default setting as is on step 2.
When you get to step 3, be sure to take notes as you will need this information for the VPN client later. It doesn’t matter what you enter for the Tunnel Group Name, so just keep it simple and easy to remember. The Pre-shared key however, should be a complex password. For the examples in this article, I'm using simple passwords and keys, which is fine for testing but not for a production environment.
Step 4 is the fork in the road and will send you down the RADIUS path for VPN authentication. Select the option Authenticate using an AAA server group. Click New and fill out the screen as Figure 2 shows. This screen contains information that you will need later, so be sure to take good notes.
Because we will be using RADIUS to authenticate to Active Directory (AD), I call my Server Group name “ActiveDirectory.” The Server IP Address is the address of the server that will host the RADIUS service. The Server Secret Key is a password of sorts that the firewall will use to access the RADIUS server and ask for authentication confirmation.
Note that while ADSM uses the term “Server Secret Key,” Windows 2003 calls the same thing a “Shared Secret,” which you can see if you check the screenshots in Radius Settings mentioned above.
Be sure to write this Server Secret Key down. As I mentioned above, my three-character Server Secret Key is just for testing; be sure to use a complex password in a production environment. We’ll discuss the Server Secret Key in further detail a little later.
Continue with the wizard, taking care to create a DHCP Pool (or use an existing one) in step 6. Assign DHCP details such as DNS and WINS in step 7. Be absolutely sure to use 3DES in step 8—not only because it's much more secure than single DES but also because the Cisco VPN client doesn’t seem to want to work with anything except 3DES. Trust me.
Leave the defaults for step 10 unless your company lets users “split tunnel” (access the secure VPN network while simultaneously accessing the unsecure Internet). The last step should allow you to click Finish and apply the configuration to the firewall. You are now done with the firewall and can move on to the RADIUS setup in Windows Server.
Now that the firewall is set up, it’s time to configure Windows Server. You can use either Windows Server 2008 or 2003, Standard or Enterprise Edition.
There is a limit of 50 RADIUS clients in Standard Edition, but the client in this instance is the firewall, not the individual users. If you have fewer than 50 VPN devices (or other devices that you want to authenticate via RADIUS), then you can use Standard Edition. If you have 51 or more, you need to use Enterprise Edition. Let's look at how to configure Windows 2003 first, then Server 2008.
If Internet Authentication Service (IAS) isn't already installed, you’ll have to do that first. IAS is the Microsoft implementation of RADIUS. Open Add/Remove Programs in the Control Panel and click Add/Remove Windows Components. You’ll find IAS in the Details of Networking Services. After it's installed, you’ll find a shortcut to IAS in Administrative Tools.
In researching this article, the technical editors and I had an interesting discussion about whether you should or shouldn't install IAS directly on a domain controller (DC). Experience tells us that it's always best to reduce the attack surface and keep the IAS/RADIUS services on a separate server from AD. At the same time, we couldn't find any Microsoft documentation to back up our rule-of-thumb.
In fact, we found two Microsoft articles that explain how to install IAS onto a DC (see "IAS Best Practices" and "Configure the Primary IAS Server on a Domain Controller"), with no mention of the potential risk. My recommendation stays the same: Keep those services on separate servers. You will have to make your own assessment.
You’ll need to register the server in AD so that it will query AD’s user database and not the local SAM database. Open IAS, right-click Internet Authentication Service, and choose Register Server in Active Directory, which you can see in Figure 3. Click OK when prompted to authorize the server to read users’ dial-in properties in AD.
Now, right-click RADIUS Clients and choose New RADIUS Client, which Figure 4 shows. Enter a friendly name for the client, such as "PIX VPN Authentication," and the INSIDE IP address of the PIX firewall (assuming that you're using that interface).
Click Next, then type in the Shared Secret (aka Server Secret Key) that you configured on the firewall in step 4 above. Use the Radius Settings PDF I mentioned above http://tinyurl.com/c7ezvv to help you keep it straight. Leave the Client-Vendor at the default RADIUS Standard.
The last step is to enable unencrypted authentication in the remote access policies. Yes, I know what you’re thinking: “Why on earth would I allow my user’s passwords to be sent unencrypted over the network?”
I had the same question, and I found the comfort that I needed after I read RFC 2865. According to the RFC, “Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecure network could determine a user's password.”
So although the setting specifies “Unencrypted Authentication” on the RADIUS server, the user’s password is encrypted using the Server Secret Key/Shared Secret between the VPN firewall and the Windows RADIUS server. Microsoft recommends a “long” complex shared secret at least 22 characters in length.
If you're using Server 2008, then the configuration process is a bit more complicated. Microsoft has moved the RADIUS services from IAS to a new service called Network Policy Server (NPS). NPS adds a new layer of complexity that IAS didn’t have. However the new features also considerably enhance the overall protection of the network from remote and local clients.
In Server 2008, we need to add a new role called Network Policy and Access Services. The New Role wizard can be found in the Server Manager MMC. Click Add Roles, then click Next until you see a screen with 16 roles. Select Network Policy and Access Services, then click Next two times.
Click Network Policy Server. Clear the check box labeled Routing, and make sure only Remote Access Service is selected. Leave everything else cleared. Click Finish, and reboot if prompted.
When the installation is complete, start Network Policy Server via the icon in Administrative Tools. The pane on the right displays a Getting Started screen. Choose RADIUS server for Dial-up or VPN Connections from the drop-down menu, then click Configure VPN or Dial-Up. A new dialog box labeled Configure VPN or Dial-Up appears. Choose Virtual Private Network (VPN) Connections. I usually leave the default name in the Name window at the bottom and add "PIX" so that it looks like this: PIX Virtual Private Network (VPN) Connections. Click Next.
At this point, the process is very similar to setting up a RADIUS client on Windows 2003. Click Add to add a new RADIUS client. Remember that the client is the Cisco PIX firewall and not an individual user's PC or username. Give the RADIUS client a friendly name, specify the IP address of the Cisco firewall, then enter and document the Shared Secret.
Click OK to close the properties page, then click Next. Leave MSCHAPv2 selected and the other options cleared. Don’t add any groups to the Specify User Groups page; click Next. Don’t add any IP Filters; again, click Next. On the Specify Encryption Settings page, leave the defaults, and click Next. A realm name isn’t necessary in this setup, so click Next. Review the settings that you specified, then click Finish.
As with Windows 2003, you need to enable unencrypted authentication. In the Network Policy Server MMC, which should already be open at this point, click Expand Policies, Network Policies, and double-click Connections to other access servers. Click the Constraints tab and enable Unencrypted authentication (PAP, SPAP).
Even though the set up of a RADIUS server is pretty straightforward, you might encounter a problem or two. Here are some common Event Log errors that I have run into and how to fix them. (Note that “2003” denotes Windows 2003 while “2008” denotes Server 2008.)
Event ID 2 (2003), 6273 (2008): “The user attempted to use an authentication method that is not enabled on the matching network policy.”
See whether Unencrypted authentication (PAP,SPAP) is enabled. This policy can be found in Remote Access Policies (2003), or Network Policies (2008). Edit the entry Connections to other access servers and ensure that the checkbox for Unencrypted authentication is selected.
Event ID 2 (2003), 6273 (2008): “Authentication was not successful because an unknown username or incorrect password was used.”
As the explanation in this event describes, the user has entered incorrect information. Double-check the username and password. Unfortunately, this event can also indicate a mismatch between the Server Secret key on the VPN device and the Shared Secret on the RADIUS service.
If all of your users except one are able to authenticate their VPN connections via RADIUS, then the Server Secret key/Shared Secret is fine and you need to concentrate on the user experiencing the problem. But if nobody is able to log in, then it might be good to verify that the Server Secret key/Shared Secret is the same.
Event ID 2 (2003), 6273 (2008): “The connection attempt failed because network access permission for the user account was denied.”
The username and password are correct, but the user is not authorized to dial in. Find the user in Active Directory Users and Computers and enable Allow Access on the Dial-In tab.
This event could also mean that the server doesn’t have access to read the dial-in attribute of the user objects in AD. As with the other events, to determine the cause, you need to determine if the problem is affecting one user or all users.
If you set everything up correctly, and the user enters in a correct username and password, you should receive an Event ID 1 (2003), 6278 (2008). This event tells you which user was granted access and the IP address of the VPN device that the user tunneled through.
Give RADIUS a Try
Those are the basic steps in setting up a RADIUS server in your enterprise. It might seem a bit daunting working with IAS in Windows 2003 and NPS in Server 2008. But as you set up your first RADIUS server and see how the VPN device and Windows Server communicate, you will soon realize that the concepts are very simple, and you might find yourself looking for more network devices to authenticate to AD via a RADIUS server.