Easy question on the local admin passwords

[boomboom999]

Windows XP/2003, Active Directory, SMS 2003

How can I change regularly the local administrator's password on 4000
workstations?

GPO? SMS?

Option 1 - Use SMS or GPO for that purpose

In that case, I will need to place the password in SMS packages or in
GPO scripts which is not good because the SMS packages and GPO scripts
can be read by users and the password can be easily discovered.

Option 2 - Use some script that goes thru AD and changes the password
remotely on all PCs, one by one

That seems to be a good idea but not all workstations are static. There
are laptops. So, sometimes they are absent so they will miss the
password change quite often.

Any idea or advice?

 

[Steven L Umbach]

With a Group Policy "startup" script users do not need read access to the
script in sysvol. You can remove authenticated users and add domain
computers with read/list/execute instead. You will also have a potential
problem in that the startup script will not be run until the computer is
restarted on the domain. You might want to use different local administrator
password on the laptops than the workstations. --- Steve

 

[boomboom999]

With a Group Policy "startup" script users do not need read access to the
script in sysvol. You can remove authenticated users and add domain
computers with read/list/execute instead. You will also have a potential
problem in that the startup script will not be run until the computer is
restarted on the domain. You might want to use different local administrator
password on the laptops than the workstations. --- Steve

Thanks Steve,

That seems to be a more secure solution.
But I think it is still trivial to circumvent.
Any user that manages to run a script under LocalSystem (for any
reason) can acces the administrator password in clear text. As I can
trust totally all the workstations (there are some of them that are
operated by knowledgeable users with administrative rights) I would
prefer do not offer the password in that manner.

 

[boomboom999]

Thanks Steve,

That seems to be a more secure solution.
But I think it is still trivial to circumvent.
Any user that manages to run a script under LocalSystem (for any
reason) can acces the administrator password in clear text. As I can
trust totally all the workstations (there are some of them that are
operated by knowledgeable users with administrative rights) I would
prefer do not offer the password in that manner.

Sorry, there is a typo in the last phrase

As I can NOT trust totally all the workstations (there are some of them
that are
operated by knowledgeable users with administrative rights) I would
prefer do not offer the password in that manner.

 

[boomboom999]

Thanks Steve,

That seems to be a more secure solution.
But I think it is still trivial to circumvent.
Any user that manages to run a script under LocalSystem (for any
reason) can acces the administrator password in clear text. As I can
trust totally all the workstations (there are some of them that are
operated by knowledgeable users with administrative rights) I would
prefer do not offer the password in that manner.

Sorry, there is a typo in the last phrase

As I can NOT trust totally all the workstations (there are some of them
that are
operated by knowledgeable users with administrative rights) I would
prefer do not offer the password in that manner.

 

[Joe Richards [MVP]]

If someone can get localsystem or admin access rights there is NO safe
way to do it. They simply throw a password change notification package
on the machine and will get the clear text password given to them the
instant you try to change it.

The easier way to pull a password from a startup script is to throw a
network sniffer on the box and have it pull SMB traffic and then look at
the script that comes down 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

 

[Steven L Umbach]

As Joe said if the user has system or administrator access he already owns
the operating system and yes that can pose a problem in some cases. What you
could do is make sure that those computers to not use the Group Policy
startup script and then consider making sure each of those computers has a
unique password for the built in administrator account which you could do
with something like cusmgr from the Resource Kit or PsPasswd from
SysInternals in a batch file. If sniffing the password off the wire is a
concern do the operation from a secure admin workstation and have an ipsec
require policy on the computers in question which can be implemented via
Group Policy for SMB ports/protocol from the IP address of the admin
workstation. Do not attempt ipsec however until you have a good
understanding how it works and the need for special considerations for
domain controllers. -- Steve

http://support.microsoft.com/?kbid=272530
http://support.microsoft.com/?kbid=254949 --- ipsec implementation
considerations.

 

[Roger Abell [MVP]]

I have looked at this common need from a few angles.
The startup script has the obvious issues already discussed.
Use of a script run on need (your option 2) has issues with
what passes over the wire, or as Joe pointed out, issues if
a pwd change intercept has been implanted.

The more I have considered this I have come to believe that
a large part of the problem is the use of "a" password, or a
"relatively simple" password scheme, for 100's or 1000's of
machines.

This is especially true if there are any less than fully trusted
people allowed an admin account on any of those machines,
or even crafty enough people with limited accounts that might
quickly be opportunistic when there is an unpatched privilege
elevation exploit available. In either case they are cracking
the SAM and getting the key to the 100's or 1000's.

What I am very uncomfortable with is the scenario where an
invader, a real bad guy/app, gets that password and the org
discovers that it has no way to react, no way to halt the access
within a decent timeframe.

This has lead me to explore having local admin passwords
unique, or even long random unremembered strings.

To date my ideas have leaned toward asking, why does a
large environment use the local admin account? What if there
were domain accounts in Administrators that are guaranteed
useful via cached login if there is a connectivity issue? Is this
transferring of the crack exposure from the SAM to the store
of cached credentials worth the effort?

The alternative seems to be a startup script that only triggers
a callback, such as a database lookup that returns (within
encryption) what should become the password for that one
machine. You can pencil out the details, stored proc so a
machine can only get what relates to its credentials; access
method for support staff to get current for specified machine,
etc.; startup script triggered to do this at closest date after
some periodic threshold, etc.. Also, there are third-party
group policy extensions, and other management clients,
that can replace the startup script bootstrap.

But this second alternative does not get past the issue Joe
mentioned relative to change notification (but each machine
would have its own password.

In short, there are very real dangers in how people commonly
set up access on small and large groups of machine. There seems
however no clear, best solution, at least that I have found, which
has no drawbacks. This may be a good example of the triangle,
cheap-functional-secure, rule that you can have any two.

Roger

 

[Joe Richards [MVP]]

Or even why worry about a local password on workstations. Set the
account to a random long impossible to remember password (different for
every machine) and when you need to get into a machine and domain creds
aren't working, reset the password with one of the hack CDs.

joe

--
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