Nextcloud Kerberos Neue Relevanz für alte Authentifizierung

Nextcloud Kerberos: Warum die alte Netzwerk-Authentifizierung in der Cloud neue Relevanz bekommt

Es gibt Momente, da staunt man als Administrator nicht schlecht. Man hat Nextcloud aufgesetzt, die LDAP-Anbindung konfiguriert, die Benutzer aus dem Active Directory importiert – und dann das: Jeder Login erfordert erneut die Eingabe von Benutzername und Passwort. Kein Single Sign-On, kein nahtloses Durchreichen der Windows-Anmeldung. Stattdessen ein klassischer Formular-Login, der in Zeiten von Microsoft 365 und Google Workspace fast schon antiquiert wirkt. Dabei liegt die Lösung seit Jahrzehnten parat: Kerberos. Dass dieses Protokoll aus den 1980er Jahren auch mit Nextcloud harmonieren kann, ist in vielen IT-Abteilungen noch nicht angekommen. Schade eigentlich.

Dabei zeigt sich: Wer einmal eine Kerberos-basierte Authentifizierung für Nextcloud eingerichtet hat, möchte nicht mehr zurück. Die Benutzer melden sich morgens an ihrer Workstation an – und schon sind sie auch in der Cloud-Umgebung authentifiziert. Kein zweites Passwort, keine lästigen Captchas, keine vergessenen Zugangsdaten. Gerade in Unternehmen mit heterogener Infrastruktur ist das ein echter Gewinn. Windows-Clients, Linux-Rechner, Macs – Kerberos funktioniert plattformübergreifend, solange die Uhrzeit stimmt und die DNS-Einträge sauber sind. Zugegeben, das sind zwei entscheidende Fallstricke, aber dazu später mehr.

Nextcloud selbst hat die Zeichen der Zeit erkannt. Die Open-Source-Plattform für Filesharing, Kalender, Kontakte und Kollaboration ist längst kein reiner Dropbox-Klon mehr, sondern eine ernstzunehmende Infrastrukturkomponente. Und in einer solchen Umgebung gehört Kerberos einfach dazu. Die offizielle Nextcloud-Dokumentation beschreibt die Integration zwar knapp, aber ausreichend. In der Praxis hapert es oft an der Abstimmung zwischen Apache-Webserver, PHP-Konfiguration und den Kerberos-Bibliotheken. Ein kleiner Fehler im Keytab, und schon erscheint die lästige Browser-Abfrage nach Benutzername und Passwort, obwohl der Server doch den REMOTE_USER setzen sollte.

Interessant ist die Geschichte hinter Kerberos. Entwickelt am MIT in den 1980ern als Teil des Project Athena, sollte es das unsichere Passwort-basierte Verfahren ablösen. Das Prinzip: Ein vertrauenswürdiger Dritter (der Key Distribution Center, KDC) stellt Tickets aus, die der Benutzer gegenüber einem Dienst vorzeigt. Der Dienst muss nur den öffentlichen Schlüssel des KDC kennen – kein Passwort, keine Klartext-Übertragung. Für viele Sicherheitsexperten ist Kerberos auch heute noch das Nonplusultra, zumindest in lokalen Netzwerken. Dass es auch über HTTP funktioniert, ist dem SPNEGO-Mechanismus zu verdanken, der das Kerberos-Ticket in einen HTTP-Header verpackt. Und genau diesen Mechanismus nutzt die Nextcloud-Integration.

Warum Kerberos und nicht OAuth, SAML oder LDAP?

Eine berechtigte Frage. In den letzten Jahren haben sich OAuth 2.0 und OpenID Connect als Standard für moderne Webanwendungen etabliert. SAML ist in vielen Unternehmen für den Identitätsverbund mit Cloud-Diensten im Einsatz. Warum also auf ein etwas betagtes Protokoll setzen? Die Antwort ist pragmatisch: Weil es in Windows-Domänen bereits vorhanden ist. Der Active Directory Domain Controller ist ein KDC. Jeder Windows-Rechner spricht Kerberos von Haus aus. Warum sollte man also eine zusätzliche Infrastruktur aufbauen, wenn das Protokoll schon auf der Workstation läuft?

Natürlich hat diese Argumentation eine Schwachstelle: mobile Geräte. iPhones, Android-Tablets oder auch Linux-Notebooks, die nicht in der Domäne sind, haben meist kein Kerberos-Ticket. Hier hilft ein Fallback auf die klassische Formular-Authentifizierung. Nextcloud kann das: Wenn der Apache-Server das Ticket nicht validieren kann, weil keines vorhanden ist, wird der Benutzer auf die normale Anmeldeseite weitergeleitet. Das ist kein Beinbruch, aber es bedeutet, dass man nicht auf eine reine Kerberos-Strategie setzen kann, ohne eine Alternative anzubieten. Viele Administratoren kombinieren daher Kerberos mit einer zweiten Methode, etwa LDAP-Passwort oder OAuth für mobile Apps.

Ein interessanter Aspekt ist die Performance. Kerberos-Tickets sind vergleichsweise klein und die Validierung erfolgt lokal auf dem Webserver, sofern der Keytab vorhanden ist. Anders als bei OAuth, wo ein Token bei einem externen Identity Provider überprüft werden muss (was Netzwerk-Latenz einführen kann), läuft die Kerberos-Prüfung asynchron und ohne weiteren Roundtrip. Das macht sich bei vielen gleichzeitigen Anfragen bemerkbar. Gerade Nextcloud, das mit WebDAV eine hohe Anzahl von Filesystem-Operationen erfordert, profitiert von dieser Effizienz. Der Server muss nicht bei jedem HTTP-Request einen neuen Token abholen, sondern kann das Ticket im Kontext des Benutzers lokal auswerten.

Dennoch: Kerberos ist kein Allheilmittel. Die Hürden liegen im Detail. Eine häufige Fehlerquelle ist die Zeit-Synchronisation. Kerberos-Tickets sind zeitgestempelt und verlieren ihre Gültigkeit, wenn die Systemuhren von Client und Server mehr als fünf Minuten voneinander abweichen. Wer also keinen NTP-Dienst im Unternehmen betreibt, wird scheitern. Ebenso kritisch ist die DNS-Konfiguration. Der Client muss den Server unter seinem vollqualifizierten Domainnamen (FQDN) erreichen können, denn der Service Principal Name (SPN) ist an diesen Namen gebunden. Wer Nextcloud hinter einem Reverse Proxy betreibt, muss den SPN auf den externen Namen setzen – andernfalls kommt das Ticket nicht an.

Technische Umsetzung: Das Zusammenspiel von Apache, GSSAPI und Nextcloud

Im Kern geht es darum, den Apache-Webserver so zu konfigurieren, dass er ein Kerberos-Ticket aus dem HTTP-Request extrahiert und die enthaltene Benutzeridentität an die PHP-Umgebung weitergibt. Das geschieht typischerweise mit dem Modul mod_auth_gssapi (früher mod_auth_kerb). Dieses Modul verhandelt mit dem Browser über SPNEGO, entschlüsselt das Ticket mit dem Keytab und setzt die Umgebungsvariable REMOTE_USER. Nextcloud wiederum kann diese Variable auslesen, sofern die Konfiguration entsprechend angepasst ist.

Der erste Schritt ist die Erstellung eines Service Principal Name (SPN) im Active Directory. Dazu muss ein Domänenbenutzerkonto angelegt werden – oft als svc_nextcloud oder nextcloud_sso bezeichnet. Für dieses Konto wird ein SPN registriert, zum Beispiel HTTP/cloud.example.com. Das Konto muss keine speziellen Rechte haben, lediglich der SPN muss eindeutig sein. Anschließend erzeugt man mit ktpass (Windows) oder msktutil (Linux) eine Keytab-Datei, die das Geheimnis enthält. Diese Datei wird auf dem Nextcloud-Server abgelegt, typischerweise mit restriktiven Dateirechten: nur der Apache-Benutzer darf sie lesen.

In der Apache-Konfiguration wird der Virtual-Host für Nextcloud mit folgenden Direktiven ergänzt:

<Location />
  AuthType GSSAPI
  AuthName "Kerberos Login"
  GssapiCredStore keytab:/etc/apache2/nextcloud.keytab
  GssapiAllowedMech krb5
  Require valid-user
</Location>

Das ist die grundlegende Konfiguration. Sie bewirkt, dass der Server bei jeder Anfrage ein Ticket anfordert. Sollte der Client keines senden, wird eine Berechtigungsabfrage erzwungen – was bei Browsern zu einem Popup führt. Das will man vermeiden, wenn auch Clients ohne Kerberos-Zugriff die Seite nutzen sollen. Daher sollte man den Mechanismus so konfigurieren, dass das Fehlen eines Tickets nicht sofort abbricht. Man kann GssapiBasicAuth On setzen, um einen Fallback auf HTTP-Basic-Auth zu erlauben, oder den gesamten Kerberos-Schutz optional gestalten, indem man eine RewriteCond oder Satisfy any-Klausel verwendet. Letzteres ist jedoch fummelig und erfordert gute Kenntnisse der Apache-Direktiven.

Ein eleganterer Weg ist die Verwendung des Nextcloud-internen Authentifizierungsmechanismus. Statt den gesamten Zugriff über Kerberos zu erzwingen, kann man einen speziellen Auth-Endpunkt einrichten. Nextcloud selbst unterstützt seit Version 20 die App „User Kerberos“ (offiziell: kerberos_auth). Diese App fängt den REMOTE_USER in einer frühen Phase der Anfrage ab und führt automatisch eine Login-Session aus, sofern der Benutzer im LDAP existiert. Falls kein REMOTE_USER gesetzt ist, wird die normale Login-Seite angezeigt. Das ist die praktikabelste Lösung, denn sie trennt die Authentifizierung von der Autorisierung und vermeidet die Probleme mit dem Browser-Popup.

Die Installation der App erfolgt über die Nextcloud-Kommandozeile oder den App-Store. Danach muss die config.php um folgende Zeile ergänzt werden:

'user.backends' => [
  'OCA\UserKerberos\Backend',
  'OCA\UserLDAP\User_Proxy',
],

Damit wird Nextcloud angewiesen, zuerst zu prüfen, ob ein Kerberos-Benutzer vorhanden ist, gefolgt von der LDAP-Abfrage. In der Praxis ist es oft umgekehrt: Man möchte zuerst den Kerberos-Mechanismus ausprobieren und dann auf LDAP zurückfallen. Die Reihenfolge spielt eine Rolle, denn wenn der LDAP-Backend zuerst kommt und einen Benutzer ohne Passwort findet, könnte es zu Fehlermeldungen kommen. Ein wenig Trial-and-Error ist hier nicht zu vermeiden.

Praxiserfahrung: Wo es klemmt und wie man es löst

Ich habe selbst einmal die Integration für einen Mittelständler mit rund 200 Benutzern durchgeführt. Der Kunde hatte eine bestehende Nextcloud-Instanz, die über ein LDAP-Proxy von einem AD versorgt wurde. Die Anfrage war: „Wir wollen, dass sich die Leute nicht jedes Mal neu anmelden müssen.“ Also Kerberos. Klingt einfach, war es aber nicht. Der erste Fehler: Der Apache-Server war nicht in der Domäne, sondern stand als Workgroup-Rechner im Netz. Kerberos setzt jedoch voraus, dass Server und Client die gleiche Vertrauensstellung zum KDC haben. Man kann den Server nicht in die Domäne aufnehmen, wenn er kein Windows-Rechner ist? Geht auch ohne. Ein Linux-Client kann den Keytab hinterlegen, ohne in die Domäne eingetreten zu sein. Wichtig ist nur, dass der Server die Keytab-Datei kennt und die KDC (also den Domain-Controller) über DNS finden kann. Das erfordert eine korrekte /etc/krb5.conf.

Der zweite Fehler war der SPN. Der Kunde verwendete eine Subdomain cloud.firma.de, aber der AD-Domänencontroller war unter ad.firma.intern erreichbar. Der SPN muss auf den Namen lauten, den der Browser im Request verwendet – also HTTP/cloud.firma.de. Das ist nicht der interne Hostname des Servers. Wer also einen Reverse Proxy vorschaltet (HAProxy, nginx, etc.), muss den SPN auf den externen Namen setzen. Das klingt logisch, wird aber gerne übersehen. Der Keytab muss dann diesen SPN enthalten. Mit ktpass -princ HTTP/cloud.firma.de@FIRMA.INTERN erstellt man den richtigen Principal. Achten Sie auf die Großschreibung des Realms: Der Realm ist in der Regel der Domainname in Großbuchstaben.

Der dritte Fallstrick war die Apache-Konfiguration. Nextcloud wird häufig mit PHP-FPM betrieben. Dann läuft der Webserver (z.B. Apache) im Proxy-Modus: Er nimmt die Anfrage entgegen, leitet sie an PHP-FPM weiter, und die Antwort wird zurückgegeben. In diesem Fall muss der Apache nicht nur das Kerberos-Ticket auswerten, sondern auch die REMOTE_USER-Variable an den FPM-Prozess übergeben. Das geschieht entweder über SetEnvIf oder mit FastCgiExternalServer-Direktiven. Ohne diese Weitergabe sieht PHP keinen REMOTE_USER, und die Kerberos-App in Nextcloud greift nicht. In meinem Fall musste ich einen kleinen Patch in der Apache-Konfiguration vornehmen: SetEnv REMOTE_USER %{REMOTE_USER}s. Das klingt banal, aber die Dokumentation geht darauf nicht immer ein.

Ein weiteres Ärgernis ist die Browser-Unterstützung. Chrome und Firefox unter Windows senden Kerberos-Tickets automatisch, sofern die Seite in der „Intranetzone“ liegt oder die auth_negotiate-Optionen entsprechend gesetzt sind. Unter macOS ist Safari ebenfalls kooperativ. Linux-Browser wie Firefox können über about:config mit den Einstellungen network.negotiate-auth.trusted-uris konfiguriert werden. Das muss man den Benutzern mitteilen – oder, besser, über Gruppenrichtlinien forcieren. Ohne diese Konfiguration sendet der Browser kein Ticket, und der Benutzer sieht die Login-Seite (weil der Fallback greift). Das ist kein echtes Problem, aber es macht das nahtlose SSO zunichte.

Alternativen und Abgrenzung: LDAP, OAuth, SAML – was ist besser?

Man sollte nicht den Fehler machen, Kerberos als die allein selig machende Lösung zu betrachten. In modernen Cloud-Umgebungen, die über das eigene Rechenzentrum hinausgehen, stoßen Tickets schnell an Grenzen. Kerberos funktioniert nur solange, wie der Client direkt auf den Server zugreifen kann. Hinter einer Firewall oder über das Internet muss man andere Wege gehen. Nextcloud bietet seit einigen Versionen eine native Integration von OpenID Connect (OIDC) an, die mit einem externen Identity Provider (z. B. Keycloak, Authentik, Azure AD) zusammenarbeitet. Das ist für viele Unternehmen die zukunftssicherere Lösung, weil sie hybride Szenarien abdeckt und auch mobile Clients ohne Domänenzugehörigkeit integriert.

Dennoch: Kerberos hat in reinen Intranet-Umgebungen einen unschlagbaren Vorteil: Die Latenz ist minimal, es gibt keine Abhängigkeit von einem externen Dienst, und die Sicherheit ist aufgrund der Ticket-basierten Architektur hoch. Kein Passwort wird über das Netz geschickt – auch nicht als Hash. Das Ticket ist zeitlich begrenzt und kann nur für den spezifischen Dienst verwendet werden. Ein abgefangenes Ticket nützt einem Angreifer wenig, solange er nicht den Keytab des Servers besitzt.

Ein interessanter Aspekt ist die Kombination von Kerberos mit anderen Authentifizierungsmethoden. Nextcloud unterstützt sogenannte „Chained Authentication Backends“. Man kann also Kerberos als primären Mechanismus für Desktop-User nutzen und gleichzeitig LDAP mit Passwort für mobile Nutzer anbieten. In der Praxis muss man dann darauf achten, dass der Benutzer in beiden Backends existiert und die gleiche UID hat. Fehler treten auf, wenn das Kerberos-Ticket einen anderen Benutzer-Principal ausweist als der LDAP-Eintrag (z. B. benutzer@FIRMA.DE vs. FIRMA\benutzer). Hier ist eine saubere Mapping-Tabelle in der LDAP-Konfiguration notwendig. Die Nextcloud-Administration erlaubt es, die LDAP-Attribute flexibel zu mappen, sodass der aus dem Ticket stammende User-Name (der nur den Benutzernamen ohne Domain enthält) mit dem LDAP-Benutzernamen übereinstimmt.

Sicherheit: Was man über Keytabs und Ticket-Management wissen sollte

Ein Keytab ist im Grunde ein Schlüsselbund, der die Geheimnisse der Service-Accounts enthält. Wird er kompromittiert, kann ein Angreifer sich als der Dienst ausgeben und beliebige Benutzer authentifizieren. Das wäre ein GAU. Daher sollte die Keytab-Datei auf dem Server nur für den Prozess lesbar sein, der sie benötigt (also www-data oder apache). Zudem empfiehlt es sich, regelmäßig den zugehörigen Service-Account im AD zu rotieren – das geht mit ktpass -setpass oder msktutil -rotate. Ein weiterer Security-Aspekt: Kerberos schützt vor Passwort-Phishing, aber nicht vor Session-Hijacking, wenn die Verbindung nicht über TLS läuft. Das impliziert: Nextcloud muss zwingend über HTTPS erreichbar sein, sonst kann jemand das Ticket im Klartext abgreifen und replayen. TLS ist also obligatorisch.

Ein weiteres Thema ist die Ticket-Lifetime. Standardmäßig sind Kerberos-Tickets für zehn Stunden gültig. Das bedeutet: Ein Benutzer, der sich morgens anmeldet, ist bis zum Feierabend authentifiziert – auch wenn sein Account im AD deaktiviert wird. Nextcloud führt keine regelmäßige Überprüfung des Account-Status durch, solange die Session gültig ist. Das ist ein relevantes Sicherheitsloch. In der Praxis sollte man die Session-Timeout-Einstellungen von Nextcloud auf einen kürzeren Wert setzen (z. B. 8 Stunden oder weniger) und gleichzeitig die Möglichkeit einer Zwangs-Abmeldung vorsehen. Die Kerberos-App kann so konfiguriert werden, dass sie bei jeder Anfrage prüft, ob das Ticket noch gültig ist. Das ist jedoch mit einem gewissen Overhead verbunden. Eine pragmatische Lösung ist, die Session-Dauer auf die Ticket-Lifetime zu begrenzen und eine erneute Authentifizierung zu erzwingen, sobald das Ticket abläuft.

Nicht zuletzt: Die Sicherheit des gesamten Setups hängt von der Integrität des Domain Controllers ab. Ein Angreifer, der den KDC kompromittiert, kann goldenes Ticket ausstellen und sich als jeder Benutzer ausgeben. Das ist kein Nextcloud-spezifisches Problem, sondern eine fundamentale Schwäche von Kerberos im Allgemeinen. Daher sollte der AD-Server besonders geschützt werden – was man ohnehin tut, oder etwa nicht? Die meisten Unternehmen vernachlässigen die Härtung ihrer Domain Controller. Dabei sind es die Kronjuwelen der Authentifizierung.

Betrieb und Wartung: Was läuft schief – und wie behebt man es?

Der Betrieb einer Kerberos-Integration ist erstaunlich stabil, solange man die Grundlagen nicht vernachlässigt. Die häufigsten Ausfälle sind auf zwei Ursachen zurückzuführen: Änderungen am DNS-Namen des Servers oder eine Rotation des AD-Kontos ohne nachgezogene Keytab. Wenn der SPN geändert wird (etwa weil die Nextcloud-Instanz auf einen anderen Hostnamen umzieht), muss ein neuer SPN registriert und eine neue Keytab erstellt werden. Das vergessen viele. Ebenso stößt man auf Probleme, wenn der NTPService ausfällt. Die Uhren von Client und Server weichen dann ab, und plötzlich funktioniert die Anmeldung nicht mehr. Ein einfacher Befehl ntpq -p auf dem Server gibt Aufschluss.

Ein weiterer Klassiker: Die Kerberos-Erweiterung mod_auth_gssapi benötigt die Bibliothek libgssapi_krb5. Unter Ubuntu/Debian ist das Paket libapache2-mod-auth-gssapi hinreichend. Aber mancher Admin installiert vergessen die Entwickler-Pakete, und das Modul wird nicht geladen. Oder das Modul gibt es nicht für die verwendete Apache-Version. Dann hilft nur, auf mod_auth_kerb zurückzugreifen, das aber seit Jahren nicht mehr maintained wird. Ein heikles Unterfangen. Ich rate daher dringend zu einer aktuellen Distribution, die mod_auth_gssapi unterstützt.

Die Logs sind Ihr Freund. Der Apache-Error-Log (/var/log/apache2/error.log) gibt meist präzise an, warum die GSSAPI-Verhandlung scheitert: „Failed to acquire credentials: No key table entry found“ oder „Ticket not yet valid“. Beide Meldungen deuten auf falsche Keytab-Zuordnung beziehungsweise Zeitprobleme hin. Der Nextcloud-Log wiederum zeigt, ob die Kerberos-App den REMOTE_USER empfangen hat. Aktivieren Sie das Debug-Logging der App, indem Sie die config.php um 'log_level' => 0 ergänzen. Das kann bei der Fehlersuche sehr helfen, sollte aber im Produktivbetrieb wieder zurückgesetzt werden.

Zusammenfassung und Ausblick: Wohin entwickelt sich die Authentifizierung?

Nextcloud hat sich in den letzten Jahren von einer einfachen File-Sharing-Lösung zu einer umfassenden Kollaborationsplattform entwickelt. Der Trend geht zu Hub-Funktionen: Talk, Kalender, Office-Integration. Mit dieser Komplexität steigen auch die Anforderungen an die Identitätsverwaltung. Kerberos allein wird diesen Anforderungen auf Dauer nicht gerecht, vor allem wenn Nextcloud auch außerhalb des Firmennetzes genutzt werden soll.

Dennoch: Für den internen Betrieb, in einer homogenen Windows-Umgebung, ist die Kombination aus Nextcloud und Kerberos ein Traum. Sie reduziert die Passwort-Flaut, erhöht die Akzeptanz bei den Benutzern und entlastet den Helpdesk. Und das mit relativ geringem Aufwand, wenn man die Grundregeln beachtet. Die Open-Source-Philosophie von Nextcloud erlaubt es, genau die Authentifizierungsmethode zu wählen, die zum Unternehmen passt – ohne Lizenzkosten, ohne Vendor-Lock-in. Das ist der eigentliche Trumpf.

Einige Nextcloud-Entwickler arbeiten daran, die Integration von Kerberos weiter zu vereinfachen. Die App user_kerberos wird aktiv maintained, und die Dokumentation wird nach und nach verbessert. Aber wie so oft bei Open-Source: Die Community lebt vom Mitmachen. Wer einen guten Workaround für ein Problem hat, sollte ihn teilen. Denn die meisten Admins stehen vor den gleichen Hürden – und es gibt nichts Besseres als einen praxiserprobten Tipp aus erster Hand.

Also: Wenn Sie Nextcloud betreiben und Ihren Benutzern das lästige Passwort-Eingeben ersparen wollen, geben Sie Kerberos eine Chance. Es ist nicht die modernste Methode, aber eine der stabilsten und sichersten, die in der lokalen Netzwerkumgebung verfügbar ist. Und mit den hier beschriebenen Hinweisen sollte die Integration auch ohne stundenlange Fehlersuche gelingen. Zumindest fast. Denn ganz ohne Überraschungen läuft es dann doch nie – das gehört zum Handwerk des Admins dazu. Aber das wissen Sie ja schon.

Kleiner Tipp zum Schluss: Testen Sie die Konfiguration zunächst mit einem dedizierten Browser-Profil, in dem Sie die Kerberos-Einstellungen vornehmen. So vermeiden Sie, dass Ihr Haupt-Browser bei einem Fehler in eine Endlos-Schleife gerät. Einmal erlebt, nie wieder vergessen.