Sektion 29: Policy Conflict Resolution: Wer gewinnt bei Widersprüchen?

Einleitung

In einer idealen IT-Welt würde jede Richtlinie genau das tun, was sie soll, und jede Einstellung wäre eindeutig. Die Realität in komplexen Enterprise-Umgebungen sieht jedoch anders aus. Je länger ein Intune-Tenant besteht, desto mehr Schichten an Konfigurationen legen sich über die Geräte. Wir haben Device Configuration Profile, Settings Catalog, Administrative Templates, Compliance Policies und vielleicht sogar noch alte Group Policy Objects (GPOs) aus einer hybriden Welt.

Was passiert, wenn eine Richtlinie sagt: „USB-Speicher sind verboten“, aber eine andere (vielleicht für eine spezielle User-Gruppe) sagt: „USB-Speicher sind erlaubt“? Wer gewinnt diesen Kampf? Wenn Sie diese Frage nicht mit absoluter Sicherheit beantworten können, riskieren Sie nicht nur inkonsistente User-Experiences, sondern auch kritische Sicherheitslücken, die durch unbemerkte Konflikte entstehen.

Diese Masterclass widmet sich der Policy Conflict Resolution. Wir analysieren die internen Entscheidungsmechanismen von Microsoft Intune und dem Windows MDM-Agenten. Wir lernen, wie Konflikte entstehen, wie man sie im Intune-Portal identifiziert und wie man eine Architektur aufbaut, die Konflikte von vornherein minimiert.

Grundkonzepte: Die Hierarchie der Entscheidung

Um zu verstehen, wer gewinnt, müssen wir zuerst verstehen, wie Intune-Richtlinien auf das Gerät gelangen. Intune ist im Grunde ein Orchestrator, der Konfigurationen an den MDM-Agenten (Mobility Management) auf dem Endgerät sendet. Der Agent wendet diese Einstellungen im Windows Registry oder über CSPs (Configuration Service Providers) an.

1. Der Unterschied zwischen „Konflikt“ und „Überschreibung“

Ein häufiges Missverständnis ist die Gleichsetzung von Konflikten mit einfachen Änderungen. In Intune gibt es zwei grundlegend verschiedene Szenarien:

• Die Überschreibung (Overwrite): Wenn zwei verschiedene Einstellungen denselben Registry-Key ändern, aber über unterschiedliche Mechanismen (z.B. einmal via Settings Catalog und einmal via Custom OMA-URI), gewinnt oft die Einstellung, die zuletzt vom System verarbeitet wurde oder die „spezifischere“ ist. Das ist technisch gesehen kein „Intune-Konflikt“, sondern ein Betriebssystem-Verhalten.
• Der Intune-Konflikt (Conflict): Ein echter Intune-Konflikt tritt auf, wenn ein Gerät zwei oder mehr Configuration Profiles zugewiesen ist, die denselben CSP-Setting mit unterschiedlichen Werten konfigurieren. In diesem Fall meldet Intune im Dashboard explizit den Status „Conflict“.

2. Die goldene Regel: Der sicherste Wert gewinnt

Bei klassischen Intune-Konfigurationsprofilen folgt Microsoft einem Sicherheitsprinzip: Wenn zwei Richtlinien kollidieren, gewinnt im Zweifelsfall die restriktivere Einstellung.

Beispiel:

• Richtlinie A: Kamera deaktivieren = Nein (Erlaubt)
• Richtlinie B: Kamera deaktivieren = Ja (Verboten)

In diesem Szenario wird die Kamera deaktiviert, da dies die sicherere Option für das Unternehmen ist. Dies gilt jedoch primär für einfache Boolean-Werte (True/False). Bei komplexeren Einstellungen (z.B. einer Liste von erlaubten Anwendungen) kann das Ergebnis variieren, was oft dazu führt, dass die Einstellung als „Conflict“ markiert wird und gar nicht erst angewendet wird, bis der Administrator eingreift.

3. CSP (Configuration Service Providers) als Wahrheitsebene

Alles, was wir im Intune-Portal klicken, wird in eine CSP-Anfrage übersetzt. Ein CSP ist eine Schnittstelle im Windows-OS, die Intune sagt: „Setze den Wert X in Pfad Y“. Wenn zwei Profile versuchen, den Pfad ./Device/Vendor/MSFT/Policy/Config/AllowBluetooth gleichzeitig zu beschreiben, erkennt der MDM-Agent den Widerspruch.

Praxis-Implementierung: Konflikte in der Realität

Schauen wir uns an, wie Konflikte in verschiedenen Szenarien entstehen und wie das System reagiert.

Szenario A: Settings Catalog vs. Administrative Templates

Viele Administratoren nutzen sowohl den neuen Settings Catalog als auch die klassischen ADMX-Templates. Da beide oft auf dieselben CSPs zugreifen, ist das Konfliktpotenzial riesig.

Wenn Sie im Settings Catalog festlegen, dass der Bildschirmschoner nach 10 Minuten startet, und in einem Admin Template sagen, es sollen 15 Minuten sein, wird das Gerät einen Konflikt melden. Da beide Profile die gleiche Prioritätsstufe haben, kann das OS nicht entscheiden. Das Ergebnis: Keine der beiden Einstellungen wird angewendet, und im Intune-Portal erscheint der Status „Conflict“.

Szenario B: User-Profil vs. Device-Profil

Dies ist eine der wichtigsten Unterscheidungen in der Intune-Architektur.

• Device-assigned: Die Richtlinie gilt für das Gerät, egal wer angemeldet ist.
• User-assigned: Die Richtlinie gilt für den Benutzer, egal an welchem Gerät er sitzt.

Was passiert, wenn ein Gerät-Profil „A“ sagt und das User-Profil „B“?
Regel: Device-Einstellungen überschreiben in der Regel User-Einstellungen.
Das ist logisch: Wenn die Firma entscheidet, dass ein Gerät aus Sicherheitsgründen keine USB-Sticks darf (Device-Policy), darf ein einzelner Benutzer dies nicht über seine User-Policy wieder erlauben.

Szenario C: MDM vs. GPO (The Hybrid Nightmare)

In hybriden Umgebungen kämpfen Intune und die lokale Active Directory Group Policy um die Vorherrschaft. Standardmäßig gewinnt die GPO, da sie lokal auf dem Client verarbeitet wird und die Registry-Keys überschreibt.

Um dies zu lösen, gibt es das Feature Control Policy Conflict (MDM wins over GPO). Dies wird über eine spezifische CSP-Einstellung gesteuert:

./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP = 1

Wenn dieser Wert gesetzt ist, ignoriert Windows die entsprechende GPO-Einstellung, falls Intune eine widersprüchliche Konfiguration sendet.

Best Practices zur Vermeidung von Konflikten

Die beste Art, Konflikte zu lösen, ist, sie gar nicht erst entstehen zu lassen. Ein „Trial-and-Error“-Ansatz führt in Enterprise-Umgebungen schnell zum Chaos.

1. Die „Single Source of Truth“-Strategie

Entscheiden Sie sich für einen Weg, um Einstellungen zu konfigurieren. Wenn Sie den Settings Catalog nutzen können, nutzen Sie ihn konsequent. Mischen Sie nicht willkürlich Administrative Templates, Settings Catalog und Custom OMA-URIs für dieselben Funktionsbereiche.

2. Nutzung von Filter statt Gruppen-Überlappung

Ein klassischer Fehler ist die Zuweisung von Profilen an mehrere Azure AD Gruppen, die sich überschneiden.

• Gruppe „Alle Mitarbeiter“ bekommt Profil A.
• Gruppe „Marketing“ bekommt Profil B.
• Der Marketing-Mitarbeiter ist in beiden Gruppen und erhält beide Profile.

Lösung: Intune Filters. Nutzen Sie Filter, um Richtlinien präzise zuzuweisen. Anstatt zwei Gruppen zu erstellen, weisen Sie ein Profil an „Alle Geräte“ zu, aber setzen Sie einen Filter, der besagt: „Wende dies nur an, wenn Gerät.Department NICHT ‚Marketing‘ ist“.

3. Hierarchisches Design (Baselines)

Bauen Sie Ihre Richtlinien wie eine Pyramide auf:

• Level 1: Global Baseline. Ein einziges Profil für alle Geräte mit den absolut notwendigen Sicherheitsstandards (z.B. Verschlüsselung, Passwortrichtlinien).
• Level 2: Rollen-spezifische Profile. Zusätzliche Einstellungen für Entwickler, HR oder Management.
• Level 3: Ausnahme-Profile. Hochspezifische Richtlinien für einzelne Geräte oder User.

Achten Sie darauf, dass Level 2 und 3 niemals dieselben Einstellungen wie Level 1 konfigurieren, sondern diese nur ergänzen.

Troubleshooting: So finden und fixen Sie Konflikte

Schritt 1: Das Intune Portal nutzen

Navigieren Sie zu Devices -> Configuration profiles. Suchen Sie in der Spalte „Device status“ nach dem Status Conflict. Klicken Sie auf das Gerät, um zu sehen, welche spezifischen Einstellungen kollidieren. Intune zeigt Ihnen dort genau an: „Profil A will Wert X, Profil B will Wert Y“.

Schritt 2: Lokale Analyse via MDM Diagnostics

Wenn das Portal nicht präzise genug ist, müssen Sie auf das Gerät. Windows bietet ein mächtiges Tool für MDM-Analysen. Führen Sie folgenden Befehl in einer administrativen PowerShell aus:

Get-Diagnostics -Type MDMDiagnostics

Dies erstellt eine HTML-Datei und Log-Files. In den Logs können Sie nach Conflict oder dem spezifischen CSP-Pfad suchen, um zu sehen, welche Richtlinie zuletzt den „Sieg“ davongetragen hat oder warum der Agent die Anwendung abgebrochen hat.

Schritt 3: Registry-Check

Die endgültige Wahrheit liegt in der Registry. Die meisten Intune-Einstellungen landen unter:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device

Wenn Sie dort einen Wert finden, der nicht mit Ihren Erwartungen übereinstimmt, prüfen Sie, ob ein lokaler Administrator oder eine GPO den Wert manuell überschrieben hat.

Beispiel für eine Konflikt-Analyse in JSON (Simulation des Intune-Reports)

Stellen Sie sich vor, Intune würde den Konflikt intern so analysieren:

{

  "Setting": "AllowBluetooth",

  "Status": "Conflict",

  "ConflictingProfiles": [

    {

      "ProfileName": "Global_Security_Baseline",

      "Value": "0",

      "Priority": "Device",

      "Assignment": "AllDevices"

    },

    {

      "ProfileName": "Developer_Special_Access",

      "Value": "1",

      "Priority": "User",

      "Assignment": "Group_Devs"

    }

  ],

  "ResolvedValue": "0",

  "ResolutionReason": "Security_Restrictive_Wins"

}


Fazit
Policy Conflict Resolution in Intune ist kein Zufallsprodukt, sondern folgt einer strikten Logik. Die wichtigsten Take-aways für Ihren Alltag als Intune-Administrator sind:

Sicherheit gewinnt: Bei Boolean-Werten setzt Intune im Konfliktfall auf die restriktivere Option.
Device schlägt User: Gerätebezogene Richtlinien haben Vorrang vor benutzerbezogenen.
Konflikt bedeutet Stillstand: Wenn zwei gleichwertige Profile (z.B. beide Settings Catalog) kollidieren, wird oft gar nichts angewendet.
Prävention vor Heilung: Nutzen Sie Filter und eine klare Baseline-Hierarchie, anstatt zu versuchen, Konflikte nachträglich durch "mehr Richtlinien" zu lösen.

Ein sauberer Tenant ist kein Ergebnis von Glück, sondern von Disziplin in der Benennung und Zuweisung. Wenn Sie die Hierarchie beherrschen, beherrschen Sie die Kontrolle über Ihre Endgeräte.