Alias de grupo frente a URL de grupo en ASA: cómo se selecciona el perfil
Un alias de grupo es una entrada de la lista de inicio de sesión, no una asignación de URL. Siga cómo el ASA selecciona el perfil y luego lea la política que la sesión recibe en realidad.
Un perfil de conexión gobierna una sesión solo después de que el ASA lo seleccione. Esa frase es todo el modelo de diagnóstico para un portal antiguo sin cliente. Un perfil sin usar puede tener reglas de acceso perfectas y aun así no aplicarse a nadie. Siga el punto de entrada del inicio de sesión antes de editar cualquier política.
Las distinciones siguientes siguen la documentación de la 9.16; el SSL VPN sin cliente se eliminó en la 9.17(1) y posteriores.
El alias es una entrada de lista, no una URL
group-alias proporciona una etiqueta que el usuario elige de la lista de grupos en la página de inicio de sesión. Mostrar esa lista es un ajuste aparte, tunnel-group-list enable. El alias es un nombre de selección y nada más. Configurar un alias llamado staff no crea una URL /staff que seleccione el perfil.
La gente espera que el alias haga doble trabajo porque, desde el navegador, la lista y la URL parecen la misma elección.
Qué hace coincidir realmente group-url
group-url vincula una URL entrante a un perfil de conexión. Cuando esa URL habilitada coincide, el ASA selecciona el perfil sin pedir al usuario que elija de la lista. La URL debe ser la completa que se pretende, en la sintaxis que admite su versión. Su registro DNS y su certificado deben coincidir con lo que escriben los usuarios, o la coincidencia nunca llegará a producirse.
Un sufijo de URL copiado no demuestra nada sobre la configuración. Revise el perfil, no la barra de direcciones.
Siga la selección hasta la política que se ejecuta
Una vez seleccionado un grupo de túnel, el dispositivo resuelve el método de autenticación y la política de grupo predeterminada asociada. Después, los atributos específicos del usuario, los valores devueltos por la autenticación y la autorización dinámica pueden anular partes de esa base. Inspeccione qué recibió realmente la sesión. Leer la política nombrada por sí sola le da la base, no el resultado.
La brecha entre ambas es el origen de la mayoría de los informes de «la regla es correcta pero el acceso es incorrecto».
La herencia no es aislamiento
Los atributos que deje sin especificar pueden heredarse de la política de grupo predeterminada. Por eso una política nombrada nueva no está aislada de los valores predeterminados compartidos, y editar esos valores llega a cada perfil que los hereda. Compare el acceso efectivo a recursos, los ajustes de DNS y las restricciones de sesión por perfil. Hágalo antes de cambiar algo compartido.
Mantenga también la aplicación del acceso separada de la selección.
En una sesión sin cliente, el filtro aplicable es la ACL webtype. Un filtro VPN para cliente de túnel no lo sustituye solo porque ambos estén cerca del mismo bloque de política en la configuración.
Decida el caso sin coincidencia y luego pruebe cada ruta
Determine qué debe ocurrir en la URL genérica del portal y en otros puntos de entrada sin coincidencia. Mire la ruta real del perfil predeterminado y su autorización en lugar de editar un valor predeterminado compartido para que pase una sola cuenta de prueba. Luego abra tres sesiones nuevas: la URL explícita, la entrada habilitada de la lista y el punto de entrada genérico. Anote el perfil seleccionado y la política efectiva de cada una.
Reutilizar una pestaña del navegador de un inicio de sesión anterior arruina la comparación, porque esa sesión ya está vinculada a un perfil.
Ese registro convierte «el portal se abre» en una asignación de inicio de sesión a política que puede auditar más adelante, y es la única respuesta duradera cuando un perfil parece correcto y no gobierna a nadie.