Základní popis: Kerberos je autentizační protokol pro důvěryhodné stroje na nedůvěryhodné síti. Autentizační server v Kerberovi je označován jako Key Destribution Center (KDC). Tento se skládá ze tří hlavních částí: databáze, Autentication Server (AS) a Ticket Granting Server (TGS). Cílem Kerbera je poskytování autentizačních služeb klientům, přičemž žádné klientské heslo není v rámci protokolu přenášeno (ani v šifrované podobě). Pro komunikaci mezi KDC a klienty je v Kerberovi použita pouze symetrická kryptografie. Kerberos vyžaduje zadání hesla po klientovi jen jednou za session (tzv. single sign on)
Proces ověření identy, např prokázání znalosti hesla, vlastnicví privátního klíče apod
Autentizace dvou stran prostřednictím důvěryhodné třetí strany. V našem případě je onou důvěryhodnou stranou právě Kerberos.
Autentizační doména. Server může přímo autentizovat pouze klienty v rámci svého realmu. Autentizace může probíhat i mezi objekty v různých realmech prostřednictím cross authentication. Uživatel/služba patří do realmu právě když sdílí heslo s autentizačním serverem. Název realmu je citlivý na velikost písmen, podle konvencí bývá obvykle psán pouze velkými písmeny.
Název uživatele nebo služby uložený v databázi autentizačního serveru ve tvaru:
jméno[/Instance]@REALM.
Např user@EXAMPLE.COM imap/mbox.example.com@EXAMPLE.COM
Lítek je část zprávy, kterou se klient autentizuje vůči aplikaci. Tato část je šifrována klíčem, který mezi sebou sdílí aplikace a KDC - klient není schopen jeho obsah číst nebo ovlivnit. Pro aplikaci je správný lístek zárukou, že identitu klienta ověřil autentizační server. Obsahem lístku je session key, principal klienta, principal aplikace, čas vystavení, doba platnosti a volitelne adresy, ze kterých se klient může přihlásit.
AS_REQ - klient žádá autentizační server o TGT (Ticket granting ticket). Součástí requestu je principal klienta a služby ke které se chce autentizovat. Volitelně klient uvádí IP adresy, ze kterých bude službu využívat. Poslední částí zprávy je lifetime. Tato zpráva není šifrovaná.
AS_REP - odpověď KDC klientovi. KDC nejprve ověřuje existenci klienta a služby v databázi. Potom vygeneruje náhodný klíč SK_TGS, který bude sdíleným tajemstvím mezi klientem a TGS. Dále server vytvoří TGT, obsahuje (principal klienta a krbtgt/REALM@REALM, časovou známku, lifetime, IP adresy). Klientovi je odeslán SK_TGS, časová známka, životnost a principal služby, o kterou žádal. Tato část je šifrována klíčem K_USER, který spolu sdílejí klient a KDC. Zbytek zprávy tvoří TGT, který je šifrován klíčem K_TGS, který zná TGS, ale nikoliv klient.
Po obdržení AS_REP je po klientovi vyžádáno zadání hesla. Z tohoto hesla a soli uložené na disku je odvozen klíč K_USER, klient dešifruje část zprávy AS_REP a získá klíč SK_TGS
TGS_REQ - žádost klienta o lístek. Klient vytvoří tzv Authenticator (pricipal, časové razítko) šifrovaný klíčem SK_TGS. Odeslaná zpráva obsahuje Authenticator, pricipal služby, životnost a TGT.
TGS ověří validitu TGT (requset přišel od stejného klienta jako je uvedený v TGT, sedí IP adresy, časová razítka jsou platná). Poté vygeneruje lístel složený z: pricipal klienta a služby, čaasové razítko, životnost a nově vygerovaný klíč SK_Service. Tento lístek je zašifrován klíčem K_Service - sdílený klíč mezi TGS a službou.
TGS_REP - obsahuje SK_Service, pricipal služby, časové razítko a životnost. Vše je šifrováno klíčem SK_TGS. Zbytek zprávy tvoří lístek.
Klient dešifruje TGS_REP a získá klíč SK_Service
AP_REQ - nyní už klient prokazuje svou totožnost aplikaci. Vytvoří Authenticator (principal klienta, časová známka) zašifrovaný pomocí SK_Service. Aplikaci pošle tento Authenticator společně s razítkem.
Aplikace dešifruje lískek klíčem K_Service, který je jejím sdíleným tamjemstívm s TGS. Ověří, že principal klienta v Authenticatoru odpovídá obsahu lístku. Dále ověřuje platnost časových razítek a případně IP adresu klienta. Toto je
$ORIGIN foobar.com.
_kerberos TXT "EXAMPLE.COM"
kerberos CNAME daisy
kerberos-1 CNAME use-the-force-luke
kerberos-2 CNAME bunny-rabbit
_kerberos._udp SRV 0 0 88 daisy
SRV 0 0 88 use-the-force-luke
SRV 0 0 88 bunny-rabbit
_kerberos-master._udp SRV 0 0 88 daisy
_kerberos-adm._tcp SRV 0 0 749 daisy
_kpasswd._udp SRV 0 0 464 daisy
Poznámka: podle doporučení MIT by se primární KDC měl jmenovat 'kerberos' a sekundární 'kerberos-x', jako v příkladu.
kadmin.local: add_principal pv090 kadmin.local: list_principleskinit - nástroj pro získání TGT
#klist Valid starting Expires Service principal 08/11/2014 16:39 09/11/2014 16:39 krbtgt/PROTO08.LAB.FI.MUNI.CZ@PROTO08.LAB.FI.MUNI.CZkdb5_util - nástroj pro údržbu databáze Kerbera
kdb5_util dump /root/dumpkprop - nástroj pro propagaci databáze kpass - nástroj pro změnu uživatelova hesla
Konfigurace je umístěna na v etc/krb5.conf, konfigurace KDC potom v /etc/krb5kdc (na Debianu).
Aby nebylo nutné při každém spuštění zadávat master password, kterým je šifrovaná databáze principalů, je tento klíč uložen v souboru stash
V situaci, kdy existuje jeden primární server a více sekundárních, je potřeba jejich databáze udržovat konzistentní. V terminologii Kerbera se tomuto procesu říká propagace. Pro propagaci je nutné vytvořit na obou serverech principal pro vzájemnou autentizaci (host service). Dále je nutné přenést master key, kterým jsou položky v databázi šifrovány. To lze udělat například šifrovaným přenosem souboru stash nebo vytvoření nové databáze se stejným heslem na slave serveru (při první propagaci bude přepsána).
#master kadmin: add_principal -randkey host/masterkdc.example.com kadmin: ktadd host/masterkdc.example.com #slave kadmin: add_principal -randkey host/slavekdc.example.com kadmin: ktadd host/slavekdc.example.com@EXAMPLE.COM echo host/masterkdc.example.com@EXAMPLE.COM > /etc/krb5kdc/kpropd.acl
Testování propagace databáze
kdb5_util dump /etc/krb5kdc/slave_datatrans kprop slavekdc.example.com
~]# kadmin -r A.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM ~]# kadmin -r B.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COMKlienti realmu A.EXAMPLE.COM se niní mohou autentizovat ve službách z B.EXAMPLE.COM. Tato vazba je pouze jednosměrná. Cross-realm authentication také může fungovat hierarchicky.
Cílem synchronizace je, jak název napovídá, snížit rozdíly v systémovém čase synchronizovaných strojů na akceptovatelnou úroveň.
Jde o hierarchický protokol pro synchrozaci času v počítačové síti. Jednotlivé úrovně se nazývají stratum X, kde X je celé číslo označující úroveň. NTP za maximální únosnou úroveń považuje stratum-15. Stratum-0 je tzv. referenční čas, podle kterého se synchronizují počítače na stratum-1 atd. S rostoucí úrovně roste nepřesnost. Úrovně se používají pro snížení zátěže. Na lokální síti lze dosáhnout přesnosti kolem 10 ms, v internetu potom do 100 ms. V české republice provozuje stratum-1 server například cesnet (ntp.cesnet.cz ).
Pokud NTP zjistí, že je potřeba provést korekci systémové času, mohou nastat při případy. Pokud je rozdíl jen malý, systémový čas upraví na referenční. Pro větší rozdíly na nějakou dobu začne NTP synchronizaci odmítat a upraví tik vnitřních hodin tak, aby se čas po malých kouscích přiblížil k referenčnímu. Pro ještě větší rozdíly dojde ke skokové korekci. Speciální případ nastává při obrovských nepřesnostech, které NTP vyhodnotí jako chybu.
NTP komunikuje přes TCP/UDP na portu 123. Pro synchronizaci NTP odesílá časové známky, které jsou tvořeny dvěma 32-bitovými čísly. Prvních 32 bitů značí počet sekund od počátku epochy (pozn. NTP epocha začala 1.1.1900, ne 1970), zbylých 32 bitů reprezentuje desetinou část sekundy.
NTP pool je dynamická množina NTP veřejně dostupných NTP serverů (aktuálně asi 2900 ipv4 a 970 ipv6), které lze využít pro synchronizaci. Tyto servery patří do domény pool.ntp.org. Existují i subdomény obsahující servery podle geografické polohy (např. cz.pool.ntp.org). V DNS daného poolu se používá algoritmus Round Robin, který zajišťuje roznoměrné rozložení zátěže na všechny stroje zapojeného do poolu.
server 0.cz.pool.ntp.org server 1.cz.pool.ntp.org server 2.cz.pool.ntp.org server 3.cz.pool.ntp.org
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*mort.cihar.com 195.113.144.201 2 u 350 512 377 5.616 -18.163 13.905