A Microsoft Intune MDM megoldása már régóta a piacon van, lefedve a Windows, Android, macOS, Linux és iOS platformok menedzselését. A Microsoft azóta több szolgáltatást is fejlesztett és ezeket különböző csomagokba építette, igényekre reflektálva (Távoli segítség, firmware frissítést stb.)
Az alábbi táblázat mutatja az Intune Suite funkcióit, a licenszelésre később kitérünk:
Nézzük meg egyenként a funkciókat, röviden áttekintve:
Endpoint Privilege Management: Az EPM segítségével a standard jogosultságú felhasználók végrehajthatnak különböző feladatatokat, amik admin jogosultságot igényelnek (pl. alkalmazástelepítés, driver install, stb). Az IT-adminok különböző policykat küldhetnek a gépekre, ahol a felhasználó használhatja a “Run with elevated access” opciót és indoklás megadávásal elvégezheti a feladatot.
Enterprise App Management: egy előregyártott Win32 alkalmazásgyűjtemény, ami tartalmaz Microsoft és 3rd party alkalmazásokat (pl. Foxit PDF Reader, Dell Command Update stb). Az alkalmazásokat előre paraméterezték (detection rule, install-uninstall script) igy azonnal használatba vehetőek. Az itt található alkalmazások automatikus frissitik magukat, a kliensgépen is.
Advanced Analyitcs: az AA segítségével proaktívan felderíthetők és megoldhatók a kliensgépeken található problémák (alkalmazás összeomlások, legfagyások, váratlan gépújraindulások stb) vagy akár a laptopok akkumulátor-problémái is azonosíthatók.
Remote Help: biztonságos helpdesk kapcsolat Windows/Android/macOS eszközök felé. Ennek segítségével a helpdesk tud kapcsolódni az adott eszközre és láthatja a képernyőjét, átveheti az irányítást is. A biztonságot a role-based access adja, szigorúan meghatározott szerepkörökkel. Ez különösen hasznos funkció, ha külső hálózatban lévő gépet kell távolról supportálni.
Microsoft Tunnel for Mobile Application Management: amennyiben használunk Microsoft Tunnel VPN Gateway-t, a Tunnel for MAM szolgáltatással ki tudjuk terjeszteni az elérést a nem-enrollolt, nem menedzselt eszközökre is. A felhasználó a nem menedzselt eszközével is el tud érni belső hálózaton található erőforrásokat, SSO-val, modern hitelesítéssel, Conditional Access szabályokkal. Ez Android és iOS platformokra vehető igénybe.
Firmware-over-the-air-update: bizonyos támogattott eszközök automatikus firmware frissítését teszi lehetővé, pl. Zebra vagy Samsung Knox eszközök.
Specialized device management: AR/VR headsetek (RealWear, HTC eszközök), Microsoft Teams Rooms, Microsoft HoloLens eszközök menedzselését teszi lehetővé.
Licenszelés:
Alapvetően szükséges a Microsoft Intune licensz megléte. Ez lehet Business Premium vagy E3/E5 licensz, esetleg standalone Intune előfizetés. Erre lehet fűzni az Intune Plan 2-t ( Tunnel for MAM és specialty device management képességek) vagy az Intune Suite-ot, ami minden funkciót tartalmaz. Fontos azonban hangsúlyozni: az Intune Suite-hoz szükség van az alap Intune licenszre!
Leggyakoribb igény esetleg a Remote Help lehet, ezt add-on formájában meg lehet vásárolni az alap Intune licenszhez, 3,5 USD/hó/felhasználó áron.
A többi elérhető szolgáltatást igénybevételét is lehet mérlegelni, igénybe venni.
A Defender for Identity (MDI) szolgáltatásban többféle account típust definiálhatunk a Directory Services komponensben:
Használhatunk:
Standard AD account: pl. contoso\mdidirservice. Előnye hogy könnyen és gyorsan beállítható, hátránya hogy a jelszavát időszakosan cserélni illik és tárolni kell.
Group managed service account: ez a javasolt megoldás. Előnye, hogy a jelszót nem kell generálni/cserélni/tárolni, automatikusan frissül pl 30 naponta, több szolgáltatás is tudja egyidejűleg használni az accountot. Hátránya, hogy több előkészítést igényel.
Local service account: külön accountok létrehozása nélkül tudjuk az MDI sensorokat telepiteni. Hátránya hogy bizonyos MDI szolgáltatásokat nem támogat.
Ahogy említettük, a gMSA account használata javasolt. Nézzük, hogyan lehet létrehozni és az MDI szolgáltatáshoz rendelni.
gMSA előkövetelmények:
Windows Server 2012 vagy magasabb forest level
Windows Server 2012 vagy újabb operációs rendszerek
64-bites PowerShell a gMSA adminisztrálásához
gMSA konfiguráció:
Első körben létre kell hozni egy KDS root key-t. Lépjünk be egy domain controllerre (domain admin vagy enterprise admin jogosultság szükséges) és futtasuk le admin powershellben a következő parancsot:
Add-KdsRootKey –EffectiveImmediately
A létrehozás után várjunk legalább 10 órát (ez az idő, ameddig a beállítás replikálódik a domain controllerekre. Ha előbb próbáljuk létrehozni a gMSA accountokat, hibára fut.)
A létrehozást ellenőrizni tudjuk a következő paranccsal:
Get-KDSRootKey
Következő lépésként hozzunk létre az AD-ben egy security group-ot, aminek tagjai a domain controllerek:
Ezek után létrehozhatjuk a gMSA accountot. A parancsnál különösen fontos hogy a “PrincipalsAllowedToRetrieveManagedPassword” kapcsoló után a fenti security groupot jelöljük meg:
New-ADServiceAccount -Name mdisvc01 -DNSHostName mdisvc01.contoso.local –Description "Microsoft Defender for Identity service account" –KerberosEncryptionType AES256 –ManagedPasswordIntervalInDays 30 -PrincipalsAllowedToRetrieveManagedPassword MDISensorGroup
Az account megjelenik a Managed Service Accounts tárolóban:
Következő lépésként futtasuk le az alábbi parancsot admin powershellben minden domain controlleren:
Install-ADServiceAccount -Identity mdisvc01
Amennyiben access denied hibaüzenet kapunk, indítsuk újra a domain controllert és adjuk ki újra a parancsot.
Az accountot le tudjuk tesztelni:
Test-ADServiceAccount -Identity mdisvc01
Végül az accountot hozzárendelhetjük a Defender for Identity szolgáltatáshoz. Navigáljunk el a https://security.microsoft.com portálon a Settings/Identities/Directory Services accountra és adjuk meg a gMSA adatait:
Ezzel a gMSA account konfigurálásra került.
Az account működését ellenőrizni tudjuk a Health Issues opciónál. Amennyiben valamit rosszul állítottunk be, az alábbi hibát jelzi a portál:
Ebben az esetben ellenőrizzük újra a beállításokat illetve ha a domain controllerekre vonatkozó GPO-ban definiálva van a Log on a a service jogosultság, akkor a gMSA accountot is hozzá kell adni.
Entra Connect Sync (régi nevén AD Connect) esetén a javasolt konfiguráció egy aktiv Connect Sync és egy másik kiszolgálón futtatni egy staging példányt. A staging nem végez exportálást az Entra ID-be (Azure AD-ba).
Az alábbi powershelles lekérdezéssel megtudhatjuk, hogy az adott instance active vagy staging módban van.
$aadSyncSettings=Get-ADSyncGlobalSettings
($aadSyncSettings.parameters | ?{$_.name -eq "Microsoft.Synchronize.StagingMode"}).value
# output "False" means Staging mode is disabled
# output "True" means Staging mode is enabled
Ez könnyebbé teszi a meghatározást, mint a grafikus felületi ellenőrzés
Microsoft Intune Certificate Connector telepítése közben szükséges belépni az Azure AD-ba. Ilyenkor viszont belefuthatunk egy hibaüzenetbe:
“Something went wrong An unanticipated error occurred. Your IT department may be able to help.”
A sikeres konfigurációhoz az alábbi feltételek szükségesek:
Global Administrator vagy Intune Service Administrator szerepkör ÉS Intune license hozzárendelve (ez elég ideiglenesen, a konfiguráció időtartamára) az accounthoz.
Az accountnak szinkronizálva kell lennie az Azure AD-val.
Ami ebből érdekes, az a 403 16. Ennek jelentése: “A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.”
Továbbkeresgélve, ez egy certificate store validation hiba, amikor is a gépen a Trusted Root Certification Authorities tárolóban nem csak önaláírt (self-signed) tanúsítványok vannak. Márpedig oda csak olyannak illik kerülnie, aminél az Issuer és Subject Name megegyezik.
Powershellből le tudjuk kérni a nem oldavaló tanúsítványokat:
A Microsoft Defender for Identitiy (MDI) integrálható egy meglévő VPN szolgáltatással, azaz a VPN el tudja küldeni a RADIUS accounting logokat az MDI szenzornak (IP cím, ország stb). Ezzel információkat tudunk gyűjteni, honnan próbálják a VPN kapcsolatot felépíteni, van-e anomália. Gyanús esemény lehet ha hirtelen más országokból próbálnak VPN-en csatlakozni.
Jelen pillanatban az alábbi gyártók VPN megoldásai támogatottak a standad RADIUS accountinggal:
Microsoft
F5
Check Point
Cisco ASA
Nézzük meg, hogy a Microsoft RRAS esetén mik a beállítási lépések:
Nyissuk meg az RRAS konzolt, a Security fülön tudjuk konfigurálni a RADIUS accountingot
Itt megadhatjuk az egyik MDI szenzor nevét/IP-jét.
Utána pedig az MDI portálon beállítjuk a Shared Secretet
Eddig rendben; de mi van olyakor, ha Network Policy Servert használunk, ugyanazon a VPN szerveren? Ebben az esetben nincs ott a RADIUS accounting az RRAS konzolban.
Hogy tudjuk igy eljuttatni a RADIUS accounting logokat az MDI szenzorhoz?
Az NPS konzolban definiáljunk új Remote RADIUS Server Groupot, megadva az MDI szenzorok nevét/IP-jét:
Állítsuk be a Shared Secret értékeket:
Végül pedig a VPN connnection request policyben definiáljuk, hogy a RADIUS accounting melyik távoli szerveren történjen meg (ez esetben az MDI szenzorok)
Utána természetesen ne felejtsük el az MDI portálon is megtenni a szükséges beállításokat.
Abban az esetben viszont, ha ezek a függőségek nem kötik meg a kezet, érdemes a Cloud Syncet választani. Ilyenkor lehetőség van több aktiv agentet telepíteni, ami rugalmasabb az AD Connect active/staging modelljénél.
A legtöbb funkcionalitást az AD Connect adja, az egyszerűbb üzemeltetést pedig a Cloud Sync. A szervezet igényeinek alapos felmérése után érdemes a kettő közül választani.
Mikor ügyfelekkel beszélgetek információvédelem, Azure Information Protection (új nevén Microsoft Purview) témakörről, szinte mindig előjön a földi fileshare-ek kérdése: lehet-e az onprem rendszereken tárolt adatokat kategorizálni és esetleg automatikusan labellel ellátni?
A jó hír, hogy lehet. A rosszabbik, hogy minden felhasználónak E5-ös licensz kell hozzá (ez igy nem teljesen igaz, nemsoká kifejtem), ez sokszor az ügyfelek kedvét szegi, tehát érdemes tisztázni ennek a technikai és licenszelési hátterét.
Tehát, mi kell hozzá hogy egy földi fileshare-en tárolt dokumentumokat automatikusan kategorizálni és labelezni lehessen?
Microsoft Purview scanner bekonfigurálva
Megfelelő licensz
Amikor a scanner labelez egy dokumentumot, a file tulajdonosának rendelkeznie kell Azure Information Protection P2 licensszel. Ha valaki a fileshareben létrehoz egy új dokumentumot, amire alkalmazódik a label, akkor is kell az AIP P2 licensz. Mivel gyakorlatilag mindenki hozhat létre dokumentumokat, amiket ilyen vagy olyan okokból automatikusal labelezni kell, nagyjából mondhatjuk hogy szinte az összes felhasználót licenszelni kell AIP P2-re.
Ezt persze lehet szofisztikálni, előzetes felméréssel, hány owner lehet a meglévő fileokon illetve hogy kik használják a fileshare-t és rájuk szűkíteni a licenszelést.
Licenszelési oldalról sokszor elhangzik a fent emlitett “E5 kell hozzá”. Szerencsére nem feltétlenül. Az automatikus labelezéshez szükséges AIP P2-t az alábbi módokon is beszerezhetjük:
Azure Information Protection P2 mint standalone előfiezetés, kb 5 euró/hó/fő
M365 E5 Information Protection & Governance addonként (meglévő E3-as liceszek mellé vehető) kb. 7 euró/hó/fő
Zoltan Istvanffy's IT Blog 