Wir haben ein Active Directory im Labor an ein GLPI 11 angebunden: 7 Benutzer in 1,4 Sekunden importiert, jeder mit dem richtigen Profil über die AD-Gruppe und Login mit dem Netzwerkpasswort. Bis hierhin lief alles wie erwartet. Das Problem zeigte sich, als wir einen ausgeschiedenen Mitarbeiter im AD deaktivierten: In GLPI blieb er aktiv, mit demselben Profil. Und die Konfiguration nachträglich zu ändern half nicht, weil GLPI die Austrittsregel nur beim ersten Erkennen des Austritts anwendet.
Sie nutzen Microsoft Entra ID (Azure AD) und möchten Single Sign-on im Browser? Lesen Sie SSO mit Microsoft Entra ID in GLPI. Dieser Artikel behandelt das lokale AD über LDAP.
Was die AD-Integration leistet
- Login mit dem Netzwerkpasswort: Der Benutzer meldet sich in GLPI mit demselben Login und Passwort wie in Windows an. Das Passwort wird nie in GLPI gespeichert.
- Import der Daten: Vorname, Nachname, E-Mail, Telefon, Position und weitere Felder kommen aus dem AD.
- Profil über die Gruppe: Autorisierungsregeln vergeben Profil und Einheit entsprechend der AD-Gruppe (Techniker, Manager, Benutzer).
- Synchronisierung: Änderungen im AD, etwa ein neues Telefon, eine neue Position oder ein Austritt, gelangen über die geplante Synchronisierung nach GLPI.
Das Labor
Wir haben einen Samba-Domänencontroller (kompatibel mit Active Directory) mit der Domäne ACME.TEST aufgesetzt, der fiktiven Firma Acme, drei Gruppen (GLPI-Tecnicos, GLPI-Gestores, GLPI-Usuarios) und acht Benutzern: sieben aktive und einen deaktivierten in einer OU für Ausgeschiedene. Auf der anderen Seite ein GLPI 11.0.7 zum Testen.
Schritt 1: das LDAP-Verzeichnis
Unter Einrichtung > Authentifizierung > LDAP-Verzeichnisse:
| Feld | Was wir verwendet haben | Warum |
|---|---|---|
| Server und Port | der Domänencontroller, 389 (636 mit LDAPS) | In der Produktion LDAPS oder StartTLS bevorzugen |
| BaseDN | OU=Acme,DC=acme,DC=test |
Beginnen Sie bei der OU der Personen, nicht an der Wurzel der Domäne |
| RootDN und Passwort | ein Dienstkonto nur mit Lesezugriff | Nie das Konto eines Administrators |
| Verbindungsfilter | (&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) |
Nur Personen und nur aktive Konten |
| Login-Feld | samaccountname |
Der kurze Windows-Login |
| Synchronisierungsfeld | objectguid |
Ändert sich nicht, wenn der Benutzer Namen oder OU wechselt |
| Gruppen | Suchtyp „In Benutzern“, Attribut memberof |
Um die AD-Gruppe in den Regeln zu verwenden |
Die Schaltfläche Testen prüft die Verbindung, bevor irgendetwas importiert wird.
Schritt 2: das Profil über die AD-Gruppe
Unter Verwaltung > Regeln > Regeln für die Zuweisung von Berechtigungen an einen Benutzer, eine Regel pro Gruppe:
Wenn der Benutzer aus diesem Verzeichnis kommt und memberOf enthält |
Erhält das Profil | In der Einheit |
|---|---|---|
CN=GLPI-Tecnicos, |
Technician | die des Unternehmens |
CN=GLPI-Gestores, |
Supervisor | die des Unternehmens |
CN=GLPI-Usuarios, |
Self-Service | die des Unternehmens |
Per Regel vergebene Berechtigungen sind dynamisch: Verlässt die Person die Gruppe im AD, entfällt das Profil bei der nächsten Synchronisierung.
Schritt 3: importieren und synchronisieren
Über die Oberfläche (Neue Benutzer importieren) oder über die Kommandozeile, die für die Zeitplanung entscheidend ist:
php bin/console ldap:synchronize_users --ldap-server-id=1 --deleted-user-strategy=1,0,1
Im Labor brachte der Import die 7 aktiven Benutzer in 1,4 Sekunden, und der deaktivierte blieb durch den Filter außen vor. Name, E-Mail und Telefon kamen aus dem AD, und jeder erhielt das Profil seiner Gruppe. Der Login mit dem AD-Passwort funktionierte, mit falschem Passwort wurde er verweigert.
Was passierte, als wir einen Mitarbeiter deaktivierten
Wir haben einen Benutzer im AD deaktiviert und die Synchronisierung ausgeführt, zunächst mit der Standardkonfiguration.
| Test | Ergebnis in GLPI |
|---|---|
| Im AD deaktiviert, Standardsynchronisierung | GLPI erkennt den Austritt, unternimmt aber nichts: Benutzer aktiv, gleiches Profil |
| Gleicher Benutzer, nächste Synchronisierung mit „deaktivieren“ | Nichts ändert sich: Er war bereits als aus LDAP gelöscht markiert |
| Anderer ausgeschiedener Benutzer, bereits mit „deaktivieren“ bei der ersten Synchronisierung | Benutzer deaktiviert und dynamische Profile entfernt |
| Im AD reaktivierter Benutzer, Synchronisierung mit „aktivieren“ | Ist wieder aktiv |
Zwei Schlussfolgerungen:
- Der Standard von GLPI ist, nichts zu tun mit Personen, die das AD verlassen (Strategie „0,0,0“). Ein ehemaliger Mitarbeiter behält ein aktives Konto in GLPI, bis es jemandem auffällt.
- Die Strategie greift in dem Moment, in dem GLPI den Austritt erkennt. Lief die erste Synchronisierung mit dem Standard, erfasst eine spätere Änderung der Konfiguration die bereits markierten Benutzer nicht. Diese müssen von Hand behandelt werden.
Konfigurieren Sie die Aktion für aus LDAP gelöschte Benutzer vor der ersten Synchronisierung (unter Einrichtung > Authentifizierung oder mit --deleted-user-strategy im Befehl). Die Kombination, die wir empfehlen, ist „1,0,1“: das Konto deaktivieren, die Gruppen behalten (für die Historie) und die dynamischen Berechtigungen entfernen.
Für die Rückkehr reaktiviert die Wiederherstellungsstrategie „3“ das Konto, wenn die Person im AD reaktiviert wird.
Ein Detail zum Standardprofil
Alle importierten Benutzer erhielten zusätzlich zum Profil aus der Regel auch das Standardprofil von GLPI (in unserem Fall Self-Service). Für Techniker stört das nicht, es erscheint aber beim Profilwechsel. Wenn Sie das nicht möchten, prüfen Sie vor dem Import, welches das Standardprofil von GLPI ist.
Checkliste
- Dienstkonto nur mit Lesezugriff für den RootDN.
- LDAPS oder StartTLS in der Produktion.
- BaseDN auf der OU der Personen und ein Filter, der deaktivierte Konten ausschließt.
objectguidals Synchronisierungsfeld.- Autorisierungsregeln je AD-Gruppe, mit festgelegter Einheit.
- Aktion für aus LDAP gelöschte Benutzer vor der ersten Synchronisierung konfiguriert („1,0,1“).
- Geplante Synchronisierung (Cron) mit
ldap:synchronize_users, mindestens täglich. - Test mit einem fiktiven Benutzer: im AD anlegen, Gruppe wechseln, deaktivieren und reaktivieren und GLPI bei jedem Schritt prüfen.
Sie brauchen Hilfe bei der Integration oder beim Audit von Zugriffen? Sprechen Sie mit dem Team. Um Profile und Berechtigungen zu verstehen, lesen Sie Profile und Berechtigungen in GLPI.
Test von NexTool am 4. Oktober 2026: Samba-Domänencontroller (kompatibel mit Active Directory) mit fiktiven Benutzern und GLPI 11.0.7 zum Testen. Das Labor wurde am Ende gelöscht. Verhalten der Synchronisierung im GLPI-Befehl selbst geprüft.
Kommentare
Die Kommentare zu diesem Beitrag stammen von GitHub (giscus). Beim Laden verbindet sich Ihr Browser mit GitHub; GitHub erhält dabei Ihre IP-Adresse und kann eigene Cookies setzen.
Um sie automatisch zu laden, aktivieren Sie funktionale Cookies