Re: local admin account password

• Previous message: Eli Allen: "Re: local admin account password"
• 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 ]

Date: Tue, 25 Nov 2003 21:35:30 -0600
To: Eli Allen <eallen@bcpl.net>

Eli,

I'm going to assume that you have all your servers on a domain, but not
necessarily the same domain. We always used an escrow for the local
admin passwords and forced everyone else to log in through the domain.
I know that this works in 1000+ server set ups because I've used it that
way.

Our particular set up employed a safe which required 2 keys to open.
Each local administrator password for each server was randomly
generated, printed out, sealed in an envelope with the name of server on
it and locked up. No one person had both keys. In the event that the
safe had to be opened, it took two people, each verifying what the other
was doing and signing off on it in a log book. In 3 1/2 years I was
there, we only had to open the safe twice. Both times this was due to a
catastrophic hardware failure.

If people are using the "local admin" account, something is wrong.
Either the people aren't handling the servers properly or your domain
needs revising (i.e. GPO's to allow them to do the necessary things with
their domain accounts). This is likely defeating your audit controls
since you can't tell the difference between Sam logging in as local
admin and Joe logging in as local admin.

The people that I know that resisted this policy the most were the first
ones fired for doing things that they weren't supposed to be doing.
When they had access to the "local admin" account, they had been able to
claim they hadn't done certain things. Once the local admin account
went away, we were able to establish exactly who was doing what and when
they were doing it. I know that many of the "unexplainable" problems
that we had experienced suddenly vanished, never to re-appear.

HTH,

Jimi

Eli Allen wrote:

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

---------------------------------------------------------------------------
---------------------------------------------------------------------------

• Previous message: Eli Allen: "Re: local admin account password"
• 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 ]