Slow AD-LDS connection with the PrincipalContext-class via LDAP in SSL

Question

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.

Answer 1

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.