OUR SITES NetworkRADIUS FreeRADIUS

Adding a new user to the server

Goal: To configure the server with a new user, to send test packets as that new user, and to receive a reply.

Time: 15-25 minutes.

File:

  • etc/raddb/users

man page: users

The file is the usual place where new users may be added. The file is located in etc/raddb/users. It has a manual page; man users, or man 5 users will display this page. The manual page describes how the entries in the file are formatted and also contains some example entries.

The comments at the top of the file should also be read.

For testing purposes, add an entry at the top of the file, which will add a new user "bob" with password "hello", as suggested in the man page for the file.

Start the server:

$ radiusd -X

Test the server with a radius test client (radclient, NTRadPing), and verify that the server responds with an Access-Accept packet. For this test, use a PAP password.

If the server was successful, look for a message similar to:

(0)  files : users: Matched entry bob at line 1
(0)   [files] = ok

These messages indicate which entries in the file were used to match the incoming request.

If the server does not see the packet, then double-check the IP address and port to which the client is sending the request.

If the server does not send an Access-Accept, then stop the server and re-start it, while recording its output to a log file:

$ script log.txt
$ radiusd -X

Send the test packet again, and after the Access-Reject is received by the client, "exit" the shell to close the "log.txt" file. Open the "log.txt" file in a text editor, and read the output. The cause of the error can generally be determined from those messages.

The error will usually be one of the following problems:

  • the shared secret was incorrect

  • the user was not found, or no entry matched the request.

Test the server again with a PAP password, but this time, deliberately use the wrong shared secret. Observe what happens and what error messages are produced.

Test the server again with a test packet, this time using a CHAP password. Verify that authentication also succeeds.

Test the server again with a CHAP password, but this time, deliberately use the wrong shared secret. Observe what happens and what error messages are produced. Also observe how the error messages are different from the previous test with a PAP password and incorrect shared secret.

Stop the server.

Questions

  1. What happens when using a PAP password with an incorrect shared secret, and why do we get this result?

  2. What is different when using a CHAP password with an incorrect shared secret?

  3. Why does the server need access to a clear-text password to perform CHAP authentication?