Understanding Expected State Detection

With expected state detection (ESD), you can detect the custom states of objects in your managed external systems in Microsoft® Forefront® Identity Manager (FIM) 2010 and configure a response to them.

The objective of this document is to give you an overview of ESD, to explain how ESD works, and to discuss advanced ESD solutions.

Understanding Expected State Detection

In an enterprise environment, identity data is typically distributed among various connected data sources that are managed by different departments. As a consequence, the managed data quickly becomes out of date. The objective of the FIM Synchronization Service is to ensure that your managed resources converge to a state that you want and to apply updates to them as necessary throughout an object’s lifecycle.

To determine whether updates to an existing object are necessary, FIM keeps track of the current state of a resource in a connected data source. What FIM knows about an object is a result of import operations from a connected data source. For an already synchronized object, imports from a connected data source are required to determine whether it is necessary to export updates to the connected data source.

As part of this process, it is often a requirement to detect and report on expected states of a resource in a connected data source. With ESD, you can configure the detection of states you care about in your synchronization rules. When the synchronization engine detects an expected state of an object, it indicates this by updating a multivalued attribute called detected rules list (DRL). You can use the value of the DRL attribute to determine which states have been detected and further process the state information in the form of, for instance, a notification message.

For example, to be compliant with the Sarbanes-Oxley (SOX) requirements, our fictitious company, Fabrikam, has removed almost all administrative access to their business applications. If there is a need for administrative access outside business hours, then the person calls the helpdesk and an already prepared emergency account is activated and a password is set. The owner of the account, the application owner, is notified that the account has been activated.

In this example, the synchronization engine does not have write permissions to the EmergencyAccounts organizational unit; it can only read. When an account is activated, it is detected and an e-mail message is sent to the application owners notifying them that the account has been checked out. When the account is disabled again, another message is sent. The application owner can then follow the work that was needed outside business hours and verify that the application data was not impacted.

The objective of this document is to explain how object state detection works and what you need to know to use this mechanism in your environment.

How Expected State Detection Works

In FIM, the metaverse functions as an authoritative source for resource information. When an update has been applied to a metaverse object, the synchronization engine consults your configured outbound flow mappings to determine whether the export updates need to be staged on your connector space resources. In other words, a staged export update can be a result of applied changes to metaverse objects. However, export requirements are not only a result of metaverse changes; they can also be a result of the most recent data that has been imported from a connected data source. When the imported data does not match the state that you want of an object in a connected data source, the synchronization engine also uses the imported data to calculate data that needs to be staged for an export.

This means, in addition to updates that have been applied to the metaverse, updates that have been imported from a connected data source can result in staged export changes. This mechanism ensures that your managed resources in a connected data source converge to a state that you want that is governed by the information stored in the metaverse.

In a FIM environment, you typical run the scheduled import to activate the system to determine update requirements. The interaction between export and import operations is always used to determine the need for export changes. As a consequence, you need to also run an import operation after each export operation to complete it. An import operation that you run after an export operation is also known as a confirming import. When the data of the confirming import does not match the previously exported data, the system indicates this in the form of a warning message.

This warning message is already an example for an ESD implementation that is built into FIM. While the objective of this warning is to report on an obvious issue, there might be custom states that you need to detect and report on in your environment.

In addition to this already built-in mechanism, you might want to define your own states that you need to detect in a connected data source. For example, if you have a business rule stating that all employees on temporary leave must have their accounts disabled, you want to detect if a disabled account is activated and take manual corrective actions. Another example would be when the account used by the management agent has not been granted full control to all objects and permissions are managed at a detailed level. If an object is not in its expected state, this could be used to signal to the administrator to take a corrective action and grant the management agent account additional permissions. A third example would be a configuration with several outbound attribute flow rules with overlapping flows and attribute precedence, that is, an object can be in the state of Prepared, Active, and Retired. A detected state can be used to query and report that only Active objects are activated and have access to the system.

In FIM, you implement the detection of expected states in the form of outbound flow mappings that are selected for an existence test. The collection of these flow mappings in an outbound synchronization rule defines your expected state. The synchronization service compares the expected flow mappings with the actual values that were imported from an external system. When the imported values for an object match the expected values, the system indicates this by updating a DRL attribute. With this attribute, you can locate the outbound synchronization rule for which the expected state is satisfied.

Introduction to the expected state detection configuration

The first component of the ESD architecture is the collection of outbound flow mappings that define the state you want. Depending on your requirements, a state can be defined by just one export attribute flow mapping or a collection. The scope of an expected state is one outbound synchronization rule. In other words, you can define one expected state per outbound synchronization rule.

To define the expected state, you select the Use as existence test flag for the outbound flow mappings that define the state you want. The following illustration shows an example for this:

The list of outbound flow mappings that have been selected for an existence test in an outbound synchronization rule represent the flow mappings that would, when successfully confirmed by an import operation, result in a positive existence test. These flow mappings are also known as an existence test flow mapping set.

The second component of the ESD architecture is the collection of values that have been imported from an external system.

To summarize, from the configuration perspective, the ESD architecture consists of two components:

• Existence test flow mappings collections in an outbound synchronization rule

• Identity data that has been imported from a connected data source

Understanding the existence test

The objective of the ESD process is to report on a state of a resource in a connected data source. The result of the detection process is tracked on your metaverse object. In your configuration, you indicate the state you want in the form of existence test flow mappings in an outbound synchronization rule. In FIM, synchronization rules are only processed during a synchronization run. As a consequence of this, the actual existence test is also performed in the context of a synchronization run.

The synchronization process consists of two separate phases:

• Inbound – from a connector space to the metaverse

• Outbound – from the metaverse to the connector spaces

The following illustration shows an example for this:

You configure existence test flow mappings in an outbound synchronization rule. However, the objective of the ESD process is to report on a state of an object in a connected data source.

As a result, the actual existence test cannot be applied during the outbound synchronization phase. For example, if your outbound synchronization rule called Fabrikam Outbound Synchronization Rule that you use to manage your Active Directory® resources that have existence test flow mappings configured, these flow mappings cannot be evaluated when the outbound synchronization rule is applied to a resource.

In other words, while logically configured in an outbound synchronization rule, existence test flow mappings belong technically to an inbound operation. In our example, the actual existence test is performed during the inbound synchronization phase of a synchronization run on the related Active Directory management agent (MA). The following illustration shows an example:

In FIM, an outbound attribute flow mapping always has a single attribute as the destination. In the context of the ESD architecture, this value of the destination attribute is also known as expected value. The actual attribute value that was imported from the connected data source for the destination attribute is also known as confirmed value. The objective of the existence test is to determine whether the confirmed value matches the expected value. If both values match, the existence test is positive.

The actual existence test evaluation is performed at the end of the inbound synchronization phase when the data that was imported from a connected data source has been processed. If you have several existence test flow mappings configured in an outbound synchronization rule, the existence test is only positive if all the values you want match the confirmed values.

Tracking the outcome of an existence test

In the previous section, you have learned how the existence test is processed. The objective of this section is to explain what the synchronization engine does with the existence test results.In FIM, the synchronization engine uses DRL to track the results of an existence test. This DRL attribute is multivalued since you can have various existence tests configured for an object in your environment. Because an individual existence test is configured in an outbound synchronization rule, each value of the DRL attribute is used to eventually point to the outbound synchronization rule for which the existence test was satisfied. However, the DRL attribute values do not point directly to the related outbound synchronization; instead, the synchronization engine creates an additional object called detected rule entry (DRE) that is used to tie the resource and the outbound synchronization rule together. This is necessary to track additional information about the relationship between the two objects.

Part of the additional information is, for example, a back link from the DRE attribute to the resource. With the back link, you can locate the object that the DRE was created for.

The following illustration outlines the related DRL architecture:

This architecture is also known as an ESD triple. The synchronization engine creates an ESD triple if an existence test flow mapping set has been confirmed by a connected data source. If an ESD triple exists, and the confirmed values do not match the values you want, the synchronization engine removes the triple.The synchronization engine assigns a predefined name to each DRE resource—the name of the related outbound synchronization rule prefixed with DRE. This implementation simplifies the interpretation of the meaning that a DRL value has when you examine it.The following illustration shoes an example:

You can also review the DRL related state of an object in the FIM Portal. To do this, you need to ensure that you have an export attribute flow mapping configured for the detectedRulesList attribute on your FIM management agent.

You can review the current DRL state of a resource by looking at the Provision information in the FIM Portal.

The following illustration shows an example:

Processing detected states

When you configure ESD in your environment, you have a specific purpose in mind. For example, you might want to send a notification to someone in response to a detected state or when an object leaves the detected state.

In the FIM architecture, the state of a resource is defined by the set membership. You can use detected state changes in the form of set transitions to trigger a management policy rule that invokes a workflow. To do this, you need to translate the values in your DRL attribute into a set membership.In FIM, you can configure this is requirement in the form of a criteria-based set.

In this set, you need to select all users with a DetectedRulesList attribute that contains the DRE resource you care about.The following illustration shows an example for this:

However, the set definition above would not generate the results that you want for all users. This definition returns all users with a DRL attribute that has a reference to one specific DRE resource.

DREs are created on a per user basis. In other words, the synchronization engine creates an individual DRE resource for each resource that has satisfied the existence test. To address the requirement of our scenario, you need two sets.

The first set is a collection of all DRE resources that have a reference to the synchronization rule that you want.

You can define this set by using the following set definition:

The set definition above creates a list of all the DRE resources that have a reference to the Fabrikam Active Directory outbound SR synchronization rule. For the current scenario, you need to find all users that have a DRL attribute with a reference to one of the members in the set above. In FIM, this set has to be created with a custom filter. The custom filter statement has the following architecture:

/Person[DetectedRulesList = Set[ObjectID='<GUID of the Set with the DREs>']/ComputedMember]

Creating a set that has all users with the DRL attribute that points to a required DRE is a more complex task since you need two sets to accomplish this task. However, with the information outlined in this section, you have all the components you need to build this set in your environment.

Advanced Considerations for ESD

The objective of the ESD model is to report on detected states in a connected data store. This is accomplished by comparing the values that you want for the existence test flow mappings in an outbound synchronization rule with the confirmed values from a connected data source.

In addition to a confirmation that a set of outbound attribute flow mappings are confirmed to be active on a resource, you might also want to detect states in a connected data source that are indirectly managed. This includes, for example, the detection of states you do not manage in the form of active outbound attribute flows on a resource. The objective of this section is to explain how you can take advantage of the object state detection architecture for these scenarios.

Introduction to operational solution components

To define an existence test, you need to configure existence test flow mappings in an outbound synchronization rule. However, there are cases where the confirmed value is not managed by FIM.

An example for this is the detection of object exists in an external system. In FIM, the synchronization service uses the anchor attribute of a connector space object to locate the corresponding partner object in a connected data source. If a confirmed anchor value for an object exists in the connector space, an object can be considered to exist in the external system. However, in many cases, the anchor attribute of an object is not managed by FIM. This is, for example, true for Active Directory® Domain Services (AD DS). In AD DS, all existing objects are identified by the Active Directory GUID. The Active Directory GUID is also the anchor attribute of the Active Directory MA in FIM.

If you want to detect existing objects, you need to get the confirmation of an existing Active Directory GUID value. In AD DS, the GUID value of an object is under the exclusive control of the directory service. In other words, as soon as an object has a GUID value, the value must have been applied by the directory service. For the scope of the object state detection, the actual value of the GUID attribute is irrelevant. As soon as a value for the Active Directory GUID was imported, you have a confirmation for an existing resource. This can also be used as a watchdog to ensure that sensitive accounts that the Sync Engine does not have permissions to manage are not leaving an expected state. Even if the synchronization engine cannot correct the state, it can report the state so that corrective actions can be taken.

You can handle this scenario in FIM by introducing the following components into your solution:

• Operational outbound synchronization rule

• Operation inbound attribute flow

The main purpose of an outbound synchronization rule is to manage a resource in a connected data source. To manage a resource with an outbound synchronization rule, you need to bring the resource into the scope of the synchronization rule. In FIM, you bring a resource into the scope of an outbound synchronization rule by configuring a provisioning policy. This provisioning policy consists of the following components:

• Outbound synchronization rule

• Workflow

• Set transition-based management policy rule

However, in case of the Active Directory GUID, you do not want to manage the outbound-facing Active Directory GUID. In FIM, you can prevent an attribute flow mapping from becoming an actual attribute flow by configuring the mapping in an operational outbound synchronization rule.

An operational outbound synchronization rule is an outbound synchronization rule that has only existence test flow mappings that you do not want to become actual attribute flows. The synchronization rule is not part of a provisioning policy.

As a consequence, an object is never brought into the scope of an operational outbound synchronization rule. Existence test flow mappings are configured in an outbound synchronization rule but applied during the inbound synchronization phase. The synchronization engine locates in the metaverse all outbound synchronization rules with existence test flow mappings that apply to currently processed data source.

To activate the existence test flow mappings of an operational outbound synchronization rule, all you need to do is to bring the synchronization into the metaverse. If you want to detect existing resources, you only need to configure one existence test flow mapping for the objectGUID attribute. However, to do this, you also need an operational metaverse attribute that can store GUID values. The following illustration shows an example for the related existence flow mapping:

The actual existence test is a comparison of confirmed values with the expected values. To have an expected value, you need to populate the metaverse attribute with a value. To recap, for the scope of this scenario, the actual value is irrelevant as long as the value comes from the right source—AD DS. You can accomplish this by configuring an operational inbound attribute flow for the object objectGUID attribute in an inbound synchronization rule that has the Active Directory connector space as scope.

During the inbound synchronization phase from the Active Directory connector space, the adGuid attribute in the metaverse is populated with the objectGUID value. The actual existence test is applied at the end of the inbound synchronization phase. At this point, the expected value and the confirmed value are the same, which results in a positive existence test.

To summarize, by using a combination of an operational outbound synchronization rule and an operational inbound attribute flow, you can take advantage of the ESD architecture to detect states that are not managed by your outbound attribute flows.

As a best practice recommendation, you should assign a descriptive name to your operational outbound synchronization rule that indicates the purpose of the test. In our current example, you could assign a name like Is Existing Active Directory User. Using a descriptive name helps to simplify the process of interpreting DRL values in your environment.

Introduction to advanced operational inbound attribute flow mappings

In the previous section, you were introduced to the concept of operational attributes in the context of object state detection. A simple operational attribute flow is sufficient if all you need to know is whether an attribute of a resource in a connected data source has a value.

When designing your solution, you might run into cases where you need to know more about the confirmed attribute value. This is the case, for example, if you want to use ESD to track activated accounts in AD DS. In AD DS, whether a user is activated or not is encoded in the userAccountControl attribute. This attribute is a bit vector, which means that there are various states encoded in one attribute value.

In the userAccountControl attribute, the second bit of the attribute value is used to indicate whether the attribute belongs to an activated object. If the second bit is 0, the resource is turned on. Otherwise, it is turned off. If you want to determine the current state of the resource, you need to calculate the state from the attribute value. In a synchronization rule, you can use the BitOr function to test whether a bit is set in an attribute. If the specified bit is set in the source attribute, the BitOr operation returns the value of the source attribute. In other words, the operation BitOr(userAccountControl,2) returns the userAccountControl attribute value if the attribute belongs to a disabled resource. In an activated account, the operation returns a value of userAccountControl + 2.

For the existence test, it is only relevant if the value that you want and the confirmed value are the same. With an advanced operational attribute flow, you can predefine the actual outcome of the existence test. If the attribute you examine in your attribute flow mapping logic has the state you need to detect, you flow the value as it is. If the attribute does not have the state you need to detect, you can flow something else. The purpose of this technique is to ensure that the confirmed value and the value that you want either match or do not match depending on what it is you need to detect. With binary operations, you have the required value you need to flow as the value that you want built into the operation.

The following table summarizes the actual results for the current example:

When you implement this solution, the synchronization service adds an entry to the DRL attribute if the processes object is a disabled user in AD DS.

Summary

With ESD, FIM introduces a flexible mechanism to detect states of managed objects in your external systems. You can use this mechanism to create reports and also to implement corrective actions. The detection process consists of a comparison of the expected values in your collection of outbound flow mappings that have the Use as Existence Test flag set and the corresponding values that have been imported from an external system. When the imported values match the expected values, the existence test is positive. In a positive existence test, the synchronization engine adds an entry to the DRL attribute of an object. You can use DRL values to locate the outbound synchronization rule for which the existence test is satisfied.