In this post we will discuss the attribute flows needed to synchronize groups into the Metaverse from Active Directory.
Understanding Group Management - Inbound Group Synchronization
Configuring an Inbound Group Synchronization Rule
Thus far, we have created a means for getting users out of Active Directory and into the portal, as well as provisioned from the Portal to Active Directory. Now we will address groups. Though the process is similar (SR, MPR, WF), there is some added complexity with regard to the custom expressions that are required for groups to flow correctly.
To begin, navigate to the Portal home screen:
In the right-hand menu, select “Synchronization Rules”
This will open the Synchronization Rules menu.
In the top menu, click “New”
On the “General” tab, enter the following Information
The Display Name should be something that clearly identifies what the Sync Rule is doing and what Direction the Data flow is into the Metaverse.
The Description isn’t required but maybe useful to assist anyone who needs to understand the configuration of the FIM Sync and Portal.
Data Flow Direction
You are given 3 option which are used to determine the direction of data from the connected data source and the Metaverse, I rarely use Inbound and Outbound because I feel that it is easier for people to understand data direction flow when the sync rules are separated.
Brings data from the Data Source Connector Space into the Metaverse
Brings data from the Metaverse to the Datasource Connector Space
Inbound and Outbound
Is used to Synchronize Data in both directions to and from the Metaverse.
This is used to determine how the sync rule is applied to the data in the Metaverse
To Specific metaverse resources of this type based on Outbound Synchronization Policy. Outbound Synchronization Policy consist of MPR, Set, and Workflow.
To all metaverse resources of this type according to Outbound System Scoping Filter. Outbound System Scoping Filter is defined in the scope tab.
Under the “Scope” tab, for “Metaverse Resource Type” select “group”. For “External System”, select the Active Directory management agent you wish to use. For “External System Resource Type”, select “group”. Click “Next” to continue.
For the “Relationship” tab, use the drop-down menu below “MetaverseObject:group(Attribute)” to select “accountName”. For “ConnectedSystemObject:group(Attribute)”, select “sAMAccountName”.
If you would like to create the object in the FIM Portal if it does not exist, be sure to place a check in the box next to “Create resource in FIM”, then click “Next” to continue.
Now we must configure “Inbound Attribute Flows”. Most of these are straight forward, with a few exceptions
Suggested Attribute flow Environment Dependent: Direct Attribute Flows
Note: Any Attribute that will be managed by the FIM Portal such as MembershipLocaked and MembershipAddWorkflow which are used to determine the type of group must have a supporting attribute flow configured on the FIMMA. Please see referenced links at the beginning of this post.
Your active Directory Environment does not have the schema extended to include extensionAttribute1 or extensionAttribute2 I would recommend using any other 2 open attributes that are not being used in your environment. This will be very beneficial in the development of a fully functional Group Management solution. These attributes will be used to store data that can be used to determine what type of Group you are syncing. One of the major benefits of using Forefront Identity Manager for Group Management is the ability to easily Manage Groups with a specified criteria or approvals required to join a group. Without the use of the Custom Expressions for membershipAddWorkflow or membershipLocked you would have to set a string value which would be constant which could be problematic for Group Synchronization where AD and FIM are have equal precedence, you would probably see that you would configure a Group in the FIM Portal to utilize Owner Approval and then you would sync that group into Active Directory, once the group was synced back from Active Directory the group would be modified depending on the static value that was set for the attribute flows of membershipAddWorkflow or MembeshipLocked. If your environment consisted of only one type of group you could easily set these values with a static value but realistically that will not be the case and I try to configure my attribute flows to give me the greatest flexibility.
By default in Active Directory Display Name is not a required attribute when creating groups, In fact it’s not even an option to fill in with a value during the initial creation of the Group. Without a Display Name Groups can be difficult to manage in the FIM Portal.