14.7. KerberosIV

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-Kollektion 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 /etc/kerberosIV Verzeichnis 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/kerberosIV. 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