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
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.

Aufzeichnung des LConf-Webinars ist online!

lconf_logo
Die Aufzeichnung unseres gestern geführten Webinars steht ab sofort zum Ansehen auf YouTube bereit. Vielen Dank nochmal an alle Teilnehmer für die Aufmerksamkeit. Im Webinar wurden folgende Punkte durchgesprochen:

  • Kurzvorstellung NETWAYS
  • Einführung LDAP
  • Vorteile/Funktionen LConf mit LDAP

natürlich wurde dann noch ausführlich eine Live-Demo gezeigt.

 
Nicht vergessen: Nächste Woche führen wir ein Webinar zum Thema Puppet. Ein Blick in unser Webinar-Archiv lohnt sich, dort gibt es auch die Präsentationsfolien zum Download!

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

NETWAYS Webinar für das Nagios/Icinga Konfigurationstool LConf

lconf_logo
Neben dem Bearbeiten von Nagios/Icinga Konfigurationsdateien über die Command-Line, gibt es noch Web-basierte Lösungen, welche die Konfiguration deutlich vereinfachen.
 
Eines dieser Tools ist der LConf. Ein aus dem Audi Projekt entstandenes Tool, welches die Nagios-Konfiguration über eine LDAP Struktur abbildet und an Nagios/Icinga zurück exportieren kann.
In diesem Webinar, werden wir näher auf die Möglichkeiten, die Vererbungslogik sowie den daraus resultierenden Vorteil eingehen.
Die Registrierung erfolgt wie immer über unser Webinar Center. Das Webinar startet am Mittwoch 09. Oktober um 14 Uhr.
Wir freuen uns auf eine rege Teilnahme!
Übrigens: nächste Woche Donnerstag (17.10.2013) halten wir ein Webinar über Puppet.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

FLOSS UK 2013 in Newcastle

Ooups, this gallery does not have any images...

Letzte Woche war ich wie bereits angekündigt in Newcastle unterwegs um bei der diesjährigen Spring Conference teilzunehmen. Nachdem ich am Starbucks Schiphol wie angekündigt nicht vorbeigekommen bin, bin ich kurz vor Mitternacht in Newcastle angekommen und sofort in komatösen Schlaf gefallen. Die Konferenz bot, über die beiden Tage verteilt, ein interessantes Programm und ich hab wieder einiges dazugelernt. Sehr erfreuliche war dass sich Icinga einer zunehmenden Beliebtheit erfreuen kann. War es vor drei Jahren noch relativ unbekannt, so war es jetzt jedem ein Begriff und einige andere Vorträge verwiesen auch auf ihre Migration auf Icinga.

Besonders gelungen war die diesjährige Abendveranstaltung im Hancock Museum. Neben sehr leckerem Essen (typische Collection aus Fleisch, Gemüse und Kartoffeln), wurde man zusätzlich noch von einem Weißen Hai und einem Elefanten beobachtet.


Nächstes Jahr findet die Spring Conference in Brighton, dem südlichen Ende von Great Britain statt. Wir sind auf jeden Fall wieder dabei! Die beiden Vorträge zu Icinga und OpenNebula gibt es natürlich hier und hier zum download.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

LDAP-Filter zur Autorisierung bei rekursiven Gruppen

Bevor wie zum Eingemachten kommen zuerst ein paar klärende Worte zum Titel. Hier ist unter rekursiven Gruppen, eine rekursive Gruppenstruktur gemeint, bei der eine Gruppe eine weitere Gruppe als Mitglied enthalten kann. Der Filter

&(sAMAccountName=__USERNAME__)(member=CN=group,DC=netways,DC=de)

leistet dies leider nicht, so dass Mitglieder einer Gruppe, die Mitglied von CN=group ist, nicht authorisiert sind. Mit dem memberOf-Overlay, ist dies mit einer eingebauten “Funktion” jedoch leicht möglich:

&(sAMAccountName=__USERNAME__)(memberOf:1.2.840.113556.1.4.1941:=CN=group,DC=netways,DC=de)

Das Active Directory von Microsoft bringt das memberOf-Overlay von Hause aus mit. Bei Openldap kann es als Modul nachgeladen werden.

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: memberof
dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf

Eine zur Authentifizierung zusätzliche Autorisierung bei einem Apache-Webserver, wie in SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory beschrieben, sähe dann wie folgt aus:

AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://dc.netways.de/dc=netways,dc=de?userPrincipalName"
AuthLDAPBindDN "cn=ads,cn=Users,dc=netways,dc=de"
AuthLDAPBindPassword ********
Require ldap-filter memberOf:1.2.840.113556.1.4.1941:=CN=group,DC=netways,DC=de
Lennart Betz
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: N-Way Master Replication

In diesem Artikel möchte ich kurz beschreiben, wie man aus einem einzelnen OpenLDAP-Server eine hochverfügbare Farm aufbauen kann. Voraussetzung sei hierfür ein eingerichteter Standalone-Server mit dynamischer Konfiguration im LDAP selbst (cn=config) und konfiguriertem LDAPS bzw. SSL auf Port 638. Für die hier exemplarisch verwendeten LDAP-Client-Kommandos muss zusätzlich die IPC-Unixsocket (ldapi) Schnittstelle des Servers aktiviert sein.
Für die Replikation von einem Master auf einen Slave LDAP-Server wird jeweils eine Abstarktionsschicht, Overlay genannt, im jeweiligem Server selbst “eingezogen”. Hierbei wird der Slave im LDAP-Jargon als Consumer und er Master als Provider bezeichnet. Für eine Multi-Master-Umgebung muss also jeder LDAP-Knoten Provider wie auch Consumer sein.
Zuerst machen wir aus unserem Standalone-Server einen Provider. Hierfür soll das nachfolgende Listing als provider.ldif abgespeichert sein.

dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 0x001 ldaps://kdc01.netways.int
olcServerID: 0x002 ldaps://kdc02.netways.int

Wie dem Listing zu entnehmen ist, haben wir neben der Konfiguration cn=config, bisher lediglich einen weiteren Baum bzw. Datenbank im DBD-Format in unseren LDAP abgelegt. Bei einer weiteren Datenbank, ist ein weiterer ensprechender DN hinzuzufügen. Soll die Farm aus mehr als zwei Servern bestehen müssen ebenfalls weitere ServerIDs angefügt werden. Mit

# ldapmodify -Y EXTERNAL -H ldapi:/// -f provider.ldif

kann nun die Konfiguration erweitert werden. Hier kann man nun auch erahnen, dass jede Datenbank einzeln synchronisiert wird. Das folgende Listing auth.ldif macht dies klarer ersichtlich, da wir hier für jede Datenbank die Authenfizierung anpassen werden.

dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=config

add: olcRootPW
olcRootPW: {SSHA}4KIL4Ob3SLaLqbe/AyMO80KALdBUWj6M

Dieses Listing ist jedoch nur mit

# ldapmodify -Y EXTERNAL -H ldapi:/// -f auth.ldif

hinzuzufügen, wenn in der Datenbank cn=config für den Benutzer cn=config noch kein Passwort gesetzt hat. Bei unserer zweiten Datenbank {1}bdb gehen wir davon aus, dass der RootDN cn=admin,dc=netways,dc=int lautet und ein Passwort gesetzt ist.
Die beiden folgenden Listings consumer_0.ldif und consumer_1.ldif konfigurieren unseren LDAP-Server zusätzlich als Consumer.

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldaps://kdc01.netways.int binddn=”cn=config” bindmethod=simple credentials=PASSWORD searchbase=”cn=config” type=refreshAndPersist retry=”5 +” timeout=1
olcSyncRepl: rid=002 provider=ldaps://kdc02.netways.int binddn=”cn=config” bindmethod=simple credentials=PASSWORD searchbase=”cn=config” type=refreshAndPersist retry=”5 +” timeout=1

add: olcMirrorMode
olcMirrorMode: TRUE

dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=003 provider=ldaps://kdc01.netways.int binddn=”cn=admin,dc=netways,dc=int” bindmethod=simple credentials=PASSWORD searchbase=”dc=netways,dc=int” type=refreshAndPersist interval=00:00:00:10 retry=”5 +” timeout=1
olcSyncRepl: rid=004 provider=ldaps://kdc02.netways.int binddn=”cn=admin,dc=netways,dc=int” bindmethod=simple credentials=PASSWORD searchbase=”dc=netways,dc0int” type=refreshAndPersist interval=00:00:00:10 retry=”5 +” timeout=1

add: olcMirrorMode
olcMirrorMode: TRUE


# ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_0.ldif
# ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_1.ldif

aktivieren den jeweiligen Consumer, der nun via LDAPS und Simple Authentification, die zu synchronisierenden Daten vom jeweilgen Provider ausliest. Um die Performance der Synchronisation zu erhöhen sollte man unbedingt noch jeweils einen Index auf entryUUID und entryCSN setzen.

dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
olcDIndex: entryCSN eq

Das wars schon. Jetzt beschäftigen wir uns mit dem zweiten Knoten unserer Farm. Dieser wird zunächst wie ein Standalone Server konfiguriert. Zubeachten ist, dass z.B. die Zertifikate unter dem selben Pfad und mit dem selben Namen abzulegen sind, da wir auf beiden Knoten, die selbe Konfiguration verwenden werden. Nachdem wir auf unserem fertig konfigurierten Knoten, die Konfiguration mit

# slapcat -n 0 -l config.ldif

gesichert haben und auf unseren zweiten Knoten kopiert haben, spielen wir diese auf dem neuen Knoten mit

# slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif

wieder ein und starten den LDAP-Server. Von nun an werden beide Datenbanken repliziert.

Lennart Betz
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.