Ошибка 0x80005000 и DirectoryServices - PullRequest
39 голосов
/ 12 ноября 2009

Я пытаюсь выполнить простой запрос LDAP, используя службы каталогов в .Net.

    DirectoryEntry directoryEntry = new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com");
    directoryEntry.AuthenticationType = AuthenticationTypes.Secure;

    DirectorySearcher directorySearcher = new DirectorySearcher(directoryEntry);

    directorySearcher.Filter = string.Format("(&(objectClass=user)(objectCategory=user) (sAMAccountName={0}))", username);

    var result = directorySearcher.FindOne();
    var resultDirectoryEntry = result.GetDirectoryEntry();

    return resultDirectoryEntry.Properties["msRTCSIP-PrimaryUserAddress"].Value.ToString();

И я получаю следующее исключение:

System.Runtime.InteropServices.COMException (0x80005000): Unknown error (0x80005000)
  at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
  at System.DirectoryServices.DirectoryEntry.Bind()
  at System.DirectoryServices.DirectoryEntry.get_AdsObject()
  at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne)
  at System.DirectoryServices.DirectorySearcher.FindOne()

Как фрагмент в Консольном приложении, это работает. Но когда я запускаю его как часть службы WCF (работающей с теми же учетными данными), он генерирует указанное выше исключение.

Есть предложения?

Спасибо

Ответы [ 11 ]

87 голосов
/ 11 апреля 2012

У меня было то же самое снова и снова, и ничто, казалось, не помогало.

Смена пути с ldap:// на LDAP:// сделала свое дело.

31 голосов
/ 12 ноября 2009

Это проблема с разрешением.

Когда вы запускаете консольное приложение, оно запускается с вашими учетными данными, например, как "ты".

Служба WCF работает где? В IIS? Скорее всего, он работает под отдельной учетной записью, которой не разрешено запрашивать Active Directory.

Вы можете либо попытаться заставить олицетворение WCF работать, чтобы передать ваши собственные учетные данные, либо указать имя пользователя / пароль при создании DirectoryEntry:

DirectoryEntry directoryEntry = 
    new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com", 
                       userName, password);

ОК, так что в конце концов это могут быть не учетные данные (как правило, это более чем в 80% случаев, которые я вижу).

Как насчет того, чтобы немного изменить свой код?

DirectorySearcher directorySearcher = new DirectorySearcher(directoryEntry);
directorySearcher.Filter = string.Format("(&(objectClass=user)(objectCategory=user) (sAMAccountName={0}))", username);

directorySearcher.PropertiesToLoad.Add("msRTCSIP-PrimaryUserAddress");

var result = directorySearcher.FindOne();

if(result != null)
{
   if(result.Properties["msRTCSIP-PrimaryUserAddress"] != null)
   {
      var resultValue = result.Properties["msRTCSIP-PrimaryUserAddress"][0];
   }
}

Моя идея такова: почему бы не сказать DirectorySearcher сразу, какой атрибут вас интересует? Тогда вам не нужно делать еще один дополнительный шаг, чтобы получить полную DirectoryEntry из результата поиска (должно быть быстрее), и, поскольку вы сказали поисковику каталогов найти это свойство, оно, безусловно, будет загружено в результат поиска. - поэтому, если оно не равно нулю (значение не установлено), вы сможете легко его получить.

Марк

17 голосов
/ 01 июля 2014

В контексте Ektron эта проблема решается путем установки в Windows функции «Совместимость с метабазой IIS6»:

Проверьте «Функции Windows» или «Ролевые службы» для метабазы ​​IIS6. совместимость, добавьте, если отсутствует:

enter image description here

Ссылка: https://portal.ektron.com/KB/1088/

10 голосов
/ 22 января 2015

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

BAD:

DirectoryEntry directoryEntry = 
    new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com/", 
                       userName, password);

GOOD

DirectoryEntry directoryEntry = 
    new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com", 
                       userName, password);
7 голосов
/ 23 ноября 2011

У меня также была эта ошибка, и для меня это была OU с косой чертой в имени: «Группы доступа к файлам / папкам».

Эта ветка форума указала мне в правильном направлении. В конце концов, вызов .Replace("/","\\/") для каждого значения пути перед использованием решил проблему для меня.

5 голосов
/ 20 декабря 2017

На сайтах, размещенных в IIS, попробуйте перезапустить пул приложений. Это исправило мою проблему. Спасибо

3 голосов
/ 14 июля 2015

Только что возникла эта проблема в производственной системе в компании, где я живу ... Веб-страница, на которой привязка LDAP перестала работать после изменения IP.

Решение ... ... Я установил базовую аутентификацию для устранения неисправностей, указанных здесь: https://support.microsoft.com/en-us/kb/329986

И после этого все только начало работать. Даже после того, как я снова отключил базовую аутентификацию на странице, которую я тестировал, все остальные страницы снова начали работать с аутентификацией Windows.

С уважением, Acácio

3 голосов
/ 12 марта 2011

Просто к вашему сведению, у меня была та же ошибка, и я использовал правильные учетные данные, но мой URL-адрес LDAP был неправильным: (

Я получил точно такое же сообщение об ошибке и код

1 голос
/ 23 июня 2017

Эта ошибка может возникать, если на физическом компьютере недостаточно памяти. В моем случае я размещал сайт на IIS, пытаясь получить доступ к AD, но серверу не хватило памяти.

0 голосов
/ 09 июня 2017

Потратил день на мою похожую проблему, но все эти ответы не помогли.

Оказалось, что в моем случае я не включил проверку подлинности Windows в настройках IIS ...

...