adam - 通过 SSL 中的 LDAP 与 PrincipalContext 类的慢速 AD-LDS 连接

Question

在我的开发机器上，我必须安装一个 AD-LDS。原则上它工作正常，但是第一次通过 PrincipalContext-class 连接到 AD-LDS 非常慢(30 秒以上)。在我看来，它首先尝试连接到某个不存在的主机或目录，然后在超时(30 秒)后连接到我的 AD-LDS 并执行它应该执行的操作。

我在连接 LDP.exe 和 SSL 时观察到的相同行为。但是，使用 ADSI-Edit，通过 SSL 连接的速度非常快。通过非 SSL 连接也是如此。
我看看我是否能在 fiddler 中看到什么，但什么也没有。同样在事件日志中我什么也找不到。也许它与证书查找有关？它是用 makecert 自签名的。

更新
与此同时，我观察到一件小事，可能会给出一个提示:在系统事件日志中，第一次建立到 AD-LDS 的 SSL 连接时，会出现以下消息:

名称 _ldap._tcp.[ machineName 的名称解析] 在没有配置的 DNS 服务器响应后超时

但是，该消息仅注册一次，但每次连接到服务器都需要 30 秒以上。我还尝试在主机文件中输入相应的条目，但没有任何改变。

附加信息
可能这不是证书的问题，但可能有助于解决问题。因此，这里是我创建证书的方式(或多或少的 cargo 代码):

根权限

makecert -pe -n "CN=MyDevRootAuthority" -ss my -sr LocalMachine -a sha1 -sky signature -r "MyDevRootAuthority.cer" 

服务器证书

makecert -pe -n "CN=[MyComputerName]" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "MyDevRootAuthority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 "MyTestCertificate.cer" 

创建后，我将根权限移动到受信任的权限并授予所需的权限。

Answer 1

更新
最近遇到这个问题后，我深入挖掘了一下，发现，使用ContextOption ServerBind在构建 PrincipalContext 时可靠地解决了问题，除了ValidateCredentials - 上下文中的方法。
使用 SDS.P 的替代方法
附加信息:使用 SDS 和 SDS.AM 对我来说总是很复杂。由于其组件提供的通常不相关且不准确的错误信息(由于所用系统组件 (ADSI) 的复杂内部层次结构)，它花费了大量时间。
最终，我将一些代码移到了 SDS.P 命名空间，虽然互联网上关于如何使用的信息很少，但它似乎更合适和更好。我不能代表每个人或每个领域，但从基于 ADSI 的组件迁移到 SDS.P(基于 wldap32.dll)对我来说已经简化和澄清了很多。它甚至在大部分部分都是异步工作的。作为奖励，它非常快。
一个好的起点在这里:
https://msdn.microsoft.com/en-us/library/bb332056.aspx
旧解决方案
问题来自于我的开发计算机不属于域的情况。我们在域集成机器上尝试了同样的事情后，我看到了这一点，但没有出现问题。
解决方案(适用于非 AD 嵌入式计算机)
代码
在代码中，与 DirectoryContext 连接，主机名必须使用 dns 后缀“.local”指定。

[machinename].local

网卡
此外，在“高级”窗口的网络适配器设置中，在“DNS”选项卡下，必须将“本地”后缀注册为连接 DNS 地址的 DNS 后缀。

证书
然而，证书，我不必改变。