Microsoft maakt meerstapsverificatie verplicht voor Azure-gebruikers

Microsoft Azure rolt vanaf juli een nieuwe beveiligingsmaatregel op tenant-niveau uit. Alle gebruikers moeten dan meerstapsverificatie geactiveerd hebben om toegang te krijgen tot Azure-diensten. De nieuwe maatregel wordt geleidelijk uitgerold, benadrukt Microsoft.

Microsoft stelt in eigen onderzoek dat 99,9 procent van alle gecompromitteerde accounts geen meerstapsverificatie gebruikt. Ook blijkt uit dat onderzoek dat mfa meer dan 99,2 procent van alle aanvallen om accounts te compromitteren kan blokkeren. "Dat maakt het een van de effectiefste beschikbare beveiligingsmaatregelen", aldus het bedrijf in een aankondiging.

Daarom besluit het bedrijf nu om mfa verplicht te stellen voor alle Azure-accounts. De maatregel wordt vanaf juli geleidelijk uitgerold, wat betekent dat de regel niet voor alle gebruikers tegelijk gaat gelden. In de komende maanden gaat Microsoft naar gebruikers communiceren wanneer de regel precies ingaat. De communicatie verloopt via e-mails en via notificaties in het Azure Portal. Mfa is gratis op tenantniveau in te schakelen via de wizard voor Microsoft Entra. Ook is er een faq beschikbaar gesteld over mfa.

Uit reacties onder de aankondiging blijkt dat er nog enige onduidelijkheid bestaat over de gestelde maatregel. Gebruikers vragen zich af of de maatregel ook gaat gelden voor bijvoorbeeld serviceaccounts. Microsoft heeft op het moment van schrijven niet op deze vragen gereageerd.

Door Eveline Meijer

Nieuwsredacteur

16-05-2024 • 15:07

59

Submitter: robcoenen

Reacties (59)

59
59
16
1
0
37
Wijzig sortering
Er is in het bronartikel nu ook een reply geplaatst door een Microsoft medewerker die de scope van de maatregel wat verduidelijkt:

https://techcommunity.mic...2574/highlight/true#M6071

"MFA will be required when logging in to the azure portal (portal.azure.com) and the entra portal (entra.microsoft.com)."
Die MFA requirements voor admin portals zaten er al een tijd aan te komen
https://www.microsoft.com...line-identity-protection/
Zoals meerdere mensen al aangeven in de reacties onder de aankondiging; hoe ziet Microsoft het voor zich dat studenten 2FA gaan gebruiken? Mobiele telefoons zijn in Nederland verboden in de klas (en in sommige gevallen op het schoolterrein). Daarbij vind ik 'vanaf juli' wel bijzonder vlot voor zo'n ingrijpende wijziging.
Dit lijkt mij te gaan over het inloggen op de beheersinterface van Azure, en dus niet van toepassing op de doorsnee leerling/student :)
Je zou gelijk kunnen hebben.. in dat geval ben ik helemaal voor. Maar in de aankondiging wordt niet echt duidelijk om welke accounts het nu precies gaat.
Lijkt mij ook, in een organisatie die gemanaged wordt mag de administrator zelf aangeven of 2FA wordt gebruikt.
Tenzij het een IT opleiding betreft waarbij studenten hun eigen tenants hebben. Maar dan zou je nog met Yubikeys kunnen werken.
Je kan gewoon een software OTP nemen, heb ik ook in mijn wachtwoord manager.
Dan heb je geen telefoon nodig.

Dit is dus een non issue.
Nadeel van je OTP in je password manager hebben is de gratis toegang die je overal op geeft als men in je PWM komt.

Dat is precies de reden dat mijn OTPs uit 2 apps komen, 1 met alle OTPs en 1 extra waarmee ik in de kluis van de “verzameling” kan komen.

Omslachtig maargoed ik durf wel te stellen dat ik niet zomaar gegevens kwijt raak.
studenten kunnen natuurlijk perfect MFA doen zonder enige vorm van mobiele telefoon.

Je hebt nl oa:
  • Windows Hello
  • OTP softtokens
  • OTP Hardware tokens
  • Ubikeys
Hoe gebruik ik Windows Hello voor portal.azure.com MFA?
Hello is een strong auth, je cap policy zegt strong auth niet user initiated mfa.

Het is strong auth omdat het is iets wat je hebt en iets wat je weet.

Niet dat het een best practise is voor de admin portal daar wil je als auth context phish resistend mfa, plus no user risk plus no device risk plus managed device en als het even kan alleen vanaf paw.

[Reactie gewijzigd door Scriptkid op 23 juli 2024 08:59]

daar heb je vast een conditional access regel voor waarmee je dit kan omzeilen :)
(hoop ik dan maar...)
CA policies. En mocht die licentie te duur zijn, dan per-user MFA settings -> bepaalde IP ranges excluden.
2FA hoeft toch niet via een telefoon te gaan? Er zijn ook desktopapps en zelfs webapps die 2FA-codes kunnen genereren.
Waarom is het nodig om een mobiele telefoon te hebben voor MFA?
En bijzonder vlot is het niet, dit zat er al minstens drie jaar aan te komen.
Dat word weer een hoop telefoontjes van klanten maar wel goed dat ze het gaan verplichten.
Wat een slecht bronartikel, comments eronder zijn ook niet mals ....

Inderdaad, wat met Break Glass accounts? Of SERVICE accounts bv ?
En dan ook uitrollen in juli als iedereen op vakantie is.
Serviceaccounts? Ik mag hopen dat men ondertussen toch gewoon GMSA gebruikt .. ? Of bedoel je wat anders met service accounts?
GMSA --> ik denk dat je hierbij bedoelt Group Managed Service Accounts
Dat is voor on-premise active directory

Wat ik bedoel is dat er ook wel accounts kunnen zijn in AzureAD (Entra ID) die door applicaties / geautomatiseerde systemen worden gebruikt die nog geen native support hebben voor iets als service principals.
Ja daar doelde ik inderdaad op, ik weet eerlijk gezegd ook niet precies hoe Entra hiermee omgaat tegenwoordig. Ben een andere tak binnen IT gaan beoefenen een tijdje geleden en die ontwikkelingen gaan wat langs me heen.
Scanto e-mail op printers bijv.?
Dat is inderdaad ook een van die toepassingen
Die gaan via onprem appliance of een oauth api zoals graph of sendgrid.
Dat kan op een andere manier in Azure, gewoon via poort 25 zonder login.
Dan zou dus iedereen een email namens elk willekeurig domein kunnen sturen. Of begrijp ik je verkeerd?
Het gaat om de toegang tot de portal. Services (of printers) zullen hier dus niet door beïnvloed worden.
Break Glass accounts kan je excluden van je CA policies en op die manier MFA skippen. Nog beter is het gebruik van meerdere Break Glass accounts, allemaal met een eigen MFA methode. Op die manier heb je altijd toegang. Bijvoorbeeld eentje met MS Authenticator en een ander met sms. Vervolgens auditing op die accounts, zodat je een alert krijgt zodra ingelogd wordt met zo'n soort account.

Service accounts? Bedoel je service principals? Die hebben sowieso geen passwords en MFA, maar een secret of certificate. En eigenlijk heb je daarvoor managed accounts nodig.

Voor guest accounts is het best practice om authentication te laten doen door de B2B partner en daarmee ook de MFA eis. Authorization doe je vervolgens zelf.

Microsoft stuurt al vele jaren erop aan om MFA in te stellen voor alle gebruikers en middels CA policies te bepalen wanneer MFA nodig is. Voor wie dit als een verassing komt, heeft onder een steen geleefd.

[Reactie gewijzigd door segil op 23 juli 2024 08:59]

Als Microsoft het nu gaan aanzetten dat ALLE users moet inloggen met MFA, is het excluden met CA niet relevant, daar gaat dit namelijk over.
jawel, want ik geloof niet dat MS een system-wide aanpassing maakt, die elke CA policy overruled. CA policies i.c.m. risky users zijn juist in het leven geroepen om MFA fatique tegen te gaan. Het zou een beetje gek zijn om dat nu ineens overboord te zetten :)

Microsoft heeft de laatste paar jaar al default CA policies uitgerold om MFA af te dwingen voor bepaalde directory roles. En die policy kan je ook uitzetten, alleen krijg je dan wel een melding.
Service accounts is al jaren een best practice om in te laten loggen met MFA en ook je breaking glass account dient 1 van de 2 gewoon MFA te hebben en de andere strong auth wat beteken een ubikey = MFA
Inmiddels ben ik van mening dat een break glass account juist wel MFA moet hebben. Als de MFA computer van Microsoft faalt, dan is het leuk dat je breakglass nog wel de tenant in kan, maar je schiet er toch niets mee op. Overige admins moeten juist worden geblokkeerd voor MFA en minimaal phishing resistant hebben.

Service accounts kun je prima uitzonderen in je CA policies. Je kunt bijvoorbeeld Legacy Auth voor ze inschakelen en hun toegang beperken tot alleen trusted IPs.
Break glass account zouden op papier in een (twee) fysieke kluis of kluizen moeten liggen.
Service Accounts laat je managen door een password manager, bijvoorbeeld CyberArk.
Het gaat er om dat die accounts ineens nu MFA moeten hebben terwijl dat nu juist niet wenselijk is (is immers niet persoonsgebonden)
Goede zaak, maar veel handelingen in de Azure Portal ondersteunen nog geen MFA Entra accounts.
Grappig, ik kreeg vandaag ineens de melding dat het verplicht was. :P
Grappig dat je het nog niet ingesteld had.
Ik kreeg de melding ook. Als je CA policies enigszins afwijken van de templates, krijg je de melding al. Een voorbeeld:

Als je een "MFA for all accounts" hebt en je selecteert de volgende auths niet:
• Browser
• Modern Auth
• Activesync
• Legacy auth
Dan is MFA wel degelijk actief, maar gaat je securescore niet omhoog. Selecteer je deze vier wel dan is dat effectief gezien hetzelfde maar gaat je securescore wel omhoog.

Het uitzonderen van bijv. een breakglass zorgt er al voor dat je de melding krijgt.
Geen verrassing. Persoonlijk heb ik het idee dat er momenteel veel wordt aangevallen op de account, krijg de hele week al op de gekste momenten het verzoek om een code af te geven. Ook van een account die ik zelden gebruik.
If you didn't request this code, you can safely ignore this email. Someone else might have typed your email address by mistake.
Mistake? On purpose ligt hier meer voor de hand.
Somebody is currently trying to hack your account.
Dan zullen ze pas veel angstige telefoontjes op de helpdesk krijgen... :)
Het bericht is ontzettend vaag. ".. your access to Azure services.. ".
Mijn eerste gedachte zou dan zijn: dat is voor toegang tot de Azure portal.
Het gros van de gebruikers komt daar nooit, en heeft daar geen last van. Dit is vooral voor IT'ers.

Maar, de titel spreekt van ".. for all Azure users".
Dat is meer dubieus, want wellicht dat men alle gebruikers in Entra ID zien als 'Azure gebruikers'?
Wat zijn 'Azure services'?
Office applicaties? Teams? Power BI?
Lijkt me wel aangezien je het instelt in Entra ID. Wat ik me dan kan voorstellen is dat ja, het is voor Azure Portal. Maar als je een eigen applicatie hebt (al dan niet gedeployed op Azure) en gebruikersbeheer / authenticatie / authorisatie van die applicatie gaat ook via Entra ID, dan gaat MFA dus ook gedwongen aan voor die applicatie.

Maar het blijft erg vaag beschreven, dus garantie tot aan de deur. Ik kan me voorstellen dat Microsoft momenteel een oepsje aan het voorbereiden is en wellicht de uitrol nog even gaat uitstellen.
Volgensmij gaat het er over uit dat de 2 policies die al maanden aan wezig zijn en in reporting only staan dat die actief zullen worden gemaakt als je die niet zelf disable hebt gemaakt.

https://www.microsoft.com...ectory&searchterms=183905
Wie weet hoe je 2FA kunt herstellen als de Microsoft Authenticator backup niet meer werkt ?

Ik heb namelijk een (.onmicrosoft.com) account Microsoft Entra ID Free tier en kom er niet meer in omdat 2FA is vereist.

Je kunt ook niks veranderen in de instellingen want daarvoor is een tweede factor noodzakelijk.

Kortom de kip en het ei, dus ik zit vast.

Herstel met SMS of per telefoon werkt niet.

https://imgur.com/3eEJdeQ

[Reactie gewijzigd door Mapje op 23 juli 2024 08:59]

http://aka.ms/mfasetup zou je dan moeten gebruiken. Als dat niet werkt, aan je Azure admin vragen of hij een MFA re-register wil laten forceren (is een knopje in Entra onder je account).

Edit:
Ben je zelf de (enige) admin, ticket loggen bij Microsoft Support, dat zij een MFA reregister kunnen afdwingen.

[Reactie gewijzigd door walteij op 23 juli 2024 08:59]

Dat gaat mij dan dus een onderhoudsabonnement van $ 29 p/mnd kosten als ik het goed zie.

Ontwikkelaar want ik heb nu Basis (geen support).
Ik zie onder Basic dat je 'gewoon' support kunt aanvragen, er zit alleen geen SLA aan gekoppeld, dus het kan even duren voordat je iets hoort. Issue is wel dat ze willen dat je inlogt om het support ticket te registreren en daar zit natuurlijk weer een probleem in jouw geval.
Kan je niet kiezen voor gebruiken van sms als fallback? Dat is wat ik heb ingesteld
Heb ik gezien, maar wanneer ik dit aanzet kan ik nergens een telefoonnummer opgeven ik zie dan ook deze (nieuwe) aanmeldoptie niet bij inloggen.
Gewoon een ticket submitten bij Microsoft? Net als dat je jezelf hebt uitgesloten middels CA, kun je ook hiervoor gewoon toegang krijgen. Dit is een procedure die je sowieso eens moet testen in de praktijk. Zet een block all op een testtenant en bel Microsoft, om te controleren of je procedure goed is beschreven.

Op dit item kan niet meer gereageerd worden.