PowerShell Get-LocalGroupMember & Rogue Local Admin Audit Guide

3 min. read

The Ticket: The Lazy Tech Legacy

You just took over a messy network from a previous IT provider and the onboarding process is raising some major red flags. Standard users are installing their own software, bypassing UAC prompts, and accidentally downloading malware. You strongly suspect the old provider got tired of typing in their administrative credentials for simple helpdesk tickets and just blindly dropped standard users into the local Administrators group. We need to instantly audit a machine and see exactly who has the keys to the castle.

Pre-Flight Check

• Permissions: Standard users can technically read local group memberships in most default Windows environments, but running this as an elevated Administrator guarantees full visibility.
• Tools: PowerShell.
• Impact: Zero. This is a read-only query that makes no system changes.

[!WARNING] The Risk Factor: There is zero system risk when running an audit query. The real risk here is human oversight. This script checks direct membership of the local group. If an entire Active Directory group like "Domain Users" was accidentally nested inside the local Administrators group, you might glance at the output, see a group name instead of a username, and miss the massive security hole.

The Solution: The Audit Script

Taking a look at the script provided in image_014e46.png, it is a great one-liner that formats the data perfectly. However, this specific PowerShell cmdlet has a notorious, undocumented bug that we will address in the edge cases below. For a clean machine, this is exactly what you want to run.

PowerShell

# *** 404 & More: The Rogue Local Admin Auditor ***

Get-LocalGroupMember -Group "Administrators" | 
Select-Object Name, PrincipalSource, ObjectClass | 
Format-Table -AutoSize

The "Why" (Root Cause)

Why does this happen in the first place? It always comes down to lazy troubleshooting. A legacy line of business application refuses to run without elevated privileges, or a VIP user complains loudly enough about not being able to install their own printer drivers at home. Instead of configuring a proper shim, setting up LAPS (Local Administrator Password Solution), or pushing the printer via Intune, a tech takes the path of least resistance. Over the course of a few years, a secure environment turns into the Wild West.

Under the Hood (Technical Deep Dive)

The script queries the local Security Accounts Manager (SAM) database to enumerate the group members. The extra properties we are selecting are incredibly helpful for MSPs:

• PrincipalSource: This tells you exactly where the account originated. It will say Local for a local backdoor account, ActiveDirectory for an on-premise domain environment, or AzureAD for modern Entra ID joined machines.
• ObjectClass: This clarifies if the assigned member is an individual User or an entire Group.

RMM & Automation Tips

• The Baseline Monitor: Do not just run this manually. Turn it into a custom monitoring script in your RMM. Have the script count the number of users in the Administrators group. If that number exceeds your strict baseline (for example, if the count is greater than 2, representing the built-in Admin and your dedicated RMM service account), the script should fail and generate a critical alert ticket on your service board.

Troubleshooting & Edge Cases

• Edge Case 1: The Orphaned SID Crash. This is the massive bug I mentioned earlier. If a domain user was added to the local Administrators group, and then that user was later deleted from Active Directory, Windows leaves behind an "unresolved SID" (a long string of numbers) in the local group. If Get-LocalGroupMember encounters an unresolved SID, the entire script crashes and throws a red error stating "Failed to compare two elements in the array." If this happens, abandon PowerShell and fall back to the old-school command prompt: type net localgroup administrators to bypass the crash and see the raw list.
• Edge Case 2: Localized Windows Versions. The script specifically targets the group named "Administrators". If you are dealing with a machine running a Spanish, French, or German installation of Windows, the group name will be translated and the script will fail. You can bypass this by querying the well-known SID for local admins (S-1-5-32-544) instead of the localized name.

If you want to see more guides, scripts, and technical deep dives just like this, make sure to follow us on Twitter, check out our Facebook page, and sign up for the weekly 404 & More newsletter! ✌️