Microsoft belicht oorzaken multi-factor authenticatie storing

Microsoft belicht in een online rapport de recente oorzaken rond de multi-factor authenticatie storing waardoor sommige gebruikers niet konden inlogen in een hun cloud diensten. Microsoft biedt hierbij zijn excuses aan.

Microsoft meldt: "op 19 november 2018 ondervond er een storing in de Microsoft Azure AD Multi-Factor Authentication (MFA) -services. Gebruikers van Azure Active Directory-verificatieservices - inclusief gebruikers van Office 365, Azure, Dynamics en andere services die Azure Active Directory gebruiken voor authenticatie - konden zich niet aanmelden als MFA was vereist, zoals bepaald door het beleid van hun organisatie. Het evenement werd gemitigeerd op maandag 19 november 2018 om 18:38 UTC. Bovendien hielden technici het evenement open en bevestigden ze door uitgebreid te controleren of de geïdentificeerde worteloorzaken klopten, opgenomen directe telemetrie en verwerkte wijzigingen om het incident te sluiten op woensdag 21 november 2018 om 03:00 uur UTC.

Hoofdoorzaak:
er zijn drie onafhankelijke basisoorzaken ontdekt. Bovendien vertraagden lacunes in telemetrie en monitoring voor de MFA-diensten de identificatie en het begrip van deze hoofdoorzaken, wat een verlengde verzachtende tijd veroorzaakte.
De eerste twee hoofdoorzaken werden geïdentificeerd als problemen op de frontend-server van MFA, beide geïntroduceerd in een uitrol van een code-update die begon in een aantal datacenters (DC's) op dinsdag 13 november 2018 en voltooid in alle DC's vóór vrijdag 16 november 2018. Later werd vastgesteld dat de problemen werden geactiveerd zodra een bepaalde verkeersdrempel werd overschreden die zich voor het eerst in de vroege maandag (UTC) voordeed in de Azure West Europe (EU) DC's. Ochtendpieken in het verkeer in West DC DC's waren de eerste die de drempel overschreden die de bug veroorzaakte. De derde oorzaak is niet geïntroduceerd in deze uitrol en werd gevonden als onderdeel van het onderzoek naar deze gebeurtenis.

1. De eerste oorzaak is gemanifesteerd als latentieprobleem in de communicatie van de MFA-frontend met zijn cacheservices. Dit probleem begon onder hoge belasting zodra een bepaalde verkeersdrempel was bereikt. Zodra de MFA-services dit eerste probleem hadden ondervonden, hadden ze meer kans om een tweede oorzaak te veroorzaken.

2. De tweede hoofdoorzaak is een raceconditie bij het verwerken van antwoorden van de MFA-backendserver die heeft geleid tot hergebruik van de MFA frontend-serverprocessen die extra latentie kunnen triggeren en de derde oorzaak (lager) op de MFA-backend.

3. De derde geïdentificeerde oorzaak, was voorheen een niet-gedetecteerd probleem in de backend MFA-server die werd geactiveerd door de tweede oorzaak. Dit probleem veroorzaakt opeenhoping van processen op de MFA-back-end die leidt tot uitputting van bronnen op de back-end. Op dat moment kon het geen verdere verzoeken van de MFA-frontend verwerken terwijl het anders gezond leek in onze monitoring.

Mitigatie: er waren drie hoofdfasen van deze gebeurtenis:

Fase 1: impact op EMEA- en APAC-klanten - 04:39 UTC tot 07:50 UTC op 19 november 2018:
Om de betrouwbaarheid en prestaties te verbeteren, worden caching-services gebruikt in Azure Active Directory. Het MFA-team heeft onlangs een wijziging geïmplementeerd om verbindingen met de caching-services effectiever te beheren. Helaas introduceerde deze wijziging meer latentie en een race-conditie in de nieuwe code voor verbindingsbeheer, onder zware belasting. Dit zorgde ervoor dat de MFA-service de verwerking van aanvragen vertraagde, aanvankelijk met gevolgen voor de West-Europese DC's (die APAC- en EMEA-verkeer bedienen). Gedurende deze periode werden meerdere mitigaties toegepast - inclusief veranderingen in de verkeerspatronen in de EU-DC's, uitschakeling van auto-mitigatiesystemen om verkeersvolumes te verminderen en uiteindelijk verkeer dat werd omgeleid naar Oost-VS DC. Onze verwachting was dat een gezonde cacheservice in de East US DC de latentieproblemen zou verminderen en de ingenieurs in staat zou stellen om zich te concentreren op andere mitigaties in de West-Europese DC's. Het extra verkeer naar Oost-DC zorgde er echter voor dat de frontend-servers van MFA hetzelfde probleem ondervonden als West EU, en uiteindelijk begonnen verzoeken om time-out. Ingenieurs reden daarom het verkeer terug naar de West-Europese DC-landen en gingen door met het onderzoek.

Fase 2: Brede impact van de klant - 07:50 UTC tot 18:38 UTC op 19 november 2018:
Een eerder niet-gedetecteerd probleem in de Azure MFA-back-end, veroorzaakt door de raceconditie aan de voorkant en veroorzaakte een opeenstapeling van processen. De back-endresourceslimieten van Azure MFA zijn uitgeput, waardoor de levering van MFA-berichten aan klanten wordt voorkomen. Gedurende deze periode ondervonden de West-Europese DC-afdelingen nog steeds een time-out bij het indienen van verzoeken en bij afwezigheid van signalen / telemetrie om andere problemen aan te geven, bleef de focus van het technische team gericht op het verminderen van het latency-probleem in de MFA-frontendservers. Om de gezondheid van deze datacenters te herstellen, hebben ingenieurs de recente implementatie teruggedraaid, extra capaciteit, verhoogde smoorlimieten, gerecycleerde MFA cacheservers en frontend-servers toegevoegd en een hotfix toegepast op de frontend-servers om de cache te omzeilen. Dit loste het latentieprobleem op,
Na het onderzoeken en identificeren van problemen in de MFA-back-endservers, hebben de technici de MFA-backendservers gefietst om de servicegezondheid volledig te herstellen. De eerste diagnose van deze problemen was moeilijk omdat de verschillende gebeurtenissen die van invloed waren op de service elkaar overlappen en niet als afzonderlijke problemen manifesteerden. Dit werd nog nijpender gemaakt door de hiaten in telemetrie die de oorzaak zouden zijn van het probleem met de back-end server. Nadat deze problemen in alle DC's waren vastgesteld en volledig waren verholpen, bleef het team de gebeurtenissen en door klanten gemelde problemen de komende 48 uur volgen.

Fase 3: Postherstel - RCA, monitoring en analyse van door klanten gemelde problemen - 18:38 UTC op 19 november 2018 tot 03:00 UTC op 21 november 2018:
ingenieurs hielden het incident open gedurende een periode van ongeveer 48 uur om te monitoren en volledig onderzoek alle door de klant gemelde gevallen en bevestig dat de problemen volledig zijn verholpen. We wilden ook ons ??vertrouwen vergroten dat de geïdentificeerde worteloorzaken de oorzaak van de mislukkingen waren. Op woensdag 21 november 2018 om 03:00 UTC was het incident gesloten.

Volgende stappen:
Microsoft meldt verder: "We bieden onze oprechte excuses aan voor de impact op getroffen klanten. We zijn continu bezig met het verbeteren van het Microsoft Azure Platform en onze processen om ervoor te zorgen dat dergelijke incidenten in de toekomst niet plaatsvinden. In dit geval omvat dit (maar is niet beperkt tot):

Bekijk onze updateprocedures voor updates om soortgelijke problemen tijdens onze ontwikkelings- en testcycli beter te identificeren (voltooiing vóór december 2018)
Controleer de bewakingsservices om manieren te vinden om de detectietijd te verkorten en de service snel te herstellen (voltooiing vóór december 2018)
Bekijk ons containmentproces om te voorkomen dat een probleem wordt verspreid naar andere datacenters (voltooiing vóór januari 2019)
Update het communicatieproces naar het Service Health Dashboard en monitoring tools om publicatieproblemen direct tijdens incidenten te detecteren (voltooiing voor december 2018)
We moedigen klanten altijd aan om op de hoogte te blijven van problemen, onderhoudsgebeurtenissen of adviezen. Zij moeten het volgende bezoeken: https://www.aka.ms/ash-alerts en meldingen configureren via hun voorkeurscommunicatiekanaal (s): e-mail, sms, webhook, enz. Bij dit incident werden de mededelingen niet onmiddellijk naar het blad Service Health verzonden in de managementportal voor alle betrokken klanten. Dit is een fout van het Azure-team waarvoor we onze excuses aanbieden."