Legacy authentication voor Exchange Online

Laatste update 04 juli 2022

Mogelijk heb je zelf het nieuws al vernomen: Microsoft stopt op 13 oktober 2020 met het ondersteunen van “Legacy authenticatie” voor Exchange Online (hier vind je meer informatie).

Dit is een grote stap voor Microsoft, vooral in het kader van security. Maar wat houdt deze wijziging nu eigenlijk in? En wat is de impact voor jouw organisatie? Om dat te begrijpen leggen we eerst uit wat legacy authenticatie en haar moderne alternatief modern authenticatie inhouden.

Wat is zijn legacy- en moderne authenticatie?

Als we het hebben over “authenticatie” denken we van oudsher vaak aan de combinatie van gebruikersnaam en wachtwoord. Deze traditionele manier van authenticeren en de ondersteuning hiervoor, heet legacy authenticatie.

Moderne authenticatie (Modern authentication) is de ondersteuning voor een uitgebreidere, veiligere vorm van authenticatie en authorisatie. De ondersteuning voor deze nieuwere, moderne vorm is al geruime tijd aanwezig in de producten van Microsoft. Sinds de Office 2013 programmatuur is ondersteuning in de producten aanwezig.

Moderne authenticatie maakt het ondersteunen van geavanceerdere authenticatie- en authorisatie-mogelijkheden mogelijk. Hierdoor kan men gebruik maken van Multi-Factor Authenticatie (MFA) methoden en kunnen keuzes gemaakt worden voor de gevraagde verbinding op basis van bijvoorbeeld:

Het IP-adres waar vanuit een connectie wordt geïnitieerd,
Of het apparaat “compliant” is (voldoet aan de, door de organisatie gestelde, regels),
Of het type/de versie van het programma dat zich “meldt”.

Met beleidsregels (policies) zoals in Conditional Access, onderdeel van Intune/EMS aanwezig, kan bepaald worden of een verbinding toegelaten wordt, of dat er bijvoorbeeld een extra vorm van authenticatie nodig is (een zogeheten “Proof up”).

Waarom is legacy authenticatie een security-risico?

Zoals eerder aangegeven is legacy authenticatie “simpel”, er is ondersteuning voor de combinatie van gebruikersnaam/wachtwoord en verder niets. Tegenwoordig wordt een wachtwoord steeds vaker beschouwd als een noodzakelijkheid, maar onvoldoende op zichzelf. Wachtwoord kunnen we ge-“phisht” (of ge-“spearfisht”) met, al dan niet gerichte, aanvallen en zijn kwetsbaar voor man-in-the-middle aanvallen. Hoewel Microsoft de Password Protection functionaliteit aanbiedt om te controleren dat een nieuw in te stellen wachtwoord voldoet aan de door de organisatie eisen voldoet, en geen “standaard” of ooit in een hack voorgekomen wachtwoord is, blijven aan een wachtwoord risico’s kleven die bij een alternatieve authenticatie-mogelijkheden niet (of minder) aanwezig zijn. Zie ook de blog van mijn collega’s over Password-less.

Het gebruik van enkel een gebruikersnaam/wachtwoord combinatie wordt in deze tijd beschouwd als onvoldoende, daar waar veel alternatieven beschikbaar zijn. Met Conditional Access kunnen we een beleid opstellen met betrekking tot toegestane verbindingen en voor het automatiseren van taken die een verbinding maken met Office 365 (Exchange Online) kunnen service principals/App Registrations bijvoorbeeld als alternatief gebruikt worden.

Een belangrijke toevoeging aan bovenstaande is het feit dat legacy authenticatie Multi-Factor Authenticatie bypassed. Dat klinkt heel logisch, maar graag staan we even stil bij effect hiervan. Stel je het volgende scenario voor: Je hebt netjes met Conditional Access policies gesteld waardoor mensen alleen met een compliant device, of met Multi-Factor Authenticatie een verbinding mogen leggen met hun mailbox. Daarentegen staan de authenticatie-methoden IMAP en/of POP3 nog enabled op alle mailboxen binnen je organisatie. Effectief betekent dit dat een hacker met bijvoorbeeld “leaked credentials”, of de credentials die achterhaald zijn bij een phishing-aanval, een verbinding met de mailbox kan leggen zonder daarvoor MFA nodig te hebben en een export kan maken van alle data in die mailbox. Hierbij omzeil je dus alle opgelegde veiligheidseisen. Onderschat dit risico niet, helaas hebben we dit in de praktijk al zien gebeuren.

Microsoft wil geen enkel onnodig risico meer lopen terwijl er goede alternatieven beschikbaar zijn, daar kunnen we toch alleen maar achter staan?

Wat is de impact?

Microsoft schakelt de ondersteuning uit voor deze legacy authenticatie binnen Office 365 – Exchange Online. Dat betekent dat een aantal verbindingsmechanismen voor het verbinden richting het Exchange Online niet meer zullen werken. Het gaat hierbij om verbindingen via:

ActiveSync protocol;
Secure POP3 protocol;
Secure IMAP protocol;
Remote Powershell (de traditionele connectie-methode).

Houdt er daarnaast rekening mee dat de traditionele Outlook Anywhere verbindingen al langere tijd niet meer ondersteund zijn in Office 365.

Moet ik nog iets doen?

Ja. Wanneer nog integraties bestaan met Exchange Online waarbij op een van de hierboven genoemde manieren verbinding gemaakt wordt, dienen deze omgezet te worden naar een wel ondersteunde methode. Denk hierbij bijvoorbeeld aan een servicedesk-applicatie die middels POP3 de binnenkomende berichten in een mailbox uitleest, of (verouderde) mail-clients die middels POP3 of IMAP verbindt met een mailbox.

Daarnaast zien we dat vaak ActiveSync nog gebruikt wordt om met mobiele apparaten een verbinding met de mailbox te maken; denk bijvoorbeeld aan de “native” app op Android-appraten, welke geen modern authentication ondersteunt. Het alternatief hiervoor is het gebruik van bijvoorbeeld de Outlook-app. Deze biedt ondersteuning voor modern authentication maar heeft daarnaast nog andere voordelen (vanuit security perspectief, maar ook voor bijvoorbeeld voor het openen van een gedeelde mailbox op een mobiel toestel). Het informeren van de eindgebruikers binnen de organisatie is hierbij van kritiek belang om ervoor te zorgen dat zij niet zonder e-mail op een mobiel apparaat komen te zitten.

Vervolgens is het van belang, als dit al niet het geval is, de protocollen op alle mailboxes te disablen.

Maar hoe kom erachter waar Legacy authenticatie nog gebruikt wordt?

Binnen de Azure AD is veel informatie aanwezig in de vorm van logging waarin uitgelezen kan worden op wat voor manier een verbinding gemaakt wordt met Office 365 & Azure resources. Door deze logging te analyseren, of een Conditional Access policy aan te maken (in geval van Azure AD Premium P1 of hoger) die specifiek verzamelt welke verbindingen middels legacy authenticatie worden opgezet, kan achterhaald worden waar nog wijzigingen nodig zijn om er zeker van te zijn dat deze wijziging geen negatieve impact heeft op de organisatie. Op basis van deze analyse kunnen vervolgens de noodzakelijke acties uitgezet worden. Denk hierbij bijvoorbeeld aan het omzetten van de eerdergenoemde Servicedesk-applicatie naar het maken van een EWS- in plaats van een POP3/IMAP-verbinding. Wanneer scripts middels serviceaccounts worden gestart, dan wordt vaak een verbinding gemaakt naar Exchange Online met gebruikersnaam/(encrypted) wachtwoord, dit zal ook niet meer kunnen in de toekomst.

En zijn we er dan?

Nee. Dit is niet de enige boodschap die we met dit artikel willen overbrengen. Vanuit Inspark raden wij ten sterkste aan op zo kort mogelijke termijn Multi-Factor Authenticatie in te schakelen en te gaan gebruiken binnen Office 365 en Azure. De mogelijkheden van Azure MFA zijn in te zetten wanneer je beschikt over Azure AD Premium P1 licenties of hoger. Wij zijn van mening dat je zonder het gebruik van MFA in de tegenwoordige tijd een te groot risico loopt. Rond augustus 2018 werd Multi-Factor Authenticatie slecht gebruikt voor- en door gebruikers en beheerders van Office 365 in 20% van de gevallen. Zowel Microsoft zelf als wij van Inspark zien hierin een groot, maar vooral onnodig risico dat organisaties nemen met betrekking tot beveiliging.

Ben je niet zeker of jouw organisatie over een licentie-vorm beschikt waarmee je Azure MFA kunt gaan gebruiken, of schakel je graag hulp in bij het valideren dat je geen risico loopt door deze wijziging van Microsoft? Neem contact met ons op, we helpen graag!