none
Managing groups of multiple forests and other directories RRS feed

  • Question

  • Hi folks -

    We have an environment with 2 AD forests, and 'other' LDAP-type directories that support applications.  We also have an AD LDS instance that is considered the authoritative source for all identities in the environment.  Managing users and groups within the environment is cumbersome currently, so we're looking to FIM to help sync identity information between directories, provide a self service capability so that users could update their information in one location, and help manage group memberships for each of the component directories.

    So far with a single FIM service and sync engine, we have found that we are unable to manage group memberships across these forests and directories for reasons that might seem obvious to those with extensive experience in trying to do so.  What it seems we may need to do is stand up a FIM service for each forest and LDAP directory, and I'm just doing a check to see if there are other options out there (possible outside the FIM world) toward managing groups within multiple directories.

    Thanks!



    • Edited by Osho27 Wednesday, June 5, 2013 8:53 PM
    Wednesday, June 5, 2013 8:50 PM

All replies

  • Can you perhaps clarify that what you mean by "managing groups within multiple directories" is something like the following?

    • FIM manages users and groups in both forests FA and FB
    • User UA and Group GA are in Forest FA
    • User UB and Group GB are in Forest FB
    • Users UA and UB are in ADLDS (authoritative identity source) and in FIM
    • Groups GA and GB are authoritative in FIM (created and managed in FIM Portal)
    • Users UA and UB are assigned membership in both Groups GA and GB (i.e. we have GA.ComputedMember contains UA and UB, and GB.ComputedMember contains UA and UB)
    • On provisioning/synchronisation to FA and FB you were looking for both GA and GB to each have members UA and UB in BOTH domains ... but all you end up with is GA.UA + GB.UA in Forest A, and GA.UB + GB.UB in Forest B.

    If the above is true, you understand why this is the case, AND you can explain what you are hoping to achieve by this, then we can look at options.  Maybe I've completely misrepresented your problem :) ...


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Thursday, June 6, 2013 9:12 AM
  • Hi Bob, I'll follow your nomenclature and try to describe what we are after.  Let's say we have a 5 dozen applications within the environment and 20 applications point to FA, 20 point to FB, and 10 to LDA, 10 to LDB, where LDA and LDB are LDAP directories with their own users and groups.  So far, we have 4 different systems, each with there own users and groups and apps.  There is nothing special about FA and FB, no trusts, they are only treated as directories.

    During an onboarding process, it is desired that a special admin could open up FIM Portal, see the onboarded user which was provided by an HR AD LDA, perhaps make an update to the user, then see that the user is provisioned into the 4 directories (FA, FB, LDA, LDB) and assigned necessary group memberships in each of those directories (GA, GB, GDA, GDB).  No expectation to mix groups between directories.

    So, what you've articulated is a pretty good representation if just looking at the AD portions; I'll comment on each...

    • FIM manages users and groups in both forests FA and FB (True, add in other non-AD directories LDA, LDB)
    • User UA and Group GA are in Forest FA (true)
    • User UB and Group GB are in Forest FB (true)
    • Users UA and UB are in ADLDS (authoritative identity source) and in FIM (true)
    • Groups GA and GB are authoritative in FIM (created and managed in FIM Portal) (these are actually imported from existing ADs, but afterward could be considered authoritative in FIM meaning changes will only occur in FIM so fair enough statement)
    • Users UA and UB are assigned membership in both Groups GA and GB (i.e. we have GA.ComputedMember contains UA and UB, and GB.ComputedMember contains UA and UB) (nope, UA and UB are only assigned memberships to groups in their respective directories, we are trying to avoid trusts or the forests knowing of each other for the most part - at least here in design phase)
    • On provisioning/synchronisation to FA and FB you were looking for both GA and GB to each have members UA and UB in BOTH domains ... but all you end up with is GA.UA + GB.UA in Forest A, and GA.UB + GB.UB in Forest B. (nope, too complicated, we just what UA in GA in FA, and UB in GB in FB, etc.)

    From what we've learned so far is that a single FIM service/portal instance cannot manage more than one directory's groups and that to manage X number of directories in the way I've described above I would need X number of FIM service/portal instances, with one sync engine. 

    Apparently the issue is that by hooking up FIM to FA for example, it has no ability to manage groups from FB because the domain value (set to FA) makes things go haywire. This worsens when adding LDA and LDB directories.

    Thoughts appreciated!

    Thursday, June 6, 2013 11:11 AM
  • From what we've learned so far is that a single FIM service/portal instance cannot manage more than one directory's groups and that to manage X number of directories in the way I've described above I would need X number of FIM service/portal instances, with one sync engine. 

    Apparently the issue is that by hooking up FIM to FA for example, it has no ability to manage groups from FB because the domain value (set to FA) makes things go haywire. This worsens when adding LDA and LDB directories. 

    In that case I'm surprised by your experience as I would expect what you want to do would be completely supportable with the setup you've described, i.e.

    • you have 2 AD connectors (for FA and FB) and 2 LD connectors (LDA, LDB)
    • you have groups imported from FA and FB with domain names assigned in FIM (A or B)
    • (guessing this) you also have groups imported from LDA and LDB with possibly no concept of domain - but if not something else to identify it as originating from one of LDA or LDB
    • you have a SR for FA and FB with at least an EAF (export attribute flow) for Group.Member for each one
    • you have a SR for LDA and LDB with at least an EAF (export attribute flow) for Group.Member for each one
    • you have set/workflow/MPR (set transition) triples for each SR

    If you have something like the above then it should work fine, so can you describe what you mean by going "haywire"?


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM


    • Edited by UNIFYBobMVP Thursday, June 6, 2013 12:22 PM
    Thursday, June 6, 2013 12:21 PM
  •  Thanks, Bob.

    Question: What changes with this scenario if at the onset of standing up the environment:

    1.) Groups in both FA or FB were imported from the directories into FIM.

    2.) Groups in both FA or FB were created by FIM and exported to those directories.

    Thursday, June 6, 2013 7:58 PM
  • You seem to have missed this:

    you have groups imported from FA and FB with domain names assigned in FIM (A or B)

    In the syncrule assignment you only add the syncrule for FA to a group from FA and the otherway arround.

    What you describe is that each group is assinged the syncrule for FA and FB. You should check the MPRs which assigns the syncrule for the FA and FB groups.

    You do have two, do you?

    Thursday, June 6, 2013 8:28 PM
  • I mistyped. To be accurate, let's call GA and GB a group from FA and FB, respectfully.

    There is no intention or interest to push either GA or GB into the alternate forest.  Our goal is simply to design a solution for managing groups in each respective forest.

    That being said, our observation is that when importing GA from FA and GB from FB at initialization, FIM fails to be able to reconcile the groups.  It has been pointed out that if FIM were in fact the actual creator of the group, versus having imported the group, it would have the necessary ingredients to manage those directories in an autonomous and independent manner.  Yet, at the object-level or FIM internal-level, it is not clear to us what the technical difference is between a GB created within FIM then exported to the directory (actually creating it then managing it) and a GB imported from AD then subsequently managed.

    Note that when FIM is installed, it is pointing to FA in this case. 

    Thursday, June 6, 2013 9:31 PM
  • If you look at this article (you have probably already seen this) you will know that FIM can be configured for multi-forest group management (under the specified conditions).  Click on the Verification Checklist link and compare this to your FIM configuration for any missed steps ... I expect that you will at least have one domain configuration object for FA given that this was where FIM was installed, but you won't necessarily have one for FB, and you may not have a forest configuration object either.  These are key to the multi-forest FIM design ...

    If you look at the FIM policy that controls this type of deployment by default you will eventually locate the following (sorry if you already know all this stuff):

    MPR: Group management workflow: Group information validation for dynamic groups
    Workflow: Group Validation Workflow (AuthZ)

    You will soon realise that this is all designed for group management in FA and FB as you require, but what about LDA and LDB you ask?

    I have just tried creating "dummy" domain and forest configuration objects for myself with the name "CONTOSO" (seemed like a good name for a test!) and this worked OK - i.e. it didn't try to validate the existence of a domain alias matching CONTOSO.  I was then able to create a new (global) group "ContosoG1" without FIM throwing any wobbly.

    So - to answer your question a few posts back, the only difference between creating a group via the FIM Portal UI vs. creating one via an import sync rule from AD or ADLDS should be the fact that when the export from the FIM sync server happens it bypasses any RCDC uniqueness validation for DisplayName and AccountName, and any AuthZ workflows - however you will get an export failure from the FIM MA if you try to create 2 groups with the same AccountName (e.g. "GA") from 2 different source MAs (AD and ADLDS for example) - it will happily allow DisplayName duplicates though.  You only run into problems later in the FIM UI when you try to update either of the duplicate groups and it complains about there being another one with the same DisplayName.  Of course the concept of "group type" really only makes sense for an AD group (not ADLDS) - so I would set this to the default "Universal" value for these ones.

    In summary - as long as you have a strategy to enforce uniqueness for groups, and you match each authoritative directory connector/MA with its own domain configuration (specify a value for "Domain" on import to the FIM metaverse, and make sure you flow this out via the FIM MA on export - FIM takes care of the DomainConfiguration reference for you automatically) then you should see no difference between creating them this way and via the FIM UI from that point onwards.

    If you still can't get this working (and I can't think of a reason why not) there's always thefimteam.com if that works for you.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Friday, June 7, 2013 1:02 AM
  • Bob,

    What we have discovered after some trial and error is that a single instance of FIM Service is unable to manage groups of multiple directories (FA, FB, LDA, etc) that it did not initially create.  In other words, if you created independent groups in FA, FB and LDA, and imported them into FIM, FIM is unable to discern and manage those groups or more specifically the memberships of those groups.  Your test example and discussion talk to a case where FIM creates those groups, then subsequently manages them.  I'll post any findings or explanations as to 'why' this is the case. This seems like an pretty important capability currently unavailable in FIM.


    • Edited by Osho27 Monday, June 10, 2013 8:03 PM
    Monday, June 10, 2013 8:01 PM
  • I appreciate you have obviously hit a problem in your scenario, but there is no reason I know of why a group created in FIM should behave differently to one created by the FIM Sync Service after being imported from an external directory - it is just a matter of ensuring that the values you export to FIM match the values you are creating via the FIM Portal.  The one thing I do expect to be a problem initially is precedence with your sync rules - i.e. after the initial import into FIM you will need to make FIM authoritative (at least for membership).

    I don't believe there should be a limitation with FIM group management in your use case scenario, so I am keen to understand exactly what you mean by "unable to manage".  It is a common use case to be importing existing groups, and changing mastery to FIM - and to handle this in a multi-domain scenario.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    • Proposed as answer by UNIFYBobMVP Thursday, August 13, 2015 12:07 PM
    Tuesday, June 11, 2013 12:03 AM
  • I'm in agreement with Bob: FIM has no problem managing groups it did not provision, whether they exist in AD:DS, AD:LDS, SQL, Notes, or wherever else.  Group management is a bit more nuanced than user management, but the solution here should be readily achievable with a single instance of FIM.

    Steve Kradel, Zetetic LLC

    Tuesday, June 11, 2013 5:43 PM
  • Thanks for the input Bob and Steve.

    We finally had a breakthrough on this issue.  We were getting a group 'invalid membership' error when adding users to FB groups.  Recall that FIM is installed under FA.  It turned out that the forest and domain configuration was faulty.  Another part of the issue may have been that we were importing groups as Global, and while it seems odd that FIM would honor the AD-typed scope, converting those groups to either universal or domain local upon import added to the fix.  Glenn provided support on resolving the issue and perhaps he'll write up a TechNet article on the subject.  Thanks for input and offering hope that the solution should work!


    • Edited by Osho27 Wednesday, June 12, 2013 7:29 PM
    • Proposed as answer by UNIFYBobMVP Thursday, August 13, 2015 12:07 PM
    Wednesday, June 12, 2013 7:29 PM