= 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:

[source, bash]
------------
$ 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:

[source, bash]
----------------
$ 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?

// Copyright (C) 2021 Network RADIUS SAS.  Licenced under CC-by-NC 4.0.
// This documentation was developed by Network RADIUS SAS.
