登录不上可能是账号被锁
员工「无线登录不上」有时根本不是无线问题，而是账号被锁：AD 或 AAA 上通常配置了「连续错误 N 次即锁定」的策略，一旦触发，输入正确密码也会被拒。最常见的触发源是终端后台重试——手机或笔记本保存了旧密码，改密后仍自动重连，一分钟内就能把错误次数刷满。
基本信息
| 触发机制 | 连续认证失败达到阈值后锁定（AD/AAA 策略） |
|---|---|
| 常见根因 | 终端保存旧密码、服务账号或扫描工具反复重试 |
| 处理顺序 | 先解锁账号，再在问题终端上删除旧凭据 |
| 定位线索 | RADIUS 日志中同一账号短时间大量拒绝 |
| 预防动作 | 改密流程中同步通知用户清理终端保存的密码 |
典型使用场景
- 员工改密后「上午还好，下午就登录不上」
- 同一账号在多地同时失败，怀疑是批量设备在重试
- 服务账号被锁导致依赖它的系统集体异常
- 排查「只有某些人反复被锁」的规律
- 制定改密后需要同步执行的终端清理流程
排查线索
排查线索
# RADIUS 日志中筛同一账号短时间内的多次 Access-Reject
# 记录请求来源（NAS/AP 的 IP 与 MAC），锁定是谁在重试
# 在 AD 上查看该账号的锁定事件与锁定来源工作站
# 解锁后先让问题终端断开并清理保存的凭据常见触发源
| 触发源 | 特征 | 处理 |
|---|---|---|
| 手机保存旧密码 | 单账号、固定来源 MAC | 终端忘记网络后重连 |
| 笔记本后台重连 | 与改密时间点吻合 | 清理凭据管理器中的条目 |
| 服务账号或扫描工具 | 高频等间隔请求 | 更新配置或暂停服务 |
| 多设备共用账号 | 多来源 MAC 并发失败 | 拆分账号或改 802.1X |
「改完密码后马上被锁」几乎总是指向终端后台重试：先找终端再谈策略，否则调整阈值只是把下一次锁定推迟。
提高错误次数阈值只是让锁定来得更晚，根因（旧凭据还在自动重连）依然存在，问题会反复出现。
服务账号被锁的影响面往往比个人账号大：一次锁定可能造成一整类设备断流，应为它单独设置更严格的告警。