Möchte sich ein Benutzer mittels Kerberos an einem System anmelden, ist hierfür eine Kommunikation mit einem Key-Distribution-Center (KDC) über den UDP/TCP-Port 88 notwendig. Der Zugriff auf diesen Port aus fremden Netzwerken wird jedoch in den meisten Fällen durch die Firmenfirewall unterbunden. Somit können Benutzer also nur innerhalb des Firmennetzwerkes mit dem KDC kommunizieren, um die notwendigen Kerberos-Tickets anzufordern, die für eine erfolgreiche Authentifizierung notwendig sind.

Üblicherweise benötigt der Benutzer zuerst ein sogenanntes Ticket Granting Ticket (TGT), um seine eigene Identität gegenüber dem KDC zu bestätigen, und zusätzlich ein Service-Ticket (ST), sobald der Benutzer auf einen Kerberos-Service zugreifen möchte. Die Authentifizierung gegenüber diesem Service läuft für den Benutzer vollkommen transparent ab, ohne dass hierfür die erneute Eingabe des Benutzerpassworts notwendig ist. Wer sich näher in das Kerberos-Protokoll einlesen möchte, dem sei an dieser Stelle RFC 4120 [1] als Lektüre empfohlen.

Kerberos-Authentifizierung von extern

Es wäre jedoch wünschenswert, dass auch Benutzer aus externen Netzwerken sich über Kerberos authentisieren dürfen, ohne dass hierfür ein direkter Zugang zum Firmen-Netzwerk notwendig ist. Tatsächlich existiert schon seit einigen Jahren eine Lösung für dieses Problem. So hat Microsoft bereits im Jahre 2011 eine Spezifikation für das Kerberos-Key-Distribution-Center-Proxy-Protocol (MS-KKDCP) veröffentlicht [2]. Sie sieht vor, dass in dem Kommunikationspfad zwischen Benutzer und Kerberos-Server ein Proxy eingebaut wird. Der Benutzer tauscht hierbei Nachrichten über das HTTPS-Protokoll mit dem Proxy aus, der sie an einen entsprechenden Kerberos-Server im Backend weiterleitet.

Das Bild auf der rechten Seite zeigt den beispielhaften Ablauf einer Sitzung, bei der ein Benutzer über einen TLS-Kanal mit dem Proxy kommuniziert. Der Proxy übersetzt hier die entsprechenden Anweisungen des Clients und leitet sie an das KDC weiter. Um beispielsweise ein TGT anzufordern, ist eine KRB_AS_REQ-Nachricht an den Authentication-Server des KDC zu senden; ein Service-Ticket erfordert eine KRB_ TGS_REQ-Nachricht an den Ticket-Granting-Server. Entsprechende Antworten des KDC gelangen dann wiederum über den TLS-Kanal zurück an den Client. Wie in Bild 1 zu erkennen ist, sind auch Änderungen des Passwortes mittels einer KRB_CHG_ PWD_REQ-Nachricht möglich.

WSGIDaemonProcess kdcproxy processes=2 threads=15 maximum-requests=1000 display-name=%{GROUP}
WSGIImportScript /usr/lib/python2.7/site-packages/kdcproxy/__init__.py process-group=kdcproxy application-group=kdcproxy
WSGIScriptAlias /KdcProxy /usr/lib/python2.7/site-packages/kdcproxy/__init__.py
WSGIScriptReloading Off
<Location "/KdcProxy">
      Satisfy Any
      Order Deny,Allow
      Allow from all
      WSGIProcessGroup kdcproxy
      WSGIApplicationGroup kdcproxy
</Location>

Zwar unterstützt MIT-Kerberos in aktuellen Versionen ebenfalls das KKDCP-Protokoll [3], bietet hierfür jedoch keine eigene Server-Implementierung an. Eine solche steht unter [4] als WSGI-Modul zur Verfügung und kann somit zusammen mit beliebigen WSGI-kompatiblen Webservern zum Einsatz kommen. Listing 1 zeigt eine beispielhafte Konfiguration für den Apache-Webserver. In Listing 2 ist die Kerberos-Client-Konfiguration zu sehen. Darin wird die Adresse des Kerberos-Proxy hinterlegt.

# In der Kerberos-Konfigurationsdatei ist statt des Kerberos-Servers nun der Kerberos-Proxy einzutragen.
[realms]
   EXAMPLE.COM = {
     http_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
     kdc = https://account.example.com/KdcProxy
     kpasswd_server = https://account.example.com/KdcProxy
}

Trust Store definieren

Um das X.509-Zertifikat des Webservers verifizieren zu können, ist außerdem anzugeben, an welcher Stelle sich der X.509-Truststore auf dem System befindet. Wird nun das Tool kinit aufgerufen, sollte es eine Anfrage an den Kerberos-Proxy stellen, statt direkt auf den Kerberos-Server zuzugreifen. Sollte es nicht auf Anhieb funktionieren, lassen sich mittels der Variable KRB5_TRACE hilfreiche Debug-Meldungen auf dem Bildschirm ausgeben (siehe Listing 3).

# Der Trace zeigt: Die Kommunikation läuft über den Proxy statt des Kerberos-Servers
KRB5_TRACE=/dev/stdout kinit foobar
[1037] 1431509096.26305: Getting initial credentials for foobar@EXAMPLE.COM
[1037] 1431509096.26669: Sending request (169 bytes) to EXAMPLE.COM
[1037] 1431509096.26939: Resolving hostname accounts.example.com
[1037] 1431509096.34377: TLS certificate name matched "accounts.example.com"
[1037] 1431509096.38791: Sending HTTPS request to https 128.66.0.1:443
[1037] 1431509096.46387: Received answer (344 bytes) from https 128.66.0.1:443
[1037] 1431509096.46411: Terminating TCP connection to https 128.66.0.1:443

An dieser Stelle sei auch erwähnt, dass der Kerberos-Proxy bereits standardmäßig in dem Identity-Management-Framework FreeIPA zum Einsatz kommt. Der FreeIPA-Server verfügt bereits über die notwendige Konfiguration, damit Clients mit einem Kerberos-Proxy kommunizieren können.

Kerberos-Infos im DNS

In Listing 2 wurde eine statische Konfiguration des Clients vorgestellt. Üblicherweise ist es aber so, dass ein Client diese Informationen dynamisch mit Hilfe von DNS Service Records ermittelt. Hierfür sind diese Informationen dann natürlich als SRV Ressource Records im DNS zu hinterlegen. Im RFC 4120 [1] ist dieser Vorgang im Abschnitt 7.2.3.2. (Specifying KDC Location Information with DNS SRV records) genau beschrieben. Ein KDC Proxy Ressource Record könnte somit also wie folgt aussehen:

_kerberos.example.com. IN URI 0 100 "krb5srv:M:kkdcp:https://accounts.example.com/KdcProxy"

Weitere Informationen zur Kerberos Service Discovery finden sich auch auf den Kerberos-Projektseiten des MIT [6]. Ehrlicherweise muss man zugeben, dass der aktuelle RFC etwas veraltet ist und eine Vielzahl von DNS Ressource Records benötigt, wenn es um die dynamische Verteilung von Kerberos-Server-, Proxy- und Realm-Infomationen mittels DNS geht. Daher steht unter [7] bereits ein Draft zum Update von RFC 4120 zur Verfügung, um den ganzen Prozess zu vereinfachen. Dieser wurde der IETF bereits vorgeschlagen, aber noch nicht offiziell akzeptiert.

Fazit

Kerberos ist ein Protokoll, das primär in internen Netzwerken zum Einsatz kommt, um die Authentifizierung sicherer zu gestalten. Der Zugang zu einem Kerberos-Server aus externen Netzen ist in den allermeisten Fällen jedoch nicht möglich. Damit Benutzer aus fremden Netzwerken trotzdem mit einem KDC kommunizieren können, lässt sich ein Proxy einsetzen. Mit Hilfe von DNS Ressource Records lässt sich die Adresse des Proxy auch dynamisch ermitteln, sodass Clients nicht zwingend mit einer statischen Konfiguration zu versehen sind.

(of) Aus dem IT-Administrator Magazin Ausgabe 1/2018: Softwareverteilung & Patchmanagement Seite 58-59