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.

1 thought on “Password hash sync vagy pass-through authentication – összehasonlítás

  1. Pingback: Seamless SSO – cseréljük a Kerberos kulcsot | Zoltan Istvanffy's IT Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s