Bundesamt für Sicherheit in der Informationstechnik

M 2.236 Planung des Einsatzes von Novell eDirectory

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, Leiter IT

Grundsätzlich gibt es zwei Einsatzszenarien für eDirectory:

  • der Einsatz als Managementprodukt für Ressourcen in einem gegebenen Netz oder
  • die Verwendung als (Meta-)Verzeichnisdienst ( LDAP -Server).

Abstrakt gesehen bildet das eDirectory eine hierarchisch und baumartig organisierte, Objekt-basierte Datenbank. Es ist an den Verzeichnisdienst-Standard X.500 angelehnt, von dem es die interne Struktur und den internen Aufbau entliehen hat. Es ist jedoch kein X.500-kompatibler Verzeichnisdienst, da das Zugriffsprotokoll auf dem proprietären NDAP (Novell Directory Access Protocol) basiert.

Das Baum-Konzept von eDirectory stellt sich auf folgende Weise dar: in einem Baum (Tree) werden Server, Benutzer und weitere Ressourcen abgebildet und können durch den Baum-Administrator verwaltet werden. Ein Baum bildet grundsätzlich eine administrative Grenze und limitiert auch den Wirkungsbereich von Berechtigungen.

Ein eDirectory-Verzeichnisbaum besteht aus verschiedenen Objekten. Jedes Objekt gehört einer ausgezeichneten Klasse an, z. B. Benutzerobjekt oder Serverobjekt, und ist gemäß dieser Klasse aus verschiedenen Attributen bzw. Eigenschaften zusammengesetzt. Die verschiedenen Objektattribute können unterschiedliche Werte aufnehmen, z. B. Telefonnummer oder IP-Adresse. Die Informationen über die bestehenden Objektklassen inklusive der darin vorkommenden Attribute werden im Directory-Schema gehalten. Durch Änderungen der Schemadefinition können neue Objektklassen erzeugt oder bestehende Objektklassen mit veränderten Attributsätzen versehen werden. Bei Veränderung des Schemas spricht man dann vom Extended Schema. eDirectory kennt verschiedene vordefinierte Objekttypen:

  • Tree-Objekt: Dieses Objekt ist die Wurzel aller eDirectory-Objekte eines Verzeichnisbaums und enthält Informationen über diesen, z. B. Name des Baums. Unterhalb des Tree-Objekts können weitere Objekte angeordnet sein.
  • Container-Objekte: Diese Objekte dienen dazu, andere Objekte zu gruppieren. Standardmäßig stehen die Objekte Land (Country, C), Organisation (Organization, O) und Organisations-Einheit (Organizational Unit, OU) zur Verfügung. Unterhalb eines OU-Objektes können weitere OU-Objekte enthalten sein, sowie so genannte Leaf-Objekte (siehe unten).
  • Leaf-Objekte: Dies sind Server-, Benutzer-, Benutzer-Gruppen-, Rollen-, Drucker-, Druckerwarteschlangen-, Profil- sowie Applikations-Objekte. Weiterhin können auch Alias-Objekte zum Verweis auf bestehende Objekte in anderen Teilbäumen definiert werden.

In einem eDirectory-Baum gibt es immer eine ausgezeichnete Wurzel, die eine gewisse Sonderstellung besitzt: sie wird bestimmt durch den ersten Server, der in einem Baum installiert wird. Auf diesem Server läuft die Zertifizierungsstelle ( CA ) des Baums, der Voraussetzung für die Einbindung weiterer eDirectory-Server in den Baum ist. Die CA kann später auch auf einen anderen eDirectory-Server verschoben werden. Sämtliche weiteren eDirectory-Installationen müssen sich bei dem gegebenen eDirectory-Baum anmelden. Dabei muss der genaue Kontext, in dem der eDirectory-Server in einen bestehenden Baum eingebunden wird, angegeben werden. Ein späteres Verschieben der eDirectory-Server ist nur sehr schwer möglich, so dass der Server-Kontext im Voraus geplant werden muss.

Die ersten drei eDirectory-Server eines Baums erhalten automatisch eine vollständige Replica der Verzeichnisdaten, die weiteren nicht mehr - sofern dies nicht explizit so konfiguriert wird.

Nach einer Standardinstallation existiert eine zunächst einfache eDirectory-Struktur, die von eDirectory angelegt wird und dann entsprechend der Planung verändert werden kann. Da eDirectory primär der Verwaltung von IT-Ressourcen dient, sollte beim Aufbau der eDirectory-Baumstruktur darauf geachtet werden, dass die Struktur vornehmlich auf administrative Gegebenheiten abgestimmt wird. Wenn stattdessen zwanghaft die organisatorische Unternehmensstruktur bis ins Kleinste nachgebildet wird, kann dies zu Problemen in der Administration führen.

Es ist weiterhin darauf zu achten, dass die gewählte Baumstruktur nicht zu flach ist, damit sich die Replizierung zwischen den eDirectory-Servern nicht auf den gesamten Baum auswirkt. Der Ausfall eines einzelnen eDirectory-Servers oder der Verbindung dieses Servers zum Restsystem führt anderenfalls zu Fehlermeldungen sämtlicher in den Replizierungsring eingebundener Server.

Die möglichen Anordnungen von eDirectory-Objekten, d. h. welches Objekt welche anderen Objekte enthalten darf, welche Attribute existieren und aus welchen Attributen Objekte zusammengesetzt werden, wird durch das so genannte eDirectory-Schema definiert. Das von eDirectory vorgegebene Schema kann verändert werden, dies stellt jedoch einen gravierenden Eingriff in die Verzeichnisstruktur dar, der nur nach sorgfältiger Planung durchgeführt werden darf.

Der eDirectory-Verzeichnisdienst bietet die Möglichkeit, mit anderen Verzeichnisdiensten über einen Synchronisationsmechanismus Daten im XML-Format abzugleichen. Als XML-Schnittstelle steht dazu das Produkt DirXML zur Verfügung. Diese besteht aus einem Kern (engine) und verschiedenen Treibern für diverse unterstützte Zielsysteme, z. B. Lotus Notes, SAP R/3, Windows 2000 Active Directory, Netscape (iPlanet), etc. Es gibt dabei zwei Kommunikationskanäle: Zum einen den so genannten Publisher Channel, unter dem fremde Verzeichnisdienste Änderungen ihres Datenbestandes dem eDirectory mitteilen können. Zum anderen gibt es den Subscriber Channel, mit dessen Hilfe eingeschriebene fremde Verzeichnisdienste von Änderungen im eDirectory erfahren.

Der Einsatz der DirXML-Schnittstelle bedarf auf jeden Fall einer genauen Planung, um später unerwünschte Seiteneffekte zu vermeiden, z. B. Endlosschleifen.

Im Rahmen der eDirectory-Planung sind folgende Aspekte zu berücksichtigen:

  • Welche Gliederung in Organisations-, Organisationseinheit- und weitere Container-Objekte soll gewählt werden?
  • Welche Objektklassen werden benötigt und welche Attribute sollen diese haben?
  • Welche Benutzer und Server sollen in welchen Organisationseinheiten zusammengefasst werden?

Für jede Organisation muss entschieden werden,

  • welche Administratorgruppen benötigt werden,
  • welches administrative Modell umgesetzt wird (zentrale oder dezentrale Verwaltung),
  • welche administrativen Rollen innerhalb der Baumstruktur existieren sollen,
  • ob und an wen administrative Aufgaben delegiert werden sollen,
  • welche Sicherheitseinstellungen für verschiedene Typen von Servern und Benutzergruppen gelten sollen,
  • auf welche Informationen über die verschiedenen eDirectory-Schnittstellen (z. B. eDirectory-Clients, LDAP) von wem zugegriffen werden darf.

Generell muss die geplante eDirectory-Struktur dokumentiert werden. Dies trägt maßgeblich zur Stabilität, konsistenten Administration und damit zur Systemsicherheit bei. Es empfiehlt sich insbesondere festzuhalten:

  • Welche Schemaänderungen werden durchgeführt? Dabei sollen auch die Gründe für die Änderung dokumentiert sein.
  • Welche Objektklassen werden in welcher Weise verwendet, speziell welche Attribute werden für welche Inhalte genutzt?

Für jedes eDirectory-Objekt sollte dokumentiert sein:

  • Name und Position im eDirectory-Baum (z. B. "StandortBerlin", Vater-Objekt: OU "Filialen-Deutschland"),
  • welchem Zweck das Objekt dient,
  • welche administrativen Zugriffsrechte für das Objekt und dessen Attribute vergeben werden sollen (z. B. vollständig verwaltet von "Admin1"),
  • wie die Vererbung von eDirectory-Rechten konfiguriert werden soll, z. B. blockieren oder filtern der Rechtevererbung,
  • welche Sicherheitsäquivalenzen zwischen Objekten bestehen sollen.

Die eDirectory-Administration und das benutzte administrative Modell muss auf jeden Fall geplant werden. Besonders auch die Einrichtung einer Rollen-basierten Administration und die Möglichkeit der Delegation von Administrationsaufgaben sind sicherheitskritisch. Bei sinnvoller, übersichtlicher und konsistenter Planung kann die Sicherheitsadministration durch diese Funktionalitäten transparenter und effizienter gestaltet werden.

Die Nutzung von eDirectory beinhaltet den Betrieb einer eigenen, eingebundenen Zertifizierungsstelle (CA). Auch hier muss sich die Planung nach den Anforderungen und besonders nach der zuvor aufgestellten Sicherheitsleitlinie richten.

Zusammengefasst ergeben sich folgende sicherheitsrelevante Kernaspekte bei der eDirectory-Planung:

  • Bäume begrenzen die administrative Macht von Administratoren und den Verzeichnisdienst an sich.
  • Standardmäßig ist bei der Erstinstallation von eDirectory der Benutzer Admin innerhalb des Organisationscontainers des eDirectory-Baums angelegt. Dieser besitzt das so genannte Supervisor-Recht auf den gesamten Baum.
  • Administrative Delegation wird durch die Vergabe von Zugriffsrechten auf eDirectory-Objekte und deren Attribute erreicht. Die Verteilung der Zugriffsrechte muss gemäß dem administrativen Modell erfolgen. Die Mechanismen für Zugriffsrechte im eDirectory sind unter anderem Vererbung, Kontrolle der Vererbung, Wirkungsbereich von Zugriffseinstellungen und Sicherheits-Äquivalenz zwischen Objekten. Damit können sehr komplexe Berechtigungsstrukturen aufgebaut werden, die sehr schnell unübersichtlich und nicht mehr administrierbar werden, so dass sich durch Fehlkonfigurationen im eDirectory Sicherheitslücken ergeben können. Eine möglichst einfache Berechtigungsstruktur ist daher vorzuziehen.
  • Schemaänderungen sind kritische Operationen und dürfen nur von autorisierten Administratoren nach sorgfältiger Planung durchgeführt werden.

Abschließend sei darauf hingewiesen, dass Fehler in der eDirectory-Planung und den zugrunde liegenden Konzepten nach erfolgter Installation nur mit beträchtlichem Aufwand zu berichtigen sind.

Prüffragen:

  • Wurde für jeden geplanten eDirectory-Server sein genauer Kontext innerhalb des Verzeichnisbaumes festgelegt?

  • Wurde eine eDirectory-Planung durchgeführt und dokumentiert?

  • Wurde die Synchronisation der Verzeichnisdaten mit weiteren Verzeichnisdiensten geplant?

  • Werden bei Schemaänderungen die Gründe für die Änderung dokumentiert?

  • Wurde das Konzept der Rollen-basierten Administratoren konsistent geplant?

  • Werden Schemaänderungen nur von autorisierten Administratoren nach sorgfältiger Planung durchgeführt?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK