OpenWebUI Keycloak: Active Directory SSO

TL;DR

OpenWebUI Active Directory Keycloak ist die On-Premise-Kette Verzeichnis → IdP → Chat: Keycloak federiert Active Directory per LDAP, Open WebUI spricht nur OIDC. Die Herstellerdoku verlangt OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET, OPENID_PROVIDER_URL (Well-Known-Dokument) und den Redirect /oauth/oidc/callback. Der Claim email ist Pflicht. WEBUI_URL muss vor dem ersten SSO stehen, sonst schlägt der Rücksprung fehl. Passwörter bleiben laut Keycloak im Verzeichnis; Keycloak importiert sie nicht. Gelesen in der Open-WebUI-SSO- und Umgebungsdoku sowie im Keycloak-Admin-Guide am 2026-10-17. Kein Anbieter-Ranking.

Drei Wege, ein Keyword

IT-Leiter suchen „openwebui active directory keycloak“, wenn Windows- Konten den Firmen-Chat öffnen sollen, ohne eine zweite Passwortliste. Das ist nicht Entra in der Cloud und nicht das eingebaute LDAP von Open WebUI.

Die Chat-Oberfläche ohne SSO bleibt OpenWebUI plus Ollama. TLS und WEBUI_URL vor der Anmeldung: OpenWebUI Nginx Reverse Proxy. Microsoft Entra statt Keycloak: Entra-ID-SSO für Open WebUI, LiteLLM und n8n. Keycloak am Gateway, nicht an der UI: LiteLLM Keycloak. JWT vor beliebigen LLM-Endpunkten: LLM-API-Sicherheit Keycloak.

Open WebUI kennt native LDAP-Variablen (ENABLE_LDAP, Host, Bind-DN, Suchbasis). Das hängt die UI direkt an das Verzeichnis. Der Keycloak-Weg hält die Anmeldung im IdP: ein Realm, ein Client, ein OIDC-Callback. Nur ein OIDC-Anbieter gleichzeitig über OPENID_PROVIDER_URL; Microsoft- und Google-OIDC parallel gehen laut SSO-Seite nicht.

Schicht 1: Active Directory in Keycloak

Keycloak beschreibt User Federation so: bestehende LDAP- und Active-Directory-Server bleiben die Quelle, Keycloak prüft Kennwörter dort und zieht Identität in das Realm-Modell. Menü User Federation → Add LDAP providers.

Laut Admin-Guide:

1. Zuerst ein lokales Admin-Konto im Realm anlegen. Keycloak sucht lokale Nutzer vor jedem LDAP-Provider. Fällt das Verzeichnis aus, bleibt dieser Admin der Zugang.
2. Vendor, Edit Mode und Import Users beim Anlegen festlegen. Die ersten LDAP-Mapper hängen an dieser Kombination. Späteres Umschalten ändert die Mapper nicht automatisch.
3. Import Users ein: Nutzer landen bei Login oder Suche in der lokalen Datenbank. Import Users aus: das Verzeichnis bleibt die Laufzeitquelle; Features, die lokale Profildaten brauchen, fehlen dann.
4. Kennwörter werden nicht importiert. Die Prüfung läuft immer gegen LDAP/AD.

Edit Mode laut Doku:

Für Microsoft Active Directory nennt der Guide den MSAD User Account Mapper. Er liest userAccountControl und pwdLastSet. Wert pwdLastSet = 0 setzt die Required Action UPDATE_PASSWORD. Wert userAccountControl = 514 (Konto deaktiviert) deaktiviert den Keycloak-Nutzer. Das sind Verzeichnisattribute, kein LDAP-Standard.

Verbindung: ldaps://<dc>:636 plus Truststore auf der Keycloak-Seite. Mehrere Domain-Controller derselben Domäne als leerzeichengetrennte URLs, nicht mit Komma. Der Guide: Default-Timeout 5000 Millisekunden pro unerreichbarer URL, dann die nächste. Komma verwirft die erste URL still.

Sync: einmal Synchronize all users, danach periodisch nur geänderte Konten. Lokale Nutzernamen und E-Mails speichert Keycloak bei Import klein; ohne Import bleibt die LDAP-Groß/Kleinschreibung.

Die Community-Anleitung von Open WebUI legt das Realm-Beispiel openwebui an und den Client open-webui. Das ist ein Demo-Name, kein Pflichtname.

Schicht 2: OIDC-Client für Open WebUI

Im selben Realm Clients → Create client:

1. Client type OpenID Connect.
2. Eine Client-ID vergeben, speichern.
3. Client authentication auf ON (confidential, Client-Secret). Die Community-Anleitung zu Keycloak 26.x: Default ist „None“, manuell auf Client-ID und Secret stellen.
4. Standard Flow an (Authorization Code).
5. Valid Redirect URIs exakt, case-sensitive. Production ohne Wildcard *.

Redirect laut Open-WebUI-SSO-Seite:

https://<ihre-chat-url>/oauth/oidc/callback

Ohne Override leitet Open WebUI den Callback aus dem eingehenden Request ab. OPENID_REDIRECT_URI überschreibt das, wenn der Proxy die Request-URL verbiegt.

Keycloak veröffentlicht die Discovery-URL

https://<keycloak>/realms/<realm>/.well-known/openid-configuration

und die relativen OIDC-Pfade (Realm-Name einsetzen):

/realms/{realm-name}/protocol/openid-connect/auth
/realms/{realm-name}/protocol/openid-connect/token
/realms/{realm-name}/protocol/openid-connect/userinfo
/realms/{realm-name}/protocol/openid-connect/certs
/realms/{realm-name}/protocol/openid-connect/logout

Open WebUI braucht das Well-Known-Dokument, nicht die Einzelpfade von Hand. Falsche Namen laut Troubleshooting: OIDC_CONFIG, WEBUI_OIDC_CLIENT_ID, WEBUI_ENABLE_SSO. Korrekt sind OPENID_PROVIDER_URL und OAUTH_CLIENT_ID.

Schicht 3: Open-WebUI-Umgebung

Vor dem ersten SSO-Login WEBUI_URL auf die öffentliche HTTPS-Adresse setzen. Die Env-Doku: das Feld ist persistent; nachträglich nur über Admin-Panel oder ENABLE_PERSISTENT_CONFIG. Fehlt die URL hinter einem Proxy, scheitert der Login.

# docker-compose.yml — Ausschnitt, Werte ersetzen
services:
  open-webui:
    environment:
      WEBUI_URL: 'https://chat.ihre-domain.de'
      WEBUI_SECRET_KEY: '<langes zufälliges Geheimnis>'
      ENABLE_OAUTH: 'true'
      ENABLE_OAUTH_SIGNUP: 'true'
      OAUTH_CLIENT_ID: 'open-webui'
      OAUTH_CLIENT_SECRET: '<secret aus Keycloak Credentials>'
      OPENID_PROVIDER_URL: 'https://idp.ihre-domain.de/realms/openwebui/.well-known/openid-configuration'
      OAUTH_PROVIDER_NAME: 'Keycloak'
      OAUTH_SCOPES: 'openid email profile'
      ENABLE_OAUTH_PERSISTENT_CONFIG: 'false'

ENABLE_OAUTH ist laut Doku standardmäßig an; false schaltet SSO ab, ohne Client-Daten zu löschen. ENABLE_OAUTH_SIGNUP legt Konten beim ersten IdP-Login an und ist standardmäßig aus. Die Env-Doku warnt: ENABLE_LOGIN_FORM auf false, sobald ENABLE_OAUTH_SIGNUP an ist — sonst kein Login. ENABLE_PASSWORD_AUTH erst auf false, wenn SSO steht und Signup an ist; vorher sperren Sie sich aus.

WEBUI_SECRET_KEY muss gesetzt sein, in einem Cluster auf allen Instanzen identisch, sonst Session- und OAuth-Fehler. OAUTH_SESSION_TOKEN_ENCRYPTION_KEY teilt dasselbe Geheimnis, wenn Sie es nicht extra setzen.

Default-Scopes: openid email profile. Der Claim email ist erforderlich. name und picture nutzt die UI, wenn sie kommen. OAUTH_MERGE_ACCOUNTS_BY_EMAIL führt ein bestehendes Lokal-Konto mit dem SSO-Konto zusammen, wenn die Adresse stimmt. Die SSO-Seite warnt: unsicher, falls der IdP E-Mails nicht prüft. Active Directory liefert mail nur, wenn das Attribut gepflegt ist.

Gruppen: Keycloak-Clients tragen Gruppen nicht von selbst im Token. Mapper im Client-Scope (Community-Tutorial: Scope profile oder <client>-dedicated), Claim-Name typisch groups. In Open WebUI dann ENABLE_OAUTH_GROUP_MANAGEMENT=true und OAUTH_GROUP_CLAIM=groups. Mit ENABLE_OAUTH_GROUP_CREATION legt die UI fehlende Gruppen beim Login an. Die Synchronisation ist strikt: Mitgliedschaften folgen dem Token, nicht lokalen Resten.

Rollen analog: ENABLE_OAUTH_ROLE_MANAGEMENT, Claim roles (oder verschachtelt), OAUTH_ALLOWED_ROLES, OAUTH_ADMIN_ROLES. Rollenwechsel gilt erst nach erneutem Login.

Abmelden im IdP: ENABLE_OAUTH_BACKCHANNEL_LOGOUT=true öffnet POST /oauth/backchannel-logout. Ohne Redis bleiben ausgestellte JWTs bis zum Ablauf gültig.

Default-Port beider Dienste ist 8080. Die Community-Anleitung verschiebt Keycloak im Dev auf 9090. Produktiv trennen Hostnamen und TLS, nicht nur der Port.

Häufige Fehler

Häufige Fragen

Ist das dasselbe wie Open-WebUI-LDAP?

Nein. ENABLE_LDAP bindet die UI direkt an Host, Bind-DN und Suchfilter. Keycloak federiert das Verzeichnis und stellt OIDC bereit. Gleichzeitig LDAP in der UI plus OIDC ist für OAUTH_AUTO_REDIRECT ausgeschlossen.

Ist das dasselbe wie Entra-ID-SSO?

Nein. Entra nutzt MICROSOFT_CLIENT_ID, Tenant und /oauth/microsoft/callback. Keycloak läuft über Generic-OIDC und /oauth/oidc/callback. Die Entra-Anleitung bleibt Entra-ID-SSO.

Reicht Keycloak ohne Active Directory?

Ja, mit lokalen Realm-Nutzern. Dann ist das Keyword nicht getroffen: „Active Directory“ meint User Federation gegen das Windows-Verzeichnis.

Warum schlägt der erste Login fehl, obwohl der Client stimmt?

Zuerst WEBUI_URL und Redirect-URI. Danach E-Mail-Claim und ENABLE_OAUTH_SIGNUP. Hinter Nginx dieselben Header wie in OpenWebUI Nginx Reverse Proxy.

Kann ich LiteLLM denselben Realm geben?

Ja. Die UI bleibt bei /oauth/oidc/callback, das Gateway bei /sso/callback. Getrennte Clients, gemeinsame User Federation: LiteLLM Keycloak.

Fazit

Open WebUI, Active Directory und Keycloak koppelt man in drei dokumentierten Schritten: LDAP-Provider im Realm, confidential OIDC-Client mit exaktem Callback, Open-WebUI-Umgebung mit OPENID_PROVIDER_URL und WEBUI_URL. Das Verzeichnis bleibt Passwortquelle. Kein zweiter Hardware-Kaufguide und keine Euro-Versprechen.