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

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

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

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

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

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

После создания я переместил корневые полномочия в доверенные органы и предоставил необходимые разрешения.


adam principalcontext adlds
person HCL    schedule 29.11.2015    source источник
comment
если вы ipconfig /all, чтобы увидеть ваши DNS-серверы, есть ли у вас какие-либо зарегистрированные, к которым вы не можете получить доступ? Кроме того, у вас не выбрано Автоматическое определение настроек в Свойствах обозревателя -> Подключения -> Настройки локальной сети?   -  person ghangas    schedule 10.12.2015
comment
@ghangas: Спасибо за ваше предложение. К сожалению, недоступные DNS-серверы не настроены. Что касается настроек LAN, я не знаю, что вы имеете в виду. Но сетевой адаптер настроен на получение своей конфигурации через DHCP и то же самое для DNS (что работает, как и ожидалось) [Настройки сети->Ethernet->Параметры адаптера].   -  person HCL    schedule 11.12.2015
comment
Если ваш компьютер настроен на автоматическое определение параметров прокси-сервера, вы можете столкнуться с таким поведением при поиске wpad.domain. Время ожидания .com/wpad.dat истекло.   -  person ghangas    schedule 11.12.2015
comment
@ghangas: я пробовал, но поведение было таким же. Но все равно спасибо за предложение.   -  person HCL    schedule 12.12.2015

Ответы (1)


arrow_upward
1
arrow_downward

ОБНОВЛЕНИЕ

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

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

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

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

[machinename].local

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

Сертификат
Сертификат мне, однако, менять не пришлось.

person HCL    schedule 12.12.2015