none
Separation of Duties - Ideas or Experience RRS feed

  • Question

  • Hi All. Any ideas for the following scenario?

     

    • We have 10 departments and each department has a unique manager e.g. Manager1 to Manager10
    • Active Directory groups are sync'd with MIM portal and we have a group for each department e.g. RoleGroup1 to RoleGroup10 for Department1 to Department10 respectively
    • So Manager1 is an owner of RoleGroup1 for Department1 and the manager will use MIM portal to add/remove members as they join/leave their team
    • Users regularly move between these 10 departments but membership to more than one of the department RoleGroups creates a toxic combination of permissions that we must avoid
    • Our goal is to allow the managers to add users to their RoleGroup and automate the removal of the user from their previous RoleGroup

     

    The question is how can we achieve this? Do we need to create additional resources and/or attributes? Can we do it all via MIMWAL? Do we need to run PowerShell scripts with the Lithnet module? If the number of RoleGroups grow, does the solution scale nicely?

     

    Any thoughts would be appreciated, cheers.

    Dan

    Friday, September 13, 2019 8:12 AM

Answers

  • Thanks Brian. I ended up going with my initial plan to use a workflow that contains a combination of MIMWAL and PowerShell with assistance from the Lithnet module because we're already doing a lot of processing in the script for other Add/Remove actions that I won't go into in this thread. In summary...

    The workflow is triggered by a request MPR when a user is added/removed from a group.

    I also created two new user reference attributes called CurrentRole and PreviousRole.

    When a user is added to RoleGroup1, that group is added to the CurrentRole attribute. If a user is later added to RoleGroup2, the script checks the CurrentRole attribute and if it contains a value, it copies the value to PreviousRole before removing the user from RoleGroup1.

    PreviousRole is required to prevent the script from performing Remove actions on the user when they were actually added to a second RoleGroup. So if the user is removed from RoleGroup1 because they were added to RoleGroup2, the script just clears the value from PreviousRole and ends. If the user is later removed from RoleGroup2, it would not find a value in PreviousRole and would process the Remove actions as required.

    I don't know if any of that will be of use to anyone but thought I'd share what I've done to at least close this thread.

    Cheers,
    Dan


    Thursday, September 26, 2019 5:46 AM

All replies

  • Hi Dan-

    I expect you could get this done with the MIMWAL. I would define a multi-valued reference on the group object type that stores all the enemies of that group. I'd then add an authorization workflow to prevent adding someone to a group if they're a member of one of the listed enemy groups. 


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Monday, September 16, 2019 1:40 PM
    Moderator
  • Thanks Brian. The idea makes sense but I'm trying to avoid an approach that creates a hard block like this. In reality we're talking 400 users across 40 teams and the amount of chatter that would be generated would not be workable in situations where users don't have correct access, someone making sure managers are available to remove a user from a group at the same time as another manager being available to add the user to a new group...etc, etc.

    That's why we're aiming to let the change go through and automate the removal from the old group. I appreciate the suggestion though!

    Cheers,
    Dan

    Tuesday, September 17, 2019 2:12 AM
  • Hi Dan-

    You can reverse the pattern to do it that way too. You would use an action workflow from the MIMWAL in response to someone being added to a group.

    I'm not clear if there are different sets of mutually exclusive groups or if they all are. If there are different sets of them, I'd do something similar to what I suggested where you mark all the groups that are mutually exclusive. If all groups are mutually exclusive, then I'd have a simple checkbox to identify if it's such a group and have the workflow remove the user from any other groups they're a member of with the box checked.


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Tuesday, September 17, 2019 2:15 PM
    Moderator
  • Have you thought about criteria based groups??

    Rob

    Monday, September 23, 2019 2:45 PM
  • Thanks Brian. I ended up going with my initial plan to use a workflow that contains a combination of MIMWAL and PowerShell with assistance from the Lithnet module because we're already doing a lot of processing in the script for other Add/Remove actions that I won't go into in this thread. In summary...

    The workflow is triggered by a request MPR when a user is added/removed from a group.

    I also created two new user reference attributes called CurrentRole and PreviousRole.

    When a user is added to RoleGroup1, that group is added to the CurrentRole attribute. If a user is later added to RoleGroup2, the script checks the CurrentRole attribute and if it contains a value, it copies the value to PreviousRole before removing the user from RoleGroup1.

    PreviousRole is required to prevent the script from performing Remove actions on the user when they were actually added to a second RoleGroup. So if the user is removed from RoleGroup1 because they were added to RoleGroup2, the script just clears the value from PreviousRole and ends. If the user is later removed from RoleGroup2, it would not find a value in PreviousRole and would process the Remove actions as required.

    I don't know if any of that will be of use to anyone but thought I'd share what I've done to at least close this thread.

    Cheers,
    Dan


    Thursday, September 26, 2019 5:46 AM
  • Thanks Rob. Criteria based groups using something like Job Title would be ideal but it's not an option because sometimes users move between teams temporarily to provide cover and in these cases, Job Title is not updated.

    Cheers,
    Dan


    Thursday, September 26, 2019 5:47 AM
  • Sure.  In our implementation we also have 'exception' groups and 'exclusion' groups which are manually managed.  We then add these to the criteria using 'Resource ID is member of' the exception group so that you can add others to the group that don't meet the initial criteria.  We also use 'ResourceID not a member of' the exclusion group in the criteria if we need to explicitly prevent someone who should be in the group but there maybe a conflict of interest for example which should see them excluded.

    Hope that helps

    Rob

    Thursday, September 26, 2019 8:04 AM