{"id":499698,"date":"2026-10-22T08:01:22","date_gmt":"2026-10-22T05:01:22","guid":{"rendered":"https:\/\/savepearlharbor.com\/?p=499698"},"modified":"2026-10-22T08:01:22","modified_gmt":"2026-10-22T05:01:22","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=499698","title":{"rendered":"How a helpdesk role could take over the admin: five traps in a web console for Active Directory and OpenLDAP"},"content":{"rendered":"
\n

In Axia 0.1.0, a user allowed to edit accounts and move OUs could reset an administrator\u2019s password in four requests. None of the four broke the rule written to prevent exactly that.<\/p>\n

Axia is an open-source web console and REST API for Active Directory and OpenLDAP (.NET 10, React). It exists for a routine every company with a directory knows: create an account, reset a password, add someone to a group, disable a leaver. That work belongs with helpdesk, but helpdesk must not be able to promote itself, and every action must leave a trace.<\/p>\n

This is not a feature tour. It is five places where the obvious implementation turned out to be a hole or a bug, and what fixed each one. Most of them have nothing to do with Axia: anyone who builds access control on top of LDAP will run into them. The code is linked at the end.<\/p>\n

Why not directory ACLs<\/h3>\n

The textbook way to let helpdesk reset passwords is delegation: OU permissions in AD, olcAccess<\/code> rules in OpenLDAP. The directory itself decides who may do what, and no middleman needs broad rights.<\/p>\n

In practice this has two problems. The first is complexity. \u201cSupport resets passwords in ou=people<\/code>, except for members of cn=admins<\/code>\u201d can be written in OpenLDAP, but such rules are hard to read and maintain, and a mistake in their order silently grants more than intended. The second is that the rules live on the directory tree while the questions are about people: \u201cwhat can Peters do?\u201d has to be pieced together from the ACLs of several OUs.<\/p>\n

Axia takes the other route, and its price is worth naming up front. The application binds to the directory with a service account that has broad rights, and decides on its own who may do what: directory groups map to roles, and roles to a set of 17 permissions.<\/p>\n

\"Directory<\/p>\n
Directory groups mapped to roles<\/figcaption><\/div>\n<\/figure>\n

Permissions are evaluated on every request from the account\u2019s current groups, with a 30-second cache. Take someone out of a group, and half a minute later the rights are gone, even if their token is still valid.<\/p>\n

The more important consequence is another one. Since the service account makes every change, the directory no longer protects against privilege escalation. That is now the application\u2019s job, and nearly every trap below is about it. And whoever breaks into the application gets the directory, as far as the service account\u2019s rights reach. Weigh that before choosing the approach.<\/p>\n

How it compares<\/h3>\n

It makes more sense to compare approaches than products: where permissions are checked and what you pay for it. Axia is one option here, and not the best one everywhere.<\/p>\n

\n
\n\n\n\n\n\n\n\n\n\n\n
\n

\n<\/th>\n

\n

Delegation in AD + RSAT<\/p>\n<\/th>\n

\n

phpLDAPadmin, LAM<\/p>\n<\/th>\n

\n

Adaxes, ADManager Plus<\/p>\n<\/th>\n

\n

Axia<\/p>\n<\/th>\n<\/tr>\n

\n

Who checks permissions<\/p>\n<\/td>\n

\n

the directory (ACLs)<\/p>\n<\/td>\n

\n

the directory (ACLs)<\/p>\n<\/td>\n

\n

the application<\/p>\n<\/td>\n

\n

the application<\/p>\n<\/td>\n<\/tr>\n

\n

The tool itself holds broad rights<\/p>\n<\/td>\n

\n

no<\/p>\n<\/td>\n

\n

no, signs in as the user<\/p>\n<\/td>\n

\n

yes, a service account<\/p>\n<\/td>\n

\n

yes, a service account<\/p>\n<\/td>\n<\/tr>\n

\n

Directories<\/p>\n<\/td>\n

\n

AD<\/p>\n<\/td>\n

\n

any LDAP<\/p>\n<\/td>\n

\n

AD, Microsoft 365<\/p>\n<\/td>\n

\n

AD, OpenLDAP, eDirectory<\/p>\n<\/td>\n<\/tr>\n

\n

Admins protected from password resets<\/p>\n<\/td>\n

\n

AdminSDHolder, built in<\/p>\n<\/td>\n

\n

if your ACLs say so<\/p>\n<\/td>\n

\n

its own delegation model<\/p>\n<\/td>\n

\n

adminCount, protected groups, \u201cno one above yourself\u201d<\/p>\n<\/td>\n<\/tr>\n

\n

Change log<\/p>\n<\/td>\n

\n

DC security log, if auditing is on<\/p>\n<\/td>\n

\n

OpenLDAP accesslog, if configured<\/p>\n<\/td>\n

\n

yes<\/p>\n<\/td>\n

\n

yes, refusals included<\/p>\n<\/td>\n<\/tr>\n

\n

What it runs on<\/p>\n<\/td>\n

\n

Windows with RSAT<\/p>\n<\/td>\n

\n

a web server with PHP<\/p>\n<\/td>\n

\n

a server and a licence<\/p>\n<\/td>\n

\n

Docker or .NET<\/p>\n<\/td>\n<\/tr>\n

\n

Maturity<\/p>\n<\/td>\n

\n

years<\/p>\n<\/td>\n

\n

years<\/p>\n<\/td>\n

\n

years, vendor support<\/p>\n<\/td>\n

\n

MVP, version 0.2<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

When you don\u2019t need Axia:<\/p>\n