I'm working on an FAQ for passwords right now. Look for it in the Security Newsletter next month (http://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.
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?
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? :-)
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.
Just a couple of points:<p>1. Note that assigning a blank password to administrator is only secure so long as the Local Security Policy setting remains in force to restrict blank password logons to the console only. I'm all for disabling the account, and setting it with a long, random, password. While there's nothing to be done to protect against the ruthless evil administrator, it's worth putting a couple of barriers up, which may be enough to protect against the lazy evil administrator :-)<p>2. To David Mackie: creating a honeypot is not necessarily a great idea. After all, what are you going to do with the information you've garnered? And with what time? It's probably more worth your while to do a quick round-up of some of the more likely paths of entry, and make sure everything's up-to-date and secure. When's the last time you checked, for instance, that every machine you administer is running the latest set of patches? Jesper's heard me say it a dozen times or so - "Is this the most important thing you can do to secure your system? Is it in the top ten? Top twenty? Hundred?" Don't waste your time playing games with criminals, just lock them out. Above all, don't go attacking back. You don't have that right, and the source of the attack may not be what it appears to be. [Example: I tried to log on to someone else's machine as Administrator the other day. All because I'd been assigned a different IP address, and the DNS registration hadn't propagated out.]
David, creating a dummy admin account is pretty common as a honey-pot technique. However, I question whether putting in an account (or a system) that you <i>want</i> people to break into. Alun has some good points about those types of systems that I totally agree with.
Alun, you are obviously right that unless the policy to restrict blank passwords to local logons is still turned on (it is on by default) blank passwords are relatively suboptimal. I just figured nobody would turn off that feature.
We're not really trying to protect against rogue administrators here. We are trying to make it more obvious and auditable when they chose to allow us to audit what they do. Maybe we are just splitting hairs though and the better option is to just give up and go tend bar at some beach resort in the Bahamas?
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.
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.
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.
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.
..yeah we gotta talk to dev about that one....
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?
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!!
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.
You're welcome, Jesper. :)
I was surfing around and stumbled into Chris Henley's blog.&nbsp; In his post at http://blogs.technet.com/chenley/archive/2006/07/13/441642.aspx,...
Not all system administrators feel comfortable on the command line and most system administrators don't