SUSE Multi-Linux Manager 5.2: SSO mit Keycloak, SAML und MFA integrieren

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.

https://mlm01.lab.example

Kompletter Ablauf der Serie

Diese Reihe führt dich Schritt für Schritt durch den produktiven Aufbau: 1. SLES 16 produktiv installieren · 2. SUSE Multi-Linux Manager 5.2 installieren · 3. Erste Linux-Clients onboarden · 4. Patch- und Lifecycle-Management · 5. Mixed Linux verwalten · 6. OpenSCAP, Compliance und Audit · 7. Proxies für Standorte aufbauen · 8. SSO mit Keycloak integrieren · 9. Ansible neben Salt nutzen · 10. Reporting, Inventar und Audit · 11. Produktiv betreiben und härten

Zielbild

Der Admin öffnet https://mlm01.lab.example. 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.

manager_url: https://mlm01.lab.example
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.

Client ID=https://mlm01.lab.example/rhn/manager/sso/metadata
Valid redirect URI=https://mlm01.lab.example/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.

curl -k https://mlm01.lab.example/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.

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.

acceptance:
  login_with_keycloak: PASS
  mfa_required: PASS
  disabled_user_blocked: PASS
  user_without_role_blocked: PASS
  read_only_user_cannot_patch: PASS
  admin_user_can_open_reports: PASS
  local_break_glass_admin_available: PASS

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.

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.

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 Tokens 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.