A graphical interface is only useful for the things you do over and over. Almost nothing worth doing to a RADIUS server qualifies.
Alan DeKok, CEO and Founder, InkBridge Networks
Jana Sedivy has written about why there is no FreeRADIUS GUI. I want to take the question that comes after it. If you are not going to click your way through a FreeRADIUS configuration, what should managing a RADIUS server look like?
The short answer is that you automate the boring half and keep hold of the interesting half. Working out which half is which is the whole argument.
What a GUI is good for
The obsession with graphical interfaces comes from the fact that they are misleadingly useful. If you do not know how a piece of software works, a GUI gives you a great way to interact with it, and makes it hard to get anything wrong. That is a real benefit, and I am not going to pretend otherwise. Set against that interface, if a program keeps its configuration in text files, it’s easier to get things wrong, and it takes more effort to get anything done.
So I understand the appeal. The problem is that the protection only covers the easy things. I want the server to listen on one address: type the address into a box. Fine. But if you can do that, you can open a configuration file and change an IP address, and you have learned something that carries over to the next problem.
When you’re running a RADIUS server, one half of the job is managing users; the other half is policy. They want opposite things from you.
User management belongs behind an API
Most “RADIUS Server” management is just user management.
These process are actions like add a user. Delete a user. Check whether an account is active. Reset a credential. Watch what people do with a management interface and this is very nearly all of it. For an ISP, it runs continuously in the background, thousands of times a day.
None of that is RADIUS work. It is user management, and the world already contains a million user management systems. We are not going to write another one.
Not writing one turns out to be a selling point. The question we field most often from prospective customers is whether moving to us means changing their user database, their provisioning workflow, or their ticketing system. The answer is no. We will make the FreeRADIUS configuration fit whatever schema you already have. Username and password, or username, address, and password, it does not matter. Your provisioning does not change and nobody has to be retrained.
Once you accept that user management belongs in the system that already manages users, what you need is not a GUI, it’s an API. And for us, those APIs are largely called “SQL”, or “LDAP”. They aren’t “custom FreeRADIUS integration with 100s of pages of documentation”.
Your team doesn’t need to learn a new API, they can just use the ones that they’re already familiar with. This re-use lowers risk substantially.
Policy is a program
The other half of the problem is where an interface stops being merely unnecessary, and starts getting in the way.
Once you’re past user management, a RADIUS server enforces policy. E.g. “If someone logs in on this set of equipment, during these hours, then do this”. Or “If a user is coming in over the VPN and their account is already active inside the building, reject the request and warn somebody, because one of those two sessions is not who it claims to be”.
Now, try to build those policies in a graphical interface. How many checkboxes is it? How many nested accordions, conditional dropdowns, and little plus buttons that add another rule row? You would be constructing a programming language out of form controls, badly. Anyone who has used a product that tried it knows how that ends.
A FreeRADIUS configuration file is not a limitation you tolerate because nobody has built you a better interface yet. It is a programming language, and a policy is a program. The reason it looks like text is that text is what programs look like.
There is a second reason to keep policy out of a screen. The people writing these policies are not writing them often. An ISP might revise its authentication policy once a year. When they do, they are not going to poke a live production system. They will build the change in a lab, test it against real traffic, and roll it out under change control. An interface helps with none of that. What helps is a FreeRADIUS configuration you can see, review, put under version control, and copy between environments while knowing that you copied all of it.
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!)
What large operators ask us for
Large ISPs usually ask us to confirm that our product does not require a GUI. That it, they don’t ask whether or not it has a GUI. They ask whether they can avoid having one.
That request comes from experience. If the only way to change a setting is to log into a console and click, then during an outage somebody has to be awake, authenticated, and sitting in front of the right screen before anything can be fixed. Teams that have lived through that once are not keen to repeat it. They would rather deploy a FreeRADIUS configuration change from the tooling they already run, at 3:00 in the morning, without a human in the loop.
Those same operators either already have their own front ends, built for their own workflows, or they provision through an API. What they want from us is a server that does what it is told, integrates with what they already have, and never becomes the component that needs special handling.
The demand for a GUI comes from the other end of the market, from smaller deployments where there is often no database at all, and the operator is glad to have the RADIUS server keep track of users itself.
Output you can act on
There is one more argument for text-based configuration, and I would make it even if everything above were untrue.
When something goes wrong in a graphical tool, you get an outcome. Access denied. Somewhere there may be a log, if you are lucky and you know where to look. When something goes wrong in FreeRADIUS, you turn the debug output up and read what the server did. Somewhere in the pages of text scrolling past is the line telling you that the password which arrived was hello and the password LDAP returned was 123. Those are not the same password. You now know exactly what to fix, and our guide to common FreeRADIUS debug messages is a good place to start.
That is the difference between output that reports a result and output that tells you what to do next.
Control is the thing you are buying
Underneath all of this is a question about who is in charge of your infrastructure.
When your FreeRADIUS configuration is text that you own, you can build workflows the authors of any interface never imagined. You can change your database schema and adjust one line to match. You can generate configuration from your provisioning system, template it across sites, and review a change the way you would review code.
You can also get in when things are bad. The senior engineers I have worked with, the ones who have been burned a few times across 20 years, are consistently the most enthusiastic about this. They know a text file and a terminal will still work when the rest of the stack is on fire. Layers of modern tooling are wonderful right up until one layer breaks and takes everything above it with it. A file you can edit over a serial console is not exciting, but it is available during non-business hours, when the alternative is waiting for a vendor to answer the phone.
That is what control means here. Nothing stands between you and the system at the moment you need to change it.
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
Build what you need
Your authentication server goes down during a holiday weekend. You’re the only one on call. Now you’re checking: is it a hardware failure? A configuration error? Nope. It’s because the license expired, the licensing server is unreachable, and the vendor isn't responding to queries.
RADIUS design for internet service providers (ISPs)
More than almost any other business, internet service providers (ISPs) need to provide their customers with fast, reliable internet connection to their computer network. Any downtime can be catastrophic to their business operations. Slow connection speeds will drive customers away to other providers.