通过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连接时,将显示以下消息:

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

但是,该消息仅注册一次,但每次连接到服务器需要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

更新

\n

最近遇到这个问题后，我进行了更深入的研究，发现除了上下文中的 - 方法之外，使用ContextOption ServerBindwhile 构造PrincipalContext解决的问题是可靠的。ValidateCredentials

\n

使用 SDS.P 的替代方法
\n其他信息：使用 SDS 和 SDS.AM 对我来说总是很复杂。由于其组件经常提供不相关且不准确的错误信息（由于所使用的系统组件 (ADSI) 的复杂内部层次结构），因此花费了大量时间。\n最终，我将一些代码移至 SDS.P 命名空间尽管互联网上关于如何使用的信息很少，但它似乎更合适和更好。我不能代表每个人或每个领域，但从基于 ADSI 的组件迁移到 SDS.P（基于 wldap32.dll）对我来说已经简化和澄清了很多。它的大部分部分甚至是异步工作的。作为奖励，它的速度非常快。\n这里有一个很好的起点：\n https://msdn.microsoft.com/en-us/library/bb332056.aspx

\n

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

\n

解决方案（对于非 AD 嵌入式计算机）
\n代码
\n在代码中，要与 进行连接DirectoryContext，必须使用 dns 后缀 \xe2\x80\x9c.local\xe2\x80\x9d 指定主机名。

\n

[machinename].local\n

\n

网络适​​配器
\n此外，在\xe2\x80\x9cAdvanced\xe2\x80\x9d-窗口中的网络适配器设置中，\xe2\x80\x9cDNS\xe2\x80\x9d-选项卡下，\xe2\x80 \x9clocal\xe2\x80\x9d-suffix 必须注册为连接\xe2\x80\x99s DNS 地址的 DNS 后缀。\n

\n

证书
\n但是，我不必更改证书。

\n