FreeRADIUS users File Generator

Turn a list of subscribers and speed plans into a valid FreeRADIUS users file, or the equivalent radcheck and radreply SQL rows.

Config generator RADIUS & AAA Runs in your browser
One per line. Speeds in Mbit/s. Comma or tab separated.
Try:

Result

Subscribers
3
Password storage
Cleartext-Password
Rate limits set
3
raddb/mods-config/files/authorize
alice  Cleartext-Password := "Passw0rd-1"
        Mikrotik-Rate-Limit = "20000k/100000k",
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Acct-Interim-Interval = 300

bob  Cleartext-Password := "Passw0rd-2"
        Mikrotik-Rate-Limit = "10000k/50000k",
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Acct-Interim-Interval = 300

charlie  Cleartext-Password := "Passw0rd-3"
        Mikrotik-Rate-Limit = "1000000k/1000000k",
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Acct-Interim-Interval = 300
Password storage
Cleartext-Password stores the password recoverably - required for CHAP and MS-CHAP, and a real breach liability. Store the file with 0600 permissions owned by the radius user, and keep the database off any shared host.

About FreeRADIUS users File Generator

The users file is FreeRADIUS's flat-file authorisation source: fast to test with, awkward to scale. This generates correct entries from a subscriber list, or the equivalent radcheck/radreply SQL rows when you are ready to move to a database.

Moving from files to SQL

The flat file is read at startup and cached, so every subscriber change needs a reload — workable for a lab, untenable once customers are provisioned by a billing system. The SQL module reads radcheck and radreply per request, so changes take effect on the next authentication. Index username in both tables, keep radacct on separate storage because it grows fastest, and put a connection pool between FreeRADIUS and the database so an authentication storm does not exhaust it.

check items versus reply items

Everything before the first newline is a check item - a condition the request must satisfy, such as the password. Indented lines are reply items sent back on Access-Accept, such as the rate limit or framed address. In SQL the split is literal: radcheck holds conditions, radreply holds the response.

The operators matter: := sets and replaces, = only sets if absent, and == compares. Using = where you meant := produces a policy that appears to work until an attribute already exists.

Common use cases

  • Standing up a lab RADIUS server with realistic subscriber data.
  • Bulk-loading a small ISP subscriber base into SQL.
  • Producing a reproducible test fixture for a billing integration.

Edge cases and gotchas

  • Entries are matched top to bottom; a DEFAULT entry above your users will shadow them.
  • Never store real subscriber passwords in a repository or ticket attachment.

Frequently asked questions

Should I use the users file or SQL?
Files for labs and a handful of static accounts. SQL as soon as you have subscribers who change, because the users file requires a server reload to pick up edits while SQL is read per request.
Why does my entry get ignored?
Usually a DEFAULT entry earlier in the file matched first, or the username case does not match. FreeRADIUS is case-sensitive unless you normalise in policy.