Bugs
Values for a binary data type attribute are not returned (by confirming import) when exported to Identity Broker from ILM 2007 FP1
Values exported successfully to the "objectSid" attribute (binary data type) of the person object from ILM are not being returned in a subsequent delta import, nor are they returning in a full import either.
The purpose of using this data type is that it is the native data type for the AD objectSid (unique directory identifier), ensuring a guaranteed match via a direct join rule and attribute flow.
I have implemented a work-around using the "objectGUID" attribute (also binary data type in AD and in the ILM metaverse, but a guid data type in Identity Broker. The downside of this work-around is that rules extension logic is required to convert byte arrays to guids, via string data types in the ILM MA CS. This is quite convoluted and while it works, the use of objectSid would be far preferable (simpler to maintain and troubleshoot).
I first witnessed this behaviour (which I believe to be a bug) in Identity Broker 3.0.0, and upgrading to 3.0.5 has made no difference. Please escalate this to the UNIFY PG for prioritisation.
Customer support service by UserEcho
Adam,
Not sure if this one is still hanging around to be considered for next version.
Yes, we'll have to take a look at this one at an appropriate time.
Thanks.
Please start with an initial analysis to determine what the most appropriate solution might be.
Testing with SharePoint 2010 SID value. Representation in database appears to be correct (saved under the "ImageValue" column). Management Studio displays this as "System.Byte[]", however. This could possibly also be happening in the exported LDIF.
ToString was not properly implemented. This led to a number of updates to the BinaryValue type, LDIF processing, and unit testing of value types. Reading and writing has been unit tested. Marked as resolved, to be confirmed by an engine test
Closed.
Covered by 5.1 in the regression test document