locked
Rename Administrator account RRS feed

  • General discussion

  • As a Windows Server admin at work, I know it's a best practice to rename the Administrator account to something other than 'administrator'. I went in (via RDP) last night and renamed my admin account. While most things still work, I can't use the connector software on my desktop anymore. Not major to me, as I prefer to RDP and then open the connector home app on the server, but it would be nice if there was a way to rename the account and still be able to have full functionality... Maybe it could ask for the admin user account name during install?
    Sunday, March 18, 2007 1:17 PM

All replies

  •  Tha Dawg wrote:
    As a Windows Server admin at work, I know it's a best practice to rename the Administrator account to something other than 'administrator'. I went in (via RDP) last night and renamed my admin account. While most things still work, I can't use the connector software on my desktop anymore. Not major to me, as I prefer to RDP and then open the connector home app on the server, but it would be nice if there was a way to rename the account and still be able to have full functionality... Maybe it could ask for the admin user account name during install?

    Thanks for sharing, I was going to do this (same reasons) now I'll wait.

    Sunday, March 18, 2007 11:19 PM
  •  Tha Dawg wrote:
    As a Windows Server admin at work, I know it's a best practice to rename the Administrator account to something other than 'administrator'. I went in (via RDP) last night and renamed my admin account. While most things still work, I can't use the connector software on my desktop anymore. Not major to me, as I prefer to RDP and then open the connector home app on the server, but it would be nice if there was a way to rename the account and still be able to have full functionality... Maybe it could ask for the admin user account name during install?

    The only problem with renaming the Administrator account is that most people think they're safe.  But by renaming the Administrator account that doesn't change the SID of the account.  The SID for the Administrator account on any Windows computer is:

    S-1-5-domain-500

    So any good hacker is going to try to find the account based on the SID, not the name.  I agree that taking any steps to make it harder for someone to compromise your system is a good thing, you should probably either disable the built-in Administrator account completely or disable "Allow Anonymous SID/Name Translation" or both.

    Wednesday, March 21, 2007 7:35 PM
  •  Tha Dawg wrote:
    As a Windows Server admin at work, I know it's a best practice to rename the Administrator account to something other than 'administrator'. I went in (via RDP) last night and renamed my admin account. While most things still work, I can't use the connector software on my desktop anymore. Not major to me, as I prefer to RDP and then open the connector home app on the server, but it would be nice if there was a way to rename the account and still be able to have full functionality... Maybe it could ask for the admin user account name during install?

    Dawg, did you try running Discovery on your desktop?  I haven't yet tried renaming the Administrator account, but I did change the WHS computer name and gave it a new static IP.  To get the client connector to find it again, I simply ran the following on each connecting desktop:

    \program files\windows home server\discovery.exe

    Picked it up fine, so you may want to try that.

     Doug Deitterick wrote:
    The only problem with renaming the Administrator account is that most people think they're safe.  But by renaming the Administrator account that doesn't change the SID of the account.  The SID for the Administrator account on any Windows computer is:

    S-1-5-domain-500

    So any good hacker is going to try to find the account based on the SID, not the name.  I agree that taking any steps to make it harder for someone to compromise your system is a good thing, you should probably either disable the built-in Administrator account completely or disable "Allow Anonymous SID/Name Translation" or both.

    If you really want to secure your default accounts, you can do the following (obviously, you don't need to do all of this, depending on your situation, but gives a good overview of concepts):

    • Rename the default "Administrator" account, give it a strong password, then disable it
    • Create a new account entitled "Administrator", give it no rights and a strong password, then disable it
    • Create a new account with a normal user name (don't use "John Doe" or a well-known person - maybe a relative or a name you just make up) and give this account administrative rights with a strong password
    • I forget how, but there is also a way to prevent enumeration of the "Administrators" group
    • Operate day to day using your own named account with limited privileges

    What this does is give a lot of false trails.  The default administrative account is a different name if attacked by name.  If by SID, it is disabled and has a strong password.  The "dummy" administrative account is also disabled and has a strong password, in addition to the fact that it has no or limited privileges if successfully cracked.  The real administrator does not have a known SID, has a strong password, and has a standard user name.

    There are a lot of other thoughts, but I have found this to be a solid way to secure a workstation over the years.  Very difficult to crack into (assuming you take other security measures as well - I hope that goes without saying).

    Anyway, just some thoughts.

     

    Friday, March 23, 2007 11:12 PM
  • You can disable SID enumeration 2 ways:

    1. Click Start, Administrative Tools, Local Security Policy (you can also enter secpol.msc at a command prompt or using Start, Run).
    2. Click on the + next to Local Policies
    3. Click on Security Options
    4. On Windows Server 2003 and Windows XP systems select Network access: Allow anonymous SID/Name translation in the details pane and make sure the policy is disabled.
    5. Click OK and close the console.

    You can also apply the policy across a domain instead of on one individual computer by following these steps:

    1. Open the Active Directory Users and Computers console screen.
    2. Right-click the domain and select Properties.
    3. Click the Group Policy tab.
    4. Click the Default Domain Policy, and select Edit.
    5. Drill down through the console pane to Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options.
    6. On a Windows Server 2003 domain, double-click Network access: Allow anonymous SID/Name translation and make sure the policy is disabled.
    7. Click OK and close the console.
    Saturday, March 24, 2007 2:49 AM
  • The only unfortunate thing is that you can't edit Security Policy on Windows XP Home and Windows Vista Home Basic/Premium...  that is, unless they are administrative policies (not including Security Options) and you know the related registry keys, which you can then edit directly.

    IMHO, Microsoft didn't think through that very well.  Seems rather strange not to allow home level users to directly customize the security on their own computers.  True, many won't understand it.  But, I have a hard time putting together the Microsoft equation "Many Don't Understood = No One Should Be Allowed".

    Saturday, March 24, 2007 5:13 AM
  •  Shaun Phurrough wrote:
    But, I have a hard time putting together the Microsoft equation "Many Don't Understood = No One Should Be Allowed".
    I'll finish the thought for you:

    ...Because it's so easy to severely impact the usability of a system when changing these policies, and so difficult to recover.

    I'm pretty sure that's why some of those policy options are unavailable on home OSes. That, and Microsoft wants to make sure that businesses (which actually want to use them regularly) will have to buy a version of the OS that's targeted at business, rather than home users.
    Saturday, March 24, 2007 12:54 PM
    Moderator
  • Oh, I already understand the reasons, I just don't agree with them.

    For 1 reason, most local GPOs these days aren't that difficult to recover from (not sure I understand your comment - the registry is far more difficult to recover from than local policy editing).  I've been administrating policies for years at home and at work and you REALLY have to make several KEY policy changes to get yourself in a serious jam.  As to general items, it is easy enough for the average user to figure out they need to reverse their previous steps.  But, then we aren't doing this for the average user are we?  It is highly likely that only the power user/enthusiast would even know how to get to GP locally.

    I used to believe your second comment was the main reason, but not so sure anymore, especially with Vista Ultimate.  Ultimate is NOT targeted at businesses, but at home enthusiasts and does include local GPO editing.  But I still disagree with their decisions.  There are plenty of other items to make money on if that is what they are concerned about (Bit-Locker for example).  Local policy editing seems a silly one to me.  Those of us who know how to use them, know the value of keeping our family members from intentionally or accidentally changing certain items by using local policies.  And they aren't hard to use at all.  Much easier than editing the registry and significantly easier to keep track of changes.  Almost always, when I teach people about them, they shift to using local policy over registry weaks.

    What Microsoft should rely on as a selling point is the ability to centrally manage policy (in other words, AD), not the ability to locally edit it.  Seems really silly to me.

    Anyway, went off topic a bit.  Sorry.

    Thanks for the comments, Ken!

    Saturday, March 24, 2007 3:05 PM