Pokud chcete využívat cloudové služby Microsoftu jako je Office 365 nebo Azure, potřebujete Azure Active Directory. O něj můžete opřít i vaše aplikace s využitím moderních metod přihlašování a získat celou řadu nadstavbových vlastností v oblasti bezpečnosti (například Azure Identity Protection), řízení přístupů (conditional access, Priviledged Identity Management), správy stavu koncových zařízení (InTune), napojení na partnery (B2B) či zákazníky (B2C). Jak napojit vaše standardní Active Directory do cloudového světa Azure Active Directory, který získáváte jako vysoce dostupnou platformní službu?
Obrovské množství zákazníků využívá AD pro svou vnitřní síť a odtud řeší uživatelské účty, skupiny, práva, přístupy do aplikací nebo doménové politiky stanic. Klíčové ale je, že AD využívá protokoly, které jsou od základu vymyšlené pro lokální síť jako je Kerberos apod. Co když potřebujete ověřit uživatele z domova či kavárny k aplikaci, když nějaké privátní spojení neexistuje (mobilní telefon) nebo je kostrbaté (VPN z PC)? Nebo co když potřebujete aplikaci integrovat s identitami vašeho obchodního partnera? Nebo řídit oprávnění, například umožňit uživatelům schválit přístup k některým informacím o sobě aplikaci třetí strany? Nebo co když chcete hotovu mutli-tenantní aplikaci třetí strany jako služba (SaaS) a potřebujete přistupovat svými identitami, ale logicky nechcete svoje hesla předat SaaS providerovi?
Tyto problémy se nejprve řešily použítím federačních protokolů typu SAML a WS-Federation, ale ani to nepokrývá všechny dnešní potřeby zejména s ohledem na autorizaci. Moderní aplikace dnes využívají OAuth 2.0 pro autorizaci a Open ID Connect jako nadstavbu pro řešení autentizace. Pokud máte Live ID Microsoftu, účet na Google, Facebooku, tak to z praxe velmi dobře znáte. Můžete se takovým účtem přihlásit k jiné službě a to velmi bezpečně, aniž by tato služba získala přístup k vašemu heslu. Klasická Active Directory tyto služby postupně přidávala v roli Active Directory Federation Services (ADFS), které přes SAML a WS-Federation doiterovalo až do podpory moderních protokolů typu OAuth 2.0.
AAD je cloudová as a service identita a je od základu postavena na claim-based autentizaci, zejména Open ID Connect a OAuth 2.0 (a další). Nativně nepodporuje protokoly lokální sítě (nicméně existuje managed služba AAD DS, která to v omezené míře může pro vaše VM v Azure nabídnout - ale o tom jindy). Je zaměřena na cloudové scénáře - moderní aplikace, SaaS a postupně se objevují i snahy některé klasické metody z privátní sítě nabízet i s modernější podobou (například Windows 10 dnes umí join do AAD a SQL umí pro přihlašování uživatelů použít AAD).
Hlavní síla AAD kromě faktu, že je as a service (takže neřešíte patchování, HA či backupy), je v nadstavbách. Základní AAD Free je dost dobré na to, abyste s ním řešili synchronizaci s AD, přihlašování do aplikací a vychytávky moderních claim-based systémů. Placené verze AAD ale přináší výhody nad tím. Například v oblasti bezpečnosti (AAD Identity Protection, vícefaktorové ověření, InTune), provozních záležitostech a governance (self-service, write-back, Privileged Identity Management), možnostech přizpůsobení rozhranní vašim potřebám i systém pro správu účtů pro vaše zákazníky (B2C).
Využívejte AAD. V dalších článcích se zaměřím na zprovoznění moderních forem autentizace a různé scénáře jako jsou webové aplikace, autorizace, ověření mezi mikroslužbami a on-behalf-of flow a tak podobně. Ale dnes pojďme na synchronizaci AD s AAD.
Cloudový svět a moderní aplikace namíříte na AAD, ale interní uživatele máte se všemi výhodami v on-premises Active Directory po mnoho let a dává to velký smysl. Co tedy prakticky každý zákazník hledá je integrace AD s AAD.
U všech budete potřebovat synchronizovat uživatelské účty, atributy (s možností různých filtrací) jako jsou telefon či adresa nebo skupiny, podle kterých pak můžete chtít řešit autorizaci (třeba role-based-access-control v Azure portálu). Na to je software AAD Connect (zdarma). Další otázka je, jak zajistit ověření uživatele, tedy ověření jeho hesla. Tady máte tři možnosti.
Velmi jednoduchá a elegantní cesta do AAD je využít password hash synchronizaci, tedy do AAD se dostane kopie vaší AD identity. Nemusíte se bát, že by se vaše hesla dostaly mimo kontrolu nebo si je zaměstnanci Microsoftu četli. Žádná plain-text hesla se do AAD nedostanou. Synchronizace využívá prakticky stejného mechanismu, jako AD replikace, ale s větším důrazem na bezpečnost. Při synchronizaci tedy necestuje žádné heslo, ale MD4 hash hesla tak, jak je uložena v AD s tím, že ani ta MD4 není vidět "na drátu" (samotná MD4 je pro účely přenosu dále šifrována). Pro AAD ale chce Microsoft ukládat hesla ještě bezpečněji, než v AD s MD4. Při synchronizaci tedy neuloží MD4 jak ho dostane z AD, ale aplikuje na něj salt a velmi dobrou HMAC-SHA256 hash. Aby toho nebylo málo, tak výsledek vezme a aplikuje HMAC znova. A pak znova. Celkem 1000x. Výsledná hash je tedy extrémně silná. Při každém ověření se samozřejmě proces zopakuje (nejdřív MD4 a pak 1000x HMAC-SHA256) a výsledek porovná.
Je tu ale jedna věc. Pokud se připojujete z telefonu nebo počítače v kavárně, je jasné, že poté co zadáte URL aplikace budete přesměrováni na přihlášení, kam zadáte jméno a heslo (případně se aplikují další věci jako je Azure Multi Factor Authentication). Jenže u stroje, který máte uvnitř firmy, který je v doméně a kde jste přihlášeni doménovým účtem předpokládáte, že aplikace využívají klasickou Windows-integrated autentizaci (Kerberos) a na hesla se neptají. V tomto případě k tomu ale dojde (ale ne nutně pokaždé - můžete kliknout na "keep me signed" což počet dotazů na heslo minimalizuje). Pokud vám to vadí, můžete nasadit Seamless SSO. To je geniální finta. Přihlašovací stránka AAD má v sobě Javascript kód, který se spustí ve vašem browseru, přihlásí se vůči lokálnímu AD Kerberos protokolem a bezpečně AAD řekne, jak to dopadlo. AAD následně ví, že jste přihlášeni a může pokračovat logováním do aplikace. Jak to funguje si ukážeme příště. Pokud se to z nějakého důvodu nepovede (nepodporovaný prohlížeč apod.), nevadí - systém sám přepne do zobrazení logovací stránky.
Tato varianta tedy elegantně řeší synchronizaci, nevyžaduje žádnou speciální složitou infrastrukturu a AAD není závislé na AD. Jinak řečeno pokud vám vypadne spojení do AD, cloudové aplikace stále fungují! To považuji za zásadní výhodu. I přesto je možné díky Seamless SSO uživatele neobtěžovat přihlašováním navíc. Negativem je, že pokud deaktivujete účet pouze v AD a ne v AAD, může trvat až 30 minut, než ta informace doputuje do cloudu (interval synchronizace). Druhým "negativem" je, že to bezpečáky neseznámené s mechanismem fungováním může (zbytečně) děsit.
Jsou situace, kdy vaši bezpečáci odmítnou synchronizace hash do cloudu. Často je to spíše nepochopení a když prozkoumají jak hash synchronizace funguje, dost možná námitky zaniknou. Možná ale máte nad sebou regulační úřad nebo zahraničního vlastníka, kteří nejsou tak chápaví, jako vy. Požadavek na to, že ani hash nesmí opustit on-premises tu zkrátka být může. Řešením může být pass-throw autentizace. AAD Connect nasynchronizuje uživatelské účty (a atributy a skupiny dle vašeho zadání), ale žádné hash hesel. AAD a AD si vytvoří velmi zabezpečený TLS kanál (včetně automatické rotace klíčů) a při přihlášení do AAD vám toto zobrazí login stránku a údaje z ní poskytne vašemu AD tímto šifrovaným kanálem a ověření hesla proběhne u vás. Stejně jako u předchozího příkladu je možné v tomto scénáři použít trik se Seamless SSO pro maximální uživatelský komfort.
Toto řešení rovněž nevyžaduje nějakou složitou infrastrukturu navíc a lze ho napojit na další AAD vychytávky jako je vícefaktorové ověření z Azure. To, že hesla zůstávají v on-premises má výhody a nevýhody. Dobré je, že pokud zneplatníte uživatele, bude to s okamžitou platností u vás i v cloudu. Nemáte hash v cloudu, což možná pomůže překonat některé politické překážky. Na druhou stranu váš svět cloudových aplikací je závislý na spojení do on-premises. Vypadne linka, vypadne i cloud.
Pokud ještě nemáte žádné řešení implmenetované, doporučuji ADFS až jako poslední volbu z důvodu vysoké komplexity a nákladnosti. Na něco takového potřebujete nainstalovat ADFS role, ADFS proxy a to vše ve vysoké dostupnosti. Vše je potřeba správně nastavit a starat se o to. ADFS umožňuje dost z toho, co nabízí nadstavby v AAD - podmíněné přístupy (ale AAD už je dnes dál), podpora vícefaktorového ověření (ale u AAD je to daleko snadnější) a tak podobně. Možná už máte celou tu práci za sebou a třeba jste investovali i do zaintegrování různých dalších řešení, třeba vícefaktoru třetí strany a dává smysl infrastrukturu využít i v souvislosti s napojením do AAD. V takovém scénáři je tedy AAD federováno s ADFS a potažmo AD a login tak může podléhat tomu, co je implementováno v ADFS. Protože jde o skutečnou federaci je Single Sign On nativní vlastností celého scénáře.
Výhody vidím dvě. Jednak využijete stávající investice v podobě peněz i potu do ADFS infrastruktury a její integrace různých řešení a za druhé můžete docílit scénářů, které s AAD zatím nejsou možné. Tak například AAD krásně podporue Azure MFA jako druhý faktor (a ten umí např. SMS kód, telefonát, appku), ale ne například hardwarové OTP generátory.
Nevýhodou je zásadně větší komplexita (víc komponent, ADFS proxy do DMZ apod.) a nároky na zdroje (více serverů). Současně také platí, že je cloud nefunkční bez vaší infrastruktury, což vzhledem k tomu, že dnes je cloud bezpečnější a dostupnější, než průměrná on-premises infrastruktura, považuji za riskantní. Faktem je, že jsem viděl zákazníky, kteří to řeší vybudováním ADFS infrastruktury i v Azure. Ale to je ještě složitější a ještě nákladnější, nicméně pokud na ADFS potřebujete stát tak jako tak, proč ne.
Azure Active Directory je úžasný produkt a moderní autentizace/autorizace krásné téma. Na tomto blogu se podíváme na integraci aplikací a jak toho využít, nejdřív si ale krok za krokem ukážeme synchronizaci AD s AAD. Hned příště vyzkoušíme password hash synchronizaci. Těmito kroky obvykle začíná vaše cesta do cloudu a moderních identitních systémů - ať už jde o Azure nebo Office 365.