UNIFYBroker/Microsoft Identity Manager Containers
Containers
As with all management agents which use a distinguished name anchor, the UNIFYBroker Management Agent utilizes container objects to represent hierarchy object. Any object in the connector space must be supported by its parent hierarchy object.
Containers on Import
When a object is created from an Full or Delta Import operation, any supporting hierarchy objects are automatically generated. Empty containers will be imported only when configuration is correct, see Configuration for details.
For example, if an object CN=100,OU=Users,DC=IdentityBroker is imported to an empty connector space, the following container objects will be created:
- DC=IdentityBroker
- OU=Users,DC=IdentityBroker
If another object CN=kjones,OU=Clients,DC=IdentityBroker is imported, then only the following container object will be created.
- OU=Clients,DC=IdentityBroker
Containers on Provision
When provisioning objects to a management agent connector space, supporting container objects are not created automatically. However, the UNIFYBroker management agent can import container objects if the hierarchy exists in UNIFYBroker.
If the management agent is correctly configured, a Full Import run against an adapter, even if empty, will query UNIFYBroker for container objects and add them to the connector space. Hierarchy objects which are not known to UNIFYBroker cannot be created in this way and must be created during provisioning.
Changes to Container Hierarchy
New container objects and changes to existing container objects cause MIM to reevaluate all objects and reference values in its connector space on its referential update step. As such, changes at this level may introduce delays as MIM recalculates these references. Keep this in mind prior to the reconfiguration of Distinguished Name generators of adapters.
Issues can be introduced if multiple containers are added to the connector space with different casing.
Management agents are created with an additional object class known as a container. As with all management agents using a distinguished name, container objects are required and represent objects that are higher up in the hierarchy. UNIFYBroker will check all present distinguished names during an adapter import, and extract all container information.
Containers are a concept required by the management agent's connector space. Consequentially Composite Adapters will share container information, and it is possible for cross-references between multiple object classes to resolve correctly as a result. Moreover, provisioning attempts made to a management agent will not succeed if the container components do not yet exist for the provisioned distinguished name.
For example, if a user CN=9001,OU=Users,DC=UNIFYDomain,DC=net is imported, the following container objects will additionally be created:
OU=Users,DC=UNIFYDomain,DC=net
DC=UNIFYDomain,DC=net
DC=net
If distinguished names are configured to generate items that already exist in the adapter, these will be referenced instead of creating a new container object. In the above example, if an object CN=SubUser,CN=9001,OU=Users,DC=UNIFYDomain,DC=net existed in the same adapter or composite adapter as CN=9001,OU=Users,DC=UNIFYDomain,DC=net, a container of the same name would not be abstracted.
New container objects and changes to existing container objects cause MIM to reevaluate all objects and reference values in its connector space on its referential update step. As such, changes at this level may introduce delays as MIM recalculates these references. Keep this in mind prior to the reconfiguration of Distinguished Name generators of adapters.
Issues can be introduced if multiple containers are added to the connector space with different casing.
Customer support service by UserEcho
