Why did I rename my Administrator account?

The question of whether you should rename the built-in administrator account in Active Directory surprisingly resurfaced. I recently had chats about it with customer's security teams and it is a subject that is also coming back internally at Microsoft. It has always been a battle royale with the arguments that "obscurity is not security" on one side and "ROI of implementation wins" on the other. In a nutshell, even if you rename the account, the objectSid of the account remains the same (so easily identifiable) but at the same time, renaming it is virtually free, so why not doing it and slowing down script kiddies.

So here is my take on it: I would do it. And this is in part why:

• Network access validation algorithms and examples for Windows Server 2003, Windows XP, and Windows 2000 https://support.microsoft.com/kb/103390

Yes, an old school KB article.

Some bits before we start...

They might seem unrelated, but you'll see that everything connects at the end like in a Tarantino movie.

1. The built-in Administrator of the domain is applying the account policy you defined in your domain but does not get locked out once the badPwdcount reaches the threshold of your account lockout policy. Why? Because it is your emergency account to access the environment in a situation when all the other accounts have been locked out (case of an annoying password discovery attack or malware). Well, technically it is possible to make the built-in account behave like the other and locking out, but that's too much of a tangent at this point (see here if you are curious: DOMAIN_LOCKOUT_ADMINS).
2. The built-in administrator account on Windows has the same name everywhere: Administrator. Unless you have changed it as well.
3. Although it is not a good practice, some desktop and server administrators are using the built-in Administrator to do local admin stuff on domain joined machines (if you really need to use that account, make sure you at least use LAPS).

Let's connect the dots

Remember back in the day when you had your two Windows XP in a LAN at home and you didn't want to be prompted when you were accessing a network share? Well, you had two ways to do it. You could enable anonymous access... Or you could have the same set of username/password on both machines. And looking at the latter, and following the logic described in the kb 103390, you will try to perform a network logon with the currently used account because you have an account with the same name in the remote machine. Well kinda the same thing happens in a domain environment. With a difference that if the remote machine is domain joined, this access might be forwarded to the domain controller. Let's look at some examples in action:

 

1. An operator opens a session on a server with the built-in local Administrator account. Or opens a command prompt or a PowerShell console with "runas" as a the built-in Administrator.
2. In the previous context, the operator runs a script or a console which tries to read Active Directory.
3. Each attempt will generate a failed authentication on the domain controller for the built-in domain Administrator account. Here are the events we see in the DC's security event log:

   • Event ID:      4625
     Task Category: Logon

     An account failed to log on.
     Subject:
     Security ID:  NULL SID
     Account Name:  -
     Account Domain:  -
     Logon ID:  0x0
     Logon Type:   3
     Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  administrator
     Account Domain:  VFILE01Failure Information:
     Failure Reason:  Unknown user name or bad password.
     Status:   0xC000006D
     Sub Status:  0xC000006A
     Process Information:
     Caller Process ID: 0x0
     Caller Process Name: -
     Network Information:
     Workstation Name: VFILE01
     Source Network Address: 10.10.0.8
     Source Port:  52444
     Detailed Authentication Information:
     Logon Process:  NtLmSsp
     Authentication Package: NTLM
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

   • Event ID:      4776
     Task Category: Credential Validation

     The computer attempted to validate the credentials for an account.
     Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
     Logon Account: administrator
     Source Workstation: VFILE01
     Error Code: 0xC000006A

Another scenario:

1. An operator opens a session on a server with the built-in local Administrator account. Or opens a command prompt or a PowerShell console with "runas" as a the built-in Administrator.
2. The operator tries to access a resource located on VSRV01. In that case it is using NET USE and explicitly specified the name of the account that has to be used (but not the password).
3. The server VSRV01 doesn't have an account called administrator (or it has one, but it is disabled).
4. The authentication is forwarded to the DC and an authentication attempt is performed for the built-in domain Administrator account resulting in an event 4625 being logged on VSRV01 and the following event in the DC's security logs:

   • Event ID:      4776
     Task Category: Credential Validation

     The computer attempted to validate the credentials for an account.
     Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
     Logon Account: Administrator
     Source Workstation: VFILE01
     Error Code: 0xC000006A

Those are just two examples. So you see it coming, these actions will at some point lock out the built-in domain administrator. But wait... I just said it won't lock out. True, but you will still see the event 4740 on the domain controller (and on the ePDC) although the account can still be used. Potentially quite confusing.

Soundproofing the security event logs

The problem of the behavior described above is that it will make you think your built-in domain administrator is under password discovery type of attacks when in fact, it is just some local user with the same name being used somewhere. Are you "affected" by this? Run the following PowerShell cmdLet:

 $_default_admin = Get-ADUser -Identity "$((Get-ADDomain).DomainSID.Value)-500" 
$_metadata_lockoutTime = Get-ADReplicationAttributeMetadata -Object $_default_admin -Properties lockoutTime -Server VDC01
$_metadata_lockoutTime.Version
$_metadata_lockoutTime.LastOriginatingChangeTime

This will tell you how many times the built-in domain admin has been locked out since the creation of the domain as well as the date and time of the last occurrence.
You will be surprised to see that it is often a very high number and that the last time was a few minutes ago.
So are you under attack?
Maybe. Or maybe you're just observing the behavior described here.

In case you don't have PowerShell handy (shame on you!), here is the equivalent in command line with REPADMIN:

[code]FOR /F %S IN ('dsquery * domainroot -scope base -attr objectSid ^| find /v "objectSid"') DO SET SID=%S
FOR /F "TOKENS=4,5 DELIMS= " %A IN ('repadmin /showobjmeta fsmo_pdc: "<SID=%SID%-500>" ^| find "lockoutTime"') DO ECHO %A %B

Yes I know, it is a super fancy way to call REPADMIN...

So if you rename the built-in administrator account with something different than what you use on your workstations and servers, you'll avoid that noise and the next lockout for the built-in domain administrator will maybe be worth being investigated.

But really, that's up to you :)