Nextcloud mit SAML und OIDC: 8 Fehler, die im Support immer wieder auftauchen

Nextcloud bringt für Single Sign-on zwei Apps mit: SSO & SAML authentication (user_saml) für SAML 2.0 und OpenID Connect user backend (user_oidc) für OIDC. Beide funktionieren zuverlässig — wenn Nextcloud, Reverse Proxy und Identity Provider dieselbe Sicht auf URLs, Zeit und Benutzer-IDs haben. Fast jedes SSO-Ticket lässt sich auf eine dieser drei Stellen zurückführen.

Vorab: den Notausgang kennen

Bevor man an der SSO-Konfiguration schraubt, sollte man wissen, wie man ohne SSO hineinkommt. Mit https://cloud.example.com/login?direct=1 zeigt Nextcloud das klassische Login-Formular, und ein lokaler Admin kann sich auch dann anmelden, wenn der Identity Provider streikt. Wer das vorher testet, erspart sich im Ernstfall viel Stress.

1. Redirect-Schleife hinter dem Reverse Proxy

Symptom: Nach dem Login beim IdP springt der Browser endlos zwischen Nextcloud und IdP hin und her, oder der IdP meldet eine ungültige Rücksprung-URL.

Ursache: Nextcloud läuft hinter einem Proxy, der TLS terminiert, und erzeugt deshalb http://-URLs oder einen falschen Hostnamen. Die Assertion Consumer Service URL (SAML) bzw. Redirect-URI (OIDC) passt dann nicht zu dem, was beim IdP hinterlegt ist.

Lösung: In der config.php overwriteprotocol auf https, overwrite.cli.url auf die öffentliche URL und den Proxy in trusted_proxies eintragen. Danach die erwarteten Endpunkte prüfen: für SAML /apps/user_saml/saml/acs (Metadaten unter /apps/user_saml/saml/metadata), für OIDC /apps/user_oidc/code.

2. Uhrzeit weicht ab

Symptom: Sporadisch oder dauerhaft „Assertion expired“ oder „not yet valid“, obwohl die Konfiguration stimmt.

Ursache: SAML-Assertions und OIDC-Tokens haben enge Gültigkeitsfenster. Schon wenige Minuten Abweichung zwischen Nextcloud-Server und IdP reichen.

Lösung: NTP auf beiden Seiten aktivieren und mit timedatectl prüfen. In Containern gilt die Uhr des Hosts.

3. Zertifikat beim IdP erneuert

Symptom: Von einem Tag auf den anderen schlägt jeder Login mit einem Signaturfehler fehl.

Ursache: Der IdP hat sein Signaturzertifikat getauscht, in Nextcloud ist noch das alte X.509-Zertifikat eingetragen.

Lösung: Das aktuelle Zertifikat aus den IdP-Metadaten übernehmen. Viele IdPs veröffentlichen das neue Zertifikat schon vor dem Wechsel — wer beide Termine kennt, plant den Tausch, statt ihn zu bemerken.

4. UID-Mapping auf das falsche Attribut

Symptom: Nach einer Namens- oder E-Mail-Änderung meldet sich ein Benutzer an und sieht ein leeres, neues Konto.

Ursache: Als eindeutige Benutzer-ID wurde ein veränderliches Attribut gemappt, etwa die E-Mail-Adresse. Ändert sie sich, legt Nextcloud ein neues Konto an.

Lösung: Von Anfang an ein unveränderliches Attribut verwenden — bei OIDC den sub-Claim, bei SAML eine feste ID wie die Objekt-ID aus dem Verzeichnisdienst. Das Mapping nachträglich zu ändern ist eine Migration, keine Einstellung: vorher Daten und Freigaben der betroffenen Konten sichern.

5. Konto existiert nicht — oder wird doppelt angelegt

Symptom: „Account not provisioned“ bzw. ein Login ohne Zugriff auf bestehende Daten, wenn parallel LDAP oder lokale Konten im Spiel sind.

Ursache: Unklar, welches Backend die Benutzer liefert. Bei SAML kann Nextcloud Konten selbst anlegen oder nur Benutzer zulassen, die schon in einem anderen Backend (z. B. LDAP) existieren.

Lösung: Eine Quelle der Wahrheit festlegen und die Option „nur bestehende Konten zulassen“ bewusst setzen. Die gemappte UID muss exakt der UID im anderen Backend entsprechen — Groß-/Kleinschreibung inklusive.

6. OIDC: Provider nicht erreichbar

Symptom: Beim Anlegen des Providers oder beim Login erscheint ein Fehler beim Abruf der Discovery-URL.

Ursache: Der Nextcloud-Server selbst muss /.well-known/openid-configuration des IdP erreichen können. Interne IdPs mit privaten IP-Adressen blockiert Nextcloud standardmäßig, außerdem stören Firewalls oder ein Proxy ohne passende Ausnahme.

Lösung: Vom Server aus mit curl testen. Für einen IdP im internen Netz 'allow_local_remote_servers' => true in der config.php setzen — gezielt und dokumentiert, weil die Option auch andere Funktionen betrifft. Provider lassen sich per occ user_oidc:provider skriptbar verwalten.

7. Gruppen kommen nicht an

Symptom: Login klappt, aber Freigaben für Gruppen oder Admin-Rechte fehlen.

Ursache: Der IdP sendet keinen Gruppen-Claim bzw. kein Gruppen-Attribut, oder der Name im Mapping stimmt nicht.

Lösung: Mit einem Browser-Add-on wie SAML-tracer (oder dem dekodierten ID-Token bei OIDC) nachsehen, was tatsächlich ankommt, und das Mapping danach ausrichten — nicht umgekehrt.

8. Logout meldet nicht überall ab

Symptom: Nach dem Abmelden in Nextcloud ist man beim nächsten Klick sofort wieder eingeloggt.

Ursache: Abgemeldet wurde nur die Nextcloud-Sitzung, die Sitzung beim IdP läuft weiter. Das ist das erwartete SSO-Verhalten, wird aber oft als Fehler gemeldet.

Lösung: Single Logout bzw. die Logout-URL des IdP konfigurieren, falls ein vollständiges Abmelden gewünscht ist — und Nutzern erklären, was „Abmelden“ in einer SSO-Umgebung bedeutet.

Checkliste für das nächste SSO-Ticket

• Notfall-Login mit /login?direct=1 getestet?
• Öffentliche URL, overwriteprotocol und trusted_proxies korrekt?
• ACS-URL bzw. Redirect-URI beim IdP identisch mit Nextcloud?
• Zeit auf Nextcloud und IdP synchron?
• Aktuelles IdP-Zertifikat hinterlegt?
• UID auf ein unveränderliches Attribut gemappt?
• Tatsächliche Attribute/Claims mit SAML-tracer oder Token-Decoder geprüft?
• Für die Analyse vorübergehend loglevel 0 und nextcloud.log lesen — danach wieder zurücksetzen.

Die meisten SSO-Probleme sind keine Bugs, sondern zwei Systeme, die sich über eine Kleinigkeit nicht einig sind. Wer URLs, Zeit und IDs systematisch abklopft, findet die Ursache meist in Minuten statt Stunden.