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
Ü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?
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.
Az Outlook az AzureAD-hoz fordul, végrehajtja a modern auth folyamatot, alkalmazódnak rá az esetlegesen beállított Conditional Access szabályok.
A sikeres auth után a felhaszáló megkapja az Access Tokent és Refresh Tokent.
Az Access Tokent átadva a földi Exchange szervernek, a mailbox elérhetővé válik.
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.
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
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:
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.
Ü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ény
Választás
Mailboxok gyors migrációja
Minimal Hybrid
Office 365 mailboxok kezelése és földi AD szinkronizálása
Minimal Hybrid
Global Address List fenntartása a földi és and Office 365 között
Minimal Hybrid
Organization configuration beállítások szinkronizálása, pl. ActiveSync policyk
Minimal Hybrid
A mailboxok migrációjának előkészítése (pre-sync) és migráció befejezése alkalmas időben
Minimal Hybrid
Bejövő és kimenő levelezés a földi Exchange-en keresztül kell történjen
Full Hybrid
Földi Exchange és Exchange Online közötti levélforgalom TLS-sel legyen titkosított
Full Hybrid
Megtartani a mailek eredeti fejlécét , ami szükséges a mailtippek és out of office válaszokhoz
Full 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ása
Full Hybrid
Integráció Skype for Business / Teams és Exchange 2016 mailboxok között vagy cross-premises eDiscovery használata
Full 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.
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:
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:
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.