Kerberos
Archivierte Anleitung
Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.
Artikel für fortgeschrittene Anwender
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Der Begriff Kerberos steht sowohl für ein Protokoll als auch dessen Implementierung und ermöglicht eine sichere Authentifizierung in einer unsicheren Umgebung. Der Name bezieht sich auf den Höllenhund, der in der griechischen Mythologie den Ein- bzw. den Ausgang der Unterwelt bewacht.
Das Protokoll basiert auf dem Needham-Schroeder-Protokoll von 1978 und beschreibt ein Verfahren zum Austausch von Schlüsseln zwischen gleichberechtigten Partnern (Client, Server) und einer dritten gesicherten Instanz, dem Kerberos Server (oder mehreren Servern). Das Protokoll unterscheidet bei der Authentifizierung zwischen Host, Dienst und Benutzer. Die aktuelle Kerberos Version 5 wurde 2005 als RFC 4120 🇬🇧 veröffentlicht.
Es existieren aktuell vier konkurrierende Implementierungen:
MIT Kerberos 🇬🇧
Active Directory - diese umfasst nicht nur Kerberos Funktionalitäten, sondern implementiert auch LDAP
Hinweis:
Um den Artikel einfach zu halten, wird im Folgenden nur auf die MIT Kerberos Implementierung eingegangen.
Voraussetzungen¶
Bevor ein Kerberos-Server in Betrieb genommen werden kann müssen zwei Voraussetzungen geschaffen werden.
NTP-Server: Kerberos arbeitet mit Tickets, welche ein absolutes "Verfallsdatum" haben. Driften die Uhren der beteiligten Verbindungspartner zu stark auseinander (MIT-Standard: 5 Min), kommt keine Verbindung zu Stande.
DNS-Server: Kerberos arbeitet mit FQDN (z.B.
host1.realm.some.domain). Alle beteiligten Verbindungspartner müssen sowohl im Forward- als auch im Reverse-Lookup aufgelöst werden können.
Installation - Server¶
Achtung!
Die Sicherheit eines Kerberos-Netzwerkes basiert vollständig auf der Sicherheit des Kerberos-Servers. Erlangt ein Angreifer Root-Rechte bzw. -zugriff auf die Schlüssel-Datenbank des Kerberos, kann dieser beliebige Berechtigungen ausstellen, kennt die Schlüssel für eventuelle Verschlüsselungen usw. Dieser "Mangel" ist durch das Design bedingt. Das MIT empfiehlt als Gegenmaßnahme, den/die Kerberos Server entsprechend dieser Anforderung zu sichern. Dazu gehört:
Am besten nur dedizierte Kerberos Server, damit so wenig wie irgend möglich (weitere) Dienste auf dem Rechner laufen. Vor allem keine Dienste, die als Benutzer
rootlaufen oder das Erlangen von Root-Rechten ermöglichen.Das Gerät sollte physikalisch in einem gesicherten Bereich stehen.
Es sollten nur Accounts für den Kerberos-Admin geben.
Das OS sollte auf dem aktuellsten Patch-Stand sein (unter Ubuntu: keine Pakete aus
backportsoderproposed)
Quellen: Kerberos installation help 🇬🇧 , Erneute Warnung vor „proposed“-Paketquellen
krb5-kdc
krb5-admin-server
Befehl zum Installieren der Pakete:
sudo apt-get install krb5-kdc krb5-admin-server
Oder mit apturl installieren, Link: apt://krb5-kdc,krb5-admin-server
Nach der Installation erfolgt ein geführter Konfigurationsdialog. Der übernimmt die wichtigsten Einstellungen. Die fertige Konfiguration findet sich dann unter /etc/krb5kdc/kdc.conf
[kdcdefaults]
kdc_ports = 750,88
[realms]
my.realm.root = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
default_principal_flags = +preauth
}Hinweis:
Unter Ubuntu wird der MIT-Kerberos ohne Standard-Benutzer/Admin angelegt. Man muss initial einen Realm-Admin anlegen.
Dies geschieht mit folgendem Befehl:
sudo krb5_newrealm
Hier muss ein Passwort vergeben werden, das möglichst komplex sein sollte und das nicht vergessen werden darf.
Benutzer anlegen¶
Existiert noch kein Adminuser für einen Realm oder will man die Anmeldung am Kerberos umgehen (Password vergessen...), erlangt mit folgendem Befehl zugriff auf die Kerberos Admin Konsole.
sudo kadmin.local
Hinweis:
Der gezeigte Befehl kann nur lokal an einem Kerberos-Server ausgeführt werden. Ein ordnungsgemäß konfigurierter Kerberos benötigt diese Möglichkeit zur Administration nicht.
Im Normalfall kann man von jedem Rechner, der sich dem Kerberos-Realm angeschlossen hat, wie folgt Zugriff auf die Admin-Konsole erlangen:
kadmin -p principal-name
Einmal in der Admin-Konsole kann wie folgt ein Benutzer angelegt werden:
addprinc simple_user #legt einen normalen Benutzer addprinc some_new_admin/admin #legt einen Admin-Benutzer an
Experten-Info:
Es kann prinzipiell jeder Name für einen Admin vergeben werden. Es hat sich jedoch als sinnvoll herausgestellt, alle Admins in eigene Instanzen (der Teil nach dem Slash) zu packen. Diese Instanz "/admin" kann dann als "Gruppe" gebraucht werden, um ihr über ACLs entsprechende Kerberos-Berechtigungen zuzuweisen.
Der Benutzer "some_new_admin/admin" besitzt noch keine Berechtigung auf dem Kerberos. Dies wird durch die Datei /etc/krb5kdc/kadm5.acl gesteuert.
*/admin@my.realm.root * #gewährt allen Benutzern der Instanz admin alle Rechte myadmin@my.realm.root * #gewährt dem Benutzer myadmin alle Rechte untrust@my.realm.root ADMCI #entzieht alle Rechter außer das Listing-Recht von Benutzer untrust
| Mögliche ACL Rechte | |
| Recht | Beschreibung |
a | Erlaubt das Hinzufügen von Principals oder Policies. |
A | Verbietet das Hinzufügen von Principals oder Policies. |
d | Erlaubt das Löschen von Principals oder Policies. |
D | Verbietet das Löschen von Principals oder Policies. |
m | Erlaubt das Modifizieren von Principals oder pPolicies. |
M | Verbietet das Modifizieren von Principals oder Policies. |
c | Erlaubt das Ändern des Passworts für Principals. |
C | Verbietet das Ändern des Passworts für Principals. |
i | Erlaubt das Abfragen der Datenbank. |
I | Verbietet das Abfragen der Datenbank. |
l | Erlaubt das Auflisten aller Principals oder Policies. |
L | Verbietet das Auflisten aller Principals oder Policies. |
s | Erlaubt das explizite setzen eines Keys für einen Principal. |
S | Verbietet das explizite setzen eines Keys für einen Principal. |
Dienste anlegen¶
Neben einzelnen Benutzern verwaltet Kerberos auch Dienste. Diese werden ebenfalls über Principals abgebildet. Angelegt werden sie wie folgt:
kadmin -p some_new_admin/admin addprinc -randkey nfs/server.my.realm.root addprinc -randkey cifs/server.my.realm.root addprinc -randkey nfs/client.my.realm.root addprinc -randkey cifs/client.my.realm.root addprinc -randkey nfs/some-other-client.my.realm.root addprinc -randkey cifs/some-other-client.my.realm.root
In diesem Beispiel sind am Kerberos nun Principals für den Dienst CIFS und NFS auf den Rechnern server, client, some-other-client hinterlegt. Welche Rollen diese Rechner später einnehmen, spielt für Kerberos keine Rolle. Es ist durchaus möglich, dass der Rechner client.my.realm.root einen CIFS-Server stellt und sich server.my.realm.root darauf verbindet. Dieses Erzeugen und Speichern der Keys hat auch im ersten Schritt keine sicherheitsrelevanten Konsequenzen. Erst wenn die Keys manuell auf dem entsprechenden Client hinterlegt werden, kann dieser die Keys auch benutzen.
Installation - Client¶
Hinweis:
Wenn auf dem Kerberos Server auch Dienste laufen, die sich gegenüber Kerberos authentifizieren, wird auch die Client-Komponente benötigt.
krb5-user
Befehl zum Installieren der Pakete:
sudo apt-get install krb5-user
Oder mit apturl installieren, Link: apt://krb5-user
Sollen sich an dem Client auch Benutzer über Kerberos authentifizieren, wird noch die PAM-Komponente benötigt.
Achtung!
Beim Einrichten von libpam-krb5 sollte man immer eine aktive "Notfall"-Konsole mit Admin-Rechten offen habe. Ist die Kerberos Server/Client-Konfiguration fehlerhaft, kann man sich u.U nicht mehr am System anmelden.
krb5-user
libpam-krb5
Befehl zum Installieren der Pakete:
sudo apt-get install krb5-user libpam-krb5
Oder mit apturl installieren, Link: apt://krb5-user,libpam-krb5
Sollte es sich bei dem Client um ein Gerät handeln, das nicht permanent den Kerberos-Server zur Verfügung hat, benötigt man noch das folgende Paket, um die User-Credentials lokal zu cachen. Dies ist ebenfalls im Fehlerfall nützlich, wenn der Kerberos-Server nicht verfügbar ist.
libpam-ccreds
Befehl zum Installieren der Pakete:
sudo apt-get install libpam-ccreds
Oder mit apturl installieren, Link: apt://libpam-ccreds
Nach der Installation wird abermals ein geführter Konfigurationsdialog ausgeführt. Dieser konfiguriert die /etc/krb5.conf so, dass eine Anmeldung mit Kerberos prinzipiell möglich sein sollte. In dieser Datei sind eine Reihe von Beispiel-Realms parametriert, die man bedenkenlos löschen kann. Eine aufgeräumte Konfiguration kann so aussehen.
[libdefaults]
default_realm = MY.REALM.ROOT
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
[realms]
MY.REALM.ROOT = {
kdc = KERBEROS-SERVER
admin_server = KERBEROS-SERVER
default_domain = my.realm.root
}
[domain_realm]
[login]
krb4_convert = false
krb4_get_tickets = false
[logging]
kdc = SYSLOG:INFO:DAEMON
admin_server = SYSLOG:INFO:DAEMON
default = SYSLOG:INFO:DAEMONMan sollte sich nun in einer zweiten Konsole mit einem Kerberos-Benutzer anmelden können.
Hinweis:
Kommt keine Benutzer/Gruppen-Synchronisation via LDAP zum Einsatz, muss der Administrator selber dafür Sorge tragen. Damit ein Benutzer über Kerberos authentifiziert werden kann, muss dieser auch in der lokalen /etc/passwd hinterlegt sein. Andernfalls kann sich der Benutzer nicht an dem Client anmelden.
Soll der Benutzer sich an dem Client nicht nur anmelden können, sondern auch Dienste benutzen, müssen die entsprechenden Keys hinterlegt werden.
sudo kinit some_new_admin/admin ktadd cifs/client.my.realm.root ktadd nfs/client.my.realm.root
Ab diesem Moment ist es möglich, NFS und CIFS-Shares ohne User-Credentials einzubinden (mounten) und den Zugriff von jedem durch Kerberos authentifizierten Benutzer zu gestatten.
Sonderfall - automatische Anmeldung¶
Manchmal ist es nötig, einen Rechner ohne Authentifizierung zur Verfügung zu stellen. Als Beispiele sind HTPCs oder Terminal-Rechner in Ausstellungsräumen zu nennen. Für diesen Zweck gibt es diverse Mechanismen unter Ubuntu. Soll ein solcher Rechner auch in einem Kerberos Netz betrieben werden, kommt es darauf an, ob die benutze Login-Variante in den PAM-Prozess eingreift oder einfach ein gespeichertes Password durchreicht. Bei letzterer Variante ist kein Eingriff nötig, da der "User" gegenüber Kerberos wie jeder normale Benutzer authentifiziert wird (mit dem gespeicherten Passwort). Einige Displaymanager (z.B NoDM) umgehen bei einer automatischen Anmeldung einfach die PAM-Authentifizierung bzw. richten eine eigene PAM-Kette ein, die kein Passwort erfordert.
Ist man sich nicht sicher, ob eine gültige Kerberos-Umgebung vorliegt, kann man das mittels folgendem Befehl prüfen:
klist
Liefert dieser Befehl die Meldung "No credentials cache found", existiert keine gültige Kerberos Umgebung.
Um eine Kerberos-Umgebung ohne Passwort zu bekommen, benötigt man den Schlüssel des Principals auf dem Client. Dieser sollte in einer benutzerbezogenen Keytab abgelegt werden, da die Datei /etc/krb5.keytab nur root zugänglich ist.
Achtung!
Mit den folgenden Befehlen legt man das Secret eines Benutzers auf einem "ungeschützten" Ort. Diese Information kann jeder extrahieren und zur Authentifizierung nutzen.
sudo -u autologinuser kadmin -p some_new_admin/admin addprinc -randkey autologinuser ktadd -k /home/autologinuser/.keytab autologinuser
Um eine Kerberos Umgebung zu initialisieren, führt muss man kinit mit der Keytab und dem Benutzernamen auf.
/usr/bin/kinit -k -t /home/autologinuser/.keytab autologinuser@MY.REALM.ROOT
Dieser Befehl kann in einem Startskript (z.B. /home/autologinuser/.xsession) hinterlegt werden.
Soll das System sehr lange laufen, kann es passieren, dass die Tickets ablaufen. Standartmäßig ist der KDC auf 10 Stunden Ticket-Lebenzeit und maximal 7 Tage "Wiederbelebung" eingestellt. Entweder erhöht man diese Werte in der /etc/krb5kdc/kdc.conf oder man legt auf Clientseite einen Cronjob an, welchen eine Erneuerung der Tickets anstößt. Dazu einfach in der User-Crontab folgende Zeile anlegen:
0 * * * * /usr/bin/kinit -R
Links¶
Kerberos - Wikipedia
Weitere Artikel zum Thema:
Serverdienste Übersichtsartikel