Asignación de grupos LDAP en ASA frente a DAP para la política de grupo VPN

Dos registros distintos deciden qué política de grupo recibe una sesión de AnyConnect, y viven en partes diferentes de la configuración con modos de fallo distintos. Un mapa de atributos LDAP traduce un valor del directorio en un atributo de autorización de la ASA durante la autenticación; un registro DAP evalúa condiciones después y puede añadir o sobrescribir atributos. Ambos pueden terminar en el mismo nombre de política, así que un inicio de sesión que funciona no le dice nada sobre qué mecanismo lo produjo. El sentido de compararlos es elegir uno a propósito en lugar de dejar que el segundo anule silenciosamente al primero.

Dos mecanismos, dos puntos de decisión

La elección se reduce a tres preguntas. ¿Depende la decisión de un único valor de atributo del directorio, necesita más que ese valor, y qué mecanismo tiene permiso para ganar cuando ambos coinciden?

Si la única entrada es la pertenencia a un grupo, el mapa de atributos es la herramienta más pequeña y la más fácil de auditar: un mapa, asociado a un servidor AAA, con una línea por grupo. Si la selección debe considerar la postura, la identidad del endpoint, un segundo atributo o una ventana temporal, el mapa se queda sin entradas y DAP es el mecanismo que puede expresar la regla. Si ambos están en juego, conozca la precedencia en su versión antes de escribir cualquiera de los dos, porque una sesión que coincide con un registro DAP puede no conservar la política que devolvió el mapa. Todo lo demás es contabilidad.

La ruta del mapa de atributos, en orden de configuración

La ruta del mapa comienza en la definición del servidor AAA. El mapa de atributos debe estar asociado a la entrada del servidor LDAP que el perfil de conexión realmente utiliza; un mapa que existe en la configuración en ejecución pero que ese servidor no referencia no cambia nada. Esa línea de asociación es la que hace viva el resto de la configuración. La guía de mapeo LDAP de la ASA es la referencia para la sintaxis del mapa en las versiones 9.x.

Dentro del mapa, una sentencia nombra el atributo del directorio y el atributo de la ASA que alimenta, y otras sentencias traducen valores concretos. map-name memberOf Group-Policy seguido de map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly es la forma: el lado izquierdo es lo que devolvió el directorio, el lado derecho es el nombre de una política de grupo que ya debe existir. Un nombre distinguido y un nombre de visualización de política no son intercambiables, y una coincidencia casi exacta en cualquiera de las dos cadenas no produce ningún error al iniciar sesión.

Aquí muerden dos detalles: memberOf devuelve todos los grupos a los que pertenece la cuenta, así que un usuario en dos grupos mapeados entrega al mapa dos valores candidatos, y la regla alfabética de la guía es el único desempate con el que puede contar en lugar de su propio orden de prioridad. Un valor no mapeado no devuelve nada, lo que recae silenciosamente en la política predeterminada del perfil.

La ruta DAP y qué añade

DAP evalúa condiciones y aplica atributos sobre el resultado de AAA. Un registro lleva una prioridad, una acción y un conjunto de condiciones; los registros se evalúan en orden de prioridad y la acción decide si la evaluación continúa o se detiene. Ese es un modelo de ejecución distinto del de una búsqueda de valor, y por eso mismo puede expresar reglas que el mapa no puede.

Lo que DAP añade son entradas. Las condiciones pueden referenciar atributos del directorio, atributos del endpoint y el estado de postura, y un registro coincidente puede llevar ACL, listas de URL o filtros para esa sesión. Así, una regla como que el personal de soporte en un portátil gestionado reciba la política de solo lectura mientras ese mismo personal en un dispositivo no gestionado recibe una restringida es expresable en DAP y no en un mapa de atributos. El mapa tiene exactamente una entrada: el valor que el directorio devolvió para el atributo que usted nombró.

DAP también añade un segundo lugar donde mirar cuando una sesión acaba en la política equivocada. Un registro que coincide con una acción de continuar no termina la evaluación, y un registro posterior todavía puede cambiar el resultado, así que lo que observa es el producto de una secuencia y no de una sola búsqueda. Lea los números de prioridad en orden, y recuerde que el registro de respaldo puede ser el que hace el trabajo. El mapa, en cambio, no tiene secuencia: un atributo, un valor, una respuesta.

Donde los dos discrepan

La precedencia es la parte que rompe diseños. Cuando una sesión coincide tanto con una entrada del mapa como con un registro DAP, el resultado depende de la versión y de la acción del registro, así que verifíquelo en su propia ASA en lugar de suponer que uno de los mecanismos posee el resultado.

Tres modos de fallo explican la mayor parte de la confusión. Un mapa definido pero nunca asociado a la etiqueta de servidor que utiliza el perfil produce la política predeterminada sin ningún error en ninguna parte. Una cadena de condición DAP que difiere del valor del directorio en mayúsculas o espacios nunca coincide, y el registro de respaldo se aplica silenciosamente. Y una política de grupo que aún no existe es aceptada por el mapa, porque el mapa solo devuelve un nombre, así que la sesión no recibe ninguno de los permisos previstos y no hay nada en el registro que señale el objeto que falta. Compruebe los tres antes de tocar la pertenencia a grupos.

Leer la evidencia de una sesión activa

Lea la respuesta de una sesión nueva y no de la configuración. show vpn-sessiondb detail anyconnect filter name jdoe imprime la política de grupo que la sesión recibió realmente, y show running-config ldap attribute-map confirma qué valores podría haber devuelto el mapa. Del lado del directorio, test aaa-server authentication LDAP-AD username jdoe password <password> muestra los atributos que la ASA recibió de vuelta, y debug ldap 255 muestra el intercambio cuando la prueba no coincide con lo que esperaba.

Después concilie cuatro registros por escrito: el valor del directorio, el mapa o la condición DAP configurados, la política de grupo local y el recurso al que el usuario pudo llegar realmente. Si los tres primeros cuadran y el cuarto no, el problema está en el cuerpo de la política y no en la selección. Si la sesión muestra el nombre de política correcto pero la ACL equivocada, deje de mirar LDAP por completo. Cambie un registro a la vez y vuelva a comprobar una sesión nueva, porque una sesión reconectada es la única evidencia que refleja la configuración que acaba de escribir.