La autenticación LDAP de OpenVPN funciona pero la comprobación de grupo falla: dónde mirar

Las credenciales pasan, el túnel empieza a levantarse y luego la sesión falla con un mensaje sobre el grupo y no sobre la contraseña. Esa combinación sitúa el fallo en la segunda mitad del trabajo del complemento LDAP: la vinculación y la comprobación de la contraseña tuvieron éxito, y la decisión de pertenencia que sigue no. Ambas mitades leen de la misma estrofa de configuración, por eso una corrección en un sitio puede dejar la otra intacta. Empiece por la línea de registro que nombra el paso, no por la cuenta con la que esté probando.

Trate el rechazo como una respuesta de autorización

El complemento realiza una vinculación de servicio, busca la cuenta, verifica la contraseña suministrada y luego pregunta si esa cuenta pertenece a un grupo permitido. Son cuatro operaciones distintas, y solo la última trata de grupos. Por eso un rechazo que llega después de una vinculación correcta no dice nada sobre la contraseña, incluso cuando el cliente muestra un error genérico de autenticación. Subir el nivel de registro del complemento antes de cambiar la configuración es lo que separa las cuatro en la salida.

Busque la propia evaluación del grupo. Cuando no aparece ninguna consulta de grupo, no se llega al bloque de autorización, lo que suele significar que una directiva está fuera de la estrofa que la posee o que falta una opción obligatoria. Cuando la consulta aparece y no devuelve nada, el punto de conexión o el filtro responden a una pregunta distinta de la que usted quería.

Decida si la pertenencia vive en el filtro o en un bloque de grupo

Hay dos formas admitidas, y mezclarlas es como una configuración que funcionaba deja de funcionar. La primera empuja la pertenencia a la búsqueda de usuarios pidiendo un atributo en el objeto de usuario; la segunda deja la búsqueda de usuarios tranquila y hace que el complemento busque el objeto de grupo después. Elija una por despliegue y anote cuál eligió.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

Con esa forma el filtro lo decide todo, así que RequireGroup tiene que ser false o el complemento irá a buscar un objeto de grupo que el filtro nunca mencionó. El atributo del filtro debe existir en el objeto de usuario y estar relleno, lo que no está garantizado cuando los grupos están anidados.

La otra forma mantiene la búsqueda simple y añade una búsqueda de grupo después. El objeto de grupo se nombra explícitamente, y el complemento compara el usuario con los miembros que el directorio devuelve para ese grupo. Nada cambia en el filtro de usuario, lo que hace esta forma más fácil de auditar cuando otro equipo gestiona el grupo.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

El punto ciego es compartido: una comparación simple de pertenencia no expande grupos anidados, así que una cuenta cuyo acceso llega a través de un grupo padre falla mientras la consola sigue mostrando la pertenencia. Active Directory expone member en el grupo, otros esquemas usan uniqueMember, y apuntar al atributo equivocado devuelve un resultado vacío en lugar de un error.

Elija un punto de conexión que contenga el objeto de grupo

La URL decide a qué directorio pregunta el complemento, y un controlador de dominio en el puerto 389 responde solo por su propio contexto de nombres. Un catálogo global en el puerto 3268 responde por todo el bosque, solo lectura y con un conjunto parcial de atributos. Cuando las cuentas están en un dominio y el grupo VPN en otro, una consulta de un solo dominio puede encontrar al usuario y aun así perder la pertenencia. Ese es el caso en el que mover la URL al puerto del catálogo resuelve el rechazo, y también es el caso en el que la gente generaliza demasiado.

El conjunto parcial de atributos es el límite: no se puede filtrar por un atributo que el catálogo no contiene, así que el mismo cambio puede hacer que un despliegue funcione y otro no devuelva nada. Confirme qué devuelve realmente el punto de conexión para el usuario y el grupo reales antes de reescribir la estrofa. Las referencias y TLS son de nuevo asuntos aparte, ya que una referencia debe seguirse y un punto de conexión que exige TLS necesita los archivos de confianza correspondientes.

Mantenga el estado de la cuenta y el alcance de búsqueda en sus propios campos

La marca de deshabilitado pertenece al filtro, no a la comprobación de grupo. En Active Directory es el segundo bit de userAccountControl, y sin esa condición una cuenta deshabilitada con una contraseña válida se autentica y luego falla en el paso de grupo, lo que parece un error de autorización. El alcance de búsqueda pertenece al DN base, porque empezar en la raíz del dominio es más lento y puede coincidir con objetos fuera de la unidad organizativa que quería cubrir.

Mantenga también estrechos los derechos de la cuenta de vinculación. Los derechos amplios de directorio convierten un filtro mal configurado en una consulta correcta y esconden el fallo hasta que alguien audita la cuenta. Cambie la pertenencia en el propio directorio, nunca en una lista local de excepciones, para que deshabilitar la cuenta baste para retirar el acceso. Si otro equipo gestiona el grupo, acuerde el atributo que rellena antes de escribir un filtro contra él.

Demuestre el resultado con tres cuentas

Ejecute la configuración contra tres identidades: un miembro permitido, una cuenta válida fuera del grupo y una cuenta que se ha deshabilitado. Si las tres son rechazadas, la vinculación o la consulta de grupo están rotas; si las tres son aceptadas, no se aplica ninguna condición de grupo. Un resultado mixto es el único que demuestra que la configuración distingue los casos que le importan.

Lea las mismas tres respuestas directamente del directorio antes de culpar al complemento. La primera consulta muestra el atributo de grupo del que depende el filtro, y la segunda muestra el valor de control de cuenta. Sustituya por su propio DN base, cuenta y punto de conexión:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

Un usuario cuyo memberOf vuelve vacío es un hecho del directorio, no un fallo del complemento, y una cuenta que sigue autenticándose después de ser deshabilitada significa que al filtro le falta la condición de control de cuenta. Corrija esa evidencia primero y vuelva a ejecutar la prueba de tres cuentas. Deje la línea de registro que nombró el paso fallido junto al cambio de configuración, para que la siguiente persona pueda separar la autorización de la autenticación sin repetir la búsqueda.