Skip to the main content.

LDAP-Integration mit i-doit

Die Anbindung eines Verzeichnisdienstes an i-doit bietet Ihnen viele Vorteile. Ob Active Directory, OpenLDAP oder Novell Directory Services: Nahezu jeder verbreitete Verzeichnisdienst wird unterstützt. Benutzer, Gruppen und Computer werden durch die Anbindung über LDAP/LDAPS regelmäßig in i-doit importiert und aktualisiert. Da wir immer wieder Fragen zum Thema Active Directory erhalten, fassen wir hier die wichtigsten Informationen und Best-Practice-Konfigurationen für Sie zusammen.

 

Welche Vorteile bringt eine Anbindung?

 

Wer sein Active Directory ohnehin pflegt, spart sich durch die Anbindung eine doppelte Pflege der Stammdaten. Je mehr Benutzer sich in in Ihrem AD befinden, desto mehr Zeit sparen Sie.

Darüber hinaus werden Gruppen aus dem Active Directory übernommen oder auf Gruppen in i-doit gemappt. Dadurch werden Berechtigungen auf Basis der AD-Gruppenzugehörigkeit erteilt. Wenn ein Nutzer einer anderen Gruppe im AD zugeordnet wird, wirkt sich das auf seine Berechtigungen in i-doit aus. Dies ist z. B. bei der Einstellung neuer Mitarbeiter hilfreich. Durch Anlegen des neuen Mitarbeiters in der jeweiligen AD-Gruppe erhält er automatisch Zugriff auf die Informationen, die er für seine Aufgaben benötigt.

 

LDAPS Zertifikat anlegen

 

Für die Nutzung von LDAPS wird ein Zertifikat benötigt. Dieses muss den Anforderungen entsprechen, um für die Kommunikation zwischen i-doit und dem AD-Server genutzt werden zu können.

Je nachdem welche Zertifikate Sie im Einsatz haben, weicht hier der Export ab.

 

01-ldap-zertifikat-erstellen

 

Zertifikat Mindestanforderungen
SHA256, Version V3, Min 2048 Bits, Einsatzzweck Client- / Server Authentication
Hinweis: Sollten Sie das Zertifikat “DER-encoded” exportieren, müssen Sie es z.B. über openssl neu encoden.

 

Nach dem Export laden Sie das Zertifikat auf den i-doit Server in das folgende Verzeichnis hoch:

/usr/local/share/ca-certificates

 

LDAPS Zertifikat installieren

 

Das Zertifikat muss nun noch von der Dateiendung .cer auf .crt geändert werden. Nachdem das Zertifikat hochgeladen wurde, muss das Zertifikat noch in den ca certificates aktualisiert werden.

update-ca-certificates

 

Zertifikat testen

 

Um das Zertifikat zu testen, bietet sich zum Beispiel gnuTLS an. Dieses können Sie z. B. unter Debian mit folgendem Befehl installieren:

apt-get install gnutls-bin

Danach kann geprüft werden, ob das Zertifikat auf Port 636 für den angegeben Domainnamen (dcbw1.i-doit.com) gültig ist.

gnutls-cli –print-cert -p 636 –x509cafile /etc/ssl/certs/ca-certificates.crt dcbw1.i-doit.com

Als Ergebnis sollte das Zertifikat mit einer Meldung ausgegeben werden:

– Status: The certificate is trusted.
– Successfully sent 0 certificate(s) to server.
– Description: (TLS1.2)-(ECDHE-SECP384R1)-(RSA-SHA256)-(AES-256-GCM)
– Session ID: 3A:4C:00:00:7E:DB:D4:D0:8E:AC:4B:E5:EA:14:4F:EA:71:8B:46:E1:49:65:8A:F5:A3:05:BD:43:0B:66:21:E8
– Options: extended master secret, safe renegotiation,
– Handshake was completed

Andernfalls wird Ihnen eine Fehlermeldung wie hier ausgegeben:

signed using RSA-SHA1 (broken!)
Status: The certificate is NOT trusted. The certificate chain uses insecure algorithm.

In diesem Fall müssen Sie ein sicheres Zertifikat erstellen, das den Anforderungen entspricht.

 

LDAPS auf Windows Server testen

 

Prüfen Sie auf Seiten des Windows-Server, ob Verbindungen akzeptiert werden. Dazu klicken Sie mit der rechten Maustaste auf das Windows-Icon und dann auf „Ausführen“. Geben Sie “LDP” ein, um das LDP-Tool zu öffnen.

 

02-ldap-ldp-aufrufen

 

Als Server wird hier der DC auf Port 636 SSL angegeben.

 

03-ldap-ltd-ausfuehren

 

LDAPS im Webinterface testen

 

Unter Verwaltung -> Schnittstelle / externe Daten  -> LDAP -> Server muss der LDAP Server angelegt werden. Für LDAPS sollte Port 636 und unter TLS “LDAPS” angegeben werden.

 

04-ldap-ldaps-im-webinterface

 

Benutzer und Gruppenfilter

 

Nicht immer möchte man sämtliche Benutzer und Gruppen aus dem AD auch in i-doit vorfinden. Oft reicht es, die Benutzer auszuwählen und die Benutzergruppen z.B. explizit anzugeben oder nach OU’s zu filtern.

Dazu können in der LDAP Server-Konfiguration verschiedene Filter verwendet werden.

Beispiel: Konfiguration der Gruppen über distinguishedName, um diese explizit anzugeben.

 

05-ldap-bennutzer-und-gruppenfilter

 

Separaten Benutzer anlegen: ldapsync

 

Für die Nachverfolgung von Änderungen sollte ein separater Benutzer über das Webinterface angelegt werden. Dieser wird dann bei sämtlichen Änderungen im i-doit Logbuch als Nutzer angezeigt. Bedenken Sie besonders bei der Nutzung mehrerer Schnittstellen und Automationen, dass Änderungen nachvollziehbar bleiben. Wenn wir für alle genutzten Schnittstellen derselbe Benutzer genutzt wird, ist es bei auftretenden Fehlern schwer, die Ursache zu ermitteln.

 

06-ldap-personen-ldap-sync

 

Über das Webinterface erstellen wir einen neuen Benutzer und vergeben ein Passwort. In diesem Beispiel nennen wir den Benutzer “ldapsync”.

Dieser Benutzer erhält keine Admin-Rechte. Ihm wird lediglich unter Verwaltung -> Rechtesystem -> Rechtevergabe -> Verwaltung die Berechtigungen zum Ausführen des SyncCommands erteilt.

 

07-ldap-berechtigungen-ldap-benutzer

 

Diese Benutzerdaten tragen wir später im oberen Teil der Konfigurationsdateien ein, damit diese beim sync verwendet werden.

 

08-ldap-i-doit-logbuch

 

Die Änderungen sind dann im i-doit Logbuch bestens ersichtlich. Alles, was über die LDAP Schnittstelle geändert wird, ist dem “ldapsync” Benutzer zugeordnet.

 

09-ldap-kategorieerweiterungen

 

Über die Kategorieerweiterungen können bis zu 8 zusätzliche Attribut-Felder aus dem AD angesprochen und importiert werden.

 

Konfigurationsdatei anlegen

 

Navigieren Sie auf der Shell in das Installationsverzeichnis von i-doit. Für gewöhnlich dürfte sich dieses unter /var/www/html/ befinden. Hier wechseln wir in das Verzeichnis

/src/handler/config/

Wichtig:
Wenn die .ini Datei im i-doit Ordner angelegt wird, muss in der .htaccess Datei dieser Code hinzugefügt werden. Es ist auch möglich diese .ini Datei außerhalb des Web Verzeichnisses abzulegen.

## Deny access to all ini files…
<Files "*.ini">
Require all denied
</Files>

Nun legen wir eine neue Konfigurationsdatei mit dem Namen ldap-sync.ini an.

nano /var/www/html/src/handler/config/ldap-sync.ini

Unsere Konfigurationsdatei sollte über die entsprechenden Parameter verfügen um die Attribute aus dem AD zu mappen.

[commandArguments]
[commandOptions]
user=ldapsync
password=password123
tenantId=1

[additional]

import_rooms=true
defaultCompany=“
deletedUsersBehaviour=disable_login
disabledUsersBehaviour=disable_login

; LDAP Attributes are individual. This default configuration is prepared for Active Directory:

attributes[department]=department
attributes[phone_company]=telephoneNumber
attributes[phone_home]=homephone
attributes[phone_mobile]=mobile
attributes[fax]=facsimileTelephoneNumber
attributes[description]=info
attributes[personnel_number]=initials
attributes[organization]=company
attributes[street]=streetAddress
attributes[city]=city
attributes[zip_code]=postalCode
attributes[function]=title
attributes[service_designation]=title

;Kategorieerweiterung fuer Personen

attributes[custom_1]=objectSid
attributes[custom_2]=sn
attributes[custom_3]=homePhone
attributes[custom_4]=mobile
attributes[custom_5]=info
attributes[custom_6]=manager
attributes[custom_7]=physicaldeliveryofficename
attributes[custom_8]=company
autoReactivateUsers=false
ignoreUsersWithAttributes[]=“sn“
ignoreUsersWithAttributes[]=“givenName“
syncEmptyAttributes=true
ignoreFunction=empty

Sollten Sie wie oben beschrieben eine ldap-sync.ini für den Import verwenden, müssen Sie die Attribute entsprechend dort festlegen. Folgende Einträge in der ldap-sync.ini festlegen:

attributes[custom_7]=physicaldeliveryofficename attributes[custom_8]=company

Nun müssen wir den LDAP-sync ausführen damit die neuen Attribute übertragen werden. Dies können wir auf dem CLI über die Console.

/usr/bin/php /var/www/html/console.php ldap-sync –config /var/www/html/src/handler/config/ldap-sync.ini

oder ohne Konfigurationsdatei

/usr/bin/php /var/www/html/console.php ldap-sync –user ldapsync –password password123 –tenantId 1 –ldapServerId 1

 

Sicherheitsgruppen aus dem AD auf Personengruppen in i-doit Mappen

 

Neben dem reinen Import von Benutzern und Gruppen können auch Sicherheitsgruppen aus dem AD auf Personengruppen in i-doit gemappt werden. Dafür kann es ganz unterschiedliche Use-Cases geben, wie z. B.

  • Die IT-Administratoren der IT-Abteilung sollen auch automatisch entsprechende Berechtigung in i-doit erhalten.
  • Eine bestimmte Abteilung soll z.B. nur Lesezugriff auf i-doit erhalten

Für diesen Use-Case werden wir die Mitarbeiter aus der Buchhaltung in die Gruppe “reader” aus i-doit mappen.

 

 10-ldap-ad-backofficegruppe

 

In unserer OU “Backoffice” befinden sich 2 Nutzer und eine Sicherheitsgruppe für das Backoffice. In dieser Gruppe befindet sich auch “Birte Neuling”, die zwar im Vertrieb tätig ist, aber häufig Tätigkeiten im Backoffice mit übernimmt.

Diese Sicherheitsgruppe werden wir nun auf die Gruppe “reader” in i-doit mappen.

Dazu wechseln wir in die Personengruppe und gehen in die Stammdaten. Hier finden wir das Feld LDAP-Gruppe (Mapping), in das wir nun den Namen der Gruppe aus dem AD eintragen. Statt des Namen kann auch die objectSID der Gruppe verwendet werden.

 

11-ldap-ad-backofficegruppe-idoit

 

Nachdem der LDAP-Sync ausgeführt wurde, werden die Benutzer in den angegeben Gruppen hinzugefügt. Dadurch erhalten Sie die Berechtigungen der Personengruppe in i-doit.

 

12-ldap-ad-backofficegruppe-nutzer

 

Personen zu Standorten mappen

 

Eine etwas komplizierte Angelegenheit ist es, Personen zu Standorten zu Mappen. Als Standort könnte hier zum Beispiel das Firmengebäude oder ein bestimmter Raum interessant sein. Hierfür könnte man nun mit etwas Programmierarbeit ein Array über die i-doit API zusammenstellen. Dieses legt erst alle Benutzerdaten an und schreibt danach in den Standort.

Es geht jedoch auch deutlich einfacher und ganz ohne Programmierkenntnisse.

Gehen wir strukturiert vor. Zuerst einmal muss identifiziert werden, in welchem Attributfeld der zukünftige Standort bei den Nutzern eingetragen wurde. Dies kann z.B. das Attribut “Büro” oder “Firma” sein.

Wichtig: Der Standortname muss identisch mit den Objektnamen in i-doit sein. Möchten Sie, dass der Benutzer später automatisch Ihrem “Raum-EG-002” zugeordnet wird? Dann muss der Eintrag im AD genau wie der Objekttitel in i-doit lauten.

 

13-ldap-ad-raum

Für eine Raumangabe wird üblicherweise
das Feld Office/Büro verwendet.

14-ldap-ad-raum-eigenschaften

 Dieses wird als Attribut
“physicalDeliveryofficeName” im AD geführt.

15-ldap-ad-unternehmen

Für die Zuordnung zu einem Unternehmen / Organisation
ist das Attribut Firma/Company häufig im Einsatz.

16-ldap-ad-unternehmen-attribute

Dieses wird im AD als “company” geführt.

 

Diese Attribut-Werte tragen wir in der ldapsync.ini oder in der Verwaltung unter CMDB Einstellungen -> Kategorieerweiterungen in Feld 7 und 8 ein. Dadurch werden beim nächsten ldap-sync die entsprechenden Attribute aus dem AD mit übernommen.

Wichtig: Durch Nutzung einer INI-Konfigurationsdatei werden die Kategorieerweiterungen aus dem Webinterface nicht genutzt.

 

Report erstellen

 

Die Daten aus dem AD befinden sich nun in der CMDB. Hier können diese nun automatisiert weiterverarbeitet werden. Wir möchten nun erreichen, dass der Benutzerstandort in den Stammdaten im Feld Custom_7 auf die Kategorie Standort übertragen wird. Haben Sie diese noch nicht aktiviert, öffnen Sie den “Quick Configuration Wizard” unter Verwaltung -> CMDB-Einstellungen und aktivieren Sie die Kategorie “Standort” für den Objekttyp “Personen”.

Hinweis: Nach demselben Prinzip könnten Sie natürlich auch vorgehen, um einem Benutzer einen Arbeitsplatz zuzuweisen, einen logischen Standort anzugeben oder ihm ein Gerät zuzuordnen.

Wir wechseln nun in den Report Manager und erstellen eine neue Kategorie für Automationen. Über diese Kategorie können wir später über das Rechtesystem steuern, welche Personengruppen / Benutzer darauf Zugriff erhalten sollen.

 

17-reportkategorie-automationen-berechtigungen“Normale” Benutzer sollten keinen Zugriff auf die Berichte erhalten, um unbedachten Änderungen vorzubeugen. Die Berechtigungen können für Benutzer oder Gruppen erteilt bzw. entzogen werden.

 

In dieser Kategorie erstellen wir nun einen neuen Report. Dieser Bericht soll uns als Ausgaben den Objekt-Titel und die “physicaldeliveryofficename” aus den Stammdaten liefern. Als Bedingung geben wir an, dass nur Objekte vom Typ “Personen” ausgegeben werden sollen.

 

18-ldap-i-doit-report-abfrageeditor

 

Report als CSV-Datei exportieren

 

Diesen Report möchten wir nun regelmäßig exportieren. Auch dafür gibt es eine Funktion auf der Console, die uns diese Arbeit abnimmt.

Wichtig:
Wenn die .ini Datei im i-doit Ordner angelegt wird, muss in der .htaccess Datei dieser Code hinzugefügt werden. Es ist auch möglich diese .ini Datei außerhalb des Web Verzeichnisses abzulegen.

## Deny access to all ini files…
<Files "*.ini">
Require all denied
</Files>

Wir erstellen eine neue INI-Datei über das CLI.

sudo nano /var/www/html/src/handler/config/isys_handler_report-export.ini

Hier müssen wir genau wie bei der ldap-sync.ini die Zugangsdaten angeben. Darüber hinaus muss auch festgelegt werden, welcher Bericht exportiert werden soll.

 

19-ldap-report-id

 

[commandArguments]
[commandOptions]
user = ldapsync
password = password123
tenantId = 1
reportId = 55
exportPath = /var/www/html/automation
exportFilename = personenstandorte
exportFileType = csv

 

In dieser Konfiguration wird wieder der Nutzer “ldapsync” genutzt, folglich werden im Logbuch die Einträge wieder mit diesem Benutzer geführt. Damit dieser auch die Funktion “report-export” nutzen darf, müssen wir ihm auch hier wieder gesondert die Berechtigung erteilen. Diesmal für das Command “ReportExportCommand”

Die Report-ID finden Sie in der Übersichtsseite der jeweiligen Report-Kategorie. Diese ID muss zusammen mit dem Export-Pfad in der Konfigurationsdatei angegeben werden. Zu guter Letzt legen wir auch für diese Aufgabe einen Cronjob an. Dieser soll täglich um 6 Uhr ausgeführt werden.

sudo nano /etc/cron.d/automationen

Nach der Erstellung erfolgt die Konfiguration des Cronjob:

* 6 * * * www-data /usr/bin/php /var/www/html/console.php report-export –config /var/www/html/src/handler/config/isys_handler_report-export.ini >/dev/null 2>&1

Nun wird der Bericht täglich um 06:00 Uhr in das Verzeichnis /var/www/html/automation als personenstandorte.csv exportiert. Fast geschafft! Jetzt müssen die Daten nur noch regelmäßig importiert werden, um den Standort der Benutzer zu aktualisieren.

 

Standorte aktualisieren

 

Nun folgt das automatische Importieren dieser CSV-Datei, um die Standorte der Benutzer zu aktualisieren. 

Im ersten Schritt müssen wir ein CSV-Importprofil anlegen. Dies geht am einfachsten, indem man die erstellte CSV Datei herunterlädt und unter Extras -> CMDB -> Import -> CSV-Import erneut hochlädt.

Hier legen wir als Globaler Objekttyp “Personen” fest und Mappen die Spalten entsprechend den gewünschten Attribut-Feldern. In diesem Beispiel möchten wir nun den Standort auf “Räume” festlegen.

Wichtig: Diese Auswahl müssen wir nun als Profil speichern. Sie können ebenfalls einen Import durchführen, um zu testen, ob die Profilkonfiguration korrekt ist. 

Nachdem wir das Profil gespeichert ist, wechseln wir auf das CLI um die Profil-ID herauszufinden.

sudo -u www-data /usr/bin/php /var/www/html/console.php import-csvprofiles -u admin -p password456

Daraufhin werden alle Profile inkl. ID angezeigt.

List of profiles:

1: Mobile (mobile.csv)
2: Server (server.csv)
3: Clients (clients.csv)
4: standortepersonen (standortepersonen.csv)

Wichtig:
Wenn die .ini Datei im i-doit Ordner angelegt wird, muss in der .htaccess Datei dieser Code hinzugefügt werden. Es ist auch möglich diese .ini Datei außerhalb des Web Verzeichnisses abzulegen.

## Deny access to all ini files…
<Files "*.ini">
Require all denied
</Files>

Wir legen nun eine neue Konfigurationsdatei für den CSV-Import an.

sudo nano /var/www/html/src/handler/config/benutzerstandort-import.ini

In dieser geben wir wieder den Benutzer, den Pfad zur CSV-Datei und das anzuwendende CSV-Profil an.

[commandArguments]
[commandOptions]
user = ldapsync
password = password123
tenantId = 1
importProfileId = 4
csvSeparator = „;“
multiValueMode = column
importFile = /var/www/html/automation/personenstandorte.csv

[additional]

Auch hierfür benötigen wir wieder einen Cronjob, um diese Funktion automatisch anzustoßen.

sudo nano /etc/cron.d/automationen

Dieser Job soll etwas zeitverzögert um 06:30 Uhr täglich ausgeführt werden.

30 6 * * * www-data /usr/bin/php /var/www/html/console.php import-csv –config /var/www/html/src/handler/config/benutzerstandort-import.ini >/dev/null 2>&1

 

Automatische Zuweisung abgeschlossen

 

Die Benutzer werden nun automatisch den Standorten zugeteilt, die im AD geführt werden. Beim Aufruf der Standortsicht kann nun direkt beim Öffnen eines Raums erkannt werden, welche Personen sich in diesem befinden.

 

20-ldap-ergebnis

Werfen wir einen Blick auf den gesamten Prozess. Um 05:00 Uhr morgens wird ein Cronjob angestoßen, der eine Verbindung zum AD-Server aufbaut und gemäß Serverkonfiguration einen Abgleich mit den vorhandenen Benutzern und Gruppen durchführt. Dabei werden auch die Kategorieerweiterungen (z.B. physicaldeliveryofficename) mit den gewünschten Attributen aus dem AD vervollständigt. Der im Report Manager vorhandene Bericht wird mit den übermittelten Werten automatisch aktualisiert.

Um 06:00 Uhr wird der nächste Cronjob ausgeführt, der den Bericht als CSV-Datei exportiert. Um 06:30 Uhr wird der letzte Cronjob ausgelöst, der den exportieren Bericht über ein CSV-Profil importiert. Nun werden die Standorte der Nutzer aktualisiert und der Prozess ist abgeschlossen.

 

21-ldap-integration-prozess

 

Warum wurden zwischen dem AD-Import (05:00 Uhr) und dem zweiten Cronjob für den Report-Export 1 Stunde Zeit gelassen? Dauert der Importvorgang so lange?

Der Import ist stark von der vorhandenen / genutzten Infrastruktur abhängig. Normalerweise benötigt der Vorgang für ca. 2500 Personen und Gruppen etwa 1 – 2 Minuten. Wenn Server jedoch über entfernte VPN-Netzwerke angefragt werden oder das Netzwerk stark ausgelastet ist (wenn z. B. Backups parallel durchgeführt werden), kann dies länger dauern. 

Empfehlung: Machen Sie einen Testlauf und prüfen Sie wie lange der Import tatsächlich benötigt. Sie sollten dennoch etwas Pufferzeit einplanen, falls das Netzwerk Auslastungsspitzen unterliegt.

 

Haben Sie Fragen oder Anregungen?

 

Wir hoffen, Ihnen hat dieser kleine Guide für die LDAP-Integration mit i-doit gefallen. Weitere Informationen zum Thema „LDAP-Integration“ finden Sie auch in der i-doit Knowledgebase. Sollten Sie Fragen oder Anregungen haben, kommen Sie gerne auf uns zu.

Server-Dokumentation mit i-doit

Die Server-Dokumentation umfasst die Erfassung und Speicherung wichtiger Informationen über die Server-Infrastruktur eines Unternehmens. Dazu gehören...

Jetzt mehr lesen

i-doit pro Add-on OCS: Effiziente IT-Inventarisierung leicht gemacht

Mit i-doit pro verfügen Unternehmen über ein mächtiges Tool, mit dem Sie Ihre gesamte IT-Infrastruktur zentral dokumentieren können. Eine umfassende...

Jetzt mehr lesen

Humans4help und synetics schließen eine Partnerschaft

Paris/Düsseldorf, Dezember 2023 - Humans4help, ein führender französischer Gründerkonzern für digitale Transformation mit Fokus auf...

Jetzt mehr lesen