[English]Am heutigen 1. Februar 2019 kam es wohl zu einem kurzzeitigen Azure Active Directory-Ausfall. Im Rahmen der Recherche habe ich dann auch einige Informationen gefunden, warum Microsoft seit dem 29. Januar 2019 unter Ausfällen seiner Cloud leidet.
Anzeige
Kunden der Microsoft-Cloud leiden ja seit Tagen unter sporadischen Ausfällen, bei denen Dienste nicht erreichbar sind. Ich hatte zeitnah hier im Blog darüber berichtet (siehe Artikellinks am Beitragsende). Selbst der Windows Updatedienst wurde davon nicht verschont. Seit heute Mittag ca. 14:30 kann ich hier mit meinem Clients wieder Updates abrufen. So viel als Vorbemerkung.
Azure Active Directory-Ausfall (1. Feb. 2019)
Als ich eben meinen Twitter-Stream durchgegangen bin, stieß ich auf eine neue Störungsmeldung von Tero Alhonen, der in Nordeuropa sitzt und über einen Azure Active Directory-Ausfall berichtet. Zwischen 8:05 und 10:00 Uhr UTC (also 9:05 und 11:00 Uhr deutscher Zeit) kam es am 1. Februar 2019 zu diesem Ausfall beim Azure Active Directory.
Issues we had this morning accessing Azure Active Directory have been fixed https://t.co/1w75mhxxaL pic.twitter.com/Hn8fb0phGK
— Tero Alhonen (@teroalhonen) 1. Februar 2019
Betroffen waren einige Kunden in Europa (u.a. Frankreich, Niederlande, Tschechien). Es waren diverse Dienste, auch Microsoft Teams, mit Mitleidenschaft gezogen. Hier die Statusmeldung mit den Details:
Anzeige
Active Directory – Mitigated
Between 08:05 and 10:00 UTC on 01st Feb 2019, a small subset of users in certain countries in Europe including France, Netherlands, Hungary, Czech Republic may have experienced intermittent issues while accessing functionality in Azure Portal, Azure Active Directory B2C, Azure Active Directory Privileged Identity Management, Managed Service Identity, Azure RBAC and Microsoft Teams.
Engineering team have applied mitigation and all impacted services have been recovered 10:00 UTC.
Engineers are continuing to monitor the health of all impacted services to ensure full mitigation.
Diese Störung ist inzwischen behoben, die Azure-Dienste sollten wieder wie gewohnt arbeiten.
Ursache für die Ausfälle (29./30. Januar 2019)
In der Seite für Azure-Störungen finden sich inzwischen auch Einträge, warum es in den vergangenen Tagen zu Problemen kam.
30.1.2018: Störung in den USA
Die Störungen vom 30. Januar 2019 im Westen der USA wurden durch Netzwerk-Timeouts verursacht. Als vorläufige Ursache wurde der Ausfall von Netzwerkgeräten nach einer routinemäßigen Netzwerkwartung angegeben. Diese wirkten sich intermittierend auf die Azure Services aus, was erklärt, warum die Leute nur sporadische Probleme bemerkten.
29.1.2019: RCA – Network Infrastructure Event
Ab dem 29. Januar 2019 21:00 UTC bis zum 30. Januar 2019 00:10 UTC (in Deutschland ist das alles eine Stunde später) gab es Probleme beim Zugriff auf Microsoft Cloud-Ressourcen. Hier der Microsoft Text der Root Cause Analyse (RCA). Zudem gab es intermittierende Authentifizierungsprobleme bei mehreren Azure-Diensten, die die Azure Cloud, die US-Regierungs-Cloud und die deutsche Cloud betrafen.
Summary of impact: Between 21:00 UTC on 29 Jan 2019 and 00:10 UTC on 30 Jan 2019, customers may have experienced issues accessing Microsoft Cloud resources, as well as intermittent authentication issues across multiple Azure services affecting the Azure Cloud, US Government Cloud, and German Cloud. This issue was mitigated for the Azure Cloud at 23:05 UTC on 29 Jan 2019. Residual impact to the Azure Government Cloud was mitigated at 00:00 UTC on 30 Jan 2019 and to the German Cloud at 00:10 UTC on 30 Jan 2019.
Azure AD authentication in the Azure Cloud was impacted between 21:07 – 21:48 UTC, and MFA was impacted between 21:07 – 22:25 UTC.
Customers using a subset of other Azure services including: Microsoft Azure portal, Azure Data Lake Store, Azure Data Lake Analytics, Application Insights, Azure Log Analytics, Azure DevOps, Azure Resource Graph, Azure Container Registries, and Azure Machine Learning may have experienced intermittent inability to access service resources during the incident. A limited subset of customers using SQL transparent data encryption with bring your own key support may have had their SQL database dropped after Azure Key Vault was not reachable. The SQL service restored all databases.For customers using Azure Monitor, there was a period of time where alerts, including Service Health alerts, did not fire. Azure internal communications tooling was also affected by the external DNS incident. As a result, we were delayed in publishing communications to the Service health status on the Azure Status Dashboard. Customers may have also been unable to log into their Azure Management Portal to view portal communications.
Dieses Problem wurde für die Azure Cloud um 23:05 UTC am 29. Januar 2019 behoben. Die verbleibenden Auswirkungen auf die Azure-Cloud wurden am 30. Januar 2019 um 00:00 Uhr UTC und am 30. Januar 2019 um 00:10 Uhr UTC auf die deutsche Wolke gemildert.
Laut meinen Blog-Beiträgen begannen die Schwierigkeiten aber Stunden vorher und dauerten wohl auch länger an. Aber das sind nur Feinheiten.
Interessant ist die Begründung, warum diese Störung auftrat. Schuld war ein externer DNS-Server-Betreiber, bei dem es nach einem Software-Update zu einem globalen Ausfall der DNS-Infrastruktur kam. Im Zusammenhang mit den Windows Update-Problemen ist mir der Name Comcast unter die Augen gekommen – wenn dieser Anbieter auch nicht im Microsoft-Statusbericht genannt wird. Hier die Microsoft-Erklärung zum Root Cause:
Root Cause: An external DNS service provider experienced a global outage after rolling out a software update which exposed a data corruption issue in their primary servers and affected their secondary servers, impacting network traffic.
A subset of Azure services, including Azure Active Directory were leveraging the external DNS provider at the time of the incident and subsequently experienced a downstream service impact as a result of the external DNS provider incident.
Azure services that leverage Azure DNS were not impacted, however, customers may have been unable to access these services because of an inability to authenticate through Azure Active Directory.
An extremely limited subset of SQL databases using "bring your own key support" were dropped after losing connectivity to Azure Key Vault. As a result of losing connectivity to Azure Key Vault, the key is revoked, and the SQL database dropped.
Zum Thema gelöschte SQL-Datenbanken hatte ich auch was geschrieben. Laut Microsoft wurden die DNS-Dienste an einen alternativen DNS-Anbieter übertragen, was das Problem zumindest entschärfte.
Authentifizierungsanfragen, die vor den Änderungen am Routing aufgetreten sind, konnten in Folge dieses Fehlers fehlgeschlagen sein. Das war immer der Fall, wenn DNS-Anfragen über den betroffenen DNS-Anbieter weitergeleitet wurde. Während Azure Active Directory (AAD) mehrere DNS-Anbieter nutzt, war ein manueller Eingriff erforderlich, um einen Teil des AAD-Verkehrs an einen sekundären Anbieter weiterzuleiten.
Laut Microsoft-Bericht hat der externe DNS-Dienstleister hat das Problem der kaputten DNS-Server behoben. Zudem hat dieser Anbieter Vorkehrungen getroffen, um die Wahrscheinlichkeit für einen solchen Fehler zu verringern. Laut Microsoft haben die Azure SQL-Ingenieure inzwischen auch alle SQL-Datenbanken wiederhergestellt, die aufgrund dieses Vorfalls gelöscht wurden.
Anmerkung 1: Die oben erwähnten Updates beim DNS-Provider und bei den Microsoft Netzwerkgeräten könnten im Zusammenhang mit dem Windows Server Domain Name System (DNS) Flag Day Compliance stehen. Sicher bin ich aber nicht.
Anmerkung 2: Ich hatte zu diesen Ereignissen auch Artikel bei heise.de im Newsticker. Dort wurde ausgiebig diskutiert, ob Ausfälle häufiger/länger auf OnPremise-Lösungen im Hause oder in der Cloud passieren. Die Quintessenz der Vorfälle zeigen aber, wie kritisch selbst kleine Störungen in der Infrastruktur der Cloud oder des Internet sind. Und jetzt haben wir noch nicht einmal einen großangelegten Cyberangriff staatlicher Hacker auf diese Infrastruktur. Sondern das Einspielen simpler Updates, die natürlich vorher ausgiebig getestet waren, bewirkten eine weltweiten Schluckauf der Microsoft Azure-Cloud-Funktionen. Merkt ihr was?
Ähnliche Artikel
OneDrive, und Azure Data Lake Store gestört … (29.11.2018)
Office 365 down (24. Januar 2019)?
Update zum Office365-Ausfall (Samstag, den 26.1.2019)
Office365.com: Großstörung behoben, dafür Links blockiert (29.1.2019)
Dumm gelaufen: Microsoft löscht Azure Cloud Datenbanken
Microsoft Windows Update-Service global gestört? (31.1.2019)
Anzeige
"Sondern das Einspielen simpler Updates, die natürlich vorher ausgiebig getestet waren"
woher hast Du dieses Gerücht – die Realität zeigt deutlich was anderes.
warum soll es auf Azure besser laufen als mit Windows clients ist schliesslich der gleiche Laden
"Sondern das Einspielen simpler Updates, die natürlich vorher ausgiebig getestet waren"
Das tönt für mich ironisch oder sonstwie, aber nicht ernst.
Das ist kein Gerücht – Microsoft erzählt uns das doch täglich aufs Neue ;-).
Spass beiseite – ich halte die Leute bei Microsoft nicht alle für doof – speziell wenn es um Updates für Server in der Cloud geht (daher habe ich die Ironie-Anführungszeichen weggelassen, obwohl mir beim Schreiben der Zeile der Schalk im Nacken saß). Die werden bei Microsoft schon getestet haben.
Aber hast Du Recht, die wirklichen Probleme stellen sich erst nach der Update-Installation heraus. Und jetzt hat es die Netzwerker der Azure-Infrastruktur getroffen. Ob der DNS-Provider auch mit Windows-Maschinen arbeitet, weiß ich nicht.
Die Tragik der Geschichte: Das MS-Management glaubt immer noch, mit der agilen Entwicklung und den Updates auf dem richtigen Weg zu sein, obwohl die Praxis oft was anderes erzählt.
Vielen Dank für den ausführlichen Bericht über das ganze Problem.
Die ganze Sache ist sehr komplex und für Normal-Anwender sehr schwer nachzuvollziehen, und natürlich Stress pur für Administratoren mit vielen Clienten und Cloud-Anbindung. Der Private Anwender steht da natürlich dumm da.
Für Firmen wird das sicher kritisch, wenn schon eine Kleinigkeit alles lahmlegt oder blockiert.