db.dobo.sk

Výpisky ku Kerberu. Kerberos je sieťový autentizačný protokol, základné info RFC 4120.

Účel

1. Sieťová (doménová) autentifikácia, účty v centrálnej databáze – tzv. KDC (key distribution server). Princíp “doveryhodných hostov na nedoveryhodnej sieti” (z čoho vyplýva, že pokiaľ dojde ku kompromitácii servra pridělujúceho autentifikáciu, alebo podvrhnutie identity klienta je všetko v riťke).
2. Single sign on (SSO) – klient sa autentifikuje len raz voči autentifikačnému servru a ten mu potom poskytuje tickety na služby v celej sieti – odpadá zadávanie hesiel pre jednotlivé appky na iných servroch a pod. Zároveň je jednoduchá aktualizácia a správa prístupu (na 1 mieste v KDC).
3. Klientove heslá nejdú nikdy po sieti. Klientove heslá nie sú ukladané na hostoch. Z hľadiska administrácie je to príjemné, na hostoch može byť bordel, ale admin si pečlivo stráži “kerberizáciu” siete.
4. Autentifikuje sa nielen klient/host, ale aj aplikačný server (obaja majú istotu, že ten druhý je ten, za ktorého sa vydáva). Autentifikujú sa voči KDC.
5. Nutno podotknúť, že mnoho funkcií závisí na konfigurácii. Kerb5 napr. defaultne nemá preautentifikáciu (TGT), ale ingrovaný vo WinAD ju má štandardne zapnutú.

Terminológia

• Realm (Kerberos Realm) – je rozsah spravovanej siete, doména, napr. dobo.local.
• Ticket – základ autentizácie, posiela sa po sieti namiesto hesla. Obsahuje spravidla klientovu identifikáciu, session key (= dočasný šifrovací kľúč) a timestamp. Vždy zašifrovaný.
• Principal – identita klienta (hosta), ktorému može byť priradený ticket. Kompletne identifikovaný ako hostname@realm, alebo service/hostname@realm atd.
• KDC – server, ktorý autentizuje, resp. sada servrov – AS (authentication server), – TGS (ticket granting server) a hlavne databáza/katalóg principalov a ich údajov. Okrem šifrovania v záznamoch o passwordoch (hashe) je celá DB ešte šifrované pomocou tzv. Master Key, ktorý sa používa i pri dumpoch.
• Šifrovanie kľúčov (encryption) je symetrické, t.j. kľúče sa šifrujú a dešifrujú rovnakým kľúčom. Pre šifrovanie kľúčov je možné použiť rozne algoritmy, najčastejšie AES (128/256). Hashovanie v databázi – MD5 i CRC32, obvykle sa pridáva soľ vo forme mena principála (nech sa líši v rozdielnych realmoch)
• Kľúče (keys) – rozdielne typy a účely. Session key – jedinečný kľúč pre pacovnú sešnu medzi klientom a aplikačným serverom.
• Tikety – dva druhy. TGT (ticket granting ticket) je tiket, ktorý rieši posúdenie autentifikácie klienta a je vystavený na ďalšiu komunikáciu, pri ktorej klient už dostane TGS (ticket granting service)

obr z ofiko dokumentácie kerbera

Jak to funguje

(nekryptované),  K{kryptované kľúčom K}

1. AS_REQ

Klient (kinit) zasiela požiadavku na KDS, úvodná je AS_REQ, konkrétne na AS a dožaduje sa TGT.  Požiadavka obsahuje:

• AS_REQ  = (principal/klient; principal/service; ip_list; lifetime) – prvé dve identifikujú principála, IP list je zoznam IP adries, na ktoré sa bude ticket vzťahovať a lifetime je požadovaný čas pre tiket.

2. AS_REP

AS jukne do databáze, či je tam oprávnený klient alebo oprávnená služba, ak áno, vezme si jeho heslo K_USER a pokračuje ďalej. Vystaví:

• session key (randomgen) pre ďalšiu komunikáciu s TGS —> SK_TGS
• TGT (principal/klient; krbtgt/REALM@REALM; ip_list; timestamp; lifetime; SK_TGS) – prvé tri položky len prekopíruje z AS_REQ, zbytok dopĺňa sám. Lifetime v tomto prípade je menší, než žiadal klient a menší, než propagujú aplikačné servry, pretože je to “predtiket”.
• Všetko to spakuje a zašle spať klientovi, v nasledovnom tvare:

AS_REP = K_USER{principal; timestamp; lifetime; SK_TGS} + K_TGS{TGT}

Ku klientovi to dorazí a on si je schopný rozšifrovať len 1. časť na základe svojho hesla (hashe z hesla) a tým aj potvrdiť svoju identitu, nie však 2., ktorá sa pre ďalšie použitie uloží do keše (tzv. credential cache – do keše z bezpečnostných dovodov – je to v /temp/krb5cc_UserUID). Teraz, keď klient dokázal svoju totožnosť a v keši má zašifrovaný kľúč pre ďalšie obcovanie, pokračuje ďalej a bude usilovať získať TGS.

3.TGS_REQ

• Klient vytvorí tzv. “autentikátor”: Autenticator = SK_TGS{principal; timestamp}
• vytvorí celý požiadavok: TGS_REQ = (principal; lifetime; Authenticator) + K_TGS{TGT}

Pošle to na TGS server KDC.

4. TGS_REP

Keď žiadost dorazí na TGS, tak ten:

• jukne do databáze, či taký principal vobec existuje
• rozšifruje si TGT a Autentifikátor
• porovná principálov v TGT a Autentifikátore, či sa zhodujú (nenastal podvrh medzi TGT a TGS?)
• porovná timestamp a lifetime na TGT, či v poriadku (expired?)
• nejaké menšie čeky ako ip_list a pod….

Pokiaľ všetko v poriadku, tak principal je autentifikovaný a bude mu vystavený ticket pro službu (T_SERVICE):

• T_SERVICE = (principal/client; principal/service; ip_list; timestamp; lifetime; SK_SERVICE) – SK_SERVICE je randomizovaný session kľúč ku komunikácii medzi klientom a požadovanou aplikáciou (aplikačným serverom).
• finálna odpoveď TGS_REP spať ku klientovi je poskladaná tak, že tam zabalí nejaké info okolo a na koniec akurát vytvorený T_SERVICE, ktorý však bude pre klienta zašifrovaný servisným kľúčom K_SERVICE:  TGS_REP  =  K_TGS{principal; timestamp; lifetime; SK_SERVICE} + K_SERVICE{T_SERVICE}

Klient po prijatí si dokáže rozšifrovať 1. časť (má v credential cache K_TGS), ale nedokáže rozšifrovať K_SERVICE a obsah tiketu mu je utajený – ten sa bude vystavovať až aplikačnému servru.

Jednoduchšie

Pokiaľ má v tom človek chaos (akože ho mám), čo sa šifruje čím, tak skvelý prehľadový obrázok z webu samuraj.com prehľadne zhrňuje problematiku. Tu je to na WinAD environmente, ale to je jedno:

 

 

Ako postaviť a nakonfigurovať Kerberos server s LDAPom

1. Cieľom je postaviť infraštruktúru s kerberom a LDAPom, krotú budú využívať klienti pre to, aby sa mohli rýchle a bez problémov autentizovať v realme a využívať služby. Je to jedna s častí skúšky na RHCE. Budem to tu demonštrovať na RHEL 7.2.

2. Pozor. Pre kerberizáciu siete a služieb nie je LDAP nevyhnutný, je to len niečo naviac. V zásadě je možné postaviť len Kerbera a na LDAP sa vykašlať.

3. Svatou trojicou je trojica Kerberos/LDAP/sssd. Kerberos vydáva tickety a kerberizuje sieť, LDAP zavádza centrálnu správu autentikácie a sssd na klientoch sprostredkúva pre klientov tieto služby na lokálnej mašine.

Inštalácia Kerberos servru

Na servri musí byť funkčný NTP a DNS (stačí hosts).
Inštalácia balíkov:

yum install -y krb5-server krb5-workstation pam_krb5

Konfigurácia 3 konfigurákov, všade nahradiť EXAMPLE.COM názvom svojho realmu:

/var/kerberos/krb5kdc/kdc.conf  – uncomment master_key_type = aes256-cts a pridanie default_principal_flags = +preauth do [realms]

/etc/krb5.conf – všetko odkomentovat, nahradiť realm a doplniť fqdn Kerberosieho serveru

/var/kerberos/krb5kdc/kadm5.acl – prepísať realm

Vytvoriť kerberosiu databázu (KDC), nahraď svojim realmom EXAMPLE.COM:

kdb5_util create -s -r EXAMPLE.COM

Spustiť a enablovať kerberos:

systemctl start krb5kdc kadmin
systemctl enable krb5kdc kadmin

Výsledok – na Kerberos servri musia bežať 2 démoni – KDC a kadmin:

systemctl status krb5kdc

systemctl status kadmin

Čo s tým – správa kerbera lokálne (na servri):

kadmin.local (help ukáže možnosti, pridávanie, mazanie, editácia principálov a pod.). Je nutné pridať do realmu kerberosí server, urobiť lokálneho admina kerbera a lokálnu kopiu keytab entry..

addprinc root/admin
addprinc -randkey host/fqdn kerberos server
ktadd host/fqdn kerberos server

Záverečná obsluha – kerberizovať sshd a nastaviť firewall

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

authconfig –enablekrb5 –update

Pre firewall vytvoriť XML konfigurák v /etc/firewalld/services/kerberos.xml

<?xml version=”1.0″ encoding=”utf-8″?>
<service>
  <short>Kerberos</short>
  <description>Kerberos network authentication protocol server</description>
  <port protocol=”tcp” port=”88″/>
  <port protocol=”udp” port=”88″/>
  <port protocol=”tcp” port=”749″/>
</service>

firewall-cmd –permanent –add-service kerberos
firewall-cmd –reload

 

nakonfignúť klienta pre kerberos

yum install krb5-workstation pam_krb5

vim /etc/krb5.conf a oeditovat to vzhľadom na realm a kerberosí server. Možnosť skopírovať to z kerberosieho serveru.

na klientovi vytvorím testovacieho usera a na serveri ho pridám do principálov. Pozor, je nutné na serveri pridať do principálov aj klienta, nielen usera.

useradd dobo

addprinc -randkey host/klient.example.com

addprinc -randkey dobo@EXAMPLE.COM

cpw dobo

Na klientovi nutné poeditovaťssh a pam

/etc/ssh/ssh_config
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

 authconfig –enablekrb5 –update

Otestovanie, esli user dostáva ticket

su – dobo

kinit

klist