How to change the local administrator account password on clients across a domain
Hi,
We want to reset / update the password of the local administrator account on all of our Windows 7 / Windows 8 clients across a Server 2012 /2003 domain and I am wondering what would be the best / easiest way to do this?
I am assuming that it will probably something that can be done in Powershell or maybe even with Group Policy, but I am looking for the detail of how to do it, not just the method.
Who has done this before, what method did you use and what is the detail of the solution?
Thanks!
Jon
We want to reset / update the password of the local administrator account on all of our Windows 7 / Windows 8 clients across a Server 2012 /2003 domain and I am wondering what would be the best / easiest way to do this?
I am assuming that it will probably something that can be done in Powershell or maybe even with Group Policy, but I am looking for the detail of how to do it, not just the method.
Who has done this before, what method did you use and what is the detail of the solution?
Thanks!
Jon
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
That won't change the SID so many attack vectors remain.
You can also reference the Active Directory Team Blog to accomplish this via Group Policy.
http://blogs.technet.com/b/askpfeplat/archive/2014/05/19/how-to-automate-changing-the-local-administrator-password.aspx
Will.
http://blogs.technet.com/b/askpfeplat/archive/2014/05/19/how-to-automate-changing-the-local-administrator-password.aspx
Will.
Yep, that leads to my link, by the way :)
That won't change the SID so many attack vectors remain.Realistically, how is someone going to get the SID of the administrator account. The only thing that is the same is -500 at the end of the SID. You would still need to get the rest of the SID as well and you would also still need the correct password.
Most people that use combo lists use usernames not SID's as no SID is the same across different domains.
Having the account renamed and a strong password is plenty to secure this account.
Will.
Realistically, he would need a local logon, that's all. There are many tools, user2sid/sid2user for example. Those retrieve your own SID and you just append 500 instead of your own suffix.
ASKER
Thanks. A lot to take in here. I will digest what's been posted so far and come back with any questions.
One initial question is the appending 500 thing you mentioned McKnife. Can you elaborate on that?
Are you saying that appending 500 to any SID makes user account into an admin?
If so, wouldn't that be an easy attack vector that we should be trying to lock down?
One initial question is the appending 500 thing you mentioned McKnife. Can you elaborate on that?
Are you saying that appending 500 to any SID makes user account into an admin?
If so, wouldn't that be an easy attack vector that we should be trying to lock down?
Hi.
"Are you saying that appending 500 to any SID makes user account into an admin?" nooo :)))
I was talking about 2 tools: sid2user.exe and user2sid.exe which enable standard users to lookup SIDs of known usernames (user2sid) or translate a known SID to an unknown username (SID2User). That makes hiding the admin account by renaming it quite ineffective from the perspective of an attacker THAT IS ALREADY logged on to the system, because, no matter what you rename the acount to, it will still end in -500. So you'll definitely find out the new name with ease.
Please tell us why you would like to change the passwords and not leave those accounts simply disabled as Microsoft recommends.
"Are you saying that appending 500 to any SID makes user account into an admin?" nooo :)))
I was talking about 2 tools: sid2user.exe and user2sid.exe which enable standard users to lookup SIDs of known usernames (user2sid) or translate a known SID to an unknown username (SID2User). That makes hiding the admin account by renaming it quite ineffective from the perspective of an attacker THAT IS ALREADY logged on to the system, because, no matter what you rename the acount to, it will still end in -500. So you'll definitely find out the new name with ease.
Please tell us why you would like to change the passwords and not leave those accounts simply disabled as Microsoft recommends.
ASKER
We often need to remotely connect to:-
Remote Registry, Computer Management, Hidden Drive Shares etc for administration.
If you can give me some different best practice for how to achieve this, then I would be happy to disable local admin accounts!
Remote Registry, Computer Management, Hidden Drive Shares etc for administration.
If you can give me some different best practice for how to achieve this, then I would be happy to disable local admin accounts!
ASKER
The other issues we have seen where local admin has been invaluable have been quick log on to machines (the Domain Admin pulls down a load of stuff from the network) and when machines have had networking issues and have not been able to contact the domain, this has been the only way to get on to those machines.
If you have alternative solutions to these situations then I am really open to disabling the local admin account!
(the next question would be how I do that en-mass!)
If you have alternative solutions to these situations then I am really open to disabling the local admin account!
(the next question would be how I do that en-mass!)
"We often need to remotely connect to: Remote Registry, Computer Management, Hidden Drive Shares etc for administration." - all of these can be accessed via RSAT. What you cannot do via RSAT (if any), you will be able to do via remote shell/psexec/remote powershell. You should not need to logon to those systems.
But if you do, you have two best, secure practices:
Either you use the local admin password changer extension I linked before, or you use extra domain accounts, one per system. The latter would require some script and a little management effort in the first place. I have outlined that in a german forum which you should let google translate for you - see if you understand it: http://www.administrator.de/wissen/sicherer-umgang-supportkonten-262066.html
The scripted solution is better, I use it. Those accounts can access domain resources and get auto activated/deactivated just for the support use.
But if you do, you have two best, secure practices:
Either you use the local admin password changer extension I linked before, or you use extra domain accounts, one per system. The latter would require some script and a little management effort in the first place. I have outlined that in a german forum which you should let google translate for you - see if you understand it: http://www.administrator.de/wissen/sicherer-umgang-supportkonten-262066.html
The scripted solution is better, I use it. Those accounts can access domain resources and get auto activated/deactivated just for the support use.
ASKER
The Google Translate rendition of that page is not great and I am struggling to understand it. Sorry....
(your English is much better than Google Translate!)
(your English is much better than Google Translate!)
You don't have to understand the text. Just that much: I used AD accounts set as local admins, one per machine. If that one is compromised, so what - it is only good for one machine and my script deactivates it right after support is over. If you don't understand the code, you are better off with my first link anyway.
ASKER
Thanks. Some excellent wisdom and suggestions here for different ways of tackling the problem we actually had.
Will.