You may want to look at User Manager Pro, you can
specify a list of workstations and an account to
change then it goes through and does it. With the
ease of use this provides you could change the account
every 30 days or some other riduclously small amount.
This would also enable you to do a rapid change if one
of your staff left or if an outsider found out some
other way. We have used this software across the US
on over 8000 machines so you shouldn't have any
problems there. But then you run into an issue with
laptops, if you are concerned with that.
http://www.lanicu.com/products/nt_user_mgr.cfm
Regards,
Chris
--- "Depp, Dennis M." <deppdm (at) ornl (dot) gov [email concealed]> wrote:
> The problem I see with a central database is two
> fold. One it is a
> single point of failure and two all you valuables
> are stored in one
> location. The single point of failure can be worked
> with clustering or
> mirroring the database, but all your valuables are
> still stored in one
> location. Granted a hacker will have to understand
> what they have
> (which may not be easy). If I went with a central
> database, I would
> ensure I had a host base intrusion detection system
> installed. This
> would be in addition to all my other detection and
> alerting systems.
>
> Dennis
>
> -----Original Message-----
> From: Eli Allen [mailto:eallen (at) bcpl (dot) net [email concealed]]
> Sent: Wednesday, November 26, 2003 4:37 PM
> To: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP];
> dave kleiman
> Cc: focus-ms (at) securityfocus (dot) com [email concealed]
> Subject: Re: local admin account password
>
> 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/colum
> ns/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 (at) isecureu (dot) com [email concealed]
> > >www.SecurityBreachResponse.com
> > >
> > >"High achievement always takes place in the
> framework of high
> expectation."
> > >Jack Kinder
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Eli Allen [mailto:eallen (at) bcpl (dot) net [email concealed]]
> > >Sent: Tuesday, November 25, 2003 13:47
> > >To: focus-ms (at) securityfocus (dot) com [email concealed]
> > >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 (at) bcpl (dot) net [email concealed]
> > >
> > >
> >
>
>-----------------------------------------------------------------------
specify a list of workstations and an account to
change then it goes through and does it. With the
ease of use this provides you could change the account
every 30 days or some other riduclously small amount.
This would also enable you to do a rapid change if one
of your staff left or if an outsider found out some
other way. We have used this software across the US
on over 8000 machines so you shouldn't have any
problems there. But then you run into an issue with
laptops, if you are concerned with that.
http://www.lanicu.com/products/nt_user_mgr.cfm
Regards,
Chris
--- "Depp, Dennis M." <deppdm (at) ornl (dot) gov [email concealed]> wrote:
> The problem I see with a central database is two
> fold. One it is a
> single point of failure and two all you valuables
> are stored in one
> location. The single point of failure can be worked
> with clustering or
> mirroring the database, but all your valuables are
> still stored in one
> location. Granted a hacker will have to understand
> what they have
> (which may not be easy). If I went with a central
> database, I would
> ensure I had a host base intrusion detection system
> installed. This
> would be in addition to all my other detection and
> alerting systems.
>
> Dennis
>
> -----Original Message-----
> From: Eli Allen [mailto:eallen (at) bcpl (dot) net [email concealed]]
> Sent: Wednesday, November 26, 2003 4:37 PM
> To: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP];
> dave kleiman
> Cc: focus-ms (at) securityfocus (dot) com [email concealed]
> Subject: Re: local admin account password
>
> 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/colum
> ns/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 (at) isecureu (dot) com [email concealed]
> > >www.SecurityBreachResponse.com
> > >
> > >"High achievement always takes place in the
> framework of high
> expectation."
> > >Jack Kinder
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Eli Allen [mailto:eallen (at) bcpl (dot) net [email concealed]]
> > >Sent: Tuesday, November 25, 2003 13:47
> > >To: focus-ms (at) securityfocus (dot) com [email concealed]
> > >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 (at) bcpl (dot) net [email concealed]
> > >
> > >
> >
>
>-----------------------------------------------------------------------
> ----
> >
>
>-----------------------------------------------------------------------
> ----
> > >
> > >
> > >
> > >
> > >
> >
>
>-----------------------------------------------------------------------
> ----
> >
>
>-----------------------------------------------------------------------
> ----
> > >
> > >
> > >
> >
> > --
> > http://www.sbslinks.com/really.htm
> >
> >
> >
> >
>
------------------------------------------------------------------------
> --
> -
> >
>
------------------------------------------------------------------------
> --
> -
> >
> >
>
>
>
------------------------------------------------------------------------
> ---
>
------------------------------------------------------------------------
> ---
>
>
>
>
------------------------------------------------------------------------
---
>
------------------------------------------------------------------------
---
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
[ reply ]