Kerberos, část 3 – princip Kerberos autentizace

Po té, co jsme si vysvětlili potřebné základy a termíny patřící k Active Directory Domain Services, Single Sign-On a Kerberos protokolu (první díl seriálu, druhý díl seriálu), se dnes pustíme do hlavní části. Popis principu, jak funguje Kerberos autentizace, což zároveň znamená také Single Sign-On. Princip není úplně jednoduchý, používají se různé šifrovací klíče, časové známky, tikety, atd. Někomu stačí znát logický princip funkce a nepotřebuje vědět, jaké pakety se posílají a co obsahují. Proto je popis uveden třikrát, kdy každý jde více do hloubky.

Ač je vlastní princip ověřování stejný, tak se v různých situacích (třeba autentizace mezi doménami - Cross Realm Kerberos) přidávají části do celkového fungování. Řadu z nich si postupně popíšeme později.

Velmi jednoduchý popis

Princip Kerberosu se dá rozdělit do tří kroků. Předpokladem je, že jsme se na začátku přihlásili do Windows, kdy jsme zadali jméno a heslo (případně použili certifikát a PIN). Následně chceme přistoupit k nějaké síťové službě, ta podporuje Kerberos a tuto informaci nám předá spolu s požadavkem na autentizaci.

• získání TGT– ověříme, jestli máme TGT, pokud ne, tak se kontaktuje KDC služba AS a získáme TGT, který se uloží do vyrovnávací paměti (většinou se získává jen na začátku při přihlášení do počítače):
• získání Service Ticket – kontaktujeme KDC službu TGS a požadujeme Service Ticket pro službu, kde se chceme přihlásit, ověřujeme se pomocí TGT
• autentizace u služby – Service Ticket odešleme aplikačnímu serveru a ten z něj získá důvěryhodně naše uživatelské jméno

Trochu podrobněji

Autentizace uživatele– získání TGT

• při přihlašování do počítače zadá uživatel svoje přihlašovací údaje (credentials) na stanici [1]
• stanice si vytvoří uživatelův Secret Key
• nalezne se DC pro autentizaci a komunikuje se s KDC AS (která má přístup k AD databázi uživatelů)
• za pomoci šifrování se Secret Key se získá Ticket-Granting Ticket (TGT) [2]

Získání Service Ticket – když chce klient přistoupit k nějaké síťové službě(třeba aplikaci na webovém serveru), která podporuje Kerberos a vyžaduje autentizaci, tak se použije princip SSO

• klient se obrátí na svoje DC na KDC službu TGS
• požádá o Service Ticket, v žádosti se posílá (mimo jiné) typ služby (třeba HTTP, KRBTGT, LDAP, CIFS) a adresa serveru (třeba www.firma.local), což dohromady tvoří Service Principal Name (SPN), tedy unikátní identifikátor služby běžící na serveru
• pokud TGS nalezne SPN v Active Directory (a jsou splněny další autentizační podmínky), tak odesílá v odpovědi Service Ticket (ten je šifrovaný pomocí Secret Key služby) [3]

Autentizace u služby – ověření klienta na síťové službě(serveru)

• pomocí protokolu, kterým komunikuje aplikační server, odešle klient data na server a ta (mimo jiné) obsahují Service Ticket
• server rozšifruje tiket pomocí svého klíče a z něj se dozví údaje o uživateli (jeho jméno)
• ve vlastním procesu autentizace server nekomunikuje s KDC (tedy DC), ale pouze s klientem
• pokud je zapnuta obousměrná autentizace (Mutual Authentication), tak server odesílá klientovi šifrovanou časovou známku a dojde i k ověření serveru na klientovi [4]

Podrobný popis

Uvažujeme běžnou situaci v doménovém prostředí, kdy je vyžadována Pre-authentication a Mutual Authentication.

Autentizace uživatele a získání Ticket-Granting Ticket

• při přihlášení do počítače zadá uživatel své přihlašovací údaje (budeme uvažovat jméno a heslo) [1]
• klient k heslu přidá uživatelské jméno s doménou a provede jednosměrnou hashovací funkci, výsledkem je Secret Key
• klient sestaví žádost KRB-AS-REQ a odešle ji na Authentication Server (AS) což je součást Key Distribution Center (KDC), v žádosti je část KDC_REQ_BODY, kde je uživatelské jméno a Realm (doména), SPN služby (krbtgt), adresa klienta, podporované šifry, vše v holém textu (nikdy zde není heslo ani Secret Key) [2]
• AS vyžaduje před-autentizaci, která v požadavku nebyla, takže odpoví chybovou zprávou KRB-ERROR s kódem KRB5KDC_ERR_PREAUTH_REQUIRED (25) [3]
• klient sestaví nový požadavek KRB-AS-REQ, který navíc v části padata obsahuje časovou známku (timesamp) zašifrovanou pomocí Secret Key klienta [4]
• AS nalezne uživatele v AD a vytvoří si jeho Secret Key, pomocí něj rozšifruje časovou známku (tím ověřil uživatele), ověří její platnost (jestli není proti času serveru posunuta o více než 5 minut a jestli již od klienta nepřišla stejná nebo novější)
• pokud bylo vše v pořádku, tak AS vygeneruje Session Key (pro šifrování další komunikace s klientem) a Ticket-Granting Ticket (TGT) pro klienta, připraví odpověď pro klienta KRB-AS-REP, do které vloží jméno uživatele, Session Key zašifrovaný pomocí Secret Key klienta (část enc-part) a Ticket-Granting Ticket (TGT), který zašifruje svým klíčem (KDC Secret Key) [5]
• klient rozšifruje Session Key (tím se potvrdilo, že je to opravdu on) a uloží si jej pro další komunikaci s KDC, TGT rozšifrovat nedokáže, takže jej ani nemůže modifikovat
• 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 se používá pro další komunikaci s KDC, aby se nemuselo používat Secret Key (a tedy heslo), obsahuje jméno klienta, adresu, dobu platnosti, Session Key
• při každém požadavku na KDC posílá klient TGT, rozšifrovat jej může pouze KDC, takže důvěřuje obsaženým informacím, je tam i Session Key, takže si KDC nemusí udržovat žádné informace v paměti (z toho plyne vysoká škálovatelnost)

Získání Service Ticket

• když se chce klient přihlásit k nějaké službě v síti (třeba webová stránka či souborové sdílení) pomocí Kerberos protokolu (a tedy SSO), tak sestaví žádost KRB-TGS-REQ a odešle ji na Ticket Granting Service (TGS), další součást KDC [6]
• žádost obsahuje část KDC_REQ_BODY, kde jsou údaje o žádosti, hlavně jméno služby a Realm (což dohromady tvoří SPN), podporované šifry, žádanou dobu platnosti tiketu, náhodně vygenerované číslo
• druhá část padata obsahuje autentizační údaje, což je hlavně náš TGT tiket (stále šifrovaný KDC klíčem) a Authenticator (šifrovaný pomocí Session Key, obsahem je hlavně identifikace klienta a časová známka), tyto údaje tvoří dočasné credentials uživatele
• TGS si z požadavku vezme TGT a ten rozšifruje svým klíčem, z něj se dozví Session Key a pomocí něj rozšifruje Authenticator a ověří jeho data
• pokud jsou údaje v požadavku v pořádku, tak TGS připraví odpověď KRB-TGS-REP a odešle ji klientovi [7]
• do odpovědi vloží jméno uživatele, Service Ticket pro požadovanou službu, který obsahuje svoje SPN a v části šifrované pomocí Secret Key služby uvedeno jméno uživatele a Session Key pro komunikaci mezi klientem a službou, a v části enc-part je Session Key pro komunikaci se službou (klient - služba) zašifrovaný pomocí Session Key z TGT (klient - KDC), pro šifrování by se mohl použít i klíč z Authenticator (pokud by jej sem klient umístil)
• klient získá šifrovaný Service Ticket a rozšifruje si Session Key pro komunikaci se službou, oboje uloží do cache

Ověření u služby (serveru)

• klient má nyní všechna potřebná data, aby se pomocí Kerberosu autentizoval na serveru, když začal se službou komunikovat, tak se pomocí jejího protokolu (třeba HTTP) dozvěděl, že vyžaduje autentizaci a podporuje Kerberos
• klient nyní připraví odpověď v rámci stejného protokolu (třeba HTTP) do kterého zabalí další vyjednávací protokol (třeba SPNEGO GSS-API) a dovnitř již vloží Kerberos zprávu KRB-AP-REQ a odešle na server [8]
• do autentizačního požadavku vloží hlavně Service Ticket pro službu a Authenticator (šifrovaný pomocí Session Key pro komunikaci se službou, obsahuje údaje o klientovi kontrolní součet, časovou známku)
• server rozšifruje Service Ticket, z něj se dozví Session Key a rozšifruje Authenticator, ověří přijatá data
• pokud je vše v pořádku (a je vyžadována oboustranná autentizace), tak server připraví odpověď KRB-AP-REP, kterou odešle klientovi opět zabalenou pomocí aplikačních protokolů [9]
• odpověď je šifrována pomocí Session Key (klient-služba) a obsahuje časovou známku, kterou poslal klient jako součást Authenticator

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é vzájemné autentizaci

Pozn.:Pokud chceme nalézt ještě detailnější popis, tak doporučuji prostudovat specifikaci RFC 4120.

Doplňující informace

Výše jsme si docela podrobně popsali proces autentizace, přesto může vzniknout řada otázek na určité praktické detaily, na které nám tento postup neodpoví. Většinu věcí můžeme odvodit z obecných informací, které jsme si uvedli dříve. Přesto si tu ukážeme praktický případ, na kterém si popíšeme speciální problémy.

Budeme uvažovat připojení klienta pomocí webového prohlížeče k aplikaci na web serveru, kde dochází k Single Sign-On přihlášení pomocí Kerberosu. Použití webové aplikace (protokolu http) slouží pouze k tomu, abychom mluvili konkrétně, obecně je situace obdobná u většiny ostatních protokolů.

Aby byla situace složitější, a mohli jsme si popsat speciální situace, tak budeme uvažovat následující scénář. Webový server je Apache na Linuxu a fyzicky běží v jiné síti než uživatelské stanice (nemůže komunikovat s DC). Adresa je www.firma.cz a je síťově dostupná klientovi. V rámci lokální domény firma.local jsme vytvořili účet, registrovali SPN HTTP/www.firma.cz@FIRMA.LOCAL (to může obsahovat libovolnou adresu z libovolné domény, za zavináčem je naše doména, kde jsme záznam registrovali) a vytvořili keytab soubor, který jsme nahráli a nastavili na Apache.

Uživatel Petr Bouška má v doméně účet s UPN petr.bouska@jina-firma.local a sAMAccountName firma\bouska. Je přihlášen na stanici, která je součástí domény a korektně autentizován pomocí Kerberosu.

• otevřeme stránku www.firma.cz
• dostaneme odpověď, že stránka vyžaduje autentizaci a podporuje vyjednáni metodou Negotiate, klient volí Kerberos
• klient potřebuje získat Service Ticket, nijak neřeší, že adresa serveru je v jiné doméně než on, prostě se obrátí na svoje KDC (které nalezl při přihlášení dle postupu, který jsme popsali dříve)
• připraví žádost KRB-TGS-REQ, kam vloží autentizační údaje a data požadavku, tedy Realm (doménu KDC severu) FIRMA.LOCAL a Server Name (Principal Name služby) HTTP/www.firma.cz
• doménový řadič hledá v rámci své domény SPN HTTP/www.firma.cz, tak nalezne účet, který jej má přiřazené (SPN by se mohlo nacházet i v rámci jiné důvěryhodné domény, to popíšeme později)
• tím má DC všechny údaje, aby sestavil Service Ticket (do něj vloží jméno uživatele), odešle jej klientovi
• klient odešle Service Ticket (jako součást HTTP hlavičky) na webový server, ten využije keytab soubor a rozšifruje zaslaná data
• tak server získá uživatelské jméno, což je Client Name: bouska a Client Realm: FIRMA.LOCAL

Z výše uvedeného plyne několik závěrů, které jsou důležité pro praktické nasazování Kerberos SSO.

• server nemusí komunikovat s DC, stačí, když bude mít keytab soubor
• klient musí komunikovat s DC v průběhu autentizace (není to úplně pravda, komunikovat musí poprvé, pak si tikety i klíče na určitou dobu uloží do cache a může je opakovaně použít)
• DNS jméno služby může být z jiné domény než klient a buď je SPN registrováno v klientově doméně, nebo se může uplatnit Cross Realm autentizace (ověření v rámci jiné důvěryhodné domény)
• jako jméno uživatele se vždy bere sAMAccountName a DNS jméno domény, může se zapisovat ve tvaru bouska@FIRMA.LOCAL

Kerberos SSO mezi doménami

Výše jsme si popsali průběh Kerberos autentizace (SSO) v rámci jedné domény (Realmu). Výhoda protokolu Kerberos je, že umí navazovat vztahy mezi Realmy a provádět autentizaci Cross-Realm. V případě Microsoft domén to znamená, že když máme navázaný vztah důvěry mezi nějakými doménami, tak nám automaticky funguje autentizace. Takže uživatelský účet se může nacházet v jedné doméně a server (služba) v jiné, uživatel se přesto přihlásí pomocí SSO.

I když vše funguje automaticky, tak je dobré vědět, jakým způsobem autentizace probíhá. To jsem popsal v článku Cross Domain Kerberos Single Sign-On.

Troubleshooting Kerberos SSO

Pokud používáme Kerberos autentizaci, obzvláště ve speciálních (webových) aplikacích, tak určitě narazíme na různé problémy. Určitý způsob detekce a řešení některých problémů jsem popsal v článku Troubleshooting Kerberos Single Sign-On.

Autor: Petr Bouška
 

Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.