Hi Guys
Why is it possible for a non Master Operator to change/add the computer settings? And is there a way to disable this? I think this is not logical that a non master operator can edit/add computer settings…
I would like your input on how to “solve” this “problem”.
Thanks guys.
I create Fixlets to allow Console Operators to manage Client Settings. I don’t know why it requires a Master Operator to manage Client Settings in the Console.
Ok, but how do you forbid them to manage the client settings? You create fixlet, but what if they just do it straight away? What if a Console Operator just changes the whole relay structure (by accident or on purpose)?
In general, console operators SHOULD be able to manage client settings for the computers they manage.
It sounds like you want to prevent the right click, edit computer settings in the console?
If you have a problematic console operator, you could enable 4 eyes for them, which would keep them from doing anything without review.
I just want to prevent that first line/2nd line support can manage settings without we noticing…
What is the “4 eyes” for them? That they need to check everything they do with a trusted operator? (not that it’s the case, we don’t have problematic operators 
)
@jgstew
You mentioned that “console operators SHOULD be able to manage client settings for the computers they manage” but in our environment we have operator groups we enabled every access level setting except “master Operator” and we’re not able to edit computer setting on systems that group manages. What setting would allow non-master operators to edit computer systems? We’re trying to allow these groups the ability to edit computer settings but can’t seem to find the settings. We’re currently running BigFix 10.0.2.
Also what is that “4 eyes” thing you mentioned above? Sounds like something we could find useful.
Thanks in advance!
An operator who has management rights over the computer, “Custom Content” rights, and “Take Action” rights should be allowed to edit a computer setting.
There is a nuance to creating a brand-new, never-before-seen setting in the “Edit Computer Settings” dialog though. If this is the first time a setting is being used, a Global Property is automatically created to retrieve the value of that setting from clients. I don’t know off-hand how that interaction works with a non-master-operator (either the setting gets applied without the Global Property, or the ability to create the new setting is blocked).
I should be able to check on the behavior later today.
As a Non-Master Operator, you can edit any existing settings that have a value on the computer. However only those settings that already have a value are displayed:
If you click the “More Options” button at the bottom, select the “Custom Setting” checkbox, you can add any setting that already exists anywhere in the deployment, even if it does not currently have a value on that specific computer. However you cannot create a new setting that does not already exist from the global properties list:
To create an entirely new custom setting on one of the computers, you would need to take a custom action. Here’s an example Action Script that should do it:
setting "MyCustomSetting"="My Custom Value" on "{parameter "action issue date" of action}" for client
Awesome! thanks for that information. I can create custom settings using the Action script you showed.
You don’t happen to know anything about what @jgstew was talking about enabling “4 eyes” do you? Having a feature that will require an approval or second set of eyes for deployment would be super useful. Thanks again.
I…am aware of four-eyes. I’m not a fan honestly.
Using four-eyes is a great concept but has some serious drawbacks too.
No approval queue - the second set of eyes has to be live, with you, when you take an action. Most customers set up a Teams meet to send actions that way.
Four-eyes requirement and setting approval role has to be applied to individual operator accounts, it cannot be inherited from a Role. This is a problem with most of my larger customers that auto-provision operator accounts based on LDAP group membership.
WebUI currently has no four-eyes ability. I think that may be on the roadmap still but I’m not certain of that.
That said, it can be useful especially if you have some “junior operators” who you’d rather not have full control.
I personally prefer a couple of other options - we have masthead options we can set through BESAdmin that will give a “summary preview” of your action before you take it, and another to force re-entering your own password when taking any action. Either or both of these can go prevent accidental actions.
Every time four-eyes comes up, it reminds me of this scene from war games…
TURN YOUR KEY SIR!
I totally agree that the implementation lacks, but was done within the limitations of the existing architecture. Do I smell a BigFix Idea cooking?
For me, the problem with 4-Eyes is that it doesn’t work with SAML Authentication at this time.