Kerberos: Single Sign-on in gemischten Linux/Windows-Umgebungen

Von Mark Pröhl und Daniel Kobras

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.

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 14. Apr. 2022
• ISBN: 9783960888529

Buchvorschau

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.¹

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

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änkungen

Bones

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

NTLM

Active 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 Authentifizierung¹. 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.1 Eine 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 Function

string2key

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.

Smartcards

Kerberos 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örterbuchangriff

Brute-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

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/Service

Client

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.2 Eine 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 Maschine

Hostdienst

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.3 Authentisierung 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.4 Authentisierung 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 Konvention² 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 [e-mail] lauten;

der Dienst, dargestellt durch den Dienste-Principal. Ein Webdienst auf dem Server www.example.com wird durch den Principal-Namen HTTP/[e-mail] 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.1 Principal-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.5 Authentisierung 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-Tier

Frontend-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-Rechnern³ 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.6 Eine 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.6würde das bedeuten, dass der Backend-Dienst einen Zugriff des Principals HTTP/[e-mail] 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 [e-mail]. 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 Zugriffskontrolle⁴.

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, GID

E-Mail-Adresse

DN

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 [e-mail].

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 [e-mail] 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.2 Dienstspezifische Darstellungsformen der Identität von Max Mustermann

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/group

NIS

LDAP

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.7 Authentisierung 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)⁵, 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 unterstützt Kerberos auch die Delegation im Sinne der Weiterleitung einer Clientidentität.

Autorisierung gehört nicht zu den Aufgaben des klassischen Kerberos-Dienstes, obwohl einzelne Kerberos-Implementierungen Autorisierungsdaten in ihre Kerberos Tickets einfügen.

Genug der Theorie. Das nächste Kapitel widmet sich der Kerberos-Praxis aus Sicht der Anwender.

3Kerberos aus Anwendersicht

Nachdem Sie in den Kapiteln 1 und 2 einen Überblick über die Netzwerkauthentisierung mit Kerberos erhalten haben, werden Sie hier nun die Kerberos-Praxis aus der Sicht eines Beispielnutzers kennenlernen.

Alle Clients und Dienste in den Beispielen unterstützen Kerberos bereits, sie sind kerberisiert. Wie Sie eine solche kerberisierte Umgebung selbst einrichten können, erfahren Sie ab Teil II dieses Buches. Das vorliegende Kapitel soll Ihnen zunächst einen Einblick in die Anwenderseite von Kerberos verschaffen.

3.1Die Beispielumgebung

Der Anwender der Beispielumgebung heißt Max Mustermann und arbeitet an einer Linux-Workstation (Distribution: CentOS 8) mit dem Namen lx01. Der Name des Kerberos Realm ist EXAMPLE.COM und entspricht dem Namen der DNS-Domäne (example.com). Der Kerberos-Dienst der Beispielumgebung läuft auf einem Server mit dem Namen kdc01 (ebenfalls eine CentOS-Maschine).

Neben seiner lokalen Workstation lx01 meldet sich Herr Mustermann hin und wieder auch per Secure Shell auf einer weiteren Maschine mit dem Namen lx02 an. Außer diesem Secure-Shell-Dienst gibt es noch einen LDAP-Verzeichnisdienst (OpenLDAP) und einen Webserver (Apache). Der Webserver läuft auf der lx02, der Verzeichnisdienst auf der kdc01. Im DNS ist ein Alias für lx02.example.com eingerichtet, sodass Herr Mustermann den Webserver unter der URL http://www.example.com ansprechen kann. Abbildung 3.1 zeigt diese Beispielumgebung.

Abb. 3.1 Die Beispielumgebung

3.2Lokale Anmeldung

Der Anwender Max Mustermann meldet sich lokal am Linux-Arbeitsplatz lx01 an. Wie in Abschnitt 2.1 beschrieben, muss er sich dazu gegenüber der lx01 authentisieren, indem er dem Login-Programm seinen Nutzernamen (maxm) und sein Passwort (»P@ssw0rd«) übergibt. Das Listing 3.1 zeigt die lokale Anmeldung an der nichtgrafischen Linux-Konsole, die Abbildung 3.2 das grafische Äquivalent.

Listing 3.1 Lokale Anmeldung an der Linux-Konsole

CentOS Linux 8 (Core)

Kernel 4.18.0-193.14.2.el8_2.x86_64 on an x86_64

lx01 login: maxm

Password: P@ssw0rd

maxm@lx01:~$

Abb. 3.2 Lokale Anmeldung mit dem grafischen Login-Programm GNOME Display Manager (GDM)

Die Passwortüberprüfung an der lx01 funktioniert bereits über Kerberos. Man sagt auch: Das Anmeldeprogramm ist kerberisiert. Max Mustermann hat dabei bereits einmal sein Passwort angegeben; im Sinne des in Abschnitt 2.5 beschriebenen Single Sign-on (SSO) sollte er damit netzwerkweit angemeldet sein. Beim Zugriff auf die Beispieldienste wird sich Herr Mustermann durch Kerberos Tickets authentisieren. Sollte er nochmals nach einem Passwort gefragt werden, dann würde das bedeuten, dass eine Fehlkonfiguration vorliegt.

3.3Der Credential Cache

Das kerberisierte Login-Programm legt die Kerberos Tickets, die es im Rahmen der Passwortüberprüfung erhalten hat, in einem sogenannten Credential Cache ab. Auch maxm hat bei seiner Anmeldung einen Credential Cache erhalten.

Das Kerberos-Kommando klist dient zur Anzeige des Inhalts von Credential Caches. In Listing 3.2 ist ein Aufruf von klist dargestellt, den maxm direkt nach der Anmeldung an der lx01 eingegeben hat. Dieser Aufruf des klist-Kommandos erfolgt dabei ohne weitere Kommandozeilenoptionen.

Listing 3.2 Ausgabe des Kommandos klist

maxm@lx01:~$ klist

Ticket cache: FILE:/tmp/krb5cc_10000_zGOviZ

Default principal: [e-mail]

Valid starting      Expires              Service principal

06/22/2021 17:32:59 06/23/2021 03:32:59  krbtgt/EXAMPLE.   

  [e-mail]

renew until 06/23/2021 17:32:57

maxm@lx01:~$

Ticket-Granting Ticket

Wie Sie in Listing 3.2 sehen können, liegt der Kerberos-v5-Cache in der Datei /tmp/krb5cc_10000_zGOviZ. 10000 ist dabei die numerische Benutzer-ID von maxm, zGOviZ ist ein zufällig gewählter Anhang an den Dateinamen. Eine weitere Information in der klist-Ausgabe ist die Angabe des Default principal. Der gibt Herrn Mustermanns Kerberos-Identität an, also seinen Principal-Namen [e-mail]. Weiter unten werden dann die Kerberos Tickets gelistet. Zum jetzigen Zeitpunkt (direkt nach der lokalen Anmeldung) liegt nur eines für den Service krbtgt/[e-mail] vor. Dies ist das sogenannte Ticket-Granting Ticket (TGT).

In den Ausgaben von klist in Listing 3.2 sind noch weitere Angaben zu diesem Ticket zu sehen: In der Spalte Valid starting steht der Zeitpunkt, ab wann das Ticket gültig ist, in Expires, wann es abläuft. Der Angabe nach renew until kann man entnehmen, wie lange es erneuerbar ist (Abschnitt 6.4 behandelt Ticket-Erneuerung im Detail).

In Listing 3.3 sehen Sie die Auswirkung der zusätzlichen Option -f. Damit zeigt klist zusätzlich auch die gesetzten Ticket Flags an. Im vorliegenden Beispiel sind das die Flags FRIA; sie bedeuten im Einzelnen: Forwardable, Renewable, Initial und Pre-Authenticated. Was es mit diesen Flags genau auf sich hat, werden Sie in Abschnitt 6.2 sehen.

Listing 3.3 Mit der Kommandozeilenoptionen -f zeigt klist zusätzliche Ticket Flags an.

maxm@lx01:~$ klist -f

Ticket cache: FILE:/tmp/krb5cc_10000_zGOviZ

Default principal: [e-mail]

Valid starting      Expires            Service principal

06/22/2021 17:32:59 06/23/2021 03:32:59 krbtgt/EXAMPLE.   

  [e-mail]

renew until 06/23/2021 17:32:57, Flags: FRIA

3.4Anmeldung an Netzwerkdiensten

Herr Mustermann hat also bereits alles Nötige, um auf kerberisierte Netzwerkdienste zugreifen zu können. Beispielsweise kann er eine Suchanfrage an den LDAP-Verzeichnisdienst auf dem Server kdc01 stellen. Dieser Zugriff und die resultierende Änderung am Credential Cache sind in Listing 3.4 dargestellt: Herr Mustermann benutzt das OpenLDAP-Kommando¹ ldapsearch, um nach einem LDAP-Eintrag mit einem uid-Attribut zu suchen, das den Wert maxm hat. Von diesem Verzeichniseintrag fragt er die Werte der beiden Attribute uidNumber und gidNumber ab. Mit der Option -h gibt er den Hostnamen des LDAP-Servers (kdc01) an. Die Optionen -QLLL haben nur den Zweck, das Suchergebnis übersichtlicher darzustellen. Die genauen Details der LDAP-Suche sind an dieser Stelle unwesentlich. Hier ist nur wichtig, dass es sich um einen Client-Server-Zugriff im Sinne von Abschnitt 2.1.3 handelt.

Service Ticket

Anschließend hat sich der Credential Cache verändert. Die Ausgabe von klist -f in Listing 3.4 zeigt, dass der Credential Cache nun ein zusätzliches Service Ticket enthält. Dieses ist für den Dienste-Principal ldap/[e-mail] ausgestellt worden.

Listing 3.4 Netzwerkzugriff am Beispiel des LDAP-Verzeichnisdienstes

maxm@lx01:~$ ldapsearch -h kdc01 -QLLL                    \

uid=maxm uidNumber gidNumber

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

uidNumber: 10000

gidNumber: 10000

maxm@lx01:~$ klist -f

Ticket cache: FILE:/tmp/krb5cc_10000_zGOviZ

Default principal: [e-mail]

Valid starting      Expires            Service principal

06/22/2021 17:32:59 06/23/2021 03:32:59 krbtgt/EXAMPLE. 

  [e-mail]

renew until 06/23/2021 17:32:57, Flags: FRIA

06/22/2021 17:34:07 06/23/2021 03:32:59 ldap/kdc01.     

  [e-mail]

renew until 06/23/2021 17:32:57, Flags: FRAT

maxm@lx01:~$

Das Listing 3.5 zeigt einen weiteren kerberisierten Netzwerkzugriff, diesmal am Beispiel der Secure Shell (SSH).

Listing 3.5 Netzwerkzugriff am Beispiel einer Secure-Shell-Anmeldung. Auf der lx02 liegen keine Kerberos Tickets vor. Der Credential Cache auf der lx01 erweitert sich durch die SSH-Sitzung um ein Host Ticket für die lx02.

maxm@lx01:~$ ssh lx02.example.com

Last login: Fri Aug 21 14:28:07 2020 from 10.1.2.111

maxm@lx02:~$ klist -f

klist: No credentials cache found (filename: /tmp/       

  krb5cc_10000)

maxm@lx02:~$ logout

Connection to lx02.example.com closed.

maxm@lx01:~$ klist -f

Ticket cache: FILE:/tmp/krb5cc_10000_zGOviZ

Default principal: [e-mail]

Valid starting      Expires            Service principal

06/22/2021 17:32:59 06/23/2021 03:32:59 krbtgt/EXAMPLE.     

  [e-mail]

renew until 06/23/2021 17:32:57, Flags: FRIA

06/22/2021 17:34:07 06/23/2021 03:32:59  ldap/kdc01.       

  [e-mail]

renew until 06/23/2021 17:32:57, Flags: FRAT

06/22/2021 17:35:53 06/23/2021 03:32:59 host/lx02.example 

  [e-mail]

renew until 06/23/2021 17:32:57, Flags: FRAT

maxm@lx01:~$