Proxmox VE y Active Directory: cómo sincronizar usuarios y grupos sin dejar puertas abiertas

Las claves en 30 segundos

• Proxmox no copia las contraseñas de Active Directory. Sincroniza usuarios y grupos a /etc/pve/user.cfg, y en cada inicio de sesión pregunta al controlador de dominio. Los permisos viven en Proxmox.
• El modo por defecto es ldap en el puerto 389, sin cifrar. Hay que elegir ldaps o ldap+starttls y activar la verificación del certificado, que también viene apagada.
• Desactivar a un usuario en AD corta su login, pero no sus tokens de API. El token se valida contra user.cfg y AD ni se entera. Por eso la baja hay que completarla con filtro y remove-vanished, o a mano.
• remove-vanished borra de verdad. Si un filtro mal escrito devuelve cero usuarios y tienes activada la opción entry, se van todos. Antes de cada cambio, vista previa.
• Los grupos llegan con el nombre del realm detrás. PVE-Admins pasa a ser PVE-Admins-ad, y los permisos se asignan a ese nombre.
• Un filtro anidado no anida los grupos. El usuario entra, pero su grupo de Proxmox solo recoge a los miembros directos.
• Mantén siempre una salida. Si los controladores de dominio caen, root@pam sigue funcionando. Si lo has desactivado, te quedas fuera.

---

Con tres administradores, root@pam y un par de usuarios locales se aguanta un tiempo. Con quince personas entre sistemas, operaciones y un proveedor externo, cada alta y cada baja son una tarea más que alguien acaba olvidando. Si la empresa ya tiene Active Directory, lo razonable es que el clúster Proxmox se fíe de él.

La configuración es sencilla y está bien integrada en la interfaz. Lo que no suele contarse es cómo se comporta luego, y eso es justo lo que decide si la integración aporta seguridad o solo comodidad. Este artículo está contrastado con la documentación de Proxmox VE 9.2 y con el código de pve-access-control. No lo hemos probado contra un dominio real, así que lee la vista previa de tu sincronización antes de dar nada por hecho.

Qué hace la sincronización y qué no

En Proxmox un realm es un origen de autenticación. Vienen dos de serie (pam y pve), y se pueden añadir LDAP, Active Directory y OpenID Connect. La integración con AD hace tres trabajos distintos, y conviene no mezclarlos.

La sincronización usa una cuenta de servicio para leer usuarios y grupos, y los escribe en /etc/pve/user.cfg, que se replica a todo el clúster. Nada de contraseñas.

El inicio de sesión comprueba la contraseña contra el controlador de dominio con un bind a nombre del usuario (usuario@dominio). Si sale bien, Proxmox mira en su propia configuración qué puede hacer esa persona.

Los permisos son locales. AD dice quién eres y a qué grupos perteneces, pero la lista de control de acceso que dice qué puedes tocar se define en Proxmox.

Antes de tocar Proxmox: lo que hay que preparar en AD

Tres cosas, y ninguna tarda mucho.

Una cuenta de servicio solo para esto. Un usuario normal, sin grupos privilegiados y sin inicio de sesión interactivo, como svc-pvesync. Por defecto cualquier usuario autenticado puede leer casi todo el directorio, así que no necesita permisos especiales. Decide qué haces con la caducidad de su contraseña: si caduca sin que nadie lo apunte, la sincronización empezará a fallar y nadie mirará por qué hasta que falte un usuario.

Necesitarás su nombre distinguido completo, porque Proxmox pide un DN en el campo Bind User. Lo sacas en un controlador de dominio:

Get-ADUser svc-pvesync | Select-Object DistinguishedName

Grupos por función, no uno solo. Un único grupo con todo el mundo dentro te obliga a dar el mismo rol a todos. Mejor algo como PVE-Admins, PVE-Operadores y PVE-Auditores, sin espacios en el nombre: Proxmox descarta los grupos cuyo nombre no cumpla sus reglas de caracteres, y un Admins Proxmox se quedaría fuera.

Certificado en los controladores de dominio. LDAPS necesita que los controladores presenten un certificado válido, normalmente emitido por la CA interna. Si no existe, este es el momento de resolverlo, no un motivo para saltarse el cifrado.

El realm, sin dejar la contraseña al aire

En Datacenter > Permissions > Realms > Add > Active Directory Server. Estos son los campos que importan:

Lo mismo por línea de comandos, con la comprobación de conexión incluida:

read -rs PW   # la contraseña no se queda en el historial
pveum realm add ad --type ad \
  --domain empresa.local \
  --server1 dc1.empresa.local --server2 dc2.empresa.local \
  --mode ldaps --verify 1 --capath /etc/ssl/certs \
  --base_dn 'OU=Empresa,DC=empresa,DC=local' \
  --bind_dn 'CN=svc-pvesync,OU=Servicio,OU=Empresa,DC=empresa,DC=local' \
  --password "$PW" \
  --case-sensitive 0 \
  --check-connection 1

La contraseña de la cuenta se guarda en /etc/pve/priv/realm/ad.pw, dentro de la parte privada del sistema de ficheros del clúster.

Dos detalles que suelen dar guerra. El certificado raíz de tu CA tiene que estar en todos los nodos, porque capath apunta a una ruta local: cópialo a /usr/local/share/ca-certificates/ y ejecuta update-ca-certificates en cada uno. Y si el DN lleva comas u otros caracteres reservados, va entre comillas dobles: CN="García, Ana",OU=TI,DC=empresa,DC=local.

Por qué no vale quedarse en el puerto 389

Proxmox se autentica con un bind simple, que manda el usuario y la contraseña tal cual. Sin TLS, cualquiera que escuche en esa red los lee. Además, puede dejar de funcionar: Microsoft avisa de que, al exigir la firma LDAP en los controladores de dominio, dejan de funcionar los binds simples sobre conexiones sin SSL/TLS. Si el login de Proxmox se rompe tras un endurecimiento del dominio y el error es Strong(er) authentication required, ya sabes por dónde va.

Filtrar: traer a quien debe y a nadie más

Sin filtro, la sincronización se trae todo lo que encuentre bajo la base. Y en AD eso incluye más de lo que parece, porque las cuentas de equipo también son objetos de la clase user. Un filtro de usuarios decente para un dominio con grupos anidados:

(&(memberOf:1.2.840.113556.1.4.1941:=CN=PVE-Acceso,OU=Grupos,DC=empresa,DC=local)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Tiene dos partes. 1.2.840.113556.1.4.1941 es la regla LDAP_MATCHING_RULE_IN_CHAIN, que busca la pertenencia recorriendo grupos anidados. El memberOf normal solo ve la directa. La segunda parte descarta las cuentas desactivadas: el bit 2 de userAccountControl. Este segundo detalle es el que luego hará funcionar las bajas.

Para los grupos, algo así en Group Filter:

(|(cn=PVE-Admins)(cn=PVE-Operadores)(cn=PVE-Auditores))

Ojo con el anidamiento. Proxmox construye cada grupo leyendo su atributo member, que contiene a los miembros directos. Si Ana entra en PVE-Admins a través de un subgrupo Sistemas, el filtro la trae como usuaria, pero no aparecerá dentro de PVE-Admins-ad y no heredará sus permisos. O metes a los usuarios directamente en los grupos de Proxmox, o sincronizas también el subgrupo y le das permisos a él.

Vista previa, siempre

Antes de escribir nada en user.cfg, comprueba qué pasaría:

pveum realm sync ad --dry-run 1 --scope both

En la interfaz es el botón Preview dentro de Sync. Mira tres cosas: que no salgan cuentas de equipo, que el número de usuarios se parezca al que esperabas y que los grupos aparezcan con sus miembros. Luego lanza la sincronización real.

Los grupos llegan con el sufijo del realm, así que PVE-Admins queda como PVE-Admins-ad. Proxmox lo hace para evitar choques con grupos creados a mano.

Permisos: Administrator no es el valor por defecto

Es tentador darle Administrator en / al grupo y seguir adelante. Ese rol tiene todos los privilegios, incluidos los de cambiar la configuración del sistema y los permisos de los demás. En la práctica, cualquiera que controle ese grupo en AD controla el clúster, así que el equipo que gestiona el dominio pasa a mandar también sobre la virtualización.

pveum acl modify / --groups PVE-Operadores-ad --roles PVEAdmin
pveum acl modify / --groups PVE-Auditores-ad --roles PVEAuditor

PVEAdmin no incluye Sys.PowerMgmt, Sys.Modify, Realm.Allocate ni Permissions.Modify, y para el día a día suele sobrar. Si necesitas aislar a un cliente o a un equipo, usa pools y da el rol en /pool/<nombre>. Lo explicamos con más detalle en cómo endurecer el acceso a Proxmox.

Comprueba el acceso cerrando sesión y entrando con el realm ad seleccionado. El usuario se escribe sin dominio: ana.

Automatizar sin borrar lo que no toca

Los trabajos de sincronización existen en la interfaz desde Proxmox VE 8.0, en Datacenter > Permissions > Realms > Realm Sync Jobs. Cada media hora es razonable para un equipo normal; también se puede crear por API:

pvesh create /cluster/jobs/realm-sync/ad-sync \
  --realm ad --schedule '*/30' --scope both \
  --remove-vanished 'acl;entry;properties'

La decisión importante es remove-vanished, que dice qué hacer con lo que ya no devuelve la sincronización. El código deja claro su efecto:

entry y acl tienen sentido juntos. properties solo si AD es la única fuente de nombres y correos: borra también lo que hayas escrito a mano, como un comentario o una fecha de caducidad.

El riesgo real de entry. Si cambias el filtro y por un error devuelve cero usuarios, sin ningún fallo de conexión, la siguiente pasada los elimina a todos junto con sus tokens y permisos directos. Un trabajo programado no pide confirmación. Por eso cualquier cambio de filtro pasa antes por --dry-run.

Qué pasa de verdad cuando alguien se va

Aquí es donde la integración se queda corta si se monta deprisa. La sincronización no copia el estado de la cuenta de AD: no hay un campo que diga «desactivado» y que llegue a Proxmox. Y verify_token, la función que valida un token de API, solo comprueba user.cfg: que el usuario esté activado, que el token exista y que no haya caducado. A AD no le pregunta nada.

Esta es la razón del filtro con userAccountControl. Combinado con remove-vanished=acl;entry, la cuenta desactivada desaparece de la respuesta y Proxmox la elimina con sus tokens. La ventana de exposición es el intervalo del trabajo, y si la baja es urgente puedes lanzarlo a mano con pveum realm sync ad.

También queda otro hueco, aunque más pequeño: una sesión ya abierta en la interfaz no se consulta contra AD, así que dura lo que le quede a su ticket. En una baja delicada, desactiva al usuario también en Proxmox:

pveum user modify ana@ad --enable 0

Y mejor aún, evita que las cuentas de personas tengan tokens para automatizaciones. Un script de copias no debería dejar de funcionar porque alguien cambió de empresa, ni seguir funcionando con los permisos de esa persona. Para eso, un usuario de servicio del realm pve con el mínimo de privilegios.

Doble factor y la salida de emergencia

Autenticarse contra AD no impide exigir un segundo factor. El realm admite TFA forzado (TOTP o YubiKey) en su configuración, y con eso solo entrarán los usuarios que lo tengan configurado: actívalo cuando todos lo hayan hecho, no antes. Los usuarios también pueden registrar WebAuthn por su cuenta.

Queda la pregunta de qué pasa si caen los dos controladores de dominio, o si los apagas en el mismo clúster que depende de ellos para entrar. La respuesta es root@pam. Sigue siendo local, no pasa por AD y es tu salida, así que guarda su contraseña en un sitio al que puedas llegar con el directorio caído. Si los controladores de dominio son VM del propio clúster, reparte al menos uno en otro nodo o, mejor, fuera de él.

Fallos habituales

Lista de comprobación

1. Cuenta de servicio sin privilegios y con la caducidad de su contraseña bajo control.
2. Grupos por función y sin espacios.
3. Modo ldaps o ldap+starttls, con verificación activada y CA en todos los nodos.
4. Filtro de usuarios por grupo y sin cuentas desactivadas.
5. Vista previa antes de la primera sincronización y de cada cambio de filtro.
6. Rol mínimo por grupo y Administrator para muy pocos.
7. Trabajo programado con remove-vanished=acl;entry, salvo motivo para no usarlo.
8. Procedimiento de baja que revise los tokens de la persona.
9. TFA forzado cuando todo el equipo lo tenga configurado.
10. root@pam accesible con AD caído, y probado.

Cómo lo hacemos en Cloud Privado

Cuando integramos un clúster gestionado con el directorio de un cliente, tratamos la baja como parte del diseño: filtro por grupo, LDAPS verificado, cuentas de servicio separadas de las personales y un acceso de emergencia que no dependa de AD. Si quieres verlo aplicado a tu entorno, en Proxmox en cloud privado contamos cómo trabajamos.

Preguntas frecuentes

¿Proxmox guarda las contraseñas de Active Directory?

No. Solo guarda la de la cuenta de servicio, en /etc/pve/priv/realm/. Las de los usuarios se comprueban en cada login contra el controlador de dominio.

¿Es mejor el tipo LDAP o el de Active Directory?

Para AD, el tipo Active Directory: incluye el dominio, usa sAMAccountName por defecto y hace el login como usuario@dominio. El tipo LDAP tiene más sentido para OpenLDAP y similares.

¿Hace falta rellenar el Base DN?

En Active Directory no es obligatorio, porque Proxmox lee defaultNamingContext del servidor. Aun así conviene acotarlo a la OU que te interese, para que las búsquedas sean más pequeñas.

¿Qué pasa si los controladores de dominio no responden?

Los usuarios de AD no pueden iniciar sesión y la sincronización falla. Las máquinas virtuales no se enteran, y root@pam y los usuarios del realm pve siguen entrando.

¿Un usuario desactivado en AD pierde el acceso?

Pierde el login, pero no sus tokens de API, que se validan solo dentro de Proxmox. Para que caigan hace falta que deje de aparecer en la sincronización con remove-vanished activado, o desactivarlo en Proxmox.

¿Se puede usar SAML o OpenID Connect en lugar de LDAP?

Proxmox VE admite OpenID Connect de forma nativa, por ejemplo con Entra ID o Keycloak: los usuarios pueden crearse en su primer acceso y los grupos pueden llegar en un claim. SAML no está entre los realms que trae de serie.

Fuentes

• Proxmox, gestión de usuarios y realms de Proxmox VE y Roadmap.
• Código de Proxmox: AD.pm, LDAP.pm, Domains.pm y AccessControl.pm, consultados el 5 de noviembre de 2026.
• Microsoft, cómo habilitar la firma LDAP y sintaxis de los filtros de búsqueda.

---

¿Tu clúster sigue viviendo de usuarios locales o quieres revisar cómo se dan las bajas? En Cloud Privado te ayudamos a integrarlo con tu directorio sin dejar accesos olvidados, sobre Proxmox gestionado en centros de datos en España.