Kaseya Community

Centralized Admin & Admin Password Management. (Single domain controller for all customers.)

  • Subject: Consolidated Admin Credentials & Passwords

    Summary:  It's difficult maintaining all of the different administrative accounts and their respective passwords across the entire portfolio of machines that you manage.  Furthermore, if you perform any administrative changes in Kaseya (i.e. Patch Management or Software Installs through Agent Procedures), you need to formally set the administrative credentials for the machine within Kaseya ('Agent' tab -> 'Set Credentials').  One of the best tips is having Kaseya create a single local administrative password on each system in the field.  This provides a few very large benefits:

    1)     Your technicians need only remember a single administrative password for the entire portfolio of windows systems you manage

    2)     If a technician leaves your organization or you have a policy for rotating admin passwords every 30 days, it will take you seconds to change the single admin account password across the board.

    3)     Have a single easy to set admin account and password for credentials within Kaseya ('Agent' tab -> 'Set Credentials')

    4)     Think of this as an Active Directory server for all of your different customer's machines, having one central way to manage the admin account.


    Create a new administrative account, to be used across all machines:




    Apply credentials to all of your machines, using this single Local Admin Account you created:




    Then run a Test (by using the 'Test' button within Set Credentials) to ensure that all machines pass and now allow Kaseya to perform any administrative operation you desire with Kaseya.  Now if you ever need to change that password for the machines in the field just 'Reset Password' within Kaseya and change the 'Set Credentials' to reflect the changed password:



    With this set, stay tuned for extremely powerful new tips and tricks.





  • Hey Brendan,

    Thanks for the posting, a good idea for those who don't do this to put it in. This will work on most machines, except domain controllers.

  • There are some problems with this.  

    We have found, but should confirm, if you create the local administrator account through Kaseya and don't actually go to the machine and log into the machine, then no profile gets created on that local machine.

    A number of items require a local profile to actually exist.  One of those being the installation of IE8 through patch management.   When I had my guys install it, they found that some machines worked and others did not.  Turned out to be that the machine that didn't work never had that local admin account.   Installed fine if I set the credentials to an existing user.

    Also, keep in mind that there can be some problems when trying to deal with domain resources in scripting.  If you are running as a local admin, you may not have access to domain shares, etc.

    You may want to create a common domain admin or domain user with local rights which require a little more scripting.  Just as easy and allows for full access to shares, etc.

    I'm sure the information is here already to set the create the user, then adjust machine to auto-login as that user, reboot, turn-autologin off, reboot and it solves the problem I mentioned above.

    Also, make sure, that your techies don't take shortcuts and get people to login with this local admin because they can't get connected remotely.  Sort of opens up a few problems if your user knows a password to all your networks.

  • @David Bourgeois Can you elaborate what you mean with "This will work on most machines, except domain controllers. "?

  • Yeah, I've used this on domain controllers before.  

    The only difference is that the admin account you create (or change the password on) is a domain account (not a local account) since domain controllers don't have local users and groups functionality.  This actual makes it easier to create a support/admin account that is usable across a client's domain.

  • I stand corrected! In K1 I never got this working and thought that in K2 it would be the same issue.

  • We do something similar, but we automated it. We have a script that creates that local universal admin account.  That script is run as part of our KPM, so we do not have to remember to add them.

  • I've been working on this and I typically had procedures to do this but hate the password being in the script.

    I've been trying to use the Kaseya building components in scripting for Creating Local user and Domain User since it seems to encrypt the password, but I have not been able to get them working.

    I have been able to use the remote control option which works well, however the challenge is that you have to do this manually.  You will also not know if someone's reset the password since this is a one time setting and if you've let a tech go, then you have to re-force the password everywhere.  It would be nicer to have that script reset daily so exposure is limited.

    James...does your script have the credentials saved in it?

    Brendan, does this create a hidden account or is it actively displayed on XP/Windows 7 workgroup machines?

    [edited by: Mark.Hodges at 9:52 PM (GMT -8) on 1-13-2012] spelling
  • Mark,

    We do not hide the password.  It is a NOC admin script so only the primary NOC person can see/edit it.  However we made the decision to give the password to our techs to help them do their job.  If we have a tech leave, it only takes a minute to change the password on all 2500 systems.

  • We have password stored in managed variables. Its usually 20 char long randomly generated and we use agent procedure using net user command to deliver it to machines. This account is used only for Kaseya scripting needs. We use other accounts for human users.

    If you have trouble managing passwords I can recommend product called Secret Server from Thycotic

  • remembering the password isn't a problem, we just use keypass...its the fact the passwords are plain text in a procedure i am not overly fond of.

    I didn't actually even notice the variables before....where are these stored?  In the database somewhere?

  • My suggestion for the "Reset Password" page is to change the check box for "Create new account" to "Create new account if one doesn't exist" (or something similar).

    The idea here should be to build in logic to check if the account that you are trying to reset is present already. That way we don't have to select all, reset with box checked, then reset without box checked. This would solve many problems... particularly around agents that are offline at the time of the global reset.

    [edited by: SMason at 5:42 PM (GMT -8) on 2-29-2012] Added a sentence.
  • I've been working on this for a while and still hitting a bit of a roadblock

    I now have a script that checks for the existence of a text file..if it exists, it skips processing.

    If it doesn't, it tried to create my admin account...if that fails, the process ends.  If it works, then it sets the password, sets the expiry, sets the hidden status and writes out my text file (from above).  It also checks for AD process and adds the account to domain admins

    This is all working great at the moment...however I have hit a roadblock in that on Domain controllers, the expiry does not work

    wmic path Win32_UserAccount where Name='supportAdmin' set PasswordExpires=false

    If I try running this on a DC it fails...

    anyone else used anything that works?

  • NetUser.zip

    I just tested this tool on a DC and it worked: www.windowsitpro.com/.../jsi-tip-0570-freeware-command-line-batch-account-rename-

    The download link is busted, so I Googled and found it on MSFN.org.... I'll attach it to this post.

  • We do the above but we also hide the account from the login screen.