Wie kann ich einen Teil meiner Arbeit loswerden? – Oder: LConf und ACL

Da ich persönlich eher zu den faulen Menschen gehöre und sich bestimmt jeder Admin auch dazu zählen kann, will ich in diesem Blogpost darauf eingehen wie man zumindest die Aufgabe Monitoring ein wenig auf fleißige Kollegen oder auch Azubis und Praktikanten verschieben kann. Natürlich möchte man sich im Nachhinein nicht mehr Arbeit gemacht haben, indem man Fehlersuche betreiben muss, daher ist mein Ansatz: graphische Administration und eingeschränkte Berechtigungen.
Unser Werkzeug für graphische Administration LConf dürfte mittlerweile wohl bekannt sein. Wem dieses gar nichts sagt kann sich ja mal das Webinar anschauen. Kurz zusammengefasst verwendet LConf ein LDAP-Backend, bietet Vererbung und Templates sowie ein hübsches Frontend.
Gebe ich nun dem Azubi eine kurze Einweisung und volle administrative Rechte, sehe ich mich schon statt beim Feierabend-Bier beim Restore und anschließendem “Hätte ich’s bloß gleich selbst gemacht” und “Wenn etwas richtig gemacht werden soll, muss man es selber machen”. Und damit sich niemand diskriminiert fühlt, gilt das gleiche natürlich für alle anderen Kollegen wie Windows- oder Netzwerk-Admins. 😉
Diese Grundhaltung höre ich doch des öfteren bei Kunden und Schulungsteilnehmern, daher müssen also eingeschränkte Rechte her und dies ermöglicht LDAP zum Glück leicht mittels ACL. Voraussetzung hierfür ist ein Benutzer oder eine Gruppe innerhalb des LDAP. Da der LConf-Connection-Manager mir erlaubt eine Verbindung zu erstellen und dann einer Gruppe Zugriff auf diese zu erlauben, reicht mir ein Benutzer.
Diesen lege ich mir folgendermaßen an:

  1. Passwort-Hash generieren:
    # slappasswd
    New password: awesome
    Re-enter new password: awesome
    {SSHA}ZOmXcrADeKGkthMlJ3PZwKbyM8bnbP5t
  2. Datei user.ldif für den Import bauen:
    dn: cn=myuser,ou=users,dc=icinga,dc=lab
    objectClass: organizationalPerson
    cn: myuser
    sn: User
    description: My User
    userPassword: {SSHA}ZOmXcrADeKGkthMlJ3PZwKbyM8bnbP5t
  3. Benutzer mit administrativem Account einspielen:
    ldapadd -x -h localhost -D cn=admin,dc=icinga,dc=lab -W -f user.ldif

Nun muss ich mir überlegen wie meine Grundstruktur aussieht und worauf ich meinen Benutzer berechtigen will. Mein Ansatz ist hierbei dem Kollegen auf einen Teilbaum gemäß seiner Zuständigkeit schreibend zu berechtigen und Templates sowie grundlegende Objekte lesend zur Verfügung zu stellen. Hierfür müssen die Standard-Zugriffsregeln teilweise gelöscht werden bevor die neuen gesetzt werden, da diese in der gespeicherten Reihenfolge abgearbeitet werden.
Die Vorgehensweise ist hierbei:

  1. Datei access.xml für Import bauen:
    changetype: modify
    dn: olcDatabase={1}hdb,cn=config
    delete: olcAccess
    olcAccess: to dn.base="" by * read
    -
    delete: olcAccess
    olcAccess: to * by self write by dn="cn=admin,dc=icinga,dc=lab" write by * read
    -
    add: olcAccess
    olcAccess: to dn.base="dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.base="ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.base="ou=IcingaConfig,ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.subtree="ou=global,ou=IcingaConfig,ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.subtree="ou=Templates,ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.subtree="ou=myconfig,ou=IcingaConfig,ou=LConf,dc=icinga,dc=lab" by dn="cn=myuser,ou=users,dc=icinga,dc=lab" write
    -
    add: olcAccess
    olcAccess: to * by self write by dn="cn=admin,dc=icinga,dc=lab" write
  2. Importieren unter Nutzung der ldapi-Schnittstelle:
    ldapmodify -Y EXTERNAL -H ldapi:/// -f access.ldif

Nun noch in dem Wissen, dass die Kollegen nicht so leicht was kaputt machen können, die Verbindung im LConf-Frontend angelegt, die Kollegen berechtigt und eine Einweisung im Wiki hinterlegt. Danach heißt es dann heim zum Feierabend-Bier während die fleißigen Kollegen mit den neuen Rechten Hosts und Services ins Monitoring aufnehmen! 😉
In diesem Sinne viel Erfolg beim Verteilen der Arbeit und natürlich Prost!

Dirk Götz
Dirk Götz
Senior 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: Pyinotify, OpenLDAP & Birger's Sabbatical

11 – 15 June counted down to the OSMC and Birger’s sabbatical, but also shared a few tips on databases replication, working in VIM and a python library worth looking into.
Eva counted 128 days down to the OSMC 2012 with a video of Jens Schanz’s presentation on “Monitoring at Mueller Ltd. & Co.KG” and introduced the workshops on the conference eve.
While Dirk had fun with Pyinotify, Markus gave a quick tip on brightening the syntax in VIM, and Lennart shared his on what he dubbed N-way master replication for OpenLDAP.
Bound for his yearlong sabbatical, Birger bid farewell and started his “Birger Sabbatical” blog series. We wish him all the best!

Weekly Snap: OpenLDAP with ACL, NodeJS & Dev Tools Galore

23 – 27 January was filled with developer tools, in particular NodeJS as well as OpenLDAP, with a sys admin email tip to boot.
Martin offered a quick troubleshoot for the Mac error “Index Out Of Range Exception” that popped up as he installed SP2 on the company Exchange 2010.
Then in a development tag team, Angsar briefly reviewed the top tools for software developers with a good dose of scepticism, while Eric went into more depth on one of the better ones – NodeJS. With a quick guide to installation creating a simple .png, he gave the server side Java Script framework the thumbs up.
Finishing off the week, Philipp continued on his OpenLDAP roll, this time in working with ACL on 2.4.x versions.

OpenLDAP 2.4.x und die ACL

In vergangenen Blogposts habe ich erwähnt welche Möglichkeiten OpenLDAP 2.4.x bei der Replikation bietet und wie man neuerdings weitere Schema zu OpenLDAP hinzufügen kann.
Mit dem dynamischen Backend cn=config hat sich auch das bearbeiten der ACL (Access Control List) verändert.
Unter OpenLDAP < 2.4.x war die slapd.conf die richtige Anlaufstelle um Benutzern, Gruppen etc. den Zugriff auf bestimmte Attribute, Objekte, Teilbäume... zu ermöglichen. cn=config als dynamisches Backend fordert hier eine neue Vorgehensweise um die ACL zu administrieren.
Generell gibt es zwei Möglichkeiten neue Zugriffsrechte zu definieren oder bestehende zu ändern.

  • Änderungen direkt in das entsprechende Backend-LDIF eintragen (olcDatabase={1}hdb oder olcDatabase={1}bdb).
  • Änderungen über ein separates LDIF File mit ldapadd oder ldapmodify zu importieren.

Wie bei allen Dingen die im Backend geändert werden gilt auch hier, alle Änderungen werden während der Laufzeit übernommen und erfordern keinen Reload des OpenLDAP Daemons.
Nun aber ans Eingemachte…
Bevor wir eine Access Control List aufbauen können, müssen wir wissen wie die Definition auszusehen hat und welche Möglichkeiten der Definition es gibt.
Die Definition einer ACL hat sich zu älteren OpenLDAP Versionen nicht groß geändert und immer den Folgenden grundlegenden Aufbau:

olcAccess: {n} to "what" by "who" "access"

Was in vollendeter Form z.B. so aussehen kann:

olcAccess: {2}to dn.subtree="ou=company,dc=netways,dc=org" by group.exact="cn=admins,ou=users,dc=netways,dc=org" write by * read by anonymous none

Das Beispiel ermöglicht den Mitgliedern der Gruppe “admins” Schreibrechte auf den Inhalt der Organisationseinheit “company”. Andere Benutzer haben Leserechte und Anonyme haben keinerlei Rechte.
Die {2} definiert die Reihenfolge der Verarbeitung. Die Access Control List wird von oben nach unten abgearbeitet. Regeln mit {1} greifen vor Regeln mit {2}, {3} etc… und werden auch so angewendet.
Eine Standardregel, die meist sehr weit oben in der ACL angesiedelt ist, lautet:

{1}to * by self write by dn="cn=admin,dc=netways,dc=org" write by * read

Diese Regel verhindert meist das folgende Regeln überhaupt Wirkungsvoll sind. Die Regel sagt aus das Überall der Benutzer “admin” Schreibrechte hat und jeder andere Benutzer Leserechte hat (und Benutzer auf die eigenen Objekte Schreibrechte haben). Ist diese Regel weit oben in der ACL angesiedelt haben die darauf folgenden Regeln meist keine Wirkung, daher empfiehlt es sich hier die Reihenfolge anzupassen.
Eine sehr detaillierte Anleitung über die Möglichkeiten der Definitionen gibt hier die OpenLDAP 2.4 Dokumentation: http://www.openldap.org/doc/admin24/access-control.html
Die Dokumentation entält, meiner Meinung nach, eine sehr gute und verständliche Beschreibung der “what” Definition:
0: o=suffix
1: cn=Manager,o=suffix
2: ou=people,o=suffix
3: uid=kdz,ou=people,o=suffix
4: cn=addresses,uid=kdz,ou=people,o=suffix
5: uid=hyc,ou=people,o=suffix
dn.base=”ou=people,o=suffix” trifft 2
dn.one=”ou=people,o=suffix” trifft 3 und 5
dn.subtree=”ou=people,o=suffix” trifft 2, 3, 4 und 5
dn.children=”ou=people,o=suffix” trifft 3, 4 und 5
Welche unterschiedlichen Möglichkeiten der “what” “who” und “access” Definition man hat beschreibt das Schaubild unter “8.2. Access Control via Static Configuration”.
Bisschen was aus der Praxis…
Damit dieser Blogpost nicht allzu theoretisch wird ein paar Code snippets die das Thema ACL ggf. etwas leichter machen.
Definitionen zur ACL hinzfügen:

changetype: add
add: olcAccess
olcAccess: to dn.subtree="ou=company,dc=netways,dc=org" by group.exact="cn=admins,ou=users,dc=netways,dc=org" write by * read

Neue Definitionen werden in der Liste ganz am Ende aufgeführt und bekommen immer die höchste Listenzahl {}
Definition in der ACL ändern:

changetype: modify
delete: olcAccess
olcAccess: to dn.children="ou=contacts,dc=netways,dc=org" by * search
-
add: olcAccess
olcAccess: to dn.children="ou=contacts,dc=netways,dc=org" by * write
-

Definitionen abändern erfordert ein “delete: olcAccess” und ein “add: olcAccess”. Die “-” sind im LDIF wichtig.
Definition an bestimmter Stelle in ACL ändern:

changetype modify
delete: olcAccess
olcAccess: {1}
-
add: olcAccess
olcAccess: {1}to dn.children="ou=contacts,dc=netways,dc=org" by * write
-

Hier wird der Inhalt von {1} mit dem neuen überschrieben.
Noch was Gutes zum Schluß…
Das Backend cn=config kann mit der Zeit sehr groß und sehr komplex werden.
Insbesondere dann wenn die ACL sehr groß geworden ist.
Zur Administration des Backends ist es daher Empfehlenswert auf einen gut strukturieren und übersichtlichen LDAP Browser / Editor zurück zu greifen.
Ich verwende sehr gerne Apache Directory Studio oder unter Windows LDAPAdmin.
Eine Verbindung zur cn=config erfolgt über den administrativen Backendbenutzer (meist cn=Manager,cn=config oder cn=admin,cn=config) und über die BaseDN cn=config.

Weekly Snap: OpenLDAP & Jasper Reports, OSMC Partners & Xsensior Sensors

22 – 26 August offered tips on Jasper Reports and OpenLDAP, introduced the OSMC partners and USB sensors for Windows.
To start the week, Pamela announced our partners for this year’s OSMC (Open Source Monitoring Conference). Linux Magazin, Admin Magazin and Thomas Krenn will support us again, while SuSE Linux will for the very first time.
From our hardware store, Martin introduced a simple environmental monitoring device for Windows. The Xsensior Lite USB temperature and humidity sensors come equipped with software to monitor up to 10 sensors displayed in tabs side by side. They can also export .csv metrics to other formats e.g. MS Excel, for further processing and can alert via email. With a USB extension, these simple sensors can also be set up a little further away.
Marius  then offered an easier way to prepare reports – with Jasper and SOAP. Alongside an interface to manage reports and their resources, JasperServer also exports its functionality via SOAP. Installation is easy – either the complete package or just the application can be deployed on a Tomcat server. Report templates can also be created with the report designer iReport, and transferred to the server. Marius showed how to format a report with PHP and recommended a bunch of other docs for more advice.
Finally, Philipp followed with his own 4-step how-to on extending OpenLDAP 2.4 schemas with cn=config.

Openldap Schema Erweiterung cn=config

In dem Artikel wurde beschrieben welche Neuerungen in OpenLDAP 2.4 enthalten sind.
In diesem Artikel möchte ich kurz darauf eingehen wie man das Schema mit dem cn=config Konfigurationsbackend erweitern kann.
Um neue Schema einzubinden müssen zunächst alle vorhanden inkl. dem neuen Schema in ein LDAP Format exportiert werden.
1. Eine schema_convert.conf erstellen mit dem Inhalt aller vorhandenen Schema:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/netways.schema

Wichtig: Das neue Schema (in diesem Fall netways.schema) muss unter /etc/openldap/schema liegen.
2. Schema an einen temporären Ort exportieren:

# mkdir /tmp/ldapexport
# slaptest -f schema_convert.conf -F /tmp/ldapexport

3. Editieren der Datei /tmp/ldapexport/cn=config/cn=schema/cn={8}netways.ldif und folgende Attribute abändern:

dn: cn=netways,cn=schema,cn=config
...
cn: netways

Folgende Zeilen am Ende der Datei entfernen:

structuralObjectClass: olcSchemaConfig
entryUUID: 10dae0ea-0760-102d-80d3-f9366b7f7757
creatorsName: cn=config
createTimestamp: 20080826021140Z
entryCSN: 20080826021140.791425Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20080826021140Z

4. Abschließend muss das erweiterte Schema mit ldapadd wieder importiert weden.

# ldapadd -x -D cn=admin,cn=config -f /tmp/ldapexport/cn=config/cn=schema/cn={8}netways.ldif

In unserem LDAP Backend (cn=config) sollte nun die DN: cn={8}netways,cn=schema,cn=config auftauchen.
Anmerkung:
Der Name {8}netways kann variieren.
Mit folgendem Befehl kann der korrekte Name herausgefunden werden:

slapcat -f schema_convert.conf -F /tmp/ldapexport -n 0 | grep netways

Weekly Snap: MySQL, Puppet & OpenLDAP tricks

16 – 20 May was filled with tips and tricks for MySQL, Puppet, OpenLDAP and thoughts on social networking usage.
To begin, Bernd discussed the MySQL concurrent read/write function. Unlike InnoDB which supports real ACID transaction administration, MyISAM nonetheless enables concurrent reading/writing. For this he recommends the concurrent_insert parameter which controls simultaneous access to a table, alongside the regular use of ‘optimise table’. Unfortunately, this may no longer work if the writing is activated by Binlogs as the database engine is “forced” into following the correct serial order to maintain its uniqueness in the Binlog.
Continuing on the topic of MySQL, Gunnar offered his tip to accelerate test imports. With the libeatmydata library, the fsync() function can be deactivated for certain applications. But he cautioned that it can lead to data loss and irreparable database damage when inappropriately implemented.
From databases to their directory services, Philip looked at OpenLDAP. He considered the purpose of directory services and the current version OpenLDAP 2.4 in terms of performance and functionality. Of note were two new features which enable greater replication: MirrorMode distributes LDAP servers across two locations, and enables data replication via two providers, while N-Way Multimaster allows the replication of multiple active masters, which can be combined in any number of ways and in turn possess slave servers.
Manuela shared the results of a study into the European use of email, Facebook, Twitter and other social media. She noted that 50% of all Europeans use both email and social networks, with Facebook the undisputed leader (Hyves in Holland being the exception). Also dubbed “multi-channel countries”, company fan pages are best received in Great Britain, Italy and Spain. In contrast, Germany, France and Holland tend more towards being“email countries”. The study includes consumer and decision maker surveys, and can be found at eCircle.
Finally, Christoph showed us how SSH key administration can be done with Puppet in 3 steps. First by creating an SSH class, then SSH keys for root registration and lastly SSH keys for user registration.

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
OpenLDAP 2.4 Mirror ModeBeim 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.OpenLDAP Standalone Ldap Proxy
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.