Disable that Pesky Built-in Administrator Account!

re: Disable that Pesky Built-in Administrator Account!

JP — Tue, 20 Sep 2005 04:14:21 GMT

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?

re: Disable that Pesky Built-in Administrator Account!

jesper — Tue, 20 Sep 2005 09:18:37 GMT

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? :-)

re: Disable that Pesky Built-in Administrator Account!

David Mackie — Tue, 20 Sep 2005 14:01:24 GMT

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.

re: Disable that Pesky Built-in Administrator Account!

Alun Jones — Tue, 20 Sep 2005 18:08:56 GMT

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.]

re: Disable that Pesky Built-in Administrator Account!

jesper — Wed, 21 Sep 2005 01:48:12 GMT

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?

re: Disable that Pesky Built-in Administrator Account!

Bill Faulkner — Wed, 21 Sep 2005 19:29:36 GMT

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

re: Disable that Pesky Built-in Administrator Account!

John C. Kirk — Wed, 21 Sep 2005 19:39:30 GMT

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.

re: Disable that Pesky Built-in Administrator Account!

Dan Halford — Thu, 22 Sep 2005 00:00:50 GMT

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.

re: Disable that Pesky Built-in Administrator Account!

Susan — Thu, 22 Sep 2005 03:48:21 GMT

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

re: Disable that Pesky Built-in Administrator Account!

jesper — Thu, 22 Sep 2005 23:58:49 GMT

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?

re: Disable that Pesky Built-in Administrator Account!

JP — Fri, 23 Sep 2005 03:46:23 GMT

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!!

re: Disable that Pesky Built-in Administrator Account!

jesper — Sun, 25 Sep 2005 03:23:48 GMT

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.

re: Disable that Pesky Built-in Administrator Account!

Byron Hynes — Sun, 25 Sep 2005 06:37:45 GMT

You're welcome, Jesper. :)

Say What? Disable the local admin account?

Keith Combs' Blahg — Fri, 14 Jul 2006 09:33:00 GMT

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,...

Remotely managing your Server Core using RDP

The things that are better left unspoken — Thu, 24 Jan 2008 10:08:31 GMT

Not all system administrators feel comfortable on the command line and most system administrators don't

Dom?nen Adminkonto umbenennen | hilpers

Dom?nen Adminkonto umbenennen | hilpers — Tue, 20 Jan 2009 18:11:23 GMT

PingBack from http://www.hilpers.com/970813-domaenen-adminkonto-umbenennen