Multi Admin Approval trifft die Graph API: Wenn deine Intune-Automation plötzlich 403 wirft
Ein Automation-Skript, das seit Monaten klaglos Compliance Policies gegen Microsoft Graph ausrollt, wirft plötzlich einen 403. Die App-Registrierung hat weiterhin DeviceManagementConfiguration.ReadWrite.All, das Token ist gültig, die Berechtigung stimmt. Trotzdem lehnt Intune den Request ab.
Der Grund ist kein Bug. Seit dem Juni-2026-Update greift Multi Admin Approval (MAA) nicht mehr nur bei interaktiven Admin-Aktionen im Intune Admin Center, sondern auch bei App-Only-Aufrufen über die Microsoft Graph API. Service Principals, Automation-Skripte und Third-Party-Tools sind damit demselben Freigabe-Workflow unterworfen wie ein Admin, der manuell im Portal klickt.
Ich habe mich in einem früheren Artikel schon kritisch mit MAA bei Device Actions in großen Umgebungen auseinandergesetzt. Das Kernproblem war dort organisatorisches Routing, nicht die Technik. Mit dieser Erweiterung wandert genau dieses Problem jetzt in eure Pipelines.
Was sich technisch ändert
Bisher unterschied Intune sauber zwischen delegierten (interaktiven) und App-Only-Aufrufen. Nur delegierte Aktionen liefen durch MAA. App-Only-Calls mit Client-Credentials-Flow liefen daran vorbei, unabhängig davon, ob die Zielressource durch eine Access Policy geschützt war.
Das ist jetzt vorbei. Wenn ein App-Auth-Call eine durch MAA geschützte Ressource verändert, greift exakt derselbe Approval-Mechanismus wie bei einem menschlichen Admin.
Betroffen sind ausschließlich schreibende Operationen:
| Ressourcentyp | Betroffen |
|---|---|
| Apps (Deployments) | Ja, bei aktiver Access Policy |
| Compliance Policies | Ja, bei aktiver Access Policy |
| Configuration Policies (Settings Catalog) | Ja, bei aktiver Access Policy |
| Device Actions (Wipe, Retire, Delete) | Ja, bei aktiver Access Policy |
| Role-based Access Control | Ja, bei aktiver Access Policy |
| Scripts | Ja, bei aktiver Access Policy |
| Tenant Configuration | Ja, bei aktiver Access Policy |
| GET-Requests auf beliebige Ressourcen | Nein, lesende Zugriffe sind nie betroffen |
Wichtig: Das aktiviert MAA nicht automatisch in eurem Tenant. Die Erweiterung greift ausschließlich dort, wo bereits Access Policies konfiguriert sind. Wer MAA nie eingerichtet hat, merkt von dieser Änderung nichts.
Den Approval-Workflow in Automation einbauen
Damit eure Skripte nicht einfach nur fehlschlagen, muss die Automation den kompletten Request-Approve-Resubmit-Zyklus abbilden.
Der Exclusions-Tab: praktischer Ausweg mit Haken
Für Applikationen, die nicht kurzfristig umgebaut werden können, gibt es einen Exclusions-Tab in der Access Policy. Dort lässt sich ein Service Principal gezielt von der Enforcement ausnehmen. Wichtig dabei: Die Ausnahme gilt ausschließlich für App-Auth-Calls dieser einen Anwendung. Interaktive Admins, die dieselbe Ressource anfassen, brauchen weiterhin eine Freigabe. Und die Exclusion selbst muss von einem zweiten Admin bestätigt werden, bevor sie wirkt.
Das ist ein sauberer Kompromiss, aber kein Freifahrtschein. Jede Exclusion ist faktisch ein Loch in der Kontrolle, die ihr euch mit MAA erst aufgebaut habt. Wer hier großzügig Applikationen ausnimmt, um Fehlermeldungen loszuwerden, hat am Ende eine Access Policy, die auf dem Papier existiert und operativ nichts mehr absichert.
Warum das dieselbe Diskussion ist wie bei Device Actions
Genau wie bei Wipe, Retire und Delete in großen Umgebungen liegt das eigentliche Problem nicht in der Technik. Der Approval-Mechanismus funktioniert wie dokumentiert. Das Problem ist die Frage, die jede Pipeline jetzt beantworten muss:
Wer genehmigt einen automatisierten Deploy um drei Uhr nachts, wenn kein Mensch aus dem Approver-Kreis online ist?
Für eine CI/CD-Pipeline, die Konfigurationsänderungen mehrmals täglich ausrollt, ist ein manueller Freigabeschritt kein zusätzliches Sicherheitsnetz, sondern ein struktureller Bruch im Automatisierungsmodell. Entweder blockiert ihr eure Pipeline regelmäßig, oder ihr baut einen Approver-Bereitschaftsdienst auf, der Anfragen faktisch nur durchwinkt, weil niemand nachts den fachlichen Kontext einer Settings-Catalog-Änderung prüfen kann. Beides ist keine gute Option.
Meine pragmatische Einordnung für Automation-Szenarien:
- Access Policies bewusst scopen. Schützt mit MAA die Ressourcentypen, bei denen Änderungen selten und wirkmächtig sind, RBAC und Tenant Configuration allen voran. Genau dort ist ein manueller zweiter Blick sinnvoll und die Frequenz gering genug, um ihn nicht zur Belastung zu machen.
- Gut governte Service Principals gezielt ausnehmen. Eine Pipeline mit Code Review vor jedem Merge, minimalen Graph-Permissions, Conditional Access auf die Workload Identity und vollständigem Audit-Trail hat bereits Kontrollen, die eine MAA-Freigabe im Kern dupliziert. Hier ist eine dokumentierte Exclusion die ehrlichere Lösung als ein Freigabeschritt, den ohnehin niemand fachlich prüft.
- Ungeprüfte oder breit berechtigte Automation nicht ausnehmen. Ein Skript mit
.All-Permissions ohne Code Review und ohne eingeschränkte Umgebung ist genau der Fall, für den MAA gebaut wurde. Hier gehört der Approval-Workflow implementiert, nicht wegkonfiguriert.
Monitoring nicht vergessen
Jede MAA-Aktivität bei App-Auth-Calls landet im normalen Intune-Audit-Log, inklusive Approve, Block, Pass sowie Exclusion Add und Remove. Wer MAA für Automation aktiviert, sollte dieses Log aktiv auswerten, nicht nur bei Vorfällen hineinschauen. Gerade Exclusion-Änderungen sind ein Signal, das in jedes Security-Monitoring gehört, weil sie direkt die Kontrolle verändern, die MAA eigentlich bieten soll.
Die Erweiterung von MAA auf die Graph API ist technisch konsequent. Wer aber automatisiert Änderungen an geschützten Ressourcen vornimmt, kommt an dieser Stelle nicht um eine bewusste Entscheidung herum: robusten Approval-Workflow einbauen, gezielt und dokumentiert ausnehmen, oder den Ressourcentyp gar nicht erst unter MAA stellen. Alles andere endet in Pipelines, die entweder brechen oder ihre eigene Sicherheitskontrolle im Blindflug bestätigen.