RE: local admin account password
From: Clark, Andre M. (Andre.Clark_at_timewarner.com)
Date: 11/26/03
- Previous message: Clark, Andre M.: "RE: local admin account password"
- Maybe in reply to: Eli Allen: "local admin account password"
- Next in thread: Clark, Andre M.: "RE: local admin account password"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: "'Herbold, John W.'" <JWHERBOLD@arkbluecross.com>, "'focus-ms@securityfocus.com '" <focus-ms@securityfocus.com> Date: Wed, 26 Nov 2003 12:35:30 -0500
Folks,
I concur. This is what I do in my environment. Take note that if you have
Windows 2000, or higher systems, you can have a password up to 127
characters. Yes this is extreme but if anyone can crack a password that
long and get into your system you have other problems (i.e. how did a person
get the opportunity to spend that much time hitting against one system).
André M. Clark
Sr. Manager, Engineering & Support Services
-----Original Message-----
From: Herbold, John W. [mailto:JWHERBOLD@arkbluecross.com]
Sent: Tuesday, November 25, 2003 16:50
To: 'focus-ms@securityfocus.com '
Subject: RE: local admin account password
Why not make them the same, but use a program or a script to change them
when needed. Like every xx days, or a staffing change.
John Herbold
Security Specialist
-----Original Message-----
From: Eli Allen
To: focus-ms@securityfocus.com
Sent: 11/25/2003 12:47 PM
Subject: local admin account password
Say you have more then 1000 systems, how do you handle the local admin
account password on the machines? (assuming it needs to be available for
extreme cases to get into the machine as you'd normally just use a domain
login)
A few ways I can think of (in order from what I think is worst to best):
1) use the same password on all boxes. Obviously insecure
2) Use a different password on all boxes and a big filling cabinet to secure
it (as its impossible to memorize). Don't think this would work in the real
world so not worth using.
3) Use a password scheme where the password is basically the same on all box
except its based on something specific about the server. This means if
someone figures out the scheme (cracking a single box and figuring it out or
just gets told) they basically made this as good as the first idea I list.
4) Only use domain accounts so delete the local ones. But this means no
more recovery console and don't think cached logins will work. With so many
boxes and hence lots of admins you may not have logged onto the box and so
not have cached login in the cache even if you increased the logins that can
be cached.
5)My main idea/plan is to store all the passwords on a central SQL server.
This way you can easily have a different random passwords for the admin
accounts on all the boxes.
The DB file would be encrypted with EFS so only the limited user SQL runs
under has access to the file and another user just used for doing backups of
this file. This means an attacker can't use an OS break-in to get to the
data and needs to compromise SQL or one of those two user accounts. SQL
would be set to integrated auth and only allow the domain groups who are
allowed access to the admin password in. (i.e. using the access rights
already existing)
For data recovery (this DB is very important not to lose) there are two main
considerations, one the file is small as the DB has very little info in it
and two it doesn't get updated very often. The backup user can make a zip
backup of the DB whenever it gets changed and then encrypt the file (PGP or
something like it with the private key stored on a/multiple CD-R(s)
somewhere safe) Then this file could be copied to lots of employee's
desktops. Its encrypted so they can't read it and with lots of people
having the file the likelihood of everyone's copy being damaged from HDD
failure is low. (Yes will use tape backup of the file too including off site
storage but tape is slow and should only be used if necessary) If there is
an emergency the managers could easily allow the file to be decrypted and
then attached to any SQL server available relatively quickly.
Access to this file can be made by any utility that can make use of stored
procedures. There would be basically two stored procs, one to get a
password from the DB and one to set the password in the DB both would have 3
values (machine name, username, and password) passed in and out (obviously
depending on which you use). This way if a person decides to try and dump
the DB and get all the passwords the stored proc can do something about it
(alert management, stop it from happening, or something like that) This way
its easy to write whatever interface you want to be able to do access the DB
and the app itself doesn't really need to be secure as the authentication is
based on the user that app is run by.
Yes I realize it has a central point of attack at the DB but I think that
can be secured well enough and the design is secure that its still better
then the other methods.
Any comments? Thanks
Eli Allen
eallen@bcpl.net
------------------------------------------------------------------------
--- ------------------------------------------------------------------------ --- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ============================================================================== This message is the property of Time Warner Inc. and is intended only for the use of the addressee(s) and may be legally privileged and/or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, he or she is hereby notified that any dissemination, distribution, printing, forwarding, or any method of copying of this information, and/or the taking of any action in reliance on the information herein is strictly prohibited except by the original recipient or those to whom he or she intentionally distributes this message. If you have received this communication in error, please immediately notify the sender, and delete the original message and any copies from your computer or storage system. Thank you ============================================================================== --------------------------------------------------------------------------- ---------------------------------------------------------------------------
- Previous message: Clark, Andre M.: "RE: local admin account password"
- Maybe in reply to: Eli Allen: "local admin account password"
- Next in thread: Clark, Andre M.: "RE: local admin account password"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
