How does your organizations manage the local administrator account on workstations?

Gurus,

How does your organizations manage the local administrator account on
workstations? Typically the end-users do run with "administrative"
privileges, but a local admin account is needed to access a machine offline.
So how is this account typically named (i.e. renamed) and password secured
(i.e., complex and only a few people know it)? Then you have the problem of
having to change this password on every workstation if a member of the IT
staff leaves. Just looking for quick thoughts here, no long treatise on the
topic is necessary!

--
Spin

Spin
Fri Aug 29 22:34:24 CDT 2008

I meant to say "Typically the end-users don't run with "administrative"
privileges"

Meinolf
Sat Aug 30 01:31:18 CDT 2008

Hello Spin,

Also domain users can logon if they are not connected to the domain with
cached credentials, there is only a onetime domain login needed before.

If you really have the need to make your users local admins use Restricted
groups with a GPO:
http://www.frickelsoft.net/blog/?p=13

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> Gurus,
>
> How does your organizations manage the local administrator account on
> workstations? Typically the end-users do run with "administrative"
> privileges, but a local admin account is needed to access a machine
> offline. So how is this account typically named (i.e. renamed) and
> password secured (i.e., complex and only a few people know it)? Then
> you have the problem of having to change this password on every
> workstation if a member of the IT staff leaves. Just looking for
> quick thoughts here, no long treatise on the topic is necessary!
>

Anteaus
Sat Aug 30 02:34:00 CDT 2008

Likewise we make users local admins, having found limited-user working to
cause too many problems. We maintain the local Administrator password with a
small program run from the logon-script. This arrangement has the advantage
that if an installer forgets to set a password, the standardised one will be
set at next logon.

The key thing is to make sure users don't get added to the Domain Admins
group. I've seen sites that are like this, and it leaves the whole network
open to attack from any one compromised computer.

> > How does your organizations manage the local administrator account on
> > workstations? Typically the end-users do run with "administrative"
> > privileges, but a local admin account is needed to access a machine
> > offline. So how is this account typically named (i.e. renamed) and
> > password secured (i.e., complex and only a few people know it)? Then
> > you have the problem of having to change this password on every
> > workstation if a member of the IT staff leaves. Just looking for
> > quick thoughts here, no long treatise on the topic is necessary!

Mathieu
Sat Aug 30 07:28:38 CDT 2008

Hello,

renaming the account isn't helpful when people are logged in. It's useful
for remote attacker trying to brute force and can't guess it.
smacking the local admin password is easy from a boot CD. All you can do is
:
-Making things harder
-Automate check on this account and usage.

Making things harder:
-The Password length must be > 14 to prevent the storage in LM Hash of the
password (so only NTLM version). Or Storage in LM Hash format must be
prohibited by GPO.
-All workstations must have unique local admin pass. If they share the same,
anyone that got it is admin of all Workstations.
-Disable the account. It's normally not needed for day to day usage.
-Set a bios password (one per machine) and only allow boot from Disk. No CD,
USB or network.
-Enforce members of the local administrators group through GPO.

Automate checks:
-Place a logon script on it, so when it's used, it create a flag in registry
or file. So you have a clue if it was used and when.
-Audit eventlog securitty for trace of this account being used.
-Change it every X months. When changing, test for it. So will know if
someone changed it.
-Inventory Software installed on wks. Local admin rights is searched for
being able to install what you want. Especially on Notebooks, which you can
brings to your best friends, the computer expert one of course.

--
Cordialement,
Mathieu CHATEAU
English blog: http://lordoftheping.blogspot.com
French blog: http://www.lotp.fr

"Spin" <Spin@invalid.com> a écrit dans le message de
news:6hrtd6FnibtiU1@mid.individual.net...
> Gurus,
>
> How does your organizations manage the local administrator account on
> workstations? Typically the end-users do run with "administrative"
> privileges, but a local admin account is needed to access a machine
> offline. So how is this account typically named (i.e. renamed) and
> password secured (i.e., complex and only a few people know it)? Then you
> have the problem of having to change this password on every workstation if
> a member of the IT staff leaves. Just looking for quick thoughts here, no
> long treatise on the topic is necessary!
>
> --
> Spin

Dan
Sat Aug 30 11:01:00 CDT 2008

Nice advice. The only thing I can think of adding is to make sure the
computers are physically locked down with cables securing the desktops and
ideally in locked and secured rooms with limited access to those rooms on an
as needed basis and the physical locks on the computers like a computer cable
for the desktop to prevent access to the inside of the computers where
someone could physically remove the CMOS battery to reset the BIOS password.

"Mathieu CHATEAU" wrote:

> Hello,
>
> renaming the account isn't helpful when people are logged in. It's useful
> for remote attacker trying to brute force and can't guess it.
> smacking the local admin password is easy from a boot CD. All you can do is
> :
> -Making things harder
> -Automate check on this account and usage.
>
> Making things harder:
> -The Password length must be > 14 to prevent the storage in LM Hash of the
> password (so only NTLM version). Or Storage in LM Hash format must be
> prohibited by GPO.
> -All workstations must have unique local admin pass. If they share the same,
> anyone that got it is admin of all Workstations.
> -Disable the account. It's normally not needed for day to day usage.
> -Set a bios password (one per machine) and only allow boot from Disk. No CD,
> USB or network.
> -Enforce members of the local administrators group through GPO.
>
> Automate checks:
> -Place a logon script on it, so when it's used, it create a flag in registry
> or file. So you have a clue if it was used and when.
> -Audit eventlog securitty for trace of this account being used.
> -Change it every X months. When changing, test for it. So will know if
> someone changed it.
> -Inventory Software installed on wks. Local admin rights is searched for
> being able to install what you want. Especially on Notebooks, which you can
> brings to your best friends, the computer expert one of course.
>
> --
> Cordialement,
> Mathieu CHATEAU
> English blog: http://lordoftheping.blogspot.com
> French blog: http://www.lotp.fr
>
> "Spin" <Spin@invalid.com> a écrit dans le message de
> news:6hrtd6FnibtiU1@mid.individual.net...
> > Gurus,
> >
> > How does your organizations manage the local administrator account on
> > workstations? Typically the end-users do run with "administrative"
> > privileges, but a local admin account is needed to access a machine
> > offline. So how is this account typically named (i.e. renamed) and
> > password secured (i.e., complex and only a few people know it)? Then you
> > have the problem of having to change this password on every workstation if
> > a member of the IT staff leaves. Just looking for quick thoughts here, no
> > long treatise on the topic is necessary!
> >
> > --
> > Spin
>
>

Mathieu
Sat Aug 30 11:43:00 CDT 2008

I have heard even a workaround for this:

Write a bad bit in the bios configuration. Then the bios will return to
default at next boot.
But i don't know tool for this and needed write to do so.
Maybe by customising a bios update tool from Dell or Asus...

--
Cordialement,
Mathieu CHATEAU
English blog: http://lordoftheping.blogspot.com
French blog: http://www.lotp.fr

"Dan" <Dan@discussions.microsoft.com> a écrit dans le message de
news:7D305B84-597B-439D-B96A-D4E3E9D7C2AD@microsoft.com...
> Nice advice. The only thing I can think of adding is to make sure the
> computers are physically locked down with cables securing the desktops and
> ideally in locked and secured rooms with limited access to those rooms on
> an
> as needed basis and the physical locks on the computers like a computer
> cable
> for the desktop to prevent access to the inside of the computers where
> someone could physically remove the CMOS battery to reset the BIOS
> password.
>
> "Mathieu CHATEAU" wrote:
>
>> Hello,
>>
>> renaming the account isn't helpful when people are logged in. It's useful
>> for remote attacker trying to brute force and can't guess it.
>> smacking the local admin password is easy from a boot CD. All you can do
>> is
>> :
>> -Making things harder
>> -Automate check on this account and usage.
>>
>> Making things harder:
>> -The Password length must be > 14 to prevent the storage in LM Hash of
>> the
>> password (so only NTLM version). Or Storage in LM Hash format must be
>> prohibited by GPO.
>> -All workstations must have unique local admin pass. If they share the
>> same,
>> anyone that got it is admin of all Workstations.
>> -Disable the account. It's normally not needed for day to day usage.
>> -Set a bios password (one per machine) and only allow boot from Disk. No
>> CD,
>> USB or network.
>> -Enforce members of the local administrators group through GPO.
>>
>> Automate checks:
>> -Place a logon script on it, so when it's used, it create a flag in
>> registry
>> or file. So you have a clue if it was used and when.
>> -Audit eventlog securitty for trace of this account being used.
>> -Change it every X months. When changing, test for it. So will know if
>> someone changed it.
>> -Inventory Software installed on wks. Local admin rights is searched for
>> being able to install what you want. Especially on Notebooks, which you
>> can
>> brings to your best friends, the computer expert one of course.
>>
>> --
>> Cordialement,
>> Mathieu CHATEAU
>> English blog: http://lordoftheping.blogspot.com
>> French blog: http://www.lotp.fr
>>
>> "Spin" <Spin@invalid.com> a écrit dans le message de
>> news:6hrtd6FnibtiU1@mid.individual.net...
>> > Gurus,
>> >
>> > How does your organizations manage the local administrator account on
>> > workstations? Typically the end-users do run with "administrative"
>> > privileges, but a local admin account is needed to access a machine
>> > offline. So how is this account typically named (i.e. renamed) and
>> > password secured (i.e., complex and only a few people know it)? Then
>> > you
>> > have the problem of having to change this password on every workstation
>> > if
>> > a member of the IT staff leaves. Just looking for quick thoughts here,
>> > no
>> > long treatise on the topic is necessary!
>> >
>> > --
>> > Spin
>>
>>

Anteaus
Sun Aug 31 03:50:00 CDT 2008

Possibly, though it would not be easy to exploit.

On this subject, bear in mind that setting and forgetting a notebook BIOS
password can effectively brick the machine. The password is typically stored
in a NVRAM chip, and sometimes the only remedy possible is to replace this
chip, which requires SMD soldering kit. This is more of a concern, especially
as there is in most cases no way to prevent a 'clever clogs' user from doing
the set/forget trick, not realising the seriousness of their blunder.

Some OEMs even go as far as provide a desktop utility that sets the NVRAM
password. Most users, on seeing this, will *think* it sets their LAN
password, with predictable consequences.

"Mathieu CHATEAU" wrote:

> I have heard even a workaround for this:
>
> Write a bad bit in the bios configuration. Then the bios will return to
> default at next boot.
> But i don't know tool for this and needed write to do so.
> Maybe by customising a bios update tool from Dell or Asus...
>

Roger
Sun Aug 31 08:49:24 CDT 2008

"Anteaus" <Anteaus@discussions.microsoft.com> wrote in message
news:7722DB1B-B8CA-47CD-A2C2-D2FD5997E982@microsoft.com...
> Likewise we make users local admins, having found limited-user working to
> cause too many problems. We maintain the local Administrator password with
> a
> small program run from the logon-script. This arrangement has the
> advantage
> that if an installer forgets to set a password, the standardised one will
> be
> set at next logon.
>
> The key thing is to make sure users don't get added to the Domain Admins
> group. I've seen sites that are like this, and it leaves the whole network
> open to attack from any one compromised computer.
>
>> > How does your organizations manage the local administrator account on
>> > workstations? Typically the end-users do run with "administrative"
>> > privileges, but a local admin account is needed to access a machine
>> > offline. So how is this account typically named (i.e. renamed) and
>> > password secured (i.e., complex and only a few people know it)? Then
>> > you have the problem of having to change this password on every
>> > workstation if a member of the IT staff leaves. Just looking for
>> > quick thoughts here, no long treatise on the topic is necessary!
>

I could argue that your entire client infrastructure is open to high risk,
not just of attack/compromise but perhaps more significantly for violation
of information privacy. Consider, any account (you say they are admins)
can get the local admin password from the program used to set that pwd.
It might take a little effort, but I would bet that you cannot prevent that.
So, any accont can obtain a password valid for admin access on any of
the client systems. That basically means that anything stored on any of
those systems is or can be made available. As for network stored data
it would only by a keylogger away.

Roger
PS We have found that users can function without problem as non-admin.

Roger
Sun Aug 31 08:51:58 CDT 2008

You have listed some good techniques Mathieu, thanks for sharing.
Roger

"Mathieu CHATEAU" <gollum123@free.fr> wrote in message
news:48b93cf6$0$10452$426a74cc@news.free.fr...
> Hello,
>
> renaming the account isn't helpful when people are logged in. It's useful
> for remote attacker trying to brute force and can't guess it.
> smacking the local admin password is easy from a boot CD. All you can do
> is :
> -Making things harder
> -Automate check on this account and usage.
>
> Making things harder:
> -The Password length must be > 14 to prevent the storage in LM Hash of the
> password (so only NTLM version). Or Storage in LM Hash format must be
> prohibited by GPO.
> -All workstations must have unique local admin pass. If they share the
> same, anyone that got it is admin of all Workstations.
> -Disable the account. It's normally not needed for day to day usage.
> -Set a bios password (one per machine) and only allow boot from Disk. No
> CD, USB or network.
> -Enforce members of the local administrators group through GPO.
>
> Automate checks:
> -Place a logon script on it, so when it's used, it create a flag in
> registry or file. So you have a clue if it was used and when.
> -Audit eventlog securitty for trace of this account being used.
> -Change it every X months. When changing, test for it. So will know if
> someone changed it.
> -Inventory Software installed on wks. Local admin rights is searched for
> being able to install what you want. Especially on Notebooks, which you
> can brings to your best friends, the computer expert one of course.
>
> --
> Cordialement,
> Mathieu CHATEAU
> English blog: http://lordoftheping.blogspot.com
> French blog: http://www.lotp.fr
>
> "Spin" <Spin@invalid.com> a écrit dans le message de
> news:6hrtd6FnibtiU1@mid.individual.net...
>> Gurus,
>>
>> How does your organizations manage the local administrator account on
>> workstations? Typically the end-users do run with "administrative"
>> privileges, but a local admin account is needed to access a machine
>> offline. So how is this account typically named (i.e. renamed) and
>> password secured (i.e., complex and only a few people know it)? Then you
>> have the problem of having to change this password on every workstation
>> if a member of the IT staff leaves. Just looking for quick thoughts
>> here, no long treatise on the topic is necessary!
>>
>> --
>> Spin
>

Roger
Sun Aug 31 09:03:11 CDT 2008

Also, look at what Group Policy Preferences can do for you, allowing you
to run computer startup/shutdown script (selectively by GPO targets).
Setting password from network is always a hazard as at some point the
password is either available on the network or it is obtainable from its
storage point, but at least with computer script you can make that storage
inaccessible to all except the computer accounts that need access.

As far as I have determined, client system local admin account(s) are a
darned if you do and darned if you don't situation. The local account is
not needed on most systems for daily operations. If something happens
such that local admin login is needed it probably needs to have been set
up / enabled before that something happens. If there is no local admin
account prepared and available, then techs are using domain accounts,
which probably means that there are domain accounts in daily use that
have large-scale admin access over all, or major sections of, the client
systems. If one tries to keep one local admin account ready to go, it
should have either a unique password (and not one that can be determined
from some formula such that if you know one you can substitute part and
get the password for another system) or if not unique then many should
be used, each on some small logical subset of the client systems. That
however has problems in keeping track of what password to use where
and of making passwords available when need (and only then) to those
that need to use them (and only to those).

There simply appears to be no great solution when using only accounts
and passwords.

Roger

"Spin" <Spin@invalid.com> wrote in message
news:6hrtd6FnibtiU1@mid.individual.net...
> Gurus,
>
> How does your organizations manage the local administrator account on
> workstations? Typically the end-users do run with "administrative"
> privileges, but a local admin account is needed to access a machine
> offline. So how is this account typically named (i.e. renamed) and
> password secured (i.e., complex and only a few people know it)? Then you
> have the problem of having to change this password on every workstation if
> a member of the IT staff leaves. Just looking for quick thoughts here, no
> long treatise on the topic is necessary!
>
> --
> Spin

Dan
Sun Aug 31 17:40:00 CDT 2008

Okay, so what is the best policy to secure the network? I am thinking a
combination of biometrics, passwords and potentially keycards. What are
people's thoughts on this. Perhaps, this list as a suggestion:

1. fingerprint scanner -- cleaned when done to prevent band-aid technique of
using same fingerprints after person scanned originally

2. keycard access --- perhaps as a swipe which is a special keycard seperate
from access keycard to secure and safe computer room

3. complex password to login to computer --- numerous passwords with at
least 7+ alpha-numeric and special character and grc.com can generate random
complex passwords to give users an idea and Microsoft's password checker is
also good.

4. Any other thoughts?

"Roger Abell [MVP]" wrote:

> Also, look at what Group Policy Preferences can do for you, allowing you
> to run computer startup/shutdown script (selectively by GPO targets).
> Setting password from network is always a hazard as at some point the
> password is either available on the network or it is obtainable from its
> storage point, but at least with computer script you can make that storage
> inaccessible to all except the computer accounts that need access.
>
> As far as I have determined, client system local admin account(s) are a
> darned if you do and darned if you don't situation. The local account is
> not needed on most systems for daily operations. If something happens
> such that local admin login is needed it probably needs to have been set
> up / enabled before that something happens. If there is no local admin
> account prepared and available, then techs are using domain accounts,
> which probably means that there are domain accounts in daily use that
> have large-scale admin access over all, or major sections of, the client
> systems. If one tries to keep one local admin account ready to go, it
> should have either a unique password (and not one that can be determined
> from some formula such that if you know one you can substitute part and
> get the password for another system) or if not unique then many should
> be used, each on some small logical subset of the client systems. That
> however has problems in keeping track of what password to use where
> and of making passwords available when need (and only then) to those
> that need to use them (and only to those).
>
> There simply appears to be no great solution when using only accounts
> and passwords.
>
> Roger
>
> "Spin" <Spin@invalid.com> wrote in message
> news:6hrtd6FnibtiU1@mid.individual.net...
> > Gurus,
> >
> > How does your organizations manage the local administrator account on
> > workstations? Typically the end-users do run with "administrative"
> > privileges, but a local admin account is needed to access a machine
> > offline. So how is this account typically named (i.e. renamed) and
> > password secured (i.e., complex and only a few people know it)? Then you
> > have the problem of having to change this password on every workstation if
> > a member of the IT staff leaves. Just looking for quick thoughts here, no
> > long treatise on the topic is necessary!
> >
> > --
> > Spin
>
>
>

Brian
Sun Aug 31 17:48:01 CDT 2008

How about something that actually works, like two factor authentication.
Fingerprint scanners are easily defeated, watch Mythbusters
Card key access is getting there, but swipe is one factor.
7+ passwords is really not a strong passwored. Especially when working with
archaic operating systems like Windows 98 that use LM hashes that are easily
broken. A real operating system would recomend using passphrases that are
16+ characters.
Brian

"Dan" <Dan@discussions.microsoft.com> wrote in message
news:BFC78AB9-187E-47F5-987D-1E62FDAD6248@microsoft.com...
> Okay, so what is the best policy to secure the network? I am thinking a
> combination of biometrics, passwords and potentially keycards. What are
> people's thoughts on this. Perhaps, this list as a suggestion:
>
> 1. fingerprint scanner -- cleaned when done to prevent band-aid technique
> of
> using same fingerprints after person scanned originally
>
> 2. keycard access --- perhaps as a swipe which is a special keycard
> seperate
> from access keycard to secure and safe computer room
>
> 3. complex password to login to computer --- numerous passwords with at
> least 7+ alpha-numeric and special character and grc.com can generate
> random
> complex passwords to give users an idea and Microsoft's password checker
> is
> also good.
>
> 4. Any other thoughts?
>
> "Roger Abell [MVP]" wrote:
>
>> Also, look at what Group Policy Preferences can do for you, allowing you
>> to run computer startup/shutdown script (selectively by GPO targets).
>> Setting password from network is always a hazard as at some point the
>> password is either available on the network or it is obtainable from its
>> storage point, but at least with computer script you can make that
>> storage
>> inaccessible to all except the computer accounts that need access.
>>
>> As far as I have determined, client system local admin account(s) are a
>> darned if you do and darned if you don't situation. The local account is
>> not needed on most systems for daily operations. If something happens
>> such that local admin login is needed it probably needs to have been set
>> up / enabled before that something happens. If there is no local admin
>> account prepared and available, then techs are using domain accounts,
>> which probably means that there are domain accounts in daily use that
>> have large-scale admin access over all, or major sections of, the client
>> systems. If one tries to keep one local admin account ready to go, it
>> should have either a unique password (and not one that can be determined
>> from some formula such that if you know one you can substitute part and
>> get the password for another system) or if not unique then many should
>> be used, each on some small logical subset of the client systems. That
>> however has problems in keeping track of what password to use where
>> and of making passwords available when need (and only then) to those
>> that need to use them (and only to those).
>>
>> There simply appears to be no great solution when using only accounts
>> and passwords.
>>
>> Roger
>>
>> "Spin" <Spin@invalid.com> wrote in message
>> news:6hrtd6FnibtiU1@mid.individual.net...
>> > Gurus,
>> >
>> > How does your organizations manage the local administrator account on
>> > workstations? Typically the end-users do run with "administrative"
>> > privileges, but a local admin account is needed to access a machine
>> > offline. So how is this account typically named (i.e. renamed) and
>> > password secured (i.e., complex and only a few people know it)? Then
>> > you
>> > have the problem of having to change this password on every workstation
>> > if
>> > a member of the IT staff leaves. Just looking for quick thoughts here,
>> > no
>> > long treatise on the topic is necessary!
>> >
>> > --
>> > Spin
>>
>>
>>

Mathieu
Mon Sep 01 01:04:49 CDT 2008

Hello,

LM Hash are not stored when length is > 14. But new risk are there, like
brute force with nvidia graphics cards and larger rainbow table.

Steve Riley (MS Security guy) wrote an excellent article on password
policies:
http://blogs.technet.com/steriley/archive/2007/09/04/passwords-policies-once-again.aspx

--
Cordialement,
Mathieu CHATEAU
English blog: http://lordoftheping.blogspot.com
French blog: http://www.lotp.fr

"Brian Komar (MVP)" <brian.komar@nospam.identit.ca> a écrit dans le message
de news:F20B2B2D-A9D0-41D2-9D51-261317A47E75@microsoft.com...
> How about something that actually works, like two factor authentication.
> Fingerprint scanners are easily defeated, watch Mythbusters
> Card key access is getting there, but swipe is one factor.
> 7+ passwords is really not a strong passwored. Especially when working
> with archaic operating systems like Windows 98 that use LM hashes that are
> easily broken. A real operating system would recomend using passphrases
> that are 16+ characters.
> Brian
>
> "Dan" <Dan@discussions.microsoft.com> wrote in message
> news:BFC78AB9-187E-47F5-987D-1E62FDAD6248@microsoft.com...
>> Okay, so what is the best policy to secure the network? I am thinking a
>> combination of biometrics, passwords and potentially keycards. What are
>> people's thoughts on this. Perhaps, this list as a suggestion:
>>
>> 1. fingerprint scanner -- cleaned when done to prevent band-aid technique
>> of
>> using same fingerprints after person scanned originally
>>
>> 2. keycard access --- perhaps as a swipe which is a special keycard
>> seperate
>> from access keycard to secure and safe computer room
>>
>> 3. complex password to login to computer --- numerous passwords with at
>> least 7+ alpha-numeric and special character and grc.com can generate
>> random
>> complex passwords to give users an idea and Microsoft's password checker
>> is
>> also good.
>>
>> 4. Any other thoughts?
>>
>> "Roger Abell [MVP]" wrote:
>>
>>> Also, look at what Group Policy Preferences can do for you, allowing you
>>> to run computer startup/shutdown script (selectively by GPO targets).
>>> Setting password from network is always a hazard as at some point the
>>> password is either available on the network or it is obtainable from its
>>> storage point, but at least with computer script you can make that
>>> storage
>>> inaccessible to all except the computer accounts that need access.
>>>
>>> As far as I have determined, client system local admin account(s) are a
>>> darned if you do and darned if you don't situation. The local account
>>> is
>>> not needed on most systems for daily operations. If something happens
>>> such that local admin login is needed it probably needs to have been set
>>> up / enabled before that something happens. If there is no local admin
>>> account prepared and available, then techs are using domain accounts,
>>> which probably means that there are domain accounts in daily use that
>>> have large-scale admin access over all, or major sections of, the client
>>> systems. If one tries to keep one local admin account ready to go, it
>>> should have either a unique password (and not one that can be determined
>>> from some formula such that if you know one you can substitute part and
>>> get the password for another system) or if not unique then many should
>>> be used, each on some small logical subset of the client systems. That
>>> however has problems in keeping track of what password to use where
>>> and of making passwords available when need (and only then) to those
>>> that need to use them (and only to those).
>>>
>>> There simply appears to be no great solution when using only accounts
>>> and passwords.
>>>
>>> Roger
>>>
>>> "Spin" <Spin@invalid.com> wrote in message
>>> news:6hrtd6FnibtiU1@mid.individual.net...
>>> > Gurus,
>>> >
>>> > How does your organizations manage the local administrator account on
>>> > workstations? Typically the end-users do run with "administrative"
>>> > privileges, but a local admin account is needed to access a machine
>>> > offline. So how is this account typically named (i.e. renamed) and
>>> > password secured (i.e., complex and only a few people know it)? Then
>>> > you
>>> > have the problem of having to change this password on every
>>> > workstation if
>>> > a member of the IT staff leaves. Just looking for quick thoughts
>>> > here, no
>>> > long treatise on the topic is necessary!
>>> >
>>> > --
>>> > Spin
>>>
>>>
>>>
>

S
Mon Sep 01 03:42:28 CDT 2008

G'day:

Roger Abell [MVP] wrote:
> "Anteaus" <Anteaus@discussions.microsoft.com> wrote in message

>> Likewise we make users local admins, having found limited-user working to
>> cause too many problems. We maintain the local Administrator password with
>> a
>> small program run from the logon-script. This arrangement has the
>> advantage
>> that if an installer forgets to set a password, the standardised one will
>> be
>> set at next logon.

> I could argue that your entire client infrastructure is open to high risk,
> not just of attack/compromise but perhaps more significantly for violation
> of information privacy. Consider, any account (you say they are admins)
> can get the local admin password from the program used to set that pwd.
> It might take a little effort, but I would bet that you cannot prevent that.
> So, any accont can obtain a password valid for admin access on any of
> the client systems. That basically means that anything stored on any of
> those systems is or can be made available. As for network stored data
> it would only by a keylogger away.
>
> Roger
> PS We have found that users can function without problem as non-admin.

I second Roger's comments.

If you want to manage local admin passwords, you actually have to alert
on every case the local password will be changed. Otherwise there is
little point.


--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

S
Mon Sep 01 03:47:44 CDT 2008

G'day:

Spin wrote:
> Gurus,
>
> How does your organizations manage the local administrator account on
> workstations? Typically the end-users do run with "administrative"
> privileges, but a local admin account is needed to access a machine
> offline. So how is this account typically named (i.e. renamed) and
> password secured (i.e., complex and only a few people know it)? Then
> you have the problem of having to change this password on every
> workstation if a member of the IT staff leaves. Just looking for quick
> thoughts here, no long treatise on the topic is necessary!
>

Set random password and throw it away. Do not try managing passwords for
disk encryption either.

Users should not have expectation that the data located on the local
disks can be recovered in case of the system failure. Store data on servers.

Stateless systems that actually reset to original state when user logs
off will proliferate, thanks to advances of virtual desktop
technologies. There is no point in managing local admin password on such
systems.

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

S
Mon Sep 01 03:54:19 CDT 2008

Side note: pass-the-hash techniques actually allow to exploit strong
password protection, including smart-card only admin logons, as there is
no need to brute force. Of course the attack requires the administrator
to log on to already compromised system, which is why local admin
protection is even more important.

Some info:
http://truesecurity.se/blogs/murray/archive/tags/passing-the-hash/default.aspx


--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

Mathieu CHATEAU wrote:
> Hello,
>
> LM Hash are not stored when length is > 14. But new risk are there, like
> brute force with nvidia graphics cards and larger rainbow table.
>
> Steve Riley (MS Security guy) wrote an excellent article on password
> policies:
> http://blogs.technet.com/steriley/archive/2007/09/04/passwords-policies-once-again.aspx
>
>

Brian
Mon Sep 01 08:22:46 CDT 2008

Ummm, Yes this is true if we are talking about the NT code base
The point I was making is that the glorified Windows 98 code base only
supported max 14 characters.
Trust me, I know that anything above 14 characters does not store a LM hash
(in AD)
That is why you cannot use that long of a password with Win98
Brian
"Mathieu CHATEAU" <gollum123@free.fr> wrote in message
news:48bb8603$0$23998$426a34cc@news.free.fr...
> Hello,
>
> LM Hash are not stored when length is > 14. But new risk are there, like
> brute force with nvidia graphics cards and larger rainbow table.
>
> Steve Riley (MS Security guy) wrote an excellent article on password
> policies:
> http://blogs.technet.com/steriley/archive/2007/09/04/passwords-policies-once-again.aspx
>
> --
> Cordialement,
> Mathieu CHATEAU
> English blog: http://lordoftheping.blogspot.com
> French blog: http://www.lotp.fr
>
> "Brian Komar (MVP)" <brian.komar@nospam.identit.ca> a écrit dans le
> message de news:F20B2B2D-A9D0-41D2-9D51-261317A47E75@microsoft.com...
>> How about something that actually works, like two factor authentication.
>> Fingerprint scanners are easily defeated, watch Mythbusters
>> Card key access is getting there, but swipe is one factor.
>> 7+ passwords is really not a strong passwored. Especially when working
>> with archaic operating systems like Windows 98 that use LM hashes that
>> are easily broken. A real operating system would recomend using
>> passphrases that are 16+ characters.
>> Brian
>>
>> "Dan" <Dan@discussions.microsoft.com> wrote in message
>> news:BFC78AB9-187E-47F5-987D-1E62FDAD6248@microsoft.com...
>>> Okay, so what is the best policy to secure the network? I am thinking a
>>> combination of biometrics, passwords and potentially keycards. What are
>>> people's thoughts on this. Perhaps, this list as a suggestion:
>>>
>>> 1. fingerprint scanner -- cleaned when done to prevent band-aid
>>> technique of
>>> using same fingerprints after person scanned originally
>>>
>>> 2. keycard access --- perhaps as a swipe which is a special keycard
>>> seperate
>>> from access keycard to secure and safe computer room
>>>
>>> 3. complex password to login to computer --- numerous passwords with at
>>> least 7+ alpha-numeric and special character and grc.com can generate
>>> random
>>> complex passwords to give users an idea and Microsoft's password checker
>>> is
>>> also good.
>>>
>>> 4. Any other thoughts?
>>>
>>> "Roger Abell [MVP]" wrote:
>>>
>>>> Also, look at what Group Policy Preferences can do for you, allowing
>>>> you
>>>> to run computer startup/shutdown script (selectively by GPO targets).
>>>> Setting password from network is always a hazard as at some point the
>>>> password is either available on the network or it is obtainable from
>>>> its
>>>> storage point, but at least with computer script you can make that
>>>> storage
>>>> inaccessible to all except the computer accounts that need access.
>>>>
>>>> As far as I have determined, client system local admin account(s) are a
>>>> darned if you do and darned if you don't situation. The local account
>>>> is
>>>> not needed on most systems for daily operations. If something happens
>>>> such that local admin login is needed it probably needs to have been
>>>> set
>>>> up / enabled before that something happens. If there is no local admin
>>>> account prepared and available, then techs are using domain accounts,
>>>> which probably means that there are domain accounts in daily use that
>>>> have large-scale admin access over all, or major sections of, the
>>>> client
>>>> systems. If one tries to keep one local admin account ready to go, it
>>>> should have either a unique password (and not one that can be
>>>> determined
>>>> from some formula such that if you know one you can substitute part and
>>>> get the password for another system) or if not unique then many should
>>>> be used, each on some small logical subset of the client systems. That
>>>> however has problems in keeping track of what password to use where
>>>> and of making passwords available when need (and only then) to those
>>>> that need to use them (and only to those).
>>>>
>>>> There simply appears to be no great solution when using only accounts
>>>> and passwords.
>>>>
>>>> Roger
>>>>
>>>> "Spin" <Spin@invalid.com> wrote in message
>>>> news:6hrtd6FnibtiU1@mid.individual.net...
>>>> > Gurus,
>>>> >
>>>> > How does your organizations manage the local administrator account on
>>>> > workstations? Typically the end-users do run with "administrative"
>>>> > privileges, but a local admin account is needed to access a machine
>>>> > offline. So how is this account typically named (i.e. renamed) and
>>>> > password secured (i.e., complex and only a few people know it)? Then
>>>> > you
>>>> > have the problem of having to change this password on every
>>>> > workstation if
>>>> > a member of the IT staff leaves. Just looking for quick thoughts
>>>> > here, no
>>>> > long treatise on the topic is necessary!
>>>> >
>>>> > --
>>>> > Spin
>>>>
>>>>
>>>>
>>
>

Dan
Tue Sep 02 11:05:01 CDT 2008

Okay, so passwords greater than 17 characters using alph-numeric with special
symbols and would protecting them with 448-bit Blowfish encryption be good
enough in this day and age?

"Brian Komar (MVP)" wrote:

> How about something that actually works, like two factor authentication.
> Fingerprint scanners are easily defeated, watch Mythbusters
> Card key access is getting there, but swipe is one factor.
> 7+ passwords is really not a strong passwored. Especially when working with
> archaic operating systems like Windows 98 that use LM hashes that are easily
> broken. A real operating system would recomend using passphrases that are
> 16+ characters.
> Brian
>
> "Dan" <Dan@discussions.microsoft.com> wrote in message
> news:BFC78AB9-187E-47F5-987D-1E62FDAD6248@microsoft.com...
> > Okay, so what is the best policy to secure the network? I am thinking a
> > combination of biometrics, passwords and potentially keycards. What are
> > people's thoughts on this. Perhaps, this list as a suggestion:
> >
> > 1. fingerprint scanner -- cleaned when done to prevent band-aid technique
> > of
> > using same fingerprints after person scanned originally
> >
> > 2. keycard access --- perhaps as a swipe which is a special keycard
> > seperate
> > from access keycard to secure and safe computer room
> >
> > 3. complex password to login to computer --- numerous passwords with at
> > least 7+ alpha-numeric and special character and grc.com can generate
> > random
> > complex passwords to give users an idea and Microsoft's password checker
> > is
> > also good.
> >
> > 4. Any other thoughts?
> >
> > "Roger Abell [MVP]" wrote:
> >
> >> Also, look at what Group Policy Preferences can do for you, allowing you
> >> to run computer startup/shutdown script (selectively by GPO targets).
> >> Setting password from network is always a hazard as at some point the
> >> password is either available on the network or it is obtainable from its
> >> storage point, but at least with computer script you can make that
> >> storage
> >> inaccessible to all except the computer accounts that need access.
> >>
> >> As far as I have determined, client system local admin account(s) are a
> >> darned if you do and darned if you don't situation. The local account is
> >> not needed on most systems for daily operations. If something happens
> >> such that local admin login is needed it probably needs to have been set
> >> up / enabled before that something happens. If there is no local admin
> >> account prepared and available, then techs are using domain accounts,
> >> which probably means that there are domain accounts in daily use that
> >> have large-scale admin access over all, or major sections of, the client
> >> systems. If one tries to keep one local admin account ready to go, it
> >> should have either a unique password (and not one that can be determined
> >> from some formula such that if you know one you can substitute part and
> >> get the password for another system) or if not unique then many should
> >> be used, each on some small logical subset of the client systems. That
> >> however has problems in keeping track of what password to use where
> >> and of making passwords available when need (and only then) to those
> >> that need to use them (and only to those).
> >>
> >> There simply appears to be no great solution when using only accounts
> >> and passwords.
> >>
> >> Roger
> >>
> >> "Spin" <Spin@invalid.com> wrote in message
> >> news:6hrtd6FnibtiU1@mid.individual.net...
> >> > Gurus,
> >> >
> >> > How does your organizations manage the local administrator account on
> >> > workstations? Typically the end-users do run with "administrative"
> >> > privileges, but a local admin account is needed to access a machine
> >> > offline. So how is this account typically named (i.e. renamed) and
> >> > password secured (i.e., complex and only a few people know it)? Then
> >> > you
> >> > have the problem of having to change this password on every workstation
> >> > if
> >> > a member of the IT staff leaves. Just looking for quick thoughts here,
> >> > no
> >> > long treatise on the topic is necessary!
> >> >
> >> > --
> >> > Spin
> >>
> >>
> >>
>

Dan
Tue Sep 02 11:20:00 CDT 2008

Thanks, Brian

"Brian Komar (MVP)" wrote:

> Only if using a modern, securely designed OS, Dan.
> I am really done discussing this BS topic with you, as it just lends
> creedence to your absurd theories.
> Brian
> "Dan" <Dan@discussions.microsoft.com> wrote in message
> news:A80049C9-3996-476C-A611-AD52DC97BC3F@microsoft.com...
> > Okay, so passwords greater than 17 characters using alph-numeric with
> > special
> > symbols and would protecting them with 448-bit Blowfish encryption be good
> > enough in this day and age?
> >
> > "Brian Komar (MVP)" wrote:
> >
> >> How about something that actually works, like two factor authentication.
> >> Fingerprint scanners are easily defeated, watch Mythbusters
> >> Card key access is getting there, but swipe is one factor.
> >> 7+ passwords is really not a strong passwored. Especially when working
> >> with
> >> archaic operating systems like Windows 98 that use LM hashes that are
> >> easily
> >> broken. A real operating system would recomend using passphrases that are
> >> 16+ characters.
> >> Brian
> >>
> >> "Dan" <Dan@discussions.microsoft.com> wrote in message
> >> news:BFC78AB9-187E-47F5-987D-1E62FDAD6248@microsoft.com...
> >> > Okay, so what is the best policy to secure the network? I am thinking
> >> > a
> >> > combination of biometrics, passwords and potentially keycards. What
> >> > are
> >> > people's thoughts on this. Perhaps, this list as a suggestion:
> >> >
> >> > 1. fingerprint scanner -- cleaned when done to prevent band-aid
> >> > technique
> >> > of
> >> > using same fingerprints after person scanned originally
> >> >
> >> > 2. keycard access --- perhaps as a swipe which is a special keycard
> >> > seperate
> >> > from access keycard to secure and safe computer room
> >> >
> >> > 3. complex password to login to computer --- numerous passwords with at
> >> > least 7+ alpha-numeric and special character and grc.com can generate
> >> > random
> >> > complex passwords to give users an idea and Microsoft's password
> >> > checker
> >> > is
> >> > also good.
> >> >
> >> > 4. Any other thoughts?
> >> >
> >> > "Roger Abell [MVP]" wrote:
> >> >
> >> >> Also, look at what Group Policy Preferences can do for you, allowing
> >> >> you
> >> >> to run computer startup/shutdown script (selectively by GPO targets).
> >> >> Setting password from network is always a hazard as at some point the
> >> >> password is either available on the network or it is obtainable from
> >> >> its
> >> >> storage point, but at least with computer script you can make that
> >> >> storage
> >> >> inaccessible to all except the computer accounts that need access.
> >> >>
> >> >> As far as I have determined, client system local admin account(s) are
> >> >> a
> >> >> darned if you do and darned if you don't situation. The local account
> >> >> is
> >> >> not needed on most systems for daily operations. If something happens
> >> >> such that local admin login is needed it probably needs to have been
> >> >> set
> >> >> up / enabled before that something happens. If there is no local
> >> >> admin
> >> >> account prepared and available, then techs are using domain accounts,
> >> >> which probably means that there are domain accounts in daily use that
> >> >> have large-scale admin access over all, or major sections of, the
> >> >> client
> >> >> systems. If one tries to keep one local admin account ready to go, it
> >> >> should have either a unique password (and not one that can be
> >> >> determined
> >> >> from some formula such that if you know one you can substitute part
> >> >> and
> >> >> get the password for another system) or if not unique then many should
> >> >> be used, each on some small logical subset of the client systems.
> >> >> That
> >> >> however has problems in keeping track of what password to use where
> >> >> and of making passwords available when need (and only then) to those
> >> >> that need to use them (and only to those).
> >> >>
> >> >> There simply appears to be no great solution when using only accounts
> >> >> and passwords.
> >> >>
> >> >> Roger
> >> >>
> >> >> "Spin" <Spin@invalid.com> wrote in message
> >> >> news:6hrtd6FnibtiU1@mid.individual.net...
> >> >> > Gurus,
> >> >> >
> >> >> > How does your organizations manage the local administrator account
> >> >> > on
> >> >> > workstations? Typically the end-users do run with "administrative"
> >> >> > privileges, but a local admin