A hibrid vállalati környezetekben a jelszómentes hitelesítés már nem csak kényelmi funkció, hanem biztonsági és üzemeltetési elvárás. A Windows Hello for Business fejlődésével megjelent a Cloud Kerberos Trust, amely egyszerűbbé, gyorsabbá és PKI-mentessé teszi a hibrid hitelesítési folyamatot. Ez a modell a korábbi Key Trust és Certificate Trust megközelítéseket váltja fel egy modernebb, kevesebb infrastruktúrát igénylő megoldással.

Mi az a Key Trust?

A Key Trust modell a Windows Hello for Business egyik alapvető hitelesítési módszere, ahol a felhasználó által generált kulcspár (private/public key) kerül regisztrálásra Entra ID-ban, és ezt használja a rendszer a hitelesítés során. Hibrid környezetben azonban a Key Trust több korlátozással jár: szükséges hozzá Entra ID Connect writeback, és a domain controllereknek támogatniuk kell a hitelesítési lekérdezéseket. Emiatt hibrid környezetekben ma már kevésbé preferált.

Mi az a Certificate Trust?

A Certificate Trust a Windows Hello for Business klasszikus, tanúsítvány alapú hibrid modellje, amelyhez teljes PKI infrastruktúra szükséges (CA, CRL, NDES, SCEP). A felhasználó WHfB kulcsára tanúsítvány kerül kiállításra, amelyet az Active Directory fogad el hitelesítéskor. Stabil és bevált megoldás, de komplex, sok szereplős és jelentős üzemeltetési terhet jelent.

Mi az a Cloud Kerberos Trust?

A Cloud Kerberos Trust az Entra ID és az Active Directory közötti modern, felhőalapú hitelesítési modell, amely lehetővé teszi, hogy a felhasználók jelszó nélkül (pl. Windows Hello for Business) jelentkezzenek be hibrid környezetekbe tanúsítványok nélkül, teljesen háttérrendszerbeli PKI és tanúsítványkiadás nélkül. A modell lényege, hogy a felhőben lévő Entra ID ad ki egy “evidence ticketet”, amelyet az AD elfogad, így a klasszikus Kerberos TGT megszerzése PKI nélkül történik.

Miért fontos?

• Jelentősen csökkenti az infrastruktúra komplexitását (nincs szükség NDES-re, tanúsítványelosztásra, WHfB tanúsítványokra).
• Gyorsabb és egyszerűbb bevezetés, mint a Certificate Trust.
• Modern, jelszómentes hitelesítést tesz lehetővé hibrid AD környezetben.

Funkció / Modell	Key Trust	Certificate Trust	Cloud Kerberos Trust
Szükséges PKI infrastruktúra	Nem	Igen (CA, CRL, NDES/SCEP)	Nem
Szükséges Entra ID Connect writeback	Igen	Nem	Nem
WHfB kulcs típusa	Kulcspár Entra ID-ban	Tanúsítvány a WHfB kulcsra	Felhőben kiadott Kerberos “evidence ticket”
On-prem AD hitelesítés	Igen	Igen	Igen
DC követelmények	2016+	2016+	2016+ + KB-k
Bevezetés komplexitása	Alacsony–közepes	Magas	Alacsony
Jelszómentes támogatás	Részleges	Teljes	Teljes, PKI nélkül
Ideális felhasználási eset	Egyszerűbb hibrid környezetek	PKI-val rendelkező vállalatok	Modern, egyszerű hibrid hitelesítés tanúsítványok nélkül

Követelmények és környezet

Az előfeltételek részletes listája elérhető a Microsoft hivatalos dokumentációjában:

https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune

A Cloud Kerberos Trust bevezetése három fő lépésből áll:

1. Microsoft Entra Kerberos telepítése
2. Windows Hello for Business házirend beállításainak konfigurálása
3. Windows Hello for Business inicializálása

Az alap hibrid környezet már elő van készítve, ezért a Cloud Kerberos Trust főbb beállításait ezen a kész infrastruktúrán keresztül mutatom be.

A hibrid infrastruktúra főbb elemei:

• Domain Controller: vm-dc-01
• Entra Connect Sync szerver: vm-ECS-01
• Intune (Microsoft Endpoint Manager) – konfigurációk és Cloud Kerberos Trust beállítások kiküldése
• Kliens gép: NLBWin11
• Licencelés: Microsoft Intune P1, Entra ID P2
• Domain információk: On-premises domain: labor.com, Entra ID domain: nlb.hu Közös domain: nlb.hu

A dsregcmd /status alapján a kliens jelenleg kizárólag Entra ID-hoz csatlakozik, és nincs on-premises tartományba beléptetve.

1. Microsoft Entra Kerberos telepítése

Microsoft Entra Kerberos és Cloud Kerberos Trust hitelesítés

https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azureadhybridauthenticationmanagement-module

Amikor a Microsoft Entra Kerberos engedélyezve van egy Active Directory tartományban, a rendszer létrehoz egy AzureADKerberos nevű számítógépobjektumot. Ez az objektum:

• látszólag egy Read-Only Domain Controller (RODC) objektumként jelenik meg, de nincs hozzárendelve semmilyen fizikai szerverhez;
• kizárólag azt a célt szolgálja, hogy a Microsoft Entra ID Kerberos TGT-ket generáljon az adott Active Directory tartomány számára.

Ehhez először telepíteni kell az AzureADHybridAuthenticationManagement modult.

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Ezután négy különböző opció áll rendelkezésre arra, hogyan futtathatjuk a scriptet.

1. Example 1 – Prompt for all credentials

Ebben a módban a rendszer minden hitelesítési adatot bekér a felhasználótól:

• on-premises AD hitelesítés
• Entra ID / felhőalapú hitelesítés

Ez akkor hasznos, ha nincs egyértelműen meghatározva, melyik hitelesítési forrás legyen az elsődleges, vagy ha a gép hibrid környezetben működik.

2. Example 2 – Prompt for cloud credential

Ebben az esetben a rendszer kizárólag a felhőbeli (Entra ID) hitelesítési adatokat kéri be.
On-premises AD-t nem használ a hitelesítéshez.

Ez tipikusan Entra ID-joined vagy cloud-first eszközöknél jellemző.

3. Example 3 – Prompt for all credentials using modern authentication

Ez ugyanaz, mint az első példa, de modern auth (OAuth 2.0 / WS-Trust helyett MSAL alapú hitelesítés) segítségével történik.
A rendszer így:

• támogatja a többfaktoros hitelesítést
• támogatja az Entra ID feltételes hozzáférést
• korszerűbb login élményt ad

Mind a felhős, mind az on-prem hitelesítési adatok bekérése megtörténik.

4. Example 4 – Prompt for cloud credentials using modern authentication

Itt csak a felhős hitelesítési adatokat kéri a rendszer, modern authentication módon.

Ez a legbiztonságosabb és legelterjedtebb módszer:

• MFA-t támogat
• Entra ID feltételes hozzáférést támogat
• nincs szükség on-prem AD credential-re

Cloud-first környezetekben ez a preferált modell.

A scriptek itt érhetők el:

Passwordless security key sign-in to on-premises resources – Microsoft Entra ID | Microsoft Learn

Én a harmadikat választottam:

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Enter a Domain Administrator username and password.
$domainCred = Get-Credential

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Ezzel létrejött a Microsoft Entra Kerberos kiszolgáló. Ellenőrizzük is le:

# When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)

Az eredmény:

2. Windows Hello for Business házirend beállításainak konfigurálása

A Windows Hello for Business házirendek konfigurálását Intune-ban végeztem, ahol létrehoztam egy külön Configuration profile-t, és ezen belül három részt állítottam be a szükséges WHfB funkciók engedélyezéséhez. Ezután érvényesítettem a beállításokat a kliensre.

3. Windows Hello for Business inicializálása

Ezután újraindítottam a klienst, és megjelent Windows Hello beállítófelület, ahol elvégeztem a konfigurálást.

Tesztelés

A kliens gépről megpróbáltam elérni egy megosztást a Domain Controlleren. Az elérés sikerült anélkül, hogy hitelesítő adatokat kért volna.

De nézzük meg, hogy valóban Kerberos-szal történt-e a hitelesítés, és nem fallback NTLM volt. Futtassuk a klist parancsot.

Ezzel elértük, hogy a kizárólag Entra ID-hoz csatlakoztatott kliens elérje az on-premises erőforrást anélkül, hogy meg kellene adnia a hitelesítő adatokat, és mindehhez nincs szükség robusztus, összetett infrastruktúrára.

Végszó

Gondolom sokan láttátok már olyan videót, ahol az autószerelő azt mutatja, hogy az akkumulátor csatlakozót leveszi az akksiról, és rajta van még a védőkupak. Majd a következő kép, hogy az egész autó belseje szét van bontva, mert kereste az elektronikai hibát. Na, valami ilyesmi történt velem is a labor során. Nem akart működni, folyamatosan fallback NTLM volt. Mint írtam, egy meglévő laborkörnyezetet használtam, és hát persze, hogy nem akart működni, mert a kliensnek nem a DC volt beállítva DNS-nek. Viszont ez arra pont jó volt, hogy minden troubleshootinghoz szükséges logútvonalat és toolt megismerjek.

Event Viewer, log útvonal:

Microsoft-Windows-User Device Registration/Admin

Microsoft-Windows-HelloForBusiness/Operational

Parancsok:

dsregcmd /status

AzureAdPrt: PRT = Primary Refresh Token.

AzureAdPrt : YES – felhasználó Entra ID-ba sikeresen hitelesített, és a gépen van érvényes PRT.

Ez kell ahhoz, hogy SSO működjön felhős appok felé (M365, Azure, stb.), és hogy a Cloud Kerberos Trust el tudjon indulni.

OnPremTgt: On-premises Kerberos TGT

OnPremTgt : YES – van klasszikus Kerberos TGT-d az on-prem AD-hez

Ez azt mutatja, hogy a kliens Kerberos-szal tud az on-prem erőforrásokhoz menni.

CloudTgt: Cloud Kerberos TGT / Cloud KDC TGT

CloudTgt : YES – a kliens a felhőből (Entra ID / Cloud KDC) kapott Kerberos ticketet, nem a hagyományos jelszavas AD bejelentkezésből.

Ez konkrétan a Cloud Kerberos Trust működésének bizonyítéka.

NgcSet = Next Generation Credentials, State/Status

NGCSET = YES – a Windows Hello for Business be van állítva és használható.

certutil -deletehellocontainer

Mi az a „Hello Container”?

A Windows Hello for Business a felhasználó számára létrehoz egy kulcstárolót, amely tartalmazza:

• a WHfB privát kulcsot
• a hozzá tartozó publikus kulcs regisztrációs metaadatait
• Cloud Kerberos Trust esetén az NGC kulcsot
• TPM-bound credential információt

Törli a felhasználó Hello konténerét, vagyis:

• WHfB PIN/biometrikus kulcsokat
• Hello for Business kulcspárokat
• Cloud Kerberos Trust-hoz használt kulcsot
• TPM-bound WHfB credentialt

Preview módban elérhető egy újdonság a Defender for cloud-on belül. Ez a Agentless scanning for machines. Két előfizetési típusban érhető el, a Defender Cloud Security Posture Management (CSPM) vagy a Microsoft Defender for Servers Plan 2-ben. A lényege, hogy agent nélkül információt kapunk a virtuális géppel kapcsolatban, hogy milyen ismert sebezhetőségek (Vulnerability assessment) vannak jelen és milyen szoftverek vannak telepítve (software inventory).

De mindezt, hogy tudja véghez vinni? Úgy, hogy pillanatképet készít a virtuális gép merevlemezéről és egy izolált környezetben szkenneli azt.

A portálon pedig láthatóak lesznek az eredmények, konszolidálva az esetlegesen telepített ügynök eredményeivel.

Már jöhetnek is a biztonsági aggodalmak….és a válaszok rá. Nem, nem tárolja a Microsoft a szkennelés után ezeket a pillanatképeket, azonnal törlésre kerülnek. Csak a szkennelés ideje alatt kerül megtartásra régiónként és biztonságos, izolált módon.

Milyen “lábnyomot” hagy ez a tenantunkban az előfizetésen? “VM Scanner Operator” jogosultsága lesz a “Microsoft Defender for Cloud Servers Scanner Resource Provider”-nek az előfizetésen.

További információ:

• 24 óránként szkennel
• Támogatott operációs rendszer: Windows, Linux
• A megoldás nem gyűjt nyers adatokat, személyes információkat és érzékeny üzleti adatokat (Ahogy az ügynök alapú sem)

Üdv.:
NLB

Egyszer volt, hol nem volt, telepítésre került az Azure AD connect és a sok kijelölhető opció közül bepipálásra került az “Enable single sign-on” lehetőség, mert ezzel tuti jó lesz a felhasználói élmény 🙂

Aztán böngésszük az on-premise AD-t (Private cloud AD – csak, hogy maradjunk a hivatalos megnevezéseknél) és találunk egy computer accountot, ami valahogy, valamikor létrejött, aminek a neve “AZUREADSSOACC”. Bizonyám ez összefügg azzal az opcióval amit kipipáltunk. De ez miért jött létre? Mire kell? Hogyan működik? Na ezt nézzük meg.

Az nem kérdés, hogy szeretnénk növelni a felhasználói élményt úgy, hogy a biztonság ne sérüljön, tehát a felhasználó által a private cloud-ban megszokott szolgáltatások elérése, ugyanúgy működjön a felhőben is, tehát ne kelljen újból és újból megadni a felhasználói-jelszó párost. Igen, a kerberosról beszélek.

Bizony, ezért jött létre ez a computer account, ami nem más mint az Azure AD “megszemélyesítése”. De hogyan működik? Vizsgáljuk meg.

1. Felhasználó be szeretne jelentkezni egy felhős web app-ba.
2. Az App átírányítja az Azure AD-hoz.
3. Az adott App nem továbbít semmilyen domain vagy tenant információt, ezért meg kell adni a felhasználónak a felhasználó nevét.
4. A webbrowser 401-es hibát ad, mert nincs érvényes kerberos ticket.
5. A felhasználó böngészője kerberos jegyet igényel a “AZUREADSSOACC” objektumhoz. Igen és itt nyer értelmet ez az objektum, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget és ez az objektum képviseli az Azure AD-t.
6. Kapunk egy kerberos ticketet a “AZUREADSSOACC” objektumhoz, ami titkosítva lesz a “számítógép” kulcsával.
7. A felhasználó böngészője elküldi a titkosított kerberos ticketet.
8. Azure visszafejti a titkosított kerberos ticketet, azzal a kulcssal, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget.
9. Amennyiben érvényes a jegy, akkor a böngésző visszakap egy tokent, amivel hozzáférhet az erőforráshoz.
10. Ezáltal a felhasználó sikeresen bejelentkezett a wep app-ba, anélkül, hogy megadta volna a jelszavát.

Remélem hasznos volt! 🙂

Üdv.:
NLB

Egy ideje elérhető egy új funkció az Azure AD-ban, ami “Administrative units” névre hallgat. Igaz még “csak” preview fázisban. Az Azure portálon az Azure AD-n belül itt található:

De mire jó ez? Egyszerű. Logikai egységeket tudunk létrehozni, amelyekben jelenleg még “csak” felhasználókat és csoportokat tudunk definiálni, a vállalatunk felépítése alapján, például földrajzi szempontból. Az “+Add” gombra kattintva tudjuk az egységeket létrehozni egy név megadásával, valamint egy leírást is hozzá tudunk adni.

Miután létrehoztuk és megnyitjuk az AU-t, akkor az alábbi lehetőségek közül választhatunk.

A Manage rész alatt a következő lehetőségek jelennek meg:

• Properties (Alap tulajdonságokat tudunk módosítani, mint például a “Displayname”)

• Users (Hozzá tudjuk adni azon felhasználókat, akik a szervezeti egységekhez tartoznak)

• Groups (Hozzá tudjuk adni azon csoportokat, akik a szervezeti egységekhez tartoznak)

• Roles and administrators
  Na elérkeztünk a lényeghez. Különböző adminisztratív jogosultságokat tudunk adni az adott AU-hoz. Jelenleg ezek a szerepkörök állnak rendelkezésre.

Nyissuk meg az egyik szerepkört, például a “User administrator”-t. Ezután a “+Add assignments” lehetőségre kattintva hozzá tudjuk adni azon adminisztrátorokat, akiknek ilyen jogot szeretnénk adni erre az AU-ra.

Héééé, na de várjuk csak. Ezek ugyanazok a role-ok, amik directory szinten is megtalálhatóak! Hogyha itt valakit hozzáadok, akkor az egész directory-n ilyen joga lesz!? Neeem! Miért nem? Ezért:

Bizonyám a scope kizárólag erre az AU erőforrásra szól. Sőt! Nézzük meg, hogy ez hogy látszik az Azure AD\Roles and administrators oldalról.

Megnyitom a “User administrator” szerepkört. Bizonyám itt is szépen látszódik a hatókör. Sőt! innen vissza sem tudom vonni az adminisztrátortól a szerepkört!

Remélem hasznos volt!

üdv.:
NLB

Ez egy olyan post sorozat lesz, ahol bemutatom a Defender ATP központosított konfigurációs lehetőségeit az Microsoft Endpoint Manager admin centeren belül az Endpoint Security segítségével, valamint érinteni fogom az Azure Sentinelt, ahol részletesen nyomon követhetjük és elemezhetjük a különböző endpoint támadásokat, a KQL (Kusto Query Language) segítségével pedig összetett log lekérdezéseket tudunk létrehozni. Na vágjuk bele.

Nagyon sok támadási felület van, amiket valamely módon védenünk kell. Ezek közül az egyik a kliensek/szerverek. Erre a Microsoft-os megoldás a Defender ATP, ami egy felhős szolgáltatás a központosított kliens/szerver védelem felügyeletére. Adott Windowsokon beépítve találjuk a klineseket, más platformon külön kell telepítenünk (pl. Linux, macOS, Windows Servers)

Windows 10 (1909) esetében a beépített kliens védelmi szolgáltatásokat az alábbi képen láthatjuk.

https://www.av-test.org

Az AV test három fő szempont szerint osztályoz:
– Védelem
– Teljesítmény
– Használhatóság

Nézzünk egy 2015 februári tesztet:

2020 Áprilisi teszt:

Persze itt nem teljesen ugyanazt hasonlítjuk össze, mert 2015-ben még nem volt igazi nagyvállalati megoldása a Microsoft-nak végpontvédelemre, de azért így is szépen látszódik a fejlődés.

Csak összehasonlításképpen nézzük az AVAST és az AVG-t, akik nem most kezdték a védelmi megoldásainak fejlesztését és elég népszerűek, ők vajon mennyi pontszámot értek el? Lássuk:

Kimondhatjuk, hogy a Defender felnőtt a feladathoz 🙂

Na kanyarodjunk vissza az eredeti témához, hogyan tudjuk a Defendert központosítottan szabályozni? (A post sorozatban nem térek ki, hogy mely módokon tudjuk bekötni a klienseket a Defender ATP-be, erről itt található útmutatás:
https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/onboard-configure )

Elsőnek vizsgáljuk meg milyen lehetőségeket kínál a “Attack Surface Reduction”. Lépjünk be az Intune adott részének új felületére (https://endpoint.microsoft.com) és az “Endpoint Security-n” belül kattintsunk a “Attack surface reduction” lehetőségre.

Itt különböző szabályokat tudunk létrehozni. Hozzuk létre az első szabályunkat, kattintsunk a “Create Policy-re”, majd adjuk meg az alap adatokat.

Jelenleg még “csak” Windows 10 platform érhető el. A Profile-nál adjunk egy nevet és javasolt egy leírást hozzáadni.

A “Next” gombra kattintva megjelennek az elérhető szabályok, amiket konfigurálni tudunk.
Fontos! Nem minden szabálynál, de alapértelmezetten négy konfigurálási lehetőség érhető el:
– not configured (Mint a nevében is benne van, nincs konfigurálva, tehát nem szabályozzuk központilag)
– User defined (A felhasználó dönt az adott beállításról)
– Enable/block (Bekapcsolásra kerül az adott védelem vagy blokkolja a tevékenységet)
– Audit mode (Az adott tevékenység logolásra kerül)

Miket tudunk szabályozni. Nézzünk egy példát. Telepítve van az Office valamely csomagja és ugye tudjuk, hogy például egy word dokumentum megnyitásával elindulhatnak olyan folyamatok, amik kártékony kódot tartalmazhatnak. Ezt blokkolni szeretnénk és erre vannak különböző szabályok:

De mi van akkor, hogyha valóban vannak olyan “gyermek” folyamatok, amiket a cégünk fejlesztett az office-hoz és ezért ezt nem szeretnénk blokkolni? Ezért ajánlott, hogy elsőnek mindeképp az adott szabályokat audit módba állítsuk, hogy lássuk, hogy vállalaton belül ehhez kapcsolódóan milyen tevékenységek zajlanak anélkül, hogy blokkolnánk a vállalat elvárt működését.

A következő ablakon a scope-ot tudjuk beállítani, de ami fontosabb az az, hogy mely csoportokra legyen érvényes az adott policy. Itt tudunk egyedi csoportot megadni vagy a képen látható előre meghatározott csoportokat.

A végén pedig összesíti az általunk választott beállításokat.

A szabályok létrehozása és érvényesítése után értesítés keletkezik a központi felügyeleti rendszeren és a kliens oldalon.

Ezzel pedig létre hoztuk az első olyan szabályt, amivel módosítani tudjuk a defender kliens oldali működést.

Folytatás következik 🙂

üdv.:
NLB

Az évek során sokat fejlődött a Microsoft cloud és az on-premise összeköttetésére szolgáló eszköz, az Azure AD connect:

Ez szépen végig követhető az alábbi linken:

https://docs.microsoft.com/hu-hu/azure/active-directory/hybrid/reference-connect-version-history

De milyen opciók támogatottak? Például lehet két különböző tenanthoz összekötni az on-premise AD-t és ugyanazokat az objektumokat szinkronizálni a különböző tenantokba? Az ilyen eseteket vázolja fel az alábbi oldal

https://docs.microsoft.com/hu-hu/azure/active-directory/hybrid/plan-connect-topologies

Valmint mi van akkor, ha több AD forest-el rendelkezünk és Exchange hybridet szeretnénk kialakítani egy tenanttal? Akkor érdemes az alábbi oldalra ellátogatni:

https://docs.microsoft.com/en-us/exchange/hybrid-deployment/hybrid-with-multiple-forests

Amennyiben kicsit összetettebb kihívásba futunk bele, akkor érdemes egy FastTracket indítani a Microsoft-nál:

https://www.microsoft.com/en-us/fasttrack

Végcél a cloud 🙂

üdv.: NLB

Microsoft meghallotta a nép hangját 🙂 Viccet félre téve, nagyon sok szavazat és comment érkezett a Microsoft-hoz a témával kapcsolatban. Public Preview fázisban elérhető az a funkció, amivel meg tudjuk változtatni egy eszközhöz rendelt primary usert. Sőt nem csak meg tudjuk változtatni, hanem az alábbi műveletek is elvégezhetők:

• Primary user megváltoztatása A-ról B-re
• Primary user megváltoztatása megosztott állapotról egy adott userre
• Primary user megváltoztatása egy adott felhasználóról megosztott állapotra

Támogatott megoldások:

• Windows 10-es eszközök
• Azure AD vagy Hybrid Azure AD-hoz csatlakoztatott eszközök
• Co-management eszközöknél nem lehet megváltoztatni a primary user-t (https://docs.microsoft.com/hu-hu/configmgr/comanage/overview)
• Leendő primary user intune license-el kell rendelkeznie
• Primary user módosításához a Helpdesk Operator, School Administrator és az Endpoint Security Managernek is van joga.

Felhő legyen veletek…

Üdv.: NLB

Március 16.-ai hét elég sok újdonságot hozott az intune-nal kapcsolatban. Ezen belül is a Microsoft Endpoint Manager admin center-ben.

Számos új policy jelent meg. Nézzük meg ezeket profil típusok szerint.

Antivirus (Preview) :

• macOS: Menedzselni tudjuk a “Microsoft Defender ATP for Mac”-et.
• Windows 10 and later: policy beállítások a következőkhőz. cloud protection, Antivirus exclusions, remediation, scan option és még sok más…
• Windows Security Experience: felhasználói értesítések kezelése

Disk Encyption (Preview):

• macOS: FileVault
• Windows 10 and later: Bitlocker

Firewall (Preview):

• macOS: macOS firewall
• Windows 10 and later: Windows Defender Firewall

Endpoint detection and response (Preview):

• Windows 10 and later:

Sample sharing for all files: Minták gyűjtése és megosztása a Microsoft defender ATP-val

Expedite telemetry reporting frequency: gyakrabban küldi a telemetria adatokat a Microsoft defender ATP-nek

Attack surface reduction (Preview):

• Windows 10 and later: App and browser isolation, Web protection, Application control, Application control, Attack surface reduction rules, device control, exploit protection

Account protection (Preview):

• Windows 10 and later: Account protection

Üdv.:NLB

Amikor használjuk a keresőt a Intune/M365 device management portal/Azure AD-ban, hogy megtaláljunk egy csoportot, akkor az nem túl hatékony…

Például keresem a csoport nevében az “Auto” szót. Meg is találja azokat a csoportokat, amik “Auto”-val kezdődnek.

De mi van akkor, ha a keresett szó nem a csoport név kezdéseként szerepel? Sajnos nincs találat, pedig van ilyen csoport… 🙁

De itt az új hatékonyabb keresési megoldás. Kattintsunk a “Try out new groups experience…” lehetőségre

Újból beírom a “test” szót. Nézzük mi lesz az eredmény.

Azért ez így már mindjárt más 🙂

Felhő legyen veletek…

Üdv.: NLB

Ez egy gyors áttekintés lesz. Az nem kérdés, hogy az MFA kell! – ha esetleg még nem használjátok, akkor gyorsan vezessétek be 🙂 – Már csak az a kérdés milyen lehetőségeink vannak az MFA-val kapcsolatban az Azure-ban. Ezt fogom részletezni ebben a kis szösszenetben 🙂

Mielőtt bevezetnénk tekintsünk át néhány előfeltételt. Ez sokban függ attól, hogy mely forgatókönyv szerint használjuk az Azure szolgáltatásokat.

A bevezetést két fontos eseménynek kell megelőznie:

• A konfiguráció tesztelése
• Felhasználók megfelelő tájékoztatása!

Miután ezzel megvagyunk két fő konfigurációs lehetőség közül választhatunk:

• Központosított policy alapú MFA (Itt például szűrhetünk, hogy az adott felhasználó honnan jelentkezik be és ez alapján lesz érvényes az MFA. De itt más szűrési feltételek is elérhetőek.
• Felhasználókénti MFA konfiguráció

Fontos! A státusz azt jelzi, hogy a rendszergazda regisztrálta őket az MFA-ba és hogy elvégezték-e a regisztrációs folyamatot.

Az összes felhasználó alapesetben le van tiltva. Amikor a felhasználót regisztráljuk az MFA-ba, akkor az állapotuk engedélyezetté válik. Ezután ha a felhasználó bejelentkezik és elvégzi a regisztrációs folyamatot, akkor állapotuk kikényszerítetté válik.

Az MFA állapotot le tudjuk kérdezni Azure felületen és powershellből.

Azure felület:

Azure Active Directory > felhasználók és csoportok > minden felhasználólehetőséget > multi-Factor Authentication

Powershell:

Powershell alapú ellenőrzéshez javasolok egy scriptet, amit itt érthettek el:

https://gallery.technet.microsoft.com/office/Export-Office-365-Users-eed7a82c

Ezen beállításokat tudjuk módosítani powershellből vagy a webes felületen.

Fontos! Az MFA több lehetőséget biztosít az azonosításhoz:

• Értesítés jóváhagyása a mobiltelefonra telepített Microsoft Authenticator alkalmazásban. (Ez a lehetőség nem elérhető Android alapú mobiltelefonon Kínában élőknek és oda utazóknak)
• Ellenőrző kód használata a Microsoft Authenticator alkalmazásban
• Telefonhívás
• SMS üzenet a mobiltelefonra

A rendszergazdáknak további lehetőségeik vannak az MFA konfigurációhoz. Például meg tudják adni, hogy meddig legyen megbízható az a készülék amiről a MFA-t elvégezték vagy szabályozhatjuk, hogy mely azonosítási lehetőség érhető el a felhasználó számára.

Fontos! Amennyiben a felhasználó kikényszerítve állapotba kerül, akkor szükséges lesz alkalmazás jelszó beállítására, amennyiben az adott alkalmazás nem támogatja a modern hitelesítést (pl.: POP, IMAP protokollt használó alkalmazás). Továbbá minden bejelentkezésnél szükség lesz az MFA-ra, tehát nem lesz token lejárat.

….folytatás következik…addig is a biztonság és a felhő legyen veletek:)

Üdv.: NLB