# SUSE Multi-Linux Manager 5.2: SSO mit Keycloak, SAML und MFA integrieren Source: https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa Language: de Published: 2026-09-15 Updated: 2026-10-16 Keycloak-SAML-SSO für SUSE Multi-Linux Manager: Client, Metadata, ACS, Zertifikat, MFA, Rollen, Break-Glass und Abnahmetest. SUSE Multi-Linux Manager ist ein zentrales Administrationssystem. Deshalb gehört die Anmeldung in produktiven Umgebungen in die bestehende Unternehmens-Identity: zentrale Benutzer, MFA, Rollen, Auditierbarkeit und kontrolliertes Offboarding. Der relevante Integrationspfad ist SAML. Keycloak authentifiziert die Benutzer als Identity Provider. SUSE Multi-Linux Manager bleibt Service Provider und entscheidet weiterhin über Rollen und Berechtigungen im Manager. [![SUSE-Multi-Linux-Manager-Dashboard nach der Grundinstallation.](https://forgeone.solutions/media/suse-mlm-5-2-07-manager-dashboard.png)](https://forgeone.solutions/media/suse-mlm-5-2-07-manager-dashboard.png) ## Zielbild Der Admin öffnet https://mlm01.example.test. Der Manager leitet zu Keycloak weiter. Keycloak prüft Benutzer, Passwort, MFA und Richtlinien. Danach kommt der Benutzer zurück zum Manager und erhält dort nur die Rollen, die explizit vorgesehen sind. SSO bedeutet nicht automatisch Administratorrechte. Authentifizierung klärt, wer jemand ist. Autorisierung klärt, was diese Person darf. ## Keycloak vorbereiten Lege einen eigenen Realm oder einen klar getrennten Client im bestehenden Realm an. Redirect-URIs müssen eng gesetzt sein, MFA sollte über Realm-, Gruppen- oder Conditional-Policies erzwungen werden. Private Testkonten gehören nicht in einen produktiven Admin-Fluss. ```yaml manager_url: https://mlm01.example.test realm: forgeone-operations client: suse-multi-linux-manager protocol: SAML mfa_policy: required for administrators ``` ## SAML-Client anlegen Der SAML-Client bekommt als Client ID den Metadata-Endpunkt des Managers. Die Assertion Consumer Service URL zeigt auf den ACS-Endpunkt des Managers. Verwende den echten Manager-FQDN, nicht localhost, keinen SSH-Tunnel und keinen temporären Port. ```ini Client ID=https://mlm01.example.test/rhn/manager/sso/metadata Valid redirect URI=https://mlm01.example.test/rhn/manager/sso/acs Name ID format=persistent oder username-basiert Force POST binding=nach IdP-Policy aktivieren ``` ## Mapper, Zertifikat und Metadaten Für den Start reichen stabile Mapper für Benutzername, Anzeigename und E-Mail. Der Manager muss außerdem dem öffentlichen SAML-Zertifikat des Identity Providers vertrauen. Private Schlüssel gehören nie in Screenshots, Tickets, Git oder öffentliche Beiträge. ```bash curl -k https://mlm01.example.test/rhn/manager/sso/metadata # Keycloak-Metadaten über abgesicherten Admin-Zugriff exportieren # Öffentliches IdP-Zertifikat im Manager nach unterstütztem Verfahren hinterlegen ``` ## Manager konfigurieren Die Manager-Konfiguration verbindet Keycloak-Metadaten mit dem lokalen Rollenmodell. Plane diesen Schritt wie einen produktiven Change: Wartungsfenster, Rollback, Break-Glass-Admin, Browser-Test und Auditprüfung. ```bash mgrctl status mgrctl exec -- bash -lc 'spacewalk-service status' # SSO-Konfiguration einspielen # Manager-Services kontrolliert neu laden oder neu starten mgrctl status ``` ## MFA und Rollen testen Teste einen Administrator, einen Read-only-Benutzer, einen Benutzer ohne Rolle und einen deaktivierten Benutzer. MFA muss im Keycloak-Fluss erzwungen werden. Der Manager darf aus einer erfolgreichen Anmeldung keine ungewollten Rechte ableiten. ```yaml acceptance: login_with_keycloak: geprüft mfa_required: geprüft disabled_user_blocked: geprüft user_without_role_blocked: geprüft read_only_user_cannot_patch: geprüft admin_user_can_open_reports: geprüft local_break_glass_admin_available: geprüft ``` ## Reports und Audit Nach der SSO-Integration müssen Reports weiterhin nachvollziehbar bleiben. Prüfe Benutzerlisten, Systemzugriffe, geplante Aktionen und Auditdaten. Für Security-Teams ist wichtig, dass der Login zentral erfolgt, aber Aktionen im Manager weiterhin einem Benutzer zuordenbar sind. ```bash spacewalk-report users spacewalk-report users-systems spacewalk-report actions spacewalk-report system-history ``` ## Supportmodell und Grenzen SUSE beschreibt Keycloak als Beispiel für SAML-SSO. In produktiven Projekten muss klar sein, welche Teile vom SUSE-Support, vom Identity-Team und vom Betriebsdienst verantwortet werden. Diese Klärung gehört vor den Go-live, nicht erst in den Störfall. ## Identity-Lifecycle und Offboarding SSO ist besonders wertvoll, wenn Benutzer nicht manuell in mehreren Administrationssystemen gepflegt werden sollen. Neue Administratoren werden über den Identity-Prozess berechtigt, Rollen werden nachvollziehbar vergeben, und beim Austritt reicht nicht ein vergessenes lokales Konto aus, um später noch Zugriff zu haben. Trotzdem bleibt der Manager ein sicherheitskritisches System. Gruppen aus Keycloak dürfen deshalb nicht unkontrolliert zu Superuser-Rechten führen. Wir trennen Authentifizierung, Gruppenzuordnung und Manager-Rolle bewusst voneinander. ## MFA für privilegierte Konten Für Administratoren sollte MFA verpflichtend sein. Sinnvoll ist eine Policy, die mindestens alle Manager-Administratoren betrifft und im Zweifel auch Read-only-Zugriffe auf sicherheitsrelevante Reports schützt. Für Notfallkonten gelten eigene Regeln: starkes Passwort, Tresorablage, dokumentierter Zugriff und regelmäßiger Funktionstest. ## Attribut- und Namensstrategie Der Benutzername, der im Manager ankommt, muss stabil sein. Wenn ein Unternehmen E-Mail-Adressen als Login verwendet, müssen Namensänderungen berücksichtigt werden. Für langlebige Admin-Identitäten ist häufig ein stabiler technischer Username besser als eine wechselnde Mailadresse. ```yaml identity_mapping: login_name: preferred_username display_name: name mail: email group_source: keycloak_groups manager_roles: assigned deliberately inside SUSE Multi-Linux Manager ``` ## Berechtigungen testen Ein guter Test endet nicht beim erfolgreichen Login. Prüfe konkret, ob ein Read-only-Benutzer Reports lesen kann, aber keine Patchaktion auslösen darf. Prüfe, ob ein Benutzer ohne passende Gruppe zwar authentifiziert wird, aber keinen Manager-Zugriff bekommt. Prüfe, ob ein deaktivierter Keycloak-Benutzer sofort ausgesperrt ist. ## Betriebsdokumentation In die Betriebsdokumentation gehören Realm, Client-ID, ACS-URL, Zertifikatslaufzeit, MFA-Policy, verantwortliche Teams, Break-Glass-Verfahren und Rollback. Keine privaten Schlüssel, keine Passwörter und keine temporärer Zugriffswerts gehören in diese Dokumentation. ## Warum SSO für Multi-Linux wichtig ist Multi-Linux Manager verwaltet Systeme unterschiedlicher Distributionen. Damit steigt auch die Zahl der Teams, die Reports lesen oder Änderungen auslösen möchten: Linux-Betrieb, Security, Netzwerk, Plattformteam, Einkauf und externe Partner. SSO macht diese Zugriffe kontrollierbar, ohne dass jedes Team lokale Konten im Manager pflegen muss. ## Schrittfolge für die Keycloak-Integration Zuerst wird festgelegt, welche Benutzergruppen den Manager überhaupt öffnen dürfen. Danach wird definiert, welche Gruppen nur Reports lesen, welche Patchaktionen planen dürfen und welche Personen echte Administratorrechte erhalten. Diese Entscheidung gehört vor die technische SAML-Konfiguration. Danach wird der Keycloak-Client angelegt. Client ID und ACS-URL müssen exakt zum produktiven Manager-FQDN passen. Wenn der Manager später über einen anderen Namen, Load Balancer oder Reverse Proxy erreichbar ist, muss diese Zielarchitektur vorab feststehen. Im nächsten Schritt werden Mapper gesetzt. Der wichtigste Wert ist der stabile Login-Name. Anzeigename und E-Mail sind hilfreich, aber die technische Identität muss dauerhaft eindeutig bleiben. Das verhindert spätere Probleme bei Namensänderungen oder Rollenprüfungen. Anschließend wird das öffentliche Zertifikat des Identity Providers im Manager hinterlegt. Danach folgt der erste Login-Test mit einem normalen Benutzer, nicht sofort mit einem Volladministrator. So erkennst du, ob Authentifizierung und Rollenzuordnung getrennt funktionieren. Erst danach werden MFA-Policies, Adminrollen und Break-Glass-Verfahren final geprüft. Der lokale Notfallzugang bleibt bewusst getrennt vom SSO, damit ein Keycloak- oder Zertifikatsproblem nicht den gesamten Manager-Zugriff blockiert. ## Prüfung nach dem Go-live Nach der Aktivierung testest du mehrere Szenarien: erfolgreicher Login, falsches Passwort, fehlender zweiter Faktor, gesperrter Benutzer, Benutzer ohne Rolle, Read-only-Benutzer und Administrator. Zusätzlich prüfst du, ob Aktionen, Reports und Benutzerzugriffe weiterhin auditierbar bleiben. ## Warum SSO mehr als Komfort ist Multi-Linux Manager steuert Patches, Compliance, Inventar und Systemaktionen. Diese Rechte sind sicherheitsrelevant. SSO mit MFA sorgt dafür, dass Adminzugriffe denselben Unternehmensregeln folgen wie andere kritische Plattformen. Das stärkt Betrieb, Security und Nachvollziehbarkeit gleichzeitig. Für ForgeOne-Projekte ist SSO deshalb ein Architekturthema: Es verbindet Linux-Betrieb, Identity Management, Security Audit und Kundenbetrieb. Der technische Login ist nur ein Teil davon; entscheidend ist, dass Rollen, Reports und Verantwortlichkeiten sauber zusammenpassen. SSO ist kein kosmetisches Login-Thema. Für einen produktiven Manager trennt es Admin-Identität, MFA, Rollenmodell und Nachvollziehbarkeit von lokalen Einzelkonten. Die getestete Manager-Serie behandelt SSO deshalb als Betriebsbaustein neben Patch, Reporting und Audit. [![SUSE Multi-Linux Manager 5.2 mit verwalteten SLES-, Debian-, Ubuntu-, Rocky- und AlmaLinux-Systemen.](https://forgeone.solutions/media/01-all-systems-multidistro-1.png)](https://forgeone.solutions/media/01-all-systems-multidistro-1.png) ## Finale technische Abnahme: SSO und MFA Dieser Abschnitt dokumentiert den abschließenden Live-Rollout-Stand für Teil 8. Grundlage ist das bestandene Lab mit SUSE Multi-Linux Manager 5.2, mgradm 5.2.16, mgrctl 5.2.16, Keycloak 26.7.3, dem Realm suse-mlm-lab, SAML, uid-Mapping, TOTP und Playwright-End-to-End-Tests. ### Architektur des getesteten SSO-Flows Der getestete Weg ist bewusst einfach: SUSE Multi-Linux Manager leitet den Benutzer per SAML zu Keycloak weiter. Keycloak authentifiziert den Benutzer, erzwingt bei aktivierter Richtlinie TOTP und liefert danach die SAML-Antwort an den Manager zurück. Der uid-Mapper stellt sicher, dass die Benutzerzuordnung auf den erwarteten Login-Namen erfolgt. ### Konfiguration, die im Lab geprüft wurde - Keycloak-Realm suse-mlm-lab mit SAML-Client für SUSE Multi-Linux Manager. - SP-/Entity- und ACS-Werte passend zum Manager-FQDN, ohne interne Test-URLs im öffentlichen Artikel. - uid-Mapper aktiv, damit der SAML-NameID-/Attributwert dem Manager-Benutzer entspricht. - TOTP als MFA-Schritt aktiviert und mit Required Action im Loginpfad geprüft. - Logout und Rückkehr zum Anmeldezustand geprüft. ### Basis-SSO-Test Der Basis-Test öffnet den Manager, folgt dem SAML-Redirect zu Keycloak, meldet den Benutzer an und landet wieder im Manager. Der Test zählt nur als bestanden, wenn die Manager-Oberfläche nach dem Redirect erreichbar ist. [![SUSE Multi-Linux Manager zeigt den SSO-Einstieg vor der Weiterleitung zu Keycloak.](https://forgeone.solutions/media/01-mlm-sso-entry-2.png)](https://forgeone.solutions/media/01-mlm-sso-entry-2.png) [![Keycloak Login im Realm suse-mlm-lab für den SAML-Test.](https://forgeone.solutions/media/02-keycloak-login.png)](https://forgeone.solutions/media/02-keycloak-login.png) [![SUSE Multi-Linux Manager nach erfolgreichem SAML-SSO.](https://forgeone.solutions/media/04-mlm-after-sso.png)](https://forgeone.solutions/media/04-mlm-after-sso.png) [![Abgemeldete SUSE-Multi-Linux-Manager-Sitzung nach dem Logout-Test.](https://forgeone.solutions/media/05-logout.png)](https://forgeone.solutions/media/05-logout.png) ### MFA-Test mit TOTP Der Enrollment-Schritt wurde ausgeführt, aber der QR-Code und das TOTP-Secret werden nicht veröffentlicht. Öffentlich dokumentiert sind nur sichere Schritte: Passwort, TOTP-Prüfung, Negativtests und erfolgreicher Login. [![Negativtest mit falschem Passwort im Keycloak-Login.](https://forgeone.solutions/media/01-wrong-password.png)](https://forgeone.solutions/media/01-wrong-password.png) [![Negativtest mit fehlendem TOTP-Code.](https://forgeone.solutions/media/02-missing-totp.png)](https://forgeone.solutions/media/02-missing-totp.png) [![Negativtest mit falschem TOTP-Code.](https://forgeone.solutions/media/03-wrong-totp.png)](https://forgeone.solutions/media/03-wrong-totp.png) [![Erfolgreicher MFA-Login nach korrektem TOTP-Code.](https://forgeone.solutions/media/04-correct-totp.png)](https://forgeone.solutions/media/04-correct-totp.png) [![SUSE Multi-Linux Manager nach erfolgreichem MFA-Login.](https://forgeone.solutions/media/04-mlm-after-mfa.png)](https://forgeone.solutions/media/04-mlm-after-mfa.png) ### Negativtests Die Abnahme hat falsches Passwort, fehlenden TOTP-Code und falschen TOTP-Code geprüft. Erst der korrekte MFA-Schritt führte zurück in den Manager. ### Typische Fehlerbilder - Redirect- oder ACS-Fehler: Entity-ID, ACS-URL und externe Manager-URL konsistent prüfen. - Benutzer wird nicht zugeordnet: uid-Mapper und Manager-Benutzername vergleichen. - MFA wird nicht abgefragt: Required Action, Realm-Flow und Benutzerstatus in Keycloak prüfen. - Login gelingt, Rückkehr scheitert: SAML-Antwort, Zertifikate, Zeitabweichung und Browser-Cookies prüfen. ### Technische Ergebniskontrolle | Prüfbereich | Prüfung | Ergebnis | | --- | --- | --- | | Versionen | MLM 5.2, mgradm 5.2.16, mgrctl 5.2.16, Keycloak 26.7.3 | PASS | | SAML | Redirect Manager zu Keycloak und zurück | PASS | | Mapping | uid-Mapper für Benutzerzuordnung | PASS | | MFA | TOTP wird abgefragt und korrekt ausgewertet | PASS | | Negativtests | Falsches Passwort, fehlender und falscher TOTP-Code | PASS | | Logout | Sitzung wird beendet und Login erneut verlangt | PASS | | Secrets | Kein TOTP-QR und kein Secret im öffentlichen Artikel | PASS | ## Titelbild [![SUSE-Multi-Linux-Manager-Dashboard nach der Grundinstallation.](https://forgeone.solutions/media/suse-mlm-5-2-07-manager-dashboard.png)](https://forgeone.solutions/media/suse-mlm-5-2-07-manager-dashboard.png) ## Autor Mathias Rumbold ## Kategorie - [Enterprise Linux](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa?category=enterprise-linux) - [Linux Lifecycle Management](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa?category=linux-lifecycle-management) ## Tags - [SUSE](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa?tags=suse) - [SUSE Multi-Linux Manager](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa?tags=suse-multi-linux-manager) - [SSO](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa?tags=sso) - [Keycloak](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa?tags=keycloak) - [SAML](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa?tags=saml) - [Hardening](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa?tags=hardening) ## SUSE Enterprise Linux & Multi-Linux Manager Schritt für Schritt Die Serie verbindet SLES 16 Grundlagen mit dem produktiven Aufbau von SUSE Multi-Linux Manager 5.2. Bestehende URLs bleiben unverändert. 1. [SLES 16 produktiv installieren: vom ISO zum verwaltbaren Linux-Server](https://forgeone.solutions/de/tech/sles-16-installieren) 2. [SLES 16 und Enterprise Linux: Wie unterschiedlich ist der Admin-Alltag noch?](https://forgeone.solutions/de/tech/sles-16-enterprise-linux-rhel-rocky-almalinux-vergleich) 3. [SLES 16 härten und prüfen: OpenSCAP, CIS-Einordnung und SUSE Multi-Linux Manager](https://forgeone.solutions/de/tech/sles-16-hardening-openscap-cis-mlm) 4. [SUSE Multi-Linux Manager 5.2 produktiv installieren: SL Micro, Storage und erster Channel-Sync](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sl-micro-installieren) 5. [SUSE Multi-Linux Manager 5.2: erste Linux-Clients produktiv onboarden](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-clients-onboarden) 6. [SUSE Multi-Linux Manager 5.2: Patch- und Lifecycle-Management produktiv aufbauen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management) 7. [SUSE Multi-Linux Manager 5.2: Mixed Linux produktiv verwalten](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten) 8. [SUSE Multi-Linux Manager 5.2: OpenSCAP, Compliance und Audit produktiv nutzen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-openscap-compliance-audit) 9. [SUSE Multi-Linux Manager 5.2: Proxies für Standorte und verteilte Linux-Flotten aufbauen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-proxy-standorte-aufbauen) 10. [SUSE Multi-Linux Manager 5.2: SSO mit Keycloak, SAML und MFA integrieren (aktueller Teil)](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa) 11. [SUSE Multi-Linux Manager 5.2: Ansible neben Salt produktiv nutzen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt) 12. [SUSE Multi-Linux Manager 5.2: Reporting, Inventar und Subscription Audit aufbauen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-reporting-inventory-subscription-audit) 13. [SUSE Multi-Linux Manager 5.2 produktiv betreiben und härten](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-produktiv-betreiben-haerten) ## Weiterführende Inhalte - [Identity & Access mit Open Source und Enterprise-Support](https://forgeone.solutions/de/produkte/identity-access) - [Keycloak](https://forgeone.solutions/de/produkte/keycloak) - [Single Sign-On (SSO)](https://forgeone.solutions/de/single-sign-on-sso)