One basic requirement for an identity management system is the ability to provision resources to an external system. This guide walks you through the main building blocks that are involved in the process of provisioning users from Microsoft Forefront™ Identity Manager (FIM) 2010 to Active Directory® Domain Services (AD DS), outlines how you can verify whether your scenario works as expected, provides suggestions for managing Active Directory users by using FIM, and lists additional sources for information.
In this section, you will find information about the scope of this document. In general, "How Do I" guides are targeted at readers who already have basic experience with the process of synchronizing objects with FIM as covered in the related Getting Started Guides.
This guide is intended for information technology (IT) professionals who already have a basic understanding of how the FIM synchronization process works and are interested in getting hands-on experience and more conceptual information about specific scenarios.
This document assumes that you have access to a running instance of FIM 2010 and that you have experience in configuring simple synchronization scenarios as outlined in the following documents:
The content in this document is scoped to function as an extension to these introductory documents.
The scenario outlined in this document has been simplified to address the requirements of a basic lab environment. The focus is to give you an understanding of the concepts and technologies discussed. This document helps you develop a solution that involves managing users in AD DS by using FIM.
The procedures in this document require 90 to 120 minutes to complete. These time estimates assume that the testing environment is already configured and does not include the time required to set up the test environment.
If you have questions regarding the content of this document or if you have general feedback you would like to discuss, feel free to post a message to the FIM TechNet forum.
Fabrikam, a fictitious company, is planning to use FIM to manage the user accounts in the corporation’s AD DS by using FIM. As part of this process, Fabrikam needs to provision users to AD DS. To start with the initial testing, Fabrikam has installed a basic lab environment that consists of FIM and AD DS. In this lab environment, Fabrikam is testing a scenario that consists of a user that was manually created in the FIM Portal. The objective of this scenario is to provision the user as an enabled user with a predefined password to AD DS.
To use this guide, you need three architectural components:
The following illustration outlines the required environment:
You can run all components on one computer.
The following table lists the components that are part of this scenario in this guide.
The scenario outlined in this guide consists of the following building blocks:
In this section, you will find instructions for the resources that you need to create that are outside of your FIM environment.
You need the organizational unit as a container for the provisioned sample user.
For the scenario in this guide, you need two Active Directory user accounts:
In both cases, it is sufficient to create regular user accounts. More information about the specific requirements of both accounts is found later in this document.
For the configuration steps in this section, you need to start the FIM Synchronization Service Manager.
For the scenario in this guide, you need to create two management agents:
When you configure a management agent for AD DS, you need to specify an account that is used by the management agent in the data exchange with AD DS. You should use a regular user account. However, to import data from AD DS, the account must have the right to poll changes from the DirSync control. If you want your management agent to export data to AD DS, you need to grant the account sufficient rights on the target organizational units. For more information about this topic, see Configuring the ADMA Account.
To create a user in AD DS, technically, the only attribute you must flow out is the object's DN. In addition to this, it is a good practice to also flow the first name, last name, and display name out to AD DS to ensure that your objects are discoverable.
In AD DS, it is still common for users to use the sAMAccountName attribute to log on to the directory service. If you do not specify a value for this attribute, the directory service generates a random value for it. However, these random values are not user friendly, which is why a user-friendly version of this attribute is typically part of an export to AD DS.
To enable a user to log on to AD DS, you also need to include a password created by using the unicodePwd attribute in your export logic.
When you set a password for AD DS accounts, you also need to create an account as an enabled account. You accomplish this by setting the userAccountControl attribute.
The following table lists the most important scenario specific settings you need to configure:
When you configure a FIM Service management agent, you need to specify an account that is used by the management agent in the data exchange with the FIM Service. You should use a regular user account. The account must be the same account as the one you specified during the installation of FIM. Using Windows PowerShell to Do a FIM MA Account Configuration Quick Test contains a script that you can use to determine the name of the FIMMA account name that you specified during setup and to test whether this account is still valid.
The following table lists the most important scenario specific settings you need to configure.:
The following table lists the run profiles you need to create for the scenario in this guide:
For the scenario in this guide, you need to configure a provisioning policy:
The objective of this provisioning policy is to bring contractors into the scope of the AD User Outbound Synchronization Rule. By bringing your resource into the scope of the synchronization rule, you enable the synchronization engine to provision your resource to AD DS according to your configuration.
To configure the FIM Service, navigate in Windows Internet Explorer® to http://localhost/identitymanagement. On the FIM Portal page, to create the provisioning policy, go to the related pages from the Administration section. To verify your configuration, you should run the Windows PowerShell Script to Document Your Synchronization Triple Configuration.
The following table shows the configuration of the required Fabrikam Provisioning Synchronization Rule:
The objective of the AD Provisioning Workflow is to add the Fabrikam Provisioning synchronization rule to a resource. The following table shows the configuration:
The required MPR is of type Set Transition and triggers when a resource becomes a member of the All Contractors set. The following table shows the configuration:
The objective of the initialization phase is to bring your:
The following table lists the run profiles that are part of the initialization phase.
The objective of this section is to test your actual configuration. To test the configuration, you:
The following table lists the properties of the sample user:
To provision the sample user to AD DS, two prerequisites must be satisfied:
To verify, whether the user is a member of the All Contractors Set, you open the Set, and then click View Members.
To verify, whether the user is in the scope of the synchronization rule, open the user’s property page and review the Expected Rules List attribute in the Provisioning tab. The Expected Rules List attribute should list the AD User Outbound Synchronization Rule.
The following illustration shows an example for this.:
At this point in the process, the Synchronization Rule Status is Pending. This means, the synchronization rule has not been applied to the user yet.
Before you start a first synchronization cycle for a test object, you should track the expected state of your object after each run profile that you run in a test plan. Your test plan should include next to the general state of your object (created, updated, or deleted) also the attribute values that you expect. Use your test plan to verify your test plan expectations. If a step does not return the expected results, do not proceed with to the next step until you have resolved the discrepancy between your expected result and the actual result.
To verify your expectations, you can use the synchronization statistics as a first indicator. For example, if you expect new objects to be staged in a connector space, but the import statistics returns no "Adds", there is obviously something in your environment that does not work as expected.
While the synchronization statistics can give you a first indication of whether your scenario works as expected, you should use the Search Connector Space and the Metaverse Search feature of the Synchronization Service Manager to verify the expected attribute values.
To synchronize the user to AD DS, follow the steps below:
To accomplish these tasks, you run the following run profiles.:
After the import from the FIM Service database, Britta Simon and the ExpectedRuleEntry object that links Britta to the AD User Outbound Synchronization Rule are staged in the Fabrikam FIMMA connector space. When you review Britta's properties in the connector space, you find next to the attribute values that you have configured in the FIM Portal and you also find a valid reference to the ERE object.
The following screenshot shows an example for this:.
The objective of the delta synchronization run on your Fabrikam FIMMA is to perform several operations:
As already indicated by the synchronization statistics, a provisioning activity has taken place on the connector space of the Fabrikam ADMA. When you review the metaverse object properties of Britta Simon, you find that this activity is a result of the expectedRulesList attribute that has been populated with a valid reference:
During the following export on the Fabrikam FIMMA, the synchronization rule status of Britta Simon is updated from Pending to Applied, which indicates that your outbound synchronization rule is now active on the object in the metaverse:
Because a new object has been provisioned to the ADMA connector space, you should have one pending export Add on this management agent. By using the script called "Using Windows PowerShell to Display the Export Statistics of a Management Agent", you get one reported pending export Add for the Fabrikam ADMA.:
In FIM, each export run requires a following delta import to complete the export operation. The delta import that you run after a previous export run is known as a confirming import. Confirming imports are required to enable the FIM Synchronization Service to make appropriate update requirements during successive synchronization runs.
To verify that your sample user has been provisioned to AD DS, you open the FIMObjects organizational unit. Britta Simon should be located in it.
The objective of this document is to introduce you to the main building blocks for synchronizing a user in FIM with AD DS. In your initial testing, you should first start with the minimum number of attributes that are required to complete a task, and then add more attributes to your scenario when the general steps work as expected. Keeping the complexity to a minimum simplifies the process of troubleshooting.
When you test your configuration, it is very likely that you delete and recreate new test objects. For objects with a populated ExpectedRulesList attribute, this can result in orphaned ERE objects. The article A Method to Remove Orphaned ExpectedRuleEntry Objects from Your Environment describes how you can remove these objects from your test environment.
In a typical synchronization scenario that includes AD DS as a synchronization target, FIM is not authoritative for all attributes of an object. For example, when you manage user objects in AD DS by using FIM, at a minimum, the domain and the objectSID attributes need to be contributed by the AD DS management agent. The account name, domain, and objectSID attributes are required if you want to enable a user to log on to the FIM Portal. To populate these attributes from AD DS, an additional inbound synchronization rule is required for your AD DS connector space. When you manage objects with multiple sources for attribute values, you need to ensure that you configure your attribute flow precedence correctly. If the attribute flow precedence is not correctly configured, the synchronization engine blocks attribute values from being populated. You can find more information about attribute flow precedence in the article About Attribute Flow Precedence.