个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化Active Directory 工具学习笔记10.4AdInsight 概述与抓包原理——把 LDAP/认证“看得见”Active Directory 工具学习笔记10.4AdInsight 概述与抓包原理——把 LDAP/认证“看得见”1. AdInsight 是什么它看的是调用链不是网络帧2. 抓包原理客户端调用栈如何变成事件时间线3. 首次使用最小可用流程4. 输出字段先读懂列再谈定位根因5. 返回码不要停在数字要拆调用链6. 五大常见诊断场景6.1 登录 / SSO 偶发失败6.2 GPO 应用缓慢或失败6.3 应用程序目录查询失败6.4 LDAPS / 证书相关错误6.5 组解析或嵌套过深导致超时7. 实操剧本还原一次问题现场8. 常见坑位与处理建议9. 总结把黑盒调用翻译成可读事件Active Directory 工具学习笔记10.4AdInsight 概述与抓包原理——把 LDAP/认证“看得见”前面几篇我们主要围绕AdExplorer展开重点是把 AD 对象、属性、搜索和快照看清楚。从这一篇开始视角要切换到另一个工具AdInsight。AdExplorer 更像是“看目录结构”的工具而 AdInsight 更像是“看调用过程”的工具。它不是普通网络抓包工具不是去看网线上跑了多少数据帧而是从客户端调用栈出发把应用访问 Active Directory 时发生的 LDAP、ADSI、SSPI、认证协商、DC 发现、返回码和调用耗时记录下来。这类工具在企业桌面和域环境排障里非常有价值。因为很多问题看起来像网络问题实际上是调用参数、认证方式、SPN、Base DN、Filter、权限或证书链出了问题。网络通了不代表 LDAP 调用成功能连上 DC也不代表认证和目录查询正常。这张图展示的是 AdInsight 的整体定位它把 LDAP、ADSI、SSPI、Kerberos、返回码、DC 发现和耗时分析放到同一个调用链视角里让原本黑盒的认证和目录访问过程变得可见。从图中可以看出AdInsight 的强项不是“看包多不多”而是看一次调用到底经历了哪些环节、哪个环节慢、哪个环节失败、失败时返回了什么状态码。对登录慢、GPO 卡顿、目录查询失败、LDAPS 证书错误、Kerberos / NTLM 回落这类问题它比单纯看网络包更贴近根因。1. AdInsight 是什么它看的是调用链不是网络帧很多人第一次听到 AdInsight会下意识把它理解成“LDAP 抓包工具”。这个理解只对了一半。它确实能帮助我们分析 LDAP 和认证问题但它不是 Wireshark也不是 NetMon。Wireshark 这类网络抓包工具看到的是线上的数据包比如源 IP、目标 IP、端口、协议、TLS 握手、请求响应数据帧。这个视角适合证明“网络有没有包”“连接有没有建立”“TLS 握手有没有失败”。AdInsight 看的则更靠里。它关注的是进程内部发起的 LDAP / ADSI / SSPI 调用以及系统返回给客户端的状态。也就是说它更适合回答哪个进程发起调用、调用了什么 API、连到哪台 DC、用了什么认证方式、返回了什么错误码、耗时多久。如果问题是“网络有没有通”优先看网络抓包如果问题是“为什么应用明明能连 DC 但仍然认证失败”优先看 AdInsight。对比项网络抓包工具AdInsight观察层级网络数据帧客户端调用栈 / API 事件适合问题连通性、端口、TLS 握手、数据包往返LDAP 调用、认证协商、返回码、耗时典型对象IP、端口、协议、数据帧Process、Operation、Auth、Result、Duration优势证明网络层事实还原应用和系统调用过程局限不一定知道应用为什么失败不替代网络层抓包不要用一个工具解决所有层的问题。网络抓包和 AdInsight 不是替代关系而是互补关系。网络层证明“链路有没有问题”AdInsight 证明“调用有没有成功”。这两个证据合起来排障结论才更稳。应用或系统组件LDAP / ADSI / SSPI 调用AdInsight 捕获调用事件显示进程 / API / 目标 DC / 认证方式返回码 / 耗时 / Filter / Scope定位慢在哪一步 / 错在哪一环2. 抓包原理客户端调用栈如何变成事件时间线理解 AdInsight关键是先理解它的数据来源。它不是去域控数据库里翻业务逻辑也不是绕过安全策略直接读取秘密信息。它关注的是客户端访问 AD 时发生过的调用行为。比如一个应用要做目录查询通常会经历连接、绑定、搜索、读取属性、解析结果等动作。再比如登录或 SSO 失败背后可能经历了 SSPI 协商、Kerberos 尝试、NTLM 回落、SPN 匹配、DC 定位等过程。AdInsight 的作用就是把这些过程按时间顺序记录下来。这张图展示的是 AdInsight 的抓包原理应用进程发起 LDAP / ADSI / SSPI / LSA 调用客户端调用栈捕获这些行为再规范化成事件时间线最终指向目标 DC 和认证服务。从图中可以看出AdInsight 的核心产物是“事件”。一次 ldap_bind 是一个事件一次 ldap_search 是一个事件一次 SSPI 初始化或认证协商也是一个事件。事件里会包含时间戳、进程、线程、操作类型、目标服务器、端口、认证方式、返回码和耗时。这就是为什么 AdInsight 很适合分析“慢”和“失败”。慢可以看 Duration失败可以看 Result / Status责任边界可以看 Process / PID / TID目录查询问题可以看 Base DN、Scope 和 Filter。不过也要明确它不做什么。AdInsight 不会替你判断业务系统逻辑是否正确也不会帮你绕过权限或破解认证。它只是把发生过的调用和返回结果摆出来让你能按证据还原过程。如果工具里没有捕获到对应事件不一定代表问题不存在。可能是你没有选对进程也可能是复现窗口错过了也可能是权限不足导致事件捕获不完整。现场使用时先保证捕获范围和复现动作准确。3. 首次使用最小可用流程AdInsight 不建议一上来就全系统抓取。全局抓取虽然看起来完整但噪音会很大尤其在域环境里后台服务、系统组件、办公软件、浏览器、代理、杀软都可能产生目录相关调用。第一次上手推荐按最小可用流程走以管理员运行选择目标进程开始捕获复现问题停止捕获保存会话。这个流程不复杂但非常关键。这张图展示的是 AdInsight 的最小可用流程以管理员运行选择目标进程开始捕获复现问题最后停止捕获并保存会话。从图中可以看出关键不是“抓得越多越好”而是“抓得刚刚好”。只抓目标进程可以明显减少噪音也能降低采集到无关敏感调用的概率。最小可用流程 1. 以管理员身份运行 AdInsight 2. 指定目标进程例如 gpupdate.exe、winlogon.exe 或业务系统 EXE 3. 点击 Start Capture 4. 立即复现问题 5. 停止捕获 6. 保存会话文件 7. 按错误码、耗时、Operation 做筛选。推荐先抓目标进程不要默认系统范围全抓。比如 GPO 问题关注 gpupdate.exe 或 winlogon.exe应用鉴权问题关注应用自身 EXE目录查询失败关注发起 LDAP 查询的客户端进程。现场还有一个小技巧复现问题前先记录开始时间。比如用户说 10:32 登录卡住那么你后续筛选事件时就可以围绕 10:32 前后几分钟看调用链而不是在海量事件里乱翻。4. 输出字段先读懂列再谈定位根因AdInsight 的界面里会出现很多字段。初学时容易被字段吓住其实只要抓住几列就够了Time、Duration、Process、Operation、Server、Port、Auth、Result、Filter、Scope。Time 和 Duration 用来判断时间点和耗时。Process / PID / TID 用来判断是谁发起调用。Operation 告诉你是 bind、search、modify 还是其他动作。Server / Port 告诉你打到了哪台 DC、走的是 389、636 还是 GC。Auth 告诉你认证方式。Result / Status 则直接指向成功或失败。这张图展示的是 AdInsight 输出字段和常见返回码速查左侧是 Time / Duration、Process、Operation、Server / Port、Auth、Result、Filter 等关键字段右侧是 LDAP、Win32、NTSTATUS 常见错误码。从图中可以看出AdInsight 不是只给一个“失败”。它会把失败放在上下文里哪个进程、哪个操作、哪个服务器、哪个端口、哪种认证、什么返回码、耗时多久。这些信息组合起来才是可以流转给目录团队、网络团队或开发团队的证据。字段重点看什么现场判断Time / Duration调用时间和耗时判断慢在哪一步Process / PID / TID发起调用的进程线程划定责任边界Operationbind / search / modify明确动作类型Server / PortDC / 389 / 636 / 3268 / 3269判断目标和协议Auth / SASLKerberos / NTLM / Negotiate判断认证方式Filter / ScopeLDAP 过滤器和搜索范围判断查询是否合理Result / StatusLDAP / Win32 / NTSTATUS定位错误本体不要只盯着错误码本身。LDAP 49 可以是凭据错误也可能和 UPN 后缀、账号锁定、密码过期有关LDAP 81 / 82 可能和网络、SSL、名字解析有关。错误码必须结合目标 DC、端口、认证方式和调用参数一起看。5. 返回码不要停在数字要拆调用链AdInsight 排障里返回码是非常重要的线索但它不是终点。很多人看到 49 就说“密码错了”看到 81 就说“网络不通”这个判断太粗。返回码常见含义需要继续确认LDAP 49凭据错误UPN 后缀、账号锁定、密码过期、绑定方式LDAP 32对象不存在DN 路径、Base DN、搜索范围LDAP 34DN 语法错误特殊字符转义、路径拼接LDAP 50 / 51 / 53权限 / 不可用 / 服务繁忙ACL、DC 状态、服务负载LDAP 81 / 82本地错误 / 不可用网络、SSL、名字解析、端口策略Win32 5拒绝访问权限、UAC、ACLNTSTATUS 0xC000006D认证失败用户名、密码、域、认证协议NTSTATUS 0xC0000064无此用户账号名、域名、UPN 后缀正确做法是先看失败事件再看它前后的 bind / search / referral / retry再看目标 DC 和认证方式。这样才能判断是账号问题、路径问题、网络问题、证书问题还是应用查询条件写错。返回码分析顺序 1. 找到失败事件 2. 看 Operation 是 bind / search / modify 3. 看 Server / Port 4. 看 Auth / SASL 5. 看 Filter / Scope / DN 6. 看 Duration 是否异常 7. 结合上下游事件判断根因。建议把常见返回码整理成团队速查表。这样一线同事看到错误码后不会只凭经验猜而是按固定字段补齐证据。6. 五大常见诊断场景AdInsight 最适合的不是泛泛巡检而是带着问题去抓。比如登录失败、GPO 慢、应用查询失败、LDAPS 证书错误、组嵌套过深导致超时这些都适合用它还原调用过程。这张图展示的是 AdInsight 的五大诊断场景登录 / SSO 失败、GPO 缓慢、目录查询失败、LDAP 证书问题、组嵌套超时。从图中可以看出每个场景都不是单独看一个错误码而是要看一组链路。登录 / SSO 失败要看 Kerberos、NTLM、SPNGPO 缓慢要看 gpupdate 或 winlogon 发起的搜索目录查询失败要看 Base DN 和 FilterLDAPS 问题要看 636 / 3269 和证书链组嵌套超时要看连续搜索和返回项数量。6.1 登录 / SSO 偶发失败登录或 SSO 失败时重点看 ldap_bind、Auth、SPN 和 Result。如果出现 Negotiate 后回落到 NTLM要优先检查 SPN、时间同步、约束委派、信任路径。不要看到 NTLM 就直接下结论说“不安全配置”。先判断为什么没有走 Kerberos是 SPN 缺失、重复还是客户端拿不到票据。6.2 GPO 应用缓慢或失败GPO 问题可以关注 gpupdate.exe 或 winlogon.exe。重点看 ldap_search、Duration、Server、Referral。某些情况下客户端命中了远端 DC或者跨域引用跳转过多会让策略处理变慢。6.3 应用程序目录查询失败应用程序失败时不要只看应用日志里一句“LDAP Error”。AdInsight 可以把失败时的 Base DN、Filter、Scope、Result 取出来。把这些信息给开发或供应商比截图一个报错窗口更有价值。6.4 LDAPS / 证书相关错误如果目标端口是 636 或 3269且握手阶段失败问题可能在 DC 证书、EKU、CN / SAN、信任链、客户端根证书或策略要求。此时可以结合 DC 端 Schannel 日志一起看。6.5 组解析或嵌套过深导致超时如果连续出现大量 ldap_searchDuration 越来越长返回项越来越多就要考虑组嵌套层级、分页大小、应用侧缓存和裁剪策略。这个问题不是简单扩服务器就能解决。7. 实操剧本还原一次问题现场工具真正好不好用要看能不能把一次问题还原出来。下面这套剧本适合登录慢、GPO 卡顿、应用 LDAP 查询失败这类问题。AdInsight 实操剧本 1. 圈定目标进程 2. 记录开始时间 3. 开始捕获 4. 复现问题 5. 停止捕获并保存会话 6. 过滤 bind / search / modify 7. 按 Duration 排序 8. 查看失败事件 9. 导出精简证据 10. 绑定工单流转。建议优先看两类事件失败事件和 Top 慢事件。失败事件告诉你哪里错了Top 慢事件告诉你哪里拖慢了。把这两类事件拿出来基本就能形成第一轮排查结论。如果要流转给其他团队建议不要把完整会话文件直接甩出去。更好的方式是导出精简证据问题时间段、目标进程、失败 Operation、目标 DC、Result、Duration、Filter / DN并对域名、服务器名、UPN 做脱敏。完整会话文件可能包含敏感目录信息和认证上下文不要随意外发。尤其是给供应商分析时必须先脱敏。8. 常见坑位与处理建议第一个坑是抓不到关键步骤。多数原因不是工具坏而是捕获开始得太晚、目标进程选错、权限不够或者复现动作没有真正触发 LDAP / 认证调用。第二个坑是事件太多。解决办法不是硬看而是过滤。先只看目标进程再过滤 bind / search / modify再按 Duration 和 Result 排序。第三个坑是与网络抓包结果看起来不一致。线上包可能是正常的但应用调用仍然失败。这个时候不要互相否定要分层判断网络层看连通性AdInsight 看调用结果。第四个坑是导出 CSV 字符异常。中文、DN、多值属性很容易在 Excel 里显示混乱。建议统一 UTF-8 BOM多值属性用分号分隔。第五个坑是被 EDR 拦截。Sysinternals 工具虽然是微软工具但在部分企业安全策略下仍可能被拦。应按流程走白名单不要临时关闭安全软件。AdInsight 的正确使用方式是用最小范围抓取最关键证据。它不是拿来长时间全量监控的工具更适合问题复现窗口内的精准捕获。9. 总结把黑盒调用翻译成可读事件这一篇我们先把 AdInsight 的定位和抓包原理讲清楚。它不是传统网络抓包工具而是从客户端调用栈出发把 LDAP、ADSI、SSPI、Kerberos、NTLM、DC 定位、返回码和耗时变成可读事件。它最适合解决的是那些“网络看起来正常但应用就是失败或很慢”的问题。因为这类问题的根因往往不在网线而在调用参数、认证方式、SPN、证书、Base DN、Filter、Referral 或权限边界。核心判断是Wireshark 让你看到网络发生了什么AdInsight 让你看到客户端以为自己在做什么以及系统返回了什么。当你能把一次 LDAP / 认证问题拆成“进程 → 操作 → 目标 DC → 认证方式 → 返回码 → 耗时 → 参数”的链路时排障就从猜测进入了证据阶段。 返回顶部点击回到顶部