Proxmox: Fallos de inicio de sesión LDAP/AD — dónde se rompe la cadena de autenticación y cómo solucionarlo

octubre 9, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 9

¿Te fue útil?

Cuando el inicio de sesión LDAP/AD en Proxmox falla, no tienes “un problema LDAP”. Tienes una cadena rota: resolución de nombres, red, TLS, bind, búsqueda, resolución de grupos, mapeo de usuario, permisos y, finalmente, la propia pila de autenticación de Proxmox. Un eslabón débil y la interfaz muestra “authentication failure” como si te hiciera un favor.

Esta guía recorre la cadena en el orden en que realmente falla en producción, con comandos que puedes ejecutar ahora mismo, qué significa la salida y qué decisión tomar a continuación. Sin misterio. Sin “prueba reiniciar” como filosofía de trabajo.

La cadena de autenticación: qué hace Proxmox realmente cuando inicias sesión

La autenticación de Proxmox VE (PVE) no es un solo subsistema. Es un conjunto de realms más un modelo de permisos más un poco de pegamento. Si no entiendes ese pegamento, arreglarás la capa equivocada y “funciona en mi portátil” te llevará a un incidente.

Paso 0: ¿Qué realm estás usando realmente?

Proxmox soporta realms como:

pam: cuentas Linux locales autenticadas vía PAM (que podrían estar respaldadas por LDAP/SSSD, pero esa es otra cadena).
pve: usuarios locales de Proxmox guardados en /etc/pve/user.cfg.
ldap: directorio externo via LDAP (OpenLDAP, AD vía LDAP).
ad: tipo de realm para Active Directory (sigue siendo LDAP bajo el capó, pero con defaults estilo AD como manejo de grupos).

Los usuarios inician sesión como user@realm. Si tu equipo sigue escribiendo user@pam por costumbre, puedes afinar LDAP hasta la muerte térmica del universo y no ayudará.

Paso 1: ¿Puede PVE alcanzar el servicio de directorio?

Antes de la autenticación, Proxmox debe resolver los nombres de DC/LDAP, enrutar hacia ellos y abrir una conexión TCP. Para AD, eso suele significar elegir el DC correcto (o múltiples) y no dejar que el DNS te engañe.

Paso 2: TLS (LDAPS o StartTLS) funciona o no

LDAP sobre TLS es el primer sitio donde “funciona en pruebas” muere en producción. Certificados, SNI, SANs, cadenas intermedias y relojes importan. Si LDAPS falla, Proxmox a menudo lo reporta como un error de autenticación porque el bind no llegó a ocurrir.

Paso 3: El bind funciona

Proxmox puede hacer bind como:

Anónimo (rara vez permitido en AD; a menudo deshabilitado en LDAP endurecido).
Cuenta de servicio (el caso común; se usa para buscar usuarios y grupos).
Bind de usuario directo (DN del usuario derivado de una plantilla, luego bind como ese usuario).

Un bind exitoso prueba las credenciales y (a menudo) que la negociación TLS fue correcta.

Paso 4: La búsqueda encuentra la entrada del usuario

Aquí es donde importan el base DN y los filtros. Si la búsqueda devuelve cero entradas, Proxmox no puede mapear el nombre de usuario que escribiste a un DN, y obtendrás “login failed” aunque la contraseña sea correcta.

Paso 5: El mapeo de grupos/roles decide qué puedes hacer

Incluso si la autenticación tiene éxito, la autorización puede fallar de formas que parecen fallos de autenticación (por ejemplo, “inicias sesión” pero no ves nada; o las llamadas API devuelven 401/403). Los permisos de Proxmox son tipo RBAC y separados de la autenticación. La pertenencia a grupos en AD debe mapearse a grupos/roles de Proxmox, o habrás creado una identidad preciosa sin derechos—como entregar una tarjeta que no abre ninguna puerta.

Paso 6: Consistencia de la configuración del clúster Proxmox

Proxmox almacena la configuración de autenticación en el sistema de archivos del clúster (/etc/pve). Si el clúster está particionado o un nodo está en un estado extraño, un nodo puede tener la configuración del realm que otros no. Entonces fallan solo “algunos inicios de sesión”, que es la categoría favorita de incidentes.

Una idea parafraseada de Werner Vogels (CTO de Amazon): “Lo construyes, lo operas”. Si lo operas, necesitas depurarlo sin conjeturas.

Guía de diagnóstico rápido (comprobar primero/segundo/tercero)

Este es el orden que reduce el tiempo hasta la verdad. Es intencionalmente aburrido. Aburrido es rápido.

Primero: identifica el realm y reproduce desde CLI

Confirma el formato del nombre de usuario (alice@ad vs alice@ldap vs alice@pam).
Usa la CLI de Proxmox para validar que la configuración del realm existe en el nodo que maneja el login.
Prueba el bind/búsqueda LDAP desde el nodo con ldapsearch (o openssl s_client para TLS).

Segundo: prueba red + DNS + hora

El DNS resuelve los DC correctamente desde el nodo Proxmox.
TCP conecta a 389/636 y no hay firewall/NAT extraño.
El desfase de reloj es razonable (TLS y Kerberos no perdonan viajes en el tiempo).

Tercero: valida bind DN, base DN, filtro de usuario y atributos de grupo

Las credenciales de bind son correctas y no están bloqueadas/expiradas.
El base DN es correcto e incluye los objetos de usuario que esperas.
El filtro de usuario coincide con el esquema del directorio (diferencias AD vs OpenLDAP).
Los atributos de pertenencia a grupos coinciden con lo que Proxmox espera para tu tipo de realm.

Cuarto: confirma el mapeo de autorización en Proxmox

El usuario está presente en el mapeo de usuarios/grupos de Proxmox (o auto-provisionado si está configurado).
Roles y ACLs conceden al menos PVEAuditor o similar donde sea necesario.

Quinto: escalar a logs y captura de paquetes

Lee los logs de pveproxy y pvedaemon para la cadena de error exacta.
Usa tcpdump para confirmar el handshake TLS y si los binds ocurren o no.

Disciplina en una frase: no toques Proxmox hasta que puedas reproducir el fallo con ldapsearch desde el nodo que falla.

Hechos interesantes y contexto (por qué esto es más enrevesado de lo que debería)

Hecho 1: LDAP data de principios de los 1990 como alternativa ligera a X.500. “Ligero” se ha convertido en un rasgo de personalidad, no en una garantía.
Hecho 2: Active Directory habla LDAP, pero no es “solo LDAP”. AD mezcla LDAP con Kerberos, registros SRV de DNS y comportamientos de políticas que sorprenden a quienes vienen de OpenLDAP.
Hecho 3: LDAPS (LDAP sobre 636) compitió históricamente con StartTLS (LDAP + upgrade). Muchas empresas aún usan ambos, según la antigüedad del cliente.
Hecho 4: La pertenencia a grupos en AD se recupera comúnmente desde el atributo memberOf, pero los grupos anidados requieren lógica extra (o reglas de coincidencia) que no todos los clientes implementan igual.
Hecho 5: Microsoft ha endurecido comportamientos LDAP en AD con el tiempo (signing, channel binding, desuso de cifrados débiles). Una actualización de Proxmox puede “romper LDAP” cuando en realidad el DC está aplicando seguridad moderna.
Hecho 6: Los certificados fallan con más frecuencia por desajuste de nombres que por criptografía. Los humanos son excelentes nombrando mal las cosas, especialmente bajo presión.
Hecho 7: El sistema de archivos del clúster de Proxmox (pmxcfs) hace la config de auth consistente—hasta que el clúster está enfermo, momento en que la consistencia se vuelve sugerente.
Hecho 8: Muchos errores LDAP “credenciales inválidas” son en realidad “bind DN no encontrado” o “cuenta bloqueada”, porque los servidores devuelven mensajes vagos para no filtrar información.

Tareas prácticas: comandos, salidas, decisiones (12+)

Ejecuta estos en el nodo Proxmox donde falla el inicio de sesión. Si tienes un clúster detrás de un balanceador, ese detalle importa más de lo que nadie quiere admitir.

Tarea 1: Lista los realms configurados y verifica que exista el correcto

cr0x@server:~$ pveum realm list
Realm    Type  Comment
pam      pam
pve      pve
ad       ad    Corporate AD

Qué significa: El realm ad existe en este nodo. Si no existe, estás depurando el nodo equivocado o la configuración del clúster no es consistente.

Decisión: Si falta el realm en un nodo, arregla la salud del clúster o recrea el realm desde un nodo sano. No “lo añadas localmente”; Proxmox quiere esto en /etc/pve.

Tarea 2: Volcar la config del realm (sanity-check bind DN, base DN, servidor)

cr0x@server:~$ pveum realm config ad
base_dn          dc=corp,dc=example,dc=com
bind_dn          svc_pve@corp.example.com
capath           /etc/ssl/certs
default          0
domain           corp.example.com
group_classes    group
password         **********
port             636
secure           1
server1          dc01.corp.example.com
user_attr        sAMAccountName

Qué significa: Esto es lo que Proxmox usará. Fíjate en server1, port, secure, base_dn y el atributo de usuario.

Decisión: Si server1 es un nombre corto sin un SAN coincidente en el certificado, espera fallos TLS. Usa un FQDN que coincida con el certificado.

Tarea 3: Verificar resolución DNS (y capturar “dominios de búsqueda” “útiles”)

cr0x@server:~$ getent hosts dc01.corp.example.com
10.10.10.11   dc01.corp.example.com

Qué significa: El nodo resuelve el DC. Si resuelve a una IP distinta de la esperada, podrías estar alcanzando el DC equivocado o un registro obsoleto.

Decisión: Si la resolución es incorrecta, arregla /etc/resolv.conf (o systemd-resolved), no Proxmox. La autenticación depende del DNS correcto.

Tarea 4: Confirmar conectividad TCP hacia LDAP/LDAPS

cr0x@server:~$ nc -vz dc01.corp.example.com 636
Connection to dc01.corp.example.com 636 port [tcp/ldaps] succeeded!

Qué significa: La ruta de red está abierta. Si falla, detente y arregla enrutamiento/firewall primero.

Decisión: Si 636 está bloqueado pero 389 funciona, decide si puedes usar StartTLS en 389 o debes abrir 636.

Tarea 5: Inspeccionar handshake TLS y nombres del certificado

cr0x@server:~$ openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = dc01.corp.example.com
issuer=CN = Corp Issuing CA 01, O = Corp
notBefore=Oct  1 00:00:00 2025 GMT
notAfter=Oct  1 00:00:00 2027 GMT
X509v3 Subject Alternative Name:
    DNS:dc01.corp.example.com, DNS:dc01

Qué significa: El certificado coincide con el nombre que usaste. Si el SAN no incluye el FQDN, Proxmox puede rechazar TLS (según la configuración).

Decisión: Si los nombres no coinciden, usa el nombre que coincida con el certificado o arregla el certificado. No desactives la verificación salvo que disfrutes incidentes prevenibles.

Tarea 6: Validar la cadena CA que confía Proxmox

cr0x@server:~$ openssl verify -CApath /etc/ssl/certs <(openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com /dev/null | openssl x509)
stdin: OK

Qué significa: El nodo confía en la cadena emisora.

Decisión: Si esto falla, instala tu CA empresarial en el almacén de confianza del SO y actualiza certificados. Arregla la confianza una vez, no por aplicación.

Tarea 7: Probar que el bind funciona con ldapsearch (cuenta de servicio)

cr0x@server:~$ ldapsearch -H ldaps://dc01.corp.example.com:636 -D 'svc_pve@corp.example.com' -W -b 'dc=corp,dc=example,dc=com' -s base '(objectClass=*)' defaultNamingContext
Enter LDAP Password:
dn:
defaultNamingContext: DC=corp,DC=example,DC=com

Qué significa: TLS funciona, el bind funciona, el base DN es reachable.

Decisión: Si obtienes Invalid credentials (49), verifica el formato de la identidad de bind. AD suele aceptar UPN (user@domain) o DN completo; elige uno y sé consistente.

Tarea 8: Buscar la entrada del usuario de la misma forma que lo hará Proxmox

cr0x@server:~$ ldapsearch -H ldaps://dc01.corp.example.com:636 -D 'svc_pve@corp.example.com' -W -b 'dc=corp,dc=example,dc=com' '(sAMAccountName=alice)' dn sAMAccountName userPrincipalName memberOf
Enter LDAP Password:
dn: CN=Alice Nguyen,OU=Users,DC=corp,DC=example,DC=com
sAMAccountName: alice
userPrincipalName: alice@corp.example.com
memberOf: CN=PVE-Admins,OU=Groups,DC=corp,DC=example,DC=com
memberOf: CN=VM-Operators,OU=Groups,DC=corp,DC=example,DC=com

Qué significa: El usuario existe y puede encontrarse mediante el atributo elegido.

Decisión: Si la búsqueda no devuelve nada, arregla base_dn y el filtro/atributo de usuario. No toques contraseñas; son inocentes hasta demostrar lo contrario.

Tarea 9: Comprobar grupos anidados si tu RBAC depende de ellos

cr0x@server:~$ ldapsearch -H ldaps://dc01.corp.example.com:636 -D 'svc_pve@corp.example.com' -W -b 'dc=corp,dc=example,dc=com' '(&(objectClass=user)(sAMAccountName=alice)(memberOf:1.2.840.113556.1.4.1941:=CN=PVE-Admins,OU=Groups,DC=corp,DC=example,DC=com))' dn
Enter LDAP Password:
dn: CN=Alice Nguyen,OU=Users,DC=corp,DC=example,DC=com

Qué significa: La “matching rule in chain” de AD confirma la pertenencia anidada. Si necesitas grupos anidados y tu configuración no los contempla, la autorización será inconsistente.

Decisión: Decide si vas a soportar grupos anidados (y pruébalo deliberadamente) o impone “no anidamiento para grupos PVE” para mantener el comportamiento predecible.

Tarea 10: Inspeccionar logs de Proxmox durante un intento de login

cr0x@server:~$ journalctl -u pveproxy -u pvedaemon --since "10 minutes ago" | tail -n 30
Dec 26 09:40:12 pve01 pveproxy[2211]: authentication failure; rhost=10.10.20.55 user=alice@ad msg=ldap_bind: Invalid credentials (49)
Dec 26 09:40:12 pve01 pvedaemon[2198]: user authentication failed: alice@ad

Qué significa: Proxmox llegó hasta el bind (o lo intentó) y recibió un error LDAP. La cadena de error es tu brújula.

Decisión: Si ves errores TLS en su lugar (handshake/verify), deja de mirar la configuración de usuario y arregla confianza/certs/hora.

Tarea 11: Forzar una sincronización del realm y ver qué ocurre

cr0x@server:~$ pveum realm sync ad
syncing users
syncing groups
OK

Qué significa: Proxmox puede consultar objetos del directorio usando la config del realm. Si falla, suele imprimir un error LDAP significativo.

Decisión: Si la sincronización funciona pero el inicio de sesión falla, sospecha desajuste de atributos de usuario, problemas de contraseña o selección de realm en el login.

Tarea 12: Verificar que el usuario existe desde la vista de Proxmox y ver permisos

cr0x@server:~$ pveum user list | grep -E 'alice@ad|userid'
alice@ad

Qué significa: Proxmox conoce al usuario. Eso no garantiza permisos, solo mapeo de identidad.

Decisión: Si el usuario no aparece y dependes de sync, arregla los filtros de sync. Si no dependes de sync, decide si vas a gestionar usuarios PVE localmente o vía sync—elige uno y documéntalo.

Tarea 13: Comprobar ACLs (porque “login funciona” pero la UI está vacía sigue siendo un fallo)

cr0x@server:~$ pveum acl list | grep -i alice
/ - user alice@ad - role PVEAuditor

Qué significa: El usuario tiene al menos un rol asignado en la raíz. Si esto falta, el usuario puede autenticarse pero no ver casi nada.

Decisión: Si quieres acceso dirigido por grupos AD, asigna roles a grupos, no a usuarios individuales, y mantén la lista de ACLs manejable.

Tarea 14: Verificar el mapeo de grupos desde AD hacia Proxmox

cr0x@server:~$ pveum group list
Administrators
VMOperators

Qué significa: Estos son grupos de Proxmox (no necesariamente grupos de AD). Debes mapear grupos AD a grupos de Proxmox o usar ACLs directamente contra usuarios.

Decisión: Si tu organización espera “grupo AD otorga derechos en Proxmox”, implementa ese mapeo explícitamente. Las expectativas no son configuraciones.

Tarea 15: Comprobar la salud del sistema de archivos del clúster (la config de auth depende de ello)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             2025-12-26 09:42:33
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.12
Quorate:          Yes

Qué significa: El clúster tiene quórum y la configuración debería ser consistente. Si no hay quórum, espera rarezas incluyendo config de auth obsoleta.

Decisión: Si se pierde el quórum, no hagas cirugía de auth: arregla el clúster primero.

Tarea 16: Prueba a nivel de paquetes cuando todo “parece bien”

cr0x@server:~$ tcpdump -i vmbr0 -nn host 10.10.10.11 and port 636 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:43:10.120345 IP 10.10.10.21.49122 > 10.10.10.11.636: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7], length 0
09:43:10.120611 IP 10.10.10.11.636 > 10.10.10.21.49122: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 200 ecr 100,nop,wscale 7], length 0
09:43:10.120744 IP 10.10.10.21.49122 > 10.10.10.11.636: Flags [.], ack 1, win 502, options [nop,nop,TS val 101 ecr 200], length 0

Qué significa: SYN/SYN-ACK/ACK prueba la conectividad. Si no ves tráfico durante intentos de login, tu nodo Proxmox ni siquiera está intentando alcanzar el directorio—realm equivocado, nodo equivocado o config no aplicada.

Decisión: Si los paquetes fluyen pero la autenticación aún falla, céntrate en TLS/bind/búsqueda en lugar de enrutamiento.

Dónde se rompe: modos de fallo por capa

Capas 1: IU y selección de realm (el problema de la “puerta equivocada”)

La pantalla de login de Proxmox tiene un desplegable de realm. Los usuarios eligen el realm equivocado. Siempre eligen el realm equivocado. Si tienes pam y ad habilitados, “pam” ganará la competición de popularidad porque suena familiar.

Solución: Establece un realm por defecto claro, comunícalo y considera restringir inicios locales a cuentas de emergencia.

Broma #1: LDAP es el único protocolo donde “Invalid credentials” puede significar “tu contraseña está mal”, “tu cuenta está bloqueada” o “la luna está en retroceso”.

Capas 2: DNS y selección de DC (catástrofe silenciosa)

AD depende del DNS. Si tus nodos Proxmox no usan DNS integrado con AD (o al menos no pueden resolverlo correctamente), puedes obtener:

Búsquedas que devuelven un DC fuera de servicio.
Confusión por split-horizon donde los nombres internos se resuelven externamente.
Adición de dominios de búsqueda que convierten dc01 en dc01.lab.example.com.

Solución: Usa FQDNs en la configuración del realm. Asegura que los nodos Proxmox usen los resolvers correctos. No confíes en dominios de búsqueda “amistosos”. Ayudan del mismo modo que un gato ayuda con un rompecabezas.

Capas 3: Hora (TLS y Kerberos se preocupan)

Aunque uses binds LDAP (no Kerberos), la validación de certificados TLS depende de la hora. El desfase de reloj produce errores de certificado “no válido aún” o “expirado” que parecen fallos TLS.

Solución: Haz NTP aburrido y redundante. Si tus nodos no mantienen la hora, tu pila de auth es un adorno.

Capas 4: Confianza TLS e identidad del certificado

La mayoría de los despliegues AD empresariales usan PKI interna. Si Proxmox no confía en tu CA, LDAPS falla. Si te conectas a dc01 pero el cert dice dc01.corp.example.com, LDAPS falla. Si falta un intermedio, LDAPS falla. Si la política TLS cambia en el DC, los clientes antiguos fallan.

Solución: Pon tu CA en el almacén de confianza del SO. Usa nombres que coincidan con los SANs. Mantén la cadena intacta. Prefiere políticas TLS modernas, pero pruébalas con clientes reales, no con esperanzas.

Capas 5: Formatos de identidad de bind (UPN vs DN vs DOMAIN\user)

AD acepta varias formas, pero no siempre en los mismos contextos. La config del realm en Proxmox puede usar estilo UPN (svc_pve@corp.example.com) o DN completo (CN=svc_pve,OU=Service Accounts,...). Si tu cuenta de servicio se mudó de OU y hardcodeaste el DN, obtendrás fallos de bind. Si la contraseña cambió y nadie actualizó Proxmox, obtendrás fallos de bind.

Solución: Usa UPN para cuentas de servicio cuando sea posible (menos acoplado a OU). Documenta la propiedad de esa credencial. Rótala con plan, no por intuición.

Capas 6: Base DN y filtros (la discusión “el usuario existe, te lo juro”)

La gente pone base_dn demasiado estrecho (una OU) y luego añade usuarios en otro sitio. O copian un filtro de OpenLDAP a AD y se preguntan por qué uid no coincide con nada.

Solución: Establece el base DN en la raíz del dominio salvo que tengas una razón fuerte. Si debes acotar, incluye todas las OUs relevantes y manténlo.

Capas 7: Resolución de pertenencia a grupos (grupos anidados, elección de atributos)

Puedes autenticar sin un manejo correcto de grupos, pero no autorizar correctamente. Los grupos anidados de AD son una trampa clásica: el usuario muestra memberOf solo para pertenencias directas. Tu política dice “PVE-Admins” pero los usuarios son miembros vía anidamiento. Mitad del equipo tiene acceso, la otra mitad no, y todos culpan a Proxmox.

Solución: Decide si permites grupos anidados. Si sí, pruébalo. Si no, haz gobernanza del directorio para evitarlo.

Capas 8: Permisos y tokens de Proxmox (auth vs authz)

El login en Proxmox está separado de los permisos. Un usuario puede autenticarse y aún así no ver nada. Además: los tokens API y las sesiones de usuario se comportan distinto que inicios interactivos. No depures una falla de token API cambiando filtros LDAP.

Solución: Da a los usuarios un rol mínimo en la ruta correcta. Usa grupos para ACLs. Mantén cuentas locales de emergencia y audita su uso agresivamente.

Capas 9: Rarezas del clúster (funcionaba en node1)

En un clúster es común probar en un nodo, declarar éxito y luego recibir alertas porque los logins fallan en otro nodo. Normalmente eso es:

Nodo sin quórum, config obsoleta.
DNS o políticas de firewall distintas por nodo.
Estado del almacén de confianza CA distinto (alguien “lo arregló” manualmente una vez).

Solución: Trata dependencias de auth (DNS, CA, hora, firewall) como configuración gestionada a escala de clúster, no como ajustes artesanales por nodo.

Tres micro-historias corporativas (cómo falla esto en el trabajo)

Micro-historia 1: El incidente causado por una suposición equivocada

Estaban migrando desde un entorno vSphere heredado a Proxmox, a mitad de trimestre, con la radiación de fondo habitual de plazos. El equipo de AD entregó una cuenta de servicio y dijo: “Puede leer usuarios y grupos”. El equipo de Proxmox asumió que eso significaba que podía leer todos los usuarios y grupos bajo el dominio. No podía.

En AD, habían delegado permisos de lectura solo a una OU específica donde vivían “admins de servidores”. El base DN del realm de Proxmox era la raíz del dominio, así que las búsquedas cruzaban a áreas donde esa cuenta de servicio no tenía derechos. En pruebas, quienes intentaban iniciar sesión casualmente estaban en la OU delegada. En producción, la mitad del NOC estaba en otra OU. El inicio de sesión falló para ellos, pero no para el ingeniero on-call, lo cual es un tipo especial de engaño.

La primera reacción fue predecible: alguien intentó cambiar filtros de usuario, luego otro deshabilitó la verificación TLS “temporalmente”. Eso no ayudó, porque el problema no era TLS ni filtros. Era la autorización dentro de AD para la cuenta de bind.

Lo arreglaron alineando alcance con permisos: o bien ampliar los derechos de lectura de la cuenta de servicio (preferible, con alcance mínimo) o estrechar el base DN a la OU prevista y documentar el acoplamiento. Hicieron ambas cosas: estrecharon el alcance por ahora, crearon un RFC para extender permisos de lectura correctamente y añadieron una prueba de login para un usuario fuera de la OU original al checklist de despliegue.

Micro-historia 2: La optimización que se volvió en contra

Otro equipo tuvo la “eficiente” idea de apuntar Proxmox a un único DC porque “reduce latencia” y facilita troubleshooting. Eligieron el DC en el mismo pasillo del rack. Todo iba bien—hasta la noche de parches.

El equipo Windows parchó ese DC y se reinició. Durante unos 12 minutos, LDAP/LDAPS no estuvo disponible. Los nodos Proxmox intentaron autenticar; los logins fallaron; las llamadas API empezaron a devolver errores; la automatización que usaba la API empezó a reintentar agresivamente. La carga aumentó por todas partes, incluido el DC cuando volvió, y su monitorización pasó de “rojo” a “arte performativo”.

Tras el polvo, añadieron server2/server3 a la config del realm y re-probaron. Eso resolvió disponibilidad, pero descubrieron un efecto secundario: el DC secundario tenía una cadena de certificados ligeramente distinta (válida, pero emitida por un intermedio diferente). Algunos nodos Proxmox confiaban en un intermedio pero no en el otro, porque alguien había instalado certificados de manera inconsistente con el tiempo.

La solución final fue poco romántica: estandarizar la confianza CA en todos los nodos, configurar múltiples servidores LDAP y dejar de optimizar por unos pocos milisegundos en una ruta de autenticación que se ejecuta órdenes de magnitud menos que IO de almacenamiento. También añadieron un runbook de mantenimiento: parchear DCs uno a la vez y validar LDAPS desde clientes Linux antes de declarar éxito.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización tenía la costumbre: cada cambio de auth venía con un pequeño script de prueba repetible ejecutado desde cada nodo Proxmox. Nada sofisticado—solo resolución DNS, TCP connect, verificación TLS, ldapsearch bind y búsqueda de usuario. Versionaban el script y mantenían las salidas esperadas documentadas.

Durante una rotación rutinaria de CA, el equipo de CS de AD desplegó una nueva CA emisora y empezó a servir nuevas cadenas en los controladores de dominio. Muchos sistemas tuvieron problemas. Proxmox no—porque el equipo de Proxmox ya había desplegado la nueva CA en el almacén de confianza del SO en cada nodo como parte del plan de cambio, una semana antes, con verificación.

Lo que parecía suerte era en realidad disciplina barata: “el almacén de confianza es configuración gestionada”, no “algo que arreglas cuando se rompe”. Su auth no falló, lo que dejó su plataforma de virtualización aburrida mientras otros equipos triageaban incendios de certificados.

No ganó premios. Salvó un fin de semana. En operaciones empresariales, ese es el mejor premio.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “Login failed” para todos; los logs mencionan TLS/handshake

Causa raíz: Proxmox no confía en la cadena de certificados AD/LDAP, o el hostname no coincide con el SAN del certificado.

Solución: Instala la CA empresarial en el almacén de confianza del SO, verifica con openssl verify, usa FQDN que coincida con el SAN. Evita desactivar la verificación salvo que quieras permitir que atacantes inicien sesión como tu servidor de directorio.

2) Síntoma: “Invalid credentials (49)” aunque la contraseña sea correcta

Causa raíz: Formato de bind DN incorrecto, cuenta de servicio expirado/bloqueada, o política AD que bloquea binds simples sin TLS.

Solución: Confirma bind DN/UPN, revisa estado de la cuenta en AD, asegúrate de usar LDAPS/StartTLS. Valida con ldapsearch -D ... -W desde el nodo.

3) Síntoma: Solo algunos usuarios pueden iniciar sesión

Causa raíz: Base DN demasiado estrecho, desajuste de scoping de OUs, o cuenta de servicio sin derechos de lectura en partes del directorio.

Solución: Amplía el base DN apropiadamente o ajusta la delegación en AD. Prueba con usuarios de distintas OUs.

4) Síntoma: El usuario se autentica pero ve la UI vacía o no ve nodos

Causa raíz: ACLs/roles de Proxmox faltantes; la autenticación tuvo éxito pero la autorización no.

Solución: Asigna un rol en la ruta correcta (a menudo / o /vms), idealmente vía ACLs basadas en grupos.

5) Síntoma: Funciona en node1, falla en node2

Causa raíz: Clúster no sano, configuración no replicada o diferencias por nodo en DNS/firewall/almacén de confianza.

Solución: Restaura quórum/salud del clúster, estandariza la gestión de la configuración de nodos, verifica la config del realm en cada nodo.

6) Síntoma: La sincronización del realm funciona, pero el login interactivo falla

Causa raíz: Desajuste de atributos de usuario (por ejemplo, se espera sAMAccountName pero los usuarios inician con UPN), o el usuario seleccionó el realm equivocado.

Solución: Alinea el formato de inicio de sesión con user_attr y las instrucciones de la UI. Considera establecer un realm por defecto para reducir errores humanos.

7) Síntoma: Tras endurecer seguridad, LDAP falla “aleatoriamente”

Causa raíz: Cambios en requisitos de signing/channel binding en AD, o política TLS más estricta que expone suposiciones antiguas del cliente.

Solución: Pasa a LDAPS/StartTLS con confianza válida, asegúrate de que Proxmox y bibliotecas subyacentes soporten las políticas requeridas, prueba en staging con la configuración real del DC.

8) Síntoma: Permisos basados en grupos no se aplican como se espera

Causa raíz: Grupos anidados no resueltos, atributo/clase de grupo mal configurado, o DNs de grupos que no coinciden con lo que Proxmox mapea.

Solución: Decide la estrategia de grupos anidados, valida consultas de pertenencia y mantén nombres/DN de grupos estables (o mapea usando atributos inequívocos donde sea posible).

Broma #2: La forma más rápida de encontrar tu punto único de fallo es “optimizarlo”. La autenticación es una gran maestra con un momento terrible.

Listas de verificación / plan paso a paso (hazlo aburrido)

Checklist A: Cuando construyes un nuevo realm AD/LDAP

Elige el tipo de realm (ad para AD, ldap para LDAP genérico). No te compliques salvo que debas.
Usa FQDNs para servidores DC/LDAP que coincidan con los SANs de los certificados.
Configura múltiples servidores si están disponibles (evita dependencia de un único DC).
Instala la confianza CA en el almacén del SO en cada nodo, de forma consistente.
Usa una cuenta de servicio dedicada con el principio de mínimos privilegios para leer las OUs necesarias.
Define el base DN intencionalmente. La raíz del dominio es lo más sencillo; acotar requiere gobernanza.
Decide el formato de inicio de usuario (sAMAccountName vs UPN) y alinea user_attr.
Decide la política sobre grupos anidados y pruébala con ejemplos reales.
Define el mapeo grupo→rol en Proxmox y mantenlo bajo control de cambios.
Prueba desde cada nodo (DNS, TCP, TLS, ldapsearch, login en Proxmox).

Checklist B: Cuando los inicios de sesión fallan ahora mismo y estás de guardia

Confirma el realm usado en el login y el nodo que recibe la petición.
Ejecuta pveum realm list y pveum realm config <realm>.
Comprueba DNS: getent hosts para el servidor LDAP configurado.
Comprueba TCP: nc -vz hacia 636/389.
Comprueba TLS: openssl s_client y openssl verify.
Ejecuta ldapsearch bind y búsqueda de usuario con el mismo base DN y atributo.
Revisa journalctl -u pveproxy -u pvedaemon alrededor del tiempo de fallo.
Comprueba permisos en Proxmox: pveum acl list y mapeo de grupos.
Si es multi-nodo: verifica quórum del clúster y que la config es consistente.
Solo entonces escala a captura de paquetes.

Checklist C: Endurecimientos que no te morderán después

Mantén al menos un usuario local de break-glass en Proxmox con MFA o controles fuertes (y audita su uso).
Estandariza la gestión del almacén de confianza CA en todos los nodos (config management).
Monitoriza la disponibilidad de LDAPS y la expiración de certificados desde nodos Proxmox.
Rota credenciales de cuentas de servicio con un runbook y plan de pruebas.
Restringe reglas de firewall a DCs y puertos requeridos, pero documéntalo.

FAQ

1) ¿Por qué Proxmox muestra “authentication failure” cuando el problema real es TLS?

Porque desde el punto de vista de Proxmox, no pudo autenticarse contigo. El bind nunca ocurrió. Siempre revisa logs y prueba TLS por separado con openssl s_client.

2) ¿Debo usar el tipo de realm `ad` o `ldap` para Active Directory?

Usa ad salvo que tengas una razón específica para no hacerlo. Alinea mejor los defaults con el comportamiento de AD y reduce errores de esquema.

3) ¿LDAPS en 636 o StartTLS en 389?

Ambos pueden ser seguros. Elige lo que soporte tu equipo de directorio y lo que tu monitorización pueda validar con fiabilidad. En muchas empresas, 636 es operativamente más simple (separación clara) pero depende mucho de certificados.

4) Mi bind DN es un DN completo y se rompió tras mover la OU. ¿Cómo lo prevengo?

Usa identidad estilo UPN (ej., svc_pve@corp.example.com) si está permitido. Eso desacopla el bind de la estructura de OU. Además: trata los movimientos de OU como cambios con impacto, no como “mantenimiento”.

5) Los usuarios pueden iniciar sesión, pero los permisos no reflejan los grupos AD. ¿Qué falta?

La autenticación no es autorización. Aún necesitas ACLs/roles en Proxmox vinculados a usuarios o grupos. Si quieres acceso guiado por AD, decide cómo mapear grupos AD a roles de Proxmox e impléméntalo explícitamente.

6) ¿Necesito sincronizar usuarios y grupos con `pveum realm sync`?

Depende de tu modelo operativo. Sync puede facilitar la gestión basada en grupos, pero es otra pieza en movimiento. Si la usas, monitorízala y ejecútala como parte de cambios controlados.

7) ¿Por qué funciona el login para miembros directos de un grupo pero no para miembros anidados?

Porque memberOf a menudo refleja solo pertenencias directas. La resolución anidada requiere reglas de coincidencia especiales o expansión explícita. O bien soporta grupos anidados y pruébalos, o prohíbe el anidamiento para grupos relacionados con Proxmox.

8) ¿Puedo “simplemente desactivar la verificación de certificados” para salir del paso?

Puedes, y también puedes quitarte el cinturón para alcanzar la radio. Si desactivas la verificación, te expones a MITM y endpoints de directorio falsos. Arregla la confianza correctamente.

9) ¿Por qué falla solo en un nodo Proxmox?

Normalmente porque ese nodo tiene DNS, reglas de firewall o estado del almacén de confianza CA distinto. A veces es inconsistencia de config por quórum del clúster. Verifica ambos: dependencias por nodo y pvecm status.

10) ¿Cuál es la forma más limpia de separar break-glass del acceso normal?

Mantén un usuario local pve (o una cuenta pam muy controlada) para emergencias, pero exige un ticket de cambio o proceso auditado para usarla. Usa AD para acceso cotidiano.

Siguientes pasos que deberías hacer después de que funcione

Hacer que LDAP/AD funcione una vez no es el objetivo. Mantenerlo funcionando durante cambios rutinarios sí lo es.

Escribe un runbook de una página con tus ajustes de realm, formatos de login soportados y el comando exacto de ldapsearch usado para validar binds y búsquedas.
Estandariza los almacenes de confianza en todos los nodos Proxmox y lleva seguimiento de rotaciones de CA. Si tu CA cambia cada pocos años, sigue siendo suficiente para arruinar tu semana.
Añade monitorización para la reachabilidad de LDAPS y expiración de certificados desde nodos Proxmox (no desde alguna subred de monitorización aleatoria).
Haz la autorización explícita: mapeo grupo→rol en Proxmox, documentado y revisado como reglas de firewall.
Prueba la conmutación por error quitando temporalmente un DC del servicio y verificando que los inicios de sesión siguen funcionando vía el servidor alternativo.

Si haces eso, LDAP deja de ser una casa encantada y se convierte en lo que debe ser: una dependencia que entiendes, mides y puedes arreglar bajo presión.