Secure Your Endpoint Admin User ...

Author Archives: Dan Kolansky

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!

Scripts Included in this Blog:

Etiquette For The Easiest Mail Encryption Service In The World

One of the most popular offerings we have right now is Mailprotector’s Bracket Email Encryption service. And for good reason, Since its release Bracket has gotten so popular because it allows you to send encrypted messages without the need for a username / password or the requirement to download special software or install certificates on…Continue Reading

CloudJumper 3 Years Later

It is hard to believe that it has been 3 years since we announced our “MSP 4.0” model to the world. Our partnership with CloudJumper has been one of quiet resiliency over the last three years. But we have been taking a close look internally at the service and if it has been worth it…Continue Reading

The Spectre/Meltdown Fiasco Continues

The fallout continues from Intel’s Spectre firmware update coupled with Microsoft’s patch cycle. Microsoft just released a new patch that disables Intel’s firmware update citing random reboots as an issue with the Spectre patches. So, where do we stand now? While Spectre and Meltdown are considered pretty massive security flaws, there aren’t any reported exploits…Continue Reading

Meltdown – Look Before You Leap

UPDATE 1-12-2018 Two scripts were updated to new versions. They are linked in the original article below. Update to add link to this week’s patch blog. ~~~~ If you aren’t living under a rock I’m sure you have seen the recent news surrounding Intel and virtually every other CPU manufacturer in existence. The two security…Continue Reading

$10 / User IT Service? The MoviePass Argument

Earlier this week there was a huge announcement made by the company MoviePass. For those unfamiliar with the service, MoviePass offers all-you-can watch movie tickets (with a few stipulations) for one monthly price. It sounds mighty familiar to the MSP’s mantra of “All-you-can-eat” service contracts. However, at the beginning of the week, MoviePass did something…Continue Reading

Copyright © 2007-2017 Network Depot LLC DBA Virtual Administrator. All Rights Reserved.