NetExtender inicia sesión pero non hai acceso: SonicWall local + LDAP
NetExtender conecta pero nada responde: separa a autenticación de SonicWall, a pertenza ao servizo SSL VPN e os permisos de acceso VPN para usuarios locais e LDAP.
O inicio de sesión remata ben, o túnel levanta e nada detrás da devasa responde. Ese patrón nun SonicWall SSL VPN adoita significar que a conta superou a autenticación e detívose nun dos dous permisos posteriores: a admisión ao servizo SSL VPN ou o permiso para chegar a un recurso. As contas locais e LDAP mesturadas empeórano, porque os dous almacéns chegan a eses permisos por camiños distintos. O síntoma é idéntico desde o cliente, e por iso as capas deben separarse a propósito.
O síntoma e os tres permisos que hai detrás
Tres decisións independentes separan un nome de usuario dun servidor accesible. O método de autenticación decide se se acepta a credencial e que almacén a acepta. A pertenza ao servizo SSL VPN decide se esa identidade pode usar o SSL VPN. A lista de acceso VPN decide a que destinos privados pode chegar a sesión. Superar unha non di nada das dúas seguintes.
Un usuario que se autentica pero non está no grupo do servizo SSL VPN ve unha conexión que se establece e despois non transporta nada, e o rexistro da devasa mostra un inicio de sesión aceptado en lugar dun fallo. Ese é o caso que convén recoñecer axiña, porque a solución é unha pertenza a un grupo e non un restablecemento de contrasinal.
Un usuario admitido pero sen recursos ve unha sesión que conecta e non encamiña a ningún sitio útil. Ambos parecen un túnel roto desde o servizo de asistencia, e ambos son configuración e non conectividade.
O campo de dominio non é o directorio
NetExtender pide un dominio, e ese campo non é unha base de busca para Active Directory. Na disposición predeterminada o campo debe coincidir co dominio de usuario SSL VPN que teña configurado a devasa, e o valor predeterminado documentado é LocalDomain. A comparación distingue maiúsculas e minúsculas, así que un valor escrito con outra capitalización falla aínda que a conta sexa correcta.
Coa partición de autenticación configurada, os nomes de partición seleccionan o contexto de autenticación externo, e o valor predeterminado configurado conserva o seu propio papel. En calquera das dúas disposicións, a etiqueta de dominio do cliente non se reenvía a LDAP nin a RADIUS como parte do nome de usuario, así que non pode dirixir unha busca no directorio.
Mantén as tres cadeas separadas nas túas notas: o sufixo DNS da empresa, a base de busca LDAP e a etiqueta de dominio de NetExtender. Parécense e ningunha substitúe a outra. Copia o valor do operador para esta instalación e non un valor dunha mensaxe de foro sobre outra versión de firmware.
A admisión e o acceso aos recursos son permisos separados
As contas locais necesitan pertencer ao grupo do servizo SSL VPN antes de que o servizo as acepte. As contas de directorio chegan ao mesmo grupo mediante o fluxo de traballo de asignación de grupos admitido, o que significa que a relación de grupo LDAP debe configurarse e despois verificarse como pertenza efectiva en lugar de darse por suposta desde o lado do directorio.
O acceso aos recursos vén despois, en Acceso VPN sobre o usuario ou o grupo. Concede as subredes e os servizos concretos que necesita o rol, e resiste o atallo de conceder toda a LAN porque faga falta unha aplicación. As rutas da sesión, as regras de acceso e os permisos do servizo de destino deben coincidir todos con ese alcance.
| Layer | What it decides | Where it is set |
|---|---|---|
| Authentication | Whether the credential is accepted, and by which store | Authentication method and directory configuration |
| Admission | Whether the identity may use the SSL VPN | SSL VPN service group membership |
| Resource | Which destinations the session may reach | VPN Access on the user or group |
Unha ruta no cliente fai que un destino se poida seleccionar e non o autoriza. A pertenza ao grupo SSL VPN tampouco converte a conta en administrador da devasa, e non debe tratarse como unha concesión de privilexios xeral.
Dúas identidades, catro comprobacións cada unha
Proba cunha conta local e unha conta de directorio, ambas con autorización estreita e ambas documentadas como contas de proba. Para cada unha, rexistra a fonte de autenticación que aceptou o inicio de sesión, os grupos efectivos, o acceso a recursos asignado e unha operación de aplicación permitida. Catro comprobacións, dous almacéns e un resultado escrito para cada combinación.
Despois proba os casos negativos: un recurso ao que a conta non debe chegar e unha conta que debe rexeitarse de plano. Un deseño que só demostra o camiño positivo tende a deixar aberta unha segunda entrada, sobre todo cando o mesmo nome de usuario curto existe nos dous almacéns. Desactiva a conta de directorio e confirma que a local non segue funcionando en silencio.
Revisa os nomes duplicados como parte do despregamento e non despois dun incidente. A mesma persoa en dous almacéns é á vez unha comodidade para o soporte e un problema de auditoría, e a devasa autenticará de bo grado o que configurases.
Mantén estreita a ruta de recuperación
Conserva a política MFA para cada clase de conta en lugar de eximir dela as contas locais. Se as contas locais ofrecen unha ruta de recuperación aprobada para unha caída do directorio, limita esa ruta a administradores con nome e opéraa con deliberación, porque unha conta de emerxencia local para cada empregado é un segundo sistema de autenticación con menos supervisión.
Escribe o dominio do cliente, a fonte de autenticación e o acceso efectivo no mesmo rexistro. O seguinte administrador poderá entón reproducir un deseño de contas mixtas que funcione en lugar de probar cadeas de dominio ata que un inicio de sesión saia ben.