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
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.
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:
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:
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.
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”
Zoltan Istvanffy's IT Blog 