Microsoft sender en analyse af årsagen til denne uges store Microsoft 365-loginproblemer

I denne uge havde vi en næsten 5 timer lang nedetid for Microsoft 365, med brugere, der ikke kan logge på flere tjenester, inklusive OneDrive og Microsoft Teams.

I dag Microsoft offentliggjorde en rodårsagsanalyse af problemet, som Microsoft siger skyldtes en serviceopdatering, som var beregnet til at være målrettet mod en intern valideringstestring, men som i stedet blev implementeret direkte i Microsofts produktionsmiljø på grund af en latent kodefejl i Azure AD-backend-tjenesten Safe Deployment Process (SDP)-systemet.

Microsoft siger, at mellem ca. 21:25 UTC den 28. september 2020 og 00:23 UTC den 29. september 2020 stødte kunder på fejl under udførelse af godkendelseshandlinger for alle Microsoft- og tredjepartsapplikationer og -tjenester, der er afhængige af Azure Active Directory (Azure AD). ) til godkendelse. Problemet var først fuldstændig afhjulpet for alle klokken 2:25 næste dag.

USA og Australien var hårdest ramt, hvor kun 17 % af brugerne i USA kunne logge ind.

Problemet blev forværret af, at Microsoft ikke var i stand til at rulle opdateringen tilbage på grund af den latente defekt i deres SDP-system, der korrumperer implementeringsmetadataene, hvilket betyder, at opdateringen skulle rulles tilbage manuelt.

Microsoft undskyldte over for berørte kunder og siger, at de fortsætter med at tage skridt til at forbedre Microsoft Azure-platformen og deres processer for at sikre, at sådanne hændelser ikke opstår i fremtiden. Et af de planlagte trin omfatter anvendelse af yderligere beskyttelse til Azure AD-service backend-SDP-systemet for at forhindre klassen af ​​identificerede problemer.

Læs hele analysen herunder:

RCA – Godkendelsesfejl på tværs af flere Microsoft-tjenester og integrerede Azure Active Directory-applikationer (sporings-id SM79-F88)

Sammenfatning af påvirkning: Mellem ca. 21:25 UTC den 28. september 2020 og 00:23 UTC den 29. september 2020 kan kunder være stødt på fejl under udførelse af godkendelseshandlinger for alle Microsoft- og tredjepartsapplikationer og -tjenester, der afhænger af Azure Active Directory (Azure AD) til autentificering. Applikationer, der bruger Azure AD B2C til godkendelse, blev også påvirket.

Brugere, der ikke allerede var godkendt til cloud-tjenester ved hjælp af Azure AD, var mere tilbøjelige til at opleve problemer og kan have set flere godkendelsesanmodningsfejl svarende til de gennemsnitlige tilgængelighedstal vist nedenfor. Disse er blevet aggregeret på tværs af forskellige kunder og arbejdsbelastninger.

• Europa: 81 % succesrate under hændelsens varighed.
• Amerika: 17 % succesrate under hændelsens varighed, forbedret til 37 % lige før afhjælpning.
• Asien: 72 % succesrate i de første 120 minutter af hændelsen. Efterhånden som arbejdstidens spidsbelastning begyndte, faldt tilgængeligheden til 32 % på det laveste.
• Australien: 37 % succesrate under hændelsens varighed.

Tjenesten blev gendannet til normal driftstilgængelighed for størstedelen af ​​kunderne kl. 00:23 UTC den 29. september 2020, men vi observerede sjældne autentificeringsanmodningsfejl, som kan have påvirket kunder indtil kl. 02:25 UTC.

Brugere, der havde autentificeret før virkningens starttidspunkt, var mindre tilbøjelige til at opleve problemer afhængigt af de applikationer eller tjenester, de havde adgang til.

Resiliensforanstaltninger på plads beskyttede Managed Identities-tjenester til virtuelle maskiner, Virtual Machine Scale Sets og Azure Kubernetes Services med en gennemsnitlig tilgængelighed på 99.8 % i hele hændelsens varighed.

Hovedårsagen: Den 28. september kl. 21:25 UTC blev en serviceopdatering rettet mod en intern valideringstestring implementeret, hvilket forårsagede et nedbrud ved opstart i Azure AD-backend-tjenesterne. En latent kodefejl i Azure AD-backend-tjenesten Safe Deployment Process (SDP)-systemet fik dette til at implementere direkte i vores produktionsmiljø og omgå vores normale valideringsproces.

Azure AD er designet til at være en geo-distribueret tjeneste implementeret i en aktiv-aktiv konfiguration med flere partitioner på tværs af flere datacentre rundt om i verden, bygget med isolationsgrænser. Normalt er ændringer i første omgang rettet mod en valideringsring, der ikke indeholder kundedata, efterfulgt af en indre ring, der kun indeholder Microsoft-brugere, og til sidst vores produktionsmiljø. Disse ændringer implementeres i faser på tværs af fem ringe over flere dage.

I dette tilfælde kunne SDP-systemet ikke målrette valideringstestringen korrekt på grund af en latent defekt, der påvirkede systemets evne til at fortolke implementeringsmetadata. Følgelig blev alle ringe målrettet samtidigt. Den forkerte implementering medførte, at servicetilgængeligheden blev forringet.

Inden for få minutter efter påvirkning tog vi skridt til at fortryde ændringen ved hjælp af automatiserede rollback-systemer, som normalt ville have begrænset varigheden og alvoren af ​​påvirkningen. Imidlertid havde den latente defekt i vores SDP-system ødelagt implementeringsmetadataene, og vi var nødt til at ty til manuelle rollback-processer. Dette forlængede betydeligt tiden til at afhjælpe problemet.

Begrænsning: Vores overvågning opdagede serviceforringelsen inden for få minutter efter den første påvirkning, og vi gik straks i gang for at påbegynde fejlfinding. Følgende afværgeforanstaltninger blev iværksat:

• Påvirkningen startede kl. 21:25 UTC, og inden for 5 minutter opdagede vores overvågning en usund tilstand, og teknik blev straks sat i gang.
• I løbet af de næste 30 minutter, i takt med fejlfinding af problemet, blev der taget en række trin for at forsøge at minimere kundepåvirkning og fremskynde afhjælpning. Dette omfattede proaktiv udskalering af nogle af Azure AD-tjenesterne for at håndtere forventet belastning, når en afbødning ville være blevet anvendt, og fejl over visse arbejdsbelastninger til et backup Azure AD-godkendelsessystem.
• Klokken 22:02 UTC etablerede vi den grundlæggende årsag, begyndte udbedring og igangsatte vores automatiske tilbagerulningsmekanismer.
• Automatisk tilbagerulning mislykkedes på grund af korruption af SDP-metadata. 22:47 UTC påbegyndte vi processen for manuelt at opdatere servicekonfigurationen, som omgår SDP-systemet, og hele operationen afsluttet kl. 23:59 UTC.
• Ved 00:23 UTC vendte nok backend-serviceforekomster tilbage til en sund tilstand til at nå normale driftsparametre for service.
• Alle servicetilfælde med resterende påvirkning blev gendannet kl. 02:25 UTC.

Næste trin: Vi undskylder oprigtigt for indvirkningen på de berørte kunder. Vi tager løbende skridt til at forbedre Microsoft Azure-platformen og vores processer for at sikre, at sådanne hændelser ikke opstår i fremtiden. I dette tilfælde omfatter dette (men er ikke begrænset til) følgende:

Vi har allerede gennemført

• Rettede den latente kodedefekt i Azure AD-backend SDP-systemet.
• Rettede det eksisterende tilbagerulningssystem for at tillade gendannelse af de sidste kendte gode metadata for at beskytte mod korruption.
• Udvid omfanget og hyppigheden af ​​tilbagerulningsøvelser.

De resterende trin omfatter

• Anvend yderligere beskyttelse til Azure AD-tjenestens backend SDP-system for at forhindre klassen af ​​problemer, der er identificeret her.
• Fremskynd udrulningen af ​​Azure AD-sikkerhedskopigodkendelsessystem til alle nøgletjenester som en topprioritet for at reducere virkningen af ​​en lignende type problem betydeligt i fremtiden.
• Indbygget Azure AD-scenarier til den automatiske kommunikationspipeline, som sender indledende kommunikation til berørte kunder inden for 15 minutter efter påvirkning.

Give feedback: Hjælp os med at forbedre Azure-kundekommunikationsoplevelsen ved at deltage i vores undersøgelse: https://aka.ms/AzurePIRSurvey

via ZDNet