在通过Wireshark查看LDAPstream量时，我很想了解Windows客户端和Active Directory之间的对话。 每个对话将会变化到小于80k字节。 但有时会有2.5-3MB的对话。 有人可以解释从Windows客户端被要求的广告查询的types，也许正在交换的数据包大小不同吗？ 我有数据包捕获的有效载荷数据，但不知道如何读取它。 有一种方法我知道启动对话，这是“gpupdate / force”命令。 我也想知道窗口内的其他内部处理是如何启动查询的？
活动目录在LDAP目录中是不寻常的，因为拥有非常大的有效载荷并不罕见。 事实上，你可以发送的最大有效载荷是12兆字节。 这看起来奇怪，但是你去了。
在input方面，可能有人可能会发送像（|（samAccountName = jsmith）（samAccountName = jdoe）（…）（samAccountName = zsmith））的查询，并指定单个通配符或一起。
在输出端，大载荷的一个常见原因是分页。 当你有一个返回多个结果的查询时，响应可能是巨大的。 AD内置支持分页function，而且很容易实现，所以对于所有对象的简单查询都可以返回GB响应。
另一种情况是没有在查询中指定您需要的实际属性。 如果未指定，则可以返回对象的所有属性（构造属性除外），并且AD对象可能具有很多属性。
3 MB有效负载实际上是有趣的，因为如果你有Exchange，这将是当有人login时DC向工作站返回的数据量。 这是ADSI架构属性。 如果您在本地networking上，这可能不明显，但是如果您有远程客户端和有限的networking带宽，则每天下载ADSI模式属性会非常明显。
有关ADSI架构caching下载的更多信息：
当用户login工作站时，工作站将检查ADSI模式属性是否未下载，或者registry中保存的modifyTimestamp属性是否比AD中存储的更旧。 registry看起来像这样：
[HKEY_CURRENT_USER\Software\Microsoft\ADs\Providers\LDAP\CN=Aggregate,CN=Schema,CN=Configuration,DC=contoso,DC=com] "Time"="20141114030449.0Z" 被比较的AD属性：
DN：CN =架构，CN =configuration，DC = contoso，DC = com
属性：modifyTimestamp
modifyTimestamp是一个“构造”属性。 AD采取最新的whenChangeddate的其他属性来确定modifyTimestamp。 您可以通过运行repadmin / showObjMeta CN = Schema，CN = Configuration，DC = contoso，DC = com来查看whenChangeddate
一个合理的人会假设一个用户会下载ADSI架构caching一次，而不需要再次下载它，因为AD架构不会经常改变。 但是，modifyTimestamp并不仅仅指示AD架构更新时，因为客户可以执行自己的架构更新。
这成为一个问题是备份。 在域控制器上执行系统状态备份时，备份信息将logging在分区的dsaSignature属性中。 这反过来导致客户端工作站和成员服务器确定他们需要再次下载ADSI架构caching。 在本地networking上，这是不明显的，但是如果你有一个带宽有限的广域网隔离你的客户端和域控制器，这可能是非常痛苦的。
更为复杂的是，2008 R2 SP1发布时，modifyTimestampfunction实际上无法正常工作。 Microsoft使用一个修补程序纠正了此问题，这可能实际上会导致ADSI架构caching性能命中显现。
作为解决方法，可以在架构分区上的dsaSignature属性上设置一个标志，以指示备份在备份完成时不更新dsaSignature属性。 这将阻止modifyTimestamp连续递增，并将停止下载ADSI模式属性。 缺点是您的监控应用程序可能会抱怨架构分区没有被备份。 另一种select是你可以创build一个GPO来标记“时间”registry值到未来的一个date，但这将是一个kruge。