ActiveDirectory error 0x8000500c when traversing properties

前端 未结 5 1916
北荒
北荒 2020-12-11 05:07

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

var entry = new DirectoryEntry(\"LDAP://CN=SomeNa         


        
相关标签:
5条回答
  • 2020-12-11 05:28

    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 :)

    0 讨论(0)
  • 2020-12-11 05:29

    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.

    0 讨论(0)
  • 2020-12-11 05:37

    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.

    0 讨论(0)
  • 2020-12-11 05:37

    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.

    0 讨论(0)
  • 2020-12-11 05:42

    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

    0 讨论(0)
提交回复
热议问题