我正在从Active Directory迁移一些代码，重写所有目录请求以引用System.Directory.Protocols中的类，并与LDAP v3兼容。这应该是一个低级的v3 LDAP命名空间，因此假设它不会被AD特定类型污染。以下代码来自一个监视器后台工作进程，该进程已经在使用System.Directory.Protocols命名空间。它向AD打开一个异步长时间运行请求，并使用Control DirSyncRequestControl侦听更改。
SearchRequest request = new SearchRequest(
mDNSearchRoot,
mLdapFilter,
SearchScope.Subtree,
mAttrsToWatch
);
request.Controls.Add(
new DirSyncRequestControl(
mCookie,
mDirSyncOptions
)
);
mConn.BeginSendRequest(
request,
mRequestTimeout,
PartialResultProcessing.NoPartialResultSupport,
endPollDirectory,
null
);它以字节[]的形式发送一个cookie，告诉目录什么时候开始查询，这样在后台工作崩溃并需要重新启动的情况下很方便.在endPollDirectory回调中，一个更新cookie被接收并立即保存到文件系统中，以防需要重新启动，我们总是知道我们最后一次接收到结果的时间.该cookie在重新启动时加载，并随DirSyncRequestControl传递回来。
我所面临的问题是DirSyncRequestControl是针对一个OID运行的，该OID具体来说是一个Active Directory扩展，不是标准LDAP。我们的公司目录是基于IBM的LDAP，无法应用AD OID和控件。标准LDAP支持“Persistent Search”2.16.840.1.113730.3.4.3，但.NET不提供可以按上述代码添加的控件。也没有办法像cookie一样传递参数。Persistent Search控件的思想是，您打开连接，随着时间的推移，LDAP服务器发送回更改，我可以对此做出响应。但在启动连接时，没有办法指定何时返回结果。只有请求启动后的结果才会被接收。2如果监视器死机，并且在监视器重新启动之前发生了目录更改，则这些更改将永远无法处理。
有人知道是否有一个符合标准LDAP的现有控件可以添加到请求中，该请求的操作方式与AD特定的DirSyncRequestControl相同，其中可以传递开始日期时间？
1条答案
按热度按时间ujv3wf0j1#
有人知道是否有一个符合标准LDAP的现有控件可以添加到请求中，该请求的操作方式与AD特定的DirSyncRequestControl相同，其中可以传递开始日期时间？
标准将是来自RFC 4533的
1.3.6.1.4.1.4203.1.9.1.1“同步请求”控制，这是OpenLDAP和389-ds中“Syncrepl”目录复制的基础。（尽管“标准”并不保证IBM的LDAP服务器将支持它--或者在您的服务器上专门启用它，类似于OpenLDAP要求首先加载“syncprov”覆盖层的方式。）
虽然dotnet本身并不支持这个控件（它似乎只专注于支持Active Directory扩展），但应该可以创建一个类似于Dir Sync Request Control类的自定义类，带有正确的OID和正确的BER序列化（并以某种方式处理“Sync Done”控件，将最终的同步cookie传递给您，等等）。
另一种方法是持续搜索
(modifyTimestamp>=...)，并跟踪最后接收到的条目更改时间戳，而不是“cookie”。