There is no official FreeRADIUS GUI. Here is what does exist, what it will and will not do for you, and why the missing piece is unnecessary.
Jana Sedivy, VP Customer Experience & Product, InkBridge Networks
Does FreeRADIUS have a GUI?
No, and InkBridge Networks has no active plans to build an official one.
What exists instead is a small ecosystem of third-party web interfaces. Some of them are useful. None of them does the thing most people are picturing when they ask for a FreeRADIUS GUI.
The FreeRADIUS web interfaces that do exist
Search for a FreeRADIUS GUI and you will find a handful of third-party projects products, none of them official.
daloRADIUS is the one most people find first. It is a PHP front end for the SQL tables that FreeRADIUS uses, and it has been around a long time.
RADIUSdesk is aimed at hotspot and mesh deployments.
OpenWISP RADIUS is built on Django for multi-tenant provider environments, with features such as self-registration and SMS verification.
One correction to the roundups that dominate this search. Several of them list TekRADIUS as a FreeRADIUS GUI. It is not one. It is a separate RADIUS server for Windows with an interface of its own. If you install it expecting a front end for your existing FreeRADIUS deployment, you will have a confusing afternoon.
Each of these GUIs reads and writes user records in SQL schema. I.e. the tools manage users. None of them lets you change the FreeRADIUS configuration files.
When people ask for a FreeRADIUS GUI, most are picturing something that would let them set the server up by clicking through screens. None these tools does that.
Arguably, that’s a good thing. See below for why we think that this surprising statement is true.
Third-party FreeRADIUS web interfaces sit on the SQL database, not on the server configuration.
One further category is worth knowing about. There are several commercial products consisting of FreeRADIUS underneath, with a front end and a subscription on top. There are too many to name, so we won’t do that here. Some focus on FreeRADIUS, others allow changes to a small set of the FreeRADIUS configuration.
This “wrapping” of FreeRADIUS is entirely allowed, and we are glad the software is being used, because we make it available for free so that people can. It is worth knowing, though, that some of the vendors who say that “a graphical interface is essential” are really selling you stripped-down version of FreeRADIUS. Getting increased cost, and reduced functionality isn’t for everyone.
Why has no one built a FreeRADIUS configuration GUI?
GUIs are hard. The main reason is integration, and thisfollows directly fromthe functionality that makes FreeRADIUS worth running in the first place.
FreeRADIUS works with whatever else is in your stack. You can back it with MySQL, PostgreSQL, Oracle, or Redis. You can point it at LDAP. You can connect it to Active Directory, which needs Samba sitting in between, something we have written about at some length. Each of those components is configured differently. And that’s before you get to certificates, EAP methods, session tickets, and proxying, each of which carries its own set of decisions.
A configuration interface would have to cover all of the above functionality in order for it to be useful. This is the general difficulty with building an interface for a flexible product. It is often said that 80% of users only use 20% of the features. The part usually left out is that the users all use a different 20%! In Excel, one person lives in pivot tables, another writes formulas, and a third totals a column and draws a bar chart. There is no such thing as a power user. There are only people using different chunks of the same product, and covering any one chunk leaves the rest of them stranded.
Our estimate that even with AI, it takes a substantial amount of resources to build a GUI that does what everyone needs. The GUI won’t be useful to most people until it’s functionally complete, and no one will buy it until it does what they need. The result is that we’re left with a choice: fund it ourselves, in the hope that it will be useful, or find a customer to sponsor it.
No customer has (as yet) offered to sponsor that work, and don't have the resources to fund it ourselves when the overwhelming majority of our customers do not want it.
There are other reasons to avoid building a GUI. The simplest one is that most people simply don’t need one.
Worth subscribing to.
Worth reading.
Our weekly newsletter covers network authentication tips, how-tos, security vulnerabilities, free resources, standards updates, and industry news. (All stuff you should stay up to date on!)
An authentication server is not a tool you live in
Complex software is a fair bargain when you use it every day. Photoshop is not walk-up-and-use software. It is closer to an instrument: hard to start with and enormously capable once mastered. I spent years at Adobe watching designers accept that trade quite happily, because they were in the product daily.
An authentication server is a different kind of product. You configure it, you deploy it, and then ideally you do not touch it for years. Think of it this way, when you’re running an ISP, how often do you change the network, versus how often do you change user information?
I’ll bet that most large ISPs change user information hundreds to thousands of times a day. They have those changes built into their business processes, using a UI that works for them.
In contrast, large ISPs change their core networks rarely to never. So they don’t need a GUI to automate work they rarely do. They need tools to help automate, manage, and to monitor their networks. A FreeRADIUS GUI won’t help there.
We have customers whose entire IT team has turned over since deployment, where nobody left in the building knows how the system works. They know they have a support contract, so they call us and ask us to explain their own infrastructure to them.
A screen full of tabs does not solve that. Somebody who has not looked at a system in seven years will not be reacquainted with it by an interface they have never seen either. What they need is documentation and somebody who knows the system.
A FreeRADIUS GUI would not deliver what people are asking for. What they want is for this to be easier, which is a completely reasonable thing to want.
Nobody is blocked by the absence of a graphical interface. They are blocked because a certificate chain is incomplete, or an LDAP bind is failing, or their system libraries and their RADIUS server disagree about which TLS implementation is in use. No screen fixes any of those.
Where an interface earns its place
Two jobs suit a user interface:
The first is user provisioning: adding a user, disabling an account, resetting a credential, or issuing a few hundred at once. Most organisations already run a system that does this, and the sensible answer is usually to keep using it.
The second is session inspection. Somebody says they cannot get online, and you want to look at that specific session and see what happened to it.
The person doing these jobs is frequently not the person who built the system: a helpdesk agent checking why a subscriber will not connect, or a site manager issuing credentials to people who have just arrived. That need is real, and the practical answer is usually an API into the system you already run rather than a new screen. Alan has more to say about that, and about why the configuration itself belongs in text.
The interface we offer is us
FreeRADIUS is free, the source is public, and there is a mailing list where you can ask us questions. Ask a good one and you may still be told to read the documentation, which is not the warmest interface ever designed, but it is an honest one and it is staffed by the people who wrote the server.
When you want more than that, you tell us what you need. We build it, we test it, we deploy it, and then you go back to your job. If something breaks in three years, you call us. In practice, that is a more usable interface than any set of screens we could ship.
Need more help?
If your team is wrestling with network configuration, a troubleshooting problem you cannot resolve, or a system that needs to be more resilient, we can help. InkBridge Networks has 25 years of expertise - we wrote the standards, maintain FreeRADIUS, and have seen every failure mode there is. Reach out to request a quote.
Related Articles
Stop looking for FreeRADIUS alternatives
Afraid of FreeRADIUS? If worries about support, scalability, and security have you looking for alternatives, FreeRADIUS creator Alan DeKok explains why those fears are unfounded.
The FreeRADIUS getting started guide
After an administrator installs FreeRADIUS for the first time, the big question is “Now what?” Most sites need complex policies, interactions with databases, and logging. Yet the documentation for the server doesn’t give detailed instructions for how to configure the server for your particular location.