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.

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.

M365 Enterprise és SMB csomagok összehasonlító táblázatok

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”

M365 Enterprise csomagok összehasonlító táblázat (PDF)

M365 SMB csomagok összehasonlító táblázat (PDF)

Háttérzajok elnyomása Teams meetingek során

A pandémia miatt nagyon sokan kényszerülnek otthonról dolgozni és meetingelni, ahol sokszor korántsem ideálisak a körülmények: pont akkor kezd el falat fúrni a szomszéd (ő is otthon van, ráér 🙂 ), a másik szobából áthallatszik a kisgyerekek zsinatolása, és még ezer háttérzaj lehet, ami zavarhatja a Teams-meetingeket.

Év végére megérkezett a frissítése a Teams szolgáltatásba, ami beépített zajszűrőt használ. A mesterséges intelligencia folyamatosan elemzi a hangokat és képes kiszűrni a nem beszédhez tartozó zajokat.

A Teams kliensben a Settings / Devices résznél találjuk a Noise Suppression beállításokat:

A következő opciók vannak:

  • Auto: a Teams figyeli a háttérzajokat és szükség esetén kiszűri őket, pl. kutyaugatás vagy papírzörgés
  • Low: a zajszűrés folyamatos, ideális ha pl. a háttérben zenét hallgatnak
  • High: minden zajt eltávolít, ami nem beszédhez köthető
  • Off: nincs zajszűrés

Az alapbeállítás az Auto, érdemes ezen maradni és hagyni, hogy a mesterséges intelligencia tegye a dolgát. A magasabb szintű szűrések (Low, High) viszont többletterhelés a gépnek, CPU szinten.

Amennyiben olyan “szerencsénk” van, hogy a szomszéd fúrni kezd, akkor a meeting idejére érdemes a High opciót választani.

Remote Desktop Gateway és Azure MFA integráció

Az RD Gateway elég régóta létező komponens, segítségével megoldható a belső hálózaton található gépek RDP elérése, biztonságosan (TCP 443-as porton keresztül)

A pandémiás helyzet miatt sok cégnek kapóra jöhet ez a megoldás. Jön az igény: a céges PC-met el kellene érnem az otthoni gépemről, mintha azon dolgoznék. Lehetőleg biztosítva az identitásellenőrzést is, azaz a név/jelszó pároson kívül legyen többfaktoros hitelesítés is.

Lássuk, hogyan lehet ezt egy meglévő RD Gateway és Azure MFA-val megoldani! (Az RD Gateway telepítés-konfigurálás lépéseket a cikk nem tartalmazza)

Előfeltételek:

  • Azure MFA licensz a felhasználónak, Authenticator konfigurálva push notification módra
  • Földi Active Directory integrációja az Azure AD-val (dirsync)
  • Remote Desktop Gateway konfigurálva és elérhető az internet felől (pl. tsgw.corp.com címen)
  • Földi Network Policy and Access szerepkör telepítve

Azure AD tenant ID beszerzése

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview linken kiolvashatjuk a tenant id-t. Ezt mentsük el a későbbi használat miatt.

Azure NPS Extension telepítése

Az NPS szerverre telepíteni kell az Azure MFA extensiont. Vigyázat! A telepítés után minden authentikációs kérést az Azure felé fog küldeni, ezért feltétlenül fontos, hogy külön NPS szervert használjunk. Ellenkező esetben a wifihez/vpn-hez használt NPS-t működésképtelenné teheti.

Töltsük le az extensiont és teleptsük fel:

https://www.microsoft.com/en-us/download/details.aspx?id=54688

Telepítés után konfiguráció következik. Admin powershellből navigáljunk a “c:\Program Files\Microsoft\AzureMfa\Config” folderbe és indítsuk el az .\AzureMfaNpsExtnConfigSetup.ps1 scriptet.

Majd a felugró ablakban jelentkezzünk be Global Adminként

A script bekéri majd a Tenant ID-t, ezt másoljuk be és nyomjunk Entert:

Connection authorization policy beállítása központi használatra

Remote Desktop connection authorization policies (RD CAPs) szükségesek az RD Gateway-hez kapcsolódáshoz. Alapértelmezetten ezek a policy lokálisan vannak tárolva, de ez esetben át kell állítani központi RD CAP Store-ra.

Nyissuk meg az RD Gateway szerveren a Remote Desktop Gateway Managert. Jobb klikk a szerver nevén, Properties, RD CAP Store és a Central Server running NPS résznél vegyük fel a kívánt NPS nevét vagy IP-jét

Adjunk meg egy erős, hosszú shared secretet és mentsük el a későbbi használathoz.

RADIUS Timeout átállítása

A RADIUS timeout értékét át kell állítani az alapértelmezettről, hogy a felhasználónak legyen ideje a kétfaktoros hitelesítést végrehajtani.

Ehhez az RD Gateway szerveren indítsuk el a Network Policy Server konzolt, majd menjünk a Radius Clients/Remote Radius Server részre. Nyissuk meg a TS Gateway Server Groupot. Itt megjelenik az általunk beállított radius szerver, kattintsunk az Edit…-re. A Load Balancing tabon látunk két értéket:

Number of seconds without response before request is considered dropped

Number of seconds between requests when server is identified as unavailable

Ezek értékét állítsuk át 60-ra

Connection Request Policy ellenőrzése

Az RD Gateway-en nyissuk meg a Network Policy Server konzolt, keressük meg a Policies / Connection Request Policies részt. Kattintsunk duplán a TS GATEWAY AUTHORIZATION POLICY-re, majd Settings és végül Authentication. Győződjünk meg róla, hogy a kérések biztosan a távoli NPS szerverre mennek:

NPS konfiguráció

Az NPS szerveren, ahol telepítettük az MFA Extsensiont, nyissuk meg az NPS konzolt, és adjunk hozzá RADIUS klienst:

A new radius client ablakban adjuk meg az RD Gateway nevét és IP/DNS nevét, illetve írjuk be a korábban elmentett Shared Secretet:

Network Policy konfiguráció

Az NPS szerveren indítsuk el az NPS konzolt, nyissuk ki a Policies ágat és válasszuk a Network Policies részt. Kattintsunk jobb klikkel a “Connections to other access servers” policyre és válasszuk a “Duplicate policy” opciót:

Nevezzük át a policyt, kapcsoljuk be a “Policy enabled” részt és válasszuk a “Grant access opciót:

Kattintsunk át a “Constraints” fülre és pipáljuk be az “Allow clients to connect without negotiating an authentication” method opciót:

Mentsük el a policyt, majd győződjünk meg róla, hogy engedélyezve van és a lista elején áll:

Csatlakozás RDP klienssel

Miután végeztünk minden konfigurációs beállítással, teszteljünk. Indítsuk el az RDP klienst és csatlakozzunk egy belső géphez a szokásos beállításokkal:

Ha mindent jól csináltunk, a telefonon meg kell jelennie az Authenticatior üzenetnek, ahol a belépést jóváhagyhatjuk:

Hibakeresés, logok ellenőrzése

Probléma esetén segítségül hívhatjuk az eventlogot. Az RD Gateway szerveren nyissuk meg az Event Viewert és navigáljunk el Network Policy and Access Services custom nézethez:

Összefoglalás: az RD Gateway kényelmes és hasznos megoldás, amit az Azure MFA Extensionnal biztonságosabbá is tehetünk.

Távollévő gépek menedzselése

A céges hálózattól tartósan távollévő gépek menedzselésének kérdése nem újkeletű, több szervezetnek is okozott már fejfájást. Illetve új problémaként felmerült a COVID miatt, hogy sok felhasználó hirtelen távolról kényszerült dolgozni az eszközével.

Mit értünk tartósan távollévő gép alatt?

Olyan laptopokat, amik a felhasználási sajátosságok miatt alig lépnek be a céges hálózatba, legyen az irodai hálózat vagy VPN. Néhány opció:

  • orvoslátogatók laptopjai
  • biztosítási és egyéb utazó ügynökök laptojai
  • alvállakozók, akik kapnak céges laptopot, de nincs igény a belső hálózat elérésre

Kiemelten jó példa a gyógyszeripari cégeknék az orvoslátogatók gépei. Kapnak céges eszközt, használják a levelezést, a munkájukat tudják végezni, az irodába nagyjából sosem mennek be, hálózatra nem csatlakoznak fel.

Mi történik menedzsment szempontból egy ilyen géppel?

  • 30 nap után megszűnik a domaines secure channel (“kiesik a domainből”)
  • Az előírt group policyk nem futnak le, nem frissülnek
  • A startup és logon scriptek nem futnak le
  • A wsus/sccm által kezelt frissítések nem települnek a gépre
  • Legrosszabb esetben akár az antivirus definiciós frissítések sem jutnak le a gépre (volt példa, ahol tiltották a frissítések internetről letöltését is)

Amint látjuk, ez a helyzet kellemetlen az IT-számára, hiszen ezen gépek felett gyakorlatilag elveszítette a kontrollt. A menedzselhetőség innetől a felhasználótól függ (mikor megy be az eszközzel céges hálózatra, mikor kapcsolja be a VPN-t stb…és milyen rossz az, mikor a céges bérelt vonalon kezd töltődni az akár több GB-os SCCM-csomag 🙂 ) A kockázat pedig adott: nem kerülnek fel a biztonsági frissítések, az IT nem értesül a gépet érintő incidensekről és lehetne sorolni.

Mi lehet a megoldás?

Toljuk ki a menedzsment határait a céges hálózaton kívülre! Gondoljuk át, hogy milyen nagyszerű lenne, ha az IT-felügyelet az Interneten kereszül történhetne! Az orvoslátogatók gépeinek üzemeltetői repesnének az örömtől.

Csináljunk Hybrid Azure AD joint, vagy akár Azure AD joint, Microsoft Endpoint Management (MEM) felügyeleti eszközzel párban. Evvel a következő lehetőséghez juthatunk (maradva az orvoslátogatók gépeinél)

  • Az on-premise domain gépet beléptetjük az AzureAD-ba is (ezt nevezzük Hybrid Azure AD joinnak. Innenől az AAD “ismeri” a gépobjektumot
  • Nincs secure channel hiba többé
  • A MEM segítségével teljeskörűen tudjuk menedzselni a gépet: frissítések telepítése, scriptek futtatása, VPN, emailfiók konfigurációk leküldése, megfelelőségek ellenőrzése (pl. lemeztitkosítás be van-e még kapcsolva), központi szoftvertelepítések
  • Jelentések-leltár futtatása a távoli gépeken, folyamatos státuszriportolással

Láthatjuk, hogy evvel a megoldással visszakapjuk az elveszett kontrollt a távollévő gépek felett.

Összegzés: érdemes átgondolni a kliensmenedzsment kérdését és válaszolni az új igényekre (céges hálózat nélkül is a kontroll megléte), erre az AzureAD és MEM egy jó alternatíva lehet.

Kerberos – határok nélkül

Bizonyára nagyon sokan ismerik a Kerberos authentikációt, on-premise környezetben főleg. Szeretjük is, mert biztonságos és működik vele a single sin-on (SSO). Ha a felhasználónk már authentikálta magát, akkor a további erőforrások eléréséhez nem kell újra megtennie, a háttérben intéződik.

Emlékeztetőül, a klasszikus Kerberos-hitelesítés így történik:

Így ha egy active directory userrel vagyunk belépve és megpróbáljuk elérni a pl. a belső sharepointot (pl. https://sharepoint.company.com), akkor a háttérben megtörténik a hitelesítés és a felhaszáló eléri az erőforrást (természetesen vannak előkövetelmények, SPN legyen beállítva). Ha nincs SPN definiálva, akkor Kerberos helyett NTLM hitelesítéssel próbálkozik (ez is SSO még, de jóval nagyobb terhelés a kiszolgálónak a challenge/response folyamat miatt), ha az NTLM sem sikerül, akkor felugrik a jelszóbekérő ablak. Természetesen mindez függ, hogy a Sharepointnál milyen hitelesítést állítottunk be:

Tehát van működő Kerberos és SSO. Viszont, ahogy láttuk, a működéshez kell a Ticket Granting Service, azaz a domain controller. Ha ez kiszolgáló nem elérhető hálózati szinten, a Kerberos nem működik.

Mi lehet a megoldás, ha távolról, céges hálózat nélkül szeretnénk elérni a belső alkalmazásokat, SSO-val? A régi megoldás a VPN kapcsolat, de az nehézkes, komplexé tehet az infrastruktúrát.

A modern megoldás, ha Azure AD Application Proxyt használunk, melynek segítségével a belső webalkalmazásokat elérhetjük SSO-val, az Azure AD segítségével.

Nézzük, hogyan lehet egy belső alkalmazást publikálni:

Előfetétel: az AAD App Proxyhoz Azure AD P1 vagy P2 licensz szükséges.

Azure AD Connect megléte, felhasználók szinkronizálása az AzureAD-ba.

Működése:

A felhasználó szeretné elérni a belső alkalmazást, először az Azure AD-hoz fordul. Az AAD továbbítja őt az Application Proxy Service-hez, ami kommunikál az előzőleg a földi környezetbe telepített Application Proxy Connectorral. Itt megtörténik az authentikáció és a felhasználó megkapja a hozzáférést.

  1. lépés

Application Proxy Connectorok telepítése: két on-premise kiszolgálóra telepíteni kell a Connector agentet. A két agent a redundancia miatt szükséges. Amennyiben Kerberost akarunk használni, a két szervernek ugyanannak a domainnek tagja kell legyen, mint ahol a belső erőforrás található. A telepítés menete itt olvasható:

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application

Amennyiben a Connectorok telepítve vannak, lehet őket csoportokba rendezni:

A csoportba rendezés lehetővé teszi hogy különböző applikációkhoz külön Connector Agenteket rendeljünk.

2. lépés

Enterprise Application létrehozása: itt hozzuk létre az AzureAD-ban a publikálni kívánt alkalmazást.

https://portal.azure.com/#blade/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/AllApps/menuId/

Válasszuk a New Applicationt, majd a következő oldalon az “On-premies application” lehetőséget:

A Basic Settings résznél töltsük ki az Internal és External URL részeket. Ennél a példánál split-dns van, tehát a külső és belső névtér megegyezik. Így az internal és external url egyaránt https://sharepoint.istvanffy.eu lett. A pre-authentication legyen “Azure Active Directory”, a Connector Groupot pedig állítsuk be, ha szükséges (tesztkörnyezetben maradhat Default-on)

Az Additional Settings résznél hagyjuk az alapbeállításokon:

Az így elkészült alkalmazásnál a Properties résznél kapcsoljuk ki az “User assignment required” opciót.

Ha ezt nem tesszük, akkor csak azok a felhasználók férnének hozzá az alkalmazáshoz, akiket a Users and Groups résznél engedélyezünk. Ez hasznos lehet, ha szeretnénk csoportszinten megszabni, kik érhetik el az alkalmazást. Egyéb esetekben (ha mindenkinek szeretnénk elérhetővé tenni) ki kell kapcsolni.

3. lépés

Single Sign-on beállítása: a létrehozott alkalmazásnál navigáljunk el a Single Sing-on részhez és az alábbi beállításokat találjuk

Mivel mi a Kerberost szeretnénk megvalósítani, válasszuk a Windows Integrated Authentication opciót.

Itt meg kell adnunk az on-premise környezetben beállított SPN értékét (lásd később)

Vigyázzunk a formátumra, SPN esetén http/sharepoint.istvanffy.eu formában kell megadni. A Delegated Login Identity értékét hagyjuk az User Principal Name formában, így a felhasználó az UPN-jével tud authentikálni.

4. lépés

SPN ellenőrzése: jó esetben már beállításra került a földi környezetben a szükséges SPN. Ezt leellenőrizhetjük egy domaines gépen futtatott setspn -Q http/sharepoint.istvanffy.eu lekérdezéssel.

Amennyiben mégsem létezne az SPN, az alábbi hibát kapjuk:

Ez esetben kézzel kell hozzárendelnünk az SPN-t, a következő paranccsal: setspn -S http/sharepoint.istvanffy.eu <sharepoint szerver neve>

5. lépés

Kerberos delegálás beállítása: a következő lépésben lehetővé tesszük a Connector Agentek számára, hogy a Kerberos-delegálást használják.

Az Active Directory Users and Computers konzolban keressük meg a Connector Agent számítógép objektumát, majd menjünk a Delegation fülre, válasszuk ki a “Trust this computer…” és “Use any authentication protocol” részt

Az Add gombbal keressük ki a sharepoint szerver computer accountját (vagy service userét, ha ahhoz van az SPN hozzárendelve), és válasszuk ki a kívánt service-t (esetünkben a http/sharepoint.istvanffy.eu)

A fenti beállítást ne felejtsük el minden Connector Agent computernél hozzáadni, különben Kerberos-hibákat kaphatunk.

6. lépés

DNS beállítása: ahhoz, hogy az applikáció elérhető legyen az Azure AD-n keresztül, a DNS-t be kell állítani. Esetünkben definiálnunk kell, hogy a sharepoint.istvanffy.eu mutasson az Azure-re. Ezt CNAME-rekord létrehozással tudjuk megtenni, erre az Enterprise Application figyelmeztet is:

7. lépés

3rd party tanúsítvány feltöltése: ahhoz, hogy az applikációt a saját domainnevünkkel tudjuk elérni, szükséges egy harmadik féltől származó tanúsítvány feltöltése az Azure-be. Ezt a tanúsítványt fogja a hitelesítéshez használni és így biztosan nem kapunk böngésző-figyelmeztetéseket

A tanúsítványt pfx formátumban kell feltölteni és megadni a hozzá tartozó jelszót:

Amennyiben később több alkalmazást is publikálánk, a tanúsítványt nem szükséges minden alkalommal feltölteni, elég egyszer.

8. lépés

Tesztelés: ezek után az active directory felhasználóval belépve a gépre (VPN és céges hálózat nélkül) elnavigálunk a publikált alkalmazás linkjére (jelen cikk példájában https://sharepoint.istvanffy.eu) akkor azt tapasztaljuk, hogy a sharepoint rögtön “beengedett”, azaz nem kért authentikációt, sikerült a Kerberos-hitelesítés.

Amennyiben más gépről hívjuk meg a linket, az AzureAD fogja kérni a hitelesítést:

A céges accountot és jelszót megadva szintén megtörténik a hitelesítés.

Hibakeresés:

A leggyakoribb probléma, hogy a Kerberos-delegáció nincs jól beállítva, ez esetben az alábbi hibát kapjuk (incorrect Kerberos constrained delegation configuration)

Ez esetben duplán ellenőrizzük le az SPN és delegációs beállításokat.

Szintén tud segíteni a Connector Agenteken eventlog:

Applications and Services Logs > Microsoft > AadApplicationProxy > Connector > Admin

A teljes hibakeresési link: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-back-end-kerberos-constrained-delegation-how-to

Összefoglalva: megoldható a belső alkalmazások elérése külső hálózatból, a biztonságos és SSO-t nyújtó Kerberos-hitelesítéssel is.

O365 és M365, mi különbség?

Sokszor felmerül ez a kérdés, hogy mi a különbség a két termék között?

Nagyon röviden:

  • Az O365 az productivityhez kapcsolódó termékeket tartalmaz, Office-Teams-Sharepoint stb
  • Az M365 a fentieket tartalmazza, plusz a Windows 10-et és az Enterprise Mobility + Security csomag részeit.

A lenti táblázat részletezi az egyes elérhető komponenseket

Tippek a helpdesk terhelésének csökkentésére

Az utóbbi fél évben bekövetkezett távoli munkavégzés az IT-helpdeskek terhelését jelentősen megnövelte. Nézzünk pár tippet, amivel a felhasználók produktivitása is megmarad, a helpdeskről is levesz terheket és a működési költséget is csökkenti.

  1. Elfelejett jelszavak problémája

Nagyon sok szervezetnél jelent kihívást, hogy kezeljék az elfelejettett felhasználói jelszavak resetelését. Ez mindenkinek rossz, hiszen a felhasználó addig nem tud dolgozni, az IT-helpdesknek pedig ismétlődő unalmas feladat. További kérdés, hogy a megváltoztatott jelszót hogyan juttatják el a felhasznónak (SMS, vagy magán emailcímre küldéssel? Ez vajon bizonságos?)

Azure AD Self-Service password reset szolgáltatással a felhasználó tud jelszót resetelni saját magának is, biztonságos módon (kétfaktoros hitelesítéssel)

A felhasználó pedig ezt látja:

Állítsuk be ezt szolgáltatást és oktassuk le a felhasználóknak. Megfelelő kommunikáció után akár 80%-kal is csökkenhet az “elfelejettem a jelszavam, resetet kérnék” esetek száma.

2. Windows upgrade-ek zavartalansága

A Windows 10-hez évente kétszer érkezik nagyobb frissítőcsomag, melyek telepítése minden esetben nagyon ajánlott. Érdemes up-to-date tartani az operációs rendszereket, mind a biztonsági, mind az egyéb funkcionális frissítések miatt.

Amennyiben viszont nem-Microsoft végpontvédelmi megoldás van használatban, az okozhat gondot a frissítési folyamatnál, ezáltal megint csak jelentős mennyiségű helpdesk-ticketet generálva.

Elkerülhető ez a probléma és a hosszas előzetes kompatibilitási tesztelések, ha végpontvédelmi megoldásnak a Microsoft Defender ATP-t használjuk. Az MDATP-vel nem csak a klasszikus vírusvédelmi megoldást lehet bevezetni, hanem a különböző fejlett támadási formákat is képes detektálni és megállítani.

3. Bátorítsuk a BYOD-ot!

Megint csak egy jellemző problémakör tud lenni az eszközök menedzselése. Új felhasználó érkezik a céghez, laptopra van szüksége, beállításokra, jogosultságokra stb. A gép átvételéhez személyesen kell megjelennie az irodában, várnia, ez mind-mind időveszteség.

Ezek csökkentésére egy megoldás lehet a BYOD-eszközök használata. Amennyiben van mód rá, érdemes bátorítani a felhasználókat hogy használják a meglévő eszközeiket (számítógép, mobil stb), ezáltal “önjáró” módon beálltani a munkakörnyezetét.

A Microsoft Endpoint Managerrel (régi nevén Intune), egy robosztus, biztonságos keretrendszer alakítható ki az ilyen eszközöknek (és természetesen a vállalati eszközöknek is). A MEM-mel biztosítható az eszközök felügyelet alá vonása (enrollment), különböző alap-alkalmazásokat lehet automatikusan telepíteni, VPN-beállítások leküldeni, különféle biztonsági beállításokat előírni.

A fenti környezetek kialakítása nem egyszerű, egylépéses feladat, viszont megéri a befektetést.

Egy cybertámadás forgatókönyve

Az alábbi cikkemben szeretném kötetlenebb stílusban bemutatni, hogyan zajlik egy célzott phishing cybertámadás. A levezetés mellett bemutatom azokat a Microsoft 365 / Azure szolgáltatásokat is, amikkel ezek a támadások lefülelhetők/megállíthatók.

Képzeletbeli támadónk, legyen a neve Mr. X, szeretne bejutni a Riprop Kft céges IT-rendszerébe, hogy onnan értékes adatokat szerezzen meg észrevétlenül. Célja tehát a rejtőzködés, nem a károkozás, így nem is gondolkodik romboló technikákban. A Riprop Kft egy “felhős” cég, a földi infrasruktúrája mellett M365-öt használ.

Mr. X, miután egyszerű script-kiddie megoldásokkal leellenőrizte hogy kívülről nem tud bejutni a hálózatba, másik támadási vektort keresett. Azt már megtanulta, hogy az emberi tényező (mulasztás, hiszékenység) a legtöbb sikerrel kecsegtető lehetőség, így a phishing mail támadás mellett döntött.

Kisméretű botnetje segítségével elkezdett leveleket küldözgetni a Riprop Kft egyes dolgozóinak. Az emailcímek formátumát ismerte (kis.jolan@riprop.com), így könnyű dolga volt. Az adathalász emailt úgy állította össze, hogy a benne lévő link egy O365 loginpage-re hasonlított, a levél tartalma pedig az volt hogy az IT Helpdesk kéri, hogy a belépésével erősítse meg az accountját.

(ennél vannak kifinomultabb támadások is, tudunk olyan esetről, ahol a támadók ismerték a titkárnő színházak iránti rajongását, ezért a kedvenc színháza formátumával preparált adathalász levelet küldtek neki…)

Lehetséges védekezés: az Office 365 Advanced Threat Protection szolgáltatás egy extra védelmi réteg az Exchange Online-ban. Segítségével az adathalász, és egyéb hamisított mailek (pl. a CEO nevében küldött, pénz átultalását utasító) kiszűrhetőek, fejlett AI alapján. Emellett képes a mailekben lévő linkek előzetes megvizsgálására és ha támadó webhelyre mutatnak, akkor letiltja az elérést a felhasználó számára. Szintén képes az emailekben érkező csatolmányok megvizsgálására, egy felhős virtualizált környezetben lefuttatására. Ha a kapott PDF file mondjuk egy preparált darab és megnyitásakor mindenféle gyanús tevékenységet végezne (powershell futtatás, http kapcsolódás egy ismeretlen IP-címhez, stb) akkor a csatolmányt letiltja, nem kézbesíti a felhasználónak.

Az alábbi képen összefoglalva a működése:

Tegyük fel, hogy ez a védelmi megoldás nem volt beállítva Riprop Kft-nál, így az adathalász mailek akadálytalanul bejuthattak. Sajnos kb. harminc dolgozó nem figyelt eléggé, és gondolkodás nélkül megadta a felhasználónevét és jelszavát a kért URL-re kattintva (közben morogva, hogy “jajj, az IT már megint akar valamit, kétnaponta küldenek maileket, azt se tudom már mit akarnak”. (ez nagyon fontos szempont IT-oldalról, hogy nem szabad “elárasztani” infókkal-változásokkal a felhasználókat, hiszen nem tisztjük ilyen mélységben követni. Teljesen jogosan, csak a munkájukat akarják végezni. Fontos tehát megtalálni az egyensúlyt az oktatás-kommunikáció-informálás között, különben a felhasználók közömbössé válnak és könnyebben esnek ilyen tévedések áldozatául)

Lehetséges védekezés: van mód az O365-be jelszó nélkül bejelentkezni. Használható az okostelefonokkal a Phone Sign-in megoldás (az O365 a név megadása után nem jelszót kér be, hanem a Microsoft Authenticator alkalmazáson megjelenít 3 számjegyet és a megfelelőt kell kiválasztani. A kiválasztás után pedig az okostelefon ujjelnyomat-azonosítása a második faktor.

Ha a Riprop Kft-nél ez a megoldást implementálták volna, a dolgozóknak feltűnik, hogy miért jelszót kér a rendszer, mikor mindig Phone SignIn-t használtak.

Szintén használható a FIDO2 biztonsági kulcs erre a célra, az USB-s hardveres kulcs végzi a hitelesítést, jelszó megadására ott sincs szükség.

Támadónk, Mr.X számára tehát megnyílt az aranybánya, volt harminc érvényes felhasználóneve és jelszava a rendszerhez. Mivel lusta volt próbálgatni egyenként a hozzáféréseket, a már meglévő botnetje segítségével kezdett el belogolni a Riprop Kft rendszerébe a megszerzett accountokkal.

Lehetséges védekezés: Az Azure AD Identity Protection szolgáltatás monitorozza a felhasználói belépéseket, szokásokat. Az ezektől eltérő jelenségekre (pl. bejelentkezés ismeretlen országból (ahol a felhasználó nem járt az elmúlt fél évben), lehetetlen utazás megvalósulása (több belépés rövid idő alatt, pl. pár perc eltéréssel Moszkva és Madrid), belépés TOR-hálózatból, vagy botnet-tag számítógépről) azonnal reagál. Az észlelt anomáliákhoz akciókat is tud hozzárendelni, pl. ismeretlen helyről belépés esetén kényszeríti az MFA hitelesítés végrehajtását, vagy kompromittálódott account esetén azonnal letiltja azt és csak a helpdesk oldhatja fel.

(Kompromittálódott accountok: azok, amiknek kiszivárgott a név/jelszó párosa, és megtalálhatóak mindenféle adatbázisokban. Nem titok, a Microsoft elég sok pénzt és energiát áldoz rá, hogy jelen legyen a “darkweben” is, ahol az ilyen adatbázisok megtalálhatók. Ha talál egyezést, az adatbáziban szerepel a név/jelszó páros, azonnal tudja értesíteni az Azure AD-t, aki a fenti módon letiltja az accountot.

Sajnos mivel a Riprop Kft-nél ez a megoldás sem volt implementálva, nem tűnt fel senkinek, hogy tömegesen jelentkeznek be a felhasználók adataival, különböző országokból.

A baj megtörtént, támadónk bejutott a rendszerbe. Volt néhány alapszintű (tehát admin privilégiumokkal nem rendelkező) accountja, amivel szabadon tudott mozogni a hálózaton. A további lépések ilyenkor a támadó részéről:

  • felmérni, milyen szenzitív (admin jogkörrel bíró) accountok vannak a hálózatban (ezt hívják Reconnaissance-nak)
  • megpróbálni hozzáférést szerezni a szenzitív accountokhoz (lateral movement)
  • végül átvenni az uralmat a rendszer felett, admin jogosultságokkal megbújni a rendszerben (domain dominance)

Mr. X tehát különböző felderítési technikákat alkalmazva (ldap lekérdezések, stb) eljut odáig, hogy van a hálózatban egy Terminal Server, amihez van működő accountja is, ráadásul a TS-en futó régi számlázóprogram miatt local admin jogosultsággal. Ide belépve felfedezi, hogy bizony a helyi IT hibázott és konfigurációs hiba miatt a víruskereső nem működik. Innentől felgyorsulnak az események:

Mivel admin joga van, rögtön látja, hogy még a domain adminok is ide lépnek be, sőt, van éppen bejelentkezett admin. Különféle programok segítségével (pl. Mimikatz) képes kinyerni a TS memóriájából a domain admin jelszóhash-t! Ne felejtsük el, a vírusirtó nem működik a gépen, tehát bármilyen malware jellegű programot lefuttathat.

A megszerzett hash-hel továbbhalad a központi SQL szerver felé, és a domain admint megszemélyesítve bejut az adatbázisszerverre. Ujjgyakorlatként még a domain controllerre is ellátogat, ahol kiállít magának a örök lejáratú kerberos ticketet, így bármelyik szerveren tud már mozogni. Itt a vége, csapda bezárult, a domain dominance megvalósult. Mr. X uralja a hálózatot, az SQL szerverről csendben készít adatbázis dumpokat és http segítségével tölti fel őket a saját rendszerébe. A történésekről nem tud senki, Mr. X hónapokig rejtőzhet a hálózatban (az átlagidő, a bejutásról a felfedezésig, 180 nap körül van, azaz a támadók gyakran fél évig is garázdálkodhatnak a rendszerben, mire felfedezik őket).

Lehetséges védekezés: az Azure ATP segítségével a fenti folyamatok egyenként detektálhatók (Reconnaissance-Lateral Movement-Domain Dominance), így az adminoknak azonnal van módjuk a támadást megakadályozni. A támadónak időre van szüksége, amíg a felderítést stb végrehajtja, ez sokszor több hét is lehet, így van idő a támadás kifejlődése előtt megállítani azt.

Az Azure ATP a domain controllerekre telepített szenzorok segítségével elemzik a hálózati forgalmat és azonnal riasztást küldenek különféle támadási észlelések esetén. Az alábbi táblázat mutat pár észlelési típust, de ez folyamatosan fejlődik, és felhős technológia révén, folyamatosan frissül is.

Kiegészítő védekezés: többszintű jogosultsági rendszer kialakítása. Külön accountok admin feladatokra, “sima” usernek sose legyen admin szerepköre. Admin accountokkal csak védett gépekre lehessen bejelentkezni, többfaktoros hitelesítéssel (pl. security key vagy virtual smart card)

Mint a fenti forgatókönyv is mutatja, a támadás könnyen megvalósítható, a fenyegetés nagy. A cikkben leírt védelmi megoldások viszont nagyrészt megtalálhatóak az O365/M365 előfizetésekben, csak elő kell őket venni a polcról és beüzemelni. Egy ilyen kiépített rendszerrel, a támadás kb az első lépésnél (phishing mailek megérkezése) elhalt volna.