链路上的慢在哪一段
企业无线与有线认证常把 RADIUS 当门面、LDAP/AD 当用户库：RADIUS 收到认证请求后要去 AD 查账号、属性、所属组，再决定放行与授权 VLAN。一旦 AD 查询变慢，症状会从认证层冒出来——大面积登录变慢、偶发超时、部分用户直接失败。根因通常在 LDAP 侧或 RADIUS 到 LDAP 这一段，而不是无线本身。
基本信息
| 认证链路 | 终端 → AP/AC → RADIUS → LDAP/AD |
|---|---|
| 典型症状 | 登录等待从 1~2 秒涨到 10 秒以上、批量失败 |
| 常见根因 | 查询基准 DN 过大、连接未复用、AD 负载高 |
| 关键指标 | LDAP 查询响应时间 P95 |
| 观察点 | RADIUS 日志中的 LDAP 超时条目 |
典型使用场景
- 上班高峰集中登录，出现「一部分人能上、一部分转圈」
- 域控做过维护或迁移后，认证整体变慢
- 新接入一批终端后 RADIUS 查询量激增
- 域内新增大量 OU 与组，查询范围未收敛
- 需要判断问题是出在无线还是账号系统
验证命令
验证命令
# 从 RADIUS 主机直接查 AD，测出真实响应耗时
ldapsearch -x -H ldap://dc01.example.com -b "dc=example,dc=com" \
-D "svc_radius@example.com" -W "(sAMAccountName=zhangsan)"
# 连跑 10 次取 P95，与 RADIUS 侧超时阈值对比
# 再确认 RADIUS 到 AD 的长连接是否在复用，而非每次重建分段定位
| 环节 | 观察方法 | 结论指向 |
|---|---|---|
| 终端→AP | 抓 EAP 报文时间戳 | 客户端重传多则偏向空口与信号 |
| AP→RADIUS | RADIUS 收到请求的时间 | 收不到则是网络或共享密钥问题 |
| RADIUS→LDAP | ldapsearch 实测耗时 | 与整体耗时相当则慢在 AD 侧 |
| RADIUS 处理 | 日志中的查询语句与耗时 | 查询范围过大则收敛基准 DN |
定位诀窍是分段计时：从终端发出 EAP-Response 到 RADIUS 回 Access-Accept，把时间拆成 AP、RADIUS、LDAP 三段，哪段占比大就查哪段，别在无线侧空转。
排查期间不要用域管理员账号做高频压测查询，容易触发账号锁定策略或影响生产负载；用专用服务账号并限制查询频率。
AD 侧还有两个容易被忽略的点：域控自身的 DNS 与时间同步异常会让查询偶发失败；账号过期或密码策略拦截会返回明确的拒绝码。先把「超时」和「拒绝」分清，方向完全不同。