Seite wählen

NETWAYS Blog

User aus LDAP in Icinga Director Importieren

Ich hatte das Vergnügen mich etwas mit dem Icinga Director zu beschäftigen dabei war eine der Aufgabenstellungen die User aus unserem LDAP in den Director zu Importieren. Im Folgenden werde ich erläutern, welche Schritte notwendig sind, um dies zu tun. Dabei ist zu beachten, dass jede LDAP-Umgebung anders aussieht und diese nicht ganz genau für jede passen.

Zuerst legen wir im Backend an, woher der Director sich die Daten ziehen soll. Das tun wir in der resources.ini, welche unter /etc/icingaweb2/ liegt.
Dort fügen wir das Untenstehende ein und passen die Daten an unsere LDAP-Umgebung an.

[ActiveDirectory]
type = "ldap"
hostname = "example.com“
port = "389"
encryption = "starttls"
root_dn = "dc=example,dc=com"
bind_dn = "cn=serviceuser,ou=users,dc=example,dc=com"
bind_pw = "password"
timeout = "5"

Wenn das geschafft ist, wechseln wir zu Icinga Web 2 und gehen dort auf Configuration > Application > Resources und klicken dort auf ActiveDirectory um unsere Konfiguration zu überprüfen. Dort steht dann das, was wir gerade in die ressources.ini eingetragen haben. Natürlich kann dies auch gleich hier grafisch konfiguriert werden, aber der nächste Schritt muss eh auf der Kommandozeile erfolgen.

Die Vertrauenstellung zu Certificate Authority (CA) des Active Directory funktioniert überall ein bisschen anders:
Auf CentOS sind die LDAP-Clienttools gegen OpenSSL und Mozilla NSS gelinkt, heißt sie nutzen den zentralen Truststore und man kann die eigene CA folgendermaßen hinzufügen:

# cp /tmp/ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust extract

Möchte man den zentralen Truststore nicht nutzen, kann man in der ldap.conf den Pfad unter TLS_CACERTDIR abändern und die Methode c_hash nutzen:

# cd $(grep TLS_CACERTDIR /etc/openldap/ldap.conf | cut -f2 -d" ")
# cp /tmp/ca.pem .
# ln -s ca.pem $(/etc/pki/tls/misc/c_hash ca.pem | cut -f1 -d" ")

Alternativ dazu kann auch eine Datei mit allen zu vertrauenden Zertifikaten genutzt werden, wozu die Konfiguration auf TLS_CACERT geändert werden muss.

# vi /etc/openldap/ldap.conf
TLS_CACERT /etc/openldap/certs/ca.pem

Dies ist beispielsweise bei Ubuntu, wo die LDAP-Clients gegen GnuTLS gelinkt sind, der Standard und man kann das CA-Zertifikat an die Datei:

TLS_CACERT /etc/ssl/certs/ca-certificates.crt

Wenn das geschafft ist und man die Daten Quelle hinzu gefügt hat, muss man noch den PHP-FPM-Service neustarten via systemctl restart rh-php73-php-fpm.service. Ab jetzt wechselt man in das web und konfiguriert von dort aus weiter.

Danach wechseln wir auf den Icinga Director, und gehen zu „Import Data Sources“, dort fügt man dann eine neue Datenquelle hinzu. Diese könnten so aussehen:

Add import source

Hier noch zur Erklärung des LDAP-Filters:
(memberof=CN=icinga,OU=Groups,DC=example,DC=com)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(mail=*)
Hinter memberof steht der Distingushed Name einer Gruppe, in der alle gewünschten benutzer enthalten sind, die userAccountControl steht für gesperrte Benutzer und wird entsprechend durch das ! negiert und da wir per Mail benachrichtigen wollen muss auch das Attribute mail gesetzt sein.

Zum Schluss wieder auf Add drücken und dann ist auch schon die Import Source erstellt.

Um die Daten noch anzupassen können Modifiers unter Icinga Director > Automation > Import source > Modifiers hinzugefügt werden. In unserem Fall wollen wir die Gruppenmitgliedschaft in den Abteilungen in einem einfacheren Format.


 

Zunächst wechseln wir in Icinga Director > Users > Contacts > User Templates > Add um ein Template zu erstellen bevor wir mit der Sync Rule beginnen können.
Hier sind ein paar Felder wichtig, welche geändert werden sollten, wenn man nicht den Default von Icinga 2 übernehmen möchte. Das sind folgende:

 

Dann auf Add drücken und dann sollte auf der linken Seite „User aus LDAP – not in use – ” stehen.

Als nächstes oben in der Tabliste zu Groups wechseln und dort dann Usergruppen anlegen. (Beispielsweise jede Abteilung als eigene Gruppe o. ä. )

 

Danach wieder links auf Icinga Director > Synchronize > Add, dort muss dann ein Rule name, Object Type, Update Policy sowie Purge eingestellt werden. Zum Schluss wieder Add drücken.

Damit ergibt sich folgende Liste an Properties für den User.

Jetzt noch die Properties setzen diese sind wieder in der Tablist zu finden. Hier müssen folgende Eigenschaften für jede Property gesetzt werden:

Jetzt muss nur Import und Synchronisation einmal gelaufen sein und das wars. Schon sind alle Benutzer aus dem LDAP in Icinga und können ggf. benachrichtigt werden.

Nathaniel Donahue
Nathaniel Donahue
Technical Service Manager

Nathaniel hat 2022 seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS erfolgreich abgeschlossen. Seitdem unterstützt er sein Team im Bereich Operations vor allem beim Betriebsconsulting. In seiner Freizeit ist Nathaniel gerne unterwegs mit Freunden oder reist in der Gegend herum. Ansonsten schnappt er sich gerne mal sein Fahrrad oder geht Schwimmen.

Change Your AD Password easily via OWA

In many environments, Microsoft Active Directory is used to manage users, their roles and permissions and of course their passwords.
When you have set up an  Exchange Server as well, you may want to provide your users with the Outlook Web App. Here also users without Microsoft Windows are able to tune their mail settings and their Active Directory passwords, too.
Sometimes the method may not be completely clear, so please feel free to use this following guide whenever you need to.
Disclaimer: The screenshots display a German OWA and my GIMP skills are, well, improvable.
First you need to login. Please don’t forget to add your domain name.

Then find the small gear and click it.

Use the drop down and navigate to „change password“

You’ll now be prompted to enter your old (1) and your new password twice (2,3). Hit „Save“(4) for using your new password and you’re done!

Tim Albert
Tim Albert
Senior Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

Icinga Director: Active Directory User als Kontakte importieren

Heute erklären wir euch im Schnelldurchlauf wie man Kontakte aus dem Active Directory in den Icinga Director importiert.
Als Grundlage konfigurieren wir das Active Directory als Ressource im Icinga-Web 2
# vi /etc/icingaweb2/resources.ini
[active_directory]
type = "ldap"
hostname = "ms-ad.supercorp.com"
port = "389"
encryption = "none"
root_dn = "DC=supercorp,DC=com"
bind_dn = "CN=bind_user,OU=Users,DC=supercorp,DC=com"
bind_pw = "*******"

Danach muss der Import im Icinga Director erstellt werden. Dazu geht ihr im Icinga Director auf Automation => Import Source => Add und legt den Import wie folgt an:

Wichtig ist hierbei der LDAP Filter mit mail=*. Dadurch werden nur Benutzer importiert die auch eine E-Mail-Adresse haben. Bei Benutzern ohne E-Mail-Adresse würde der spätere Sync fehlschlagen.
Im Anschluss erstellt ihr den dazu passenden Sync unter Automation => Sync Rule => Add


Die Customvariable var.import wird zwar nicht zwingend benötigt, ich verwende sie aber um später die Möglichkeit zur Filterung zu haben. So kann man (neben der History Funktion) erkennen ob ein Kontakt manuell oder vom Import angelegt worden ist.

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker und renoviert, baut und bastelt als Heimwerker an allem was er finden kann.

Apache und viele, viele User

Kollege Lennart hat zwar schon dankenswerterweise einiges zu Apache, Openldap und Active Directory geschrieben trotzdem ist dieses Thema noch nicht völlig erschöpft. Ich möchte diesmal die Anleitung liefern wie man mehrere verschiedene LDAP-Server bei der Apache-Authentifizierung nutzt. Auch nutzbar ist diese Lösung um mehrere Einstiegspunkte in den gleichen Verzeichnisbaum zu bekommen.
Die einen fragen sich nun wo soll da bitte die Schwierigkeit sein, die anderen wozu sollte man so etwas brauchen. Die Schwierigkeit hierbei stellt der LDAP-Provider dar, der nur eine LdapAuthURL akzeptiert. Der Grund dafür mehrere zu brauchen können mehrere Verzeichnisdienste für verschiedene Anwendergruppen sein oder auch ein Struktur im Active Directory, bei der sonst neue Gruppen gebildet und gepflegt werden müssten oder ein Verschieben der Benutzer innerhalb des Baums aus organisatorischen oder gar technischen Gründen nicht möglich ist.
Die Lösung hierfür heißt mod_authn_alias (oder ab 2.4 mod_authn_core). Mit diesem Modul lässt sich ein Alias für einen Authentfizierungs-Provider erstellen, so dass es möglich wird diesen mehrfach zu verwenden. Die Konfiguration könnte dann folgendermaßen aussiehen:

<AuthnProviderAlias ldap admins>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=admins,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias>
<AuthnProviderAlias ldap entwickler>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=entwickler,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias> 

Diese Konfiguration muss einmalig und vor der Verwendung eingebunden werden. Daher bietet sich ein Dateiname wie 00provider.conf an mit dem die Konfiguration im Apache-Konfigurationsverzeichnis abgelegt wird.
Für die Verwendung bietet es sich dann eine Datei auth.inc anzulegen, die dann in den einzelnen Konfigurationsdateien für die Webanwendungen mit include eingebunden werden kann. Diese sieht dann beispielsweise so aus:

AuthName "Icinga Access"
AuthType Basic
AuthBasicProvider admins entwickler
Require valid-user

Wer zusätzlich noch einen Fallback für einen anderen Provider benötigt kann diesen einfach hinzufügen und je nach Apache-Version einen Blick auf AuthzLDAPAuthoritative (2.2) oder RequireAny (2.4) werfen.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Weekly Snap: Source Code Pro, Apace & Active Directory, JMX

weekly snap 11 – 15 February introduced new products at our shop and shared tips for programmers and sys admins alike.
Eva began by counting 65 days down to the OSDC with Jochen Lillich’s presentation on Kanban.
Lennart then solved an Apache and Active Directory configuration problem as Johannes trialled Adobe’s coding font, Source Code Pro.
Ronny followed with his quick guide to activating JMX and Christian announced the arrival of new power distribution units by Gude to our online hardware store.
Finally, Georg gave the adjudication reins over to our readers to decide which poet should win our competition for two TKS Supermicro 2HE servers.