Назад | Перейти на главную страницу

Фильтр ISAPI с LDAP через SSL работает только как администратор

Я создал фильтр 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

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