Changing local user password on clients?

(imported topic written by MikeP23)

Has anyone identified a way of creating a fixlet that would be able to change the local administrator account password for BES Clients? It would be a really useful task but I can’t quite get my head around the win-actions needed for a customer.

Also, does anyone know of a way of removing specific users from local groups on Clients (for example, looking for specific users in the local Administrator’s group and then removing them)?


(imported comment written by brolly3391)

Hello MikeP,

We have covered your first question in previous threads but I like the title of this thread so lets review:

BigFix can be used to change the password on your local administrator accounts but

not securely

. Anytime you use a distributed method to send a password to an endpoint, that password is vulnerable to capture and compromise. In this case the new password is in plain text on every machine that subscribes to the site with this fixlet as well as on the BigFix server.

I will show you how to do it but you have to understand the security exposure.

The local admin account in this example task is administrator. New password is p4$$w0rD. I know the net.exe command is available on Win 2k, 2k3 and XP, maybe more.


exists member whose (it as string as lowercase contains “\administrator”)of local group “administrators”


RunDetached {pathname of system folder}\net.exe user administrator p4$$w0rD

To reinforce this point, go ahead and create the above task in your development environment. Don’t deploy it, just create it. Note the ID of the new task in the tasks pane of your console (this column is off by default so you might have to turn it on).

Now go to one of your test machines that subscribe to your actionsite. Perform a file search for the ID number of the task you just created in the folder c:\Program Files\BigFix Enterprise\BES Client. Open the file Fixlet


.fxf. You will see the password exposed in cleartext without even taking an action from that task.

other related threads:

RunAsCurrentUser (post #11 and on)

password on service

VNC password

Your second question can be taken care of without the above concerns as the password is never transmitted.

Sample where account to be removed from local admin is named RemoveMe:


exists member whose (it as string as lowercase ends with “RemoveMe” and it as string as lowercase starts with computer name as lowercase) of local group “administrators”


RunDetached {pathname of system folder}\net.exe localgroup “Administrators” “{computer name}\RemoveMe” /delete

You could also substitute in a domain name instead of {computer name} to remove a domain account from a local group.



(imported comment written by MikeP23)

I see…splendid, thanks Brolly

(imported comment written by manna91)


I am using vncserver on HP-UX and vncviewer on Windows XP. My display on the viewer (in my PC) is not showing properly (poor resolution) when I bring up vncviewer. Thexstartup file I used is shown at the end of the message.

However, the problem goes away if I type, " xterm -sb & " on one of the (poorly displayed) windows to bring up a new window. The new window is fine. Any ideas as to how to fix the problem from the start (i.e. without the extra step of typing the xterm command)?

-----xstartup file-----



-r $xsession

&& exec $xsession

  1. Fall back if the script wasn’t readable or the exec failed

xrdb $HOME/.Xresources

#Uncomment the following two lines for normal desktop:


#exec /etc/X11/xinit/xinitrc

http:// -r $HOME/.Xresources

&& xrdb $HOME/.Xresources

xsetroot -solid grey

vncconfig -iconic -nowindow &

xterm -geometry 80x24+10+10 -depth 16 -ls -title “$VNCDESKTOP Desktop” &

twm &

(imported comment written by Shawn_Jefferson)


I have created a fixlet that prompts for the password to set the local administrator account password to (using parameter of action). How does that affect the security of the password? (ie, where would it be kept and who could see it if they were looking?)

PS. I noticed that you used RunDetached in your example. Any reason to use that other than RunHidden/WaitHidden?



(imported comment written by jessewk)


You are very strongly discouraged from attempting to change passwords using BigFix.

In your scenario the password would be available in plain text on every single BigFix client in the client data folder (__BESData). Further, it would be accessible in plain text via http on every relay and your main server. If you have a relay in your DMZ it would be available in plain text via http to anybody on the internet.

Please consider these implications very carefully before chosing to use your Fixlet.


(imported comment written by Shawn_Jefferson)

That doesn’t sound good. :slight_smile:

What about using a compiled batch (such as winbatch) or similiar to change the password, and then deleting the file from the download directory aftereward. Or is it the case that each tasks files are always available on the relays and anyone can get them via http?


(imported comment written by jessewk)

Compiling the password into an executable will only obscure the information from casual inspection. Any determined attacker worth their salt will be able get around your attempts. For an extended discussion, see this post (make sure you make it to the 2nd page):

Note that even if the compiled executable is removed from the client machine it would still be easy to hit URLs on the server or relay to download a copy.

(imported comment written by balexph3291)

Once the task completes will the Fixlet ID file get deleted the contains the pwd?

(imported comment written by BenKus)

If you stop the action and delete the Fixlet, then the file will go away (eventually)… there are some archives left on the server for diff reasons… but we don’t recommend you send passwords like this because it is visible anyone pretending to be a client.


(imported comment written by SystemAdmin)

Dredging up an old thread here. When I created the task above and tested it, it appears that the FXF file is encrypted in some way. Have things changed in the way Bigfix processes these tasks since this thread was created? Is it now safe to change passwords through the process above?

(imported comment written by BenKus)

Nope… Same mechanism… Why did you think the .fxf file was encrypted?


(imported comment written by SystemAdmin)

Not the entire file - just the end. I can see how it is encoded base64 - but when I convert it to ASCII, it still looks obfuscated. Just having a tough time finding where in the file the action script is, and more importantly where the clear text password is shown.

(imported comment written by SystemAdmin)

Is it something obvious? I just cant figure out what I am missing here.

(imported comment written by BenKus)

The encoded block at the end of the .fxf file contains the signature of the Fixlet that is used to verify the authenticity of the message. Data from the Fixlet is not put in that block.

If you put a password in an actionscript then it will be visible in the fxf file as clear text.

Zak is working on something that might be interesting in this area:


(imported comment written by Kerni91)

Ben Kus

If you put a password in an actionscript then it will be visible in the fxf file as clear text.

Yeah, that’s the point i missed out too. Helped me much!

(imported comment written by samuel7791)

Would there be a way to change the password of the user on the local machine but with the criteria that it has not seen the BigFix server for the last 7 days?

(imported comment written by BenKus)

I can’t think of a good way to do this… The agent doesn’t know what the server sees…

(imported comment written by BenKus)

Anyone interested in Local User Management and changing passwords should look at:


(imported comment written by Andrew_TEM)

Bringing back up an old topic here.

How have the improvements made in v9 with Client Mailboxing affect the above scenarios with changing passwords via fixlets in Endpoint Manager?