Azure AD Connect – Auto Upgrade lehetőségek

A hibrid szervezeteknél az AAD Connect egy nagyon fontos eszköz, ennek segítségével tudják naprakészen tartani az Azure AD-t is. Kiemelt jelentőségű tehát, hogy mindig a támogatott és friss verziót használjuk.

(Jó tudni, hogy a 18 hónapnál régebben kiadott AAD Connect verziók nem támogatottak (a cikk írásakor az 1.3.20.0-as verzió és régebbeiek))

Az AAD Connect elég régóta tartalmazza az Auto-Upgrade lehetőséget. A kliens meghatározott időközönként lekérdezi a Microsoft szervereit és frissíti magát.

A frissítések állapotát ellenőrzini lehet az eventlogban, Applications and Services Logs\Microsoft\AzureADConnect\AgentUpdater\Admin résznél

Viszont fontos észben tartani, hogy a fenti Auto-Upgrade nem minden esetben működik! Előfordulhat egyedi konfiguráció, illetve nem minden egyes új kiadás jelenti, hogy az AADConnect frissíti magát.

Ellenőrizzük, az Auto-Upgrade állapotát, az AAD Connect felületén:

illetve powershellből is lekérdezhető:

Get-ADSyncAutoUpgrade 

Háromféle állapot lehetséges:

  • Enabled – Auto-Upgrade engedélyezve van és 6 óránként keres frissítést
  • Disabled – Auto-Upgrade le van tiltva, nem frissül a kliens
  • Suspended – Auto-Upgrade nem támogatott, egyedi beállítás(ok) miatt

Az utolsó, Suspended funkciót maga az AAD Connect kliens állítja be, ennek parancssoros átállítása (Enabled) nem támogatott.

Amennyiben a Suspended állapotot látjuk, akkor érdemes párhavonta ellenőrizni hogy van-e frissebb kliens és kézzel telepíteni (in-place upgrade). Az AAD Connect verziólista itt elérhető: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history

Ha lenne mód az Auto-Upgrade használatára, de mégsem szeretnénk, hogy frissítse magát a kliens (szeretnénk előtte tesztelni stb), akkor a használjuk a következő parancsot:

Set-ADSyncAutoUpgrade -AutoUpgradeState Disabled

Ha pedig mégis visszaállnánk az automatikus frissítésre, akkor így tehetjük meg:

Set-ADSyncAutoUpgrade -AutoUpgradeState Enabled

Vendégposzt – Seamless SSO

Nagy-Löki Balázs kollégám posztját ajánlom mindenki figyelmébe:

Az eredeti poszt linkje: https://nlbit.blog/2020/08/07/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

Távollévő gépek menedzselése

A céges hálózattól tartósan távollévő gépek menedzselésének kérdése nem újkeletű, több szervezetnek is okozott már fejfájást. Illetve új problémaként felmerült a COVID miatt, hogy sok felhasználó hirtelen távolról kényszerült dolgozni az eszközével.

Mit értünk tartósan távollévő gép alatt?

Olyan laptopokat, amik a felhasználási sajátosságok miatt alig lépnek be a céges hálózatba, legyen az irodai hálózat vagy VPN. Néhány opció:

  • orvoslátogatók laptopjai
  • biztosítási és egyéb utazó ügynökök laptojai
  • alvállakozók, akik kapnak céges laptopot, de nincs igény a belső hálózat elérésre

Kiemelten jó példa a gyógyszeripari cégeknék az orvoslátogatók gépei. Kapnak céges eszközt, használják a levelezést, a munkájukat tudják végezni, az irodába nagyjából sosem mennek be, hálózatra nem csatlakoznak fel.

Mi történik menedzsment szempontból egy ilyen géppel?

  • 30 nap után megszűnik a domaines secure channel (“kiesik a domainből”)
  • Az előírt group policyk nem futnak le, nem frissülnek
  • A startup és logon scriptek nem futnak le
  • A wsus/sccm által kezelt frissítések nem települnek a gépre
  • Legrosszabb esetben akár az antivirus definiciós frissítések sem jutnak le a gépre (volt példa, ahol tiltották a frissítések internetről letöltését is)

Amint látjuk, ez a helyzet kellemetlen az IT-számára, hiszen ezen gépek felett gyakorlatilag elveszítette a kontrollt. A menedzselhetőség innetől a felhasználótól függ (mikor megy be az eszközzel céges hálózatra, mikor kapcsolja be a VPN-t stb…és milyen rossz az, mikor a céges bérelt vonalon kezd töltődni az akár több GB-os SCCM-csomag 🙂 ) A kockázat pedig adott: nem kerülnek fel a biztonsági frissítések, az IT nem értesül a gépet érintő incidensekről és lehetne sorolni.

Mi lehet a megoldás?

Toljuk ki a menedzsment határait a céges hálózaton kívülre! Gondoljuk át, hogy milyen nagyszerű lenne, ha az IT-felügyelet az Interneten kereszül történhetne! Az orvoslátogatók gépeinek üzemeltetői repesnének az örömtől.

Csináljunk Hybrid Azure AD joint, vagy akár Azure AD joint, Microsoft Endpoint Management (MEM) felügyeleti eszközzel párban. Evvel a következő lehetőséghez juthatunk (maradva az orvoslátogatók gépeinél)

  • Az on-premise domain gépet beléptetjük az AzureAD-ba is (ezt nevezzük Hybrid Azure AD joinnak. Innenől az AAD “ismeri” a gépobjektumot
  • Nincs secure channel hiba többé
  • A MEM segítségével teljeskörűen tudjuk menedzselni a gépet: frissítések telepítése, scriptek futtatása, VPN, emailfiók konfigurációk leküldése, megfelelőségek ellenőrzése (pl. lemeztitkosítás be van-e még kapcsolva), központi szoftvertelepítések
  • Jelentések-leltár futtatása a távoli gépeken, folyamatos státuszriportolással

Láthatjuk, hogy evvel a megoldással visszakapjuk az elveszett kontrollt a távollévő gépek felett.

Összegzés: érdemes átgondolni a kliensmenedzsment kérdését és válaszolni az új igényekre (céges hálózat nélkül is a kontroll megléte), erre az AzureAD és MEM egy jó alternatíva lehet.

Kerberos – határok nélkül

Bizonyára nagyon sokan ismerik a Kerberos authentikációt, on-premise környezetben főleg. Szeretjük is, mert biztonságos és működik vele a single sin-on (SSO). Ha a felhasználónk már authentikálta magát, akkor a további erőforrások eléréséhez nem kell újra megtennie, a háttérben intéződik.

Emlékeztetőül, a klasszikus Kerberos-hitelesítés így történik:

Így ha egy active directory userrel vagyunk belépve és megpróbáljuk elérni a pl. a belső sharepointot (pl. https://sharepoint.company.com), akkor a háttérben megtörténik a hitelesítés és a felhaszáló eléri az erőforrást (természetesen vannak előkövetelmények, SPN legyen beállítva). Ha nincs SPN definiálva, akkor Kerberos helyett NTLM hitelesítéssel próbálkozik (ez is SSO még, de jóval nagyobb terhelés a kiszolgálónak a challenge/response folyamat miatt), ha az NTLM sem sikerül, akkor felugrik a jelszóbekérő ablak. Természetesen mindez függ, hogy a Sharepointnál milyen hitelesítést állítottunk be:

Tehát van működő Kerberos és SSO. Viszont, ahogy láttuk, a működéshez kell a Ticket Granting Service, azaz a domain controller. Ha ez kiszolgáló nem elérhető hálózati szinten, a Kerberos nem működik.

Mi lehet a megoldás, ha távolról, céges hálózat nélkül szeretnénk elérni a belső alkalmazásokat, SSO-val? A régi megoldás a VPN kapcsolat, de az nehézkes, komplexé tehet az infrastruktúrát.

A modern megoldás, ha Azure AD Application Proxyt használunk, melynek segítségével a belső webalkalmazásokat elérhetjük SSO-val, az Azure AD segítségével.

Nézzük, hogyan lehet egy belső alkalmazást publikálni:

Előfetétel: az AAD App Proxyhoz Azure AD P1 vagy P2 licensz szükséges.

Azure AD Connect megléte, felhasználók szinkronizálása az AzureAD-ba.

Működése:

A felhasználó szeretné elérni a belső alkalmazást, először az Azure AD-hoz fordul. Az AAD továbbítja őt az Application Proxy Service-hez, ami kommunikál az előzőleg a földi környezetbe telepített Application Proxy Connectorral. Itt megtörténik az authentikáció és a felhasználó megkapja a hozzáférést.

  1. lépés

Application Proxy Connectorok telepítése: két on-premise kiszolgálóra telepíteni kell a Connector agentet. A két agent a redundancia miatt szükséges. Amennyiben Kerberost akarunk használni, a két szervernek ugyanannak a domainnek tagja kell legyen, mint ahol a belső erőforrás található. A telepítés menete itt olvasható:

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application

Amennyiben a Connectorok telepítve vannak, lehet őket csoportokba rendezni:

A csoportba rendezés lehetővé teszi hogy különböző applikációkhoz külön Connector Agenteket rendeljünk.

2. lépés

Enterprise Application létrehozása: itt hozzuk létre az AzureAD-ban a publikálni kívánt alkalmazást.

https://portal.azure.com/#blade/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/AllApps/menuId/

Válasszuk a New Applicationt, majd a következő oldalon az “On-premies application” lehetőséget:

A Basic Settings résznél töltsük ki az Internal és External URL részeket. Ennél a példánál split-dns van, tehát a külső és belső névtér megegyezik. Így az internal és external url egyaránt https://sharepoint.istvanffy.eu lett. A pre-authentication legyen “Azure Active Directory”, a Connector Groupot pedig állítsuk be, ha szükséges (tesztkörnyezetben maradhat Default-on)

Az Additional Settings résznél hagyjuk az alapbeállításokon:

Az így elkészült alkalmazásnál a Properties résznél kapcsoljuk ki az “User assignment required” opciót.

Ha ezt nem tesszük, akkor csak azok a felhasználók férnének hozzá az alkalmazáshoz, akiket a Users and Groups résznél engedélyezünk. Ez hasznos lehet, ha szeretnénk csoportszinten megszabni, kik érhetik el az alkalmazást. Egyéb esetekben (ha mindenkinek szeretnénk elérhetővé tenni) ki kell kapcsolni.

3. lépés

Single Sign-on beállítása: a létrehozott alkalmazásnál navigáljunk el a Single Sing-on részhez és az alábbi beállításokat találjuk

Mivel mi a Kerberost szeretnénk megvalósítani, válasszuk a Windows Integrated Authentication opciót.

Itt meg kell adnunk az on-premise környezetben beállított SPN értékét (lásd később)

Vigyázzunk a formátumra, SPN esetén http/sharepoint.istvanffy.eu formában kell megadni. A Delegated Login Identity értékét hagyjuk az User Principal Name formában, így a felhasználó az UPN-jével tud authentikálni.

4. lépés

SPN ellenőrzése: jó esetben már beállításra került a földi környezetben a szükséges SPN. Ezt leellenőrizhetjük egy domaines gépen futtatott setspn -Q http/sharepoint.istvanffy.eu lekérdezéssel.

Amennyiben mégsem létezne az SPN, az alábbi hibát kapjuk:

Ez esetben kézzel kell hozzárendelnünk az SPN-t, a következő paranccsal: setspn -S http/sharepoint.istvanffy.eu <sharepoint szerver neve>

5. lépés

Kerberos delegálás beállítása: a következő lépésben lehetővé tesszük a Connector Agentek számára, hogy a Kerberos-delegálást használják.

Az Active Directory Users and Computers konzolban keressük meg a Connector Agent számítógép objektumát, majd menjünk a Delegation fülre, válasszuk ki a “Trust this computer…” és “Use any authentication protocol” részt

Az Add gombbal keressük ki a sharepoint szerver computer accountját (vagy service userét, ha ahhoz van az SPN hozzárendelve), és válasszuk ki a kívánt service-t (esetünkben a http/sharepoint.istvanffy.eu)

A fenti beállítást ne felejtsük el minden Connector Agent computernél hozzáadni, különben Kerberos-hibákat kaphatunk.

6. lépés

DNS beállítása: ahhoz, hogy az applikáció elérhető legyen az Azure AD-n keresztül, a DNS-t be kell állítani. Esetünkben definiálnunk kell, hogy a sharepoint.istvanffy.eu mutasson az Azure-re. Ezt CNAME-rekord létrehozással tudjuk megtenni, erre az Enterprise Application figyelmeztet is:

7. lépés

3rd party tanúsítvány feltöltése: ahhoz, hogy az applikációt a saját domainnevünkkel tudjuk elérni, szükséges egy harmadik féltől származó tanúsítvány feltöltése az Azure-be. Ezt a tanúsítványt fogja a hitelesítéshez használni és így biztosan nem kapunk böngésző-figyelmeztetéseket

A tanúsítványt pfx formátumban kell feltölteni és megadni a hozzá tartozó jelszót:

Amennyiben később több alkalmazást is publikálánk, a tanúsítványt nem szükséges minden alkalommal feltölteni, elég egyszer.

8. lépés

Tesztelés: ezek után az active directory felhasználóval belépve a gépre (VPN és céges hálózat nélkül) elnavigálunk a publikált alkalmazás linkjére (jelen cikk példájában https://sharepoint.istvanffy.eu) akkor azt tapasztaljuk, hogy a sharepoint rögtön “beengedett”, azaz nem kért authentikációt, sikerült a Kerberos-hitelesítés.

Amennyiben más gépről hívjuk meg a linket, az AzureAD fogja kérni a hitelesítést:

A céges accountot és jelszót megadva szintén megtörténik a hitelesítés.

Hibakeresés:

A leggyakoribb probléma, hogy a Kerberos-delegáció nincs jól beállítva, ez esetben az alábbi hibát kapjuk (incorrect Kerberos constrained delegation configuration)

Ez esetben duplán ellenőrizzük le az SPN és delegációs beállításokat.

Szintén tud segíteni a Connector Agenteken eventlog:

Applications and Services Logs > Microsoft > AadApplicationProxy > Connector > Admin

A teljes hibakeresési link: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-back-end-kerberos-constrained-delegation-how-to

Összefoglalva: megoldható a belső alkalmazások elérése külső hálózatból, a biztonságos és SSO-t nyújtó Kerberos-hitelesítéssel is.

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.

Tippek a helpdesk terhelésének csökkentésére

Az utóbbi fél évben bekövetkezett távoli munkavégzés az IT-helpdeskek terhelését jelentősen megnövelte. Nézzünk pár tippet, amivel a felhasználók produktivitása is megmarad, a helpdeskről is levesz terheket és a működési költséget is csökkenti.

  1. Elfelejett jelszavak problémája

Nagyon sok szervezetnél jelent kihívást, hogy kezeljék az elfelejettett felhasználói jelszavak resetelését. Ez mindenkinek rossz, hiszen a felhasználó addig nem tud dolgozni, az IT-helpdesknek pedig ismétlődő unalmas feladat. További kérdés, hogy a megváltoztatott jelszót hogyan juttatják el a felhasznónak (SMS, vagy magán emailcímre küldéssel? Ez vajon bizonságos?)

Azure AD Self-Service password reset szolgáltatással a felhasználó tud jelszót resetelni saját magának is, biztonságos módon (kétfaktoros hitelesítéssel)

A felhasználó pedig ezt látja:

Állítsuk be ezt szolgáltatást és oktassuk le a felhasználóknak. Megfelelő kommunikáció után akár 80%-kal is csökkenhet az “elfelejettem a jelszavam, resetet kérnék” esetek száma.

2. Windows upgrade-ek zavartalansága

A Windows 10-hez évente kétszer érkezik nagyobb frissítőcsomag, melyek telepítése minden esetben nagyon ajánlott. Érdemes up-to-date tartani az operációs rendszereket, mind a biztonsági, mind az egyéb funkcionális frissítések miatt.

Amennyiben viszont nem-Microsoft végpontvédelmi megoldás van használatban, az okozhat gondot a frissítési folyamatnál, ezáltal megint csak jelentős mennyiségű helpdesk-ticketet generálva.

Elkerülhető ez a probléma és a hosszas előzetes kompatibilitási tesztelések, ha végpontvédelmi megoldásnak a Microsoft Defender ATP-t használjuk. Az MDATP-vel nem csak a klasszikus vírusvédelmi megoldást lehet bevezetni, hanem a különböző fejlett támadási formákat is képes detektálni és megállítani.

3. Bátorítsuk a BYOD-ot!

Megint csak egy jellemző problémakör tud lenni az eszközök menedzselése. Új felhasználó érkezik a céghez, laptopra van szüksége, beállításokra, jogosultságokra stb. A gép átvételéhez személyesen kell megjelennie az irodában, várnia, ez mind-mind időveszteség.

Ezek csökkentésére egy megoldás lehet a BYOD-eszközök használata. Amennyiben van mód rá, érdemes bátorítani a felhasználókat hogy használják a meglévő eszközeiket (számítógép, mobil stb), ezáltal “önjáró” módon beálltani a munkakörnyezetét.

A Microsoft Endpoint Managerrel (régi nevén Intune), egy robosztus, biztonságos keretrendszer alakítható ki az ilyen eszközöknek (és természetesen a vállalati eszközöknek is). A MEM-mel biztosítható az eszközök felügyelet alá vonása (enrollment), különböző alap-alkalmazásokat lehet automatikusan telepíteni, VPN-beállítások leküldeni, különféle biztonsági beállításokat előírni.

A fenti környezetek kialakítása nem egyszerű, egylépéses feladat, viszont megéri a befektetést.

Dokumentumok megosztása külsős partnerekkel, biztonságosan

Előző cikkemben bemutattam, hogyan lehet egy alap információvédelmi megoldást implementálni, amit a felhasználók egymás között tudnak használni:

https://istvanffyzoltan.com/2020/07/14/informaciovedelem-m365-alapon/

Ezek után merül fel a jogos igény, hogy lehet ezt kiterjeszteni külsős parterekre is, azaz biztosítani számukra a dokumentumok megosztását és közös Teams-munkát, miközben a hozzáférés/tartalomvédelem is megmarad.

A most következő cikkben leírok egy lehetséges megoldást, amit kiindulási alapnak lehet használni.

A külsős accountok kezelése mindig is fejtörést okozott a szervezeteknek. Létrehozhatók a földi vagy felhős AD-ben, mint standard userek, de akkor nekünk kell a biztonságról/jelszókezelésről/licenszekről gondoskodnunk.

A javasolt megoldás inkább, hogy a kezeljük őket az Azure AD-ban, guestként. Erre az AAD lehetőséget ad, ingyenesen. Az általános szabály, hogy egy licenszelt userre 5 guest juthat. Tehát egy 100 fős cégnél 500 guest accountot lehet létrehozni díjmentesen.

Az Azure AD B2B (business-to-business) lehetőségét kihasználva nagyon egyszerűen megoldható, hogy egy vállalati accounttal rendelkező külsőst meghívjunk (invite) guestként. Így lehetősége van a saját accountja használatára, nincs szükség külön regisztrációra, név/jelszó karbantartására.

Azure AD Guest meghívása

Ehhez küldenünk kell számára egy meghívót az Azure AD-ból. Navigájunk el ide adminként ide: https://portal.azure.com/#blade/Microsoft_AAD_IAM/UsersManagementMenuBlade/AllUsers és válasszuk a New Guest opciót.

Töltsük ki a név és emailcím mezőket, ide fog kimenni a meghívó.

A meghívó elküldése meg is tudjuk nézni az így létrejött accountot:

Látható, hogy még nem fogadta el a meghívást, azaz nem csinálta végig a regisztrációs processt.

A címzett egy emailt kap, melyben lévő linkre kattintva el tudja kezdeni a regisztrációt:

Figyelmeztetés: mindig legyünk óvatosak a invitáló mailekkel! Csak akkor kattintsunk a linkre és végezzük el a belépést, ha előtte megbizonyosodtunk a meghívó szervezet érvényességéről. Ha ismeretlentől érkezik a felkérés, töröljük a meghívó levelet.

A linkre kattintva az O365 bejelentkező képernyő fogad, az authentikáció miatt:

A bejelentkezés után kapunk egy beleegyezés-kérő ablakot, ami felsorolja, hogy milyen információkat kérne rólunk a meghívó szervezet (név, emailcím, esetleg fotó)

A beléptetés után a meghívó szervezet oldalára jutunk:

Ha újra megnézzük az Azure AD-ban a meghívott user adatlapját, már látható, hogy a regisztrációt megcsinálta, és példánkban egy külső Azure AD-tenantból érkezett.

Evvel a felhasználó accountja létrejött az Azure AD-ban, használatra kész.

Természetesen a fenti folyamat scriptelhető, sőt Power Automate segítségével egy olyan workflow is összeállítható, ahol a meghívást indító felhasználó csak beírja a kívánt meghívott nevét és emailcímét, a rendszer pedig a háttérben intézi a folyamatot.

Következő lépésben engedélyezni kell a külsősökkel való együttműködést a Sharepoint Online / Teams rendszerekben.

Teams Guest access engedélyezése:

Az Office Admin Portalon, az Org Settings / Microsoft Teams részen kapcsolhatjuk be a guest accesst:

https://portal.office.com/AdminPortal/Home#/Settings/Services/:/Settings/L1/SkypeTeams

A Sharepoint Online-ban is érdemes beállítani a megosztási lehetőségeket, szabályozva, hogy csak olyan külsősökkel lehet fileokat megosztani, akik már guestként szerepelnek az Azure AD-címtárunkban:

A Sharepoint Admin Centerben állítsuk be az External Sharing opciónól, hogy Existing guests only:

Ezután a guest usert meghívhatjuk a Teamsbe:

Illetve fileokat is megoszthatunk vele az OneDriveból:

Ezeken túl van mód az információvédelmi megoldást is kiterjeszteni a külsősökre. A sensitivity labelek között kell egy olyan labelt definiálni, ahol a jogosultságot vagy “any authenticated users”-re állítjuk be (ilyenkor bárki, akinek van Azure AD, vagy Microsoft-accountja, hozzá tud férni az információhoz a megfelelő jogosultsággal (pl. Viewer, vagy egyedi beállításokkal, hogy ne tudjon a dokumentumból copyzni, printelni)

Természetsen beállíthatunk guestekre vonatkozó labeleket is:

A fenti labelt alkalmazva az Office-dokumentumokra, majd elküldve pl. emailben a külsős partnernek, meglesz a megfelelő adat- és tartalomvédelem.

Evvel az Azure AD guest + sensitivity label párossal megfelelő biztonság mellett tudjuk biztosítani a Teams és filemegosztási együttműködést.

Miért ne féljünk a password hash szinkronizálástól?

A Microsoft Detection and Response Team (DART) csapat tollából született egy remek cikk, https://www.microsoft.com/security/blog/2019/05/30/demystifying-password-hash-sync/

Ennek kapcsán szeretnék én is pár gondolatot megírni.

Ügyfelekkel történő konzultációk során, mikor szóbakerül a jelszóhash-szinkronizálás, sok esetben a teljes megdöbbenés és elutasítás a reakció:

“nem szeretném, hogy a Microsoft hozzáférjen az összes földi AD-jelszavamhoz”

“szigorúan tilos, hogy jelszóinformációk elhagyják a belső hálózatot”

“küzdjön csak meg az NSA a jelszavaimért, nem adom neki az MS-en kereszül tálcán” (ez remélem, irónia volt, nem mertem visszakérdezni…)

Először is, nézzük, hogyan a fenti aggodalmak miért nem valósak, és hogyan történik ez a hash-kezelés:

  • Az AzureAD Connect kliens a domain controllertől kapott jelszóhash-t átalakítja egy 32 bájtos hexadecimális karakterré
  • utána egy binárissá alakítja UTF-16 kódolással
  • a kapott értéket megsózza (salt) további 10 bájttal
  • az így kapott eredményt pedig 1000 alkalommal újrahash-eli HMAC-SHA256 kódolással
  • a végeredményt pedig a tenanthoz dedikált Service Bus juttatja el az AzureAD-ba (TLS kapcsolaton keresztül)

Ez a folyamat valószínűleg már mindenkinek megnyugató 🙂

Továbbmenve, paradox módon hangozhat, de nagyobb biztonságot tudok elérni a felhő felé nyitással (azaz a password hash szinkronizálással), mintha teljesen bezárkóznék mindenféle földi védelmi rendszere mögé! Szembemegy a gondolat a régi beidegződésekkel,igaz? 🙂

Mire gondolok itt?

Ha engedélyezzük a password hash szinkronizálást, igénybevehetünk robosztus felhő alapú, gép intelligenicára támaszkodó szolgáltatásokat, mint például az Azure AD Identity Protection. Dióhéjban, evvel a szolgáltatással nagyon erősen védhető az userek identitása, kaphatok riasztásokat, ha gyanús bejelentkezések történnek az accountokkal, ha kompromittálódott a felhasználói fiók (azaz az usernév/jelszó páros kiszivárgott, pl feltört adatbázisokba) és ezekhez az anolimáliákhoz automatikus akciókat is lehet rendelni (pl. gyanús felhasználói bejelentkezés esetén legyen kötelező a multifaktoros hitelesítés). Elérhetővé válik a Smart Lockout szolgáltatás, ami a jelszótörő brute-force támadásokat megállítja. Az IP lockout service, ami észleli az ún. password spray-attack támadásokat és blokkolja azokat, miközben a valódi felhasználó továbbra is gond nélkül be tud jelentkezni a hálózatba.

Mondanom sem kell, ilyenhez hasonló földi védelmi rendszer ára (hardverek, licenszköltségek, speciális szoftverek) a csillagos égig érhet.

Összefoglalva: használjuk bátran a password hash szinkronizálás szolgáltatást, a kockázatot nem növeljük vele, és elérhető lesz sok magas szintű felhős védelmi megoldás.

Egy cybertámadás forgatókönyve

Az alábbi cikkemben szeretném kötetlenebb stílusban bemutatni, hogyan zajlik egy célzott phishing cybertámadás. A levezetés mellett bemutatom azokat a Microsoft 365 / Azure szolgáltatásokat is, amikkel ezek a támadások lefülelhetők/megállíthatók.

Képzeletbeli támadónk, legyen a neve Mr. X, szeretne bejutni a Riprop Kft céges IT-rendszerébe, hogy onnan értékes adatokat szerezzen meg észrevétlenül. Célja tehát a rejtőzködés, nem a károkozás, így nem is gondolkodik romboló technikákban. A Riprop Kft egy “felhős” cég, a földi infrasruktúrája mellett M365-öt használ.

Mr. X, miután egyszerű script-kiddie megoldásokkal leellenőrizte hogy kívülről nem tud bejutni a hálózatba, másik támadási vektort keresett. Azt már megtanulta, hogy az emberi tényező (mulasztás, hiszékenység) a legtöbb sikerrel kecsegtető lehetőség, így a phishing mail támadás mellett döntött.

Kisméretű botnetje segítségével elkezdett leveleket küldözgetni a Riprop Kft egyes dolgozóinak. Az emailcímek formátumát ismerte (kis.jolan@riprop.com), így könnyű dolga volt. Az adathalász emailt úgy állította össze, hogy a benne lévő link egy O365 loginpage-re hasonlított, a levél tartalma pedig az volt hogy az IT Helpdesk kéri, hogy a belépésével erősítse meg az accountját.

(ennél vannak kifinomultabb támadások is, tudunk olyan esetről, ahol a támadók ismerték a titkárnő színházak iránti rajongását, ezért a kedvenc színháza formátumával preparált adathalász levelet küldtek neki…)

Lehetséges védekezés: az Office 365 Advanced Threat Protection szolgáltatás egy extra védelmi réteg az Exchange Online-ban. Segítségével az adathalász, és egyéb hamisított mailek (pl. a CEO nevében küldött, pénz átultalását utasító) kiszűrhetőek, fejlett AI alapján. Emellett képes a mailekben lévő linkek előzetes megvizsgálására és ha támadó webhelyre mutatnak, akkor letiltja az elérést a felhasználó számára. Szintén képes az emailekben érkező csatolmányok megvizsgálására, egy felhős virtualizált környezetben lefuttatására. Ha a kapott PDF file mondjuk egy preparált darab és megnyitásakor mindenféle gyanús tevékenységet végezne (powershell futtatás, http kapcsolódás egy ismeretlen IP-címhez, stb) akkor a csatolmányt letiltja, nem kézbesíti a felhasználónak.

Az alábbi képen összefoglalva a működése:

Tegyük fel, hogy ez a védelmi megoldás nem volt beállítva Riprop Kft-nál, így az adathalász mailek akadálytalanul bejuthattak. Sajnos kb. harminc dolgozó nem figyelt eléggé, és gondolkodás nélkül megadta a felhasználónevét és jelszavát a kért URL-re kattintva (közben morogva, hogy “jajj, az IT már megint akar valamit, kétnaponta küldenek maileket, azt se tudom már mit akarnak”. (ez nagyon fontos szempont IT-oldalról, hogy nem szabad “elárasztani” infókkal-változásokkal a felhasználókat, hiszen nem tisztjük ilyen mélységben követni. Teljesen jogosan, csak a munkájukat akarják végezni. Fontos tehát megtalálni az egyensúlyt az oktatás-kommunikáció-informálás között, különben a felhasználók közömbössé válnak és könnyebben esnek ilyen tévedések áldozatául)

Lehetséges védekezés: van mód az O365-be jelszó nélkül bejelentkezni. Használható az okostelefonokkal a Phone Sign-in megoldás (az O365 a név megadása után nem jelszót kér be, hanem a Microsoft Authenticator alkalmazáson megjelenít 3 számjegyet és a megfelelőt kell kiválasztani. A kiválasztás után pedig az okostelefon ujjelnyomat-azonosítása a második faktor.

Ha a Riprop Kft-nél ez a megoldást implementálták volna, a dolgozóknak feltűnik, hogy miért jelszót kér a rendszer, mikor mindig Phone SignIn-t használtak.

Szintén használható a FIDO2 biztonsági kulcs erre a célra, az USB-s hardveres kulcs végzi a hitelesítést, jelszó megadására ott sincs szükség.

Támadónk, Mr.X számára tehát megnyílt az aranybánya, volt harminc érvényes felhasználóneve és jelszava a rendszerhez. Mivel lusta volt próbálgatni egyenként a hozzáféréseket, a már meglévő botnetje segítségével kezdett el belogolni a Riprop Kft rendszerébe a megszerzett accountokkal.

Lehetséges védekezés: Az Azure AD Identity Protection szolgáltatás monitorozza a felhasználói belépéseket, szokásokat. Az ezektől eltérő jelenségekre (pl. bejelentkezés ismeretlen országból (ahol a felhasználó nem járt az elmúlt fél évben), lehetetlen utazás megvalósulása (több belépés rövid idő alatt, pl. pár perc eltéréssel Moszkva és Madrid), belépés TOR-hálózatból, vagy botnet-tag számítógépről) azonnal reagál. Az észlelt anomáliákhoz akciókat is tud hozzárendelni, pl. ismeretlen helyről belépés esetén kényszeríti az MFA hitelesítés végrehajtását, vagy kompromittálódott account esetén azonnal letiltja azt és csak a helpdesk oldhatja fel.

(Kompromittálódott accountok: azok, amiknek kiszivárgott a név/jelszó párosa, és megtalálhatóak mindenféle adatbázisokban. Nem titok, a Microsoft elég sok pénzt és energiát áldoz rá, hogy jelen legyen a “darkweben” is, ahol az ilyen adatbázisok megtalálhatók. Ha talál egyezést, az adatbáziban szerepel a név/jelszó páros, azonnal tudja értesíteni az Azure AD-t, aki a fenti módon letiltja az accountot.

Sajnos mivel a Riprop Kft-nél ez a megoldás sem volt implementálva, nem tűnt fel senkinek, hogy tömegesen jelentkeznek be a felhasználók adataival, különböző országokból.

A baj megtörtént, támadónk bejutott a rendszerbe. Volt néhány alapszintű (tehát admin privilégiumokkal nem rendelkező) accountja, amivel szabadon tudott mozogni a hálózaton. A további lépések ilyenkor a támadó részéről:

  • felmérni, milyen szenzitív (admin jogkörrel bíró) accountok vannak a hálózatban (ezt hívják Reconnaissance-nak)
  • megpróbálni hozzáférést szerezni a szenzitív accountokhoz (lateral movement)
  • végül átvenni az uralmat a rendszer felett, admin jogosultságokkal megbújni a rendszerben (domain dominance)

Mr. X tehát különböző felderítési technikákat alkalmazva (ldap lekérdezések, stb) eljut odáig, hogy van a hálózatban egy Terminal Server, amihez van működő accountja is, ráadásul a TS-en futó régi számlázóprogram miatt local admin jogosultsággal. Ide belépve felfedezi, hogy bizony a helyi IT hibázott és konfigurációs hiba miatt a víruskereső nem működik. Innentől felgyorsulnak az események:

Mivel admin joga van, rögtön látja, hogy még a domain adminok is ide lépnek be, sőt, van éppen bejelentkezett admin. Különféle programok segítségével (pl. Mimikatz) képes kinyerni a TS memóriájából a domain admin jelszóhash-t! Ne felejtsük el, a vírusirtó nem működik a gépen, tehát bármilyen malware jellegű programot lefuttathat.

A megszerzett hash-hel továbbhalad a központi SQL szerver felé, és a domain admint megszemélyesítve bejut az adatbázisszerverre. Ujjgyakorlatként még a domain controllerre is ellátogat, ahol kiállít magának a örök lejáratú kerberos ticketet, így bármelyik szerveren tud már mozogni. Itt a vége, csapda bezárult, a domain dominance megvalósult. Mr. X uralja a hálózatot, az SQL szerverről csendben készít adatbázis dumpokat és http segítségével tölti fel őket a saját rendszerébe. A történésekről nem tud senki, Mr. X hónapokig rejtőzhet a hálózatban (az átlagidő, a bejutásról a felfedezésig, 180 nap körül van, azaz a támadók gyakran fél évig is garázdálkodhatnak a rendszerben, mire felfedezik őket).

Lehetséges védekezés: az Azure ATP segítségével a fenti folyamatok egyenként detektálhatók (Reconnaissance-Lateral Movement-Domain Dominance), így az adminoknak azonnal van módjuk a támadást megakadályozni. A támadónak időre van szüksége, amíg a felderítést stb végrehajtja, ez sokszor több hét is lehet, így van idő a támadás kifejlődése előtt megállítani azt.

Az Azure ATP a domain controllerekre telepített szenzorok segítségével elemzik a hálózati forgalmat és azonnal riasztást küldenek különféle támadási észlelések esetén. Az alábbi táblázat mutat pár észlelési típust, de ez folyamatosan fejlődik, és felhős technológia révén, folyamatosan frissül is.

Kiegészítő védekezés: többszintű jogosultsági rendszer kialakítása. Külön accountok admin feladatokra, “sima” usernek sose legyen admin szerepköre. Admin accountokkal csak védett gépekre lehessen bejelentkezni, többfaktoros hitelesítéssel (pl. security key vagy virtual smart card)

Mint a fenti forgatókönyv is mutatja, a támadás könnyen megvalósítható, a fenyegetés nagy. A cikkben leírt védelmi megoldások viszont nagyrészt megtalálhatóak az O365/M365 előfizetésekben, csak elő kell őket venni a polcról és beüzemelni. Egy ilyen kiépített rendszerrel, a támadás kb az első lépésnél (phishing mailek megérkezése) elhalt volna.