Axia: el panel open source que frena a helpdesk en AD

En pocas palabras: Axia es una interfaz web y API REST open source bajo Apache 2.0, creada por Nelsar, para administrar Active Directory, Samba AD, OpenLDAP y eDirectory. Está en versión 0.3 (MVP), construida en .NET 10 con frontend React/TypeScript, y suma 959 tests automatizados.

Axia es una consola autohospedada construida en .NET 10 con frontend en React y TypeScript, acompañada de una API REST documentada con OpenAPI. Nelsar la publicó en versión 0.3, pensada para delegar altas, bajas y reseteos de contraseña a helpdesk sin entregar permisos de administrador. Permite crear, editar y borrar usuarios, grupos, unidades organizativas y cuentas de equipo en Active Directory u OpenLDAP desde un solo panel. El proyecto está publicado en GitHub y apunta a reemplazar RSAT, clientes LDAP o scripts de PowerShell en tareas rutinarias de helpdesk.

¿Qué problema de delegación en Active Directory resuelve Axia?

Toda empresa con un directorio tiene la misma rutina: crear una cuenta, resetear una contraseña, sumar a alguien a un grupo, dar de baja a quien se va. Según el anuncio de Nelsar en dev.to, ese trabajo le corresponde a helpdesk o RR.HH., pero las formas habituales de delegarlo (RSAT en una máquina unida al dominio, un cliente LDAP, o un script de PowerShell que alguien tiene que mantener) comparten el mismo defecto de fondo: nada impide que helpdesk se promueva a sí mismo en silencio.

Ponele que armás un script en PowerShell para que el equipo de soporte resetee contraseñas. Funciona bien durante meses. Hasta que alguien, con las mismas credenciales que usa para resetear contraseñas de usuarios comunes, descubre que también puede tocar el grupo de Domain Admins. ¿Quién se enteró? Nadie, hasta que ya era tarde.

Axia ataca ese punto exacto. La app habla con el directorio a través de una sola cuenta de servicio con permisos amplios, y es la aplicación (no el directorio) la que decide quién puede hacer qué. Eso tiene un costo que el propio equipo de Nelsar reconoce sin vueltas: “el directorio ya no protege a tus administradores, porque todo lo que ve es la cuenta de servicio”, escribió el equipo en la publicación original. AdminSDHolder, la delegación por OU y olcAccess de OpenLDAP dejan de ser útiles en ese esquema, así que la protección tiene que vivir en el código de la aplicación misma.

¿Qué funcionalidades ofrece la interfaz web y la API REST de Axia?

Axia cubre la gestión completa de objetos de directorio desde el navegador, más una API REST para automatizar todo eso sin tocar LDAP a mano. Según la documentación del repositorio en GitHub, la lista de funciones incluye:

• Usuarios, grupos, OUs y cuentas de equipo: se buscan, crean, editan y borran desde el navegador, con acceso a atributos crudos del directorio cuando hace falta.
• Varios directorios en simultáneo: una sola instancia puede atender AD y OpenLDAP a la vez, y cada sesión queda atada al directorio con el que inició sesión.
• Roles desde grupos del directorio: un grupo como cn=helpdesk,ou=groups se mapea a un rol, y el rol controla 17 permisos. Sacás a alguien del grupo y en medio minuto pierde los derechos.
• Aprovisionamiento masivo: creación de cuentas en lotes, con un generador de logins que transliteran nombres (de cirílico a latín, por ejemplo) y valida cada login contra el directorio antes de escribir nada.
• Log de auditoría: registra cada inicio de sesión y cada cambio, incluidos los intentos rechazados, con quién lo hizo.
• API REST con OpenAPI: scripts de onboarding y offboarding pueden llamarla en lugar de hablar LDAP directo.
• Nueve idiomas de interfaz, incluidos árabe y hebreo con diseño espejado (RTL).

El dato que llama la atención acá es el de los 959 tests automatizados que, según el propio repositorio, cubren tanto la API como la consola. No es una cifra que uno vea seguido en un proyecto en etapa MVP.

¿Cómo evita Axia que un rol de helpdesk escale privilegios sobre un administrador?

Axia aplica cinco reglas puntuales para que nadie con permisos de helpdesk termine, de rebote, con control sobre una cuenta de administrador. El equipo las documentó en detalle en un artículo complementario sobre cinco “trampas” típicas de las consolas web para directorios. Son estas:

• Nadie actúa sobre quien tiene más derechos: la jerarquía se mide con los roles de Axia y con los grupos protegidos del propio directorio (localizados por SID, resolviendo anidamiento y grupo primario). Un rol de helpdesk que resetea contraseñas no puede resetear la de un Domain Admin.
• Mover o renombrar una OU cuenta como cambio de permisos: si la OU contiene un grupo que otorga un rol, solo alguien que ya tiene ese rol puede moverla.
• Reapuntar una conexión exige reingresar la contraseña de bind: sin esta regla, cualquiera que pudiera editar una conexión podría mandar la contraseña de la cuenta de servicio guardada a un host propio (un ataque conocido como LDAP pass-back).
• La fuerza bruta por consola no bloquea cuentas de AD: un bloqueo en el directorio frena nuevos inicios de sesión pero no corta sesiones activas, así que nadie puede sacar a un admin a los golpes de contraseñas falladas. Los intentos fallidos se limitan por cuenta, por debajo del umbral del propio directorio.
• Las contraseñas se escriben como el directorio espera: unicodePwd sobre conexión cifrada en AD, y la operación extendida Password Modify en OpenLDAP. Nunca como atributo userPassword en texto plano.

Ya cubrimos antes un tema relacionado de delegación en AD: errores comunes al configurar GPO en Azure AD.

¿Suena como mucho trabajo de ingeniería para algo que “debería” venir gratis con cualquier panel de administración? Y sí, exactamente por eso lo documentaron en un artículo separado: porque cada una de estas protecciones nació de un bug real que encontraron mientras construían la herramienta.

¿Cómo instalar y probar Axia con Docker?

Instalar Axia para probarlo toma unos minutos con Docker y Compose v2, sin nada más que configurar de entrada. Los pasos, tomados directo del repositorio oficial, son:

• Cloná el repositorio: git clone https://github.com/Nelsar/Axia.git y entrá a la carpeta con cd Axia.
• Levantá los contenedores: docker compose up descarga las imágenes publicadas en GHCR para amd64 y arm64; con --build las compila desde el checkout local.
• Abrí la consola: en http://localhost:8080. El demo trae un OpenLDAP con una cuenta por rol, y todas las contraseñas son Axia-Demo-1.
• Probá el caso límite: iniciá sesión como editor.demo e intentá resetear la contraseña de admin.demo. Si el sistema está bien armado, te lo va a negar.

Para producción hay imágenes en ghcr.io y Docker Hub (nelsar/axia-api, nelsar/axia-console) y un instalador para Windows que corre Axia como servicio. Los datos se guardan en PostgreSQL o SQLite, según lo que prefieras. Si lo vas a sacar del laboratorio y ponerlo en producción, necesitás un servidor propio donde alojarlo (Axia es self-hosted, no un SaaS), y ahí un VPS cumple sin vueltas para correr los contenedores de la API y la consola.

¿Qué limitaciones tiene la versión actual de Axia (v0.3)?

Axia es un MVP en versión 0.3, y el propio equipo de Nelsar prefiere que las limitaciones se sepan de entrada antes de instalarlo en producción. Las principales, según el anuncio:

• Sin cierre de sesión ni revocación de token: un token de sesión vive 60 minutos. Deshabilitar la cuenta en el directorio corta la sesión en 30 segundos, pero no hay un “logout” que invalide el token al instante.
• Sin 2FA ni login por OpenID Connect todavía: ambos están en el roadmap, con TOTP obligatorio según el rol y sign-in vía Entra ID, AD FS o Keycloak.
• Sin verificación de revocación de certificados (CRL, OCSP) para los certificados del directorio.
• Pensado para una sola instancia: los jobs masivos y los contadores de login viven en memoria, sin soporte multi-instancia todavía.
• El instalador de Windows no está firmado con código: cada release trae en cambio una atestación de procedencia de build, verificable con gh attestation verify.

Errores comunes al delegar tareas de Active Directory

Delegar sin pensar en estos puntos es la forma más rápida de terminar con un helpdesk que tiene más poder del que debería. Sobre eso hablamos en cómo detectar un ataque DCSync a tiempo.

• Dar RSAT completo “porque es más rápido”: instalar las herramientas de administración remota en la máquina de un técnico de soporte le da acceso a mucho más de lo que necesita para resetear contraseñas. La corrección es usar un panel acotado por rol, como el que propone Axia con sus 17 permisos.
• Confundir delegación de OU con control real: alguien puede tener permisos sobre una OU y, sin saberlo, heredar control sobre un grupo protegido anidado ahí adentro. Por eso Axia trata mover o renombrar una OU como un cambio de permisos en sí mismo.
• No auditar los intentos fallidos: si solo registrás los cambios exitosos, te perdés justo la evidencia de alguien probando escalar privilegios sin lograrlo. El log de Axia guarda también los intentos rechazados.
• Asumir que un MVP está listo para producción crítica: correr una versión 0.3 sin 2FA en un entorno con cuentas de Domain Admin expuestas es jugar con fuego. Para eso están las notas de “qué no hace todavía” que el propio equipo publicó.

Preguntas Frecuentes

¿Qué es Axia y para qué sirve en Active Directory?

Axia es una interfaz web y API REST de código abierto para administrar usuarios, grupos, OUs y cuentas de equipo en Active Directory, Samba AD, OpenLDAP y eDirectory. Sirve para que helpdesk o RR.HH. manejen altas, bajas y reseteos de contraseña desde el navegador, sin acceso a RSAT ni a un cliente LDAP directo.

¿Cómo evita Axia que el helpdesk escale sus propios privilegios?

Axia bloquea cualquier acción sobre una cuenta o grupo con más derechos que los del usuario que la ejecuta, midiendo esa jerarquía por roles de Axia y por grupos protegidos del directorio localizados por SID. Además trata mover una OU, reapuntar una conexión o escribir contraseñas como operaciones sensibles con sus propias reglas de permiso.

¿Axia es gratuito y de código abierto?

Sí, Axia es gratuito y está publicado bajo licencia Apache 2.0 en GitHub. El código, la documentación y las imágenes de Docker están disponibles públicamente para autohospedar sin costo de licencia.

¿Cómo se instala y prueba Axia con Docker?

Se instala clonando el repositorio de GitHub y corriendo docker compose up, que descarga las imágenes de la API y la consola. El demo queda disponible en http://localhost:8080 con cuentas de prueba para cada rol y contraseña Axia-Demo-1.

¿Axia funciona con OpenLDAP, Samba AD y eDirectory?

Sí, el proveedor StandardLdap de Axia habla LDAP estándar (RFC 4511) sobre LDAPS o StartTLS y funciona contra Active Directory, Samba AD, OpenLDAP y eDirectory por igual. Según el repositorio, la integración con Samba se prueba en CI contra un controlador de dominio Samba real.

Conclusión

Axia no inventa un concepto nuevo (la delegación de tareas de directorio existe desde siempre), pero resuelve algo que casi nadie resuelve bien: que delegar no signifique regalar poder. La propuesta concreta es un panel con roles granulares, auditoría completa y protecciones específicas contra escalada, todo open source y auditable.

Para un equipo de IT que hoy maneja todo con scripts de PowerShell sin versionar o con RSAT instalado en media oficina, vale la pena mirarlo. Eso sí: es un MVP en versión 0.3, sin 2FA todavía y sin soporte multi-instancia, así que antes de ponerlo frente a cuentas críticas conviene levantarlo en un entorno de prueba, correr el escenario de editor.demo contra admin.demo con tus propios grupos y ver si las protecciones aguantan tu estructura real de OUs. Eso no lo dice la fuente, pero es el criterio mínimo antes de confiar en cualquier herramienta de este tipo con privilegios sobre tu directorio.

Fuentes

• GitHub – Nelsar/Axia: repositorio oficial, documentación técnica y arquitectura del proyecto
• Dev.to – Anuncio original de Nelsar sobre Axia, con detalle de las protecciones contra escalada de privilegios
• Documentación online de Axia: instalación, configuración y referencia de la API REST