# daloRADIUS: a web front end for FreeRADIUS

> daloRADIUS is a PHP management application for FreeRADIUS deployments, covering user accounts, hotspots, NAS devices, accounting, reporting and a billing engine, with OpenStreetMap and Leaflet for hotspot geolocation. It shares the FreeRADIUS database rather than replacing it, and the current release narrows the supported database path to MariaDB with the PDO MySQL driver.

**lirantal/daloradius** — daloRADIUS is an advanced RADIUS web management application for managing hotspots and general-purpose ISP deployments. It features user management, graphical reporting, accounting, a billing engine, and integrates with OpenStreetMap for geolocation. The system is based on FreeRADIUS with which it shares access to the backend database.

- Repository: https://github.com/lirantal/daloradius
- Website: http://www.daloradius.com
- Stars: 920 · Forks: 441
- Language: PHP
- License: GPL-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/lirantal-daloradius

## A front end for the daemon, not a replacement for it

daloRADIUS does not implement RADIUS. It manages a FreeRADIUS installation, and the relationship is described precisely: the system is based on FreeRADIUS with which it shares access to the backend database.

That shared database is the whole architectural point. The users, hotspots, NAS devices, group mappings and accounting rows live in the radius schema that the daemon already reads. The web application is a management plane sitting on top of it, which is why daloRADIUS can list online users, show accounting history and create accounts without any message passing to the daemon.

The functional scope is what you would expect from that arrangement. User management covers listing, creating, editing, searching and deleting accounts, plus a quick add flow intended for point of sale or hotspot shops where speed matters more than field completeness. Hotspot management handles the list of configured hotspots and their settings. NAS management covers the Network Access Servers registered in the system. Group management handles the user-group mapping in the radius database along with the group reply and group check settings that configure group wide attributes.

On top of that sits accounting, reporting and a billing engine, and an OpenStreetMap integration for geolocation, which is where the project goes beyond plain administration.

## Accounting views and the open session problem

The accounting section is more detailed than the management section, and one entry in it points at a real operational problem.

You can view accounting by username, by the user's IP address, by NAS IP address, or by a date range. There is a view of all accounting records and a view of active records, the latter defined by the Max-All-Session attribute or the Expiration attribute. There is also a custom accounting query for extracting specific data, and a comparison view across hotspots that reports each hotspot's unique users, total hits, average time and total time.

The interesting one is open-session maintenance. Crashed clients leave accounting sessions open forever, which inflates the active session count and distorts any report built on it. The open session maintenance feature lets you preview open accounting records and then either close them while retaining the usage data or permanently delete the selected records. Preview before applying is the right shape for this, since a permanent delete cannot be undone from the interface.

For hotspot operators the per hotspot comparison is the feature that turns accounting into a business question rather than an operations one, since unique users and average session time per hotspot is what you compare when deciding where to put the next access point.

## Leaflet and OpenStreetMap put the hotspots on a map

The GIS feature is the one that departs from what an administration screen usually does. daloRADIUS ships integrated GIS support provided by Leaflet with an OpenStreetMap basemap, which lets you see where the deployed hotspots are on a map and monitor their status visually.

The two documented operations are a view map for monitoring deployed hotspots and an edit map for adding or deleting hotspots directly on the map without navigating to the hotspot management page.

That edit map is the operationally interesting one. Adding a hotspot by clicking a location on a map is dramatically faster than the form route, and for an operator who installs dozens of access points across a town it is the difference between a ten second task and a two minute one. Deleting straight from the map works the same way.

The catch is the same one that applies to any mapping tool: the basemap is OpenStreetMap, so the map view depends on an external service being reachable, and the coordinates you place are geographic rather than network ones. You still have to associate a hotspot with a NAS and with an address range somewhere in the configuration, so the map is an input convenience rather than a complete provisioning flow.

## Reporting, logs and the audit trail

The reporting section splits into what is happening now and what has happened.

Online users shows who is connected at this moment across all NAS devices. Last connection attempts shows recent attempts with their status, whether rejected or successful, which is the fastest way to diagnose a bad password or a policy problem. Search users mirrors the user management search. Top users ranks by bandwidth consumption or by time usage.

The logs section is what turns this into something you can hand to an auditor. The daloRADIUS log records all actions performed within the interface, including page visits, form actions such as deleting users or creating hotspots, and query submissions for user accounting. That is an application level audit trail separate from the daemon's own log.

Alongside it, the RADIUS server log shows the FreeRADIUS logfile, and the system log shows syslog or messages depending on configuration. A boot log is also listed.

The distinction between the daloRADIUS log and the RADIUS server log matters when you are investigating. The first tells you what operators did through the web interface. The second tells you what the daemon decided. A deleted user who keeps connecting is a question for the second log, and a user who was deleted by mistake is a question for the first.

## The database path narrowed to MariaDB and PDO MySQL

This is the most consequential change in the current release and it is stated directly rather than hinted at.

daloRADIUS is written in PHP and uses native PDO for database access. The installation paths target MariaDB with the PDO MySQL driver, pdo_mysql, and the existing mysql and mysqli configuration values both select that PDO driver now. PEAR DB is no longer required, though PEAR Mail and Mail_Mime remain separate dependencies for notification delivery.

The sentence that follows is the one to note: other database engines have not been validated end to end and are not recommended. That is a narrower support statement than the project used to make, and it directly affects upgrade planning for anyone running daloRADIUS on PostgreSQL.

The Docker image reflects the same choice. The base is debian:13-slim with PHP 8.4, and the install list includes php-mysql and mariadb-client alongside the mail stack of php-mail, php-mail-mime and php-net-smtp, php-ldap for directory integration, php-gd for image handling and php-mbstring. After the install, a single inline PHP check verifies that PDO exists and that the mysql driver is among the available drivers, and the build fails if it is not.

That assertion in the Dockerfile is worth knowing about, because it means the image refuses to build rather than starting up and failing later at runtime.

## Docker Compose brings up MariaDB, FreeRADIUS and the web interfaces

For a complete local stack, the documented path is to copy .env.example to .env, set the required secrets, and start everything with one compose command.

```bash
docker compose up -d --build
```

The compose file defines a MariaDB service on mariadb:11.8 with the database, user and password taken from the environment, and a radius service built from a separate Dockerfile-freeradius that publishes the standard RADIUS ports.

```yaml
    ports:
      - '1812:1812/udp'
      - '1813:1813/udp'
```

Both services use the no-new-privileges security option and drop the NET_RAW capability, and both wait on health checks rather than on a sleep. The database health check runs healthcheck.sh with the connect and innodb_initialized flags every ten seconds, and the FreeRADIUS health check pipes a status request into radclient against a local statistics port with a three second timeout.

The secrets are not optional. The compose file references MYSQL_PASSWORD, MYSQL_ROOT_PASSWORD and DEFAULT_CLIENT_SECRET with the shell style required syntax that makes compose fail if they are unset, and the .env.example file ships with CHANGE_ME placeholders for all three. A stack that starts with a predictable shared secret is a stack that authenticates anyone who reads the repository, so replacing those three values is the first deployment step, not an optional hardening one.

The environment file also carries the timezone, the operator bind address, the FreeRADIUS SQL TLS setting and the mail settings. The primary Dockerfile can also run the web interfaces alone against externally managed MariaDB and FreeRADIUS services, which is the deployment mode for people who already run those as separate infrastructure.

## Operator authentication and the LDAP settings worth reading twice

The .env.example file contains the operator authentication block, and it reads like a security checklist rather than a copy and paste template.

There are three switches. DALORADIUS_OPERATOR_AUTH_LOCAL_ENABLED, DALORADIUS_OPERATOR_AUTH_LDAP_ENABLED and DALORADIUS_OPERATOR_AUTH_DEFAULT, which is set to local. The comment on the block says to keep local auth enabled until LDAP login and local recovery are verified. That is the right instruction, because disabling local auth while pointing at a directory that has not been tested is how you lock yourself out of your own radius server.

The LDAP settings themselves are careful. The URI and the allowed groups must be JSON arrays. The security mode defaults to starttls, and TLS verification is on by default with a separate CA file setting. The bind password is documented as one to set only in a protected .env, since it overrides the PHP configuration at runtime.

The most important single line is the comment on the external ID attribute. It says to use an immutable directory attribute such as objectGUID on Active Directory or entryUUID on OpenLDAP, and never a mutable login name. Using a login name as the stable identifier means that renaming a user in the directory breaks every mapping, and it opens the door to someone else claiming the freed name. The setting is left empty and marked as required when LDAP is enabled.

There is also a note on nested group support for Active Directory, with the matching rule OID given as 1.2.840.113556.1.4.1941, and a timeout of five seconds for the directory connection.

## Releases, licence and where the documentation lives

The version history shows a project that has moved considerably recently. The releases are 2.4 on 2026-10-08, 2.3 on 2026-05-22 and 1.3 on 2021-11-04. The repository is not archived and the last push was on 2026-10-13, so the 2.x line is the active one and the gap between 1.3 and 2.3 is a large jump in behaviour rather than a slow creep.

Note that the Dockerfile label still reads Version 2.3 while the release list is at 2.4, so the image metadata is not a reliable way to tell which release you are running.

The licence is GPL-2.0, recorded in the LICENSE file at the repository root and in the image label as GPLv2.

Documentation is Markdown in the doc/ directory of the repository, with the full installation guide available both in the project wiki and in doc/install, and a separate README.docker.md covering environment variables, ports, persistence, upgrades and the two deployment modes. Individual feature documents exist too, such as doc/setup/open-session-maintenance.md for the accounting cleanup described earlier. A SECURITY.md file is present in the repository root, along with an AGENTS.md and a CONTRIBUTING.md.

There is also a quick installation path for Debian, which pipes the install script over the network into bash.

```bash
wget -qO - https://raw.githubusercontent.com/lirantal/daloradius/master/setup/install.sh | bash
```

That script stands up a basic standalone AAA infrastructure and, at the end of the procedure, generates random credentials for the operator first login.

## Conclusion

Adopt daloRADIUS when you run FreeRADIUS and need an operator interface for accounts, hotspots, NAS devices and accounting, since it reads and writes the same radius database the daemon uses and ships a Docker stack that brings up MariaDB, FreeRADIUS and the web interfaces together. Do not adopt it on PostgreSQL or another engine, because the project states only MariaDB with pdo_mysql has been validated end to end and recommends nothing else. Verify first that your database matches that path, that you set MYSQL_PASSWORD, MYSQL_ROOT_PASSWORD and DEFAULT_CLIENT_SECRET in .env before starting the compose file, that your operator login method is one you have actually tested, since local auth should stay enabled until LDAP login and local recovery are confirmed, and that the 2.x release notes cover the upgrade from the 1.x line.

## FAQ

### How do I install daloRADIUS quickly on Debian?

Run wget -qO - https://raw.githubusercontent.com/lirantal/daloradius/master/setup/install.sh | bash in a root terminal. The script installs a basic standalone AAA infrastructure based on daloRADIUS and generates random credentials for the operator first login at the end of the procedure.

### Which database engines does daloRADIUS support?

The installation paths target MariaDB with the PDO MySQL driver pdo_mysql, and the mysql and mysqli configuration values both select that PDO driver. The project states that other database engines have not been validated end to end and are not recommended, and PEAR DB is no longer required.

### How do I run the daloRADIUS Docker stack?

Copy .env.example to .env, replace the CHANGE_ME values for MYSQL_PASSWORD, MYSQL_ROOT_PASSWORD and DEFAULT_CLIENT_SECRET, then run docker compose up -d --build. The compose file starts MariaDB, FreeRADIUS and the web interfaces, and it fails to start if the required secrets are missing.

### How do I use LDAP for daloRADIUS operator login?

Set DALORADIUS_OPERATOR_AUTH_LDAP_ENABLED to true, configure the LDAP URI, base DNs, bind DN and allowed groups as JSON arrays, and set DALORADIUS_LDAP_EXTERNAL_ID_ATTRIBUTE to an immutable directory attribute such as objectGUID or entryUUID. Keep local auth enabled until LDAP login and local recovery are verified.

## Sources

- [License: GPL-2.0](https://github.com/lirantal/daloradius/blob/master/LICENSE)
- [lirantal/daloradius on GitHub](https://github.com/lirantal/daloradius)
- [Project website](http://www.daloradius.com)
- [README](https://github.com/lirantal/daloradius/blob/master/README.md)
- [Releases](https://github.com/lirantal/daloradius/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lirantal-daloradius