ActiveDirectory error 0x8000500c when traversing p

问题:

I got the following snippet (SomeName/SomeDomain contains real values in my code)

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

It prints OK for the first 21 properties, but then fail with:

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

Why? How can I prevent it?

Update

It's a custom attribute that fails.

I've tried to use entry.RefreshCache() and entry.RefreshCache(new[]{"theAttributeName"}) before enumerating the properties (which didn't help).

Update2

entry.InvokeGet("theAttributeName") works (and without RefreshCache).

Can someone explain why?

Update3

It works if I supply the FQDN to the item: LDAP://srv00014.ssab.com/CN=SomeName,xxxx

Bounty

I'm looking for an answer which addresses the following:

• Why entry.Properties["customAttributeName"] fails with the mentioned exception
• Why entry.InvokeGet("customAttributeName") works
• The cause of the exception
• How to get both working

回答1:

If one wants to access a custom attribute from a machine that is not part of the domain where the custom attribute resides (the credentials of the logged in user don't matter) one needs to pass the fully qualified name of the object is trying to access otherwise the schema cache on the client machine is not properly refreshed, nevermind all the schema.refresh() calls you make

Found here. This sounds like your problem, given the updates made to the question.

回答2:

Using the Err.exe tool here

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

It spits out:
for hex 0x8000500c / decimal -2147463156 :
E_ADS_CANT_CONVERT_DATATYPE adserr.h
The directory datatype cannot be converted to/from a native
DS datatype
1 matches found for "0x8000500c"

Googled "The directory datatype cannot be converted to/from a native" and found this KB: http://support.microsoft.com/kb/907462

回答3:

I have the same failure. I´m read and saw a lot of questions about the error 0x8000500c by listing attribute from a DirectoryEntry. I could see, with the Process Monitor (Sysinternals), that my process has read a schema file. This schema file is saved under C:\Users\xxxx\AppData\Local\Microsoft\Windows\SchCache\xyz.sch.

Remove this file and the program works fine :)

回答4:

I just encountered the issue and mine was with a web application. I had this bit of code which pulls the user out of windows authentication in IIS and pulls their info from 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;
    }
}

This worked fine in my tests, but when I published the website it would come up with this error on FindByIdentity call.

I fixed the issue by using correct user for the app-pool of the website. As soon as I fixed that, this started working.

回答5:

I had the same problem with a custom attribute of a weird data type. I had a utility program that would extract the value, but some more structured code in a service that would not.

The utility was working directly with a SearchResult object, while the service was using a DirectoryEntry.

It distilled out to this.

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
}

My gut feel is that the SearchResult is a little less of an enforcer and returns back whatever it has.

When this is converted to a DirectoryEntry, this code munges the weird data type so that even InvokeGet fails.

My actual extraction code with the extra [0] looks like:

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

I picked up the second line from another posting on the site.