locked
When importing Security Groups from AD into the Portal how do I complete the "owner" and "displayedOwner" Portal fields? RRS feed

  • General discussion

  • I am using a sync rule to pull security groups from AD into my Portal. However, I am baffled by these two Portal attributes.

    The SG *is* created in the Portal OK, and also members of the Group are synchronized Ok as well. BUT..

    I am having no luck with owner and displayedOwner.

     

    A blog describing this scenario quotes:

    "The membership in a group is tracked in an attribute called a member, a multivalued reference attribute."

    "

    • An Owner-approval group needs an owner so that they can manage membership in the group.

    • FIM requires that the Displayed Owner is a member of the Owner group.

    One option that you have is to populate both attributes based on the managedBy attribute in AD DS. "

     

    I understand how the members travel... because FIM can dereference the reference type attribute member. But why not the managedBy attribute. It seems to contain a character string that looks like a dn. I admit that when I use MetaView search I dont see the managedBy as a reference type..

     

    so. the $64k question is what do I have to do to transform the managedBy attribute value into something FIM accepts?

     

    *HH

    Thursday, January 19, 2012 7:08 PM

All replies

  • I think the attribute looks like a string DN because that's the only way to display such a reference.  If you look at the member attribute of a group it will have a series of DNs for the objects that are members of the group, depending on the tool you are using and the context of course.

    I just checked my FIM test box, on which I don't think I've done anything beyond the defaults for the group object type in the metaverse.  There is no managedBy attribute for groups at all.  If that is your case, too, then you'd just need to add a new attribute in Metaverse Designer called "managedBy" and make if a "Reference (DN)" attribute type.  I do not thing it is multivalued in AD so you'd leave the multivalued checkbox cleared.

    Then you could set up flow rules to bring AD's managedBy attribute into the metaverse and then flow it out to whatever FIMMA attributes you want.  Your owner values should be reference attributes as well so you shouldn't have to do any transformation.  FIM translates the references from one system to another.

    For more information about reference attributes, see Understanding Reference Attributes Processing in FIM

    Chris

    Thursday, January 19, 2012 7:40 PM
  • The way we do it is to flow the AD 'managedBy' attribute into two separate attributes in the group metaverse object -

    'owner' (multi-valued Reference (DN) attribute)

    'displayedOwner' (single-valued Reference (DN) attribute)

    From memory, these two attributes are part of the default group metaverse object, so you shouldn't need to create anything, just flow those two attributes out to the Portal after flowing the 'managedBy' attribute in from AD.

    An ongoing issue for us is that the 'managedBy' attribute in AD isn't populated for a lot of our groups, which means we need to populate the attributes manually in the Portal and then flow the 'displayedOwner' attribute back into AD. A bit annoying, but everything still works as expected.

    Friday, January 20, 2012 12:20 AM
  • Yes, my bad.

    I forgot that although these managedBy attribute was in the sync rule attribute flow, I forgot to add the owner and displayedOwner attribute export flow in the FIM Management Agent!

    Now I see the references flow as expected

    I agree that if the originating AD group owner is unknown (managedBy is empty) then we need some means of plugging in a default "owner". In our case, the AD security groups are per Application, e.g. CRM, Elmo, WallStreetSuite and so on.. so I hope to be able to add some logic into the procedure so that if for example the cn contains Elmo and managedBy is blank then plug in 'xyz' as owner and displayedowner. Easy to say but not so easy to do I guess.

    Friday, January 20, 2012 7:56 AM