Connexion lente AD-LDS avec la classe PrincipalContext via LDAP en SSL

Question

Sur ma machine dev, j'ai dû installer un AD-LDS. En principe cela fonctionne bien, mais est le premier à se connecter à l'AD-LDS via la classe PrincipalContext extrêmement lent (30 secondes +). Il me semble qu'il essaie d'abord de se connecter à un hôte ou un répertoire non existant, puis après un délai (les 30 secondes) se connecte à mon AD-LDS et fait ce qu'il est censé faire.

Le même comportement que je constate lors de la connexion avec LDP.exe et SSL. Cependant avec ADSI-Edit, la connexion via SSL est super-rapide. Donc se connecte via non-SSL.
J'ai regardé si je pouvais voir quelque chose dans un violoniste, mais il n'y avait rien. Dans le journal des événements, je ne trouve rien non plus. Peut-être que cela a quelque chose à voir avec la recherche de certificat? Il est auto-signé avec makecert.

Mise à jour
En attendant, je l'ai observé une petite chose qui donne peut-être un indice: Dans le système événement journal, la première fois une connexion SSL connexion à l'AD-LDS est établie, le message suivant apparaît :.

résolution de noms pour le nom _ldap._tcp [machineName] a expiré après aucun des serveurs DNS configurés ont répondu

Cependant, le message est seulement enregistré une fois, mais tous les connecter au serveur prend la 30secs +. J'ai également essayé d'entrer les entrées correspondantes dans le fichier hosts, mais rien n'a changé.

Informations complémentaires
Probablement ce n'est pas un problème avec les certificats, mais peut-être qu'il aide à résoudre le problème. Par conséquent ici la façon dont je crée les certificats (plus ou moins de fret-code):

RootAuthority

makecert -pe -n "CN=MyDevRootAuthority" -ss my -sr LocalMachine -a sha1 -sky signature -r "MyDevRootAuthority.cer" 

certificat_serveur

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" 

Après la création je me suis déplacé l'autorité racine aux autorités de confiance et accordé les autorisations requises.

Answer 1

MISE À JOUR

Après avoir récemment le problème, je creusais un peu plus et trouvé que l'utilisation du ContextOptionServerBind lors de la construction du PrincipalContext a résolu le problème fiable, à l'exception du ValidateCredentials -method le contexte.

Une manière alternative avec SDS.P
Informations complémentaires: Travailler avec SDS et SDS.AM était pour moi toujours compliqué. Il en coûte beaucoup de temps grâce aux informations d'erreur souvent inexactes et inexactes données par ses composants (en raison de la hiérarchie interne complexe des composants système utilisés (ADSI)). Finalement, j'ai déplacé du code dans l'espace de noms SDS.P et bien qu'il y ait peu d'informations sur Internet sur la façon de travailler, cela semble un peu plus correct et agréable. Je ne peux pas parler pour tout le monde ou tous les domaines, mais le passage des composants basés sur ADSI à SDS.P (basé sur wldap32.dll) a simplifié et clarifié beaucoup pour moi. Et il fonctionne même de manière asynchrone pour la plupart de ses parties. Et en prime, c'est super rapide. Un bon point de départ est ici: https://msdn.microsoft.com/en-us/library/bb332056.aspx

solution Old Le problème vient de la circonstance, que mon ordinateur dev ne faisait pas partie d'un domaine. Je l'ai vu après avoir essayé la même chose sur une machine intégrée au domaine et le problème ne s'est pas produit.

Solution (pour les ordinateurs non embarqués AD-)
code
Dans le code, pour se connecter avec DirectoryContext, le nom d'hôte doit être spécifié avec le dns suffixe « .local ».

[machinename].local 

Adaptateur réseau
De plus, dans les paramètres adaptateurs réseau dans l'onglet « Avancé » -window, sous le -tab « DNS », le « local » -suffix doit être enregistré comme le suffixe DNS pour les adresses DNS de la connexion.

certificat
Le certificat cependant, je n'avais pas changer.