Changing workstation Admin password through AD

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I would like to do the following:
1. Rename the Administrator account
2. Change the password to the Administrator account
3. Create a dummy Administrator account
4. Disable the new account called Administrator.

I know how to rename the administrator's account, but how can I do the other
three steps without visiting each workstation. I would like to push this out
through AD if possible. Any suggestions are appreciated.
 
There really isn't a mechanism to do any of these through. The design of
AD isn't to manage local accounts on member machines. You can do #1
through GPOs which in turn leverages AD though in actuality, you aren't
managing the account name through AD. 2-4 could also be accomplished
through startup scripts in GPOs but I am not sure I would say that was
much better than say just writing a script to go through and do this
from a centralized console other than the fact that you don't have to
worry about reaching out and touching machines, they will be calling
back for the scripts to run.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
 
From time to time I see posts or have customers call with a lot of interest
in doing these steps. Some of these steps provide limited benefit.
Renaming the administrator account and creating another one in its place
might protect you from some malicious attacks from people that only know the
basics. Most serious, malicous people bent on exploiting local
administrator accounts do not bother looking for the account name. It is
quite common knowledge that the RID (the last part of the SID) for the
administrator account is always "500". It is just as easy to look for the
RID as it is the name.... most hackers know this. If you have already
weighed the cost benefit and still want to go down that path then GPOs and
scripts can help you with the renaming parts as Joe mentioned.

Of the steps you named, there is one that stands out in my mind as higher
value. Changing the local administrator password on a regular basis is good
practise. You can use GPOs and other methods but there are some downsides
to those. How do you know for sure if the GPO has processed on every
machine successfully? There is no real log for you to be 100% sure that
your changes have happened. Scripting can help if you write a script to
touch each machine and then log whether it was successful or not.

There are third party tools available as well. I work in the support
department for the company that makes DSRAZOR for Windows. We have a lot of
happy customers that successfully, regularly reset the local administrator
password on their machines remotely. DSRAZOR also logs successful changes
so you know where you stand. It is a lot easier to select a thousand
computer accounts in a list, enter in the new password twice, press "OK" and
let the applet work than to go around to all of those machines or write a
script.

You can go to www.visualclick.com/?source=localadminreset050407 for more
information.
 
Hello Joey,

Add a simple batchfile to the startup script of the computer settings part
(pw.bat for example).

net user administrator password

Remove domain users and everyone from the security, add only system and administrators
with Full and domain computers with read and execute. If the workstation
starts up the password will apply.

Best regards

Myweb
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
 
See now this isn't really safe... Anyone who can get to power user or
admin level on a workstation will have a path to get that batch file and
anyone with physical access to a machine can get admin regardless of
what their "official" access level is. The machine has to have read
access to the file in order for it to work and to get to a point where
you can access sysvol as that machine isn't very difficult. Also someone
could always just run a network sniffer and watch the clear text script
come down over the wire.


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
 
Joe,

Those are great points and it is good for you to mention them. I see that
startup script method recommended a lot on forums and I wonder how many
people realize what you have said.

The other point is that in many organizations machines do not get rebooted
very often... or even logged off. In that case, how can you be sure that
passwords are being updated? Or that the password ages will be relatively
similar? The only way to be sure is to force a reboot of everyone's
computers... that just does not fly in many organizations. There are better
methods available in that environment.

--
Ken Aldrich
DSRAZOR for Windows
Visual Click Software, Inc.
www.visualclick.com
 
Brian,

I don't want to sound contrarian, but there are a lot of organizations where
bouncing every member server and workstation monthly is not practical. Some
companies have strict change control policies that mandate patches of that
nature only be applied once a quarter, or at other intervals of scheduled
maintenance. The intervals in password change policies do not always line up
with these schedules.
On the other side of that, some people cannot simply tell their auditors,
"I'm sure the password must have gotten reset sometime in the last week
because we patched all our computers."
At some point they may need to show a log, or proof. What if some
workstations or servers were turned off for an extended period of time and
were not patched? Sometimes the patching process fails and computers are
not properly patched or rebooted. These hosts would not update their
passwords if you were relying on that scripted process... and the only way
to determine that would be to look at patch logs or some other type of log.

When you have a dependancy like this, if your patch process develops a
problem and does not patch each and every host, you may have a "finding" in
your audit for failure to patch. But, if you rely on patching to force
other processes such as this one, then you may multiply how many "findings"
you have in an audit. Again, this is not a strong argument that would apply
to everyone, but for some people it is a very important consideration.

There are some people out there that need to have a more precise change
mechanism, or more importantly, a more precise logging mechanism for
accountability.

Anyway, those are some of the considerations or "down sides" to using the
GPO/startup script method... in addition to what Joe mentioned. They
certainly are not an issue for everyone, but there are still a lot of people
that do need workarounds for these concerns.

--
Ken Aldrich
DSRAZOR for Windows
Visual Click Software, Inc.
www.visualclick.com
 
What we've done in our organization is to create a few scheduled tasks that
run locally on the workstations. One of them runs nightly and resets the
local admin password to a different password based on the month. It's a
custom executable that was written by one of our VB-savvy admins so that it's
compiled and would be fairly difficult for an end-user to extract passwords
from. The other task is one that reboots workstations on Sunday night. We
have a small list of exceptions which are easily controlled by a text file
that has the workstation name of the exceptions in it.

It's not perfect, but we find that 95% or more of our workstations have the
correct local admin password, and that those that don't are usually only 1
password behind, or have the default password still set. And most
workstations get rebooted at least weekly. Part of that is user training.
Our helpdesk reminds people when they call to restart their machines before
leaving, and to always leave their workstation turned on.

Oh, and we use SMS periodically to fix the scheduled tasks on machines that
they're not working on, and to push out a new password executable with a new
list of monthly passwords in it.

I'm actually going to be changing the password change method when we refresh
our workstations this year. The password task on the local machine will by
default set the password each night to a new random strong password for the
month. If someone needs to log onto a workstation with the local
administrator account, the password will need to be reset by a domain
administrator. Since all of our Helpdesk personnell are in the local
administrators group for workstations, they rarely need to use the local
administrators account. If the machine is off the network, the end-user
support techs have password reset disks that they can use to get into the
machine.

I don't think there's any perfect solution. There will always be missed
machines or security loopholes. For example the password reset disks. Anyone
with the desire to break into a workstation can download one of these CDs off
of a website. So unless you disable CD-booting completely and lock the BIOS
with a password, anyone can break into your workstations and have local
administrator access. And then you're dealing with another password that
either has to be changed regularly, or can be compromised because everyone
knows it.

Such is life for the security guy. heh
 
Back
Top