Медленное соединение AD-LDS с классом PrincipalContext через LDAP в SSL

Question

На моей машине dev мне пришлось установить AD-LDS. В принципе, он отлично работает, однако первый подключается к AD-LDS через класс PrincipalContext очень медленно (30 секунд +). Мне кажется, что он сначала пытается подключиться к некоторому не существующему хосту или директории, а затем после истечения таймаута (30 секунд) подключается к моему AD-LDS и делает то, что он должен делать.

Такое же поведение наблюдается при подключении к LDP.exe и SSL. Однако с помощью ADSI-Edit подключение через SSL происходит очень быстро. Таким образом, подключается через не-SSL.
Я посмотрел, мог ли я что-нибудь увидеть в скрипаче, но ничего не было. Также в журнале событий я ничего не могу найти. Может быть, это как-то связано с поиском сертификата? Это самозапись с makecert.

Update
В то же время я заметил одну маленькую вещь, которая, возможно, дает подсказку: В системном журнале событий, в первый раз, установил SSL-соединение с AD-LDS, появляется следующее сообщение :.

разрешение имен для имени _ldap._tcp [machineName] истекло после того, как ни один из настроенных DNS-серверов ответил

Однако сообщение регистрируется только один раз, но каждый подключиться к серверу принимает 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

UPDATE

После того, как проблемы в последнее время, я вырыл немного глубже и обнаружил, что с помощью ContextOptionServerBind при построении PrincipalContext решено надежной проблемы, для ValidateCredentials -метода от контекста, за исключением.

Альтернативный способ с SDS.P
Дополнительная информация: Работа с SDS и SDS.AM был для меня всегда сложно. Это требует много времени благодаря часто несвязанной и неточной информации об ошибках, предоставляемой ее компонентами (из-за сложной внутренней иерархии используемых компонентов системы (ADSI)). В конце концов, я переместил некоторый код в пространство имен SDS.P, и, хотя в Интернете мало информации о том, как работать, кажется, что это несколько более правильно и приятно. Я не могу говорить для всех или каждого домена, но переход от компонентов на основе ADSI к SDS.P (на основе wldap32.dll) упростил и разъяснил многое для меня. И он работает асинхронно для большинства его частей. И в качестве бонуса это супер быстро. Хорошая отправная точка здесь: https://msdn.microsoft.com/en-us/library/bb332056.aspx

Старый решение Проблема возникает из того обстоятельства, что мой DEV компьютер не входит в домен. Я видел это после того, как мы попробовали одно и то же на интегрированной с доменом машине, и проблемы не произошло.

Решение (для не-AD-встроенные компьютеры)
Код
В коде, чтобы соединиться с DirectoryContext, имя-хоста должно быть указано с ДНС-суффикс «.local».

[machinename].local 

Сетевой адаптер
Кроме того, в настройках сетевых адаптеров-в «Advanced» -window под «DNS» -Tab, «местный» -suffix должен быть зарегистрирован в качестве суффикса DNS для DNS-адресов соединения.

Сертификат
Сертификат однако, я не изменить.