L’autenticació LDAP d’OpenVPN funciona però la comprovació de grup falla: on cal mirar

Les credencials passen, el túnel comença a aixecar-se i llavors la sessió falla amb un missatge sobre el grup i no sobre la contrasenya. Aquesta combinació situa la fallada a la segona meitat de la feina del connector LDAP: el bind i la comprovació de la contrasenya han reeixit, i la decisió de pertinença que ve després no. Les dues meitats llegeixen de la mateixa estança de configuració, i per això una correcció en un lloc pot deixar l’altra intacta. Comenceu per la línia de registre que nomena el pas, no pel compte amb què feu la prova.

Tracteu el rebuig com una resposta d’autorització

El connector fa un bind de servei, cerca el compte, verifica la contrasenya proporcionada i després pregunta si aquell compte pertany a un grup permès. Són quatre operacions diferents, i només l’última tracta de grups. Per tant, un rebuig que arriba després d’un bind correcte no diu res sobre la contrasenya, fins i tot quan el client mostra un error genèric d’autenticació. Pujar el nivell de registre del connector abans de canviar la configuració és el que separa les quatre a la sortida.

Busqueu l’avaluació del grup mateixa. Quan no apareix cap consulta de grup, no s’arriba al bloc d’autorització, cosa que normalment vol dir que una directiva és fora de l’estança que la posseeix o que falta una opció obligatòria. Quan la consulta apareix i no retorna res, el punt de connexió o el filtre responen una pregunta diferent de la que volíeu.

Decidiu si la pertinença viu al filtre o en un bloc de grup

Hi ha dues formes suportades, i barrejar-les és com una configuració que funcionava deixa de funcionar. La primera empeny la pertinença a la cerca d’usuaris demanant un atribut a l’objecte d’usuari; la segona deixa la cerca d’usuaris tranquil·la i fa que el connector busqui l’objecte de grup després. Trieu-ne una per desplegament i anoteu quina heu triat.

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

Amb aquesta forma el filtre ho decideix tot, així que RequireGroup ha de ser false o el connector anirà a buscar un objecte de grup que el filtre no ha esmentat mai. L’atribut del filtre ha d’existir a l’objecte d’usuari i estar omplert, cosa que no està garantida quan els grups són imbricats.

L’altra forma manté la cerca simple i hi afegeix una cerca de grup després. L’objecte de grup es nomena explícitament, i el connector compara l’usuari amb els membres que el directori retorna per a aquell grup. No canvia res del filtre d’usuari, cosa que fa aquesta forma més fàcil d’auditar quan un altre equip gestiona el grup.

<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 punt cec és compartit: una comparació simple de pertinença no desplega els grups imbricats, així que un compte l’accés del qual arriba per un grup pare falla mentre la consola encara mostra la pertinença. Active Directory exposa member al grup, altres esquemes fan servir uniqueMember, i apuntar a l’atribut equivocat retorna un resultat buit en lloc d’un error.

Trieu un punt de connexió que contingui l’objecte de grup

L’URL decideix a quin directori pregunta el connector, i un controlador de domini al port 389 només respon pel seu propi context de noms. Un catàleg global al port 3268 respon per tot el bosc, només de lectura i amb un conjunt parcial d’atributs. Quan els comptes són en un domini i el grup VPN és en un altre, una consulta d’un sol domini pot trobar l’usuari i tot i així no veure la pertinença. Aquest és el cas en què moure l’URL al port del catàleg resol el rebuig, i també és el cas en què la gent generalitza massa.

El conjunt parcial d’atributs és el límit: no es pot filtrar per un atribut que el catàleg no conté, així que el mateix canvi pot fer que un desplegament funcioni i un altre no retorni res. Confirmeu què retorna realment el punt de connexió per a l’usuari i el grup reals abans de reescriure l’estança. Les referències i TLS són de nou qüestions separades, ja que una referència s’ha de seguir i un punt de connexió que requereix TLS necessita els fitxers de confiança corresponents.

Manteniu l’estat del compte i l’abast de la cerca en els seus camps

La marca de desactivat pertany al filtre, no a la comprovació de grup. A Active Directory és el segon bit de userAccountControl, i sense aquesta condició un compte desactivat amb una contrasenya vàlida s’autentica i després falla al pas de grup, cosa que sembla un error d’autorització. L’abast de la cerca pertany al DN base, perquè començar a l’arrel del domini és més lent i pot coincidir amb objectes fora de la unitat organitzativa que volíeu cobrir.

Manteniu també estrets els drets del compte de bind. Els drets amplis de directori converteixen un filtre mal configurat en una consulta correcta i amaguen l’error fins que algú audita el compte. Canvieu la pertinença al directori mateix, mai en una llista local d’excepcions, perquè desactivar el compte sigui suficient per treure l’accés. Si un altre equip gestiona el grup, poseu-vos d’acord sobre l’atribut que omplen abans d’escriure-hi un filtre.

Demostreu el resultat amb tres comptes

Executeu la configuració contra tres identitats: un membre permès, un compte vàlid fora del grup i un compte que s’ha desactivat. Si els tres són rebutjats, el bind o la consulta de grup estan trencats; si els tres són acceptats, no s’aplica cap condició de grup. Un resultat mixt és l’únic que demostra que la configuració distingeix els casos que us importen.

Llegiu les mateixes tres respostes directament del directori abans de culpar el connector. La primera consulta mostra l’atribut de grup del qual depèn el filtre, i la segona mostra el valor de control del compte. Substituïu-hi el vostre DN base, compte i punt de connexió:

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 usuari el memberOf del qual torna buit és un fet del directori, no un error del connector, i un compte que encara s’autentica després de ser desactivat vol dir que al filtre li falta la condició de control del compte. Corregiu aquesta evidència primer i torneu a executar la prova de tres comptes. Deixeu la línia de registre que va nomenar el pas fallit al costat del canvi de configuració, perquè la persona següent pugui separar l’autorització de l’autenticació sense repetir la cerca.