Deprovisioning In-Depth: Part 1 - Disconnectors
I’m going to say some words now that may be frightening to you, so consider yourself warned: disconnector, explicit disconnector, deprovision, deletion. For those of you who survived that, I’d like to discuss the above in some degree of detail. This is part one of three in a series about deprovisioning. To begin, let’s establish some nomenclature.
Deprovision: When we provision an object (user, group, etc.), it is the act of reading in information about them from a source data directory (HR, for example) and then creating (provisioning) the object in a target data directory (such as Active Directory). As such, a deprovision, then, is the obverse. A user (such as a termination) is removed from the authoritative data source and, as a result, is thereby modified (deleted, disconnected, etc.) from any target directory in which they exist.
Disconnector: A disconnector, simply put, is an object (user, group, etc.) for which a connection has been broken. An example of this might be a user is contained in an Active Directory forest. FIM may only be configured to communicate with a single domain controller in that environment, and it may geographically be located a great distance away. During an import/sync cycle, this domain controller (due to network load, offline switches, etc.) may be temporarily unavailable. As a result, every user object contained within that AD will enter the state of disconnector. Further, as these are naturally occurring (non-explicit) disconnections, we refer to them as regular or normal disconnectors. A regular disconnector will, if possible, reenter the connected state. In the above example, if the domain controller is available on the next import/sync cycle, all currently disconnected users will rejoin and again enter the state of connector.
Explicit Disconnector: An explicit disconnector is identitcal to a regular disconnector but with two exceptions: 1.) explicit disconnections occur intentionally (they will not occur autonomously in the wild for any reason), and, 2.) an explicitly disconnected object will remain disconnected until either it is manually joined by use of the joiner tool or, more likely, its state is manually changed to that of regular disconnector.
Deletion: A deletion is, as it sounds, the deletion of an object. Here, when an object (such as a user) is removed from an authoritative data source (such as HR), rather than being disconnected, they are actually deleted anywhere they exist (such as AD).
To begin, let’s look at (regular) disconnectors. Here, we have configured the management agent (Active Directory, in this example) to disconnect on deprovision.
Likewise, I have configured the FIMMA to do the same:
I have also configured an object deletion rule to initiate a deprovision event when a user object is removed from the “Vice Presidents” management agent.
Being a text file based management agent, we can initiate a deprovision event by simply deleting our user:
Goodbye, Mr. Burr.
Next, a full import of the VPMA shows a delete:
And a full synchronization of the same shows us staging disconnections to both FIM portal and AD:
Note, if you try to view the disconnection for FIM, you may see the following:
Similarly, if we search our AD connector space for pending exports, we see:
And the same thing when searching our FIMMA connector space:
Since we see nothing in the pending exports for either the FIM portal or Active Directory, we can rest assured that, while a disconnection has occurred (and the bond between the various instances of this user object broken), the user object itself has not, in fact, been altered in any of the locations where it exists. For further verification, we can search within the FIM portal:
And within Active Directory:
And clearly see the user continues to exist in both.
At this point, the user has been removed from our source directory and, while continuing to exist in the portal and AD, the associations have been broken in the metaverse. In fact, the connector space object(s) (csObjectID)) for this user have been deleted. What this means is that, even if equal precedence is in place, if the user is modified in the portal or AD (either place), they will not be changed in the other. It is also worth noting that, at this stage, the user object is in a state known as a regular disconnector. If the user object were recreated in the authoritative data source (rehired, for example) and the values used for join logic were reused (such as the same employee ID), the recreated user object would actually join to the preexisting AD and portal objects.
Questions? Comments? Love FIM so much you can't even stand it?
EMAIL US>WE WANT TO HEAR FROM YOU!<