NexTool Solutions

SSO in GLPI mit Microsoft Entra ID (Azure AD) ersetzt lokale Passwörter und zentralisiert die MFA in Ihrem Mandanten (Tenant). Was jedoch über einen stabilen Login oder eine nächtliche Bereitschaft entscheidet, ist nicht der Klick auf „SAML“ im Portal: Es ist die Wahl des richtigen Protokolls für Ihre GLPI-Version und die Vorausplanung dessen, was ablaufen wird.

SAML oder OIDC? Die Entscheidung beginnt bei der GLPI-Version

Entra ID bietet SSO über zwei Protokolle: SAML 2.0 und OpenID Connect (OIDC, auf Basis von OAuth 2.0). GLPI beherrscht keines davon nativ für den Login – Sie brauchen ein Plugin. Und hier liegt die Falle, in die alle tappen, die auf GLPI 11 migrieren: Das am besten gepflegte SAML-Plugin der Community, glpisaml, ist auf MAX_GLPI = 10.9.99 begrenzt. Der Autor selbst erklärt, dass es nicht mit GLPI 11 kompatibel ist (und auch nicht sein wird). Wer bei Version 11 ankommt und erwartet, „einfach das SAML-Plugin neu zu installieren“, läuft gegen eine Wand.

In der Praxis verwenden wir diese Entscheidungsmatrix:

Zusammengefasst: GLPI 10 akzeptiert SAML (glpisaml) oder OIDC (oauthsso); GLPI 11 und 12 setzen auf OIDC. Für 11 und 12 empfehlen wir das Modul SSO Login von NexTool, das im nächsten Abschnitt beschrieben wird. oauthsso, das Teclib im Abonnement GLPI Network vertreibt, bleibt in den Schritten 1 bis 5 die Alternative. Die Teile zu Reverse Proxy, JIT und Betrieb gelten für beide.

Der empfohlene Weg in GLPI 11 und 12: das Modul SSO Login

SSO Login ist das NexTool-Modul für den Login mit Microsoft Entra ID, Google und jedem OpenID-Connect-Anbieter (Keycloak, Okta). Es löst die Punkte, die mit oauthsso die meisten Tickets erzeugen: Es bedient mehrere Organisationen in einem GLPI (mandantenfähig, für MSPs), weist das Profil schon beim ersten Login über die Entra-Sicherheitsgruppe zu, respektiert die automatische Benutzeranlage von GLPI, beendet beim Abmelden auch die Sitzung bei Microsoft und kann den Benutzer direkt zum Microsoft-Login führen, ohne den GLPI-Anmeldebildschirm.

In Entra ID

1. App-Registrierungen > Neue Registrierung. Wählen Sie den Kontotyp: ein einzelner Mandant für Ihr Unternehmen oder mehrere Mandanten, wenn GLPI Kunden aus anderen Organisationen bedient. Fügen Sie unter Umleitungs-URI (Plattform Web) die Adresse ein, die das Modul zum Kopieren bereitstellt, im Format https://glpi.yourcompany.com/plugins/nextool/sso/ssologin/callback.

1. Übersicht: Notieren Sie die Anwendungs-ID (Client) und die Verzeichnis-ID (Mandant). Erstellen Sie unter Zertifikate & Geheimnisse den geheimen Clientschlüssel und kopieren Sie den Wert sofort: Er wird nur ein einziges Mal angezeigt. Notieren Sie auch das Ablaufdatum.

1. Tokenkonfiguration: Fügen Sie dem ID-Token die optionalen Ansprüche email und upn hinzu. Um das Profil über die Gruppe zuzuweisen, verwenden Sie Gruppenanspruch hinzufügen, markieren Sie Sicherheitsgruppen und behalten Sie Gruppen-ID bei.

1. API-Berechtigungen: Microsoft Graph email, profile und User.Read, delegiert. Ohne Administratorzustimmung bestätigt jeder Benutzer den Zugriff beim ersten Login.

In GLPI

1. Einrichtung > SSO Login > Hinzufügen: Anbieter Microsoft Entra ID, Client-ID, Geheimnis und Mandant (die Verzeichnis-ID). Für mehrere Organisationen verwenden Sie den Mandanten organizations mit der Liste der akzeptierten Mandanten oder, wenn Sie beliebige Kunden bedienen, die Option, jeden Mandanten zu akzeptieren.
2. Feld für die erste Zuordnung: upn. Beim ersten Zugriff sucht das Modul den GLPI-Benutzer, dessen Login dem upn entspricht; danach nutzt die Verknüpfung die feste Kennung des Kontos in Entra, und eine Änderung der E-Mail-Adresse dort bricht den Login nicht.
3. Profil über die Gruppe: Geben Sie in der Anwendung groups als Profil-Claim an und legen Sie eine Regel zur Rechtezuweisung an (Verwaltung > Regeln) mit dem Kriterium Roles (claim) gleich der Objekt-ID der Sicherheitsgruppe und der Profilaktion. Das Profil wird dynamisch zugewiesen: Wer die Gruppe verlässt, verliert das Profil beim nächsten Login.
4. Testen und freigeben: Der Reiter Test der Anwendung prüft die Konfiguration und die Schlüssel des Anbieters, ohne sich anzumelden. Ist die Anwendung aktiv, erscheint die Schaltfläche auf dem Anmeldebildschirm. Um diesen Bildschirm zu überspringen, aktivieren Sie Direkt zum SSO-Login im Reiter Einstellungen des Moduls; der lokale Administrator meldet sich immer über die Adresse des Anmeldebildschirms mit ?noAUTO=1 am Ende an.

Zwei Unterschiede im Betrieb gegenüber oauthsso. Lokale GLPI-Konten und Administratoren werden nicht von einem externen Login übernommen, es sei denn, Sie geben das in der Anwendung frei. Und die automatische Benutzeranlage respektiert die GLPI-Konfiguration und erfolgt nur mit verifizierter E-Mail-Adresse in einer erlaubten Domain. Das Assignment required von Entra, beschrieben in Schritt 5, bleibt eine gute Praxis, um einzuschränken, wer ein Token erhält.

1. Die Anwendung in Entra ID registrieren

Für OIDC führt der Weg im Entra-ID-Portal über App registrations (App-Registrierung), nicht über die Enterprise Application mit „SAML“: Sie registrieren eine App und erzeugen ein Geheimnis (Client Secret).

1. App registrations > New registration. Name „GLPI“; unterstützte Konten: nur Ihr Mandant (Single Tenant), es sei denn, Sie bedienen mehrere Organisationen.
2. Redirect URI (Typ Web): der Callback des Plugins – https://glpi.yourcompany.com/plugins/oauthsso/front/callback.php.
3. Certificates & secrets > New client secret. Notieren Sie den Wert (er erscheint nur einmal) und vor allem das Ablaufdatum.
4. Token configuration: Stellen Sie die Claims email und preferred_username (oder upn) sicher – über sie ordnet GLPI den Benutzer zu.
5. Enterprise Applications > Ihre App > Properties: Assignment required = Yes. Das ist Ihre eigentliche Whitelist (Erklärung in Schritt 5).

2. GLPI konfigurieren (OIDC-Weg)

Entpacken Sie das Plugin in plugins/ (oder marketplace/) und installieren Sie es über die Kommandozeile. Der typische Fehler hier ist, die Konsole als root auszuführen: Die erzeugten Dateien erhalten den falschen Eigentümer, und der nächste Zugriff über das Web scheitert an den Berechtigungen. Führen Sie sie als Benutzer des Webservers aus:

# GLPI 11: install and enable the plugin as the Apache user (www-data/apache)
php bin/console plugin:install oauthsso
php bin/console plugin:activate oauthsso

# oauthsso does NOT create its own table: it stores everything in glpi_configs,
# under the 'plugin:oauthsso' context (tenant id, client id, client secret).

Geben Sie in der Plugin-Maske (oder direkt in glpi_configs) die Tenant ID, die Client ID und das Client Secret der registrierten App ein. Der GLPI-Anmeldebildschirm zeigt dann die Schaltfläche „Login with Microsoft“.

3. Die Redirect-Falle hinter einem Reverse Proxy

Das ist das Ticket, das wir bei Implementierungen am häufigsten eröffnen: GLPI steht hinter einem Nginx/Apache, der TLS terminiert, und sieht die Anfrage intern als http://. Ergebnis: GLPI baut den Callback mit http://, Entra erhält eine Redirect-URI, die nicht mit der registrierten übereinstimmt, und antwortet mit redirect_uri_mismatch – oder der Benutzer landet in einer Weiterleitungsschleife. Die endgültige Korrektur ist, die Basis-URL in der Datenbank festzulegen:

-- Force the correct base URL (avoids an http:// callback behind the proxy)
UPDATE glpi_configs
SET value = 'https://glpi.yourcompany.com'
WHERE context = 'core' AND name = 'url_base';

-- GLPI caches config: clear the cache after changing it
-- php bin/console cache:clear

Stellen Sie außerdem sicher, dass der Proxy das tatsächliche Schema weitergibt – zum Beispiel RequestHeader set X-Forwarded-Proto "https" in Apache oder proxy_set_header X-Forwarded-Proto $scheme; in Nginx. Korrekte Basis-URL plus korrekter Header beenden die Schleife.

4. JIT: wenn sich der Benutzer anmeldet, aber nichts sieht

Die Just-in-Time-Bereitstellung legt den Benutzer beim ersten Login an – weist aber kein Profil zu. Das Symptom ist klassisch: Die Authentifizierung gelingt, der Benutzer meldet sich an und landet auf einem leeren Bildschirm („kein Profil zugewiesen“). Im Betrieb ist das der zweithäufigste Ticketgrund direkt nach „SSO konfiguriert“. Die Diagnose ist eine SQL-Abfrage:

-- SSO users (external authentication) that ended up WITHOUT a profile:
-- they log in, but land on an empty screen.
SELECT u.id, u.name, u.authtype
FROM glpi_users u
LEFT JOIN glpi_profiles_users pu ON pu.users_id = u.id
WHERE pu.id IS NULL
  AND u.is_deleted = 0;

Die Ausgabe zeigt genau, wer ein Profil braucht. Die skalierbare Lösung ist eine Regel zur Rechtezuweisung (Verwaltung > Regeln), die allen, die über SSO kommen, ein Standardprofil zuweist, statt das bei jedem neuen Benutzer von Hand zu erledigen.

5. Die eigentliche Whitelist liegt in Entra, nicht in GLPI

Ein Detail, das man nur im Betrieb auf die harte Tour lernt: oauthsso legt den Benutzer beim ersten Login an und ignoriert das Flag is_users_auto_add des GLPI-Cores. Das heißt: Jedes gültige Konto des Mandanten, das den Callback erreicht, wird zum GLPI-Benutzer. Es hilft nichts, die Sperre in GLPI zu suchen – im Plugin gibt es sie nicht. Die eigentliche Kontrolle ist das Assignment required = Yes aus Schritt 1: Ist es aktiviert, stellt Entra nur denen ein Token aus, die Sie der Anwendung ausdrücklich zugewiesen haben. Das ist Ihre Whitelist, verwaltet im Mandanten.

Ein Nachtrag zu Gruppen: Wenn Sie AD-Gruppen auf GLPI-Profile abbilden möchten, beachten Sie, dass Entra die Gruppen als GUID sendet, nicht als lesbaren Namen. Entweder Sie verwenden App Roles (Namen, die Sie selbst festlegen), oder Sie übersetzen die GUID in der Zuordnung. „IT“ zu erwarten und 7a2f... zu erhalten, ist die dritte häufige Überraschung.

Betriebs-Checkliste: was in der Produktion bricht

SSO ist kein „einrichten und vergessen“. In unserem Betrieb kommt jede Umgebung mit SSO mit diesen überwachten Punkten ins Inventar, denn sie sind es, die den Login lahmlegen, ohne dass jemand etwas angefasst hat:

• Ablauf des Client Secret (OIDC) oder des Signaturzertifikats (SAML): die Ursache Nummer 1 für „SSO funktioniert plötzlich nicht mehr“. Das Entra-Secret läuft ab (nach 6 bis 24 Monaten); halten Sie das Datum fest und erneuern Sie es rechtzeitig.
• Serveruhr (SAML): Die Assertion hat ein Gültigkeitsfenster; driftet die Uhrzeit ab, lehnt GLPI mit „assertion not yet valid“ ab. Halten Sie NTP/chrony aktiv (timedatectl status).
• Wechsel von URL/Domain: Hat sich die GLPI-Domain geändert? Aktualisieren Sie die Redirect-URI in Entra und die url_base in der Datenbank im selben Deployment.
• Lokaler Fallback: Halten Sie mindestens ein lokales Administratorkonto aktiv. Fällt der IdP aus, kommen Sie weiterhin über den klassischen GLPI-Login hinein.

Bei NexTool konfigurieren und betreuen wir SSO (Entra ID, Google Workspace und LDAP/AD) in GLPI-Umgebungen von Kunden, mit dokumentiertem Inventar der Ablaufdaten und dokumentiertem Fallback – damit der Login nicht zur Bereitschaft wird. Wenn Sie dieses Konzept auf Ihre Umgebung anwenden möchten, sprechen Sie mit uns über den GLPI-Betrieb.

Geprüft vom Team von NexTool Solutions.