A server with devices but no people still cannot log anyone in. The users file is where the first test account lives — added at the top, checked with radtest, and treated as a temporary lab account, not a company directory.
With the client registered, the server will answer questions — now it needs somebody to say yes about. The simplest place is the users file in /etc/freeradius/3.0/. This page shows how to add a first test account correctly, explains the top-of-file rule that trips up most beginners, and is honest about where this file stops being the right tool.
The file /etc/freeradius/3.0/users is FreeRADIUS' simplest built-in user list. Each entry starts with a username, followed by the check the server must perform — for a beginner setup, a clear-text password comparison. Lines below the username, indented with a tab, are items sent back in the reply when the login succeeds.
One behaviour surprises everyone: the file is read top to bottom and the first entry that matches is the one used. Entries you add belong above the pre-written DEFAULT sections, not at the bottom of the file, or they may never be reached.
sudo nano /etc/freeradius/3.0/userstestuser Cleartext-Password := "TestPass123"Reply-Message = "Welcome, test user" — seeing this text in the test result proves your exact entry matchedsudo freeradius -C, then restart: sudo systemctl restart freeradiusradtest testuser TestPass123 localhost 0 testing123 and look for Access-AcceptUse a password you invented for this test, not a real person's password — and not an example password copied from any article.
The users file is the right tool for exactly what we are doing: a first test account and a handful of lab users. It is the wrong tool for a whole company. Every change needs an edit and a restart, there is no password policy, and passwords sit in plain text in the file — protected only by the file's permissions.
The grown-up path is to keep this file for the test account and point FreeRADIUS at a real user store for everyone else — an SQL database, LDAP, or Active Directory, all of which FreeRADIUS supports as modules. Same server, same clients, same secrets; only the place it checks names and passwords changes.
The complete setup on a real Ubuntu server — install, first client, first user and the live test, all shown step by step in the video.
▶️ Watch Full VideoFreeRADIUS processes the file from the top and uses the first entry that matches the incoming request. The DEFAULT entries further down can match broad situations first, so a user added at the bottom may never be reached. Putting your entries above the DEFAULT sections guarantees they are evaluated first.
For a lab test account it is the documented, normal way to prove the server works, and the users file is readable only by root and the freerad group. For production, treat it as a stepping stone: real deployments check passwords against a database, LDAP or Active Directory, so passwords are not sitting in a plain text file on the server.
The usual causes are placement (entry below a matching DEFAULT), a missing restart after editing, or a password mismatch between the file and your test command. Run radtest and read the result carefully, then watch sudo freeradius -X debug output — it prints exactly which entry matched and why the password check failed.