Understanding Deprovisioning in FIM
In FIM, the objective of the synchronization service is to provide a solution for the management of an object’s lifecycle.
Next to the creation and management of objects in an external system, this also includes stopping the management or even the deletion of them when they become obsolete.
While the term deprovisioning is often used as a synonym for the deletion of an object in an external system, it is important to note, that, in the context of the FIM synchronization engine, deprovisioning has various meanings.
In FIM, depending on the context, deprovisioning can refer to a specific process that consists of several activities or to a specific activity.
Due to the ambiguity, you should avoid using the term deprovisioning when possible.
The objective of this document is to give you an overview of what deprovisioning means in FIM.
Introduction to deprovisioning
To synchronize data between various connected data sources, you need to first build inside the synchronization service the required infrastructure that consist of connector space (CS) and metaverse (MV) objects and link relationships between these objects.
The infrastructure is comparable to a rail network with the connector space and metaverse objects as stations and the links as the tracks that are used to flow data.
The following picture shows an example for this:
In the FIM terminology, a connector space object, if it is linked to a metaverse object is known as connector and disconnector if it is not linked.
There are cases where you don’t want to manage an object in an external system anymore.
This is, for example, necessary, when the authoritative source for an object does not exist anymore.
If your business requirement dictates that all HR account should also have an account in your Active Directory, you might also have a requirement to delete Active Directory accounts, when the authoritative HR account has been terminated.
When you need to remove the link relationship to a target connector space object in response to a changed condition, you need to involve the deprovisioning process.
Understanding the deprovisioning process requires a basic understanding of the synchronization process and how the synchronization service responds to a condition.
In FIM, the synchronization process consists of two distinct phases called inbound synchronization and outbound synchronization.
The following illustration outlines this process:
During the inbound synchronization phase, the data that is staged on a connector space is processed toward the metaverse according to the configuration of your synchronization rules.
If the inbound synchronization phase results in updates to the metaverse, the outbound synchronization phase is invoked.
In other words, the inbound synchronization phase handled the CS to MV transition and the outbound synchronization phase handles the MV to CS transition.
Dividing the synchronization process into two phases is necessary because a CS object can only contribute data to a single MV object.
However, applied changes to a single metaverse object may have to be distributed to several CS objects.
In the context of the synchronization process, the deprovisioning process is part of the outbound synchronization phase and consists of two components, a deprovisioning action and a deprovisioning reaction.
The deprovisioning action is implemented in form of a link removal between MV and a CS object during the outbound synchronization phase and the deprovisioning reaction is the configured response to it.
The first option you have to trigger the deprovisioning action is to delete the metaverse object of a connector as outlined in the following illustration:
If a MV object is deleted, the link relationships to its connectors are also deleted:
In FIM, the deletion of metaverse objects is handled by the object deletion rule.
The second option you have to trigger the deprovisioning action is to trigger the link removal by using an outbound synchronization rule.
Outbound synchronization rules have an option you can set to enable deprovisioning.
When you select this option, the target CS object is disconnected from the MV object when the related object is removed from the scope of the outbound synchronization rule.
The following screenshot shows the related option of an outbound synchronization rule:
Initiating deprovisioning by using the object deletion rule is the right method to handle cases where all authoritative contributors have been disconnected from a MV object.
In this case, there is no need to keep the MV object.
For example, if you have an Active Directory that is populated based on accounts in a HR database and you need the Active Directory accounts that are linked to a HR account to be deleted when a connector from the HR database has been removed, you can use the object deletion rule to handle this case.
In this case, you configure the object deletion rule to delete a MV object when a connector from the HR management agent has been removed.
Using a synchronization rule to initiate the deprovisioning process is the right method when you need to disconnect a MV object from a non-authoritative target.
For example, if you have an Active Directory management agent that doesn’t function as an identity data contributor and the authoritative source object doesn’t meet the requirements for having an Active Directory connector anymore, you can use the deprovisioning setting in a synchronization rule to disconnect the object.
The deprovisioning reaction is a setting you configure per management agent.
The Management Agent Designer has a related configuration page in the Configure Deprovisioning section that you use to configure the deprovisioning reaction.
The following screenshot shows the related dialog page:
The object deletion rule, the deprovisioning setting in an outbound synchronization rule and the deprovisioning setting in the configuration of a management agent represent the configurable options you need to configure to define your deprovisioning implementation in your environment.
While the first two settings are related to the deprovisioning trigger, the last option is used to define the response of your system.
The following sections provide more details about these settings.
Initiating deprovisioning by using the object deletion rule
When the object deletion rule deletes a metaverse object, the link relationship between the metaverse object and all linked connector space objects is removed and the deprovisioning process is initiated.
The default configuration of this rule is to delete a metaverse object when the last connector has been disconnected.
The rule provides additional options that enable you to customize the metaverse object deletion behavior; however, regardless of your current configuration of the object deletion rule, the default behavior always supersedes your current configuration.
This is because identity data synchronization always requires at least one authoritative contributor.
Without a contributor there is no data that can be synchronized anymore.
In other words, a metaverse object is always automatically deleted when the last connect to it has been removed during a synchronization cycle.
The following screenshot shows the related dialog of the object deletion rule in the Synchronization Manager.
To customize the behavior of the object deletion rule, you can configure three different options:
Delete a metaverse object when the last connector is removed – As mentioned previously, a metaverse object is always deleted when the last connector has been removed.
In addition to this, you can select management agents the synchronization service should ignore for this option.
In other words, if a connector was removed from a MV object, which was not the last connector but the remaining connectors are on the list of ignorable management agents, the removed connector is considered to be the last connector.
This configuration setting helps to address scenarios, in which you have more than one authoritative source management agent and one of the following conditions is true:
- All authoritative management agents have the power to trigger the deprovisioning process
- The authority to delete a metaverse object has been transitioned from a management agent to another management agent
In an identity management scenario, it is possible to transition the ownership for MV object between management agents. For example, when a scenario includes an Active Directory Domain Services management agent, it is a common best practice to move an account for a grace period into a separate Organizational Unit before it is actually deleted.
The deprovisioning process for the Active Directory Domain Services (ADDS) account spans in this case the complete timeframe from moving the account into this container to the actual deletion.
The deprovisioning trigger is in this scenario defined by the decommissioned HR record. Because the HR connector is in this scenario gone and you still need to manage the affected ADDS connector, the ownership for the MV object needs to be transitioned to a different management agent.
Typically, the ownership is in this case transitioned to the FIM management agent, because FIM provides the required logic for timed events.
The following illustration shows an initialized scenario:
In this scenario, the disconnection of the HR connector is no sufficient trigger to delete the affected metaverse object.
The only safe deletion decision is the case when all connectors from the authoritative management agents are gone.
If a metaverse object only has connectors to non-authoritative management agents, it can be safely deleted.
This is why the target management agents should be on the list of ignored management agents for this configuration option.
Delete a metaverse object when a connector from specific management agent is removed – This option is useful when you have several authoritative management agents and removing a connector from one of them is sufficient to make a metaverse object deletion decision.
For example, if your fulltime employees are managed in an HR database and your contractors are managed in the FIM portal and a linked Active Directory account that is supposed to be immediately deleted when either a full time employee or a contractor has been removed, you can use this option to handle this case.
The following illustration shows an example for this case:
Rules Extension – If you have a scenario, in which a decision for a metaverse object deletion cannot be efficiently answered by the two declarative options, you can implement your deletion decision in a rules extension.
This is, for example, necessary if the deletion decision is based on an attribute value of the disconnected connector space object or the affected metaverse object.
The related method is called ShouldDeleteFromMV and has a CSEntry and a MVEntry as parameters.
For more information about this function, see ShouldDeleteFromMV Method.
Determining the right configuration of your object deletion rule requires careful planning.
As you have learned in this section, there are scenarios, in which the ownership can transition between management agents.
In other words, the disconnection from the originator is not always sufficient as criterion to delete a metaverse object.
In general, you should only configure the object deletion rule if there is no need to manage an identity anymore.
Initiating deprovisioning by using a synchronization rule
In addition to the deletion of a metaverse object by the object deletion rule, you can also initiate the deprovisioning process by using a synchronization rule.
To manage an object by using FIM, you need to bring the object into the scope of a synchronization rule.
When you bring a resource into the scope of a synchronization rule, a relationship between the resource and the synchronization rule is established in form of an outbound synchronization triple.
The triple consists of three components:
- The Expected Rules List (ERL)attribute of the resource
- An Expected Rules Entry (ERE) object
- An outbound synchronization rule
The following illustration outlines the related architecture.
To initiate the triple creation process, you need to configure a synchronization policy that consists of the following components:
- A Set
- A Management Policy Rule
- A Workflow
- A Synchronization Rule
The following illustration outlines the architecture of a synchronization policy:
In addition to bringing a resource into the scope of a synchronization rule, you can also remove a resource from the scope of it.
Whether a synchronization policy brings a resource into the scope or removes it from the scope of a synchronization rule is defined by the action selection in the related workflow.
The following screenshot shows an example for the related configuration setting in a workflow:
As mentioned earlier in this document, when you configure a synchronization rule, you can set a flag to enable deprovisioning when a resource is removed from the scope of the synchronization rule.
When the related synchronization policy is triggered, the FIM service does not immediately remove the related outbound synchronization triple.
Instead, another triple is created.
The ERE of this triple has an action of remove.
The following screenshot shows the Provisioning configuration of an affected object:
To remove the triples from a resource, you need to synchronize the affected resource.
While a triple relationship is established by the FIM Service, the removal of it is done by the FIM synchronization service.
In other words, in case of a synchronization rule removal scenario, the FIM service requests the removal of the synchronization rule from a resource.
The actual removal has to be done by the synchronization service.
This implementation is required because the synchronization service may have to trigger the deprovisioning process, which may involve disconnecting an object.
As soon as the remove action has been synchronized, the Expected Rules List of the affected object is empty.
The following screenshot shows an example for this:
When you intend to use a synchronization rule to deprovision an object, you need to be aware of what the result of this configuration is and how FIM processes it.
The objective of this section is to give you an answer to this.
To recap, it is possible to initiate the deprovisioning process by configuring a related synchronization policy.
While the FIM service is in charge of initiating this process, the synchronization service has to complete it.
Completing deprovisioning by using the deprovisioning synchronization rule
The deprovisioning process is initiated by a link removal between a metaverse object and a connector space object during the outbound synchronization phase.
The synchronization service needs to determine what the impact of the link removal to the affected connector space object is.
You configure the reaction by setting a Deprovisioning Option.
The following screenshot shows the related dialog:
In FIM, you can configure four different deprovisioning options:
Make them disconnectors – This option keeps the affected object as disconnector in the target connector space.
A disconnector has the potential to contribute data to the metaverse again.
This means, if you run at some point a synchronization run profile on the target management agent and you have an inbound synchronization rule that is applied to this object, the disconnector has the potential to become a connector again.
You can use this option if you have a need to disconnect a connector space object from an incorrect metaverse object.
Make them explicit disconnectors – This option is similar to the previous option.
However, in this case, the connector space object is turned into an explicit disconnector.
Explicit disconnectors have no potential to become connectors again.
In other words, an existing inbound synchronization rule on the target management agent cannot bring the connector space object back into the metaverse.
You can use this option if you don’t want the object to contribute data anymore and you can also not use FIM to delete the object in the external system.
Stage a delete on the object for the next export run – When you set this option, a deletion is staged on the affected connector space object.
Setting this option does not delete the affected connector space object.
The staged deletion is pushed out as request to the external system during the next export run on the target management agent.
Determine with a rules extension – There are cases, where it is not possible to make an appropriate deprovisioning decision based on the declarative options.
In this case, you can implement a detailed decision on a rules extension.
This method is also useful if you need to set an attribute value on the disconnected object before it is disconnected.
Summary
From the FIM perspective, deprovisioning is a process that disconnects a MV object from a related CS object during the outbound synchronization phase and performs a specified action on the disconnected object.
While staging a deletion is a possible outcome of the deprovisioning process, it is not the only result of it.
When designing deprovisioning scenarios, you should avoid using the term deprovisioning to reduce ambiguity.
It is better to use terms such as disconnect, link removal or deletion to avoid confusion.
The deprovision process consists of an action and a response to it.
While the action is triggered by either the object deletion rule or a synchronization rule, the response is an activity that is defined by the affected management agent.
The response activity varies from a simple disconnect to a staged deletion.
Even in case of a staged deletion, the synchronization service does not delete objects.
Instead deletion requests are staged that need to be pushed out to an external system in form of export run profiles.
Additional Reading
For more details regarding deprovisioning, see:
Note
To provide feedback about this article, create a post on the FIM TechNet Forum.