ldap分页查询限制导致同步不全，本质是客户端未适配rfc 2696分页控件：ad默认maxpagesize=1000属服务端硬截断，而0x71错误实为maxresultsetsize超限；须用带cookie的pagedresultscontrol（criticality设false）、收紧filter、启用tcp keepalive并抓包验证。
ldap分页查询限制导致账号同步不全，本质是客户端未适配服务端的分页机制，而非单纯“数据没拉完”。关键要区分两种情况：一种是服务端硬性截断（如ad默认maxpagesize=1000），另一种是查询匹配条目总数超限（maxresultsetsize触发0x71错误）。解决必须从协议层入手，不能只调客户端参数。
用标准分页控件（RFC 2696）代替手动分段
很多脚本或工具试图用(sAMAccountName>=a)按字母拆分过滤器，这虽能绕过单页限制，但极易漏数据（如含空格、特殊字符的账号），且无法保证顺序一致性。正确做法是启用Paged Results Control：
- Java JNDI中，每次
search()前必须传入带更新cookie的PagedResultsControl，且criticality设为false（Control.NONCRITICAL），否则服务器拒绝非关键控件时会直接失败 - Python ldap3库需显式启用
paging=True并检查响应中的cookie字段，空值才表示结束；仅设paged_size不循环处理cookie，实际只取第一页 - PowerShell中避免直接用
Get-ADObject -ResultPageSize，该参数仅影响客户端缓冲，不触发服务端分页——应改用[System.DirectoryServices.Protocols.SearchRequest]手动构造带控件的请求
确认并规避服务端总结果集限制
0x71 LDAP_ADMIN_LIMIT_EXCEEDED错误常被误判为权限问题，实则是服务端对本次搜索操作的**累计匹配条目数**超限（由MaxResultSetSize策略控制，非MaxPageSize）。即使分页取，只要筛选器匹配到10001个对象，第10001次分页请求就会被终止：
- 优先收紧
filter：把(objectClass=user)拆成(sAMAccountName>=a)(sAMAccountName，再逐段查；或加时间戳条件如<code>(whenChanged>=20260401000000.0Z)限定增量范围 - 禁用
memberOf等高开销属性：这些属性需实时计算，大幅增加匹配耗时与结果集膨胀风险；同步时只取distinguishedNamesAMAccountName等核心字段 - 验证当前策略：在DC上运行
dsquery server -o ldif -attr rangeUpper查MaxPageSize，用组策略编辑器确认MaxResultSetSize是否被域策略设为5000等异常低值
客户端保活与超时协同配置
分页过程若持续数分钟，中间网络设备（防火墙、LB）可能因TCP空闲断连，导致后续分页请求静默失败。此时调整timeout参数无效，必须激活TCP keepalive：
- Linux客户端：调
/proc/sys/net/ipv4/tcp_keepalive_time至240秒（低于常见代理5分钟切断阈值） - Java应用：启动参数加
-Dcom.sun.jndi.ldap.connect.pool.timeout=5000，并自定义SocketFactory设置SO_KEEPALIVE - PowerShell：设置
$searcher.ClientTimeout = [TimeSpan]::FromMinutes(10)，同时确保DC与客户端间无NAT设备干扰keepalive探测包
验证分页行为是否真正生效
不要依赖日志里“共获取X条”的统计，要抓包或查服务端日志确认协议交互：
- 用
ldp.exe连接DC，勾选Options → Perform Queries Using Simple Paged Results，手动输入页大小测试，观察是否返回非空cookie - 开启AD DS诊断日志（
Event Viewer → Applications and Services Logs → Directory Service → Debug），查找LDAP client exceeded page limit事件 - Wireshark过滤
ldap.controls == "1.2.840.113556.1.4.319"，确认每个请求都携带cookie且响应有sizeLimitExceeded以外的状态码
