November 10-én 17 órától online meetup:
https://www.meetup.com/m365-security-compliance-group/events/281519248
Hogyan működik a WHfB, milyen előnyökkel jár, és hogyan használható Azure AD / on-premise AD közötti integrációra is.
Várunk minden érdeklődőt!
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.
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:
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:
Ö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”
M365 Enterprise csomagok összehasonlító táblázat (PDF)
M365 SMB csomagok összehasonlító táblázat (PDF)
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:
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.
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:
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.
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:
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.
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
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:
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:
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:
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:
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.
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ó:
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?
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)
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.
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.
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ó:
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.
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:
A lenti táblázat részletezi az egyes elérhető komponenseket
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.
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.
Zoltan Istvanffy's IT Blog 