[Microsoft Entra ID] - Ervaringen & Discussie

[Blokker_1999]

Ik heb gelukkig een test tenant om mee te spelen en te proberen, voordeel van een Visual Studio subscription te hebben

[Blokker_1999]

Nope, not gonna work. De setting voorkomt dat gebruikers uitgenodigd kunnen worden, maar eenmaal uitgenodigd, en daarna op de block list, blokkeert het hun authenticatie naar de externe tenant niet.

[HKLM_]

Blokker_1999 schreef op zaterdag 28 maart 2026 @ 18:49:
Nope, not gonna work. De setting voorkomt dat gebruikers uitgenodigd kunnen worden, maar eenmaal uitgenodigd, en daarna op de block list, blokkeert het hun authenticatie naar de externe tenant niet.

Ik denk dat jij dit niet kan doen vanuit je tenant, als zij met een guest account aanmelden op een andere tenant (AVD) dan ligt de autorisatie bij de andere tenant en zijn zij in charge m.b.t conditional access bijvoorbeeld.

Enige waar ik nog aan denk is iets met IP whitelisting (hun IP's) van hun AVD aan jullie kant maar dat is wel een beetje beunhazen denk ik.

[ Voor 11% gewijzigd door HKLM_ op 28-03-2026 19:08 ]

[Blokker_1999]

Klopt, daar lijkt het op. Rottigste is dat ik wel netjes op de bron tenant in de sign-in logs kan zien dat er een authenticatie plaatsvindt, en die gaat ook netjes door mijn standaard CA policies, maar ik krijg geen controle om selectief om te springen met welke gebruikers naar welke externe tenant mogen. Had MS nu ook niet even de resource tenant als een mogelijk doelwit aan de CA policies kunnen toevoegen? Dan was dit in 5 seconden opgelost. Want voor inkomende guest gebruikers kan je wel policies aanmaken, zelfs per tenant als je wenst.

Wat mis ik mijn vorige werkgever, waar we dit soort problemen niet op een technische manier probeerden op te lossen, maar puur met geschreven policies.

[ Voor 12% gewijzigd door Blokker_1999 op 28-03-2026 19:11 ]

[F_J_K]

Dat laatste is hier sowieso aan de orde, als de andere kant zich verantwoordelijk heeft gemaakt voor de autorisaties.

[HKLM_]

Blokker_1999 schreef op zaterdag 28 maart 2026 @ 19:10:
Klopt, daar lijkt het op. Rottigste is dat ik wel netjes op de bron tenant in de sign-in logs kan zien dat er een authenticatie plaatsvindt, en die gaat ook netjes door mijn standaard CA policies, maar ik krijg geen controle om selectief om te springen met welke gebruikers naar welke externe tenant mogen. Had MS nu ook niet even de resource tenant als een mogelijk doelwit aan de CA policies kunnen toevoegen? Dan was dit in 5 seconden opgelost. Want voor inkomende guest gebruikers kan je wel policies aanmaken, zelfs per tenant als je wenst.

Wat mis ik mijn vorige werkgever, waar we dit soort problemen niet op een technische manier probeerden op te lossen, maar puur met geschreven policies.

Geen idee of het past maar even droppen: Kan je dan niet een conditional access policy maken welke vanuit de network selectie een block doet naar de IP'adressen van de klant zijn AVD met standaard een block access tenzij je vanuit jullie proces in een CA wordt gezet welke het wel toe staat?

[Gr4mpyC3t]

Blokker_1999 schreef op zaterdag 28 maart 2026 @ 12:13:
Eens zien of hier nog iemand een idee heeft.

Om ondersteuning te geven op de het product dat wij verkopen aan onze klanten (en dat zijn grote bedrijven, geen consumentenspul) hebben we een standaard oplossing om aan de servers bij de klant te komen, maar we zijn flexibel. Wij hebben evenwel de vereiste dat wij van onze kant uit, op automatische wijze, onze gebruikers (zowel support specialisten als consultants in geval van implementaties) toegang moeten kunnen geven en ontnemen. Heb je geen project, ticket of bug, dan hoor je geen toegang te hebben tot die klant.

1 van onze klanten wenst nu evenwel geen gebruik te maken van onze standaard oplossing omdat dat niet in hun beveiligingsmodel past maar wil dat onze mensen gaan verbinden via Azure Virtual Desktops met behulp van een guest account in hun tenant. Ik zie evenwel geen enkele mogelijkheid langs mijn kant om accounts wel of geen toestemming te geven om als guest aan te melden in die specifieke tenant. Weet er iemand of daar wel een mogelijkheid voor is?

Als die organisatie dat wil, dan zit je al snel in de Identity Governance hoek, waar zij onder andere met Access Packages aan de slag moeten.

De access package is dan de aanvraag/onboarding van je collega’s in de tenant van de klant, waarna via automatische groepslidmaatschap (op basis van die access package) iets met Privileged Identity Management moet gebeuren.

Maar dat is nogal een proces en kom ik eerlijk gezegd weinig tegen bij organisaties. Dan moet zo’n klant wel in staat zijn om zo’n proces te bedenken en ook om te zetten in techniek.

Ik wil dat best wat verder uitdiepen voor je als ik tenminste je vraag goed begrepen heb.

[Quad]

Wat is tegenwoordig zo'n beetje de best-practice om gebruikers op phishing-resistant MFA over te stappen?
Met de default MFA krijg je automatisch een implementatie voor de gebruiker om stappen te volgen, maar bij toegangssleutels mis ik dat een beetje.

Iemand een idee?

[HKLM_]

Quad schreef op vrijdag 3 april 2026 @ 09:05:
Wat is tegenwoordig zo'n beetje de best-practice om gebruikers op phishing-resistant MFA over te stappen?
Met de default MFA krijg je automatisch een implementatie voor de gebruiker om stappen te volgen, maar bij toegangssleutels mis ik dat een beetje.

Iemand een idee?

Als je passkeys afdwingt krijg je toch ook zo’n setup schermpje met stappen, vergelijkbaar met de Authenticator of bedoel je dat niet?

[Quad]

HKLM_ schreef op vrijdag 3 april 2026 @ 09:24:
[...]


Als je passkeys afdwingt krijg je toch ook zo’n setup schermpje met stappen, vergelijkbaar met de Authenticator of bedoel je dat niet?

Als ik dat afdwing met CA dan krijgt de gebruiker gewoon een block en kan de gebruiker niets. Dus idd, ik zoek de optie dat gebruikers automatisch de prompt krijgen om toegangssleutels in te stellen.

[HKLM_]

Quad schreef op vrijdag 3 april 2026 @ 09:30:
[...]

Als ik dat afdwing met CA dan krijgt de gebruiker gewoon een block en kan de gebruiker niets. Dus idd, ik zoek de optie dat gebruikers automatisch de prompt krijgen om toegangssleutels in te stellen.

Maar nadat je gebruikers dus al door een MFA setup heen zijn geweest? Ik zou het in de System-preferred authentication zoeken als iemand dan een Authentication strengths heeft met Phishing-resistent MFA zou die moeten triggeren. Eventueel met een CA policy for Register security informatiom.

Registration campaign is ook nog het uitzoeken waard.

[ Voor 26% gewijzigd door HKLM_ op 03-04-2026 09:42 ]

[HKLM_]

Wat zijn jullie ervaringen met de passkey as default voor de users die sms/voice aan hebben staan. Hebben jullie je voorbereid/ er last van in de organisatie?

[Blokker_1999]

Heb het uitgesteld . We beginnen binnen 2 weken met de uitrol van Windows Hello for Business en ook passkeys worden dan in 1 keer meegepakt.

Wel hebben enkele specifieke gebruikers toch de registratiecampagne gezien, en ik begrijp niet goed waarom net die groep gebruikers hem te zien krijgt. Maar als die breed zichtbaar zou zijn voor gebruikers, dan was het tickets aan het regenen, en dat gebeurt gelukkig ook niet.

[F_J_K]

HKLM_ schreef op maandag 28 september 2026 @ 19:16:
Wat zijn jullie ervaringen met de passkey as default voor de users die sms/voice aan hebben staan. Hebben jullie je voorbereid/ er last van in de organisatie?

We hebben sms/voice een tijd geleden al geblokkeerd. Eerst een tijdje broadcasten wat de betere manieren zijn. Daarna de 20% rest actief benaderen via mail, even later de 5% met CC leidinggevenden en uiteindelijk sms/voice via CA geblokkeerd. Waarna een procent (een of twee dozijn) kwam vragen waarom ze niet meer konden inloggen en kwam dat ook goed.

Maar dat was naar authenticator, volgende stap is naar passkey.

[wagenveld]

Is prima en ik snap het ook voor MFA, maar hoe doen jullie dat met SSPR? Want ik meen vanuit CIS wordt aangeraden om minimaal 2 methodes voor SSPR te gebruiken, waar we nu veelal authenticator + SMS gebruiken blijven er nu niet veel opties meer over. Persoonlijke email is niet een praktisch alternatief.

Passwordless is natuurlijk de end state, maar veel organisaties zijn daar nog niet en hebben nog steeds een wachtwoordbeleid wat elke 6 maanden of elk jaar verloopt. Hier dus ook uitgesteld voor een aantal klanten totdat er meer duidelijkheid vanuit MS komt. Hier staan de inmiddels bekende telefoon providers: Choose a telephony provider for SMS and voice authentication - Microsoft Entra ID | Microsoft Learn

[grimson]

wagenveld schreef op dinsdag 29 september 2026 @ 11:41:
Passwordless is natuurlijk de end state, maar veel organisaties zijn daar nog niet en hebben nog steeds een wachtwoordbeleid wat elke 6 maanden of elk jaar verloopt.

Zover ik heb begrepen verloopt het wachtwoord niet automatisch in Entra ID, ook al heb je Entra ID Connect Sync in gebruik met het lokale AD. Het AD‑password policy wordt standaard namelijk niet gesynchroniseerd; alleen de hash gaat mee. Dus binnen Entra ID moet je expliciet een password policy instellen op verloop of Connect Sync instellen de policy te synchroniseren (iig sinds enkele jaren default).

Dat gezegd hebbende, ik ben benieuwd hoe jullie dit doen qua notificaties.

Stel je gebruikt Windows Hello for Business én Entra ID‑wachtwoordverloop: hoe signaleren jullie gebruikers dat hun Entra‑wachtwoord verloopt? WHfB toont immers geen waarschuwing omdat het wachtwoord niet wordt gebruikt tijdens sign‑in. Zover ik kan nagaan is hier native geen oplossing voor (corrigeer mij svp ) maar er is toch vraag om een verlopen password te wijzigen naar aanleiding van een notificatie.

[wagenveld]

Volgens mij gebruiken ze daar een tooltje van manageengine voor - en idd die vlag in Entra Connect. Voor de WHfB gebruikers idd niet zo relevant, maar dat is maar een klein deel van de populatie.

[Quad]

F_J_K schreef op maandag 28 september 2026 @ 22:46:
[...]

Maar dat was naar authenticator, volgende stap is naar passkey.

Ik heb voor een organisatie de registrationcampaign aangezet voor Passkey (FIDO2). Maar tot op heden zie ik in een week tijd slechts 2 nieuwe registraties. Dat lijkt me niet de bedoeling. Het is mij niet helemaal duidelijk wanneer de trigger voor het registreren plaatsvindt.

[F_J_K]

Quad schreef op woensdag 30 september 2026 @ 08:53:
[...]

Ik heb voor een organisatie de registrationcampaign aangezet voor Passkey (FIDO2). Maar tot op heden zie ik in een week tijd slechts 2 nieuwe registraties. Dat lijkt me niet de bedoeling. Het is mij niet helemaal duidelijk wanneer de trigger voor het registreren plaatsvindt.

Wij hebben de campaign even gestopt, kregen foutmeldingen bij registreren van passkeys in bijv. iOS. Eerst zien waar het aan schort.

[Blokker_1999]

Hoewel het een eigen topic zou kunnen maken is het probleem waarmee ik zit zo specifiek dat het mij verspilling van database ruimte lijkt. Benieuwd of iemand dit ooit is tegen gekomen, en even geduld, want het heeft wel degelijk met Entra te maken.

We zijn begonnen met het uitrollen van onze eerste Privileged Access Workstations via AVD. Om hierop aan te melden gebruiken we niet onze standaard gebruikersaccount, maar een admin account. We hebben hierop een conditional access policy geplaatst waarmee we afdwingen dat

• phishing resistant authenticatie gebruikt moet worden
• er elke keer geauthenticeerd moet worden (dus 5 minuten grace period en daarna opnieuw authenticeren)

Dit heeft relatief weinig invloed want als je sessie naar de remote desktop eenmaal is opgezet, wordt er in de basis niet om herauthenticatie gevraagd. Je kan heel de dag in die sessie werken, of totdat je te lang idle bent en dan wordt je er ook af gegooid.

Maar wanneer die verbinding uit zichzelf verbreekt, gaat de Windows App proberen deze verbinding te herstellen, hiervoor heb je een herautenticatie. Als je daar niet op reageert en tot een timeout laat komen, bijvoorbeeld omdat je niet achter je computer zit op dat moment, dan loopt het mis.

Wil je daarna alsnog authenticeren, ongeacht in welke applicatie of met welke gebruiker, met een passkey of Windows Hello for Business, dan opent je browservenster om te gaan aanmelden maar krijg je een relatief generieke foutmelding dat er iets is misgelopen.

Na veel zoekwerk, en met behulp van Copilot gevonden dat het authenticatieprocess ergens vast loopt en blijft hangen. Als ik dan Microsoft.AAD.Brokerplugin.exe kill in taakbeheer, dan werkt de authenticatie opnieuw. Ook wanneer ik CredentialUIBroker.exe de nek omwring kan ik opnieuw verder. Beide processen blijven actief, wat niet hoort.

2 maanden terug een case geopend bij Microsoft, na heel weinig feedback van hun kant uit, vandaag de melding gekregen dat het Directory Services team het ticket niet kan opnemen omdat het foutief zou aangemaakt zijn. Ik moet dus van voor af aan herbeginnen met heel hun support, dat gaat me weer weken kosten om door die first line te zwemmen. Maar het feit dat het dus tot bij het DS team geraakt is, is de reden dat ik de vraag ook even hier stel.

Als test heb ik ook op mijn admin account een passkey aangemaakt en deze opgeslagen in mijn standaard gebruiker zijn Windows Hello for Business container. Als ik dat gebruik om te authenticeren, dan zie ik dit probleem niet, omdat bij herauthenticatie de passkey zelf wel bereikbaar is, althans dat is mijn vermoeden. Maar daar passkeys op dit moment niet in WHfB kunnen in combinatie met attestation is het niet de route die we op dit moment willen nemen. Gebruikers zijn vrij om een fysieke security key te gebruiken danwel de passkey in de authenticator app van Microsoft, ongeacht welke van de 2 methodes gebruikt wordt, het probleem blijft bestaan.

Is er iemand bij wie dit probleem bekend in de oren klinkt?