This sounds like something you would do from Active Directory rather than from BigFix.
You can join groups from an Endpoint using PowerShell (see Add-ADGroupMember) but this will obviously require domain privileges.
Doing it from the endpoint seems more than a little backwards to me, as you’d have to run in a user context or provide credentials with access to Active Directory. Remember that the BigFix agent by default runs everything as the local system account on each endpoint.
This could be done with an action script using wait with the very cool override run as a specific user function.
override wait
runas=jgo@bigfix.local"
asadmin=true
user=TEM\User1
password=required
wait “{pathname of system folder}\cscript.exe” “{((pathname of client folder of current site) & “__Download\scriptName.vbs”)}”
here is a link to an example vbs that you could use. I would want a better one as I don’t like using vbscript anymore… perhaps someone has a more elegant solution?
That would require that the logged in user have the necessary rights in Active Directory to modify the group, correct?
I still maintain that this isn’t something I would do from the endpoint itself, but rather from the AD side directly, perhaps using data FROM BigFix if necessary.
EDIT: Also, wouldn’t this expose the password in clear text? An alternative would be to use secret parameters to pass an encrypted password to the action script, but actions using secret parameters cannot be issued dynamically.
So again, I come back to why this action needs to be performed from the endpoint directly instead of at the AD architecture/operations level.
Because when your only tool is a hammer, every problem looks like a nail…
If it must be done via Bigfix, I think the better option is to target the action to a Domain Controller, and send the computer name as a parameter. When the action is run on a DC, the LocalSystem account should be able to manage the group so you don’t need to deal with credentials.
You can create Auto Group which will pull only PC are on Global Security Group. You can ran Fixlate/Task on that group with Dynamically Target By property to make task Automated.
The following considerations about the RunAs=localuser keyword apply to users defined on Windows systems only:
You can specify a domain user by using one of the following formats:
"user@domain" where domain is an active directory domain, for example "john@tem.test.com".
"domain\user" where domain is specified in the short domain name notation, for example "TEM\john".
Note: The action runs even if the specified domain user has never logged on the target system before then.
So I think I should have used:
override wait
**runas=localuser** // while this does specify localuser the next line uses a domain user to launch the process that launches csript.exe
user=jgo@bigfix.local
password=required
wait “{pathname of system folder}\cscript.exe” “{((pathname of client folder of current site) & “__Download\scriptName.vbs”)}”
In this case it does not matter what the local users rights are as I am using a domain account.
The password I would modify to be a secure parameter if that was a concern.
IMO it looks like a hammer. I would run it from the endpoint directly assuming this is a one time config, for instance in a server or workstation build.
// **syntax to run an action as a user that is a **local user** on the Operating System:**
override wait
runas=localuser
user=testuser
password=required
timeout_seconds=360
disposition=terminate
wait mkdir "c:\tmp"
// **syntax to run an action as a user that is a **_domain user_**:**
override wait
**runas=localuser** // while this does specify localuser the next line uses a domain user to launch the process that launches csript.exe
user=jgo@bigfix.local
password=required
timeout_seconds=360
disposition=terminate
wait “{pathname of system folder}\cscript.exe” “{((pathname of client folder of current site) & “__Download\scriptName.vbs”)}”