Category Archives: Azure Active Directory

Elavult böngészők szűrése

Posted on by
Reply

Az IT-securityben nagy hangsúlyt fektetünk rá, hogy az operációs rendszerek/alkalmazások naprakészek legyenek. Ugyanez vonatkozik a böngészőkre is, elemi érdek, hogy mindig a biztonsági frissítésekkel ellátott verziót használjuk, a céges erőforrások eléréséhez (OWA, Sharepoint Online stb).

Lásd CIS Control 9.1 “Ensure only fully supported browsers and email clients are allowed to execute in the enterprise, only using the latest version of browsers and email clients provided through the vendor.”

Eddig az elmélet, de a gyakorlatban hogyan tudjuk kikényszeríteni, hogy valóban csak “friss” böngészővel lehessen az erőforrásokat elérni?

Ebben segit az Azure AD Conditional Acces és Defender for Cloud Apps szolgáltatás. Lássuk, hogyan lehet letiltani az “outdated” browser használatát.

Megjegyzés: outdated browsernek számít az aktuális főverzió -2. Tehát ha pl. az Edge a 109-es verziónál jár, akkor támogatott a 109, 108 és 107 főverzió.

Először is, szükség lesz a kívánt erőforrás (OWA, Sharepoint stb) továbbirányítására a Defender for Cloud Apps-ba.

Conditonal Access

Készítsünk egy Conditional Access policy-t, az alábbi beállításokkal:

Defender for Cloud Apps Access Policy

A Cloud Apps-ban hozzunk létre egy Access Policyt:

Az User agent tag értéke legyen egyenlő az Outdated browser kategóriával illetve az Action legyen Block értéken. Természeseten más filtereket is hozzáadhatunk (user group stb.)

Tesztelés

Tesztelésként telepítettem egy Firefox 98-at és megpróbálkoztam egy böngészős Teams bejelentkezéssel. A Defender for Cloud Apps blokkolta is az elérést, ahogy vártuk:

A fenti tiltást nemcsak böngészőre, de akár operációs rendszerre is alkalmazható:

Összefoglalás

Ahogy a fentiekből látható, könnyen biztosíthatjuk, hogy naprakész böngészőkből legyen elérhető az erőforrás (ne feledjük, hogy nemcsak beépített MS szolgáltatásokat tudunk így védeni, az Azure AD Application Proxy segítségével akár 3rd party vagy on-prem alkalmazásokat is).

Break-glass account monitorozása

Posted on by
Reply

Fontos szerepe van a break-glass accountoknak, hogy legyen “visszaállási” lehetőségünk hibás konfiguráció (pl. kizártuk magunkat a tenantból Conditional Access policyval) vagy szolgáltatás kiesés esetén. Személyes élmény 2018-ból, mikor nagyjából napig nem működött az Azure MFA, így bejelentkezni sem tudtam az admin accounttal 🙂

Erre a veszélyre reflektálva sok szervezet használ már break-glass accountot. Mielőtt rátérnénk a security vonatkozásokra, nézzük át gyorsan az ajánlásokat az accounttal kapcsolatban:

  • a break-glass account az Azure AD-ban létrehozott entitás legyen; ne használjuk syncelt vagy federált accountot.
  • ne legyen személyhez kapcsolva
  • Ha használunk a breakglasshoz MFA-t, ne legyen valaki személy telefonja, emailcíme stb; a legjobb egy dedikált FIDO2 security key, biztos helyre elzárva
  • az accountra ne vonatkozzon semmilyen Conditional Access policy, illetve egyéb más security policy
  • Azure AD Identity Protectionban állítsuk permanent Global Administratorra, ne csak Eligible-re

Monitorozás

Security szempontból elengedhetetlen, hogy monitorozzuk ennek az accountnak a használatát. Hiszen nincs személyhez kötve, nincs MFA sem hozzá, így kritikus hogy lássuk az aktivitását. Ebben tud segiteni a Microsoft Sentinel.

A monitorozáshoz szükséges előfeltételek:

  • Microsoft Sentinel és Log Analytics Workspace
  • Azure AD P1 vagy P2 licensz a sign-in logok exportálásához
  • Break-glass account
  • Break-glass account Object ID

Feltételezzük, hogy a Sentinel már be van állítva, rátérhetünk a konnektor konfigurálásra.

Sentinel konnektor konfigurálása

Navigáljunk el a Sentinel portálra, majd a Data Connectors közül válasszuk ki az Azure Active Directory konnektort:

Az Audit és Sign-in logokat válasszuk ki:

A konnektor státuszát és a loggyűjtést tudjuk ellenőrzni a tulajdonságlapon:

Analytic rule elkészítése

Készítünk egy rule-t, ami incidenst generál ha a break-glass accounttal aktivitás történne.

Navigáljunk el a Sentinel portálon az Analytics részre és válasszuk a Create scheduled query rule opciót.

Adjunk nevet és leírást a szabálynak, a Tactics résznél válasszuk ki az Initial Access és Credential Access lehetőségeket, a Severity legyen High értéken.

A Set rule logic résznél egy Kusto lekérdézést kell definiálnunk:

SigninLogs
| project UserId,UserPrincipalName, Location, SourceSystem, TimeGenerated, IPAddress
| where UserId == 'object-id'
| extend AccountCustomEntity = UserPrincipalName
| extend IPCustomEntity = IPAddress
| extend HostCustomEntity = SourceSystem

Az UserID-hoz tartoztó object-id-t megtaláljuk az Azure Active Directoryban a break-glass account tulajdonságlapján.

A lekérdést állítsuk be 5 percenkéntire.

Az Incident setting résznél állitsuk be hogy generálódjon incidens

Ellenőrzés

A beállítások után érdemes leellenőrizni, hogy valóban működik-e az incidensgenerálás. Ehhez jelentkezzünk be a break-glass accounttal és nézzük, megjelenik-e a Sentinel alert.

Összefoglalás

Az break-glass account megléte nagyon fontos, de ugyanúgy kiemelt szerepet kap a monitorozása is. A fentiek alapján ez könnyen beállítható.

Legacy authentication protokollok

Posted on by
Reply

Egyre közeleg a dátum, mikor a Microsoft végleg kivezeti a basic authenticationt az Exchange Online elérésében (2023.március 31.)

Az M365 adminok ezt többé-kevésbé tudják, és meg is teszik a szükséges lépéseket. Viszont sokszor jön a kérdés, mik is ezek a legacy protokollok és mi használja őket?

Az Azure Active Directoryban sign-in logban leszűrve ezeket látjuk, mint legacy protocols:

Legacy protocols:

  • Authenticated SMTP – POP és IMAP kliensek használják levélküldésre
  • Autodiscover – Outlook és Exhange Active Sync kliensek használják a mailboxok megkeresésére az Exchange Online-ban, pl Windows Mail és egyéb mobilalkalmazások
  • Exchange ActiveSync (EAS) – Postafiók elérés Exchane Online-ban
  • Exchange Online PowerShell – Exchange Online elérése Powershellből
  • Exchange Web Services (EWS) – úgynevezett programming interface amit az Outlook, Outlook for Mac, és 3rd party alkalmazások használnak
  • IMAP4 – IMAP4 email kliensek használják, pl Thunderbird vagy Apple Mail
  • MAPI over HTTP (MAPI/HTTP) – Outlook 2010/2013 kliensek használják.
  • Offline Address Book (OAB) – Outlook használja az address list letöltésére
  • Outlook Anywhere (RPC over HTTP) – Outlook 2016 használja
  • Outlook Service – Windows 10-ben lévő Mail and Calendar app használja
  • POP3 – POP3 kliensek használják
  • Other clients – minden más protokoll ami legacy módon működik

A POP/IMAP/Remote Powershell már kapott Oauth 2.0 támogatást, ezek továbbra is használhatók.

Microsoft Sentinel – ingyenes konnektorok

Posted on by
Reply

Ügyfelekkel való konzultáció során szinte mindig elhangzik a kérdés: melyek az ingyenes Sentinel-konnektorok? Tudjuk őket definiálni, de vannak olyan ingyenes konnektorok, amik tartalmaznak fizetős elemeket is.

Ingyenes adatforrások:

  • Azure AD Identity Protection
  • Azure Activity Logs
  • Office 365
  • Microsoft Defender for Cloud
  • Microsoft Defender for IoT
  • Microsoft 365 Defender
  • Microsoft Defender for Endpoint
  • Microsoft Defender for Identity
  • Microsoft Defender for Cloud Apps

Fontos tisztázni: a data connector bekötése mindig ingyenes. A logfileok esetén csak az Azure Acive Directory és O365 audit logok ingyenesek. A többi logforrásnál csak az alert és incidens generálás és néhány aktivitás ingyenes.

Nézzük egyenként a data connectorokat:

Azure AD Identity Protection:

Előfeltétel: Azure AD Premium 2 licensz

Ingyenes adattipus: Security Alert (IPC)

Azure Activity:

Ingyenes adattipus: minden tipus

Office 365

Ingyenes adattipus: Sharepoint, Exchange és Teams activity

Defender for Cloud:

Ingyenes adattipusok: Security Alert

Defender for IoT:

Ingyenes adattipus: Security Alert

Microsoft M365 Defender:

Ingyenes adattipus: Security Alert és Security Incident

Figyelem: a többi adatbetöltés már számolódik a Sentinel költségbe!

Defender for Endpoint:

Ingyenes adattipus: Security Alert (MDATP)

Defender for Identity:

Ingyenes adattipus: Security Alert (AATP)

Defender for Cloud Apps:

Ingyenes adattipus: Security Alert (Defender for Cloud App)

A Cloud Discovery logok bekapcsolása szintén számolódik a Sentinelben

Összefoglalva:

Mint látjuk, a Microsoft Sentinelt költséghatékony módon tudjuk használni arra hogy az O365 és Azure Activity logokat gyűjtsük és a különböző Microsoft termékekből érkező alerteket is fogadjuk.

Azure AD Certificate-based Authentication

Posted on by
Reply

2022 novemberében a Microsoft az Ignite konferencián bejelentette az Azure AD CBA szolgáltatás végleges (General Available) állapotba kerülését. Lássuk, mi ez és hogyan tudjuk beállitani.

Mi az Azure AD CBA?

A CBA lehetővé teszi, hogy különböző Microsoft alkalmazásokba és webes felületekre tanúsitvánnyal jelentkezzünk be. A tanúsitványt a saját PKI (public key infrastructure) környezetünkből kapjuk és az Azure AD ezt használja fel a hitelesitéshez. Ezzel egy úgynevezett phishing-resistent megoldást kapunk.

Hogyan működik a CBA?

A következő ábra bemutatja a bejelentkezési folyamatot:

Lássuk az egyes lépéseket:

  1. A felhasználó megnyitja a https://myapps.microsoft.com portált
  2. Ha nem volt eddig bejelentkezve, akkor a felhasználót elirányitja a https://login.microsoftonline.com oldalra
  3. A felhasználó megadja a nevét
  4. Az Azure AD ellenőrzni, hogy a tenantban be van-e állitva a CBA authentication. Ha igen, akkor megjelenik egy link “Use a certificate or smartcard” néven
  • 7. Az Azure AD ellenőrzni a tanúsitvány visszavonási listát (CRL), hogy nincs-e visszavonva
  • 8. Ha van Conditional Access policy, ami megköveteli az MFA-t, és ha az úgynevezett certificate authentication binding rule megfelel, akkor a belépés megtörténik.
  • 9. Az Azure AD elküldi a primary refresh tokent és a belépési process lezárul

Hogyan állitsuk be a CBA-t?

Előfeltételek:

  • Működő PKI rendszer (legalább egy root CA plusz egy intermediate CA)
  • Kiadott tanúsitvány a felhasználóknak (client authentication SKU)
  • A CA-nak legyen elérhető a CRL listája az internet felől (ennek hiányában az Azure AD nem fogja leellenőrizni a tanúsitvány érvényességét és nem blokkolja a belépést)

CA konfiguráció az Azure portálon

Lépjünk be a https://portal.azure.com/#view/Microsoft_AAD_IAM/SecurityMenuBlade/~/CertificateAuthorities portálra és töltsük fel a Root (és esetleg az intermediate CA) tanúsitványunk publikus kulcsát. Töltsük ki a CRL endpoint URL-jét is.

Engedélyezzük a CBA-at a tenantban

Lépjünk be a https://portal.azure.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AdminAuthMethods portálra és engedélyezzük a Certificate-based authenticationt.

Beállithatjuk az user csoportokat vagy minden usert is, a configure részben pedig maradhatunk az alapbeállitásoknál.

A többi opciót (single vs multi-factor authentication, rules) a következő posztban fogom részletezni.

Összefoglaló:

Áttekintettük, hogy mi az Azure CBA, hogyan működik és hogyan lehet alapszinten bekonfigurálni.

Földi Exchange postafiók elérérés – Azure AD Conditional Access

Posted on by
Reply

Ügyfeles konzultáció során merült fel az alábbi scenárió:

“Exchange 2016 hybrid környezetünk van, sok postafiókot már migráltunk az O365-be, de sok még a földi Exchange-en van. Az Exchange Online elérésére van több Conditional Access lehetőségünk (MFA, Intune compliant device stb) is, lehetne ezt a földi fiókokra is alkalmazni?”

Jó hír, hogy lehetséges, a Hybrid Modern Authentication révén (minimum követelmény az Exchange 2013 és Outlook 2013)

Hogyan néz ki a Hybrid Modern Authentication (HMA) folyamat?

  1. A felhasználó elindítja az Outlookot ami az autodiscover segítségével csatlakozik a földi Exchange–hez. Innen a kapcsolat továbbmegy az evoSTS URL-hez, amit az HMA kialakítása során beállítottunk.
  2. Az Outlook az AzureAD-hoz fordul, végrehajtja a modern auth folyamatot, alkalmazódnak rá az esetlegesen beállított Conditional Access szabályok.
  3. A sikeres auth után a felhaszáló megkapja az Access Tokent és Refresh Tokent.
  4. Az Access Tokent átadva a földi Exchange szervernek, a mailbox elérhetővé válik.
Hybrid modern authentication diagram

Kinek ajánlott a HMA?

Olyan szervezeteknek, ahol hosszú távú hybrid kialakítását tervezik, és biztosítani kívánják, hogy a földi postafiókok elérése is ugyanolyan szabályozottan történjen, mint a felhős esetén.

M365 Enterprise és SMB csomagok összehasonlító táblázatok

Posted on by
Reply

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)

modern-work-user-subscription-plan-comparison-for-enterpriseDownload

M365 SMB csomagok összehasonlító táblázat (PDF)

microsoft-365-business-plan-comparison-for-smbDownload

Seamless SSO – cseréljük a Kerberos kulcsot

Posted on by
1

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.