Results 1 to 1 of 1

Thread: IADs::GetEx() fails with error 0x8000500C

Threaded View

  1. #1
    Join Date
    Jul 2014

    IADs::GetEx() fails with error 0x8000500C


    I'm currently working on a software project where i need to enumerate and evaluate the contents of the 'wellKnownObjects'-attribute of the Active Directory Domain container, provided by DSfW. When using the IADs::GetEx()-method (MSDN: "http://msdn.microsoft.com/en-us/library/aa746348%28v=vs.85%29.aspx") to query this attribute i get the error 0x8000500C, which translates to:
    The data type cannot be converted to/from a native DS data type.
    Verify that the correct data type is used and/or that there is sufficient schema data available to perform data type conversion.

    My environment is currently setup as follows:
    1. An eDirectory server running OES11 SP2, hosting my test eDirectory tree
    2. A second server running DSfW, which makes the test eDirectory tree behave like a Windows AD (e.g. domain name: DC=dsfw,DC=novell)
    3. A Windows 2008R2 machine, which joined the DSfW domain and will have to run some custom software

    On the Windows 2008R2 machine i run a command line tool, which basically does the following:
    1. Initialise COM-usage by calling CoInitialize
    2. ADsOpenObject("LDAP://DC=dsfw,DC=novell", ..., II_IADs, (void**) &pADsObject) (see MSDN: "http://msdn.microsoft.com/en-us/library/aa772238%28v=vs.85%29.aspx")
    3. pADsObject->GetEx(CComBSTR("wellKnownObjects"), ...)

    As result i expect a VARIANT-array containing several GUID-distinguished-name-pairs. But IADs::GetEx returns 0x8000500C. This does not happen on a native Active Directory.

    Cross checking this issue, by using other ADs-methods i was able to narrow the issue down. I used IDirectorySearch::ExecuteSearch() (MSDN: "http://msdn.microsoft.com/en-us/library/aa746365%28v=vs.85%29.aspx") to search for an object with the distinguished name "DC=dsfw,DC=novell" and queried its 'wellKnownObjects'-attribute. This succeeded so far. But when iterating through the result using the IDirectorySearch-methods GetNextRow() and GetColumn(), i found that the dwADsType-member of the result column-structure is set to ADSTYPE_PROV_SPECIFIC. In contrast, in a native Windows domain, the column dwADsType-member is set to ADSTYPE_DN_WITH_BINARY. At least for me, this explain the error "E_ADS_CANT_CONVERT_DATATYPE". I know that ADSTYPE_DN_WITH_BINARY is a Microsoft specific type. But is there a way to make DSfW to provide this ADs-type in a MS-manor?

    The issue seem pretty complex to me, so every help is pretty much appreciated. Or maybe there is already a solution, which i missed...

    Thanks for your help.

    PS: Additional information: The FindByIdentity-methods of several Principal-APIs (e.g. System.DirectoryServices.AccountManagement.GroupPr incipal) in the .NET Framework 4.0 seem utilize those methods to, as they have the same issue and throw InteropServices.COMException exceptions which correspond to the error code 0x8000500C.
    Last edited by jahei12; 10-Jul-2014 at 12:34 PM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts