Is there any way to restrict an operator or role from pushing mass actions? We’ve just had an incident where a tech accidentally pushed an action, dynamically, to all assets. Fortunately it was pretty much an empty task with no serious ramifications, but I’d like to find a way to avoid this going forward. Anything built in?
Thanks
We didn’t find anything for this.
There is a feature that seems promising – four eyes authentication for actions. This would require an approver of actions before they actually make changes to an endpoint.
Turns out the feature is very poorly implemented and doesn’t really work for 99.9% of use cases.
Where we would have liked to have seen a queue of actions to be approved with designated approvers you instead get two authentication prompts (making this impractical).
Sorry, I have to completely disagree with this. I’ve seen four eyes actively used as part of a business process and it does exactly what is described - require a second set of ‘eyes’ to review an action and approve it for release. I don’t know what other magical confirmation action you’re expecting it to do.
Now, would I prefer it was implemented where you could send actions and leave them as ‘pending’, waiting for approval - yes.
But does it work as implemented - yes. Perhaps rather ‘awkward’, given how simple it is to send an action, but therein lies the rub…making it harder to ensure more effort is taken to confirm actions are appropriately targeted.
jwilkinson is right and I guess I could have been more specific.
We have a very dispersed IT staff with lots of staff working from remote locations and working from home.
The four eyes approval will work alright if you have people collocated in the same room/wing. It is awkward but it will definitely work.
For situations where people are not together, the common process was to temporarily provide remote desktop access for the ‘approver’, send the action and disconnect. If someone has a few to do, they would generally gather the requirements, have their plan and then work at setting them up.
Again, workable, but not necessarily that convenient.
P.S. - This is also why it’s been done differently with ‘other’ products. 
I believe it is possible to warn the user if they select too many endpoints, but I think that is only if they select them specifically, not dynamically… though I’m not completely certain.
You’re correct @jgstew
It would be interesting if it were possible to prevent certain operators from targeting “All Computers”. They would be expected to either always target specific endpoints, or target specific+groups.
There would always be a way of targeting everything through some kind of property as long as the operator can target by property. For example I target only those computers with a CPU brand of Intel. That’s going to get a LOT of endpoints.
I typically have the operators’ default Action Settings configured to use a Constraint (Execute only when…client setting “PatchWindowState”=“Open”). This way, unless they specifically clear that constraint when they use the Take Action dialog, the action will only be executed by clients that are in an active maintenance window. We have different batches of machines enter maintenance windows on different schedules (staggered over weeks), so there’s time to review actions before the client actually runs them.
Of course this isn’t a security control, any operator can easily clear the constraint. But it does help with careless clicking, and there’s a chance to notice that an action has thousands of clients reporting “Constrained” when we didn’t expect the action to target so many.