PoC: /* Grundinstallation unter Debian-Linux */ Aktualisierung

2016-08-26T19:45:52Z

Grundinstallation unter Debian-Linux: Aktualisierung

Neue Seite

Dieser Artikel soll einen Überblick und Kurzeinstieg in '''Kerberos''', sowie dessen Zusammenspiel mit verschiedenen Diensten und Plattformen für ein Single-Sign-on-System ermöglichen.

== Was ist Kerberos ==
Kerberos ist als Single-Sign-On-Lösung entwickelt worden. Der Gedanke dahinter ist, dass der Benutzer sich einmal zu Tagesbeginn gegenüber einer zentralen Instanz authentisiert und diese im weiteren Tagesverlauf den Benutzer gegenüber den einzelnen Diensten authentisiert.

Kerberos bietet ''keine'' verteilte Benutzerdatenbank. Auf den einzelnen beteiligten Maschinen müssen die lokal eingerichteten Benutzer gleich benannt sein oder über andere geeignete Maßnahmen gegenüber Kerberos gemappt werden. Eine Möglichkeit dazu ist ''~/.k5login'', dort können zeilenweise alle Principals vermerkt werden, die Zugriff auf den jeweiligen Account haben dürfen.

Microsoft Windows verwendet im Hintergrund ebenfalls Kerberos und umgeht dieses Problem mit ''ActiveDirectory'' über den Weg ''LDAP'' als verteilte Benutzerdatenbank. Unter Linux sind traditionelle Wege wie ''NIS'' oder lokale Benutzer völlig suffizient.

Kerberos fasst alle Benutzer in einer administrativen Domain zusammen, diese wird ''Realm'' genannt. Der Realm wird in Grossbuchstaben konfiguriert und entspricht meist (aber nicht zwingend) der DNS-Domain. Ein Benutzer ist lediglich ein Objekt (''Principal'') in der zentralen Benutzerdatenbank auf dem ''Adminserver''. Vom Adminserver losgelöst funktioniert der KDC (key distribution center). Dieser verteilt in Absprache mit dem Adminserver die Tickets.

Dienste und Hosts werden ebenso in der Benutzerdatenbank gesichert. Diese Principals haben allerdings nicht die Möglichkeit, ein Passwort einzugeben. Daher werden diese Principals mit ''-randkey'' angelegt (Zufallspaßwort) und diese Information auf der Gegenseite in einer ''Keytab'' abgelegt. Diese Keytab (üblicherweise ''/etc/krb5.keytab'' für alle Dienste, die als ''root'' laufen) dient den Hosts und Services als Passwortdatei. Dienste, die unter eigenen Benutzern laufen, brauchen ihre eigene, (nur) für sie lesbare Keytab.

Diese Abhängigkeit von Hostnamen bedingt einen saubere Konfiguration der beteiligten DNS. Lösungen wie Avahi für Zeroconf können nicht sinnvoll genutzt werden, da die DNS-Auflösung nicht konsistent mit den Hostnamen ist. Die jeweils verwendete ''.local''-Domain mit in Kerberos zu integrieren würde die relative Sicherheit des Systems aushebeln.

Immer wieder gerne übersehen wird die Tatsache, dass Kerberos eine saubere Zeitsynchronisation über alle beteiligten Maschinen hinweg voraussetzt. Am Sinnvollsten ist es daher, vor der Konfiguration von Kerberos erst einmal entsprechende Dienste wie ntp einzurichten.

Grundlegend besteht im Rahmen der Redundanzbildung die Möglichkeit, mehrere KDCs parallel am Laufen zu haben, während der Adminserver nur einmal pro Ralm vorhanden sein kann. Mit einem gewissen Maß an Handarbeit kann die Benutzerdatenbank aber zu einem Standbysystem gesichert werden.

Ein Benutzer beginnt den Tag mit einem ''kinit''. Dies legt ein ''TGT'' (Ticket Granting Ticket) für den jeweiligen Benutzer an, was als Generalausweis für die Authentisierung des Benutzers gegenüber Kerberos sorgt. Üblicherweise verfällt dieses nach 10 Stunden. Den Status des TGT kann man mit ''klist'' einsehen. Über dieses TGT läuft der restliche Authentisierungsprozess. Zum Tagesende wird das Ticket mit ''kdestroy'' gelöscht.

=== Principals ===
Ein Principal ist ein Benutzerobjekt in der Benutzerdatenbank.

Syntax:
primary[/instance][@REALM]

; poc@POCNET.NET
: Benutzer ''poc'' im Realm ''POCNET.NET''.
; poc/admin@POCNET.NET
: Benutzer ''poc'' mit dem Zusatztag ''admin'' im Realm ''POCNET.NET''.
; host/leela.pocnet.net@POCNET.NET
: Ein Host-Objekt für den Host ''leela.pocnet.net'' im Realm ''POCNET.NET''.
; imap/leela.pocnet.net@POCNET.NET
: Ein Service-Objekt für den Service ''imap'' im Realm ''POCNET.NET''.

=== Glossar ===
; Client
: Ein Objekt, welches Tickets anfordern kann. Das kann ein Benutzer sein, ein Host oder ein Service.
; Host
: Ein Server, welcher Dienste (Services) zu Verfügung stellt.
; Service
: Ein Prozess, der über Netzwerk seine Dienste anbietet, z. B. ein Telnet-Server.
; Principal
: Ein Benutzerobjekt auf dem Adminserver. z. B. poc/admin@POCNET.NET. Siehe oben.
; Adminserver
: Der Server, welcher die Benutzerdatenbank vorhält und für Änderungen des Kerberos-Paßwortes kontaktiert werden muss.
; KDC
: Key Distribution Center, ein Server, welcher Tickets ausstellt.
; Keytab
: Von '''Key Tab'''le, hier “merken” sich Hosts und Services ihre “Paßwörter”.
; Realm
: Eine administrative Domain, sie enthält mindestens einen Adminserver und einen KDC.
; TGT
: Das Ticket Granting Ticket, eine Art Masterticket. Basierend auf diesem können Clients weitere, spezifischere Tickets im gleichen Realm anfordern.
; Ticket
: Eine temporäre Zusammenstellung von kryptographischen Schlüsseln, welche die Identität eines Clients gegenüber einem Host oder Service bestätigen.

== Grundinstallation unter Debian-Linux ==
Dieser Abschnitt ist unter Lenny (5) getestet worden. Die Installation unter Squeeze (6) unterscheidet sich nur minimal, ebenso unter Jessie (8).

apt-get install krb5-kdc krb5-admin-server
Bei der Installation werden grundlegende Fragen wie z. B. nach dem eigenen Realm gestellt. Kompatibilität zu Kerberos4 wird normalerweise nicht benötigt und ist wegen erheblicher Defizite der zugrundeliegenden kryptographischen Methode DES auch nicht anzuraten. Für Mac OS < 10 gibt es leider keine Kerberos5-Implementation, lediglich Kerberos4.

Die Fehlermeldung, dass ''kadmind'' wegen einer fehlenden Datei nicht gestartet werden kann, kann ignoriert werden. In ''/etc/default/krb5-kdc'' kann <code>RUN_KRB524D</code> auf ''false'' gesetzt werden. Wir benutzen wie gesagt keine Kerberos 4-Kompatibilität, daher ist der Daemon unnötig. In der mit Debian Jessie ausgelieferten Version gibt es diesen Daemon nicht mehr und die Dateien in ''/etc/default'' sind leer. Die automatisch erstellte Datei weist noch einige Konfigurationsparameter in Sachen Heimdal und Kerberos 4 auf. Diese können ersatzlos gelöscht werden, siehe Kommentare.

Beispieldatei ''/etc/krb5.conf'':
[libdefaults]
clockskew = 60
default_realm = POCNET.NET
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac camellia128-cts-cmac
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac camellia128-cts-cmac
dns_fallback = yes
dns_lookup_kdc = true
forwardable = true
kdc_timesync = 1
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac camellia128-cts-cmac
proxiable = true

[realms]
POCNET.NET = {
kdc = leela.pocnet.net
admin_server = leela.pocnet.net
}

Beispieldatei ''/etc/krb5kdc/kadm5.acl'' dient zur Verteilung von Zugriffsrechten auf das ''kadmin''-Kommando.
root@POCNET.NET *
*/admin@POCNET.NET *

Jetzt kann die Benutzerdatenbank initialisiert werden:
kdb5_util create -s

Im nächsten Schritt müssen die eigenen Host- und Serviceprincipals angelegt werden. Mit dem Kommando ''kadmin.local'' kann dies initial erreicht werden (interaktiv):
add_principal -randkey host/leela.pocnet.net
ktadd host/leela.pocnet.net

Damit ist die Grundkonfiguration von Kerberos abgeschlossen. Als wichtiger, zu beachtender Punkt wäre die Uhrzeit zu nennen. Kerberos fällt auf die Nase, wenn die Uhrzeit der beteiligten Hosts über einen gewissen Schwellwert abweicht. Dieser ist im obigen Beispiel von (default) 300 auf 60 Sekunden reduziert.

=== Administration ===
* ''kadmin'' bzw. ''kadmin.local'': Benutzerpflege. Ersteres für die Principalpflege übers Netz, letzteres läuft nur auf dem Adminserver.
** <code>add_principal ''principal''</code> — Erstellt normalen Benutzer.
** <code>add_principal -randkey ''host/<nowiki><hostname></nowiki>''</code> — Erstellt Hostprincipal.
** <code>add_principal -randkey ''imap/<nowiki><hostname></nowiki>''</code> — Erstellt Serviceprincipal für z. B. IMAP.
** <code>ktadd ''host/<nowiki><hostname></nowiki>''</code> — Übernahme in lokale Keytab, auf dem Rechner machen, der trusted sein soll!
** <code>ktremove ''host/<nowiki><hostname></nowiki>''</code> — Löschen aus lokaler Keytab.

* ''ktutil'' für die Pflege von z. B. ''/etc/krb5.keytab'' — Management (evtl. eher über ''kadmin'' machen!)
** <code>read_kt /etc/krb5.keytab</code> — liest die Keytab ein.
** <code>list</code> — Inhalt listen.
** <code>delent ''num''</code> — Key löschen. Achtung, Rest rückt auf!
** <code>write_kt /etc/krb5.keytab2</code> — schreibt die Keytab, das muss zwingend unter anderem Namen passieren, überschreiben funktioniert nicht!

* Benutzerseitig:
** <code>kinit</code> — TGT ausstellen.
** <code>klist</code> — TGT-Status prüfen.
** <code>kdestroy</code> — Tagesende, TGT löschen.

=== Weitere Clientrechner ===
Die Erweiterung des Realms ist unter Linux recht einfach:
* Installation der Clientprogramme und beantworten der entsprechenden Fragen nach Realm, kdc und Adminserver:
apt-get install krb5-user
* Erzeugen eines Hostprincipals für den Host auf dem Adminserver über ''kadmin.local'':
add_principal -randkey host/ci.pocnet.net
* Übertragen des Hostprincipals auf den Client, dazu auf dem Client aufrufen:
kadmin -p … (hier einen berechtigten Benutzerprincipal mitgeben)
ktadd host/ci.pocnet.net

==== Mac OS X ====
Für einen Client unter Mac OS X genügt es die ''/etc/krb5.conf'' wie im Beispiel weiter oben anzupassen, sowie die Erweiterung der lokalen Keytab wie beschrieben.

==== Cisco IOS vs. Kerberos ====
Prinzipiell kann z. B. ein Cisco-Router auch als Kerberos-Client mit eingebunden werden. Die Vorgehensweise ist analog zu anderen Clients.

Konfigurationsausschnitt:
aaa authentication login default krb5 local
!
kerberos local-realm POCNET.NET
kerberos realm pocnet.net POCNET.NET
kerberos realm .pocnet.net POCNET.NET
kerberos server POCNET.NET 192.168.59.10
kerberos credentials forward

Da es auf dem Router keine lokale Keytab gibt, muss der zugehörige Hostprincipal isoliert werden. Das kann innerhalb ''kadmin(.local)'' mit ''ktadd -k /tmp/routerkeytab'' sehr leicht erreicht werden. Diese kann dann mittels des IOS-Befehls <code>kerberos srvtab remote</code> herüberkopiert werden. IOS konvertiert den Key dann zu einer (ähnlichen) Zeile wie folgt:
kerberos srvtab entry host/router.pocnet.net@POCNET.NET 1 1276208580 3 1 8 0076>7658=?0=;0?>

Das scheint aber nicht wirklich allzugut zu funktionieren, im Syslog erscheint die Meldung:
KDC has no support for encryption type

Lt. [http://www.h5l.org/manual/HEAD/info/heimdal.html#Things-in-search-for-a-better-place Heimdal-Doku] hat IOS nur Unterstützung für die inzwischen als nicht wirklich sichere DES-Verschlüsselung eingebaut.

Siehe auch [http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_cfg_kerberos.html Configuring Kerberos] auf ''cisco.com''.

==== Windows ====
Der Artikel [http://technet.microsoft.com/en-us/library/bb742433.aspx Step by Step Guide to Kerberos 5], zeigt exemplarisch, wie Windows 2000 an MIT-Kerberos angedockt werden kann und umgekehrt.

* [http://technet.microsoft.com/en-us/library/cc753771(d=printer,v=ws.10).aspx Anleitung zu ''ktpass''], einem Hilfsprogramm u. A. zum Erzeugen von Kerberos-Keytabs im MS-Technet
* [https://cwiki.apache.org/DIRxINTEROP/exporting-keytabs-from-active-directory.html Beachtenswertes zu ''ktpass''] bei Apache.org
* Anleitungen zu SetSPN im MS-Technet, einem Hilfsprogramm zum Pflegen von Kerberos-Principals innerhalb ADS-Benutzerobjekten.
** [http://technet.microsoft.com/en-us/library/cc773257(v=ws.10).aspx Setspn Overview]
** [http://technet.microsoft.com/en-us/library/cc731241(v=ws.10).aspx Setspn]
** [http://technet.microsoft.com/de-de/library/cc755442(v=ws.10).aspx Setspn Syntax]
** [http://technet.microsoft.com/de-de/library/cc755413(v=ws.10).aspx Setspn Examples]
** [http://technet.microsoft.com/en-us/library/ms191153.aspx Registering a Service Principal Name]

Unsortierte Links:
* http://www.mail-archive.com/kerberos@mit.edu/msg10373.html
* http://blog.scottlowe.org/2007/07/09/linux-ad-integration-with-windows-server-2008/
* http://blog.scottlowe.org/2006/08/10/kerberos-based-sso-with-apache/
* http://social.technet.microsoft.com/wiki/contents/articles/kerberos-interoperability-step-by-step-guide-for-windows-server-2003.aspx
* http://thejavamonkey.blogspot.com/2008/03/active-directory-and-kerberos-service.html
* https://blog.godatadriven.com/cross-realm-trust-kerberos.html

===== Linux als Client an AD =====
Voraussetzungen: AD-Member mit Samba, aktuelle Samba-Version aus Debian Squeeze.

Auf dem AD-Server muss mit ''setspn'' das Mapping von AD-Computerkonto zu Kerberosinstanz kontrolliert/nachgebessert werden.

Die für den Linuxclient notwendige Keytab erhält man mit
net ads keytab create [-U domainadminuser_in_ad ]

Voraussetzung hierfür: In ''/etc/samba/smb.conf'':
kerberos method = secrets and keytab

Die passenden Principalkeys werden automatisch in die ''/etc/krb5.keytab'' eingepflegt. Das ist ein Vorgang, der mit ''ktpass'' leider nicht auf Anhieb zum Funktionieren zu bringen war.

== Dienste ==
Dienste als auch Clientprogramme, die über Kerberos authentisieren sollen, müssen diese Methode auch beherrschen. Im aktuellen Kerberos5 wird das über GSSAPI (Generic Security Services API) geregelt. Als Alternative besteht noch SASL (Simple Authentication and Security Layer), was wiederum über ein GSSAPI-Plugin auf Kerberos5-Authentisierung zugreifen kann.

=== Ssh ===
* Benutzt host-Auth (Principal ''host/…'').
* In ''ssh_config'':
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPITrustDns yes
''GSSAPIDelegateCredentials'' sorgt dafür, dass das bereits ausgestellte TGT auf den jeweiligen Zielhost weitergeleitet wird (sofern das TGT ''forwardable'' ist). Das hat den Vorteil, dass man sich dann von dort aus ebenfalls mit Kerberos-Auth weiterhangeln kann.

* In ''sshd_config'':
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck yes
''GSSAPICleanupCredentials'' ist dringend empfohlen, wenn ''GSSAPIDelegateCredentials'' benutzt wird: Es ruft nach dem Logout des Users ein ''kdestroy'' auf, damit das TGT wieder vom Host verschwindet.

=== Su ===
* Benutzt host-Auth (Principal ''host/…'').
Im Home des Zielbenutzers muss die Datei ''.k5login'' angelegt werden. Hierin können zeilenweise alle Principals vermerkt werden, die über ''ksu'' den Benutzer wechseln dürfen.

Wenn kein genereller Zugriff erlaubt sein soll, sondern nur bestimmte Kommandos, so kann dies über die Datei ''.k5users'' geschehen.
poc@POCNET.NET /bin/ls
poc/admin@POCNET.NET *
So darf ''poc'' ein <code>ksu -e /bin/ls</code> ausführen, die Adminvariante ''poc/admin'' dagegen alle Kommandos.

=== Dovecot ===
* Benutzt service-Auth (Principals ''imap/…, pop/…, smtp/…'').
* In ''/etc/dovecot/dovecot.conf'':
auth_krb5_keytab = /etc/krb5.keytab
auth default {
mechanisms = plain login gssapi
passdb pam {
}
userdb passwd {
}
}

Siehe auch das Dovecot-Wiki zum Thema [http://wiki.dovecot.org/Authentication/Kerberos Kerberos] zum Thema.

=== Sendmail ===
* Benutzt service-Auth (Principal ''smtp/…'').

Beschreibung gilt für das aktuelle sendmail-Paket von PoC.

apt-get install libsasl2-modules-gssapi-mit
* In ''/etc/mail/sendmail.mc'':
TRUST_AUTH_MECH(`GSSAPI PLAIN LOGIN')dnl
define(`confAUTH_MECHANISMS', `GSSAPI PLAIN LOGIN')dnl

Danach sendmail neu starten (erzeugt automatisch die ''sendmail.cf'' neu).

* Konfig siehe auch [http://www.upenn.edu/computing/pennkey/sysadmin/d_install_unix/smtp.html hier]

=== Netatalk ===
* Benutzt service-Auth (Principal ''afpserver/…'').
* In ''/etc/netatalk/afpd.conf'':
… -uamlist uams_clrtxt.so,uams_gss.so -k5service afpserver
-k5realm POCNET.NET -k5keytab /etc/krb5.keytab -fqdn leela.pocnet.net …
(muss in eine Zeile)

=== Samba ===
* Benutzt service-Auth (Principal ''cifs/…'').
* In ''/etc/samba/smb.conf'':
[global]
client use spnego = yes
realm = POCNET.NET
use kerberos keytab = true

Zugriff von OS X aus ist nun ohne Passwort möglich. Nachteil: Man muss zwingend den passenden Sharenamen im Server-Verbinden-Dialog mit angeben oder über die Freigaben-Liste in der Seitenleiste eines Finder-Fensters zugreifen.

=== Telnet und Konsorten ===
* Benutzt host-Auth (Principal ''host/…'').
apt-get install krb5-telnetd krb5-rsh-server krb5-clients
Installiert u. A. einen kerberisierten Telnet-Server. Ebenfalls werden einige r-Dienste mit ihren Kerberospendants installiert (klogind/eklogind, kshelld).

Ggfs. muss in der ''/etc/inetd.conf'' nachgebessert werden, falls hier schon vorher Dienste mit scheinbar doppelten Einträgen vorhanden waren (IPv6).

<code>telnet -f</code> leitet ein als ''forwardable'' angelegtes TGT auf den Zielhost weiter. <code>telnet -x</code> verschlüsselt die Verbindung.

=== Apple Calendarserver ===
* Benutzt service-Auth (Principal ''http/…'').
* In ''/etc/caldavd/caldavd.plist'' Serviceprincipal ergänzen:

<key>Kerberos</key>
<dict>
<key>Enabled</key>
<true/>
<key>ServicePrincipal</key>
<string>http/leela.pocnet.net@POCNET.NET</string>
</dict>

* In Apple iCal:
** Account auf Kerberos umstellen (Servereinstellungen),
** Account-Informationen: Passwort löschen, Benutzername muss stehen bleiben!

Nachteile: Wenn als Benutzername in iCal nicht die eigene Mailadresse verwendet wird, funktioniert das Einladen von Kontakten nicht. Hier beisst sich Kerberos mit Mail, was beides das @-Zeichen für eine Trennung zwischen Domain und Benutzernamen verwendet.

=== Webbasierte Dienste ===
==== Apache ====
* Benutzt service-Auth (Principal ''HTTP/…'').

Unter Debian ist die Installation von ''libapache2-mod-auth-kerb'' notwendig. Kerberos benutzt DNS für die Verifizierung von Hostnamen, daher muss zwingend ''HostnameLookups'' auf on gesetzt werden und der URL-Zugriff auch auf diesen Hostnamen erfolgen. Zu diesem Hostnamen muss ein passender Principal angelegt werden und in die in der ''htaccess'' referenzierte Keytab exportiert werden. In dieser Keytab können im Falle der Verwendung von VHosts auch mehrere Serviceprincipals für HTTP hinterlegt werden.

Die Benutzung einer separaten Keytab empfiehlt sich, da der Apache nicht als ''root'' läuft. Über eine Anpassung der globalen Keytab erkauft man sich das Risiko, dass auch andere Keys ausgelesen und damit kompromittiert werden könnten.

Eine Beispiel-htaccess sieht so aus:
AuthName Krb-Test
AuthType Kerberos
Krb5Keytab /etc/apache2/krb5.keytab

<Limit GET PUT>
require valid-user
</Limit>

Das Kerberos-Modul verwendet HTTP als Serviceprincipal, also in Großbuchstaben. Das muss beim Anlegen des Principals berücksichtigt werden! Alternativ kann auch mit dem Parameter ''KrbServiceName'' ein eigener Wert vorgegeben werden.

==== Firefox ====
* In der URL-Zeile about:config eingeben und Return drücken.
* Bei Filter network.nego eingeben,
* In die Felder ''network.negotiate-auth.delegation-uris'' und ''network.negotiate-auth.trusted-uris'' jeweils den Realm in Kleinbuchstaben eingeben.

Siehe auch [https://developer.mozilla.org/En/Integrated_Authentication Mozilla Developer: Integrated Authentication].

==== Safari ====
Keine Anpassungen notwendig.

== Weblinks ==
* [http://web.mit.edu/Kerberos/krb5-1.7/krb5-1.7.1/doc/krb5-admin.html MIT-Kerberos Admin-Guide] (engl.)
* [http://web.mit.edu/Kerberos/krb5-1.7/krb5-1.7.1/doc/krb5-user.html MIT-Kerberos User-Guide] (engl.)
* [http://leela.pocnet.net/heise/ix/07/03/123/art.htm Heise-Artikelserie zu Kerberos ab iX 03/2007]
* [http://forums.macosxhints.com/showthread.php?t=80265 Besonderheiten zu Kerberos unter OS X] (engl.)
* [http://chrisp.de/en/rsrc/kerberos.html Kurzeinstieg in Kerberos] (engl.)
* [http://www.ncsu.edu/mac/sma/sma.html Kerberos für alte Mac-OS-Versionen bis System 7] (engl.)
* [http://www.faqs.org/faqs/kerberos-faq/general/preamble.html Kerberos FAQ] (engl.)

[[Kategorie:Software]]
[[Kategorie:UNIX]]

Kerberos - Versionsgeschichte

PoC: /* Grundinstallation unter Debian-Linux */ Aktualisierung