NetExtender inicia sesión pero no hay acceso: SonicWall local + LDAP

El inicio de sesión se completa, el túnel se levanta y nada detrás del firewall responde. Ese patrón en un SonicWall SSL VPN suele significar que la cuenta superó la autenticación y se detuvo en uno de dos permisos posteriores: la admisión al servicio SSL VPN o el permiso para llegar a un recurso. Las cuentas locales y LDAP mezcladas lo empeoran, porque los dos almacenes llegan a esos permisos por rutas distintas. El síntoma es idéntico desde el cliente, y por eso las capas deben separarse a propósito.

El síntoma y los tres permisos que hay detrás

Tres decisiones independientes separan un nombre de usuario de un servidor accesible. El método de autenticación decide si se acepta la credencial y qué almacén la acepta. La pertenencia al servicio SSL VPN decide si esa identidad puede usar el SSL VPN siquiera. La lista de acceso VPN decide a qué destinos privados puede llegar la sesión. Superar una no dice nada de las dos siguientes.

Un usuario que se autentica pero no está en el grupo del servicio SSL VPN ve una conexión que se establece y luego no transporta nada, y el registro del firewall muestra un inicio de sesión aceptado en lugar de un fallo. Ese es el caso que conviene reconocer deprisa, porque la solución es una pertenencia a un grupo y no un restablecimiento de contraseña.

Un usuario admitido pero sin recursos ve una sesión que conecta y no enruta a ningún sitio útil. Ambos parecen un túnel roto desde el servicio de ayuda, y ambos son configuración y no conectividad.

El campo de dominio no es el directorio

NetExtender pide un dominio, y ese campo no es una base de búsqueda para Active Directory. En la disposición predeterminada el campo debe coincidir con el dominio de usuario SSL VPN que haya configurado el firewall, y el valor predeterminado documentado es LocalDomain. La comparación distingue mayúsculas y minúsculas, así que un valor escrito con otra capitalización falla aunque la cuenta sea correcta.

Con la partición de autenticación configurada, los nombres de partición seleccionan el contexto de autenticación externo, y el valor predeterminado configurado conserva su propio papel. En cualquiera de las dos disposiciones, la etiqueta de dominio del cliente no se reenvía a LDAP ni a RADIUS como parte del nombre de usuario, así que no puede dirigir una búsqueda en el directorio.

Mantén las tres cadenas separadas en tus notas: el sufijo DNS de la empresa, la base de búsqueda LDAP y la etiqueta de dominio de NetExtender. Se parecen y ninguna sustituye a otra. Copia el valor del operador para esta instalación y no un valor de un mensaje de foro sobre otra versión de firmware.

La admisión y el acceso a recursos son permisos separados

Las cuentas locales necesitan pertenecer al grupo del servicio SSL VPN antes de que el servicio las acepte. Las cuentas de directorio llegan al mismo grupo mediante el flujo de trabajo de asignación de grupos admitido, lo que significa que la relación de grupo LDAP debe configurarse y luego verificarse como pertenencia efectiva en lugar de darse por supuesta desde el lado del directorio.

El acceso a recursos viene después, en Acceso VPN sobre el usuario o el grupo. Concede las subredes y los servicios concretos que necesita el rol, y resiste el atajo de conceder toda la LAN porque haga falta una aplicación. Las rutas de la sesión, las reglas de acceso y los permisos del servicio de destino deben coincidir todos con ese alcance.

Una ruta en el cliente hace que un destino sea seleccionable y no lo autoriza. La pertenencia al grupo SSL VPN tampoco convierte la cuenta en administrador del firewall, y no debe tratarse como una concesión de privilegios general.

Dos identidades, cuatro comprobaciones cada una

Prueba con una cuenta local y una cuenta de directorio, ambas con autorización estrecha y ambas documentadas como cuentas de prueba. Para cada una, registra la fuente de autenticación que aceptó el inicio de sesión, los grupos efectivos, el acceso a recursos asignado y una operación de aplicación permitida. Cuatro comprobaciones, dos almacenes y un resultado escrito para cada combinación.

Después prueba los casos negativos: un recurso al que la cuenta no debe llegar y una cuenta que debe rechazarse de plano. Un diseño que solo demuestra la ruta positiva tiende a dejar abierta una segunda entrada, sobre todo cuando el mismo nombre de usuario corto existe en ambos almacenes. Desactiva la cuenta de directorio y confirma que la local no sigue funcionando en silencio.

Revisa los nombres duplicados como parte del despliegue y no después de un incidente. La misma persona en dos almacenes es a la vez una comodidad para el soporte y un problema de auditoría, y el firewall autenticará de buen grado el que hayas configurado.

Mantén estrecha la ruta de recuperación

Conserva la política MFA para cada clase de cuenta en lugar de eximir de ella a las cuentas locales. Si las cuentas locales ofrecen una ruta de recuperación aprobada para una caída del directorio, limita esa ruta a administradores con nombre y operaciónala a conciencia, porque una cuenta de emergencia local para cada empleado es un segundo sistema de autenticación con menos supervisión.

Escribe el dominio del cliente, la fuente de autenticación y el acceso efectivo en el mismo registro. El siguiente administrador podrá entonces reproducir un diseño de cuentas mixtas que funcione en lugar de probar cadenas de dominio hasta que un inicio de sesión salga bien.