Azure AD CBA – konečně i s vlastními certifikáty

Z této novinky mám nepříjemně smíšené pocity. Jednak jde o jeden z posledních milníků lemujících cestu našeho zamilovaného AD FS do zapomnění, a jednak se jedná o skvělou funkci umožňující zásadní zvýšení zabezpečení i komfortu ověřování uživatelů M365 a Azure AD.

Ověřování pomocí certifikátů není pro Azure AD úplná novinka, pokud jste ale chtěli používat vlastní certifikační autoritu pro ověřování koncových uživatelů, museli jste až do nedávna stále využívat služeb Active Directory Federation Services (AD FS). S přihlédnutím k nedávným útokům a kompromitovaným certifikátům federačních služeb, to však pro mnohé mohla být cesta z bláta do louže. Provozovat AD FS opravdu bezpečně a s vysokou dostupností opravdu není žádná legrace a pocit bezpečí (vždyť přece používáme certifikáty) mohl být často lehce zavádějící a neoprávněný.

Z předchozího úvodu je asi patrné s čím si dnes budeme hrát – ověřování administrátorů a uživatelů do Azure AD s využitím vlastních X.509 certifikátů konečně dorazilo do Public Preview! Pracovně i oficiálně budeme používat zkratku CBA – Certificate-Based Authentication.

Co budeme potřebovat

• Vlastní certifikační autoritu, která již patrně roky vystavuje uživatelům certifikáty pro přihlašování k Wi-Fi nebo VPN.
• CRL dostupné z internetu. Pokud tuto konfiguraci pominete, ověřování sice může fungovat, ale logickým požadavkem bude možnost využívat odvolání platnosti certifikátů (revokace) k omezení přístupu k AAD.
• Licenci – nepotřebujeme J Ověřování certifikátem je k dispozici pro všechny uživatele Azure AD (tedy i pro free licence).

Co nás může omezit

• Pokud používáte Alternate ID (například emailovou adresu místo UPN), pak CBA prozatím používat nemůžete.
• Pokud používáte více cest CDP, pro ověřování musíte použít pouze jedinou HTTP cestu. LDAP nebo OCSP využít nelze vůbec.
• Velikost CRL je omezena na 20 MB, přičemž musí být poskytnuto do 10 sekund. Ověřuje se však pouze CRL vystavující autority, CRL nadřazených autorit se neověřují.
• Nelze použít další omezení např. pomocí OID nebo na základě hodnot dalších atributů.

S čím je potřeba počítat

• Aktivací CBA prozatím nedojde k zablokování nebo potlačení možnosti přihlašování uživatelským jménem a heslem. Zda uživatel heslo vůbec zná, nebo zda budeme hesla do AAD synchronizovat je pak jedno z dalších souvisejících rozhodnutí.
• Uživatel musí při přihlášení vybrat správný certifikát. Pokud jich má ve svém úložišti více, budou zobrazeny všechny, což může být v některých scénářích méně komfortní.
• CRL jsou načítány do mezipaměti, při potenciálním blokování přístupu uživatele je vhodné nejen revokovat jeho certifikáty, ale také jeho existující sessions v Azure AD.

• V sign-in logu bude v polích „user“ a „username“ zobrazeno „User ID“. Není to komfortní, ale dá se s tím žít.

  

Jak budeme postupovat

1. Upload certifikátů: Zdůvěryhodníme naši interní PKI nahráním certifikátů RootCA a případných dalších CA do tenantu;
2. Vazby ověřování: Volitelně přepneme režim ověřování z jedno-faktorového na MFA;
3. Vazby uživatelů: Nastavíme mapování uživatelských jmen, pokud je potřeba;
4. Povolení CBA.

Upload certifikátů

Připravíme si certifikáty našich certifikačních autorit a URL pro seznam odvolaných certifikátů (CRL) vystavující CA. V rámci testování můžete kontrolu CRL dočasně deaktivovat, ale v produkci ji rozhodně potřebovat budeme.

Pokud je potřeba, aktualizujeme si PowerShell modul pro Azure AAD alespoň na verzi 2.0.0.33 (Install-Module -Name AzureAD –RequiredVersion 2.0.0.33) a připojíme se k našemu tenantu (Connect-AzureAD).

Postupně nahrajeme všechny certifikáty našich interních certifikačních autorit:

$cert=Get-Content -Encoding byte "Cesta_k_certifikatu.cer"

$new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation

$new_ca.AuthorityType=0 #0 pro RootCA, 1 pro IntermediateCA

$new_ca.TrustedCertificate=$cert

$new_ca.crlDistributionPoint="http://cesta_k_crl"

New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca

Výsledek a kontrola bude vypadat nějak takto:

Vazby ověřování

Nyní je potřeba rozhodnout, jak moc důvěřujeme naší CA a nastaveným procesům. Pokud využíváme čipové karty a máme jistotu, že certifikáty jsou vždy chráněny pinem, můžeme nastavit ověřování certifikátem rovnou jako multifaktorové ověřování.

Pokud ale certifikáty vystavujeme uživatelům automaticky, jsou exportovatelné, jsou využívány v osobních zařízeních a podobně – pak bude lepší ponechat výchozí nastavení, kdy se ověření certifikátem považuje za jednofaktorové ověření.

Dokonce je možné definovat pravidla, podle kterých se různé certifikáty budou vyhodnocovat odlišně. Certifikáty lze rozlišovat podle vystavující CA nebo dokonce podle jednotlivých OID v různých typech certifikátů a podle ne/splnění podmínek definovat „sílu ověření“.

Vazby uživatelů

V ideální konfiguraci mají uživatelé stejné UPN v lokální AD jako v Azure AD, a stejně tak mají UPN ve svých certifikátech. Nemusí tomu tak být vždy, a možná budete potřebovat výchozí mapování (Principal Name v certifikátu à onPremisesUserPrincipalName v AAD) upravit. Pracovat můžete s atributy UPN a RFC822Name (tedy emailová adresa) v těchto kombinacích:

SAN Principal Name à userPrincipalName

SAN Principal Name à onPremisesUserPrincipalName

SAN RFC822Name à userPrincipalName

SAN RFC822Name à onPremisesUserPrincipalName

Přednost mají hodnoty v SAN (Subject Alternative Name), ale k dispozici je i fallback na legacy Subject Name (tedy například E=uzivatel@kpcs.cz), vazby můžete také přesouvat a definovat tak jejich priority.

Podstatné je, ab byl v AAD vždy nalezen právě jeden uživatel, jinak ověření nebude úspěšné. Stejně tak se vazba s nižší prioritou využije pouze v případech, kdy první definovaný atribut v certifikátu není vůbec přítomen. Nenalezení odpovídajícího uživatele v tenantu není důvodem pro vyhledávání podle další vazby v pořadí (!).

Povolení CBA uživatelům

Tento krok jste pravděpodobně nastavili již na začátku, takže pro kontrolu – CBA povolíme pro všechny, nebo pro vybrané skupiny uživatelů. Po aktivaci může nějakou dobu trvat, než bude ověřování k dispozici.

Poznámka: Odkaz pro přihlášení certifikátem bude zobrazován všem uživatelům bez ohledu na to, zda mají CBA povoleno.

Jak to vidí uživatel

Uživatelé s povoleným CBA budou mít po několika minutách k dispozici další možnost přihlášení – přihlásit se certifikátem.

Po výběru této volby uživatel vybere správný certifikát pro přihlášení. Pro Windows a Android zařízení by nemělo být potřeba nastavovat nic dalšího, pro iOS bude patrně nutné mít v zařízení již instalován kompletní sadu certifikátů CA, jinak ověřování certifikátem může končit chybou.

A to je vlastně vše. Pokud je potřeba projít MFA ověřováním, uživatel je standardně vyzván pro potvrzení přihlášení, pokud jste nastavili CBA na úroveň MFA, uživatel může rovnou začít pracovat.

Ověřování CBA považuji za obrovský přínos a krok kupředu, rozhodně jej alespoň vyzkoušejte! Velmi dobře zpracovanou dokumentaci najdete jako vždy na stránkách https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-certificate-based-authentication

PS: Na našem blogu často píšeme také o možnostech používání FIDO2 hardwarových klíčů pro ověřování uživatelů. Nezanevřete na ně, jedná se stále o jednu z nejbezpečnějších metod přihlašování. Některé klíče dokonce disponují sloty pro digitální certifikáty. USB token pak může sloužit zároveň pro FIDO2 i CBA ověřování, a přitom se certifikáty uživatele netoulají na ploše nebo jako přílohy v osobních emailových schránkách.