Local Administrator: To Rename or not to Rename

Aim

In this post I aim to examine some of the common advice you may find on the Internet regarding the best way of securing the Local Administrator account on a Windows domain joined workstation.

Introduction

I’ve seen it in advice scattered throughout the internet for more years than I care to share, that for workstations in your Active Directory domain you should rename the Local Administrator account. Alternatively, the advice may state that you should disable the admin account completely and create an inconspicuously named alternative.

The idea is that if a user can logon to a workstation (even with basic User rights), then they have access to the hash of the admin account, and if that account’s password is shared between systems then the hash can be used to attack them as well. I’m not going in to why sharing admin account passwords between computers is a bad idea here, or that you should be using something like Microsoft LAPS to randomize the password on each system (and OverLAPS to manage LAPS). But just looking at the account itself, should you be renaming or otherwise obfuscating it?

Security through Obscurity

Attempting to “hide” attack vectors from those with possibly malicious (or simply inquisitive) intent is simple bad practice. Renaming the admin account or creating an alternate account and disabling the original is going to achieve precisely nothing against a motivated individual with the slightest knowledge of the Windows operating system.

Finding a Renamed Administrator

So you’ve renamed your Local Administrator account to “localadmin” or something more obscure, that’ll keep those pesky hackers away, right? Wrong.

The BUILTIN\Administrator account always has a relative identifier (RID) of 500. So we can find out its current name with a quick bit of PowerShell:

Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$principalContext = New-Object System.DirectoryServices.AccountManagement.PrincipalContext([System.DirectoryServices.AccountManagement.ContextType]::Machine)
$userPrincipal = New-Object System.DirectoryServices.AccountManagement.UserPrincipal($principalContext)
$searcher = New-Object System.DirectoryServices.AccountManagement.PrincipalSearcher
$searcher.QueryFilter = $userPrincipal
$searcher.FindAll() | Where-Object { $_.Sid -Like "*-500" } | Select-Object SamAccountName

Any user (admin or not) can run this to quickly get the name of the local administrator account as shown here:

Finding any Local Administrators

Ok, so you’ve disabled the BUILTIN\Administrator account and created a new, even more fiendishly named account (“johnnyt”, apologies to any John T.’s out there) and added it to the Local Administrator group. Good to go, right?

Nope. Even easier than using PowerShell, the “net localgroup administrators” command is all we need to see every member of the Local Administrators group. All a user would have to do would be to compare two or more computers to find which accounts are common between them.

So you can see, obfuscating the admin account in any way is largely pointless. The only possible argument that can be made for it is in the case of an outside attacker who doesn’t have login credentials, but could attempt to brute force a known account such as “administrator”. However, this is and should be mitigated through a properly configured firewall rather than going to the trouble of modifying the admin account.

So what is best practice?

Jesper Johansson, a former Security Program Manager with Microsoft, wrote a great Security Watch article on Why You Should Disable the Administrator Account. (Update see below) If you need access to the recovery console, or have need to boot into Safe Mode, then the account is automatically re-enabled for that session, so you still have it as a fall-back if you need it.

*** Update: This is no longer the case in modern versions of Windows and Windows Server. If you want to login using a local admin account in Safe Mode, you will first need to manually re-enable the account. This can be done from the Windows Recovery Environment command prompt using the “net user administrator /active:yes” command. ***

In my past life working on a busy Service Desk, I myself came across many other instances when having a local admin account has come in useful. Having the ability to remotely re-join a workstation to the domain when it has lost its trust for instance is useful and helps keep those ticket resolution times down. But at the same time, that breaks all kinds of best practice guidelines, and sometimes having to make a physical visit is better than making your systems vulnerable to attack.

Conclusion

Taking all this into account, it seems fairly clear that you should:

1. Disable, but don’t rename, the BUILTIN\Administrator account on all devices
2. Install Microsoft LAPS (Local Administrator Password Solution) on your domain and let it regularly randomize the local admin password on each device. Even if they’re disabled, the hashes could exist and they could still be vulnerable. So make sure no two passwords are the same.
3. Grab a copy of OVERLAPS so that when your Service Desk staff need the password for some reason (safe mode/recovery console for example), then they can get it quickly and easily, and force it to reset again afterwards if needed.

Contact

Got any suggestions or comments? Tweet us @Int64Software or email support@int64software.com.