Microsoft Defender for Endpoint: Onboarding je Plattform

Nachdem die Komponenten und das Vulnerability Management der Serie geklärt sind, geht es jetzt um den Schritt, ohne den Defender for Endpoint (MDE) gar nichts liefert: das Onboarding. Erst ein onboardetes Gerät sendet Telemetrie an den Dienst, taucht im Portal auf und wird durch die Security-Policies geschützt.

Der richtige Onboarding-Weg hängt an der Plattform und daran, wie das Gerät bereits verwaltet wird. Dieser Artikel geht jede relevante Plattform einzeln durch: Windows-Clients über Microsoft Intune, Server über Defender for Cloud und Azure Arc (inklusive Direct Onboarding), Linux, das klassische Onboarding über Configuration Manager und GPO sowie die mobilen bzw. Apple-Plattformen macOS und iOS.

Diese Serie fokussiert Microsoft Defender for Endpoint Plan 2. Alle Plan-1-Funktionen sind in Plan 2 enthalten. Das Onboarding des Defender Antivirus (Next Generation Protection) ist ein kritischer Baustein der Gesamtplattform – die AV-Konfiguration und die Migration von Drittanbieter-Lösungen behandelt der nächste Teil.

Onboarding über Microsoft Intune

Wenn Windows 10/11 oder ein Windows Cloud PC bereits mit Intune verwaltet wird, ist Intune auch der empfohlene Weg für Onboarding und Konfiguration von Defender for Endpoint. Über Co-Management lassen sich zusätzlich Geräte einbinden, die an Configuration Manager hängen; für Server ist außerdem Tenant Attach möglich (das Onboarding über Configuration Manager beschreibt ein eigener Abschnitt weiter unten).

Integration aktivieren (Service-to-Service-Verbindung)

Bevor Geräte angebunden werden können, muss die Service-zu-Service-Verbindung zwischen Intune und Defender for Endpoint einmalig hergestellt werden. Dafür sind in beiden Portalen entsprechende Administratorrechte nötig. Im Defender-Portal:

• Am Microsoft Defender-Portal (security.microsoft.com) anmelden.
• Zu Settings → Endpoints → Advanced features navigieren.
• Den Schalter Microsoft Intune connection auf On stellen.

Der Schalter „Microsoft Intune connection" in den Advanced features des Defender-Portals.

Anschließend lässt sich der Status im Intune-Portal unter Endpoint security → Microsoft Defender for Endpoint prüfen. Bei erfolgreicher Kopplung steht Connection status = Enabled, und Last synchronized liegt kurz zurück.

Verbindungsstatus im Intune-Portal: „Enabled" mit aktuellem Synchronisierungszeitpunkt.

Endpoint-Security-Konfiguration und Compliance

In derselben Ansicht gibt es mehrere relevante Einstellungen:

• Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations einschalten, wenn MDE Sicherheitskonfigurationen auf Geräten durchsetzen soll. Das betrifft nur Geräte, die nicht über Intune verwaltet werden, und ist für das eigentliche Onboarding nicht erforderlich – es dient der späteren Policy-Verwaltung.
• Compliance-Integration: In Intune lassen sich Compliance-Richtlinien definieren, die nur konforme Geräte zulassen. Signale des MDE-Sensors fließen dabei in den Konformitätsstatus ein – etwa über die Einstellung „Require the device to be at or under the machine risk score". Zusätzlich prüfen die Richtlinien optional den Defender-Antivirus-Status (installiert, aktuelle Definitionen, aktivierter Echtzeitschutz).

Compliance-Einstellung „Require the device to be at or under the machine risk score" in Intune.

Optionale Defender-Antivirus-Prüfungen in der Compliance-Richtlinie (installiert, aktuelle Definitionen, Echtzeitschutz).

Im Abschnitt Defender for Endpoint der Endpoint-Security-Seite aktiviert man je nach Plattform die passenden Schalter:

• Android-Geräte (ab 6.0.0) mit MDE verbinden
• iOS/iPadOS-Geräte (ab 13.0) mit MDE verbinden
• Windows-Geräte (ab 10.0.15063) mit MDE verbinden
• App-Synchronisierung für iOS/iPadOS aktivieren (sendet Inventardaten installierter Apps)
• Nicht unterstützte Betriebssystemversionen blockieren

Für Windows sollte insbesondere Connect Windows devices version 10.0.15063 and above to Microsoft Defender for Endpoint auf On stehen.

Der Windows-Schalter „Connect Windows devices version 10.0.15063 and above" im Abschnitt Defender for Endpoint.

Für mobile Plattformen lassen sich zusätzlich App-Schutzrichtlinien (App Protection) auswerten. Damit kann der Zugriff auf Unternehmensdaten eingeschränkt werden, wenn ein Gerät ein festgelegtes maximales Bedrohungsniveau überschreitet. Diese Funktion ist nur für iOS und Android verfügbar und benötigt die entsprechende Verknüpfung unter App protection policy evaluation im Intune-Portal.

Verknüpfung unter „App protection policy evaluation" für iOS und Android.

Onboarding-Profil (EDR) erstellen

Sobald die Integration steht, werden die Geräte tatsächlich angebunden. Empfohlen wird das Endpoint Detection and Response (EDR)-Profil unter Endpoint Security:

• Im Intune-Portal zu Endpoint security navigieren.
• Endpoint detection and response auswählen und Create Policy klicken.

Über „Endpoint detection and response → Create Policy" beginnt die Erstellung des Onboarding-Profils.

• Als Platform Windows 10, Windows 11, and Windows Server und als Profile Endpoint detection and response wählen.

Platform „Windows 10, Windows 11, and Windows Server" und Profile „Endpoint detection and response".

Im Abschnitt Basics einen aussagekräftigen Namen und optional eine Beschreibung vergeben. Unter Configuration settings sind drei Einstellungen besonders relevant:

Beim client configuration package type gibt es folgende Optionen:

• Auto from connector – bezieht das Onboarding-Paket (Blob) automatisch aus der MDE-Bereitstellung. Voraussetzung: aktive und synchronisierte Integration zwischen Intune und MDE. Ein manuelles Hochladen entfällt.
• Onboard – für den Fall, dass keine Verbindung besteht oder Intune in einem anderen Tenant konfiguriert ist. Hier wird der Onboarding-Blob manuell eingetragen.
• Offboard – nur für das spätere Offboarding, beim Onboarding nicht relevant.

Der Paket-Typ „Auto from connector" bezieht das Onboarding-Paket automatisch aus der MDE-Bereitstellung.

Sample sharing sollte auf Enabled bleiben, um die cloudbasierten Schutzmechanismen voll zu nutzen. Die Telemetry reporting frequency (Standard: Normal, alternativ Expedite) ist seit Juli 2023 veraltet und aus den aktuellen Vorlagen entfernt; in bestehenden Profilen bleibt der Wert auf Not Configured.

Die Einstellung „Sample sharing" sollte auf „Enabled" bleiben.

Die „Telemetry reporting frequency" ist heute veraltet – in bestehenden Profilen auf „Not Configured" belassen.

Abschließend das Profil speichern und der gewünschten Gerätegruppe zuweisen. Es empfiehlt sich, mit einer kleinen Pilotgruppe zu starten, um Sensor-Funktion und Netzwerkverbindungen kontrolliert zu prüfen, bevor das Rollout auf alle Geräte erfolgt. Wichtig: Der Windows-Dienst SENSE (der Sensor) wird gelegentlich manuell blockiert – für MDE müssen aber alle empfohlenen Netzwerkzugriffe des Dienstes erlaubt sein. Nach der Anbindung der ersten Geräte lohnt eine Prüfung mit dem Microsoft Defender for Endpoint Client Analyzer.

Nach dem Onboarding: Prüfen und Troubleshooting

Nach kurzer Zeit sollte MDE bereitgestellt sein und der Dienst SENSE auf jedem Client laufen. Über die Assignment Report-Funktion in Intune lässt sich prüfen, ob das Profil angewendet wurde.

Der Assignment Report zeigt, ob das Profil erfolgreich auf die Geräte angewendet wurde.

Für die Fehlersuche:

• Lokales Ereignisprotokoll (SENSE): Im Event Viewer unter Applications and Services Logs → Microsoft → Windows → SENSE. Läuft SENSE, braucht die erste Synchronisierung ein paar Minuten. Kommt keine Cloud-Verbindung zustande, führt die gemeldete Event-ID zur Ursache.
• Voraussetzung Diagnosedaten: Der Windows-Diagnosedaten-Dienst muss aktiviert sein, sonst schlägt Onboarding bzw. Datenerfassung fehl.
• Registry: Unter HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection liegen die zentralen Onboarding-Informationen. Der Unterschlüssel OnboardingInfo enthält u. a. Organisations-ID, geoLocation und den Blob-Wert.

Ist alles korrekt, erscheint das Gerät im Defender-Portal unter Assets → Devices. In der Spalte Managed by steht für Intune-verwaltete Geräte der Eintrag Intune; der Sensor-Status sollte auf Active stehen.

Das erfolgreich angebundene Gerät im Defender-Portal – Sensor-Status „Active", verwaltet durch Intune.

Geräte-Tag über Intune verteilen

Tags helfen, Geräte nach Kategorie oder Standort zu strukturieren – wichtig etwa für Ausschlüsse, automatisierte Untersuchungen (AIR) oder Indikatoren. Tags lassen sich direkt im Portal setzen oder per Registry-Schlüssel, den man über Intune-Konfigurationsprofile verteilt:

• Im Microsoft Intune admin center zu Devices navigieren.
• Configuration profiles auswählen und Create Policy klicken.
• Als Platform Windows 10 and later, als Profile type Templates → Custom wählen.

Dann folgende OMA-URI-Einstellung hinzufügen:

Nach Zuweisung erscheint das Tag beim Gerät im Portal. Über Registry, PowerShell oder Intune lässt sich pro Gerät jeweils nur ein Tag setzen; mehrere Tags müssen manuell im Portal oder über eine erweiterte Automatisierung (z. B. Logic App und API) vergeben werden.

Onboarding über Defender for Cloud

Für Windows-Server ist Microsoft Defender for Cloud (bzw. Defender for Servers) der empfohlene Weg. Mit Defender for Servers wird der Defender-for-Endpoint-Plan-2 automatisch per Integration auf Server-Ressourcen ausgerollt – die dafür nötige Lizenz ist bereits enthalten.

Plan 1 vs. Plan 2

Defender for Cloud umfasst zwei Tarife, die beide MDE Plan 2 einschließen. Für rund 10 $ Aufpreis pro geschütztem Server bietet Plan 2 zusätzliche Funktionen. Wichtig: Hinsichtlich Defender for Endpoint selbst gibt es keinen Unterschied – Plan 1 und Plan 2 ermöglichen beide das volle MDE Plan 2. Plan 2 enthält jedoch u. a. das MDVM Add-on ohne zusätzliche Lizenz.

Plan 1 reicht, wenn man ausschließlich Defender for Endpoint (inkl. Schwachstellen-Management) und das grundlegende Agent-Onboarding nutzen möchte.

Automatische Bereitstellung

Ist Defender for Servers aktiviert und die MDE-Integration konfiguriert, wird der Agent automatisch auf allen unterstützten Maschinen der jeweiligen Azure-Subscription installiert. Für Windows rollt Defender for Cloud die Azure-Erweiterung MDE.Windows aus, die im Hintergrund folgende Schritte durchführt:

• Onboarding in MDE: Registrierung der Maschine beim Dienst.
• Installation des einheitlichen Agents (Windows Server 2012 R2/2016): Das Paket MD4WS.msi (Microsoft Defender for Windows Server) wird installiert.
• SCEP-Prüfung: Ein vorhandenes System Center Endpoint Protection wird automatisch deinstalliert, um Konflikte zu vermeiden.
• Patch-Prüfung: Fehlende notwendige Updates werden – sofern erforderlich – installiert.
• AV-Upgrade (2016): Bei Windows Server 2016 wird bei Bedarf die Defender-Antivirus-Produktversion aktualisiert.

Auf Linux-Systemen wird die Erweiterung MDE.Linux installiert. Unter Linux läuft Defender for Endpoint standardmäßig im passiven Modus, d. h. Sensordaten-Erfassung und EDR laufen, aber kein aktiver AV-Schutz.

Ablaufdiagramm: Der automatisierte Onboarding-Prozess je nach Server-Version (2019+, 2012 R2, 2016) inkl. SCEP-Entfernung und Update-Installation.

Voraussetzungen (Server 2012 R2 / 2016)

Der einheitliche Agent für die älteren Server-Versionen bringt zusätzliche Voraussetzungen mit:

Windows Server 2012 R2:

• System auf dem aktuellen monatlichen Rollup-Update.
• Updates KB2999226 und KB3080149 installiert (in den neuesten Rollups bereits enthalten).

Windows Server 2016:

• Servicing Stack Update (SSU) vom 14. September 2021 (oder neuer).
• Latest Cumulative Update (LCU) vom 20. September 2018 (oder neuer). Empfohlen: stets aktuelle SSUs/LCUs, Server vor der MDE-Installation vollständig patchen.
• Windows-Defender-Antivirus-Serverrolle installiert, aktiviert und aktuell.
• Aktuellste Defender-Antivirus-Plattformversion (z. B. über Microsoft Update-Katalog oder MMPC).

Integration im Azure-Portal aktivieren

Die manuelle Aktivierung erfolgt im Azure-Portal (alternativ per PowerShell/API für mehrere Subscriptions):

1. Am Azure-Portal anmelden und Microsoft Defender for Cloud öffnen.
2. Zu Environment settings navigieren.

Der Bereich „Environment settings" in Microsoft Defender for Cloud.

3. Die gewünschte Subscription auswählen.
4. Im Abschnitt Defender plans den Eintrag Servers auf Plan 1 oder Plan 2 stellen und auf On schalten.

Im Abschnitt „Defender plans" den Eintrag „Servers" auf Plan 1 oder Plan 2 einschalten.

Über „Change plan" lässt sich der Plan wechseln; rechts werden die Unterschiede und Preise je Server/Monat aufgelistet.

Danach in denselben Defender plans auf Settings & monitoring klicken und Endpoint protection auf On stellen, um die automatische Bereitstellung zu aktivieren.

Über „Settings & monitoring" erreicht man die einzelnen Komponenten-Schalter.

„Endpoint protection" auf „On" rollt den Defender-for-Endpoint-Agent automatisch auf die Server aus.

Hinweise zu älteren Subscriptions: Die Schaltfläche Enable unified solution ist nur sichtbar, wenn Defender for Servers vor dem 20. Juni 2022 aktiviert war – hier sollte man von der Legacy-Lösung (Log Analytics/MMA-Agent) auf die einheitliche Lösung wechseln. Erscheint ein Hinweis wie „Components missing. Fix", müssen fehlende Komponenten über Fix nachinstalliert werden.

Beispiel einer älteren Subscription: fehlende Komponenten werden über „Fix" nachinstalliert.

Alternative über Azure Policy

Statt der integrierten Bereitstellung kann der MDE-Agent auch über Azure Policy ausgerollt werden. Microsoft stellt dafür vordefinierte Richtlinien bereit:

• Deploy Microsoft Defender for Endpoint agent on Windows virtual machines
• Deploy Microsoft Defender for Endpoint agent on Windows Azure Arc machines
• Deploy Microsoft Defender for Endpoint agent on Linux hybrid machines
• Deploy Microsoft Defender for Endpoint agent on Linux virtual machines

Log Analytics / Azure Monitor Agent nötig?

Die neue MDE-Lösung für Windows Server 2012 R2/2016 basiert – wie bei Windows 10 oder Server 2019+ – auf dem SENSE-Dienst und benötigt für die grundlegende Endpoint-Schutzfunktion keinen Log-Analytics-Agenten. Auto-Provisioning für LA/AMA kann daher deaktiviert bleiben, wenn ausschließlich MDE genutzt wird.

Einige erweiterte Plan-2-Funktionen erfordern jedoch zusätzliche Überwachungs-Agents (Log Analytics Agent und Azure Monitor Agent):

• Endpoint Protection Assessment (ist ein Endpunktschutz installiert und aktuell?)
• Adaptive Application Controls (AAC)
• File Integrity Monitoring (FIM)
• Fileless Attack Detections
• OS Baseline Configuration (zusätzlich Guest-Configuration-Agent, in Preview)

Auto-Provisioning für den Log Analytics- bzw. Azure Monitor-Agent – hier deaktiviert (Off).

Es empfiehlt sich, diese Funktionen zu nutzen und dafür das Auto-Provisioning des Azure Monitor Agents zu aktivieren.

Defender Antivirus – Betriebsmodus auf Servern

Auf Windows-Servern wird Defender Antivirus nicht automatisch deaktiviert, wenn eine andere AV-Lösung aktiv ist (nur unter Linux wird MDE standardmäßig passiv installiert). Ist Defender AV nicht die primäre Lösung, sollte man den passiven Modus erwägen. Wichtig: Ohne Drittanbieter-AV muss Defender AV aktiv im Echtzeitschutz laufen. Den passiven Modus erzwingt man per Registry-Schlüssel:

Pfad:  HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection
Name:  ForceDefenderPassiveMode
Typ:   REG_DWORD
Wert:  1

Wert 1 aktiviert den passiven Modus; bei 0 oder fehlendem Schlüssel läuft Defender AV im aktiven Modus, sofern kein anderer AV aktiv ist.

Installation überwachen

Der Status der MDE.Windows-Erweiterung lässt sich pro Maschine im Azure-Portal unter Extensions + applications prüfen. Bei erfolgreicher Bereitstellung steht dort Provisioning succeeded; die Detailansicht zeigt Version, Status und Logs.

Unter „Extensions + applications" ist die MDE.Windows-Erweiterung mit Status „Provisioning succeeded" sichtbar.

Die Detailansicht der MDE.Windows-Erweiterung zeigt Versionsnummer, Bereitstellungsstatus und Statusmeldungen.

Schlägt die Installation fehl, sind erfahrungsgemäß folgende Ursachen häufig:

• Defender Antivirus läuft nicht im aktiven Modus (v. a. Server 2016/2019).
• Windows-Defender-Serverrolle nicht installiert (Server 2016).
• Erforderliche Updates fehlen.
• Netzwerk-/Konnektivitätsanforderungen nicht erfüllt.
• Defender AV per Registry oder GPO deaktiviert.

Azure Arc

Server, die nicht in Azure laufen – on-premises oder in einer anderen Cloud –, lassen sich über Azure Arc oder das neue Direct Onboarding anbinden. Der bevorzugte Weg für Defender for Cloud ist Azure Arc: Ein Arc-verbundener Server erscheint als Azure-Ressource und wird dann genauso in MDE integriert wie eine Azure-VM.

Wichtige Ankündigung: Die separate Defender for Endpoint for Servers-Lizenzierung (z. B. via GPO, MECM) wird eingestellt. Künftig führen Azure Arc / Defender for Cloud bzw. Direct Onboarding die Server in MDE. Direct Onboarding (angekündigt Juni 2023) bindet lokale Windows- und Linux-Server direkt aus dem Defender-Portal an; die Abrechnung läuft über Azure/Defender for Cloud – ohne zusätzliche Agents oder Erweiterungen und mit derselben Datenintegration wie das Arc-Verfahren.

Was sind Azure-Arc-fähige Server?

Azure-Arc-fähige Server binden Windows- und Linux-Maschinen (physisch oder VM) außerhalb von Azure in Azure ein – konsistent mit der Verwaltung regulärer Azure-VMs. Jede angebundene Maschine erhält eine Resource-ID und liegt in einer Ressourcengruppe. Auf deren Basis lässt sich Defender for Cloud aktivieren und Defender for Servers Plan 1/2 einschalten, wodurch der MDE-Agent automatisch bereitgestellt wird.

Azure Arc ist nicht für VMs in Azure, Azure Stack Hub oder Azure Stack Edge gedacht (diese gelten als Azure-VMs). Sinnvolle Einsatzgebiete sind:

• VMware-basierte VMs
• Hyper-V-VMs
• On-Premises-(physische) Server
• Azure Stack HCI
• andere Clouds (AWS, Google Cloud usw.)

Der Azure Connected Machine Agent läuft nur auf 64-Bit-Systemen. Die unterstützte Onboarding-Methode hängt am Betriebssystem:

Voraussetzungen (Netzwerk und Azure)

Arc-fähige Server brauchen ausgehende Internet-Konnektivität zu bestimmten Azure-Diensten (Proxy ist möglich); alle Endpunkte und Ports stehen in den Netzwerk-Anforderungen des Connected Machine Agents. In der Azure-Subscription müssen zudem drei Resource Provider registriert sein – z. B. per Azure PowerShell:

Connect-AzAccount
Set-AzContext -SubscriptionId <Subscription-ID>
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute
Register-AzResourceProvider -ProviderNamespace Microsoft.GuestConfiguration
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridConnectivity

Berechtigungen: Vorsicht bei Tier-0

Beim Onboarding von Domänencontrollern oder anderen Tier-0-Servern nach Azure Arc ist ein sauberes Zugriffsmodell entscheidend. Über verfügbare Erweiterungen (z. B. die Custom Script Extension) lassen sich PowerShell-Skripte ausführen, lokale Benutzer anlegen oder kritische Einstellungen ändern. Wer Azure-Arc-Administrator ist (oder werden kann), ist damit faktisch Domänen-Administrator dieser Umgebung – MDE als EDR erkennt viele, aber nicht zwingend alle bösartigen Aktionen.

Maßnahmen zur Risikominimierung (Azure Arc):

• Durchdachte RBAC-/IAM-Struktur entwerfen und umsetzen.
• Tier-0-Server und Domänencontroller nur einem sehr kleinen Personenkreis zugänglich machen.
• Dedizierte Ressourcengruppen für Tier-0-Assets und strikt beschränkter Zugriff.
• Regelmäßig prüfen, wer Kontrolle über die Arc-Ressourcen hat.

Auch ohne Azure Arc besteht ein Risiko: Über die Live Response-Funktion können berechtigte Benutzer eigene PowerShell-Skripte auf jedem eingebundenen Rechner ausführen. Deshalb sollte streng geregelt sein, wer im Portal Live Response nutzen darf. Empfehlungen:

• Kritische Maschinen (Tier-0) eindeutig taggen.
• Separate Gerätegruppen für Tier-0/kritische Systeme.
• Nur wenigen Personen Berechtigungen für diese Gerätegruppen erteilen.
• Live-Response-Aktivitäten regelmäßig prüfen.
• Falls möglich, in den erweiterten Features die Ausführung unsignierter Skripte via Live Response deaktivieren.

Onboarding-Schritte im Azure-Portal

Es gibt mehrere Wege, den Connected Machine Agent bereitzustellen (Einzelserver, mehrere Server, aus Update Management, mit Azure Migrate). Exemplarisch das Onboarding eines Windows Servers:

1. Am Azure-Portal anmelden.
2. Nach Azure Arc suchen und den Dienst öffnen.
3. Auf Servers klicken.
4. Über Add einen oder mehrere Server hinzufügen und die Onboarding-Methode wählen. Der Hauptunterschied zwischen Einzel- und Massen-Onboarding ist die Authentifizierung: Für mehrere Server nutzt man einen Service Principal, für einen einzelnen Server genügt der Device Code Flow.
5. Voraussetzungen: HTTPS-Zugriff (Port 443) auf bestimmte Azure-URLs, lokale Administratorrechte, Auswahl der Verbindungsart (Internet, Proxy, öffentlich, privat), ggf. Service Principal mit Rolle Azure Connected Machine Onboarding.
6. Ressourcendetails: Subscription, Resource Group, Region, Betriebssystem und Connectivity method festlegen. Tipp: getrennte Ressourcengruppen für Windows- und Linux-Server verwenden.
7. Authentifizierung (bei Massen-Onboarding): Über Create or manage service principals with Azure Arc-related roles einen neuen Service Principal erstellen, Name/Scope/Subscription/Resource Group angeben, ein Client Secret generieren und die Rolle Azure Connected Machine Onboarding zuweisen. Application (Client) ID und Client Secret kopieren und sicher aufbewahren.
8. Tags (optional): Azure-Tags für bessere Struktur (z. B. Standort/Rechenzentrum).
9. Skript herunterladen und ausführen: Azure erzeugt ein PowerShell-Skript (als .ps1 herunterladbar), das den Connected Machine Agent installiert und die Maschine bei Arc registriert. Bei Service-Principal-Nutzung muss der Secret-Wert im Skript eingetragen werden.

Onboarding-Skript ausführen und prüfen

Das Skript wird auf dem Server ausgeführt und installiert ggf. .NET Framework sowie den Connected Machine Agent. Im Erfolgsfall meldet es u. a. „Installation of azcmagent completed successfully" und „Machine successfully connected to Azure". Logs und Konfigurationsdateien liegen unter:

C:\ProgramData\AzureConnectedMachineAgent

Den Status des Agents und der angewendeten Konfiguration fragt man so ab:

azcmagent show

Der Befehl liefert Details zur Verbindung: laufende Dienste, Agent-Version, zugeordnete Ressourcengruppe, Subscription, Tenant und mehr.

Nach dem Arc-Onboarding: Defender for Cloud und Portal

Nach kurzer Zeit erscheint der Server unter Azure Arc → Servers (inkl. gesetzter Tags) und wenig später in Defender for Cloud mit dem Ressourcentyp „Servers – Azure Arc". Ist Defender for Servers in der Subscription aktiviert (inkl. MDE-Integration/einheitlicher Lösung), wird der Server automatisch in MDE onboardet. Unter Recommendations erscheinen Hinweise zur Sicherheitskonfiguration – für MDE besonders die Empfehlung, dass ein Endpoint Protection (Antivirus) installiert sein sollte. Schließlich ist das Gerät im Defender-Portal unter Devices sichtbar, und auf dem Server ist die MDE.Windows-Erweiterung installiert.

Prüfung des installierten Defender auf dem Server.

Der Arc-Server ist nach abgeschlossenem Onboarding im Defender-Portal unter „Devices" sichtbar.

Zusatzfunktionen kosten extra: Azure Arc bietet Azure Policy, Extensions, Machine Configuration, Automanage, Updates u. v. m. – manche dieser Funktionen verursachen zusätzliche Kosten (die Azure-Policy-Gast-Konfiguration z. B. ca. 6 $/Server/Monat).

Azure-Arc-Agent aktualisieren

Der Connected Machine Agent aktualisiert sich nicht automatisch; Update-Empfehlungen erscheinen im Azure Advisor. Alle Maschinen, die nicht auf dem aktuellen Stand sind, findet man per Azure Resource Graph:

AdvisorResources
| where type == 'microsoft.advisor/recommendations'
| where properties.category == 'HighAvailability'
| where properties.shortDescription.solution == 'Upgrade to the latest version of the Azure Connected Machine agent'
| project
   id,
   JoinId = toupper(properties.resourceMetadata.resourceId),
   machineName = tostring(properties.impactedValue),
   agentVersion = tostring(properties.extendedProperties.installedVersion),
   expectedVersion = tostring(properties.extendedProperties.latestVersion)
| join kind=leftouter(
   Resources
   | where type == 'microsoft.hybridcompute/machines'
   | project
      machineId = toupper(id),
      status = tostring(properties.status)
) on $left.JoinId == $right.machineId
| where status != 'Expired'
| summarize by id, machineName, agentVersion, expectedVersion
| order by tolower(machineName) asc

Der Agent lässt sich manuell oder über Microsoft Update aktualisieren.

Direct Onboarding (ohne Azure Arc)

Manche Organisationen brauchen nur den EDR-Schutz, nicht die zusätzlichen Management-Funktionen der Azure-Resource-Ebene – und Azure Arc ist kein reines „Weiter, Weiter, Fertig": Es erfordert laufende Pflege, ein RBAC-Konzept, Update-Management und Auditing. Mit Direct Onboarding lassen sich On-Premises-Windows- und -Linux-Server direkt in Defender for Servers aufnehmen: Der MDE-Client wird wie gewohnt über das Defender-Portal (Onboarding-Paket oder Skript) installiert, Lizenzierung und Abrechnung laufen im Hintergrund über Azure/Defender for Cloud.

Direct Onboarding ist eine bewusst zu setzende Opt-in-Mandanteneinstellung. Nach Aktivierung wirkt sie auf alle bestehenden und neuen MDE-Server; neue Server werden automatisch der gewählten Subscription hinzugefügt.

Aktivieren:

• Voraussetzungen: Owner-Rechte auf die ausgewählte Subscription sowie Global Administrator oder Security Administrator.

1. In Defender for Cloud zu Environment Settings navigieren.
2. Den Abschnitt Direct Onboarding auswählen.
3. Den Schalter auf On stellen.
4. Eine Subscription auswählen, unter der die MDE-geschützten Server geführt werden. Idealerweise eine separate Subscription, um Plan-Verwaltung und Kostenzuordnung sauber zu halten.

Nach dem Einschalten kann es bis zu 24 Stunden dauern, bis alle Maschinen im Inventory der Subscription auftauchen.

Plan bei Direct Onboarding: Direct Onboarding gewährt alle Funktionen von Plan 1; Plan 2 bringt hier bezogen auf Defender for Endpoint keinen Mehrwert. Einige Plan-2-Features benötigen den Azure Monitor Agent, der auf Nicht-Azure-Servern nur über Azure Arc verfügbar ist. Per Direct Onboarding eingebundene Maschinen erhalten daher nur Plan-1-Funktionen plus das Vulnerability-Management-Add-on.

Inventar prüfen: In Defender for Cloud unter Inventory über den Filter Resource Type nach neuen Typen filtern:

• Servers – Defender for Endpoint – über Direct Onboarding eingebunden.
• Virtual machines – klassische Azure-VMs.
• Servers – Azure Arc – über Azure Arc eingebunden.

Doppelte Erfassung vermeiden: Ist eine Azure-VM oder Arc-Maschine bereits über Defender for Servers registriert und der MDE-Client läuft, wird sie trotzdem in den Direct-Onboarding-Flow einbezogen, sofern die MDE.Windows/MDE.Linux-Erweiterung nicht installiert ist – dann droht Doppelzählung. Man muss sicherstellen, dass Azure-VMs und Arc-Server über die passende MDE-Erweiterung angebunden sind. Erscheinen Maschinen dennoch doppelt, erfolgt die Abrechnung stundengenau nach Aktivität. Ein späterer Wechsel von Direct Onboarding zu Azure Arc ist problemlos möglich, ohne Doppelkosten und ohne vorheriges Offboarding.

Sensor-Installation bei Direct Onboarding: Der MDE-Sensor wird über die üblichen Methoden installiert. Für Windows-Server z. B. per Configuration Manager (SCCM), Intune (Tenant Attach), PowerShell-Skript oder GPO. Für Linux-Server per Shell-Skript (lokal oder SSH), Puppet, Ansible, Chef oder SaltStack. Bei Windows Server 2012 R2/2016 muss zunächst der Unified Agent (MSI) installiert und danach das Onboarding-Skript ausgeführt werden. Der grundlegende Ablauf:

1. Server in MDE onboarden (GPO, Skript, SCCM, Intune o. Ä.).
2. Direct Onboarding in Defender for Cloud aktivieren, mit Defender for Servers Plan 1.
3. Automatische Synchronisation zur Lizenzverwaltung in Defender for Cloud.
4. Alarme und Empfehlungen erscheinen in Defender for Cloud.
5. Ergebnis: Der Server läuft unter MDE, die Lizenzierung/Abrechnung erfolgt über Defender for Servers Plan 1.

Linux

Das Onboarding eines Linux-Servers über Azure Arc bzw. Direct Onboarding folgt demselben Muster wie bei Windows – nur wählt man beim Betriebssystem Linux aus. Statt eines PowerShell-Skripts erhält man ein Shell-Skript, das lokal auf dem Server ausgeführt wird.

Wie bei Windows – nur beim Betriebssystem „Linux" auswählen.

Vorgehen:

1. Auf dem Server anmelden.
2. Einen Text-Editor öffnen, z. B. nano, und eine neue Skriptdatei anlegen (etwa ArcSkript.sh).

Den Text-Editor „nano" öffnen, um das Onboarding-Skript einzufügen.

3. Den Inhalt des generierten Onboarding-Skripts einfügen.
4. Speichern (in nano: Strg + X, dann mit Y bestätigen).

Die Skriptdatei wird unter dem Dateinamen „ArcSkript.sh" gespeichert.

5. Das Skript mit Root-Rechten ausführen:

sudo bash ArcSkript.sh

Das Skript wird mit Root-Rechten ausgeführt; anschließend folgt die Authentifizierung.

6. Anschließend die Authentifizierung durchführen (Device Code bzw. Service Principal, je nach gewählter Methode).

Nach erfolgreichem Onboarding erscheint der Linux-Server – wie ein Windows-Server – in Azure Arc bzw. Defender for Cloud und im Defender-Portal. Auf Linux-Systemen läuft Defender for Endpoint standardmäßig im passiven Modus (Sensor und EDR aktiv, kein aktiver AV-Schutz).

Configuration Manager & GPO

Wo weder Intune noch die Cloud-Wege genutzt werden, lassen sich Windows-Geräte klassisch über Microsoft Endpoint Configuration Manager (ConfigMgr/MECM, ehemals SCCM) oder Gruppenrichtlinien (GPO) onboarden. Idealerweise migriert man Clients langfristig zu Intune oder nutzt Co-Management.

Hinweis für Server: Defender for Endpoint Plan 1/2 (Standalone) beinhalten keine Server-Lizenzen. Für Server ist Microsoft Defender for Servers (Plan 1 oder 2) im Rahmen von Defender for Cloud vorgesehen. Die separate MDE-Lizenzierung für Server wird eingestellt – für Windows-Server künftig Azure Arc bzw. Defender for Cloud nutzen.

Deployment mit Configuration Manager (Onboarding-Profil)

MECM enthält vordefinierte Endpoint-Protection-Onboarding-Richtlinien für Windows 10/11 (integrierte Konsole ab Version 1606; bei älteren Versionen ein Upgrade empfohlen). Die Endpoint Protection Site Role ist für die initiale Bereitstellung nicht erforderlich – sie dient optional der Verwaltung von Defender-AV-Einstellungen.

Onboarding-Paket herunterladen:

1. Im Portal security.microsoft.com zu Settings → Endpoints → Onboarding navigieren.
2. Bei Deployment method Microsoft Endpoint Configuration Manager wählen.
3. Das Onboarding-Paket herunterladen.
4. Die ZIP-Datei entpacken – die enthaltene .onboarding-Datei wird für MECM benötigt.

Im Defender-Portal die Deployment-Methode „Microsoft Endpoint Configuration Manager" wählen und das Paket herunterladen.

Profil in MECM importieren: In der MECM-Konsole zu Assets and Compliance → Endpoint Protection → Microsoft Defender ATP Policies navigieren und eine neue Richtlinie hinzufügen:

• Name und optional Beschreibung vergeben.
• Onboarding als Richtlinientyp wählen.
• Über Browse… die extrahierte .onboarding-Datei einbinden. (Die Felder für Organization-ID, Workspace Key und Workspace ID sind nur für ältere Systeme mit MMA-Agent nötig, nicht für Windows 10/11.)

Der MECM-Assistent: Auswahl der zuvor heruntergeladenen Onboarding-Konfigurationsdatei.

Im nächsten Schritt konfiguriert man die Proben-Sammlung – hier „Alle Dateitypen" wählen, damit im Verdachtsfall alle Dateitypen an die Defender-Cloud gehen. Danach die Richtlinie einer Device Collection zuweisen und zunächst auf Testgeräten erproben. Der Onboarding-Prozess auf den Clients kann etwas Zeit brauchen.

Deployment via Co-Management

Sind Windows 10/11-Geräte noch nicht in Intune eingebunden, geht das Onboarding auch über Co-Management – die Verbindung einer bestehenden ConfigMgr-Umgebung mit der Microsoft-365-Cloud. Damit lassen sich Verwaltungs-Workloads schrittweise von ConfigMgr auf Intune verlagern.

Co-Management: App- und Policy-Workloads lassen sich flexibel zwischen Configuration Manager (on-premises) und Intune (Cloud) aufteilen.

Die Konfiguration erfolgt im MECM-Admin-Center unter Administration → Cloud Services → Cloud Attach → Workloads. Je Workload gibt es drei Steuerungsmodi:

• Configuration Manager – ausschließlich durch MECM/SCCM verwaltet.
• Pilot Intune – für eine definierte Pilot-Gerätekollektion über Intune (schrittweise Einführung).
• Intune – vollständig durch Intune gemanagt.

Per Co-Management steuerbare Workloads sind u. a. Compliance policies, Device configuration, Endpoint Protection, Resource access policies, Client apps, Office Click-to-Run apps und Windows Update policies.

Für Defender for Endpoint muss die Endpoint Protection-Workload auf Intune umgeschaltet sein. Diese Kategorie umfasst u. a.:

• Windows Defender Antimalware
• Windows Defender Application Guard
• Windows Defender Firewall
• Windows Defender SmartScreen
• Windows Encryption (BitLocker)
• Windows Defender Exploit Guard
• Windows Defender Application Control
• Windows Defender Security Center
• Windows Defender for Endpoint (Microsoft Defender for Endpoint)

Bei aktiviertem Co-Management bleiben bestehende MECM-Einstellungen auf einem Gerät wirksam, bis Intune-Policies sie überschreiben – das ist by Design, um während der Übergabe lückenlosen Schutz zu gewährleisten.

Das eigentliche Onboarding via Co-Management folgt den gleichen Schritten wie beim Intune-Onboarding (Gerätekonfigurations-/EDR-Profil mit dem Onboarding-Skript). Einziger Unterschied: Geräte-Tags gehören nicht zur Endpoint-Protection-Workload, sondern zur Device-configuration-Workload – das Tagging kann daher entfallen oder muss separat über ein Intune-Konfigurationsprofil erfolgen.

Onboarding per Gruppenrichtlinie (GPO)

Werden weder Intune noch MECM genutzt, lässt sich das Onboarding per GPO durchführen.

Onboarding-Skript herunterladen:

1. Im Portal security.microsoft.com zu Settings → Endpoints → Onboarding navigieren.
2. Bei Deployment method Group Policy wählen.
3. Das Onboarding-Paket herunterladen.
4. Die ZIP entpacken – die Datei WindowsDefenderATPOnboardingScript.cmd wird benötigt. (Im Ordner OptionalParamsPolicy liegen zusätzlich ADMX-Vorlagen für Optionen wie Sample Sharing.)

Im Defender-Portal die Deployment-Methode „Group Policy" wählen und das Onboarding-Paket herunterladen.

Die .cmd-Datei an einen zentralen, schreibgeschützten Speicherort (Dateifreigabe) kopieren, auf den alle betreffenden Geräte zugreifen können.

GPO erstellen und konfigurieren: Das Skript wird per geplanter Aufgabe verteilt:

1. Die Gruppenrichtlinien-Verwaltungskonsole (GPMC) öffnen und mit Rechtsklick auf Group Policy Objects ein neues GPO erstellen (z. B. „MDE-Onboarding").
2. Rechtsklick auf das GPO → Edit.
3. Zu Computer Configuration → Preferences → Control Panel Settings → Scheduled Tasks navigieren.
4. Rechtsklick auf Scheduled Tasks → New → Immediate Task (At least Windows 7).

Im Dialog auf dem Reiter General:

• Security Options: Über Change User or Group… den Benutzer SYSTEM wählen, sodass unter When running the task NT AUTHORITY\SYSTEM eingetragen ist.
• Run whether user is logged on or not aktivieren.
• Run with highest privileges aktivieren.

Reiter „General": Benutzer auf SYSTEM (1), „Run whether user is logged on or not" (2) und „Run with highest privileges" (3) aktiviert.

Auf dem Reiter Actions eine neue Aktion (New…) mit Start a program anlegen und den UNC-Pfad zum Skript eintragen, z. B.:

\\Server\Share\WindowsDefenderATPOnboardingScript.cmd

Der UNC-Pfad muss für die Rechner erreichbar und das Skript ausführbar sein; das GPO wird auf die betreffenden Computer-Accounts verknüpft.

Reiter „Actions": „Start a program" mit dem UNC-Pfad zum Onboarding-Skript auf der Freigabe.

Sample Submission konfigurieren: Zwei Wege, um die Übermittlung verdächtiger Dateien zu steuern.

Methode 1 – GPO-Vorlage: Die ADMX-Vorlagen aus OptionalParamsPolicy in den zentralen Store (oder lokal nach C:\Windows\PolicyDefinitions\) kopieren. Danach unter Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Defender ATP die Richtlinie Enable/Disable Sample collection auf Enabled setzen.

Die Richtlinie „Enable/Disable Sample collection" auf „Enabled" gibt Proben zur Analyse an die Defender-Cloud frei.

Methode 2 – Registry-Schlüssel:

Wert 1 gibt alle Dateitypen frei (empfohlen); 0 deaktiviert die Übermittlung.

Troubleshooting: Zur Fehlersuche helfen mehrere Quellen:

• SENSE Event-Log: Im Event Viewer unter Applications and Services Logs → Microsoft → Windows → SENSE → Operational. Die erfolgreiche Registrierung meldet Event 403 („Registration of Windows Defender Advanced Threat Protection service completed").

Im SENSE-Operational-Log bestätigt Event 403 die erfolgreiche Registrierung des Defender-Dienstes.

• Onboarding-Ereignisse: Unter Windows Logs → Application (Quelle WDATPOnboarding) – zeigt Fehler/Erfolg beim Onboarding-Skript.
• ATPHandler.log (MECM): Beim Onboarding über Configuration Manager protokolliert der Client-Agent unter C:\Windows\CCM\Logs\ATPHandler.log die Ausführung der Policy und etwaige Fehler.

macOS

Für macOS wird MDE über Microsoft Intune bereitgestellt. Voraussetzungen sind macOS-kompatible Geräte und ein passend lizenzierter Defender-Plan (Plan 1/2 oder Business). Die Profile sollten exakt in der vorgegebenen Reihenfolge erstellt werden, damit die Bereitstellung sauber greift.

Bereitstellungsschritte in Intune

1. System-Erweiterungen: Konfigurationsprofil für macOS anlegen und System Extensions erlauben – Team ID UBF8T346G9 für wdav.epsext und wdav.netext.
2. Netzwerkfilter: netfilter.mobileconfig über eine Custom Policy ausrollen, um den Netzwerkverkehr zu überwachen.
3. Full Disk Access: Seit macOS 10.15 nötig – über fulldisk.mobileconfig.
4. Hintergrunddienste erlauben: Ab macOS 13 müssen Background-Services explizit erlaubt werden – background_services.mobileconfig.
5. Benachrichtigungen: notif.mobileconfig steuert, ob Defender- und Update-Warnungen erscheinen.
6. Accessibility und Bluetooth: accessibility.mobileconfig bzw. bluetooth.mobileconfig (wichtig ab macOS 14).
7. Microsoft AutoUpdate: Defender-Updates über com.microsoft.autoupdate2.mobileconfig verwalten (Kanal von Fast/Beta bis Production).
8. Defender-Einstellungen (Antivirus/EDR): Policy-Konfiguration wahlweise über das Defender-Portal oder Intune, mit Antivirus- oder EDR-Vorlage; optional per XML-Konfiguration (z. B. com.microsoft.wdav.xml).
9. Network Protection / Device Control: Optionale Funktionen, über Antivirus-Template und Full-Disk-Profil aktivierbar.
10. App-Veröffentlichung: Die eigentliche MDE-App über den Intune-App-Typ Microsoft Defender for Endpoint → macOS verteilen.
11. Onboarding-Paket: Im Defender-Portal unter macOS die MDM/Intune-Auswahl treffen, das Onboarding-XML (WindowsDefenderATPOnboarding.xml) herunterladen und in Intune hochladen.

Prüfung und Verifikation

• Gerätestatus: In Intune unter Devices → Configuration die Status-Reports einsehen und das MDE-Icon prüfen.
• Client-Installation: In den macOS-Systemeinstellungen unter Device Management kontrollieren, ob alle .mobileconfig-Profile vorhanden sind und das Defender-Icon in der Menu-Bar erscheint.
• Tests: Anti-Malware-Detection-Test und EDR-Detection-Test durchführen; ergänzend empfiehlt sich die DLP-Integration mit Microsoft Purview.

Hinweis zur Deinstallation: MDE lässt sich auf macOS nicht zentral über Intune deinstallieren – dafür ist derzeit Jamf nötig (siehe Uninstall-Anleitung). Häufige Probleme betreffen fehlende Lizenzen, nicht genehmigte System-Erweiterungen oder gestörte Cloud-Kommunikation.

iOS

Auf iOS schützt Defender for Endpoint vor Phishing, erkennt Jailbreaks und unsichere Netzwerkverbindungen; alle Signale laufen im zentralen Defender-Portal zusammen. Dieser Abschnitt behandelt die Bereitstellung über MEM/Intune für verwaltete (supervised/unsupervised) Geräte. Voraussetzungen:

• MDE-Lizenz zugewiesen
• Intune-Lizenz verfügbar
• iOS-Gerät mit iOS 14.0 oder höher
• Gerät in Entra ID registriert (über Authenticator-App) oder mit der Intune Company Portal App enrollt

Intune-Connector aktivieren und App bereitstellen

Zuerst im Defender-Portal unter Settings → Endpoints → Advanced features die Funktion Microsoft Intune connection aktivieren.

Die „Microsoft Intune connection" im Defender-Portal aktivieren.

Dann im Endpoint-Manager-Admin-Center iOS-Geräte für den Compliance-Datenaustausch zulassen:

1. Endpoint-Manager-Admin-Center öffnen.
2. Zu Endpoint Security → Microsoft Defender for Endpoint navigieren.
3. Connect iOS devices to Microsoft Defender for Endpoint auf On stellen.

Der Schalter „Connect iOS devices to Microsoft Defender for Endpoint" auf „On".

Die App aus dem App Store hinzufügen:

• Zu Apps → iOS/iPadOS → Add → iOS store app und Select klicken.
• Nach Microsoft Defender suchen.

Die Microsoft-Defender-App wird im App Store gesucht und hinzugefügt.

• Als minimales Betriebssystem iOS 14.0 wählen (darunter wird die App nicht installiert).

Als minimales Betriebssystem wird „iOS 14.0" gewählt.

• Die App als required app an die passende Benutzergruppe verteilen – zunächst an einige Testnutzer.

Supervised Mode

Der Supervised Mode gibt mehr Kontrolle über firmeneigene Geräte und schaltet zusätzliche Konfigurationen frei (z. B. Locate device, Lost Mode). Standardmäßig sind Geräte nicht supervised; auf dem Lock Screen eines supervised Geräts steht „This iPhone is managed by …". Der große Vorteil: Für supervised Geräte wird kein VPN-Profil installiert – der Web-Schutz läuft über das importierte Control-Filter-Profil (VPN-less). Dieser VPN-less-Ansatz ist nur im Supervised-Zustand verfügbar.

App-Configuration-Policy für Supervised Mode:

• Zu Apps → App configuration policies → Add, Managed devices wählen.
• Namen vergeben, Plattform iOS/iPadOS, als App die Microsoft Defender for Endpoint-App.
• Im Configuration Designer den issupervised-Schlüssel setzen:

Zero-Touch-Profil für supervised Geräte: Ein Custom-.mobileconfig-Profil konfiguriert die Web-Protection nahtlos, ohne lokale Einrichtung. Microsoft stellt dafür ein Control-Filter-Zerotouch-Profil bereit. Für supervised Geräte ist kein lokales/self-looping VPN nötig – der Control Filter enthält die lokale Web-Filter-Policy.

Das Custom-.mobileconfig-Profil richtet die Web-Protection für supervised Geräte zero-touch ein.

Unsupervised Mode (Zero-Touch mit VPN-Profil)

Unsupervised ist der Standard. Auch hier ist ein Zero-Touch-Onboarding möglich (für mit Benutzerkonto registrierte Geräte), bei dem der Nutzer nur über Installation und Aktivierung des Web-Schutzes informiert wird. Wichtig: Das MDE-VPN-Profil ist kein regulärer VPN-Tunnel, sondern rein local/self-looping – es entsteht kein ausgehender Traffic. Für unsupervised Geräte muss das VPN-Profil bereitgestellt werden; für supervised Geräte nicht.

Custom-VPN-Profil anlegen:

1. Endpoint-Manager-Admin-Center öffnen.
2. Zu Devices → Configuration Profiles → Create profile navigieren.
3. Plattform iOS/iPadOS, Profiltyp VPN wählen.
4. Namen vergeben.
5. Custom VPN konfigurieren.

Ein Custom-VPN-Profil wird für unsupervised iOS-Geräte angelegt.

Base-VPN-Einstellungen:

• Connection Name = Microsoft Defender for Endpoint
• VPN server address = 127.0.0.1
• Auth method = Username and password
• Split Tunneling = Disable
• VPN identifier = com.microsoft.scmx
• Key-Value: SilentOnboard = True
• Key-Value: SingleSignOn = True

Die konfigurierten Base-VPN-Einstellungen (Server 127.0.0.1, VPN identifier com.microsoft.scmx, SilentOnboard).

Automatic-VPN-Einstellungen:

• Type of Automatic VPN = On-demand VPN
• On-demand rules: Connect VPN für alle Domains

Die Automatic-VPN-Einstellungen: On-demand VPN mit „Connect VPN" für alle Domains.

Optional lässt sich block users from disabling automatic VPN auf Yes setzen. Standardmäßig wird das VPN nach dem Deaktivieren ohnehin binnen Sekunden wieder aktiviert. Beim Zero-Touch-Profil werden alle Einstellungen automatisch erzwungen; die Geräte werden ohne Nutzeraktion onboardet und der Nutzer erhält nach der Installation eine Benachrichtigung. Über App-Configuration-Policies lässt sich der Web-/Network-Protection-Schutz bei Bedarf auch deaktivieren.

Network Protection konfigurieren

Network Protection ist auf iOS standardmäßig deaktiviert und wird über App-Configuration-Policies aktiviert:

1. Endpoint-Manager-Admin-Center öffnen.
2. Zu Apps → App configuration policies → Add → Managed devices navigieren.
3. Plattform iOS/iPadOS wählen.
4. Als Ziel-App Microsoft Defender for Endpoint wählen.

Im Configuration Designer:

Network Protection wird über den Schlüssel DefenderNetworkProtectionEnable = true aktiviert.

Zur Feinabstimmung stehen weitere Schlüssel bereit: DefenderOpenNetworkDetection, DefenderEndUserTrustFlowEnable, DefenderNetworkProtectionAutoRemediation und DefenderNetworkProtectionPrivacy.

App-Inventar und Vulnerability Assessment

Schwachstellenbewertungen für Apps stehen aktuell für enrollte (MDM)-Geräte zur Verfügung und sind standardmäßig nicht aktiv. Nach der Konfiguration dauert die Datenverarbeitung bis zu 24 Stunden.

• Supervised: Unter Endpoint Security → Microsoft Defender for Endpoint die Funktion Enable App sync for iOS/iPadOS devices aktivieren.
• Unsupervised: Enable App Sync (sending application inventory) for iOS/iPadOS devices aktivieren und optional Send full application inventory data on personally owned iOS/iPadOS devices (damit lassen sich auch nicht über Intune verteilte Apps erfassen – abhängig von der Datenschutz-Policy der Organisation).

Die App-Synchronisierung liefert das App-Inventar für die Schwachstellenbewertung.

Compliance-Policy und Ergebnis prüfen

Bei konfiguriertem Intune lässt sich eine Device-Compliance-Policy nutzen: Überschreitet ein iOS-Gerät ein bestimmtes Risikoniveau, kann es als non-compliant markiert werden, was über Conditional Access weitere Maßnahmen auslöst. Erforderlich ist die Einstellung Connect iOS/iPadOS devices version 13.0 and above to Microsoft Defender for Endpoint; danach fließt der Device Risk Score in die Compliance-Bewertung ein (z. B. require the device to be at or under the medium machine risk score).

Für die Compliance-Bewertung wird „Connect iOS/iPadOS devices version 13.0 and above" benötigt.

Der Device Risk Score fließt in die Compliance-Bewertung ein – hier: maximal „medium".

Sind alle Policies und die App korrekt verteilt, ist das Gerät im Defender-Portal sichtbar. Der Onboarding-Status sollte Onboarded lauten (nicht Can be onboarded). Zum Testen des Web-Schutzes eignet sich die SmartScreen-Demo-Site smartscreentestratings2.net – MDE erzeugt dann den Alert „Device tried to access a phishing site".

Der SmartScreen-Test löst in MDE den Alert „Device tried to access a phishing site" aus.

Lokal auf dem iPhone sind der Defender-Startbildschirm, geblockte Websites und die VPN-Konfiguration sichtbar:

Der Startbildschirm der Defender-for-Endpoint-App auf dem iPhone.

Eine per Indikator geblockte Website – abgefangen durch Defender for Endpoint.

Die lokale Einstellungsübersicht mit der VPN-Konfiguration.

Im Portal stehen Geräte-, Timeline- und Vulnerability-Ansicht bereit:

Portal-Ansicht: das onboardete iOS-Gerät.

Portal-Ansicht: Timeline des Geräts.

Portal-Ansicht: Schwachstellen (Vulnerabilities) des Geräts.

Nächster Teil der Serie: AV-Konfiguration.