Pri autentizácii s použitím Kerberosu sa používateľ autentizuje voči konkrétnej službe na konkrétnom serveri prostredníctvom Kerberos KDC (viď nižšie) ako dôveryhodnej tretej strany. Ide teda o centralizovaný autentizačný systém. Heslo sa neposiela po sieti a používateľ ho musí zadať iba raz za session (SSO, viď nižšie). Využíva symetrickú kryptografiu. Je špecifikovaný v RFC4120 a naň naväzujúcimi RFC a môže byť využívaný ako na úrovni OS, tak na úrovni jednotlivých aplikácií. Tento referát pokrýva použitie na úrovni OS. Príklad, ako môže vyzera použitie vo webových aplikáciách, možno nájsť napríklad v BP autora.
Dostupná na https://web.mit.edu/kerberos/. Ide o referenčnú implementáciu, ktorá sa však približne do r. 2000 nesmela z USA vyvážať, pretože bola klasifikovaná ako pomocné vojenské vybavenie a obsahovala šifrovací algoritmus DES. [1][5]
Dostupná na https://www.h5l.org/. Európska implementácia vyvinutá primárne vo Švédsku v čase, keď ešte nebola implementácia od MIT voľne dostupná.
Ďalšou voľne dostupnou implementáciou je Shishi a implementácie Kerberosu sú aj v Microsoft Windows a Jave od Sun, neskôr Oraclu. Interoperabilita implementácie od MIT s ostatnými je popísaná hneď na začiatku zoznamu funkcií v jej dokumentácii. Ďalšia diskusia o ich vzájomnej kompatibilite sa nachádza na fóre Microsoftu, prehľad rozdielov je popísaný v článku na difference.wiki.
Na väčšiu odolnosť proti výpadkom sa môže používať záložný KDC [1] [5]. Základ nasledujúceho príkladu a stručného vysvetlenia replikácie databázy je prevzaté z [4]:
Ak existuje jeden primárny server a jeden alebo viacero sekundárnych, je potrebné ich databázy udržiavať konzistentné. V terminológii Kerberosu sa tento proces nazýva propagácia. Na propagáciu je nutné vytvoriť na oboch serveroch principal pre vzájomnú autentizáciu (host service). Ďalej je nutné preniesť master key, ktorým sú položky v databáze šifrované. To sa dá urobiť napríklad šifrovaným prenosom stash súboru alebo vytvorením novej databázy s rovnakým heslom na slave serveri (pri prvej propagácii bude prepísaná). Keď potom primárny server nie je dostupný, využíva sa sekundárny server, pričom ale nie je možné pristupovať k administrátorským funkciám [2].
Na primárnom serveri treba spustiť:
kadmin: add_principal -randkey host/masterkdc.example.com kadmin: ktadd host/masterkdc.example.com
Na sekundárnom serveri treba spustiť:
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
Alternatívne tiež možno miesto príkazu kadmin používať príkaz kadmin.local a miesto podpríkazu add_principal podpríkaz addprinc [2].
Testovanie propagácie databázy:
kdb5_util dump /etc/krb5kdc/slave_datatrans kprop slavekdc.example.com
Vo verzii 5 Kerberos na lokalizáciu KDC pre daný realm využíva SRV záznamy v DNS, ktoré spresňujú informácie o službách. V princípe sú podobné MX záznamom. Príklad:
$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: podľa odporúčania MIT by sa primárny KDC mal volať 'kerberos' a sekundárny 'kerberos-x', ako v príklade.
Kerberos 5 umožňuje autentizovať používateľov aj v inom realme. Jeden realm môže dôverovať druhému priamo, funguje tu aj tranzitivita. Príklad konfigurácie:
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 sa teraz môžu autentizovať v službách z B.EXAMPLE.COM. Táto väzba je iba jednosmerná. Cross-realm autentizácia tiež môže fungovať hierarchicky.
krb5_newrealm – inicializace nového realmu
kadmin – konzola na správu
kadmin.local: add_principal pv090 kadmin.local: list_principles
kinit – nástroj na získanie TGT
klist – nástroj na zobrazenie lístkov umiestnených v ticket cache
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.CZ
kdestroy – nástroj na zničenie aktívnych lístkov používateľa prepísaním a zmazaním
credentials cache, ktorá ich obsahuje [7]
kdb5_util – nástroj na údržbu databázy Kerberosu
kdb5_util dump /root/dump
kprop – nástroj na propagáciu databázy
kpass – nástroj na zmenu používateľovho hesla
ktutil – príkaz, ktorý vyvolá rozhranie, z ktorého administrátor môže čítať, zapisovať
alebo upravovať záznamy v keytab súbore alebo – u Kerborosu verzie 4 – srvtab súbore
firewall-cmd --add-port=88/udp --permanent service firewalld restart yum install krb5-* yum search rng-tools vi /etc/krb5.conf vi /var/kerberos/krb5kdc/kdc.conf rngd -r /dev/urandom -o /dev/random -b kdb5_util create -s -r myrealm service krb5kdc restart kadmin.local -q "addprinc username/admin"
Poznámka: od Fedory 22 sa na správu balíkov v systéme používa dnf miesto yum.
/etc/krb5.conf:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = PROTO07.LAB.FI.MUNI.CZ
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
PROTO07.LAB.FI.MUNI.CZ = {
kdc = localhost
admin_server = localhost
}
[domain_realm]
.proto07.pv090.fi.muni.cz = PROTO07.LAB.FI.MUNI.CZ
proto07.pv090.fi.muni.cz = PROTO07.LAB.FI.MUNI.CZ
/var/kerberos/krb5kdc/kdc.conf:
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88
[realms]
PROTO07.LAB.FI.MUNI.CZ = {
#master_key_type = aes256-cts
acl_file = /var/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
}
Ide o hierarchický protokol pre synchrozáciu času v počítačovej sieti. Jednotlivé úrovne sa nazývajú stratum X, kde X je celé číslo označujúce úroveň. NTP za maximálnu únosnú úroveň považuje stratum-15. Stratum-0 je tzv. referenčný čas, podle ktorého sa synchronizujú počítače na stratum-1 atď. S rastúcou úrovňou rastie nepresnosť. Úrovne sa používajú na zníženie záťaže. Na lokálnej sieti sa dá dosiahnuť presnosť okolo 10 ms, na internete potom do 100 ms. V Českej Republike prevádzkuje stratum-1 server napríklad cesnet (ntp.cesnet.cz).
Ak NTP zistí, že je potrebné vykonať korekciu systémového času, môžu nastať 4 prípady:
NTP komunikuje s využitím protokolov TCP a UDP na porte 123. Na synchronizáciu NTP odosiela časové známky, ktoré sú tvorené dvomi 32-bitovými čislami:
NTP pool je dynamická množina NTP verejně dostupných NTP serverov, ktoré je možné využiť pre synchronizáciu. Tieto servery patria do domény pool.ntp.org. Existujú aj subdomény obsahujúce servery podľa geografickej polohy (např. cz.pool.ntp.org). V DNS daného poolu sa používa algoritmus Round Robin, ktorý zaisťuje rovnomerné rozloženie záťaže na všetky stroje zapojené do poolu.
Konfiguracia NTP sa nachádza v soubore /etc/ntp.conf. Pre použitie českého poolu je do tohto súboru treba pridať nasledujúce riadky:
server 0.cz.pool.ntp.org server 1.cz.pool.ntp.org server 2.cz.pool.ntp.org server 3.cz.pool.ntp.org
Na Unixových OS je rdate nástroj na zisťovanie aktuálneho času zo servera v sieti a voliteľne aj nastavovanie systémového času. Používa protokol Time, ktorý je všeobecne považovaný za zastaraný a bol nahradený NTP.
Napríklad Precision Time Protocol (PTP) využíva funkcionalitu sieťového hardvéru týkajúcu sa presného času. Podrobné informácie sú v článku na Wikipédii o PTP.