Re: Changing workstation Admin password through AD

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

"Ken Aldrich" wrote:

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

"Brian Desmond [MVP]" <brian@xxxxxxxxxxxxxxxx> wrote in message
news:ePW4ETOkHHA.4516@xxxxxxxxxxxxxxxxxxxxxxx
Should be getting bounced at least once a month for patches I'd hope.

--
Thanks,
Brian Desmond
Windows Server MVP - Directory Services

www.briandesmond.com


"Ken Aldrich" <supportw@xxxxxxxxxxxxxxx> wrote in message
news:OUr0pWLkHHA.4800@xxxxxxxxxxxxxxxxxxxxxxx
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

"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message
news:uM9wr$DkHHA.4676@xxxxxxxxxxxxxxxxxxxxxxx
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


Myweb wrote:
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.

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.








.

Relevant Pages

  • Re: Office XP After Windows 2000 Upgrade
    ... on these three workstations. ... work with Microsoft products--especially when Microsoft ... >>complete installation from the administrator account ...
    (microsoft.public.office.misc)
  • Re: Domain users unable to print to parralel printer
    ... Did you configure the printer as "Default printer" after installing with the administrator account? ... workstations and we encounter a very strange problem which we can't ...
    (microsoft.public.windows.server.networking)
  • Re: Domain users unable to print to parralel printer
    ... Additionally I have disabled the logon scripts that maps drive automatically upon domain users login but did not help to fix the problem. ... I don't understand why a new created domain account with the same privileges as the existing users can print. ... Did you configure the printer as "Default printer" after installing with the administrator account? ... workstations and we encounter a very strange problem which we can't ...
    (microsoft.public.windows.server.networking)
  • Administering without Administrator
    ... Windows2003 server and 5 accompanying workstaitons. ... and then granted that user administrator ... workstations in my group, which this guy has installed, however he hasn't ... administrator account, looking at print queues, setting up workstations, ...
    (microsoft.public.win2000.setup)
  • Re: Does anyone truly use Restricted User Accounts?
    ... > local administrator privileges, after Jeff Middleton announced that it was ... > is to make the distinction between user accounts and users. ... >> workstations and network. ... >> user to have local Admin rights. ...
    (microsoft.public.windows.server.sbs)
Loading