UNIFYBroker/Microsoft Identity Manager Attribute Types and Reference Attributes
Type Mapping
UNIFYBroker's expansive schema allows for the definition of a flexible set of attributes in the Microsoft Identity Manager management agent. Below is a table showing the mapping of UNIFYBroker types to MIM types.
| UNIFYBroker Type | MIM Type |
|---|---|
|
Date Decimal Double Guid Single String Time Timestamp |
String |
|
Byte Integer Long Short |
Number |
| Binary | Binary |
| Boolean | Boolean |
| DN | Reference |
Depending on the expectations of the target system, Guid may also be mapped to a binary.
UNIFYBroker may also convert string attributes in MIM to most types, including reference attributes. This may be used to emulate referencing and memberships without requiring the object to exist in the connector space as is usually required.
INFO: The UNIFYBroker types Date and Timestamp send over LDAP in Generalized Time format.
Considerations for Reference Attributes
Implementers need to be wary of the use of and changes to the distinguished names of objects. The following should be considered:
- Introducing a container that contains different casing to objects already existing in the connector space can result in large amounts of recalculation on the Referential Updates step of a sync, and can produce undesirable results.
- For a reference attribute to correctly resolve in the metaverse, the object must exist with the referenced DN in the same management agent as it is first referred to. In other words, if CN=101 has a manager CN=102 and an entitlement CN=HRAccess101,CN=Entitlement, both the manager and the entitlement object must exist in the connector space for the reference to resolve
- In some systems, employees in the highest location in the hierarchy will contain a reference to themselves (ie. they are marked in HR as being their own manager). This should be kept in mind if advanced synchronization logic is attempting to determine or use hierarchy.
Self-Referencing Issue
In situations where a management agent is required to export entities which contain references to other entities within the same space, issues may arise. This is due to how MIM calculates reference values on multiple passes. The first pass sends a request to create the entity in the UNIFYBroker adapter, then the second pass sends an update request adding the resolved reference DN to the entity. If the DN attribute in UNIFYBroker is flagged as Required then the initial add requests without the required field will fail. If not required, the second pass update request will fail as not enough time has passed for the newly created entity to be reflected to the adapter.
The current workaround for this issue is to ensure that the self-referencing DN attributes are not flagged as Required and to run the MIM Export operation a second time after a short window.
Implementers need to be wary of the use of and changes to the distinguished names of objects. The following should be considered:
- Introducing a container that contains different casing to objects already existing in the connector space can result in large amounts of recalculation on the Referential Updates step of a sync, and can produce undesirable results.
- For a reference attribute to correctly resolve in the metaverse, the object must exist with the referenced DN in the same management agent as it is first referred to. In other words, if CN=101 has a manager CN=102 and an entitlement CN=HRAccess101,CN=Entitlement, both the manager and the entitlement object must exist in the connector space for the reference to resolve
- MIM calculates reference values on multiple passes, and requires the target object to exist in the space it is passing the value to. While this appears to succeed when viewing the user in the connector space, at times it does not correctly resolve self-references when exporting entities. This results in an object being passed to UNIFYBroker with the reference field empty. This issue is best resolved by dereferencing the source attribute. This is as simple as opening the management agent in question, browsing to the Configure Attributes tab, and changing the attribute from a Reference type to a string type. This forces MIM to correctly calculate the reference, while the reference will still be correctly resolved in UNIFYBroker and the target system.
- In some systems, employees in the highest location in the hierarchy will contain a reference to themselves (ie. they are marked in HR as being their own manager). This should be kept in mind if advanced synchronization logic is attempting to determine or use hierarchy.
Multivalue Attributes
Version 5.0+
UNIFYBroker multivalue attribute types can be directly mapped to MIM attribute types with two exceptions:
- UNIFYBroker supports multivalue boolean attributes, however MIM does not.
- MIM supports multivalue binary attributes, however UNIFYBroker does not.
Customer support service by UserEcho
