Re: local admin account password

From: Jimi Thompson (jimit_at_myrealbox.com)
Date: 11/28/03

  • Next message: Jimi Thompson: "Re: local admin account password" 
    Date: Thu, 27 Nov 2003 23:33:20 -0600
To: Eli Allen <eallen@bcpl.net>

    If you have a properly configured domain, your GPO's will determine who
    can log in to what.
    If not, you might want to re-visit your domain desgin (i.e. forest root,
    trees, etc.)

    HTH,

    Jimi

    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: Jimi Thompson: "Re: local admin account password"