偶发LDAP认证失败（错误码49/-669）问题排查咨询

针对你描述的场景——500用户规模下，每隔几周有10-15名用户出现10-15分钟的登录失败，错误码为LDAP: error code 49 - NDS error: failed authentication (-669)，且已排除WebAccess_PCO对象缺失PublicKey/ACL（该问题会导致全员故障），结合eDirectory 8.8.7的特性，以下是几个高概率的排查方向：

1. LDAP连接池/服务器连接数耗尽 #

eDirectory 8.8.7默认有连接数限制，如果你的认证服务没有合理配置LDAP连接池，或者eDirectory服务器的最大连接数设得过低，当短时间内并发认证请求较多时，部分用户的请求会因无法建立新连接而失败，待现有连接释放后恢复正常。

• 排查步骤：
  • 用命令ndsconfig get n4u.server.max-connections查看eDirectory的最大连接数配置
  • 检查认证服务的LDAP连接池参数（比如最大空闲连接、最大活跃连接数）
  • 故障发生时，通过iMonitor工具实时监控eDirectory的当前连接数

2. eDirectory复制延迟或对象同步异常 #

如果你的环境是多服务器集群，部分用户的对象数据可能在故障发生时未完成同步，导致认证请求被发送到未同步的服务器上，触发认证失败。这类情况通常会在复制完成后自动恢复。

• 排查步骤：
  • 使用ndsrepair工具检查eDirectory的复制状态，查看是否有未解决的复制错误
  • 故障发生时，对比故障用户对象在不同服务器上的属性（比如密码哈希、状态属性）是否一致
  • 检查ndsd.log中是否有复制相关的警告或错误

3. 服务器资源瓶颈（内存/CPU） #

eDirectory服务器内存不足或CPU使用率过高时，会导致LDAP服务处理请求的能力下降，部分认证请求会因超时或资源分配失败而被拒绝。这类间歇性故障通常和服务器的负载波动有关。

• 排查步骤：
  • 故障发生时，监控服务器的内存使用率、CPU负载、交换分区使用情况
  • 检查eDirectory的内存配置（比如n4u.server.memory-limit参数），确认是否有内存分配不足的情况
  • 查看ndsd.log中是否有内存不足、GC频繁的日志条目

4. 时间同步异常 #

虽然NDS错误码-669主要指向认证失败，但如果用户端或eDirectory服务器之间的时间偏差过大（超过Kerberos或证书认证的时间容忍范围，若启用此类认证方式），也可能触发间歇性的认证失败。

• 排查步骤：
  • 检查所有eDirectory服务器、认证服务服务器以及故障用户设备的时间同步状态
  • 确认NTP服务运行正常，时间偏差控制在5分钟以内（Kerberos默认容忍范围）

5. WebAccess_PCO对象的隐性权限问题 #

虽然知识库提到缺失PublicKey/ACL会导致全员故障，但不排除部分用户组被意外排除在WebAccess_PCO的ACL之外，或者该对象的权限配置存在部分用户的访问限制。当这些用户的认证请求依赖该对象时，就会出现间歇性失败。

• 排查步骤：
  • 通过ConsoleOne或iManager查看WebAccess_PCO对象的ACL设置，确认所有用户/用户组是否拥有必要的访问权限
  • 检查该对象的PublicKey属性是否存在，是否有部分用户无法读取该属性

建议优先从连接数/资源瓶颈和复制同步这两个方向入手排查，因为这两类问题最符合“间歇性、部分用户”的故障特征。

内容的提问来源于stack exchange，提问作者likeGreen