4

We have a network with Windows 7 Enterprise machines, all members of a domain. We've been keeping a local (unlocked) 'Admin' account on each workstation in parallel to the built-in (locked) 'Administrator' account. Since installation of the OS requires an initial account to be created before the computer is joined into the domain, we've left the 'Admin' account with a strong password as it is. However, this requires the same password to be used across machines, and possibly never expiring.

Note that in our environment we don't restrict users (mostly developers) much and don't plan to do so. Usually domain user accounts are members of the Administrators group on respective desktops. On the other hand, we try to keep things centrally managed.

What are the pros and cons of keeping such local (non-domain) admin accounts on domain-joined workstations in respect to:

  • security
  • management
  • data access
  • problem solving
Improve this question

2 Answers 2

Reset to default
4

What are the pros and cons of keeping such local (non-domain) admin accounts on domain-joined workstations in respect to:

Security

There's little difference. An account with administrative privileges can destroy a machine. This is true whether we're talking about a domain or local account. Some would argue that the local Administrator account is more vulnerable to attack simply because it's a well-known username. If that's a concern, you can always change the account's username with a GPP although this doesn't mitigate attacks that rely on the account's well-known SID, which cannot be changed. IMHO it's more important to use a strong password than try to evade unwanted logon attempts.

One noteworthy difference unique to the local administrator account is that by default it automatically bypasses UAC. This is meaningless if an attacker is logged in; UAC won't stop him. However, UAC can be useful to help protect a legitimate admin. This behavior can be changed through GP eliminating it as a difference.

Management

Local accounts are harder to manage. And not just the local Administrator account. Changing a domain account is easily done in one place, affecting all computers where the account is used. A local account can only be modified on the workstation where it exists. However, with the advent of Group Policy Preferences, some local account changes (e.g. renaming the local Administrator to something else [see above]) can be managed with Group Policy. There are also utilities available for changing local account passwords.

Data Access/Problem Solving

A local administrator account is indispensable. Only the previous 10 domain accounts to successfully logon a machine can still logon in the event connectivity to a DC is lost (this number is configurable). If none of these accounts have local admin privileges and you're troubleshooting a machine that can't establish a network connection, you're stuck. Even access to the Recovery Console won't be possible (at least without hacks). But with an available local Administrator account, you never have to worry about this happening. For this reason alone I have a local admin account on all domain machines I manage, including (especially) servers.

Improve this answer
2
  • 2
    The actual local administrator account (regardless of its name) bypasses UAC policies which makes it slightly more of a security risk than other accounts in the Administrators group. Also, renaming the administrator account doesn't really do much any more because most of the malware and pen testing tools have moved to using the SID instead of the username.
    – Ryan Bolger
    Dec 10, 2014 at 19:02
  • Excellent observations. I've included both points in my answer with links for reference, including how to disable the automatic UAC bypass for the built-in Administrator account.
    – I say Reinstate Monica
    Dec 10, 2014 at 19:52
1

my rep is still too low to post comments so i have to post this as an answer:

having a local admin account is generally a good idea, when the network fails or the domain membership expires you can still log in and fix the problem. BUT having the same password for all machines is no good idea, there are two possible solutions for this 1. change the password regulary 2. write some script that generates a random password and store it where only you have access (e.g. on a share)

Improve this answer
4
  • A better way to store these passwords would be to use a unique identifier to the system (like either a hostname, or serial number etc..) and create a "generator" that you can query with this identifier and it will produce the password. This way, you don't have actual admin passwords written somewhere, and you can access/password protect this generator.
    – sandroid
    Oct 30, 2011 at 21:00
  • 1
    then your passwords are only as good as the generating algorith, also you would have to hide/protect the generator itself.
    – weberik
    Oct 30, 2011 at 22:23
  • Having a unique password for each machine is generally a good idea; however, it's a security/complexity tradeoff. I'm speaking about ~10 machines. Also, I'd recommend using a password manager like KeePass. My primary concern rather is whether I'd ever need a local admin account once the machine is in a domain -- whether this is a frequently used measure or not.
    – Ondrej Tucny
    Oct 30, 2011 at 22:47
  • maybe you can disable the local admin account completely then, if there is a problem you still could activate it using some bootable recovery tool like ntpasswd or CIA/ERD commander. i used local admin accounts quite a few times in my life, usually when the domain is not reachable due to network problems
    – weberik
    Oct 30, 2011 at 23:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .