Register security information geldt nu ook voor Windows Hello for Business en Platform SSO
Vanaf maandag 6 juli rolt Microsoft een wijziging uit waardoor Conditional Access-policies op de user action Register security information ook gaan gelden bij het inrichten van Windows Hello for Business en bij de Platform SSO-registratie op een Mac. Op 13 juli moet de uitrol in alle tenants klaar zijn. Heb je nooit een policy op die user action gemaakt, dan merk je er niets van. Heb je er wel een, dan is die waarschijnlijk geschreven met de Security info-pagina in My Sign-ins in gedachten, en vanaf die week geldt hij ook tijdens je Autopilot- en Mac-onboarding.
Foto: Yevhenii Deshko via Unsplash
Wat de user action nu afdekt
Conditional Access kent maar twee user actions: Register security information en Register or join devices. De tweede valt buiten deze wijziging (daar zijn alleen MFA en authentication strength beschikbaar als grant control, zie user actions). Register security information wordt geëvalueerd bij combined registration: de Security info-pagina in My Sign-ins en de interrupt mode die verschijnt als iemand zich moet registreren voor SSPR of MFA. Volgens Microsoft Learn vallen ook gebruikers die zich aanmelden in de Authenticator-app of passwordless phone sign-in aanzetten eronder. Het is de plek waar de meeste organisaties regels zetten als "alleen registreren vanaf een vertrouwde locatie", "buiten kantoor eerst MFA", "alleen vanaf een compliant device", of een authentication strength met Temporary Access Pass (TAP) zodat nieuwe medewerkers kunnen bootstrappen.
Windows Hello for Business en Platform SSO liepen hier nooit doorheen. Bij het inrichten van Hello for Business vraagt de provisioning-app via WAM een access token aan voor de Azure Device Registration Service, de gebruiker moet in de laatste tien minuten MFA hebben gedaan, en daarmee is de controle klaar (zo werkt provisioning). Ook Platform SSO met Secure Enclave of smartcard vraagt MFA bij de setup (Intune Platform SSO-handleiding). Geen van beide flows keek naar je registratiepolicies. Dat verandert nu: de standaard MFA-eis blijft, en daarbovenop gelden de voorwaarden en grant controls van elke actieve policy op deze user action (policies in report-only worden niet afgedwongen), of dat nu een authentication strength, een locatievoorwaarde of een device-eis is. De tijdlijn is al goed beschreven in MC1326253 (gepubliceerd op 29 mei) en op de Entra-blog van Microsoft, dus ik richt me op wat je in je eigen policies moet nalopen.
Windows Hello for Business en Platform SSO liepen hier nooit doorheen. Bij het inrichten van Hello for Business vraagt de provisioning-app via WAM een access token aan voor de Azure Device Registration Service, de gebruiker moet in de laatste tien minuten MFA hebben gedaan, en daarmee is de controle klaar (zo werkt provisioning). Ook Platform SSO met Secure Enclave of smartcard vraagt MFA bij de setup (Intune Platform SSO-handleiding). Geen van beide flows keek naar je registratiepolicies. Dat verandert nu: de standaard MFA-eis blijft, en daarbovenop gelden de voorwaarden en grant controls van elke actieve policy op deze user action (policies in report-only worden niet afgedwongen), of dat nu een authentication strength, een locatievoorwaarde of een device-eis is. De tijdlijn is al goed beschreven in MC1326253 (gepubliceerd op 29 mei) en op de Entra-blog van Microsoft, dus ik richt me op wat je in je eigen policies moet nalopen.
Policies die onboarding kunnen blokkeren
Als eerste zou ik kijken naar de eis van een compliant device. Learn noemt zelf dat organisaties device compliance gebruikten om registratie af te schermen, en voor registratie in de browser op een bestaande beheerde laptop werkt dat prima. Het inrichten van Hello for Business begint echter direct na de eerste aanmelding op een vers uitgerold apparaat, en op dat moment is Intune mogelijk nog niet klaar met de compliance-evaluatie. Voor hybrid joined Autopilot-apparaten is dat gedocumenteerd: op de pagina met Autopilot known issues staat dat de compliance-status van het hybrid device op N/A staat tot er een gebruiker heeft aangemeld, omdat Intune pas na een geslaagde gebruikersaanmelding synchroniseert met het hybrid device ID. Provisioning draait precies tijdens die eerste aanmelding. Op een Mac verschilt, voor zover ik kan zien, de volgorde van enrollment, Entra-registratie en compliance-rapportage in de praktijk tussen de Company Portal-flow en Automated Device Enrollment (Microsoft documenteert die volgorde niet expliciet), dus ik zou er niet van uitgaan dat de Mac al compliant is als de melding "Registration Required" verschijnt.
Een policy die een Microsoft Entra hybrid joined device eist, is op Windows minder riskant, want Hello for Business kan op een hybrid apparaat pas worden ingericht als de join rond is. Een Mac is echter nooit hybrid joined, dus als dat de enige grant control is, kan Platform SSO-registratie er nooit aan voldoen.
Daarna de vertrouwde locaties. Een policy die registratie buiten trusted locations blokkeert, of daar een compliant device eist, deed geen kwaad zolang mensen hun authenticator op kantoor of via VPN registreerden. Zodra de handhaving start, geldt dezelfde policy ook voor de collega die thuis een Autopilot-laptop uitpakt, en dan faalt de Hello for Business-provisioning daar.
Het bootstrap-probleem is lastiger te zien. TAP voldoet aan de control Require multifactor authentication, en tijdens Microsoft Entra join kan een gebruiker met een TAP aanmelden zonder wachtwoord, het apparaat joinen en in één keer Hello for Business registreren. Op hybrid joined apparaten, en op apparaten die al gejoind zijn, moet de gebruiker eerst met een andere methode (bijvoorbeeld een wachtwoord) aanmelden voordat de TAP voor Hello for Business wordt geaccepteerd. Het addertje zit in authentication strengths: TAP zit alleen in de ingebouwde Multifactor authentication strength, niet in Passwordless MFA of Phishing-resistant MFA. Eist je registratiepolicy een van die twee (een gangbare keuze zodra een passwordless-traject verder is), dan kan een nieuwe medewerker met alleen een TAP er niet aan voldoen, en dat geldt vanaf nu ook in de OOBE. Learn beschrijft de oplossing: een custom authentication strength met de TAP-combinatie naast de methodes die je echt wilt, gekoppeld aan de policy op Register security information (zie het voorbeeld "Bootstrap and recovery" in hoe authentication strengths werken). Ook federated multifactor zit alleen in de MFA strength. Dat is relevant als je gefedereerde domein
Er spelen ook twee timingdetails. Meldt de gebruiker zich aan met een single-use TAP en start de Hello for Business-provisioning pas na meer dan tien minuten, dan is een tweede TAP nodig, of je gebruikt een multi-use TAP; het TAP-artikel heeft daar een aparte tabel voor. En de MFA uit de OOBE scheelt de gebruiker alleen een prompt als die ook aan je policy voldoet. Microsoft waarschuwt in het eigen bericht dat gebruikers tijdens de device setup een nieuwe authenticatieprompt kunnen zien, dus licht je servicedesk in.
Dan zijn er nog de uitsluitingen. Elke exclusion op deze policies (een groep nieuwe medewerkers, gasten, een provisioning-account) zondert die groep nu ook uit van je controls op Hello for Business en Platform SSO. Er is geen aparte user action voor deze twee flows. Wil je ze anders behandelen dan registratie in de browser, dan heb je alleen de gewone voorwaarden op dezelfde user action. De voorwaarde device platforms lijkt de voor de hand liggende, en filter for devices is een tweede kandidaat, maar ik heb Microsoft nergens zien bevestigen welke voorwaarden in deze flows worden geëvalueerd.
Een policy die een Microsoft Entra hybrid joined device eist, is op Windows minder riskant, want Hello for Business kan op een hybrid apparaat pas worden ingericht als de join rond is. Een Mac is echter nooit hybrid joined, dus als dat de enige grant control is, kan Platform SSO-registratie er nooit aan voldoen.
Daarna de vertrouwde locaties. Een policy die registratie buiten trusted locations blokkeert, of daar een compliant device eist, deed geen kwaad zolang mensen hun authenticator op kantoor of via VPN registreerden. Zodra de handhaving start, geldt dezelfde policy ook voor de collega die thuis een Autopilot-laptop uitpakt, en dan faalt de Hello for Business-provisioning daar.
Het bootstrap-probleem is lastiger te zien. TAP voldoet aan de control Require multifactor authentication, en tijdens Microsoft Entra join kan een gebruiker met een TAP aanmelden zonder wachtwoord, het apparaat joinen en in één keer Hello for Business registreren. Op hybrid joined apparaten, en op apparaten die al gejoind zijn, moet de gebruiker eerst met een andere methode (bijvoorbeeld een wachtwoord) aanmelden voordat de TAP voor Hello for Business wordt geaccepteerd. Het addertje zit in authentication strengths: TAP zit alleen in de ingebouwde Multifactor authentication strength, niet in Passwordless MFA of Phishing-resistant MFA. Eist je registratiepolicy een van die twee (een gangbare keuze zodra een passwordless-traject verder is), dan kan een nieuwe medewerker met alleen een TAP er niet aan voldoen, en dat geldt vanaf nu ook in de OOBE. Learn beschrijft de oplossing: een custom authentication strength met de TAP-combinatie naast de methodes die je echt wilt, gekoppeld aan de policy op Register security information (zie het voorbeeld "Bootstrap and recovery" in hoe authentication strengths werken). Ook federated multifactor zit alleen in de MFA strength. Dat is relevant als je gefedereerde domein
enforceMfaByFederatedIdp gebruikt, want dan vindt de MFA voor Hello for Business-provisioning plaats op je federatieserver.Er spelen ook twee timingdetails. Meldt de gebruiker zich aan met een single-use TAP en start de Hello for Business-provisioning pas na meer dan tien minuten, dan is een tweede TAP nodig, of je gebruikt een multi-use TAP; het TAP-artikel heeft daar een aparte tabel voor. En de MFA uit de OOBE scheelt de gebruiker alleen een prompt als die ook aan je policy voldoet. Microsoft waarschuwt in het eigen bericht dat gebruikers tijdens de device setup een nieuwe authenticatieprompt kunnen zien, dus licht je servicedesk in.
Dan zijn er nog de uitsluitingen. Elke exclusion op deze policies (een groep nieuwe medewerkers, gasten, een provisioning-account) zondert die groep nu ook uit van je controls op Hello for Business en Platform SSO. Er is geen aparte user action voor deze twee flows. Wil je ze anders behandelen dan registratie in de browser, dan heb je alleen de gewone voorwaarden op dezelfde user action. De voorwaarde device platforms lijkt de voor de hand liggende, en filter for devices is een tweede kandidaat, maar ik heb Microsoft nergens zien bevestigen welke voorwaarden in deze flows worden geëvalueerd.
De policies vinden
Het filter in de portal werkt, maar in een tenant met veel policies wil ik liever een lijst inclusief grant controls. Met Microsoft Graph PowerShell, en de user action zoals die in de property
includeUserActions staat: Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
Where-Object { $_.Conditions.Applications.IncludeUserActions -contains 'urn:user:registersecurityinfo' } |
Select-Object DisplayName, State,
@{ n = 'BuiltInControls'; e = { $_.GrantControls.BuiltInControls -join ', ' } },
@{ n = 'Operator'; e = { $_.GrantControls.Operator } },
@{ n = 'AuthStrength'; e = { $_.GrantControls.AuthenticationStrength.DisplayName } },
@{ n = 'InclLocations'; e = { $_.Conditions.Locations.IncludeLocations -join ', ' } },
@{ n = 'ExclLocations'; e = { $_.Conditions.Locations.ExcludeLocations -join ', ' } },
@{ n = 'Platforms'; e = { $_.Conditions.Platforms.IncludePlatforms -join ', ' } } |
Format-Table -AutoSize
Let op
compliantDevice en domainJoinedDevice in de built-in controls, block in combinatie met locatievoorwaarden, en authentication strengths zonder TAP. Neem policies in report-only ook mee, want die zet iemand vroeg of laat aan. De wijziging testen
Zowel het bericht van Microsoft als de notitie op Learn adviseren te testen met report-only. Het artikel over report-only zegt echter dat policies in report-only kunnen worden geëvalueerd "except for items included in the User Actions scope". Ik zou voor deze policies dus niet op report-only resultaten rekenen. De What If-tool ondersteunt user actions wel: simuleer een testaccount van een nieuwe medewerker, kies Register security information als target, zet het platform op Windows of macOS en gebruik een thuis-IP-adres. Dan zie je welke policies van toepassing zijn en aan welke grant controls de gebruiker moet voldoen.
Echt testen kan pas als de wijziging in je tenant is aangekomen. Plan dus een vers Autopilot-apparaat en een verse Mac met een testaccount in de week van 6 juli, liefst vóór je volgende onboardingronde. Microsoft heeft niet gedocumenteerd hoe de nieuwe evaluatie precies in de sign-in logs verschijnt. Het provisioning-token wordt aangevraagd voor de Device Registration Service (app ID
Echt testen kan pas als de wijziging in je tenant is aangekomen. Plan dus een vers Autopilot-apparaat en een verse Mac met een testaccount in de week van 6 juli, liefst vóór je volgende onboardingronde. Microsoft heeft niet gedocumenteerd hoe de nieuwe evaluatie precies in de sign-in logs verschijnt. Het provisioning-token wordt aangevraagd voor de Device Registration Service (app ID
01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9), dus daar zou ik beginnen, met een blik op het tabblad Conditional Access. Stuur je sign-in logs naar Log Analytics, dan laat deze query zien tegen welke resources je registratiepolicies worden geëvalueerd (vul je eigen policynamen in), zodat je de periode voor en na de uitrol kunt vergelijken: let regPolicies = dynamic(["CA-RegisterSecInfo-TrustedLocations", "CA-RegisterSecInfo-AuthStrength"]);
SigninLogs
| where TimeGenerated > ago(14d)
| mv-expand cap = ConditionalAccessPolicies
| where tostring(cap.displayName) in (regPolicies)
| where tostring(cap.result) !in ("notApplied", "notEnabled")
| summarize Count = count() by AppDisplayName, ResourceDisplayName, Policy = tostring(cap.displayName), Result = tostring(cap.result), ResultType
| order by Count desc
Op het Windows-apparaat zelf toont de User Device Registration admin log (Applications and Services Logs, Microsoft, Windows) de prerequisite checks van provisioning en event 300 zodra de key geregistreerd is. Bij een mislukte test is de lijst met PIN-foutcodes handig.
Vóór 6 juli
Draai het script hierboven en beantwoord per policy op Register security information één vraag: kan een nieuwe medewerker, thuis, op een gloednieuw apparaat, met alleen een TAP, hieraan voldoen? Is het antwoord nee, voeg dan een custom authentication strength met TAP toe, verplaats de device- of locatie-eis naar een voorwaarde die de OOBE niet raakt, of besluit bewust dat Hello for Business-provisioning op afstand moet falen. Plan daarna een testapparaat in voor de week van de uitrol.
Bronnen
- MC1326253: Conditional Access-policies gelden nu ook voor registratie van Windows Hello for Business en macOS Platform SSO
- Microsoft Entra blog: Microsoft Entra ID security updates, what organizations need to do now
- Registratie van security info beschermen met Conditional Access
- Conditional Access target resources: user actions
- Zo werkt provisioning van Windows Hello for Business
- Platform SSO voor macOS configureren in Intune
- Windows Autopilot known issues
- Temporary Access Pass: Windows device setup
- Ingebouwde en custom authentication strengths
- Hoe authentication strengths werken
- Resource type conditionalAccessApplications (Microsoft Graph)
- Report-only-modus in Conditional Access
- De What If-tool van Conditional Access
- Foutcodes bij het aanmaken van een PIN voor Windows Hello for Business