Kaseya Community

Looking for Feedback

  • We occasionally get a call from an end-user that needs local admin access to install a printer driver or some other component that prompts with UAC. Not difficult if the user is online and connected to VSA, but challenging if they are not. We don't want to give out our local admin credentials, and the Administrator account is disabled on most newer platforms. We wanted a local admin account that would only be used for such situations and would change regularly.

    After the last time this happened, I created an application to pull a list of agents from the VSA, filter on workstation platforms, then generate a random 14-character password, passing it to a procedure to run on an agent - each agent gets a unique password. The procedure creates the account if necessary, sets the password, and if successful, writes the password to a custom field. The password is salted using the uptime and part of the hostname from where the application is run from and part of the agent name, making it impossible to duplicate. The process runs fast enough (about 11,000 agents/hour) that it could be run daily, and the custom field isn't changed unless the credentials are successfully created/updated. The application can run from scheduled task on the VSA or any system with a Kaseya agent. The procedure can be adapted to write the current password to a database or password management application instead of the custom field

    Would this be a useful addition to your tool chest?
    Are there concerns with putting the password in the custom field? (I don't see any, since if you have access to VSA, you probably have access to create your own account/password.)
    Would any other capability or feature be useful?

    Thanks!

    Glenn

  • Sounds like an awesome idea - perhaps tho using SQL to inject the password to the built-in agent credentials within the VSA would be a great touch - that way this could be used for patches and other procedures pushed from the VSA when the agents are connected.

  • Did you look at (Remote Control>Desktop Control>Reset password)

    Wasn't this helpful?

    This is kaseya inbuilt procedure to create a local user or reset local user password.

  • The point of our tool was to create a unique password on every workstation that could be given to the end-user at a time when the user does not have network connectivity but needs local admin access at a UAC prompt for some task, such as connecting to a local printer.

    It's not a common condition, but unless you create an account and store the password in advance of the user needing it, you're limited to either exposing your common credentials or denying support.

    The Reset Password option would require a lot of manual effort to create a UNIQUE set of credentials on every agent. It's really designed to deploy common credentials to a group of systems. This is more appropriate for MSP or local IT use than for an end-user. (we typically never grant users local admin rights, BTW.)

    We have procedures to create MSP and Customer local admin credentials during onboarding and when needed to update the password. These accounts are used by support staff and never given to an end user because they are the same within the user's environment. Our process would limit access to a specific machine because every agent has a unique and random password.

    Glenn

  • One of the things we've contemplated similar to this Glenn is instead of having a password that is put in the custom field, doing some type of challenge response.  Where the account is "known" to the local application running on the PC, and instead of storing the password on the VSA a new "token" is created on a timed interval as long as the machine is connected to the VSA.  (Thinking something along the lines of a public key/private key encryption system).  Then when the end user's PC is not connected to the Internet or the VSA for one reason or another and they call up needing admin access for some reason, they launch the local app (from the system tray?), and it prompts for the "Challenge" key which the tech can then read from the custom field.  The local app then either gives them local admin privileges for a specific amount of time, or something similar.  Haven't worked through all the logistics yet.  

  • Interesting concept,  Jonathan..  we already have a system-tray GUI app for our maintenance suite that interfaces between the user and VSA. I would have to think about some method of controlling access, where they still had to call for an authorization code or something. It would not be difficult to add local features to that app.

    Our first attempt was a fairly simple solution to implement via the APIs. This would take a bit more effort, but would probably be cleaner as it would elevate the user's account, similar to our current procedures. The user logs off/on, has admin rights and a timer fires that logs them off in "X" minutes. The user account is removed from the local admin group right after logon, but they already have the admin rights.

    The only concern I have is that we were going for something that provided an input to the UAC prompt, without the need to log off/on/off/on. The next time they connected to VSA, the local password would be updated so they'd have limited time to potentially abuse it.

    Thanks much for the ideas and feedback!

    Glenn

  • ... Here's a thought on that.  When they enter the response from the VSA, the app resets a local admin account to a randomized password and displays that on the screen for the user.  Then XX minutes later the app resets that same account password to something else.

  • Neat! I'll have to see if I can create an account and use the credentials while the UAC prompt is displayed. Of course, the user could simply restart the process, but we both know that they'll try not to! :)

    With our SysTray tool, that would work - add a button to request admin - call the office, get a code, and the correct code updates and displays the password, changing it minutes later. I like it!

    Glenn

  • I would be interested in that procedure for an authentication of a non-connected system.  Sounds like a cool idea to me!