FIDO2 - přihlašování bez hesla i v lokální Active Directory - II. část

V tomto článku navážeme na předchozí díl FIDO2 - přihlašování bez hesla i v lokální Active Directory - I. část, kde jsme detailně rozebírali kapitoly Co je FIDO2, Proč chceme FIDO2, Kerberos, SSO, jak to celé funguje, Výběr tokenů, Co potřebujeme v cloudu a Co potřebujeme v AD DS

Nyní pojďme dál.

Jak to vidí uživatel

Registrace klíče

Máme nastaveno, náš testovací uživatel má svůj zbrusu nový klíč a může začít testovat.

Malá nástraha čeká v nastavení na straně uživatele. Spojení uživatelského účtu a klíče neprobíhá přímo ve Windows – tam lze prakticky nastavit pouze PIN k FIDO2 klíči.

Nejdůležitější krok očekává uživatele na adrese https://mysignins.microsoft.com/, kde ke stávajícím metodám přihlašování přidá (registruje) nový FIDO2 bezpečnostní klíč.

Pokud registraci bude provádět na podporovaném Windows 10 zařízení, operační systém to rozpozná a provede mnoho dalších důležitých operací automaticky na pozadí.

Všechny operace s FIDO2 klíčem jsou chráněny PINem, registrace nového klíče samozřejmě není výjimkou.

Uživatel se také vždy musí dotknout tlačítka na klíči – to je pro mallware prakticky nepřekročitelná bariéra.

Protože klíčů je samozřejmě vhodné mít ke každému účtu zaregistrováno více, je dobrý nápad je vhodně pojmenovat. To se hodí např. při ztrátě nebo výměně klíče a nutnosti jeho odebrání z konfigurace.

Přihlašování

Konečně, pojďme spolu s uživatelem vyzkoušet přihlášení! Protože jsme v GPO umožnili přihlašování pomocí bezpečnostního klíče, uživatel v přihlašovacím dialogu uvidí novou ikonu s obrázkem USB klíče.

Humor: Za pár let bude takový obrázek asi stejně vypovídající, jako ten podivný čtvereček na ikoně „Uložit“

Klíč je vložen, zbývá zadat PIN…

… a dotknout se klíče.

Hello! Vítej uživateli!

Přihlášení uživatele pohledem administrátora

Ihned po přihlášení má uživatel standardní výbavu Kerberos tiketů, dle očekávání.

Pokud by se něco nepodařilo, detaily můžeme dohledat v logu „WebAuthN“ přímo na stanici.

Údržba a rutiny

Účty počítačů si v pravidelných intervalech mění hesla. My už máme v souvislosti s Azure Active Directory (AAD) v našem místním Active Directory (AD DS) typicky dva objekty, které jsou z pohledu bezpečnosti kritické, a přitom jsou jejich hesla statická.

• AZUREADSSOACC – ten se používá pro Azure Active Directory Seamless Single Sign-On
• AzureADKerberos – náš nový objekt RODC.

Podobně jako je vhodné pravidelně měnit heslo standardního účtu KRBGT, je důrazně doporučováno pravidelně měnit také hesla těchto účtů, ideálně jednou měsíčně.

Taková měsíční údržba pak může zahrnovat například aktualizaci AAD Connect serveru, kontrolu stavu replikace, řešení případných konfliktů a samozřejmě nastavení nových hesel pro výše uvedené účty.

Pozn.: Je velmi důležité nespouštět resety hesel dvakrát za sebou. Pokud (například při pokusu o automatizaci) provedete reset příliš brzy, celý systém ověřování přestane fungovat.

Omezení a trable

Ne všechny uživatelské scénáře jsou momentálně podporovány, při standardním používání by ale běžní koncoví uživatelé neměli být zásadně omezováni.

Omezení, se kterými musíte počítat, jsou především:

• Přístupy na RDP, VDI nebo Citrix nejsou podporovány.
• Používání S/MIME není podporováno.
• Spouštění programů jako jiný uživatel (Run as) nelze použít.
• Přihlašování k serverům prozatím není podporováno.
• Přihlašování lokálních administrátorů prozatím není podporováno, je ale plánováno již při uvedení do GA (general Availability).
• Ve srovnání se smart kartami s digitálními certifikáty není tento způsob vyloženě univerzální. Jsme odkázáni na registraci klíce na zařízení, resp. stanici.
• Přihlášení bezpečnostním klíčem nelze jednoduše vynutit. Pokud uživatel heslo zná, vždy jej může použít. Nicméně, pokud uživatel heslo nezná (např. zde), nebo pokud je minimální délka hesla nastavena na 50+ znaků, stane se bezpečnostní klíč jeho oblíbenou přihlašovací metodou.
• Při přihlašování k AzureAD nebo M365 službám na webu je uživateli nabízen kompletní seznam účtů, ke kterým je klíč asociován. To bohužel neplatí při přihlašování do Windows 10 tak, jak jsme si jej dnes popsali. Systém použije naposledy registrovaný účet, který jsme s klíčem na tomto zařízení propojili.

Přihlášení klíčem ve webovém prohlížeči:

Stejný klíč použitý pro přihlášení k Windows 10:

Závěr

Přihlašování k Active Directory pomocí FIDO2 klíčů ještě není zcela ideální pro všechny scénáře používání. S postupnou adopcí Azure AD se ale bude dále vyvíjet a bude si nacházet cestu do dalších společností

Dnes jsem úmyslně nepřidával žádné konkrétní příkazy nebo skripty, spíše jsem se snažil naznačit cestu, na kterou se můžete vydat při zabezpečování firemního prostředí AAD/AD DS. Hlavní část konfigurace můžete mít připravenu za jedno odpoledne, přesto je dobré vědět předem, co můžeme od řešení očekávat. Dva obrázky někdy vydají za dvacet stan dokumentace, snad i vám dnešní a minulá téměř komiksová sada pomůže při implementaci nebo alespoň v orientaci v dnešních širokých možnostech integrace cloudových služeb do lokální infrastruktury.

Pokud vás přihlašování s pomocí FIDO2 klíčů nadchlo stejně jako mě, pokračujte rovnou k oficiální dokumentaci na stránkách společnosti Microsoft.

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises

https://docs.microsoft.com/cs-cz/azure/active-directory/authentication/concept-authentication-passwordless#fido2-security-keys