One of the challenges we had on our MSP side is dealing with how to setup and manage a local admin account that can be used by our techs. Historically there are a few ways to handle this.
- Use a Domain Admin account. – This is fine in most cases, since the Domain Admin is already a member of the Local Administrators group for any domain-connected machine. But what happens when it is a stand-alone laptop, or we need to boot in safe mode, or loses connectivity with the domain for long enough that the cached credentials don’t work?
- Create a common Local Administrator account. This is what most people have, but what about the password? If you are like many MSPs that password is the same across ALL your clients. In today’s world, YIKES! Maybe you are better than most, and actually create a separate password for each client? Better, but that entire client is exposed if the password gets out. What happens when a technician leaves your employee? Are you going to change and record that password across ALL your clients?
What if the client is stuck with no internet (no remote control) and needs the admin password to install or update something? You certainly aren’t going to give them the Domain Admin, or even the common Local Admin password!
What if we could use automation to solve all these issues? What if we could set an individual password for EACH workstation? What if we could change that password every couple of days or weeks?!
You could even give the password to an end-user, knowing a) it would be changed automatically, and b) that password ONLY worked with their computer!
Well, the Virtual Administrator scripting team has done just that! We have a new script called “Password Generator to change Admin PW”. In short, this script will:
- Prompt you for your desired Admin name (you can set this permanently in the script, see PS below)
- By default, set a “complex” password to 12 characters (you can change this in Line 4 of the script)
- Do some error trapping and email you in case the account creation or password reset fails.
- Update a custom field in Kaseya with the new Password.
Just schedule this to run every few days, and you now have a secure password solution!
Two Caveats
- This should probably ONLY be run on Windows Workstations. While you could probably also create a local admin on a NON-Domain Controller server, running this on Domain Controller would be BAD!
- The passwords are stored in clear-text in a Kaseya custom field (you need to create this field ahead of time!). Clearly (pun intended), this is a risk, but my feeling is that if they have access to Kaseya and can read that field, you have bigger problems on your hands! Even if someone got a copy of the SQL database, because the passwords change frequently, it would be of little value. Prior to this script, we had a script that set the Admin account and the password was in the script, so there was always a risk, but much less of one now!
Try it out and let us know if you have any questions or suggestions for improvement.
Stay safe!
Chris and the VA Team!
PS. We had a good question: “How can I make the admin name fixed inside the script?”. (This is necessary if you want to make this part of a policy since a policy can’t prompt for the admin name.)
Here is how you do it:
In Line 1, change the “Prompt when Procedure is scheduled” to “Constant Value“, and then change the “Enter Admin user… ” prompt to the name of your administrator, and keep user as the variable.
Before:
After:
