Testing the Initial Setup
Once you have FreeRADIUS running, you need to test the configuration to make sure it is responding to requests. FreeRADIUS starts up listening, by default, on the port specified either in the local /etc/services file or in the port directive in radiusd.conf. While RFC 2138 defines the standard RADIUS port to be 1812, historically RADIUS client equipment has used port 1645. Communicating via two different ports is obviously troublesome, so many users start the FreeRADIUS daemon with the
-p flag, which overrides the setting in both the /etc/services file and anything set in radiusd.conf. To do this, run the following from the command line:
radius:/etc/raddb # radiusd -p 1645 radiusd: Starting - reading configuration files ... radius:/etc/raddb #
The server is now running; it is listening for and accepting requests on port 1645.
So, what is an easy way to test your configuration to see if it functions properly? It's easier than you might think, in fact. MasterSoft, Inc. has released a Windows desktop RADIUS server testing tool called NTRadPing, available at http://www.dialways.com. The latest version as of this writing is 1.2, and it's a freeware tool. Download and install this utility on a Windows machine, and then run it. The initial application window should look much like Figure 5-1.
Figure 5-1. The NTRadPing 1.2 application window
To do a quick test, follow these steps:
Enter the IP address of your FreeRADIUS machine in the RADIUS Server/port box, and then the port number in the adjacent box. For this example, I've used IP address
192.168.1.103and port 1645.
Type in the secret key you added in /etc/raddb/clients for this Windows console machine. For this example, I used the key "testing123."
In the User-Name field, enter root, and in the Password field, enter the root password for your FreeRADIUS machine.
Select Authentication Request from the Request Type drop-down list box.
If your server is working properly, and you entered a valid root password, you should see the reply in the RADIUS Server reply box to the right of the NTRadPing window. You should see something like:
Sending authentication request to server 192.168.1.103:1645 Transmitting packet, code=1 id=1 length=47 Received response from the server in 15 milliseconds Reply packet code=2 id=1 length=20 Response: Access-Accept ------------------attribute dump----------------------
Now, change the password for root inside NTRadPing to something incorrect, and resend the request. You should get an
Access-Reject message much like the one shown here:
Sending authentication request to server 192.168.1.103:1645 Transmitting packet, code=1 id=3 length=47 No response from server (timed out), new attempt (#1) Received response from the server in 3516 milliseconds Reply packet code=3 id=3 length=20 Response: Access-Reject ------------------attribute dump----------------------
Next, you'll need to test accounting packets. The old standard for RADIUS accounting used port 1646. Change the port number in NTRadPing accordingly, and select Accounting Start from the Request Type drop-down list box. Make sure the root password is correct again, and send your request along. The response should be similar to the following:
Sending authentication request to server 192.168.1.103:1646 Transmitting packet, code=4 id=5 length=38 Received response from the server in 15 milliseconds Reply packet code=5 id=5 length=20 Response: Accounting-Response ------------------attribute dump----------------------
Finally, stop that accounting process by changing the Request Type box selection to Accounting Stop and resending the request. You should receive a response like this:
Sending authentication request to server 192.168.1.103:1645 Transmitting packet, code=4 id=6 length=38 Received response from the server in 16 milliseconds Reply packet code=5 id=6 length=20 Response: Accounting-Response ------------------attribute dump----------------------
If you received successful responses to all four ping tests, then FreeRADIUS is working properly. If you haven't, here's a quick list of things to check:
Is FreeRADIUS running? Use
ps -aux | grep radiusd
to determine whether the process is active or not.
Is FreeRADIUS listening on the port you're pinging? If necessary, start
radiusdwith an explicit port, i.e.,
radiusd -p 1645
Have you added your Windows console machine to the list of authorized clients that can hit the RADIUS server? Do this in the /etc/raddb/clients file.
Are you using the correct secret key? This as well is configured in the /etc/raddb/clients file.
Have you double-checked the locations of the group, passwd, and shadow files inside the radiusd.conf file? These locations are specified in the Unix section. Make sure they're not commented out and that the locations are correct.
Can FreeRADIUS read the group, passwd, and shadow files? If you're running FreeRADIUS as root, this shouldn't be a problem, but check the permissions on these files to make sure the user/group combination under which
radiusdis running can access those files.
Is there any port filtering or firewalling between your console machine and the RADIUS server that is blocking communications on the ping port?
Is the daemon taking a long time to actually start up and print a ready message (if you're running in debugging mode)? If so, your DNS configuration is broken.
To assist in diagnosing your problem, you may want to try running the server in debugging mode. While operating in this mode, FreeRADIUS outputs just about everything it does, and by simply sifting through all of the messages it prints while running, you can identify most problems.
To run the server in debugging mode, enter the following on the command line to start
radiusd -sfxxyz -l stdout
It should respond with a ready message if all is well. If it doesn't, then look at the error (or errors as the case may be) and run through the checklist above.
You can also check the configuration of FreeRADIUS using the following command:
This command checks the configuration of the RADIUS server and alerts you to any syntax errors in the files. It prints the status and exits with either a zero, if everything is correct, or a one if errors were present. This command is also useful when you're updating a production server that cannot be down: if there were a syntax error in the files,
radiusd would fail to load correctly, and downtime would obviously ensue. With the check capability, this situation can be avoided.