none
What is the best practice method of removing all group memberships of a user when his status becomes "terminated"? RRS feed

  • Question

  • It is a requirement that FIM removes all the Manually managed Group memberships when his status is "terminated". Criteria and Manager based groups are easy; its the Manually added group memberships he has acquired over the years which is the trouble.

    Historically we have done this by manipulating the user's memberOf AD attribute directly.  But I guess the FIM way is to run an Action Workflow whenever this status is met. Big question is what this action should consist of.

    Is Powershell the recommended method.. i.e. build a list of all possible groups and loop thru them removing user X from the list of members if he is present in the group by cmdlets? Or what?

    Its just that PS seems such a big hammer to crack this nut.

    Wednesday, May 23, 2012 10:52 AM

Answers

  • Historically we have done this by manipulating the user's memberOf AD attribute directly.

    The ADUC interface gives you the illusion that this is what you are doing, but in fact the memberOf property is what is sometimes referred to as a "virtual attribute" or "back-link".  What you see there is the inverse of the Group.member (multi-value reference) property, and is calculated "on the fly" for the purposes of implementing the friendly ADUC interface.

    I have approached this problem in the past using post-termination processing "out of process" of the FIM/ILM synchronization thread - by doing exactly what you just said (stripping group members in a loop), but instead of PowerShell I used C# managed code.  Same thing now with FIM, but of course now we have the FIM Portal and its workflows.  What I would be looking to do here is invoke a FIM workflow fired by a "terminated user" set transition MPR - but I am most likely going to have to write some C# here in the form of a custom workflow activity.  Possible considerations here are:

    1. Are ALL of your groups present in FIM (at least the sync engine if not the portal)?  If not, option 3 below may still be an option, but here your PowerShell idea is probably as good as any.
    2. Are ALL groups present AND authoritative in FIM?  If so then we can delete all membership and sync out to AD.  Still ... unless you have a pre-prepared workflow activity at your disposal (which many of us do these days) then you're up for some C# or VB.Net development.
    3. Are ALL groups present BUT some/all of your groups authoritative in AD?  If so we can still go down the workflow activity route, but you're going to have to modify AD group objects directly in code ... and this is probably more work than option #1.

    If you can answer YES to the first question above, then I am going to propose NONE of the above approaches ... and suggest something I haven't tried myself but know it will work :).

    Group.member is a reference property, and a feature of any FIM MA with respect to such properties is that if a CS reference is not present and connected to a corresponding MV object, then any export of the referencing object will cause the removal of that referenced member.  In other words, I can have all group.member references present in both the metaverse and the authoritative source, but if it's not in the target CS, then the referencing property will be dropped on export.

    So ... I would try this:

    1. Use a secondary AD MA to manage all group membership updates ONLY, and ensure only non-terminated users are present as connectors (e.g. you can filter all terminated users, or perhaps exclude them via OU selection if you exclude a "terminated users" OU from the scope of this MA.
    2. Define your member export flow to AD using only this secondary MA (retain all other attribute flows in your primary AD MA)
    3. Experiment and test :).

    If the above works for you, it will be the simplest code-free approach I can think of, and I'd be keen to find out how you go implementing it :).


    Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine

    Wednesday, May 23, 2012 3:22 PM
  • That was one of my first custom activities (removing termed users from groups) actually, and it's a fairly straightforward activity to write.

    It only becomes a half-solution when (as Bob points out) FIM isn't authorative (or at least collaborate) with all the groups a person exists in.

    On the other hand, some people will take the approach that it doesn't matter which groups you belong to if your account is disabled, but it doesn't sound like that's acceptable in your environment.

    An even more interesting probem is what happens if you find you have accidently deprovisioned a person from 30 groups and they need to be put back in. Consider an extra attribute to store 'PreviousGroupMemberships'..


    Frank C. Drewes III - Architect - Oxford Computer Group

    Wednesday, May 23, 2012 8:09 PM

All replies

  • Historically we have done this by manipulating the user's memberOf AD attribute directly.

    The ADUC interface gives you the illusion that this is what you are doing, but in fact the memberOf property is what is sometimes referred to as a "virtual attribute" or "back-link".  What you see there is the inverse of the Group.member (multi-value reference) property, and is calculated "on the fly" for the purposes of implementing the friendly ADUC interface.

    I have approached this problem in the past using post-termination processing "out of process" of the FIM/ILM synchronization thread - by doing exactly what you just said (stripping group members in a loop), but instead of PowerShell I used C# managed code.  Same thing now with FIM, but of course now we have the FIM Portal and its workflows.  What I would be looking to do here is invoke a FIM workflow fired by a "terminated user" set transition MPR - but I am most likely going to have to write some C# here in the form of a custom workflow activity.  Possible considerations here are:

    1. Are ALL of your groups present in FIM (at least the sync engine if not the portal)?  If not, option 3 below may still be an option, but here your PowerShell idea is probably as good as any.
    2. Are ALL groups present AND authoritative in FIM?  If so then we can delete all membership and sync out to AD.  Still ... unless you have a pre-prepared workflow activity at your disposal (which many of us do these days) then you're up for some C# or VB.Net development.
    3. Are ALL groups present BUT some/all of your groups authoritative in AD?  If so we can still go down the workflow activity route, but you're going to have to modify AD group objects directly in code ... and this is probably more work than option #1.

    If you can answer YES to the first question above, then I am going to propose NONE of the above approaches ... and suggest something I haven't tried myself but know it will work :).

    Group.member is a reference property, and a feature of any FIM MA with respect to such properties is that if a CS reference is not present and connected to a corresponding MV object, then any export of the referencing object will cause the removal of that referenced member.  In other words, I can have all group.member references present in both the metaverse and the authoritative source, but if it's not in the target CS, then the referencing property will be dropped on export.

    So ... I would try this:

    1. Use a secondary AD MA to manage all group membership updates ONLY, and ensure only non-terminated users are present as connectors (e.g. you can filter all terminated users, or perhaps exclude them via OU selection if you exclude a "terminated users" OU from the scope of this MA.
    2. Define your member export flow to AD using only this secondary MA (retain all other attribute flows in your primary AD MA)
    3. Experiment and test :).

    If the above works for you, it will be the simplest code-free approach I can think of, and I'd be keen to find out how you go implementing it :).


    Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine

    Wednesday, May 23, 2012 3:22 PM
  • Well.. your idea is rather sneaky but I think its too artificial even for FIM. I can imagine problems ahead with 2 AD MA's. Two agents acting on the same Data Source just doesnt feel right somehow.

    I think I remain a traditionalist, bite the bullet and hack together some sort of custom activity in a custom workflow for people who become "terminated".

    Wednesday, May 23, 2012 6:05 PM
  • That was one of my first custom activities (removing termed users from groups) actually, and it's a fairly straightforward activity to write.

    It only becomes a half-solution when (as Bob points out) FIM isn't authorative (or at least collaborate) with all the groups a person exists in.

    On the other hand, some people will take the approach that it doesn't matter which groups you belong to if your account is disabled, but it doesn't sound like that's acceptable in your environment.

    An even more interesting probem is what happens if you find you have accidently deprovisioned a person from 30 groups and they need to be put back in. Consider an extra attribute to store 'PreviousGroupMemberships'..


    Frank C. Drewes III - Architect - Oxford Computer Group

    Wednesday, May 23, 2012 8:09 PM
  • Two AD MAs for the same forest isn't  a problem if they are doing fundamentally different things.  However, if you are using PCNS for password synchronization with FIM then you can only have one AD MA per forest.

    I was once considered using deprovisioning code in the sync engine to remove non-employees from the FIM portal (I don't think the idea was originally mine...), effectively removing them from groups that FIM managed.  The problem was the re-adding.  While connectors would be recreated on each sync for the user, if my code let them stay provisioned FIM did not do an export of all attributes...only those queued up by the delta sync.  A full sync had to hit the object for all the relevant attributes to export to the FIM MA again.  That was less than ideal.

    Chris

    Wednesday, May 23, 2012 8:52 PM
  • I think customers prefer a reliable consistent solution. If a User is managed by FIM, i.e. he is known to the FIM portal then if FIM detects he is terminated then I see no problem in FIM removing all group memberships from that user.

    Now if he is a member of a group in an OU which FIM does not ordinarily manage (I think this what you mean about FIM not being authoritative) then we have a decision to make. But that decision is best done in the C# program. Either we only build a list of Groups that FIM knows about or we build a list of groups AD domain wide. Either way we just loop through groups removing the user from each one if he is a member.

    As an aside, since this is so basic a need (the custom activity) , why isn't this more widely discussed.

    • Proposed as answer by UNIFYBobMVP Wednesday, September 26, 2012 12:56 PM
    Thursday, May 24, 2012 6:17 AM
  • I use the custom workflow approach a good deal ... and of course it works well, but with one major downfall ... action workflows can and do fail, and when they do your FIM portal is left in a state of inbalance with missing referential integrity.  I use housekeeping policy to mitigate against this, and on my current project I have a good deal of this kind of policy in place.  However, whenever I can, I try to leverage the sync engine to enforce referential integrity, and in the case of back-links this is something I'd do a great deal more if I could.  Hence the idea above appeals to me as a way of avoiding the shortcomings of the other options.

    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

    Wednesday, September 26, 2012 1:05 PM