CZ 
05.11.2024 Miriam VÍTEJTE V MÉM SVĚTĚ

An English translation is available for this article. Pro tento článek je dostupný anglický překlad.
Kerberos part 9 - Keytab (key table) file

Kerberos část 9 - Keytab (key table) soubor

| Petr Bouška - Samuraj |
V tomto díle navážeme na předchozí, kde jsme popisovali SSO pro webovou aplikaci. Protože uvažujeme jiné webové servery než Microsoft IIS, tak si detailně popíšeme vytváření keytab souboru, který se v tom případě využívá. Keytab soubor nám nahradí zařazení a komunikaci serveru s doménovým řadičem.
zobrazeno: 14 353x (14 291 CZ, 62 EN) | Komentáře [0]

Co je to keytab

Běžně můžeme SSO použít pro Microsoft služby, které běží na počítači zařazeném do domény. V tom případě sdílí počítač i AD heslo, z kterého si vytvoří Secret Key. Pomocí tohoto klíče pak šifrují vzájemnou komunikaci. Pokud chceme využít SSO na službě, která nemůže komunikovat s DC, třeba běží na Linuxu, není v doméně, apod. Tak stačí, když bude znát Secret Key pro rozšifrování komunikace (musí ho sdílet s DC).

Keytab (tabulka klíčů) je soubor, který obsahuje SPN a jim odpovídající šifrovací klíče (Secret Key). Může se použít pro rozšifrování komunikace při SSO a tedy ověření klienta přistupujícího ke službě. Je také možné jej použít pro autentizaci do domény (aniž by se muselo zadávat jméno a heslo). V keytab souboru může být jeden nebo více SPN/klíčů.

Pomocí keytab souboru nahrazujeme to, že je počítač zařazen do domény (a tím má k dispozici šifrovanou komunikaci s DC). V souboru máme klíč pro šifrování. Samozřejmě potřebujeme i odpovídající údaj v doméně. To se provádí tak, že se vytvoří servisní uživatelský účet (teoreticky lze použít i počítačový, ale mohou být různé problémy, takže je lepší zůstat u uživatelského) a na tento účet se registruje SPN pro službu. Účet musí používat stejné heslo jako keytab soubor.

Pozn.: Z toho, co jsme si řekli, je jasné, že je třeba myslet na bezpečnost. Keytab soubor představuje uživatelské credentials, pomocí něj se můžeme přihlásit do domény. Takže by servisní účet neměl mít žádná speciální práva (pro účel našeho použití žádná nepotřebuje) a přístup ke keytab soubor by měl být co nejvíce zabezpečen.

Vytvoření Keytab souboru

Jako součást Windows Server 2008 a novějších (nebo v Support Tools u starších) nalezneme řádkový příkaz ktpass. Tento příkaz provádí několik operací. Nejprve registruje SPN (Service Principal Name) dle zadaného Principal Name a účtu. Defaultně také nastaví na účtu UPN (User Principal Name) na hodnotu Principal Name. Změní heslo na účtu a toto použije i pro keytab soubor. Nakonec vytvoří výstupní keytab soubor.

Pozn.: Některé verze ktpass na Windows Server 2003 měli bug, postižena je verze 5.2.3790.1830, takže je potřeba použít novější.

Níže je uveden příklad vytvoření keytab souboru pro webový server, nejprve obecná forma a poté s ukázkovými hodnotami.

Pozn.: Stejně, jako většinu jiných příkazů, musíme ktpass spouštět pod účtem s dostatečnými právy a jako administrátor (cmd Run as administrator).

ktpass -out jméno-souboru -princ HTTP/hostname@AD-DOMÉNA -mapUser AD-účet -mapOp set -pass * -ptype KRB5_NT_PRINCIPAL -kvno 0
ktpass -out mujweb.keytab -princ HTTP/mujweb.firma.local@FIRMA.LOCAL -mapUser firma\mujweb-sso -mapOp set -pass * -ptype KRB5_NT_PRINCIPAL -kvno 0

Ve výše uvedeném příkladu používáme následující parametry:

  • out - output, tedy výstupní soubor
  • princ - Principal Name je závislé na velikosti písmen, obsahuje SPN (službu/adresu) a Kerberos Realm, tedy určení domény v které se nachází účet (zapisuje se velkými písmeny)
  • mapUser - Mapping User - doménový účet, na který se SPN registruje, obecně se má jednat o uživatelský účet, ale v některých případech lze použít i účet počítače, můžeme zadat UPN, ale bezpečnější je použít formu domena\sAMAccountName
  • mapOp - Mapping Operation určuje, jestli se SPN přidává (add) nebo nastavuje (set), čímž odstraní všechny předchozí SPN záznamy
  • pass - Password - pro vytvoření keytab souboru musíme zadat heslo, které se použije pro generování klíče a nastaví se na účet. Hvězdička znamená, že se na zadání hesla dotáže při vytváření. Zajímavé je, že pokud použijeme hvězdičku, tak se následně zadaným heslem do účtu nepřihlásíme, ale pokud heslo zadáme rovnou za parametr, tak se s ním k účtu můžeme přihlásit. Je třeba myslet na naši politiku hesel, pokud by ji zadané heslo nevyhovovalo, tak při nastavování vrátí chybu (Password set failed).
  • ptype - Principal Type nastavujeme na obecný typ KRB5_NT_PRINCIPAL
  • kvno - Key Version Number představuje verzi klíče, která se zvyšuje při každé změně hesla a je uložena u účtu. Pomocí parametru můžeme nastavit určitou hodnotu. Verze se ukládá i do keytabu (pokud neurčíme parametrem, tak se použije aktuální z AD) a při použití se porovnává s hodnotou na účtu. V keytabu je možno ji nastavit na 0 a pak se nekontroluje.

Použít můžeme řadu dalších parametrů, zajímavé z nich jsou:

  • target - určujeme, jaký doménový řadič se má použít, když nezadáme, tak se automaticky detekuje podle realmu v Principal Name
  • crypto - určujeme šifrovací metodu, dnes defaultní je RC4-HMAC-NT, pro zpětnou kompatibilitu DES-CBC-CRC, DES-CBC-MD5 a další třeba AES256-SHA1, pro nejširší možnosti můžeme použít hodnotu All, která zajistí, že se vygeneruje tiket pro každou šifru (do jednoho keytabu). Pokud bychom měli starou verzi ktpass, tak nemusí podporovat RC4-HMAC-NT a keytab nebude fungovat.
  • setUpn - pokud přidáme parametr -setUpn, tak nedojde k nastavení UPN na účtu

Příklad vytvoření keytabu výše, odpovídá způsobu, jak je popisován v hodně článcích na internetu. Dochází při něm ke změně UPN na uživatelském účtu. Nemyslím, že je to k něčemu potřeba (při Kerberos autentizaci se hledá SPN a ne UPN), takže je možné využít parametr -setUpn. Provedl jsem řadu testů a vše je funkční. Takže níže je příklad použití ktpass, který mi připadá optimální.

ktpass -out mujweb.keytab -princ HTTP/mujweb.firma.local@FIRMA.LOCAL -mapUser firma\mujweb-sso -mapOp set -pass heslo -ptype KRB5_NT_PRINCIPAL -kvno 0 -setupn -crypto All

Doplněno 8. 2. 2024

UPN je důležité, když využíváme AES šifrování. Pro typ šifrování RC4-HMAC se při vytváření šifrovacích klíčů vychází pouze z hesla. Ale pro AES128-CTS-HMAC-SHA1-96 nebo AES256-CTS-HMAC-SHA1-96 se přidává sůl (Salt). Ta je tvořena z Kerberos Realm (jméno domény velkými písmeny) a uživatelského jména (část UPN před zavináčem). Klíče se vytváří při nastavení hesla pro všechny podporované typy šifrování a uloží se k účtu v AD.

Když se vytváří Keytab soubor, tak se do něj vytváří šifrovací klíče a ty musí odpovídat klíčům u účtu. Příkaz ktpass vezme zadané parametry a z nich se vytvoří klíče v souboru (nic se nenačítá z účtu v AD). Použije se parametr Principal Name (princ), z kterého se bere uživatelské jméno a doména, a heslo.Problém je, že princ také představuje Service Principal Name (SPN), podle kterého se hledá služba. Aby byly klíče v Keytabu a AD stejné, tak musíme změnit UPN účtu (což je defaultní chování bez parametru setupn).

Je tu ještě jiná možnost, kdy můžeme zachovat UPN. Při vytváření Keytab souboru můžeme použít parametr -rawsalt FIRMA.LOCALusername. Zde zadáme sůl, která se použije při vytváření klíčů v Keytabu.

ktpass -out mujweb.keytab -princ HTTP/mujweb.firma.local@FIRMA.LOCAL -mapUser firma\mujweb-sso -mapOp set -pass heslo -ptype KRB5_NT_PRINCIPAL -kvno 0 -crypto AES256-SHA1 -rawsalt FIRMA.LOCALmujweb-sso -setupn 

Vytvoření Keytab souboru s více SPN

Na aplikačním serveru můžeme většinou použít pouze jeden keytab soubor. Přitom může nastat situace, kdy potřebujeme použít více SPN. Například, když chceme, aby na webovém serveru fungovalo SSO pro standardní adresu (FQDN - mujweb.firma.local) a pro nějaký alias (www.firma.local).

Můžeme to udělat tak, že nejprve vytvoříme keytab pro první SPN, které nastavíme (set) na uživatelský účet.

C:\>ktpass -out mujweb.keytab -princ HTTP/mujweb.firma.local@FIRMA.LOCAL -mapUser firma\mujweb -mapOp set -pass * -ptype KRB5_NT_PRINCIPAL -kvno 0 -setupn
Targeting domain controller: dc.firma.local
Using legacy password setting method
Successfully mapped HTTP/mujweb.firma.local to mujweb.
Type the password for HTTP/mujweb.firma.local:
Type the password again to confirm:
Key created.
Output keytab to mujweb.keytab:
Keytab version: 0x502
keysize 72 HTTP/mujweb.firma.local@FIRMA.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0xad04eaf7d0d0a63adf0596c0788e910c)

Poté zavoláme příkaz znovu, na vstupu mu dáme první keytab soubor, přidáme druhé SPN, změníme Mapping Operation na add. Tak se vytvoří keytab, který obsahuje dvě SPN. Když používáme stejný uživatelský účet, tak bychom v obou případech měli zadat stejné heslo.

C:\>ktpass -in mujweb.keytab -out mujweb.keytab -princ HTTP/www.firma.local@FIRMA.LOCAL -mapUser firma\mujweb -mapOp add -pass * -ptype KRB5_NT_PRINCIPAL -kvno 0 -setupn
Existing keytab:

Keytab version: 0x502
keysize 72 HTTP/mujweb.firma.local@FIRMA.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0xad04eaf7d0d0a63adf0596c0788e910c)
Targeting domain controller: dc.firma.local
Using legacy password setting method
Successfully mapped HTTP/www.firma.local to mujweb.
Type the password for HTTP/www.firma.local:
Type the password again to confirm:
Key created.
Output keytab to mujweb.keytab:
Keytab version: 0x502
keysize 72 HTTP/mujweb.firma.local@FIRMA.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0xad04eaf7d0d0a63adf0596c0788e910c)
keysize 59 HTTP/www.firma.local@FIRMA.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0xad04eaf7d0d0a63adf0596c0788e910c)

Identicky můžeme použít dva různé účty, které budou mít nastaveny každý svoje SPN a vytvořit spojený keytab soubor.

Odkazy

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. Popisuje i řadu souvisejících věcí, které jsou potřeba pro pochopení fungování Kerberos Single Sign-On (SSO).

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

Zatím zde nejsou žádné komentáře.

Přidat komentář

Vložit tag: strong em link

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