Folgendes Problem aus der Praxis: In meinen Intune- und Defender-Kursen taucht regelmäßig dieselbe Frage auf – und sie ist berechtigt. Ein Gerät gilt im Microsoft Endpoint Manager (heute: Microsoft Intune Admin Center) als compliant, zeigt aber im Microsoft Defender-Portal gleichzeitig einen aktiven Alert. Wie kann das sein? Die Antwort liegt im Zusammenspiel zweier Steuerungsebenen, die scheinbar dasselbe Ziel verfolgen, aber unterschiedliche Verantwortungsbereiche haben. Wer das nicht durchdringt, baut ein Sicherheitskonzept auf Sand.
Zwei Systeme, eine Aufgabe – aber unterschiedliche Rollen
Microsoft Intune und Microsoft Defender for Endpoint (MDE) sind keine Konkurrenten, sondern konzeptionell aufeinander abgestimmt. Trotzdem überlappen sich ihre Zuständigkeiten an mehreren Stellen – und genau dort entstehen Konflikte.
Intune ist primär ein Mobile Device Management (MDM)– und Mobile Application Management (MAM)-System. Es verwaltet Geräte, stellt Konfigurationsprofile bereit und bewertet die Compliance (Regelkonformität) von Endgeräten anhand definierter Richtlinien. Intune kennt per se keinen Bedrohungsstatus – es sei denn, es wird aktiv mit einem Mobile Threat Defense-Partner (MTD) gekoppelt.
Microsoft Defender for Endpoint ist eine EDR-Plattform (Endpoint Detection and Response). MDE erkennt Bedrohungen, klassifiziert Geräte nach Risikoniveau und kann über die MDE-Connector-Integration in Intune diesen Risikowert als Compliance-Kriterium einbringen.
Genau hier liegt der Schlüssel: Intune fragt MDE nicht automatisch ab. Die Integration muss explizit aktiviert und konfiguriert werden. Wer das versäumt, hat zwei parallel laufende Systeme – ohne gemeinsamen Sicherheitszustand.
Der MDE-Connector im Intune Admin Center: Erst wenn dieser aktiv ist, fließt das Geräterisiko aus Defender in die Intune-Compliance-Bewertung ein.
Richtlinienebenen und Vorrangregelungen im Detail
Sobald beide Systeme verbunden sind, gibt es mehrere Richtlinienebenen, die ineinandergreifen. Das folgende Schaubild zeigt, welche Ebene wann greift:
| Richtlinienebene | Verwaltungsort | Wirkungsbereich | Vorrang bei Konflikt |
|---|---|---|---|
| MDE Security-Konfiguration (Security Settings Management) | Defender-Portal (security.microsoft.com) | Antivirus, ASR-Regeln, Firewall – direkt auf dem Gerät | Höchster Vorrang wenn Gerät im MDE-only-Management |
| Intune Endpunktsicherheits-Richtlinien | Intune Admin Center | Antivirus, Firewall, EDR-Onboarding, Angriffsflächen-Reduzierung | Vorrang gegenüber Konfigurationsprofilen bei gleicher Einstellung |
| Intune Geräte-Konfigurationsprofile | Intune Admin Center | Defender-Einstellungen via OMA-URI oder Settings Catalog | Niedrigster Vorrang; wird bei Konflikt von Endpunktsicherheits-Richtlinien überschrieben |
| Compliance-Richtlinien mit MDE-Risikowert | Intune Admin Center | Compliance-Status des Geräts (genutzt für Conditional Access) | Eigenständige Ebene; kein direkter Konflikt mit Konfigurationsrichtlinien |
| Gruppenrichtlinien (GPO) | Active Directory / lokale Richtlinie | Defender-Einstellungen via Registry | Kann MDM-Richtlinien überschreiben, wenn kein MDM-Win gesetzt |
Merksatz: Intune Endpunktsicherheits-Richtlinien haben gegenüber normalen Gerätekonfigurationsprofilen Vorrang – aber nur dann, wenn beide dieselbe Einstellung adressieren. Konfigurieren Sie dieselbe Einstellung in beiden Richtlinientypen, gewinnt die Endpunktsicherheits-Richtlinie. Statt eines Fehlers sehen Sie im Reporting allerdings oft nur „Conflict“ – ohne weiteren Hinweis auf die Ursache.
Besonders heikel ist das Zusammenspiel mit Gruppenrichtlinien (GPO). Wird ein Gerät hybrid-joined betrieben (Azure AD Join + Active Directory), können GPO-Einstellungen MDM-Richtlinien aushebeln, sofern der Registry-Schlüssel MDMWinsOverGP nicht gesetzt ist. Das ist ein klassischer Stolperstein, der in meinen Azure-Kursen regelmäßig für Aha-Momente sorgt.
Ohne diesen Registry-Eintrag gewinnen GPOs im Zweifelsfall gegen Intune-MDM-Richtlinien – auch wenn Intune „Applied“ meldet.
Konflikte erkennen, analysieren und beheben
Das Intune Admin Center zeigt Richtlinienkonflikte auf Geräteebene unter Geräte → Konfigurationsrichtlinien → [Richtlinie] → Gerätestatus. Dort erscheint der Status „Conflict“ ohne Detailangabe. Für die Ursachenanalyse brauchen Sie das Settings Catalog Reporting oder – bei komplexeren Szenarien – den Microsoft Intune Troubleshooting-Bereich im Admin Center.
Folgende Schritte haben sich in der Praxis bewährt:
- Gerät im Admin Center öffnen → Richtlinienstatus aufrufen → alle Richtlinien mit Status „Conflict“ identifizieren.
- Einstellungen der konfliktierenden Richtlinien nebeneinander vergleichen (Settings Catalog erleichtert das erheblich gegenüber OMA-URI-Profilen).
- Entscheiden, welche Richtlinie „Herr“ der jeweiligen Einstellung sein soll – dann die andere Einstellung entfernen oder deaktivieren.
- Bei GPO-Beteiligung:
MDMWinsOverGPprüfen und ggf. per GPO selbst setzen (ja, das ist keine Ironie – GPO kann MDM den Vorrang geben). - MDE Security Settings Management (SSM) prüfen: Falls das Gerät im Defender-Portal direkt über SSM verwaltet wird, überschreibt das bestimmte Intune-Einstellungen ohne Rückmeldung in Intune.
Praxistipp: Nutzen Sie das Settings Catalog statt älterer OMA-URI-Profile, wo immer möglich. Das Catalog-Format zeigt Konflikte deutlich transparenter im Reporting und erlaubt eine einstellungsscharfe Analyse.
Das Settings Catalog-Reporting zeigt pro Einstellung, welche Richtlinien sich widersprechen – deutlich hilfreicher als der pauschale „Conflict“-Status älterer Profiltypen.
Praxisempfehlung: KMU-taugliche Grundstruktur
Noch mal in Kürze – kurz, knapp und strukturiert, zum Abharken:
Für kleinere und mittlere Unternehmen, die Intune und MDE gemeinsam einsetzen, empfehle ich folgende Grundstruktur:
| Aufgabe | Empfohlene Richtlinienart | Verwaltungsort |
|---|---|---|
| Antivirus-Konfiguration (Defender AV) | Endpunktsicherheits-Richtlinie: Antivirus | Intune Admin Center |
| Firewall-Regeln | Endpunktsicherheits-Richtlinie: Firewall | Intune Admin Center |
| MDE-Onboarding | Endpunktsicherheits-Richtlinie: EDR | Intune Admin Center |
| Geräterisiko als Compliance-Kriterium | Compliance-Richtlinie mit MDE-Connector | Intune Admin Center |
| Zugriffssperre bei Non-Compliance | Conditional Access (Bedingter Zugriff) | Microsoft Entra ID (ehem. Azure AD) |
| ASR-Regeln (Attack Surface Reduction) | Endpunktsicherheits-Richtlinie: Angriffsflächen-Reduzierung | Intune Admin Center – nicht GPO |
Das Prinzip lautet: eine Einstellung, eine Richtlinie, ein Verwaltungsort. Dopplungen zwischen Konfigurationsprofilen, Endpunktsicherheits-Richtlinien und GPOs sind die häufigste Quelle für „Conflict“-Einträge, die niemand wirklich erklären kann.
Wer das Zusammenspiel zwischen Intune, MDE und Conditional Access nicht nur in der Theorie verstehen, sondern in der Praxis sicher anwenden möchte, findet in meinen Azure-Kursen entsprechende Lab-Szenarien – inklusive bewusst herbeigeführter Konflikte und deren systematischer Auflösung. Denn nur wer Fehler im Labor macht, macht sie nicht in der Produktion.