Защищенная аутентификация LDAP Проблема

Question

Я использую следующий код C# в коде, расположенном за веб-формой, развернутой в пуле приложений ASP.NET 4 (4.0.30319) на Server1 и Server2.

PrincipalContext pc = new PrincipalContext(ContextType.Domain, "testnet.testad.org:636", "dc=testnet,dc=testad,dc=org"); 
bool validated = pc.ValidateCredentials(username, password, ContextOptions.Negotiate); 

Сервер1 работает: Windows Server 2003 SP2
IIS 6.0
ASP.NET версии 4.0.30319

Это занимает от 30-60 секунд для проверки подлинности в зависимости от опций.
(Примечание: с помощью регулярных LDAP сразу проверяет подлинность без задержки)

Сервер 2 бежит: Windows Server 2008 SP2
IIS 7.0
версия ASP.NET 4.0.30319

Запуск таже как Server1, Server2 аутентифицируется почти мгновенно.
(Я также пробовал код с другим сервером IIS 7.0 с теми же результатами)

Кто-нибудь сталкивался с этим вопросом раньше?
Есть ли альтернативный способ аутентификации на сервере IIS 6.0 или сервере IIS 7.0?
Есть ли что-то, что мне нужно для настройки, добавления, удаления и т. Д.,?

Спасибо за любую помощь по этому вопросу.

.............................................. .................................................. ..............................................

[Обновить]

Я включил wirehark при выполнении запроса аутентификации ldaps.
Я создал файл, содержащий все запросы через 636.
Его можно посмотреть здесь: Server1 636 traffic

Самые большие зазоры находятся между:

No. 1949 на 1.115583 сек - № 06788 на 14.501754 сек
и
No. 6803 на 14.64297 сек - № 11742 на 27,921379 сек

Все другие движения на этом порту происходит в течение одной секунды.

ПРИМЕЧАНИЕ. На сервере Server примерно одинаковое количество трафика, но все это происходит между 2-3 секундами.
Его можно посмотреть здесь: Server2 636 traffic

Я побежал команду NetStat -ano»и обнаружил следующие соединения для LDAPS, когда я Логин:

Прото Локальный адрес Внешний адрес Состояние PID
TCP 10.1.72.74:1761 10.1.72.54:636 УСТАНАВЛИВАЕТСЯ 3688
TCP 10.1.72.74:1800 10.1.72.54:636 УСТАНАВЛИВАЕТСЯ 3688
TCP 10.1.72.74:1825 10.1.72.54: 636 ESTABLISHED 3688

Answer 1

Посмотрите на мой ответ в ServerFault ...

Служба не может быть в состоянии получить доступ к:

C: \ Documents и Settings \ All Users \ Application Data \ Microsoft \ Crypto \ RSA \ MachineKeys

Ваше упоминание:

Дата: 25.03.2013 Время: 10:11:06 AM Источник: Schannel «Произошла фатальная ошибка при попытке доступа к учетным записям SSL-клиента ключ.

делает его вероятным.

Answer 2

Проверьте записи реестра, чтобы узнать, какая версия SSL/TLS поддерживается; вопрос, который может привести к проблемам рукопожатия ... (см Сценарий 5 в ссылке, приведенной ниже)

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Protocols

Для некоторых соответствующих сценариев и их разрешения имеют a читать troubleshooting ssl related issues server certificate

Answer 3

PrincipalContextValidateCredentials метод в основном является оберткой для операции связывания LDAP. Двумя основными статьями, которые следует читать для этого, являются IADsOpenDSObject::OpenDSObject и LDAP ADsPath.

Вы используете SSL, поэтому вам нужно указать, что если вы хотите, чтобы он был максимально эффективным. Документация по ContextOptions аргумента метода ValidateCredentials на самом деле звучит как он не поддерживает это:

Сочетание одного или нескольких ContextOptions перечисления значений параметров, используемых для привязки к серверу. Этот параметр может указывать только Simple bind с SSL или без него или Negotiate bind.

Предполагая, что я искажая документацию и метод ValidateCredentials действительно поддержка определения Negotiate | SecureSocketLayer, вы должны смотреть на то, как вы передаете имя пользователя. В статье OpenDSObject, он дает этот совет от формата имени пользователя в:

Вы можете пройти в lpszUserName в качестве одного из следующих строк:

1. Имя учетной записи пользователя, такие как «jeffsmith ». Чтобы использовать имя пользователя самостоятельно, вы должны установить только флаг ADS_SECURE_AUTHENTICATION в параметре lnReserved.

2. Путь пользователя из предыдущей версии Windows NT, такой как «Fabrikam \ jeffsmith».

3. Отличительное имя, такое как «CN = Jeff Smith, OU = Sales, DC = Fabrikam, DC = Com». Для использования DN параметр lnReserved должен быть равен нулю или должен содержать флаг ADS_USE_SSL

4. Имя пользователя (UPN), например, «jeffsmith@Fabrikam.com». Чтобы использовать UPN, вы должны назначить соответствующее значение UPN для атрибута userPrincipalName целевого пользовательского объекта.

Вы установив флаг SSL, поэтому вы должны использовать 2, 3 или 4.

P.S. В вашем примере кода вы указываете DNS-имя домена в конструкторе. Если вы указываете сервер в своем реальном коде, вам нужно добавить флаг ServerBind.