Renaming the adminstrator account, pro's and con's

[Kyle]

i know Microsoft recommend renaming the administrator account for obvious reasons. What i want to know and clear up (no microsoft training ever)

 

A procedure to rename the account,

how it works,

pros and cons

 

 

 

please keep this basic for me please.

[ChrisH]

Well the biggest pro is that it is a different name and takes some work to find rather than just having administrator to start with which is the obvious one you have stated. I have seen a script also that renames the local administrator account and changes its description. It then recreates an administrator account with right description but puts it in a normal group.

[alan-d]

I may be wrong but I think the procedure is the same as renaming a user account. Test it first.

 

This is copied from the 2003 manual;

 

Find the user account that you want to rename in Active Directory Users And

Computers.

Right-click the user account and then select Rename. Active Directory Users And

Computers then highlights the account name for editing. Press Backspace or Delete to

erase the existing name and then press Enter to open the Rename User dialog box.

Make the necessary changes to the user’s name information and then click OK. If the

user is logged on, you’ll see a warning prompt telling you that the user should log off

and then log back on using the new account logon name.

 

The account is renamed and the SID for access permissions remains the same. You

may still need to modify other data for the user in the account properties dialog box,

including the following:

User Profile Path—As necessary change the Profile Path on the Profile tab, and

then rename the corresponding directory on disk.

Logon Script Name—If you use individual logon scripts for each user, change the

Logon Script Name on the Profile tab, and then rename the logon script on disk.

Home Folder—As necessary change the home folder path on the Profile tab, and

then rename the corresponding directory on disk.

 

Pros - system is more secure as the account is not as visible to the hacker.

Cons - You have to remember what it is

[Dos_Box]

Cons. Lot of of other stuff hangs off the admin account and will stop working the minute you re-name it and change its password.

[E1uSiV3]

also you can just use common knowledge to find the account, a scripted example from microsoft demonstrates this.

[Geoff]

Security through obscurity is no security at all.

 

http://en.wikipedia.org/wiki/Security_through_obscurity

[Michael]

I agree with Dos_Box that there are services or applications which rely on the administrator account, but in my experience, re-installing these applications after re-naming the administrator account should resolve any problems.

 

By default every Windows Server has an administrator account named "administrator". Thinking about it logically, not renaming the account means that an intruder is already 50% of the way, as now they only have to guess your password. Renaming the administrator account and enforcing strong password policies in AD will make it much more difficult to crack.

 

Believe me I've seen many Primary schools with servers setup with default administrator accounts and the password is "password". Terrible from a security point of view.

 

@E1uSiV3 - I presume this script has to be run locally on the machine? I know that physical security of servers are covered by LEA policies. Unless you have physical access to a machine, it should be near impossible to obtain the administrator username and password. I guess if intruders are really that determined they'll get in, but for most, an easier target would probably be in the intruders sights.

[NetworkGeezer]

Security through obscurity is no security at all.

 

http://en.wikipedia.org/wiki/Security_through_obscurity

 

Agreed but the more obstacles you can put in the way of crackers the better. Strength in depth so you wouldn't just stop at renaming the admin account you would also create a dummy account called 'administrsator' with minimal powers. Sure the l33t hak3r5 would see through it but it will keep the wannabes guessing

[indie]

Cons. Lot of of other stuff hangs off the admin account and will stop working the minute you re-name it and change its password.

 

As I once found out, it breaks lots of stuff. I find it's best to do it on server setup, not once it's been in production.

[Dos_Box]

Its all legacy too. If you take over an old network changing the administrator account in any way is almost guarenteed to breaks lots of things which have been set over the years.

I think the rule of thumb should be.

 

*If you didn't set up the network then don't change the administrator account*

[petectid]

Cons. Lot of of other stuff hangs off the admin account and will stop working the minute you re-name it and change its password.

 

Surely everything should run under either the Local System Account, the NT Authority\LocalService or NT Authority\NetworkService or an account which is setup to be used by a particular service like virus update package. If your server is new then would any service be using the administrator account to log on? If so you could simply change the logon details for the service.

[Geoff]

Agreed but the more obstacles you can put in the way of crackers the better.

 

Agreed, but renaming the admin account isn't an obstacle. It (was) standard practice in NT4 days so its one of the first things a hacker would test for.

 

Strength in depth so you wouldn't just stop at renaming the admin account you would also create a dummy account called 'administrsator' with minimal powers.

 

Querying AD, LDAP, RPC, or various other funs things allows you to see right through this in seconds. Plus, you need to be able to spell 'Administrator' for this technique to be effective.

 

Sure the l33t hak3r5 would see through it but it will keep the wannabes guessing

 

Shannon's maxim explains why this doesn't work quite eloquently.

 

"The enemy knows the system"

 

Also, consider the average 'l33t hak3r' is attending the school for seven years. Giving plenty of time for them to 'know the system'.

 

Personally, I follow the following best practices:

 

1. Apply software patches regularly. Security fixes ASAP.

2. Run Antispyware and Antimalware software on all hosts.

3. Use host based firewalls.

4. Use a perimeter firewall.

5. Use a network IDS.

6. Do not use any unencrypted authentication mechanisms.

7. Do not use any unauthenticated mail or proxy systems.

8. Use pyhisical security to augment any software based security.

9. Disable unnecesseary services

[sahmeepee]

We've renamed the admin account on all our servers (at install time) with no problems. I'd think all Microsoft stuff will reference the domain admins group or the Administrator's SID (the user part of the SID is always the same for the builtin administrator)

[CyberNerd]

This really is a waste of time, you'd need to disguise all the admin groups as well to be effective. Like previous post says grepping ldap will reveal all sorts of info about users and groups, its trivial and doesn't require any leetness.

[NetworkGeezer]

@Geoff: All good stuff though you could have added: 0. Use Strong Passwords

 

Do you run antispyware on your servers? Personally I never surf while logged in as domain admin or other interactive server account.

 

The point about authentication mechanisms is good but is not always possible in a hetroegnous environment where you have legacy NAS say, using NTLM.

 

The spelling lesson was below the belt but I'll let it pass. I don't want this to degenerate into handbags at dawn