On my dev machine I had to install an AD-LDS. In principal it works fine, however is the first connect to the AD-LDS via the PrincipalContext-class extremely slow (30 seconds+). It seems to me that it first tries to connect to some non existing host or directory and then after a timeout (the 30 seconds) connects to my AD-LDS and does what it is supposed to do.
The same behavior I observe when connecting with LDP.exe and SSL. However with ADSI-Edit, connecting via SSL is super-fast. So are connects via non-SSL.
I looked if I could see something in fiddler, but there was nothing. Also in the event-log I can find nothing. Maybe it has something to do with the certificate lookup? It is self-signed with makecert.
Update
In the meantime I have observed one little thing that maybe gives a hint: In the system event-log, the first time an SSL-connection to the AD-LDS is established, the following message appears:
Name resolution for the name _ldap._tcp.[machineName
] timed out after none of the configured DNS servers responded
However, the message is only registered once, but every connect to the server takes the 30secs+. I also tried to enter corresponding entries in the hosts-file, but nothing changed.
Additional info
Probably it's not a problem with the certificates but maybe it helps solving the problem. Therefore here the way I created the certificates (more or less cargo-code):
RootAuthority
makecert -pe -n "CN=MyDevRootAuthority" -ss my -sr LocalMachine -a sha1 -sky signature -r "MyDevRootAuthority.cer"
Server-certificate
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"
After creation I moved the root authority to the trusted authorities and granted the required permissions.
UPDATE
After having the problem recently, I dug a little deeper and found, that using the ContextOption
ServerBind
while constructing the PrincipalContext
solved the problem reliable, except for the ValidateCredentials
-method on the context.
Alternative way with SDS.P
Additional information: Working with SDS and SDS.AM was for me always complicated. It costs a lot of time thanks to the often unrelated and inaccurate error-information given by its components (due to the complex inner hierarchy of the used system components (ADSI)).
Eventually, I moved some code to the SDS.P namespace and although there is little information in the internet on how to work with, it seems somewhat more proper and nice. I cannot speak for everyone or every domain, but moving from the ADSI-based components to SDS.P (wldap32.dll based) has simplified and clarified a lot for me. And it even works asynchronously for the most of its parts. And as a bonus, it's super fast.
A good starting-point is here:
https://msdn.microsoft.com/en-us/library/bb332056.aspx
Old solution The problem comes from the circumstance, that my dev computer was not part of a domain. I saw this after we tried the same thing on a domain-integrated machine and the problem didn’t happen.
Solution (for non-AD-embedded computers)
Code
In code, to connect with DirectoryContext
, the host-name must be specified with the dns-suffix “.local”.
[machinename].local
Network Adapter
Additionally, in the network-adapters settings in the “Advanced”-window, under the “DNS”-tab, the “local”-suffix must be registered as the DNS suffix for the connection’s DNS addresses.
Certificate
The certificate however, I had not to change.