Integrating Wireless Access Points with RADIUS and AD.

This project is a little more advanced than some of the other pieces I've done on here. Not because it's technically difficult, but because of the software requirements are a little beyond what a regular home user would normally have... Before diving into this, the requirements for this project is: 1. Microsoft Windows Server 2000 or 2003 w/AD. 2. Certification server (or, you could buy a certificate from a third party certificate authority). 3. RADIUS server (comes with Windows server). 4. Wireless Access point that supports WPA with Radius authentication. 5. Wireless network card. 6. Windows XP clients with WPA patch. If you got #1, then you automatically have #2 and #3, as these are services that comes with Windows Server (with the possible exception of Windows 2003 web edition). Installing the Internet Authentication Service (IAS) and the Certificate Authority service is easy enough. IAS is installed without any questions of any kind, the CA service installation is also painless yet it does ask you to name the certificate authority.

NOTE: I have gotten some questions regarding the installation and configuration of the CA server, specifically about having to issue a Server Authentication Certificate to the IAS server before authentication will work. I didn't intentionally leave anything out; my setup as described here worked without having to issue any certificates. I don't want to say it "worked out of the box", because I did spend many hours reading sometimes contradicting information about how to configure this. UPDATE: If you are having issues with the Certificate requirement of the configuration, please check out this article at TechRepublic for information on how to create a self-signed certificate for your server. Basically, it tells you to download the IIS 6.0 resource kit, and then install the SelfSSL 1.0 component, and walks you through the process of creating the certificate. I will be testing this in the near future, hopefully by the end of July 2007.

Self-signed digital certificates is a way avoiding the use of public or private Certificate Authorities. They have long been used by developers for the purpose of testing secure Web servers and code signing but have not been used in production systems. Few people know of this method or use it for RADIUS PEAP authentication and it has been difficult to find any documentation anywhere on the Internet or books explaining how to do this.

The concept of self-signed digital certificate is similar to Pretty Good Privacy (PGP) because it doesn't use the Certificate Authority model. Although both PKI and PGP are part of the broader umbrella of PKC, digital certificates were designed to conform to the PKI trust model made up of centrally trusted CAs while PGP used a freeform peer-topeer method of establishing trust. For example, a PGP user would generate their own public and private key pair and then post the public key to their own public Website for all to verify. Because of this model of establishing trust, there is no need for a public or private CA which is the biggest impediment to secure authentication protocols such as SSL and PEAP. To create a self-signed digital certificate, one would simply use a utility (shown in next section) to generate a digital certificate with a digital signature. The difference here is that instead of using an external trusted CA (analogous to a Notary) to sign the digital certificate, the utility would simply sign the certificate itself. Once the digital certificate is generated, a pubic version of the digital certificate containing the only the public key called a "root certificate" can be exported and be made publicly accessible. The root certificate can be distributed by any means (even on a public Website) without fear of compromising the certificate since the private key is kept private. As with any PKC technology such as PGP or PKI, there is no practical method of deriving the private key from the public key. Once a self-signed digital certificate, users can securely authenticate against that RADIUS server using PEAP authentication.

Microsoft IIS 6.0 Resource Kit

As soon as I thought of using self-signed digital certificates for PEAP authentication, I began looking for a simple utility for creating self-signed digital certificates. After an extensive search, I found within the Microsoft IIS 6.0 Resource Kit an interesting command line utility called SelfSSL.exe which can create self-signed digital certificates. Although it's intended to be used for Microsoft IIS 6.0 SSL Web server testing, it works for many other applications as well including PEAP since the certificate it generates is a standard X.509 certificate. After a quick test in the lab, it became obvious that this was a good alternative to building a PKI Certificate Authority to simplify PEAP authentication. Download a copy of the Microsoft IIS 6.0 Resource kit here When you install it, you only need to install the 332 KB SelfSSL 1.0 component of the Resource Kit. (Figure A) Figure A

SelffSSL 1.0 Installation Wizard

The SelfSSL.exe tool should work with most RADIUS/AAA Authentication Servers and I've verified this on Microsoft IAS server. On your Authentication Server, open up a command prompt and go to the directory where you installed it (default -- C:\Program Files\IIS Resources\SelfSSL). You then type the following command. selfssl /N:CN=ServerName.YourDomain.com /K:1024 /V:1825 /S:1 /P:443

/N:CN should be set to your ServerName and your fully qualified domain name. /K: typically set to 1024. 1024 is the number of bits allocated to the RSA key. /V: is the number of days before the certificate expires. 1825 days is 5 years. /S: is the site number in IIS. /P: is the TCP port number. 443 is the standard SSL port.

Note that /S: and /P: are irrelevant in our case since you don't need IIS running on your Authentication Server. As a general rule of thumb for security sake, you run as few services on your server as possible. If you don't have IIS installed, executing the SelfSSL command as shown above will end with an error message "Error opening metabase: 0x80040154". That just means the IIS site was not found but you can ignore that error message since the Certificate you need for PEAP authentication will have already been generated.

Creating the root certificate

Once the digital certificate has been generated on your authentication server, you will need to export the root certificate for this Self Signed Certificate. The digital certificate is different from the root certificate. The digital certificate contains the public and private key pairs. The root certificate only contains the public key and a self proclamation that "I am a root certificate". You will need this root certificate for publication on a Web-server or file-server for manual root certificate deployment or you can import it in to your Active Directory Group Policy for automatic root certificate Deployment. To begin, you'll need to open an MMC console by clicking Start | Run. Then type "mmc" and OK. You will see the following console appear (Figure B). From there, you'll click "ADD/Remove Snap-in...". Figure B

MMC Console

You'll then see this screen (Figure C). Click on the "ADD" button. Figure C

Add/Remove Snap-in

On this screen (Figure D), highlight "Certificates" and click on "Add" again. Figure D

Certificates

Select "Computer account" and click "Next". (Figure E) Figure E

Computer account

Then select "Local computer" as shown below in Figure F and click "Finish". Figure F

Local computer

You will see the resulting console appear. (Figure G) Figure G

Console root

Expand "Certificates (Local Computer) to reveal the following. Right click on "MyAuthServ.MyDomain" or whatever you used for your SelfSSL "/N:CN" argument, hit "All Tasks" and then choose "Export". (Figure H) Figure H

Export

You will see the following wizard (Figure I). Choose "Next". Figure I

Certificate Export Wizard

For this step, make sure you DO NOT export the "Private Key" because that must be kept private on the server. If you use the "Yes, export the private key" feature, that allows you to make a backup of the digital certificate but you want to guard that file in a protected area. Anyone who gets that file compromises your digital certificate because they now have a copy of your private key. Exporting the private key also lets you take that digital certificate and copy it to a redundant RADIUS server so you can import it there without having to generate a second key. If you have more than one RADIUS authentication server, make sure you copy the certificate over and don't generate a second key unless you want to complicate deployment matters by having to deploy two root certificates. (Figure J) Figure J

Not the private key

Use the "DER" format because it is compatible with Windows and Windows Mobile devices (Figure K). Windows doesn't care what format it's in but Windows Mobile does. Figure K

File format

Give the certificate a path and file name. (Figure L) You'll need to note the name for later use. Figure L

Path and file name

Hit "Finish" and you've just exported your Self Signed root certificate to a file. (Figure M) Figure M

Finish

Now you're have a self-signed root certificate ready to be deployed to the clients automatically or manually along with the digital certificate on your authentication server ready to use. We'll discuss how you actually use this certificate on our Microsoft IAS RADIUS server configuration guide. My setup:

Windows 2003 server standard with AD, CA and IAS. Linksys WAP54G wireless access point running firmware 2.06 or 2.07 Linksys WPC54G wireless network card, driver version 3.30.15 Windows XP Pro SP1 with WPA patch.

Creating RADIUS Client for Wireless Access point(s).

Once these two services have been installed, open the IAS management console. Step one is to create a RADIUS Client in IAS for your access point, and give it the IP address (or DNS name) of your access point. If you have more than one WAP, you can enter in an address range for the access points using using the format a.b.c.d/p, where p is the prefix length, i.e. 192.168.15.0/24. With proper planning, you should be able to reserve a range of addresses for the wireless access points and narrow down the range. The friendly name is simply what'll show up in the IAS management console. The client-vendor attribute is best set at RADIUS Standard unless your access point are one of the relatively few vendors in the list. Message Authenticator must be checked. This is required for the authentication piece which we will come back to in the Policies later. Even with RADIUS, you'll need a shared secret. This secret is used by the Radius server and the client, which is the WAP(s) and not by the actual wireless clients, so it's transmitted on the wired network only. Still, it should be a decent key using the same recommendations as for a strong password.

Creating a Remote Access Policy.

To create a new Remote Access Policy, select "Remote Access Policies" in the IAS management console, right-click in the blank area in the right column, and select "New Remote Access Policy". I initially used the wizard to create the policy. Even if you choose "custom profile" during the creation of the new policy, you'll still get a lot of help in the process, so you might as well let the wizard do most of the work. But, if you don't, you'll need the following settings: The policy conditions should be "NAS-Port-Type matches 'Wireless - IEEE 802.11 OR Wireless - Other'". You're better off starting here, and remove the "Other" later to test if your setup will work without it. Click the Edit Profile button to configure authentication methods and other settings. Most of these can be left as is, and you can made modifications to things like Dial-In Constraints to restrict login times and disconnect times once you got everything up and running. To start with, nothing on the Dial-in Constraints tab should be checked. On the IP Tab, "Server settings determine IP address assignment" should be selected. On the Multilink tab, "Server determines multilink usage" should be selected. On the Advanced tab, the only attribute should be "Service-Type" with Vendor "Radius standard" and a value of "Framed".

On the Encryption tab, check all the boxes. Once you have verified that your wireless network works, you can go back and uncheck the "No Encryption" option and test if it's still working.

The last tab is the Authentication tab, and this is where it's all done. First, uncheck everything! Then click the "EAP Methods" box. This will open the "Select EAP Providers" window, which lists the EAP types used during authentication. The only item that should be listed in the "EAP types" list box is "Protected EAP (PEAP)". If it's already there, select it, if it's not, then add it, then click the Edit button. This will bring up the "Protected EAP Properties" window, which will show you which server issued the certificate you're using, the name of the issuer, and also the EAP types used. There's only a couple of things to ensure are set, including checking the "Enable Fast Reconnect", and the EAP type should be "Secured Password (EAP-MSCHAP v2).

If it's not there, add it, selected it, and hit the "Edit" button. Check the box for "Automatically use my Windows logon name", and close out of everything...

There's one more thing that needs to be done on the AD server. The user accounts that will need to use the wireless network needs to have "Allow Access" for "Remote Access Permission" set in the dial-in tab of the user properties. Configuring the Wireless Access Point. Before we move on to the wireless clients, the Access Point have to be configured. For the Linksys access point, this is a small matter. Just click the "Edit Security Settings", and select "WPA Radius" from the dropdown list. Then select, the encryption algorithm (AES if you got it), enter the IP address of the Radius server and the shared key that was entered during the creation of the Radius client for the WAP. That's it, now move on to the wireless client.

Configuring the WLAN client for use with Radius.

Continuing from part 1, it is now time to configure the wireless client on the computers to connect to the wireless network. Using Windows XP, this is best done by allowing Windows to do most of the work. Bring up the Network Connection Properties window (as seen on the right), and switch to the Wireless Networks tab. It should look something similar to what is shown here. Since I'm not broadcasting my SSID, it doesn't show up as in the "Available Networks" section, but rather the "Preferred network" section. If you

are not broadcasting the SSID, you'll have to manually add the information by clicking on the "Add" button. Your SSID should definitely show up in the "preferred networks" section. Also, click the "Advanced" button and un-check the box that says "automatically connect to non-preferred networks". Having this enabled may disconnect you from your WLAN and connect you to your neighbors if suddenly his signal is stronger than yours.

Select your SSID, and click "Properties" or "configure", depending on where you selected your SSID. That will bring up another window which allows you to select Network Authentication mode and Data encryption algorithm. Since we set it up for WPA and AES earlier (see part 1), that's what we'll select here too. The key that is shown (grayed out) in the graphic to the right is the remains of the static AES key used prior to changing from shared key (WPA-PSK). Next, click the Authentication tab, to bring up the next set of options. There really isn't a whole lot here either, only the "EAP type" and a couple of check-boxes. Make sure that the "EAP type" is set to "Protected EAP (PEAP)" to match the provider we set up in part 1, and that the "Autheticate as computer when computer information is available" check-box is checked.

Then, hit the "Properties" button to bring up the "Protected EAP Properties window. Again, not a whole lot to do. Check that "Validate server certificate" is checked, and move on to "Authentication Method", which should be set to "Secured Password (EAPMSCHAP v2). Pick it from the the dropdown box, and click the "configure" button to bring up the last window. In the last window, simply make sure that the box is checked so that your login credentials are passed along as for authentication. Click "OK" to get back to the "Protected EAP Properties" window, and make sure the "Enable Fast Reconnect" box is checked. Once this is done, click "OK" to close out of all the property windows, and you'll be all set. If you open the "Network Connections" windows, you'll notice that (assuming everything is working) it'll say "Authentication succeeded" below your wireless connection, rather than simply "enabled" as it would with regular shared key connections.

Congratulations, that's "all" there's to it. Enjoy your secure WLAN... And this is where I promised we'll look at EAP-TLS next. Unfortunately, that might not happen any time soon. My experimental wireless network has turned into "production", and I cannot easily take it down to experiment with other types of authentication. What I can promise though, is that by the end of January (2005), I'll have another article on better tuning your settings to simplify the management of your wireless users and implement a few more restrictions.