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)

Seamless SSO – cseréljük a Kerberos kulcsot

Az Azure portálon, az AD Connect résznél szemünkbe tűnhet egy sárga háromszöges figyelmeztetés:

Pánikra nincs ok, a napi működésre nincs kihatással 🙂

De mit jelent mindez?

Áttekintés

A Seamless SSO-t beállíthatjuk, ha password hash sync vagy pass-through authentikációt határoztunk meg (a két hitelesítési mód összehasonlítása: Password hash sync vagy pass-through authentication – összehasonlítás | Zoltan Istvanffy’s IT Blog (istvanffyzoltan.com) )

A Seamless SSO segíti a felhasználói élményt, hogy domain-joined gépeken automatikusan bejelentkeznek az Azure AD-ba.

Amikor az AD Connect segítségével konfiguráljuk az SSO-t, a földi domainben létrejön egy AZUREADSSOACC computer objektum. Ez felelős érte, hogy megvalósuljon az SSO az Azure AD-val. A működésének rövid leírása:

  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.

(forrás: https://nlbit.blog/2020/08/07/seamless-sso-azureadssoacc/ )

Ez az objektumot érdemes egy külön OU-ba tenni és bekapcsolni rajta a “protect object from accidental deletion” opciót is.

A Kerberos-kulcs (decryption key) a lényeges, ezt érdemes legalább 30 napota cserélni. Ha nem tesszük, akkor kerül ki az Azure portálra a figyelmeztető ikon.

Hogyan cseréljük a Kerberos-kulcsot?

A művelethez szükségünk van Global Administrator és Domain Admin jogosultságra. Lépjünk be az AD Connect szerverre és admin powershellben navigáljunk el a “Microsoft Azure Active Directory Connect” mappába:

cd “C:\Program Files\Microsoft Azure Active Directory Connect\”

Importáljuk be az SSO modult:

Import-Module .\AzureADSSO.psd1

A következő paranccsal végrehajtjuk a hitelesítést az Azure AD felé:

New-AzureADSSOAuthenticationContext

Futtassuk le a kulcs-csere parancsot, és hitelesítsük magukat a földi AD felé:

Update-AzureADSSOForest

A hitelesítés után megtörténik a kulcs cseréje:

Rövid idő után frissül az Azure portálon is:

Összefoglalva: evvel az egyszerű művelettel érdemes legalább 30 naponta frissíteni a Kerberos-kulcsot. Az AZUREADSSOACC objektumra kevés figyelem jut, de érdemes jól “eltenni” egy külön OU-ba és bekapcsolni rajta a véletlen törlés elleni védelmet.

OneDrive- hozzáférés megtagadva

Egy gyors esetleírás.

Környzetet: a felhasználók használják az OneDrive-ot, és a Desktop/Documents/Pictures mappa is oda van irányítva (lásd cikk: OneDrive mint felhasználói backup | Zoltan Istvanffy’s IT Blog (istvanffyzoltan.com)

A gépek Microsoft Endpoint Management-tel (Intune) menedzseltek, Windows Information Protection policy beállítva.

Hibajelenség: nem lehet új file-t létrehozni az OneDrive folderekben, hozzáférés megtagadva hibaüzenettel.

Megoldás:

A WIP-policyben meghatározott Data Recover Agent tanúsítványa lejárt.

Cseréljük ki a DRA tanúsítványt, és újra működőképes lesz az OneDrive.

Folyamatos hozzáférés-ellenőrzés

Az Azure AD egyik, még Preview fázisban lévő megoldása, a Continous Access Evaluation jó eszköz lehet, hogy még robosztusabb legyen a hozzáférési szabályzatunk.

Amikor egy felhasználó bejelentkezik egy online szolgáltatásba (pl. Exchange Online), akkor az Azure AD egy hozzáférési tokent állít ki számára, egy óra érvényességgel. A token érvényésségének lejártáig él a hozzáférés.

(az időtartam egyébként szabályozható, pl. conditional access session control segtíségével)

Nézzünk egy alappéldát:

Mi történik, ha letiltunk egy felhasználót?

Sajnos, a token érvényessége ettől még megmarad és továbbra is eléri az online szolgáltatást. Ez sok szervezet számára elfogadhatatlan, és szükség van granulárisabb megoldásra.

Itt jön képbe a Conditional Access Evaluation (CAE). Ennek lényege, hogy bizonyos események hatására az addigi token érvényessége azonnal megszűnik és szükséges lesz egy újra-authentikáció végrehajtása.

Milyen eseményeknél történik meg?

  • A felhasználói fiókot letiltjuk/töröljük
  • Jelszóreset vagy jelszócserét követően
  • MFA engedélyezésekor a felhasználó számára
  • Az admin visszavonja a meglévő hozzáférési tokeneket
  • Azure AD Identity Protection magas kockázatot érzékel

Valamelyik esemény bekövetkeztekor gyakorlatilag egy percen belül megszűnik a hozzáférés a Sharepoint Online, Exchange Online és Teams szolgáltatásokhoz (jelen preview állapotban ezt a két szolgáltatást támogatja). Saját tesztelés alapján 20-30 mp elteltével jöttek az authentikációs popup-ok, laptopon-telefonon-tableten egyaránt.

Milyen alkalmazások támogatják a CAE-t?

Alapesetben a kliensek megpróbálják felhasználni a már meglévő tokent a hozzáféréshez. CAE-vel a kliens az ún. claim challenge segítségével tudja, hogy nem a tárolt tokent kell használnia, hanem újat kell kérnie az Azure AD-tól (authentikáció bekérése)

Az alábbi alkalmazások CAE-kompatibilisek:

  • Outlook Windows
  • Outlook iOS
  • Outlook Android
  • Outlook Mac
  • Outlook Web App
  • Teams for Windows (Only for Teams resource)
  • Teams iOS (Only for Teams resource)
  • Teams Android (Only for Teams resource)
  • Teams Mac (Only for Teams resource)
  • Word/Excel/PowerPoint for Windows
  • Word/Excel/PowerPoint for iOS
  • Word/Excel/PowerPoint for Android
  • Word/Excel/PowerPoint for Mac

Hogyan működik a gyakorlatban?

Az alábbi példában úgy állítottuk be a Conditional Access policyt, hogy az online szolgáltatást csak meghatározott IP-tartományokól elérhető (pl. irodai hálózat)

  1. A CAE-kompatibilis kliens megkéri a tokent az Azure AD-tól (vagy felhasználja a tárolt érvényes tokent)
  2. A Conditional Access Policy megvizsgálja a hozzáférési kérést és engedélyezi (mivel az irodai hálózatban van)
  3. A kliens megkapja a hozzáférési tokent
  4. A felhasználó elmegy az irodai hálózatból, átvált mobilnetre
  5. A kliens az engedélyezett IP-tartományon kívülről küldi a hozzáférési kérést
  6. Az Azure AD megvizsgálja a kérést
  7. Az Azure AD megtagadja a hozzáférést és 401+ claim challenge-et küld vissza a kliensnek
  8. A kliens értelmezi a 401+ claim challenge-t, és nem próbálja a tárolt tokent használni, hanem újat kér
  9. A Conditional Access megtagadja a hozzáférést, mert nem a policyben engedélyezett IP-tartományokból érkezett a kérés.

Hogyan engedélyezzük a CAE-t?

Navigáljunk a https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/ContinuousAccessEvaluation linkre és válasszuk az Enable preview funkciót

Kijelölhetünk csoportokat, tesztelési célből, vagy alkalmazhatjuk minden felhasználóra:

Limitációk az IP-tartományokkal kapcsolatban:

A CAE nem értelmezi az MFA Trusted IP vagy a country location beállításokat. Csak az Azure AD-ba felvitt Named Location IP-ket használja.

https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/NamedNetworks

Ide kell felvinni azokat az IPv4 és IPv6 tartományokat, amikre szeretnénk ebben az esetben a CAE-t hasznáni.

Összefoglaló:

A CAE egy nagyszerű irányba mutató fejlesztés, és bízhatunk benne, hogy a preview után még több funckióval bővül. Addig is, érdemes kipróbálni és használatba venni.

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.

Letöltés blokkolása Cloud App Securityvel

Amennyiben rendelkezünk Azure AD P1 vagy P2 és Cloud App Security licensszel (Microsoft E5, EMS E5 vagy Microsoft E5 Security), könnyen megakadályozhatjuk céges adatok letöltését, ha nem menedzselt eszközről lép be.

Nem menedzselt eszköz: ami nincs az Intune-ba bevonva vagy nem Hybrid Azure AD-tag.

A példában az Exchange Online-nál fogjuk beállítani, tehát ha nem menedzselt eszköről lépünk be az OWA-ra, akkor kötelező lesz az Azure MFA hitelesítés és nem fogjuk tudni a mellékleteket a gépre letölteni. Így megmarad a lehetőség az OWA elérésre bármilyen gépről, de csak “read-only” módban.

Azure AD Conditional Access beállítása:

Navigáljunk el a conditional access portálra és hozzunk létre egy új szabályt:

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies

A Conditions részrél állítsuk be a Client app / Browser-t

Az Access Control / Grant mezőnél pedig pipáljuk be a “Require multi-factor authentication” opciót

Az Access Control / Session résznél kapcsoljuk be az “Use Conditional Access App Control” és use custom policy… opciót

Cloud App Security beállítása:

Navigáljunk el az MCAS portálra: https://portal.cloudappsecurity.com/

A Control / Policies résznél készítsünk egy új Session policyt

A session control type-nál állítsuk át “control file download (with inspection)”-ra és az Appnál vegyük fel a Microsoft Exchange Online-t

(Ha megnézzük a szabályt, látszik, hogy ha a Device Tag nem egyenlő “intune compliant” vagy “Hybrid Azure AD joined”, akkor lép érvénybe)

Az Action résznél állítsuk be a block-ot

A szabály elmentése után teszteljünk:

Ha nem menedzselt gépről lépünk be az OWA-ra, ez az üzenet fogad minket:

Továbblépve, ha megpróbálunk egy mellékletet letölteni a levelezésből, a következő üzenetet kapjuk:

A policy kiterjeszthető több alkalmazásra is, pl. Teams / Sharepoint, egyéb üzleti alkalmazások.

Jelszócsere vagy jelszó reset?

Sok szervezetnél teszem fel az alábbi kérdést: “van password reset megoldásotok?”

A válasz szinte minden esetben egy magabiztos “Igen! Ott az OWA felületünk, vagy akár az ADFS-en”

Elsőre jónak hangzik, de nézzük meg közelebbről. Technikailag a jelszócsere és reset esetén is ugyanaz történik: megváltozik a jelszó. Az odavezető út azonban már árnyaltabb.

Jelszócsere megoldások:

Ahogy említettem, jelszócserére tökéletes az OWA vagy ADFS felület:

Ahogy látjuk, itt minden esetben szükéséges, hogy a felhasználó tudja a régi jelszavát is, annak megadásával tud új jelszót is beállítani.

Ez kockázatos is lehet, mert ha egy támadó megszerzi a jelszót, annak birtokában meg is tudja változtatni.

A fentiek viszont nem adnak megoldást, ha a felhasználó ténylegesen elfelejtette a jelszavát. Ebben az esetben marad a nehézkes megoldás, ahol az IT-helpdesk segítségét kell kérje. Ez is érdekes lehet, hogy miként történik meg, ha a céges ticketing rendszerbe nem tud belépni. Telefonon felhívja az IT-t, hogy kérek egy jelszóresetet? Nem biztonságos. Megkér egy kollégát, hogy nyisson egy ticketet a jelszóresetről? Nem biztonságos, plusz hogyan juttatjuk el neki az új jelszót? Egy külső emailcímre vagy egy megadott telefonszámra sms-ben? Megint csak nem biztonságos.

Fontos tehát, hogy legyen password reset megoldásunk, lehetőleg önkiszolgáló módon, tehát a felhasználó saját magának tudjon jelszót resetelni, az IT-bevonása nélkül. Így az IT-t sem terheli, és felhasználói oldalról sincs várakozás.

Az Azure AD P1 licenszekkel igénybevehető a Self-Service Password Reset eszköz, amivel biztonságos módon, többfaktoros hitelesítéssel lehet új jelszót beállítani.

A felhasználó elnavigál a https://portal.office.com oldalra és kiválasztja a “can’t access your account?”

Megadja a felhasználónevét:

A következő oldalon pedig kiválasztja, hogy milyen megoldással szeretné hitelesíteni magát. A lenti képen az AzureAD-ban regisztrált telefonra SMS-küldéssel vagy az Authenticator alkalmazásból való kóddal:

A kód megadása után már beállítható az új jelszó:

Mint látható, az Azure AD SSPR eszközzel egy nagyon könnyen és gyorsan beüzemelhető bizotonságos jelszóreset-rendszert kapunk.

ADFS monitorozás a felhőből

A nagy szervezeteknél gyakori az ADFS használata. Itt tenném hozzá, ha csak az Office365 felé hitelesítést szeretnénk kezelni, ahhoz van már sokkal rugalmasabb eszköz, Pass-Through Autentication Method (https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)

Visszatérve, ilyen vagy olyan okok mentén kiépült a hibatűrő-magas rendelkezésre állású ADFS-farmunk. A hitelesítés működik, felhasználók részéről nincs panasz, minden rendben.

Mint minden fontos szolgáltatást, az ADFS-t is kell tudnunk monitorozni, látni a hibákat és rögtön beavatkozni, ha szükséges. A loggyűjtés megvalósítható egy SIEM rendszerrel, központi logolással, de abból visszamenőleg adatokat-riportokat kinyerni nehézkes feladat. Az Azure AD Connect Health with ADFS segítségével viszont könnyen, pár kattintással ellenőrizhetjük az ADFS-farmunkat.

Segítségével riasztásokat kaphatunk az ADFS teljesítményéről, konfigurációs hibáiról:

Illetve figyelemmel kísérhetjük az hitelesítési forgalmat, a relying party-k kihasználtságát:

Ezen kívül monitorozhatjuk a node-ok teljesítményét is:

Sőt, egy jelentést is kaphatunk, a top 50 hibás felhasználónév/jelszó párosról:

Ennek figyelése különösen fontos, mert lehet hogy csak egy konfigurációs hibáról van szó (scriptben bennemaradt egy régi jelszó), de lehet, hogy egy támadás jele is. Ez a riport 12 óránként frissül automatikusan.

Hogyan üzemeljük be az AD Connect Health with ADFS szolgáltatást?

Előfeltétel: Azure AD Premium P1 vagy P2 licensz

Engedélyezzük az ADFS Auditot:


Open Local Security Policy by opening Server Manager on the Start screen, or Server Manager in the taskbar on the desktop, then click Tools/Local Security Policy.
Navigate to the Security Settings\Local Policies\User Rights Assignment folder, and then double-click Generate security audits.
On the Local Security Setting tab, verify that the AD FS service account is listed. If it is not present, click Add User or Group and add the AD FS service account to the list, and then click OK.
To enable auditing, open a command prompt with elevated privileges and run the following command: auditpol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable
Close Local Security Policy.
— The following steps are only required for primary AD FS servers. —
Open the AD FS Management snap-in (in Server Manager, click Tools, and then select AD FS Management).
In the Actions pane, click Edit Federation Service Properties.
In the Federation Service Properties dialog box, click the Events tab.
Select the Success audits and Failure audits check boxes and then click OK. This should be enabled by default.
Open a PowerShell window and run the following command: Set-AdfsProperties -AuditLevel Verbose.

Töltsük le a szükséges agentent az Azure Portalról:

https://portal.azure.com/#blade/Microsoft_Azure_ADHybridHealth/AadHealthMenuBlade/QuickStart

Telepítsük fel az agentet az összes ADFS és Web Application Proxy node-ra

A telepítés után kezdődhet a konfigurálás

Jelentkezzünk be Global Adminként

A bejelentkezést követően elindul egy Powershell és elvégzi a szükséges beállításokat. Az esetleges hibákat is jelzi:

A sikeres telepítést követően három service fog futni:

Azure AD Connect Health AD FS Diagnostics Service
Azure AD Connect Health AD FS Insights Service
Azure AD Connect Health AD FS Monitoring Service

A sikeres telepítést és regisztrálást követően a működés ellenőrizhető az Azure AD-ban:

https://portal.azure.com/#blade/Microsoft_Azure_ADHybridHealth/AadHealthMenuBlade/AdfsServicesList

Megnézhetjük az Overview-t

Ellenőrizzük az Active Alerts részt:

Rögtön két konfigurációs hiba, ami javításra szorul. A javítást követően a rendszer lezárja a riasztást. A riasztásokról egyébként a Global Adminok emailt is kapnak:

A Monitoring rész alatt megnézhetjük az alapvető értékeket pl token requests/sec

Illetve a lekérdezést testreszabhatjuk jobb klikkel:

Az Usage Analytics résznél megnézhetük a használt relying party-kat:

A Bad Passwords Attemps résznél tudjuk ellenőrizni a leggyakrabban előforduló felhasználónév/jelszó hibákat

A kiugró failure eredményeket itt is érdemes megnézni és remedálni (pl. scriptben maradt régi jelszó, stb).

A Risky IP Report résznél láthatjuk a következő eseményeket:

  • IP címek, amikről túllépték a failed password logint
  • Felhasználóneveket, amikkel a belépési kísérletek történtek

A fenti screenshot alapján látszik, hogy este 6 és 7 óra között az adott IP-címről 14 különböző felhasználónévvel kíséreltek meg belépést.

Összefoglalva: érdemes az ADFS monitorozást beállítani at Azure AD segítségével, sok hasznos információhoz juthatunk vele.