Zero-Touch-Laptop-Offboarding mit Microsoft Intune

Überblick

Mitarbeiter-Offboarding ist sowohl ein Identity-Ereignis als auch ein Endpoint-Kontrollproblem. Die Deaktivierung eines Kontos löscht keine bereits auf einem Laptop gespeicherten Daten, und das Senden einer Intune-Aktion beweist nicht, dass ein Offline-Gerät sie empfangen oder abgeschlossen hat. Ein belastbares Design koordiniert beide Kontrollebenen und dokumentiert den Zustand jeder einzelnen.

Eine praktische Microsoft-Architektur beginnt mit einem maßgeblichen HR-Austrittsereignis, nutzt Microsoft Entra Lifecycle Workflows für unterstützte Identity-Aufgaben, ruft über eine Custom Task Extension eine Azure Logic App zur Geräteorchestrierung auf und startet die passende Intune-Remoteaktion über Microsoft Graph. Das Design sollte Zugriffe sicher schließen, bei der Geräteauswahl sicher anhalten und eine Ausnahme offenhalten, bis das Endpoint-Ergebnis verifiziert ist.

Was die Architektur richtig abbilden muss

• Identity-Containment bedeutet keine sofortige Vernichtung aller Tokens. Deaktivieren Sie zuerst das Konto und widerrufen Sie Refresh- und Browser-Session-Tokens. Bestehende Access Tokens können nutzbar bleiben, bis der jeweilige Dienst sie neu bewertet oder sie ablaufen; Continuous Access Evaluation verkürzt dieses Fenster nur für unterstützte Anwendungen und Bedingungen.
• Lifecycle Workflows führen nicht jede Intune-Aktion nativ aus. Nutzen Sie integrierte Leaver-Aufgaben für unterstützte Identity-Operationen. Rufen Sie für Gerätesuche, Genehmigungslogik und Intune-Aktionen über eine Lifecycle-Workflows-Custom-Task-Extension eine Azure Logic App oder einen anderen kontrollierten Orchestrierungsdienst auf.
• Eine erfolgreiche Graph-Antwort belegt keinen Abschluss am Endpoint. Die Remoteaktion kann angenommen werden, während der Laptop ausgeschaltet oder getrennt ist. Verfolgen Sie Annahme, ausstehende Übermittlung, Geräte-Check-in, Aktionsstatus und das verifizierte Client-Ergebnis als getrennte Ereignisse.
• Remote Wipe ist kein universelles Zertifikat für kryptografische Löschung. Intune Wipe entfernt Daten und Einstellungen durch Zurücksetzen des Geräts, doch das Speicherverhalten variiert nach Plattform und Konfiguration. Halten Sie für Entsorgung, Legal Hold, beschädigte Hardware und Anforderungen mit verifizierter Vernichtung einen separaten Standard zur Datenträgersanitisierung vor.
• Compliance-Richtlinien sind keine Offline-Wipe-Engine. Intune kann ein veraltetes oder unsicheres Gerät als non-compliant markieren, und Conditional Access kann geschützte Ressourcen blockieren, sobald dieser Zustand bewertet ist. Compliance-Aktionen lassen einen vom Internet getrennten Windows-Laptop keinen Wipe ausführen; die BitLocker-Schlüsselrotation ist eine eigene Remoteaktion und keine automatische Folge einer Grace Period.

Die automatisierte Offboarding-Architektur

• 1. Ein maßgebliches Austrittsereignis empfangen. Nutzen Sie HR-gesteuerte Bereitstellung oder eine andere freigegebene Quelle für Mitarbeiter-ID, wirksamen Austrittszeitpunkt, Kündigungsklasse, Führungskraft, Legal-Hold-Status und bekannte Asset-IDs. Normalisieren Sie Zeitzonen und verarbeiten Sie wiederholte Ereignisse idempotent.
• 2. Die Identität eindämmen. Deaktivieren Sie zum wirksamen Zeitpunkt das Microsoft-Entra-Konto, widerrufen Sie Refresh- und Browser-Session-Tokens, entfernen Sie unterstützte Gruppen-, Team-, Access-Package- und direkt zugewiesene Lizenzberechtigungen gemäß Richtlinie und bewahren Sie für Legal Hold oder Manager-Übergaben erforderliche Zugriffe. Das Entfernen einer Gruppenmitgliedschaft kann den Geltungsbereich von Conditional Access ändern, löscht oder entfernt aber nicht die Richtlinien selbst.
• 3. Das richtige verwaltete Gerät auflösen. Ordnen Sie Personen- und Asset-Datensatz der Intune-managedDevice-ID zu. Wipen Sie nicht pauschal jedes einem Benutzer zugeordnete Gerät: Berücksichtigen Sie gemeinsam genutzte Geräte, mehrere zugewiesene Laptops, veraltete Datensätze, BYOD-Registrierungen, Leihgeräte und bereits an andere Verwahrer übergebene Geräte.
• 4. Eine risikobasierte Entscheidung treffen. Wählen Sie anhand von Geräteeigentum, physischem Gewahrsam, Wiederverwendungsabsicht, Legal Hold, Verschlüsselungsstatus, letztem Check-in und Kündigungsrisiko zwischen Retire, Wipe, Autopilot Reset, Quarantäne oder manueller Prüfung. Verlangen Sie eine Genehmigung bei mehrdeutiger Zuordnung und bei destruktiven Aktionen außerhalb einer vorab genehmigten Richtlinie.
• 5. Mit Least Privilege senden. Lassen Sie die Orchestrierungs-Workload Microsoft Graph mit der für die ausgewählte Aktion erforderlichen Intune-Privileged-Operations-Berechtigung aufrufen. Schützen Sie die Workload-Identität, begrenzen Sie Änderungen am Workflow, validieren Sie jede ID und speichern Sie keine weitreichenden Graph-Zugangsdaten in Skripten oder Tickets.
• 6. Verifizieren und abschließen. Korrelieren Sie HR-Ereignis, Workflow-Lauf, Identity-Aufgaben, Geräteentscheidung, Graph-Anfrage, Intune-Aktionsstatus, letzten Check-in, Client-Ergebnis und physische Asset-Rückgabe. Schließen Sie den Fall erst, wenn das erforderliche Ergebnis bestätigt ist oder ein benannter Ausnahmeverantwortlicher das Restrisiko akzeptiert.

Intune-Aktion nach gewünschtem Ergebnis auswählen

Gehärtetes PowerShell-Beispiel für den Versand

Das folgende Referenzbeispiel akzeptiert bewusst genau eine genehmigte Intune-managedDevice-ID und eine erwartete Seriennummer. Es sucht Geräte nicht per UPN und setzt nicht jedes einem ausgeschiedenen Benutzer zugeordnete Gerät zurück. Lösen und genehmigen Sie das Asset früher im Workflow, bestätigen Sie die Eignung des zurückerhaltenen Geräts für Autopilot Reset und prüfen Sie die Windows-Recovery-Environment-Bereitschaft in Ihren Deployment-Kontrollen.

Zur besseren Lesbarkeit bezieht das Beispiel ein Client Secret aus einer Prozess-Umgebungsvariable. Bevorzugen Sie in Produktion eine Managed Identity oder ein Zertifikat und injizieren Sie Secrets aus einem genehmigten Secret Store statt aus Befehlsverlauf, Quellcode, Protokollen oder Tickets. Die App benötigt DeviceManagementManagedDevices.Read.All zum Lesen des Ziels und DeviceManagementManagedDevices.PrivilegedOperations.All zum Senden der Wipe-Aktion.

• Schutzvorkehrungen für destruktive Aktionen. SupportsShouldProcess und ConfirmImpact High stellen -WhatIf und eine interaktive Bestätigung bereit. Ein unbeaufsichtigter Workflow sollte -Confirm:$false erst übergeben, nachdem seine eigenen Richtlinien- und Genehmigungskontrollen die genaue managedDevice-ID und Seriennummer ausgewählt haben.
• Aktuelle Graph-Aktion. Microsofts aktuelle Autopilot-Reset-Dokumentation verweist auf POST /deviceManagement/managedDevices/{managedDeviceId}/wipe. Das Beispiel behält Registrierungsdaten bei und entfernt Benutzerdaten; validieren Sie dieses Verhalten in einem Nichtproduktionsring mit den von Ihnen eingesetzten Windows- und Intune-Versionen.
• Versand ist nicht Abschluss. Eine erfolgreiche Anfrage erzeugt nur einen Dispatched-Datensatz. Der umgebende Workflow muss Intune-Aktionsstatus, Geräte-Check-in, Client-Abschluss und physischen Gewahrsam weiterverfolgen, bevor der Fall geschlossen wird.

<#
.SYNOPSIS
    Dispatches an approved Windows Autopilot-style reset through Microsoft Graph.
.DESCRIPTION
    Validates one Intune managed-device ID against an expected serial number,
    then calls the documented managedDevice wipe action while retaining enrollment.
.NOTES
    Required application permissions:
    DeviceManagementManagedDevices.Read.All
    DeviceManagementManagedDevices.PrivilegedOperations.All
#>

[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'High')]
param (
    [Parameter(Mandatory = $true)]
    [guid]$TenantId,

    [Parameter(Mandatory = $true)]
    [guid]$ClientId,

    [Parameter(Mandatory = $true)]
    [guid]$ManagedDeviceId,

    [Parameter(Mandatory = $true)]
    [ValidateNotNullOrEmpty()]
    [string]$ExpectedSerialNumber
)

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

$clientSecret = $env:GIDEON_GRAPH_CLIENT_SECRET
if ([string]::IsNullOrWhiteSpace($clientSecret)) {
    throw 'GIDEON_GRAPH_CLIENT_SECRET must be injected by an approved secret store.'
}

$tokenResponse = $null
$headers = $null

try {
    $tokenUri = "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token"
    $tokenBody = @{
        client_id     = $ClientId
        client_secret = $clientSecret
        scope         = 'https://graph.microsoft.com/.default'
        grant_type    = 'client_credentials'
    }

    $tokenResponse = Invoke-RestMethod -Uri $tokenUri -Method Post -Body $tokenBody
    if ([string]::IsNullOrWhiteSpace($tokenResponse.access_token)) {
        throw 'Microsoft identity platform returned no access token.'
    }

    $headers = @{
        Authorization = "Bearer $($tokenResponse.access_token)"
        'Content-Type' = 'application/json'
    }

    $deviceUri = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$($ManagedDeviceId)?`$select=id,deviceName,serialNumber,operatingSystem,lastSyncDateTime,managementAgent"
    $device = Invoke-RestMethod -Uri $deviceUri -Method Get -Headers $headers

    if ($device.operatingSystem -ne 'Windows') {
        throw "Managed device '$ManagedDeviceId' is not a Windows device."
    }

    if (-not [string]::Equals(
        $device.serialNumber,
        $ExpectedSerialNumber,
        [System.StringComparison]::OrdinalIgnoreCase
    )) {
        throw "Serial mismatch for managed device '$ManagedDeviceId'."
    }

    $operation = 'Remove user data while retaining Intune enrollment'
    $target = "$($device.deviceName) [$($device.serialNumber)]"
    if (-not $PSCmdlet.ShouldProcess($target, $operation)) {
        return [pscustomobject]@{
            Status = 'Skipped'
            ManagedDeviceId = $device.id
            DeviceName = $device.deviceName
            SerialNumber = $device.serialNumber
        }
    }

    $resetUri = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$($device.id)/wipe"
    $payload = @{
        keepEnrollmentData = $true
        keepUserData = $false
    } | ConvertTo-Json

    Invoke-RestMethod -Uri $resetUri -Method Post -Headers $headers -Body $payload

    [pscustomobject]@{
        Status = 'Dispatched'
        ManagedDeviceId = $device.id
        DeviceName = $device.deviceName
        SerialNumber = $device.serialNumber
        LastSyncDateTime = $device.lastSyncDateTime
        DispatchedAtUtc = (Get-Date).ToUniversalTime().ToString('o')
    }
}
finally {
    $clientSecret = $null
    $tokenResponse = $null
    $headers = $null
}

Offline-Laptops einplanen

Intune-Remoteaktionen setzen voraus, dass sich das Gerät mit dem Internet verbindet und eincheckt. Ein ausgeschalteter Laptop bleibt deshalb ein ausstehendes Endpoint-Risiko, selbst nachdem seine Identität deaktiviert wurde. Der Workflow sollte diesen Zustand sichtbar machen, statt das Offboarding als abgeschlossen zu melden.

Nutzen Sie Defense in Depth während der Wartezeit: Festplattenvollverschlüsselung, deaktivierten Benutzerzugriff, an aktuelle Geräte-Compliance gebundenen Conditional Access, kurze und gut kontrollierte lokale Zugangspfade, Endpoint-Detection-Kontrollen und physische Rückholprozesse. Keine dieser Kontrollen ist ein Nachweis dafür, dass eine ausstehende Remoteaktion ausgeführt wurde.

• Eskalationsschwellen festlegen. Eskalieren Sie anhand von Austrittsrisiko, Eigentum, Gewahrsam und Zeit seit dem letzten Check-in. Ein fehlender Unternehmens-Laptop nach einer unfreiwilligen Kündigung sollte nicht denselben Timer haben wie ein bestätigtes Gerät im IT-Rückgabebereich.
• Die Aktion ausstehend halten. Fragen oder abonnieren Sie den verfügbaren Intune-Aktions- und Gerätezustand, dokumentieren Sie Wiederholungen sicher und ersetzen Sie eine destruktive Aktion nicht durch einen widersprüchlichen ausstehenden Befehl.
• Physische Rückholung koordinieren. Verknüpfen Sie den Sicherheitsworkflow mit Asset Management, Versand, Manager-Bestätigung und Lost-Device-Prozessen, damit technische Eindämmung und Hardware-Gewahrsam in einem Fall zusammenlaufen.

Auditfähige Nachweise

• Trigger-Nachweis. Maßgebliche Quelle, Ereignis-ID, wirksamer Zeitpunkt, Empfangszeit, Workflow-Version und Idempotency Key.
• Identity-Nachweis. Ergebnis der Kontodeaktivierung, Ergebnis des Sitzungswiderrufs, Berechtigungsänderungen, Ausnahmen und Zeitstempel jeder Aufgabe.
• Entscheidungsnachweis. Aufgelöste Geräte-ID, Seriennummer, Eigentum, Gewahrsam, letzter Check-in, ausgewählte Aktion, Richtlinienversion, erforderlicher Genehmiger und verworfene Alternativen.
• Endpoint-Nachweis. Graph-Anfragekorrelation, Intune-Aktionsstatus, Übermittlungs- oder Check-in-Nachweis, Client-Ergebnis, physischer Rückgabestatus und Eskalationshistorie.
• Aufbewahrung und Integrität. Senden Sie Datensätze an eine aufbewahrungsgesteuerte Audit- oder Sicherheitsplattform mit Zugriffskontrollen und manipulationsnachweisbarer Behandlung. Microsoft-Serviceprotokolle sind wertvolle Nachweise, doch alle Offboarding-Logs standardmäßig als unveränderlich zu bezeichnen, wäre übertrieben.

Implementierungscheckliste

• Definieren Sie freiwillige, unfreiwillige, Contractor-, Lost-Device-, Legal-Hold-, Shared-Device- und Todesfallpfade, bevor destruktive Automatisierung aktiviert wird.
• Trennen Sie den wirksamen Austrittszeitpunkt vom Eingang des Quellereignisses, normalisieren Sie Zeitzonen und testen Sie Zeitumstellungen.
• Verwenden Sie stabile Microsoft-Entra- und Intune-Objekt-IDs statt Anzeigenamen, E-Mail-Adressen oder Gerätenamen als Schlüssel für destruktive Aktionen.
• Verarbeiten Sie Ereignisse idempotent und verhindern Sie, dass Duplikate oder Ereignisse in falscher Reihenfolge widersprüchliche Geräteaktionen auslösen.
• Verlangen Sie manuelle Genehmigung, wenn Eigentum, Gewahrsam, Legal Hold oder Geräteidentität unklar sind.
• Testen Sie ausgeschaltete Geräte, Flugmodus, veraltete Datensätze, mehrere Geräte, Shared Devices und bereits ausgemusterte Geräte in einem Nichtproduktionsring.
• Messen Sie Identity-Containment-Zeit, Geräteübermittlungszeit, Abschlusszeit, Ausnahmealter, Verhinderung falscher Geräteaktionen und physische Rückgabezeit getrennt.

Verwandte Ressourcen

• Nutzen Sie das vollständige Lebenszyklusmodell in Zero-Touch-Endpoint-Management für Security-Teams.
• Erstellen Sie die präventive Windows-Kontrollbasis mit der Windows Autopilot Security Baseline für Mid-Market-Teams.
• Planen Sie tiefere Offline-Transparenz und freigegebene lokale Kontrollen mit MDM plus Native Agent Architecture.
• Entdecken Sie Gideon Endpoint Management für Evaluierungswege zu Lebenszyklus, Posture und Remediation.

Primärquellen

• Microsoft beschreibt integrierte Identity-Aufgaben und Logic-Apps-Erweiterbarkeit in Plan a Lifecycle Workflows deployment.
• Microsoft dokumentiert die Grenze der Custom Extension in Lifecycle Workflows custom task extensions.
• Microsoft definiert Konnektivität, Priorität und Statusverhalten von Remoteaktionen in Geräteaktionen in Microsoft Intune.
• Microsoft dokumentiert das Entfernen von Unternehmensdaten und das Verhalten beim nächsten Check-in in Remote-Geräteaktion: Ausmustern.
• Microsoft dokumentiert Reset-Verhalten und plattformspezifische Optionen in Geräteaktion: Zurücksetzen.
• Microsoft dokumentiert Wiederverwendung und beibehaltene Konfiguration in Geräteaktion: Autopilot Reset.
• Microsoft erklärt, warum die Durchsetzung von Access Tokens je nach Dienst variiert, in Continuous Access Evaluation in Microsoft Entra.

So verwenden Sie diese Ressource

Überführen Sie jede Architekturphase in eine verantwortete Kontrolle mit messbarem Service Level. Pilotieren Sie zunächst mit synthetischen Austritten und Testgeräten, weisen Sie nach, dass mehrdeutige Gerätezuordnungen sicher anhalten, und definieren Sie Erfolg als verifiziertes Identity-Containment plus bestätigtes Endpoint-Ergebnis oder formal akzeptierte Ausnahme.