Windows-Verwaltung

Delegieren von Befugnissen in Active Directory

Joel Yoker and Rob Campbell

Kurz zusammengefasst:

• Definieren von Administratorrollen
• Entwickeln eines Modells der Organisationseinheit und Sicherheitsgruppen
• Verwenden sekundärer Konten
• Tools für das Delegieren von Rechten

Die Delegierungsfunktionen in Active Directory sind ausgesprochen leistungsstark und können eine Anzahl von Sicherheitsproblemen lösen und Verwaltungsaufgaben vereinfachen. Durch das ordnungsgemäße Delegieren von Rechten in Active

Directory® können Sie festgelegte Rollen in der Umgebung durchsetzen, die Wahrscheinlichkeit von Administratorfehlern und die Folgen derartiger Fehler verringern und das Prinzip der geringsten Rechte innerhalb der Infrastruktur realisieren. Viele Organisationen, die sich auf Active Directory verlassen, schöpfen die Leistungsstärke der Delegierung nicht aus. Dies liegt zum Teil daran, dass das Entwickeln eines Active Directory-Delegierungsmodells für ein Unternehmen auf den ersten Blick als eine recht komplizierte Aufgabe erscheint. Die größte Hürde besteht im Entwickeln eines Delegierungsmodells, das den jeweiligen Anforderungen der Organisation entspricht. Es gibt jedoch sehr einfache Modelle, die mit geringfügigen Änderungen in fast allen IT-Infrastrukturen verwendet werden können.

Obwohl jede Umgebung ihre Besonderheiten aufweist, ähneln sich die meisten großen Unternehmen in vieler Hinsicht und stehen im Bereich IT vor den gleichen Herausforderungen. So sind z. B. viele Organisationen in geografische Regionen unterteilt, aus separaten Teams von IT-Technikern oder Support-Experten hervorgegangen und verfügen über unabhängige Geschäftsbereiche. Viele große Organisationen müssen sich mit Problemen wie der Rechteerweiterung, dem Missbrauch von Dienstkonten und mit „Vertrauen“ befassen.

Das Wort „Vertrauen“ ist ein interessanter Begriff und wird oft als Rechtfertigung für das Vorhandensein mehrerer Active Directory-Gesamtstrukturen verwendet. Probleme mit dem Vertrauen entstehen oftmals durch die Fähigkeit eines Geschäftsbereichs oder einer Region, die Systemverfügbarkeit für einen anderen Geschäftsbereich oder eine andere Region negativ zu beeinflussen. Normalerweise bestehen über die Grenzen innerhalb einer Organisation hinweg Unterschiede bei den Fähigkeiten und Fertigkeiten. Daraus ergibt sich ein Wissensdefizit bezüglich der Besonderheiten der Systeme, die für die Unterstützung einer bestimmten Region oder eines bestimmten Geschäftsbereichs erforderlich sind. Folglich möchten die Bereiche in den meisten Fällen ihre Administratorrechte nicht an eine zentralisierte Gruppe abtreten.

Mittlerweile ist es bei jeder Implementierung von Active Directory notwendig, dass die Administratoren die Regeln für das Aktivieren von Anwendungen definieren, welche die Infrastruktur von Active Directory nutzen. Leider besteht eine allgemein verbreitete Lösung (eine Lösung, die oftmals in Installationshandbüchern angegeben wird) darin, dass ein Dienstkonto als Mitglied der Gruppe der Domänenadministratoren eingerichtet wird. Das Problem bei dieser Vorgehensweise besteht darin, dass Dienstkonten ihrem Wesen nach allgemeine Konten sind. Durch das Gewähren von Rechten eines Domänenadministrators für diese Konten sorgen Sie für eine ernste Bedrohung für die IT-Umgebung. Dienstkonten können leicht durch böswillige oder unvorsichtige Administratoren einer unsachgemäßen Verwendung ausgesetzt werden, oder diese Konten werden von Angreifern ausgenutzt, die sich grundlegende Sicherheitsprobleme in einer Anwendung zunutze machen.

Obwohl diese Hürden möglicherweise unüberwindlich scheinen, stellen sie ein wichtigstes Szenario zum Implementieren eines Delegierungsmodells in Active Directory zur Verfügung. Das Entwickeln eines Delegierungsmodells ist ein iterativer Entwurfsprozess, und es empfiehlt sich, dass Sie dazu die folgenden Schritte ausführen:

1. Definieren Sie die Rollen für die IT-Administratoren innerhalb der Organisation.
2. Entwickeln Sie ein Modell für Organisationseinheit und Sicherheitsgruppe.
3. Richten Sie sekundäre Konten für IT-Administratoren ein.
4. Delegieren Sie Rechte.

Im Folgenden werden diese Schritte näher betrachtet.

Definieren von Rollen

Der Prozess für die Rollendefinition baut auf einem eingehenden Verständnis der Dienstverwaltung und der Datenverwaltung auf. Diese Begriffe sind die Säulen eines jeden Delegierungsmodells für Active Directory.

Seinem Wesen nach besteht die Dienstverwaltung in der Verwaltung der Infrastrukturkomponenten kritischer Verzeichnisdienste wie Exchange-Server und Domänencontroller. Die Datenverwaltung ist die Verwaltung von Objekten wie Postfächer und Benutzerkonten, die innerhalb dieser Dienste bestehen. Innerhalb des Wirkungsbereichs von Active Directory sind Dienstadministratoren letzten Endes für die Bereitstellung und die Verfügbarkeit der Verzeichnisdienste verantwortlich. Datenadministratoren verwalten demgegenüber Benutzer- und Serverkonten, Gruppen und andere Domänenressourcen.

Active Directory unterstützt über Organisationseinheiten (Organizational Units, OUs) die exakt umgrenzte Delegierung von Verantwortlichkeiten. Organisationseinheiten können oftmals so gestaltet werden, dass sie die gleiche Befugnisebene bieten, über die Administratoren innerhalb des vorhandenen Verzeichnisdienstes oder der vorhandenen Domänenmodelle verfügen. Es ist jedoch wichtig zu verstehen, dass einige Funktionen einfach nicht delegiert werden können und von einer einzelnen, höchst vertrauenswürdigen Gruppe oder Einheit verwaltet werden müssen.

Auch die Analyse der Aufgaben ist von entscheidender Bedeutung. Sie müssen wissen, welche Aufgaben in Active Directory von Administratoren ausgeführt werden und wie diese Aufgaben Rollen zugeordnet sind. So ist z. B. das Anlegen eines Active Directory-Standorts eine Dienstverwaltungsaufgabe, während Änderungen an der Mitgliedschaft in Sicherheitsgruppen gewöhnlich unter die Aufgaben der Datenverwaltung fallen. Jede Aufgabe sollte hinsichtlich Häufigkeit, Wichtigkeit und Schwierigkeit bewertet werden. Dies sind wichtige Aspekte der Aufgabendefinition, da sie bestimmen, ob ein Recht delegiert werden sollte. Aufgaben, die routinemäßig ausgeführt werden, nur ein begrenztes Risiko darstellen und einfach auszuführen sind, sind ausgezeichnete Kandidaten für eine Delegierung. Aufgaben, die selten ausgeführt werden, bedeutende Auswirkungen auf die Organisation haben und ein hohes Niveau an Fähigkeiten und Fertigkeiten erfordern, eignen sich dagegen nicht für eine Delegierung. Für diese Aufgaben ist stattdessen die Rechteerweiterung (das vorübergehende Heraufsetzen eines Kontos auf die erforderliche Rolle bzw. die Neuzuweisung der Aufgabe) die richtige Lösung.

Da sich viele Merkmale großer Organisationen ähneln, kann davon ausgegangen werden, dass ein allgemeines Delegierungsmodell implementiert werden kann. Für diesen Artikel werden wir einen Beispielsatz von Rollen bereitstellen, die Verwaltungsfunktionen ermöglichen und dabei Organisationsgrenzen respektieren und darauf abzielen, Vertrauensprobleme (wie z. B. die Verfügbarkeit von unternehmensweiten Ressourcen wie Domänencontroller) einzuschränken. Beachten Sie, dass dieses Modell lediglich ein Beispiel ist. Es bietet einen hervorragenden Ausgangspunkt für eine Diskussion über die Rollen in einer Organisation, sollte jedoch nicht buchstabengetreu umgesetzt werden.

Einige Rollen werden bereits von Active Directory festgelegt, und einige müssen von Grund auf neu festgelegt werden, um das Delegierungsmodell abzurunden. Ein Beispielsatz der Rollen, der für viele große Active Directory-Umgebungen geeignet wäre, enthält möglicherweise die Rollen „Organisations-Admins“, „Domänen-Admins“ und „Tier4-Admins“ für die Dienstverwaltung und „Tier3-Admins“, „Regional-Admins“, „Tier2-Admins“ und „Tier1-Admins“ für die Datenverwaltung. Eine Liste dieser Rollen und der zugehörigen Verantwortlichkeiten finden Sie in Abbildung 1.

Figure 1 Definieren von Rollen und Verantwortlichkeiten

Dienstadministratoren

Im Folgenden werden die Dienstadministratorrollen näher betrachtet. Dienstadministratoren verwalten kritische Infrastrukturkomponenten, und alle Administratoren in dieser Kategorie verfügen über umfangreiche Rechte. Daher ist in diesem Falle eine Strategie der geringsten Rechte äußerst angebracht. Dies bedeutet, dass lediglich der für die Ausführung der notwendigen Aufgaben benötigte minimale Satz an Berechtigungen vergeben wird.

Für Organisations- und Domänenadministratoren definiert Active Directory zwei Gruppen von speziellen Administratoren, deren Sicherheitskontext für kritische Funktionen innerhalb des Verzeichnisses erforderlich ist. Diese Gruppen (Organisations-Admins und Domänen-Admins) sind für die Dienstverwaltung auf höchster Ebene verantwortlich. Um die Risiken zu verringern, die mit solchen mit umfangreichen Rechten ausgestatteten Gruppen verknüpft sind, wird dringend angeraten, die Gruppenmitgliedschaft streng einzugrenzen. Genau gesagt, sollte die Gruppe der Organisations-Admins keine ständigen Mitglieder haben und die Gruppen der Domänen-Admins nur eine geringe, überschaubare Anzahl vertrauenswürdiger Personen enthalten, die auf Vollzeitbasis für die Organisation tätig sind.

Wenn unternehmensweite Verwaltungsaufgaben wie die DHCP-Serverautorisierung oder das Anlegen von Active Directory-Standorten ausgeführt werden müssen, können die Domänen-Admins in der Stammdomäne der Active Directory-Gesamtstruktur Berechtigungen durch Verwalten der Mitgliedschaft in der Gruppe der Organisations-Admins erweitern. Diese Berechtigungen sollten nur für kurze Zeit gewährt werden, um das Einrichten permanenter Mitglieder in der Gruppe der Organisations-Admins zu vermeiden. Selbstverständlich müssen alle Mitglieder der Gruppe „Domänen-Admins“ in einer gegebenen Active Directory-Gesamtstruktur das gleiche Vertrauen genießen.

Ein allgemein bekannter Fehler, den die meisten Organisationen beim Entwickeln eines Delegierungsmodells begehen, besteht im Deaktivieren oder Schwächen dieser Standardrollen. Änderungen an den Standardrollen können zu nicht vorhersagbaren Ergebnissen führen, und es gibt keine Garantie, dass Service Pack-Revisionen oder Produktupgrades diese Einstellungen übernehmen. Außerdem entsteht durch diese Art von Änderungen eine nicht unterstützte Umgebung außerhalb der Organisation. Eine praktikable Lösung besteht darin, die Standardgruppen und die Standardrollen zu nutzen, die Mitgliedschaft in diesen Gruppen jedoch einzuschränken. Um dies umzusetzen, müssen Sie wahrscheinlich neue Rollen für Administratoren erstellen, die sich bisher auf ihre Mitgliedschaft in Gruppen wie Domänen-Admins verlassen haben.

Tier4-Admins: Die Gruppe der Tier4-Administratoren sollte aus zentralisierten Dienstadministratoren bestehen, die Support für alle Unternehmensdienste bereitstellen. Da es sich um eine erstellte Rolle handelt, können Verzeichnisdienst und Berechtigungen für den Systemzugriff an die spezifischen Anforderungen der Organisation angepasst werden. Obwohl die Mitglieder dieser Gruppe Dienstadministratoren sind, können sie gelegentlich auch gesamtstrukturübergreifende Datenverwaltungsaufgaben durchführen. Da es viele Klassen von Systemen und verschiedene Verantwortungsbereiche gibt, werden Tier4-Rollen in verschiedene Untergruppen innerhalb des Verzeichnisses aufgeteilt. So sollten z. B. separateTier4-Gruppen erstellt werden, um eine eigenständige Verwaltung für bestimmte Systeme (z. B. Exchange Server) bereitzustellen. Diese Gruppe dient auch als Ansatzpunkt für die Rechteerweiterung für Datenadministratoren.

Ein Grund, warum Benutzer gern die Mitgliedschaft in der Gruppe der Domänenadministratoren erlangen möchten, besteht darin, dass sie über Administratorrechte für alle Systeme in einer Domäne verfügen möchten. Der Trick, diese Dienstadministratoren in einem Modus mit den geringsten Rechten arbeiten zu lassen, besteht darin, ihnen die Rechte eines Tier4-Administrators für die Unternehmensserver zu gewähren, ohne sie als Domänenadministratoren einzurichten. Um die Erweiterung von Rechten zu verhindern, sollten Tier4-Administratoren nicht als Mitglieder der Gruppe „BUILTIN\Administratoren“ auf Domänencontrollern eingerichtet werden, da diese Gruppe über eine Vielzahl an grundlegenden Rechten im Verzeichnisdienst verfügt, die untrennbar sind. Beispielsweise kann ein Mitglied der Gruppe „BUILTIN\Administratoren“ einer Domäne die Mitgliedschaft in der Gruppe „Domänen-Admins“ verwalten und somit Mitgliedern das Erweitern von Rechten ohne jegliche Überprüfungen und Abgleiche ermöglichen.

Wenn Sie sich an die Regel über das Nichteinschränken von Standardberechtigungen erinnern, kann dieses Risiko verringert werden, indem die Tier4-Gruppen als verschachtelte Mitglieder in den Standardgruppen der Server-Operatoren und der DNS-Administratoren eingerichtet werden. Dies ermöglicht die lokale Verwaltung der Domänencontroller und schränkt gleichzeitig die Möglichkeiten von Tier4-Administratoren zum Erweitern von Rechten ein. Für die meisten Systeme (die keine Domänencontroller, Zertifikatserver usw. sind) sollten Sie die Gruppe der Tier4-Administratoren als Mitglied der lokalen Administratorengruppe einrichten. Eine Automatisierung der Mitgliedschaft in verschachtelten lokalen Gruppen kann mit der Funktion „Eingeschränkte Gruppen“ in der Gruppenrichtlinie erreicht werden.

Datenadministratoren

Im Folgenden werden die Datenadministratorrollen näher betrachtet. Diese sollten mit kumulativen Rechten gestaltet werden. Das bedeutet, dass ein Tier2-Administrator über alle Rechte eines Tier1-Administrators und über einige zusätzliche Berechtigungen verfügen sollte usw. Aus diesem Grund sind die Gruppen in aufsteigender Reihenfolge angegeben.

Tier1-Admins: Die Gruppe der Tier1-Administratoren sollte allgemeine Verwaltungsaufgaben für bereits erstellte Verzeichnisobjekte ausführen. Diese Gruppe ist für Administratoren mit dem kleinsten Verantwortungsbereich oder für solche Administratoren vorgesehen, die isolierte Aufgaben wie das Zurücksetzen von Kennwörtern ausführen. Gewähren Sie dieser Gruppe die Rechte innerhalb ihrer Organisationseinheit zum Ändern der Eigenschaften von Benutzerkonten, zum Zurücksetzen der Kennwörter von Benutzerkonten, zum Entsperren von Konten, zum Aktivieren bzw. Deaktivieren von Benutzerkonten, zum Hinzufügen und Zurücksetzen von Konten auf Arbeitsstationen und zum Ändern der Mitgliedschaft in Gruppenobjekten für Gruppen ohne Administratorstatus.

Tier2-Admins: Diese Gruppe sollte das selektiven Verwalten und Erstellen von Objekten ermöglichen. Dabei sollten Objekte nur dort erstellt werden, wo sie von Tier1-Administratoren verwaltet werden können. (So können z. B. Sicherheitsgruppen nur in der Gruppen-Organisationseinheit erstellt werden). Tier2-Administratoren können Konten für Tier1-Administratoren hinzufügen und ändern, Benutzerkonten für eine Organisationseinheit hinzufügen, ändern und löschen, Computerobjekte des Typs „Arbeitsstation“ löschen und Objekte des Typs „Server“, „Kontakt“ und „Freigegebener Ordner“ hinzufügen, ändern und löschen.

Regional-Admins: Dieser Gruppe werden exklusive Rechte über die Struktur ihrer regionalen Organisationseinheit gewährt. Diese Administratoren können jedoch keine anderen Strukturen regionaler Organisationseinheiten innerhalb des Verzeichnisses verwalten. Regionaladministratorkonten sollten als mit umfangreichen Rechten ausgestattete Konten behandelt werden. Demzufolge werden diese Konten in einer separaten Hierarchie der Organisationseinheit gespeichert und durch die Dienstadministratoren der Gruppe „Tier4-Admins“ verwaltet. Regionaladministratoren können ohne Einschränkungen fast alle Objekte innerhalb der Struktur ihrer Organisationseinheit erstellen (ausgenommen hiervon ist jedoch das Erstellen anderer Organisationseinheiten). Dabei besteht das zusätzliche Risiko, dass Objekte erstellt werden, die von Benutzern auf niedrigeren Berechtigungsebenen nicht verwaltet werden können.

Tier3-Admins: Viele Organisationen verfügen über einen zentralisierten Helpdesk oder einen Helpdesk auf höherer Berechtigungsebene. Diese Rolle erstellt die Liste der Datenadministratoren und bildet somit eine Datenadministratorgruppe, die über allen Regionaladminstratoren angeordnet ist. Rechte werden an diese Gruppen nicht speziell innerhalb des Verzeichnisses delegiert. Stattdessen werden die Rechte über verschachtelte Mitgliedschaft in den einzelnen Regionaladministratorgruppen vergeben. Dies stellt einen Punkt auf höchster Ebene für die Rechteerweiterung für alle Datenadministratoren sowie einen Grenzübergang für Belange dar, die auf die Gruppen der Dienstverwaltung ausgeweitet werden müssen.

Erstellen eines Modells der Organisationseinheit und Sicherheitsgruppen

Nachdem die Rollen in der Organisation festgelegt sind, muss ein Modell der Organisationseinheit und Sicherheitsgruppen definiert werden. Es gibt zwei wichtige Gründe, eine Organisationseinheit in Active Directory zu erstellen: Zum Delegieren von Rechten und zum Einrichten eines Punkts, an dem Gruppenrichtlinienobjekte verknüpft werden können. Organisationseinheiten definieren einen Verwaltungsbereich (Scope of Management, SOM) innerhalb des Verzeichnisses, und dieser kann zum Einschränken von Rechten über Objekte auf verschiedenen Ebenen genutzt werden. Demzufolge sollte die Art und Weise der Delegierung von Befugnissen einer der wichtigsten Faktoren bei der der Implementierung der Struktur der Organisationseinheit sein.

Auf der Grundlage dessen sollte eine Organisationseinheit (oder eine Reihe von Organisationseinheiten) auf der obersten Ebene direkt unter der Domäne erstellt werden, um alle Objekte aufzunehmen. Diese Organisationseinheit dient dem speziellen Zweck der Definition des Verwaltungsbereichs für die Tier4-Administratoren. Durch das Erstellen einer Organisationseinheit auf höchster Ebene können Rechte über den Verzeichnisdienst explizit erst ab der Ebene der Organisationseinheit vergeben werden, anstatt bereits auf Domänenebene. Das Delegieren von einer Organisationseinheit der höchsten Ebene aus anstatt von der Domäne verringert das Risiko, das besteht, wenn Benutzer Berechtigungen durch Ändern der bereits erwähnten Standarddomänengruppen erweitern können.

Unter den Organisationseinheiten der höchsten Ebene sollten Sie separate Organisationseinheiten erstellen, um jede einzelne Region bzw. jeden einzelnen Geschäftsbereich darzustellen, die bzw. der über eigene Teams für die Datenverwaltung verfügt. Jede regionale untergeordnete Organisationseinheit sollte über eine gemeinsame, nicht erweiterbare Hierarchie der Organisationseinheiten für die Verwaltung der Verzeichnisobjekte verfügen. Einheitlichkeit ist für die alltägliche Verwaltung wichtig, da ein großer Umfang der Delegierung von Rechten automatisiert wird. Dies ist unter Umständen nicht einfach zu verwirklichen, da jede Region möglicherweise über eindeutige Organisationseinheiten verfügen möchte. IT-Administratoren sollten sich jedoch an die Vorgabe halten, und wenn eine Erweiterung für eine einzelne Region erforderlich ist, sollte die Struktur der untergeordneten Organisationseinheiten für alle Regionen erweitert werden. Dies mag anfänglich recht mühsam erscheinen, aber wenn die Organisation einen allgemeinen Speicherort für Objekte bereitstellt, werden die Ausnahmesituationen im Laufe der Zeit immer seltener auftreten.

Erstellen Sie zum Abschluss separate Gruppen und Konten für untergeordnete Administratoren, um Administratoren die Möglichkeit zum Erweitern ihrer Rechte zu nehmen: jeweils eine Gruppe von Tier1-Administratoren, Tier2-Administratoren und Regionaladministratoren für jede Hierarchie einer untergeordneten Organisationseinheiten. Das Platzieren dieser Konten in separate Organisationseinheiten ermöglicht die Einschränkung der Verwaltungsrechte auf die jeweilige Ebene oder die darunter liegende Ebene. Wenn alle Konten für Tier1-Administratoren und die zugeordnete Sicherheitsgruppe in einer Organisationseinheit untergebracht sind, in der sie über keine Rechte verfügen, sind Administratoren daher nicht in der Lage, die Kontrolle über andere Administratorkonten zu übernehmen oder die Berechtigungen anderer Administratoren auf ihre Ebene zu erweitern. Jedes Mitglied der Gruppe „Domänen-Admins“ kann z. B. jedes andere Benutzerkonto in der Domäne als Domänenadministrator einrichten. Mit dem vorliegenden Modell der Organisationseinheiten verringert sich dieses Risiko. Ein Beispiel für eine Organisationseinheitsstruktur mit zugeordneten Sicherheitsgruppen ist in Abbildung 2 dargestellt.

Abbildung 2** Organisationseinheitsstruktur mit zugeordneten Sicherheitsgruppen **

Einrichten sekundärer Konten

Der Schlüssel zu einem erfolgreichen Delegierungsmodell besteht im Durchsetzen des Prinzips der geringsten Rechte. In der Praxis bedeutet dies, dass ein Sicherheitsprinzipal ausschließlich die Möglichkeit zum Ausführen von Aufgaben haben sollte, die für die ihm zugewiesene Rolle erforderlich sind. Leider verwenden viele IT-Administratoren den gleichen Sicherheitsprinzipal für die Verzeichnisverwaltung und für alltägliche Aufgaben wie Webbrowsing und das Lesen von E-Mails. Durch das Einrichten separater Konten verringert sich die Wahrscheinlichkeit, dass ein Administrator einer niedrigeren Schicht versehentlich den Verzeichnisdienst beschädigt oder Opfer eines Angriffs wird, der über alltägliche Anwendungen erfolgt, jedoch auf den Verzeichnisadministrator abzielt.

Um dies zu erreichen, ohne dass sich der Benutzer abmelden und erneut anmelden muss, verwenden Sie den Dienst „Sekundäre Anmeldung“ (Runas.exe). Dies ermöglicht Benutzern, ihre Berechtigungen durch Bereitstellen eines anderen Satzes an Anmeldeinformationen beim Ausführen von Skripts oder EXE-Dateien auf Servern und Arbeitsstationen heraufzusetzen.

Obwohl das Konzept der Konten mit geringsten Rechten verhältnismäßig einfach ist, finden Organisationen die Durchsetzung in manchen Fällen schwierig, da bestimmte Gewohnheiten möglicherweise schwer zu ändern sind. Eine einfache Lösung zu verhindern, dass Konten mit hohen Berechtigungen für alltägliche Aufgaben verwendet werden, besteht darin, diesen Konten keinen Mailzugriff in Exchange Server zur Verfügung zu stellen. Dies kann durch administrative Richtlinien innerhalb der Organisation erreicht werden. Diese verhältnismäßig einfache Lösung verringert die Wahrscheinlichkeit, dass die Konten für alltägliche, nichtadministrative Aufgaben verwendet werden, erheblich.

Delegieren von Rechten

Der letzte Schritt bei der Entwicklung eines Delegierungsmodells besteht in der Delegierung von Rechten in Active Directory. Hierzu ist das Bearbeiten von Zugriffssteuerungseinträgen (Access Control Entries, ACEs) und Zugriffssteuerungslisten (Access Control Lists, ACLs) von Daten erforderlich, die innerhalb des Verzeichnisses gespeichert sind. ACLs für Active Directory-Container definieren, welche Objekte erstellt werden können und wie die Objekte verwaltet werden. Die Delegierung von Rechten beinhaltet grundlegende Bearbeitungsvorgänge für Objekte, wie z. B. die Möglichkeit, ein Objekt anzuzeigen, ein untergeordnetes Objekt einer Klasse zu erzeugen oder Attribut- und Sicherheitsinformationen über Objekte einer Klasse zu lesen. Neben diesen grundlegenden Vorgängen definiert Active Directory „Erweiterte Rechte“, die Vorgänge wie z. B. „Senden als“ und „Replikationstopologie verwalten“ ermöglichen.

In den vorherigen Schritten wurde das Erstellen von Sicherheitsgruppen behandelt, die definierten organisatorischen Rollen zugeordnet sind. Dies bedeutet, dass durch die Struktur der untergeordneten Organisationseinheiten eine zugeordnete Sicherheitsgruppe für jede Rolle vorhanden ist. Um das Delegierungsmodell zu implementieren, müssen diesen Gruppen Berechtigungen für die Objekte im Verzeichnis zugewiesen werden. An dieser Stelle geht es nicht darum, ein komplett neues Verfahren anzuwenden und eine hochspezielle Umgebung einzurichten. Versuchen Sie stattdessen, Standardgruppen und -rechte nach Möglichkeit wirksam einzusetzen. Angenommen, eine spezielle Rolle muss DNS-Einträge für die Gesamtstruktur verwalten. Versuchen Sie nicht, Rechte für die Container und die Namenskontexte bezüglich des in Active Directory integrierten DNS zu delegieren. Setzen Sie stattdessen einfach die Gruppe „BUILTIN\DNS-Admins“ wirksam in der Domäne ein. Außerdem können Benutzerrechte und andere Berechtigungen über die Funktion „Gruppenrichtlinie“ erweitert werden, um zusätzliche Rechte bereitzustellen, die zum Verwalten einer bestimmten Klasse des Systems durch eine vorgegebene Rolle benötigt werden.

Wenn Sie Berechtigungen mithilfe der Delegierung zuweisen, sollten Sie die Verwendung von Verweigern-ACEs innerhalb des Verzeichnisses einschränken oder komplett ausschließen. Dies könnte schwierig werden, wenn eine Problembehandlung notwendig wird. Eine bessere Lösung besteht darin, mithilfe von expliziten Zulassen-ACEs den speziellen Gruppen, die Ihre Rollen darstellen, Rechte zu gewähren. Denken Sie daran, dass benutzerdefinierte Rollen wie z. B. Tier4-Administratoren nur über die expliziten Rechte verfügen, die durch diese Rolle definiert sind.

Die Vererbung ist für die Active Directory-Sicherheit von entscheidender Bedeutung und definiert, wie eine bestimmte ACL für untergeordnete Objekte in einem Container oder untergeordneten Container angewendet wird. Geben Sie die Reichweite der Vererbung immer genau vor, indem Sie sicherstellen, dass vererbbare ACEs so genau wie möglich auf die Zielobjekte angewendet werden. Vererbbare Verweigerungsberechtigungen, die für das übergeordnete Objekt gelten, haben Vorrang vor allen vererbbaren Verweigerungsberechtigungen, die auf das dem übergeordneten Objekt übergeordnete Objekt angewendet werden. Dies ist einer der Hauptgründe, warum Verweigern-ACEs für eine brauchbare Delegierung nicht empfohlen werden. Darüber hinaus können vererbbare Berechtigungen keinen expliziten ACE für ein Objekt überschreiben. Aus diesem Grund wird empfohlen, dass Sie die Möglichkeit für untergeordnete Administratoren, Änderungen an der DACL (Discretionary Access Control List, freigegebene Zugriffssteuerungsliste) (durch Entfernen der Berechtigung „Write DACL“) für Verzeichnisobjekte vorzunehmen, einschränken oder ganz ausschließen. (Beachten Sie, dass der Ersteller des Objekts implizit über diese Rechte verfügt.) Grundsätzlich gilt, dass Administratoren, welche die Möglichkeit haben, die DACL für ein Objekt zu ändern, dies wahrscheinlich auch ausführen werden. Sorgen Sie dafür, dass die Arbeit und Mühe, die Ihre Organisation auf das Delegierungsmodell verwendet hat, nicht zunichte gemacht wird, indem Sie Raum für Beliebigkeiten und potenzielle administrative Fehler lassen.

Es gibt eine Anzahl an Tools, die Sie für das ordnungsgemäße Implementieren eines Active Directory-Delegierungsmodells benötigen werden. Für die meisten großen Organisationen ist die Verwendung des integrierten Delegierungsassistenten zum Zuweisen von Berechtigungen im Verzeichnis eine schwierige Aufgabe, die viele Möglichkeiten für administrative Fehler bietet. Stattdessen sollte immer durch Automatisierung sichergestellt werden, dass das Delegierungsmodell gut dokumentiert ist, dass es supportfähig ist und dass es eine Wiederherstellungsoption bietet, falls Einstellungen verloren gehen oder versehentlich geändert werden.

Das wichtigste Tool, das für das Implementieren der Delegierung benötigt wird, ist DSACLS.EXE, ein Befehlszeilenprogramm zum Bearbeiten von Verzeichnisdienst-ACLs für Objekte. Dieses Tool ermöglicht auch das Vorgeben von Vererbungskennzeichen für eine DACL, die im übergeordneten Objekt angegeben wird. (Zu den Vererbungskennzeichen gehören „this object and sub-objects“ (dieses Objekt und untergeordnete Objekte), „sub-objects only“ (nur untergeordnete Objekte) und „propagate inheritable permissions one level only“ (vererbbare Berechtigungen nur an eine Ebene übermitteln).) DSACLS-Befehle schlagen fehl, wenn ein Vererbungskennzeichen nicht richtig festgelegt ist. Deshalb ist ein Test beim Verwenden dieses Tools unumgänglich. Im Folgenden ist Beispiel der DSACLS-Syntax zum Delegieren der Möglichkeit, Computerobjekte in der Ziel-Beispielorganisationseinheit zu erstellen:

dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer

DSACLS unterscheidet zwischen Groß- und Kleinschreibung bei Objekttypen. Das bedeutet, dass der Versuch, Berechtigungen für die Objektklasse „cn=Computer“ durch Eingabe von „cn=computer“ zu delegieren, nicht fehlschlagen wird (siehe Abbildung 3).

Abbildung 3** Fehler aufgrund der Groß-/Kleinschreibung **(Klicken Sie zum Vergrößern auf das Bild)

Für das Erstellen einiger Objekte ist ein bestimmter Satz an Rechten erforderlich. Dies ist auf die Attribute „muss enthalten“ und „kann enthalten“ von Objekten zurückzuführen. Die beste Metapher, die ich zur Verdeutlichung dieses Konzepts gehört habe, ist das Hamburgermodell. Hamburger müssen eine Frikadelle und ein Brötchen haben, um als Hamburger zu gelten. Dies sind die Attribute „muss enthalten der Objektklasse „Hamburger“. Elemente wie z. B. Pickles, Ketchup, Salat usw.sind Attribute „kann enthalten“. Wenn wir die Objektklasse erweitern, um einen Cheeseburger zu definieren, würden wir Käse in die Liste der Attribute „muss enthalten“ einfügen.

Benutzerobjekte funktionieren auf gleiche Weise. Nehmen wir an, dass wir uns an dieses Modell halten müssen, um mithilfe der folgenden DSACLS-Syntax Benutzerobjekte zu erstellen:

dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user 

Der Administrator würde während des Anlegens des Benutzerobjekts mit mehreren Fehlern konfrontiert werden. Wir müssen die notwendigen Berechtigungen gewähren, um erforderliche Attribute für das Benutzerobjekt festzulegen, einschließlich Festlegen des Kennworts. Dies wird in der folgenden zusätzlichen DSACLS-Syntax realisiert.

Im ersten Schritt gewähren Sie die Berechtigung, „muss enthalten“-Attribute zu schreiben, indem Sie „Generic Read/Generic Write“ für alle Attribute der Benutzerklasse zulassen:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user

Im nächsten Schritt gewähren Sie das erweiterte Recht, das Kennwort zu ändern:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user

Im letzten Schritt gewähren Sie die Berechtigungen „Read Property“ und „Write Property“ für das Attribut „Password Last Set“:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user

Nachdem die entsprechenden Rechte delegiert wurden, werden die definierten Rollen auf das Verwalten von Objektklassen, die in der DACL des Containers definiert sind, eingeschränkt. Wenn wir bei dem oben erwähnten Beispiel eines Computerobjekts bleiben, schränkt das Kontextmenü in Active Directory-Benutzer und -Computer die Liste neuer Objekte ein, die von einem Benutzer erzeugt werden können, an den derartige Rechte delegiert wurden (siehe die eingeschränkte Liste in Abbildung 4).

Abbildung 4** Eingeschränkte Liste neuer Objekte **

DSACLS kann auch so eingerichtet werden, dass eine komplexe Bereitstellung von Rechten automatisch erfolgen kann. Hier sind einige der DSACLS-Befehle, mit denen Sie Rechte delegieren können, um gemeinsame Adressattribute von Benutzerobjekten in einem gegebenen Container zu ändern:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user

Beispiele wie diese treten bei den meisten Delegierungsmodellen auf und können in Verbindung mit den zuvor definierten Rollen verwendet werden.

Ein anderes Tool, das für das Implementieren von Delegierung verwendet wird, ist DSREVOKE.EXE. Mit diesem Tool können Administratoren delegierte Rechte für bestimmte Sicherheitsprinzipale von Objekten innerhalb des Verzeichnisses ermitteln und entfernen. Obwohl es sich um ein sehr hilfreiches Tool handelt, bezieht es sich auf einen Sicherheitsprinzipal und bewertet nicht geschachtelte Mitgliedschaften innerhalb von Sicherheitsgruppen.

Außer diesen Befehlszeilenprogrammen empfehlen wir unbedingt auch die Verwendung von „Zuweisen von Benutzerrechten“ und „Eingeschränkte Gruppen“ mit Gruppenrichtlinien. Wie bereits weiter oben besprochen, ermöglicht „Zuweisen von Benutzerrechten“ IT-Administratoren untergeordnete Rechte (wie z. B. das Recht, auf ein System von einem Remotestandort aus zuzugreifen und es neu zu starten) für verschiedene Gruppen von Benutzern auf vorgegebenen Zielsystemen auszudehnen oder zu entfernen. Mithilfe eingeschränkter Gruppen können Mitgliedschaften in lokalen Gruppen und Domänengruppen innerhalb der Gesamtstruktur vorgegeben und durchgesetzt werden. In Kombination stellen diese Tools alles bereit, was Sie für die Automatisierung und das Implementieren eines Delegierungsmodells für Active Directory benötigen.

Zusammenfassung

Obwohl die Aufgabe, ein Active Directory-Delegierungsmodell zu entwickeln, komplex erscheinen mag, können in Wahrheit für die meisten IT-Infrastrukturen sehr einfache Modelle verwendet werden. Einer der wichtigsten Schritte beim Bereitstellen eines funktionierenden Delegierungsmodells besteht im Definieren klarer Rollen. Sie sollten die definierten Rollen auf eine kleine, überschaubare Anzahl beschränken. Es ist nicht einfach, die optimale Anzahl zu finden. Zu viele Rollen führen zu Rollen, die nie genutzt werden, zu wenige Rollen hingegen ergeben keine ausreichende Trennung von Rollen.

Denken Sie beim Definieren von Aufgaben daran, diese nach Häufigkeit, Wichtigkeit und Schwierigkeitsgrad zu klassifizieren. Nachdem Sie die Rollen definiert haben, entwickeln Sie einen Satz von Anwendungsfällen. Dadurch können Sie besser erkennen, was jede Rolle kann oder nicht kann, und der Prüfungsprozess kann einfacher automatisiert werden. Gut vorbereitete Anwendungsfälle werden Ihnen helfen, diese Rollen den Interessengruppen in der Organisation zu erklären und das Auftreten von Überraschungen aufgrund von Fehlern bei der Automatisierung zu vermeiden.

Schließlich ist beim Entwickeln eines Delegierungsmodells ein praktischer Ansatz immer eine gute Idee. Denken Sie daran: Einfachheit ist gleichbedeutend mit Unterstützbarkeit, und ein tragfähiges Delegierungsmodell wird sich beim Kontrollieren von Administratorrechten innerhalb Ihrer Active Directory-Umgebung durch gewaltige Nutzeffekte auszahlen.

Weitere Ressourcen

• Design Considerations for Delegation of Administration in Active Directory (auf Englisch)
• Best Practices for Delegating Active Directory Administration (auf Englisch)

Joel Yoker ist Senior Consultant im Microsoft Federation Team. Joel Yoker und Rob Campbell befassen sich hauptsächlich mit der Entwicklung und Bereitstellung von Sicherheitslösungen für die Bundesregierung der USA.

Rob Campbell ist Senior Technical Specialist im Microsoft Federation Team. Joel Yoker und Rob Campbell befassen sich hauptsächlich mit der Entwicklung und Bereitstellung von Sicherheitslösungen für die Bundesregierung der USA.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.