Microsoft dwingt multifactorauthenticatie op Azure vanaf oktober verder af

Microsoft gaat multifactorauthenticatie afdwingen voor alle vormen van Azure-toegang. Eerder begon het bedrijf al met verplichte mfa voor directe logins voor bijvoorbeeld Azure Portal en Entra, maar nu wordt dat ook verplicht voor api's en de cli.

Microsoft schrijft op een ondersteuningspagina dat het vanaf 1 oktober van dit jaar begint met het afdwingen van multifactorauthenticatie voor alle vormen van Azure-toegang. Het bedrijf noemt specifiek toegang via de command line interface, Azure PowerShell, de mobiele app, REST-api's, library's in de Azure-sdk en infrastructure-as-codetools.

Het gaat om wat Microsoft de tweede fase noemt in een plan om Azure-toegang beter te beveiligen. Vorig jaar zei Microsoft al dat het mfa zou gaan verplichten voor Azure-toegang. Dat gebeurde in twee fases, waarvan de eerste eind 2024 begon. In die eerste fase moesten alle gebruikers mfa inschakelen voor directe toegang tot Azure-omgevingsbeheer via de Portal en de admincenters in Entra en Intune. In maart van dit jaar werd die fase afgerond; sindsdien is iedere gebruiker op mfa over.

Daarom begint nu vanaf 1 oktober 'fase twee', waarbij Azure-beheer via alternatieve kanalen ook beter beveiligd gaat worden. Ook dat gaat geleidelijk, zegt Microsoft, al zegt het bedrijf niet met welke frequentie het de verandering afdwingt. Microsoft gaat deze week beginnen met het e-mailen van admins. Die kunnen dan zorgen dat software, zoals cli-versies en PowerShell, naar de juiste versies worden bijgewerkt, specifiek 2.76 voor Azure CLI en 14.3 voor Azure PowerShell.

Reacties (26)

[HKLM_]

Heel goed, brengt ook gelijk een eind aan service accounts welke eigenlijk helemaal geen service accounts zijn en gewoon onder de user van admin x draaien. En 9/10x een exclude hebben op de MFA binnen conditional access.. Hebben beheerders mooi deze maand om een Managed identities, Service principals als workload identity te configureren op de juiste wijze.

[Reactie gewijzigd door HKLM_ op 8 september 2025 17:31]

[nzall]

wij zitten in de situatie dat we momenteel een user-based service account hebben (aparte user, geen misbruik van een developer's account) die toegang moet hebben tot de Azure Devops API als TFS client, zodat we als onderdeel van onze integratietests in onze build onze TFS integratie kunnen testen, zowel voor source control als voor issue management tool. Werkt één van die drie opties (Managed identity, Service Principal of Workload Identity) vergelijkbaar genoeg met een standaard useraccount dat we er zo ééntje kunnen aanmaken en dan via een access token gewoon dezelfde toegang als daarvoor kunnen hebben, dus zonder dat we onze eigen code moeten aanpassen om een ander soort token telkens opnieuw te moeten genereren via de API?

[Reactie gewijzigd door nzall op 8 september 2025 16:53]

[Aapmansz]

Managed Identity's hebben geen einddatum.
App Registrations wel met een maximum van 2 jaar.

[Joost1981_2]

Ik hoop niet dat je nog TFS hebt. Maar Azure DevOps Services ondersteund gewoon Managed Identities.

[nzall]

Het is een integratie die wij (momenteel nog) ondersteunen in ons product.

Wij hebben die Managed Identities vandaag even kort bekeken, maar het was voor ons niet duidelijk of die Managed Identities gewoon username/password of een equivalent met lange vervaltijd kunt gebruiken op dezelfde manier als bij een reguliere user account, dus met andere woorden gewoon een app password genereren op het platform en dan invullen in de property file en gewoon vergeten tot het bijna vervalt.

[Timmo70]

Een managed identity werkt niet met username/wachtwoord. Het vervangt net wachtwoorden of secrets.
Je geeft de identity rechtstreeks access tot je resources waarmee het moet werken.

Use Service Principals and Managed Identities - Azure DevOps | Microsoft Learn

[nzall]

Ja, dat is nu net het probleem... Onze integratie met TFS werkt momenteel enkel met traditionele username/password credentials. Wij gebruiken ergens een TFS-CLC command line tool of iets in die aard dat ook weer tamelijk verouderd is en voor zover ik weet geen managed identities ondersteunt. Dus als Microsoft effectief binnenkort zegt "wij ondersteunen niet meer het uitchecken van code via username/password credentials, je MOET een Managed Identity gebruiken, dan kunnen wij Azure Devops via TFS niet meer ondersteunen. Maar dat betekent dan ook dat we TFS zelf ook niet meer kunnen ondersteunen, want wij hebben geen lokale TFS server meer staan.

[Johan Wessels]

Zover ik begrijp vallen de Azure DevOps / TFS API’s niet onder de afgedwongen MFA. Je kunt straks dus nog steeds TFS aanspreken met een simpele username/password.

[Bor]

Een managed identity en een service principal zijn voorbeelden van een workload identity. De workload identity is geen 3e optie.

In Microsoft Entra, workload identities are applications, service principals, and managed identities.

Bron: Microsoft learn

[Danferno]

Kan iemand mij vertellen of dit een impact heeft op automated script access via identities? Denk Azure functions die VMs opstarten, of bash scripts die az login gebruiken om toegang te krijgen tot container registries?

[geenstijl]

Als het goed is zijn dit soort dingen ingeregeld via ManagedIdenties en niet via user accounts.

En anders is het aan te raden dit zsm te doen.

[Danferno]

Top, merci!

[3_s]

Pdf, als consultant waarbij we met meerdere collega's op een klantenomgeving moeten kunnen inloggen, is dit maar vervelend. Ja, ik snap de redenen, maar het blijft onhandig.

[WargamingPlayer]

Een beetje serieus bedrijf werkt niet met gedeelde accounts.

[-Vasa-]

Wat een bedrijf wel of niet wilt doen hangt af van de situatie. Als je een kmo moet ondersteunen, maar die ondersteuning door 12 verschillende personen kan gebeuren, gaat die klant de overweging moeten maken of het risico om een gedeelde account (met mfa natuurlijk) aan te bieden in plaats van 12 named accounts te gaan voorzien. Goede security is iets dat vol te houden is ook, niet gewoon een checkboxje op je spreadsheet voor de auditors.

[pieterhi]

Er is ook een mogelijkheid tot OTP en dat icm een credential manager. Dan kan je eenvoudig de bevoegdheid bij iemand onttrekken zonder dat je vanalles moet gaan uitzoeken en aanpassen.

[3_s]

Wij implementeren erp, business central via saas.

Dat is doorheen het project met vijftal verschillende consultants, nadien nog support. Tegen > € 130 per maand per licentie wordt dat al snel veel te duur voor onze KMO-klanten.

[Mimiix]

Gastgebruiker toegang zodat je je eigen licentie meeneemt?

[WargamingPlayer]

€ 130 per user per maand, dat is voor een bedrijf niet zo veel. Als daar al bezuinigd op gaat worden, waar worden dan nog meer shortcuts genomen? Die € 130 per user per maand wordt ook gewoon afgeboekt als kosten en zal netto nog geen fractie zijn. En je praat over maar € 650 per maand voor misschien 5-6 maanden.

[themadone]

jullie krijgen van de klant geen eigen inlog met 2fa? Dat doen wij onprem zelfs lol.

[david-v]

Onhandig is hoe de toegang geregeld is op de klanten omgeving. Als je het sh*t regelt dan is alles natuurlijk vervelend.

[Ruuddie]

Grappig, ik stoor me juist mateloos aan klanten die ons een algemeen 'bedrijfsaccount' willen geven i.p.v. losse accounts voor al mijn collega's die bij ze moeten inloggen. Dat is toch een accident waiting to happen, zo'n algemeen admin account gedeeld door 10 man.

[Erwin1967]

Ik zie niet het verschil met of zonder mfa als je 10 man toegang moet geven tot je systemen. Belangrijker is het beperken van het aantal mensen en enkel die rechten uitdelen die nodig zijn.

[-Vasa-]

Hoewel ik met andere mensen die reageren akkoord ben dat een gedeelde account die je aangeboden krijgt net vervelender is, kan je dit oplossen door een gedeelde telefoon/tablet die je op kantoor laat liggen. Er van uitgaande natuurlijk dat er altijd wel iemand op het kantoor aanwezig is.

[ytterx]

Moet het wel werken... krijg gewoon de mfa berichten niet binnen, wat je ook insteld..

[Audiodude]

Ik heb nog niets gehoord voor mijn domein. Ik hoop wel dat via conditional access MFA excluded accounts gewoon kunnen blijven bestaan, want zelfs niet alle APIs van MS kunnen werken met een managed user of system identity of met service principals.

Vooral PowerBI is qua APIs nog een drama.