www.SAMURAJ-cz.com 

14.12.2017 Lýdie Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Kerberos část 6 - Kerberos SSO mezi doménami

Upraveno 27.06.2014 15:10 | vytvořeno 23.04.2014 15:03 | Samuraj - Petr Bouška |
Dosud jsme se věnovali průběhu 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. 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.

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].

Princip Kerberos SSO

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 v rámci domény

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ámci lesa

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ě

SSO mezi doménami v různých lesech

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.

SSO mezi doménami v různých lesech a více domén

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í.

Wireshark - packety procesu Kerberos SSO mezi doménami

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.

Wireshark KRB-AS-REQ

KRB-AS-REP - vrácení TGT

Doménový řadič mu odesílá požadovaný ticket.

Wireshark KRB-AS-REP

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.

Wireshark KRB-TGS-REQ 1

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.

Wireshark KRB-TGS-REP 1

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.

Wireshark KRB-TGS-REQ 2

KRB-TGS-REP 2 - odpověď s Ticketem

V odpovědi dostává správný Service Ticket.

Wireshark KRB-TGS-REP 2

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.

Wireshark HTTP KRB-AP-REQ

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.

zobrazeno: 5629krát | Komentáře [1]

Autor:

Související články:

Kerberos protokol se zaměřením na SSO v AD DS

Nový seriál, který se podrobně věnuje protokolu Kerberos V5, hlavně v prostředí Microsoft Active Directory. Popíšeme si i řadu souvisejících věcí, které jsou potřeba pro pochopení fungování Kerberos Single Sign-On (SSO).

Active Directory a protokol LDAP

Správa počítačové sítě ala Microsoft, to je Active Directory. Jedná se o velice rozsáhlou skupinu technologií a služeb. Základem jsou adresářové služby, adresáře a komunikační protokol LDAP.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže. Pokud chcete poradit s nějakým problémem či diskutovat na nějaké téma, tak použijte fórum.

Komentáře

  1. [1] David_K

    Hezky srozumitelne vysvetleno. Diky

    Středa, 07.05.2014 14:24 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách