17.12.2013 - Fachbeitrag

LDAP und Unix Accounts - das Dilemma mit posixGroups und groupOfNames

Wird ein Verzeichnisdienst als zentraler Speicherort für Accountdaten eingesetzt, sind dort neben den Benutzerdaten auch Gruppen abgelegt. LDAP kennt nun prinzipiell zwei Arten (Objektklassen), um Accounts zu gruppieren: posixGroup und groupOfNames. Der grundlegende Unterschied zwischen beiden Onjektklassen ist die Referenzierung ihrer Mitglieder. Während es bei posixGroups reicht, nur den (Unix)-Benutzernamen einzutragen, ist es bei einer groupOfNames der komplette distiguished name (DN), also der Pfad im LDAP-Baum zum Objekt. Dies schränkt die Verwendung von posixGroups im Prinzip auf eine Anwendung ein, nämlich die als Unix-Gruppe. Denn in der /etc/group stehen auch nur die Benutzernamen als Mitglieder, was dort auch völlig ausreichend ist. Eine Mitgliederliste, die als Referenz allerdings den DN enthält, ist für eine Vielzahl anderer Anwendungen nützlich. Das fängt bei der Möglichkeit an, diese Gruppe(n) für LDAP ACLs zu nutzen und geht weiter mit Drittanwendungen, die ihre Benutzerdatenbank per LDAP pflegen oder darüber sogar Mailverteiler realisieren. Diese nutzen sehr häufig DNs statt nur der Benutzernamen.

Warum ist das ein Dilemma?

Wenn LDAP für die Bereitstellung von Nutzerdaten eingesetzt wird, passiert dies unter dem Gesichtspunkt der einfachen und zentralen Administration von Zugangsberechtigungen. An einer Stelle soll definiert werden, wer sich anmelden darf und welchen Gruppen er angehört. Diese Gruppen definieren dann in einzelnen Anwendungen bestimmte Zugriffsrechte oder auch Rollen (z.B. über LDAP ACLs oder Filesystemzugriffsrechte). Es sollte also nicht so sein, dass die Gruppenmitgliedschaft an mehreren Stellen definiert werden muss. Es soll also vermieden werden, dass es eine posixGroup (für Filesystemzugriffsrechte) und eine semantisch identische groupOfNames gibt, die mit denselben Mitgliedern für weitere Anwendungen definiert und gewartet werden muss. Sicher lassen sich Automatismen erdenken, die aus einer Menge von groupOfNames entsprechende posixGroups machen (z.B. per Script und Cronjob), aber hinkt dann immer in der Zeit hinterher. Einfacher und eleganter wäre es, wenn es nur noch groupOfNames gäbe. Das Dilemma ist die Tatsache, dass in den gängigen LDAP-Schemata (core und nis) beide Objektklassen als "STRUCTURAL" definiert sind und deshalb nicht gleichzeitig für einen Eintrag verwendet werden können.

Eine Lösung

Vor Jahren gab es einen Vorschlag RFC2307 mit einer Erweiterung RFC2307bis, der das Schema nis umgebaut und die Objektklasse posixGroup AUXILIARY gemacht hat. Das hat den Vorteil, dass sie jetzt zusammen mit groupOfNames (als Strukturklasse des Objektes) für einen Eintrag verwendet werden kann. Und damit stehen auch die für Unixgruppen wichtigen Attribute gidNumber und userPassword zur Verfügung, ohne dass jeder LDAP-Admin eine eigene Hilfs-Objektklasse definieren müsste. Dies würde nämlich wiederum eine Einschränkung der Interoperabilität bedeuten. Mit dieser Konstruktion können also im Verzeichnis Einträge der Klasse groupOfNames mit einer numerischen Unix-Gruppen-ID versehen werden.

libnss-ldap & libpam-ldap

Jetzt ist noch offen, wie ein Unix bzw. Linux-System diese Gruppen verwenden kann. Prinzipiell ganz genauso wie posixGroups aus dem LDAP mit libnss-ldap. Diese Bibliothek ist ein Helfer für den Naming Service und spricht mit dem LDAP-Server. In der Konfigurationsdatei /etc/libnss-ldap.conf werden die LDAP-Zugangsdaten definiert und Search-Base sowie Scope. Es können für die verschiedenen NSS-Objekte (Benutzer, Gruppen, aber auch Hosts etc.) verschiedene Search-Bases angegeben werden. Hier ist der Eintrag "nss_schema rfc2307bis" wichtig, damit die Bibliothek aus den DNs der Gruppenmitglieder Unix-Benutzernamen macht. Dies geschieht natürlich über weitere LDAP-Anfragen, so dass sich gerade hier der Einsatz eines nscd für das Caching der Ergebnisse empfiehlt.

libnss-ldapd & libpam-ldapd

Eine etwas neuere Methode der LDAP-Einbindung in PAM und NSS bieten die beiden Pakete libnss-ldapd und libpam-ldapd. Sie bringen mit dem nslcd einen caching LDAP-Client mit, ähnlich dem generischen nscd. Der nslcd wird in /etc/nslcd.conf eingerichtet und erhält dort die Zugangsdaten zum LDAP-Server sowie Search-Base und Scope. Die Debian-Pakete können dann automatisch mit der LDAP-Objektklasse groupOfNames unmgehen, bei RedHat muss das member-Attribut mit "map group uniqueMember member" umgeschrieben werden, da hier offensichtlich die Objektklasse groupOfUniqueNames eigentlich vorgesehen ist.

Das RFC2307bis Schema

Die grundlegendsten Änderungen zum nis-Schema sind:

die Objektklasse posixGroup ist AUXILIARY und nicht STRUCTURAL
das Attribut memberUid hat kein SubstringMatch mehr
die Attribute nisPublicKey, nisSecretKey, nisDomain, automountMapName, automountKey und automountInformation sind neu
die Objektklassen nisKeyObject, nisDomainObject, automountMap, automount und namedObject sind neu

Wir haben die Schema-Definition für die dynamische openLDAP-Konfiguration (slapd.d-Verzeichnis) angepasst: rfc2307bis.ldif

Fazit

So ist dann erreicht, dass im Verzeichnis nur noch eine Art von Gruppen gepflegt werden muss, die für eine Vielzahl von Anwendungen benutzt werden können. Wird z.B. Zarafa benutzt, können mit der Hilfs-Objektklasse zarafa-group die Attribute mail und zarafaAliases hinzugefügt werden. Damit ist dann sichergestellt, dass derselbe Personenkreis Zugriff auf Verzeichnisse im Filesystem hat, der auch Empfänger von E-Mails über einen Verteiler gleichen Namens ist, und die Liste muss nicht doppelt gepflegt werden.