Legacy authentication voor Exchange Online stopt

Microsoft stopt op 13 oktober 2020 met het ondersteunen van “Legacy authenticatie” voor Exchange Online. 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 het moderne alternatief, genaamd modern authenticatie, inhoudt.

Wat houden legacy- en moderne authenticatie in?

Als we het hebben over “authenticatie” en inloggen, denken we van oudsher vaak aan de combinatie van een gebruikersnaam en een wachtwoord. Deze traditionele manier van authentiseren en de ondersteuning hiervoor heet legacy authenticatie. Moderne authenticatie ondersteunt een uitgebreidere, veiligere vorm van authenticatie en autorisatie. De ondersteuning voor deze nieuwere, moderne vorm is al geruime tijd aanwezig in de producten van Microsoft. Met deze geavanceerdere authenticatie- en authorisatiemogelijkheden, kan gebruik gemaakt worden van Multi-Factor Authenticatie (MFA) methoden. Denk hierbij bijvoorbeeld aan password-less inloggen met Windows Hello for Business, of een FIDO 2 Security Key. Daarbij kun je bijvoorbeeld gebruik maken van biometrische sensoren zoals gezichtsherkenning en/of een vingerafdruk. Je maakt daarmee het aanmelden eenvoudiger voor je eindgebruikers, maar kunt toch de veiligheid waarborgen.

Door geavanceerdere mogelijkheden voor toegangscontrole met Conditional Access (meegeleverd in de Azure AD Premium- en EMS-licentievormen) te gebruiken, kun je ook de manier waarop verbinding wordt gemaakt filteren. Dit is een goede aanvulling op de methodes van authenticeren (wachtwoord, MFA), met “hoe” dit toegestaan is. Denk bijvoorbeeld aan filters op basis van:

• 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, 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”. Je logt in met een gebruikersnaam en wachtwoord, maar er is verder geen controle. Tegenwoordig wordt een wachtwoord steeds vaker beschouwd als een noodzakelijkheid, maar werken zonder wachtwoorden blijkt veiliger te zijn. Wachtwoorden kunnen worden ge-“phisht” (of ge-“spearfisht”) met al dan niet gerichte aanvallen. Ze zijn kwetsbaar voor man-in-the-middle aanvallen.

Hoewel Microsoft met de Password Protection functionaliteit controleert of een wachtwoord voldoet aan de door de organisatie gestelde eisen, 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 Passwordless. Het gebruik van enkel een gebruikersnaam/wachtwoord combinatie, wordt in deze tijd beschouwd als onvoldoende. Er zijn verschillende alternatieven beschikbaar.

Met Conditional Access kunnen we bijvoorbeeld een beleid opstellen met betrekking tot toegestane verbindingen en legacy authenticatie blokkeren. Een belangrijke toevoeging aan het 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 moet ik doen?

Microsoft schakelt de ondersteuning uit voor deze legacy authenticatie binnen Office 365 – Exchange Online. Je kunt dus vanaf oktober 2020 niet meer inloggen met enkel een gebruikersnaam en een wachtwoord.

Je mag vanaf dat moment dus geen verbinding meer maken met een mailbox in Office 365 (of andere Exchange Online diensten). Het gaat hierbij om verbindingen via:

• ActiveSync protocol

Dat betekent dat vooral veel oudere mailprogramma’s, met name op mobiele apparaten (zoals verschillende niet standaard email-apps op telefoons), niet meer zullen werken;

• Secure POP3 protocol

Een alternatieve, verouderde manier van verbinding maken met de inhoud van mailbox;

• Secure IMAP protocol

Ook zoals POP3 een alternatieve manier van verbinding maken met de inhoud van mailbox;

• Remote Powershell (de traditionele connectie-methode)

Hierbij maak je met gebruikersnaam/wachtwoord verbinding met de dienst Exchange Online om bijvoorbeeld geautomatiseerde (gescripte) taken uit te voeren of rapportages te maken.

Houd er daarnaast rekening mee dat de traditionele Outlook Anywhere verbindingen al langere tijd niet meer ondersteund zijn in Office 365.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- of ticketing 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 exotische mail-apps op mobiele apparatendie geen modern authentication ondersteunenDaar waar iOS vanaf versie 12.1 de nieuwe manier (moderne authenticatie) heeft ingebouwd, is dat voor de Gmail-app vanaf Android Pie het geval, maar niet in hybride Exchange-scenario’s waarbij de verbindingen nog op de interne Exchange-omgeving uitkomen. Alléén als je devices rechtstreeks op Office 365 uitkomen (autodiscover). Zorg er daarom voor dat er binnen je organisatie up-to-date telefoons gebruikt worden die de laatste versie van Android/iOS gebruiken. Is het e-mail account op het toestel geconfigureerd vóórdat de moderne authenticatie was ondersteund, dan kan het nodig zijn opnieuw te authenticeren wanneer Microsoft de knop om zet.

Het alternatief voor niet ondersteunde mailclients ,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. Op die manier voorkom je dat, hoewel al je collega’s mogelijk netjes via de nieuwe/veiligere manieren werken, je alsnog de mogelijkheid open laat staan voor misbruik. In een vervolg-blog gaan we in op de mogelijkheden om die connectie-methodes te blokkeren.

Hoe kom ik erachter waar Legacy authenticatie nog gebruikt wordt?

Let erop dat Legacy Authenticatie een manier van verbinding maken is, niet zo zeer het gebruik van een gebruikersnaam en wachtwoord op zich. Dat betekent dat je de verbindingen wilt herkennen die op die oude manier verbinden, maar hoe doe je dat?

Binnen 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 en platformen (zoals bijvoorbeeld Exchange Online, Sharepoint of Teams). 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, 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 om zo snel mogelijk Multi-Factor Authenticatie in te schakelen en te 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 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!