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.

http://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 (0)

Skip to main content