Intune Multi-Admin Approval en Graph API: waarom uw scripts falen en hoe u ze repareert

Servicerelease 2606 van juni 2026 breidde Intune Multi-Admin Approval uit naar Graph API-aanroepen. Automatiseringsscripts die apps deployen of apparaten beheren, falen nu met HTTP 403. Ontdek oorzaak, werking en de twee praktische oplossingen.

Veel IT-teams merkten het pas toen een geautomatiseerde taak misging: een pipeline die apps uitrolt in Intune of een PowerShell-script dat apparaten beheert, gaf opeens een HTTP 403-fout terug. Geen rechtenprobleem, geen verlopen certificaat, maar een beveiligingsfunctie die in de Intune-servicerelease 2606 van juni 2026 stil werd uitgebreid: Multi-Admin Approval. Wat tot dan toe uitsluitend gold voor interactieve acties via de beheerconsole, geldt nu ook voor aanroepen via de Microsoft Graph API.

Wat is Multi-Admin Approval in Intune?

Multi-Admin Approval, afgekort MAA, is een beveiligingslaag binnen Microsoft Intune waarmee u bepaalde schrijfacties pas kunt doorvoeren als een tweede beheerder ze heeft goedgekeurd. Het principe is vergelijkbaar met het vierogenprincipe in financiële processen: niemand kan gevoelige configuraties eigenhandig aanpassen zonder dat een collega met de juiste rol de actie eerst heeft beoordeeld en goedgekeurd.

Concreet werkt het zo: een beheerder wil een script uitrollen of een applicatie-deployment bijwerken. Zodra die actie valt binnen een geconfigureerd MAA-toegangsbeleid, wordt de wijziging niet direct doorgevoerd maar in de wachtrij gezet. Een andere beheerder ontvangt een notificatie en moet de actie goedkeuren of afwijzen voordat die effect heeft. Dit voorkomt dat een enkelvoudige fout of een kwaadwillende beheerder met toegang tot een beheerdersaccount onomkeerbare schade aanricht.

Wat veranderde in servicerelease 2606?

Vóór juni 2026 gold MAA uitsluitend voor menselijke beheerders die handmatig in het Intune Admin Center werkten. Automatiseringsoplossingen vielen buiten die bescherming: PowerShell-scripts via Azure Automation, GitHub Actions-workflows die configuratieprofielen uitrollen, Terraform-configuraties die Intune-resources beheren, of maatwerkapplicaties die de Graph API aanroepen. Die blinde vlek is met servicerelease 2606 gedicht.

Vanaf die release onderschept MAA ook application-authenticated API-aanroepen, aanvragen die worden gedaan via een service principal of een app-registratie in Entra ID. Als de doelresource, een applicatie, een script, een device-configuratieprofiel, beschermd is door een MAA-toegangsbeleid, wordt de aanroep niet meer stilletjes doorgevoerd maar in een goedkeuringsstroom geplaatst. Scripts die dat niet verwachten, ontvangen een HTTP 403 met de foutcode ApprovalRequired.

Welke automatisering wordt geraakt?

De impact beperkt zich tot schrijfoperaties: POST, PATCH, PUT en DELETE via de Graph API op resources die onder een MAA-beleid vallen. Leesoperaties, alle GET-aanroepen, worden nooit onderschept door MAA. Monitoring-scripts, rapportagetools en queries om apparaatinformatie op te halen blijven dus gewoon werken.

Wat wel kan worden geraakt zijn automatiseringsscenario's waarbij Intune-resources worden aangepast. Denk aan PowerShell-scripts in Azure Automation of via een devops-platform die apps deployen, bijwerken of verwijderen. CI/CD-pipelines die device-configuratieprofielen of compliance-policies uitrollen. Tooling van externe leveranciers die de Intune Graph API gebruikt voor workflowautomatisering. En eigen scriptoplossingen die apparaten pensioneren of verwijderen op basis van compliancestatus.

Belangrijk: de impact treedt alleen op als uw tenant een MAA-toegangsbeleid heeft geconfigureerd voor de betreffende Intune-resources. Heeft u nooit MAA ingesteld, dan verandert er voor uw automatisering niets. Heeft u MAA wel actief maar alleen voor een beperkt aantal resources, dan raken alleen de pipelines die die specifieke resources aanpassen.

Hoe werkt de nieuwe goedkeuringsflow technisch?

Microsoft heeft de Graph API uitgebreid met een tweestapsflow voor MAA-onderschepte aanroepen. In de eerste stap verstuurt uw script de oorspronkelijke aanroep inclusief een extra header: x-msft-approval-justification, gevuld met een Base64-gecodeerde omschrijving van waarom de actie noodzakelijk is. Als de doelresource beschermd is, antwoordt de server met een HTTP 412 Precondition Required, of in sommige configuraties met de bekende HTTP 403 met foutcode ApprovalRequired. In de responsheaders zit een x-msft-approval-code: een unieke aanvraag-ID die uw script moet bewaren.

In de tweede stap moet een andere beheerder met goedkeuringsrechten de aanvraag goedkeuren in het Intune Admin Center, onder Tenant administration > Multi Admin Approval > Pending requests. Zodra goedkeuring is gegeven, kan het script de oorspronkelijke aanroep herhalen, nu met de x-msft-approval-code header in plaats van de justification-header. De API voert de actie dan alsnog door.

Voor pipelines waarbij een menselijke goedkeurder midden in de uitvoering niet haalbaar is, denk aan nachtelijke batchuitrolscripts of geautomatiseerde respons op incidenten, is dit een praktisch probleem. De pipeline kan niet onbeperkt wachten op een klik in een portal. Hier zijn twee oplossingen voor.

Twee praktische oplossingen

Oplossing één: sluit uw service principal uit van het MAA-beleid. Voor vertrouwde automatiseringsaccounts is dit de meest pragmatische aanpak. In het MAA-toegangsbeleid kunt u specifieke app-registraties aanwijzen als uitgesloten. MAA blijft dan van kracht voor menselijke beheerders die handmatig in de console werken, maar uw automation-service principal voert schrijfoperaties ongehinderd uit. Voeg wel compenserende controles toe: beperk de app-registratie strikt tot de minimaal benodigde Graph-machtigingen en zorg dat alle aanroepen zichtbaar zijn in de Entra ID-auditlogs. Documenteer de beslissing en laat de uitsluiting jaarlijks beoordelen.

Oplossing twee: maak uw scripts MAA-bewust. Als u de uitsluiting niet wilt instellen of als het MAA-beleid ook voor bepaalde automatiseringsscenario's van toepassing moet zijn, past u het script aan om de tweestapsflow te ondersteunen. Voeg een x-msft-approval-justification-header toe bij elke schrijfoperatie, vang de 412-respons op, sla de approval-code op, stuur een notificatie naar de goedkeurder via Teams of e-mail, en herstart de actie zodra goedkeuring is bevestigd. Dit vereist meer ontwikkelwerk maar geeft de meest volledige MAA-integratie.

Wat u nu moet controleren

Eerste stap: controleer of uw tenant MAA-toegangsbeleid heeft geconfigureerd. Ga naar Microsoft Intune Admin Center, kies Tenant administration en vervolgens Multi Admin Approval. Bekijk welke resources zijn beschermd. Heeft u geen beleid ingesteld, dan is er geen urgente actie nodig voor uw bestaande automatisering.

Tweede stap: inventariseer welke automatiseringsoplossingen schrijfoperaties uitvoeren op beschermde Intune-resources. Bekijk Azure Automation-jobs, GitHub Actions-workflows en scripts in andere devops-platforms op Graph API-aanroepen met POST, PATCH, PUT of DELETE gericht op Intune-eindpunten. Test deze scripts in een acceptatieomgeving als u twijfelt of ze geraakt worden.

Derde stap: kies per service principal bewust voor uitsluiting of aanpassing van de scriptlogica, documenteer de beslissing en het bijbehorende risicoafweging. Een uitsluiting is veilig zolang de app-registratie minimale machtigingen heeft en auditlogging actief is. Beheer de uitsluitingen centraal zodat ze niet vergeten worden bij toekomstige beleidswijzigingen. Wilt u hulp bij het beoordelen van uw Intune-automatisering of het correct inrichten van MAA voor uw omgeving? Neem contact op met Zarioh voor een vrijblijvend gesprek.