DEV Community

Nelsar
Nelsar

Posted on

Axia: an open-source web interface and REST API for Active Directory and OpenLDAP

Every company with a directory has the same routine: create an account, reset a password, add someone to a group, disable a leaver. That work belongs with helpdesk or HR. But the usual ways of handing it over are RSAT on a domain-joined machine, an LDAP client, or a PowerShell script that someone has to maintain. And in all of them, the hard part is making sure helpdesk can't quietly promote itself.
We built Nelsar.Axia for that: a self-hosted web interface and REST API for Active Directory, Samba AD, OpenLDAP and eDirectory. It's open source under Apache 2.0.
What it does
• Users, groups, OUs and computer accounts. Search, create, edit and delete them from the browser, and read raw attributes when you need them.
• Several directories at once. One instance can serve AD and OpenLDAP side by side, and each session stays bound to the directory it signed in to.
• Roles from directory groups. You map a group like cn=helpdesk,ou=groups,... to a role, and the role to a set of 17 permissions. Take someone out of the group, and half a minute later the rights are gone.
• Bulk provisioning. Create accounts in batches, with a login generator that transliterates names (Cyrillic to Latin, for example) and checks every login against the directory before anything is written.
• An audit log. It records every sign-in and every change, including refused attempts, with who made them.
• A REST API with OpenAPI. Onboarding and offboarding scripts can call it instead of speaking LDAP.
• Nine interface languages, including Arabic and Hebrew with a mirrored layout.
The part we spent the most time on
Axia talks to the directory through one service account with broad rights and decides on its own who may do what. That's how most delegation tools work, and it has a price. The directory no longer protects your admins, because all it ever sees is the service account. AdminSDHolder, OU delegation and olcAccess all stop helping.
So the protection has to live in the application:
• Nobody can act on anyone who holds more rights than they do. "More" is measured in Axia's roles and in the directory itself: members of protected groups, found by SID and resolved through nesting and primary groups. A helpdesk role that can reset passwords can't reset a Domain Admin's.
• Moving or renaming an OU counts as a permission change. If the OU holds a group that grants a role, only someone who already holds that role's rights can move it.
• Repointing a directory connection requires the bind password again. Without this rule, anyone who could edit a connection could send the stored service account password to a host of their choosing (LDAP pass-back).
• Brute force through the console can't lock accounts in AD. A lockout in the directory blocks new sign-ins but doesn't end live sessions, so nobody can kick an admin out by typing wrong passwords. Failed sign-ins are capped per account below the directory's own threshold.
• Passwords are written the way the directory expects: unicodePwd over an encrypted connection for AD, and the Password Modify extended operation for OpenLDAP. Never as a plain userPassword attribute.
We wrote up how each of these was found, along with the code, in a longer article: How a helpdesk role could take over the admin: five traps in a web console for Active Directory and OpenLDAP.
Try it in a few minutes
All you need is Docker with Compose v2:
git clone https://github.com/Nelsar/Axia.git
cd Axia
docker compose up
Open http://localhost:8080. The demo comes with an OpenLDAP that has an account for every role, and every password is Axia-Demo-1. The most telling test: sign in as editor.demo and try to reset admin.demo's password.
For real deployments, there are images on ghcr.io and Docker Hub (nelsar/axia-api, nelsar/axia-console) for amd64 and arm64. There's also a Windows installer that runs Axia as a service with nothing else to install. It stores its data in PostgreSQL or SQLite.
What it doesn't do yet
Axia is an MVP at version 0.3, and we'd rather you hear the gaps from us:
• No sign-out or token revocation. A session token lives 60 minutes. Disabling the account in the directory ends the session within 30 seconds.
• No two-factor authentication or OpenID Connect sign-in yet. Both are next on the roadmap: TOTP required by role, and sign-in through Entra ID, AD FS or Keycloak.
• No revocation checks (CRL, OCSP) for directory certificates.
• One instance only. Bulk jobs and sign-in counters live in memory.
The Windows installer isn't code-signed yet. Each release carries a build provenance attestation instead, which gh attestation verify checks.
Links
• Source: github.com/Nelsar/Axia
• Documentation: nelsar.github.io/Axia
If you run OpenLDAP or Samba in production, we'd especially like to hear what breaks. Issues are open on GitHub. And if you hand directory work to helpdesk today, how do you do it: delegation, a commercial tool, or scripts?

Top comments (0)