Pozn.: Tento článek jsem lehce upravil a zařadil do nové série o Kerberos SSO. Přitom jsme změnil jeho název z původního Cross Domain Kerberos Single Sign-On.
Odpověď na hlavní otázku, jestli nám mezi dvěma doménami bude fungovat SSO, je: Pokud existuje mezi doménami vztah důvěry, tak vše funguje automaticky. Jestliže jsou domény ve společném lese, tak je důvěra nastavena automaticky.
Kerberos Single Sign-On
Obecný princip SSO pomocí protokolu Kerberos jsme si popsali v předhozích dílech seriálu . Hlavní princip je stále stejný, ať komunikujeme v rámci stejné domény nebo do jiné. Zde si znovu zopakujeme některé části SSO procesu, které nás zajímají v souvislosti s dnešním tématem.
Nejprve musí dojít k autentizaci uživatele, ten zadá svoje přihlašovací údaje (credentials) na stanici [1]. Klient kontaktuje službu Authentication Service (AS) na Key Distribution Center (KDC), to znamená na nějakému doménovému řadiči (DC). Řadič se hledá pomocí DNS (případně NetBIOS) SRV záznamu pro danou doménu. Obecně jde o záznam _ldap._tcp.DnsDomainName (třeba _ldap._tcp.firma.local), ale Microsoft používá speciální záznamy, aby hledal Windows LDAP servery, _ldap._tcp.dc._msdcs.DnsDomainName (třeba _ldap._tcp.dc._msdcs.firma.local) Klient získá seznam dostupných řadičů a odešle na ně LDAP dotaz, oni odpoví základními informacemi. Klient použije první DC, který odpověděl. Pak se ještě může zjišťovat, jestli se řadič nachází ve stejné Site jako klient, pokud ne, tak se pokusí nalézt vhodnější DC, opět se využije DNS dotaz _ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName (třeba _ldap._tcp.Praha._sites.dc._msdcs.firma.local). Celý proces autentizace zajišťuje na klientovi služba Net Logon. Když dojde ke Kerberos autentizaci (AS využije AD databázi uživatelů), tak klient získá Ticket-Granting Ticket (TGT) [2]. Ve většině případů se při autentizaci využije nejen DC, ale také globální katalog (GC).
Když pak 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 KDC na Ticket-Granting Service (TGS), tedy svůj doménový řadič, a 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. Každá služba, která využívá Kerberos autentizaci, musí mít SPN. Pokud TGS nalezne SPN v Active Directory (a jsou splněny další autentizační podmínky), tak odesílá v odpovědi Service Ticket [3].
Poslední část je ověření klienta na síťové službě (serveru). Klient odešle data na server a ta (mimo jiné) obsahují Service Ticket. Pokud je vše v pořádku, tak z těchto dat server zjistí údaje o uživateli (jeho jméno). Ve vlastním procesu autentizace server nekomunikuje s KDC, potažmo 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].
To je stručný proces SSO. To co se liší, když komunikujeme v rámci stejné domény nebo do jiné, je pouze to odkud získáme Service Ticket (ve schématu jde o krok 3).
SSO v rámci domény
Jde o nejjednodušší situaci. Každý DC obsahuje všechny informace z dané domény. Když se tedy hledá SPN, tak se nalezne v jeho databázi a TGS může vše přímo zpracovat. Postup je tedy následující:
[1] uživatel (již autentizovaný) se ze stanice snaží připojit na síťovou službu (třeba fileshare) a ta požaduje Kerberos autentizaci
[2] stanice kontaktuje svoje KDC (DCfirma) a získá Service Ticket (pokud v pořádku proběhne vyjednání - autentizace)
[3] pomocí ticketu se uživatel autentizuje na službě
SSO mezi doménami v rámci lesa
Pokud se služba (server) nachází v jiné doméně než klient, tak se využijí informace z Global Catalogu, který pomůže najít správný DC.
[1] uživatel (již autentizovaný) se ze stanice snaží připojit na síťovou službu (třeba fileshare) a ta požaduje Kerberos autentizaci
[2] stanice kontaktuje svoje KDC (DCfirma1) se žádostí o Service Ticket pro SPN služby, ale DC nenalezne SPN ve své AD databázi
[3] DC se zeptá globálního katalogu (GC), jestli se toto SPN nachází ve stejném lese, který jej nalezne a pošle informace zpět na řadič
[4] DC předá odkaz (Referral Ticket) na cílový řadič klientovi (ten je šifrovaný pomocí interdomain key)
Pozn.: Pokud by byly domény více zanořené, tak se informace předávají po vztazích důvěry. To znamená, že klient dostane vždy odkaz (Referral Ticket) na další DC, kterého se zeptá. Musí nejprve dojít na kořenovou doménu ve svém stromě, pak může přejít do cílového stromu a tam postupovat dolů. Samozřejmě mohou být vytvořeny i speciální vztahy důvěry (třeba Shortcut), které se využijí.
[5] stanice kontaktuje řadič (DCfirma2) v cílové doméně (která obsahuje dané SPN) a pošle mu Referral Ticket, jako odpověď získá Service Ticket (pokud v pořádku proběhne vyjednání - autentizace/rozšifrování)
[6] pomocí ticketu se uživatel autentizuje na službě
SSO mezi doménami v různých lesech
Pokud chceme využít SSO mezi dvěma doménami, které jsou každá v jiném lese, tak musíme navázat důvěru mezi lesy Forrest Trust. Když se taková důvěra vytváří, tak každý les shromáždí informace o všech jmenných prostorech (namespace) v partnerském lese. Tyto informace obsahují jména domén, UPN přípony, SPN přípony a jmenné prostory pro SID (security ID). Tyto informace se uloží do AD TDO objektu (Trusted Domain Objects), který se replikuje do Global Catalog (GC).
[1] uživatel (již autentizovaný) se ze stanice snaží připojit na síťovou službu (třeba fileshare) a ta požaduje Kerberos autentizaci
[2] stanice kontaktuje svoje KDC (DCfirma1) se žádostí o Service Ticket pro SPN služby, ale DC nenalezne SPN ve své AD databázi
[3] DC se zeptá globálního katalogu (GC), který toto SPN nenalezne (protože má údaje pouze ze svého lesa), takže zkontroluje informace o všech Forrest Trust a porovná příponu z SPN se seznamem přípon partnerského lesa, zde nalezne shodu, takže předá DC informace o routování (Routing Hint)
[4] DC předá klientovi odkaz (Referral Ticket) buď na nadřazenou (kořenovou) doménu jeho lesa nebo rovnou na cílovou doménu v jiném lese
Pozn.: Podle struktury domén se pak využijí metody, které byly popsány v předchozí kapitole, až se klient dostane na cílový DC.
[5] stanice kontaktuje řadič (DCjfirma) v cílové doméně (která obsahuje dané SPN) a pošle mu poslední Referral Ticket, získá zpět Service Ticket (pokud v pořádku proběhne vyjednání - autentizace/rozšifrování)
[6] pomocí ticketu se uživatel autentizuje na službě
Výše uvedené schéma ukazuje nejjednodušší situaci, kdy se klient i server nachází v kořenových doménách lesů. Následující schéma ukazuje trochu složitější situaci, kdy jsou použity zanořené domény.
Praktické ukázky ticketů a packetů
Na závěr si ukážeme, jak vypadají Kerberos Tickety pro určité praktické situace.A jaké packety se posílají v případě dvou domén v jednom lese. Popis obsahu Ticketů a zpráv nalezneme ve specifikaci RFC 4120 - 5.3. Tickets.
Služba i klient ve stejné doméně
Nejjednodušší příklad. Účet uživatele bouska se nachází v doméně firma.local. Ve stejné síti máme webový server www.firma.local, který má v doméně účet s SPN HTTP/www.firma.local.
C:\>klist
Current LogonId is 0:0x4c956
Cached Tickets: (2)
#0> Client: bouska @ FIRMA.LOCAL
Server: krbtgt/FIRMA.LOCAL @ FIRMA.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 5/5/2014 11:14:01 (local)
End Time: 5/5/2014 21:14:01 (local)
Renew Time: 5/12/2014 11:14:01 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: DC
#1> Client: bouska @ FIRMA.LOCAL
Server: HTTP/www.firma.local @ FIRMA.LOCAL
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
Start Time: 5/5/2014 11:18:29 (local)
End Time: 5/5/2014 21:14:01 (local)
Renew Time: 5/12/2014 11:14:01 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: dc.firma.local
Služba s adresou z jiné domény
Druhá situace je technicky stejná jako první, rozdíl je pouze v tom, že DNS adresa webového serveru je www.firma.cz. Účty jsou ale pořád ve stejné doméně firma.local.
C:\>klist
Current LogonId is 0:0x4c956
Cached Tickets: (2)
#0> Client: bouska @ FIRMA.LOCAL
Server: krbtgt/FIRMA.LOCAL @ FIRMA.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 5/5/2014 17:08:46 (local)
End Time: 5/6/2014 3:08:46 (local)
Renew Time: 5/12/2014 17:08:46 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: dc.firma.local
#1> Client: bouska @ FIRMA.LOCAL
Server: HTTP/www.firma.cz @ FIRMA.LOCAL
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
Start Time: 5/5/2014 17:08:46 (local)
End Time: 5/6/2014 3:08:46 (local)
Renew Time: 5/12/2014 17:08:46 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: dc.firma.local
Služba je v jiné doméně než klient
Poslední příklad ukazuje situaci, kdy máme dvě domény v rámci jednoho lesa. Účet uživatele bouska se nachází v doméně firma2.local. Webový server má adresu www.firma1.local a jeho účet s SPN HTTP/www.firma1.local se nachází v doméně firma1.local. Je vidět, že uživatel získal TGT pro obě domény. Service Ticket obsahuje SPN z domény firma1.local pro uživatele v doméně firma2.local.
C:\>klist
Current LogonId is 0:0x1c975
Cached Tickets: (3)
#0> Client: bouska @ FIRMA2.LOCAL
Server: krbtgt/FIRMA1.LOCAL @ FIRMA2.LOCAL
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 5/5/2014 17:23:11 (local)
End Time: 5/6/2014 3:23:11 (local)
Renew Time: 5/12/2014 17:23:11 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
#1> Client: bouska @ FIRMA2.LOCAL
Server: krbtgt/FIRMA2.LOCAL @ FIRMA2.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 5/5/2014 17:23:11 (local)
End Time: 5/6/2014 3:23:11 (local)
Renew Time: 5/12/2014 17:23:11 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#2> Client: bouska @ FIRMA2.LOCAL
Server: HTTP/www.firma1.local @ FIRMA1.LOCAL
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
Start Time: 5/5/2014 17:23:11 (local)
End Time: 5/6/2014 3:23:11 (local)
Renew Time: 5/12/2014 17:23:11 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Kerberos packety
Následující obrázek ukazuje zachycenou komunikaci programem Wireshark. Klientem (192.168.50.25) byla požadována webová stránka (192.168.50.15), ta vyžaduje autentizaci. Klient měl vymazanou cache ticketů, takže nejprve získal TGT od svého DC (192.168.50.20). Pak požadoval Service Ticket, ale SPN se nachází v jiné doméně, takže od svého DC (192.168.50.20) získal Referral Ticket a obrátil se na druhé DC (192.168.50.10). Od něj již obdržel správný Service Ticket, takže se mu podařilo přihlášení.
Packety, které se používají pro běžnou Kerberos komunikaci, jsou typu KRB-AS-REQ (10) a KRB-AS-REP (11) pro získání TGT, KRB-TGS-REQ (12) a KRB-TGS-REP (13) pro získání Service Ticket, KRB-AP-REQ (14) a volitelně KRB-AP-REP (15) pro autentizaci u služby/serveru. Objevit se může také zpráva KRB-ERROR (30) s nějakou chybovou informací.
Podrobnou specifikaci zpráv nalezneme v RFC 1510. Důležité je, že požadavky mají dvě hlavní části. padata, což je zkratka pre-authentication data, zde mohou být informace potřebné zpracování nebo dešifrování. Třeba u KRB-TGS-REQ je zde Authentication Header (Ticket-Granting Ticket a Authenticator). A KDC-REQ-BODY, kde jsou vlastní data požadavku, třeba Client Name, Realm, Server Name (SPN). Odpověď může mít více částí, je zde třeba Client Name, Client Realm a Ticket, což je vlastní vystavený Ticket, v něm vidíme Server Name (SPN), Realm a šifrovanou část.
Následují ukázky jednotlivých packetů zachycených programem Wireshark.
KRB-AS-REQ - požadavek na získání TGT
Uživatel test2 se obrací na svoje DC (KDC) a požaduje TGT, komunikace je v doméně (Realmu) firma2.local.
KRB-AS-REP - vrácení TGT
Doménový řadič mu odesílá požadovaný ticket.
KRB-TGS-REQ 1 - požadavek na získání Service Ticket
Kvůli připojení na web www.firma1.local klient požaduje Service Ticket, v žádosti posílá svoje TGT a obrací se na svoje DC v doméně firma2.local.
KRB-TGS-REP 1 - odpověď s Ticketem
Řadič zjistil, že se dané SPN nenachází v jeho doméně, ale v sousední firma1.local. Vrací Ticket pro komunikaci s KDC v doméně firma1.local.
KRB-TGS-REQ 2 - požadavek na získání Service Ticket
Klient odesílá požadavek na Service Ticket na řadič v doméně firma1.local, v žádosti využívá TGT pro tuto doménu.
KRB-TGS-REP 2 - odpověď s Ticketem
V odpovědi dostává správný Service Ticket.
KRB-AP-REQ - odeslání Ticketu na server
Klient odesílá GET požadavek na webový server. V HTTP hlavičce je Kerberos autentizace KRB-AP-REQ (Service Ticket) pomocí protokolu GSS-API.
Odkazy
Některé materiály, z kterých jsem čerpal, jsou uvedeny níže. Jde o články Microsoftu a většinou jsou staršího data (věnují se Windows Server 2000 či 2003), ale věřím, že se v této oblasti nic nezměnilo.
- Active Directory
- Uživatelské účty
- Nalezení DC
- Kerberos
- SSO cross forest
Komentáře
Hezky srozumitelne vysvetleno. Diky