Re: local admin account password

From: Peterson Ellis (peterson_ellis_at_bah.com)
Date: 11/26/03

  • Next message: James D. Stallard: "RE: local admin account password" 
    Date: Wed, 26 Nov 2003 13:36:29 -0500
To: Eli Allen <eallen@bcpl.net>

    What do you mean when you say that "physical security negates the need
    to worry about boot floppy/cds"? Are you saying that the users do not
    have physical access to their boxes or that they can be observed by a
    guard/other workers/management?

    Ellis

    Eli Allen wrote:
    >
    > Thanks, I've used that tool before (seems to have a bug as it didn't work
    > with a particular password I was trying to use one while "net user" worked
    > fine at changing the password but thats a different story)
    >
    > some other consideration that I probably should have mentioned:
    > - Some users are admins of some boxes but should have no access to others.
    > i.e. they can do lophtcrack on their own box but don't wnat that to help
    > them get into another box
    >
    > - physical security negates the need to worry about boot floppy/cds
    >
    > Thanks
    > Eli Allen
    >
    > ----- Original Message -----
    > From: "David Cameron" <david@uberconcept.com>
    > To: "Eli Allen" <eallen@bcpl.net>
    > Cc: <focus-ms@securityfocus.com>
    > Sent: Wednesday, November 26, 2003 3:25 AM
    > Subject: Re: local admin account password
    >
    > > You might want to consider a solution using something like this:
    > >
    > http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q272/5/30.ASP&NoWebContent=1
    > >
    > > using the above, you could write a script that would change the
    > > passwords of the servers on a regular basis (say weekly).
    > >
    > > regards
    > > David Cameron
    > >
    > > 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
    > > >
    > > >
    > >
    > > --------------------------------------------------------------------------
    > -
    > >
    > > --------------------------------------------------------------------------
    > -
    > > >
    > > >
    > >
    > >
    > >
    >
    > ---------------------------------------------------------------------------
    > ---------------------------------------------------------------------------

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

  • Next message: James D. Stallard: "RE: local admin account password"