In some FIM solutions, it is necessary to implement a mechanism that updates the remaining connectors when one connector has been removed. For example, MaxMexican was working on a solution that publishes Active Directory users based on the content of a HR data source. In case of a new HR resource, a new and enabled user is provisioned to Active Directory. This is so far a pretty straight forward scenario. However, Max had a special requirement for deleted HR resources. If a HR deletion for an already synchronized user is processed, Max needed the related Active Directory account to be disabled.
The objective of this article is to share with you an implementation option for Max’ requirement.
The first problem with this scenario starts with the term “deletion”. From the perspective of the metaverse, deletions in a connector space are not necessarily easy to detect.
What happens, when a deletion of a connector space object is processed:
However, the same thing happens when a connector is filtered by the connector filter. As you can see in this scenario, the metaverse object cannot differentiate between a connector that was removed due to a deletion or due to a connector filter. You should keep this in mind when designing a solution!
Let’s assume, Max follows the best practice recommendation to keep the filtered objects at a minimum. In Max' case, he doesn’t even have a connector filter configured. If there is no connector filter configured, a connector removal can be considered to be a deletion.
How does this help with Max’ scenario? In this case, you can leverage a default functionality in FIM. As mentioned before, when a connector is disconnected, the attributes that were contributed by this connector are pulled. This feature is also known as “attribute recall”. By default, each management agent is configured to “recall attributes contributed by objects from this management agent when disconnected”. You can configure the behavior of this feature in the “Configure Deprovisioning” section of the Management Agent Designer:
In case of our scenario, you can take advantage of this feature in form of an operational attribute on your metaverse object. This attribute is also known as Connector Flag. There are two requirements for a Connector Flag:
If there is only one source that can populate this attribute, you know where a change comes from if the attribute is updated.
Since the ideal anchor is considered to be immutable, there are only two possible events that can result in updates to this attribute
This is exactly, what we are looking for in case of our scenario. In case of a new account, the attribute is populated; in case of a deleted account, the attribute is empty. Empty means in the FIM terminology "not present".
In the previous section, you have already been introduced to one key element of the proposed solution – a Connector Flag attribute and how this attribute should be populated. The missing component is how you can leverage this attribute to enable or disable the account in Active Directory. To update the attribute in Active Directory, you need a related outbound attribute flow mapping in your outbound synchronization rule. In this attribute flow mapping, the source is a condition that has the following logic included:
The translation into the FIM format is based on a custom expression with the following format:
The only part that is missing is an answer to what <Value A> and <Value B> are supposed to be. You find a detailed answer to this question in “Design Concepts: Using FIM to enable or disable accounts in Active Directory”. In this article, I will just give you the summary.
The enabled / disabled state is Active Directory tracked in a bit vector attribute called userAccount control.
<Value A> is the value for a new account. New account means, that you are initializing the attribute. In this case, it is OK to initialize the attribute with something like 512.
<Value B> represents the case, where we want to disable an existing account. In this case, you should not use a constant value to set the attribute value. Instead, you should use the following Boolean operation:
The resulting flow looks like this:
In FIM, to implement a poor man’s version of a connector detection mechanism, you can use a connector flag attribute in the metaverse and an IsPresent test to detect whether the connector you care about exists. To enable / disable accounts in Active Directory, you should follow the instructions outlined in “Design Concepts: Using FIM to enable or disable accounts in Active Directory”.