Author: Souhaiel MORHAG | Category: Microsoft Intune, Endpoint Security, Proactive Remediations
If your organization has historically managed local administrator access by manually adding individual users directly on devices, you’re not alone. However, this common practice introduces significant security and operational risks. In this post, we’ll walk through a real change i implemented to move from this manual model to a secure, group-based approach using Microsoft Intune’s Account Protection policies and Proactive Remediations.
The Problem: The Perils of Manual Admin Assignment
Manually adding users (e.g., companyDomain\admin1) to the local Administrators group might seem straightforward, but it creates several critical issues:
- Lack of Accountability & Auditability: It’s nearly impossible to track who was added where and when. There’s no central source of truth.
- Orphaned Accounts: When an administrator leaves the company and their account is disabled or deleted in Entra ID, their local admin membership often remains. These « ghost » accounts clutter the user list on devices and represent a potential security gap.
- Visibility to Attackers: A compromised laptop can reveal the list of local admin accounts. If these are named after real individuals (e.g.,
CompanyDomain\admin1), it gives an attacker valuable intelligence for lateral movement and privilege escalation. - Operational Overhead: Manually adding or removing users across a fleet of devices is time-consuming and error-prone.
The Solution: A Two-Pronged Approach
To solve this, i implemented a strategy with two key components:
- The New Standard: An Intune Endpoint Security > Account Protection policy that defines the local administrators group membership based on an Entra ID security group.
- The Cleanup Crew: A Proactive Remediation script package that seeks out and removes the legacy manual admin assignments, enforcing the new group-based standard.
Part 1: Configuring the Group-Based Policy in Intune
The future state is managed from the Intune admin center. By navigating to Endpoint security > Account Protection, you can create a policy that targets the local « Administrators » group and populates it solely with a designated security group.
As shown in the screenshot above, the policy is configured to:
- Action:
Update - Group name:
Administrators(orAdministrateursfor French OS) - Members: A single, well-managed Entra ID security group (e.g.,
SG-Intune-Local-Admins).
This ensures that only current members of that security group have local admin rights. Adding or removing someone is now a simple change in Entra ID, which Intune automatically enforces.
Part 2: The Proactive Remediation Script Package
The new policy sets the standard going forward, but what about the manual users already on the devices? This is where Proactive Remediations shine.
I created a two-script package:
A. Detection Script
This script runs first and checks for compliance. It looks for the presence of any usernames from a predefined list of legacy admin accounts within the local « Administrators » or « Administrateurs » group.
- Exit code 0: Compliant. None of the legacy users were found.
- Exit code 1: Non-compliant. One or more legacy users were detected, triggering the remediation script.
# Detection Script for unwanted users in Administrators group
# Author Souhaiel MORHAG
# 28/4/2025
# E.(><)
# List of users to detect
$usernamesToCheck = @(
"DomainCompany\admin1",
"DomainCompany\admin2",
"DomainCompany\admin3",
"DomainCompany\admin4",
"DomainCompany\admin5.etc"
)
# Detect group name
$groupName = if (Get-LocalGroup -Name "Administrateurs" -ErrorAction SilentlyContinue) {
"Administrateurs"
} elseif (Get-LocalGroup -Name "Administrators" -ErrorAction SilentlyContinue) {
"Administrators"
} else {
Write-Error "Neither 'Administrateurs' nor 'Administrators' group found!"
exit 1
}
# Initialize an empty list
$groupMembers = @()
# Safely retrieve valid members only
try {
$members = Get-LocalGroupMember -Group $groupName -ErrorAction SilentlyContinue
foreach ($member in $members) {
try {
# Try to access the Name property to ensure it's a valid member
$null = $member.Name
$groupMembers += $member.Name
} catch {
# Skip invalid SIDs or broken accounts
Write-Verbose "⚠️ Skipping invalid member: $($_.Exception.Message)"
}
}
} catch {
Write-Warning "⚠️ Failed to retrieve group members."
exit 1
}
# Check if any unwanted user is still a member
foreach ($username in $usernamesToCheck) {
if ($groupMembers -contains $username) {
Write-Warning "❌ $username is still a member of $groupName."
exit 1 # Non-compliant
}
}
Write-Output "✅ No unwanted users found in $groupName. Device is compliant."
exit 0
B. Remediation Script
This script is triggered automatically when the detection script finds non-compliance. It actively attempts to remove each legacy user from the local admin group. After removal, it performs a final check to confirm the users are gone.
Key Benefit of This Approach: The scripts are designed to be idempotent and safe. If a user is already removed or doesn’t exist, they are simply skipped. The focus is exclusively on removing the legacy accounts, leaving the new security group membership intact.
# Remediation Script for unwanted users in Administrators/Administrateurs group
# Author Souhaiel MORHAG
# 28/4/2025
# E.(><)
# List of users to remove
$usernamesToRemove = @(
"DomainCompany\admin1",
"DomainCompany\admin2",
"DomainCompany\admin3",
"DomainCompany\admin4",
"DomainCompany\admin5.etc"
)
# Detect group name
$groupName = if (Get-LocalGroup -Name "Administrateurs" -ErrorAction SilentlyContinue) {
"Administrateurs"
} elseif (Get-LocalGroup -Name "Administrators" -ErrorAction SilentlyContinue) {
"Administrators"
} else {
Write-Error "Neither 'Administrateurs' nor 'Administrators' group found!"
exit 1
}
# Step 1: Try to remove the listed users
foreach ($username in $usernamesToRemove) {
try {
if (Get-LocalGroupMember -Group $groupName -Member $username -ErrorAction SilentlyContinue) {
Remove-LocalGroupMember -Group $groupName -Member $username -ErrorAction Stop
Write-Output "✅ Removed $username from $groupName."
} else {
Write-Output "ℹ️ $username not found in $groupName. Skipping."
}
} catch {
Write-Warning "⚠️ Could not remove $username. Error: $_"
}
}
# Step 2: After removal, check if any of the users are still in the group
# Initialize an empty list
$groupMembers = @()
# Safely retrieve valid members only
try {
$members = Get-LocalGroupMember -Group $groupName -ErrorAction SilentlyContinue
foreach ($member in $members) {
try {
# Try to access the Name property to ensure it's a valid member
$null = $member.Name
$groupMembers += $member.Name
} catch {
# Skip invalid SIDs or broken accounts
Write-Verbose "⚠️ Skipping invalid member: $($_.Exception.Message)"
}
}
} catch {
Write-Warning "⚠️ Failed to retrieve group members after removal."
exit 1
}
# Final compliance check
foreach ($username in $usernamesToRemove) {
if ($groupMembers -contains $username) {
Write-Warning "❌ $username is still a member of $groupName after remediation."
exit 1 # Non-compliant
}
}
Write-Output "✅ All unwanted users removed from $groupName. Device is compliant."
exit 0
Why This Matters: Beyond the Technical Fix
It was a crucial step in strengthening our security posture:
- Reduced Attack Surface: Eliminates outdated, unmanaged admin accounts.
- Improved Compliance: Supports audit requirements (like SOX) by providing a clear, group-based mechanism for assigning privileged access.
- Operational Efficiency: IT can now manage local admin rights instantly from a central console.
- Security Hygiene: Hides the names of administrative accounts from the local device, denying attackers easy intelligence.
Implementation Checklist
If you want to replicate this in your environment, follow this plan:
- Create your Security Group: In Entra ID, create a group (e.g.,
SG-Intune-Local-Admins) and add all valid administrators. - Deploy the Account Protection Policy: Create a new policy in Endpoint Security | Account Protection to push the group-based membership to your devices.
- Package the Scripts: Adapt the provided detection and remediation scripts with your list of legacy usernames and upload them to Intune (Devices | Scripts and remediations).
- Pilot: Deploy the remediation script package to a small pilot group first. Monitor the reports to ensure it works as intended.
- Roll Out: Once validated, deploy the remediation package to all targeted devices to cleanse them of legacy assignments.
Conclusion
Moving from manual, user-based local admin assignment to a group-based model managed by Intune is a definitive win for security and operations. By combining a forward-looking configuration policy with a proactive cleanup script, we can seamlessly transition to a more secure and manageable state without manual intervention on thousands of endpoints.
This is a perfect example of using Intune’s automation capabilities not just to configure, but to actively remediate and enforce compliance across your modern workplace.
Has your organization made this shift? What challenges did you face? Share your thoughts in the comments below!