Почему при аутентификации по LDAP с DirectoryEntry периодически возникает исключение COMException (0x8007203A): «Сервер не работает»? - PullRequest
7 голосов
/ 21 июля 2009

Если у кого-то есть похожая история, пожалуйста, опубликуйте подробности ниже!

Я создаю веб-сайт ASP.NET, который должен поддерживать аутентификацию по LDAP.

В Windows аутентификация LDAP может выполняться через Active Directory (я не эксперт, но AD, кажется, просто особый вариант ldap). Я не управляю серверами AD и / или LDAP.

Я пробовал различные способы аутентификации, но я остановился на использовании одного DirectoryEntry для каждой попытки аутентификации:

using (DirectoryEntry de = new DirectoryEntry(ldapPath, ldapUsername, password, AuthenticationTypes.ServerBind)) {
    try {
        // Bind to the native AdsObject to force authentication.
        object obj = de.NativeObject;//not IDisposable
    } catch(...

Извлечение NativeObject вызывает COMException, если что-то пойдет не так, например, если аутентификация не удалась, исключение напоминает «Ошибка входа в систему: неизвестное имя пользователя или неверный пароль», и если сервер ldap недоступен или время что-то вроде «Сервер не работает.»

В принципе, это работает, но через переменное количество дней, которое всегда запускается первым утром, мы получаем «Сервер не работает». пока IIS не будет перезапущен. Очевидно, что это не очень хорошее долгосрочное решение, но, насколько я могу судить, ошибка кроется в Com-объекте, лежащем в основе DirectoryEntry, а не в том, что легко исправить.

Эта проблема не новая или неизвестная . Некоторые люди прошли через поддержку Microsoft со смешанными результатами; в основном ответы, похоже, сводятся к тому, чтобы «выбрать путь ldap и создать несколько эквивалентных альтернатив, и, возможно, один из них сработает». Каждый раз, когда вы пытаетесь или, конечно, в течение нескольких дней вы не узнаете, действительно ли это сработало, и пока не будет найдено реальное решение, мы вернемся к «перезагрузке Windows-серверов каждую ночь».

Для начала я попробовал пути ldap в формате

* "LDAP://server.uri:636"
* "LDAP://insecure.server.uri:389"
* "LDAP://server.uri:636/cn=username,ou=staff,o=myOrganisation,c=org"

Всегда с именем пользователя со следующим шаблоном:

* "cn=username,ou=staff,o=myOrganisation,c=org"

Все эти методы вначале работают, но перестают работать через переменное количество дней (и начинают работать после сброса IIS). Сервер работает под управлением IIS6 на win 2k3.

Если у кого-то еще есть такие проблемы, пожалуйста, напишите ниже, и, возможно, в конечном итоге мы найдем шаблон для работы или у нас будет достаточное количество примеров, чтобы убедить Microsoft исправить это.

Ответы [ 3 ]

5 голосов
/ 26 августа 2009

Хотя я не могу точно определить причину этой проблемы, похоже, что она прекратилась после перехода на некластерный сервер.

Есть и другие странные факты об этой ошибке:

  • Перезапуска хост-процесса asp.net недостаточно для устранения проблемы. Это странно; можно ожидать, что ОС принудительно освободит ресурсы при смерти процесса
  • Перезапуск службы IIS не освобождает ресурсы (порты UDP). netstat показывает, что порты кажутся свободными, но все открытые порты фактически открыты процессом # 4 - системным процессом.
  • Уничтожение IIS (например, через диспетчер IIS) делает освобождение портов UDP, а затем проверка подлинности снова работает.

В целом, это очень похоже на проблему с драйвером или ядром в win2k3 с включенной кластеризацией, а не с проблемой .NET.

Итак, если кто-то еще сталкивается с подобной проблемой, проверьте, включена ли кластеризация - это может сэкономить вам недели головной боли.

1 голос
/ 26 сентября 2011

У меня была такая же проблема и я исправил ее этим методом

http://blogs.dirteam.com/blogs/tomek/archive/2007/08/09/system-directoryservices-and-connection-pooling.aspx

0 голосов
/ 26 сентября 2011

Я прочитал кое-что о проверке с помощью NETSTAT и проверке состояний активных соединений. кратные значения времени ожидания могут указывать на проблему с перенаправлением портов. Тем не менее, я получаю ту же ошибку за последние 3 дня. Я попросил администратора сети изменить мои разрешения, и даже это не помогло. Статья обсуждает это более подробно: Приложение C # .NET теряет соединение с Active Directory

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...