Kerberos: Unterschied zwischen den Versionen

Aus Knowledgebase
Zur Navigation springen Zur Suche springen
 
(kein Unterschied)

Aktuelle Version vom 26. August 2016, 20:45 Uhr

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 Benutzer­daten­bank. 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 Table, 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 RUN_KRB524D 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.
    • add_principal principal — Erstellt normalen Benutzer.
    • add_principal -randkey host/<hostname> — Erstellt Hostprincipal.
    • add_principal -randkey imap/<hostname> — Erstellt Serviceprincipal für z. B. IMAP.
    • ktadd host/<hostname> — Übernahme in lokale Keytab, auf dem Rechner machen, der trusted sein soll!
    • ktremove host/<hostname> — Löschen aus lokaler Keytab.
  • ktutil für die Pflege von z. B. /etc/krb5.keytab — Management (evtl. eher über kadmin machen!)
    • read_kt /etc/krb5.keytab — liest die Keytab ein.
    • list — Inhalt listen.
    • delent num — Key löschen. Achtung, Rest rückt auf!
    • write_kt /etc/krb5.keytab2 — schreibt die Keytab, das muss zwingend unter anderem Namen passieren, überschreiben funktioniert nicht!
  • Benutzerseitig:
    • kinit — TGT ausstellen.
    • klist — TGT-Status prüfen.
    • kdestroy — 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 kerberos srvtab remote 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. Heimdal-Doku hat IOS nur Unterstützung für die inzwischen als nicht wirklich sichere DES-Verschlüsselung eingebaut.

Siehe auch Configuring Kerberos auf cisco.com.

Windows

Der Artikel Step by Step Guide to Kerberos 5, zeigt exemplarisch, wie Windows 2000 an MIT-Kerberos angedockt werden kann und umgekehrt.

Unsortierte Links:

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 ksu -e /bin/ls 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 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 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).

telnet -f leitet ein als forwardable angelegtes TGT auf den Zielhost weiter. telnet -x 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 Mozilla Developer: Integrated Authentication.

Safari

Keine Anpassungen notwendig.

Weblinks

Abgerufen von „https://kb.pocnet.net/index.php?title=Kerberos&oldid=1814“