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.

Dokumentenmanagement mit Alfresco Community

Wer kennt das nicht, ein Unternehmen mit mehr als 5 Angestellten  und vielen, vielen Dokumenten, Grafiken und Files, kommt sich auf einem geteilten Share doch mal schnell in die Quere. Genau dafür gibt es Dokumentenverwaltungssysteme! Das wohl bekannteste unter ihnen ist Microsoft Sharepoint, dicht gefolgt von Alfresco. Ein Document Management System (DMS) bietet Schutz vor versehentlichen Überschreiben des gleichen Dokumentes, da die Bearbeiter es vor der Bearbeitung aus-checken müssen. Das bedeutet, möchte eine andere Person das Dokument bearbeiten, wird eine entsprechende Meldung angezeigt, dass dieses Dokument gerade von Person X bearbeitet wird.
Ein weiterer großer Vorteil von einem DMS ist die Möglichkeit Dokumente zu versionieren. Das bedeutet, das Unternehmen aktualisiert seine AGB und legt Sie wieder mit dem gleichen Dateinamen auf dem DMS ab. Mittels verschiedener Felder kann man eine Versionsnummer sowie eine Notiz zu den geänderten Passagen ablegen.
Mein aktuelles Projekt umfasst die Evaluierung eines geeigneten DMS. Dazu habe ich mir verschiedene Lösungen angesehen. In der Lostrommel waren also Microsoft Sharepoint 2010, Alfresco Community und Agorumcore Pro (jeweils die aktuellste Stable).
Microsoft Sharepoint 2010
Der Grundstein der DMS hat bis heute seinen Zug nicht verpasst, Microsoft Sharepoint lässt sich innerhalb weniger Stunden Installieren und Einrichten. Ich habe dazu eine Server 2008 VM als Basis verwendet. Die Testversion lässt sich einfach per Installer auf den Server installieren. Möchte man sein Sharepoint an das Active Directory anbinden, muss man lediglich den Server in die Domäne aufnehmen. Sicherlich lässt sich mit Sharepoint sehr viel realisieren, jedoch ist es so an Funktionen und Einstellmöglichkeiten überladen, dass man schnell den Überblick verliert.
Agorum Core Pro
Agorum ist ein Nachzügler von Microsoft Sharepoint. Die Installation braucht sehr viel Vorbereitung, bis sie fehlerfrei durchläuft. In der fertig installieren Anwendung findet man sich auch wie bei Sharepoint nur mäßig zurecht. Die Anbindung an das Active Directory bedarf einem Modul, welches ich zwar installiert habe, aber nicht in der Anwendung auffinden kann. Zusätzlich ist auf dem AD-Server die Installation eines AgorumADSHelpers notwendig.
Alfresco Community
Das Tool, welches mich wirklich von Anfang an begeistert hat ist Alfresco. Es lässt sich sehr einfach installieren und startet ohne Probleme. WICHTIG: Hostname in /etc/hosts muss gesetzt sein, sonst startet die Anwendung nicht! Alfresco ist schick, übersichtlich, schnell und einfach zu bedienen. Um Alfresco zu Installieren sucht man sich auf der Homepage die geeignete Lösung raus, installiert diese und kann beginnen.
Die Anbindung von Alfresco Community an Active Directory Server ist sehr einfach möglich, auch hier zum Nachlesen.
Nach einem Neustart des Alfresco Servers ist die Anmeldung direkt über die freigeschalteten Kanäle möglich.

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.

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.