Intune Scope Tags: Delegation ohne falsches Sicherheitsgefühl
Im letzten Beitrag zu Administrative Units in Entra ID steckt eine kleine Gemeinheit: Geräte können zwar Mitglied einer Administrative Unit sein, aber Intune-Gerätemanagement lässt sich damit aktuell nicht sauber regional begrenzen.
Wenn du also Local IT Germany erlauben willst, deutsche Windows-Geräte in Intune zu betreuen, hilft dir die schönste Entra-AU nur bedingt weiter. Für Intune brauchst du Intune RBAC.
Und damit landest du bei Scope Tags.
Scope Tags gehören zu den Funktionen, die viele Tenants irgendwo konfiguriert haben, aber selten als Designentscheidung behandeln. Man legt Germany, France, HQ oder Retail an, hängt die Tags an ein paar Profile und hofft, dass daraus Delegation wird.
Meistens funktioniert das sogar eine Weile.
Bis das erste Local-IT-Team ein globales Profil sieht. Oder eine App bearbeitet, die plötzlich Geräte in drei Ländern betrifft. Oder ein Admin über mehrere Role Assignments mehr darf, als das Rollenmodell hergeben sollte.
Dann merkt man ziemlich schnell: Scope Tags sind kein kosmetisches Label. Sie filtern Sichtbarkeit und Verwaltung in Intune RBAC.
Drei Dinge, die man auseinanderhalten muss
Intune RBAC besteht in der Praxis aus drei Bausteinen, die gerne vermischt werden.
Die Rolle entscheidet, was ein Admin tun darf. Also lesen, erstellen, ändern, löschen, remote actions ausführen oder Apps verwalten.
Scope Groups entscheiden, für wen dieser Admin diese Berechtigungen nutzen darf. Das sind die Benutzer- oder Gerätegruppen, die in der Role Assignment als verwaltbarer Bereich hinterlegt werden.
Scope Tags entscheiden, welche Intune-Objekte der Admin sehen und verwalten kann. Dazu gehören zum Beispiel Apps, Konfigurationsprofile, Compliance Policies, Enrollment-Objekte oder Geräte, sofern der jeweilige Objekttyp Scope Tags unterstützt.
Wenn man diese drei Dinge sauber trennt, wird Intune RBAC deutlich weniger mystisch.
Ein Admin kann die richtige Rolle haben und trotzdem das falsche Objekt sehen. Ein Admin kann das richtige Scope Tag haben und trotzdem keine Geräte im Scope haben. Ein Admin kann Geräte im Scope haben und trotzdem keine passende Berechtigung für die Aktion besitzen.
Das klingt pedantisch, spart aber in großen Tenants erstaunlich viel Chaos.
Scope Tags sind Sichtbarkeit mit Konsequenzen
Microsoft beschreibt Scope Tags relativ nüchtern: Sie bestimmen, welche Intune-Objekte ein Admin sehen kann.
Das Wort "sehen" klingt harmlos. In der Praxis entscheidet Sichtbarkeit aber oft über Änderbarkeit. Wenn ein Admin ein Objekt nicht sieht, kann er es nicht in der Konsole bearbeiten. Wenn er es sieht und seine Rolle Update-Rechte hat, wird es interessant.
Genau deshalb sind Scope Tags keine Deko.
Nimm ein Beispiel: Local IT Germany soll deutsche WLAN-Profile und deutsche Apps verwalten. Dann brauchen diese Objekte das Scope Tag Germany. Das lokale Team bekommt eine Role Assignment mit diesem Scope Tag und einer Scope Group, die deutsche Benutzer oder Geräte enthält.
Das Team sieht dann nicht automatisch französische Profile. Es sieht auch nicht automatisch globale Security Baselines, wenn diese nur Global tragen.
Das ist der gewünschte Zustand.
Der unangenehme Zustand entsteht, wenn globale Objekte falsch getaggt werden oder gar kein Tag-Konzept existiert. Dann wachsen lokale und globale Verantwortung ineinander. Irgendwann weiß niemand mehr, ob Windows 11 Baseline Final v3 wirklich final lokal angepasst werden darf oder tenantweit produktiv hängt.
Der Fehler liegt dann im Betriebsmodell. Intune zeigt ihn nur mit hübscher Oberfläche an.
Das Default Scope Tag ist kein Papierkorb
Intune hängt das Default Scope Tag automatisch an ungetaggte Objekte, sofern der Objekttyp Scope Tags unterstützt.
Das ist praktisch, damit Objekte nicht komplett aus dem RBAC-Modell fallen. Es führt aber schnell zu einem schlechten Muster: Alles, was niemand bewusst einsortiert, landet im Default-Bereich.
In kleinen Tenants fällt das kaum auf. In großen Tenants wird Default dann zum Sammelbecken für Altlasten, globale Policies, Testprofile und Dinge, deren Besitzer längst nicht mehr klar ist.
Ich würde Default deshalb wie einen Übergangsbereich behandeln, nicht wie ein Zielmodell.
Ein gesundes Modell erkennt man daran, dass produktive Objekte bewusst getaggt sind. Global für tenantweite Plattformobjekte. Germany, France oder Retail für lokale Verantwortung. Vielleicht Pilot für technische Testobjekte, sofern klar ist, wer diese Objekte verwalten darf.
Der Name ist weniger wichtig als die Disziplin dahinter.
Scope Tags schützen nicht vor schlechtem Assignment-Design
Ein häufiger Denkfehler: "Das Profil hat ja nur das Germany Scope Tag, also kann es auch nur Germany betreffen."
Das Profil kann trotzdem breiter wirken.
Scope Tags steuern, wer das Profil sieht und verwaltet. Die Assignment des Profils steuert, welche Benutzer oder Geräte es bekommen.
Ein lokal sichtbares Profil kann immer noch auf eine zu breite Gruppe assigned sein, wenn der Admin dazu berechtigt ist. Microsoft weist in der RBAC-Dokumentation explizit darauf hin, dass Admins nur Gruppen targeten können, die in ihren Scope Groups liegen. Das hilft. Trotzdem muss das Design sauber bleiben, weil Include- und Exclude-Gruppen, dynamische Gruppen und globale Baseline-Modelle sonst schnell unübersichtlich werden.
Die wichtigste praktische Regel lautet für mich:
Ein Scope Tag beschreibt Ownership. Eine Assignment beschreibt Wirkung.
Wenn Ownership und Wirkung auseinanderlaufen, sollte jemand bewusst entschieden haben, warum.
Ein globales Security-Profil kann zum Beispiel Global tragen und auf alle Geräte wirken. Local IT Germany soll dieses Profil vielleicht sehen, aber nicht ändern. Dafür braucht man eine passende Rollenverteilung: globales Team mit Update-Rechten, lokale Teams maximal mit Read-Rechten oder separaten lokalen Ergänzungsprofilen.
Mehrere Role Assignments machen es fies
Intune RBAC wird besonders unangenehm, wenn ein Admin über mehrere Gruppen mehrere Role Assignments bekommt.
Microsoft beschreibt für das bisherige Standardverhalten, dass Intune Berechtigungen über Role Assignments hinweg zusammenführen kann, wenn dieselbe Berechtigungskategorie betroffen ist. Das kann dazu führen, dass ein Admin in einem Scope mehr darf, als man beim Blick auf die einzelne Role Assignment erwartet.
Ein Beispiel:
Ein Team bekommt für Headquarters nur Read-Rechte auf Apps. Dasselbe Team bekommt für Regional volle App-Rechte. Im Standardverhalten können sich diese Rechte über die App-Kategorie so vermischen, dass aus Read an einer Stelle plötzlich breitere Rechte werden.
Seit März 2026 gibt es dafür in Intune eine neue opt-in Preview für Scoped permissions. Damit bleiben Berechtigungen stärker an den jeweiligen Scope-Tag-Kontext gebunden. Microsoft stellt dafür einen Permissions Assessment Report bereit, bevor man die Umstellung aktiviert.
Dieses Verhalten gehört in jede RBAC-Review.
Wenn dein Tenant viele lokale Admin-Gruppen, regionale Teams und Sonderrollen hat, solltest du dieses Verhalten prüfen, bevor du dein RBAC-Modell als "fertig" bezeichnest. Der Bericht zeigt, wo sich Rechte heute breiter auswirken und was nach der Umstellung enger greifen würde.
Der Haken: Microsoft beschreibt die Aktivierung als One-Way-Action. Man schaltet das nicht an, weil es an einem Dienstag gut klingt.
Ein sauberes Modell sieht unspektakulär aus
Ich mag bei Intune Scope Tags keine komplizierten Tag-Taxonomien.
Sobald ein Objekt fünf Tags braucht, damit irgendjemand seine Ownership versteht, hat das Modell wahrscheinlich schon verloren.
Ein tragfähiges Enterprise-Modell kann erstaunlich schlicht aussehen:
| Ebene | Scope Tag | Typische Owner | Gedanke dahinter |
|---|---|---|---|
| Tenantweit | Global | Endpoint Platform Team | Security Baselines, zentrale Compliance, Standard Apps |
| Regional | Germany, France, UK | Regional IT | lokale WLANs, VPNs, Drucker, Länder-Apps |
| Betrieblich | Retail, Production | Fachnaher Betrieb | Gerätetypen mit eigener Betriebslogik |
| Test | Pilot | Engineering oder Plattform | kontrollierte Tests ohne Vermischung mit Produktion |
Der wichtige Teil liegt nicht in den Namen. Der wichtige Teil liegt in der Frage, wer ein Objekt später ändern darf.
Globale Objekte brauchen globale Ownership. Lokale Objekte brauchen lokale Ownership. Mischobjekte brauchen eine bewusste Entscheidung, sonst werden sie später zu Betriebsschulden.
Scope Tags passen nicht auf alles
Microsoft unterstützt Scope Tags für viele Intune-Objekttypen, aber nicht für alles.
Ein paar Ausnahmen sind besonders relevant: Windows Autopilot Devices, Corp Device Identifiers, Device Compliance Locations und Jamf Devices unterstützen laut Microsoft aktuell keine Scope Tags.
Gerade Autopilot überrascht viele.
Du kannst Autopilot-Geräte wunderbar über Group Tags, dynamische Gruppen und Zuweisungslogik sortieren. Aber du solltest nicht erwarten, dass Scope Tags direkt auf das Autopilot-Device-Objekt denselben Delegationskomfort bringen wie bei vielen anderen Intune-Objekten.
Das ist einer dieser Punkte, die man lieber vor dem Design merkt als nach dem Rollout.
Entra-Rollen hebeln dein schönes Modell aus
Scope Tags greifen im Intune-RBAC-Kontext.
Microsoft Entra Rollen mit Intune-Zugriff sind eine andere Nummer. Der Intune Administrator, in Graph und PowerShell oft als Intune Service Administrator sichtbar, hat laut Microsoft vollen administrativen Zugriff auf Intune, unabhängig davon, welche Scope Tags irgendwo im Intune-Rollenmodell hängen.
Global Administrator ist noch breiter.
Wenn du Local IT über Scope Tags sauber begrenzt, aber gleichzeitig großzügig Entra-Rollen mit Intune-Zugriff verteilst, hast du zwei Delegationsmodelle. Das breitere gewinnt im Zweifel.
Für den Alltag gehören Admins in Intune Built-in Roles oder Custom Roles. Entra-Privileged-Roles sollten Ausnahmefälle bleiben, idealerweise zeitgebunden über PIM.
Das nervt beim Einrichten, reduziert aber die Zahl der Admins mit Tenant-Freiflug.
Wie ich Scope Tags ausrollen würde
Ich würde bei einem bestehenden Tenant nicht zuerst Tags anlegen.
Ich würde mir zuerst die Intune-Objekte ansehen, die heute produktiv wirken: Compliance Policies, Configuration Profiles, Security Baselines, Apps, Scripts, Platform Scripts, Enrollment-Konfigurationen und Role Assignments.
Danach würde ich jedem produktiven Objekt eine Frage stellen:
Wer darf dieses Objekt ändern, ohne vorher jemanden zu fragen?
Wenn die Antwort "nur das zentrale Plattformteam" lautet, gehört das Objekt in einen globalen Bereich. Wenn die Antwort "Regional IT Germany" lautet, braucht es ein regionales Tag und eine passende Role Assignment. Wenn niemand die Frage beantworten kann, gehört das Objekt nicht in Local IT Hände, bis Ownership geklärt ist.
Erst danach lohnt sich die technische Arbeit.
Ein Pilot kann klein starten: eine Region, ein lokales IT-Team, wenige Profile, klare Scope Groups, eine Rolle mit exakt den nötigen Rechten. Danach prüft man mit einem Testadmin, welche Objekte sichtbar sind und welche Aktionen klappen.
Der Testadmin ist wichtig. Nicht der Architekt mit drei Sonderrollen. Nicht der globale Admin. Ein echter Admin aus der Zielgruppe.
Fazit
Scope Tags sind kein Ersatz für saubere Architektur.
Sie sind der Mechanismus, mit dem dein Intune-Rollenmodell überhaupt erst regional oder fachlich bedienbar wird.
Der gefährliche Teil ist nicht das Anlegen eines Tags. Der gefährliche Teil ist die Mischung aus breiten Scope Groups, unklaren Assignments, Default-Altlasten, Entra-Privileged-Roles und mehreren Role Assignments, die effektive Rechte größer machen als gedacht.
Wenn du Intune in einem großen Tenant betreibst, solltest du Scope Tags wie Ownership behandeln. Jedes produktive Objekt braucht einen verantwortlichen Bereich. Jede Role Assignment braucht ein klares Ziel. Jeder Admin sollte nur die Objekte sehen, für die er im Betrieb zuständig ist.
Dann werden Scope Tags unspektakulär.
Dann funktionieren sie.
Weitere Informationen: