Seamless SSO – AZUREADSSOACC

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

Administrative units (AU) – Azure AD

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

Defender ATP 1: Attack Surface Reduction

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.

Régen sok kritikát kapott a Windows-os “ingyenes” kliens/server védelmi szolgáltatás és adott teszteken nem igazán jó eredményeket ért el. De mi a helyzet most? Nézzünk egy sokak által elismert/ismert AVtest-et.

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:

Nem túl szép 😦

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

Azure AD Connect és társai…

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

Végre! Primary user!

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
No alt text provided for this image

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

Új policy groups – Preview

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.

No alt text provided for this image

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

No alt text provided for this image

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

Preview Groups Experience

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.

No alt text provided for this image

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… 😦

No alt text provided for this image

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

No alt text provided for this image

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

No alt text provided for this image

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

Felhő legyen veletek…

Üdv.: NLB

Azure Multi-Factor Authentication

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.

No alt text provided for this image

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ó
No alt text provided for this image

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

No alt text provided for this image

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

Biztonságosabb levelezés

Az Office 365 sok hasznos funkciója közül szeretnék bemutatni egyet. Amennyiben szeretnénk a levelünket “titkosítani”, akkor mi sem egyszerűbb ennél. Egy előfeltétele van, hogy a “Azure Rights Management” aktiválva legyen a tenantunkban.

Az outlook-ban az új levélírás ablakban válasszuk ki a “options” menüpontot, majd a megjelenő lehetőségek között találunk egy “Encrypt” gombot.

No alt text provided for this image

A megjelenő menüpontban az “Encrypt-Only”-ra kattintva a levelünk titkosítva lesz. A levél elküldése után a következők történhetnek:

  • Amennyiben a címzett fiókja Office365-ben található és minimum outlook 2013 verziót használ, akkor a titkosított emailt meg fogja tudni nyitni a levelező klienssébe.
No alt text provided for this image
  • Amennyiben a címzett más email klienst vagy levelező szolgáltatást használ, mint pl. gmail, akkor a következő fog történni:

Megírjuk a titkosított levelet, majd elküldjük például egy gmail-es címre.

No alt text provided for this image

A fogadóhoz érkezni fog egy hasonló email, mint ami a lenti képen látható.

No alt text provided for this image

 A “Read the message”-re kattintva megnyílik egy oldal, ahol onetime password-ot tudunk igényelni vagy gmail esetében authentikálni tudjuk magunkat a gmail-es accountunkkal az üzenet hozzáféréshez. A onetime jelszó kiküldésre kerül az email címünkre és 15 percig lesz érvényes. Ezután a jelszóval be tudunk lépni az oldalra és megismerhetjük az email tartalmát.

No alt text provided for this image

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

Üdv.: NLB