Workflow to notify me that a user was removed from any group

If your sync process is not performing its work through ActiveRoles, then out-of-the-box, a workflow will not detect these changes.

You would have to implement a policy script embedded into a provisioning policy that would be set to react to "native" AD changes.

So on our active roles server, the active roles sync runs daily reading a csv file.  When they Active Roles sync is done, we have it send a email letting us know how many objects were updated.  

I have created a workflow in Active Roles to send email updates for when any user properties are changed, which when the sync runs and lets say mobile number is updated during the sync, I'll get two emails.  1 email is for the sync steps completed and second email for user a mobile number has changed.  

I've also created workflows for add/remove groups and to email the results.  This works if a user support person manually removes or adds a user inside active roles.  I'll get a email for those.  But I don't get emails for any users who are removed from dynamic groups based on not meeting the criteria.  

Like if I change office from Baltimore to new york and the distribution group for baltimore and new york are dynamic where it adds users based on office location, changing the attribute automatically removes from one and adds to the other.  I'm trying to get notifications on those changes.  

Hope that makes sense since all of this is inside active roles

I just re-read your initial post and am confused about one thing:

Some users would like to stay on distribution list that is general to that office so they are in the loop about upcoming events.  At that point we would need to explicitly add them back.

You can't add people to dynamic groups manually unless you modify the group membership rule properties and do an explicit add there.  This defeats the purpose of having the dynamic group and is messy from a day to day management point of view.

Why don't you use a second (maybe virtual?) attribute in the group's membership rule to control / allow these exceptions and use a workflow to watch for changes to this attribute? For example, call it edsvaDLMembershipException and put the name of the office in there.  So let's say you have a Dallas office.  In the membership rule, you would have it look for edsvaDLMembershipException contains (or equals) "Dallas"

All this to say that you are better off tracking / triggering off changes to dynamic group membership control (criteria) attributes rather than worrying about changes to the group itself.

Unfortunately we have way too many exceptions and one offs that don't meet dynamic lists.  Our work around is we have a secondary security group that is nested into the dynamic list.  For instance user A is in app dev but he wants to be on a dynamic list that is for the tax department.  He puts a request in to get added to that list but so the user support guys just add him to the nested non dynamic group and he gets added.  They do this in the web gui of active roles since they don't have access to the server to explicitly allow.  

I'm not too worried about automating the adding back into groups once they get removed because they don't meet the criteria.  I'm more so worried about notifying me about the removal.  

Recently a hire up at my company moved to a new role and his department changed.  He was technically in the Assurance department but went to more of a COO role but he still has a background in accounting.  I know he's still active with the Assurance department so I reached out to him and basically I had to manually change his department back to what it was, do a export in powershell of the groups he was in prior to the department move, then change the department back to the new one, do another export of groups.  Then I sent him a spreadsheet of this is before and this is after, do you want to be included in any of the ones you dropped off of still.

Since our sync runs daily and auto commits the changes, my fear would be something like this happens one day when I'm not around or don't notice it and then we get the "hey why was I removed from these groups" emails.  Just trying to be proactive.  Some groups are fine to be removed from, but depending on the persons level sometimes people are still involved with certain things and want to remain on them.

So that's why I'm just trying to get notifications of when someone gets removed from a dynamic group via the active roles sync

Hello, Sean.

Based on your description, I would venture to suggest that dynamic groups may not be the right solution for your use-case. I would recommend that you consider using Group Membership Provisioning Policies instead. That option will also respond to changes made outside of the product, and in real-time, however the key difference is that a dynamic group monitors both changes made to the members as well as changes made to the group itself whereas a group membership provisioning policy will monitor only changes made to the members.

Hence, if a user's department is changed such that they should be included in the group, then the policy will add them to the group. If, however, you manually remove the user from the group, the group membership provisioning policy will do nothing: it will not attempt to re-add them to the group. Similarly, you can manually add a user to the group, and this type of policy will do nothing. The policy will only evaluate when the trigger condition is modified: changing a user's department, in this case.

This would address your scenario without having to have a second nested group.

I also tested your problem by creating a Change workflow that responded to group membership removal and confirmed your finding: my workflow was not triggered when the user was removed from the dynamic group. For what it's worth, when you manually remove a user from a group in AR, it records a 2691 event in the event log showing the group membership removal request (later accompanied by a 2692 when it completes or 2693 if it fails). This then leads to a 1526/GroupMembershipChange event. When a user is removed automatically by a dynamic group, the 1526 event is recorded - but there is no accompanying 2691/2692. This means that you could potentially generate notification of this event by using event log scraping/SIEM tools, like InTrust, Splunk, etc.

Unfortunately the Group Membership Provisioning Policy that I described above also fails this notification test: a user removed from a group due to a change that leads to their removal from the group, the workflow is not triggered.

My guess is that the workflow is not triggering because change-based Workflow in AR is not capable of being initiated by change events triggered outside of the product. As John pointed out above, you can, however, create a scripted policy in AR that has the DirSync option enabled, thereby allowing it to respond to changes initiated by any source.

Hope that helps!

Cheers,
Shawn

Hello, Sean.

Based on your description, I would venture to suggest that dynamic groups may not be the right solution for your use-case. I would recommend that you consider using Group Membership Provisioning Policies instead. That option will also respond to changes made outside of the product, and in real-time, however the key difference is that a dynamic group monitors both changes made to the members as well as changes made to the group itself whereas a group membership provisioning policy will monitor only changes made to the members.

Hence, if a user's department is changed such that they should be included in the group, then the policy will add them to the group. If, however, you manually remove the user from the group, the group membership provisioning policy will do nothing: it will not attempt to re-add them to the group. Similarly, you can manually add a user to the group, and this type of policy will do nothing. The policy will only evaluate when the trigger condition is modified: changing a user's department, in this case.

This would address your scenario without having to have a second nested group.

I also tested your problem by creating a Change workflow that responded to group membership removal and confirmed your finding: my workflow was not triggered when the user was removed from the dynamic group. For what it's worth, when you manually remove a user from a group in AR, it records a 2691 event in the event log showing the group membership removal request (later accompanied by a 2692 when it completes or 2693 if it fails). This then leads to a 1526/GroupMembershipChange event. When a user is removed automatically by a dynamic group, the 1526 event is recorded - but there is no accompanying 2691/2692. This means that you could potentially generate notification of this event by using event log scraping/SIEM tools, like InTrust, Splunk, etc.

Unfortunately the Group Membership Provisioning Policy that I described above also fails this notification test: a user removed from a group due to a change that leads to their removal from the group, the workflow is not triggered.

My guess is that the workflow is not triggering because change-based Workflow in AR is not capable of being initiated by change events triggered outside of the product. As John pointed out above, you can, however, create a scripted policy in AR that has the DirSync option enabled, thereby allowing it to respond to changes initiated by any source.

Hope that helps!

Cheers,
Shawn