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)

• https://autologon.microsoftazuread-sso.com
• https://aadg.windows.net.nsatc.net

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.

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.

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

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