Watch Demo×
×

See NinjaOne in action!

By submitting this form, I accept NinjaOne's privacy policy.

How to Change an Administrator Name on Windows Using PowerShell

In the dynamic world of IT, maintaining and managing system security is paramount. A significant aspect of this is ensuring that critical system accounts, such as the Administrator account on Windows machines, are less predictable. One primary way to bolster this account’s security is by renaming it. This not only reduces the surface for brute-force attacks but also makes it harder for malicious entities to guess standard usernames. Learn more about this PowerShell Script that enables you to change an administrator name on windows

Background

For years, IT professionals and Managed Service Providers (MSPs) have known the vulnerabilities associated with keeping default names for critical accounts. A default “Administrator” account, especially on Windows systems, is like an open invitation to hackers. Thankfully, the PowerShell script shared above facilitates the renaming of this account, enhancing the security postures of individual and enterprise systems alike.

The Script

#Requires -Version 2.0

<#
.SYNOPSIS
    Renames the Local Administrator Account.
.DESCRIPTION
    Renames the Local Administrator Account.
.EXAMPLE
     -NewName "NewAdminName"
    Renames the local Administrator account to NewAdminName.
.EXAMPLE
     -NewName "Administrator" -CurrentName "OldAdminName"
    Renames the local Administrator account back to its original name.
.EXAMPLE
    PS C:> .Rename-LocalAdministratorAccount.ps1 -NewName "NewAdminName"
    Renames the local Administrator account to NewAdminName.
.OUTPUTS
    String[]
.NOTES
    Minimum OS Architecture Supported: Windows 7, Windows Server 2012
    Release Notes:
    Initial Release
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
.COMPONENT
    LocalBuiltInAccountManagement
#>

[CmdletBinding()]
param (
    [Parameter(Mandatory = $true)]
    [String]
    $NewName,
    [Parameter(Mandatory = $false)]
    [String]
    $CurrentName = "Administrator"
)

begin {
    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)
        if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
        { Write-Output $true }
        else
        { Write-Output $false }
    }
}

process {
    if (-not (Test-IsElevated)) {
        Write-Error -Message "Access Denied. Please run with Administrator privileges."
        exit 1
    }
    $Failed = $false
    if ((Get-Command -Name "Rename-LocalUser").Count -gt 0) {
        try {
            Rename-LocalUser -Name "$CurrentName" -NewName "$NewName" -Confirm:$false
        }
        catch {
            $Failed = $true
        }
        
    }
    else {
        # Unable to find Rename-LocalUser, falling back to using WMIC.exe
        WMIC.exe useraccount where name="$CurrentName" rename "$NewName"
        $ExitCode = $LASTEXITCODE
        if ($ExitCode -ne 0) {
            # Some kind of error occurred, likely account was already renamed.
            $Failed = $true
        }
    }

    if ($Failed) {
        Write-Error "Failed to Rename $CurrentName to $NewName"
        exit 1
    }
    else {
        Write-Host "Renamed $CurrentName to $NewName"
        exit 0
    }
}

end {}

 

Access 300+ scripts in the NinjaOne Dojo

Get Access

Detailed Breakdown

  • CmdletBinding & Parameters: The script begins by defining mandatory and optional parameters. $NewName (the desired name for the administrator account) is mandatory, while $CurrentName (the current name of the administrator account) is optional and defaults to “Administrator”.
  • Begin Block: Within this block, a function, Test-IsElevated, is defined. This function checks if the script is running with elevated (Administrator) privileges, a necessary condition for renaming the Administrator account.
  • Process Block: The script first checks if it’s running with the necessary elevated privileges. It then checks for the Rename-LocalUser command, a built-in PowerShell cmdlet for renaming local users. If found, the script renames the account using this cmdlet. If not, it defaults to the older method using WMIC.exe. The result of the renaming process is checked, and success or failure messages are displayed accordingly.
  • End Block: This block is empty in the current script but can be populated with final cleanup or reporting tasks if needed.

Potential Use Cases

Imagine an IT professional, Lisa, working in a mid-sized company. As part of a quarterly security audit, she identifies that many systems in the organization still have their Administrator accounts with default names. Using this script, Lisa can swiftly rename these accounts across multiple machines, thereby reducing potential vulnerabilities.

Comparisons

There are other methods of renaming the Administrator account. One common approach is using Group Policy Objects (GPO) in a domain setting. Another is manually renaming via Computer Management. However, the provided PowerShell script offers automation, speed, and consistency, especially beneficial for large networks or frequent changes.

FAQs

  • Is running with elevated privileges mandatory?
    Yes. Administrator privileges are necessary to rename the Administrator account.
  • Does this script work on older Windows versions?
    The script supports Windows 7 and above, including Windows Server 2012.
  • Can I revert to the default name using the script?
    Yes. By specifying the -NewName and -CurrentName parameters, you can rename the account back to “Administrator”.

Implications

Renaming the Administrator account is a proactive step in IT security. However, IT personnel must also remember the new names or have a systematic naming convention to avoid account lockouts or access issues. Furthermore, any scripts or tasks that rely on the default name might need adjustments.

Recommendations

  • Always take a backup of essential system settings before making changes.
  • Use meaningful, but non-obvious names for the Administrator account.
  • Ensure all relevant personnel are informed of the change to avoid disruptions.

Final Thoughts

For IT professionals looking to integrate this process into a broader IT management framework, NinjaOne offers a comprehensive suite of tools to enhance and streamline system administration. By leveraging solutions like NinjaOne, renaming Administrator accounts can be just one part of a holistic approach to IT security and management.

Next Steps

Building an efficient and effective IT team requires a centralized solution that acts as your core service deliver tool. NinjaOne enables IT teams to monitor, manage, secure, and support all their devices, wherever they are, without the need for complex on-premises infrastructure.

Learn more about NinjaOne Remote Script Deployment, check out a live tour, or start your free trial of the NinjaOne platform.

Categories:

You might also like

NinjaOne Terms & Conditions

By clicking the “I Accept” button below, you indicate your acceptance of the following legal terms as well as our Terms of Use:

  • Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms.
  • Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party.
  • Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library belonging to or under the control of any other software provider.
  • Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations.
  • Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks.
  • Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script.
  • EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).