The problem? Those leftover admin rights don’t go away on their own. Over time, they quietly pile up and turn into a serious security risk, which most monitoring tools never bother to check. If you don’t know who’s in the local Administrators group, you’re basically trusting luck.

In this guide, I’ll walk you trough how to use Intune and Log Analytics to get a clear, reliable report of who actually has local admin access on every device in your environment.

Solution Overview

We use a proactive approach to ensure no local admins stay hidden:

1. Detection: A PowerShell script runs daily on every machine to query the administrators group.
2. Ingestion: Data is sent to a custom table in our Log Analytics Workspace.
3. Analysis: KQL queries filter out authorized local administrator accounts to highlight outliers.

1. The PowerShell Collection Script

This script gathers members of the local admin group and sends the data to Azure. By running this via Intune, we get a fresh snapshot of the local admins on each PC every 24 hours.

Prerequisite 1: Get the $CustomerID from the log analytics workspace Overview tab.

Prerequisite 2: To get the $SharedKey, use this AZ CLI query.

az monitor log-analytics workspace get-shared-keys \
   --resource-group xxxxx \
   --workspace-name xxxxxx \
   --query "primarySharedKey"

# --------------------------------------------------------------------------
# PowerShell Script: Send Local Administrator Group Members to Log Analytics
# --------------------------------------------------------------------------

# ======================
# 1. Configuration
# ======================
$CustomerID = "<your-customer-id>"
$SharedKey  = "<your-shared-key>"
$LogType    = "LocalAdminReport"

# ======================
# 2. Data Collection
# ======================
$DeviceName = $env:COMPUTERNAME

try {
    $AdminMembers = Get-LocalGroupMember -Group "Administrators"
} catch {
    Write-Error "Error retrieving local group members: $($_.Exception.Message)"
    exit 1
}

$DataToSend = @()
foreach ($Member in $AdminMembers) {
    $MemberName = $Member.Name
    $MemberSource = $Member.PrincipalSource
    if (-not [string]::IsNullOrEmpty($MemberName)) {
        $DataToSend += [PSCustomObject]@{
            DeviceName = $DeviceName
            AdminName  = $MemberName
            PrincipalSource = $MemberSource
            TimeGenerated = (Get-Date -Format s)
        }
    }
}

if ($DataToSend.Count -eq 0) {
    Write-Host "No members found in the Administrators group. Skipping log submission."
    exit 0
}

$JsonPayload = $DataToSend | ConvertTo-Json -Depth 5

# ======================
# 3. Build Request and Signature
# ======================
$Bytes         = [System.Text.Encoding]::UTF8.GetBytes($JsonPayload)
$ContentLength = $Bytes.Length
$APIVersion    = "2016-04-01"
$Date          = (Get-Date).ToUniversalTime().ToString("r")
$ResourcePath  = "/api/logs"

# Build the string for signature (see MS Docs)
$SignatureString = "POST`n$ContentLength`napplication/json`nx-ms-date:$Date`n$ResourcePath"

# Decode Shared Key and calculate signature
try {
    $KeyBytes   = [Convert]::FromBase64String($SharedKey)
    $HMACSHA256 = New-Object System.Security.Cryptography.HMACSHA256
    $HMACSHA256.Key = $KeyBytes
    $Hash = $HMACSHA256.ComputeHash([System.Text.Encoding]::UTF8.GetBytes($SignatureString))
    $Signature = [Convert]::ToBase64String($Hash)
} catch {
    Write-Error "Failed to create signature: $($_.Exception.Message)"
    exit 1
}

$Authorization = "SharedKey ${CustomerId}:$Signature"
$URI = "https://$CustomerID.ods.opinsights.azure.com/api/logs?api-version=$APIVersion"

# ======================
# 4. Send Data
# ======================
$Headers = @{
    "Authorization"        = $Authorization
    "x-ms-date"            = $Date
    "Content-Type"         = "application/json"
    "Log-Type"             = $LogType
    "x-ms-log-type"        = $LogType
    "time-generated-field" = "TimeGenerated"
}

try {
    Write-Host "Sending data to Log Analytics ($LogType)..."
    Write-Host "Target URI: $URI"
    $Response = Invoke-RestMethod -Uri $URI -Method Post -Headers $Headers -Body $JsonPayload
    Write-Host "Successfully sent log data."
} catch {
    Write-Error "Failed to send log data. Error: $($_.Exception.Message)"
    if ($_.Exception.Response) {
        try {
            $Reader = New-Object System.IO.StreamReader($_.Exception.Response.GetResponseStream())
            $Details = $Reader.ReadToEnd()
            Write-Error "Azure Response: $Details"
        } catch { }
    }
    exit 1
}

exit 0

2. Running the Script Daily via Intune

To force the check daily, we deploy an Intune remediation script.

1. Go to https://intune.microsoft.com.
2. Navigate to Devices > Scripts and remediations > Create.
3. Enter the above script as the Detection Script and leave the Remediation Script empty.

3. Analyzing the Local Administrator Report

Once the data is in our log analytics workspace, we use Kusto (KQL) to audit the results. The goal is to separate legitimate domain accounts from unauthorized user accounts that still have the local admin right.

Compliance Summary

This query counts the number of devices where a user is in the administrators group but does not have “admin” in their name (filtering out the built-in administrator and domain admins).

let allDevices = LocalAdminReport_CL | summarize by DeviceName_s;
let offenderDevices = LocalAdminReport_CL
    | where isnotempty(AdminName_s)
    | where AdminName_s !contains "Admin"
    | summarize by DeviceName_s;
let totalOffenders = offenderDevices 
    | summarize Count = count() 
    | extend Category = "Devices with Local Admin Access";
let compliantDevices = (allDevices
    | join kind=leftanti offenderDevices on DeviceName_s
    | summarize Count = count()
    | extend Category = "Compliant Devices"
);
totalOffenders
| union compliantDevices
| project Category, Count
| order by Category asc

Detailed Account Audit

Use this query to select and list every specific account that has been granted local admin permissions in the last 90 days across your computer fleet.

LocalAdminReport_CL
| where TimeGenerated > ago(90d)
| where isnotempty(AdminName_s)
| where AdminName_s !contains "Admin"
| summarize LatestSeen = max(TimeGenerated) by DeviceName_s, AdminName_s
| order by DeviceName_s asc

Implementation Tips

• Intune Deployment: Set the script to run daily using Devices > Remediations. This ensures that if a user is added and then removed, your logs stay accurate.
• Filtering: Adjust the !contains "Admin" logic if your organization uses a different naming standard for authorized admin accounts.
• Workbook Visuals: In Azure Workbooks, use the “Pie Chart” renderer for the first query to get an immediate view of your environment’s health.

Summary

Good security isn’t about saying “no” to everything. It’s about knowing what’s actually happening in your environment. With this script and report in place, you get a clear audit trail that shows exactly when someone is added as a local administrator. That way, “temporary” access doesn’t quietly turn into a permanent problem, and you stay in control instead of playing cleanup later.

The post Local Admin Report with Intune and Log Analytics appeared first on Cyberillo.

A Windows device is joined to the domain and synchronized to Azure AD (Microsoft Entra). The Registered column for the device in Azure AD shows Pending and the MDM column shows None.

The device does not show up in Intune since it was not successfully enrolled.

Running dsregcmd /status in CMD shows:

AzureAdJoined : YES [under Device State]

DomainJoined : YES [under Device State]

AzureAdPrt : No [under SSO State]

The problem here is that AzureAdPrt (Primary Refresh Token) is showing No. In a nutshell, this means that the device did not manage to authenticate successfully to Azure. Therefore, Intune auto-enrollment will fail.

You can confirm that device enrollment failed by checking for an error of the sort: “Auto MDM Enroll Device Credential 0x0, Failed” in the Event Viewer at the following location:

Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin

Resolution

1. Make sure that you have checked all the prerequisites for Intune Auto Enrollment.
2. In CMD (on the target device) run the following command:

%windir%/System32/deviceenroller.exe /autoenrollmdm

In some cases, this one-liner does its magic and triggers a successful enrollment to Intune. If the device shows up in Intune after a while (5 to 15 minutes), the issue is resolved. If not, move on to the next steps to completely remove the device from your on-premises AD and Azure AD (Entra), re-join, and successfully enroll to Intune.

3. In CMD (on the target device) run the following command to unregister from Azure AD.

dsregcmd /leave

4. Delete the device object from Azure AD.

5. Disjoin the device from the on-premises Active Directory domain.
6. Delete the device computer object from Active Directory.

7. Re-join the device to the domain and wait for the next synchronization cycle to Azure AD or force it through PowerShell on your AD Connect Server:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

8. The device will show up in Azure AD.
9. Logon to the device with the target user’s credentials.

After a while (5 to 15 minutes), the device will successfully enroll to Intune via auto-enrollment.

Running dsregcmd /status in CMD now shows:

AzureAdJoined : YES [under Device State]

DomainJoined : YES [under Device State]

AzureAdPrt : YES [under SSO State]

The post Hybrid Azure AD Joined Device Fails Intune Auto Enrollment appeared first on Cyberillo.