Das FreeBSD-Handbuch
Zurück | Kapitel 15. Sicherheit | Weiter

# 15.7. Kerberos5

Beigetragen von Tillman Hodgson. Beruht auf einem Beitrag von Mark Murray.

Kerberos ist ein Netzwerk-Protokoll, das Benutzer mithilfe eines sicheren Servers authentifiziert. Mit Risiken behaftete Dienste, wie das Anmelden an entfernten Systemen oder das Kopieren von Daten auf entfernte Systeme, werden durch Kerberos erheblich sicherer und lassen sich leichter steuern.

Kerberos hat eine Aufgabe: Die sichere Prüfung der Identität eines Benutzers (Authentifizierung) über das Netzwerk. Das System überprüft weder die Berechtigungen der Benutzer (Autorisierung), noch verfolgt es die durchgeführten Aktionen (Audit). Daher sollte Kerberos zusammen mit anderen Sicherheits-Systemen eingesetzt werden, die diese Funktionen bereitstellen. Die Daten einer Kommunikation können verschlüsselt werden, nachdem die Kommunikationspartner mit Kerberos ihre Identität geprüft haben.

Die folgenden Anweisungen beschreiben, wie Sie das mit FreeBSD gelieferte Kerberos einrichten. Eine vollständige Beschreibung des Systems entnehmen Sie bitte den entsprechenden Hilfeseiten.

Die Beschreibung der Kerberos-Installation benutzt folgende Namensräume:

- Die DNS-Domain (Zone) heißt example.org.

- Das Kerberos-Realm heißt EXAMPLE.ORG.

> Anmerkung: Benutzen Sie echte Domain-Namen, wenn Sie Kerberos einrichten. Damit vermeiden Sie DNS-Probleme und stellen die Zusammenarbeit mit anderen Kerberos-Realms sicher.

## 15.7.1. Geschichte

Das MIT entwickelte Kerberos, um Sicherheitsprobleme auf dem Netzwerk zu lösen. Das Kerberos-Protokoll verwendet starke Kryptographie, sodass ein Server die Identität eines Clients (der umgekehrte Vorgang ist auch möglich) über ein unsicheres Netzwerk feststellen kann.

Der Begriff Kerberos wird sowohl für das Protokoll als auch für Programme verwendet, die Kerberos benutzen (wie Kerberos-Telnet). Die aktuelle Protokollversion ist 5 und wird in RFC 1510 beschrieben.

Mehrere Implementierungen des Protokolls stehen frei zur Verfügung und decken viele Betriebssysteme ab. Das Massachusetts Institute of Technology (MIT), an dem Kerberos ursprünglich entwickelt wurde, entwickelt seine Kerberos-Version weiter. In den USA wird diese Version häufig eingesetzt, unterlag aber Export-Beschränkungen, da sie in den USA entwickelt wurde. Die MIT-Version von Kerberos befindet sich im Port `security/krb5`. Heimdal ist eine weitere Implementierung der Protokollversion 5. Sie wurde außerhalb der USA entwickelt und unterliegt daher keinen Export-Beschränkungen. Heimdal-Kerberos befindet sich im Port `security/heimdal` und das Basissystem von FreeBSD enthält eine minimale Installation von Heimdal.

Um möglichst viele Benutzer anzusprechen, verwenden die folgenden Beispiele die in FreeBSD enthaltene Heimdal-Distribution.

## 15.7.2. Das Heimdal KDC einrichten

Kerberos authentifiziert Benutzer an einer zentralen Stelle: dem Key Distribution Center (KDC). Das KDC verteilt Tickets, mit denen ein Dienst die Identität eines Benutzers feststellen kann. Alle Mitglieder eines Kerberos-Realms vertrauen dem KDC, daher gelten für das KDC erhöhte Sicherheitsanforderungen.

Obwohl das KDC wenig Ressourcen eines Rechners benötigt, sollte es wegen der Sicherheitsanforderungen auf einem separaten Rechner installiert werden.

Das KDC wird in `/etc/rc.conf` wie folgt aktiviert:

    kerberos5_server_enable="YES"
    kadmind5_server_enable="YES"

Danach wird die Konfigurationsdatei von Kerberos, `/etc/krb5.conf`, erstellt:

    [libdefaults]
        default_realm = EXAMPLE.ORG
    [realms]
        EXAMPLE.ORG = {
            kdc = kerberos.example.org
    	admin_server = kerberos.example.org
        }
    [domain_realm]
        .example.org = EXAMPLE.ORG

Diese Einstellungen setzen voraus, dass der voll qualifizierte Name des KDCs `kerberos.example.org` ist. Wenn Ihr KDC einen anderen Namen hat, müssen Sie in der DNS-Zone einen Alias-Eintrag (CNAME-Record) für das KDC hinzufügen.

> Anmerkung: Auf großen Netzwerken mit einem ordentlich konfigurierten BIND DNS-Server kann die Datei verkürzt werden:

>     [libdefaults]
>           default_realm = EXAMPLE.ORG

> Die Zonendatei von `example.org` muss dann die folgenden Zeilen enthalten:

>     _kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
>     _kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
>     _kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
>     _kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
>     _kerberos           IN  TXT     EXAMPLE.ORG

> Anmerkung: Damit Klienten die Kerberos-Dienste benutzen können, muss die Datei `/etc/krb5.conf` entweder die vollständige Konfiguration enthalten oder eine minimale Konfiguration enthalten und zusätzlich ein DNS-Server richtig eingerichtet sein.

Im nächsten Schritt wird die Kerberos-Datenbank eingerichtet. Die Datenbank enthält die Schlüssel aller Prinzipale und ist mit einem Passwort geschützt. Dieses Passwort brauchen Sie nicht zu behalten, da ein davon abgeleiteter Schlüssel in der Datei `/var/heimdal/m-key` gespeichert wird. Den Schlüssel erstellen Sie, indem Sie das Programm `kstash` aufrufen und ein Passwort eingeben.

Nachdem Sie den Schlüssel in `/var/heimdal/m-key` erstellt haben, können Sie die Datenbank mit dem Kommando `kadmin` initialisieren. Verwenden Sie hierbei die Option `-l` (lokal). Mit dieser Option wird die Datenbank lokal modifiziert. Normal würde der `kadmind`-Dienst benutzt, der aber zu diesem Zeitpunkt noch nicht läuft. An der Eingabeaufforderung von `kadmin` können Sie mit dem Kommando `init` die Datenbank des Realms einrichten.

Zuletzt erstellen Sie mit dem Kommando `add` Ihren ersten Prinzipal. Benutzen Sie die voreingestellten Optionen; Sie können die Einstellungen später mit dem Kommando `modify` ändern. An der Eingabeaufforderung zeigt das Kommando `?` Hilfetexte an.

Zusammengefasst wird die Datenbank wie folgt eingerichtet:

    # kstash
    Master key: xxxxxxxx
    Verifying password - Master key: xxxxxxxx

    # kadmin -l
    kadmin> init EXAMPLE.ORG
    Realm max ticket life [unlimited]:
    kadmin> add tillman
    Max ticket life [unlimited]:
    Max renewable life [unlimited]:
    Attributes []:
    Password: xxxxxxxx
    Verifying password - Password: xxxxxxxx

Jetzt kann das KDC gestartet werden. Führen Sie zum Start der Dienste die Kommandos `/etc/rc.d/kerberos start` und `/etc/rc.d/kadmind start` aus. Obwohl zu diesem Zeitpunkt noch keine kerberisierten Dienste laufen, können Sie die Funktion des KDCs schon überprüfen. Für den eben angelegten Benutzer können Sie sich vom KDC Tickets holen und diese Tickets anzeigen:

    % kinit tillman
    tillman@EXAMPLE.ORG's Password:

    % klist
    Credentials cache: FILE: /tmp/krb5cc_500
            Principal: tillman@EXAMPLE.ORG

      Issued           Expires          Principal
    Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG

Dieses Ticket kann, nachdem Sie Ihre Arbeit beendet haben, zurückgezogen werden:

    % kdestroy

## 15.7.3. Kerberos-Dienste einrichten

Alle Rechner, die kerberisierte Dienste anbieten, müssen eine Kopie der Kerberos-Konfigurationsdatei `/etc/krb5.conf` besitzen. Sie können die Datei einfach vom KDC kopieren.

Anschließend müssen Sie die Datei `/etc/krb5.keytab` erzeugen. Im Gegensatz zu normalen Workstations benötigt jeder Server eine `keytab`. Diese Datei enthält den Schlüssel des Servers, mit dem sich der Server und das KDC gegenseitig authentifizieren können. Die Datei muss sicher auf den Server transportiert werden (beispielsweise mit scp(1) oder einer Diskette). Unter keinen Umständen darf die Datei im Klartext, zum Beispiel mit FTP, übertragen werden, da sonst die Sicherheit des Servers gefährdet ist.

Sie können die `keytab` auch mit dem Programm `kadmin` übertragen. Da Sie mit `kadmin` sowieso einen Host-Prinzipal für den Server einrichten müssen, ist das ganz praktisch.

Sie müssen allerdings schon ein Ticket besitzen und berechtigt sein, `kadmin` auszuführen. Die Berechtigung erhalten Sie durch einen Eintrag in der Zugriffskontrollliste `kadmind.acl`. Weitere Informationen über Zugriffskontrolllisten erhalten Sie in den Heimdal-Info-Seiten (`info heimdal`) im Abschnitt “Remote administration”. Wenn der Zugriff auf `kadmin` von entfernten Maschinen verboten ist, müssen Sie sich sicher auf dem KDC anmelden (lokale Konsole, ssh(1) oder kerberisiertes Telnet) und die `keytab` lokal mit `kadmin -l` erzeugen.

Nachdem Sie die Datei `/etc/krb5.conf` installiert haben, können Sie das Kommando `kadmin` benutzen. An der Eingabeaufforderung von `kadmin` erstellt das Kommando `add --random-key` den Host-Prinzipal und das Kommando `ext` extrahiert den Schlüssel des Prinzipals in eine Datei:

    # kadmin
    kadmin> add --random-key host/myserver.example.org
    Max ticket life [unlimited]:
    Max renewable life [unlimited]:
    Attributes []:
    kadmin> ext host/myserver.example.org
    kadmin> exit

Das Kommando `ext` (von extract) speichert den extrahierten Schlüssel in der Datei `/etc/krb5.keytab`.

Wenn auf dem KDC, vielleicht aus Sicherheitsgründen, `kadmind` nicht läuft, können Sie das Kommando `kadmin` von entfernten Rechnern nicht benutzen. In diesem Fall legen Sie den Host-Prinzipal `host/myserver.EXAMPLE.ORG` direkt auf dem KDC an. Den Schlüssel extrahieren Sie in eine temporäre Datei (damit die Datei `/etc/krb5.keytab` nicht überschrieben wird):

    # kadmin
    kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org
    kadmin> exit

Anschließend müssen Sie die erzeugte `example.keytab` sicher auf den Server kopieren (mit `scp` oder mithilfe einer Diskette). Geben Sie auf jeden Fall einen anderen Namen für die `keytab` an, weil sonst die `keytab` des KDCs überschrieben würde.

Wegen der Datei `krb5.conf` kann der Server nun mit dem KDC kommunizieren und seine Identität mithilfe der Datei `krb5.keytab` nachweisen. Jetzt können wir kerberisierte Dienste aktivieren. Für `telnet` muss die folgende Zeile in `/etc/inetd.conf` eingefügt werden:

    telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user

Ausschlaggebend ist, dass die Authentifizierungs-Methode mit `-a` auf `user` gesetzt wird. Weitere Details entnehmen Sie bitte der Hilfeseite telnetd(8).

Nachdem sie die Zeile in `/etc/inetd.conf` eingefügt haben, starten Sie inetd(8) mit dem Kommando `/etc/rc.d/inetd restart` durch.

## 15.7.4. Kerberos-Clients einrichten

Ein Client lässt sich leicht einrichten. Sie benötigen nur die Kerberos-Konfigurationsdatei `/etc/krb5.conf`. Kopieren Sie die Konfigurationsdatei einfach vom KDC auf den Client.

Sie können jetzt mit `kinit` Tickets anfordern, mit `klist` Tickets anzeigen und mit `kdestroy` Tickets löschen. Sie können mit Kerberos-Anwendungen kerberisierte Server ansprechen. Wenn das nicht funktioniert, Sie aber Tickets anfordern können, hat wahrscheinlich der kerberisierte Server ein Problem und nicht der Client oder das KDC.

Wenn Sie eine Anwendung wie `telnet` testen, können Sie mit einem Paket-Sniffer (beispielsweise tcpdump(1)) überprüfen, dass Passwörter verschlüsselt übertragen werden. Probieren Sie auch die Option `-x` von `telnet`, die den gesamten Datenverkehr verschlüsselt (analog zu `ssh`).

Zu Heimdal gehören noch weitere Anwendungen. Allerdings enthält das FreeBSD-Basissystem nur eine minimale Heimdal-Installation mit nur einer kerberisierten Anwendung: `telnet`.

Der Heimdal-Port enthält noch mehr kerberisierte Anwendungen wie `ftp`, `rsh`, `rcp` und `rlogin`. Der MIT-Port enthält ebenfalls weitere kerberisierte Anwendungen.

## 15.7.5. `.k5login` und `.k5users`

Normalerweise wird ein Kerberos-Prinzipal wie `tillman@EXAMPLE.ORG` auf ein lokales Benutzerkonto, beispielsweise `tillman`, abgebildet. Daher benötigen Client-Anwendungen (zum Beispiel `telnet`) keinen Benutzernamen.

Manchmal wird aber Zugriff auf ein lokales Benutzerkonto benötigt, zu dem es keinen passenden Kerberos-Prinzipal gibt. Der Prinzipal `tillman@EXAMPLE.ORG` bräuchte beispielsweise Zugriff auf das Konto `webdevelopers`. Ebenso könnten andere Prinzipale auf dieses Konto zugreifen wollen.

Die Dateien `.k5login` und `.k5users` im Heimatverzeichnis eines Benutzerkontos gewähren Zugriffe ähnlich wie die Dateien `.hosts` und `.rhosts`. Um den Prinzipalen `tillman@example.org` und `jdoe@example.org` auf das Konto `webdevelopers` zu geben, wird im Heimatverzeichnis von `webdevelopers` die Datei `.k5login` mit folgendem Inhalt angelegt:

    tillman@example.org
    jdoe@example.org

Die angegebenen Prinzipale haben nun ohne ein gemeinsames Passwort Zugriff auf das Konto.

Einzelheiten entnehmen Sie bitte den Hilfeseiten zu diesen Dateien. Die Datei `.k5users` wird in der Hilfeseite des Kommandos `ksu` beschrieben.

## 15.7.6. Tipps und Fehlersuche

- Wenn Sie den Heimdal-Port oder den MIT-Port benutzen, muss in der Umgebungsvariable `PATH` der Pfad zu den Programmen des Ports vor dem Pfad zu den Kerberos-Programmen des Systems stehen.

- Sind die Uhrzeiten der Systeme synchronisiert? Wenn nicht, schlägt vielleicht die Authentifizierung fehl. Abschnitt 30.10 beschreibt, wie Sie mithilfe von NTP die Uhrzeiten synchronisieren.

- Die MIT- und Heimdal-Systeme arbeiten bis auf `kadmin` gut zusammen. Für `kadmin` wurde das Protokoll nicht normiert.

- Wenn Sie den Namen eines Rechners ändern, müssen Sie auch den `host/`-Prinzipal ändern und die Datei `keytab` aktualisieren. Dies betrifft auch spezielle Einträge wie den Prinzipal für Apaches `www/mod_auth_kerb`.

- Die Rechnernamen müssen vor- und rückwärts aufgelöst werden (im DNS oder in `/etc/hosts`). CNAME-Einträge im DNS funktionieren, aber die entsprechenden A- und PTR-Einträge müssen vorhanden und richtig sein. Wenn sich Namen nicht auflösen lassen, ist die Fehlermeldung nicht gerade selbstsprechend: “`Kerberos5 refuses authentication because Read req failed: Key table entry not found`”.

- Einige Betriebssysteme installieren `ksu` mit falschen Zugriffsrechten; es fehlt das Set-UID-Bit für `root`. Das mag aus Sicherheitsgründen richtig sein, doch funktioniert `ksu` dann nicht. Dies ist kein Fehler des KDCs.

- Wenn Sie für einen Prinzipal unter MIT-Kerberos Tickets mit einer längeren Gültigkeit als der vorgegebenen zehn Stunden einrichten wollen, müssen Sie zwei Sachen ändern. Benutzen Sie das `modify_principal` von `kadmin`, um die maximale Gültigkeitsdauer für den Prinzipal selbst und den Prinzipal `krbtgt` zu erhöhen.

- Mit einem Packet-Sniffer können Sie feststellen, dass Sie sofort nach dem Aufruf von `kinit` eine Antwort vom KDC bekommen – noch bevor Sie überhaupt ein Passwort eingegeben haben! Das ist in Ordnung: Das KDC händigt ein Ticket-Granting-Ticket (TGT) auf Anfrage aus, da es durch einen vom Passwort des Benutzers abgeleiteten Schlüssel geschützt ist. Wenn das Passwort eingegeben wird, wird es nicht zum KDC gesendet, sondern zum Entschlüsseln der Antwort des KDCs benutzt, die `kinit` schon erhalten hat. Wird die Antwort erfolgreich entschlüsselt, erhält der Benutzer einen Sitzungs-Schlüssel für die künftige verschlüsselte Kommunikation mit dem KDC und das Ticket-Granting-Ticket. Das Ticket-Granting-Ticket wiederum ist mit dem Schlüssel des KDCs verschlüsselt. Diese Verschlüsselung ist für den Benutzer völlig transparent und erlaubt dem KDC, die Echtheit jedes einzelnen TGT zu prüfen.

- Wenn Sie OpenSSH verwenden und Tickets mir einer langen Gültigkeit (beispielsweise einer Woche) benutzen, setzen Sie die Option `TicketCleanup` in der Datei `sshd_config` auf `no`. Ansonsten werden Ihre Tickets gelöscht, wenn Sie sich abmelden.

- Host-Prinzipale können ebenfalls Tickets mit längerer Gültigkeit besitzen. Wenn der Prinzipal eines Benutzers über ein Ticket verfügt, das eine Woche gültig ist, das Ticket des Host-Prinzipals aber nur neun Stunden gültig ist, funktioniert der Ticket-Cache nicht wie erwartet. Im Cache befindet sich dann ein abgelaufenes Ticket des Host-Prinzipals.

- Wenn Sie mit `krb5.dict` die Verwendung schlechter Passwörter verhindern wollen, geht das nur mit Prinzipalen, denen eine Passwort-Policy zugewiesen wurde. Die Hilfeseite von `kadmind` beschreibt kurz, wie `krb5.dict` verwendet wird. Das Format von `krb5.dict` ist einfach: Die Datei enthält pro Zeile ein Wort. Sie können daher einen symbolischen Link auf `/usr/share/dict/words` erstellen.

## 15.7.7. Unterschiede zum MIT-Port

Der Hauptunterschied zwischen MIT-Kerberos und Heimdal-Kerberos ist das Kommando `kadmin`. Die Befehlssätze des Kommandos (obwohl funktional gleichwertig) und das verwendete Protokoll unterscheiden sich in beiden Varianten. Das KDC lässt sich nur mit dem `kadmin` Kommando der passenden Kerberos-Variante verwalten.

Für dieselbe Funktion können auch die Client-Anwendungen leicht geänderte Kommandozeilenoptionen besitzen. Folgen Sie bitte der Anleitung auf der Kerberos-Seite (http://web.mit.edu/Kerberos/www/) des MITs. Achten Sie besonders auf den Suchpfad für Anwendungen. Der MIT-Port wird standardmäßig in `/usr/local/` installiert. Wenn die Umgebungsvariable `PATH` zuerst die Systemverzeichnisse enthält, werden die Systemprogramme anstelle der MIT-Programme ausgeführt.

> Anmerkung: Wenn Sie den MIT-Port `security/krb5` verwenden, erscheint bei der Anmeldung mit `telnetd` und `klogind` die Fehlermeldung “`incorrect permissions on cache file`”. Lesen Sie dazu bitte die im Port enthaltene Datei `/usr/local/share/doc/krb5/README.FreeBSD`. Wichtig ist, dass zur Authentifizierung die Binärdatei `login.krb5` verwendet wird, die für durchgereichte Berechtigungen die Eigentümer korrekt ändert.

In der Datei `rc.conf` müssen folgende Zeilen aufgenommen werden:

    kerberos5_server="/usr/local/sbin/krb5kdc"
    kadmind5_server="/usr/local/sbin/kadmind"
    kerberos5_server_enable="YES"
    kadmind5_server_enable="YES"

Diese Zeilen sind notwendig, weil die Anwendungen von MIT-Kerberos Binärdateien unterhalb von `/usr/local` installieren.

## 15.7.8. Beschränkungen von Kerberos

### 15.7.8.1. Kerberos muss ganzheitlich verwendet werden

Jeder über das Netzwerk angebotetene Dienst muss mit Kerberos zusammenarbeiten oder auf anderen Wegen gegen Angriffe aus dem Netzwerk geschützt sein. Andernfalls können Berechtigungen gestohlen und wiederverwendet werden. Es ist beispielsweise nicht sinnvoll, für Anmeldungen mit `rsh` und `telnet` Kerberos zu benutzen, dagegen aber POP3-Zugriff auf einen Mail-Server zu erlauben, da POP3 Passwörter im Klartext versendet.

### 15.7.8.2. Kerberos ist für Einbenutzer-Systeme gedacht

In Mehrbenutzer-Umgebungen ist Kerberos unsicherer als in Einbenutzer-Umgebungen, da die Tickets im für alle lesbaren Verzeichnis `/tmp` gespeichert werden. Wenn ein Rechner von mehreren Benutzern verwendet wird, ist es möglich, dass Tickets gestohlen werden.

Dieses Problem können Sie lösen, indem Sie mit der Kommandozeilenoption `-c` oder besser mit der Umgebungsvariablen `KRB5CCNAME` einen Ort für die Tickets vorgeben. Diese Vorgehensweise wird leider selten benutzt. Es reicht, die Tickets im Heimatverzeichnis eines Benutzers zu speichern und mit Zugriffsrechten zu schützen.

### 15.7.8.3. Das KDC ist verwundbar

Das KDC muss genauso abgesichert werden wie die auf ihm befindliche Passwort-Datenbank. Auf dem KDC dürfen keine anderen Dienste laufen und der Rechner sollte physikalisch gesichert sein. Die Gefahr ist groß, da Kerberos alle Passwörter mit einem Schlüssel, dem Haupt-Schlüssel, verschlüsselt. Der Haupt-Schlüssel wiederum wird in einer Datei auf dem KDC gespeichert.

Ein kompromittierter Haupt-Schlüssel ist nicht ganz so schlimm wie allgemein angenommen. Der Haupt-Schlüssel wird nur zum Verschlüsseln der Passwort-Datenbank und zum Initialisieren des Zufallsgenerators verwendet. Solange der Zugriff auf das KDC abgesichert ist, kann ein Angreifer wenig mit dem Haupt-Schlüssel anfangen.

Wenn das KDC nicht zur Verfügung steht, vielleicht wegen eines Denial-of-Service Angriffs oder wegen eines Netzwerkproblems, ist eine Authentifizierung unmöglich. Damit können die Netzwerk-Dienste nicht benutzt werden; das KDC ist also ein optimales Ziel für einen Denial-of-Service Angriff. Sie können diesem Angriff ausweichen, indem Sie mehrere KDCs (einen Master und einen oder mehrere Slaves) verwenden. Der Rückfall auf ein sekundäres KDC oder eine andere Authentifizierungs-Methode (dazu ist PAM bestens geeignet) muss sorgfältig eingerichtet werden.

### 15.7.8.4. Mängel von Kerberos

Mit Kerberos können sich Benutzer, Rechner und Dienste gegenseitig authentifizieren. Allerdings existiert kein Mechanismus, der das KDC gegenüber Benutzern, Rechnern oder Diensten authentifiziert. Ein verändertes `kinit` könnte beispielsweise alle Benutzernamen und Passwörter abfangen. Die von veränderten Programmen ausgehende Gefahr können Sie lindern, indem Sie die Integrität von Dateien mit Werkzeugen wie `security/tripwire` prüfen.

## 15.7.9. Weiterführende Dokumentation

- The Kerberos FAQ

- Designing an Authentication System: a Dialogue in Four Scenes

- RFC 1510, The Kerberos Network Authentication Service (V5)

- MIT Kerberos-Seite

- Heimdal Kerberos-Seite

Zurück | Zum Anfang | Weiter
TCP-Wrapper | Nach oben | OpenSSL

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.