External User Management in Nextcloud: Von Verzeichnisdiensten bis zu Gastkonten

Nextcloud ist ein Chamäleon. Je nach Einsatzzweck begegnet man der Plattform als privatem Fileserver, als Firmen-Intranet oder als eingebettetem Baustein einer komplexen Identity-Landschaft. In vielen Projekten, die ich begleite, steht am Anfang eine unscheinbare Frage: Woher kommen eigentlich die Benutzer? Und was passiert mit denen, die nicht ins eigene Active Directory passen? Genau darum soll es hier gehen – um das External User Management in Nextcloud, also die Kunst, Benutzer von außen an die Plattform anzubinden und dabei nicht die Kontrolle zu verlieren.

Das Thema ist präsenter, als die meisten denken. Sobald eine Nextcloud-Instanz über ein paar Testkonten hinauswächst, kollidiert das eigene Benutzerverzeichnis mit betrieblichen Realitäten. Wer eine Firma mit 500 Mitarbeitern abbilden soll, kann nicht einfach neben jedem Account auch noch die E-Mail-Adresse händisch pflegen. Wer mit externen Beratern oder Kundenprojekten arbeitet, will nicht für jeden Gast ein vollwertiges Konto mit Passwort anlegen. Und wer ein zentrales Identity-Management im Unternehmen betreibt, erwartet, dass sich Nextcloud sauber daran anschließt. Genau diese Erwartungen führen zu den verschiedensten Lösungswegen – von LDAP über SAML und OIDC bis hin zu temporären Gastkonten.

Der Baukasten: Benutzer-Backends und ihre Eigenheiten

Nextcloud ist in dieser Hinsicht erfreulich modular aufgebaut. Die Benutzerverwaltung ist nicht ein monolithischer Block, sondern eine Reihe von Backends, die nacheinander abgefragt werden können. Wer sich schon einmal durch die Datei config/config.php gewühlt hat, findet dort Einträge wie „ldap“ oder „user_saml“. Jedes Backend kann prinzipiell eine eigene Benutzerquelle anzapfen. Das System fragt sie in einer definierten Reihenfolge ab, bis es einen passenden Benutzer gefunden hat. Das ist mächtig, sorgt aber auch dafür, dass es zu Namenskonflikten kommen kann, wenn ein Benutzer im AD und ein gleichnamiger in der lokalen Datenbank existiert. Dieses Phänomen wird oft unterschätzt. In der Praxis sollte man klare Präfixe oder eine strikte Trennung der Backends festlegen – etwa, indem lokale Konten nur für Administrationszwecke vorgesehen sind.

Die wichtigste Unterscheidung ist die zwischen authentifizierenden und rein synchronisierenden Backends. LDAP und die externe Benutzerliste übernehmen die Authentifizierung, während die User Provisioning API eher dazu dient, Benutzerkonten automatisiert anzulegen. SAML und OIDC sind dagegen reine SSO-Verfahren: Die Nextcloud-Instanz selbst bekommt das Passwort nie zu Gesicht, sondern verlässt sich auf die Zusicherung des Identity Providers. Dieser Unterschied ist nicht nur akademisch, sondern hat direkte Auswirkungen auf die Sicherheit. Wenn ein SSO-Provider ausfällt, ist auch die Nextcloud-Instanz nicht mehr erreichbar. Bei LDAP sieht es nicht viel besser aus, aber manche Admins haben etwas mehr Gestaltungsspielraum.

LDAP und Active Directory: das Fundament der meisten Installationen

Die mit Abstand häufigste Anbindung für externe Benutzer ist nach wie vor LDAP. Das liegt nicht nur an der weiten Verbreitung von Microsoft Active Directory, sondern auch daran, dass sich LDAP-Dienste wie OpenLDAP oder 389 Directory Server seit Jahrzehnten als Standard für Unternehmensverzeichnisse etabliert haben. Nextcloud bringt für die Anbindung eine eigene App mit, die sich im Administratorbereich unter dem Punkt „LDAP/AD-Integration“ versteckt. Die Einrichtung ist grundsätzlich geführt, aber die Menge an Feldern kann am Anfang erdrücken. Bind-DN, Base-DN, User-Objektklassen, Filter-Optionen, Mapping-Attribute – wer nicht täglich mit Verzeichnisdiensten arbeitet, wird schnell unsicher.

Dabei zeigt sich, dass eine saubere Vorbereitung im Verzeichnis die halbe Miete ist. Wer im Active Directory eine Ordnerstruktur hat, bei der Mitarbeiter über mehrere Organisationseinheiten verteilt sind, muss die Base-DN und Filter zunächst genau prüfen. Ansonsten sieht Nextcloud nur einen Teil der Belegschaft. Eine typische Konfiguration sieht so aus, dass man als Base-DN die gesamte Domäne angibt, etwa dc=firma,dc=de, und dann per Suchfilter die relevanten Objektklassen einschränkt, zum Beispiel (&(objectClass=user)(objectClass=person)).

Ein interessanter Aspekt ist die Zuordnung von Nextcloud-Benutzerkonten zu den LDAP-Benutzern. Die App erlaubt es, festzulegen, welches Attribut in Nextcloud als Benutzername dienen soll – meistens der UserPrincipalName oder die sAMAccountName. Daran hängt mehr, als man denkt. Wenn sich später einmal der Anzeigename oder die E-Mail-Adresse ändert, bleibt die Benutzer-ID stabil, solange das gewählte Attribut unverändert bleibt. Wer hingegen leichtfertig die Mail-Adresse als ID verwendet, darf sich nicht wundern, wenn eine Heirat oder eine Umbenennung im AD zu einem scheinbar neuen Benutzer führt. Die alten Dateien bleiben dann am alten Konto hängen. Solche Probleme lassen sich hinterher nur mit erheblichem Aufwand reparieren.

Hinzu kommt die Gruppenfrage. Nextcloud kennt eigene Gruppen und Gruppen, die aus dem Verzeichnis synchronisiert werden. Für die Zusammenarbeit ist das ein Segen, weil sich Berechtigungen zentral im AD pflegen lassen. Aber es führt auch zu Verwirrung, wenn die lokale Gruppe „Marketing“ in Nextcloud und eine synchronisierte Gruppe „marketing“ aus dem AD parallel existieren. Ich habe schon Installationen gesehen, in denen Benutzer plötzlich doppelt oder gar nicht in den Berechtigungen auftauchten, weil die Fallstricke bei Groß-/Kleinschreibung und bei der eindeutigen Identifizierung der Gruppen nicht beachtet wurden.

Ein weiterer Punkt ist die Frage der Quota. Nextcloud kann die Speicherplatzkontingente je Benutzer festlegen. Diese Quota lässt sich auch aus einem benutzerdefinierten LDAP-Attribut lesen. In vielen Active-Directory-Umgebungen wird dafür das Attribut „extensionAttribute“ verwendet oder ein eigenes Schema nachgerüstet. Das klingt nach einem netten Gimmick, ist aber in Projekten oft der Knackpunkt. Wenn die Quota nicht stimmt, weil das Attribut falsch gemappt oder nicht gepflegt ist, haben die Benutzer entweder überhaupt keinen Speicher oder einen unbegrenzten. Auch das gehört zum External User Management dazu: Wer Benutzer von außen anbindet, muss sich um die Metadaten kümmern, nicht nur um die Anmeldung.

Gruppen-Synchronisation und der Blick ins Active Directory

Die Gruppen-Synchronisation ist eines der mächtigsten Features der LDAP-Integration. Mit aktiviertem Group-Loading lassen sich Verzeichnisgruppen automatisch in Nextcloud abbilden. Das ist vor allem für größere Organisationen wichtig, weil Berechtigungen nicht für einzelne Personen, sondern für Rollen vergeben werden. Ein Beispiel: Eine Firma hat im AD eine Gruppe „projekt-alpha“, in der alle Mitarbeiter des Projekts eingetragen sind. In Nextcloud wird dieser Gruppe dann ein freigegebener Ordner zugewiesen. Wechselt ein Mitarbeiter das Projekt, genügt die Pflege im AD, und die Zugriffsrechte in Nextcloud passen sich automatisch an.

Aber Achtung: Die Synchronisation ist nicht dasselbe wie eine Live-Verbindung. Nextcloud cached die Gruppen und Benutzer in einer lokalen Datenbank, die in bestimmten Intervallen aktualisiert wird. Das ist auch gut so, weil sonst jede Anfrage das Verzeichnis belasten würde. Allerdings führt es gelegentlich zu bösen Überraschungen: Ein Benutzer, der im AD deaktiviert oder gelöscht wird, kann in Nextcloud noch eine Weile weiter existieren – je nach Konfiguration und Cache-Laufzeit. Und die Dateien, die er angelegt hat, bleiben in der Datenablage. Genau das führt in der Praxis zu der Frage: Wer darf die Daten eines ausscheidenden Mitarbeiters sehen und wem werden sie übertragen? Nextcloud hat dafür zwar eine Lösung, aber sie muss konfiguriert werden. Man sollte wissen, was mit den Daten passiert, wenn ein externer Benutzer nicht mehr vorhanden ist.

Nextcloud Enterprise bietet übrigens die Möglichkeit, Verzeichnis-Benutzer direkt aus Nextcloud heraus anzulegen – der sogenannte LDAP Write Support. Damit kann ein Admin einen neuen Mitarbeiter in der Nextcloud-Oberfläche anlegen und die Daten werden tatsächlich im Active Directory gespeichert. Das ist für viele Unternehmen ein entscheidender Vorteil, weil es den Verwaltungsaufwand reduziert. Allerdings setzt es ein sauberes Berechtigungskonzept in der Nextcloud voraus, nicht jeder Benutzer soll schließlich globale Schreibrechte im Directory haben.

Der Wechsel zu SSO: SAML und OpenID Connect

Wer einmal mit einem Identity Provider gearbeitet hat, möchte nicht zurück. Die Vorteile liegen auf der Hand: Ein zentraler Login für alle Anwendungen, kein Passwort-Wirrwarr, wenig Druck auf dem Passwort-Manager der Benutzer. Nextcloud kann als Service Provider angebunden werden, sowohl per SAML als auch per OpenID Connect. SAML ist dabei der erfahrenere Veteran, OpenID Connect die modernere Variante, die auf OAuth 2.0 aufbaut und besonders im Web-Umfeld und bei vielen Identity-Providern wie Keycloak, Authentik oder Entra ID (ehemals Azure AD) eine große Rolle spielt.

In der Praxis heißt das: Ein Benutzer öffnet die Nextcloud-URL und wird automatisch auf den Identity Provider umgeleitet. Dieser authentifiziert ihn und schickt ihn mit einem Token oder einer Assertion zurück. Nextcloud prüft diese Daten, liest die gewünschten Attribute wie Vor- und Nachname, E-Mail und Gruppen aus und erstellt daraus das Benutzerkonto. Geschieht dies automatisch beim ersten Login, spricht man von Just-in-Time-Provisioning. Das Besondere daran: Die Benutzer müssen nicht vorab in Nextcloud angelegt werden, sie werden bei der ersten Anmeldung gewissermaßen geboren.

Das bringt ordentlich Komfort, hat aber eine Kehrseite: Wenn die Zuordnung der Gruppen nicht sauber konfiguriert ist, bekommen alle Benutzer im Zweifel die gleichen Berechtigungen – oder gar keine. Und weil die Attribute vom Identity Provider abhängen, muss man sich sehr genau mit deren Mapping auseinandersetzen. Ein typisches Problem ist die Gruppe als solche. Während LDAP-Gruppen klar definierte Einträge sind, liefert OIDC in der Regel einen Anspruch (Claim) mit, der eine Liste von Gruppennamen enthält. Diese Liste muss mit den Nextcloud-Gruppen abgeglichen werden. Bei Keycloak lässt sich das über sogenannte Mapper einstellen, aber die Syntax ist nicht überall gleich. Einsteiger scheitern dann schnell an dem Punkt, an dem Nextcloud die Gruppen zwar im Token sieht, aber nicht zuordnen kann.

SAML ist ähnlich gelagert. Über das SAML-Attribut kann der Identity Provider Gruppen mitteilen, und in der Nextcloud-App „user_saml“ lassen sich diese Attribute auf Nextcloud-Gruppen abbilden. Was ich an SAML immer wieder schätze, ist die große Verbreitung im Hochschulbereich. Viele Universitäten betreiben einen Shibboleth-Dienst, und für die Anbindung von Nextcloud gibt es dort etablierte Konfigurationsmuster. Der Standard ist ausgereift, aber nicht mehr durchgehend zeitgemäß, was die Bedienbarkeit angeht – etwa bei der Rückkehr aus der Session, wenn die Nextcloud-Instanz den Logout nicht an den Identity Provider weitergibt. Das führt dann dazu, dass ein Benutzer sich an der Uni abmeldet, aber die Nextcloud-Session noch offen bleibt, bis die Anmeldefrist abläuft. Solche Dinge sind nicht tragisch, aber sie zeigen, wie viel Detailliebe in der Integration steckt.

Der Identity Provider als Dreh- und Angelpunkt

Interessant wird es, wenn man sich das Zusammenspiel aus Identity Provider und Nextcloud genauer ansieht. Ein Identity Provider wie Keycloak ist nicht nur ein Login-Dienst, sondern eine eigene kleine Infrastruktur. Er übernimmt die Benutzerverwaltung, möglicherweise mit einer Datenbank im Hintergrund, und er kann diese Benutzer wiederum aus anderen Quellen beziehen – etwa aus LDAP oder Microsoft Entra ID. In einer solchen Kaskade wird Nextcloud zu einem reinen Consumer, der selbst keine Benutzer mehr besitzt. Das entlastet die Plattform, macht sie aber auch abhängig von der Verfügbarkeit und vor allem von der Korrektheit der Attribut-Zuordnung.

Ein Beispiel: Ein mittelständisches IT-Unternehmen setzt Keycloak ein, um den Zugang zu einem Kundenportal zu steuern. In Keycloak sind die Kunden als externe Benutzer angelegt, mit einer Gruppe, die ihr jeweiliges Projekt bezeichnet. Diese Gruppe wird per Mapper in den OIDC-Token geschrieben. Nextcloud wiederum liest diesen Token und weist den Benutzer der entsprechenden lokalen Gruppe zu. Für einen Ordner, der die Projektdokumente enthält, ist dann nur die Gruppe berechtigt. Klingt rund. Aber wehe, jemand ändert den Namen der Keycloak-Gruppe. Dann taucht der Benutzer in Nextcloud unter einer neuen Gruppe auf, und die Zugriffsrechte auf den Ordner sind weg. Solche Probleme lassen sich vermeiden, wenn man in Nextcloud nicht die Anzeigenamen, sondern Gruppen-IDs verwendet, sofern das die App unterstützt.

Ein anderer Aspekt ist die Sicherheit der Token. OIDC-Tokens haben ein Verfallsdatum, und Nextcloud speichert die Session, bis der Benutzer sich abmeldet. Was passiert, wenn ein externer Benutzer in Keycloak deaktiviert wird? Die bestehende Nextcloud-Session bleibt unter Umständen bis zum Ende ihrer Lebensdauer aktiv. Das ist ein Sicherheitsrisiko, das in Administrationsrunden oft zu spät diskutiert wird. Wer hier strikt sein will, muss die Session-Lifetime in Nextcloud eng begrenzen und den Identity Provider regelmäßig prüfen lassen. Man kann sich durchaus fragen, ob die Plattform hier nicht mehr tun sollte, um externe Sessions im laufenden Betrieb zu beenden. Aber so weit sind die meisten Produkte eben noch nicht.

Die App „External User Management“ und ihre Verwandten

Nun zum konkreten Thema, das im Nextcloud-Umfeld manchmal unter dem Namen „External User Management“ auftaucht. Tatsächlich gibt es eine App mit diesem Namen beziehungsweise mit der Kennung „user_external“, die in der Anfangszeit von Nextcloud entwickelt wurde. Mit ihr lässt sich eine einfache Tabelle im externen Benutzerverzeichnis hinterlegen, gegen die sich Benutzer anmelden können. Ähnlich funktioniert das Anlegen von Benutzern über eine CSV-Datei, nur ist die Tabelle eben keine Nextcloud-Tabelle, sondern eine externe Quelle. Die App ist gewissermaßen ein Relikt – aber ein nützliches.

Ich will ehrlich sein: In aktuellen Projekten spielt sie nur noch selten eine Hauptrolle. Wer ein Active Directory hat, ist mit der LDAP-Integration deutlich besser beraten. Wer eine moderne Single-Sign-on-Landschaft betreibt, für den sind SAML oder OIDC die erste Wahl. Die App für die externe Benutzerverwaltung ist dann sinnvoll, wenn es eine kleine Anwendung gibt, die eine eigene Benutzerdatenbank mitbringt, und man diese ohne viel Aufwand an Nextcloud anbinden möchte. Ein Beispiel: Ein kleines Support-Tool speichert seine Kunden in einer MySQL-Datenbank mit einem Benutzernamen und einem Passwort-Hash. Über ein PHP-Skript und die App kann man diese Datenbank quasi als LDAP-Ersatz verwenden. Das erspart den Aufbau einer vollständigen Verzeichnisinfrastruktur.

Allerdings hat die App ihre Tücken. Sie unterstützt keine Gruppen, keine Quotas und keine Attribute. Man kann mit ihr also nicht abbilden, welche Abteilung ein Benutzer hat oder ob er 10 Gigabyte oder 100 Gigabyte Speicherplatz erhält. Auch die Passwort-Hashes müssen in einem Format vorliegen, das die App verarbeitet. Das führt dann dazu, dass man für die Pflege der Benutzerdaten wieder eine eigene Anwendung schreiben muss. Und da frage ich mich: Warum dann nicht gleich LDAP? Die Antwort ist manchmal einfach: Weil es in der jeweiligen Umgebung kein LDAP gibt und eine neue und zentrale Benutzerverwaltung nicht in Aussicht steht. In solchen Nischen hat die App durchaus ihre Daseinsberechtigung.

Daneben gibt es noch die „Guest Accounts“-App, die bereits offiziell in Nextcloud integriert ist. Mit ihr lassen sich externe Personen als Gäste einladen. Das ist die unkomplizierteste Art des External User Management. Ein Gast erhält eine Einladung per E-Mail, legt sich ein Passwort an und hat Zugriff auf die für ihn freigegebenen Ordner. Er ist aber kein regulärer Benutzer – zumindest nicht, wenn man das System sauber konfiguriert hat.

Gäste und Partner: die leichte Münze des Zugriffs

Gastkonten sind in der Praxis ein Segen. Ich kenne kaum eine Nextcloud-Installation in einem Unternehmen, die nicht irgendwann externe Berater oder Kunden mit in die Plattform holen muss. Dabei geht es oft nicht um große Projektteams, sondern um einzelne Personen, die eine Datei austauschen oder an einer Besprechungsnotiz arbeiten sollen. Gastkonten sind genau dafür gemacht. Man gibt einen Namen und eine E-Mail-Adresse ein, Nextcloud erzeugt eine Einladung, und der Gast legt ein Passwort fest. Die Rechte an den freigegebenen Ordnern lassen sich anschließend über Gruppen von Gastkonten verwalten, wobei die App „Guest Accounts“ in den aktuellen Versionen sehr viel komfortabler geworden ist. So können auch mehrere Gäste gemeinsam an einer Freigabe arbeiten, ohne dass sie sich gegenseitig sehen müssen.

Ein interessanter Aspekt ist die Trennung zwischen „Gast“ und „normalem Benutzer“. Nextcloud gibt Gastkonten ein eigenes Label, und im Verzeichnis erscheinen sie nicht unter den aktiven Benutzerkonten. Das hält die Benutzerliste sauber, was man von externen Konten aus LDAP nicht behaupten kann. Der schöne Nebeneffekt: Ein Gastkonto kann nicht zum Administrieren verwendet werden, und es wird nicht in die Benutzersuche einbezogen, außer der Admin gibt es frei. Ich rate trotzdem dazu, Gastkonten regelmäßig zu prüfen und zu deaktivieren, sobald sie nicht mehr gebraucht werden. Sonst sammeln sich mit der Zeit Berge von weggefallenen Zugängen an, und das ist ein Sicherheitsproblem, das niemand wirklich kontrollieren kann.

Und dann gibt es noch die föderierte Cloud. Nextcloud kann per standardisiertem Protokoll, dem sogenannten Federation Sharing, Ordner mit Benutzern auf einer anderen Nextcloud-Instanz teilen. Der Empfänger braucht kein Konto in der eigenen Instanz, er nutzt sein Konto bei seinem eigenen Anbieter. Das ist eine Art des External User Management, die ganz ohne lokale Benutzer auskommt. Praktisch für den Austausch zwischen zwei Organisationen, die beide Nextcloud betreiben. Aber Achtung: Die föderierte Freigabe führt zu einem gewissen Vertrauensverhältnis zwischen den Administratoren der beiden Instanzen. Man sollte das nicht unbedacht öffnen.

Die User Provisioning API für Automatisierung

Wenn externe Benutzer erst einmal prinzipiell angebunden sind, stellt sich schnell die Frage nach der Automatisierung. Schließlich will niemand händisch Benutzer in Nextcloud anlegen, nur weil sie im Active Directory bereits vorhanden sind. Die LDAP-Integration erledigt einen Teil davon, aber für andere Szenarien bietet Nextcloud die User Provisioning API an – eine einfache HTTP-Schnittstelle, die auf dem OCS-Standard basiert. Damit lassen sich Benutzer anlegen, bearbeiten und löschen, Gruppen zuweisen oder Quotas setzen. Viele Administrationstools nutzen diese API, und in Skripten ist sie ein unverzichtbares Werkzeug, wenn es darum geht, Benutzer aus externen Systemen zu synchronisieren.

Die API ist dokumentiert und benötigt lediglich einen Benutzer mit Administratorrechten. Alles läuft über REST, und die Antworten kommen als XML oder JSON. Das macht sie für Programmierer zugänglich. Ich habe zum Beispiel schon einmal ein PowerShell-Skript gesehen, das alle Benutzer aus einem CRM-System ausliest und per API in Nextcloud als Gäste anlegt. Ähnlich kann man mit einer CSV-Datei verfahren. Wenn man die API mit einer Webhook-Geschichte verbindet, ergeben sich tolle Möglichkeiten.

Kritisch ist jedoch die Fehlerbehandlung. Wenn die API einen bestehenden Benutzer abgleichen soll, muss man aufpassen, dass man nicht versehentlich Daten überschreibt. Es gibt kein eindeutiges „Upsert“-Verfahren, sondern lediglich getrennte Methoden zum Erstellen und Bearbeiten. Man sollte also erst prüfen, ob der Benutzer existiert, und dann entscheiden, ob ein Update nötig ist. Das macht Skripte etwas sperrig, ist aber kein Hexenwerk. Wer die API nutzt, sollte außerdem bedenken, dass sie nicht per OAuth 2.0 abgesichert ist, sondern mit passwortbasierten App-Passwörtern für den Admin arbeitet. Das ist ein Sicherheitsrisiko, wenn die Skripte in ungeschützten Umgebungen laufen. Ein kleines Tool, das nur die API aufruft, sollte niemals mit einem Admin-Passwort im Skript stehen, sondern mit einem speziell angelegten Admin-Benutzer, der nur die nötigen Rechte hat.

Die größten Stolperfallen in der Praxis

Wer sich durch die Welten von LDAP, SAML und Gastkonten arbeitet, stolpert über die immer gleichen Probleme. Das erste ist die Umlaufzeit von Änderungen. In Nextcloud werden Benutzerdaten und Gruppenzugehörigkeiten aus externen Quellen gecacht. Die Standardwerte sind für viele Umgebungen in Ordnung, aber in dynamischen Projekten kann es passieren, dass ein neuer Mitarbeiter erst nach einer halben Stunde auf die Freigabe zugreifen kann. Das sorgt für Unruhe, gerade wenn man mit Release-Deadlines zu kämpfen hat. Lösung: Die Caching-Intervalle gezielt anpassen, aber eben nicht so weit herunterschrauben, dass das LDAP unter der Last zusammenbricht.

Das zweite Problem sind die Dateisystem-Berechtigungen. Nextcloud speichert die Benutzerdateien in Verzeichnissen unterhalb von data. Diese Verzeichnisse heißen in der Regel nach der Benutzer-ID. Wenn man externe Benutzer aus einem LDAP anbindet und dort als Benutzername den UserPrincipalName verwendet, dann kann das zu sehr langen Verzeichnisnamen führen – mit einem Punkt und einem Domain-Suffix. Das ist technisch unkritisch, aber es sieht seltsam aus und nervt beim Debuggen. Wer schon einmal versucht hat, einem externen Dienstleister den Pfad zu einer Benutzerdatei zu nennen, versteht, was ich meine. Schöner ist da der sAMAccount-Name, also ohne Domain. Aber das ist eine Entscheidung, die man am Anfang treffen sollte.

Der dritte Klassiker ist die Verwaltung von Berechtigungen. Nextclouds Berechtigungsmanagement ist stark an das Konzept von Freigaben gebunden. Benutzer, die über einen externen Identity Provider ankommen, haben zunächst keine eigenen Freigaben, es sei denn, der Admin hat sie eingerichtet. Wenn dann ein Gruppen-Sync nicht richtig funktioniert, sehen die Benutzer plötzlich nur ihre eigenen Dateien und keinen einzigen gemeinsamen Ordner. Man sollte also den Gruppen-Sync früh testen und die Benutzer in der Nextcloud-Benutzerverwaltung unter die Lupe nehmen, um zu sehen, ob die Gruppen wirklich da sind. Dabei zeigt sich auch, welche Benutzer doppelt existieren – etwas, das gerne ignoriert wird, bis jemand ein Problem meldet.

Ein vierter Punkt ist die Frage nach der E-Mail-Adresse. Nextcloud nutzt die E-Mail für Benachrichtigungen, Passwort-Rücksetzungen und Freigabelinks. Wenn die E-Mail-Adresse aus dem LDAP nicht sauber gemappt ist, bekommen Benutzer keine Benachrichtigungen über geänderte Dateien. Und die Passwort-Rücksetzung für externe Konten kann ohnehin nicht funktionieren, weil das Passwort ja nicht bei Nextcloud liegt. Genau diese Mischung führt zu Verwirrung. Ein Admin sollte immer wissen, welches Backend für welchen Benutzer zuständig ist und ob Attribute wie E-Mail, Anzeigename und Telefonnummer tatsächlich gepflegt sind.

Sicherheit und Datenschutz im Umgang mit externen Benutzern

Externe Benutzer führen dazu, dass man als Administrator weniger Kontrolle über den gesamten Lebenszyklus eines Kontos hat. Bei Gastkonten ist das noch einfach, weil sie in der Nextcloud selbst verwaltet werden. Bei LDAP oder SAML hängt die Kontrolle am Verzeichnisdienst beziehungsweise am Identity Provider. Das ist genau dort, wo es spannend wird. Wer externe Benutzer anbindet, muss wissen, wann diese Benutzer deaktiviert werden; sonst bleiben Konten aktiv, obwohl die User schon lange nicht mehr im Unternehmen sind. Deshalb ist es unerlässlich, die Synchronisationszeiten kurz zu halten und die Logs zu beobachten. Eine automatisierte Prüfung aller externen Benutzer einmal pro Woche schadet nicht.

Ein weiterer Punkt ist die Zwei-Faktor-Authentifizierung. Nextcloud unterstützt TOTP und WebAuthn, und für lokale Benutzer ist das schnell eingerichtet. Bei externen Benutzern über SAML oder OIDC kommt es darauf an, ob der Identity Provider eine zweite Stufe verlangt. Wenn nicht, sollte man in Nextcloud überlegen, ob man 2FA für alle Benutzer verpflichtend macht. Das klingt streng, ist aber in Zeiten von Phishing-Angriffen auf Administratoren und Cloud-Zugänge kaum noch verzichtbar. Leider haben nicht alle Identity Provider eine saubere Schnittstelle, um den zweiten Faktor an Nextcloud weiterzureichen. Da ist die Nextcloud-eigene 2FA oft die pragmatische Lösung.

Datenschutzrechtlich gesehen ist die Anbindung externer Benutzer eine Einladung, das Thema Auftragsverarbeitung zu klären. Nextcloud kann selbst gehostet werden, das ist der große Vorteil. Aber die externen Benutzer kommen oft aus anderen Ländern, und ihre Daten liegen in einer Cloud, die vielleicht in einem Rechenzentrum außerhalb des EWR steht. Das betrifft nicht nur Unternehmen, sondern auch öffentliche Einrichtungen und Hochschulen. Die DSGVO verlangt eine Dokumentation und – im Zweifel – einen Vertrag über die Auftragsverarbeitung. Wer das ignoriert, kann sich später auf ein unangenehmes Gespräch mit dem Datenschutzbeauftragten gefasst machen.

Auch die Frage der Löschung gehört hierher. Wenn ein Benutzer über den Identity Provider nicht mehr existiert, ist sein Nextcloud-Konto in vielen Fällen eine leere Hülle, aber die Daten in den Ordnern sind noch da. Eine saubere Löschroutine sollte deshalb nicht nur den Account erfassen, sondern auch die Freigaben und die Berechtigungen. Nextcloud bietet dafür das Konzept der Übertragung von Dateien auf andere Benutzer. Das muss man konfigurieren, sonst hängen die Daten in der Schwebe und kein Administrator bekommt ein gutes Gefühl dabei.

Drei Szenarien aus dem echten Leben

Um das Ganze greifbarer zu machen, hilft ein Blick auf typische Konstellationen, wie sie in Projekten immer wieder vorkommen.

Die erste Geschichte: ein produzierendes Unternehmen mit 400 Mitarbeitern, komplett im Active Directory. Nextcloud ist als Intranet und Dateiablage im Einsatz. Die Anbindung läuft über das LDAP-Backend. Die Firma hat Gruppen für jede Abteilung, und die Ordnerstruktur in Nextcloud bildet die Projekte ab. Zusätzlich wurde der LDAP-Write-Support gekauft, sodass die HR-Abteilung neue Mitarbeiter über Nextcloud anlegen kann. Das funktioniert gut, solange sich die Administratoren an die Regeln halten und die Filter sauber gepflegt werden. Die größte Hürde war am Anfang die Umstellung von lokalen Benutzern auf LDAP-Benutzer, weil die bestehenden Datenbestände nicht ganz sauber waren. Am Ende hat man ein Skript geschrieben, das die alten Konten mit den neuen LDAP-Konten abgeglichen hat.

Das zweite Szenario kommt aus dem Hochschulbereich. Eine Universität mit Shibboleth-Verbund, Nextcloud als Cloudspeicher für Studierende und Lehrende. Hier ist SAML die richtige Wahl, weil es sich nahtlos in die vorhandene Infrastruktur einfügt. Die Benutzer kommen per Just-in-Time-Provisioning automatisch in die Plattform. Die Hürde war hier die Zuordnung von institutionellen Rollen. Studierende haben eine andere Gruppen-Zugehörigkeit als Mitarbeiter, und die Institute sind wiederum anders organisiert. Es dauerte einige Zeit, bis die Attribute aus dem Identity Provider so aufbereitet waren, dass Nextcloud sie korrekt interpretieren konnte. Aber am Ende ist ein System entstanden, das ohne manuelle Benutzerpflege auskommt – ein Traum für einen Admin.

Das dritte Szenario schließlich ist eine mittelständische Werbeagentur, die Kunden in Projekte einbindet. Nextcloud ist hier als Kollaborationsplattform mit insgesamt 60 Benutzern im Einsatz, davon etwa 20 feste Mitarbeiter und 40 externe Kunden, die je nach Projektzeitraum Zugriff haben. Es gibt kein Active Directory, der Chef will sich auch nicht damit beschäftigen. Die Lösung sind Gastkonten, die pro Projekt angelegt und mit Projektgruppen verknüpft werden. Jeder Kunde erhält eine Einladung per E-Mail. Nach Abschluss des Projekts wird das Gastkonto deaktiviert. Das funktioniert erstaunlich gut, solange die Betreuer der Projekte diszipliniert sind und die Gäste rechtzeitig abbestellen. Eine automatische Ablaufzeit für Gastkonten wäre noch schön, ist aber nicht in Sicht.

Was Nextcloud Enterprise zusätzlich bietet

Einige der genannten Funktionen sind in der kostenlosen Community Edition nicht oder nur eingeschränkt enthalten. Nextcloud Enterprise richtet sich an Organisationen, die einen verlässlichen Ansprechpartner und garantierte Support-Zeiten brauchen. Im Kontext der externen Benutzerverwaltung sind vor allem zwei Funktionen relevant: der LDAP Write Support und das erweiterte Audit-Logging. Der LDAP-Write-Support wurde oben bereits erwähnt. Er ist lizenzpflichtig, aber für viele Firmen ein entscheidender Grund, über die Enterprise-Version nachzudenken.

Das Audit-Logging wiederum ist ein Protokollierungswerkzeug, das sich in Sicherheitskonzepten kaum wegdenken lässt. Es zeigt, wer sich wann angemeldet hat, woher die Anmeldung kam und welche Aktionen in der Benutzerverwaltung durchgeführt wurden. Gerade wenn externe Benutzer beteiligt sind, ist die Nachvollziehbarkeit wichtig. Ein externer Berater, der Projektdaten liest, hinterlässt damit Spuren, die im Streitfall und bei der internen Revision helfen. In der Community Edition gibt es lediglich die einfache Nextcloud-Logdatei, die aber nicht alle Benutzeraktionen mit einem Zeitstempel versieht. Wer das braucht, sollte Enterprise zumindest in Betracht ziehen.

Natürlich ist Enterprise eine Kostenfrage. Aber wer die Wahl zwischen einem aufwändigen Eigenbau für die Benutzerverwaltung und einer lizenzierten Lösung hat, sollte nicht nur die Lizenzkosten betrachten. Die Zeit, die in die Entwicklung einer eigenen Sync-Lösung fließt, ist im Zweifel deutlich teurer als ein Nextcloud-Abonnement. Dazu kommt das geringere Risiko bei Sicherheitslücken, weil die Enterprise-Distribution Updates rasch bereitstellt.

Ein paar Empfehlungen, die man mitnehmen kann

Was lernt man daraus? Zunächst einmal: Kein Königsweg führt an einer sauberen Bestandsaufnahme vorbei. Man sollte sich zu Beginn eines Nextcloud-Projekts nicht sofort für eine App oder ein Protokoll entscheiden, sondern die Landschaft ansehen. Wo liegen die Benutzerdaten schon vor? Gibt es ein Verzeichnis, einen Identity Provider, eine Datenbank? Welche Personen benötigen Zugang, und wie lange? Aus diesen drei Fragen ergibt sich meist eine klare Linie.

Wer ein Active Directory betreibt, kommt um die LDAP-Integration nicht herum. Sie ist ausgereift, dokumentiert und in der Community erprobt. Man sollte aber die Konfiguration nicht dem Zufall überlassen. Gerade die Entscheidung für das Benutzer-Attribut und die Gruppen-Filter will wohl überlegt sein. Wer später wechseln muss, zahlt einen Preis.

Für Unternehmen mit bereits vorhandenem Single Sign-on sollte die Anbindung per OIDC oder SAML die erste Option sein. Hier ist das Just-in-Time-Provisioning ein enormer Vorteil. Man muss sich nur darüber im Klaren sein, dass die Qualität der Group-Attribute den Ausschlag gibt. Wer die Attribute nicht richtig mappt, kann seine Benutzer zwar anmelden, aber nicht sinnvoll berechtigen.

Gastkonten sind nicht die letzte Wahl, sondern für externe Partner und Kunden oft die eleganteste Lösung. Sie halten das Verzeichnis sauber und sind schnell angelegt. Ich rate dazu, sie sparsam zu verwenden und regelmäßig zu überprüfen. Eine kleine wöchentliche Erinnerung an die Projektverantwortlichen kann Wunder wirken, wenn es darum geht, nicht mehr benötigte Gäste zu entfernen.

Die User Provisioning API ist kein Ersatz für LDAP oder SSO, sondern eine sinnvolle Ergänzung. Sie gehört in jede Werkzeugkiste, wenn es darum geht, Benutzer aus anderen Systemen zu übernehmen oder zu aktualisieren. Man sollte sie nur nicht unterschätzen, was die Sicherheit angeht. Ein dedizierter API-Admin ist besser als der vollwertige Hauptadmin.

Ausblick: Wohin steuert das Benutzermanagement?

Nextcloud hat sich in den letzten Jahren stark weiterentwickelt, und das Thema Benutzerverwaltung wird dabei nicht stehen bleiben. Die Anforderungen gehen in Richtung noch mehr Integration: Passkeys statt Passwörter, WebAuthn als zweiter Faktor, mehr Unterstützung für mehrere Identitäten pro Benutzer. Auch die föderierte Benutzeridentität, bei der man sich mit einem Konto bei verschiedenen Diensten anmelden kann, wird weiter an Bedeutung gewinnen – nicht nur im Wissenschaftsbereich, sondern auch in Unternehmen.

Gleichzeitig wird die Trennung zwischen internen und externen Benutzern durchlässiger. In hybriden Arbeitswelten sind externe Berater, Freiberufler und Projektmitarbeiter längst ein fester Teil der Belegschaft. Starre Benutzermodelle mit „drin“ oder „draußen“ werden dem nicht gerecht. Nextcloud reagiert darauf mit Gastkonten und erweiterten SSO-Funktionen, aber auch mit dem Konzept der externen Speicher und Gruppen. Es bleibt spannend.

Für Administratoren bedeutet das vor allem eines: Sie müssen das Thema Benutzerverwaltung als Prozess verstehen, nicht als einmalige Konfiguration. Der Umgang mit externen Benutzern, die Pflege von Attribute-Mappings und die regelmäßige Kontrolle von Zugriffsrechten gehören zum Betrieb einer Nextcloud-Instanz dazu. Wer das ernst nimmt, wird mit einer Plattform belohnt, die sich in die eigene IT-Landschaft so elegant einfügt, dass sie am Ende kaum noch als eigenständiges System wahrgenommen wird. Und genau das ist wohl das beste Kompliment, das man einer Kollaborationsplattform machen kann.