Tip - Action Override User settings

[JasonWalker]

This post is an attempt to demystify some of the ‘action override’ parameters and to provide some useful examples.

General Considerations

• When running a script as a user, the normal user account generally does not have access to the __BESData directory or subdirectories. After creating a script with ‘createfile’ or ‘appendfile’, or after downloading a file through ‘download’ or ‘prefetch’ commands, the content needs to be copied to a directory the user can access.
  Avoid using the ‘move’ command, as when 'move’ing files on Windows, the files keep their original permissions - which still block standard user access. Instead use either ‘copy’ ActionScript commands or ‘copy’ OS commands to copy the content.

• When using the ActionScript override ‘runas=currentuser’, the BigFix Client determines which logged-on user account to use. If there is a user logged in directly to the Console, that is preferred; if not, then any Remote Desktop user or ‘Fast-User Switched’ user session may be used.

• There is no direct inspector to return the same user account that ‘runas=currentuser’ chooses. The current user inspector returns only the Console user, while logged on users gives a plural result of all logged-on users. To retrieve an approximation of what I believe is the same user, in the ‘DOMAIN\username’ or plain ‘username’ (for local users) format that can be used for the user= or targetuser= parameters, I sometimes employ this relevance with good result; but I’d welcome any improvements from the community if you know of other methods.

parameter "preferred_user"="{(preceding text of first "|" of it | it) of concatenation "|" of ((if exists domain of it then domain of it & "\" else "") of user of it & name of it) of logged on users whose (active of it)}"

• To determine a folder I know the user can access, to copy scripts or binaries to them, I have used this statement to locate their profile folder and create a temporary working directory beneath it. In this form it creates a unique folder based on the action ID, that can be removed if you want to reuse the same temporary path for multiple actions/fixlets. Be sure to use ‘folder create’ to create the resulting folder since it should not exist already, before trying to copy scripts or files into it:

parameter "UserFolder"="{(preceding text of first "|" of it | it) of concatenation "|" of profile folders of users of logged on users whose (active of it)}\MyBESContent\{id of action as string}"

• Even when executing a script or file that is located in a user-readable area, the “Current Working Directory” defaults to the __BESData\<sitename> folder. Depending on what your script or tool is doing, that may be important. For example in my test “c:\temp\temp.cmd”, I found I could not execute the ‘ping’ command, instead getting a message about ‘Invalid working directory’. To work around that, I spawn off a cmd.exe that first changes the working directory and then executes the batch file below.

• When using the ‘password=required’ parameter, the Console prompts for the user’s password when sending the action. This is encoded in a Secure Parameter named "action override password". This may be useful from custom Parameterized Fixlets or REST API, to send the password via a Secure Parameter with the correct parameter name.

With that said, on to the Action Override settings and some example usages. Assume the following conditions:

• The user D\TestUser1 is logged on to the endpoint
• There is a batch file “C:\temp\test.cmd” to be executed.

Syntax	Description
waithidden cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	The batch file executes, using the LocalSystem context, and provides no visible window. This is default actionscript behavior.
override wait runas=currentuser wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	The script executes in the context of D\TestUser1. A visible window is presented for the script. The script does not run in Elevated context, even if D\TestUser1 is an administrator on the machine. If no account is logged on, the command fails to execute.
override wait runas=localuser user=D\TestUser1 password=impersonate wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	Executes as D\TestUser1, provides a visible window, and runs without Administrator privileges. < If D\TestUser1 is not logged on at the time, the command fails to execute.
override wait runas=localuser user=D\TestUser1 password="users-password" asadmin=interactive wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	The command executes as D\TestUser1 and provides a visible window. The process runs elevated, even if D\TestUser1 is not a member of the Administrators group. If D\TestUser1 is not logged on, the command fails to execute.
override wait runas=localuser user=D\TestUser2 password="users-password" asadmin=interactive targetuser=D\TestUser1 wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	Executes the script, running as ‘D\TestUser2’ (who does not need to be logged on at the time). The user interface is displayed to D\TestUser1 (who must be logged on at the time). The script is run with Elevated privileges, even if neither D\TestUser1 nor D\TestUser2 are members of the Administrators group.
override wait runas=localuser user=D\TestUser1 password=system wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	The script executes in the LocalSystem account, and provides a user interface to D\TestUser1 (who must be logged on at the time). The script runs with the Elevated privileges of LocalSystem.
override wait runas=localuser user=D\TestUser1 password=required asadmin=interactive wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	The Console prompts for the password for the D\TestUser1 account when sending the Action. The password is sent as a Secure Parameter named "action override password". The script executes in the context of D\TestUser1 . The script runs with Elevated Privileges, even if D\TestUser1 is not a member of the Administrators group, and runs with a visible window.
override wait runas=localuser user=Administrator password=required asadmin=interactive targetuser=D\TestUser1 wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	The Console prompts for the password which must match the local Administrator account. The script executes as Administrator, and runs with elevated permission, and runs with an interface visible to D\TestUser1, who must be logged on at the time.
override wait runas=localuser user=D\TestUser1 password=required wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	The Console prompts for the password for D\TestUser1. The script executes in the context of D\TestUser1 even if the user is not logged on. The script does not executed with elevated privileges.
override wait runas=localuser user=D\TestUser1 password=required asadmin=true wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	The console prompts for the password for D\TestUser1. The script executes in the context of D\TestUser1, and runs Elevated even if D\TestUser1 is not a member of the Administrators group. D\TestUser1 does not need to be logged on for the script to execute.

---

Things that do NOT work

• I have not found any syntax that allows executing a command in the user’s context, while elevating that command to Administrator privileges, without knowing the password of the user account.

Syntax	Description
override wait runas=currentuser asadmin=interactive wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	Command failed (The keyword 'AsAdmin=interactive' can be used when both RunAs=localuser, and Password=required or Password=empty or Password="value" are specified.) wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"
override wait runas=localuser user=D\TestUser1 password=impersonate asadmin=interactive wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	Command failed (The keyword 'AsAdmin=interactive' can be used when both RunAs=localuser, and Password=required or Password=empty or Password="value" are specified.)
override wait runas=localuser user=MyTempUser1 password="MyTempPassword" asadmin=interactive wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	Command failed (RunAsLocalUser : No local session found for user 'MyTempUser1') The documentation at developer.bigfix.com makes mention of using password="string" when using a temporary account. BigFix does not create a temporary account for you. This usage is, I believe, intended when the action creates a local user account for this usage somewhere earlier in the script, and thus knows the users password (which might be randomized)
override wait runas=localuser user=MyTempUser1 password="MyTempPassword" asadmin=true wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"	Command failed (The keyword 'AsAdmin=true' can be used when both RunAs=localuser and Password=required are specified.) ‘AsAdmin=true’ cannot be used with a clear-text string for the password.

[jgstew]

I am trying to do the following to just run the command as a specific user even if that user isn’t logged in:

override wait
runas=localuser
user=MyExistingUserName
password="MyExistingPassword"
wait cmd.exe /c "cd C:\temp & c:\temp\test.cmd"

Not sure if this is possible.

[JasonWalker]

I believe you can, but must use password=required and send the actual password as a SecureParameter.

The secure parameter must be named ‘action override password’

Mapping a network drive from BigFix

Ah, a little bit more digging. When I used ‘Take Custom Action’ along with the ‘password=required’ parameter, the Console sends the action but hasn’t evaluated that a secure parameter is needed. When the client fails to execute the command, it gives an error message with a clue in it - Command succeeded override wait (action:3200) Command succeeded override runas=localuser (action:3200) Command succeeded override user=D\TestUser1 (action:3200) Command succeeded override password=r…

[brolly33]

Another really tricky gotcha.

The override commands cannot have blank lines.
The options and the run or wait have to be all in a row in your action script with no blank lines.

This works (no blank lines)

override wait
RunAs=currentuser
wait Rundll32.exe user32.dll,LockWorkStation

This FAILS

override wait
RunAs=currentuser

wait Rundll32.exe user32.dll,LockWorkStation

Client log entry:

Command failed (Override keyword is unknown for this command.) override  (action:2770)

[JasonWalker]

2 posts were split to a new topic: CIT scan fails on Win2003 without admin rights

[JasonWalker]

One more update to tie everything together.
Scenario:

• Run a batch file as the logged-on user, and prompt the user to run Elevated

Issues:

• The logged-on user cannot access files in the __BESData folder, the batch file must be relocated to a path they can access.
• No built-in Relevance Inspector returns the value that the ActionScript override ‘runas=currentuser’ uses
• No built-in ActionScript Override prompts the user to run elevated
• The syntax for the override ‘runas=localuser’ with ‘user=SOMETHING’ requires DOMAIN\username for domain accounts, but just username for local accounts.

This ActionScript works around each of these issues:

// Create the batch file that will be executed as the user.
// The batch creates a small .VBS file that prompts for elevation and then re-runs the batch file elevated.

delete __createfile
createfile until EOF_EOF_EOF
:: BatchGotAdmin
::-------------------------------------
@REM  --> Check for elevated permissions
@ "%SYSTEMROOT%\system32\cacls.exe" "%SYSTEMROOT%\system32\config\system" >nul 2>&1 

@REM --> If error flag set, we do not have admin.
@if '%errorlevel%' NEQ '0' (
    @echo Requesting administrative privileges...
    @goto UACPrompt
) else ( @goto gotAdmin )

:UACPrompt
    @REM Ensure any previous copy of getadmin.vbs is removed to avoid escalation attack
    @del /q "%temp%\getadmin.vbs" > NUL 2>&1
    @IF EXIST "%temp%\getadmin.vbs"  @echo Unable to clear previous getadmin.vbs, aborting... & exit /B 1
    @echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\getadmin.vbs"
    @echo UAC.ShellExecute "%~s0", "", "", "runas", 1 >> "%temp%\getadmin.vbs"

    @wscript.exe "%temp%\getadmin.vbs"
    @exit /B

:gotAdmin
    @if exist "%temp%\getadmin.vbs" ( del "%temp%\getadmin.vbs" )
    @pushd "%CD%"
   @REM CD /D "%~dp0"

@REM ############################################
@REM Now do the things that required elevation

echo test > %systemroot%\test.out

@REM ############ End of batch script ###########


EOF_EOF_EOF

// Save these values as Parameters so they appear in the client log for debugging
// In the case of multiple logged-on users, we just select the first one returned by the inspector
parameter "user_name"="{(preceding text of first "|" of it | it) of concatenation "|" of names of logged on users}"
parameter "user_profile"="{(preceding text of first "|" of it | it) of concatenation "|" of profile folders of users of logged on users}"
// DOMAIN\ should be specified *only* for domain users.  Local users should have not prefix, not even COMPUTERNAME\user
parameter "user_domain_name"="{(preceding text of first "|" of it | it) of concatenation "|" of ((if exists domain whose (it as lowercase != computer name as lowercase) of it then domain of it & "\" else "") of user of it & name of it) of logged on users}"

if {exists logged on users}
// Create a per-user folder in which to store the batch file (if the action had Downloads they should be copied here as well )
folder create "{parameter "user_profile"}\BES_Action"
delete "{parameter "user_profile"}\BES_Action\test.cmd"
copy __createfile "{parameter "user_profile"}\BES_Action\test.cmd"

// Important - the check for elevation fails in 32-bit mode because \windows\syswow64\config does not exist
// The batch command must be run in native mode
action uses wow64 redirection {not x64 of operating system}

override wait
hidden=false
runas=localuser
user={parameter "user_domain_name"}
password=impersonate
wait cmd.exe /C "{parameter "user_profile"}\BES_Action\test.cmd"

else
 // No user was logged on, batch execution skipped
 parameter "Skipped"="No logged on user"
endif

[JasonWalker]

I uploaded an example task to https://bigfix.me/fixlet/details/26941

Both Actions write a test output to \windows\test.out. The first Action does not attempt to elevate (demonstrating the write fails). The second action prompts for Elevation and displays a messagebox to the user that can be used to customize a message they see before the elevation prompt appears.

[vvignesh6]

I wanted to run a script from currently logged-in user account on non-windows(ubuntu) device.

will the above action help?

I was trying with following command but its failed with exit code=2 for this command.
wait chmod a+x /var/opt/BESClient/scripts/test.sh
wait /bin/bash -c “sudo -u $USER /var/opt/BESClient/scripts/test.sh”

[JasonWalker]

Check https://developer.bigfix.com/action-script/reference/execution/override.html for the override options on UNIX/Linux. Most of the same options work, but some of the ‘password’ options are ignored on Linux/UNIX, they aren’t needed because the agent runs as root and can impersonate a user without requiring the password.

In your sample command, I don’t think $USER will have a value in the actionscript itself. If it does, it won’t be what you expect, it would still be ‘root’ since that’s our account for the BESClient.