Legacy authentication protokollok

Egyre közeleg a dátum, mikor a Microsoft végleg kivezeti a basic authenticationt az Exchange Online elérésében (2023.március 31.)

Az M365 adminok ezt többé-kevésbé tudják, és meg is teszik a szükséges lépéseket. Viszont sokszor jön a kérdés, mik is ezek a legacy protokollok és mi használja őket?

Az Azure Active Directoryban sign-in logban leszűrve ezeket látjuk, mint legacy protocols:

Legacy protocols:

  • Authenticated SMTP – POP és IMAP kliensek használják levélküldésre
  • Autodiscover – Outlook és Exhange Active Sync kliensek használják a mailboxok megkeresésére az Exchange Online-ban, pl Windows Mail és egyéb mobilalkalmazások
  • Exchange ActiveSync (EAS) – Postafiók elérés Exchane Online-ban
  • Exchange Online PowerShell – Exchange Online elérése Powershellből
  • Exchange Web Services (EWS) – úgynevezett programming interface amit az Outlook, Outlook for Mac, és 3rd party alkalmazások használnak
  • IMAP4 – IMAP4 email kliensek használják, pl Thunderbird vagy Apple Mail
  • MAPI over HTTP (MAPI/HTTP) – Outlook 2010/2013 kliensek használják.
  • Offline Address Book (OAB) – Outlook használja az address list letöltésére
  • Outlook Anywhere (RPC over HTTP) – Outlook 2016 használja
  • Outlook Service – Windows 10-ben lévő Mail and Calendar app használja
  • POP3 – POP3 kliensek használják
  • Other clients – minden más protokoll ami legacy módon működik

A POP/IMAP/Remote Powershell már kapott Oauth 2.0 támogatást, ezek továbbra is használhatók.

Földi Exchange postafiók elérérés – Azure AD Conditional Access

Ügyfeles konzultáció során merült fel az alábbi scenárió:

“Exchange 2016 hybrid környezetünk van, sok postafiókot már migráltunk az O365-be, de sok még a földi Exchange-en van. Az Exchange Online elérésére van több Conditional Access lehetőségünk (MFA, Intune compliant device stb) is, lehetne ezt a földi fiókokra is alkalmazni?”

Jó hír, hogy lehetséges, a Hybrid Modern Authentication révén (minimum követelmény az Exchange 2013 és Outlook 2013)

Hogyan néz ki a Hybrid Modern Authentication (HMA) folyamat?

  1. A felhasználó elindítja az Outlookot ami az autodiscover segítségével csatlakozik a földi Exchange–hez. Innen a kapcsolat továbbmegy az evoSTS URL-hez, amit az HMA kialakítása során beállítottunk.
  2. Az Outlook az AzureAD-hoz fordul, végrehajtja a modern auth folyamatot, alkalmazódnak rá az esetlegesen beállított Conditional Access szabályok.
  3. A sikeres auth után a felhaszáló megkapja az Access Tokent és Refresh Tokent.
  4. Az Access Tokent átadva a földi Exchange szervernek, a mailbox elérhetővé válik.
Hybrid modern authentication diagram

Kinek ajánlott a HMA?

Olyan szervezeteknek, ahol hosszú távú hybrid kialakítását tervezik, és biztosítani kívánják, hogy a földi postafiókok elérése is ugyanolyan szabályozottan történjen, mint a felhős esetén.

Exchange levélküldési probléma – mail queue stuck

Ha január 1-je után azt látjuk, hogy az Exchange szervereken állnak a levelek a küldési sorban, és az eventviewerben ezt látjuk:

“Error
The FIP-FS “Microsoft” Scan Engine failed to load. PID: 9244, Error Code: 0x80004005. Error Description: Can’t convert “2201010005” to long.”

Exchange mail flow breaks Event 5300 FIPFS

A megoldást itt találjuk: https://aka.ms/ResetScanEngineVersion

Ezt a ps scriptet lefuttatva az alábbi outputot kapjuk:

[PS] C:\Program Files\Microsoft\Exchange Server\V15\Scripts>.\Reset-ScanEngineVersion.ps1
EXCH1 Stopping services...
EXCH1 Removing Microsoft engine folder...
EXCH1 Emptying metadata folder...
EXCH1 Starting services...
WARNING: Waiting for service 'Microsoft Filtering Management Service (FMS)' to start...
WARNING: Waiting for service 'Microsoft Filtering Management Service (FMS)' to start...
WARNING: Waiting for service 'Microsoft Filtering Management Service (FMS)' to start...
WARNING: Waiting for service 'Microsoft Filtering Management Service (FMS)' to start...
WARNING: Waiting for service 'Microsoft Exchange Transport (MSExchangeTransport)' to start...
EXCH1 Starting engine update...
Running as EXCH1-DOM\Administrator.
--------
Connecting to EXCH1.CONTOSO.com.
Dispatched remote command. Start-EngineUpdate -UpdatePath http://amupdatedl.microsoft.com/server/amupdate

További információ: https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447

Levélküldés másodlagos emailcímről

Régóta fennálló probléma, hogy bár egy felhasználónak lehet több emailcíme is, küldeni csak az alapértelmezettről (primary smtp címről) tud.

Az Exchange Online-ban ez végre megoldódott, bármilyen smtp aliasról lehet már levelet küldeni (földi Exchange sajnos még vár erre a funkcióra). Ez azt jelenti hogy az adott cím kerül be a FROM és REPLY TO mezőbe.

Nézzünk egy gyakorlati példát:

Alex Wilbernek van egy másodlagos címe (sales@istvanffy.eu) és erről szeretne levelet küldeni.

Hogyan kapcsoljuk be?

A funkció bekapcsolásához futtassuk le a következő Exchange Online Powershell parancsot:

Set-OrganizationConfig -SendFromAliasEnabled $True

Az érvényrejutáshoz várni kell pár órát, mire minden tenant szerver átveszi a konfigurációt.

Hogyan küldjünk levelet másodlagos címmel?

Az Outlookban válasszuk ki a From mezőt, és írjuk be a másodlagos címet:

A fenti természetesen működik OWA esetén is.

A címzett pedig ezt látja:

Azaz a küldő neve mellett a másodlagos címe jelenik meg.

A Return-Path is megfelelő:

Ez a funkció hasznos lehet olyan esetekben is, mikor két cég összeolvad és a felhasználónak kell tudnia maileznie a régi és új emailcímmel.

Exchange Online Protection – a Safe Listek veszélyei

Sok szervezetnél van rá igény, hogy külső partnerektől mindenképpen megkapják az emaileket. Az Exchange Online erre négyféle megoldást is biztosít:

  • Mail flow rules (transport rules)
  • Outlook Safe Sender beállítás
  • IP allow list (connection filter)
  • Allowed sender/domain list (anti-spam policynél)

Most az utolsót nézzük meg, az allowed sender/domain listákat. Ahogy említettem, vannak olyan küldők, ahonnan mindenképp meg kéne kapjuk a maileket. Gyakorlati példa lehet a szamlakozpont.hu vagy gov.hu

Ilyenkor az üzemeltetők ezeket a domainek felveszik az Allowed Domain listre, hogy biztos beérkezzenek a levelek.

Mi lehet evvel a gond?

Sajnos az, hogy az ilyen feladóval érkező mailek mentesülnek az alábbi szűrések alól:

  • Spam
  • Spoof (levélhamisítás)
  • Phishing (adathalászat)

Valamint az összes küldő hitelesítés ellenőrzés alól: SPM, DKIM, DMARC

Egyedül a malware és high-confidence phishing szűrés valósul meg.

Ahogy látjuk, ez a fajta engedélyező lista komoly veszélyeket hordozhat ; bár biztosak lehetünk felőle hogy a kívánt feladótól érkező levelek nem akadnak fenn a szűrőnkön, de sajnos utat nyihat a támadóknak is.

Minimal vs Full Hybrid – melyiket válasszam?

Ügyfelekkel beszélgetve tapasztalom, hogy sok a homály az Exchange Hybrid kialakításással kapcsolatban. A legtöbb elakadás ennél a képernyőnél történik:

Azaz jön a jogos kérdés, hogy a mi különbség a kettő között, és melyiket válassza az adott szervezet?

Minimal vs Full Hybrid

A Minimal Hybrid használata esetén az alább funkciók nem lesznek elérhetőek:

  • Cross-premises Free / Busy információk (naptármegosztás funkció a földi és felhős postafiókos felhasználóknál)
  • TLS – titkosított mail flow a földi Exchange és az Exchange Online között
  • Cross-premises eDiscovery funkciók
  • Automatikus OWA és ActiveSync átirányítás az EXO-ba migrált usereknél
  • Skype for Business vagy Teams integráció a földi postafiókok esetén

Természetesen megmaradak az alábbi lehetőségek:

Online mailbox migráció (a felhasználó a mozgatás alatt is tud dolgozni a levelezésében); nincs szükség az Outlook-profil újrakonfigurálására; nincs szükség külön név/jelszó használatára (a céges account adatok szinkronizálódnak)

Mely szervezeteknek ajánlható a Minimal Hybrid kialakítás?

  • Kis -és közepes méretű cégeknek, akik szeretnének gyorsan az Exchange Online-ba migrálni, de mégis szeretnének kontrollt (szemben pl. a cutover migrációval)
  • Amely szervezeteknek nincs szükségük a fenti teljes funkcionalitásra és nem terveznek hosszú távon hybrid fenntartást.
  • Felvásárlás vagy egyesülés esetén, ha az igény a mailboxok gyors migrációja

Mely szervezeteknek javasolt a Full Hybrid kialakítás?

  • Nagy létszámú szervezeteknek, ahol hosszú távon is terveznek a földi Exchange megtartásával
  • Ahol szükség van a maximális kontrollra a migrációkat tekintve, emiatt szükséges az együttélés (co-existence) biztosítása
  • Ahol szükséges a Free / Busy információk megléte és eDiscovery funkció

Fontos tudni, hogy ha már beállítottuk a Full Hybridet, akkor az O365 Hybrid Configuration Wizard futtatásakor már nem választhatjuk a Minimal Hybridet (a fenti screenshoton is inaktív a lehetőség). Viszont amennyiben Minimalt állítottunk be, bármikor válthatunk a Full Hybridre.

Az alábbi táblázatban összeállíottam pár szempontot a döntéshez:

IgényVálasztás
Mailboxok gyors migrációjaMinimal Hybrid
Office 365 mailboxok kezelése és földi AD szinkronizálásaMinimal Hybrid
Global Address List fenntartása a földi és and Office 365 közöttMinimal Hybrid
Organization configuration beállítások szinkronizálása, pl. ActiveSync policykMinimal Hybrid
A mailboxok migrációjának előkészítése (pre-sync) és migráció befejezése alkalmas időbenMinimal Hybrid
Bejövő és kimenő levelezés a földi Exchange-en keresztül kell történjenFull Hybrid
Földi Exchange és Exchange Online közötti levélforgalom TLS-sel legyen titkosítottFull Hybrid
Megtartani a mailek eredeti fejlécét , ami szükséges a  mailtippek és out of office válaszokhozFull Hybrid
Free / Busy funckió használata (naptármegosztás földi és felhős postafiókok között)Full Hybrid
Földi és felhős postafiókok közötti Full Access / Send as jogosultságok megtartásaFull Hybrid
Integráció  Skype for Business / Teams és  Exchange 2016 mailboxok között vagy cross-premises eDiscovery használataFull Hybrid
Kontrollált mailbox migrációFull Hybrid

Összefoglalva:

Ha a cél a lassabb, de teljesen kontrollált migráció és fontos a teljes együttműködés megtartása a földi és felhős postafiókkal rendelkező felhasználók között, válasszuk a Full Hybridet.

Ha a gyors migráció a prioritás, beáldozva néhány funkciót, akkor érdemesebb a Minimal Hybrid opciót választani.

Letöltés blokkolása Cloud App Securityvel

Amennyiben rendelkezünk Azure AD P1 vagy P2 és Cloud App Security licensszel (Microsoft E5, EMS E5 vagy Microsoft E5 Security), könnyen megakadályozhatjuk céges adatok letöltését, ha nem menedzselt eszközről lép be.

Nem menedzselt eszköz: ami nincs az Intune-ba bevonva vagy nem Hybrid Azure AD-tag.

A példában az Exchange Online-nál fogjuk beállítani, tehát ha nem menedzselt eszköről lépünk be az OWA-ra, akkor kötelező lesz az Azure MFA hitelesítés és nem fogjuk tudni a mellékleteket a gépre letölteni. Így megmarad a lehetőség az OWA elérésre bármilyen gépről, de csak “read-only” módban.

Azure AD Conditional Access beállítása:

Navigáljunk el a conditional access portálra és hozzunk létre egy új szabályt:

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies

A Conditions részrél állítsuk be a Client app / Browser-t

Az Access Control / Grant mezőnél pedig pipáljuk be a “Require multi-factor authentication” opciót

Az Access Control / Session résznél kapcsoljuk be az “Use Conditional Access App Control” és use custom policy… opciót

Cloud App Security beállítása:

Navigáljunk el az MCAS portálra: https://portal.cloudappsecurity.com/

A Control / Policies résznél készítsünk egy új Session policyt

A session control type-nál állítsuk át “control file download (with inspection)”-ra és az Appnál vegyük fel a Microsoft Exchange Online-t

(Ha megnézzük a szabályt, látszik, hogy ha a Device Tag nem egyenlő “intune compliant” vagy “Hybrid Azure AD joined”, akkor lép érvénybe)

Az Action résznél állítsuk be a block-ot

A szabály elmentése után teszteljünk:

Ha nem menedzselt gépről lépünk be az OWA-ra, ez az üzenet fogad minket:

Továbblépve, ha megpróbálunk egy mellékletet letölteni a levelezésből, a következő üzenetet kapjuk:

A policy kiterjeszthető több alkalmazásra is, pl. Teams / Sharepoint, egyéb üzleti alkalmazások.

Miért fontos használni a Junk Email foldert?

Az Outlookban megtalálható Junk Email folder mindig is nagy viták tárgya volt. A felhasználók nem szeretik, mert ők csak az Inboxot nézik, az üzemeltetőknek is nyűg, ha sorra érkeznek a ticketek “nem érkeznek meg a leveleim”, holott csak a Junkba került.

Erre a problémára sok helyen azt a megoldást adják, hogy a spam-levelek tárgyába betesznek egy előtagot (prepend subject) pl [SPAM] és így küldik be a felhasználók inboxába. A felhasználók pedig tudomásul veszik, hogy néha bejön valami spam, de fontos levél biztosan nem kerül máshova.

Mindenki elégedett a helyzettel mindaddig, amíg nem jönnek az újabb panaszok: a Junk Email folderbe került a levél. Hát ez megy hogy lehet? Hiszen a spamszűrő (esetünkben Exchange Online Protection) oldalán beállítottuk, hogy a levél tárgyába tegyen valamit és utána Inbox. De mégis…

A válasz az Exchange postafiókokhoz tartozó rejtett antispam-rule (“By default, the junk email rule – a hidden Inbox rule named Junk E-mail Rule – is enabled in every mailbox)

Röviden, ehhez a szabályhoz a Spam Confidence Level (SCL) érték 4-esre van állítva. Ha az EOP ennél magasabb értéket állított be SCL-nek (pl 5-ös) akkor hiába a prepend subject, ettől még a Junk Email folderbe fog kerülni a levél.

Ezt a szabályt ki lehet kapcsolni felhasználónként:

Set-MailboxJunkEmailConfiguration “felhasználónév” -Enabled $false

Vagy az összes postafiókra:

$All = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited; $All | foreach {Set-MailboxJunkEmailConfiguration $_.Name -Enabled $false}

Ezt azért jegyezzük meg, mert később lesz jelentősége: “When the junk email rule is disabled on the mailbox, Exchange can’t deliver messages to the Junk Email folder based on the SCL Junk Email folder threshold”, azaz az Exchange nem fog tudni Junkba mozgatni leveleket. Ezt is akartuk,nem? Feladat teljesítve 🙂

Nos, kikapcsoltuk a fenti hidden szabályt, most már tényleg nem kerülhet semmilyen levél a Junk Email folderbe (ez így nem igaz, hiszen a Blocked Senderektől érkező mailek akkor is itt landolnak majd)

Ezután jön a következő fejvakarás: a spoofed és impersonated-gyanús levelek simán az Inboxban landolnak (a címzett zoltan.istvanffy@qualysoft.com, a feladó pedig zoltan.istvanffy@istvanffy.eu, ráadásul a Display Name is megegyezik, ez elég erősen véleményes lehet, mint megtévesztő)

Belenézve az O365 ATP policykbe, amikkel kontrolláljuk a spoof-impersonated próbálkozásokat, a következő a beállítás:

Hát igen, sajnos az előbb lőttük ki az Exchange képességét, hogy leveleket tudjon mozgatni a Junk Email folderbe, így nem tudott mit tenni, betette az Inboxba.

Visszakapcsolva a Junk Email Rule-t, a következő spoofolt levél már szépen a Junkba kerül:

Sajnos a spoof/impersonate policynél nincs olyan opció, hogy prepend subject, így ezt nem tudjuk beállítani.

És akkor még ott van a ZAP…

A Zero-hour auto purge előnye, hogy a már kézbesített levelek közül is visszamenőleg ki tudja szedni a káros leveleket (ehhez a mailboxnak az Exchange Online-ban kell lennie). Tegyük fel, kapunk egy mailt, benne egy ártalmatlan linkkel. Pár óra múlva a link mögé elhelyeznek egy adathalász oldalt. Erről a Microsoft is hamar tudomást szerez (a Security Intelligence Graph-ba érkező szignálok alapján), és automatikusan elindít egy workflow-t, amivel ezeket a leveleket átteszi a Junk Folderbe. Nagyon szuper szolgáltatás. Igenám, de:

“ZAP moves the message to the Junk Email folder, as long as the junk email rule is enabled on the mailbox ” azaz a működéséhez kell a junk email rule….

pluszban szintén nem működik, ha prepend subject megoldást válaszottunk “Prepend subject line with text: ZAP takes no action on the messagePrepend subject line with text: ZAP takes no action on the message

Összegezve az eddigieket, bár megoldottuk a felhasználóink számára, hogy ne kerüljön semmi a Junk Email folderbe, viszont kilőttünk két fontos védelmi vonalat: spoof-impersonation protection és a ZAP.

Mi lehet a legjobb megoldás: a fentiekből világosan látszik, hogy technikai szempontból a Microsoft erősen támaszkodik a Junk Email folderre. Amennyiben szeretnénk maximalizálni a védelmünket, érdemes átgondoni a koncepciót és használni a beépített lehetőségeket. A felhasználók felé pedig egy alapos (és folyamatos!) kommunikációval meg kell értetni, hogy bár nehézkesebb lehet a Junk Email foldert is figyelni, de összeségében közös érdek a védekezés. Az IT pedig természetesen a finomhangolással biztosítsa, hogy a lehető legkevesebb legitim levél kerüljön a Junk mappába.

Ahogy a bevezetőben is említettem, ez a spam-nem spam-junk kérdés örök vita, de azt látni kell felhasználói-üzemeltetői oldalról, hogy csak közös párbeszéddel-kompromisszummal lehet kezelni a kérdést.