Re: 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?

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.

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?

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.

In summary, here's what I've got:

1. net user <account> <password> /add

2. net user <account> <password>

3. net localgroup "Administrators" "%COMPUTERNAME%\<account>" /add

4. net localgroup "Domain Admins" "%COMPUTERNAME%\<account>" /add

5. netuser <account> /pwnexp:y

6. Add reg value (DWORD, 0): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList\<account>

Those steps create the account if it doesn't exist, reset the password if it does, adds to appropriate security groups, sets password to never expire, and hides from the welcome screen.

Am I missing anything?

I also have...

WMIC.EXE /Node:localhost Path Win32_UserAccount Where Name="#NAME#" Set PasswordExpires="FALSE"

Also I have a check for 64-Bit as I use SET 64-BIT REGISTRY KEY for 64-Bit machines but you maybe able to get away without that.

I get the idea of the single account across all sites for technicians to use and I'm happy to create the scripts for and manage that.

It would be better if Kaseya created and managed (i.e. regularly changed the password of) a local admin account on each agent to use for patching and scripting.  I don't see the need for us all to create scripts and manage it ourselves when we all need to do the same thing.  It seems like and unnecessary overhead and a way to further complicate and already complicated product, especially when competing products don't require a similar thing.

This netuser file resolved the issue for me.  Its the only workable solution I found so far for preventing the account created from expiring on domain controllers.

Also, I added one more step to my script since my last post: we need to account for our admin account getting disabled. I think this (along with my steps above) covers all possible scenarios and it works great when run on every single agent at once.

net user <account> /active:yes

So..this is an old topic, but we've been working toward using the variables to ensure clients have different passwords from each other.  Using the variables works great...now how do I go about managing credentials for the patching,etc.  Is there a way I can use policy management or some other way to automatically update the clients credentials when I update the variable (password)