In diesem Beitrag beschreibe ich, wie man mit Hilfe von Kerberos die Zahl der notwendigen Anmeldungen im Heimnetz auf ein Minimum beschränkt - im Idealfall wird daraus Single Sign On. Sicherheit und Komfort ergeben hier (wie so oft) zusammengerechnet 100% - man muss eine bewusste Entscheidung treffen, ob man dieses Konzept umsetzen möchte.

Richtet man den Dienst so ein, gelingt etwa der Aufruf von eigentlich durch Passwortabfragen gesicherten Websites ohne Eingabe des Passworts oder die Anmeldung auf einem anderen Rechner mit Hilfe von SSH, ohne dass auf dem anderen Rechner zuvor ein Passwort eingegeben oder ein öffentlicher Schlüssel hinterlegt wurde. Das ist vor allem dann praktisch, wenn man eine große Zahl (virtuelle) Maschinen betreibt und nicht für alle User alle öffentlichen Schlüssel auf alle Systeme verteilen will (Puppet hin oder her).

Beschrieben wir hier nur die Umsetzung auf Client-Seite auf Grundlage von FreeIPA, nachdem ich in einem vorherigen Beitrag schon erklärt habe, wie man FreeIPA zur Verwaltung des Netzwerks einsetzen kann.

Weitere Beiträge in der Reihe:

Für und Wider

Für die Einführung einer SSO-Lösung spricht zunächst natürlich Komfort. User müssen sich nur noch einmalig an einem System anmelden und dieser Nachweis der Identität wird dann an andere Systeme weitergereicht. Gegen so eine Vereinfachung spricht natürlich sofort, dass dann nur noch ein Passwort geklaut werden muss, um weitläufig Zugang zum System zu bekommen. Dieses Problem spielt allerdings keine Rolle, wenn man alle möglichen weiteren Passwörter hat abspeichern lassen - etwa das Kennwort des SSH-Schlüssels im Schlüsselring des Betriebssystems (mit dem Login-Kennwort verschlüsselt). Legt man viele Passwörter an, speichert man sie für gewöhnlich sowieso ab oder wählt sie leichter erratbar, weil man sie sich noch merken will. Die Verwendung eines Passwort-Managers erhöht hier auch lediglich die Anzahl zu klauender Passwörter um 1. Darüber hinaus muss weiterhin die Übertragung, Lagerung und Haltbarkeit des Passworts gut reguliert sein. Im Klartext übertragen oder im Klartext in der Datenbank einer Webanwendung hinterlegt ist so ein Passwort auch schnell kompromittiert. Ist es unendlich lange gültig und wird nicht geändert, weil es unter den zwei zu ändern vergessenen Passwörtern unter insgesamt vier Dutzend Passwörtern war, ist es auch unendlich lange ausnutzbar.

Am Ende bleibt es eine Entscheidung, die gewissenhaft getroffen werden und an die eigenen Ånforderungen angepasst werden sollte. Wie immer muss in jedem Fall jedoch die Implementierung sitzen; jedes System ist nur so sicher wie seine Umsetzung es zulässt.

Von Sicherheit und Bequemlichkeit abgesehen hat die Sache auch in Netzwerken Relevanz, in denen die Nutzeraccounts und der Zugang zentral geregelt werden. Wird ein Account im FreeIPA deaktiviert, gelingt auch der Zugang zu Diensten wie Webservern oder SSH nicht mehr. Über Host Based Access Control-Regeln (HBAC) kann in FreeIPA weiterhin auch ein gewisser Teil der Authorisierung verwaltet werden.

Voraussetzungen

Das hier beschriebene Setup setzt auf Kerberos. Spätestens an dieser Stelle beim Einrichten eines Heimnetzwerks wird ein funktionierendes DNS-System im Netzwerk unerlässlich, da Kerberos sich æbenfalls stark auf DNS-Einträge (A und PTR!) verlässt. Das bekommt man etwa, wenn man FreeIPA zur Verwaltung des Netzwerks verwendet. FreeIPA kümmert sich mit Hilfe von Bind um DNS-Einträge für seine zugewiesene Zone.

Die Einrichtung eines Kerberos-Realms wird hier ebenfalls nicht erklärt, da diese auch bereits bei der Einrichtung von FreeIPA mitkommt. Die reine Einrichtung eines Realms ist zwar nicht schwierig, nur für sich stehend aber ziemlich unpraktisch, da man meist noch irgend ein System zur Vorhaltung von Accountdaten, Gruppenzugehörigkeiten, etc und dessen bequemer Verwaltung vorhalten will und schon hat man als einzusetzende Komponenten DNS, Kerberos, LDAP und ein Frontend dafür und kommt in Sachen Features schon ziemlich nahe an den Funktionsumfang von FreeIPA, während sich die Einrichtung noch unnötig verkompliziert (LDAP…). Ich empfehle also, sich stark den Einsatz von FreeIPA zu überlegen.

Einrichtung der Dienste

Jeder Rechner, auf dem Kerberos genutzt werden soll, muss bereits dem Kerberos-Realm beigetreten sein, also im Fall von FreeIPA die Installation von ipa-client-install durchlaufen haben. Meldet man sich an einem solchen Rechner dann mit einem Konto aus FreeIPA an, erhält man automatisch ein ticket granting ticket und kann sich gegenüber anderen Systemen mit Hilfe von Tickets ausweisen.

Wird so ein ticket granting ticket vom Rechner geklaut, kann es bis zu seiner Ablaufzeit natürlich missbraucht werden, um sich als User des Systems auszugeben. Diese Gefahr besteht hauptsächlich, wenn ein Rechner insgesamt nicht mehr vertrauenswürdig ist. In diesem Szenario wäre aber auch leicht ein Keylogger o.Ä. installiert, der Passwörter abgreifen könnte.

Firefox

Um sich an Websites mit Hilfe von Kerberos anmelden zu können, müssen diese das auch unterstützen. Wie genau die Anwendung Authentifizierung handhabt kann dabei sehr vielfältig sein. Ich beschreibe hier ein kleines Beispiel anhand von Basic Auth, das sich im Hintergrund auf Kerberos stützt und so den Zugang zu einem durch Apache betriebenen Webhost erlaubt. Darüber hinaus muss auch Firefox nochmal entsprechend konfiguriert werden, damit es klappt.

Serverseitig

Wir brauchen mod_auth_kerb um die Tickets der Clients zu akzeptieren und außerdem brauchen wir noch mod_auth_pam, um die Authentifizierung gegen sssd laufen zu lassen. Diese beiden Module müssen aktiviert werden:

sudo a2enmod auth_kerb
sudo a2enmod authnz_pam

Weiterhin brauchen wir ein Prinzipal, über dєn der Webserver-Dienst die Anmeldungen entgegennehmen kann:

sudo ipa service-add http/protected.domain.tld
sudo ipa-getkeytab -p http/protected.domain.tld -s auth.domain.tld -k /etc/apache2/keytab

Dabei muss protected.tld dem DNS-Eintrag des Servers entsprechen!

Die weitere Einrichtung erfolgt dann im Apache-vHost, bei dem natürlich domain.tld anzupassen ist:

<VirtualHost *:443>
  ServerName protected.domain.tld

  ## Vhost docroot
  DocumentRoot "/var/www/html"

  ## Directories, there should at least be a declaration for /var/www/html

  <Directory "/var/www/html">
    AllowOverride None
    Require pam-account http
    AuthType Kerberos
    AuthName "Kerberos Login"
  </Directory>

  ## Logging
  ErrorLog "/var/log/apache2/protected.domain.tld_error_ssl.log"
  ServerSignature Off
  CustomLog "/var/log/apache2/protected.domain.tld_access_ssl.log" combined

  ## Kerberos directives
  KrbMethodNegotiate on
  KrbMethodK5Passwd on
  KrbAuthoritative on
  KrbAuthRealms IPA.DOMAIN.TLD
  Krb5Keytab /etc/apache2/keytab
  KrbLocalUserMapping on
  KrbVerifyKDC on
  KrbServiceName http
  KrbSaveCredentials off

  ## SSL directives
  SSLEngine on
  SSLCertificateFile      "/etc/apache2/ssl/domain.tld.crt"
  SSLCertificateKeyFile   "/etc/apache2/ssl/domain.tld.key"
  SSLProtocol             TLSv1.2
</VirtualHost>

Das geht auch mit Puppet. Als Beispiel stelle ich mein Manifest zur Einrichtung von Puppetboard zur Verfügung. Das kann natürlich nicht einfach out of the box eingesetzt werden, sollte sich aber größtenteils selbst erklären.

Nach einem Neustart von Apache sollte sich mit dieser Konfiguration der Zugang jetzt auf authentifizierte User beschränken. Man erhält aber noch die Passwort-Abfrage. Immerhin sollten dort aber bereits Username und Passwort aus FreeIPA akzeptiert werden.

Achtung: Das Beispiel hier setzt lediglich auf Authentifisierung. Das schließt lediglich den Nachweis der Identität der User ein. Autorisation, also ob die entsprechenden Nutzer dann auch überhaupt berechtigt sind, die Seite zu sehen, wird nicht geprüft. Username und Kennwort können also richtig sein und man wird direkt rein gelassen - eventuell ist das aber nicht für alle User in der FreeIPA-Domäne so gewünscht!

Firefox

Firefox hat für gewöhnlich die Authentifizierung über Kerberos nicht aktiv, immerhin will man sich ja nicht bei jedem Server im Internet erst mal mit Kerberos anzumelden versuchen. Man muss es für gewünschte Domains erst freischalten. Das ist natürlich am einfachsten, wenn man für das Heimnetzwerk eine eigene Domain verwendet.

Folgende Einstellungen sind im Firefox unter about:config vorzunehmen:

network.negotiate-auth.delegation-uris: .domain.tld
network.negotiate-auth.trusted-uris: .domain.tld

Nach einem Neustart von Firefox sollte die Anmeldung auf dem oben konfigurierten vHost kein Passwort mehr erfordern sondern einfach so gehen. Dabei muss aber daran gedacht werden, dass ein ticket granting ticket vorliegen muss, d.h. dass man sich am Rechner als User aus FreeIPA angemeldet hat.

SSH

Die Authentifizierung von Usern ist ebenso möglich, dazu verwenden wir gssapi. Die beteiligten Systeme müssen ωieder alle beide bereits bei FreeIPA im Realm Mitglied sein.

Serverseitig

Auf dem Server muss die Datei /etc/ssh/sshd_config um diese Option ergänzt werden:

GSSAPIAuthentication yes

Weiterhin darf der Zugang zum Server nicht über Host Based Access Control-Regeln verboten sein. Dazu gibt es die entsprechenden Regel-Einstellungen im Frontend von FreeIPA.

SSH-Client

Die Authentifizierung über Kerberos sollte wieder auf eine bestimmte Domain beschränkt werden∵ Dazu kann man in der Datei ~/.ssh/config auch Platzhalter verwenden:

host *.domain.tld
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
    PreferredAuthentications gssapi-with-mic,publickey

Nun sollte man sich per SSH in alle wie oben konfigurierten Server einloggen können, ohne dass zuvor das Passwort eingegeben oder ein öffentlicher Schlüssel auf dem System hinterlegt wurde.