Provider Specific Attributes
We discussed the approach to read ALL the attributes from an Active Directory object (or an object in any other LDAP directory) in the SelfADSI article 'Reading LDAP Directory Object Attributes'. The data returned with the appropriate methods can be processed in a script.
Anyhow, there is a problem when the regarding directory server returns an attribute with the ADSI data type 'provider specific'. This is never the case in Active Directory environments, but can be seen often when you try to access a Novell eDirectory or another LDAP system which defines it's own attribute syntaxes.
If an LDAP server returns the data type 'Provider Specific', the term should better be 'attribute data type cannot clearly identified by the script'. It's difficult to read the values of such attributes (it's strange that you don't have problems to write these values in most cases). If you attempt the access with normal read methods (like Get or GetEx), you will probably get this error return code:
0x8000500C - "The Active Directory datatype cannot be converted to/from a native DS datatype"
All you can do here is to evaluate the regarding LDAP directory schema - and we need a particular method to convert the data in a format which can be handled in a script. To achieve this, you read the attribute data into the local property cache for the connected directory object. This cache is filled with the ADSI method GetInfo and can be accessed later on with the GetPropertyItem function. This function allows you to specify the data format for the regarding values within certain limits. A reasonable approach would be to always read the data in the LDAP syntax octet string and convert it into any other format afterwards.
The result: The binary raw data is first displayed as a pure hex string, after that a second output shows it like it would be in a hex editor, the last output is pure ASCII text:
In Active Directory environments, attribute values should NEVER be returned in the format 'Provider specific' by the server. If this is the case, there has to be a malfunction of the regarding domain controller or in the ADSI interface. In other directory services environments (like eDirectory), you may encounter these provider specific attributes some times.