- Novell eDirectory
-
Novell eDirectory (früher NDS (Novell Directory Services)) ist ein hochskalierbarer und redundanter Verzeichnisdienst, der von Novell mit seinem Betriebssystem NetWare 4.x eingeführt wurde.
Inhaltsverzeichnis
Aufgabe der NDS
Die NDS ist die zentrale Datenbank eines Novell-NetWare-Baums. Die NDS speichert dabei alle dem System vorliegenden Daten über seine Benutzer. Dazu gehören:
- Benutzername,
- Passwort
- Berechtigung innerhalb des Systems
- Daten zum letzten Login
- zugeordnete Drucker
- und weitere Daten
Über diesen Datenbestand können, wie in Datenbanken üblich, Abfragen definiert werden. Der Benutzername ist hierbei jedoch nur ein Attribut. Intern wird der Benutzer über einen Schlüssel referenziert.
Rollen
Außer den Benutzern kennt die NDS noch die Rollen. Eine Rolle ist ein Objekt, das dem eines Benutzer sehr ähnlich ist. Es kann an fast allen Stellen der NDS als Substitution eines Benutzers eingesetzt werden. Eine Rolle hat jedoch kein Passwort und keinen Benutzernamen. Die Rolle kann aber anschließend einem Benutzer zugeordnet werden, dadurch erhält der Benutzer alle Rechte, die innerhalb der NDS mit dieser Rolle verbunden sind. Sollte der Benutzer diese Rechte nicht mehr benötigen, weil er andere Aufgaben übernommen hat, so können ihm alle Rechte, die mit seiner vorherigen Aufgabe verbunden waren, auf einfache Weise wieder genommen werden. Das Rollen-Objekt wird gerne verwendet, wenn es darum geht z. B. einen Abteilungsadministrator zu bestimmen, der maximale Rechte auf alle Drucker und Ressourcen der Abteilung hat und die Passwörter seiner Kollegen zurücksetzen kann. Dies kann in vielen Institutionen gewünscht sein, um das zentrale Netzwerkmanagement zu entlasten. Diese erweiterten Befugnisse müssen jedoch auch schnell und sauber wieder zu entfernen sein. Es kann nicht sein, dass man, um einen Abteilungsadministrator zu erstellen, an x Stellen Rechte setzen und nachher an genauso vielen Stellen diese Rechte wieder entfernen muss, daher erfreut sich die Rolle in vielen NetWare-Umgebungen recht großer Beliebtheit.
Gruppen
Die Bildung von Gruppen ist unter NetWare ebenso möglich wie in vielen anderen Systemen, dabei kann ein Benutzer Mitglied beliebig vieler Gruppen sein. Einer Gruppe können innerhalb der NDS Rechte und Ressourcen zugeordnet sein, so dass diese Zuordnung dann jeweils auf die Mitglieder der Gruppe übergeht. Die Berechtigungen von einzelnen Benutzern und den Gruppen, in denen diese Benutzer sind, können sich jedoch auch widersprechen. Dies ist ein gewolltes Feature der sehr fein definierbaren Rechtestruktur innerhalb der NDS. Die generelle Rechteordnung ist dabei: Das Benutzerrecht bricht Rollenrecht, das Rollenrecht bricht Gruppenrecht. Eine Gruppe G2 hat das Recht einen Drucker P1 zu nutzen, eine Rolle R3 darf diesen Drucker explizit nicht nutzen, der Benutzer B4 darf diesen Drucker nutzen. Ist der Benutzer B4 nun Mitglied der Gruppe G2 und verfügt über die Rolle R3 so ergibt sich, das er P1 nutzen darf. Das Nutzungsverbot der Rolle R3 bricht zwar die Erlaubnis der Gruppe G2, aber sein Benutzerrecht B4 erlaubt es ihm wieder..
Metadaten
Die NDS enthält Metadaten wie z. B. Berechtigungsstrukturen innerhalb der NDS ausschließlich zu den konkreten Instanzen der im Schema enthaltenen Objektklassen. Im Gegensatz dazu enthält die NDS jedoch keinerlei Informationen aus dem Filesystem, da beide Informationsebenen konsequent getrennt behandelt werden. Metadaten zu Ordnern und Dateien wie beispielsweise Berechtigungen, Zugriffshistorien, Größe usw. befinden sich ausschließlich im Filesystem auf dem jeweiligen Volume. Novells ältere NDS-Verwaltungswerkzeuge wie der NetWare Administrator oder die ConsoleOne suggerieren zwar einen direkten Zusammenhang bzw. Übergang zwischen NDS und Filesystem, da sich in beiden Tools das Filesystem und dessen Metadaten administrieren lassen. Jedoch wurden hier einfach die entsprechenden Schnittstellen des Filesystems integriert. Aus diesem Grund gibt es klassisch auch nur unter NetWare die Möglichkeit, NDS-Objekte im Filesystem zu berechtigen und weitere Informationen aus der NDS in das Filesystem zu übernehmen (z. B. für Last Access, Quotas usw.). Auf anderen Plattformen, auf die die NDS portiert wurde, beispielsweise Windows oder Solaris, ist dies nicht möglich. Erst mit der Portierung des Novell-eigenen Filesystems NSS auf Linux wurden diese Möglichkeiten zusätzlich auf SuSE Linux in Form des Novell Open Enterprise Servers ausgedehnt. Auch hier erfolgt eine strikte Trennung der Metadaten wie oben beschrieben.
Ressourcen
Ebenso werden alle Drucker, Server und sonstige Ressourcen, die innerhalb des NetWare-Baums bestehen, über die NDS verwaltet. Werden in einem Netzwerk noch weitere Novell-Produkte genutzt, wie z. B. die Groupware GroupWise, so wird diese natürlich ebenfalls voll in die NDS integriert. Es gibt auch Module um Produkte von anderen Herstellern in die NDS zu integrieren. So ist es möglich mit NDS for Windows NT eine Windows-NT-Domäne vollständig in eine NDS zu integrieren und somit über die NDS auch die NT-Server und Workstations mitzuverwalten.
Aufbau der NDS
Baumstruktur
Die NDS stellt eine hierarchische Baumstruktur dar. Das oberste Objekt einer NDS ist stets das Objekt [ROOT]. Alle anderen Objekte befinden sich unterhalb des Root-Objekts. Eine frisch installierte NDS enthält daher nur das Objekt [ROOT], mindestens einen Container, den Benutzer ADMIN, ein Server-Objekt und mindestens ein Volume-Objekt. Der Benutzer ADMIN ist in dieser neuen NDS Trustee des Objektes [ROOT] und hat auf dieses Objekt Supervisor-Rechte. Da sich alle Rechte, wenn sie nicht explizit revidiert werden, von einem höheren Objekt stets auf alle nachgelagerten Objekte vererben, hat der Benutzer ADMIN, durch diese eine Rechtedefinition, maximale Zugriffsrechte auf jedes Objekt in der ganzen NDS.
Replikationen
Die NDS ist wie bereits erwähnt eine hochskalierbare, redundante, relationale Datenbank. Der Baum stellt die hierarchische Abbildung der NDS dar. Die NDS als Datenbank läuft dabei immer auf einem bestimmten Server innerhalb des Baums. Alle anderen Server müssen mit diesem Server kommunizieren können, um zu prüfen ob Benutzer dazu berechtigt sind auf Dateien zuzugreifen oder ähnliches. Fast jeder Mausklick eines Benutzers löst somit eine Änderung der NDS aus. Wenn die NDS dabei nur auf einem einzigen Server laufen würde, wäre sie erstens nicht redundant und zweitens ziemlich schnell überlastet. Die NDS kann daher auf beliebig viele Server repliziert werden. Wird die NDS auf mehrere Server repiliziert, so spricht man von einem NDS-Replikationsring. Innerhalb eines solchen Replikationsrings kann es verschiedene Arten von Replikationen geben.
Die Master-Replikation
Die wichtigste Replikation ist dabei die Master-Replikation der NDS. Diese Replikation ist deshalb die wichtigste, da innerhalb der transitiven Replikation, die Novell nutzt, ihre Stimme am meisten zählt. Die Master-Replikation ist auch die einzige Replikation, die eine neue NDS-Epoche bestimmen kann. Die Master hat weiterhin eine Kontrollfunktion bei zwei wesentlichen Prozessen innerhalb der NDS: bei allen Partitionsoperationen (merge, split, create/delete/change replica) sowie beim Obituary Prozess (verschieben, umbenennen und löschen von Objekten). Die Master agiert hierbei als Synchronisationsinstanz und stellt sicher, daß alle Replikate und External References eines Objektes tatsächlich erreicht werden. Ein Totalverlust der Master-Replikation ist jedoch kein großer Schaden, da innerhalb weniger Augenblicke eine jede andere Replikation der NDS zur neuen Master-Replikation bestimmt werden kann. Solange noch eine beliebige, aber möglichst vollständige und aktuelle, Replikation der NDS besteht, ist das Gesamtsystem funktionsfähig.
Die Read-/Write-Replikation
Die nächste Stufe sind die Read-/Write-Replikationen, sie haben im normalen Systembetrieb fast die gleiche Funktion wie die Master-Replikation. Eine Read-/Write-Replikation kann Benutzeranfragen authentifizieren, sie kann neu erstelle Objekte verifizieren, und auch sonst fast jede Aufgabe innerhalb des Replikationsrings übernehmen, außer der Erklärung einer neuen NDS-Epoche. Die Stimme einer Read-/Write-Replikation ist schwächer als die Stimme der Master-Replikation, es ist jedoch auch möglich, dass innerhalb einer transitiven Replikation die Master-Replikation von den Read-/Write-Replikationen überstimmt wird.
Die Read-Replikation
Die nächste Stufe stellen die Read-Replikationen dar, diese haben im normalen Systembetrieb keinerlei Bedeutung. Sie können keine Anfragen von Benutzern verarbeiten und auch sonst keine Aufgaben innerhalb der NDS wahrnehmen. Ihre einzige Existenzberechtigung ist, dass sie im Notfall in eine Read-/Write-Replikation oder gar in die Master-Replikation befördert werden können. Der Vorteil einer Read-Replikation ist, dass sie im NDS-Replikationsring keinerlei Datenverkehr erzeugt, da sie nur Replikationspakete liest aber niemals selbst Replikationspakete erzeugt.
Die Subordinate-Replikation
Subordinate Replikationen, oder richtiger: Subordinate References, werden dort angelegt, wo ein Server zwar eine Replikation einer übergeordneten Partition hat, nicht jedoch deren Kinder. In diesem Fall braucht der Server eine Möglichkeit, die Referenzen dieser Kind-Partition abzuspeichern, den sogenannten Replica Ring. Dies geschieht in einer Subordinate Reference, die im wesentlichen genau aus dem Replica Kopf besteht, jedoch keine Objekte tragen kann. Eine Subref darf niemals zur Master erhoben werden, wenn es noch eine andere, Daten tragende, Replikation der entsprechenden Partition enthält, weil sie eben keinerlei Objekte beinhaltet und daher alle anderen Replikationen mit leeren Datenbanken überschreiben würde. Wenn es sich hierbei um eine Partition in der mittleren Baumebene handelt (also darunter noch weitere Kind-Partitionen hängen), dann wird auch die Kontinuität des Baumes zerstört. Generell sind Subordinate References vollständig automatisch verwaltet und müssen vom Administrator nicht angefasst werden
Änderung von Replikationstypen
Eine Master-, eine Read-/Write- und eine Read-Replikation können durch den Systemverwalter zu jeder Zeit in einen anderen Replikationstyp verändert werden. Einzige Ausnahme stellt die Master-Replikation dar, sie kann nicht direkt geändert werden, aber durch die Beförderung einer Read-/Write- oder einer Read-Replikation zur neuen Master-Replikation wird die alte Master-Replikation in eine Read-/Write-Replikation degradiert. Durch vom Systemverwalter ausgelöste Replikationsartenwechsel kann es nicht dazu kommen, dass keine Master-Replikation mehr besteht. Die alte Master-Replikation gibt ihren Status auch erst dann auf, wenn die neue, die Pending Master-Replikation, einen gewissen Status erreicht hat. Ist die Master-Replikation durch einen Systemausfall dauerhaft verloren gegangen, so wird eine bestehtende Replikation zum Master bestimmt, die ihre Beförderung allen anderen Replikationen mitteilt.
Partitionen
Damit die NDS ihre hohe Skalierbarkeit erreicht, kann sie in beliebige Partitionen unterteilt werden. Es können dabei die verschiedensten Gesichtspunkt zum Zug kommen. Entweder weil die NDS auch räumlich getrennt ist: Eine Firma mit drei Standorten könnte sich z. B. entscheiden, ihre NDS in vier Partitionen zu unterteilen. Eine ROOT-Partition sowie je eine Partition für jeden der Standorte. Es würden somit auch vier getrennte Replikationsringe entstehen, was für die Auslastung der Standleitungen zwischen den Standorten von großer Bedeutung sein kann. Außerdem würde ein Ausfall einer Standleitung keine allzu großen Probleme nach sich ziehen, da drei der vier Replikationsringe von den Standleitungen vollkommen unabhängig sind. Und nur der ROOT-Replikationsring über alle Standorte verläuft, dieser Ring wäre dann zwar in seiner Replikation gestört, was jedoch auch keine allzu großen Probleme darstellt, solange in dieser Zeit kein neuer vierter Firmenstandort eröffnet würde. In jedem Replikationsring gibt es wieder eine Master-Replikation, die für diesen Ring die jeweils wichtigste Replikation ist. Es kann aber auch notwendig sein, die NDS zu partitionieren, wenn sie eine gewisse Größe erreicht hat, durch eine Partitionierung kann in solch einem Fall die Leistungsfähigkeit der NDS gesteigert werden, da Benutzeranfragen nun wesentlich zielgerichter innerhalb des Systems erfolgen. Zusätzlich werden die einzelnen Replikationszyklen in den Replikationsringen beschleunigt.
Partitionsrichtlinien
Viele Novell Systemverwalter empfehlen, dass jeder Replikationsring mindestens zwei bis vier Replikationen enthalten sollte, eine Erhöhung der Replikationszahl über fünf bis sechs Replikationen bringt dann schon wieder Leistungsnachteile, weil die Replikationszyklen in betroffenen Ringen erhöht werden. Auch die Anzahl der Objekte in einer Partition ist entscheidend für die Leistungsfähigkeit einer Partition, bei mehr als 2.500 Objekten wird von vielen eine weitere Partition empfohlen.
Weiterentwicklung der NDS
Die NDS 6
Die Version 6 der NDS wurde mit NetWare 4.11 eingeführt, sie löste ihre Vorgängerversionen ab. Es wurde jedoch auf eine Kompatibilität geachtet, so dass es zwar möglich ist, mit verschiedenen NDS-Versionen auf den einzelnen Server, zu arbeiten, was jedoch nicht empfohlen werden kann.
Die NDS 7
Die neue Version der NDS wurde mit Novell NetWare 5.0 eingeführt. Die NDS 7 ist abwärtskompatibel mit der NDS 6, Server mit beiden Versionen können somit in einem Replikationsring koexistieren. Die neuen Funktionen der NDS 7, z. B. die transitive Replikation, können jedoch nur genutzt werden, wenn nur NDS 7 Server an einem Replikationsring beteiligt sind, sonst wird die alte gerichtete Replikationvariante genutzt. Mit der NDS 7 kam zum ersten Mal die Möglichkeit, die NDS über LDAP zu nutzen.
Die NDS 8
Die NDS 8 wurde mit Netware 5.1 eingeführt. Sie ist nicht vollständig kompatibel zur NDS 7, ein Übergangsbetrieb beider NDS Versionen ist jedoch zu Migrationszwecken möglich. Die NDS ermöglicht den Einsatz von LDAP v3 zur Abfrage der NDS.
Das eDirectory
Das Novell eDirectory ist aus der NDS entstanden, es ist eine Symbiose aus LDAP und NDS.
Wikimedia Foundation.
