local admin account password

From: Eli Allen (eallen_at_bcpl.net)
Date: 11/25/03

  • Next message: dave kleiman: "RE: local admin account password"
    To: <focus-ms@securityfocus.com>
    Date: Tue, 25 Nov 2003 13:47:29 -0500
    
    

    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: dave kleiman: "RE: local admin account password"

    Relevant Pages

    • RE: local admin account password
      ... Say you have more then 1000 systems, how do you handle the local admin ... Only use domain accounts so delete the local ones. ... The DB file would be encrypted with EFS so only the limited user SQL ... There would be basically two stored procs, ...
      (Focus-Microsoft)
    • RE: local admin account password
      ... Subject: local admin account password ... > 4) Only use domain accounts so delete the local ones. ... > The DB file would be encrypted with EFS so only the limited user SQL ... > backup user can make a zip backup of the DB whenever it gets changed ...
      (Focus-Microsoft)
    • RE: local admin account password
      ... Put the result as the admin password. ... Next time you need the password, you need to know: Your secret word + The ... > 4) Only use domain accounts so delete the local ones. ... > 5)My main idea/plan is to store all the passwords on a central SQL server. ...
      (Focus-Microsoft)
    • RE: local admin account password
      ... Any encryption can be cracked, it's just a question of time. ... Say you have more then 1000 systems, how do you handle the local admin ... Only use domain accounts so delete the local ones. ... 5)My main idea/plan is to store all the passwords on a central SQL server. ...
      (Focus-Microsoft)
    • RE: "login failed for user ..." appears in event viewer repeatedly
      ... OK, did I hear you right, you've determined that the attacks are coming from ... holes to that segment and/or box to just the SQL ports. ... I looked closer at the SQL accounts. ... I used SQL profiler to audit logins and login failures. ...
      (microsoft.public.sqlserver.security)