[English]Kleiner Nachtrag einer Information, die eigentlich schon seit Mitte Mai 2024 bekannt sein sollte. Microsoft will die Sicherheit von Azure-Benutzerkonten verbessern. Deshalb macht Redmond die Multifactor-Authentifizierung (MFA) für alle Azure-Nutzerkonten verpflichtend. Die Umsetzung soll ab Juli 2024 beginnen, aber in Schritten ausgerollt werden.
Anzeige
Ab Juli 2024 startet die Umstellung
Die Information ist an mir vorbei gegangen, aber ein Nutzer hat mich auf Facebook auf diesen Sachverhalt hingewiesen (danke dafür). Microsoft hat dazu bereits zum 17. Mai 2024 den Techcommunity-Beitrag Microsoft will require MFA for all Azure users veröffentlicht. Die Botschaft in diesem Beitrag: Im Juli 2024 beginnen die Azure-Teams mit der Einführung zusätzlicher Sicherheitsmaßnahmen auf Mandantenebene (Tenant-Ebene), die eine Multi-Faktor-Authentifizierung (MFA) erfordern.
Multi-Faktor-Authentifizierung (MFA) ist eine Sicherheitsmethode, bei der Benutzer zwei oder mehr Nachweise erbringen müssen, um ihre Identität vor dem Zugriff auf einen Dienst oder eine Ressource zu überprüfen. Der Nachweis kann etwas sein, das der Benutzer weiß (z. B. ein Passwort oder eine PIN), etwas, das der Benutzer hat (z. B. ein Telefon oder ein Token), oder etwas, das der Benutzer ist (z. B. ein Fingerabdruck oder ein Gesichtsscan), schreibt Microsoft.
Durch die Einführung dieser Sicherheitsgrundlagen auf Tenant-Ebene soll eine zusätzliche Sicherheit zum Schutz der Cloud-Dienste bzw. Konten der Unternehmen geschaffen werden. Die Anmeldung an einem Azure-Nutzerkonto erfordert nach der Umstellung einen zweiten Faktor zur Freigabe. Die bisherige Standardauthentifizierung mittels Benutzername und Kennwort reichen dann nicht mehr aus.
Schrittweise Umsetzung geplant
Microsoft schreibt, dass die Umsetzung der MFA-Anmeldung für Azure Nutzerkonten schrittweise und methodisch erfolgen werde, um die Auswirkungen auf Anwendungsfälle der Kunden zu minimieren. Der Blog-Beitrag Microsoft will require MFA for all Azure users enthält hilfreiche Informationen des Azure-Produktteams, die Kunden bei der Vorbereitung auf die MFA-Aktivierung des Zugangs zu Azure-Diensten unterstützen sollen.
Das Azure-Team will die Kunden zudem zukünftig durch direkte E-Mails und Azure-Portal-Benachrichtigungen über den spezifische Einführungsdaten informieren. Entsprechende Informationen sind in den kommenden Monaten zu erwarten. Wer bereits jetzt MFA für den Zugang zu Azure-Nutzerkonten umsetzen möchte, kann dies über Microsofts Entra ID durchführten.
Anzeige
Entra ID unterstützt verschiedene MFA-Methoden, wie die Microsoft Authenticator-App, SMS, Sprachanrufe und Hardware-Tokens. Benutzer können die Methode wählen, die am besten ihren Bedürfnissen entspricht. Administratoren können auch Entra ID Richtlinien für den bedingten Zugriff verwenden, um einzustellen, wann MFA erforderlich ist, basierend auf Signalen wie dem Standort des Benutzers, dem Gerät, der Rolle oder der Risikostufe. Weitere Details lassen sich dem verlinkten Techcommunity-Beitrag entnehmen.
Anzeige
Vielleicht für den ein oder anderen noch wissenswert:
Wer keine Entra AD Lizenz hat, kann den "bedingten Zugriff" nicht konfigurieren und wird im ersten Moment gezwungen, die MFA über ein OTP-fähiges Gerät einzurichten.
Eine Telefonnummer hierfür zu verwenden ist zum Beispiel erst im nachhinein verwendbar.
Du kannst mal unter "Identity" -> "Overview" -> "Properties" -> "Security defaults" -> "Manage security defaults" schauen, das könnte im Zweifel für Entra AD auch ausreichen, dass man kein MFA benötigt.
Wir wollen ja MFA, allerdings auch z.B. per Anruf da nicht jeder ein Firmenhandy hat und BYOD nicht gewünscht ist.
Der "Zwang" zum Authenticator ist da eben etwas hinderlich.
Bei deiner Variante ist natürlich fraglich, wie lange das hält.
MS spricht hier ja von einem generellen Ausrollen der MFA.
Die Security Defaults sind ja bei Erstellung des Tenants eh aktiviert.
Wenn ich mir Feature Matrix anschaue (https://m365maps.com/matrix.htm#111111110001001001001) dann kann jeder die MFA nutzen und konfigurieren, somit inkl SMS (Unsecure), Anruf, App, HW Token
Ja genau.
Und wenn man sich das Feature genauer anschaut kommt folgendes raus:
Zitat:
"Sie können Sicherheitsstandards in Microsoft Entra-Mandanten verwenden, um Microsoft Authenticator schnell für alle Benutzer*innen zu aktivieren."
"Für die genauere Steuerung können Richtlinien für bedingten Zugriff verwendet werden[…]"
Es ist also genau so wie ich es geschrieben habe.
Erst Authenticator bzw. andere taugliche App, dann alles weitere.
Kein Smartphone, kein MFA.
Schade Schokolade.
Hier ist die Übersicht in Tabellenform, wann andere Faktoren mit welcher Lizenzform möglich sind (https://learn.microsoft.com/de-de/entra/identity/authentication/concept-mfa-licensing#feature-comparison-based-on-licenses).
Telefonanruf ist für Office 365, Entra ID P1 & P2 möglich.
Umkehrschluss wer NUR Entra ID "Free" für Benutzer nutzt, kommt um eine App nicht drumherum, da kann ein WinAuth auch reichen, ob das Sinnvoll ist ist dann was anderes ;-)
Ich finde es immer seltsam wenn Microsoft die Kunden zur "Sicherheit" zwingen möchte aber es bei sich selbst nicht auf die Kette bekommt. Klar mit dem Passwort 123456 ist alles unsicher aber ob es grundsätzlich mit Benutzername und Passwort unsicher ist wage ich zu bezweifeln. Außerdem wenn das Gerät für den zweiten Faktor mal abhanden kommt oder aus irgendeinem Grund kein Zugriff auf den Telefonanschluss zur angegebenen Nummer besteht, z.B. Akku vom Handy leer, Handy verloren, Handy defekt da sieht es schon duster aus.
Hallo! Das ist nicht richtig.
Wer M365/Azure im Business Umfeld einsetzt, muss bei der MFA Einrichtung immer 2 Alternativen konfigurieren. Also einmal z.B. den Authenticator und dann noch eine Handynummer oder auch eine alternative Mailadresse, eine Festnetznummer.. Es gibt einige Alternativen. Es wird nie auf nur eine Möglichket gesetzt. Da ist Microsoft schon nicht ganz so doof wie dargestellt.
Zudem geht es bei der MFA ja auch gar nicht in erster Linie darum, dass BenutzerName in Verbindung mir einem komplexen Passwort ( und es sollte wirklich komplex sein, denn alles unter 10 Zeichen und nicht mit mind. Zahlen, Buchstaben, Sonderzeichen, Groß-/Klein-Schreibung ist in Minuten bei Brute Force Angriffen geknackt) unsicher sei. Es geht darum, dass ein Dritter, der dein Passwort "gefunden" hat, sich eben nicht einloggen kann, denn er hat den zweiten Faktor hoffentlich nicht. Wäre schon komisch wenn er dein Handy auch noch hätte oder Zugang zu einem weiteren Faktor.
Es ist also kein Unsinn. Bei deinem Online-Banking nutzt du ja auch MFA. Das ist Standard bei Banken. Wenn das bei deiner Bank anders ist, dann gib gerne mal Deine Zugangsdaten. Ich buch auch nicht zu viel ab :-D
Microsoft macht also nur das, was Banken schon lange tun.
Wie häufig kommt das vor und wo ist das Problem sich dann kurz an den Admin zu wenden und einen befristeten Zugriffspass einrichten zu lassen.
Dieser kann für 7 Tage als Ersatz für MFA verwendet werden.
Ich finde es in der heutigen Zeit schon ziemlich fahrlässig ohne MFA unterwegs zu sein, auch wenn MFA keine 100% Sicherheit bringt.
Wenn man 10'000+ User hat, dann ist das schon etwas mehr Aufwand, aber das IT-Team ist dann sicher auch etwas grösser.
Wir haben ca. 2'000 und keine grossen Probleme mit MFA. Die paar wenigen Anfragen im Monat aufgrund von Handy verloren oder ähnliches sind bei uns fast vernachlässigbar.
Naja dafür hast du ja immer noch den emergency Account, falls wirklich alle anderen Zugänge weg sein sollten. Das ist schon ein sehr unwahrscheinliches Szenario
naja in managed Umgebungen lässt du dir dann einen TAP (Temporary Access Pass) ausstellen.
Beim anderen Punkt bin ich ganz bei dir. Finde das Verhalten sehr komisch, Kritik wird laut, dass MS seine Security nicht im Griff haben, und die Reaktion, die sie bieten ist quasi die Schuld auf die User zu schieben, weil die nutzen ja "nur" User und Password.
MFA beudetet "Multi-Factor Authentication", somit gibt es mehrere Faktoren und wenn es komplett ausschöpfen will, kannst doch imho zwei Authenticator Installationen, SMS , drei Telefonnummer und diverse HW Token nutzen. Die Chance das alle Faktoren nicht funktionieren, ist wohl sehr gering bzw. hast dann ein anderes Problem, ob überhaupt noch ein Job hast :D
Die MFA alleine macht es nicht aus, sondern in Kombination mit Conditional Access und bei Admins min noch mit PIM (Entra ID P1/P2).
Laut einem MS-Kommentar (https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/microsoft-will-require-mfa-for-all-azure-users/bc-p/4143356/highlight/true#M6078) gilt das aber offenbar nicht für alle Anwendungen sondern nur für "All users signing into Azure portal, CLI, PowerShell, or Terraform to administer Azure resources are within the scope of this enforcement."
Zu den End-Usern heißt es:"
Impact on end users: Students, guest users and other end-users will only be affected if they are signing into Azure portal, CLI, PowerShell or Terraform to administer Azure resources. This enforcement policy does not extend to apps, websites or services hosted on Azure. The authentication policy for those will still be controlled by the app, website or service owners."
Das klingt also doch schon halb so wild.
Dennoch wäre der durchgängige Einsatz von MFA und Conditional Access beim Zugang auf M365/Azure Business Accounts das Sicherste. Es sollte jede Organisation durchweg einsetzen, um kompromittierte Umgebungen zu vermeiden und nach einem erfolgreichen Abfischen von Zugangsdaten eine spätere Ransomware Attacke erst gar nicht möglich machen.
Dennoch wäre der durchgängige Einsatz von MFA und Conditional Access beim Zugang auf M365/Azure Business Accounts das Sicherste. Es sollte jede Organisation durchweg einsetzen, um kompromittierte Umgebungen zu vermeiden und nach einem erfolgreichen Abfischen von Zugangsdaten eine spätere Ransomware Attacke erst gar nicht möglich machen.
Wird das auch Auswirkungen auf die Anmeldung von den AVDs haben ?
Kommt imho auf die verwendete Identität an, wenn der UPN im Entra ID als Admin flagged ist sicherlich, wer "lokal" auf virtuellen Kiste umherschwirrt, geht das dann wohl nicht wirklich.
Und ich dachte Passkeys sind der neue heiße Scheiß bei Microsoft
Windows Hello ist doch ein alter Hut und geht schon seit etlichen Jahren wer Passwordless mit kompt Hardware (TPM & Kamera) arbeiten will.
Und was willst du damit nun sagen?
Passkey IST MFA
Dumme Frage, sind damit nur die Admin Konten gemeint oder jeder User der ein Office 365 Konto hat?
M$ hat wohl noch nie was von mTLS im Speziellen und Zertifikaten im Allgemeinen gehört. Nur einfach einen Schrott deployen und meinen, das wäre dann Sicherheit. Sicherheit und Microsoft sind einfach nur orthogonal zueinander.
Das ist wohl der wichtigste Post unter dem Artikel ( https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/microsoft-will-require-mfa-for-all-azure-users/ba-p/4140391 )…
Hello everyone, my name is Naj Shahid and I am a product manager in Azure leading this initiative. I am sharing some information below that should help with your questions.
Scope: All users signing into Azure portal, CLI, PowerShell, or Terraform to administer Azure resources are within the scope of this enforcement.
Impact on end users: Students, guest users and other end-users will only be affected if they are signing into Azure portal, CLI, PowerShell or Terraform to administer Azure resources. This enforcement policy does not extend to apps, websites or services hosted on Azure. The authentication policy for those will still be controlled by the app, website or service owners.
Exclusions: Service principals, managed identities, workload identities and similar token-based accounts used for automation are excluded. Microsoft is still gathering customer input for certain scenarios such as break-glass accounts and other special recovery processes.
MFA Methods: All supported MFA methods are available for you to use.
Exceptions: While there will be no opt-out, an exception process will be provided for cases where no workaround is available. Details for the exception process will be shared via official notifications.
Timeline: Beginning July 2024, a gradual rollout of this enforcement for portal only will commence. Once we have completed the rollout for portal, a similar gradual rollout will start for CLI, PowerShell and Terraform. We understand the impact this enforcement could have on automated scripts using user identities and thus are prioritizing enforcement for Azure portal to provide additional time to adapt if needed.
Communication: Microsoft will send detailed information and timelines through official emails and notifications with advanced notice to ensure customers are well informed and prepared. The purpose of this blog post was to generate awareness about this upcoming change and help you prepare for transition to multi factor authentication.
As Erin mentioned in the post above, don't wait to set up MFA. Keep users and data safe by setting up MFA with the MFA wizard for Microsoft Entra. Microsoft recommends examining which Entra IDs are used with dev ops and API access to Azure Resource Manager. As needed, learn how to replace user identities with service principals and managed identities.
Sincerely,
Naj Shahid
Principal Product Manager
Microsoft Azure
Vielleicht überlese ich etwas, aber wird das auch für die MS365 Education Lizenzen so sein?
Als Admin für mehrere Schulen graut es mir davor.
Guten Tag,
bei uns haben alle globalen Admins des Tenants eine E-Mail mit den folgenden Eckdaten erhalten, vielleicht hilft das bei der Suche weiter:
Von: Microsoft Security
An:
Betreff: Wichtig: Wir werden bis zum , die Sicherheitsverbesserungen für Ihre Organisation aktivieren
Erster Abschnitt des E-Mail Body: Die Einstellung für die Sicherheitsstandards für Ihren Mandanten wird von , aktiviert
Ups, da ist mir wohl ein Fehler unterlaufen. Ich habe vergessen, dass spitze Klammern / Pfeile natürlich als HTML-Tags interpretiert werden (ich weiß, Anfängerfehler, verzeiht mir :)). Hier noch einmal die richtige Variante:
Von: Microsoft Security (mssecurity-noreply(at)microsoft(dot)com)
An: (globaler Tenant-Admin)
Betreff: Wichtig: Wir werden bis zum (Wochentag), (Tag) (Monat) (Jahr), die Sicherheitsverbesserungen für Ihre Organisation aktivieren
Erster Abschnitt des E-Mail Body: Die Einstellung für die Sicherheitsstandards für Ihren Mandanten wird von (Wochentag), (Tag) (Monat) (Jahr), aktiviert