Users¶

Overview¶

The Users tab manages your RADIUS subscribers — the accounts that authenticate through FreeRADIUS. Each user lives in the standard radcheck (check attributes, including the password) and radreply (reply attributes) tables, with group membership in radusergroup. Anything you set here is what FreeRADIUS reads at authentication time.

Where things are¶

The user list — searchable and paginated. Columns show the username, group(s), status (enabled/disabled), and expiration. Use the search box to filter by username; the toolbar has New user, Export (CSV), and History (import/export history).
New user — set the username, password and password type (cleartext, or a hashed type), group membership (comma-separated), an optional expiration date, and a Simultaneous-Use limit.
User detail panel — click any row to open it. Tabs:
Sessions — this user's live and recent accounting sessions.
Auth History — their Accept/Reject events from radpostauth.
Timeline — a chronological view of activity.
Attributes — the raw radcheck / radreply rows, editable.
Change Password / Groups / Limits — quick edit sections for the common fields.

Common tasks¶

Create a user — New user → username + password → assign a group → Save.
Reset a password — open the user → Change Password → set the new value and type.
Disable vs. delete — Disable keeps the account but rejects auth (reversible); Delete removes it entirely. Prefer disable for suspensions.
Expire an account — set an expiration date; after it passes, authentication is rejected.
Bulk import — use Export to get the CSV shape, then import a filled sheet to create many users at once. The History button shows past import/export runs.

Problems you may hit¶

A new user can't authenticate

Three usual causes: (1) FreeRADIUS isn't pointed at the same database — see First-time Setup; (2) the device the user connects through isn't a registered NAS with a matching shared secret; (3) the password type doesn't match what the NAS/protocol sends (e.g. CHAP needs a cleartext password stored).

"Simultaneous-Use" isn't enforced — this requires FreeRADIUS to check radacct for open sessions; make sure accounting is working (see Sessions).
Reply attributes seem ignored — put shared reply attributes on a Group and confirm the user is a member; per-user radreply overrides can conflict with group replies.
Disabled user still connects — an already-open session survives until it ends; disconnect it from Sessions (CoA) to cut it immediately.

Groups — share reply attributes across many users
Sessions — live sessions and CoA disconnect
Logs — why an authentication was rejected
CLI — monsterops users create|list|disable|delete