Ошибка ActiveDirectory 0x8000500c при обходе свойств - PullRequest
Новая
       5

Ошибка ActiveDirectory 0x8000500c при обходе свойств

5 голосов
/ 16 марта 2012

Я получил следующий фрагмент (SomeName / SomeDomain содержит реальные значения в моем коде) 

var entry = new DirectoryEntry("LDAP://CN=SomeName,OU=All Groups,dc=SomeDomain,dc=com");
foreach (object property in entry.Properties)
{
    Console.WriteLine(property);
}

Он печатает ОК для первых 21 свойств, но затем завершается ошибкой: 

COMException {"Unknown error (0x8000500c)"}
   at System.DirectoryServices.PropertyValueCollection.PopulateList()
   at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
   at System.DirectoryServices.PropertyCollection.PropertyEnumerator.get_Entry()
   at System.DirectoryServices.PropertyCollection.PropertyEnumerator.get_Current()
   at ActiveDirectory.Tests.IntegrationTests.ObjectFactoryTests.TestMethod1() in MyTests.cs:line 22

Почему?Как я могу предотвратить это?

Обновление

Это пользовательский атрибут, который не работает.

Я пытался использовать entry.RefreshCache() и entry.RefreshCache(new[]{"theAttributeName"}) перед перечислением свойств (которые не помогли).

Update2

entry.InvokeGet("theAttributeName") работает (и без RefreshCache).

Может кто-нибудь объяснить, почему?

Обновление3

Это работает, если я поставлю полное доменное имя для элемента: LDAP://srv00014.ssab.com/CN=SomeName,xxxx

Bounty

Я ищу ответ, который касается следующего:

  • Почему entry.Properties["customAttributeName"] не удается с упомянутым исключением
  • Почему entry.InvokeGet("customAttributeName") работает
  • Причина исключения
  • Как заставить работать оба

Ответы [ 5 ]

3 голосов
/ 25 марта 2012

Если кто-то хочет получить доступ к пользовательскому атрибуту с машины, которая не часть домена, где находится пользовательский атрибут (учетные данные вошедшего в систему пользователя не имеет значения) нужно пройти полностью квалифицированное имя объекта пытается получить доступ к схеме кеш на клиентском компьютере не обновляется должным образом, не обращайте внимания на все вызовы schema.refresh (), которые вы делаете

Найдено здесь . Это звучит как ваша проблема, учитывая обновления, внесенные в вопрос.

3 голосов
/ 21 марта 2012

Использование инструмента Err.exe здесь

http://www.microsoft.com/download/en/details.aspx?id=985

Выплевывает:
для шестнадцатеричного 0x8000500c / десятичное -2147463156:
E_ADS_CANT_CONVERT_DATATYPE adserr.h
Тип данных каталога не может быть преобразован в / из собственного
Тип данных DS
1 совпадений найдено для "0x8000500c"

Googled "Тип данных каталога не может быть преобразован в / из собственного" и найден этот KB: http://support.microsoft.com/kb/907462

1 голос
/ 02 июля 2014

У меня такая же ошибка. Я прочитал и увидел много вопросов об ошибке 0x8000500c, перечислив атрибут из DirectoryEntry. С помощью Process Monitor (Sysinternals) я мог видеть, что мой процесс прочитал файл схемы. Этот файл схемы сохраняется в C: \ Users \ хххх \ AppData \ Local \ Microsoft \ Windows \ SchCache \ xyz.sch

.

Удалите этот файл и программа отлично работает:)

0 голосов
/ 18 апреля 2018

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

Утилита работала напрямую с объектом SearchResult, когда служба использовала DirectoryEntry.

Это перегоняется к этому. 

SearchResult result;

result.Properties[customProp];     // might work for you
result.Properties[customProp][0];  // works for me. see below

using (DirectoryEntry entry = result.GetDirectoryEntry())
{
    entry.Properties[customProp]; // fails
    entry.InvokeGet(customProp);  // fails as well for the weird data
}

Мне кажется, что SearchResult немного менее эффективен и возвращает обратно все, что у него есть.

Когда это преобразовывается в DirectoryEntry, этот код смешивает странный тип данных, так что даже InvokeGet дает сбой.

Мой фактический код извлечения с дополнительным [0] выглядит так: 

byte[] bytes = (byte[])((result.Properties[customProp][0]));
String customValue = System.Text.Encoding.UTF8.GetString(bytes);

Я взял вторую строку из другой публикации на сайте.

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

Я только что столкнулся с проблемой, и моя была с веб-приложением.У меня был этот фрагмент кода, который выводит пользователя из проверки подлинности Windows в IIS и извлекает их информацию из AD. 

using (var context = new PrincipalContext(ContextType.Domain))
{
    var name = UserPrincipal.Current.DisplayName;
    var principal = UserPrincipal.FindByIdentity(context, this.user.Identity.Name);
    if (principal != null)
    {
        this.fullName = principal.GivenName + " " + principal.Surname;
    }
    else
    {
        this.fullName = string.Empty;
    }
}

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

Я исправил проблему, используя правильного пользователя для пула приложений на веб-сайте.Как только я это исправил, все заработало.

...