How to Detect Connectors in FIM
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.
Note
For more details on Max' scenario, see How can I re-enable a user object on a target AD with FIM2010RC1?
Detecting deletions
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:
- The link relationship between the connector space and the metaverse object is removed
- In case of the default configuration, the attributes that were contributed by the connector space object are pulled from the metaverse
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!
Note
For more details about deletions in FIM , see Understanding Deletions in ILM.
Although written for ILM, the content of this article is still applicable to FIM.
Introduction to the Connector Flag attribute
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:
Note
It is highly recommended not to change the default attribute recall configuration unless you have a very good reason!
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:
- The attribute has only one inbound flow source – the connector you care about
- The attribute is populated by your anchor attribute
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
- when a new object is processed
- when the object was deleted
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".
Solution Design
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:
Summary
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”.
Community Resources
- Design Concepts: Using FIM to enable or disable accounts in Active Directory
- Understanding Deletions in ILM.