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: https://docs.microsoft.com/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ů.
Na mém klasickém AD doménovém řadiči mám doménu, uživatele a skupiny.
Stáhnu si AAD Connect a spustím instalaci. Budu chtít custom nastavení.
Zvolím password hash synchronizaci a povolím Seamless SSO.
Pro synchronizaci přidám svojí doménu tomaskubica.cz, ale pokud chcete, může tu mít třeba celý svůj forest.
AAD Connect bude potřebovat ve vaší doméně účet s příslušným oprávněním. Nechceme mu dávat větší práva, než je potřeba (takže ne enterprise admin), tak využiji možnost, aby pro mě instalátor ideální účet založil.
Máme připojeno.
Nastavíme co se má v AAD objevit jako uživatelské jméno. Já použiji UPN, protože to v základu umožní jednoduché SSO apod. Nicméně pokud je u vás situace složitější, je fajn mít další možnosti.
Možná z celého forestu chcete jen některé domény nebo z domény jen některé organizační jednotky (OU). Pak to tady nastavte, ale já beru všechno.
Pokud máte jednoho uživatele přítomného hned v několika vašich doménách (pozůstatek akvizic apod.), dá se to řešit, ale potřebujete AAD Connectu říct, podle jakého atributu to má poznat. Můj případ to není. Dále si AAD vytvoří vlastní atribut sloužící jako jednoznačný identifikátor. Pokud to chcete jinak, dá se tu nastavit.
Chcete všechny uživatele? Já nepotřebuji různé účty tiskáren a také mám třeba hromadu účtu s historickým kontextem, které v cloudu nikdy potřebovat nebudu. Já jsem si například vytvořil skupinu cloudusers (moje ARM šablona vám to připraví) a v té jsou ti, které chci synchronizovat.
Zatím jsme používali pouze funkce, které jsou součástí AAD Free. Nicméně s AAD se dá v prémiových verzích dělat daleko víc (ale o tom jindy) - jednou z možností je povolit proces pro resetování uživatelského hesla samoobslužně přes AAD a na to musí mít AAD schopnost synchronizovat heslo i v opačném směru.
Máme hotovo, frčíme.
AAD Connect je pod kapotou mocnější, než co nabízí instalátor. Například možnosti filtrací jsou hodně bohaté, takže i složité případy můžete dobře zvládnout.
Proces synchronizace můžete sledovat.
Po nějaké době v AAD uvidíme naše uživatele.
A také naše skupiny.
Vyzkoušíme si
Připojte se do Windows mimo doménu a otevřete prohlížeč. Zatím nemáme cloudovou aplikaci, tak si to namíříme rovnou na autentizační službu na adrese login.microsoftonline.com
Výborně. Zadáme i heslo.
A jsme tam! Funguje to.
Přesuňme se na počítač, který v doméně je.
Aby fungovalo Seamless SSO, musíme určité služby přidat do sekce intranetu (dát práva jim spouštět SSO logovací skripty). To se dá samozřejmě poslat do stanic i přes GPO.
Dobrá tedy. Pojďme na login.microsoftonline.com. Jsme dotázáni na uživatelské jméno.
Ale následně to po nás heslo nechce! Na pozadí proběhlo Seamless SSO. Protože jsem zalogován do stroje v doméně, nemusím ho zadávat.
Hmm, ale to že musím zadávat jméno je možná trochu nepohodlné. To lze vyřešit aplikačně s využitím domain a/nebo login hintů. V zásadě v rámci URL vaší aplikace napojené na AAD můžete jako atribut předat právě třeba uživatelské jméno. Pokud si ho takhle uložím jako uživatel do záložek, nemusím jméno zadávat (a heslo taky ne - od toho mám SSO). Na login.microsoftonline.com to nezkoušejte, to je už přihlašovací server. Nicméně dobrým příkladem aplikace, která využívá ověřování vůči AAD je Azure portál. Do prohlížeče tedy zadáme:
https://portal.azure.com/tomaskubica.cz?login_hint=aduser01@tomaskubica.cz
A je to - rovnou se dostanete do portálu. Jméno se zjistilo z hintu a přihlášení z SSO. Pohodlné a příjemné.
Tak vidíte - ekosystém cloudových řešení Microsoft je postaven na AAD a synchronizace s AD je snadná, spolehlivá, bezpečná a funkčně bohatá. Ať si vyberete Azure, Office 365, Dynamics 365 či Intune (nebo rovnou všechno), napojte si vaše AD na AAD tenanta. Příště se podíváme na scénáře, kdy hash není synchronizována a ověřování jde zpět do AD v on-premises buď přes AAD Connect nebo ADFS.