Not sure if this is the appropriate forum category, please suggest a better one if I should post elsewhere…
GOAL: Allow BigFix console operator initiated actions to only work on Windows endpoints where the operator’s domain account has been elevated to administrator. Prevent operators from being able to to take any action where they do not have elevated rights.
PROBLEM: BigFix client runs under system account. Any action taken against an endpoint gets run as system and no change control is in place for the servers visible from the operator’s console
POSSIBLE SOLUTION:
Any/all information is welcome with how to accomplish this. I have discovered from the forum how to use secret parameters (thanks brolly33) and how to accomplish running an action as another user with “override”.
Thanks to JasonWalker for his post making sense of the command for me Tips for using override
Using Override, I can have the operator enter credentials before taking an action. I could then use a pre-execution script to test that user’s rights on the target system. If the pre-execution script passed the test of “Does this user have admin rights” then I could allow the rest of the action to execute. If they do not have admin rights the script would abort.
The console operator’s ID is associated with a change in the ticketing system and get’s automated elevation when the change window opens. This would allow the operator to have access to apply changes using bigfix only on systems where they have an approved change and only during the window of the approved change.
I’m not aware of a way to enforce this ‘pre-execution’ check, but if I could, I think I could use this to expand the usage of BigFix in the environment.
Anyone aware of how to enforce pre-execution task on the endpoint that cannot be circumvented by an operator?
One way I am thinking, you have ActionScript that starts by executing a script that does your checks and if user passes, the script will flag a setting maybe a registry key (of file for other OS) that can then be used by ActionScript and relevance substitution to control if the rest of the ActionScript code runs, As a very simple mock up
// Your code that does checks and writes a reg value to control the rest of the ActionScript
waithidden powershell.exe -command "new-item -path HKLM:\Software\MyKey; set-itemproperty -path HKLM:\Software\MyKey -Name 'MyValue' -value 'Passed' -force"
// If the first checks passed, this next part of the ActionScript would be processed
continue if {exists value "MyValue" whose (it as string = "Passed") of key "HKLM\Software\MyKey" of registry as string}
// Do your other stuff here then clean up the reg key
regdelete "[HKEY_LOCAL_MACHINE\Software\MyKey\MyValue]" "MyValue"
Not to be too cryptic but my understanding is that, from a security perspective, it is not a good idea to distribute administrator credentials regularly to endpoints even using secret parameters or waithidden override.
A compromised device can be used to exfiltrate administrator credentials and tokens if it’s been targeted by one of these actions.
I’ll post more on this topic later but I’ll need more coffee first. The short version is
Don’t send Windows Admin, esp. Domain Admin, credentials to the endpoint. Not through BigFix, or PowerShell, or Scheduled Tasks, or any other method. There are a number of tools that can “dump the hash” of passwords cached on Windows, and one of the lovely things about BigFix is that we don’t need them.
Don’t rely on a script the operator runs to determine whether the operator should be allowed to run it. There’s too much exposure. Does the operator have “Custom Content” rights? Then they can change your action to take the enforcement out of it.
The two main approaches I see are to either change their rights in BigFix to align with their permission (don’t give them operator rights on the machines they should not manage), or don’t give them BigFix rights at all, use an API integration to send actions under a service account and limit their rights to use the custom actioner. For instance have ServiceNow send the actions on their behalf instead of granting them an Operator at all. We have some customers who have built systems like this, and in our Professional Services group we have built systems like this for customers.
Thank you for replying. My main issue is how to lock this down and whether it is a good idea at all. Looks like JasonWalker and Strawgate have issues with the security of it overall.
Hello sir. Thank you for your reply and for your valuable posts over the years. These concerns would be mitigated somewhat by using credentials that are only ‘administrator’ level during the change window and only for the specific related Cis in the change. Even so, your point is well taken and indicates I’m not on the best path to solve BigFix ticket integration with automated elevated access.
Hello sir. Thank you for your reply and your valuable posts. With you and strawgate pointing out the security concerns here, I think I’ll need alternative approaches. Thank you for your suggestions. The issue is we can’t have anyone with standing execute rights to the BigFix console regardless of the population visible to the operator. We have to leverage separate accounts that are checked out after a series of approvals and controls. There are lots of these checkout accounts with a specific population of endpoints visible to them, based on the endpoint’s function and/or sensitivity.
It would be far simpler if an operator could see the entire endpoint population from the console, but only take actions against endpoints that have an associated, approved, change ticket.
I’d love to know more about the API integration with service now. Can you share some information on that solution or contact info for the Professional Services group?