Conditional Access op All resources: de uitzondering voor baseline scopes vervalt op 15 juni

De tijdlijn is elders al goed beschreven (aangekondigd op 29 januari met een datum in maart, verschoven naar 13 mei en daarna naar 15 juni), dus ik blijf bij de techniek. De Learn-sectie die het beschrijft heette eerst "Conditional Access behavior when an all resources policy has an app exclusion" en staat nu als legacy behavior-sectie in het artikel over target resources. De regel was: zodra er een app is uitgesloten van een All resources-policy, worden bepaalde scopes met lage rechten niet door die policy afgedwongen. De gedachte erachter was praktisch. Bijna elke client vraagt naast zijn eigenlijke resource ook User.Read aan (Outlook doet dat bij een token voor Exchange, om te laten zien wie er is aangemeld). Sluit je een app uit, dan verwacht je dat die app werkt, en dat zou niet lukken als het User.Read-deel van hetzelfde verzoek alsnog door de policy werd tegengehouden.

De lijst is opgesplitst per type client, en de voorwaarde is voor die twee niet gelijk:

• Native clients en SPA's: Azure AD Graph email, offline_access, openid, profile, User.Read, en op Microsoft Graph hetzelfde plus People.Read.
• Confidential clients, "if they're excluded from an All resources policy": daarnaast User.Read.All en User.ReadBasic.All, en op Microsoft Graph ook People.Read.All, GroupMember.Read.All en Member.Read.Hidden.

Die toevoeging "if they're excluded" staat alleen bij de confidential clients. Voor public clients was elke uitsluiting in de policy genoeg. Sluit je één SaaS-app uit omdat die niet overweg kan met je eis van een compliant device, dan loopt elke public client in de tenant die niets buiten deze scopes aanvraagt langs die policy heen. Daarom gebruikt Microsoft in de nieuwe documentatie zelf Visual Studio Code (vraagt openid en profile) en Azure CLI (vraagt bij het aanmelden alleen User.Read) als voorbeeld. In een gemiddelde tenant is geen van beide uitgesloten; het was de uitsluiting van een heel andere app waardoor ze erdoor kwamen.

Wat er door die opening kwam was beperkt. De tokens geven toegang tot je eigen profiel, en voor een uitgesloten confidential client tot het lezen van gebruikers en groepslidmaatschappen in de hele directory. Een vervolgtoken voor een echte resource (Exchange, SharePoint, Azure Resource Manager) wordt op dat moment gewoon weer tegen je policies gehouden, dus een volledige omzeiling was het nooit. Maar een sign-in die slaagt zonder de MFA of het compliant device dat je baseline-policy vraagt, bevestigt aan degene die het wachtwoord heeft wel dat het klopt, en directory-gegevens lezen is meestal de eerste stap van verkenning. Microsoft adviseert al lang een baseline MFA-policy op All resources zonder uitsluitingen. De gedocumenteerde workaround om directorydata te beschermen was een aparte policy op Windows Azure Active Directory (00000002-0000-0000-c000-000000000000), geselecteerd via een filter op een custom security attribute, omdat die resource niet in de app-kiezer staat.

Na de uitrol worden baseline scopes (Microsofts verzamelnaam voor de vier OIDC-scopes plus User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All en Member.Read.Hidden) beoordeeld als directory-toegang en gekoppeld aan Azure AD Graph, de resource Windows Azure Active Directory, als Conditional Access-audience. Policies op All resources met uitsluitingen, en policies die Azure AD Graph expliciet als doel hebben, worden dan afgedwongen voor sign-ins die alleen deze scopes aanvragen. Vraagt een client ook maar één scope buiten de lijst aan, dan verandert er niets: die werd al beoordeeld op de resource die hij aanvroeg. Een uitgesloten confidential client die alleen OIDC-scopes vraagt, verandert ook niet.

Waar dit problemen geeft, zie je in Microsofts eigen lijst van situaties waarin je het oude gedrag zou willen houden, en die lijst komt overeen met wat ik in policy sets van grotere organisaties tegenkom: een All resources-policy met Require compliant device en een uitgesloten app die vanaf onbeheerde apparaten moet werken, een All resources-policy met Require app protection policy en clients zonder Intune SDK, block-policies met uitsluitingen, en public clients die bewust buiten device compliance zijn gehouden. In al die gevallen slaagde een sign-in met alleen baseline scopes vroeger, en vanaf de uitrol moet hij aan de policy voldoen. Bouw je zelf apps, controleer dan of ze met een Conditional Access-challenge overweg kunnen (developer guidance). Heeft een confidential client alleen naam en e-mailadres van de gebruiker nodig, dan houdt de overstap van User.Read naar openid en profile hem helemaal buiten deze wijziging.

De uitrol gaat geleidelijk, over enkele weken. Sinds de revisie van MC1223829 van 5 juni zegt Microsoft dat je twee weken voordat de uitrol je tenant bereikt nog een Message Center-bericht krijgt, en een als hij klaar is.

Begin bij de policies. Alles wat All insluit en minstens één entry in excludeApplications heeft, valt eronder. Een uitsluiting van Office365 of MicrosoftAdminPortals telt ook als resource-uitsluiting.

Let vooral op resultaten waar in de kolom Grant compliantDevice, compliantApplication of block staat.

Voor de sign-ins zelf zijn er twee routes. Zonder iets te wijzigen laat Log Analytics al kandidaten zien: sign-ins naar Microsoft Graph of Windows Azure Active Directory waarbij je All resources-policy notApplied meldt. ConditionalAccessPolicies is in SigninLogs een dynamic kolom en in AADNonInteractiveUserSignInLogs een string, vandaar de parse_json aan één kant.

Zie de uitkomst als een lijst kandidaten: notApplied verschijnt ook als de gebruiker is uitgesloten of als een conditie zoals platform of locatie niet matchte. De nauwkeurige route loopt via de nieuwe instellingenpagina.

De configuratie kwam met de revisie van MC1223829 van 15 april: uitleg op aka.ms/BaselineScopesSettings en de pagina zelf op aka.ms/BaselineScopesSettingsUX. Je vindt hem niet door de Conditional Access-blade door te klikken; je hebt de directe link nodig, en minimaal de rol Conditional Access Administrator. Er zijn drie opties.

Enable enforcement zet het nieuwe gedrag direct aan, vóór de uitrol. Microsoft raadt aan dat eerst in een testtenant te doen. Disable enforcement houdt het oude gedrag aan voor alle policies in de tenant. Microsoft noemt dat een tijdelijke opt-out en raadt het af, maar heeft er geen einddatum voor gepubliceerd. Wat je hier kiest, wordt door de uitrol niet overschreven. Kies je niets, dan wordt de handhaving automatisch toegepast en toont de pagina daarna geen selectie meer, omdat handhaving dan de standaard is.

Customize behavior vraagt wat meer uitleg. Je registreert een single-tenant applicatie (verder geen configuratie nodig), sluit die uit van de policies waar je het oude gedrag wilt houden, en selecteert hem op de instellingenpagina als doel voor baseline scopes. Sign-ins met alleen baseline scopes worden dan beoordeeld tegen jouw placeholder-app in plaats van Windows Azure Active Directory. Waar de placeholder is uitgesloten, geldt de policy niet, en dat is het oude gedrag per policy. Overal anders wordt afgedwongen.

Uit dat ontwerp volgen twee dingen. Ten eerste suggereert de formulering van Microsoft dat je met Customize behavior vóór 15 juni de handhaving aanzet voor elke policy die de placeholder niet uitsluit (Learn zegt niet letterlijk dat het al vóór de uitrol ingaat), dus behandel het als actief vanaf het moment dat je opslaat; alles bij het oude laten doet deze optie niet. Ten tweede wordt de placeholder een markering in je logs: elke sign-in die alleen baseline scopes aanvroeg, toont zijn app-ID als Conditional Access-audience. Op Learn staat op dit moment dat dat gebeurt "after selecting the Enable enforcement option", maar in die modus is er geen custom applicatie om te tonen; lees daar dus Customize behavior.

Daarmee heb je een nette meetopstelling. Sluit de placeholder uit van precies de All resources-policies die al uitsluitingen hebben, kies Customize behavior, en je effectieve gedrag blijft het oude terwijl de logs elke betrokken sign-in vastleggen. Daarna:

Na een week of twee heb je de echte lijst. Los op wat van jezelf is, ga in gesprek met de leveranciers van wat dat niet is, haal de uitsluiting van de placeholder policy voor policy weg en sluit af met Enable enforcement.

De grant Require approved client app verdwijnt op 30 juni 2026, in dezelfde maand en vaak in dezelfde policy set. Microsofts boodschap daarover is onderweg verschoven. MC1220751 zei in januari nog dat een policy met alleen deze grant zich zou gedragen alsof de grant niet was geselecteerd. Het migratie-artikel is eind mei herschreven en zegt nu dat de control, en elke policy die hem gebruikt, op 30 juni read-only wordt: niet meer aanmaken of bewerken, wel uitschakelen of verwijderen, en bestaande ingeschakelde policies worden gewoon afgedwongen. Het praktische gevolg van die nieuwe formulering is dat je zo'n policy na 30 juni niet meer ter plekke kunt aanpassen. Migreer dus vóór die datum: voor bestaande policies Require approved client app of Require app protection policy met Require one of the selected controls, en voor nieuwe policies alleen Require app protection policy. Die grant werkt alleen als er voor die apps en gebruikers ook echt een Intune app protection policy bestaat; zonder die policy worden gebruikers geblokkeerd. In de kolom Grant van het script hierboven zie je met approvedApplication zonder compliantApplication welke policies nog aan de beurt zijn.

Mijn voorstel voor deze week: draai het policy-script, zet elke uitsluiting op een policy met compliant device, app protection of block op een rij, en richt bij treffers vóór 15 juni de placeholder-app met Customize behavior in, zodat je de lijst met betrokken sign-ins uit je logs hebt voordat de eerste gebruikers de servicedesk bellen.

• MC1223829: handhaving van Conditional Access voor All resources-policies met uitgesloten resources
• Improved enforcement for All resources policies with resource exclusions
• Conditional Access target resources: legacy behavior bij een All resources-policy met een uitgesloten resource
• MFA strength vereisen voor alle gebruikers
• Developer guidance voor Conditional Access
• Uitleg over de Baseline scopes settings (aka.ms/BaselineScopesSettings)
• Referentie van de tabel SigninLogs
• Referentie van de tabel AADNonInteractiveUserSignInLogs
• MC1220751: retirement van de grant Require approved client app
• Migrate approved client app to application protection policy in Conditional Access