Kerberos E-Book

Mark Pröhl

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: iX Edition
• Sprache: Deutsch
• Veröffentlichungsjahr: 2022

Seitenzahl: 730

Beschreibung

Fragen zu Kerberos? Hier gibt es Antworten!

• Das deutsche Standardwerk zu Kerberos
• Seit Jahren bewährt und vielerorts im Einsatz
• Komplett überarbeitete zweite Auflage
• Als Begleitliteratur für Schulungen und fürs Selbststudium geeignet

Wer als Administrator eine heterogene Netzwerkumgebung mit einheitlicher Benutzerverwaltung betreiben soll, kommt an Netzwerkdiensten wie LDAP und Kerberos nicht vorbei.

Dieses Buch behandelt zunächst die theoretischen Grundlagen von Kerberos und erklärt dabei auch fortgeschrittene Themen wie PKINIT, FAST, Principal-Aliase, KDC-Referrals und die aus Microsofts Active Directory bekannten Erweiterungen Protocol Transition und Constrained Delegation.

Die darauf folgenden Praxiskapitel beschreiben den Aufbau und die Verwaltung von Kerberos in Linux- und Windows-Infrastrukturen. Außerdem werden die Integration von Linux-Betriebssystemen und Einbindung grundlegender Netzwerkdienste unter Linux erläutert. Dabei werden auch folgende Themengebiete im Hinblick auf Kerberos behandelt:

- LDAP
- NFSv4
- SMB (Samba)
- Web-Technologien (Apache Webserver, Squid Webproxy, Keycloak)
- PKINIT und Smartcards
- Zweifaktor-Authentisierung mit Kerberos
- Kerberos in Microsoft Active Directory (AD)
- Kerberos in Samba 4
- Kerberos in FreeIPA
- Kerberos in Hadoop-Umgebungen (Secure Mode)
- Linux-AD-Integration

Für eine erfolgreiche Einführung von Kerberos ist das Verständnis seiner Funktionsweise unerlässlich. Dieses Verständnis ist gleichermaßen für die "Kerberisierung", also die Einbindung Kerberos-fähiger Anwendungen, notwendig. Aus diesem Grund werden die theoretischen Themen sehr gründlich behandelt.

Um das theoretisch Gelernte schnell umzusetzen und selbst auszuprobieren, beschreibt das Buch außerdem eine konkrete Beispielumgebung, die auf CentOS 8, Windows 10 und Windows Server 2019 basiert.

Die 2. Auflage wurde komplett überarbeitet und enthält folgende neue Themen: Squid Webproxy, Web Single Sign-on mit Keycloak, Zweifaktor-Authentisierung, FreeIPA, Samba 4, Kerberos bei Hadoop.

Leseprobe

Mark Pröhl und Daniel Kobras sind als IT-Berater bei Puzzle ITC Deutschland tätig. Neben manch anderem beruflichen Steckenpferd wie Automatisierung, Container-Plattformen oder Dateidiensten landen sie doch stets wieder beim gemeinsamen Thema Kerberos und Single Sign-on, vor allem in heterogenen Umgebungen. Seit weit mehr als einem Jahrzehnt teilen sie ihr Wissen dazu auch regelmäßig in Schulungen und Workshops.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Mark Pröhl • Daniel Kobras

Kerberos

Single Sign-on in gemischten Linux/Windows-Umgebungen

2., komplett überarbeitete Auflage

Mark Pröhl · Daniel Kobras

Lektorat: René Schönfeldt

Projektkoordinierung: Anja Weimer

Copy-Editing: Annette Schwarz, Ditzingen

Satz: Mark Pröhl

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-86490-714-2

PDF

978-3-96088-851-2

ePub

978-3-96088-852-9

mobi

978-3-96088-853-6

2., komplett überarbeitete Auflage 2022

Copyright © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Über dieses Buch

Die Verwaltung von Identitäten und deren Berechtigungen, auch »Identity and Access Management« genannt, ist eine der Grundlagen für die Sicherheit von IT-Umgebungen. Ein wesentlicher Aspekt dabei ist die Überprüfung und Bestätigung von Identitäten, also die Authentisierung bzw. Authentifizierung – ein Bereich, in dem sich das Authentisierungsverfahren Kerberos als Standard durchgesetzt hat. Diese Tatsache erkennt man u. a. daran, dass Kerberos heutzutage Bestandteil aller wichtigen Betriebssysteme ist: Unter den verschiedenen Unix- und Linux-Derivaten war Kerberos schon seit jeher vertreten. Aber auch in der Apple-Welt und insbesondere in Microsofts Active Directory spielt Kerberos eine wesentliche Rolle, wenn es um die Authentifizierung von Nutzer:innen geht. Mindestens ebenso wichtig ist die Unterstützung durch Anwendungen und Netzwerkdienste, die für Kerberos großflächig gegeben ist. Hier kann Kerberos durch echtes Single Sign-on (SSO) weiter punkten. Aber auch andere Aspekte der IT-Sicherheit, wie die Integrität und Vertraulichkeit von Nutzdaten, deckt Kerberos ab.

Gerade in heterogenen IT-Umgebungen eignet sich Kerberos aufgrund seines sehr hohen Verbreitungs- und Standardisierungsgrades als Authentisierungskomponente innerhalb einer zentralen User- und Berechtigungsverwaltung. Aus diesem Grund befasst sich dieses Buch neben dem Hauptschwerpunkt Kerberos auch mit den Möglichkeiten, Kerberos durch zusätzliche Infrastrukturdienste zu erweitern und so Kerberosintegrierte Netzwerk- und Verwaltungsumgebungen zu schaffen.

Welche Ziele hat dieses Buch?

Dieses Buch möchte Ihnen zunächst ein Verständnis für die Funktionsweise des Kerberos-Protokolls vermitteln. Diese theoretischen Inhalte liefern das nötige Hintergrundwissen für die Praxisteile, in denen der Aufbau und die Verwaltung von Kerberos-Infrastrukturen und die Integration von Anwendungen und Netzwerkdiensten (die »Kerberisierung«) behandelt werden. Dabei soll das Motto gelten: »Nicht mehr Theorie als nötig, aber auch nicht weniger.« An geeigneten Stellen wird auf weiterführende Literatur verwiesen.

Die Praxisteile beschreiben konkrete Implementierungen und sollen Ihnen die Möglichkeit geben, schnell eine funktionierende Kerberos-Umgebung aufsetzen und das theoretisch Gelernte praktisch anwenden zu können.

Für wen ist das Buch?

Dieses Buch richtet sich in erster Linie an Administrator:innen heterogener Netzwerkumgebungen, die sich eingehend mit Single Sign-on und Kerberos beschäftigen wollen. Für Anwendungsprogrammierer:innen werden vor allem jene Buchteile interessant sein, die die Funktionsweise des Kerberos-Protokolls und die Kerberisierung existierender Netzwerkdienste beschreiben.

Welche Voraussetzungen sollten Sie mitbringen?

Unsere Leser:innen sollten über allgemeine Grundkenntnisse der Administration von Linux- und Windows-Systemen verfügen, sich insbesondere nicht vor dem Einsatz der Kommandozeile scheuen und in der Lage sein, mit einem Texteditor Konfigurationsdateien zu erstellen oder anzupassen. Es wird beispielsweise nicht erklärt, wie man unter Linux ein Terminalfenster oder einen Editor startet. Grundkenntnisse in LDAP sind von Vorteil, obwohl die nötigen Voraussetzungen hier geschaffen werden (siehe Anhang A). Wenn Sie sich bereits mit den Themengebieten Authentisierung, Autorisierung und Zugriffskontrolle beschäftigt haben, wird Ihnen der Einstieg in die Materie sicherlich leichter fallen, auch wenn diese Grundlagen hier behandelt werden.

Kenntnisse in Virtualisierungslösungen sind ebenfalls von Vorteil, wenn es darum geht, die hier beschriebenen Beispielszenarien in einer eigenen virtuellen Infrastruktur nachzuvollziehen.

Wie ist das Buch aufgebaut?

Teil I befasst sich mit den theoretischen Grundlagen der Authentisierung in Rechnernetzen mit Kerberos. Um diesen theoretischen Stoff nicht zu trocken zu gestalten, bietet Kapitel 3 einen Eindruck von Kerberos aus der Sicht der Anwender:innen. Danach folgt eine eingehende Beschreibung des Protokollablaufs, wobei fortgeschrittene Themen (Stichworte: Principal-Aliase, KDC-Referrals und Constrained Delegation) in das abschließende Kapitel 6 ausgelagert sind.

In Teil II lernen Sie anhand verschiedener Beispielumgebungen, wie man Kerberos-Infrastrukturen aufbaut und verwaltet. Verschiedene Kapitel von Teil II benötigen zusätzliche Komponenten wie NTP, DNS und LDAP sowie eine Infrastruktur für X.509-Zertifikate, deren Einrichtung daher vorab in Kapitel 7 behandelt wird. Danach werden die Konzepte und Konfigurationsmöglichkeiten anhand der Kerberos-Implementierung des Massachusetts Institute of Technology (MIT Kerberos) sehr detailliert erläutert (Kapitel 8–13). In anschließenden Kapiteln geht es dann um die alternative Implementierung Heimdal und die Möglichkeiten, die Active Directory als Kerberos-Infrastruktur zu bieten hat. Kapitel 15 behandelt dabei die Microsoft-Implementierung von Active Directory, Kapitel 16 die dazu kompatible, freie Alternative des Samba-Projekts. Eine konzeptionell ähnliche integrierte Lösung speziell für Linux-Umgebungen ist FreeIPA, das Kapitel 17 im Detail vorstellt. Teil II wird von Kapitel 18 abgeschlossen, das sich fortgeschrittenen Themen der Kerberos-Praxis widmet.

In Teil III des Buches geht es darum, wie man Kerberos-Infrastrukturen durch die Integration weiterer Netzwerkdienste erweitern kann. Der Verzeichnisdienst LDAP spielt hier eine tragende Rolle, da dieser Dienst Kerberos um die Verwaltung von User- und Berechtigungsdaten ergänzt. Ein weiterer Aspekt dabei ist die Integration der Anmeldung am Betriebssystem, wobei LDAP als Namensdienst und Kerberos für die Passwortüberprüfung eingesetzt werden. Dieser Teil beschäftigt sich aber auch grundsätzlich mit dem Vorgang der Kerberisierung von Netzwerkdiensten, die unsere Leser:innen anhand zahlreicher Beispiele lernen können.

Der Aufbau des Buches erfolgt in der beschriebenen Reihenfolge, es sollte aber auch möglich sein, einzelne Kapitel zu überspringen oder erst später zu lesen, ohne dabei den Gesamtüberblick zu verlieren.

Die Beispielumgebung

Die Praxisteile II und III beschreiben die verschiedenen Aspekte von Kerberos anhand einer konkreten Beispielumgebung mit dem Namen »EXAMPLE.COM«, die auch aus weiteren Subdomänen besteht. Abbildung 6.5 auf Seite 113 stellt die Gesamtstruktur dar. Der Aufbau dieser Beispielumgebung wird detailliert beschrieben. Selbstverständlich steht es Ihnen frei, diese Umgebung oder Teile davon in einem eigenen Testlabor aufzubauen oder nur die Beschreibung zu lesen.

Verwendete Usernamen

In den Beispielumgebungen tauchen zwei Personen immer wieder auf: Max Mustermann, dem der Username maxm zugeordnet ist, und Erika Musterfrau mit dem Account erim.

Verwendete Passwörter

In vielen Listings wird das Beispielpasswort »P@ssw0rd« verwendet – das englische Wort »Password« mit einem »@« statt »a« und der Ziffer »0« (Null) statt des »o«. Derartige Passwörter sollten in realen Umgebungen natürlich nicht verwendet werden, machen aber das Leben im Testlabor einfacher. An anderen Stellen dieses Buches wird dagegen mit »richtigen« Passwörtern gearbeitet, die mit einem Passwortgenerator erzeugt werden. Das macht zwar einige Listings etwas unleserlich, soll aber die Sicherheitsrelevanz unterstreichen.

Typografische Konventionen

Im Text

Für die Auszeichnung von Programmein- und -ausgaben, Benutzernamen und Ähnlichem werden verschiedene Schriftarten verwendet, hauptsächlich ist das die Schreibmaschinenschrift. Hier ein paar Beispiele:

Die Ausgabe von textbasierten Computerprogrammen wird so dargestellt:

Dies ist der Output eines Programms

.

Befehle auf der Kommandozeile werden im Text wie folgt dargestellt:

ssh -l maxm lx01.example.com

.

Manche Befehle enthalten Platzhalter, die je nach Zusammenhang ersetzt werden müssen. Diese werden

kursiv

gesetzt. Beispiel:

ssh -l

Benutzer Hostname

. Dabei wären

Benutzer

und

Hostname

entsprechend zu ersetzen.

Benutzernamen:

maxm

und

erim

DNS-Hostnamen:

lx01.example.com

Webadressen (HTTP-URLs):

https://www.example.com

Beschriftungen innerhalb von grafischen Programmelementen, Beispiel:

OK

oder

Cancel

In den Listings

Listings werden wie folgt dargestellt:

user@lx01:~$ echo 'Hallo Welt'

Hallo Welt

user@lx01:~$

Benutzereingaben werden hierbei fett gesetzt. Es gibt aber auch unsichtbare Eingaben (beispielsweise Passwörter). Diese werden fett-kursiv dargestellt:

maxm@lx01:~$ kinit [email protected]

Password for [email protected]: P@ssw0rd

maxm@lx01:~$

Listings mit zu langen Zeilen müssen umgebrochen dargestellt werden. Der Umbruch wird dann mit den Zeichen »« und »« markiert:

user@lx01:~$ echo 'Diese Zeile ist zu lang für ein dpunkt-

Buch, daher wird sie automatisch umgebrochen'

Diese Zeile ist zu lang fuer ein dpunkt-Buch, daher wird

sie automatisch umgebrochen

user@lx01:~$

Sehr lange Listings können verkürzt dargestellt werden. Das wird dann durch die Zeichenfolge [...] angedeutet. Beispiel:

user@lx01:~$ ls -la

total 24

drwx------. 2 user user 4096 Feb 15 09:20 .

drwxr-xr-x. 3 root root 4096 Feb 15 09:20 ..

-rw-r--r--. 1 user user 18 Nov 8 17:21 .bash_logout

-rw-r--r--. 1 user user 141 Nov 8 17:21 .bash_profile

-rw-r--r--. 1 user user 312 Nov 8 17:21 .bashrc

[...]

user@lx01:~$

Die gleiche Zeichenfolge wird auch verwendet, um Kommentare in die Listings einzubauen. Im folgenden Beispiel soll zwischen zwei Kommandos neun Minuten gewartet werden:

[...]

user@lx01:~$ klist -f

[...]

[...9 Minuten warten...]

user@lx01:~$ kinit -R

user@lx01:~$ klist -f

[...]

Der Text [...9 Minuten warten...] ist also kein Teil einer Programmausgabe, sondern ein Kommentar.

Der Prompt hängt vom Betriebssystem ab. Befehlszeilen unter Linux werden durch einen Prompt wie dem folgenden eingeleitet:

[email protected]:~$

Dem Prompt entnimmt man neben dem Usernamen auch den Hostnamen der Maschine, auf der ein Kommando ausgeführt wird, sowie die Umgebung. In folgendem Beispiel führt root auf kdc01 in der MIT-Umgebung (daher kdc01.mit) das Kommando ls -la aus:

[email protected]:~# ls -la

[...]

Unter Windows geschieht das in dieser Art:

C:\>

Danksagung

Mein Dank gilt in erster Linie meiner Frau und meinen Kindern, ohne deren Unterstützung ich dieses Werk nicht hätte fertigstellen können. Vielen Dank auch an Freunde und Arbeitskollegen für viele anregende Diskussionen.

Oliver Tennert gilt ein besonderer Dank für Anregungen und Diskussionen während der Entstehung dieses Buches. Vielen Dank auch an Markus Widmer und Heiko Hütter für Tests der beschriebenen Infrastrukturen und ihre Rückmeldungen zu den LDAP-spezifischen Teilen. René Schönfeldt und dem Team beim dpunkt.verlag sowie allen Gutachtern ebenfalls ein herzliches Dankeschön für die Unterstützung bei der Realisierung dieses Buchprojektes.

Kontakt

Für Fragen, Anregungen, Kritik und Feedback jeglicher Art sind die Autoren über die E-Mail-Adresse [email protected] zu erreichen.

Im Internet

www.kerberos-buch.de

Unter https://www.kerberos-buch.de befindet sich die Homepage dieses Buches. Dort finden Sie Informationen rund um das Kerberos-Buch, insbesondere sind dort sämtliche Listings und Errata verfügbar.

Zur zweiten Auflage

Zu den jungen Wilden zählt Kerberos wahrlich nicht mehr. Als Protokoll mit Wurzeln in den 1980er-Jahren hat es inzwischen ein reifes Alter erreicht. Doch auch wenn in den rund zehn Jahren seit Erscheinen der ersten Auflage dieses Buches radikale Umwälzungen erwartungsgemäß ausgeblieben sind, gehen die Änderungen doch deutlich über reine Kosmetik hinaus. Im Protokoll selbst haben vor allem gestiegene Sicherheitsanforderungen ihre Spuren hinterlassen. Mehrere Faktoren zur Authentisierung ergänzen das klassische Passwort, gezielte Erweiterungen um asymmetrische Kryptografie beseitigen einige Problemstellen im Protokoll. Unter den Schlagworten FAST, PKINIT und SPAKE haben diese Themen in der zweiten Auflage neuen oder erweiterten Platz gefunden.

Bei den Implementierungen steht immer stärkere Integration im Vordergrund. Nach Active Directory gibt es nun auch im Open-Source-Bereich durch Samba 4 und FreeIPA sowie darauf aufbauende Produkte Komplettsysteme, die Kerberos-Authentisierung, LDAP-Verzeichnis und weitere Zusatzdienste miteinander vereinen. Entsprechend passt sich auch die Clientseite an. Der sssd als Basisdienst bündelt nun alle Anfragen ursprünglich getrennter Subsysteme wie NSS und PAM. Die Integration führt zu gleichförmigeren Umgebungen und ermöglicht so bequeme Werkzeuge wie realmd, die die Anbindung von Clientsystemen an Active Directory und Co. stark vereinfachen. Beim Anpassen der Praxisbeispiele auf aktuelle Betriebssystemversionen sind diese Aspekte in der neuen Auflage somit geradezu zwangsläufig mit eingeflossen. Gleichzeitig sollen die nach wie vor enthaltenen Abschnitte zu den einzelnen Kerberosund LDAP-Implementierungen dabei helfen, den Aufbau der integrierten Umgebungen zu verstehen, und damit unerlässliches Grundwissen für die Analyse von Problemen vermitteln.

Im Bereich der Applikationen verschiebt sich die Nutzung mehr und mehr weg vom klassischen Desktop, hin zu Browseranwendungen und mobilen Apps. Kerberos ist hier selten die erste Wahl, auf Smartphones und Tablets fehlt die entsprechende Infrastruktur sogar völlig. Stattdessen dominieren hier auf den Webbereich spezialisierte Single-Sign-on-Protokolle wie SAML oder OpenID Connect. Am Beispiel Keycloak zeigt diese Auflage, wie sich dennoch der Bogen spannen lässt vom Kerberos-SSO klassischer Netzwerkumgebungen bis hin zum Web-SSO mobiler Applikationen.

Nach über zehn Jahren ist die zweite Auflage dieses Buches einer Reihe von Personen zu verdanken: Daniel Kobras – als Kollege bei Puzzle ITC und in gemeinsamen Schulungsveranstaltungen bereits bestens mit dem Themenfeld dieses Buches vertraut – hat als neuer Co-Autor mit angepackt, die Inhalte auf einen zeitgemäßen Stand zu hieven. Unser beider Dank gilt auch wieder unseren Familien und der Geduld, die sie mit uns haben. René Schönfeldt und dem gesamten Team des dpunkt.verlags möchten wir für die Unterstützung bei der Realisierung des Buches danken. Jürgen Seeger und Oliver Diedrich gilt unser Dank für die Unterstützung bei den iX-Workshops.

Inhaltsverzeichnis

IKerberos

1Kerberos im Überblick

1.1Ursprung am MIT: das Athena-Projekt

1.2Versionen des Kerberos-Protokolls

1.3Standardisierung

1.4Implementierungen

1.4.1Kerberos v4

1.4.2Kerberos v5

1.4.3Interoperabilität und Kompatibilität

2Grundlagen der Netzwerkauthentisierung mit Kerberos

2.1Authentisierung

2.1.1Authentisierungsmerkmale

2.1.2Problematik der Passwörter

2.1.3Lokale Anmeldung vs. Netzwerkauthentisierung

2.2Authentisierung mit Kerberos

2.2.1Key Distribution Center

2.2.2Realm

2.2.3Principals

2.2.4Tickets

2.2.5Gegenseitige Authentisierung

2.2.6Lokale Anmeldung und Kerberos

2.3Delegation

2.4Autorisierung und Zugriffskontrolle

2.4.1Authentisierung ist Voraussetzung

2.4.2Identity Mappings

2.4.3Autorisierung und Kerberos

2.5Single Sign-on (SSO)

2.6Zusammenfassung

3Kerberos aus Anwendersicht

3.1Die Beispielumgebung

3.2Lokale Anmeldung

3.3Der Credential Cache

3.4Anmeldung an Netzwerkdiensten

3.5Delegation

3.6Eine Demo-Webseite

3.7Umgang mit dem Credential Cache

3.8Zusammenfassung

4Sicherheit und Kryptografie

4.1Sicherheitsüberlegungen

4.1.1Allgemeine Sicherheitsanforderungen

4.1.2Die beteiligten Systemkomponenten

4.1.3Anforderungen an Kerberos

4.2Kryptografie in der Netzwerksicherheit

4.2.1Vertraulichkeit

4.2.2Integrität

4.2.3Authentisierung

4.2.4Passwörter, Schlüssel und Schlüsselaustausch

4.2.5Zusammenfassung

5Wie funktioniert Kerberos V5?

5.1Das Funktionsprinzip im Überblick

5.1.1Voraussetzungen

5.1.2Das einstufige Kerberos-Verfahren

5.1.3Diskussion

5.1.4Das zweistufige Kerberos-Verfahren

5.1.5Zusammenfassung

5.2Das Funktionsprinzip im Detail

5.2.1Die KDC-Datenbank

5.2.2Der Authentication Service (AS)

5.2.3Zugriff auf kerberisierte Dienste

5.2.4Der Ticket-Granting Service (TGS)

5.3Zusammenfassung

6Kerberos für Fortgeschrittene

6.1KDC-Optionen

6.1.1Optionen für Ticket Renewing

6.1.2Optionen für Ticket Postdating

6.1.3Optionen für die Kerberos-Delegation

6.1.4Sonstige Optionen

6.2Ticket Flags

6.2.1Flags für Ticket Renewing

6.2.2Flags für Ticket Postdating

6.2.3Flags für die Kerberos-Delegation

6.2.4Sonstige Flags

6.3AP-Optionen

6.4Tickets automatisiert erneuern

6.5Tickets für die Zukunft

6.6Delegation zum Ersten

6.6.1Ticket Forwarding

6.6.2Ticket Proxying

6.7Authentisierung zwischen Realms

6.7.1Grundsätzliches zu Vertrauensstellung

6.7.2Zwei Realms

6.7.3Mehr als zwei Realms

6.8Namenskanonisierung und Referrals

6.8.1Kanonisierung der Client-Principal-Namen

6.8.2Kanonisierung der Dienste-Principal-Namen

6.8.3Verweise an entfernte Realms

6.9User-to-User-Authentisierung

6.10Kerberos und Autorisierungsdaten

6.11Die S4U2Self-Erweiterung

6.12Delegation zum Zweiten

6.12.1Constrained Delegation

6.12.2Protocol Transition

6.12.3Diskussion

6.13Initiale Authentisierung mit Zertifikaten

6.13.1Eine Lösung für die Passwort-Problematik

6.13.2Das Funktionsprinzip von PKINIT

6.13.3Anonymes PKINIT

6.13.4PKINIT Freshness Extension

6.13.5Fazit

6.14FAST: zusätzlicher Schutz für KDC-Austausch

6.15Kerberos über HTTPS

6.16Initiale Authentisierung mit zweitem Faktor

IIZentrale Infrastrukturen

7Grundlegende Infrastruktur

7.1Überblick

7.2Software, Systemdienste und lokale Firewall

7.3DNS-Namensauflösung mit BIND

7.3.1BIND installieren

7.3.2Zonen einrichten

7.3.3Starten und Testen

7.3.4Subdomänen

7.4Zeitsynchronisation mit NTP

7.5Certificate Authority (CA) mit OpenSSL

7.5.1Einrichtung der CA

7.5.2Einen Zertifikatsrequest erzeugen

7.5.3Das Zertifikat unterschreiben

7.6Verzeichnisdienst mit OpenLDAP

7.6.1Installation und Grundkonfiguration

7.6.2Schemadefinition

7.6.3Datenbank für dc=example,dc=com konfigurieren

7.6.4Datenbank für dc=example,dc=com befüllen

7.6.5Ein erster Test

7.6.6Sicherheit

8Das Key Distribution Center von MIT Kerberos

8.1Übersicht

8.2Softwareinstallation

8.3Konfiguration

8.3.1Der Master Key der KDC-Datenbank

8.3.2Zeitangaben bei MIT Kerberos

8.3.3Verschlüsselungstypen

8.3.4Die Datei kdc.conf

8.4Initialisierung der KDC-Datenbank

8.4.1Die Datenbank mit kdb5_util initialisieren

8.4.2Die initiale Datenbank

8.4.3Mit kadmin.local weitere Principals anlegen

8.4.4Master Key in Stash-Datei ablegen

8.5Ein erster Test

9Die Administration von MIT Kerberos

9.1Der Kadmin-Dienst

9.2Administrative Zugriffe kontrollieren

9.3Der Kpasswd-Dienst

9.4Starten der administrativen Dienste

9.5Principals verwalten

9.5.1Passwortrichtlinien

9.5.2Lockout Policies

9.5.3Principal-Eigenschaften

9.5.4Principals für Anwender:innen anlegen

9.5.5Principals für Dienste anlegen

9.5.6Verschlüsselungstypen der Principals verwalten

9.6Keytabs verwalten

9.6.1Keytabs mit kadmin verwalten

9.6.2Keytabs mit ktutil verwalten

9.7Service Keys ändern

10Die Clientkommandos von MIT Kerberos

10.1Installation und Konfiguration

10.2Die Kommandos kinit und klist

10.2.1Tickets holen

10.2.2Den Credential Cache auswählen

10.2.3Ticket-Eigenschaften anzeigen und beeinflussen

10.2.4Protokollrequests beeinflussen

10.2.5Sonstige Kommandozeilenoptionen

10.2.6Service Tickets holen

10.2.7Mit Keytabs arbeiten

10.3Das Kommando kvno

10.4Das Kommando kpasswd

10.5Das Kommando kdestroy

10.6Die Kommandos k5start und krenew

10.6.1krenew

10.6.2k5start

11Die Konfiguration der MIT Libraries

11.1Die Datei krb5.conf

11.1.1Die Struktur der krb5.conf

11.1.2Konfigurationsabschnitte

11.1.3Parameter im Abschnitt [libdefaults]

11.1.4Parameter im Abschnitt [realms]

11.1.5Parameter im Abschnitt [domain_realm]

11.1.6Parameter im Abschnitt [appdefaults]

11.1.7Die krb5.conf für den Realm EXAMPLE.COM

11.2Konfiguration über DNS

11.2.1SRV Records

11.2.2TXT Records

11.3Konfiguration mit Umgebungsvariablen

12Ausfallsicherheit für MIT Kerberos

12.1Backup der KDC-Datenbank

12.2Wiederherstellung der KDC-Datenbank

12.3Replikation der KDC-Datenbank

12.3.1Möglichkeiten der Kerberos-Replikation

12.3.2Sicherheit der Replikation

12.4Replikation bei MIT Kerberos

12.4.1Ein Replica KDC einrichten

12.4.2Schritte auf dem Master KDC

12.4.3Das Replica KDC starten

12.4.4Das Replica KDC bekannt machen

12.4.5Regelmäßig replizieren

13Ein LDAP-Backend für die MIT-Datenbank

13.1Überblick

13.1.1Erweiterte Funktionalitäten

13.1.2Vorgehensweise

13.1.3Sicherheit

13.2Software, Schema und Konfiguration des LDAP-Servers

13.2.1Software installieren

13.2.2Das Schema erweitern

13.3Das KDC auf LDAP umstellen

13.3.1Vorbereitungen

13.3.2Konfiguration

13.3.3Die KDC-Datenbank im LDAP initialisieren

13.3.4Den Realm einrichten

13.4Existierende Nutzerobjekte

13.5Principal-Aliase

13.5.1Client-Aliase

13.5.2Dienste-Aliase

13.6Ausfallsicherheit mit LDAP

13.6.1OpenLDAP auf kdc01 vorbereiten

13.6.2LDAP-Server auf kdc02 einrichten

13.6.3Ausfallsicherheit für das KDC

13.6.4Die Clientkonfiguration anpassen

14Einen Heimdal Realm einrichten

14.1Überblick

14.2Vorbereitung

14.3Das Key Distribution Center von Heimdal

14.3.1Die Datei kdc.conf

14.3.2Master Key

14.3.3Die KDC-Datenbank initialisieren

14.3.4Das KDC starten

14.4Die Administration von Heimdal

14.4.1Administrative Zugriffe kontrollieren

14.4.2Principals verwalten

14.4.3Weitere administrative Tätigkeiten

14.4.4Passwörter verwalten

14.5Die Heimdal-Werkzeuge

14.6Ausfallsicherheit für Heimdal

14.6.1Ein Replica KDC einrichten

14.6.2Starten des hpropd auf dem Replica KDC

14.6.3Die Replikation mit Hprop starten

14.6.4Regelmäßig replizieren

14.7Ein LDAP-Backend für Heimdal

14.7.1LDAP vorbereiten

14.7.2Das KDC auf LDAP umstellen

14.7.3Ausfallsicherheit mit LDAP

15Kerberos bei Microsoft Active Directory

15.1Active Directory im Überblick

15.1.1Kerberos in Active Directory

15.1.2Kerberos-Erweiterungen

15.1.3AD-Version und Functional Level

15.2Testlabor

15.3Das Key Distribution Center von Active Directory

15.3.1Die Domäne einrichten

15.3.2Grundlegende Dienste

15.3.3Ein erster Test

15.3.4Ausfallsicherheit

15.4Kerberos-Administration

15.4.1Administrationswerkzeuge

15.4.2Überblick über den neuen Realm

15.4.3Principals verwalten

15.4.4Verschlüsselungstypen

15.4.5Kerberos Policies

15.5Keytab-Verwaltung in AD-Infrastrukturen

15.5.1Keytabs unter Windows mit ktpass.exe erzeugen

15.5.2Host Keytabs unter Linux mit adcli verwalten

15.5.3Host Keytabs unter Linux mit msktutil verwalten

15.5.4Keytabs für Service Accounts unter Linux mit msktutil verwalten

15.6Kerberos-Administration mit LDAP

15.6.1LDAP-Suchen im AD

15.6.2Ein Benutzerobjekt anlegen

15.6.3Diensteobjekte anlegen

15.6.4Maschinenobjekte anlegen

15.7Weitere Werkzeuge

16Active Directory mit Samba 4

16.1Die Domäne einrichten

16.1.1DNS verwalten

16.1.2Ein erster Test

16.1.3Ausfallsicherheit

16.2Kerberos-Administration

16.2.1Benutzerkonten und Gruppen verwalten

16.2.2Principals verwalten

16.3Sicherheitsrichtlinien

16.4Domain Join und Keytab-Verwaltung

16.5Fazit

17Kerberos bei FreeIPA

17.1FreeIPA im Überblick

17.1.1IPA-Komponenten

17.1.2Deployment-Szenario

17.2Die Domäne einrichten

17.3Verwaltungsaufgaben in der IPA-Domäne

17.4Integration weiterer Linux-Systeme

17.5Ausfallsicherheit

17.6Fazit

18Kerberos für Fortgeschrittene

18.1Verteilte Kerberos-Umgebungen

18.1.1Cross-Realm bei MIT Kerberos

18.1.2Cross-Realm bei Heimdal

18.1.3Cross-Realm bei Active Directory

18.1.4Aufbau der Gesamtstruktur

18.2Delegation für Fortgeschrittene

18.2.1Vorbereitungen

18.2.2Das Ok-As-Delegate Flag

18.2.3kimpersonate

18.2.4Constrained Delegation und Protocol Transition

18.3PKINIT

18.3.1Initiale Authentisierung mit Zertifikaten

18.3.2PKINIT im Testnetz

18.3.3Kerberos, PKINIT und Smartcards

18.3.4Anonymes PKINIT

18.4Zwei-Faktor-Authentisierung

18.4.1OTP Tokens bei IPA

18.4.2OTP und Passwort bei der Anmeldung

18.4.3OTP und Passwort bei kinit

IIIIntegrierte Umgebungen

19Grundlagen

19.1Principals und Keytabs verwalten

19.1.1Client-Principals anlegen

19.1.2Funktionalität von Client-Principals prüfen

19.1.3Dienste-Principals anlegen

19.1.4Funktionalität von Dienste-Principals prüfen

19.1.5Keytab-Dateien anlegen

19.1.6Funktionalität von Keytab-Dateien prüfen

19.2Zwischenstand

19.3Die nativen Kerberos-Bibliotheken

19.4GSS-API

19.5SPNEGO

19.6SSPI

19.7SASL

19.7.1Protokolle

19.7.2Mechanismen

19.7.3Konzepte

19.7.4Cyrus SASL

19.8Zusammenfassung

20LDAP-Infrastruktur

20.1LDAP im Überblick

20.1.1Begriffe und Standards

20.1.2Serverimplementierungen

20.1.3Daten im LDAP

20.1.4Verzeichnisoperationen

20.2LDAP-Sicherheit

20.3Kerberisierung bei Active Directory

20.4Kerberisierung bei OpenLDAP

20.4.1SASL-Konfiguration

20.4.2Principal und Keytab

20.4.3Identitätsmapping

20.5Zusammenfassung

21Clientanbindung

21.1Windows-Clients in Active Directory

21.2Linux-Clients in Active Directory

21.3Der System Security Services Daemon

21.3.1Einfache sssd-Konfiguration für Active Directory

21.3.2Name Service Switch (NSS) mit sssd

21.3.3Pluggable Authentication Modules (PAM) mit sssd

21.3.4Erweiterte sssd-Konfiguration

21.4Ausbau der Gesamtstruktur

21.4.1LDAP-Referrals einrichten

21.4.2Identitäts- und Autorisierungsdaten für Linux

21.5Linux-Clients in der Gesamtinfrastruktur

21.5.1Anbindung testen

21.5.2Multi-Domänen-Anbindung konfigurieren und testen

21.5.3Schattenobjekte für LDAP-Zugriff auf Active Directory

21.6Zusammenfassung

22Elementare Netzwerkdienste unter Unix und Linux

22.1Kerberos mit OpenSSH

22.1.1Vorbereitungen

22.1.2Kerberisierte Secure-Shell-Sitzung

22.1.3Tickets weiterleiten

22.1.4Secure-Shell-Client unter Windows

22.1.5OpenSSH ohne Kerberos Tickets

22.2Remote-Dienste in verteilter Umgebung

22.2.1Cross-Realm-Problematik

22.2.2auth_to_local-Mappings

22.2.3Heimdal

22.2.4Cross-Realm-Anmeldung ohne Kerberos Tickets

23Kerberisierte Dateisysteme

23.1Server Message Block

23.1.1SMB-Service unter Windows einrichten

23.1.2Authentisierung bei SMB

23.1.3SMB-Client unter Linux

23.1.4SMB-Service unter Linux: Samba

23.1.5ID Mapping

23.1.6Heimatverzeichnisse für alle Windows-Nutzer

23.2Network File System

23.2.1Überblick

23.2.2NFSv3 ohne Kerberos

23.2.3NFSv3 und Sicherheit

23.2.4NFSv

23.2.5Kerberisierter NFSv4-Service unter Linux

23.2.6Den Server für Kerberos einrichten

23.2.7Kerberisierter NFSv4-Client unter Linux

23.2.8Den Client einrichten

23.2.9NFSv4 und Sicherheit

23.2.10NFSv4 in Cross-Realm-Umgebung

23.2.11Abschlussarbeiten

23.3Nichtinteraktiver Zugriff auf NFS-Verzeichnisse

23.3.1Impersonifizierung über gssproxy einrichten

23.3.2Impersonifizierung testen

23.4Zusammenfassung

24Single Sign-on für Webdienste

24.1Kerberos und das HTTP-Protokoll

24.1.1Das World Wide Web

24.1.2Authentisierung im HTTP-Protokoll

24.1.3Negotiate (SPNEGO)

24.2Den Apache-Server konfigurieren

24.2.1Voraussetzungen

24.2.2Principals und Keytab-Einträge

24.2.3mod_auth_gssapi konfigurieren

24.3Browserkonfiguration

24.3.1Vertrauenswürdige Seiten konfigurieren

24.3.2Zugriff testen

24.3.3Delegation konfigurieren

24.3.4Delegation testen

24.4Autorisierungsdaten und Ticket-Größe

24.5Autorisierung über LDAP

24.6Kerberos und Web-SSO

24.6.1Keycloak installieren

24.6.2Keycloak kerberisieren

24.6.3Account-Konsole als Test

24.6.4Erweiterungsmöglichkeiten

24.7Kerberos-Authentisierung im Web-Proxy

24.7.1Den Squid-Proxy vorbereiten

24.7.2Kerberos-Principal für Squid

24.7.3Squid-Anmeldung konfigurieren

24.7.4Browserkonfiguration für Proxy-Authentisierung

24.8Zusammenfassung

IVAnhang

ASchnelleinstieg in LDAP

A.1LDIF

A.1.1Das LDAP-Datenmodell

A.1.2LDIF-Repräsentation von LDAP-Daten

A.1.3Änderungen mit LDIF

A.2OpenLDAP-Tools

A.2.1Suchen mit ldapsearch

A.2.2Authentisierung

A.2.3Weitere OpenLDAP-Kommandos

A.3Grafische LDAP-Werkzeuge

BKonfiguration der Betriebssysteme

B.1Netzwerkparameter

B.2CentOS 8

B.3Windows Server 2019

B.4Windows 10

CSoftwareinstallationen

C.1Vorbemerkungen

C.2MIT Kerberos

C.3Heimdal

C.4k5start

C.5msktutil

C.6Samba

Literaturverzeichnis

Index

I

Kerberos

1Kerberos im Überblick

Dieses Kapitel soll Ihnen einen Überblick über den Authentisierungsdienst Kerberos vermitteln. Sie lernen zunächst seine Entstehungsgeschichte kennen, die vor fast 40 Jahren mit dem Athena-Projekt begann. Nach einem Überblick über die Versionen des Kerberos-Protokolls und deren Standardisierungen erfahren Sie, welche Implementierungen von Kerberos heutzutage existieren.

1.1Ursprung am MIT: das Athena-Projekt

In der griechischen Mythologie war Kerberos ein dreiköpfiger Hund, der den Zugang zum Reich der Toten bewachte. Um diesen soll es hier allerdings nicht gehen, sondern um einen Authentisierungsdienst, der zumindest den Namen dieses Hundes geerbt hat. Die Geschichte des Kerberos-Authentisierungsdienstes beginnt in den 80er-Jahren des letzten Jahrhunderts.

Damals waren typische Computerumgebungen noch vorwiegend zentral organisiert. Der Großteil der Speicher- und Rechenleistung war auf wenige Großrechner konzentriert, auf die über Terminals zugegriffen wurde. Mit dem Aufkommen von immer günstigeren Mini- und Mikrocomputern, die im Gegensatz zu Terminals vernetzt und mit eigenem Datenspeicher ausgestattet waren, sollte sich die zentrale Struktur der Großrechnernetze bald in eine verteilte Struktur von vernetzten Arbeitsplatzrechnern wandeln.

Das Athena-Projekt

In dieser Zeit rief das Massachusetts Institute of Technology (MIT) in Boston, USA, das Athena-Projekt ins Leben, um die Möglichkeiten von Computern in der studentischen Ausbildung zu untersuchen. Im Rahmen dieses Forschungsprojektes wurde am Campus des MIT eine verteilte Umgebung von vernetzten Arbeitsplatzrechnern geschaffen – aus heutiger Sicht klingt das wie selbstverständlich. Tatsächlich kann das Athena-Netzwerk in vielen Punkten als Vorbild aktueller IT-Umgebungen gelten: Längst ist es allgemein üblich, Speicher- und Rechenleistung auf viele leistungsfähige Rechner zu verteilen.

Das Athena-Projekt startete im Jahre 1983 und war zunächst auf nur fünf Jahre angelegt. Danach wurde es um weitere drei Jahre verlängert und endete im Jahre 1991. Die Unternehmen DEC und IBM unterstützten das Athena-Projekt.

Mehr als 100 Softwareprojekte wurden im Rahmen von Athena durchgeführt. Bei den meisten dieser Projekte ging es um die Entwicklung von Software, die im Rahmen der studentischen Ausbildung genutzt werden sollte. Der folgende Abschnitt zeigt jedoch beispielhaft einige weitere Projekte von größerer Tragweite, die Software und Konzepte für die Verwaltung verteilter Rechnernetze entwickeln sollten.

Teilprojekte

X Window

In einem Teilprojekt wurde die Möglichkeit einer netzwerkfähigen, grafischen Benutzeroberfläche für die Arbeitsplatzrechner untersucht. Ergebnis dieses Teilprojektes war das Fenstersystem X Window, das noch heute das Standardfenstersystem der meisten Unix-Betriebssysteme ist. Auch die sogenannten »Athena-Widgets« sind ein Ergebnis dieses Athena-Teilprojektes.1

Hesiod

Mit Hesiod wurde ein netzwerkweiter Namensdienst eingeführt. Im Kern handelt es sich dabei um eine Erweiterung des DNS-Servers BIND. Neben den Informationen über IP-Adressen und zugeordneten Hostnamen stellt Hesiod auch typische Unix-Systeminformationen zentral zur Verfügung, die herkömmlicherweise in Dateien wie /etc/passwd, /etc/group oder /etc/printcap gespeichert werden. Hesiod konnte sich allerdings nicht gegen alternative Entwicklungen wie NIS oder LDAP durchsetzen.

Auch andere Teilprojekte spielen heutzutage kaum noch eine Rolle, wie z. B. Moira (ein Tool zur zentralen Systemverwaltung), Palladium (ein Druckdienst) oder Zephyr (ein System zur Onlinebenachrichtigung).

Vernetzung und Sicherheit

Kerberos

Doch jenseits der konkreten Software erforderte die verteilte Struktur des Athena-Netzwerks vor allem grundlegend neue Konzepte. Allen voran hob die steigende Vernetzung auch das Thema Netzwerksicherheit auf eine neue Ebene. Musste man sich bislang nur um die Sicherheit weniger Großrechner kümmern, waren in der verteilten Umgebung nun wesentlich mehr Systeme in die Sicherheitsanalyse einzubeziehen. Um dieser Herausforderung zu begegnen, wurde Kerberos entwickelt. Kerberos ist in erster Linie ein Dienst bzw. ein Protokoll zur Authentisierung, deckt aber auch andere Sicherheitsaspekte ab. Welche Aufgaben Kerberos zu erfüllen hat bzw. welche Aspekte eines Sicherheitssystems durch Kerberos abgedeckt werden, wird in den Kapiteln 2 und 4 behandelt. Hier soll zunächst die Entwicklungsgeschichte weiter verfolgt werden.

1.2Versionen des Kerberos-Protokolls

Kerberos v4

Im Rahmen des Athena-Projektes durchlief Kerberos drei Versionen, die reine Entwicklungsversionen waren und nur innerhalb des MIT eingesetzt wurden (Kerberos v1, Kerberos v2 und Kerberos v3). Erst im Jahre 1989 wurde die vierte Version (Kerberos v4) freigegeben. Kerberos v4 wurde auch außerhalb des MIT zum Industriestandard und war viele Jahre lang im Einsatz.

AFS, kaserver

Zur gleichen Zeit wurde für das Andrew File System (AFS) unter dem Namen kaserver ein Kerberos-v4-ähnlicher Authentisierungsdienst entwickelt. Das AFS und der kaserver entstanden im Rahmen des Andrew-Projektes an der Carnegie Mellon University (CMU) und wurden vor Kerberos v4 veröffentlicht. Daher entsprach der kaserver nicht ganz dem Kerberos-v4-Standard.

Kerberos v5

Kerberos v4 und kaserver hatten diverse kryptografische Schwächen und konnten stetig steigende Sicherheitsanforderungen schließlich nicht mehr erfüllen. Zu diesen Schwächen gehört sicherlich, dass sie nur einen Verschlüsselungsmechanismus kannten, nämlich die längst nicht mehr zeitgemäße, einfache Variante des Data Encryption Standard (Single DES). Diese und andere Schwächen führten schließlich zur heute aktuellen Version Kerberos v5.

Spricht man heute nur von »Kerberos«, so ist in aller Regel Kerberos v5 gemeint. Wenn im weiteren Verlauf dieses Buches der Zusatz »v4« bzw. »v5« weggelassen wird, so soll immer die Version 5 gemeint sein.

Dabei gilt zu beachten: Die hier genannten Versionsnummern (4 und 5) beziehen sich auf die Version des Kerberos-Protokolls. Die Versionsnummern von Kerberos-Software haben damit nichts zu tun. Letztere werden in Abschnitt 1.4 behandelt.

1.3Standardisierung

Referenzimplementierung: KRB4

Kerberos v4 wurde am MIT entwickelt und der Allgemeinheit in Form von Quellcode unter dem Namen MIT Kerberos v4 (KRB4) zur Verfügung gestellt. MIT Kerberos v4 stellte die Referenzimplementierung des Kerberos-v4-Protokolls dar. Hersteller von Kerberos-v4-Software konnten die Funktionsweise des Kerberos-v4-Protokolls durch Studium dieses Quellcodes erlernen oder ihre Software gleich auf der MIT-Implementierung aufbauen.

Internetstandard RFC 1510

Die Herangehensweise an die Standardisierung des Protokolls änderte sich bei der Entwicklung von Kerberos v5 wesentlich. Das Kerberos-v5-Protokoll wurde nämlich als ein Internetstandard (RFC) spezifiziert. Alle Implementierungen von Kerberos v5 basieren daher auf dem RFC 1510 [14] aus dem Jahre 1993.

RFC 4120

An einer neueren Version des RFC 1510 wurde mehrere Jahre unter dem Namen »Kerberos Clarifications« gearbeitet. Das Ergebnis ist der RFC 4120 [25], »The Kerberos Network Authentication Service (V5)«, der im Jahre 2005 veröffentlicht wurde und den RFC 1510 ablöst. Die Beschreibung des Kerberos-v5-Protokolls im RFC 4120 erfolgt durch eine allgemeine Syntaxbeschreibungssprache, die »Abstract Syntax Notation number One (ASN.1)«.

1.4Implementierungen

Neben den bereits erwähnten Referenzimplementierungen des MIT existieren weitere Implementierungen von Kerberos (sowohl von Version 4 als auch von Version 5). In Tabelle 1.1 findet man die URLs, unter denen man die im Folgenden vorgestellten Implementierungen beziehen kann.

Tab. 1.1 Kerberos-Implementierungen

Implementierung

URL

MIT Kerberos v4

ftp://athena-dist.mit.edu/pub/kerberos/dist/960200

960200 Bones

ftp://athena-dist.mit.edu/pub/kerberos/bones.tar.Z

MIT Kerberos v5

https://web.mit.edu/Kerberos/

Heimdal

https://github.com/heimdal/heimdal

ShiShi

https://www.gnu.org/software/shishi

kaserver

https://www.openafs.org

Active Directory

https://www.microsoft.com

Java

https://www.java.com

Apache Directory Server

https://directory.apache.org

WAFFLE

https://github.com/Waffle/waffle

1.4.1Kerberos v4

KRB4

Das am MIT entwickelte MIT Kerberos v4 (KRB4) sollte wie alle Kerberos-v4-Implementierungen nur noch von historischem Interesse sein, da sich im Laufe der Zeit einige kryptografische Schwächen dieser Version des Protokolls herausgestellt haben. Die Entwicklung wurde im Jahre 1992 mit dem Patch-Level 10 eingestellt.

ExportbeschränkungenBones

Da die US-Regierung den Export von kryptografischer Software zu damaliger Zeit grundsätzlich stark einschränkte, konnte Kerberos v4 zunächst nicht außerhalb der USA eingesetzt werden. Um diese Exportbeschränkung zu umgehen, stellte das MIT unter dem Namen Bones eine Version ihrer Kerberos-v4-Referenzimplementierung bereit, die die exportkritischen kryptografischen Funktionen (insbesondere das Verzeichnis lib/des) nicht enthielt und daher exportiert werden konnte.

eBones KTH-KRB

Außerhalb der USA wurde Bones um die fehlenden kryptografischen Funktionen erweitert und unter dem Namen eBones verbreitet. Auch das an der Königlich Technischen Hochschule (KTH) in Stockholm entwickelte KTH-KRB basiert auf Bones bzw. eBones und damit letztendlich auf der Kerberos-v4-Referenzimplementierung des MIT.

1.4.2Kerberos v5

MIT Kerberos

Am MIT wurde unter dem Namen KRB5 eine Implementierung des Kerberos-v5-Protokolls geschaffen. MIT Kerberos unterlag zunächst den gleichen Exportbeschränkungen wie ihre Vorgängerversion.

Heimdal

Daher wurde an der KTH auch eine Kerberos-v5-Software implementiert. Diese nennt sich Heimdal und ist im Gegensatz zu KTH-KRB eine vollständig neue Implementierung, die nicht auf MIT-Quellen basiert. Im europäischen Raum entwickelt und damit nicht von den US-Exportregulierungen betroffen, fand Heimdal außerhalb der USA große Verbreitung. So setzte der deutsche Linux-Distributor SUSE lange Zeit auf Heimdal, erst seit der zeitweisen Übernahme von SUSE durch Novell wird auch bei SUSE-Linux MIT Kerberos verwendet.

Nachdem die US-Regierung die Exportbeschränkungen für kryptografische Software gelockert hat, kann MIT Kerberos heutzutage auch außerhalb der USA eingesetzt werden.

ShiShi

Eine komplette Neuimplementierung unter der GNU General Public License (GPL) stellt ShiShi dar. Diese Software ist allerdings kaum verbreitet und wird in diesem Buch daher nicht behandelt.

Die bisher genannten Implementierungen vom MIT und der KTH sind im Wesentlichen für Unix-artige Betriebssysteme gedacht (obwohl das MIT mit Kerberos for Windows (KfW) seine Software auch für Windows bereitstellt).

Microsoft Active Directory

NTLMActive Directory

Microsoft hat für seine Windows-Betriebssysteme zunächst ein eigenes, proprietäres Authentisierungsverfahren entwickelt, das unter dem Namen NTLM (später NTLMv2) bekannt ist. NTLM wurde von Microsoft seit der Zeit von Windows NT eingesetzt. Ab Windows 2000 und dem damit eingeführten Active Directory hat Kerberos v5 auch in die Windows-Welt Einzug gehalten: In Active-Directory-Domänen wird Kerberos v5 als primärer Authentisierungsdienst verwendet (obwohl NTLM auch dort immer noch unterstützt wird). Die große Verbreitung von Windows und Active Directory hat sicherlich einen wichtigen Beitrag dazu geleistet, dass Kerberos sich als Standardauthentisierungsverfahren weiter durchsetzen konnte.

Samba 4

Unter Unix/Linux wiederum enthält Samba 4 Softwarekomponenten, um Funktionen einer Active-Directory-Domäne bereitzustellen. Samba 4 beinhaltet allerdings keine eigene Kerberos-v5-Implementierung. Ursprünglich kommt hier Heimdal zum Einsatz, Teile des Funktionsumfangs können inzwischen jedoch auch mit MIT Kerberos als Basisimplementierung übersetzt werden.

Java

JAAS

Oracles Java ab Version 1.4 enthält innerhalb des JAAS-Frameworks (Java Authentication and Authorization Service) ebenfalls eine Kerberos-Implementierung. Dabei handelt es sich allerdings nur um eine Bibliothek, mit der Java-Programme an der Kerberos-Authentisierung teilnehmen können. Sie dient nicht dem Aufbau einer Kerberos-Infrastruktur.

WAFFLE

Dasselbe gilt auch für das Windows Authentication Framework WAFFLE, eine nur unter Windows nutzbare Java-Software, die Anbindung an Windows-Authentisierungsverfahren und damit auch an Kerberos bietet.

Apache Directory Server

Im Gegensatz dazu ist der Apache Directory Server eine Java-basierte Infrastrukturlösung, die neben Kerberos- auch LDAP-Dienste beinhaltet.

1.4.3Interoperabilität und Kompatibilität

Die wichtigsten Implementierungen sind derzeit also MIT Kerberos, Heimdal und Active Directory. Nur sie sollen in diesem Buch behandelt werden.

Zur Kompatibilität der Protokollversionen ist nur zu sagen, dass Kerberos v4 und v5 prinzipiell inkompatibel zueinander sind.

Die hier genannten Kerberos-v5-Implementierungen unterscheiden sich zwar in manchen Punkten, sind aber hinreichend kompatibel, um eine Interoperabilität auf Netzwerkebene zu gewährleisten. Sie werden die Gemeinsamkeiten und Unterschiede im weiteren Verlauf dieses Buches kennenlernen.

API-Kompatibilität

Anders verhält es sich aus Sicht der Softwareentwicklung: Im Gegensatz zum Netzwerkprotokoll ist die Programmierschnittstelle (API) im Kerberos-Standard nicht festgelegt. Auch wenn Heimdal und MIT Kerberos sich an manchen Punkten ähneln, verwendet grundsätzlich jede Implementierung ihre eigenen Aufrufe. Um auf API-Ebene Kompatibilität mit verschiedenen Kerberos-Implementierungen zu erreichen, sind Anwendungen üblicherweise nicht direkt für Kerberos programmiert, sondern für eine höhere, einheitliche Abstraktionsschicht. Genaueres zu den wichtigsten Schnittstellen GSS-API und SSPI erfahren Sie in den Abschnitten 19.4 und 19.6.

2Grundlagen der Netzwerkauthentisierung mit Kerberos

Das vorangegangene Kapitel hat Kerberos von seiner Entwicklungsgeschichte und seinen Implementierungen her beleuchtet: Demnach handelt es sich bei Kerberos um einen Authentisierungsdienst bzw. um ein Authentisierungsprotokoll. Allerdings wurde der Begriff Authentisierung (bzw. Authentifizierung) dort nicht genauer definiert. Da dieser Begriff aber wesentlich für die folgenden Kapitel dieses Buches ist, soll seine Klärung hier nachgeholt werden.

Darüber hinaus sollen hier die ebenfalls wesentlichen Begriffe Autorisierung, Zugriffskontrolle, Delegation sowie Single Sign-on (SSO) erklärt und deren Zusammenhang mit Kerberos beleuchtet werden.

2.1Authentisierung

Authentisierung: »Wer bin ich?«Authentifizierung: »Wer sind Sie?«

Unter Authentisierung versteht man den Nachweis der eigenen Identität. Dabei kann es sich um die Identität einer Person oder auch um die eines Computerprogramms handeln. Wird dagegen eine angegebene Identität überprüft, so spricht man von Authentifizierung1. Auch hier kann es um die Identität eines Menschen oder eines Programms gehen.

Ein Beispiel: Eine Person, die sich an einem Computer anmeldet, gibt dazu ihren Usernamen und zusätzliche Informationen (typischerweise ein Passwort) an. Damit authentisiert sie sich gegenüber dem Anmeldeprogramm des Computers. Das Anmeldeprogramm überprüft das Passwort und authentifiziert die Person. Abbildung 2.1 veranschaulicht diesen Vorgang.

Bevor es in Abschnitt 2.1.3 mit den konkreten Authentisierungsvorgängen in Rechnernetzen weitergehen soll, werden sich die folgenden beiden Abschnitte zunächst grundsätzlich mit den möglichen Authentisierungsmerkmalen und insbesondere mit Passwörtern auseinandersetzen.

Abb. 2.1Eine Person meldet sich an ihrem Arbeitsplatzrechner an. Dabei authentisiert sie sich durch die Eingabe ihres Passwortes.

2.1.1Authentisierungsmerkmale

Passwort

Die eigene Identität zu belegen oder die Identität eines anderen zu überprüfen, stellt eine vergleichsweise einfache Aufgabe dar, wenn es sich bei den Beteiligten um Menschen handelt. Denn die können sich anhand von Merkmalen wie ihrem Aussehen oder dem Klang ihrer Stimme erkennen. Darüber hinaus besitzen Menschen weitere eindeutige Merkmale wie den Fingerabdruck oder die Unterschrift. Solche Merkmale können ebenfalls für eine Identitätsprüfung herangezogen werden, wenn Aussehen oder Stimme unbekannt sind. Auch wenn alle diese Merkmale unbekannt sein sollten, so können sich zwei Menschen immer noch anhand eines gemeinsamen Geheimnisses (Shared Secret) gegenseitig ihre Identität nachweisen. Solch ein gemeinsames Geheimnis kann bei zwei Personen beispielsweise ein Losungs- bzw. Passwort sein.

Kryptografische Schlüssel

Computer besitzen zunächst keine vergleichbaren Merkmale, die sie derartig einmalig machen. Außerdem haben sie nur eingeschränkte Fähigkeiten, die oben beschriebenen Merkmale wie Aussehen oder Stimme auszuwerten. Diese Unfähigkeit gleichen sie wiederum dadurch aus, dass sie sich wesentlich komplexere und damit sicherere Geheimnisse merken können als Menschen. Anstelle von Codewörtern benutzen Computer für diesen Zweck sehr lange kryptografische Schlüssel (Keys). Dabei handelt es sich um möglichst zufällig gewählte Folgen von Nullen und Einsen einer bestimmten Länge. Eine Schlüssellänge von 256 Bit ist heutzutage für symmetrische Kryptografie üblich.

Key Derivation Functionstring2key

Unsere menschlichen Gehirne sind kaum in der Lage, sich solche kryptografischen Schlüssel zu merken. Wir müssen uns daher mit Passwörtern behelfen. Computer nutzen sogenannte Key Derivation Functions, um aus diesen Passwörtern wiederum kryptografische Schlüssel zu erzeugen, mit denen sie besser umgehen können. Natürlich haben solche passwortbasierten Schlüssel lediglich die gleiche Sicherheit wie die zugrunde liegenden Passwörter. Kerberos verwendet als Key Derivation Functions sogenannte string2key-Funktionen. Abschnitt 4.2.4 wird sich genauer mit Passwörtern und Schlüsseln beschäftigen.

Kategorien

Passwörter und kryptografische Schlüssel sind nicht die einzigen möglichen Authentisierungsmerkmale. Im Allgemeinen kann man Authentisierungsmerkmale in folgende drei Kategorien einteilen:

persönliches Wissen

persönlicher Besitz

biometrisches Merkmal

PIN

Unter 1 fallen die im Computerumfeld üblichen Passwörter oder die in Agentenfilmen gebräuchlichen Codewörter, aber auch die Persönliche Identifikationsnummer (PIN) bei Bankgeschäften. Diese Merkmale haben mehrere Nachteile: So eignen sie sich beispielsweise nicht für sehr vergessliche Menschen. Außerdem können sie ausspioniert werden, auch ohne dass das Opfer es bemerkt. Abschnitt 2.1.2 geht insbesondere auf die Nachteile der Passwörter im Detail ein.

SmartcardsKerberos Ticket

Zu den Authentisierungsmerkmalen, die man besitzt (2), zählen solche Dinge wie der Personalausweis, die EC-Karte oder auch die Transaktionsnummern beim Internet-Banking (TAN-Listen). Im Computerumfeld zählen hierzu Token-Karten, SSL-Zertifikate, Smartcards oder auch Listen von Einmalpasswörtern. Auch die in Abschnitt 2.2.4 beschriebenen Kerberos Tickets gehören zu dieser Kategorie. Der Nachteil der Merkmale der Kategorie 2 ist, dass man sie entwenden kann, wobei Kerberos diesem Manko durch eine sehr kurze Gültigkeit der Tickets begegnet.

Biometrie

Die biometrischen Merkmale (3) gehören eigentlich auch zu den Dingen, die man besitzt. Sie haben aber den Vorteil, dass sie nicht so leicht zu entwenden sind. Zu diesen Merkmalen zählt man z. B. Aussehen, Stimme, Fingerabdruck, Augenhintergrund oder Unterschrift. Der Nachteil der biometrischen Merkmale liegt darin, dass Computer sie nicht besonders gut erkennen und verarbeiten können und dass die Authentisierung über diese Merkmale daher fehleranfällig ist.

Verwendung

Alle drei Kategorien von Authentisierungsmerkmalen haben ihre Vor- und Nachteile. Idealerweise kombiniert man daher Merkmale verschiedener Kategorien, um die einzelnen Nachteile auszugleichen. Beispielsweise sind Geldgeschäfte mit einer EC-Karte (Merkmaltyp 2) nur durch zusätzliche Kenntnis einer PIN (Merkmaltyp 1) oder durch Leisten einer Unterschrift (Merkmaltyp 3) möglich. Auch die üblichen Token-Karten (Merkmaltyp 2) können nur in Kombination mit einer PIN (Merkmaltyp 1) benutzt werden.

2.1.2Problematik der Passwörter

Leicht zu erraten

Die Verwendung von Passwörtern für die Authentisierung von Personen ist problematisch. Denn die Passwörter sind oftmals einfach gewählt, damit man sie sich besser merken kann. Damit sind sie aber auch leichter zu erraten als beispielsweise zufällig erzeugte kryptografische Schlüssel.

WörterbuchangriffBrute-Force-Angriff

Es gibt verschiedene Angriffsmethoden, um an persönliche Passwörter zu gelangen: Ein Angriff kann beispielsweise ausgehend von einem Wörterbuch alle Wörter einer Sprache durchprobieren. Dieser sogenannte Wörterbuchangriff (Dictionary Attack) lässt sich mit modernen Rechnern sehr schnell durchführen und findet zumindest die sehr einfach gewählten Passwörter. Wörter einer existierenden Sprache sind als Passwörter also ungeeignet. Es empfiehlt sich daher, komplexere Kombinationen aus Zeichen, Ziffern und Sonderzeichen für Passwörter zu verwenden. Ein Wörterbuchangriff ist auf solche Passwörter nicht mehr möglich, Angreifer:innen müssen nun vielmehr sämtliche Kombinationen von Zeichen durchprobieren. Man spricht dann von einem sogenannten Brute-Force-Angriff. Authentisierungsverfahren, die auf Passwörtern beruhen, sind immer anfällig für Brute-Force-Angriffe. Diese Art des Angriffs ist jedoch sehr zeitaufwendig, wenn Länge und Komplexität der Passwörter groß genug sind.

Langlebigkeit

Passwörter sind darüber hinaus sehr langlebige Authentisierungsmerkmale: Gibt eine Person unbewusst ihr Passwort preis, können alle, die das Passwort kennen, deren Identität für lange Zeit unbefugt annehmen.

Gegenmaßnahmen

Durch Richtlinien für hohe Passwortkomplexität in Kombination mit Richtlinien, die regelmäßige Passwortänderungen vorschreiben (Password Ageing) und auch die Wiederverwendung alter Passwörter verhindern (Password History), lässt sich das Risiko eines erfolgreichen Angriffs auf Passwörter verringern. Allerdings lassen sich die Richtlinien nicht beliebig verschärfen: Überfordern sie die beteiligten Personen, führt das in der Praxis zu ungewollten Ausweichreaktionen und nur scheinbar komplexen Passwörtern.

Trotz der Nachteile von Passwörtern ist deren ausschließliche Verwendung für die Authentisierung von Anwendern auch in heutigen IT-Umgebungen noch sehr gebräuchlich. Auch Kerberos macht hier zunächst keine Ausnahme. Im weiteren Verlauf dieses Buches (Abschnitte 9.5.1, 14.4.4 und 15.4.5) werden Sie sehen, wie man Richtlinien für die Passwortqualität in Kerberos-Umgebungen umsetzen kann. Darüber hinaus tragen Smartcards und OTP-Tokens weiter zur Sicherheit in Kerberos-Umgebungen bei. In Abschnitt 18.3.3 wird auf den Einsatz von Smartcards in Kerberos-Umgebungen eingegangen. Mehr zu Einmalpasswörtern in Verbindung mit Kerberos erfahren Sie in Abschnitt 6.16.

Nach diesen Überlegungen zu Authentisierungsmerkmalen im Allgemeinen und Passwörtern im Speziellen befasst sich der folgende Abschnitt wieder mit den konkreten Authentisierungsvorgängen in Rechnernetzen.

2.1.3Lokale Anmeldung vs. Netzwerkauthentisierung

Dienste

Das Anmeldeprogramm, das Sie in Abbildung 2.1 gesehen haben, ist ein Beispiel für ein Programm, das Nutzer:innen die interaktive Verwendung eines Rechners (Hosts) ermöglicht. Daneben gibt es weitere Programme, die nur spezielle Dienste zur Verfügung stellen. Beispiele solcher Dienste sind E-Mail-Dienste, Webdienste sowie Druck- und Dateidienste. Tabelle 2.1 enthält einige Beispiele für Netzwerkdienste und zugehörige Protokolle. Auch diese Dienste verlangen im Allgemeinen, dass sich die zugreifenden Personen authentisieren.

Tab. 2.1 Dienste und Netzwerkprotokolle

Netzwerkdienst

Netzwerkprotokoll

Webserver

HTTP/HTTPS

E-Mail-Dienst

SMTP, POP3, IMAP

Dateidienst

SMB, NFS, AFS, …

Druckdienst

IPP

Verzeichnisdienst

LDAP

Host (interaktive Nutzung)

SSH, (früher auch: RSH, Telnet)

Protokolle

Die Anmeldung an einem Computer geschieht in der Regel lokal, d. h., das Anmeldeprogramm, das den Namen und das Passwort einer Person entgegennimmt, läuft auf dem lokalen Computer. Dagegen sind die beschriebenen Dienste typischerweise Prozesse auf entfernten Rechnern, und der Zugriff erfolgt über spezielle Netzwerkprotokolle. In diesem Sinne kann man die lokale Authentisierung von der Netzwerkauthentisierung unterscheiden. In Abbildung 2.2 sind beide Vorgänge dargestellt.

Client-Server

Server/ServiceClient

Man bezeichnet den Computer, auf dem ein Dienst läuft, als Server, der Dienst selbst wird auch Service genannt. Anwender greifen auf Dienste mit einem Programm zu, das als Client bezeichnet wird. Ein Beispiel eines Clientprogramms, das den Zugriff auf Webdienste ermöglicht, ist der Webbrowser. Der Client und der Dienst müssen dabei das gleiche Netzwerkprotokoll verwenden. Im Beispiel des Webdienstes greift der Webbrowser auf den Webserver über das HTTP-Protokoll zu.

Abb. 2.2Eine Person meldet sich wie in Abbildung 2.1 lokal an ihrem Arbeitsplatz an und greift dann auf verschiedene Dienste im Netzwerk zu. Auch diesen gegenüber muss sie sich authentisieren.

Lokale vs. entfernte Anmeldung

Client und Server auf derselben MaschineHostdienst

Die oben getroffene Einteilung in lokale und entfernte Programme für Anmeldung und Dienste ist so zwar üblich, aber keineswegs zwingend. Zum einen ist es natürlich durchaus möglich, Dienste auf dem lokalen Rechner zu betreiben und über Netzwerkprotokolle auf diese zuzugreifen, d. h., der Client und der Dienst können ohne Weiteres auf derselben Maschine laufen. Zum anderen gibt es aber auch Netzwerkdienste, die analog zum Anmeldeprogramm die interaktive Verwendung von entfernten Computern ermöglichen. Speziell unter Unix sind solche Dienste für eine entfernte Anmeldung üblich. Beispiele sind die ursprünglichen Werkzeuge Telnet, Remote Shell (rsh, rlogin) oder die heute überwiegend verwendete Secure Shell (ssh). Das Kapitel 22 wird sich im Detail mit der Einrichtung solcher Dienste in Kerberos-Umgebungen beschäftigen. Im Kerberos-Umfeld werden solche Dienste, die die interaktive Verwendung des ganzen Rechners erlauben, unter dem Namen Hostdienst zusammengefasst.

2.2Authentisierung mit Kerberos

An dem Prozess der Netzwerkauthentisierung bzw. -authentifizierung sind mindestens zwei Teilnehmer beteiligt: ein Client, der sich authentisieren muss, und ein Dienst, der den Client authentifizieren möchte (Abbildung 2.3). Diese beiden Teilnehmer müssen nicht immer eine Person und ein Computerprogramm sein, es kann sich auch um zwei Personen oder zwei Programme handeln.

Abb. 2.3Authentisierung zwischen Client und Dienst

2.2.1Key Distribution Center

Trusted Third Party

Speziell für die Kerberos-Authentisierung kommt noch ein dritter Teilnehmer dazu, der Kerberos-Dienst. Dieser wird als Key Distribution Center (KDC) bezeichnet. Seine konkrete Funktionsweise ist Thema von Kapitel 5. Dort werden Sie sehen, dass das KDC die Authentisierung zwischen Clients und Diensten im Netzwerk vermittelt. Dazu müssen alle Clients und alle Dienste ein Vertrauensverhältnis (Trust) zu ihrem KDC haben. Aus diesem Grund wird der Kerberos-Dienst auch als Trusted Third Party bezeichnet. Abbildung 2.4 stellt die Kerberos-Authentisierung des Anwenders maxm beim Zugriff auf einen Netzwerkservice dar.

Abb. 2.4Authentisierung zwischen Client und Dienst mit Kerberos

2.2.2Realm

Realm

Aus administrativen und organisatorischen Gründen teilt man Kerberos-Umgebungen in sogenannte Realms ein. Kerberos Realms entsprechen typischerweise Organisationen oder Teilen von Organisationen. Jeder User oder Client und jeder Dienst oder Host gehört zu einem Kerberos Realm. Innerhalb dieses Realm gibt es ein KDC, das für die Authentisierungsvorgänge zwischen den Clients und Diensten zuständig ist. Die Kerberos-Authentisierung ist dabei nicht auf einzelne Realms beschränkt: Abschnitt 6.7 befasst sich intensiv mit Authentisierungsvorgängen zwischen verschiedenen Realms (Cross-Realm-Authentisierung).

Jeder Kerberos Realm besitzt einen Realm-Namen. Dieser entspricht per Konvention2 dem DNS-Namen der Umgebung in Großbuchstaben. Im Gegensatz zu DNS-Namen spielt die Groß- und Kleinschreibung für Realm-Namen eine Rolle. Ansonsten gelten die gleichen Einschränkungen wie für DNS-Namen, beispielsweise sind :-Zeichen oder /-Zeichen nicht als Bestandteil von Realm-Namen erlaubt.

Eine der Beispielumgebungen dieses Buches hat den DNS-Namen example.com und den Realm-Namen EXAMPLE.COM.

2.2.3Principals

Clients und Dienste innerhalb eines Kerberos Realm werden durch sogenannte Kerberos Principals repräsentiert. Kerberos Principals sind also die Namen, die Kerberos für die Darstellung von Client- oder Dienstidentitäten verwendet.

An einem allgemeinen Authentisierungsaustausch in einem Kerberos Realm sind folgende Teilnehmer beteiligt:

der Client, dargestellt durch den

Client-Principal

. Typischerweise ist das der Username und dessen Kerberos Realm, getrennt durch ein

@

-Zeichen. Der Client-Principal des Beispielanwenders Max Mustermann könnte beispielsweise

[email protected]

lauten;

der Dienst, dargestellt durch den

Dienste-Principal

. Ein Webdienst auf dem Server

www.example.com

wird durch den Principal-Namen

HTTP/[email protected]

repräsentiert;

der Kerberos-Dienst (das KDC) selbst.

Am obigen Beispiel des HTTP Principal erkennt man, dass Principal-Namen aus mehreren Komponenten bestehen können. Diese werden durch ein /-Zeichen voneinander getrennt. Bei Dienste-Principals besteht die Konvention, deren langen DNS-Hostnamen (Fully Qualified Domain Name, FQDN) als zweite Komponente zu verwenden. Listing 2.1 stellt die allgemeine Syntax für Principal-Namen dar.

Listing 2.1Principal-Syntax

Komponente-1[/Komponente-2/.../Komponente-N]@REALM

Primary Instance

Die Komponenten 2 bis N sind optional. In Kerberos v4 gab es nur zwei Komponenten, die als Primary und Instance bezeichnet wurden. Diese Bezeichnungen sind auch heute noch für die erste und die zweite Komponente eines Kerberos-v5-Principal-Namens gebräuchlich.

Daneben gibt es andere Typen von Principals, wie den in Active-Directory-Umgebungen teilweise anzutreffenden Enterprise Principal, der in [29] beschrieben wird.

2.2.4Tickets

Die Kerberos-Authentisierung basiert auf den sogenannten Kerberos Tickets. Sie treten an die Stelle der sonst üblichen Passwörter, denen gegenüber sie einen entscheidenden Vorteil haben: Tickets sind kurzlebige Authentisierungsmerkmale, sie verlieren ihre Gültigkeit nach einer definierbaren Zeitdauer (üblich sind 8–10 Stunden).

Abb. 2.5Authentisierung mit Kerberos Tickets

Netzwerkclients bekommen Tickets auf Anfrage vom KDC ausgestellt. Greift ein Client dann auf einen Dienst zu, so legt er ihm ein Ticket vor, das das KDC speziell für diesen Dienst ausgestellt hat und das den Principal-Namen des Clients enthält. Der Dienst erkennt daran die Authentizität des Clients. Abbildung 2.5 stellt diesen Vorgang schematisch dar, die Details dazu folgen in Kapitel 5.

2.2.5Gegenseitige Authentisierung

Oftmals genügt es nicht, dass sich der Client dem Dienst gegenüber authentisiert. Vielmehr sollte sich auch der Client überzeugen können von der Identität des Dienstes, auf den er zugreifen möchte. So sollten Anwender:innen beispielsweise sicherstellen können, dass der Netzwerkdienst, von dem sie ihre E-Mails beziehen, authentisch ist. Sonst könnte es passieren, dass sie gefälschte E-Mails bekommen. Dasselbe gilt für das Ablegen von sensiblen Daten auf einem Dateidienst. Auch hier möchte man sicherstellen, dass man diese auf dem richtigen Server und nicht auf dem Laptop eines Industriespions ablegt.

Mutual Authentication

Kerberos bietet hierfür die Möglichkeit der gegenseitigen Authentisierung (Mutual Authentication), bei der auch der Client eine Authentisierung des Dienstes verlangen kann.

2.2.6Lokale Anmeldung und Kerberos

PAM

Der Kerberos-Authentisierungsdienst wurde in erster Linie für die Authentisierung von Clients gegenüber Netzwerkdiensten geschaffen. Für die lokale Anmeldung existieren andere Programme, die die Authentifizierung von Anwender:innen durchführen, wie beispielsweise login oder der grafische gdm unter Linux. Solche Programme verwenden unter Linux und einigen Unix-Derivaten die Pluggable Authentication Modules (PAM), um die lokale Authentifizierung durchzuführen. Die gängigen Anmeldeprogramme lassen sich darüber zur Verwendung des Kerberos-Protokolls konfigurieren. Auch die lokale Anmeldung an Windows-Rechnern innerhalb einer Active-Directory-Domäne nutzt Kerberos für die Passwortüberprüfung.

Kapitel 21 widmet sich dieser Konfiguration im Detail. Dort werden Sie in Abschnitt 21.3 auch den Dienst sssd und ein passendes PAM-Modul kennenlernen, um die Authentisierung mit Kerberos-Mitteln durchzuführen.

2.3Delegation

Bisher ging es nur um den einfachen Client-Server-Zugriff. Häufig greifen Dienste aber selbst auf andere Netzwerkdienste zu (Abbildung 2.6).

Multi-TierFrontend-Dienst Backend-Dienst

Ein Beispiel wären interaktive SSH-Logins unter Linux, bei denen man sich ausgehend vom eigenen Rechner auf einem Remote-Rechner und von dort aus auf weiteren Remote-Rechnern3 anmeldet. Auch bei Webapplikationen sind solche Multi-Tier-Architekturen üblich. In Abbildung 2.6 ist dieser Vorgang beispielhaft dargestellt: Der Client (Max Mustermann) greift auf den ersten Dienst (Frontend) zu. Der muss seinerseits auf einen weiteren Netzwerkdienst (Backend) zugreifen, um die Anfrage des Clients zu beantworten. Das Frontend tritt gegenüber dem User in einer Service-Rolle, gegenüber dem Backend in einer Client-Rolle auf.

Abb. 2.6Eine Person greift analog zu Abbildung 2.2 über ein Clientprogramm auf das Frontend zu. Dieses greift nun stellvertretend für diese Person auf einen Backend-Dienst zu. Das geht nur, wenn dem Frontend durch eine Delegation die Benutzung der Clientidentität gestattet ist.

Soll die Authentisierung des Client-Service-Zugriffs zwischen Frontend und Backend nun ebenfalls über Kerberos erfolgen, so gibt es grundsätzlich zwei Möglichkeiten:

Das Frontend kann unter seiner eigenen Identität auf das Backend zugreifen. In der Beispiel-Kerberos-Umgebung aus

Abbildung 2.6

würde das bedeuten, dass der Backend-Dienst einen Zugriff des Principals

HTTP/[email protected]

registriert.

Dem Frontend kann die Benutzung der Clientidentität der zugreifenden Person gestattet werden. Dieser Vorgang wird als

Delegation

bezeichnet. Im Beispiel bedeutet das, dass das Frontend sich dem Backend gegenüber als die zugreifende Person ausgeben kann. Der Backend-Dienst registriert dann einen Zugriff des Principals

[email protected]

. Er regelt den Zugriff dann gemäß dessen Berechtigungen.

Ticket Proxying Ticket Forwarding Constrained Delegation

Kerberos unterstützt Delegation durch die Übermittlung von Tickets an das Frontend. Dabei unterscheidet man mehrere Varianten: Ticket Proxying und Ticket Forwarding. Microsoft bringt mit der Constrained Delegation eine weitere Variante ins Spiel. Abschnitt 6.6 befasst sich mit den Details dieser Mechanismen.

2.4Autorisierung und Zugriffskontrolle

Autorisierung: »Was darf ich?«

Neben der Authentisierung sind auch die Begriffe Autorisierung und Zugriffskontrolle (Access Control) wesentlich für jedes Sicherheitskonzept.

Zugriffskontrolle

Beim Vorgang der Autorisierung wird festgelegt, mit welchen Berechtigungen User auf Ressourcen im Netzwerk zugreifen dürfen. Netzwerkdienste, die diese Ressourcen anbieten, führen im Allgemeinen eine Zugriffskontrolle (Access Control) durch. Dabei prüfen sie anhand von Zugriffsregeln, ob und wie die zugreifende Person bzw. der zugreifende Client autorisiert ist. Dementsprechend wird der Zugriff auf die Ressource erlaubt, verweigert oder nur eingeschränkt gewährt.

Damit das funktioniert, muss ein Dienst wissen, welchen Personen er auf welche Objekte welche Art von Zugriffen erlauben kann. Die dafür benötigten Regeln und wo diese hinterlegt sind, hängt von dem konkret betrachteten Dienst ab. Einige Beispiele:

Dateidienste stellen Dateisysteme zur Verfügung. Die Dateien und Verzeichnisse darin sind mit sogenannten

Access Control Lists (ACLs)

versehen. Daran kann ein Dateidienst entscheiden, ob ein bestimmter User auf eine Datei oder ein Verzeichnis zugreifen darf und in welcher Form dieser Zugriff gegebenenfalls erfolgen kann (z. B. nur lesend, lesend und schreibend oder auch ausführend).

Webanwendungen haben ebenfalls Zugriffsentscheidungen zu treffen. Beispielsweise lässt sich beim Apache-Webserver der Zugriff auf einzelne Verzeichnisse durch

.htaccess

-Dateien einschränken.

Gerade bei Verzeichnisdiensten können die Zugriffsrechte sehr feingranular vergeben werden. Die

Kapitel 7

und

13

enthalten Beispiele für die Konfiguration der Zugriffsrechte beim OpenLDAP-Server

slapd

.

2.4.1Authentisierung ist Voraussetzung

Damit ein Dienst seine Zugriffskontrolle auf einer sicheren Basis durchführen kann, muss er sich vorher von der Identität der zugreifenden Person überzeugt haben. Die Authentifizierung der Person ist also eine Vorbedingung für die sichere Zugriffskontrolle4.

NFS

Leider existieren auch Dienste, die diese Regel nicht beachten. Der Dateidienst NFS (Network File System) (ohne zusätzliche Kerberos-Security) ist ein Beispiel dafür: NFS nimmt klassischerweise keinerlei Authentifizierung der zugreifenden Person vor, sondern verlässt sich darauf, dass dessen Clientsystem die Authentifizierung bereits vorgenommen hat. Clientsystemen, die von Angreifer:innen modifiziert wurden, wird dabei genauso getraut. In Abschnitt 23.2 werden Sie sehen, wie man diese Unzulänglichkeit durch Verwendung von Kerberos eliminieren kann.

2.4.2Identity Mappings

Ein weiterer wesentlicher Punkt ist nun, dass verschiedene Dienste unterschiedliche Darstellungsformen für die Identitäten ihrer User benutzen. Damit ein Dienst eine Zugriffsentscheidung treffen kann, müssen die notwendigen Autorisierungsdaten in der passenden Darstellungsform vorliegen. Beispiele solcher Autorisierungsdaten sind:

SID, UID, GIDE-Mail-AdresseDN

Kerberos verwendet

Principal-Namen

(siehe

Abschnitt 2.2.3

) als Darstellungsform für die Identität von Clients und Diensten. Die Person Max Mustermann hat in den Beispielumgebungen dieses Buches etwa den Principal

[email protected]

.

SID, UID, GID

Dateidienste verwenden in den ACLs

numerische Identifikatoren:

Unter Windows ist das der sogenannte

Security Identifier (SID)

, unter Unix die

User-ID (UID)

. In der Regel werden User auch zu Gruppen zusammengefasst, die wiederum mit numerischen Identifikationsnummern bezeichnet werden. Unter Windows wird auch für solche Gruppen eine

SID

verwendet, unter Unix eine

Group-ID (GID)

. Es sind daher Datenquellen für Autorisierungsdaten erforderlich, die beispielsweise erlauben, einen Kerberos Principal wie

[email protected]

auf solche numerischen IDs oder Gruppenzugehörigkeiten abzubilden.

E-Mail-Adresse

Ein E-Mail-Dienst könnte beispielsweise die

E-Mail-Adresse

des Users verwenden.

DN

Der Verzeichnisdienst LDAP benutzt sogenannte

Distinguished Names (DNs)

.

Tabelle 2.2 listet einige Beispiele solcher Darstellungsformen der Identität des Beispielbenutzers maxm für verschiedene Dienste auf.

Tab. 2.2Dienstspezifische Darstellungsformen der Identität von Max Mustermann

Dienst

Darstellungsform

Dateidienst

10123

E-Mail

[email protected]

LDAP

uid=maxm,ou=people,dc=example,dc=com

Kerberos

[email protected]

2.4.3Autorisierung und Kerberos

Zusätzliche Datenquellen

Das klassische Kerberos führt ausschließlich die Authentisierung seiner Principals durch. Die für die Zugriffskontrolle benötigten Autorisierungsdaten muss ein kerberisierter Dienst aus einer zusätzlichen Datenquelle beziehen, und er muss in der Lage sein, die Namen der Kerberos Principals auf seine eigene Darstellungsform abzubilden.

/etc/passwd /etc/groupNISLDAP

Beispielsweise könnte man unter Unix die Daten über User, Gruppen und deren numerische IDs den lokalen Dateien /etc/passwd und /etc/group entnehmen. Die Pflege dieser Dateien in einer verteilten Umgebung wird aber schnell sehr aufwendig, weswegen man für diese Aufgabe spezielle Namensdienste verwendet. Im Athena-Netzwerk wurde hierzu der in Abschnitt 1.1 erwähnte Hesiod-Namensdienst eingesetzt. SUNs Network Information Service (NIS) (früher: Yellow Pages) erfüllte ebenfalls diese Aufgabe. Verzeichnisdienste bieten sich ebenfalls als Namensdienst an, weswegen auch der Einsatz von LDAP als Datenbasis für solche Autorisierungsdaten sehr verbreitet ist. Dieses Buch geht in diesem Zusammenhang nur auf LDAP ein.

Abbildung 2.7 stellt die strenge Trennung von Authentisierung (durch Kerberos) und zentraler Bereitstellung von Autorisierungsdaten (durch einen Verzeichnisdienst wie LDAP) dar. Hierbei sind hauptsächlich Client und KDC mit den Angelegenheiten der Authentisierung (blau dargestellt) beschäftigt, während sich der Dienst um alle Belange der (grün dargestellten) Autorisierung kümmern muss. Diese Trennung ist grundsätzlich auch vom Standpunkt eines sicheren Systemdesigns zu befürworten. Denn gerade wenn es um sicherheitsrelevante Software geht, ist es wesentlich, den Funktionsumfang einzelner Softwarekomponenten zu beschränken und gegeneinander abzugrenzen. Das wird durch diese Trennung erreicht.

Abb. 2.7Authentisierung und Authentisierung mit Kerberos und LDAP

Andererseits werden die Grenzen zwischen Authentisierung und Autorisierung in existierenden Systemen oft aufgeweicht. Beispielsweise stellt die Unix-Datei /etc/passwd einen solchen Mischmasch aus Authentisierungs- und Autorisierungsdaten dar: Sie kann Authentisierungsinformationen in Form von verschlüsselten Passwörtern enthalten (sogenannte Crypt-Strings)5, aber auch Autorisierungsdaten wie User-IDs und Gruppenzugehörigkeit.

PAC

Es soll nicht verschwiegen werden, dass Kerberos v5 auch Autorisierungsdaten vorsieht. Davon wird gerade im Microsoft-Umfeld Gebrauch gemacht. Zu den Microsoft-Erweiterungen des Kerberos-Protokolls gehört das sogenannte Privilege Attribute Certificate (PAC). Dieses wird in Abschnitt 6.10 behandelt.

2.5Single Sign-on (SSO)

Oftmals geht die Erhöhung der Sicherheit in einer IT-Umgebung mit Einschränkungen im Komfort und in der Usability einher. Im Folgenden werden Sie sehen, dass bei Kerberos das Gegenteil der Fall ist.

In vielen Umgebungen ist es üblich, dass einzelne Dienste eigene Passwortdatenbanken verwalten müssen. Beispiele hierfür wären ein Apache-Webserver, der über .htpasswd-Dateien konfiguriert wird, oder ein Samba-Server mit Accounts in einer lokalen smbpasswd-Datei. In solchen Umgebungen kann es sein, dass man sich unterschiedliche Passwörter für unterschiedliche Dienste merken muss. Außerdem führen solche Dienste zu einer umständlichen Benutzerverwaltung, die nicht mehr zentral durchgeführt werden kann.

Passwortsynchronisation

Ein erster Schritt zur Verbesserung ist die Einführung einer Synchronisation dieser einzelnen Passwortverwaltungen. Der Samba-Server kann z. B. dafür sorgen, dass Passwortänderungen auch gleich auf die Unix-Benutzerdatenbank übertragen werden. Auch beim Apache lassen sich die genannten .htpasswd-Dateien im Prinzip zu anderen Passwortquellen synchronisieren. Solche Synchronisationen können allerdings auch fehlschlagen. Dann stehen die User vor dem Problem, dass sie nicht mehr wissen, welches Passwort sie für welchen Dienst benutzen müssen.

Nur eine zentrale Passwortdatenbank

Ein weiterer Schritt zur Verbesserung wäre also, nur eine Quelle für Passwortinformationen zu haben, die dann von allen Diensten benutzt wird. Der Network Information Service (NIS) ist ein Beispiel für eine derartige Quelle, die heutzutage allerdings mangels jeglicher kryptografischer Funktionalität als völlig unsicher einzustufen ist. Auch LDAP lässt sich so verwenden. Jedoch müssen auch alle Dienste diese eine Quelle unterstützen. Zum Beispiel benötigt ein Samba-Server, der noch NTLM-Authentifizierung betreibt, andere Passwortinformationen als der Unix-Login, sodass man hier nicht um die beschriebene Synchronisation herumkommt.

Auch wenn alle Dienste im Netz mit einer Passwortquelle auskommen, muss man Passwörter immer wieder aufs Neue eintippen, wenn man auf den einen oder anderen Netzwerkdienst zugreifen möchte. Das führt dann fast zwangsläufig zur Wahl von zu simplen Passwörtern.

Single Sign-on

Unter Single Sign-on (SSO) versteht man nun den dritten Schritt: Passwörter müssen nur noch einmal pro Sitzung eingegeben werden. Das geschieht in der Regel bei der Anmeldung am System und wird auch als Primärauthentisierung bezeichnet. Nach dieser erfolgreichen Erstanmeldung gilt man bis zum Ablauf der Sitzung für alle Dienste im Netzwerk als authentisiert. Die Anmeldung findet also nicht mehr an einer lokalen Maschine oder an einem speziellen Dienst, sondern vielmehr netzwerkweit statt.

Zusammenfassend kann man Authentisierungsverfahren wie folgt kategorisieren:

Keine Zentralisierung der Authentisierung: User müssen sich für verschiedene Dienste unterschiedliche Passwörter merken.

»One user, one password«: User können auf alle Dienste mit ihrem persönlichen Passwort zugreifen, die zugehörigen Passwortdatenbanken werden synchron gehalten.

Zentrale Datenquelle für Passwortinformationen. Wie im vorigen Fall kann man auf alle Dienste mit seinem persönlichen Passwort zugreifen, es ist aber keine Synchronisation mehr nötig.

»Single Sign-on« (SSO): User müssen ihr Passwort nur noch einmal eingeben.

Sicheres, zeitlich begrenztes Single Sign-on

Kerberos bietet nun gerade auch die Möglichkeit des sicheren Single Sign-on, das auf den in Abschnitt 2.2.4 beschriebenen Kerberos Tickets beruht. Ein wesentlicher Sicherheitsaspekt betrifft dabei die Frage, wo Passwörter verarbeitet werden, welche IT-Systeme also überhaupt mit User-Passwörtern »in Berührung« kommen. Bei den ersten drei Kategorien verarbeiten alle Netzwerkdienste Passwörter direkt. Das ist schlecht, denn so kann jeder kompromittierte Netzwerkdienst potenziell Passwortinformationen preisgeben. In der letzten Kategorie erhalten Netzwerkdienste keine Passwörter, sondern SSO-Tokens – konkret bei Kerberos: Tickets – die lediglich die Identität des zugreifenden Clients bestätigen und sonst keinen weiteren Nutzen bieten. Diese Tickets haben in der Regel eine kurze Gültigkeit. Daraus ergibt sich auch, dass SSO-Sitzungen mit Kerberos zeitlich begrenzt sind.

Möchte man Passwörter durch sicherere Verfahren ersetzen (siehe Abschnitt 2.1.2), so kann dies in Kerberos-Umgebungen an zentraler Stelle erfolgen. Ist man noch auf Passwörter angewiesen, so sollte man zumindest Richtlinien für die Passwortqualität einstellen, um uneinsichtige Anwender:innen zur Verwendung komplexerer Passwörter zu bewegen. Kerberos liefert hierbei argumentative Schützenhilfe: Denn muss man sich nur noch ein Passwort merken und dieses idealerweise auch nur einmal am Tag eintippen, so muss man nicht mehr auf einfache, schnell zu tippende Passwörter zurückgreifen, sondern kann sich komplexere Passwörter ausdenken.

Hoher Komfort, starke Sicherheit

Zum einen bringt Kerberos Single Sign-on also den größtmöglichen Komfort für die Anwender:innen, andererseits führen gerade die im letzten Abschnitt genannten Punkte zu einer wesentlichen Erhöhung der Sicherheit.

2.6Zusammenfassung

Kerberos ist also ein Ticket-basierter, Trusted-Third-Party-Authentisierungsdienst mit Single-Sign-on-Funktionalität. Die Trusted Third Party wird auch als Key Distribution Center oder KDC bezeichnet. Dieses KDC ist für Authentisierungsvorgänge zwischen Client- und Dienste-Principals innerhalb seines Realm verantwortlich. Neben der reinen Authentisierung