Kerberos část 4 – SSO pro webovou aplikaci

Article
10/05/2014

Vítejte u čtvrté a závěrečné části seriálu, který se věnuje protokolu Kerberos se zaměřením na Single Sign-On (SSO) v prostředí Microsoft Active Directory. Zde naleznete první, druhý a třetí díl.

Již detailně víme, jak protokol Kerberos funguje a jakým způsobem probíhá SSO autentizace. Dnes se podíváme na poslední část, tedy ověření u služby. Budeme se věnovat speciálnímu případu, kdy služba je webový server a přihlašujeme se pomocí SSO do webové aplikace. Nejprve si popíšeme, jak funguje Kerberos nad protokolem HTTP (což samozřejmě zahrnuje i HTTPS). Do hry tam vstupuje několik dalších protokolů, takže si vysvětlíme celý proces. Popíšeme si, co je třeba splnit na straně webserveru. Protože budeme uvažovat jiné servery než Microsoft IIS, tak si detailně popíšeme vytváření keytab souboru, který se v tom případě využívá. Na závěr zmíníme potřebné nastavení webových prohlížečů, aby SSO fungovalo.

Kerberos a Single Sign-On s protokolem HTTP

V doménovém prostředí nám SSO autentizace funguje automaticky k řadě služeb, jako je třeba souborové sdílení nebo tiskové služby. V dnešní době velké množství aplikací funguje pomocí webového rozhraní. Bylo by tedy pohodlné se i k těmto webovým aplikacím přihlašovat pomocí SSO. A díky speciálnímu autentizačnímu schématu v rámci HTTP protokolu to možné je.

Webový server Internet Information Services (IIS), jako součást Windows, podporuje SSO pomocí jednoduchého nastavení. Ale podpora je i v dalších serverech, jako Apache HTTP Server nebo Apache Tomcat. V takovém případě řeší Kerberos komunikaci aplikační server a z jeho proměnných získá aplikace uživatelské jméno. Jiná možnost je využít Kerberos protokol přímo v aplikaci (třeba pomocí hotových knihoven). Stejně tak je podpora ve všech moderních webových prohlížečích, ale většinou je potřeba provést malé nastavení.

Pokud využijeme IIS na počítači zařazeném do domény, tak ten může (třeba) pomocí servisního účtu komunikovat přímo s doménovým řadič a řešit Kerberos autentizaci. To v případě Apache nelze, ani když běží na Windows serveru v doméně. Je tu ale jiná možnost a to využití keytab souboru. Pomocí této metody je možno využít Kerberos autentizaci pro různé aplikační servery, i když běží třeba na Linuxu či jiném OS.

Možnost použít Kerberos autentizaci v HTTP protokolu přinesl Microsoft v roce 2001 pomocí HTTP autentizačního schématu Negotiate. Ten byl později popsán v informačním RFC 4559 z roku 2006. Využívá GSSAPI pro zabalení Kerberos protokolu. Standardně se v HTTP provádí autentizace na začátku a tím se autentizuje session. Pro zabezpečení transportní vrstvy je vhodné použít HTTPS.

Integrated Windows Authentication (IWA)

Když chceme využít Kerberos SSO pro autentizaci na webu, tak se (v Microsoft prostředí) používá Integrated Windows Authentication (IWA), přihlášení pomocí našich Windows credentials (pomocí našeho aktuálního přihlášení do Windows). Nejde o žádný standard a ani přímo nejde o autentizační protokol, tento termín pro autentizační metodu používá IIS i Internet Explorer. Pro IWA se používají i jiná označení jako HTTP Negotiate Authentication, Windows NT Challenge/Response Authentication či pouze Windows Authentication. Nepodařilo se mi nalézt žádnou oficiální dokumentaci, která by IWA popisovala/definovala. Nevím, jestli celé IWA znamená pouze HTTP autentizační schéma Negotiate, nebo k němu patří ještě něco dalšího. Minimálně základ je popsaný v informačním dokumentu RFC 4559 - SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows.

IWA používá poskytovatele (Providers) pro různé autentizační metody, podporuje Negotiate a NTLM, od IIS 7.0 je také možnost nastavit samostatně Negotiate:Kerberos. Když na IIS zapneme IWA autentizaci, tak se standardně použije Negotiate (Kerberos a NTLM) a samostatné NTLM. Nastavení IWA v Internet Exploreru zajistí, aby odpovídal na Negotiate výzvy. Pokud IWA vypneme, tak pořád odpovídá na samostatné NTLM. Webservery jako Apache a Tomcatpoužijí při nastavení Kerberosu Negotiate.

HTTP Negotiate autentizace

Když chceme použít protokol Kerberos, tak se využívá metoda Negotiate. Jde o autentizační balíček, který implementuje mechanismus SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism, RFC 4178), který patří do standardizovaného GSS-API (Generic Security Service Application Program Interface, RFC 2743). Jedná se o obálku, která dovolí vyjednání/výběr vhodného protokolu. V případě Microsoftu se uvnitř Negotiate používá Kerberos v5 a NTLM, ale je možno rozšířit o další protokoly. Kerberos je upřednostněný, takže pokud má klient vše potřebné, tak využije Kerberos, pokud ne, tak se pokusí o NTLM.

Pro HTTP Negotiate (IWA) se v HTTP protokolu využívají HTTP/401 výzvy (Challenges) stejně jako pro další autentizace (třeba Basic či Digest). Popis nalezneme v navrhovaném standardu RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication. Znamená to využití stavového kódu HTTP/1.1 401 Unauthorized v HTTP hlavičce. Alespoň tento název uvádí RFC norma (RFC 2616 kapitola 10.4.2 a zmiňovaná RFC 7235), ale v praxi se často setkáme také s HTTP/1.1 401 Authorization Required.

Průběh HTTP autentizace

Komunikace mezi klientem a webovým serverem probíhá při autentizaci následovně (zaměřeno na Kerberos):

klient posílá HTTP GET požadavek pro získání nějaké stránky, standardně se používá anonymní autentizaci (žádné autorizační údaje se neposílají)
pokud má server nastaven přístup na danou stránku pouze po ověřené uživatele, tak nevrátí stránku (a kód 200), ale odpoví s kódem 401 a zároveň nabídne podporované autentizační metody (může tam být jedna nebo více, v příkladu je uvedeno IWA, Digest, Basic)

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Digest realm="" nonce="" …
WWW-Authenticate: Basic realm=""

klient zkouší ověřovací metody a pro první, kterou podporuje, připraví odpověď. Znovu pošle HTTP GET požadavek na stránku, ale tentokrát doplní do hlavičky autentizační údaje (dle použité metody)

Authorization: Negotiate YIIGKwYGKwYBBQUCoI…

server ověří zaslané autentizační údaje, a pokud je vše OK, tak vrátí stavový kód 200 a požadovanou stránku. Pokud se používá vzájemná autentizace, tak server v hlavičce znovu použije WWW-Authenticate: Negotiate, jako při nabízení autentizačních metod, ale nyní doplní svoje údaje.

WWW-Authenticate: Negotiate oYHmzsZsjbVx

V praxi se někdy používá to, že server nevrátí stránku a kód 200, ale nejprve provede přesměrování na jinou stránku, takže klient dostane kód 302 a adresu stránky, kterou má otevřít.

Autentizace z pohledu uživatele

Pokud proběhne vše správně, tak se použije Kerberos V5, jak jsme si popisovali v dřívějších dílech. Znamená to, že dojde k SSO, uživatel nemusí nic zadávat a ani nemusí poznat, že došlo k autentizaci. Jednou z podmínek je, aby měl přímé připojení do Active Directory. A správně nastavený prohlížeč (to si popíšeme dále v článku). Pokud nesplňuje všechny podmínky, nebo něco selže, tak částečně záleží, jak je napsána webová aplikace. Ve většině případů se zobrazí modální oknoWindows Security, které se ptá na jméno a heslo (případně certifikát).

V určitém procentu případů můžeme vyplnit přihlašovací údaje, provede se Kerberos autentizace s DC, a na server se odešle tiket. V tom případě dojde ke korektnímu přihlášení. Většinou se ale v tuto chvíli provede NTLM autentizacea pokud ji nemáme povolenu jako alternativu ke Kerberosu, tak přihlášení selže. Znovu se nám (třikrát po sobě) zobrazí přihlašovací dialog. Jestli vyskakující dialog bude provádět Kerberos nebo NTLM nepoznáme (jedině můžeme zachytávat komunikaci).

Obsah autentizačních dat

V klientském požadavku, který v hlavičce obsahuje řádku Authorization, se za klíčovým slovem Negotiate nachází GSS-API data kódovaná pomocí Base64. Uvnitř se nachází SPNEGO a uvnitř seznam podporovaných metod a Kerberos v5 datový objekt. V objektu je Kerberos zpráva KRB-AP-REQ a v ní Service Ticket.

Komponenty Windows pro autentizaci

V Microsoft OS zajišťuje autentizaci uživatele služba Local Security Authority (LSA). Ta volá rozhraní (bezpečnostní API) Security Support Provider Interface (SSPI), což je proprietární varianta standardního GSS-API. SSPI využívá různé poskytovatele (SSP - Security Support Provider), třeba protokol Kerberos V5 (včetně rozšíření, které umožňuje provést autentizaci pomocí certifikátu na čipové kartě) implementoval pomocí dynamicky linkované knihovny Kerberos SSP (Kerberos.dll). Webový prohlížeč (třeba Internet Explorer) také volá SSPI, to použije Negotiate SSP, které zvolí Kerberos SSP nebo NTLM SSP.

Keytab (key table) soubor

Běžně můžeme SSO použít pro Microsoft služby, které běží na počítači zařazeném do domény. V tom případě sdílí počítač i AD heslo, z kterého si vytvoří Secret Key. Pomocí tohoto klíče pak šifrují vzájemnou komunikaci. Pokud chceme využít SSO na službě, která nemůže komunikovat s DC, třeba běží na Linuxu, není v doméně, apod. Tak stačí, když bude znát Secret Keypro rozšifrování komunikace (musí ho sdílet s DC).

Keytab (tabulka klíčů) je soubor, který obsahuje SPN a jim odpovídající šifrovací klíče (Secret Key). Může se použít pro rozšifrování komunikace při SSOa tedy ověření klienta přistupujícího ke službě. Je také možné jej použít pro autentizaci do domény (aniž by se muselo zadávat jméno a heslo). V keytab souboru může být jeden nebo více SPN/klíčů.

Pomocí keytab souboru nahrazujeme to, že je počítač zařazen do domény (a tím má k dispozici šifrovanou komunikaci s DC). V souboru máme klíč pro šifrování. Samozřejmě potřebujeme i odpovídající údaj v doméně. To se provádí tak, že se vytvoří servisní uživatelský účet (teoreticky lze použít i počítačový, ale mohou být různé problémy, takže je lepší zůstat u uživatelského) a na tento účet se registruje SPNpro službu. Účet musí používat stejné heslo jako keytab soubor.

Pozn.: Z toho, co jsme si řekli, je jasné, že je třeba myslet na bezpečnost. Keytab soubor představuje uživatelské credentials, pomocí něj se můžeme přihlásit do domény. Takže by servisní účet neměl mít žádná speciální práva (pro účel našeho použití žádná nepotřebuje) a přístup ke keytab soubor by měl být co nejvíce zabezpečen.

Vytvoření Keytab souboru

Jako součást Windows Server 2008 a novějších (nebo v Support Tools) nalezneme řádkový příkaz ktpass. Tento příkaz provádí několik operací. Nejprve registruje SPN (Service Principal Name) dle zadaného Principal Name a účtu. Defaultně také nastaví na účtu UPN (User Principal Name) na hodnotu Principal Name. Změní heslo na účtu a toto použije i pro keytab soubor. Nakonec vytvoří výstupní keytab soubor.

Pozn.: Některé verze ktpass na Windows Server 2003 měli bug, postižena je verze 5.2.3790.1830, takže je potřeba použít novější.

Níže je uveden příklad vytvoření keytab souborupro webový server, nejprve obecná forma a poté s ukázkovými hodnotami.

Pozn.: Stejně, jako většinu jiných příkazů, musíme ktpassspouštět pod účtem s dostatečnými právy a jako administrátor (cmd Run as administrator).

ktpass -out jméno-souboru -princ HTTP/hostname@AD-DOMÉNA -mapUser AD-účet -mapOp set -pass * -ptype KRB5_NT_PRINCIPAL -kvno 0

ktpass -out mujweb.keytab -princ HTTP/mujweb.firma.local@FIRMA.LOCAL -mapUser firma\mujweb -mapOp set -pass * -ptype KRB5_NT_PRINCIPAL -kvno 0

Ve výše uvedeném příkladu používáme následující parametry:

out – output, tedy výstupní soubor
princ - Principal Name je závislé na velikosti písmen, obsahuje SPN (službu/adresu) a Kerberos Realm, tedy určení domény v které se nachází účet (zapisuje se velkými písmeny)
mapUser – Mapping User - doménový účet, na který se SPN registruje, obecně se má jednat o uživatelský účet, ale v některých případech lze použít i účet počítače, můžeme zadat UPN, ale bezpečnější je použít formu domena\ sAMAccountName
mapOp - Mapping Operation určuje, jestli se SPN přidává (add) nebo nastavuje (set), čímž odstraní všechny předchozí SPN záznamy
pass – Password - pro vytvoření keytab souboru musíme zadat heslo, které se použije pro generování klíče a nastaví se na účet. Hvězdička znamená, že se na zadání hesla dotáže při vytváření. Zajímavé je, že pokud použijeme hvězdičku, tak se následně zadaným heslem do účtu nepřihlásíme, ale pokud heslo zadáme rovnou za parametr, tak se s ním k účtu můžeme přihlásit. Je třeba myslet na naši politiku hesel, pokud by ji zadané heslo nevyhovovalo, tak při nastavování vrátí chybu (Password set failed) .
ptype - Principal Type nastavujeme na obecný typ KRB5_NT_PRINCIPAL
kvno - Key Version Number představuje verzi klíče, která se zvyšuje při každé změně hesla a je uložena u účtu. Pomocí parametru můžeme nastavit určitou hodnotu. Verze se ukládá i do keytabu (pokud neurčíme parametrem, tak se použije aktuální z AD) a při použití se porovnává s hodnotou na účtu. V keytabu je možno ji nastavit na 0 a pak se nekontroluje.

Použít můžeme řadu dalších parametrů, zajímavé z nich jsou:

target – určujeme, jaký doménový řadič se má použít, když nezadáme, tak se automaticky detekuje podle realmu v Principal Name
crypto – určujeme šifrovací metodu, dnes defaultní je RC4-HMAC-NT, pro zpětnou kompatibilitu DES-CBC-CRC, DES-CBC-MD5 a další třeba AES256-SHA1, pro nejširší možnosti můžeme použít hodnotu All, která zajistí, že se vygeneruje tiket pro každou šifru (do jednoho keytabu). Pokud bychom měli starou verzi ktpass, tak nemusí podporovat RC4-HMAC-NT a keytab nebude fungovat.
setUpn – pokud přidáme parametr –setUpn, tak nedojde k nastavení UPN na účtu

Příklad vytvoření keytabu výše, odpovídá způsobu, jak je popisován v hodně článcích na internetu. Dochází při něm ke změně UPN na uživatelském účtu. Nemyslím, že je to k něčemu potřeba (při Kerberos autentizaci se hledá SPN a ne UPN), takže je možné využít parametr -setUpn. Provedl jsem řadu testů a vše je funkční. Takže níže je příklad použití ktpass, který mi připadá optimální .

ktpass -out mujweb.keytab -princ HTTP/mujweb.firma.local@FIRMA.LOCAL -mapUser firma\mujweb -mapOp set -pass heslo -ptype KRB5_NT_PRINCIPAL -kvno 0 –setupn –crypto All

Vytvoření Keytab souboru s více SPN

Na aplikačním serveru můžeme většinou použít pouze jeden keytab soubor. Přitom může nastat situace, kdy potřebujeme použít více SPN. Například, když chceme, aby na webovém serveru fungovalo SSO pro standardní adresu (FQDN – mujweb.firma.local) a pro nějaký alias (www.firma.local).

Můžeme to udělat tak, že nejprve vytvoříme keytab pro první SPN, které nastavíme (set) na uživatelský účet.

C:\>ktpass -out mujweb.keytab -princ HTTP/mujweb.firma.local@FIRMA.LOCAL -mapUser firma\mujweb -mapOp set -pass * -ptype KRB5_NT_PRINCIPAL -kvno 0 –setupn
Targeting domain controller: dc.firma.local
Using legacy password setting method
Successfully mapped HTTP/mujweb.firma.local to mujweb.
Type the password for HTTP/mujweb.firma.local:
Type the password again to confirm:
Key created.
Output keytab to mujweb.keytab:
Keytab version: 0x502
keysize 72 HTTP/mujweb.firma.local@FIRMA.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0xad04eaf7d0d0a63adf0596c0788e910c)

Poté zavoláme příkaz znovu, na vstupu mu dáme první keytab soubor, přidáme druhé SPN, změníme Mapping Operation na add. Tak se vytvoří keytab, který obsahuje dvě SPN. Když používáme stejný uživatelský účet, tak bychom v obou případech měli zadat stejné heslo.

C:\>ktpass -in mujweb.keytab -out mujweb.keytab -princ HTTP/www.firma.local@FIRMA.LOCAL -mapUser firma\mujweb -mapOp add -pass * -ptype KRB5_NT_PRINCIPAL -kvno 0 –setupn
Existing keytab:
Keytab version: 0x502
keysize 72 HTTP/mujweb.firma.local@FIRMA.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0xad04eaf7d0d0a63adf0596c0788e910c)
Targeting domain controller: dc.firma.local
Using legacy password setting method
Successfully mapped HTTP/www.firma.local to mujweb.
Type the password for HTTP/www.firma.local:
Type the password again to confirm:
Key created.
Output keytab to mujweb.keytab:
Keytab version: 0x502
keysize 72 HTTP/mujweb.firma.local@FIRMA.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0xad04eaf7d0d0a63adf0596c0788e910c)
keysize 59 HTTP/www.firma.local@FIRMA.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0xad04eaf7d0d0a63adf0596c0788e910c)

Identicky můžeme použít dva různé účty, které budou mít nastaveny každý svoje SPN a vytvořit spojený keytab soubor.

Kerberos na webovém serveru

Z informací, které jsme si popsali v minulých dílech a v tomto článku, můžeme dát dohromady body, které je třeba splnit pro provozování Kerberos SSO na webovém aplikačním serveru. Uvedeme si bodový výčet, jednotlivé detaily jsme popsali dříve. Je malý rozdíl, jestli používáme IIS (kde jsou některé věci jednodušší, například odpadá keytab soubor) nebo jiný server. Zde budeme popisovat situaci jaká je například u Apache HTTP Server.

pro server potřebujeme mít DNS A záznam (host), toto FQDN bude uživatel zadávat do prohlížeče (pokud použijeme alias (CNAME), tak můžeme narazit na problém, že některé prohlížeče nepoužijí tento alias, ale navázané jméno hosta), příklad www.firma.local
servisní účet v Active Directory, nejlépe uživatelský účet bez speciálních práv, na který navážeme službu, u účtu se nesmí měnit heslo (po vytvoření keytab souboru), příklad firma\wwwsso
na servisní účet registrované SPN služby, které využívá zadané FQDN (registraci provedeme spolu s vytvořením keytabu), příklad HTTP/www.firma.local
vytvořený keytab soubor pomocí příkazu ktpass (někdy je třeba, aby se při vytváření keytabu, nacházel účet v defaultním kontejneru Users, následně jej můžeme přesunout), příklad

ktpass -out www.keytab -princ HTTP/www.firma.local@FIRMA.LOCAL -mapUser firma\wwwsso -mapOp set -pass heslo -ptype KRB5_NT_PRINCIPAL -kvno 0 –setupn –crypto All

keytab soubor nahraný ve složce na webovém serveru a odpovídajícím způsobem provedena konfigurace serveru/aplikace

Webové prohlížeče

Běžné webové prohlížeče podporují Kerberos protokol a metodu Negotiate. Pro vlastní provedení využívají systémové rozhraní SSPI. Většinou je ale třeba určitá konfigurace, aby autentizace korektně proběhla. Jde o povolení IWA (defaultně povolené je) a povolení dané DNS adresy serveru.

Internet Explorer

IE podporuje Integrated Windows Authentication (IWA) a defaultně je toto nastavení povolené. Povolení můžeme měnit v Internet Options - Advanced - část Security . Změna nastavení vyžaduje restart.

Protože IE považuje protokol Kerberos za interní, tak (standardně) povolí autentizaci pouze na adresy, které patří do zóny Local Intranet. Historicky IE bere jako interní adresy pouze NetBIOS jména a používá jednoduché pravidlo, pokud je v adrese tečka, tak jde o internetovou adresu. Takže každá běžná adresa zadaná pomocí FQDN (Fully Qualified Domain Name) nebo IP adresy je brána jako internetová, i když je lokální. Kerberos vychází z DNS, takže asi pro adresu používáme FQDN. Jediná možnost je tedy ručně zadat adresu či celou doménu mezi Local Intranet.

Nastavení provedeme v Internet Options - Security - Local Intranet - Sites – Advanced. Můžeme zadat celou adresu včetně protokolu, pouze adresu (pak funguje pro http i https) nebo využít zástupný znak hvězdička, což je nejčastější použití pro intranet (třeba *.firma.local).

Mozilla Firefox

Firefox podporuje Kerberos autentizaci již dlouho, na Windows umí využít jak SSPI (upřednostňuje), tak GSSAPI. Stejně jako u IE je podpora defaultně zapnutá, ale musí se specifikovat adresy, pro které se může použít. Pro konfiguraci musíme do adresního řádku zadat

about:config

Po potvrzení varování, že změny konfigurace mohou být nebezpečné, vidíme jednotlivé konfigurační parametry. Do filtru zadáme proměnnou, kterou chceme měnit. Což je network.negotiate-auth.trusted-uris, kterou rozklikneme. Opět zde můžeme zadat celou adresu nebo pouze doménu. Více adres můžeme oddělit čárkou.

Ještě máme další hodnoty, které standardně nemusíme měnit. Pomocí nich můžeme nastavit knihovnu, která se použije pro autentizaci. Jestli se má použít SSPI network.auth.use-sspi (defaultně true), jestli se používá defaultní knihovna GSSAPI (pokud nenastavíme SSPI) network.negotiate-auth.using-native-gsslib (defaultně true) a případně jméno jiné GSSAPI knihovny network.negotiate-auth.gsslib.

Google Chrome

Windows verze Google Chrome využívá nastavení z Internet Exploreru.

Pozn.: Na internetu je i řada zmínek, že se nastavení provádí v registrech. Ale v praxi jsem ověřil, že se změny nastavení Internet Exploreru projeví v Chrome.

Odkazy

IWA a Negotiate

Keytab

Prohlížeče

Autor: Petr Bouška