1 Úvod
V seriálu se budeme věnovat technologii Active Directory Federation Services. Články budou vycházet jednou měsíčně a v prvním díle se seznámíme s terminologií ADFS. Budeme se držet terminologie společnosti Microsoft, v závorce pak terminologie Shibboleth).
2 Teoretický základ
Active Directory Federation Services je implementace protokolu WS-Federation Passive Requestor Profile protokolu (Passive znamená, že požadavky klienta jsou cookie - popis zde) od společnosti Microsoft do služby, poskytující sdílení informací o identitách mezi důvěryhodnými partnery přes nedůvěryhodné sítě (extranet, Internet atd.). ADFS ke komunikaci využívá protokol HTTP a HTTPS na portech 80, 443. Informace se vyměňují přes Security Assertion Markup Language (SAML).
Smyslem ADFS je umožnit identitě z organizace A přistoupit ke zdrojům z organizace B bez nutnosti vytvářet pro identitu A další identitu v organizaci B. ADFS zajišťuje autentizaci a autorizaci identity v organizaci B tím, že požadavek na autentizaci a autorizaci pošle do organizace A, kde se požadavek vyhodnotí a do organizace B putuje Claim, který v sobě obsahuje potřebné údaje o tom, zda identita A může ke zdrojům v organizaci B přistoupit. Identita A se tedy autentizuje a autorizuje ve své domácí organizaci A, ADFS pak zajistí vystavení a bezpečný přesun Claimu do organizace B, kde se Claim použije.
3 Terminologie
V této kapitole si vysvětlíme jednotlivé termíny, abychom je mohli následně použít v dalších dílech seriálu o ADFS.
SAML – Security Markup Assertion Language – je otevřený datový formát, založený na XML, který zaštiťuje OASIS (odkaz na OASIS), pro výměnu informací o autentizaci a autorizaci mezi organizacemi. Technicky jde o výměnu informací mezi Identity providerem a Service providerem (viz dále). SAML je jedna z možností, jak zajistit Web Single Sign On (Web SSO), další možností je například OpenID nebo Shibboleth, které v tomto seriálu nebudeme popisovat. Popisu SAML je na internetu k nalezení spousta. My budeme potřebovat následující:
SAML definuje 3 komponenty:
XML dokument posílaný přes Federation request popisující identitu
Autentizace – ověřuje uživatelovu identitu
Autorizace – identifikuje, k čemu má uživatel mandát
Claims (*Atributes) – obsahuje specifické informace o identitě, které jsou posílány uvnitř Security tokenu
Definuje, přes jaký protokol se vyměňují SAML zprávy
SAML pracuje mimo jiné s protokoly SMTP, HTTP, FTP, EbXML a dalšími
Claims provider (*Identity provider) – je služba, která komunikuje se Service providerem za použití SAML a předává Claimy uživateli nebo aplikaci (Principal nebo Identita). Jako příklad Identity Provider je možné si představit ADFS ve vaší organizaci. Identity provider může požadovat další údaje pro Principal (Identity), například uživatelské jméno a heslo.
Relaying party (*Service provider)– Service provider je endpoint, se kterým identita komunikuje a vůči kterému se autorizuje a autentizuje. Service provider požaduje Security assertion (Claim) od Identity providera. Jako příklad Service providera uvedeme Office 365.
Claims (*Attributes)– Je sada informací o identitě, které jsou posílány v Security Tokenu
Federation Metadata– je sada OPTIONAL atributů, která je generovaná na základě konfigurace ADFS a rozšiřuje stávající SAML 2.0.
Příklad Federation Metadata.xml
Account partner organization – je reprezentovaná Claims provider trustem v lokálním ADFS. Je to například AD, ve kterém se nachází identity, které budou přistupovat do aplikace, nebo ke zdrojům Resource partner organizace
Account federation server – Je federation server (např. ADFS) v Account partner organizaci. Tento server vystavuje Security tokeny pro identity na základě autentizace. Server autentizuje uživatele, ze zdroje autentizace načte relevantní atributy, členství ve skupinách a zabalí tyto informace do Claimů. V dalším kroku vygeneruje a podepíše Security token a vrátí jej uživateli. Uživatel následně může Security token poslat do Resource partner organizace.
Resource partner organization – je organizace federačního partnera, která je v lokálním federačním serveru reprezentovaná jako Relaying party trust. Resource partner organization vystavuje Claimy, které obsahují seznam aplikací, ke kterým může uživatel z Resource partner organizace přistupovat.
Resource federaton server– je federační server v Resource partner organizaci. Resource federation server vystavuje Security tokeny uživatelům na základě Security tokenů vystavených Account federation serverem. Resource federation server příjme Security token, ověří jeho podpis, aplikuje pravidla pro přijaté Claimy (například převod UPN na Email adresu atd.) a následně vygeneruje nový Security token, který přepošle uživateli.
Relaying Party Trust– Jsou definované vztahy důvěry, skládají se z řady identifikátorů, pravidel a jmen, které identigikují partnerskou organizaci nebo webovou aplikaci vůči lokálnímu ADFS.
Jako příklad Relaying Party Trustu je možné uvést Microsoft Office 365 Identity Platform.
Příklad URL pro Federation Metadata URL v rámci Relaying party Trustu pro Office 365
Příklad Relaying Party Trust pro Office 365 – 1/ WS-Federation Passive URL, 2/ Federation Metadata URL
Relaying Party Trusty slouží:
V Account partner organization – reprezentuje organizaci ve vztahu důvěry jako organizaci, jejíž identity budou přistupovat ke zdrojům v Resource partner organizaci
V Resource partner organizaci – reprezentuje vztah důvěry (trust) mezi Federation Service a Web aplikací
Claims Provider Trust – je vztah důvěry mezi Federation Service v Resource partner organization, kde reprezentuje organizaci, ze které se budou autentizovat identity, které mají přistupovat do Resource partner organizace.
Token Signing Certificate– Certifikát jehož privátní klíč podepisuje Security tokeny
Token Decrypting Certificate – Certifikát pro dekryptování claimů vystavených partnerskými Federation servisy.
Service Communication Certificate – Důvěryhodný certifikát pro servisní komunikaci ADFS serverů.
V další části seriálu si popíšeme, základy ADFS, jak ADFS funguje a uvedeme příklady použití.
1 Úvod
V první části seriálu o ADFS jsme se věnovali terminologii, kterou budeme potřebovat znát, abychom mohli správně pochopit jak ADFS funguje. V této části si povíme, jak ADFS pracuje na příkladu autentizace do Office 365.
2 Teoretický základ
Představme si bezpečnostní entitu, kterou tvoří naše organizace, kterou reprezentuje Active Directory forest. V rámci AD forestu jsme za pomoci IWA (Integrated Windows Authentication – sada protokolů implementovaných v OS Windows 2000+) zajistit Single Sign On.
IWA rovněž poskytuje detaily o uživateli (např. členství ve skupinách).
2.1 Přístup z internetu
Pokud potřebujeme přistoupit k bezpečnostní entitě z internetu a nemáme k dispozici například Direct Access, VPN nebo autentizační proxy, Kerberos nebude fungovat
(nelze vystavit token bez přístupu uživatele k doméně). Je tedy potřeba řešit jiné modely autentizace.
2.2 Přístup partnerských organizací
Nenavážeme-li s partnerskou organizací trust, nezbyde nám bez ADFS jiná možnost, než udržovat pro partnerskou organizaci stínové kopie jejich účtů, kterým přiřadíme patřičná oprávnění. Kromě vyšších administrátorských nároků na správce se můžeme setkat nejen s bezpečnostním rizikem přístupů cizích uživatelů do námi spravované organizace, ale také s dalšími problémy (nekonzistence databáze uživatelských účtů atd.)
Elegantním řešením je ADFS, které poskytuje výhody spojené se Single Sign On a zároveň umožňuje přístup k patřičným zdrojům na základě vydaného důvěryhodného Security Tokenu. Od ADFS máme tyto požadavky:
Vytvořit jednotnou autentizační soustavu, která je nezávislá na umístění aplikací
Sestavit Security Token tak, aby mohl obsahovat více informací, ne jen členství ve skupinách a uživatelské jméno
Věřit, že partnerská organizace správně autentizuje své uživatele
Podpora webových prohlížečů a industry standard protokolů
3 Jak ADFS funguje
Funkci ADFS si popíšeme za pomocí následujícího obrázku.
Diagram funkce ADFS
1) Uživatel se snaží přihlásit do Office 365 pomocí UPN, kde doméná UPN suffixu je provázána s Office 365. V Office 365 je vytvořen Claims Provider Trust
Přihlášení do Office 365
2) Probíhá nalezení správného Claims Providera (Pro nefederované domény se autentizujeme vůči Azure AD, pro federované jdeme na krok 3)
3) Pomocí Claims Provider Trustu je do uživatelského prohlížeče poslán požadavek s přesměrováním na veřejnou IP adresu našeho Claims Providera (ADFS serveru z internetu dostupný přes WAP Proxy, odpovídá na zabezpečeném portu 443, který je navíc chráněný Service Communication certifikátem). Relaying Party je v Account Federation Serveru reprezentována jako Relaying Party Trust.
Přesměrování na Claims Providera
4) WEB prohlížeč je přesměrován na Claims Providera (Service Communication Certificate). Claims Provider přijímá požadavek na autentizaci
Přijetí požadavku na autentizaci ADFS serverem
5) Komunikace s uživatelem, kdy je potřeba, aby uživatel zadal uživatelské jméno a heslo, nebo byl v rámci IWA rovnou autentizován
6) V rámci autentizace Claims Provider komunikuje s Account Partner Organization (což je v našem případě lokální Active Directory)
Potvrzení autentizace tokenu
7) Claims Providerobdrží informace o uživateli, které dále zpracuje. Mezi informacemi mohou být další údaje, jako členství ve skupinách a další atributy, které ADFS převede do claimů. Claimy se dále mohou přeposlat v Security Tokenu.
8) Claims Provider vystaví Security Token. Security Token v sobě bude obsahovat Claimy, bude podepsán privátním klíčem Token Signing Certifikátu a bude zakódován veřejným klíčem Token Decrypting Certifikátu z Office 365 STS. Token vystaví uživateli.
Potvrzení vystavení tokenu
Výpis vložených claimů
9) Uživatelský prohlížeč přepošle Security Token do Office 365
10) Office 365 vystaví za pomocí Resource Federation Serveru token na základě security tokenu z bodu 8, který uživateli garantuje přístup k aplikacím, ke kterým má na základě autentizace oproti Account Partner Organizacipráva.
Platnost Security Tokenu je možné nastavit přes Powershell
Set-ADFSRelayingPartyTrust <jméno> -TokenLifeTime <minut>
V příštím díle seriálu si povíme, jak nainstalovat ADFS servery a jak provádět základní management.
ADFS (3) – Instalace ADFS
1 Úvod
V minulém díle jsme si vysvětlili, jak ADFS pracuje. V tomto díle se budeme věnovat instalaci ADFS serverů.
2 Teoretický základ
Teoretický základ shrnuje základy, které je potřeba zvážit před samotnou instalací a konfigurací ADFS v prostředí zákazníka.
2.1 Vysoká dostupnost ADFS
ADFS můžeme nainstalovat v několika scénářích a variantách, jejichž hlavní výhody a nevýhody jsou popsány v tabulce.
WAP | ADFSBE | Výhody | Nevýhody |
0 | 1 | · serverově nenáročné řešení · snadná implementace | · chybí vysoká dostupnost · nedoporučovaná varianta pro autentizaci uživatelů z jiné než podnikové sítě · není možnost preautentizace |
1 | 1 | · bezpečná varianta s možností preautentizace a výhod spojených s WAP proxy | · chybí vysoká dostupnost · potřeba DMZ |
2+ | 2+ | · nejrobustnější varianta nasazení ADFS · vysoká dostupnost řešení · bezvýpadkové restarty a patchování serverů | · potřeba DMZ · potřeba řešit Load Balancer |
Instalace ADFS je relativně snadná záležitost, je potřeba mít připravené:
· Servery v doméně pro ADFS backendy (požadavky pro ADFS)
· Servisní účet pro ADFS (https://msdn.microsoft.com/en-us/library/azure/dn528860.aspx)
o Je možné použít doménový účet, nebo gMSA (group Managed Service Account)
· Důvěryhodný certifikát třetí strany pro (service communication certificate)
· Token Signing a Token Decrypting certificate dle best practice (doporučení zde)
· DNS záznamy na servisní jméno ADFS (například ADFS.doména.suffix)
· Prostupy na firewallu port 443 a 80 z Internetu na WAP proxy a z WAP proxy na ADFS BE
· WAP proxy servery v DMZ zóně dle (plánování nasazení WAP proxy)
2.2 ADFS a SQL databáze
Podle zvoleného scénáře nasazení ADFS lze při instalaci využít buď existující SQL farmy, nebo použít Windows Internal Database (dříve SQL Express) s následujícími výhodami a nevýhodami.
· ADFS lze nainstalovat s Microsoft SQL, kdy si ADFS při instalaci vytvoří SQL databázi na již existující farmě (výhody nasazení ADFS s plnohodnotným SQL) a každý server v ADFS farmě lze použít k zápisu konfiguračních změn. Konfigurace s plným SQL je vhodná pro velké společnosti, které mají více než 100 relaying party trustů.
· ADFS s Windows Internal Database se hodí pro menší společnosti, které nepotřebují, nebo nemají možnost utilizovat plné SQL. ADFS s WID je plně funkční s omezeními viz (https://technet.microsoft.com/en-us/library/dn554248.aspx). Hlavní omezení z hlediska funkčnosti je nemožnost nastavit více než 100 relaying party trustů, z hlediska administrace pak lze provádět konfigurační změny pouze na prvním serveru nové ADFS farmy.
3 Instalace ADFS
Instalaci ADFS je potřeba rozdělit na několik kroků. ADFS se nejdříve nainstaluje na Windows Server 2012 R2 v interní síti. Funkčnost ADFS testujeme z interní sítě. Po ověření funkčnosti ADFS je možné nainstalovat WAP Proxy a vytvořit trust mezi WAP proxy a ADFS backendem. ADFS lze instalovat přes PowerShell nebo GUI.
3.1 Instalace ADFS backendu
· V prvním kroku je potřeba připravit Service Communication certifikát do Certificate Store pod účtem serveru.
· ADFS 3.0 je součástí Windows Server 2012 R2. Instaluje se přes PowerShell
· ADFS farmu konfigurujeme příkazem
· Po instalaci ADFS je potřeba server restartovat. Po restartu je potřeba ověřit funkčnost ADFS. DNS jméno ADFS.DOMAIN.COM by v tuto chvíli mělo směřovat na IP adresu load balanceru, nebo IP adresu jediného ADFS backendu. DNS jméno musí být přeložitelné i v DMZ.
· Funkčnost ADFS ověříme přes URL: https://adfsservicename.domain.suffix/adfs/ls/IDPinitiatedsignon.aspx
· Pro ADFS ve vysoké dostupnosti je možné přidat další ADFS server příkazem
· Po přidání dalšího ADFS serveru, je potřeba ověřit funkčnost. Funkčnost ověříme analogicky z předchozího postupu, ale místo ADFS.domain.com dáváme do URL FQDN nově přidaného ADFS serveru. https://ADFSBE2.domain.suffix/adfs/ls/IDPinitiatedsignon.aspx
· Aby bylo možné využít ADFS i pro jiné než http protokoly (WS-Trust, Windows Communication Foundation...), je potřeba zaregistrovat SPN záznam pro servisní účet, pod kterým ADFS běží. Tento servisní účet byl vytvořen, jako prerekvizita před instalací ADFS. SPN záznam se vytváří již při instalaci ADFS, pokud by bylo ADFS instalováno do prostředí, ve kterém se ADFS se stejnými parametry nacházelo již dříve, je možné narazit na problém se špatným nastavením SPN a tím na nefunkčnost ADFS pro některé protokoly. Ověření SPN může být provedeno příkazem
Příkaz zobrazí SPN záznam pro daný servisní účet, pokud SPN existuje.
· Přidání SPN záznamu pro servisní účet je možné příkazem
3.2 Instalace WAP Proxy
Dalším krokem je instalace WAP Proxy serveru. WAP proxy umožní využívat ADFS i pro externí klienty.
· Instalace se provádí příkazem
· Konfigurace příkazem, který bude chtít zadat uživatelské jméno a heslo lokálního administrátora na ADFS backend serverech
· Funkčnost WAP proxy je možné otestovat například otevřením https://adfsservicename.domain.suffix/adfs/ls/IDPinitiatedsignon.aspx, nebo kontrolou Event logu na ADFS proxy serveru. V Event logu musí být vidět, Event ID: 245, se zprávou, že WAP Proxy úspěšně získal informace z ADFS backendu. Tato zpráva v Event logu také dokládá, že trust mezi WAP Proxy a ADFS backendem funguje správně. Nefunkční trust mezi WAP Proxy a ADFS backendem je také nejčastější příčinou problémů s autentizací uživatelů z externích sítí.
V příštím díle si projdeme základní nastavení ADFS a WAP Proxy po instalaci.
1 Úvod
V minulém díle jsme nainstalovali ADFS servery ve scénáři 1x ADFS BE a 1x WAP proxy. V tomto díle se budeme věnovat základnímu nastavení ADFS po instalaci.
2 Teoretický základ
Kapitola shrnuje základy, které je potřeba zvážit před samotnou konfigurací ADFS v prostředí zákazníka.
Cílem základní konfigurace ADFS serverů, je
· Zabezpečení serverů proti hackerským útokům
· Nastavení serverů z pohledu administrátora tak, aby byl schopen kontrolovat a řešit případné chyby
· Nastavení ADFS serverů z pohledu klienta tak, aby nedocházelo chybám při připojování starších zařízení
2.1 Zabezpečení serverů
Zabezpečení serverů je zde zmíněno pouze pro úplnost. Velmi zkráceně je zájmem každého administrátora, mít ve spravovaném prostředí co nejlépe zabezpečené servery. Administrátor by tedy měl zvážit implementaci
· Antiviru
· Nastavení firewallu
· Security hardeningu (povolení pouze bezpečných šifrovacích protokolů a šifer, kontrola bezpečnostních děr)
· Automatických nebo řízených instalací aktualizací (například Microsoft SCCM)
· Zálohování
2.2 Nastavení pro administrátory
Počet připojených klientů ADFS ovlivňuje nejen množství ADFS serverů, které je potřeba nasadit do prostředí zákazníka, ale také nutnost změnit velikosti ukládaných Event logů. Podle definované maximální velikosti souborů event. Logů a způsobu jejich přepisu určujeme, kolik událostí je možné do souborů uložit. Každý administrátor by měl tedy zvážit, jak velkou velikost Event logů potřebuje ukládat. Do velkých společností je také možné zvážit produkty třetích stran, které se starají o Event log managment. Například SIEM.
V případě potřeby lze na ADFS zapnout diagnostické logování a výsledky poté vyhodnotit. Diagnostické logování zapínáme pouze v případě, kdy se vyskytne problém. Po vyřešení problému lze diagnostické logování vypnout. Diagnostickému logování se budeme věnovat v dalším díle seriálu o ADFS.
2.3 Server Name Indication
Server Name Indication je rozšíření protokolu TLS SSL, které umožňuje klientovi přidat hlavičku „hostname“, ke kterému se připojuje, do Client SSL HELLO zprávy. Server potom využívá SNI hlavičky k tomu, aby byl použit správný certifikát pro klienta. Hlavní výhoda SNI je použití více certifikátů pro jednu IP adresu a port. Pokud Client SSL HELLO neobsahuje SNI hlavičku, není server schopen rozlišit, který certifikát použít a provede RST spojení. Pro starší klienty je tedy potřeba zajistit možnost se autentizovat i přes to, že nepodporují SNI. Problémy s nepodporovaným SNI mohou nastat i při použití některých load balancerů (například kontrolní sondy neumí poslat Client SSL HELLO s rozšířením SNI). V další kapitole bude ADFS nastaveno tak, aby podporovalo i zařízení bez SNI.
https://blogs.msdn.microsoft.com/kaushal/2012/09/04/server-name-indication-sni-with-iis-8-windows-server-2012/
2.4 Nastavení z pohledu klienta
Klientské nastavení řeší kompatibilitu zařízení, které se připojují k ADFS (SNI), SSO z interní sítě bez zadávání hesla (IWA) a další. V tomto díle seriálu bude popsáno nastavení podpory NON-SNI a povolení IWA jako primární metody autentizace interních klientů.
3 Základní nastavení ADFS
V této kapitole bude popsáno, jaká nastavení je potřeba projít po instalaci ADFS. Úplný soupis požadavků pro technologii ADFS je k přečtení zde.
3.1 Nastavení parametrů ADFS
Nastavením parametrů ADFS, se ADFS přizpůsobuje lokálním potřebám spravovaného prostředí. K nastavení se používá dvojice PowerShell příkazů Get-ADFSProperties pro výpis konfigurace ADFS a Set-ADFSProperties k zápisu nové konfigurace. Pokud je ADFS farma konfigurovaná s WID, je potřeba změnu nastavení ADFS provádět na primárním serveru farmy. V opačném případě lze změnu provádět na kterémkoliv serveru.
Příkazem Set-ADFSProperties obvykle budou administrátoři chtít měnit délku platnosti Token Signing a Token Decrypting certifikátů, nastavení délky trustů pro ADFS Proxy a automatické obnovy Token Signing a Token Decrypting certifikátů.
I přes možnost tyto parametry měnit bude ADFS pracovat, i když parametry změněny nebudou. Detailní popis příkazu Set-ADFSProperties je zde.
3.2 Nastavení Group Policy pro servisní účty
Předpokládejme, že ADFS je nainstalované do prostředí zákazníka. ADFS pracuje až do druhého restartu serveru, kdy už služba ADFS nenaběhne. Velmi pravděpodobně se tak stalo proto, že servisní účet, pod kterým ADFS běží, již nemá právo „Log on as a service“. V případě implementace Windows Internal Database je potřeba nastavit GPO i pro servisní účet WID databáze.
Nastavení pro WID je popsáno zde. Právo „Log on as a service“ pro servisní účet lze řešit nalinkováním patřičné GPO na organizační jednotku, ve které jsou umístěny ADFS servery.
3.3 Konfigurace Server Name Indication
Pokud je potřeba podporovat NON-SNI klienty v ADFS (Problém popsán zde), je potřeba nastavit fallback certifikát pro případ, že klienti nebudou schopni poslat SNI hlavičku. Na serverech s ADFS se tedy přidává nový SSL binding 0.0.0.0:443 pro ADFS Application ID a Certificate thumbprint, použitý pro ADFS. Zda je nastaven fallback certifikát se zjišťuje přes příkaz netsh.
Výstupem je seznam jmen a IP adres s certifikáty pro daný server (všimněte si, že chybí binding 0.0.0.0:443 s patřičným certifikátem. Nebude tedy fungovat podpora NON-SNI zařízení. Tento obrázek ukazuje stav pro ADFS backend.
Zajímavější je obrázek pro WAP proxy, kde je vidět, že SNI umožňuje, provozovat více služeb na jednom serveru a jedné IP adrese. V případě ukázky je použit * certifikát. V obrázku jsou vyznačeny různé Application ID, pro ADFS a WAP proxy. Application ID pro ADFS je vždy stejné {5d89a20c-beab-4389-9447-324788eb944a}, Pro WAP Proxy potom. {f955c070-e044-456c-ac00-e9e4275b3f04}
Fallback certifikát přidáváme opět příkazem netsh.
Pro ADFS backendy:
netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint> appid={5d89a20c-beab-4389-9447-324788eb944a} |
Pro WAP proxy:
netshhttp add sslcert ipport=0.0.0.0:443 certhash=<thumbprint> appid={f955c070-e044-456c-ac00-e9e4275b3f04} |
Výsledkem je fallback certifikát pro default listener 0.0.0.0:443 a funkční autentizace NON-SNI zařízení.
Pokud nastavení provedete špatně, záznam lze odstranit pomocí netsh
netsh http delete sslcert ipport=0.0.0.0:443 |
Podrobný popis problematiky zde.
3.4 Kontrola záznamu pro Kerberos autentizaci
Správné nastavení Kerberos autentizace v ADFS je jedním z předpokladů, že bude správně pracovat Windows Integrated Autentizace. Při instalaci ADFS se vytvoří SPN záznam pro Kerberos, který je navázaný na DNS load balancované jméno, pod kterým běží ADFS. Dotaz, zda existuje SPN záznam a je navázaný na správný servisní účet. Dotaz se provádí příkazem setspn.
Setspn –q host/<dns_lb_jméno ADFS_služby> |
Výsledkem je nalezený SPN záznam na jméno služby.
Není-li SPN správně nastavený, lze nastavit opět přes příkaz setspn
Setspn –a host/<dns_lb_jméno ADFS_služby> <jméno_servisního_účtu_pro _ADFS> |
3.5 Integrated Windows Authentication jako primární metoda autentizace, SSO pro interní klienty
Integrated Windows Autentizace umožňuje uživateli z vnitřní sítě autentizaci bez zadávání uživatelského jména a hesla použitím tokenu z Windows. Aby toto nastavení fungovalo správně je potřeba ověřit, zda v ADFS je nastavena default autentizační metoda Windows Integrated Authentication a je potřeba nastavit zóny IE tak, aby load balancované jméno ADFS serveru bylo v zóně Intranet, aby v IE byla povolena IWA v neposlední řadě také správně nastavené SPN pro Kerberos (viz předchozí kapitola).
3.5.1 Nastavení primární autentizační metody pro interní klienty
Nastavení ADFS ověříme příkazem Get-AdfsGlobalAuthenticationPolicy. Výsledkem je výpis primárních autentizačních metod pro externí a interní klienty. Je-li ve výpisu WindowsAuthentication, jako primární autentizační metoda pro interní klienty, je možné přejít na nastavení zón pro IE. V opačném případě je potřeba nastavit IWA pomocí příkazu Set-AdfsGlobalAuthenticationPolicy.
3.5.2 Nastavení podporovaných klientů pro IWA
Seznam podporovaných IWA klientů lze editovat příkazem Set-ADFSProperties. Výpis aktuálně podporovaných IWA klientů je možné získat přes Get-ADFSProperties. $FormatEnumerationLimit = -1 zajišťuje vypsání neomezeně dlouhého textu do konzoly.
$FormatEnumerationLimit = -1Get-AdfsProperties | select *wia* | fl |
Výsledkem je seznam podporovaných klientů. Seznam lze upravovat, přičemž je nutné se k seznamu chovat, jako k poli string objektů (oddělovat elementy čárkou a názvy vkládat do uvozovek)
3.5.3 Nastavení local intranet zóny
Jestliže není load balancované jméno v Local Intranet zóně IE, při pokusu o autentizaci přes ADFS, je potřeba pro přihlášení zadat uživatelské jméno a heslo. V opačném případě bude uživatel rovnou vystaven token a uživatel bude přihlášen na ADFS.
S IWA vypadá výsledek bez zadání uživatelského jména a hesla dle obrázku.
Provedením nastavení z tohoto článku je ADFS připravená do produkce a pro propojení s Office 365.
V příštím díle si budeme pokračovat v nastavování ADFS, kde se zaměříme na debug logging, omezení autentizace ADFS pouze na některé uživatele a další.
1 Úvod
V minulých dílech jsme nastavili ADFS tak, aby vyhovovalo produkčnímu nasazení. V tomto díle si ukážeme další scénáře omezení přístupu autentizace přes ADFS a propojení ADFS se software třetích stran.
2 Rozšířené nastavení ADFS
2.1.1 Omezení autorizace na rozsah IP adres
ADFS umožňuje zakázat autentizaci uživatelů z definovaného rozsahu IP adres. Nastavení se opět provádí přes Client Access Policies. V tomto scénáři se zaměříme na povolení autentizace pouze uživatelů z vnitřního rozsahu IP adres (kompletní postup zde)
Ze zadání vyplývá, že bude potřeba nastavit Relaying Party Trust pro Office 365 tak, aby se podařilo autentizovat pouze uživatelům, jejichž klient se nachází ve vnitřní síti. Nastavení se provádí přes AD FS Management -> Trust Relationships -> Relaying Party Trusts (vybere se správný trust, u kterého je potřeba provést výše zmíněné omezení) -> záložka Issuance Authorization Rules
Na záložce Issuance Authorization Rules -> Add rule
Pro pravidlo se vybere Custom Rule
Po zadání zobrazovaného jména pravidla je potřeba dodat pravidlo, které definuje SAML jazykem, že IP adresy neshodující ses veřejnou IP adresou (nebo rozsahem) zákaznické sítě, způsobí vystavení claimu Deny.
Příklad: Hodnota regulárního výrazu jedné veřejné IP adresy Domény salonovi.cz je v REGEX syntaxi vytvořena následovně. Pokud potřebujeme definovat více IP adres, znak ”|” tvoří logický operátor nebo.
Pro veřejnou IP adresu SALONOVI.CZ je tedy pravidlo definováno v příkladu:
Testy přístupu do Office 365 z jiné veřejné IP adresy není možný:
Po přidání uživatele do skupiny je výsledkem:
2.1.2 Propojení ADFS se Software třetích stran
ADFS umožňuje komunikaci libovolných služeb, jež podporují SAML. Obecně platí, že je potřeba nastavit software třetí strany tak, aby byla autentizace směrována na ADFS. Na ADFS je potřeba vytvořit Relaying Party Trust, který bude přijímat požadavky na autentizaci a vystavovat patřičné claimy. Claimy se definují v Claim Rule Editoru.
V našem příkladu se zaměříme na propojení ADFS a Exchange 2016 OWA a ECP. K propojení Exchange 2016 a ADFS je potřeba
2.1.2.1 Vytvořit na ADFS manuálně Relaying party trust pro ECP a OWA
Do Relaying Party Identifiers se zadává LB adresa pro klientský přístup k OWA
Na záložce Endpoints vybíráme WS-Federation Passive Endpoints (Vybíráme passive proto, že prohlížeč je na ADFS přesměrován. Následně s autentizačním tokenem je přesměrován zpět na OWA/ECP url)
Do Claim rules zadáme dvě custom pravidla. První pravidlo vystavuje claim s primarySID.
Druhé pravidlo přidává claim s UserPrincipalName.
Vystavené claimy Exchange 2016 použije k připojení ke správnému mailboxu.
2.1.2.2 Konfigurace na Exchange 2016
Na straně Exchange nastavíme ADFS server, který bude používán k autentizaci uživatelů, URI, pro která se bude ADFS autentizace používat a certifikát, použitý pro ADFS.
Povolíme autentizaci ADFS a zakážeme ostatní ve virtuálních adresářích ECP a OWA.
Restartujeme IIS a můžeme testovat. Postup platí i pro Exchange 2016 a je možné jej najít zde.
2.1.3 Zamezení zamknutí účtu z extranetu
Při autentizaci pomocí ADFS je možné se přihlásit k interním službám i z internetu. Hrozí zde tedy šance, že při útoku ve formě autentizačních požadavků budou vaše účty zamčeny. Těmto útokům se dá bránit konfigurací ADFS. ADFS musí obsahovat ADFS Proxy, která v tomto případě zamezí uživatelskému požadavku na autentizaci kontaktovat DC po určité časové okno (ExtranetObservationWindow), pokud uživatel v externí síti zadal špatné heslo vícekrát, než je určeno v parametru ExtranetLockoutThreshold. Více se lze dočíst zde.
V příštím díle se zaměříme na ADFS a multifaktorovou autentizaci.
- Zbyněk Saloň, KCPS CZ
