Last week, attackers used compromised Microsoft Intune credentials to push a mass device wipe across Stryker's endpoints. Hundreds of managed devices were wiped in a single action — no MFA prompt, no second pair of eyes, no friction whatsoever. Just one compromised admin account and a policy that executed instantly.

This is not a novel attack vector. It is a predictable consequence of missing a control that Microsoft ships natively with Intune: Multi Admin Approval (MAA).

The Solution: MAA requires a second administrator to explicitly approve destructive actions before they execute. It takes about 5 minutes to configure. If Stryker had it enabled, the wipe would have sat in an approval queue instead of running.

What Is Intune Multi Admin Approval?

Multi Admin Approval is a built-in Intune governance control that adds a mandatory human approval step to high-impact actions. It directly breaks the single-account compromise attack pattern: even with full admin credentials, an attacker cannot execute a destructive action unilaterally.

What Actions MAA Covers

Action	Description
Device wipe	Factory resets the device, removing all data.
Device retire	Removes corporate data and unenrolls the device.
Device delete	Removes the device record from Intune.
Scripts	PowerShell and shell script deployments.
App deployments	Required app assignments pushed to devices.

Critical caveat: Don't just protect "Wipe". Attackers will use scripts or retire commands if wipe is blocked. Configure all five policy types.

How to Configure Intune MAA

Step-by-Step Guide

1. Navigate: Go to Tenant administration > Multi Admin Approval > Access policies.
2. Create Policy: Click + Create. Use a clear name like MAA - Device Wipe.
3. Select Type: Under Profile type, select Device wipe. (Repeat for other types later).
4. Add Approvers: Select a security group containing your designated approvers.
   • Best Practice: Use a dedicated group with at least two members.
5. Submit: Enter a business justification and click Submit.
6. Final Approval: A second admin must approve this new policy in the Pending approvals tab before it becomes active.

What Happens When MAA Is Active

When an admin initiates a wipe, the action is held. Approvers receive an email and must review the request (Device name, initiator, and justification) in the portal. If denied or ignored, the action is automatically cancelled.

What MAA Does Not Cover

MAA is a strong control but it does not protect everything. It currently excludes:

• Compliance policy changes
• Conditional Access modifications
• Configuration profile deletions
• Bulk operations via Graph API (potential bypass)

Pro Tip: Complement MAA with Privileged Identity Management (PIM) and Microsoft Sentinel alerts for real-time monitoring of admin policy changes.

Frequently Asked Questions

Does MAA apply to bulk actions?
Yes. If an admin initiates a wipe on multiple devices, the entire batch is held. This is exactly what would have stopped the Stryker attack.

Can I approve my own requests?
No. Self-approval is blocked by Intune logic.

Is it available on my license?
MAA requires Intune Plan 1 (M365 E3/E5, Business Premium, etc.).

Check your configuration against our checklist:

• ✅ Device Wipe, Retire, Delete policies active
• ✅ Scripts and Apps policies active
• ✅ Approver group has 2+ members

Monitoring policy assignments in Microsoft Teams can be challenging as your organization grows. To simplify this, I’m sharing a professional PowerShell script that generates a comprehensive report (both CSV and HTML) of all major Teams policies assigned to your user accounts.

Note: You must have the MicrosoftTeams and ExchangeOnlineManagement modules installed and connected before running this script.

The PowerShell Script

This script fetches all Teams users, identifies their specific policy assignments (Messaging, Meeting, App Setup, etc.), and highlights whether they are using a custom policy or the "Tenant Default".

# ReportTeamsPolicyAssignments.PS1
# Generate a report about major Teams policies assigned to user accounts
# Source: Office365itpros GitHub

$ModulesLoaded = Get-Module | Select-Object Name
If (!($ModulesLoaded -match "MicrosoftTeams")) {Write-Host "Please connect to the Microsoft Teams module and then restart the script"; break}
If (!($ModulesLoaded -match "ExchangeOnlineManagement")) {Write-Host "Please connect to the Exchange Online management module and then restart the script"; break}

[array]$Users = Get-CsOnlineUser -ResultSize 5000

# Filter the set to get Teams users
$Users = $Users | Where-Object {$_.InterpretedUserType -eq "PureOnlineTeamsOnlyUser" -or $_.InterpretedUserType -eq "PureOnlineTeamsOnlyUserFailedPublishingToAAD"} | Sort-Object DisplayName

If (!($Users)) {Write-Host "No users found - exiting"; break }

$Report = [System.Collections.Generic.List[Object]]::new()

# Process each user to fetch their policy assignments
ForEach ($User in $Users) {
    $TenantDefaultString = "Tenant Default" 
    $TeamsMeetingPolicy = $TenantDefaultString
    $TeamsMessagingPolicy = $TenantDefaultString
    $TeamsAppSetupPolicy = $TenantDefaultString
    $TeamsAppPermissionsPolicy = $TenantDefaultString
    $TeamsEncryptionPolicy = $TenantDefaultString
    $TeamsUpdatePolicy = $TenantDefaultString
    $TeamsChannelsPolicy = $TenantDefaultString
    $TeamsFeedbackPolicy = $TenantDefaultString
    $TeamsLiveEventsPolicy = $TenantDefaultString

    If ($User.TeamsMeetingPolicy) {$TeamsMeetingPolicy = $User.TeamsMeetingPolicy}
    If ($User.TeamsMessagingPolicy) {$TeamsMessagingPolicy = $User.TeamsMessagingPolicy}
    If ($User.TeamsAppSetupPolicy) {$TeamsAppSetupPolicy = $User.TeamsAppSetupPolicy}
    If ($User.TeamsAppPermissionPolicy) {$TeamsAppPermissionsPolicy = $User.TeamsAppPermissionPolicy}
    If ($User.TeamsEnhancedEncryptionPolicy) {$TeamsEncryptionPolicy = $User.TeamsEnhancedEncryptionPolicy}
    If ($User.TeamsUpdateManagementPolicy) {$TeamsUpdatePolicy = $User.TeamsUpdateManagementPolicy}
    If ($User.TeamsChannelsPolicy) {$TeamsChannelsPolicy = $User.TeamsChannelsPolicy}
    If ($User.TeamsFeedbackPolicy) {$TeamsFeedbackPolicy = $User.TeamsFeedbackPolicy}
    If ($User.TeamsMeetingBroadcastPolicy) {$TeamsLiveEventsPolicy = $User.TeamsMeetingBroadcastPolicy}

    # Output a report line
    $ReportLine = [PSCustomObject][Ordered]@{  
        User                         = $User.DisplayName
        UPN                          = $User.UserPrincipalName
        "Messaging Policy"           = $TeamsMessagingPolicy
        "Meeting Policy"             = $TeamsMeetingPolicy
        "App Setup Policy"           = $TeamsAppSetupPolicy
        "App Permissions Policy"     = $TeamsAppPermissionsPolicy
        "Enhanced Encryption Policy" = $TeamsEncryptionPolicy
        "Update Policy"              = $TeamsUpdatePolicy
        "Channels Policy"            = $TeamsChannelsPolicy
        "Feedback Policy"            = $TeamsFeedbackPolicy
        "Live Events"                = $TeamsLiveEventsPolicy
        "InterpretedUserType"        = $User.InterpretedUserType
    }

    $Report.Add($ReportLine) 
}

$CSVOutput = "c:\temp\TeamsPolicyAssignments.CSV"
$ReportFile = "c:\temp\TeamsPolicyAssignments.html"

# Create the HTML report
$OrgDisplayName = (Get-OrganizationConfig).DisplayName
$CreationDate = Get-Date -format g
$Version = "1.0"

$htmlhead="<html><style>
    BODY{font-family: Arial; font-size: 8pt;}
    H1{font-size: 22px; font-family: Verdana,Arial,Helvetica,sans-serif;}
    TABLE{border: 1px solid black; border-collapse: collapse; font-size: 8pt;}
    TH{border: 1px solid #969595; background: #dddddd; padding: 5px; color: #000000;}
    TD{border: 1px solid #969595; padding: 5px; }
    </style><body>
    <div align=center><h1>Teams Policy Assignment Report</h1>
    <h2>For the $OrgDisplayName organization</h2>
    <h3>Generated: $CreationDate</h3></div>"

$htmlbody1 = $Report | ConvertTo-Html -Fragment
$htmltail = "<p>Number of Teams users found: " + $Users.Count + "</p></body></html>"

# Generate the HTML file
$htmlreport = $htmlhead + $htmlbody1 + $htmltail
$htmlreport | Out-File $ReportFile -Encoding UTF8

Write-Host "All done! Report available at $ReportFile"
$Report | Export-CSV -NoTypeInformation $CSVOutput

Key Features of the Report

This script is particularly useful for audits because it covers:

• Messaging & Meeting Policies: Ensure users have the correct permissions for chat and calls.
• App Management: Verify which App Setup and Permission policies are active.
• Compliance: Check Enhanced Encryption and Channels policies across the tenant.

IT Pro Tip: Run this script monthly and store the HTML reports in a secure SharePoint folder to maintain a historical record of your Teams governance state.

Managing Apple devices in a Windows-centric enterprise environment has become a top priority. In this guide, we will walk through how to configure and deploy Microsoft Defender for Endpoint (MDE) on macOS using Microsoft Intune, ensuring full protection and seamless integration into your security portal.

Prerequisites: Ensure your macOS devices are already enrolled in Intune and the "Microsoft Defender for Endpoint" connector is enabled under Endpoint Security.

1. System Extensions Configuration

macOS requires explicit approval for the extensions that Defender uses to monitor the system. Without this, the app won't have the necessary permissions to scan the device.

• Create a new Configuration Profile (Settings Catalog).
• Search for System Extensions and add the following identifiers (Team ID: UBF8T346G9):
  • com.microsoft.wdav.epsext
  • com.microsoft.wdav.netext

2. Configuration via .mobileconfig Files

Many Defender settings on Mac must be uploaded via custom configuration files. These templates handle critical security permissions that cannot be toggled manually by users:

• Network Filter: Allows Defender to monitor and filter network traffic.
• Full Disk Access: Mandatory for Defender to scan system files and detect threats.
• Background Services: Ensures Defender processes run correctly at startup.

Tip: Always download the latest .mobileconfig templates from the official Microsoft GitHub repository and upload them as "Custom" profiles in Intune.

3. Microsoft AutoUpdate (MAU)

To keep Defender updated without user intervention, we need to configure the Microsoft AutoUpdate service.

By creating a custom profile and uploading the MAU XML configuration, you can define the update "channel." For most enterprise environments, setting this to Production is the standard, though you can use Preview for testing groups.

4. EDR Policy (Endpoint Detection and Response)

This is a step often missed by administrators. Even if the app is installed, the device needs an EDR policy to correctly "check-in" with the Microsoft Defender portal.

1. Go to Endpoint Security > Endpoint Detection and Response.
2. Create a policy for macOS and assign it to your target device groups.

5. App Deployment and Onboarding

The final step is installing the software and "linking" it to your specific tenant:

• App Deployment: In Intune, go to Apps > macOS and add the built-in "Microsoft Defender for Endpoint" app.
• Onboarding Package: Download the onboarding

One of the most common (and frustrating) issues for an IT Administrator is finding the Microsoft Intune inventory cluttered with employees' personal devices.

This often happens because a user, while trying to access Outlook or OneDrive from their home PC, clicks "Yes" to a system prompt without reading the implications. In this article, we’ll explore a new feature that puts an end to this accidental enrollment scenario.

Note: This feature is currently in public preview but is highly recommended for production environments to maintain a clean inventory.

The Problem: Accidental MDM Enrollment

When a user adds a work or school account to a personal Windows device, they often encounter the message: "Allow my organization to manage my device". By clicking Yes:

• The PC is registered in Microsoft Entra ID.
• The device is automatically enrolled in Intune (MDM).
• Corporate policies (e.g., mandatory BitLocker encryption) are applied to a private PC, often catching the user off guard.

This creates privacy concerns for the user and unnecessary "noise" in the corporate device inventory.

The Solution: Disable Automatic MDM Enrollment

Microsoft has introduced a specific toggle to block MDM enrollment while still allowing the account to be registered for app access (Entra Registration).

How to Enable the Feature:

1. Log in to the Microsoft Intune Admin Center.
2. Navigate to Devices > Enrollment.
3. Select Windows enrollment > Automatic Enrollment.
4. Look for the new option: "Disable MDM enrollment when adding work or school account on Windows".
5. Set the toggle to Yes and click Save.

What Changes for the User?

With this policy active, the user experience changes significantly:

• The second prompt (asking to manage the device) no longer appears.
• The device will still show as "Registered" in Entra ID (to allow for Conditional Access), but the MDM state will remain as "None".
• In the PC settings (Accounts > Access work or school), the account will appear, but without the "Info" button typical of an MDM-enrolled device.

Why You Should Enable It Now

Unless your organization explicitly supports BYOD (Bring Your Own Device) scenarios with full Intune management, there is no reason to let users enroll their private PCs.

Key Benefits:

• Clean Inventory: Keep Intune focused on corporate-owned assets.
• Fewer Help Desk Tickets: Prevent users from getting locked out by policies on personal hardware.
• Security: Maintain the benefits of Entra Registration for identity-based security.

This is a handy simple script to change DNS (test it before run in live environments;)) :



@echo off

:: Google DNS
set DNS1=8.8.8.8
set DNS2=8.8.4.4

for /f "tokens=1,2,3*" %%i in ('netsh int show interface') do (
    if %%i equ Enabled (
        echo Changing "%%l" : %DNS1% + %DNS2%
        netsh int ipv4 set dns name="%%l" static %DNS1% primary validate=no
        netsh int ipv4 add dns name="%%l" %DNS2% index=2 validate=no
    )
)

ipconfig /flushdns

:EOF

Simple and handy .vbs script to open a webpage into a specific browser (in this case tested with the latest and greatest Microsoft Edge 😀) 




Set WshShell = WScript.CreateObject("WScript.Shell")
Return = WshShell.Run("msedge.exe https://sccmrookie.blogspot.com/", 1)

In large organizations, multiple IT teams often work on different projects requiring specific levels of access. Providing Global Administrator or Intune Service Administrator rights to everyone is a significant security risk and unnecessary.

Microsoft Intune provides Role-Based Access Control (RBAC), allowing us to create custom roles with granular permissions. In this tutorial, we will create a custom Intune role specifically for the Help Desk, enabling them to Wipe and Sync devices without granting full administrative control.

Step 1: Accessing Intune Roles

1. Login to the Microsoft Endpoint Manager admin center at endpoint.microsoft.com.

2. Navigate to Tenant administration > Roles.

Step 2: Create a New Custom Role

1. Select All roles and click on + Create.

2. On the Basics page, enter a Name (e.g., Help Desk - Wipe and Sync) and an optional description.

Step 3: Configure Permissions

Now, select the specific permissions for this role. For this scenario, we will assign:

• Remote tasks: Wipe
• Remote tasks: Sync devices

Click Next. You can assign Scope Tags if your organization uses them to filter objects.

Step 4: Role Assignment

Creating the role is only half the work. Now you must assign it to the IT Staff group:

1. Select the newly created role and click on Assignments > + Assign.

2. Enter an assignment name and select the Admin Group (the group containing your Help Desk members).

3. Select the Scope Group: You can select a specific group of devices they can manage, or select "All Users/All Devices" to provide rights across the entire tenant.

Success! Review the settings and click Create. Your Help Desk team now has a dedicated custom role to manage basic device tasks securely.