NetExtender 能登录却无法访问：SonicWall 本地账号 + LDAP

登录成功，隧道建立，防火墙后面的资源却毫无响应。在 SonicWall SSL VPN 上出现这种模式，通常意味着账号通过了身份验证，却停在后面两道授权之一：获准使用 SSL VPN 服务，或获准访问某个资源。本地账号与 LDAP 账号混用时更容易出问题，因为两个存储到达这两道授权的路径不同。客户端看到的现象完全一样，所以必须有意识地把这几层分开。

现象，以及它背后的三道授权

从用户名到一个可达的服务器，中间隔着三个彼此独立的判断。身份验证方式决定凭据是否被接受、由哪个存储接受。SSL VPN 服务成员资格决定这个身份能否使用 SSL VPN。VPN 访问列表决定这次会话能到达哪些私有目标。通过其中一道，并不说明后面两道如何。

通过了身份验证、却不在 SSL VPN 服务组里的用户，看到的是一条建立起来却什么都不传输的连接，防火墙日志显示的是登录被接受，而不是失败。这种情况值得尽快识别，因为解决办法是加入组，而不是重置密码。

被放行、却没有任何资源的用户，看到的是能连接、却路由不到任何有用位置的会话。在服务台看来，两者都像隧道坏了，但两者都是配置问题，而不是连通性问题。

域输入框不是目录

NetExtender 会要求填写域，而那个字段并不是 Active Directory 的搜索基准。默认情况下，该字段必须等于防火墙上配置的 SSL VPN 用户域，其文档记载的默认值是 LocalDomain。 比较区分大小写，所以即使账号正确，大小写不同的值也会失败。

如果配置了身份验证分区，改由分区名称来选择外部身份验证上下文，而配置的默认值仍保留自己的作用。无论哪种安排，客户端的域标签都不会作为用户名的一部分转发给 LDAP 或 RADIUS，因此它无法用来引导目录搜索。

在笔记里把三个字符串分开记：公司的 DNS 后缀、LDAP 搜索基准和 NetExtender 域标签。它们看起来相似，任何一个都不能替代另一个。要抄录本次安装中运维方给出的值，而不是论坛帖子里针对另一个固件版本的值。

放行与资源访问是两道独立授权

本地账号必须先加入 SSL VPN 服务组，服务才会接受它。目录账号则通过受支持的组映射流程进入同一个组，这意味着必须先配置 LDAP 组关系，然后 把它当作实际生效的成员资格来验证，而不是从目录一侧想当然。

接下来才是资源访问，在用户或组的 VPN 访问里设置。只授予角色真正需要的具体子网和服务，不要因为需要一个应用就图省事把整个局域网都放出去。会话路由、访问规则和目的服务的权限，都必须与这个范围一致。

客户端上的路由只是让目标可选，并不等于授权。加入 SSL VPN 组也不会让账号变成防火墙管理员，更不应把它当成通用的权限授予。

两个身份，各查四项

用一个本地账号和一个目录账号测试，两者都只给很窄的授权，并且都登记为测试账号。对每个账号记录：接受登录的身份验证源、实际生效的组、分配到的资源访问，以及一项被允许的应用操作。四项检查、两个存储，每种组合都要有书面结果。

然后测试反面情况：账号不应到达的资源，以及应当直接被拒绝的账号。只证明正向路径的设计，往往会留下第二个入口，尤其是同一个短用户名同时存在于两个存储时。禁用目录账号，确认本地账号不会悄悄继续可用。

把重名检查作为上线工作的一部分，而不是等出事之后再做。同一个人在两个存储里，既是支持上的便利，也是审计上的问题，而防火墙会乐于验证你配置的那一个。

把恢复路径收窄

为每一类账号保留 MFA 策略，而不是把本地账号排除在外。如果本地账号是目录故障时经批准的恢复路径，就把这条路径限制在具名管理员范围内，并且有意识地使用它，因为给每位员工都留一个本地应急账号，等于多了一套监管更弱的身份验证系统。

把客户端域、身份验证源和实际生效的访问写进同一条记录。下一位管理员就能复现一套可用的混合账号设计，而不必反复试各种域字符串，直到某次登录成功。