dslreports logo
Search similar:


uniqs
112693
jbibe
Premium Member
join:2001-02-22

4 edits

jbibe

Premium Member

FreeRADIUS/WinXP Authentication Setup

This post describes how to build a FreeRADIUS server for TLS and PEAP authentication, and how to configure the Windows XP clients (supplicants). The server is configured for a home (or test) network.

Three papers have been written about TLS authentication with a FreeRADIUS server:

1) www.missl.cs.umd.edu/wireless/eaptls
2) www.freeradius.org/doc/EAPTLS.pdf
3) www.denobula.com

These papers provide an excellent background, but are somewhat out of date. Where appropriate, I will simply refer to these documents rather than repeating the information. I recommend that you follow the steps I give below rather than the steps in these documents.

In the steps below, I give examples from the FreeRADIUS server that I installed yesterday in my Red Hat 9 computer. If you follow this example, please make the needed changes to the names of the files. I installed the FreeRADIUS and OpenSSL files in special local directories. This ensures that there is no interaction between the base Linux files and the new files. It also allows you to easily remove all of the newly installed files.

One word of caution: Be prepared for some frustration. The FreeRADIUS and OpenSSL snapshots used in constructing the server are beta software. Don't be surprised if you encounter some problems.

1. Download and Install OpenSSL and FreeRADIUS

The first step is to download and install the latest snapshot versions of OpenSSL and FreeRADIUS.

a. OpenSSL -- Download the latest OpenSSL-0.9.7-stable snapshot. I downloaded the OpenSSL snapshot to my home directory. The snapshots are located at:

»ftp://ftp.openssl.org/snapshot/

Then I used the following nine steps:

mkdir -p /usr/src/802/openssl
cd /usr/src/802/openssl
cp /home/jbibe/openssl-0.9.7-stable-SNAP-20040202.tar.gz \
openssl-0.9.7-stable-SNAP-20040202.tar.gz

gunzip openssl-0.9.7-stable-SNAP-20040202.tar.gz
tar xvf openssl-0.9.7-stable-SNAP-20040202.tar
cd openssl-0.9.7-stable-SNAP-20040202

./config shared --prefix=/usr/local/openssl
make
make install

That completes the work with OpenSSL, except for building the required certificates.

When you perform the config, make, and make-install here and in the FreeRADIUS install described below, I recommend that you log the information. For example, instead of using the simple "make" command, use:

make > mymake.log 2>&1

If you encounter problems, you can review mymake.log (or myconfig.log, or myinstall.log) for errors.

b. FreeRadius -- Download the latest FreeRADIUS snapshot. Again, I downloaded the file to my home directory. The snapshot is located at:

»ftp://ftp.freeradius.org/pub/r ··· apshots/

Then I used the following nine steps:

mkdir -p /usr/src/802/radius
cd /usr/src/802/radius
cp /home/jbibe/freeradius-snapshot-20040203.tar.gz \
freeradius-snapshot-20040203.tar.gz

gunzip freeradius-snapshot-20040203.tar.gz
tar xvf freeradius-snapshot-20040203.tar
cd freeradius-snapshot-20040203

./configure --with-openssl-includes=/usr/local/openssl/include \
--with-openssl-libraries=/usr/local/openssl/lib \
--prefix=/usr/local/radius
make
make install

That completes the work with FreeRADIUS, except for building certificates, making the changes to the FreeRADIUS configuration files, moving the server certificates to their final location, and building a wrapper for radiusd.

2. Produce Certificates

Server and client certificates are needed for TLS and PEAP. To produce the required certificates, I recommend that you use CA.all that is included with FreeRADIUS. CA.all uses the configuration information in openssl.cnf.

a. openssl.cnf -- Update openssl.cnf for your configuration. The configuration file is located at:

/usr/local/openssl/ssl

A portion of the information from my openssl.cnf is given below. (The company information is does not describe an actual company located in Brentwood, TN.) Note that the configuration information includes the password "whatever". It is the certificate password.

When CA.all executes, it uses this information three times. The first pass through this information produces the root certificates. If you set up your configuration as shown below, you will be able to accept all of the settings in the first pass. The second pass through this information produces the client certificates. You only need to change the commonName to the client name. In my case, I changed the commonName to jbibe. The third pass through this information produces the server certificates. You only need to change the commonName to the server name. In my case, I changed the commonName to micron.

----- Example -------------------------------------------

...
# req_extensions = v3_req

# The extensions to add to a certificate request

[ req_distinguished_name ]

countryName = Country Name (2 letter code)
countryName_default = US
countryName_min = 2
countryName_max = 2

stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Tennessee

localityName = Locality Name (eg, city)
localityName_default = Brentwood

0.organizationName = Organization Name (eg, company)
0.organizationName_default = Helava

organizationalUnitName = Organizational Unit Name
organizationalUnitName_default = Engineering

commonName = Common Name (eg, YOUR name)
commonName_max = 64
commonName_default = HAI

emailAddress = Email Address
emailAddress_max = 40
emailAddress_default = ohb@cmcast.net

# SET-ex3 = SET extension number 3

[ req_attributes ]

challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
challengePassword_default = whatever

unstructuredName = An optional company name

---------------------------------------------------------

b. CA.all -- Update the CA.all script for your requirements. The file is located at:

/usr/src/802/radius/freeradius-snapshot-20040203/scripts

If you use the default password "whatever", you only need to verify that the path in the script points to the installed openssl information. No changes should be necessary, but there is one gotcha. At about line 30, the path will probably be in error. Look for the following line and update the path as needed.

echo "newreq.pem" | /usr/local/openssl/ssl/misc/CA.pl -newca

When CA.all executes, it produces nine certificates:

root.pem, root.p12, root.der
cert-clt.pem, cert-clt.p12, cert-clt.der
cert-srv.pem, cert-srv.p12, cert-srv.der

For TLS and PEAP, the server needs root.pem and cert-srv.pem. For TLS, the Windows XP client needs root.der and cert-clt.p12. For PEAP, the Windows XP client needs root.der.

In the event that you want to use TLS authentication with multiple clients, Document 3 provides the needed script. Look for the CA.clt script in Section 6.

3. Configure Server for TLS

There are only a few changes and additions needed for TLS authentication. The clients.conf, users, and radiusd.conf are located at:

/usr/local/radius/etc/raddb

a. clients.conf -- This file contains the basic configuration for the Access Point. Look for the following line then uncomment and modify as appropriate:

#client 192.168.0.0/24 {

client 192.168.1.0/24 {
secret = AP_Shared_Secret
shortname = WLAN
}


b. users -- This file contains the basic user information. Look for the following line and then add the user name:

#"John Doe" Auth-Type := Local, User-Password == "hello"
#

jbibe

Note that for TLS, you should not include an Auth-Type or a password. The server is able to determine the correct Auth-Type, and a password is not needed because the client uses a client certificate for authentication.

c. radiusd.conf -- This file contains the server configuration information. Look for the following lines and then change the default_eap_type from md5 to tls:

eap {
default_eap_type = md5

Change md5 to tls.

Move down to the following line, and then uncomment and modify the information, as shown below. Note that I placed the server certificates, dh file and random file in a new directory 1x on my system. Modify the path as needed for your server:

#tls {

tls {
private_key_password = whatever
private_key_file = /usr/local/radius/etc/1x/cert-srv.pem
certificate_file = /usr/local/radius/etc/1x/cert-srv.pem
CA_file = /usr/local/radius/etc/1x/root.pem
dh_file = /usr/local/radius/etc/1x/dh
random_file = /usr/local/radius/etc/1x/random
fragment_size = 1024
include_length = yes
}

No other changes are needed in radiusd.conf for TLS.

d. Server Certificates, DH File, and Random File -- I added a new directory 1x in the radius etc directory, and then copied the server certificates (root.pem and cert-srv.pem) into the directory. Finally, I used the following trick to produce dh and random:

date > dh
date > random

If you prefer, use your keyboard to enter some random characters in these files. Or even better, use the OpenSSL tools to produce the random information for these files.

e. Run-Radius -- The only server addition remaining is wrapper for radiusd. I added a new file run-radius in the /usr/local/radius/sbin directory. The script is from Document 3:

----- Wrapper Script ------------------------------------
#!/bin/sh -x

LD_LIBRARY_PATH=/usr/local/openssl/lib
LD_PRELOAD=/usr/local/openssl/lib/libcrypto.so

export LD_LIBRARY_PATH LD_PRELOAD

/usr/local/radius/sbin/radiusd $@
---------------------------------------------------------

After entering and saving the script, make run-radius executable:

chmod u=rwx run-radius

The server is complete.

4. Install Windows XP Certificates and Setup Client for TLS

The Windows XP certificates need to be installed, and client needs to be configured. I recommend that you follow Raymond McKay's example in Document 3, Section 10, XP Client (Supplicant) Setup. When this step is complete, the client is ready.

5. AP Setup

The AP configuration needs to be modified. This is the setup I used with my ZyXEL B-1000v2. (I assume that the B-1000 has been configured previously to use WEP keys and MAC addresses.)

At the wireless 802.1x tab:

Wireless Port Control = Authentication Required
ReAuthentication Timer = 1800 seconds
Idle Timeout = 3600 seconds
Authentication Database = RADIUS only
Dynamic WEP Key Exchange = 128-bit WEP

At the RADIUS tab for authentication:

Active = Yes
Server IP = 192.168.1.10
Port Number = 1812
Shared Secret = AP_Shared_Secret

6. Test TLS

The final step is to test the server. With Windows XP computer off, start the server in the debug mode by entering:

/usr/local/radius/sbin/run-radius -X -A

The server should start, displaying various debug information before it displays:

----- Example --------------------------------------------

Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on 1814/udp.
Ready to process requests

----------------------------------------------------------

If you don't see the message, look through the debug information for errors and missing information. If you see this message, start the Windows XP computer.

When the Windows XP starts, you will see various messages and certificates exchanged between the client and the server. If all is well, you should see the client authenticated and the user logged on. The following partial example is from Document 3. It shows the last few lines of a successful authentication:

----- Example ---------------------------------------------
...
MS-MPPE-Recv-Key = 0xe032765ca06c052e5fe7c2a7534a4252daec44a08505bdb459d4
fa81e70390f2221d2b06071eb0625e0ba67452a890909662
MS-MPPE-Send-Key = 0xe03131ce085bc266127528e749bd4753d3e1702df2d4d8c080351
380f52eae2c24a9fa78015c24e0d140bcd01b23d6c0cacc
EAP-Message = "\003_\000\004"
Message-Authenticator = 0x00000000000000000000000000000000
Finished request 5
Going to the next request
-----------------------------------------------------------

If you see MS-MPPE-Recv-Key and MS-MPPE-Send-Key, the server authenticated the client. You should be able to surf.

7. Change Server Configuration for PEAP

To change the server for PEAP authentication, only a few changes need to be made.

a. users -- Return to the users file and add the user password:

jbibe User-Password == "My-XP-Password"

b. Radiusd.conf -- Return to the radiusd.conf file and make the following changes:

Change the default_eap_type from tls to peap:

eap {
default_eap_type = peap

Move to the PEAP section below the TLS section and uncomment the following lines:

peap {
default_eap_type = mschapv2
}

The server is now ready for PEAP authentication.

8. Change Windows XP for PEAP

On the Wireless Network tab, select the network and click Configure to open the network properties. Then

Select the Authentication tab
Select Protected EAP on the drop-down list
Click Properties
Enable "Validate server certificate"
In Trusted Root Certification Authorities list, enable the root.der certificate.
In Select Authentication Method, select "Secured password (EAP-MSCHAPv2)"
Click Configure
If desired, enable "Automatically use my Windows logon name and password".

I did not enable "Automatically use my Windows ..." In my HP laptop, the software adds HP\\ before the user name; e.g., HP\\jbibe. If you don't enable this option, windows will ask for your user name and password the first time the laptop tries to connect to the network. The computer will then use the user name and password exactly as entered.

On the original Authentication screen, I disabled the "Authenticate as computer when computer information is available"

Windows XP is now ready for testing.

9. Test PEAP

The final step is to test the server. With Windows XP computer off, start the server in the debug mode by entering:

/usr/local/radius/sbin/run-radius -X -A

The server should start, displaying various debug information. If it displays "Ready to process requests", the server is running. This message is identical to the TLS start message. If you review the debug information, you will see additional messages as peap and mschapv2 start.

If you see the Ready message, start the Windows XP computer. As the client and server communicate, you will see various messages exchanged. If all is well, you should see the client authenticated and the user logged on. Again you will see the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key.

If you review the debug messages, you will see the TLS tunnel being built. Once it is built, you will see verification that messages are passing through the tunnel. Finally, you will see the user authenticated.

bbarrera
MVM
join:2000-10-23
Sacramento, CA

bbarrera

MVM

Any particular reason you used CVS snapshot of FreeRadius instead of version 0.9.3 released in November?

No_Strings

join:2001-11-22
The OC

No_Strings

PEAP is not available in the released version.

Rumblings on the freeradius mailing list indicate that a 1.0 release is fairly close.

bbarrera
MVM
join:2000-10-23
Sacramento, CA

bbarrera

MVM

Thanks. Assume FreeRadius 0.9.3 is OK for TLS. Wasn't planning on using PEAP so I'll give the latest release a try.

No_Strings

join:2001-11-22
The OC

No_Strings

TLS is indeed included in 0.9.3. Running here.
jbibe
Premium Member
join:2001-02-22

jbibe to bbarrera

Premium Member

to bbarrera
If you only need TLS, you can use FreeRadius-0.9.3 and OpenSSL-0.9.7c, both stable releases. Since FreeRadius-0.9.3 does not support "--with-openssl/include=" and "--with-openssl-libraries=", you will need to use:

./configure --prefix=/usr/local/radius

After configure executes, edit the rlm_eap_tls Makefile as shown in the Document 3. Then perform

make
make install

In the users file, you will need to enter the Auth-Type, as follows:

jbibe Auth-Type := EAP

Also, you will need to verify that the information in the Authorization section of radiusd.conf file matches the information in Document 3.

If you follow the How-To advice in Document 3, you do not need to download and install two OpenSSL versions. OpenSSL-0.9.7c will support the creation of the required certificates and the operation of FreeRadius-0.9.3.

bbarrera
MVM
join:2000-10-23
Sacramento, CA

bbarrera

MVM

Thanks!

DrTCP
Yours truly

join:1999-11-09
Round Rock, TX

DrTCP to jbibe

to jbibe
Regarding shared libraries:

If you install openssl under /usr/local/openssl as instructed above and try to run:

/usr/local/openssl/bin/openssl it might fail because of shared library not found.

To solve this I've added:

/usr/local/openssl/lib

to the end of /etc/ld.so.conf and as root user (su - ) regenerated ld.so.cache file by executing:

ldconfig -v

It might also be possible to solve the library problems by creating symlinks from /usr/lib/openssl/lib/* to /lib but I've not tested it.

No_Strings

join:2001-11-22
The OC

No_Strings

A great tip!

Can you help me find the hair I pulled out trying to work around that?
jbibe
Premium Member
join:2001-02-22

jbibe to DrTCP

Premium Member

to DrTCP
All of the FreeRADIUS documents recommend installing the OpenSSL files as shown in the initial post. I have always followed their advice, but it might not be the best choice. I have been reviewing the OpenSSL installation recommendations today. According to their information, the OpenSSL files are installed in /usr/local/ssl, unless the user specifies another location. In this latter case, they recommend that the user run config as follows:

./config --prefix=/usr/local --openssldir=/usr/local/openssl

This installs the bin files at /usr/local/bin, the lib files at /usr/local/lib, and the include files at /usr/local/include/openssl. And it installs the OpenSSL configuration files at /usr/local/openssl.

This install recommendation might prevent the problem that you have identified.

DrTCP
Yours truly

join:1999-11-09
Round Rock, TX

4 edits

DrTCP

Thanks for passing the recommended way.

I also appreciate all the valueable information you have collected, verified and documented here.
said by jbibe:
This install recommendation might prevent the problem that you have identified.
Yes, it does prevent the problem that way because /lib and /bin/lib and /usr/local/lib are in the default library search path.

However, it might interact with the existing openssl installed on my system. When openssl is installed under /usr/local/openssl the uninstallation is darn easy You do not have to hunt individual files among others.

Well yet another way to solve this problem is by defining two environment variables (your 3rd reference).

»www.impossiblereflex.com ··· TO.htm#8
jbibe
Premium Member
join:2001-02-22

4 edits

jbibe

Premium Member

said by DrTCP:
However, it might interact with the existing openssl installed on my system.
Alan DeKok, one of the lead designers of FreeRADIUS, is always commenting in the FreeRADIUS mail list about the Linker linking to the wrong version when you have two versions of OpenSSL on your computer. When users encounter a segmentation fault and they have two versions of OpenSSL installed, his usual recommendation is to include the --disable-shared option when building the server. I have never experimented with this option, so I can't comment on its effectiveness.
quote:
When openssl is installed under /usr/local/openssl the uninstallation is darn easy You do not have to hunt individual files among others.
I love the ability to remove all the installed information with a single command.

Edit: Alan DeKok's suggestion to add the --disable-shared option works. I installed a second FreeRADIUS server, using openssl-SNAP-20040202 and freeradius-snapshot-20040205. I selected these versions because they would probably fail to operate properly. This time I used the OpenSSL recommended config commands as follows:

./config shared --prefix=/usr/local --openssldir=/usr/local/opensnap
make
make install

Then I installed FreeRADIUS using these commands:

./configure --with-openssl-includes=/usr/local/includes/openssl \
--with-openssl-libraries=/usr/local/lib \
--prefix=/usr/local/radsnap
make
make install

After configuring the server, I started the new server in the debug mode. No trouble was encountered until the WinXP client tried to connect. During the authentication, the server crashed with a segmentation error.

I went back, added the --disable-shared option to the ./configure, and ran ./configure, make, and make install again. Once this change was made, the new server operated properly. It authenticates TLS and PEAP with WinXP clients.

I now have two working FreeRADIUS servers on my RH computer.
jbibe

2 edits

jbibe

Premium Member

In my post, I used

date > dh
date > random

to build the required random files. It is better to use the following methods:

openssl gendh >> dh
dd if=/dev/urandom of=random count=2

These methods were suggested recently in the FreeRADIUS mailing list.

I usually build the server with the simple date method when I am experimenting. Once the server is operational, I use the built-in tools to produce the final dh and random files.
your moderator at work
jamesv3
Premium Member
join:2003-03-08
Austin, TX

jamesv3 to jbibe

Premium Member

to jbibe

Re: FreeRADIUS/WinXP Authentication Setup

What should the three Common Names be? I thought Windows cared about such things.
jbibe
Premium Member
join:2001-02-22

1 edit

jbibe

Premium Member

You select what is convenient for your application. For example, a homeowner might select the family last name for the root certificates, and the first names of the family members for the cert-clt certificates.

If you are using TLS authentication, WinXP compares the common name in the client certificate (cert-clt.p12) with the login name. If the names don't match, WinXP will ask the user to identify the correct credentials.
jamesv3
Premium Member
join:2003-03-08
Austin, TX

jamesv3

Premium Member

said by jbibe:
If you are using TLS authentication, WinXP compares the common name in the client certificate (cert-clt.p12) with the login name. If the names don't match, WinXP will ask the user to identify the correct credentials.

OK. Larry, Moe & Curly would be fine, but for TLS is would be more convenient for "Moe" to be the Windows logon name.

I guess this means 802.11 WPA/Radius won't work unless someone is logged in, at least in the Windows world?

Thanks. I'm working on this right now (FreeBSD).
jbibe
Premium Member
join:2001-02-22

jbibe

Premium Member

It is not necessary for the WinXP user to log in. WinXP will ask for the user to identify the correct credentials for TLS (or PEAP) authentication the first time the user tries to connect to the network. Once the user identifies the credentials, anyone with access to that computer will have complete access to the LAN. For a home user, this might be satisfactory.