26 – 30 November ended the month with mini guides on Distributed Shell and LDAP, Google Analytics and Prestashop, alongside some familiar hardware, InGraph and news from Down Under.
Eric gave a sneak preview to features planned for coming releases of InGraph, concluding The Ultimate Guide to InGraph.
Stefan fiddled with batch mode clusters via ssh using Distributed Shell dsh, while Lennart showed how to use LDAP filters for authorisation settings in recursive groups.
Georg then showed how to make the most of Google Analytics in Prestashop and introduced one of his best sellers, the HWg-STE network thermometer.
On sabbatical, Birger got settled into Sydney and reflected on a successful Movember 2012 as Bernd shared his thoughts on Africa’s internet landscape.
NETWAYS Blog
SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory
Heute soll sich dieser Blogeintrag also um Single Sign On im Apache- und Active Directory-Umfeld drehen. Ziel ist es, sich an einem Webserver per Kerberos-Ticket zu authentifizieren und nachgelagert zu prüfen, ob der Benutzer sich ebenfalls in der Gruppe befindet, dessen Mitglieder Zugriff auf die Wibsite erhalten dürfen.
Zuerst muss ein Benutzer im Active Directory angelegt werden. Danach erzeugen wir auf unserem Domain Controller einen Schlüssel und fügen diesem Benutzer eine PrincipalName hinzu. Also Verschlüsselung wählen wir RC4-HMAC, da dies von Windows XP unterstützt wird. Die ab Windows Server 2008 hinzugekommenden Verschlüsselingen auf AES basierend werden erst von Windows Vista und Windows 7 unterstützt.
ktpass -out apache2.keytab \
-mapuser www@NETWAYS.DE \
-princ HTTP/www.netways.de@NETWAYS.DE \
-pass login123 \
-ptype KRB5_NT_PRINCIPAL \
-crypto RC4-HMAC-NT \
In unserem Beispiel haben wir den Benutzer www angelegt. Unsere NS-Domäne lauetet netways.de und unser Kerberos-Realm NETWAYS.DE. Mit dem Kommando ktpass weisen wir nun diesem Benutzer über die Option -mapusr und -princ den PrincipalName HTTP/www.netways.de@NETWAYS.DE zu. Der Schlüssel erhält das Passwort login123 mit +rndpass kann man diesen auch zufällig erzeugen lassen. Erzeugt man den Schlüssel jedoch zufällig, ist es dann aber leider nicht möglich den Schlüssel auf dem Linux-Serverauf Korrektheit zu überprüfen.
Nachdem wir nun den Schlüssel erzeugt haben, kopieren wir die Datei apache2.keytab auf sicherem Wege auf unseren Webserver.
Die Kerberos-Client-Konfiguration /etc/krb5.keytab auf unserem Linux-Server sieht wie folgt aus:
[libdefaults]
default_realm = NETWAYS.DE
[realms]
NETWAYS.DE = {
kdc = dc.netways.de
default_domain = netways.de
ktpasswd_server = dc.netways.de
}
[domain_realm]
.netways.de = NETWAYS.DE
Unsere apache2.keytab können wir nun mit kinit auf Korrektheit prüfen.
kinit -t /etc/apache2/apache2.keytab HTTP/www.netways.de
Der PrincipalName kann im Vorfeld auch schon mit klist ermittelt werden.
klist -t -k /etc/apache2/apache2.keytab
Für den Apache Webserver werden noch drei zusätzliche Module benötigt. Die Module mod_ldap und mod_authnz_ldap, im Gegensatz zu mod_auth_kerb sind diese beiden Module Bestandteil vom Apache-Paket. Das Module mod_auth_kerb muss nötigenfalls selbst übersetzt werden.
a2enmod auth_kerb
a2enmod ldap
a2enmod authnz_ldap
Für unser Beispiel benötigen wir noch einen Active Directory Benutzer ads, um auf den LDAP-Server des DC zugreifen zu können. Außerdem die Gruppe ApacheAcces, deren Mitglieder auf unsere Website zu greifen dürfen.
AuthType Kerberos
AuthName "Kerberos Login"
KrbAuthRealm NETWAYS.DE
KrbServiceName HTTP
Krb5Keytab /etc/apache2/apache.keytab
KrbMethodK5Passwd on
KrbMethodNegotiate on
AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://dc.netways.de/dc=netways,dc=de?userPrincipalName"
AuthLDAPBindDN "cn=ads,cn=Users,dc=netways,dc=de"
AuthLDAPBindPassword ********
Require ldap-group cn=ApacheAccess,cn=Users,dc=netways,dc=de
Zu Abschuss nicht vergessen den Browser für den SSO-Zugriff zu konfigurieren. Beim Firefox geschieht dies durch den Aufruf der URL about:config.
network.negotiate-auth.trusted-uris .netways.de
Weitere Artikel zum Thema:
LDAP-Filter zur Autorisierung bei rekursiven Gruppen
Nochmal Apache und Active Directory
Lennart Betz
Senior Consultant
Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
OpenLDAP – Flaggschiff unter den OpenSource Verzeichnisdiensten
Ein Verzeichnisdienst gehört zu den Grundbausteinen jeder IT-Infrastruktur und dabei ist es ganz egal ob es sich um 20 oder 2000 Anwender im Unternehmen handelt.
Sinn und zweck von Verzeichnisdiensten
In der Regel dient er als hierarchische angeordnete Ablage zur zentralen Speicherung von Benutzerdaten, der Gruppenverwaltung, dem Rechtemanagement oder dem bereitstellen von Applikationen.
Meist liegt dieser Datensammlung eine Datenbank zu Grunde welche die Informationen speichert und über verschiedene Netzwerkprotokolle (DAP, LDAP, LDAPS, Kerberos, NCP etc.) zur Verfügung stellt. Weil es in der Datenbank selten große Schreibvorgänge gibt ist sie dahingehend optimiert beim reinen Lesezugriff schnell zu antworten.
LConf nutzt diese Funktionalität ebenfalls, dient aber nicht zum speichern von Benutzerdaten sondern, dank eines angepassten Schemas, zum speichern der Nagios- oder Icingakonfigurationsdaten. Durch die hierachische Vererbung von Objekten lassen sich so schnell eigene und effiziente Strukturen aufbauen.
OpenLDAP ist DER Verzeichnisdienst unter den OpenSource Verzeichnisdiensten und muss sich schon lange nicht mehr hinter propertären Lösungen wie ActiveDirectory (Microsoft) oder eDirectory (Novell) verstecken. Auch eine möglicher Einsatz als Metadirecotry Server ist möglich. In einem solchen Szenario würden Identitätsdaten mittels verschiedener Konnektoren zu anderen Verzeichsdiensten repliziert bzw. synchronisiert.
Das OpenLDAP Projekt gibt es seit 1998 und wird von drei Hauptentwicklern vorangetrieben (Weitere Informationen: http://www.openldap.org/project/).
OpenLDAP 2.4
Die aktuelle Version OpenLDAP 2.4 hat im Bereich Performance und Funktionalität zugelegt so das dieser auch oft als zentrale Instanz in IdentityManagement Konstrukten eingesetzt wird.
Ein großer Vorteil ist das relativ neue Konfigurationsschema bei dem die Einstellungen direkt im DIT (Directory Information Tree) landen. Viele Konfigurationsänderungen können auf diese Weise ohne einen Neustart des LDAP-Servers übernommen werden. Neben diesen Features wurde das Replikationsschema um zwei weitere Möglichkeiten erweitert die jede denkbare Replikation erlauben: MirrorMode und N-Way MultiMaster
Beim MirrorMode lassen sich LDAP Server verteilt über beispielsweise zwei Standorte aufbauen und erlauben eine Replikation der Daten über zwei Provider.
In diesem Fall hat der erste Provider die Verbindung zu jedem MasterServer, schreibt aber die Daten nur auf einen Server, welcher diese wiederum repliziert. Der zweite Provider läuft als Standby mit und fängt den ersten Provider auf sollte dieser ausfallen und führt die restlichen Schreibvorgänge solange durch bis Provider 1 wieder online ist.
Der N-Way MultiMaster Replikationsweg ermöglicht es mehrere aktive Master Replikationen zu schalten welche in N-Wegen zueinander stehen können und wiederum Slaveserver besitzen können.
Neben dem „Standardaufbau“ von Master / Slave Konstrukten lassen sich mit OpenLDAP auch LDAPProxy Server zwischenschalten um ggf. an Standorten die Administration in den Slave hinein zu ermöglichen ohne Zugriff auf den Master zu benötigen.
Mittels dieser verschiedenen Architekturmöglichkeiten die OpenLDAP bietet lassen sich viele beliebige Szenarien abbilden.
OpenLDAP ermöglicht ein Onlinebackup der Datenbank (ldapsearch) oder ein Offlinebackup (slapcat).
Zudem nutzt OpenLDAP Checkpointing, welches die Fehlertoleranz anhand von einem Snapshot ähnlichem Mechanismus bietet um im Fehlerfall oder Absturz Datenbankinkonsistenz zu vermeiden.
Die Replikation sowie das Laufzeitverhalten lässt sich mit verschiedenen Nagios und Icinga Plugins monitoren.
OTRS an mehreren Standorten
Wenn nicht nur die Nutzer an einem Standort, sondern mehrere über eigene Domänen zu authentisierende Nutzergruppen OTRS nutzen sollen, bedarf das nur wenig Konfiguration. Dadurch kann man auch in heterogenen Umgebungen mittels eines einheitlichen Ticketingsystems die zum Teil Standortübergreifenden Anfragen an die IT-Abteilungen geeignet kanalisieren.
Mit diesen und einigen weiteren Mitteln ist es uns auch gelungen das Ticketsystem bei der Wasser- und Schifffahrtsdirektion Süd an die dortigen Bedürfnisse anzupassen.
OSMC Ticker: LConf verwaltet Monitoring Konfigs mit LDAP
Unser Kollege Michael Streb hält gerade seinen Vortrag über das Tool LConf zur Speicherung von Konfigurationen für Nagios oder Icinga in einem LDAP Backend. Das Tool ist im Rahmen unserer Projekts bei der AUDI AG entstanden und wird unter der GPL veröffentlicht. Vor der Entscheidung ein eigenes Tool mit LDAP stand der Vergleich verschiedener Lösungsmöglichkeiten, wie direkte Pflege von Konfigurationsdateien, Verwendung eines bereits bestehenden Konfigurationstools oder sogar Subversion. Für die gegeben Anforderungen, insbesondere Benutzerrechte auf unterschiedliche Teile der Konfiguration vergeben zu können, erwies sich LDAP als beste Wahl.
Nach einem kurzen Abriss der Features und Möglichkeiten geht es gleich in die technischen Details: Wie wird der LDAP Server installiert, wie das Schema importiert und mit welchen Tools lässt sich die Konfiguration dann auch wirklich verwalten. Das Tool selbst besteht nur aus einigen Scripten, so dass es selbst nicht installiert werden muss, aber es müssen einige Einträge im LDAP Verzeichnis selbst eingerichtet werden. Danach kann eine bestehende Nagios oder Icinga Konfiguration in die LDAP Datenbank importiert werden dabei kann das Tool sogar Gemeinsamkeiten in der Konfiguration erkennen und diese in eine übergeordnete OU verschieben. Dadurch werden quasi automatisch Template generiert. Anschliessend demonstriert Michael das Tool sogar live, importiert eine bestehende Konfiguration und zeigt wie sich die Konfiguration dann in einem LDAP Frontend wie beispielsweise dem Eclipse SDK administrieren lässt.
LConf kann auf unserem Software Portal http://netways.org/ heruntergeladen werden. Dort läuft auch unser Bug Tracker für Fehlermeldungen oder Verbesserungsvorschläge.
Julian Hein
Executive Chairman
Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.
