none
Removing users from Portal under specific conditions RRS feed

  • Question

  • Hi,

    Our users come from an HR feed, with the 'employeeStatus' attribute set to either 'active' or 'inactive'.

    When a user is 'inactive', they still remain in the HR feed, but we move the users to a Disabled OU in AD. At the same time we would like to remove them from the Portal = how do we accomplish this? only remove a user from the FIM Portal if their 'employeeStatus' = inactive?

    Note, they may return at a later date, their 'employeeStatus' may again change to 'active' and they need to be exported to the Portal again.

    Thanks,

    SK


    • Edited by D Wind Friday, June 1, 2012 5:56 AM
    Friday, June 1, 2012 5:43 AM

Answers

  • Interesting variation on this scenario :) ... and here's how I would go about this.

    Using a traditional provisioning rules extension I would

    1. Check csentry.dn for the connector in the ConnectedMAs collection where the number of AD MA connectors = 1, then hwere there is a dn part matching my "Terminated Users" OU name, I'd call mventry.deprovisionAll
    2. Ensure that I don't project from the AD MA again while my disconnectors remain in this OU (determine by rules extension)
    3. Ensure that the FIM MA has deprovisioning set to "delete on next export"

    I'm thinking that declaratively this is going to be harder :).  Here's an idea that without testing it I *think* should work (assuming you used a set transition MPR to provision your AD user in the first place):

    1. Ensure your outbound SR has the checkbox setting to disconnect the AD CS object when the SR is removed
    2. Ensure that the FIM MA has deprovisioning set to "delete on next export"
    3. Flow something into the FIM portal that you can use to adjust the definition of your outbound AD SR set transition definition ... you MUST flow something into FIM that can ONLY come from AD so you get the timing right.  You could simply flow the DN into an MV.user.dn indexed string binding, and flow this into the portal (to check for the presence of the "terminated users" string) ... and equally you could flow in some sort of boolean too
    4. Adjust your set definition (for your set transition MPR) to exclude users who are identified as being in the terminated users OU
    5. Define your object deletion rule on the MV.person object such that the object is deleted from the MV when the AD CS object is deleted

    Funny ... one seems simpler than the other? :)


    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

    Friday, June 1, 2012 9:04 AM
  • Only thing I'd do different from Bob's notes is to have my MV extension key off of the status attribute from HR versus the OU in AD.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Friday, June 1, 2012 10:59 PM
    Moderator
  • Since HR systems never delete records (generally), it's not uncommon to design FIM such that at some point after the record being marked inactive, it's disconnected. In the event that the record is re-hired, then you would re-project/join.


    True, however, the question is what “at some point” means and what the method used to do the disconnect is…

    Especially, in the case SK has outlined, disconnecting an account from FIM when it has been marked in HR as inactive, might be way too early.
    The account is moved into a special OU in AD for a grace period and should be eventually deleted – who is taking care of this?

    We have developed solutions, where this case is handled in form of a transitions of the authority.
    This means:

    • FIM detects the “inactive” account
    • FIM moves the account in AD DS into a “special” OU
    • FIM turns the HR account into an explicit disconnector
    • FIM deletes the AD DS account after the grace period

    In this example, the authority is transitioned from the HR MA to the FIM MA.

    I belief, this discussion is about a design philosophy that depends on more details – there is not necessarily a right or wrong.
    Again, from my perspective, it is also important to take a look at what a “in HR never deleted account” means.
    There are cases, where compliance demands that one needs to keep a record of these accounts for a relatively long time.
    This means, although marked as inactive or even deleted, from the FIM perspective, these are still managed accounts that do contribute valuable identity data – for example, if you need to calculate a unique value…

    All, I’m trying to say, is that it is not a good idea to turn a logical scenario to fast into a technical implementation (e.g.: counting connectors, setting connector filters, etc.)

    So, in the case of SK’s scenario, I would, for example, like to know, why the account has to be removed from the portal when the status has been changed to ‘inactive’.
    If the account has the potential to “come back”, there is, I think, no need to do this.

    Anyway, I didn’t mean to hijack this thread….

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

    Sunday, June 3, 2012 2:33 AM

All replies

  • Interesting variation on this scenario :) ... and here's how I would go about this.

    Using a traditional provisioning rules extension I would

    1. Check csentry.dn for the connector in the ConnectedMAs collection where the number of AD MA connectors = 1, then hwere there is a dn part matching my "Terminated Users" OU name, I'd call mventry.deprovisionAll
    2. Ensure that I don't project from the AD MA again while my disconnectors remain in this OU (determine by rules extension)
    3. Ensure that the FIM MA has deprovisioning set to "delete on next export"

    I'm thinking that declaratively this is going to be harder :).  Here's an idea that without testing it I *think* should work (assuming you used a set transition MPR to provision your AD user in the first place):

    1. Ensure your outbound SR has the checkbox setting to disconnect the AD CS object when the SR is removed
    2. Ensure that the FIM MA has deprovisioning set to "delete on next export"
    3. Flow something into the FIM portal that you can use to adjust the definition of your outbound AD SR set transition definition ... you MUST flow something into FIM that can ONLY come from AD so you get the timing right.  You could simply flow the DN into an MV.user.dn indexed string binding, and flow this into the portal (to check for the presence of the "terminated users" string) ... and equally you could flow in some sort of boolean too
    4. Adjust your set definition (for your set transition MPR) to exclude users who are identified as being in the terminated users OU
    5. Define your object deletion rule on the MV.person object such that the object is deleted from the MV when the AD CS object is deleted

    Funny ... one seems simpler than the other? :)


    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

    Friday, June 1, 2012 9:04 AM
  • Of course I like Bob's traditional provisioning extension method, but I'm biased as my current environment is ILM not FIM.  :-)

    The one thing I would add along with #2 (ensuring the AD MA doesn't project) is also ensuring the HR MA does not project an inactive user as well, since it sounds like the HR feed is an authoritative data source separate from the AD MA and FIM MA.

    Chris

    Friday, June 1, 2012 9:18 PM
  • Here is a different point of view :-)

    The FIM data store is supposed to be a mirror of all managed objects.
    This is why everything that enters the MV is "automatically replicated" into the FIMMA CS.
    The only reason for removing the object from FIM is an unmanaged object (e.g.: an object that was deleted in the authoritative data store).

    From that perspective, having a HR connector that doesn't have a representation in FIM is in my opinion a design issue...

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

    Friday, June 1, 2012 10:16 PM
  • Well at the point the FIM portal object is not eligible anymore, the HR connector would get disconnected.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Friday, June 1, 2012 10:58 PM
    Moderator
  • Only thing I'd do different from Bob's notes is to have my MV extension key off of the status attribute from HR versus the OU in AD.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Friday, June 1, 2012 10:59 PM
    Moderator
  • It is possible that I have misunderstood your comment - so, please bear with me...
    There are not that many details in this post and mileage may vary; however, in the classic HR case, HR is authoritative.

    So, from that perspective, a disconnected HR object makes the FIM portal object "not eligible anymore" - not the other way around.
    In other words, as long as a HR connector exists, the FIM connector must exist.

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

    Friday, June 1, 2012 11:11 PM
  • Since HR systems never delete records (generally), it's not uncommon to design FIM such that at some point after the record being marked inactive, it's disconnected. In the event that the record is re-hired, then you would re-project/join.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Friday, June 1, 2012 11:13 PM
    Moderator
  • Wow this got some activity overnight :)

    I actually (for once) didn't try to approach this from a best practice perspective (since my standard approach would also be to drive off hr status and in the ILM way retain the HR connector).  However, with FIM CAL pressure I can see why the HR disconnect sometimes has to happen!.  This is because the key piece of info that drives the stated requirement is the existence of the AD user in the terminated user OU.  It is also because this is the FIM and not the ILM forum ... and so I'm trying to think how to do this declaratively.

    In order for FIM or plain ILM to control things we usually need to maintain a connector right up until the last moment, and I know you can do a rename in a "Deprovision" method of you rules extension just prior to setting DeprovisionAction.Disconnect.  However I couldn't think of how to do this declaratively, so this influenced my response by making it the same starting point in both cases (the presence of the AD object in the OU).


    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

    Saturday, June 2, 2012 12:53 AM
  • Since HR systems never delete records (generally), it's not uncommon to design FIM such that at some point after the record being marked inactive, it's disconnected. In the event that the record is re-hired, then you would re-project/join.


    True, however, the question is what “at some point” means and what the method used to do the disconnect is…

    Especially, in the case SK has outlined, disconnecting an account from FIM when it has been marked in HR as inactive, might be way too early.
    The account is moved into a special OU in AD for a grace period and should be eventually deleted – who is taking care of this?

    We have developed solutions, where this case is handled in form of a transitions of the authority.
    This means:

    • FIM detects the “inactive” account
    • FIM moves the account in AD DS into a “special” OU
    • FIM turns the HR account into an explicit disconnector
    • FIM deletes the AD DS account after the grace period

    In this example, the authority is transitioned from the HR MA to the FIM MA.

    I belief, this discussion is about a design philosophy that depends on more details – there is not necessarily a right or wrong.
    Again, from my perspective, it is also important to take a look at what a “in HR never deleted account” means.
    There are cases, where compliance demands that one needs to keep a record of these accounts for a relatively long time.
    This means, although marked as inactive or even deleted, from the FIM perspective, these are still managed accounts that do contribute valuable identity data – for example, if you need to calculate a unique value…

    All, I’m trying to say, is that it is not a good idea to turn a logical scenario to fast into a technical implementation (e.g.: counting connectors, setting connector filters, etc.)

    So, in the case of SK’s scenario, I would, for example, like to know, why the account has to be removed from the portal when the status has been changed to ‘inactive’.
    If the account has the potential to “come back”, there is, I think, no need to do this.

    Anyway, I didn’t mean to hijack this thread….

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

    Sunday, June 3, 2012 2:33 AM
  • Hi,

    Wow, what an amazing thread this has become - thank you all for your responses.

    @Markus - the reason I wanted to remove the 'inactive' people from the Portal was to reduce the 'clutter' of accounts and also to try reduce the Service database size a little bit.

    All the comments are very valid, and even though there may be a technical solution, the idea of re-visiting the architecture is also under consideration.

    Thank you,

    SK

    Monday, June 4, 2012 8:41 AM