Я создал фильтр ISAPI для IIS 6.0, который пытается аутентифицироваться в Active Directory с помощью LDAP. Фильтр отлично работает при регулярной аутентификации через порт 389, но когда я пытаюсь использовать SSL, я всегда получаю 0x51 Server Down
ошибка в ldap_connect()
вызов. Даже пропуская вызов подключения и используя ldap_simple_bind_s()
приводит к той же ошибке.
Странно то, что если я изменю идентификатор пула приложений на учетную запись локального администратора, тогда фильтр будет работать нормально и LDAP через SSL будет успешным. Я создал exe с тем же кодом ниже и запустил его на сервере как администратор, и он работает. Кажется, проблема заключается в использовании идентификатора NETWORK SERVICE по умолчанию для пула приложений сайта. Есть мысли по поводу происходящего? Я хочу использовать идентификатор по умолчанию, поскольку не хочу, чтобы у веб-сайта были повышенные права администратора.
Сервер находится в DMZ за пределами сети и домена, где находятся наши контроллеры домена, на которых выполняется AD. У нас также есть действующий сертификат на наших контроллерах домена для AD.
Код:
// Initialize LDAP connection
LDAP * ldap = ldap_sslinit(servers, LDAP_SSL_PORT, 1);
ULONG version = LDAP_VERSION3;
if (ldap == NULL)
{
strcpy(error_msg, ldap_err2string(LdapGetLastError()));
valid_user = false;
}
else
{
// Set LDAP options
ldap_set_option(ldap, LDAP_OPT_PROTOCOL_VERSION, (void *) &version);
ldap_set_option(ldap, LDAP_OPT_SSL, LDAP_OPT_ON);
// Make the connection
ldap_response = ldap_connect(ldap, NULL); // <-- Error occurs here!
// Bind and continue...
}
ОБНОВИТЬ: Я создал нового пользователя без прав администратора и запустил тестовый exe как новый пользователь, и я получил то же самое Server Down
ошибка. Я добавил пользователя в группу администраторов и получил ту же ошибку. Единственный пользователь, который работает с аутентификацией LDAP поверх SSL на этом конкретном сервере, - это администратор.
Веб-сервер с фильтром ISAPI (на котором я запускал тестовый exe) работает под управлением Windows Server 2003. Контроллеры домена с AD работают под управлением 2008 R2.
Также стоит упомянуть, что у нас есть сайт WordPress на том же сервере, который аутентифицируется по LDAP через SSL с использованием PHP (OpenLDAP), и здесь нет никаких проблем. У меня есть файл ldap.conf, в котором указано TLS_REQCERT never
а пользователь, выполняющий код PHP, - IUSR.
Убедитесь, что сбойный пользователь доверяет центру сертификации вашего сервера ldap.
Для этого войдите в систему как пользователь, у которого произошел сбой (возможно, вам придется предоставить временные привилегии для этого, возможно, поместите его в группу «Удаленный рабочий стол»). Начало certmgr.msc
и найдите центр сертификации, который вы используете, в разделе «Доверенные корневые центры сертификации».
Сравните то, что вы видите, с тем, что находится в учетной записи администратора.
Я считаю, что у вас проблема с магазином доверия.
Посмотри пожалуйста http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_cmuncertstor.mspx?mfr=true
Примерный способ проверки этого может заключаться в различии текстового вывода при печати содержимого хранилища сертификатов.