About Zoltan Istvanffy

Microsoft Cloud Solution Architect

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

Sensitivity Auto-labeling: az automatizmus lehetőségei

Az M365 labeling funkciója (https://docs.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels?view=o365-worldwide) biztosít manuális és automatikus labelezést, ezúttal az automatikus megoldást tekintenénk át.

Miért fontos az automatizmus?

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

Client-side labeling:

(https://docs.microsoft.com/en-us/microsoft-365/compliance/apply-sensitivity-label-automatically?view=o365-worldwide#how-to-configure-auto-labeling-for-office-apps)

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:

Service-side labeling:

(https://docs.microsoft.com/en-us/microsoft-365/compliance/apply-sensitivity-label-automatically?view=o365-worldwide#how-to-configure-auto-labeling-policies-for-sharepoint-onedrive-and-exchange)

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.
  • Maximum 10 auto-labeling policy per tenant.

Certificate Authority felderítése

Biztosan sokan futottak már bele olyan problémába, hogy egy ügyfél rendszerébe belépve szükség lenne a Certification Authority kiszolgálók felderítésére (pláne ha az ügyfél nem is tudja hogy van CA-ja és hol…)

Az alábbi rövid parancs ilyenkor segít nekünk. Futtassuk le cmd-ből bármelyik domain member gépről:

certutil -config – -ping

Megkapjuk a működő CA-k nevét illetve szerverét:

USB-adathordozók kontrollálása

Régi-régi igény a vállalatoknál, hogy az USB-eszközket kontroll alatt tartsák, megakadályozva az esetleges adatszivárgást. Erre jó választ ad az Intuneban is megtalálható Device Control funckió. Ugyanezt tudja biztosítani Group Policy segítségével is.

A Windows 10 21H1-gyel érkezett meg az “Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria” GPO-beállítás, ami lehetővé teszi, hogy ne csak szimpla tiltás-engedélyezés legyen, hanem kicsit granulárisabban. Például hogy tiltsunk minden USB-adathordozót, de tudjunk kivételeket is felvenni. A gyakorlati példában ezt fogom bemutatni.

Az alábbi flow mutatja a layered policy működését:

Ahogy látható, a Device Instace ID a legerősebb, ez jelenti magát az adott USB-eszközt. Ilyen példa a USBSTOR\DISK&VEN_KINGSTON&PROD_DTR30G2&REV_PMAP\001A92053F1CBF9161021EF9&0

Ezt az ID-t látjuk, ha a Device Managerben megnézzük az eszköz DeviceInstancePath értékét.

A sorrendben következő a Device ID, ami már általánosabb. Ezt a Compatible IDs kiválasztásával kérdezhetjük le

A gyakorlati példánkhoz elég ez a két érték. Most lássuk, hogyan valósítható meg Intune-managed gépeken esetén, hogy alapból tiltsunk minden USB-adathordozót, de specifikus eszközöket mégis engedélyezzünk.

Első lépésben engedélyeznünk kell az “”Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria” beállítást.

Ezt egy Custom OMA-URI beállítással tudjuk megtenni:

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceInstallation/EnableInstallationPolicyLayering

Data type: string

Value: <enabled/><Data id=”AllowDenyLayered” value=”1″/>

Következő lépésben hozzunk létre egy új Attack Surface Reduction profilt:

https://endpoint.microsoft.com/#blade/Microsoft_Intune_Workflows/SecurityManagementMenu/asr

Válasszuk a Windows 10 or later és Device Control kategóriát

A policyben állítsuk be a “Block hardware device installation by device identifiers” résznél a következő értékeket:

USBSTOR\Disk

USBSTOR\RAW

Evvel elértük, hogy minden USB-adathordozó tiltásra kerül. A felhasználók ezt látják majd, ha adathordozót csatlakoztatnak:

Illetve a gépen a C:\Windows\INF\setupapi.dev.log fileban is logolja:

A következő lépésben tudjuk felvenni az adott USB-adathordozók egyedi azonosítóit, amiket szeretnénk engedélyezni:

A policyben állítsuk be a “Allow hardware device installation by device instance identifiers” résznél a kívánt értékeket:

A policy frissülése után megnézhetjük, hogy az értékek bekerültek-e a registrybe:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceInstallation

Innentől kezdve csak a policyben meghatározott DeviceInstanceID-jú USB-eszközöket lehet használni.

A fenti beállítások természetesen nem értntik az egyéb USB-eszközöket, tehát billentyűzet/egér/nyomtató stb ugyanúgy működő marad.

Összefoglalva: mind Intune beállításokkal, mind klasszikus GPO-beállításokkal megoldható az USB-adathordozók granuláris kezelése.

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.

Windowsupdate – automatic update és reboot opciók menedzselése

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.