Understanding Deprovisioning
Applies To: Forefront Identity Manager 2010
The purpose of the Microsoft® Forefront® Identity Manager (FIM) 2010 synchronization service is to give you a way to manage an identity object’s lifecycle. Not only does this involve creating and managing identity objects in an external system (such as Active Directory® Domain Services or Microsoft Exchange Server), it also includes ending the management of those objects or even deleting them when you no longer need them.
While the term deprovisioning is often used to mean deleting an object in an external system, it is important to note that, in the context of the FIM 2010 synchronization engine, deprovisioning has more than one meaning. This article will help you understand those various meanings. Depending on the context, deprovisioning can refer to a specific process that consists of several activities, or to a specific activity. The objective of this article is to help you understand what deprovisioning means in FIM 2010 and how it works.
Introduction to deprovisioning
If you want to synchronize data between data sources, you must first create the required infrastructure inside the synchronization. This infrastructure is made up of connector space (CS) objects, metaverse (MV) objects, and the link relationships between these objects.
The synchronization service infrastructure can be compared to a rail network: The connector space and metaverse objects are like railroad stations, while the links are like the railroad tracks that transport the data between the stations (CS and MV objects).
The following diagram shows an example of the connections between the connector space and metaverse objects that synchronize identity information between two external systems.
.jpg "FIM connector spaces and metaverse")
In FIM, a connector space object is known as a connector if it is linked to a metaverse object. If a connector space object is not linked to a metaverse object, it is known as a disconnector. There are situations in which you no longer want to use FIM to manage an object in an external system. For example, this is necessary when the authoritative source for an object no longer exists. If your business requirements dictate that all human resources (HR) accounts should also have an Active Directory Domain Services (AD DS) account, you might also have a requirement to delete the matching AD DS account when the authoritative HR account has been terminated. The deprovisioning process removes the link relationship to a target connector space object in response to a changed condition.
To understand the deprovisioning process, you need a basic understanding of the synchronization process and how the synchronization service responds to a change of condition. In FIM, the synchronization process consists of two distinct phases. These phases are called inbound synchronization and outbound synchronization.
The following diagram shows how these two phases related to each other and to FIM connector spaces and the metaverse.
.jpg "Inbound and outbound synchronization")
During the inbound synchronization phase, the data that is staged on a connector space is processed toward the metaverse by following your synchronization rules. If the inbound synchronization phase results in updates to the metaverse, the outbound synchronization phase is invoked to update the target connector space. In other words, the inbound synchronization phase handles the CS to MV transition, and the outbound synchronization phase handles the MV to CS transition. It is necessary to divide the synchronization process into two phases because a CS object can only contribute data to a single MV object. However, changes to a single metaverse object might 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 has the effect of removing the link between the metaverse and a connector space object during the outbound synchronization phase; the deprovisioning reaction is the configured response to the link being removed.
Your first option for trigging the deprovisioning action is to delete the metaverse object of a connector, as shown in the following diagram.
.jpg "Deleting metaverse object of a connector")
If a metaverse object is deleted, the link relationship to its connectors is also deleted, as this diagram shows.
.jpg "Deleted links of a deleted metaverse object")
The object deletion rule handles the deletion of metaverse objects.
Your second option for triggering the deprovisioning action is to remove a link by using an outbound synchronization rule. Outbound synchronization rules have an option that you can set to enable deprovisioning. When you select this option, the target connector space object is disconnected from the metaverse object when the related object is removed from the scope of the outbound synchronization rule.
The following illustration shows this outbound synchronization rule option in the FIM portal.
.jpg "Deprovisioning option of outbound sync rule")
When all authoritative contributors have been disconnected from a metaverse object, the correct method for launching the deprovisioning process is to use the object deletion rule to delete the metaverse object. This is because there is no longer any need to keep the metaverse object. For example, if you have AD DS accounts that are provisioned based on accounts in your HR database, and if you need to delete an AD DS account that is linked to an HR account when a connector from the HR database has been removed, you can use the object deletion rule to delete the AD DS account. In this case, you configure the object deletion rule to delete the metaverse object when a connector from the HR management agent has been removed. This, in turn, triggers the removal (deprovisioning) of the corresponding AD DS account.
On the other hand, when you need to disconnect a metaverse object from a nonauthoritative target, the correct method for launching the deprovisioning process is to use the synchronization rule. Unlike the object deletion rule, the synchronization rule preserves the metaverse object that is still connected to the authoritative connector space object. For example, if you have an AD DS management agent that doesn’t function as an identity data contributor (that is, it isn’t an authoritative source for identity data), and if the authoritative source object no longer needs to have an AD DS connector, you can use the deprovisioning setting in a synchronization rule to disconnect the object.
The deprovisioning reaction is a setting that you configure for each 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 illustration shows the dialog box page in Synchronization Service Manager that you use to configure this setting.
.jpg "Configure Deprovisioning Options dialog box")
To implement deprovisioning in your environment, you need to configure the following options:
Either the object deletion rule or the deprovisioning setting in an outbound synchronization rule
The deprovisioning setting of a management agent
While the first two settings are related to the deprovisioning trigger, you use the third setting to define the how your system responds
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 illustration shows the Configure Object Deletion Rule dialog box in Synchronization Manager.
.jpg "Configure Object Deletion Rule dialog box")
To customize the behavior of the object deletion rule, you can configure three different options:
Delete the metaverse object when the last connector is removed
Delete the metaverse object when a connector from a specific management agent is disconnected
Rules extension
The following sections explain these options and when you would use them.
Delete the metaverse object when the last connector is removed
As mentioned earlier, a metaverse object is always deleted when the last connector has been removed. In addition to this default behavior, you can select management agents that the synchronization service should ignore for this option. In other words, when a connector is removed from a metaverse object, even though it is not the last connector, you can configure the object deletion rule to delete the metaverse object if the remaining connectors are on the list of management agents that can be ignored. In this case, the removed connector is treated as though it were the last connector. This configuration setting helps to address scenarios in which you have more than one authoritative source management agent and one of these conditions is true:
All authoritative management agents can trigger the deprovisioning process.
The authority to delete a metaverse object has been transitioned from one management agent to another.
In an identity management scenario, it is possible to transition the ownership of a metaverse object between management agents. For example, when a scenario includes an AD DS management agent, it is a common best practice to move an account into a separate organizational unit for a grace period before it is actually deleted. In such a case, the deprovisioning process for the AD DS account spans the entire time from moving the account into the holding container to the actual deletion. The deprovisioning trigger is the decommissioned HR record. Because the HR connector is gone and you still need to manage the affected AD DS connector, the ownership of the metaverse object needs to be transitioned to a different management agent. Typically, the ownership is transitioned to the FIM management agent because FIM provides the required logic for timed events.
The following diagram shows an initialized scenario.
.jpg "Initialized transition of MV object ownership")
In this scenario, disconnecting the HR connector is not a sufficient trigger to delete the connected metaverse object. The only safe decision for deleting the metaverse object is when all connectors from the authoritative management agents are gone. A metaverse object can be safely deleted only when it has connectors to nonauthoritative management. This is why the target management agents should be on the list of ignored management agents for this configuration.
Delete the metaverse object when a connector from a specific management agent is disconnected
This option is useful when you have several authoritative management agents and removing a connector from one of them is sufficient to decide that a metaverse object should be deleted. For example, you can use this option if your fulltime employees are managed in an HR database, your contractors are managed in the FIM portal, and a linked AD DS account is supposed to be deleted immediately when either a fulltime employee or a contractor has been removed.
The following diagram shows an example for this case.
.jpg "Example of deleting MV object")
Rules extension
If your identity management needs are more complex and you cannot base a decision to delete a metaverse object on the basis of the two declarative options, you can implement your deletion decision in a rules extension. For example, this is necessary if the decision to delete the metaverse object is based on an attribute value of the disconnected connector space object or the corresponding metaverse object. The related method is called ShouldDeleteFromMV.For more information about this function, see ShouldDeleteFromMV Method in the MSDN library.
Determining the right configuration of your object deletion rule requires careful planning. As mentioned earlier, there are scenarios in which the ownership of a metaverse object can transition between management agents. That is, disconnecting a metaverse object from the management agent that created it is not always sufficient as the basis for deleting 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
Instead of deleting a metaverse object by using the object deletion rule, you can also initiate the deprovisioning process by using a synchronization rule. To manage an object, you 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 the 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 diagram outlines this architecture.
.jpg "Architecture of an outbound sync triple")
To begin the triple creation process, you configure a synchronization policy that consists of the following components:
A set
A management policy rule
A workflow
A synchronization rule
The following diagram outlines the architecture of a synchronization policy.
.jpg "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 a synchronization rule. Whether a synchronization policy brings a resource into the scope of a synchronization rule or removes it from the scope is defined by the action you select in the FIM portal for the related workflow.
The following illustration shows an example for the related configuration setting in a workflow.
.jpg "Example configuration for removal from scope")
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 Expected Rule Entry of this triple has an action of remove.
The following illustration shows the provisioning configuration in the FIM portal of an affected object.
.jpg "ERL for auto deprovisioning an object")
To remove the triples from a resource, you synchronize the affected resource. Although a triple relationship is established by the FIM Service, the removal of it is done by the FIM Synchronization Service. In other words, when a synchronization rule is to be removed, the FIM Service requests the removal of the synchronization rule from a resource. The actual removal must be done by the Synchronization Service because the Synchronization Service might have to trigger the deprovisioning process, which can 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 illustration shows an example for this.
.jpg "Empty ERL after deprovisioning")
In summary, it is possible to initiate the deprovisioning process by configuring a related synchronization policy. Although the FIM Service is responsible for initiating this process, the Synchronization Service actually completes it.
Completing deprovisioning by using the deprovisioning synchronization rule
The deprovisioning process is initiated by removing a link between a metaverse object and a connector space object during the outbound synchronization phase. The synchronization service determines the impact of the link removal on the affected connector space object. You configure the reaction by setting a deprovisioning option.
The following illustration shows the Configure Provisioning dialog box used to set the deprovisioning option.
.jpg "Configure Deprovisioning dialog box")
You can configure four different deprovisioning options:
Make them disconnectors—This option keeps the affected object as a disconnector in the target connector space. A disconnector has the potential to contribute data to the metaverse again. That is, if at some point you run a 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 need to disconnect a connector space object from an incorrect metaverse object.
Make them explicit disconnectors—This option is identical to the previous option except that the connector space object is turned into an explicit disconnector. An explicit disconnector cannot become a connector 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 cannot 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 object does not immediately delete the connector space object. Instead, the staged deletion is pushed out as a request to the external system during the next export run on the target management agent.
Determine with a rules extension—There are times when it is not possible to make an appropriate deprovisioning decision passed on the declarative options. In this case, you can implement a detailed decision in a rules extension. This method is also useful for setting an attribute value on the disconnected object before it is disconnected.
Summary
Deprovisioning is the process that disconnects a metaverse object from a related connector space object during the outbound synchronization and performs a specified action on the disconnected object. Although staging a deletion is a possible outcome of the deprovisioning process, it is not the only result of it. Consequently, when designing deprovisioning process, you should use precise terms (such as disconnect, link removal, or deletion) rather than the more general term deprovisioning to describe the steps in the process.
The deprovisioning process consists of an action and a response to it. The action is triggered either by deleting an object or by a synchronization rule. The response is an activity that is defined by the affected management agent. The response activity can range from a simple disconnect to a staged (deferred) deletion.
In the case of a staged deletion, the Synchronization Service does not delete objects. Instead, a deletion request is staged and then pushed out to an external system in the form of an export run profile.
Additional reading
For more details, see the following articles.