Věcem, které popisuji v tomto článku, jsem se věnoval nově a detailněji a připravil rozsáhlý seriál Kerberos protokol se zaměřením na SSO v AD DS.

Single sign-on (SSO) je metoda, která nám dovolí použít jedno přihlášení do více aplikací (pokud se ověřují u stejného zdroje, není nutné znovu vyplňovat stejné přihlašovací údaje). Ve Windows to většinou znamená, že se při přihlášení do počítače autentizujeme vůči Active Directory (doméně). Když je následně potřeba autentizace do dalšího systému, který využívá také účty v doméně (nebo používá mapování svých účtů na doménové), využijí se data, která již máme v systému, pro ověření a přihlášení do další aplikace (aniž by bylo třeba něco zadat).

Ve Windows se používá Integrated Windows Authentication (IWA), která používá protokoly SPNEGO, Kerberos a NTLMSSP. IWA je primárně spojován s webovými prohlížeči a dovolí nám využití SSO do webové aplikace (je třeba podpora v prohlížeči a na webovém serveru). SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism, RFC 2478) vyjednává, zda se použije Kerberos (verze 5, RFC 4120, což je v MS prostředí nástupce NTLM) nebo NTMLSSP (NT LAN Manager - NTLMv1 nebo bezpečnější NTLMv2, ale dnes oboje nedoporučované), případně jiný protokol. Kerberos je bezpečný protokol, který využívá metodu klíčů (ticketů) a jemu se budeme dále věnovat.

Kerberos a Single sign-on - jak funguje

Protokol Kerberos je síťový autentizační protokol, který používá silnou kryptografii pro bezpečné ověření klienta a serveru přes nezabezpečenou síť. Funguje na principu toho, že se klient neověřuje vůči serveru, kde chce získat nějakou službu, ale vůči prostředníkovi KDC. Centrální autentizační prvek zvyšuje bezpečnost a může poskytovat služby více aplikacím. Na druhou stranu se může jednat o single point of failure (takže musíme zajistit redundanci) a jeho ovládnutí ovlivní více systémů (takže jej musíme dobře zabezpečit na fyzické i síťové úrovni). KDC zná šifrovací klíče všech klientů (klienti, servery, aplikace) a ti se ověřují vůči němu, pro vzájemnou komunikaci mezi klienty jsou od KDC poskytnuty pouze nezbytné údaje.

Stručný popis Kerberos protokolu ve Windows:

• autentizace uživatele
  • při první přihlášení uživatel zadá své přihlašovací údaje (budeme uvažovat jméno a heslo)
  • klient provede jednosměrnou hashovací funkci nad heslem a získat secret key
  • klient odešle žádost na Authentication Server (AS) což je součást Key Distribution Center (KDC), ta obsahuje uživatelské údaje v otevřeném textu (neposílá heslo ani secret key)
• získání Ticket-Granting Ticket
  • AS ověří, jestli uživatel existuje a vytvoří si jeho secret key (heslo má u uživatele v AD)
  • jako odpověď odešle klientovi session key (klíč pro budoucí šifrování komunikace mezi KDC a klientem), který je zašifrovaný pomocí secret key klienta
  • a také odešle unikátní klíč Ticket-Granting Ticket (TGT), který zašifruje svým klíčem (KDC secret key)
  • tím, že si klient dokáže rozšifrovat session key se potvrdilo, že je to opravdu on (aniž by bylo třeba odesílat heslo)
  • TGT dále slouží k identifikaci uživatele, obsahuje jméno klienta, adresu, dobu platnosti, session key
  • klient nedokáže TGT rozšifrovat (to může pouze KDC)
  • TGT má omezenou životnost (default 10 hodin), ale může probíhat automatická reautentizace, při každém přihlášení se vytváří nový TGT
  • TGT i session key se na klientovi ukládají do ticket cache
• získání Service Ticket
  • když se nyní chceme přihlásit k nějaké službě v síti, tak aplikace na klientovi použije TGT a požádá KDC o service ticket
  • klient posílá žádost o service ticket na Ticket Granting Service (TGS), další součást KDC, pomocí dvou zpráv
  • jedna zpráva obsahuje klientův TGT a ID služby - Service Principal Name (SPN), TGT je již šifrovaný pomocí KDC secret key (tak jsme jej získali)
  • druhá zpráva je authenticator, skládá se z uživatelovy identifikace a časové známky, je šifrovaný pomocí session key (klient a KDC)
  • dohromady tyto zprávy tvoří credentials uživatele, které jsou platné pouze po dobu logon session, není tedy nutné se znovu ptát uživatele na přihlášení
  • TGS rozšifruje klientův TGT, z něj se dozví session key a pomocí něj rozšifruje druhou zprávu, tím ověřil klienta
  • pokud jsou údaje v pořádku, tak TGS odešle odpověď, která obsahuje část klienta a serveru
  • v klientské části je session key pro komunikaci klienta a serveru (kde je služba), šifrovaný pomocí session key (klient a KDC)
  • v serverové části je service ticket - identifikace uživatele, jeho adresa, doba platnosti a session key (klient a server), šifrováno pomocí secret key služby
  • serverovou část nemůže klient dešifrovat a ani pozměnit
• ověření u služby (serveru)
  • service ticket se potom použije k autentizaci klienta na serveru
  • na server (kam se chceme pomocí SSO přihlásit) se posílá service ticket, stále šifrovaný pomocí secret key služby
  • a také authenticator, který se skládá z uživatelovy identifikace a časové známky, je šifrovaný pomocí session key (klient a server)
  • server rozšifruje service ticket, z něho získá session key a pomocí něj rozšifruje authenticator
  • tak server získá důvěryhodné údaje o klientovi, když je vše v pořádku, tak odešle zašifrované potvrzení
  • potvrzení obsahuje časovou známku od klienta + 1, je zašifrované pomocí session key (klient a server)
• navázání session
  • klient rozšifruje potvrzení a porovná časovou známku, pokud je vše v pořádku, došlo k úspěšné autentizaci
  • ověřil se tedy nejen klient na serveru, ale i server vůči klientovi

Pozn.: Obecně jsme používali dva typy klíčů. Session key pro šifrování komunikace mezi dvěma účastníky, znají jej obě strany. Secret key zná KDC a jedna strana, ověřuje autentičnost.

Zajímavě napsaný popis Kerberosu naleznete na stránkách MS Microsoft Kerberos, bohužel v něm jsou špatně vidět jednotlivé vazby. Hodně informací přináší také PDF dokument Recommended Practices for Deploying & Using Kerberos in Mixed Environments.

Nově jsem našel velice hezký popis v článku Explain like I’m 5: Kerberos.

Praktický popis SSO k webové aplikaci s použitím Active Directory

Zkusíme si celý proces popsat z praktického a zjednodušeného pohledu. Řešil jsem řadu různých situací a potřeboval jsem přesně vědět, co se kam posílá. Ne vše jsem nalezl v nějaké dokumentaci, takže jsem další věci ověřil praxí a zkoumáním zachycené komunikace. Možná jsou mé závěry závislé na použitém prostředí, šlo o stanici s Windows, jako KDC doménový řadič AD DS, aplikační server Tomcat na Linuxu i Windows (v obou případech využívá keytab soubor).

Na začátku se přihlásíme do Windows (dojde k ověření vůči AD DS a získáme TGT), nyní pomocí webového prohlížeče otevřeme nějakou stránku/adresu (budeme ji označovat jako službu, třeba www.firma.local), která vyžaduje autentizaci a podporuje SSO. Klient teď musí kontaktovat KDC (ten běží na všech doménových řadičích), aby získal Service Ticket pro danou službu. Určitou roli hraje termín Kerberos Realm, což v MS světě odpovídá doméně (DNS názvu, třeba firma.local), standardně se zapisuje velkými písmeny (tedy třeba FIRMA.LOCAL). Dříve jsem myslel (a některá literatura na to poukazovala), že se určuje Realm pro danou službu z jejího FQDN a podle toho se dotazuje KDC. Ale není to tak. Klient vždy kontaktuje svoje KDC, tedy svůj doménový řadič, který (standardně) nalezl pomocí DNS SRV záznamu. Pro non-Windows Kerberos realms můžeme definovat příkazem ksetup a uloží se do registrů HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains.

Když známe KDC, tak se sestaví žádost (TGS-REQ), která obsahuje uživatelův Realm (FIRMA.LOCAL), typ služby (HTTP) a její adresu (www.firma.local) = SPN (HTTP/www.firma.local) a další údaje. KDC vyhledá dle SPN službu (nejprve hledá ve svém realmu, pokud zde SPN nenalezne, tak hledá v existujících důveryhodných doménách a případně předá klientovi odkaz na jiný řadič) a sestaví service ticket (který obsahuje údaje o uživateli), který je zašifrovaný pomocí klíče služby (takže s ním klient nic nenadělá) a odešle jako odpověď (TGS-REP). Service ticket posílá klient službě (aplikačnímu serveru), která se z něj dozví kdo je ověřený uživatel a nastaví jej jako přihlášeného. Klíč pro zašifrování service ticketu zná pouze služba (v mém případě využije keytab) a AD, takže není možné podvržení.

Pozn.: Důležitá je také otázka co přesně (jaký atribut) je údaj o uživateli. Nenašel jsem žádnou oficiální dokumentaci, kde by to bylo popsáno. Na řadě míst se zmiňuje, že jde o User Principal Name (UPN, atribut userPrincipalName). Kerberos ve své terminologii používá označení Principal Name, což je možná důvod zmatení s MS atributem UPN. Když zachytíme komunikaci Wiresharkem, tak se položka jmenuje Client Name (Principal), ale obsahuje pouze jméno (bez domény).To by vypadalo spíše na atribut sAMAccountName. Udělal jsem praktické pokusy, kdy jsem měl jiné UPN a sAMAccountName a vždy jsem při SSO dostal sAMAccountName. Zdá se to i logické, protože atribut UPN je v AD nepovinný (oproti sAMAccountName) a řada firem nebo jen účtů jej nepoužívá. Takže jsem přesvědčen, že se při SSO používá sAMAccountName, ale aplikace získává uživatele ve formátu sAMAccountName@ClientRealm (tedy třeba administrator@FIRMA.LOCAL).

Z výše uvedeného plyne, že server (služba) při ověřování nemusí komunikovat s AD, stačí mu, že vlastní svůj klíč pro dešifrování. S AD komunikuje pouze klient, který se chce autentizovat na server. Získá zašifrované údaje, které server rozšifruje a tím se mu potvrdila autentičnost obsažených údajů. Celá bezpečnost tkví v šifrování, vždy se používá klíč, aby zprávu rozšifrovala pouze správná strana, a pro autentizaci se používají dočasné tickety. Na klientovi se tickety kešují a mohou se použít opakovaně.

Pozn.: Náhodou jsem narazil na zajímavou věc. Generoval jsem nový keytab s jinou DNS adresou serveru (šlo ale pořád o stejný server) a použil jsem stejné heslo jako dříve. Aniž bych keytab nahrál na Tomcat, tak jsem zkusil SSO pro novou DNS adresu a vše fungovalo. Očividně se na Tomcatu pouze rozšifroval service ticket pomocí starého secret key (odvozeného od hesla) obsaženého v keytabu a vůbec se neověřovalo SPN.

Pro různé testování se může hodit nástroj klist, který je součástí Windows a vypíše nám všechny tickety. Pomocí klist purge můžeme nakešované tickety smazat. Podobně se může hodit setspn, který mimo nastavování SPN na účty, může také vypsat existující SPN a jaký účet je má přiřazeny. V hledání můžeme využít zástupný znak *, takže například setspn -Q HTTP/*.

Pozn.: V praxi jsem řešil situaci, kdy byl aplikační server umístěn mimo lokální síť a doménu firma.local a požadavek byl přistupovat z vnitřní sítě přes veřejnou adresu server.firma.cz. Potvrdil se teoretický předpoklad, že je vše funkční, když nastavíme SPN HTTP/server.firma.cz na účet v doméně firma.local. Lokální klient odesílá Kerberos požadavek na svůj DC, který podle zadaného SPN nalezne účet a vytvoří Service Ticket, který aplikační server rozšifruje pomocí keytab souboru.

Kerberos pakety žádost a odpověď

Mnoho informací se dá získat, pokud zachytíme komunikaci na klientovi a podíváme se na pakety, které si vyměňuje s KDC. Nejprve je vidět požadavek od klienta pro SPN HTTP/ssotest.firma.local. Uživatel na klientovi je Administrator přihlášený v doméně firma.test.

Dále vidíme korektní odpověď.

Poslední příklad ukazuje odpověď od DC, pokud nebylo nalezeno požadované SPN.