Password hash sync vagy pass-through authentication – összehasonlítás

Előző cikkemben (https://istvanffyzoltan.com/2020/12/15/office-365-federacio-megszuntetese/) bemutattam, hogyan lehet ADFS-ről átállni password hash sync authentikációra (PHS) az O365 esetén.

Szintén említettem értintőlegesen, hogy létezik a pass-through authentikációs megoldás is (PTA)

Felmerülhet a kérdés, hogy melyiket érdemes választani, mik az előnyeik és hátrányaik? Ezeket igyekeztem összeszedni a cikkben (feltételezve, hogy van földi környezet és az AD Connecten keresztül megtörtént a címtár szinkronizáció)

Password hash sync

A PHS esetén a földi AD-jelszavak módosított hash-jét szinkronizáljuk fel az Azure AD-ba, és a hitelesítés ott történik meg, a tárolt hash-ek alapján.

A folyamat az alábbi ábrán látható:

Hogyan jutnak fel a jelszó hash-ek az Azure AD-be?

  • Az Azure AD Connect kliens kétpercenként lekéri a domain controllerektől a jelszóhash-eket
  • A kliens a 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)

Látható, hogy a folyamat egészen biztonságos. Az esetleges aggodalmak eloszlatása érdekében leszögezendő:

  • A PHS sosem synceli az aktuális jelszót.
  • A jelszó plain-text változata soha nem kerül ki a Microsofthoz.
  • Az eredeti MD4 jelszóhash soha nem szinkronizálódik közvetlenül; csak ennek a hashnek a fenti módon leírt, újrahash-elt változata kerül az Azure AD-ba.
  • Ha megszereznék az Azure AD-ban tárolt hash-t, azt nem lehet felhasználni a földi környezetben (pl. pass-the-hash támadással)

Milyen előnyei vannak a PHS-nek?

  • A felhős erőforrásokhoz való hitelesítés az Azure AD-ban történik.
  • Az AD Connect-en kívül nem igényel semmilyen földi komponenst.
  • A Microsoft biztosítja a DDOS és password spray támadások elleni védelmet.
  • Brute-force támadás elleni védelem: alapértelmezésben 10 hibás belépési kísérlet után 1 percre blokkol.
  • Password Protection: nem enged gyenge vagy tiltott jelszavakat beállítani jelszócsere esetén (pl. password123), evvel is védve az identitást. További infó: https://istvanffyzoltan.com/2020/02/01/azuread-password-protection/
  • IP-lockout: figyeli a belépésekhez használt IP-címeket, és ahonnan túl sok hibás kísérlet érkezik, azt ideiglenesen blokkolja, a valódi felhasználók a helyes jelszóval továbbra is hozzáférnek a szolgáltatásokhoz.
  • Leaked Credential Service: a Microsoft figyeli az ellopott felhasználónév/jelszó párosokat (darkweben) és figyelmeztet vagy tilt, ha a jelszó “közkézen” forog. Ez utóbbihoz szükséges az Azure AD P2 licensz.

Milyen hátrányai vannak a PHS-nek?

  • Az O365-ben a jelszólejáratot “never expire” állítja, azaz soha nem jár le. Ez sok szervezet szabályozása alapján nem megfelelő.
  • Ha a földi AD-ben lejár a jelszó, az O365-ben nem fog, tehát a felhasználó továbbra is be tud lépni.
  • A felhasználó letiltása / lockolása esetén a változás nem jut azonnal érvényre, csak a 30 percenkénti szinkronizálási ciklus után (azaz hiába disabled / locked az user account a földi környezetben, az O365-ba be tud lépni)

Pass-through authentication

PTA hitelesítés esetén a validálás a földi domain controllereken történik meg. Kis túlzással hívhatjuk lightweight-ADFS megoldásnak is.

A működése a következő:

  • Az user szeretne belépni az pl. Office portalra
  • Az Azure AD leküldi a kérést az on-prem környezetben futó PTA agenthez
  • A földi DC hitelesítése után az Azure AD visszakapja a hozzáférést és megtörténik a hitelesítés

PTA agentből bármennyit telepíthetünk a földi környezetünkbe, evvel is biztosítva a redundanciát. Az agent esetleges hibája esetén az authentikáció továbblép a következőre. A működéshez nem szükséges külső elérés (azaz tűzfalon portnyitás befelé, NAT, stb), az agent az outbound 443-as porton kommunikál az Azure AD-vel.

Az alábbi környezetben 7 PTA agent került telepítése, fizikai és virtuális szerverekre egyaránt, biztosítva a magas rendelkezésreállást.

Könnyen belátható, hogy ez jóval rugalmasabb a nagytestvér ADFS-nél.

Milyen előnyei vannak a PTA-nak?

  • Az authentikációt a “földön” tartjuk, azaz a domain controllereink végzik a hitelesítést
  • A jelszóhash-ek nem kerülnek az Azure AD-ba
  • A felhasználókon végzett műveletek (jelszólejárat, letiltás, lockolás) azonnal érvényre jutnak
  • A szervezetnek nagyobb a kontrollja a hitelesítés felett
  • Brute-force támadások elleni védelem, mint a PHS-nál
  • Támogatja az Azure AD Conditional Accesst, többfaktoros hitelesítést és legacy authentication szűrését
  • Könnyű high-availability kialakítás (több agent telepítésével)
  • Az agentek nem igényelnek karbantartást; automatikusan frissülnek

Milyen hátrányai vannak a PTA-nak?

  • Nem támogatja a Leaked Credentials szolgáltatást
  • Szükséges a földi környezetbe agentek telepítése
  • A földi AD elérhetetlensége esetén a felhős szolgáltatásokba történő hitelesítés meghiúsul
  • Régi kliensek (pl. Office 2010) nem biztos hogy jól működnek PTA-val

Lehet váltani a PTA és PHS között?

Igen! Az AD Connect kliensben bármikor megváltoztathatjuk, hogy PTA vagy PHS hitelesítést szeretnénk használni. Ez jól jöhet olyan katasztrófa esetén, ha pl. az összes PTA agentünk elérhetetlen: át tudunk váltani PHS hitelesítésre.

Az AD Connectben állítsuk át a kívánt hitelesítési módot:

Összefoglalás

Ahogy látjuk, mindkét megoldás vannak előnyei és hátrányai; szervezettől függ, hogy milyen szabályozás alapján választ. Ha cél a földi infrastruktúra és komplexitás csökkentése, válasszuk a PHS authentikációt. Ha szorosabb a szabályozás és több kontrollt szeretnénk, a PTA hitelesítés lehet a megfelelő. A kettő között váltás bármikor megejthető, így marad mozgástér a kísérletezéshez is.

Office 365 federáció megszüntetése

Ahol ADFS-t használnak az O365 federációra, ott érdemes elgondolkodni az alternatívákon,ugyanis az O365 felé történő authentikációs workloadot le tudjuk venni az ADFS farmunkról. Abban az esetben, ha csak emiatt tartottuk az ADFS-t, akkor le is lehet állítani, és spórolni a céges erőforrásokon (farm fenntartás, üzemeltetés, patchelés, rendelkezésre állás, hálózat, biztonsági megoldások stb. biztosítása).

A federáción kívül két lehetőségünk van az O365 felé történő hitelesítésre:

  • Password hash sync: ebben az esetben a földi AD-ben tárolt jelszóhash-ek szinkronizálódnak az AzureAD-be, és a hitelesítés ott is történik meg.
  • Pass-through authentication: a hitelesítés a földi AD-ben történik, telepített agentek segítségével.

A password hash sync esetén nincs szükségünk semmilyen földi infrastruktúrára, viszont a földi domainben beállított jelszópolicy/user lock/ user disabled események nem jutnak rögtön érvényre.

A pass-through authentikáció esetén az O365 portal kéri be a hitelesítő adatokat és validáltatja a földi környezetbe telepített PTA-agentek segítségével.

A mostani cikkben az egyszerűbb, password hash sync-re (továbiakkban PHS) való áttérést taglalom.

Magyarázat:

federated domain: ahol ADFS-t használunk a hitelesítésre

managed domain: ahol PHS vagy PTA segítségével authentikálunk.

A cél, hogy a federated domaint managed domainre kapcsoljuk.

Attől függően, hogy kezdetben hogy állítottuk be az ADFS-t, kétféle lehetőségünk van:

  • Azure AD Connect segítségével: ha a federációt az AD Connect segítségével állítottuk be, akkor a PHS-re áttérést kötelezően ott kell megtennünk. Ez a háttérben a Set-MsolDomainAuthentication paranccsal az összes federált domaint átállítja.
  • Azure AD Connect és Power Shell beállítással: csak akkor használjuk ezt az opciót, ha az ADFS-t nem az AD Connecten keresztül állítottuk be. A különbség annyi az előzőhöz képest, hogy nem futtatja automatikusan a Set-MsolDomainAuthentication parancsot, tehát később kézzel tudjuk megszabni, hogy melyik domaint konvertálnánk át.

Nézzük az első opciót, tehát ha az ADFS konfigurációt az AD Connectben tettük meg:

Első lépésként engedélyezzük az AD Connectben a password hash syncet. Ha lennének félelmeink a PHS-val kapcsolatban, itt egy részletes magyarázó cikk a működéséről: https://istvanffyzoltan.com/2020/07/12/miert-ne-feljunk-a-password-hash-szinkronizalastol/

TLDR: nem szinkronizálja a közvetlen jelszavunkat 🙂

Tehát, kapcsoljuk be a PHS syncet, ha még nem tettük volna meg:

Várjuk meg, amíg a sync végigmegy (30-60 percet)

Logokat lehet ellenőrizni:

  • Event Viewer and application logs
  • Azure AD Connect wizard troubleshooting task

Ahhoz hogy a domain-joined gépeken is menjen az SSO, a következő URL-eket adjuk hozzá az Intranet zónához GPO-val: (a GPO-ban az érték legyen 1)

Következő lépésben állítsuk be a PHS-t és engedélyezzük az SSO-t:

Az Azure portalon látni fogjuk, hogy eltűnt a Federation

Második opció, ha az ADFS-t nem az AD Connecten belül állítotuk be:

Itt is fontos, hogy előtte legyen beállítva a password hash sync, különben a federáció leváltásakor minden felhasználó különálló, új jelszót kap, ami komoly gondokat okozhat!

Ha működik a PHS, akkor lépjünk be az ADFS szerverünkre és futtassuk le az alábbi parancsokat admin powershellből:

install-module msonline

import-module msonline

connect-msolservice (adjuk meg a global admin account adatait)

végül kérdezzük le a federated / managed domainek listáját:

get-msoldomain

Futtasuk le a következő parancsot, megadva az ADFS szerverünk belső FQDN-jét:

Set-MsolADFSContext -Computer <ADFS FQDN>

Végül konvertáljuk át a federált domaineket managed-be:

Convert-MsolDomainToStandard -DomainName yourdomain.com -SkipUserConversion:$true -PasswordFile C:\userpasswords.txt

A SkipUserConversion értékre nagyon figyeljünk, feltétlenül legyen True az értéke, különben új jelszavakat generál az usereknek! A PasswordFile ettől függetlenül kötelező elem, adjunk meg egy érvényes útvonalat a txt filenak.

Egy újabb get-msoldomain paranccsal látjuk, hogy nincs federated domain immár:

Végül pedig állítsuk be a PHS-t:

Set-MsolDomainAuthentication -Authentication Managed -DomainName yourdomain.com

Ezt ellenőrizhetjük később az AD Connect felületén is. A teljes átváltáshoz várjunk 2-3 órát, addig előfordulhatnak login anomáliák, így ezt a műveletet érdemes munkaidőn kívül elvégezni.

Tesztelés:

Navigáljunk el a https://portal.office.com oldalra. A felhasználónév megadása után, a régi, federated scenárió esetén kaptunk egy redirectet az ADFS oldalra:

A federáció megszűntetése után viszont már az O365 portal kéri be a jelszavunkat:

Összefoglalás: ha csak az O365 miatt van ADFS szerverünk, akkor érdemes migrálni a PHS / PTA megoldások egyikére, jelentős erőforrásfogyasztás és hibalehetőséget tudunk elkerülni.

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.

Adathalászat ellen- Company Branding

Az adathalászat az egyik legnépszerűbb kísérlet, amivel megpróbálnak céges accountokhoz (felhasználónév és jelszó páros) hozzájutni. Ennek egy tipikus formája, mikor O365 login portalt hamisítanak, és várják hogy valaki gyanútlanul beírja a név/jelszó párost.

Ebben tud segíteni az Azure AD és a Company Branding funkció. Segítségével az O365 login portal testreszabható, céges logóval, egyéb vizuális beállításokkal. A felhasználókat pedig oktatni kell, hogy csak a céges logóval ellátott portalon jelentkezzenek be.

(Megjegyzés: ha ADFS-t használunk hitelesítésre, akkor természetesen nem ezt a portált fogjuk látni, hanem a kiszolgálóét, amit szintén érdemes “brandelni”)

Nézzük, hogy néz ki, ha alapesetben az O365 portal:

Ez egy elég általános felület, könnyű hamisítani. Cseréljük le hát az alapportált egy céges design-ra:

Navigáljunk el az Azure AD portalon a Company Branding részhez:

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/LoginTenantBranding

A Defaultnál pedig töltsünk fel logót, háttérképet:

Ezt követően a felhasználóink ezt a portalt látják:

Látszik a céglogó és a háttér, jelezve, hogy ez a valódi O365 portal.

Természetesen ez is hamisítható, de ahhoz már elég célzottan kell a támadóknak előkészülni. A Company Branding beállítástól függetlenül, a felhasználókat időszakos securiy awareness tréningek keretében emlékeztetni kell, hogy ne kattintsanak gyanús linkekre, inkább mindig kézzel írják a böngészőbe a https://portal.office.com címet és úgy végezzék el a bejelentkezést.

Remote Desktop Gateway és Azure MFA integráció

Az RD Gateway elég régóta létező komponens, segítségével megoldható a belső hálózaton található gépek RDP elérése, biztonságosan (TCP 443-as porton keresztül)

A pandémiás helyzet miatt sok cégnek kapóra jöhet ez a megoldás. Jön az igény: a céges PC-met el kellene érnem az otthoni gépemről, mintha azon dolgoznék. Lehetőleg biztosítva az identitásellenőrzést is, azaz a név/jelszó pároson kívül legyen többfaktoros hitelesítés is.

Lássuk, hogyan lehet ezt egy meglévő RD Gateway és Azure MFA-val megoldani! (Az RD Gateway telepítés-konfigurálás lépéseket a cikk nem tartalmazza)

Előfeltételek:

  • Azure MFA licensz a felhasználónak, Authenticator konfigurálva push notification módra
  • Földi Active Directory integrációja az Azure AD-val (dirsync)
  • Remote Desktop Gateway konfigurálva és elérhető az internet felől (pl. tsgw.corp.com címen)
  • Földi Network Policy and Access szerepkör telepítve

Azure AD tenant ID beszerzése

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview linken kiolvashatjuk a tenant id-t. Ezt mentsük el a későbbi használat miatt.

Azure NPS Extension telepítése

Az NPS szerverre telepíteni kell az Azure MFA extensiont. Vigyázat! A telepítés után minden authentikációs kérést az Azure felé fog küldeni, ezért feltétlenül fontos, hogy külön NPS szervert használjunk. Ellenkező esetben a wifihez/vpn-hez használt NPS-t működésképtelenné teheti.

Töltsük le az extensiont és teleptsük fel:

https://www.microsoft.com/en-us/download/details.aspx?id=54688

Telepítés után konfiguráció következik. Admin powershellből navigáljunk a “c:\Program Files\Microsoft\AzureMfa\Config” folderbe és indítsuk el az .\AzureMfaNpsExtnConfigSetup.ps1 scriptet.

Majd a felugró ablakban jelentkezzünk be Global Adminként

A script bekéri majd a Tenant ID-t, ezt másoljuk be és nyomjunk Entert:

Connection authorization policy beállítása központi használatra

Remote Desktop connection authorization policies (RD CAPs) szükségesek az RD Gateway-hez kapcsolódáshoz. Alapértelmezetten ezek a policy lokálisan vannak tárolva, de ez esetben át kell állítani központi RD CAP Store-ra.

Nyissuk meg az RD Gateway szerveren a Remote Desktop Gateway Managert. Jobb klikk a szerver nevén, Properties, RD CAP Store és a Central Server running NPS résznél vegyük fel a kívánt NPS nevét vagy IP-jét

Adjunk meg egy erős, hosszú shared secretet és mentsük el a későbbi használathoz.

RADIUS Timeout átállítása

A RADIUS timeout értékét át kell állítani az alapértelmezettről, hogy a felhasználónak legyen ideje a kétfaktoros hitelesítést végrehajtani.

Ehhez az RD Gateway szerveren indítsuk el a Network Policy Server konzolt, majd menjünk a Radius Clients/Remote Radius Server részre. Nyissuk meg a TS Gateway Server Groupot. Itt megjelenik az általunk beállított radius szerver, kattintsunk az Edit…-re. A Load Balancing tabon látunk két értéket:

Number of seconds without response before request is considered dropped

Number of seconds between requests when server is identified as unavailable

Ezek értékét állítsuk át 60-ra

Connection Request Policy ellenőrzése

Az RD Gateway-en nyissuk meg a Network Policy Server konzolt, keressük meg a Policies / Connection Request Policies részt. Kattintsunk duplán a TS GATEWAY AUTHORIZATION POLICY-re, majd Settings és végül Authentication. Győződjünk meg róla, hogy a kérések biztosan a távoli NPS szerverre mennek:

NPS konfiguráció

Az NPS szerveren, ahol telepítettük az MFA Extsensiont, nyissuk meg az NPS konzolt, és adjunk hozzá RADIUS klienst:

A new radius client ablakban adjuk meg az RD Gateway nevét és IP/DNS nevét, illetve írjuk be a korábban elmentett Shared Secretet:

Network Policy konfiguráció

Az NPS szerveren indítsuk el az NPS konzolt, nyissuk ki a Policies ágat és válasszuk a Network Policies részt. Kattintsunk jobb klikkel a “Connections to other access servers” policyre és válasszuk a “Duplicate policy” opciót:

Nevezzük át a policyt, kapcsoljuk be a “Policy enabled” részt és válasszuk a “Grant access opciót:

Kattintsunk át a “Constraints” fülre és pipáljuk be az “Allow clients to connect without negotiating an authentication” method opciót:

Mentsük el a policyt, majd győződjünk meg róla, hogy engedélyezve van és a lista elején áll:

Csatlakozás RDP klienssel

Miután végeztünk minden konfigurációs beállítással, teszteljünk. Indítsuk el az RDP klienst és csatlakozzunk egy belső géphez a szokásos beállításokkal:

Ha mindent jól csináltunk, a telefonon meg kell jelennie az Authenticatior üzenetnek, ahol a belépést jóváhagyhatjuk:

Hibakeresés, logok ellenőrzése

Probléma esetén segítségül hívhatjuk az eventlogot. Az RD Gateway szerveren nyissuk meg az Event Viewert és navigáljunk el Network Policy and Access Services custom nézethez:

Összefoglalás: az RD Gateway kényelmes és hasznos megoldás, amit az Azure MFA Extensionnal biztonságosabbá is tehetünk.

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.