Freigeben über

Disable that Pesky Built-in Administrator Account!

  • Artikel

I'm working on an FAQ for passwords right now. Look for it in the Security Newsletter next month (https://www.microsoft.com/technet/security/secnews/newsletter.htm). However, one thing that has come up more than a few times in the recent past is what to do with the built-in Administrator account. I'm not sure that it fits in the framework of passwords per se, but it may actually merit a blog post, so here are some do's and don'ts. Keep in mind, I am specifically referring only to BUILTIN\Administrator, also known as NT AUTHORITY\Administrator; the account with relative identifier 500.

Do's

  • Disable it. The built-in Administrator is basically a setup and disaster recovery account. We use it during setup and to join the machine to the domain. After we are done with that we should never use it again and it can be disabled. It should never be used during normal operations. For that, each person who administers the system needs his or her own administrative account in addition to the ordinary user account they use to read e-mail, surf the web, play Age Of Empires III, etc. If you allow people to use the built-in Administrator account you lose all ability to audit what anyone is doing. There is no accountability. Not too worried about that? Well, try this: close your eyes and lean back. Now, imagine standing up in a packed court room. You are under cross-investigation by the defense attorney as a hostile witness. The question being asked is how sure you were that it was the defendant who shipped all the company secrets off to your competitor. Your best answer is "well, one of these ten people because it appears that the person logged on as 'Administrator' when he did it." OK. Open your eyes again, and open them real wide this time. Wide enough so that you can see through ease of use to see the CYA benefits of not using the built-in Administrator account.
  • Set a unique password. If the account is disabled, what does it matter what the password is? Well, here is the problem, what if it is not disabled on all systems? Now, be honest with yourself. How many unique passwords are used on the built-in administrator accounts across all systems in your environment? If the answer is less than the number of systems in your environment you have a problem. If only one of those systems gets compromised the bad guy can dump out the password hashes and he now has all that he needs to authenticate to all the other systems using the Administrator account (note that it does not matter how strong the password is here. If the bad guy has hashes, password strength is irrelevant). To avoid this you need to ensure that every system has a unique local Administrator password. How do you do that? There are a couple of options. You can use a tool like User Manager Pro (https://www.liebsoft.com/index.cfm/products/ump), which I am told does this. (I have not used it myself. If you have, please let me know how it works.) You can also use a command line tool that can set the password. Should you wish to actually ever use the account, you need to be able to recover the password. That means either writing it down, or using a tool that can recover it for you. One such tool is passgen, which comes with Protect Your Windows Network (https://www.awprofessional.com/title/0321336437). Passgen is designed to set a pseudo-random password on regular accounts and service accounts, across the network. The password can either be fully random, or based on two pieces of known input: a unique identifier for the system or account, and a common pass phrase. The common pass phrase is the global secret, but it is not stored on any of the systems protected by the secret. Hence, it is much easier to protect than the administrator password on thousands of machines.
  • Set a very long password, or none at all. Obviously a really long password is a good idea, but a blank one may be even better. In an environment where you can guarantee physical security, and you do not need to use the account across the network, leave the administrator account password blank. That way it can not be used across the network, and nobody needs to know what it is. Of course, if you have more than one administrator, it leaves you open to abuse and accountability issues, so you need to carefully consider this approach. If you need to be concerned with those problems, set a very long password; 127 characters or so. That way the account is as good as disabled.

Don'ts

  • Use it. Seriously. You should never use the built-in administrator account. Use your own administrative account instead. If things get so bad that you need the built-in administrator account, flatten the system and rebuild it. It's generally quicker and less painful. If you need to get data off of it first stick the hard drive in another system and get it off that way, or use that carefully tought out disaster recovery plan that's gathering dust on someone's shelf!
  • Share it. As I mentioned above, sharing the built-in Administrator account is a really bad idea. You may think you never need to be worried about accountability, to which I have one thing to say: neither did any of the colleagues who ended up in court being unable to explain why they had failed to provide accountability for user action.

Comments

  • Anonymous
    January 01, 2003
    PingBack from http://www.hilpers.com/970813-domaenen-adminkonto-umbenennen

  • Anonymous
    January 01, 2003
    I was surfing around and stumbled into Chris Henley's blog.  In his post at http://blogs.technet.com/chenley/archive/2006/07/13/441642.aspx,...

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    September 19, 2005
    We try to follow guidelines for security as best as possible. Users are only users, local admin accounts are renamed via GPO, password is not known and secure, and user passwords must be 15 or more characters. One thing I'm always not sure about though, is whether advice such as provided in this post applies to local machine accounts, or the domain administrator account. Are there not more than a few issues disabling the domain admin account?

  • Anonymous
    September 20, 2005
    In general, this post applies to the RID 500 account both on domains and locally. There are typically even fewer reasons to use the built-in Administrator account on a domain as you would normally have multiple administrators. That said, I have seen multiple applications that for one reason or another use that account. It is virtually always a bad idea to do so, but it is not uncommon. I am chasing down one of those issues right now.

    A couple of questions or points about what you wrote though: renaming the admin account provides nearly no security value at all. It will fool only really unsophisticated attackers. About the best thing it does is give you some hint that you are up against someone who knows something, or just knows how to run the right tools, if you see hits against the renamed admin account.

    How did you keep your users from performing a ritual sacrifice on you when required them to use 15-character passwords? :-)

  • Anonymous
    September 20, 2005
    Now I get the idea of renaming the account as good as useless, but what if you rename and then create an account called administrator as a guest equivilent. Now with a logon script that puts "Attn: KnobJockey got in, look carefully at all configs and actually useful accounts" piped to an SMTP sender so you get notified. Could be fun at least.

  • Anonymous
    September 20, 2005
    The comment has been removed

  • Anonymous
    September 20, 2005
    The comment has been removed

  • Anonymous
    September 21, 2005
    Disabling the Administrator account will work great, until you need to use the Recovery Console to repair a system. Imagine the Exchange, or SBS in a small business, server and you not having access.

    I may be on a wrong track but this issue popped into my mind as soon as I read you post.

    Nice thought, but I have reservations.

    bill

  • Anonymous
    September 21, 2005
    I agree with what you're saying, but this is an example of a situation where I get conflicting advice - the MBSA tool always flags up a warning whenever I have multiple administrators on a machine.

  • Anonymous
    September 21, 2005
    The company I work for recently covered this problem when redoing our standard operating environment. We ended up settling for a system that, although kinda complicated and relied on custom-written code, does seem to work pretty well.
    The administrator account is renamed. Yes, it doesn't do anything, but it's been common practice around here for years. Each machine has a service running on it, which sets the local admin account password to a random 12 character string each time the system's booted. The service also opens up a socket on a TCP port defined by group policy bound solely to the localhost interface.
    To retrieve the password for that machine, one simply telnets to the port concerned. The password is then echoed to the screen.
    Once this is retrieved, the credentials can then be used to log on, or - via RunAs - disable the service.
    Our problem was that we have many little sites spread over three continents, many of them with no IT person handy. We needed a way that we could manage the local administrator account, keeping the password secure, but still allowing our helpdesk ability to talk users through doing things to their own machine. It might not be ideal, and a lot of the security relies on obscurity, but the number of unauthorised people using the local admin account has fallen dramatically.

  • Anonymous
    September 21, 2005
    Just a FYI... when we went to apply SBS 2003 sp1... you HAD to be the 500 admin in order to install the service pack for SBS. You couldn't be a 'pretend' one.

    http://www.smallbizserver.net/Default.aspx?tabid=236

    ..yeah we gotta talk to dev about that one....

  • Anonymous
    September 22, 2005
    This is really awesome feedback! Susan, you did file a bug on that one right? I honestly do not recall being RID 500 when I did it though. SBS is an interesting special case as usual.

    The recovery console is another interesting one. I knew about that but I typically find that flatten and rebuild is easier and faster if things get so bad you need the recovery console. If you don't have good backups that might be a problem though.

    Dan, your approach is really interesting. I am a bit concerned about how solid the binding to localhost is though. Since it means anyone with physical access can log on to the administrator account, why would not a blank password be as good or better in that case?

  • Anonymous
    September 22, 2005
    First we educated them about how easy it was to think of a short sentence, and requested that they start doing so. After two months we enforced the policy. The only people that now grumble are new employees, and even then only for a few days. It really is easier!!

  • Anonymous
    September 24, 2005
    I have to post a correction. I was wrong. It turns out that you can use the recovery console even if the Administrator account is disabled. It appears to contain the same by-pass code that is in safe mode to allow you to use the account even if it is disabled.

  • Anonymous
    September 24, 2005
    You're welcome, Jesper. :)