Permissions To Cancel Actions

Hi folks:

In our BigFix (9.2) we have some teams working in different areas (security, patch, etc.). For best practice and security reasons we only have one admin user.

In my team, in some cases, we need to cancel the actions sent for other member of the team, but we don’t have permissions to do that.

Is there any way to cancel actions sent for other users (without be an admin)?

Thanks!

1 Like

To Stop an Action issued by a different user, you MUST be a Master Operator (I think that’s what you mean by Admin).

I’d vote for an RFE on this in a heartbeat. The limitation is definitely an issue for me as well.

Isn’t that the point? That you need to think twice before you can stop another operator’s action? (like UAC in Windows)

We have use both Master Operator Account and Non Master Operator account. We start the day as a NON MO account and when we need Master Operator we switch… Then you’re sure and can’t be mistaken :slight_smile:

That doesn’t give much of a delegation model though.
Given a deployment of 200,000 clients, 200 Operators, and 4 Master Operators…where the normal operators are delegated rights to a subset of the endpoints. You may have a number of different “management scopes”. Consider “Scope 1”, where 20 Operators are assigned rights on 10,000 endpoints. They can all take Actions against their endpoints, but sometimes one of them may need to stop another’s Actions. We don’t want to assign them Master Operator credentials, which means that they will have to call in one of the Master Operators to do that for them. The Master Operator probably knows very little about the endpoints within their scope, or whether stopping the Action is a valid/authorized action (which is why the Master Operator delegated authority to begin with).

What I’d like to see would be a functionality where we can define “Members of role Scope 1 can stop the actions created by other members of Scope 1”. Or, better yet, subdivide it further to say “Members of role Scope1_Elevated can stop actions created by members of Scope1_Junior, but members of Scope1_Junior cannot stop actions created by members of Scope1_Elevated”.

2 Likes

I work in a 24/7/365 Industry, and we have a similar desire to allow a group of Operators to stop Actions that they did not issue.

The way we are planning to resolve this need is to configure a group of our Operations Staff as Master Operator accounts that require “Four Eyes” Authentication from an Operations Shift Manager. We man our Ops Center 24/7, so if someone ever needs to stop “someone else’s” Action, they can contact Operations who can then verify who they are talking with and under controlled conditions, stop the requested Action if appropriate. Stopping the Action would require 2 Operations Staff members to agree that it was appropriate, and authenticate the activity.

That’s pretty interesting. Do you think it’s possible to configure those Master Operators themselves, to require Four-Eyes auth from an empty group (so that these Master Operators can approve the actions of underlings, but not submit new actions themselves)?

We’re pretty sensitive to adding new Master Operators just for stopping actions, we aren’t comfortable with them having access to modify Sites, Subscriptions, or taking actions.

I hadn’t considered that type of setup. I’d recommend you try it, in a test environment if you have one, and see.

Yea this one is a big strike for us. I would at least like to see the ability to give an operator “stop anyone’s action” without assigning them full system administration.

Here’s an RFE regarding: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=27980 . Hopefully the “Planned for Future Release” status is accurate.

Someone in our org looked into a rest api page that could just stop an action given an ID but I don’t know why he never finished.

Hi

Just FYI

Looked into the REST API real quick (PowerShell):

add-type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(
            ServicePoint srvPoint, X509Certificate certificate,
            WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

$user = $env:USERNAME
$cred = get-credential -Credential $user.toUpper()

$PostUrl = 'https://x.x.be:52311/api/action/193835/stop'

Invoke-RestMethod -Uri $PostUrl -Method Post -Credential $cred

Result with NON master operator:
Invoke-RestMethod : {“format”:“Access is denied”,“arguments”:[]}
At line:21 char:1
+ Invoke-RestMethod -Uri $PostUrl -Method Post -Credential $cred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

With master operator:
No error and the action is stopped in the console…

That would be expected. The model as it currently is requires Master Operator privileges to cancel another operators actions.

The previously mentioned RFE is in the correct status by the way.

If this is really a major halt for you guys and you can’t wait for an RFE it seems like you could, in a pinch, pretty easily write an asp.net (or your favorite web flavor) webpage that takes an action ID and stops it using the credentials of a master operator over REST API in the background.

You could even email the original actioning operator (or an email list) when stopping the action.

I know it’s not a perfect solution but if anyone is really hung up about this there are a ton of ways you could utilize the REST API and some web-foo to come up with a stopgap solution.

2 Likes

Well, that’s what we do… We wrote our own “application” (a simple PowerShell with GUI) and give this to people who need to take actions but who we won’t give access to the console. So we list up which actions they can send, they have a dropdown list of actions and just select it, give in the hostname and the REST API creates the action.

So to stop actions, it would be perfectly possible too… :slight_smile: