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

# 14.7. KerberosIV

Beigesteuert von Mark Murray. Basiert auf einem Beitrag von Mark Dapoz.

Kerberos ist ein zusätzliches Netzwerkprotokoll, das es Benutzern erlaubt, sich über einen sicheren Server zu authentifizieren. Dienste wie rlogin, rcp oder das sichere Kopieren von Dateien zwischen Systemen und andere risikoreiche Tätigkeiten werden durch Kerberos erheblich sicherer und kontrollierbarer.

Die folgende Anleitung kann nur als Wegweiser dazu dienen, wie Sie Kerberos für FreeBSD konfigurieren. Eine komplette Beschreibung des Systems finden Sie in den entsprechenden Hilfeseiten.

## 14.7.1. Installation von KerberosIV

Kerberos ist eine optionale Komponente von FreeBSD. Am leichtesten installieren Sie die Software, wenn Sie bei der ersten Installation von FreeBSD in sysinstall die Distribution `krb4` oder `krb5` auswählen. Damit installieren Sie entweder die “eBones” (KerberosIV) oder “Heimdal” (Kerberos5) Version von Kerberos. Beide Versionen werden mit FreeBSD ausgeliefert, da sie außerhalb von den USA oder Kanada entwickelt werden. Sie unterliegen deshalb auch nicht den restriktiven Exportbeschränkungen der USA und sind auch für Bewohner anderer Länder zugänglich.

Als Alternative steht die MIT Variante von Kerberos in der Ports-Sammlung unter `security/krb5` zur Verfügung.

## 14.7.2. Erstellen der initialen Datenbank

Die folgenden Schritte werden nur auf dem Kerberos-Server durchgeführt. Stellen Sie bitte vorher sicher, dass keine alten Kerberos-Datenbanken mehr vorhanden sind. Im Verzeichnis `/etc/kerberosIV` sollten sich nur die folgenden Dateien befinden:

    # cd /etc/kerberosIV
    # ls
    README      krb.conf        krb.realms

Wenn noch andere Dateien, wie `principal.*` oder `master_key`, existieren, müssen Sie die alte Kerberos-Datenbank mit `kdb_destroy` löschen. Wenn Kerberos nicht läuft, können Sie die Dateien auch einfach löschen.

Sie sollten nun die Dateien `krb.conf` und `krb.realms` editieren, um Ihr Kerberos-Realm zu definieren. Das folgende Beispiel zeigt dies für das Realm `EXAMPLE.COM` auf dem Server `grunt.example.com`. `krb.conf` sollte wie folgt aussehen:

    # cat krb.conf
    EXAMPLE.COM
    EXAMPLE.COM grunt.example.com admin server
    CS.BERKELEY.EDU okeeffe.berkeley.edu
    ATHENA.MIT.EDU kerberos.mit.edu
    ATHENA.MIT.EDU kerberos-1.mit.edu
    ATHENA.MIT.EDU kerberos-2.mit.edu
    ATHENA.MIT.EDU kerberos-3.mit.edu
    LCS.MIT.EDU kerberos.lcs.mit.edu
    TELECOM.MIT.EDU bitsy.mit.edu
    ARC.NASA.GOV trident.arc.nasa.gov

Die zusätzlich aufgeführten Realms brauchen Sie nicht anzulegen. Sie zeigen hier nur, wie man Kerberos dazu bringt, andere Realms zu erkennen. Sie können Sie also auch weglassen.

Die erste Zeile benennt das Realm, in dem das System arbeitet. Die anderen Zeilen enthalten Realm/Host Paare. Der erste Wert jeder Zeile ist das Realm, der zweite Teil ein Host, der in diesem Realm “Key Distribution Center” ist. Die Schlüsselwörter `admin server` nach einem Hostnamen bedeuten, dass dieser Host auch einen administrativen Datenbankserver zur Verfügung stellt. Weitere Erklärungen zu diesen Begriffen finden Sie in den Kerberos Manualpages.

Als nächstes muss `grunt.example.com` in das Realm `EXAMPLE.COM` aufgenommen werden. Des Weiteren erstellen wir einen Eintrag, der alle Rechner der Domäne `.example.com` in das Realm `EXAMPLE.COM` aufnimmt. `krb.realms` sollte danach so aussehen:

    # cat krb.realms
    grunt.example.com EXAMPLE.COM
    .example.com EXAMPLE.COM
    .berkeley.edu CS.BERKELEY.EDU
    .MIT.EDU ATHENA.MIT.EDU
    .mit.edu ATHENA.MIT.EDU

Die zusätzlichen Realms sind hier wieder als Beispiel gedacht. Sie können sie der Einfachheit halber auch weglassen.

Die erste Zeile nimmt ein einzelnes System in das Realm auf. Die anderen Zeilen zeigen, wie bestimmte Subdomänen einem bestimmten Realm zugeordnet werden.

Das folgende Kommando muss nur auf dem Kerberos-Server (oder “Key Distribution Center”) laufen. Mit `kdb_init` können wir die Datenbank anlegen:

    # kdb_init
    Realm name [default  ATHENA.MIT.EDU ]: EXAMPLE.COM
    You will be prompted for the database Master Password.
    It is important that you NOT FORGET this password.

    Enter Kerberos master key:

Anschließend muss der Schlüssel gespeichert werden, damit Server auf der lokalen Maschine darauf zugreifen können. Dies geschieht mit `kstash`:

    # kstash

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered. BEWARE!

Das verschlüsselte Master-Passwort wurde in `/etc/kerberosIV/master_key` gesichert.

## 14.7.3. Anlegen von Prinzipals

Für jedes System, das mit Kerberos gesichert werden soll, müssen zwei Prinzipale in die Datenbank eingetragen werden. Ihre Namen sind `kpasswd` und `rcmd`. Beide Prinzipale müssen für jedes System angelegt werden, wobei die Instanz der Name des jeweiligen Systems ist.

Die Dæmonen kpasswd und rcmd erlauben es anderen Systemen, Kerberos-Passwörter zu ändern und Kommandos wie rcp(1), rlogin(1) und rsh(1) laufen zu lassen.

Beide Einträge werden im Folgenden angelegt:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: passwd
    Instance: grunt

    <Not found>, Create [y] ? y

    Principal: passwd, Instance: grunt, kdc_key_ver: 1
    New Password:                    <---- geben Sie hier Zufallswerte ein
    Verifying password

    New Password: <---- geben Sie hier Zufallswerte ein

    Random password [y] ? y

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name: rcmd
    Instance: grunt

    <Not found>, Create [y] ?

    Principal: rcmd, Instance: grunt, kdc_key_ver: 1
    New Password:       <---- geben Sie hier Zufallswerte ein
    Verifying password

    New Password:           <---- geben Sie hier Zufallswerte ein

    Random password [y] ?

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:         <---- geben Sie nichts an, um das Programm zu verlassen

## 14.7.4. Erstellen der Server-Datei

Wir müssen nun für jede Maschine die Instanzen, die Dienste definieren, aus der Datenbank mit `ext_srvtab` extrahieren. Die erstelle Datei muss auf einem sicheren Weg in das Verzeichnis `/etc` jedes Clients kopiert werden. Die Datei muss auf jedem Server und auf jedem Client vorhanden sein und ist unabdingbar für Kerberos.

    # ext_srvtab grunt
    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered. BEWARE!
    Generating 'grunt-new-srvtab'....

Das Kommando erzeugt Dateien mit einem temporären Namen, der es anderen Servern erlaubt, ihre Datei abzuholen. Die Datei muss auf dem entsprechenden System in `srvtab` umbenannt werden. Auf dem originalen System können Sie mv(1) benutzen, um die Datei umzubenennen:

    # mv grunt-new-srvtab srvtab

Wenn die Datei für ein Client-System bestimmt ist und das Netzwerk nicht sicher ist, kopieren Sie die Datei auf ein bewegliches Medium und transportieren sie physikalisch. Kopieren Sie die Datei auf den Client in das Verzeichnis `/etc`. Benennen Sie die Datei in `srvtab` um und setzen Sie schließlich noch die Berechtigungen auf 600:

    # mv grumble-new-srvtab srvtab
    # chmod 600 srvtab

## 14.7.5. Füllen der Datenbank

Wir können nun Benutzer in der Datenbank anlegen. Mit `kdb_edit` legen wir zuerst die Benutzerin `jane` an:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: jane
    Instance:

    <Not found>, Create [y] ? y

    Principal: jane, Instance: , kdc_key_ver: 1
    New Password:                <---- geben Sie ein sicheres Passwort ein
    Verifying password

    New Password:                <---- wiederholen Sie die Eingabe
    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:          <---- geben Sie nichts an, um das Programm zu verlassen

## 14.7.6. Testen

Zuerst müssen die Kerberos-Dæmonen gestartet sein. Wenn Sie `/etc/rc.conf` richtig angepasst haben, passiert das automatisch, wenn Sie booten. Dieser Schritt ist nur auf dem Kerberos-Server notwendig, die Clients bekommen alles was sie brauchen aus dem `/etc/kerberosIV` Verzeichnis.

    # kerberos &
    Kerberos server starting
    Sleep forever on error
    Log file is /var/log/kerberos.log
    Current Kerberos master key version is 1.

    Master key entered. BEWARE!

    Current Kerberos master key version is 1
    Local realm: EXAMPLE.COM
    # kadmind -n &
    KADM Server KADM0.0A initializing
    Please do not use 'kill -9' to kill this job, use a
    regular kill instead

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!

Jetzt können wir mit `kinit` versuchen, ein Ticket für die ID `jane`, die wir oben angelegt haben, zu erhalten:

    % kinit jane
    MIT Project Athena (grunt.example.com)
    Kerberos Initialization for "jane"
    Password:

Mit `klist` können Sie sich vergewissern, dass Sie die Tickets auch erhalten haben:

    % klist
    Ticket file:    /tmp/tkt245
    Principal:      jane@EXAMPLE.COM

      Issued           Expires          Principal
    Apr 30 11:23:22  Apr 30 19:23:22  krbtgt.EXAMPLE.COM@EXAMPLE.COM

Versuchen Sie nun das Passwort mit passwd(1) zu ändern, um zu überprüfen, dass der kpasswd Dæmon auch auf der Kerberos-Datenbank autorisiert ist:

    % passwd
    realm EXAMPLE.COM
    Old password for jane:
    New Password for jane:
    Verifying password
    New Password for jane:
    Password changed.

## 14.7.7. Anlegen von `su` Privilegien

Mit Kerberos kann jedem Benutzer, der `root`-Privilegien braucht, ein eigenes Passwort für su(1) zugewiesen werden. Dies wird dadurch erreicht, dass die Instanz eines Prinzipals `root` ist. Mit `kbd_edit` legen wir nun den Eintrag `jane.root` in der Kerberos-Datenbank an:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: jane
    Instance: root

    <Not found>, Create [y] ? y

    Principal: jane, Instance: root, kdc_key_ver: 1
    New Password:                    <---- geben Sie ein sicheres Passwort ein
    Verifying password

    New Password:            <---- geben Sie das Passwort erneut ein

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short!
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:                <---- geben Sie nichts an, um das Programm zu verlassen

Versuchen Sie nun, für diesen Prinzipal Tickets zu bekommen:

    # kinit jane.root
    MIT Project Athena (grunt.example.com)
    Kerberos Initialization for "jane.root"
    Password:

Als nächstes fügen wir den Prinzipal in `.klogin` von `root` ein:

    # cat /root/.klogin
    jane.root@EXAMPLE.COM

Jetzt benutzen wir su(1):

    % su
    Password:

und kontrollieren, welche Tickets wir haben:

    # klist
    Ticket file:    /tmp/tkt_root_245
    Principal:      jane.root@EXAMPLE.COM

      Issued           Expires          Principal
    May  2 20:43:12  May  3 04:43:12  krbtgt.EXAMPLE.COM@EXAMPLE.COM

## 14.7.8. Weitere Kommandos

In einem der Beispiele haben wir einen Prinzipal mit dem Namen `jane` und der Instanz `root` angelegt. Der Prinzipal entstand aus einem Benutzer mit dem gleichen Namen. Unter Kerberos ist es Standard, dass ein `principal.instance` der Form `username.``root` es dem Benutzer `username` erlaubt, mit su(1) `root` zu werden, wenn die entsprechenden Einträge in `.klogin` von `root` existieren:

    # cat /root/.klogin
    jane.root@EXAMPLE.COM

Das gilt auch für die `.klogin`-Datei im Heimatverzeichnis eines Benutzers:

    % cat ~/.klogin
    jane@EXAMPLE.COM
    jack@EXAMPLE.COM

Die Einträge erlauben jedem, der sich im Realm `EXAMPLE.COM` als `jane` oder `jack` mit `kinit` authentifiziert hat, mittels rlogin(1), rsh(1) oder rcp(1) auf den Account `jane` und dessen Dateien zuzugreifen.

Im folgenden Beispiel meldet sich `jane` mit Kerberos auf `grunt` an:

    % kinit
    MIT Project Athena (grunt.example.com)
    Password:
    % rlogin grunt
    Last login: Mon May  1 21:14:47 from grumble
    Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
            The Regents of the University of California.   All rights reserved.

    FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

Im folgenden Beispiel wurde der Prinzipal `jack` mit einer Instanz `null` angelegt. Mit der obigen `.klogin`-Datei kann er sich nun auf derselben Maschine als `jane` anmelden:

    % kinit
    % rlogin grunt -l jane
    MIT Project Athena (grunt.example.com)
    Password:
    Last login: Mon May  1 21:16:55 from grumble
    Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
            The Regents of the University of California.   All rights reserved.
    FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

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

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