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

Question

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

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

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

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

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

其他信息
可能这不是证书的问题，但可能有助于解决问题。因此，我在这里创建证书的方式（或多或少的货物代码）：

RootAuthority

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解决了问题的可靠性，{{1}除外} - 关于上下文的方法。

SDS.P的替代方式
附加信息：使用SDS和SDS.AM对我来说总是很复杂。由于其组件给出的错误信息通常不相关且不准确（由于所使用的系统组件（ADSI）的复杂内部层次），因此花费了大量时间。 最后，我将一些代码移到SDS.P命名空间，尽管互联网上关于如何使用的信息很少，但它似乎更合适和更好。我无法代表每个人或每个域，但从基于ADSI的组件迁移到SDS.P（基于wldap32.dll）已经简化并为我澄清了很多。它甚至可以在大多数部件中异步工作。作为奖励，它超级快。 一个很好的起点在这里： https://msdn.microsoft.com/en-us/library/bb332056.aspx

旧解决方案 问题来自于我的开发计算机不属于域的情况。在我们在域集成机器上尝试相同的事情并且问题没有发生之后，我看到了这一点。

解决方案（适用于非AD嵌入式计算机）
的代码
在代码中，要与ValidateCredentials连接，必须使用dns后缀“.local”指定主机名。

DirectoryContext

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

<强>证书
然而，证书，我没有改变。