Understanding Group Management - Inbound Group Synchronization

Please be sure to read the first part of the series Understanding Group Management - Intro to Group Synchronization and attribute Management prior to configuring your Inbound Group Synchronization Sync Rule. I would also recommend reading Introducing Synchronization Rules - Part 1 and Part 2 to assist in the understanding of how data is synchronized with the Metaverse and connected data sources.  

as well as Understanding the FIM Service Management Agent (FIM MA) and Configuring the FIM MA

 

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

• Display Name
  • 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.
• Description
  • 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.
    • Inbound
      • Brings data from the Data Source Connector Space into the Metaverse
      • Outbound
        • 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.
• Apply Rule
  • 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.

 

 

s

 

Source	Destination
description	description
mail	mail
objectSid	objectSid
samAccountName	accountName
managedBy	displayOwner
managedBy	owner
member	member

 

 

Source (customExpression)	Destination
IIF(Eq(BitAnd(2,groupType),2),"Global",IIF(Eq(BitAnd(4,groupType),4),"DomainLocal","Universal"))	scope
IIF(Eq(BitOr(14,groupType),14),"Distribution","Security")	type
IIF(IsPresent(displayName),displayName,cn)	displayName
IIF(IsPresent(extensionAttribute1),extensionAttribute1,"None")	membershipAddWorkflow
IIF(IsPresent(extensionAttribute2),extensionAttribute2,"false")	membershipLocked

 Additionally the Domain attribute is also a required attribute which you could set with a constant string value or use something like custom expression that was posted in a previous blog.

https://blogs.msdn.com/b/connector_space/archive/2014/10/22/using-powershell-to-generate-the-custom-expression-for-the-domain-attribute-flow-single-or-multiple-domain.aspx

Exceptions:

1.      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.
2.      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.

Comments

• Anonymous
  January 17, 2018
  Nice write up Anthony. I am currently setting up a Sandbox environment of MIM 2016 for my company and have user provisioning inbound and outbound working correctly, now on the group provisioning of inbound/outbound. Currently on the inbound and experiencing an issue where I'm running MIMMA Export and giving me errors of "required attribute" is missing. and then in the event viewer, stating. "failed while trying to commit the changes to the database. "Attribute Failure Code: 'RequiredValueIsMissing" Any idea? No luck yet on googling this issue
  • Anonymous
    January 29, 2018
    verify what the object in the MIM MA looks like and determine if it has all the required attribute's, I would start by verifying that you have a value being set for the attributes listed in this posting