Re: local admin account password

• Previous message: Eli Allen: "Re: local admin account password"
• In reply to: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]: "Re: local admin account password"
• Next in thread: Jimi Thompson: "Re: local admin account password"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: "Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" <sbradcpa@pacbell.net>, "dave kleiman" <dave@isecureu.com>
Date: Wed, 26 Nov 2003 16:37:22 -0500

There is no physical access so that is already taken care of. In my plan
the central DB has the infdo to login with so just a matter of querying it
in your install script.

BTW the machines are a mix of NT4 and up so the NT4 support can limit things

Eli Allen

----- Original Message -----
> Think Patch management software now... say that all you computers are
> running in User mode and you use a product like Shavlik's HfnetchkPro to
> remotely patch all machines on that LAN. With this product you can
> easily do this with "admin account logon credentials" in one patch blast
> across the lan, the zone, whatever.
>
> Now... under your scenerio... how do I manage and remotely patch my LAN
> quickly and efficiently?
>
> Physical security is always key - see law #3.
>
> I will take the risk of physical access to my machines for the risk that
> I lessen by being able to remote patch all machines in my Network.
>
> DCs diff admin password
>
> Workstations.. those suckers are zoned and have matching admin passwords.
>
>
> Susan Bradley
>
>
> The Ten Immutable Laws of Security
>
>
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/security/essays/10imlaws.asp
>
> <#b>Law #1: If a bad guy can persuade you to run his program on your
> computer, its not your computer anymore.
> Law #2: If a bad guy can alter the operating system on your computer,
> its not your computer anymore.
> Law #3: If a bad guy has unrestricted physical access to your computer,
> its not your computer anymore.
> Law #4: If you allow a bad guy to upload programs to your web site, its
> not your web site any more.
> Law #5: Weak passwords trump strong security.
> Law #6: A machine is only as secure as the administrator is trustworthy.
> Law #7: Encrypted data is only as secure as the decryption key.
> Law #8: An out of date virus scanner is only marginally better than no
> virus scanner at all.
> Law #9: Absolute anonymity isn't practical, in real life or on the web.
> Law #10: Technology is not a panacea.
>
>
>
> dave kleiman wrote:
>
> >1. Do you think if someone wanted to break the local admin account they
> >could just boot to Password recovery disk and change the password?
> >
> >If you make them all the same you are thinking if one get compromised
they
> >all get compromised. So you make them all different. How about a standard
> >password with the last 5 digits of the MAC of that box in between.
Thinking
> >that is still to easy then I would say you are dealing with someone who
> >would just use the idea I listed in number 1.
> >
> >You could mask the passwords with little tricks, or make the local admins
> >(unusable) but it sounds like a lot of work.
> >
> >
> >Try checking: http://www.securityfocus.com/archive/88/312263
> >
> >
> >
> >
> >
> >_______________________________
> >Dave Kleiman, CISSP, MCSE, CIFI
> >dave@isecureu.com
> >www.SecurityBreachResponse.com
> >
> >"High achievement always takes place in the framework of high
expectation."
> >Jack Kinder
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: Eli Allen [mailto:eallen@bcpl.net]
> >Sent: Tuesday, November 25, 2003 13:47
> >To: focus-ms@securityfocus.com
> >Subject: local admin account password
> >
> >
> >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
> >
> >
>
>---------------------------------------------------------------------------
>
>---------------------------------------------------------------------------
> >
> >
> >
> >
> >
>
>---------------------------------------------------------------------------
>
>---------------------------------------------------------------------------
> >
> >
> >
>
> --
> http://www.sbslinks.com/really.htm
>
>
>
> --------------------------------------------------------------------------
-
> --------------------------------------------------------------------------
-
>
>

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

• Previous message: Eli Allen: "Re: local admin account password"
• In reply to: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]: "Re: local admin account password"
• Next in thread: Jimi Thompson: "Re: local admin account password"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]