www.SAMURAJ-cz.com 

16.12.2017 Albína Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Kerberos část 7 - Troubleshooting Kerberos SSO

Upraveno 29.06.2014 19:13 | vytvořeno 03.05.2014 11:30 | Samuraj - Petr Bouška |
V článku se podíváme na nějaké možnosti hledání problémů, když nastavíme Single Sign-On (SSO) autentizaci pomocí protokolu Kerberos a automatické přihlášení přesto nefunguje. Jako autentizační server uvažujeme AD doménový řadič. Většina možností je obecná, ale v praktických příkladech budeme uvažovat situaci, kdy jde o autentizaci k webové aplikaci z prohlížeče.

Pozn.: Tento článek jsem napsal asi před dvěma měsicí a nyní jsme pouze změnil jeho název z původního Troubleshooting Kerberos Single Sign-On a zařadil jej do nové série o Kerberos SSO.

Pozn.: Určitě v tomto článku neřešíme všechny možnosti. Například se zde vůbec nevěnujeme síťové úrovni – jestli komunikace po síti může doputovat na správný server, tedy třeba jestli není cestou blokovaný port 88 pro Kerberos, apod.

Když chceme provádět troubleshooting nějaké oblasti, tak je většinou potřeba ji rozumět, jak funguje a jak probíhají jednotlivé operace. Oblast Kerberosu a SSO jsme si popsali v předchozích dílech seriálu a zde budeme předpokládat znalost termínů a vlastního principu.

Pozn.: Článek popisuje testy v pořadí, jak autentizace probíhá. V praxi je určitě výhodnější nejdříve ověřit, jestli klient získal Service Ticket pro službu. Pokud ne, tak hledat problém v získání ticketu, pokud ano, tak na straně aplikačního serveru.

Rozdělení SSO procesu na části

V případě protokolu Kerberos je SSO jeho nativní vlastnost, takže vlastně vždy jde o Kerberos autentizaci nebo jinak řečeno, při autentizaci se vždy využívá SSO.

Z důvodů identifikace problémů si můžeme proces SSO rozdělit na tři části.

  • vyjednání Kerberos autentizace – síťová služba (server) musí vyjednat autentizaci a vyžadovat Kerberos, klient jej musí podporovat
  • získání Service Ticket – klient musí získat Service Ticket pro danou službu od KDC (DC)
  • odeslání a zpracování ticketu – klient pak musí odeslat autentizační údaje (včetně Service Ticket) na síťovou službu (server) a ten je musí zpracovat = dojde k přihlášení

Vyjednání Kerberos autentizace

Asi to zní jasně, že síťová služba, ke které se chceme přihlásit, musí podporovat Kerberos a mít jej nastavený. Stejně tak klient, kterým se přihlašujeme, musí mít povoleno použití Kerberosu. Přesto často bývá problém hned v tomto bodě.

Server požaduje Kerberos autentizaci

Aby server (síťová služba) mohl použít Kerberos, tak musí být buď členem AD domény, nebo se může vytvořit ruční záznam pro tuto službu v AD a vyexportovat klíč (secret key služby = keytab soubor). Tento klíč pak nastavíme aplikačnímu serveru nebo aplikaci, dle toho kdo Kerberos autentizaci provádí.

Pokud se připojujeme na webovou stránku, která vyžaduje Kerberos autentizaci, tak nám tato stránka odešle v hlavičce autentizační požadavek Negotiate (mechanizmus SPNEGO), aby se vyjednal autentizační protokol. Pro kontrolu, že tomu tak je, si můžeme prohlédnout hlavičky v prohlížeči nebo použít program Wireshark (asi nejznámější analyzátor síťového provozu Wireshark, případně použít nějaký jiný) pro zachycení celé komunikace.

Ve Wiresharku můžeme zachytit komunikaci mezi stanicí a webovým serverem (zachytávat můžeme přímo na stanici). Při požadavku prohlížeče na zobrazení určité stránky (tedy HTTP GET), by měla přijít odpověď (Response), která v hlavičce obsahuje HTTP/1.1 401 Authorization Required a WWW-Authenticate: Negotiate.

Wireshark - WWW-Authenticate: Negotiate

K podobným údajům se dostaneme i z webového prohlížeče. Internet Explorer obsahuje Developer Tools, které otevřeme stiskem F12. Přepneme se na záložku Network, začneme zachytávat komunikaci a provedeme přístup na stránku, v Details pak máme Request/Response headers (nyní nás zajímá odpověď serveru, tedy response).

IE Developer Tools - WWW-Authenticate: Negotiate

Ve Firefoxu můžeme obdobně využít Add-on Live http Headers nebo mnohem rozsáhlejší Firebug.

Pokud chceme přistoupit k nějaké síťové službě, tak v rámci daného protokolu (třeba SMB) přijde odpověď, kde je zabalená komunikace GSS-API a dojde k vyjednání autentizace. Princip je stejný jako u webové aplikace.

Klient podporuje Kerberos autentizaci

Klient dostane požadavek na autentizaci, v případě webové aplikace na vyjednání autentizace. Musí být splněno několik podmínek, aby mohl správně odpovědět. Nejprve si uvedeme trochu teorie.

Microsoft používá Integrated Windows Authentication (IWA), jinak řečeno také HTTP Negotiate Authentication, hlavně pro webové aplikace. IWA podporuje protokoly SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism), Kerberos v5 a NTLM (NT LAN Manager). Na webu se používá SPNEGO, tedy Negotiate, kde se vyjedná použití buď upřednostněného Kerberosu nebo NTLM (pokud se Kerberos nepovede). Windows poskytují API pro bezpečnostní operace SSPI (Security Support Provider Interface), což je proprietární varianta standardního GSSAPI (Generic Security Service Application Program Interface). SSPI používá NTLMSSP nebo Kerberos SSP. Autentizaci uživatele ve Windows zajišťuje Local Security Authority (LSA), která volá SSPI.

Kerberos v5 požaduje, aby měl klient přímé připojení do Active Directory. Při autentizaci vůči službě se vždy využije SSO, nikdy se nezadává jméno a heslo. Pokud není DC dostupný, tak se použije (jinak nedoporučovaný) protokol NTLM, který využívá jména a hesla (při autentizaci se odesílá hash). Že na klientovi neproběhla Kerberos autentizace, můžeme poznat dle toho, že se zobrazí modální okno pro zadání jména a hesla (případně můžeme na serveru vidět, pokud logujeme proces autentizace, že se provádí NTLM a ne Kerberos).

Pozn.: V určitých situacích se může přihlašovací dialog zobrazit, i když Kerberos autentizace proběhla. Je to v situaci, kdy přihlášený uživatel nemá oprávnění přistoupit ke službě (neprošel autorizací), takže máme možnost zadat credentials jiného uživatele. Ve webových aplikacích se většinou ošetřuje jinak, takže se případně zobrazí přihlašovací formulář a ne modální okno.

Okno Windows Security - NTLM autentizace

Aby mohla proběhnout Kerberos autentizace, tak klient musí být přihlášený k DC a tedy mít platný TGT. V případě webového prohlížeče musí být pro danou adresu serveru povolen Kerberos. To u Internet Exploreru znamená zařazení adresy nebo celé domény mezi Local Intranet, u Firefoxu nastavení proměnné network.negotiate-auth.trusted-uris. To jsme podrobněji popsali v článku Kerberos SSO - nastavení Internet Exploreru a Firefoxu. Důležitá je i forma zápisu domén či adresy (pokud třeba nakonec zadáme navíc znak /, tak nám nebude fungovat).

Můžeme zkusit několik testů na klientovi. Například ověřit, jestli klient získá adresu doménového řadiče.

C:>nltest /dsgetdc:firma.local
              DC: \\dc.firma.local
         Address: \\10.0.0.10
        Dom Guid: a9c7691a-3cf9-41dd-a35d-6bbf0316c84c
        Dom Name: firma.local
     Forest Name: firma.local
    Dc Site Name: Praha
   Our Site Name: Praha
           Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS
   The command completed successfully
C:\>nltest /dclist:firma.local
   Get list of DCs in domain firma.local' from '\\dc.firma.local'
   DC.firma.local [PDC]   [DS] Site: Praha
   DC2.firma.local        [DS] Site: Praha
   DC3.firma.local        [DS] Site: Plzen
   The command completed successfully

Informace o uživatelském Kerberos Realm a tedy nastavení přihlášení do domény (druhý příklad ukazuje stanici mimo doménu).

C:>ksetup /dumpstate
   default realm = firma.local (NT Domain)
   No user mappings defined.
C:>ksetup /dumpstate
   Machine is not configured to log on to an external KDC.  Probably a workgroup member
   Failed to create Kerberos key: 5 (0x5)

Nebo rovnou ověřit, že klient získal TGT a je tedy korektně ověřen u DC.

C:>klist tgt
Current LogonId is 0:0x4c976

Cached TGT:

ServiceName        : krbtgt
TargetName (SPN)   : krbtgt
ClientName         : bouska
DomainName         : FRIMA.LOCAL
TargetDomainName   : FRIMA.LOCAL
AltTargetDomainName: FRIMA.LOCAL
...

Získání Service Ticket

Když klient korektně vyjedná, že má použít Kerberos autentizaci, tak se obrátí na svoje KDC (tedy doménový řadič) a snaží se získat Service Ticket pro SPN serveru.

Kontrola Kerberos ticketů

Můžeme provést jednoduchou kontrolu, jestli klient získal požadovaný Service Ticket nebo ne. Pokud jej má, tak bude problém buď v předání na server, nebo zpracování serverem. Pokud ticket v cachi není, tak musíme zkoumat proces získání. Pomůže nám příkaz klist, který vypíše všechny tickety, které klient získal. Jednotlivé tickety jsou číslovány a u každého je uvedena položka Server, která obsahuje SPN, a Client, kde je identita pro kterou byl ticket vystaven.

C:\>klist
Current LogonId is 0:0x4c2b5
Cached Tickets: (10)

#2>  Client: bouska @ FIRMA.LOCAL
     Server: HTTP/www.firma.local @ FIRMA.LOCAL
     KrbTicket Encryption Type: RSADSI RC4-HMAC(NT)
     Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
     Start Time: 4/25/2014 12:53:44 (local)
     End Time:   4/25/2014 22:18:52 (local)
     Renew Time: 5/2/2014 12:18:52 (local)
     Session Key Type: RSADSI RC4-HMAC(NT)
     Cache Flags: 0
     Kdc Called: dc.firma.local

Případně můžeme cache tiketů vymazat, abychom viděli, že jsme jej opravdu získali při našem pokusu o přihlášení.

C:\>klist purge

Current LogonId is 0:0x4c956
   Deleting all tickets:
   Ticket(s) purged

Porovnání šifrování v ticketu

Pokud jsme získali správný tiket, tak ještě můžeme zkontrolovat jeho šifrovací algoritmus (třeba v příkladu výše jde o RC4-HMAC-NT) s šifrou použitou u keytab souboru. Pokud nevíme, jaká šifra se při vytváření keytab souboru použila, tak ji můžeme vypsat (příklad obsahuje opět RC4-HMAC-NT).

C:\>ktpass -in server.keytab
Existing keytab:

Keytab version: 0x502
keysize 75 HTTP/www.firma.local@FIRMA.LOCAL ptype 1 (KRB5_NT_PRINCIPAL)
vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0x2ceaf8e1e3e9bd18967c1fb09bb0b8da)

WARNING: No principal name specified.

Kontrola SPN záznamu

Pokud se nepodařilo získat Service Ticket, tak můžeme ověřit, že v doméně existuje požadovaný SPN záznam.

C:\>setspn -Q HTTP/server.firma.local
Checking domain DC=firma,DC=local
CN=Server SSO,OU=Objekty,DC=firma,DC=local
   HTTP/server.firma.local

Existing SPN found!

Případně můžeme hledat pomocí různých filtru.

setspn -Q HTTP/*    
setspn -Q */server.firma.local

Standardně setspn hledá pouze v rámci lokální domény, pokud chceme hledat v celém lese, tak musíme přidat přepínač -f, případně -t domain pro hledání v určité doméně.

C:\>setspn -F -Q HTTP/*
Checking forest DC=firma,DC=local
...

Příkaz setspn nám takto může zjistit informace o existujících SPN v doméně, ale jeho primární funkce je nastavení SPN na nějaký účet v AD. Dále je příklad, jak SPN nastavit.

setspn –S HTTP/server.firma.local firma\účet

Pozn.: Pro webové aplikace, které neběží na IIS, bychom neměli potřebovat tento příkaz, protože používáme ktpass pro vytvoření keytab souboru a ten zároveň nastaví SPN.

Získání ticketu z DC

Ve chvíli, když se připojujeme k síťové službě a má se získat Service Ticket, můžeme zachytit komunikaci mezi stanicí a DC pomocí Wiresharku. Do filtru zadáme slovo kerberos a tím se nám vyfiltruje komunikace, která nás zajímá. V komunikaci bychom měli vidět packet Kerberos TGS-REQ a případně TGS-REP. Když se podíváme do požadavku, tak vidíme pro jaký server Server Name (Service and Instance) a v jakém Realm se požaduje ticket. Musí to odpovídat SPN, které máme v AD. Při určitém použití DNS aliasů zde můžeme vidět jinou adresu a pak se nenalezne SPN.

Wireshark - požadavek na Service Ticket (KRB-TGS-REQ)

Odeslání a zpracování ticketu

Dostali jsme se do fáze, že klient získal správný Service Ticket a přesto neproběhne autentizace. Pak musíme ověřit, že se odesílají správné údaje na server a případně, že on správně data zpracovává.

Odeslání autentizace na server

Tak jak jsme zachytávali komunikaci, jestli přichází požadavek na Kerberos autentizaci, tak můžeme ověřit, jestli z klienta odchází Kerberos AP-REQ packet. U webové aplikace je zabalen do HTTP a je součástí hlavičky. Pokud si zobrazíme hlavičky v prohlížeči, tak pouze uvidíme, že v hlavičce je hodnota Authorization: Negotiate a pokračuje šifrovaný text. Wireshark jej umí rozkódovat a detailně zobrazit.

Wireshark - autentizace skrze HTTP (KRB-AP-REQ)

Celý proces SSO pro webovou stránku vidíme na zachycené komunikaci níže.

  • klient odeslal GET požadavek na zobrazení stránky, vrátila se mu odpověď, že je třeba vyjednat autentizaci (HTTP/1.1 401 Authorization Required)
  • protože byla vymazána cache ticketů, tak nejprve proběhlo získání TGT od DC (požadavek KRB-AS-REQ, odpověď KRB-AS-REP)
  • následně získání Service Ticketu od DC (požadavek KRB-TGS-REQ, odpověď KRB-TGS-REP)
  • v dalším GET požadavku na server se odeslaly autentizační údaje (byla tam zabalen požadavek KRB-AP-REQ)
  • tím došlo k přihlášení a byla zobrazena (vrácena) stránka
Wireshark - packety procesu Kerberos SSO

Testování Keytab souboru

Pokud řešíme autentizaci pro webovou aplikaci běžící na ne-MS webovém serveru, tak patrně využíváme Keytab soubor. Ve chvíli, kdy se ticket odešle na server, ale ten jej nedokáže zpracovat, může být problém právě v Keytab souboru. Na serveru se může zalogovat třeba chyba GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag). V takové situaci můžeme otestovat Keytab soubor a jeho fungování pro dané SPN.

K tomu slouží příkaz kinit, který nalezneme v Linuxu nebo i na Windows, pokud nainstalujeme JRE (je součástí Javy). Dopředu si ale musíme připravit konfigurační soubor krb5.ini a nahrát jej do C:\Windows (nejjednodušší způsob). Jeho obsah může být různý, ale asi minimální konfigurace je následující.

[libdefaults]
   default_realm = FIRMA.LOCAL
   default_tkt_enctypes = rc4-hmac
   default_tgs_enctypes = rc4-hmac
[realms]
   FIRMA.LOCAL = {
      kdc = dc.firma.local:88
   }
   [domain_realm]
   .firma.local = FIRMA.LOCAL
   firma.local = FIRMA.LOCAL

Následně můžeme použít příkaz kinit, kde zadáme náš Keytab soubor a SPN včetně Realmu (domény). Pokud je vše v pořádku, dostaneme následující odpověď.

C:\>kinit -k -t server.keytab -f "HTTP/www.firma.local@FIRMA.LOCAL"
New ticket is stored in cache file C:\Users\bouska\krb5cc_bouska

V případě, že ne, tak dostaneme chybu.

C:\>kinit -k -t server.keytab -f "HTTP/www.firma.local@FIRMA.LOCAL"
Exception: krb_error 0 No supported key found in keytab for principal HTTP/www.firma.local@FIRMA.LOCAL No error
KrbException: No supported key found in keytab for principal HTTP/www.firma.local@FIRMA.LOCAL
   at sun.security.krb5.internal.tools.Kinit.<init>(Unknown Source)
   at sun.security.krb5.internal.tools.Kinit.main(Unknown Source)

Pokud bychom neměli k dispozici soubor krb5.ini, tak dostaneme chybu, která o tom informuje.

Exception: krb_error 0 Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified) No error

Kontrola serveru

Pokud ověříme, že celý proces autentizace korektně funguje až k poslání údajů na server, tak zbývá jediná možnost, hledat problém při zpracování ticketu serverem. Pokud jde o webovou aplikaci, tak se můžeme podívat do logu aplikačního serveru (případně nastavit podrobnější logování) či aplikace (pokud provádí autentizaci přímo ona). Pokud jde o nějakou službu Windows, tak můžeme hledat v Event Logu systému, případně debugovat Kerberos.

Jedna z chyb, která může nastat, je také překročení velikosti autentizačního ticketu. V něm se odesílají informace o uživateli, které obsahují seznam jeho skupin. U webové aplikace může dojít k překročení velikosti http hlavičky, u síťové služby velikosti bufferu pro token. Více informací je v článku Kerberos autentizace a členství ve skupinách.

Debuging Kerberosu

Jenom jako poznámku na okraj si zmíníme možnost, zapnout debugování či podrobnější logování protokolu Kerberos.

Kerberos Event Logging zapneme vytvořením hodnoty LogLevel = 1 typu REG_DWORD v registrech HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters. Popis je v KB How to enable Kerberos event logging. Na stejném místě můžeme vytvořit další dvě REG_DWORD hodnoty LogToFile = 1 a KerbDebugLevel = c0000043 (nebo c3). Nějaké informace nalezneme Users experience authentication issues nebo zajímavém videu Kerberos Troubleshooting.

zobrazeno: 7805krá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] Pavel

    Skvělý článek, díky :-)

    Pátek, 09.05.2014 08:50 | 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