RE: local admin account password

From: Clark, Andre M. (
Date: 11/26/03

  • Next message: Peterson Ellis: "Re: local admin account password"
    To: "'David Cameron'" <>, "Eli Allen" <>
    Date: Wed, 26 Nov 2003 12:45:34 -0500

    There is a slight flaw with this program in that you can only use it to set
    passwords no longer then 12 characters in length. Anything above that will
    not register. I don't know if it has been updated but the last time I used
    this utility (approximately 1 yr ago) it still had the same issue.

    André M. Clark
    Sr. Manager, Engineering & Support Services

    -----Original Message-----
    From: David Cameron []
    Sent: Wednesday, November 26, 2003 03:26
    To: Eli Allen
    Subject: Re: local admin account password

    You might want to consider a solution using something like this:

    using the above, you could write a script that would change the
    passwords of the servers on a regular basis (say weekly).

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


    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


  • Next message: Peterson Ellis: "Re: local admin account password"