A autenticación LDAP de OpenVPN funciona pero a comprobación de grupo falla: onde mirar

A autenticación pode pasar mentres a comprobación de grupo rexeita a todos. Revise o bloque Authorization, o atributo de pertenza e o punto de conexión do directorio un por un.

As credenciais pasan, o túnel comeza a levantarse e despois a sesión falla cunha mensaxe sobre o grupo e non sobre o contrasinal. Esa combinación sitúa o fallo na segunda metade do traballo do complemento LDAP: a vinculación e a comprobación do contrasinal tiveron éxito, e a decisión de pertenza que segue non. Ambas as metades len da mesma estrofa de configuración, por iso unha corrección nun sitio pode deixar a outra intacta. Empece pola liña de rexistro que nomea o paso, non pola conta coa que estea probando.

Trate o rexeitamento como unha resposta de autorización

O complemento realiza unha vinculación de servizo, busca a conta, verifica o contrasinal subministrado e logo pregunta se esa conta pertence a un grupo permitido. Son catro operacións distintas, e só a última trata de grupos. Por iso un rexeitamento que chega despois dunha vinculación correcta non di nada sobre o contrasinal, mesmo cando o cliente mostra un erro xenérico de autenticación. Subir o nivel de rexistro do complemento antes de cambiar a configuración é o que separa as catro na saída.

Busque a propia avaliación do grupo. Cando non aparece ningunha consulta de grupo, non se chega ao bloque de autorización, o que normalmente significa que unha directiva está fóra da estrofa que a posúe ou que falta unha opción obrigatoria. Cando a consulta aparece e non devolve nada, o punto de conexión ou o filtro responden a unha pregunta distinta da que vostede quería.

Decida se a pertenza vive no filtro ou nun bloque de grupo

Hai dúas formas admitidas, e mesturalas é como unha configuración que funcionaba deixa de funcionar. A primeira empurra a pertenza á busca de usuarios pedindo un atributo no obxecto de usuario; a segunda deixa a busca de usuarios tranquila e fai que o complemento busque o obxecto de grupo despois. Escolla unha por despregamento e anote cal escolleu.

<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 o filtro decide todo, así que RequireGroup ten que ser false ou o complemento irá buscar un obxecto de grupo que o filtro nunca mencionou. O atributo do filtro debe existir no obxecto de usuario e estar cheo, o que non está garantido cando os grupos están aniñados.

A outra forma mantén a busca simple e engade unha busca de grupo despois. O obxecto de grupo nómese explicitamente, e o complemento compara o usuario cos membros que o directorio devolve para ese grupo. Nada cambia no filtro de usuario, o que fai esta forma máis doada de auditar cando outro equipo xestiona o 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>

O punto cego é compartido: unha comparación simple de pertenza non expande grupos aniñados, así que unha conta cuxo acceso chega a través dun grupo pai falla mentres a consola segue mostrando a pertenza. Active Directory expón member no grupo, outros esquemas usan uniqueMember, e apuntar ao atributo equivocado devolve un resultado baleiro en lugar dun erro.

Escolla un punto de conexión que conteña o obxecto de grupo

A URL decide a que directorio pregunta o complemento, e un controlador de dominio no porto 389 responde só polo seu propio contexto de nomes. Un catálogo global no porto 3268 responde por todo o bosque, só lectura e cun conxunto parcial de atributos. Cando as contas están nun dominio e o grupo VPN noutro, unha consulta dun só dominio pode atopar o usuario e aínda así perder a pertenza. Ese é o caso no que mover a URL ao porto do catálogo resolve o rexeitamento, e tamén é o caso no que a xente xeneraliza demasiado.

O conxunto parcial de atributos é o límite: non se pode filtrar por un atributo que o catálogo non contén, así que o mesmo cambio pode facer que un despregamento funcione e outro non devolva nada. Confirme que devolve realmente o punto de conexión para o usuario e o grupo reais antes de reescribir a estrofa. As referencias e TLS son de novo asuntos aparte, xa que unha referencia debe seguirse e un punto de conexión que esixe TLS necesita os ficheiros de confianza correspondentes.

Manteña o estado da conta e o alcance da busca nos seus propios campos

A marca de desactivado pertence ao filtro, non á comprobación de grupo. En Active Directory é o segundo bit de userAccountControl, e sen esa condición unha conta desactivada cun contrasinal válido autentícase e despois falla no paso de grupo, o que parece un erro de autorización. O alcance da busca pertence ao DN base, porque comezar na raíz do dominio é máis lento e pode coincidir con obxectos fóra da unidade organizativa que quería cubrir.

Manteña tamén estreitos os dereitos da conta de vinculación. Os dereitos amplos de directorio converten un filtro mal configurado nunha consulta correcta e esconden o fallo ata que alguén audita a conta. Cambie a pertenza no propio directorio, nunca nunha lista local de excepcións, para que desactivar a conta abonde para retirar o acceso. Se outro equipo xestiona o grupo, acorde o atributo que enche antes de escribir un filtro contra el.

Demostre o resultado con tres contas

Execute a configuración contra tres identidades: un membro permitido, unha conta válida fóra do grupo e unha conta que se desactivou. Se as tres son rexeitadas, a vinculación ou a consulta de grupo están rotas; se as tres son aceptadas, non se aplica ningunha condición de grupo. Un resultado mixto é o único que demostra que a configuración distingue os casos que lle importan.

Lea as mesmas tres respostas directamente do directorio antes de culpar o complemento. A primeira consulta mostra o atributo de grupo do que depende o filtro, e a segunda mostra o valor de control de conta. Substitua polo seu propio DN base, conta e 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 cuxo memberOf volve baleiro é un feito do directorio, non un fallo do complemento, e unha conta que segue autenticándose despois de ser desactivada significa que ao filtro lle falta a condición de control de conta. Corrixa esa evidencia primeiro e volva executar a proba de tres contas. Deixe a liña de rexistro que nomeou o paso fallido xunto ao cambio de configuración, para que a seguinte persoa poida separar a autorización da autenticación sen repetir a busca.

Artigos relacionados