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
Ügyfelekkel való konzultáció során szinte mindig elhangzik a kérdés: melyek az ingyenes Sentinel-konnektorok? Tudjuk őket definiálni, de vannak olyan ingyenes konnektorok, amik tartalmaznak fizetős elemeket is.
Ingyenes adatforrások:
Azure AD Identity Protection
Azure Activity Logs
Office 365
Microsoft Defender for Cloud
Microsoft Defender for IoT
Microsoft 365 Defender
Microsoft Defender for Endpoint
Microsoft Defender for Identity
Microsoft Defender for Cloud Apps
Fontos tisztázni: a data connector bekötése mindig ingyenes. A logfileok esetén csak az Azure Acive Directory és O365 audit logok ingyenesek. A többi logforrásnál csak az alert és incidens generálás és néhány aktivitás ingyenes.
Nézzük egyenként a data connectorokat:
Azure AD Identity Protection:
Előfeltétel: Azure AD Premium 2 licensz
Ingyenes adattipus: Security Alert (IPC)
Azure Activity:
Ingyenes adattipus: minden tipus
Office 365
Ingyenes adattipus: Sharepoint, Exchange és Teams activity
Defender for Cloud:
Ingyenes adattipusok: Security Alert
Defender for IoT:
Ingyenes adattipus: Security Alert
Microsoft M365 Defender:
Ingyenes adattipus: Security Alert és Security Incident
Figyelem: a többi adatbetöltés már számolódik a Sentinel költségbe!
Defender for Endpoint:
Ingyenes adattipus: Security Alert (MDATP)
Defender for Identity:
Ingyenes adattipus: Security Alert (AATP)
Defender for Cloud Apps:
Ingyenes adattipus: Security Alert (Defender for Cloud App)
A Cloud Discovery logok bekapcsolása szintén számolódik a Sentinelben
Összefoglalva:
Mint látjuk, a Microsoft Sentinelt költséghatékony módon tudjuk használni arra hogy az O365 és Azure Activity logokat gyűjtsük és a különböző Microsoft termékekből érkező alerteket is fogadjuk.
Bár tehetjük kötelezővé informatikai szabályzat révén, hogy pl. minden céges adatot tartalmazó dokumentumot/emailt a felhasználók lássanak el a megfelelő sensitivity labellel, az emberi hibát nem lehet kizárni; ha elfelejti rátenni a labelt, adatszivárgási probléma lehet belőle. Illetve ha a meglévő fileokra (pl. Sharepoint Online-ban) is szeretnénk “védelmet”, szintén segítségül hívhatjuk az M365-öt.
Érdemesebb hát az automatizmust felhasználni, a client-side labeling és service-side labeling segítségével.
A licenszelési előfeltétele: Microsoft 365 E5/A5/G5, Microsoft 365 E5/A5/G5/F5 Compliance and F5 Security & Compliance, Microsoft 365 E5/A5/G5 Information Protection and Governance, Office 365 E5, Enterprise Mobility + Security E5/A5/G5, and AIP Plan 2
Ennél a módnál “on-the-fly” történhet meg a labelezés az épp szerkesztés alatt álló dokumentumban vagy emailben. Amennyiben a rendszer érzékeli, hogy szenzitív adatokat tartalmaz (ezt nekünk kell definiálni a beállításokban), felajánlja a felhasználónak az adott label alkalmazását vagy kötelezően ráteszi.
Az alábbi példában látható, ha a dokumentum tartalmaz TAJ-számot, ajánlja fel a felhasználónak a label használatát:
Ennél a módnál nemcsak az újonnan létrehozott dokumentumok labelezést lehet ellátni, hanem a meglévő, helyben tárolt adatokra is. Ugyanazokat a feltételeket lehet konfigurálni, mint a fenti client-side példában:
Kiválaszthatjuk, hogy melyik label alkalmazódjon:
A policyt első alkalommal kötelezően Simulation mode-ban kell futtatni:
Ha mindent rendben találtunk a szimuláció lefutása után, engedélyezhetjük a tényleges alkalmazódást a fileokra. A label automatikusan rákerül a megfelelő fileokra, anélkül hogy a felhasználónak egyenként kellene megnyitni/alkalmazni azt.
Jó tudni:
Néhány korlátozás, amit szem előtt kell tartani.
Ha egy file már tartalmazott egy kézzel hozzáadott labelt, az automatizmus nem cseréli le.
Az automatic labeling felülírja a default sensitivity labelt (ha volt definiálva)
A service-side labeling nem alkalmazza a labelt meglévő emailekre, csak küldéskor (data in transit) teszi rá
Maximum 25 ezer automatic labeling művelet lehet naponta.
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:
A Microsoft Endpoint Managerrel (régi nevén Intune) szabályozhatjuk a windows frissítések telepítését.
Az update és reboot mindig is küzdés volt a felhasználók és adminok között: “munka közben indult újra a gépem”, “frissítéskor csak teker és nem tudok dolgozni”, csak hogy pár panaszt említsünk. Sok esetben ezt a problémát a rosszul beállított update policy okozza.
Nézzük, hogy a MEM-ben milyen lehetőségeink vannak. A cikkben most csak az update telepítés és reboot részre térek ki, a többi opcióra nem.
Ha megnyitjuk a Windows 10 update ring-et, a következő beállításokat látjuk az User Experince Settings / Automatic update behavior résznél:
Az egyes beállítások részletezése:
Notify download: letöltés és telepítés előtt figyelmezteti a felhasználót, akinek kézzel kell elvégeznie a műveleteket.
Auto install at maintenance time: a maintenance időben letölti és telepíti a frissítéseket, kivéve ha a felhasználó használja a gépet, vagy pl. nincs töltőre dugva. A maintenance időt az Active hours beállítással adhatjuk meg (pl. 8-17 óra között nincs automatikus letötlés és telepítés-restart). Az újraindításhoz kéri a felhasználó engedélyét, ha ez nem történik meg 7 napig, utána magától újraindul.
Auto install and restart at maintenance time: hasonló az előző beállításhoz, csak itt a telepítés után automatikus restart következik (ha az eszköz nincsen használva). Az Active Hours megadásával a reboot itt is kontrollálható. A nem menedzselt eszközökhöz ez az alapbeállítás: telepítés után auto restart, ha nem hasznáják a gépet.
Auto install and restart at scheduled time: definiálhatjuk a telepítés napját-idejét. A telepítést követően elindul egy 15 perces visszaszámláló, amit a felhasználó elhalaszthat. Alapértelmezetten hajnali 3-kor telepít.
Auto install and reboot without end-user control: a frissítések letöltése és telepítése automatikusan megtörténik. Amikor az eszköz nincs használatban, a reboot is követi. Ennél az opciónál a felhasználónak csak read-only joga van a beállítási ablakon.
Reset to default: visszaállítja alaphelyzetre az auto update beállításokat
A fenti beállításokból kiválasztható a szervezet igényeinek megfelelő update mechanizmus.
A következőkben tekintsük át, hogy milyen figyelmeztetési lehetőségek vannak, a felhasználók felé.
Telepítés után, ha újraindításra van szükség, egy felbukkanó pop-uppal jelzi a rendszer. Ez a figyelmezetés 25 mp után eltűnik, és csak a kis ikon marad az óra mellett:
Amennyiben azt szeretnénk, hogy ez a figyelmeztetés megmaradjon és a felhasználónak kelljen nyugtáznia, kapcsoljuk be a Require user approval to dismiss restart notification részt a policyben:
Szintén egy hasznos funkció, ha a felhasználó figyelmét felhívjuk a közelgő kötelező újraindításra. Evvel lehetőséget adunk, hogy reboot előtt elmentse a megnyitott munkáit. A következő figyelmeztetéseket tudjuk megjeleníteni:
Azaz hogy az újraindulás előtt 4 órával fedobjon egy figyelmeztető üzenetet a felhasználónak, 30 perccel előtte pedig már egy elnyomhatatlan figyelmeztetés jelenik meg, visszaszámolással. Természetesen ezeket az értékeket állíthatjuk.
A frissítések telepítését és a gépek kötelező újraindítását kezelhetjük a Deadline beállításokkal is. Ennek lényege, hogy meghatározzuk, mikor kerüljenek fel az update-ek és mikor történjen az újraindítás.
A deadline a frissítés megjelenésétől számítja a megadott napokat. A fenti példa alapján, ha 10-én jön ki a frissítés a Microsoft Update-re, akkor legkésőbb 3 nap múlva automatikusan telepíti és megpróbálja az újraindítást is, ha az eszköz nincsen használatban. Ha definiáljunk Grace Period értéket, akkor annak értékével halasztja. Ez különösen hasznos, ha a felhasználó pl. szabadságról tér vissza, és így kap időt, hogy a telepítés-újraindítás kontrolláltan, pl. másnap történjen.
A deadline beállításokkal egy sokkal szorosabb frissítési ütemet tudunk kialakítani, mint az első részben taglalt beállításokkal. Amennyiben ezt a módszert választjuk, ne felejtsük el a Quality update deferral period (days) és Feature update deferral period (days) értékeket 0-ra tenni, különben policy conflict keletkezhet.
A deadline esetében max 30 napot határozhatunk meg.
Ajánlott konfiguráció: itt tennék egy szubjektív ajánlást, hogyan érdemes beállítani a teljes policyt:
Quality update deferral period (days): 7 nap. Így egy hétig nem ajánlja fel a frissítés telepítését, az IT addig tudja tesztelni a patch-et
Automatic update behavior: Auto install at maintenance time. A nem aktív időben a frissítések települnek és megjelennek a reboot kérő üzenetek, 7 napig. 7 nap után kötelező lesz a reboot, amiről figyelmeztetéseket jelenít meg.
Active hours start: 8 AM
Active hours end: 4 PM
Restart checks: Allow. Ha alacsony az akku töltöttsége, vagy presenting módban van a gép, akkor nem indul újra.
Require user approval to dismiss restart notification: Enabled. A felhasználónak kézzel kell leokéznia a pop-upot, evvel is tudatosítva benne, hogy a gépe újraindításra vár.
Remind prior to requried auto-restart with dismissible reminder: 8 óra
Remind prior to requried auto-restart with permament reminder: 1 óra
Change notification update level: Use the default Windows Update notifications
Összefoglalva: az update ring beállításkészlettel megtalálhatjuk a középutat a frissítések telepítése és felhasználói élmény negatív befolyásolása között.
Sokszor nemcsak az ügyfelek, de a tanácsadók is elveszettek lehetnek, hogy melyik M365 csomagban milyen szolgáltatás szerepel, milyen limitációkkal stb.
Az alábbi két táblázat hasznos lehet, hogy eligazodjuk a “rengetegben”
Ü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.
A Seamless SSO segíti a felhasználói élményt, hogy domain-joined gépeken automatikusan bejelentkeznek az Azure AD-ba.
Amikor az AD Connect segítségével konfiguráljuk az SSO-t, a földi domainben létrejön egy AZUREADSSOACC computer objektum. Ez felelős érte, hogy megvalósuljon az SSO az Azure AD-val. A működésének rövid leírása:
Felhasználó be szeretne jelentkezni egy felhős web app-ba.
Az App átírányítja az Azure AD-hoz.
Az adott App nem továbbít semmilyen domain vagy tenant információt, ezért meg kell adni a felhasználónak a felhasználó nevét.
A webbrowser 401-es hibát ad, mert nincs érvényes kerberos ticket.
A felhasználó böngészője kerberos jegyet igényel a “AZUREADSSOACC” objektumhoz. Igen és itt nyer értelmet ez az objektum, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget és ez az objektum képviseli az Azure AD-t.
Kapunk egy kerberos ticketet a “AZUREADSSOACC” objektumhoz, ami titkosítva lesz a “számítógép” kulcsával.
A felhasználó böngészője elküldi a titkosított kerberos ticketet.
Azure visszafejti a titkosított kerberos ticketet, azzal a kulcssal, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget.
Amennyiben érvényes a jegy, akkor a böngésző visszakap egy tokent, amivel hozzáférhet az erőforráshoz.
Ezáltal a felhasználó sikeresen bejelentkezett a wep app-ba, anélkül, hogy megadta volna a jelszavát.
Ez az objektumot érdemes egy külön OU-ba tenni és bekapcsolni rajta a “protect object from accidental deletion” opciót is.
A Kerberos-kulcs (decryption key) a lényeges, ezt érdemes legalább 30 napota cserélni. Ha nem tesszük, akkor kerül ki az Azure portálra a figyelmeztető ikon.
Hogyan cseréljük a Kerberos-kulcsot?
A művelethez szükségünk van Global Administrator és Domain Admin jogosultságra. Lépjünk be az AD Connect szerverre és admin powershellben navigáljunk el a “Microsoft Azure Active Directory Connect” mappába:
cd “C:\Program Files\Microsoft Azure Active Directory Connect\”
Importáljuk be az SSO modult:
Import-Module .\AzureADSSO.psd1
A következő paranccsal végrehajtjuk a hitelesítést az Azure AD felé:
New-AzureADSSOAuthenticationContext
Futtassuk le a kulcs-csere parancsot, és hitelesítsük magukat a földi AD felé:
Update-AzureADSSOForest
A hitelesítés után megtörténik a kulcs cseréje:
Rövid idő után frissül az Azure portálon is:
Összefoglalva: evvel az egyszerű művelettel érdemes legalább 30 naponta frissíteni a Kerberos-kulcsot. Az AZUREADSSOACC objektumra kevés figyelem jut, de érdemes jól “eltenni” egy külön OU-ba és bekapcsolni rajta a véletlen törlés elleni védelmet.
Az Azure AD egyik, még Preview fázisban lévő megoldása, a Continous Access Evaluation jó eszköz lehet, hogy még robosztusabb legyen a hozzáférési szabályzatunk.
Amikor egy felhasználó bejelentkezik egy online szolgáltatásba (pl. Exchange Online), akkor az Azure AD egy hozzáférési tokent állít ki számára, egy óra érvényességgel. A token érvényésségének lejártáig él a hozzáférés.
(az időtartam egyébként szabályozható, pl. conditional access session control segtíségével)
Nézzünk egy alappéldát:
Mi történik, ha letiltunk egy felhasználót?
Sajnos, a token érvényessége ettől még megmarad és továbbra is eléri az online szolgáltatást. Ez sok szervezet számára elfogadhatatlan, és szükség van granulárisabb megoldásra.
Itt jön képbe a Conditional Access Evaluation (CAE). Ennek lényege, hogy bizonyos események hatására az addigi token érvényessége azonnal megszűnik és szükséges lesz egy újra-authentikáció végrehajtása.
Milyen eseményeknél történik meg?
A felhasználói fiókot letiltjuk/töröljük
Jelszóreset vagy jelszócserét követően
MFA engedélyezésekor a felhasználó számára
Az admin visszavonja a meglévő hozzáférési tokeneket
Azure AD Identity Protection magas kockázatot érzékel
Valamelyik esemény bekövetkeztekor gyakorlatilag egy percen belül megszűnik a hozzáférés a Sharepoint Online, Exchange Online és Teams szolgáltatásokhoz (jelen preview állapotban ezt a két szolgáltatást támogatja). Saját tesztelés alapján 20-30 mp elteltével jöttek az authentikációs popup-ok, laptopon-telefonon-tableten egyaránt.
Milyen alkalmazások támogatják a CAE-t?
Alapesetben a kliensek megpróbálják felhasználni a már meglévő tokent a hozzáféréshez. CAE-vel a kliens az ún. claim challenge segítségével tudja, hogy nem a tárolt tokent kell használnia, hanem újat kell kérnie az Azure AD-tól (authentikáció bekérése)
Az alábbi alkalmazások CAE-kompatibilisek:
Outlook Windows
Outlook iOS
Outlook Android
Outlook Mac
Outlook Web App
Teams for Windows (Only for Teams resource)
Teams iOS (Only for Teams resource)
Teams Android (Only for Teams resource)
Teams Mac (Only for Teams resource)
Word/Excel/PowerPoint for Windows
Word/Excel/PowerPoint for iOS
Word/Excel/PowerPoint for Android
Word/Excel/PowerPoint for Mac
Hogyan működik a gyakorlatban?
Az alábbi példában úgy állítottuk be a Conditional Access policyt, hogy az online szolgáltatást csak meghatározott IP-tartományokól elérhető (pl. irodai hálózat)
A CAE-kompatibilis kliens megkéri a tokent az Azure AD-tól (vagy felhasználja a tárolt érvényes tokent)
A Conditional Access Policy megvizsgálja a hozzáférési kérést és engedélyezi (mivel az irodai hálózatban van)
A kliens megkapja a hozzáférési tokent
A felhasználó elmegy az irodai hálózatból, átvált mobilnetre
A kliens az engedélyezett IP-tartományon kívülről küldi a hozzáférési kérést
Az Azure AD megvizsgálja a kérést
Az Azure AD megtagadja a hozzáférést és 401+ claim challenge-et küld vissza a kliensnek
A kliens értelmezi a 401+ claim challenge-t, és nem próbálja a tárolt tokent használni, hanem újat kér
A Conditional Access megtagadja a hozzáférést, mert nem a policyben engedélyezett IP-tartományokból érkezett a kérés.
Ide kell felvinni azokat az IPv4 és IPv6 tartományokat, amikre szeretnénk ebben az esetben a CAE-t hasznáni.
Összefoglaló:
A CAE egy nagyszerű irányba mutató fejlesztés, és bízhatunk benne, hogy a preview után még több funckióval bővül. Addig is, érdemes kipróbálni és használatba venni.
Zoltan Istvanffy's IT Blog 