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

Discussion in 'Server Networking' started by Spin, Aug 30, 2008.

  1. Spin

    Spin Guest


    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, Aug 30, 2008
    1. Advertisements

  2. Spin

    Spin Guest

    I meant to say "Typically the end-users don't run with "administrative"
    Spin, Aug 30, 2008
    1. Advertisements

  3. 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:

    Best regards

    Meinolf Weber
    Meinolf Weber, Aug 30, 2008
  4. Spin

    Anteaus Guest

    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.
    Anteaus, Aug 30, 2008
  5. 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.
    Mathieu CHATEAU, Aug 30, 2008
  6. Spin

    Dan Guest

    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.
    Dan, Aug 30, 2008
  7. 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...
    Mathieu CHATEAU, Aug 30, 2008
  8. Spin

    Anteaus Guest

    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.
    Anteaus, Aug 31, 2008
  9. 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.

    PS We have found that users can function without problem as non-admin.
    Roger Abell [MVP], Aug 31, 2008
  10. You have listed some good techniques Mathieu, thanks for sharing.
    Roger Abell [MVP], Aug 31, 2008
  11. 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 Abell [MVP], Aug 31, 2008
  12. Spin

    Dan Guest

    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 can generate random
    complex passwords to give users an idea and Microsoft's password checker is
    also good.

    4. Any other thoughts?
    Dan, Aug 31, 2008
  13. 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 Komar \(MVP\), Aug 31, 2008
  14. Mathieu CHATEAU, Sep 1, 2008
  15. Spin

    S. Pidgorny Guest

    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.
    S. Pidgorny, Sep 1, 2008
  16. Spin

    S. Pidgorny Guest

    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
    S. Pidgorny, Sep 1, 2008
  17. Spin

    S. Pidgorny Guest

    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:
    S. Pidgorny, Sep 1, 2008
  18. 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 Komar \(MVP\), Sep 1, 2008
  19. Spin

    Dan Guest

    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?
    Dan, Sep 2, 2008
  20. Spin

    Dan Guest

    Thanks, Brian

    Dan, Sep 2, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.