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í souborprinc
- 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\sAMAccountNamemapOp
- Mapping Operation určuje, jestli se SPN přidává (add
) nebo nastavuje (set
), čímž odstraní všechny předchozí SPN záznamypass
- 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ý typKRB5_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 Namecrypto
- 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 hodnotuAll
, 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.
Zatím zde nejsou žádné komentáře.