Secure Your Endpoint Admin User Account Without Locking Out Your End-Users

The constant struggle between giving end-users control without giving them the ability to blow up their machines has been the bane of Managed Services for decades now. It seems like there are a thousand ways to lock up a machine but few offer the freedom of allowing clients to do what they wish while still protecting the endpoints from harm.

While working with a partner this month we started formalizing an interesting process for controlling endpoint permissions so that you don’t have to do all the admin work on your client’s machines but you can also feel safe locking down the endpoints and limiting administrator access without bothering your clients.

This guide assumes that you are going to make endpoint user accounts regular users and have removed admin credentials from end-users.

Kaseya’s Set Credential Command

Kaseya has a built-in setting called “Set Credentials”. Set Credentials typically allows Kaseya to run tasks at the user level on a machine instead of at the system level. This opens up a few additional features in Patch Management and in Kaseya’s Agent Procedures.

Set Credentials is not 100% required for Kaseya to do its job, but it can be good to have especially if you are trying to access network resources which the System account would have no access to.. The problem is that credentials can change from machine to machine. At Network Depot, we create an local administrator account specifically to allow us to manage the machine and use Set Credentials to tell Kaseya to use that. In fact, you can reset the password from inside of Kaseya by going to Remote Control -> Reset Password. This section also allows you to create administrator accounts on the machine that you can use with the Set Credential command.

Assuming you’re running an Active Directory server you could might want to setup a Active Directory Domain admin which would allow Kaseya to gain administrator rights on endpoints as well. In that case you would tell Set Credentials to use the Domain.

If you choose to go the Local Account direction, then there is a small problem which we can resolve with a handy script. If created through the Remote Control module, then the new admin account may be visible to the end user on the login screen (Local Login). This usually creates a lot of unnecessary questions about “who” that person/account is.

So instead, use this script to create a hidden admin account. It will hide the account so that it is not visible on the login screen.. This will allow Kaseya to move freely without you needing to worry about allowing admin access for the end user.

If you do setup a local admin account, especially if you use a common password, you are creating a (minor) security risk because your end-users (or outsider) could discover the account that you use across all the machines in their office (and possibly across all your clients depending on how security conscious you are!)

But what if the end user wants admin privileges?

Giving out admin credentials to the Kaseya admin (Management) account is not a good idea because you likely use the same password across the entire client, and if you gave the password to an end-user, you would not only have to change the password on all the other machines, but you would also have to have to update Kaseya’s Set Credentials in order to continue to use that account inside of Kaseya. This can become cumbersome.

If you lock down the machine, you are going to have end-users who want to install new software, make updates, or anything else that requires them to have admin access to their machine. It is probably not cost-effective or smart for you to insert your company in the middle of what is going on so it makes sense to have a “throwaway” administrator account that you can use to give your client access to on a temporary basis.

The Change Password Agent Procedure that our team put together is the perfect solution for these unique situations.

It basically works like this:

Using the Create Hidden Administrator script, you mass create a local admin account on your client’s endpoints. Then you execute the Change Password script to randomize the password on the local admin account. This password will be stored in a Kaseya Custom Field, so that the next time you want to access this admin account then you will simply look up the current password.

Want to secure it even more? Just schedule the change password script to run on a daily or weekly basis and the passwords will automatically scramble on each machine every time the script is run. That way you can give out temporary admin access to a machine without compromising your admin privileges across the board.

Then you can give admin access to a local machine and remove that access any time you like. This lets you empower your end users to operate as an admin when they need to without compromising the security of your entire network.

It certainly can come in handy!

At the end of the day we are thinking to have 1 account that is either a domain admin account or a hidden local admin management account with a common password that you update in Kaseya’s Set Credentials. You then have a 2nd Local Admin account that is the account for the local user. You could take that one step further and keep the password for the Domain/Management account super-secret (not even the techs know it, only management). The techs would use the “Password of the Day”, located inside Kaseya, if they had to do something to the machine. In the event of an employee turnover, there would be nothing to worry about.

Your thoughts are welcome!