Slow AD-LDS connection with PrincipalContext class through LDAP to SSL

Question

On my dev machine, I had to install AD-LDS. In principle, it works fine, but the first one connects to AD-LDS through the PrincipalContext class very slowly (30 seconds +). It seems to me that he first tries to connect to some non-existent host or directory, and then after a timeout (30 seconds) connects to my AD-LDS and does what it should do.

The same behavior is observed when connecting with LDP.exe and SSL. However, using ADSI-Edit, SSL connectivity is very fast. Thus, it connects via SSL. I looked to see if I could see something in the violinist, but there was nothing. Also in the event log I can not find anything. Maybe this has something to do with certificate search? This is self-recording with makecert.

Update
In the meantime, I noticed one little thing that might give a hint: the following message appears in the system event log when you first establish an SSL connection with AD-LDS:

Name resolution for the name _ldap._tcp. [ machineName ] is disabled after none of the configured DNS servers respond

However, the message is logged only once, but each connection to the server takes 30 seconds +. I also tried to enter the appropriate entries in the hosts file, but nothing changed.

Additional Information
This is probably not a certificate issue, but it may help solve the problem. Therefore, here, as I created the certificates (more or less freight code):

Rootoothority

 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 transferred root authority to trusted authorities and granted the required permissions.

Answer 1

UPDATE

After a recent problem, I went a little deeper and found that using the ContextOption ServerBind when building the PrincipalContext resolved the problem reliably, with the exception of the ValidateCredentials method in context.

Alternative way with SDS.P
Additional Information: Working with SDS and SDS.AM has always been difficult for me. This is time consuming due to the often unrelated and inaccurate error information provided by its components (due to the complex internal hierarchy of system components used (ADSI)). In the end, I moved some code to the SDS.P namespace, and although there is little information on how to work on the Internet, it seems a bit more correct and enjoyable. I can’t speak for all or every domain, but the transition from ADSI-based components to SDS.P (based on wldap32.dll) has simplified and clarified a lot for me. And it works asynchronously for most of its parts. And as a bonus, it's super fast. Good starting point here: https://msdn.microsoft.com/en-us/library/bb332056.aspx

Old solution The problem arises because my dev computer was not part of the domain. I saw this after we tried the same thing on a machine integrated with the domain, and the problem did not occur.

Solution (for computers not equipped with AD)
Code
In the code to connect to the DirectoryContext the host name must be specified using dns-suffix ".local".

 [machinename].local 

Network adapter
In addition, in the settings of network adapters in the "Advanced" window under "DNS" -tab, the "local" suffix must be registered as the DNS suffix for the DNS addresses of the connections.

certificate
However, the certificate has not changed.