Synchronizace AD do Azure Active Directory: password hash scénář
V minulém díle jsme prošli základní možnosti synchronizace vašeho Active Directory s Azure Active Directory. Dnes si ukážeme detailně první možnost – synchronizaci password hash. Je to řešení bezpečné, jednoduché a vaše cloudové prostředí není závislé na dostupnosti on-premises.
Rekapitulace jak to funguje
Připomeňme si jak to funguje. V první řadě potřebujeme dostat informace o účtech (a případně další atributy a skupiny) do Azure Active Directory. Tady si uvědomme, že AAD tenant je plochý prostor. Nepodporuje OU a účty jsou tak v jednom jmenném prostoru. Schválně jsem neřekl v jedné doméně, protože AAD má vždy minimálně jednu (to je ta něco.onmicrosoft.com) a k tomu klidně desítky či stovky vašich vlastních domén (aktuální limit je 900).
To ale nestačí na ověření uživatele. K tomu potřebujeme nějakou identifikaci, v našem případě heslo. To je v klasickém AD uloženo ve formě MD4 hash, takže uvnitř není ve viditelné podobě a k té se tak nedostane ani administrátor. Při synchronizaci password hash z AD do AAD se použije šifrované spojení a protokol velmi podobný synchronizaci dvou AD. V Azure Active Directory se ale hash neuloží jak je (MD4), protože pro cloud mají zákazníci obvykle ještě vyšší nároky na bezpečnost, než u on-premises systémů. Proto AAD k MD4 přidá salt (to vstřikuje do výsledku náhodu a dále znesnadňuje pokusy o odhalení) a následně provede 1000x po sobě SHA256 hash. Teprve tento výsledek se uloží – úroveň bezpečnosti je tedy extrémně vysoká. Zatímco běžné atributy se mezi AD a AAD synchronizují méně často (zhruba do 30 minut), password hash se synchronizují každé 2 minuty. Proces je ve skutečnosti o něco složitější, ale pro naší úroveň detailu to takhle stačí – víc najdete tady: /en-us/azure/active-directory/connect/active-directory-aadconnectsync-implement-password-hash-synchronization
Minule jsem také popisoval, že sychronizace AD a AAD s password hash synchronizací nám zajistila stejný login v místním AD i AAD tenantu, ale ne SSO tak, jak jste z on-premises zvyklí. Uživatel, který je přihlášen doménovým účtem ve Windows už obvykle nezadává login do aplikací (využije se integrovaná autentizace). Aby tohle zůstalo zachováno i vůči aplikacím pracujícím s AAD, můžete zapnout Seamless SSO. Funguje to tak, že přihlašovací stránka si očuchá schopnosti klienta (typ browseru apod.) a pokud to jde, nechá si u AAD vygenerovat challange, kterou pak Javascript kód v browseru klienta zpracuje. Obrátí se na AD a využije speciálního computer accountu přes který provede přihlášení uživatele. Výsledkem bude ověření, podepsání challange a informace půjde z browseru do AAD, že uživatel se úspěšně přihlásil. AAD potom pokračuje dál, tedy vystaví aplikační tokeny a tak dále. Je to bezpečné a pro uživatele velmi pohodlné.
Instalace krok za krokem
V Azure jsem si vytvořil AAD tenanta. Dále potřebuji testovací prostředí – simulaci on-premises. Připravil jsem ARM šablonu včetně DSC skriptů tak, aby bylo možné celé prostředí sestavit automatizovaně během hodiny. Jde o ARM, který vytvoří AD s doménovým řadičem a provede jeho instalaci i založení testovacích uživatelů. Následně provede deployment dalšího Windows stroje a zařadí ho do domény (jeden testovací počítač) a druhého, který v doméně nebude (druhý testovací počítač). Najdete je zde: https://github.com/tkubica12/aad-demos
Začnu tím, že svému AAD tenantu přiřadím svojí custom doménu. Musím prokázat její vlastnictví založením DNS záznamů.