Home » IT - Microsoft » Understanding Deprovisioning

Understanding Deprovisioning

Escribe tu dirección de correo electrónico para suscribirte a este blog, y recibir notificaciones de nuevos mensajes por correo.

Join 5 other followers

March 2016
« Feb   May »



All messages posted to this blog are provided "AS IS" with no warranties, and confer no rights. The content of this site are personal opinions and might not represent the Microsoft Corporation view. Regarding any sample code that we provide: This Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment. THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. This blog serves 2 purposes. Firstly, I want to share information with other IT pros about the technologies we work with and how to solve problems we often face. Secondly, I use my blog as a notebook. There's so much to learn and remember in our jobs that it's impossible to keep up. By blogging, I have a notebook that I can access from anywhere. Anything you do to your IT infrastructure, applications, services, computer or anything else is 100% down to your own responsibility and liability. Mcselles bears no responsibility or liability for anything you do. Please independently confirm anything you read on this blog before doing whatever you decide to do.

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.

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.

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.

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.

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.

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.

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.

Configure Object Deletion Rule dialog box

To customize the behavior of the object deletion rule, you can configure three different options:

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.

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.

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.

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.

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.

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.

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.

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.

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.


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.

Source: https://technet.microsoft.com/en-us/library/hh859718(v=ws.10).aspx


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Microsoft on the Issues

News and perspectives on legal, public policy and citizenship topics

Mike Crowley's Whiteboard

“There are no limits to what you can accomplish when you are supposed to be doing something else."


There Be Dragons

Ken Cenerelli

My life in software development

VMware, Windows, Virtualization (Servers & Desktops)

VMware, Windows, Virtualization (Servers & Desktops)

Just a random "Microsoft Server / Client Tech" info..

"Feeding Your Training and Technology Obsessions"


WordPress.com is the best place for your personal blog or business site.


Documentación técnica, notas y apuntes sobre Administración de Sistemas, Servidores, Redes y más

Microsoft Taste

Mary's Blog

%d bloggers like this: