Windows-Verwaltung

Entwerfen funktionierender Organisationseinheitsstrukturen

Ken St. Cyr

Kurz zusammengefasst:

• Hauptprinzipien für das Entwerfen von Organisationseinheiten
• Modelle für den Organisationseinheitsentwurf
• Dokumentieren des Organisationseinheitsentwurfs

Unterschätzen Sie nicht die Bedeutung – und Komplexität – des Entwerfens einer guten Organisationseinheitsstruktur. Ich habe festgestellt, dass IT-Abteilungen häufig in eines von zwei Extremen verfallen:

Entweder messen sie der Struktur der Organisationseinheiten zu viel Bedeutung zu – oder nicht genug. Beides kann zu Problemen mit Ihrem Active Directory®-Modell führen.

Durch Überbetonung der Organisationseinheitsstruktur geraten andere Bereiche des Active Directory-Entwurfs aus dem Blickfeld, beispielsweise die Planung der Standorttopologie oder Überlegungen zur Größe des Domänencontrollers. Wenn andererseits die Planung der Organisationseinheiten in den Hintergrund gerät, wirkt sich dies negativ auf Gruppenrichtlinien und Delegierung aus.

Eine der Ausreden, die ich gelegentlich gehört habe, lautet, dass die Struktur der Organisationseinheiten flexibel ist und zu einem späteren Zeitpunkt geändert werden kann, falls sie nicht passt. Es stimmt, dass die Struktur der Organisationseinheiten flexibel ist. Administratoren stellen jedoch häufig fest, dass die spätere Änderung der Organisationseinheitsstruktur schwieriger ist als ursprünglich angenommen. Natürlich können neue Organisationseinheiten hinzugefügt werden – die alten Organisationseinheiten lassen sich jedoch nicht ohne weiteres bereinigen.

Eine schlecht geplante Organisationseinheitsstruktur entwickelt oft ein Eigenleben. Wenn ein neues Objekt im Verzeichnis erstellt wird und der Administrator nicht weiß, wo er es in der Organisationseinheitsstruktur platzieren muss, erstellt er entweder eine neue Organisationseinheit oder fügt das Objekt an einer Stelle ein, an die es nicht gehört. Beide Szenarios sind mit Gefahren verbunden. Eine neue Organisationseinheit lässt sich zwar mühelos erstellen, aber langfristig nur schwer überwachen. Die planlose Erstellung von Organisationseinheiten trägt zu einer chaotischen Organisationseinheitsstruktur bei, und es schleichen sich leicht undokumentierte Elemente in das Verzeichnis ein. Wenn Sie andererseits ein Objekt zu einer vorhandenen Organisationseinheit hinzufügen, in die es nicht wirklich gehört, könnten dem neuen Objekt Richtlinien zugewiesen werden, die es nicht erhalten sollte, oder Berechtigungen für das Objekt könnten an andere als die vorgesehenen Benutzer delegiert werden.

Beim Entwerfen von Organisationseinheitsstrukturen sollten Sie eine einfache Gleichung beachten: Einfachheit + Anpassungsfähigkeit = Nachhaltigkeit. Wenn Ihr Entwurf zu einfach ist, kann er möglicherweise nicht angepasst werden und muss daher zu oft geändert werden. Ist Ihr Entwurf zu anpassungsfähig, ist alles bis ins Kleinste aufgeschlüsselt, was eine zu hohe Komplexität mit sich bringt.

Es gibt drei Hauptprinzipien hinsichtlich Gruppenrichtlinien, Delegierung und Objektverwaltung, auf die Sie sich bei Ihrer Entwurfsentscheidung stützen können. Diese Prinzipien können in Form von drei Fragen zusammengefasst werden, die Sie sich stellen sollten, um sicherzustellen, dass sich die Organisationseinheitsstruktur, die Sie erstellen, langfristig und bei organisatorischen Änderungen bewährt:

1. Muss diese Organisationseinheit erstellt werden, damit ein eindeutiges Gruppenrichtlinienobjekt auf sie angewendet werden kann?
2. Muss eine bestimmte Gruppe von Administratoren über Berechtigungen für die Objekte in dieser Organisationseinheit verfügen?
3. Wird diese neue Organisationseinheit die Verwaltung der in ihr enthaltenen Objekte vereinfachen?

Wenn die Antwort auf eine dieser Fragen „Ja“ lautet, sollten Sie die Organisationseinheit wahrscheinlich erstellen. Lautet die Antwort auf alle drei Fragen „Nein“, sollten Sie das Layout überdenken und feststellen, ob ein anderer Entwurf vielleicht besser passt. Bevor ich jedoch näher darauf eingehe und Ihnen zeige, wie Sie diese Prinzipien anwenden, sollte ich zuerst erklären, warum diese Prinzipien so wichtig sind.

Prinzip 1: Gruppenrichtlinie

Das erste Prinzip des Entwurfs von Organisationseinheiten besteht darin, die Gruppenrichtlinienobjekte zu berücksichtigen, die auf eine Organisationseinheit angewendet werden. Ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) ermöglicht es Ihnen, Einstellungen für Benutzer und Computer auf durchsetzbare Weise zu konfigurieren. Sie können mehrere GPOs in Active Directory definieren und sie auf die gesamte Domäne, verschiedene Organisationseinheiten oder sogar auf die Standorte in der Domäne anwenden. GPOs werden in zwei Kategorien eingeteilt – eine für Benutzer und eine für Computer.

In ein und demselben GPO können sowohl Computerrichtlinien als auch Benutzerrichtlinien definiert werden. Im Abschnitt „Benutzerkonfiguration“ des GPO wird hauptsächlich die Funktionalität für angemeldete Benutzer definiert. Diese Arten von Einstellungen sind im Abschnitt „Computerkonfiguration“ ebenfalls vorhanden, er enthält jedoch weitere Einstellungen, die mit der Sicherheit des Computers in Verbindung stehen, z. B. welche Benutzer sich lokal beim Computer anmelden können oder wie Daten verschlüsselt werden.

Bei der Definition von Organisationseinheiten zur Unterstützung von GPOs sollten die folgenden Grundsätze beachtet werden. Zunächst einmal gilt: Nur weil Benutzer- und Computerrichtlinien im gleichen GPO definiert werden können, bedeutet dies nicht, dass es empfehlenswert ist, Benutzer- und Computerobjekte in der gleichen Organisationseinheit zu platzieren. Durch ihre Kombination im gleichen GPO wird die Problembehandlung bei der GPO-Anwendung erschwert. Dies wird schnell offensichtlich, wenn Sie eine Loopbackrichtlinie aktiviert haben.

Darüber hinaus vergessen viele Leute, dass GPOs auf Standortebene angewendet werden können, und entwerfen daher ihre Organisationseinheitsstrukturen so, dass ihre Standortstruktur für die GPO-Anwendung modelliert wird. Dabei handelt es sich um ein allgemeines Modell für den Entwurf von Organisationseinheiten, das als „geografisches Modell“ bezeichnet wird. Ich werde an späterer Stelle näher auf dieses Modell eingehen. Es wäre nachlässig, nicht anzuerkennen, dass das geografische Modell beim Entwerfen von Organisationseinheiten seine Berechtigung hat. Wie Sie jedoch später sehen werden, bin ich nicht davon überzeugt, dass die GPO-Anwendung der Hauptgrund für die Implementierung dieses Modells sein sollte.

Wenn bei Ihrer Organisationseinheitsstruktur GPOs im Vordergrund stehen, sollte zudem das Ziel verfolgt werden, Komplexität zu beseitigen. Stellen Sie sicher, dass die Organisationseinheit zum Fluss der GPO-Vererbung beiträgt. Wenn Ihre Organisationseinheit Server enthält, die die gleiche Richtlinie wie andere Server erfordern, sollten Sie die Möglichkeit in Betracht ziehen, diese Computerobjekte unter einer breiter gefassten Organisationseinheit namens „Server“ anzuordnen und mehrere Organisationseinheiten für unterschiedliche Servertypen unterhalb der Organisationseinheit „Server“ zu erstellen (siehe Abbildung 1). Dies kann die Richtlinienanwendung vereinfachen, da jedes Computerobjekt in den untergeordneten Organisationseinheiten die Richtlinie von der Organisationseinheit „Server“ sowie alle anderen Richtlinien erhält, die speziell für diesen Servertyp gelten.

Abbildung 1** Erstellen mehrerer Organisationseinheiten für unterschiedliche Servertypen **(Klicken Sie zum Vergrößern auf das Bild)

Ein weiterer Grundsatz besteht darin sicherzustellen, dass Sie nicht ohne zwingenden Grund mehrere GPOs erstellen oder verknüpfen. Mit einem GPO können Sie eine Richtlinie erstellen und sie auf mehrere Organisationseinheiten anwenden. Dies ist manchmal hilfreich, kann aber auch gefährlich sein. Wenn Sie eine GPO-Einstellung ändern müssen und über ein übermäßig komplexes System verknüpfter GPOs verfügen, besteht das Risiko, dass Sie eine Änderung versehentlich auf die falschen Objekte anwenden. Je mehr Verknüpfungen Sie erstellen, desto schwerer lässt sich der Geltungsbereich einer Richtlinie erfassen. Sie sollten ebenso die Erstellung zusätzlicher Richtlinien vermeiden, die die gleichen Einstellungen wie andere Richtlinien besitzen. Wenn Sie feststellen, dass dies häufig vorkommt, sollten Sie die Änderung Ihrer Organisationseinheitsstruktur für die Anwendung eines neuen GPO-Vererbungsmodells in Erwägung ziehen.

Sie sollten auch in nahezu allen Fällen eine neue Organisationseinheit für Benutzerobjekte und Computerobjekte erstellen. Standardmäßig werden Benutzer- und Computerobjekte in Containern platziert, die es nicht zulassen, dass Sie GPOs direkt mit ihnen verknüpfen. GPOs können über die Domäne auf die Container „Benutzer“ und „Computer“ angewendet werden. Wenn Sie die Vererbung nicht an anderer Stelle blockieren, werden diese Richtlinien aber auf jeden Benutzer und Computer in der Domäne angewendet. In Windows Server® 2003 können Sie mithilfe der Tools „rediruser.exe“ und „redircomp.exe“ den Standardspeicherort für Benutzer- und Computerobjekte in die Organisationseinheit ändern, die Sie für sie erstellt haben.

Prinzip 2: Delegierung

Es ist wichtig, dass Sie die Organisationseinheitsstruktur so erstellen, dass sie der Art und Weise entspricht, auf die Berechtigungen in der Domäne delegiert werden. Beachten Sie, dass bei der Delegierung von Berechtigungen in Active Directory die Berechtigungsänderungen nur am Objekt vorgenommen werden. Wenn Sie einem Benutzer Vollzugriff für ein bestimmtes Computerobjekt gewähren, könnte diese Person daher die Attribute des Objekts ändern, verfügt jedoch nicht über Administratorrechte für den Computer selbst.

Wenn Sie eine Organisationseinheitsstruktur entwerfen, werden die folgenden Methoden im Hinblick auf die Delegierung empfohlen:

Berücksichtigen Sie beim Entwerfen die Berechtigungsvererbung Angenommen, Sie möchten beispielsweise, dass Ihre Administratoren der Stufe 1 das Kennwort für die meisten Konten ändern können. Es gibt eine spezielle Gruppe von Benutzern, für die die Administratoren nicht die Möglichkeit zum Zurücksetzen von Kennwörtern haben sollten, die Administratoren müssen jedoch die Anzeigenamen dieser Konten ändern können.

In diesem Fall haben Sie zwei Möglichkeiten: Einerseits könnten Sie zwei separate, parallele Organisationseinheiten erstellen und die speziellen Benutzer von den regulären Benutzern trennen. Wenn Sie die Delegierungsoptionen für alle Benutzer ändern möchten, bedeutet dies jedoch, dass Sie diese Berechtigungen an zwei verschiedenen Stellen ändern müssen. Dies widerspricht zudem dem Grundsatz, nicht ohne zwingenden Grund mehrere Richtlinien zu verknüpfen (siehe Abbildung 2).

Abbildung 2** Verwaltung von zwei separaten, parallelen Organisationseinheiten **(Klicken Sie zum Vergrößern auf das Bild)

Die andere Option besteht darin, eine geschachtelte Organisationseinheit zu erstellen und explizit die Berechtigung für die Organisationseinheit zu verweigern, die spezielle Benutzer enthält. Jeder Delegierungsexperte kann Ihnen sagen, dass explizites Verweigern nicht empfehlenswert ist – in diesem Fall müssen Sie jedoch das kleinere von zwei Übeln wählen (siehe Abbildung 3). Sie können entweder die Einstellungen für zwei separate Organisationseinheiten duplizieren und verwalten oder für eine der Organisationseinheiten die Berechtigung explizit verweigern. Das explizite Verweigern ist tatsächlich langfristig die bessere Entscheidung.

Abbildung 3** Explizites Verweigern der Berechtigung **(Klicken Sie zum Vergrößern auf das Bild)

Achten Sie auf AdminSDHolder Dieses Beispiel funktioniert gut, sofern die speziellen Benutzer nicht alle zu einer der Administratorgruppen (Domänen-Admins, Schema-Admins, Organisations-Admins oder Administratoren) gehören, da Berechtigungen für Konten in diesen Gruppen anders behandelt werden. Dahinter steht der Gedanke, dass Sie nicht versehentlich einem Benutzer Berechtigungen für ein Administratorkonto erteilen möchten.

Wenn Sie eine separate Organisationseinheit für Administratoren erstellen, werden Sie feststellen, dass die an sie delegierten Berechtigungen immer wieder verschwinden. Dies wird durch AdminSDHolder verursacht, einen speziellen Container, dessen Zugriffssteuerungsliste in bestimmten Intervallen auf jedes Administratorkonto angewendet wird. Daher werden alle Delegierungsänderungen, die Sie an einem Administratorkonto vornehmen, rückgängig gemacht, wenn die Änderungen nicht auch am AdminSDHolder-Container vorgenommen werden. Daher sollten Sie Administratorkonten nicht zwecks Delegierung von anderen Konten trennen. Für Gruppenrichtlinien ist die Trennung der Administratorkonten jedoch vorzuziehen – dies gilt insbesondere in Windows Server 2008, wo mehrere Kennwortrichtlinien vorhanden sein können.

Prinzip 3: Objektverwaltung

Die Organisationseinheit sollte die Verwaltung der Objekte erleichtern. Durch die Gruppierung von Objekten in derselben Organisationseinheit kann die Durchführung von Massenänderungen häufig vereinfacht werden. Mithilfe des Snap-Ins „Active Directory-Benutzer und -Computer“ können Sie bestimmte Attribute für mehrere ausgewählte Objekte bearbeiten. Wenn Sie ein Attribut für eine Gruppe von Objekten regelmäßig ändern müssen, ist dieser Vorgang einfacher, wenn sie sich alle in der gleichen Organisationseinheit befinden.

Dies ist zudem besonders nützlich, wenn Sie mithilfe eines Skripts Aktualisierungen durchführen. Anhand von Skriptsprachen können alle Objekte in einer Organisationseinheit auf äußerst einfache Weise aufgelistet und einzeln behandelt werden. Eine andere Möglichkeit besteht darin, jedes Objekt einzeln zu suchen und zu ändern. Manchmal bleiben Ihnen pro Woche mehrere Stunden unnötiger Arbeit erspart, wenn Sie die Objekte zur Verwaltung einfach in der gleichen Organisationseinheit platzieren.

Eine weitere Möglichkeit zur einfacheren Verwaltung der Objekte besteht darin, die Objekte in Abhängigkeit von ihrem Typ auf verschiedene Organisationseinheiten aufzuteilen. Durch Erstellen einer separaten Organisationseinheit für Druckerobjekte oder veröffentlichte Freigaben wird sichergestellt, dass diese Objekte nicht aussortiert werden müssen, wenn Sie Verwaltungsaufgaben für andere Objekte in der Organisationseinheit durchführen. Diese Methode entspricht auch dem Grundsatz, Benutzer- und Computerkonten nicht zusammen in derselben Organisationseinheit zu gruppieren.

Auswählen eines Modells

Nachdem ich nun die Prinzipien für das Entwerfen von Organisationseinheiten erläutert habe, kann ich näher auf einige verbreitete Entwurfsmodelle eingehen. Beachten Sie, dass es neben den in diesem Artikel beschriebenen Modellen viele weitere Modelle gibt. Sie müssen sich auch nicht auf ein einziges Modell beschränken, sondern können Teile verschiedener Modelle auswählen und daraus ein eigenes Hybridmodell entwickeln, das Ihre speziellen Anforderungen erfüllt.

Nahezu jedes Modell kann im kleinen Rahmen erfolgreich sein, aber wenn Ihr Unternehmen wächst, wird es immer schwerer, den Überblick über die Umgebung zu behalten. Stellen Sie daher sicher, dass Sie Ihr Modell zuerst in einer angemessenen Testumgebung gründlich testen. Sie sollten auch Folgendes nicht vergessen: Obwohl Organisationseinheitsstrukturen anfangs problemlos geändert werden können, wird dies immer schwieriger, je länger sie bestehen.

Das flache Modell

Das flache Modell verdankt seinen Namen der Tatsache, dass es größtenteils flach gehalten wird. In diesem Modell enthalten einige wenige grundlegende Organisationseinheiten die Mehrheit der Objekte (siehe Abbildung 4). Dieses Modell wird zumeist in kleineren Unternehmen verwendet, in denen es nur eine kleine IT-Abteilung gibt, nicht viele verschiedene Geschäftsbereiche vorhanden sind oder Mitarbeiter in der Regel mehrere Rollen übernehmen. Ich empfehle normalerweise, mit nicht mehr als 10 Ebenen untergeordneter Organisationseinheiten zu arbeiten, obwohl es laut Microsoft erst bei Überschreitung eines Grenzwerts von 15 Ebenen zu Leistungseinbußen kommt.

Abbildung 4** Das flache Modell umfasst einige wenige grundlegende Organisationseinheiten, die die Mehrheit der Objekte enthalten **(Klicken Sie zum Vergrößern auf das Bild)

Wenn Ihr Verantwortlicher für Personalfragen auch für die Lohn- und Gehaltsabrechnung verantwortlich ist, ist es nicht sinnvoll, zwei separate Organisationseinheiten für Personalabteilung und Gehaltsbuchhaltung zu erstellen. Beim flachen Modell können alle Benutzerobjekte in einer großen Organisationseinheit mit der Bezeichnung „Konten“ gruppiert werden, oder sie können im Standardcontainer „Benutzer“ gespeichert werden. Zumindest sollten Ihre Benutzerobjekte von Ihren Computerobjekten getrennt werden.

Für dieses Modell empfehle ich zudem, dass Sie einen Schritt weitergehen und Ihre Arbeitsstationen von den Servern trennen. Dann können Sie zumindest verschiedene Gruppenrichtlinien anwenden, ohne ein GPO definieren zu müssen, bei dem eine WMI-Abfrage (Windows® Management Instrumentation, Windows®-Verwaltungsinstrumentation) zum Herausfiltern von Arbeitsstationen oder Servern verwendet wird.

Ein Vorteil einer flachen Organisationseinheitsstruktur gegenüber einer tiefen Struktur besteht darin, dass die Active Directory-Suche schneller ausgeführt wird. Ich empfehle in der Regel, nicht mehr als 10 Ebenen untergeordneter Organisationseinheiten zu verwenden. Ihre Kontrolle über Objekte ist in diesem Modell nicht sehr präzise, was jedoch auch nicht erforderlich ist, wenn Sie Objekte in einem Kleinunternehmen verwalten. Daraus folgt, dass sich dieses Modell in einem großen Unternehmen nur schwer mit Erfolg implementieren ließe, in kleineren Organisationen funktioniert es jedoch sehr gut.

Das geografische Modell

Beim geografischen Modell erstellen Sie für unterschiedliche geografische Regionen separate Organisationseinheiten. Dieses Modell eignet sich am besten für Organisationen, die über dezentrale IT-Abteilungen verfügen, die aber die mit dem Betrieb mehrerer Domänen verbundenen Kosten vermeiden möchten (siehe Abbildung 5).

Abbildung 5** Beim geografischen Modell werden Organisationseinheiten nach geografischer Region getrennt **(Klicken Sie zum Vergrößern auf das Bild)

Angenommen, Sie verfügen über Niederlassungen in Atlanta, Baltimore und Seattle. Wenn jeder Standort seine eigenen Benutzer und Computer verwaltet, könnte dieses Modell im Hinblick auf die Delegierung gut passen. Was geschieht jedoch, wenn ein Benutzer aus Seattle zu einer Schulung nach Baltimore fliegt und dann versehentlich sein Konto sperrt? Die IT-Mitarbeiter in Baltimore können diesem Benutzer möglicherweise nicht helfen, wenn keine Berechtigungen für das Konto des Benutzers an sie delegiert wurden. Wenn es in Baltimore 8 Uhr morgens ist, ist es in Seattle erst 5 Uhr, sodass der Benutzer unter Umständen Stunden warten muss, bevor er in der Niederlassung Seattle jemanden erreicht, der ihm weiterhelfen kann.

Einige globale Unternehmen verwenden ein „Follow-the-Sun“-Modell, bei dem Helpdeskanrufe an einen Standort in einer Zeitzone weitergeleitet werden, in der gerade die Standardgeschäftszeiten herrschen. Dies bedeutet, dass das Unternehmen nicht an jedem Standort ein 24-Stunden-Helpdesk unterhalten muss, aber dennoch Mitarbeitern bei Bedarf zu später Stunde Hilfe bieten kann, beispielsweise beim Entsperren ihrer Konten.

Wenn Sie mit diesem Modell arbeiten, ist die Erstellung separater Organisationseinheiten auf Grundlage des geografischen Standorts wahrscheinlich nicht die beste Wahl für Ihre betrieblichen Anforderungen. Sie müssten an jeden regionalen Helpdesk separate Berechtigungen für jede Benutzerorganisationseinheit delegieren. Wenn Ihre Standorte aber über eigene IT-Abteilungen verfügen, könnte das geografische Modell tatsächlich für Ihre Organisation gut geeignet sein.

Das geografische Modell lässt sich zudem aufgrund der speziellen Funktionsweise einer Domäne nur schwer in einer einzelnen Domäne implementieren. In der Regel verfügen alle Domänen über verschiedene Sicherheitsmodelle. Dies tritt klarer zutage, wenn Sie eine unternehmensweite Anwendung wie Microsoft® Exchange betrachten.

Für den Exchange-Server in Atlanta wurden möglicherweise andere E-Mail-Richtlinien definiert, aber wahrscheinlich werden auf alle Exchange-Server im Unternehmen die gleichen GPOs angewendet. Wenn dies der Fall ist, würde die Platzierung der Exchange-Server in separaten Organisationseinheiten auf Basis der Region dazu führen, dass Sie ein und dasselbe GPO unnötigerweise mit mehreren Organisationseinheiten verknüpfen. Hinsichtlich der Delegierung müssen Sie sich fragen, ob die Exchange-Administratoren für die Exchange-Server wirklich eindeutige Berechtigungen für die Computerobjekte benötigen. In den meisten Fällen werden Computerobjekte für die Anwendung von Gruppenrichtlinien und nicht für Delegierungszwecke in geografische Organisationseinheiten eingeteilt.

Das typbasierte Modell

Beim typbasierten Modell werden Objekte nach ihrem Zweck klassifiziert (siehe Abbildung 6). Haben Sie Ihr letztes Benutzerobjekt für ein reguläres Benutzerkonto, ein Administratorkonto oder ein Dienstkonto erstellt? Bei einem typbasierten Modell wird jedes dieser Objekte anders behandelt.

Abbildung 6** Beim typbasierten Modell werden Objekte entsprechend ihrer Funktion gruppiert **(Klicken Sie zum Vergrößern auf das Bild)

In den meisten Fällen sollten Sie bei Richtlinien zwischen verschiedenen Klassifizierungen von Benutzerobjekten unterscheiden. Ihre Richtlinien unterscheiden sich höchstwahrscheinlich in Abhängigkeit vom Typ des Benutzerkontos. So ist es beispielsweise im Allgemeinen nicht empfehlenswert, dass sich Benutzer mit einem Dienstkonto bei einem Computer anmelden können. Die Kennwörter von Dienstkonten werden in der Regel von vielen Personen gemeinsam verwendet, sodass ein Benutzer, der sich mit einem Dienstkonto anmeldet, anonym bleibt. Würde etwas passieren, hätten Sie Probleme, den Benutzer aufzuspüren, der beim Eintreten des Ereignisses angemeldet war. Bei diesem Beispiel müssten Sie eine Richtlinie für Dienstkonten festlegen, die eine interaktive Anmeldung verhindert. Dies passt gut in das in Abbildung 3 dargestellte hierarchische Modell.

In diesem Fall könnten Sie die GPO-Vererbung zu Ihrem Vorteil nutzen. Sie könnten beispielsweise eine Richtlinie für alle Benutzer erstellen, die auf für alle Benutzerobjekte festgelegte Richtlinien verweist. Darüber hinaus könnte eine separate und eindeutige Richtlinie für Dienstkonten vorhanden sein, die auf der Richtlinie für alle Benutzer aufbaut. Mit diesem Ansatz stellen Sie sicher, dass für Ihre Dienstkonten der gleiche Basissatz an Richtlinien wie für jedes andere Konto sowie die spezifischen Anmeldeeinschränkungen gelten.

Dieser Ansatz eignet sich auch gut für die Delegierung, bei der Sie die Berechtigungsvererbung statt der GPO-Vererbung verwenden. Angenommen, Sie möchten, dass Administratoren der Stufe 2 Kennwörter für alle Konten außer den Konten der Administratoren der Stufe 3 zurücksetzen können. Bei einer flachen Organisationseinheitsstruktur müssten Sie an jede Organisationseinheit, die Benutzerkonten enthält, Berechtigungen delegieren. Bei einem typbasierten Modell mit einer hierarchischen Struktur können Sie der Gruppe der Stufe 2 Berechtigungen zum Zurücksetzen von Kennwörtern für die Organisationseinheit „Konten“ erteilen. Dann können Sie bei der Organisationseinheit der Stufe 3 einfach die Vererbung der Berechtigungen aufheben oder sogar der Gruppe der Stufe 2 explizit das Zurücksetzen von Kennwörtern verweigern.

Dies funktioniert auch gut für Computerobjekte. Server und Arbeitsstationen können getrennt werden, sodass unterschiedliche Richtlinien auf sie angewendet werden können. Die Server können dann nach ihrer Funktion weiter unterteilt werden (siehe Abbildung 1). Bei diesem Entwurf können Sie eine allgemeine Richtlinie für die Organisationseinheit „Server“ festlegen, die für alle Server gilt, und gleichzeitig für jede untergeordnete Organisationseinheit individuelle Richtlinien einrichten.

Angenommen, Sie verfügen über ein MOM-Dienstkonto (Microsoft Operations Manager). Bei diesem mehrstufigen Modell können Sie ein MOM-GPO erstellen und es auf die MOM-Server-Organisationseinheit anwenden. In diesem GPO können Sie dann dem MOM-Dienstkonto Rechte für die Anmeldung als Dienst erteilen. Dies würde nur für die MOM-Server in dieser Organisationseinheit gelten. Die MOM-Server erhalten immer noch das GPO „Server“ von der übergeordneten Organisationseinheit „Server“, jedoch auch das spezielle MOM-GPO, das mit der MOM-Organisationseinheit verknüpft ist.

Dokumentieren des Entwurfs

Der Entwurf einer Organisationseinheitsstruktur, der die vielen Änderungen, denen eine Active Directory-Umgebung unterliegt, nichts anhaben können, kann sehr lohnenswert sein. Sie benötigen aber eine Methode für die Überwachung der dynamischen Merkmale von Organisationseinheiten. Andernfalls könnten Sie schnell die Übersicht über Ihre Umgebung verlieren. Wenn Änderungen unbedingt erforderlich sind und eine Organisationseinheit hinzugefügt oder gelöscht werden muss, müssen hierfür klare Leitfäden vorhanden sein, um sicherzustellen, dass Ihr Modell weiterhin mit Ihrem Entwurfsmodell und den drei Leitprinzipien in Einklang steht. Daher müssen Sie über einen gründlich dokumentierten Entwurf verfügen.

Microsoft stellt Dokumentationsanleitungen im Windows Server Resource Kit zur Verfügung. Diese Anleitungen sind hilfreich, wenn es sich bei Ihrer Struktur um ein stabiles Framework handelt, das wahrscheinlich keinen großen Änderungen unterliegen wird. Die meisten Organisationen verfügen jedoch über eine äußerst dynamische Struktur, die sich häufig ändert. Daher folgen nun einige wichtige Tipps, wie sichergestellt werden kann, dass Ihre Organisationseinheitsstruktur gut dokumentiert ist und eine dynamische Umgebung unterstützen kann.

Stellen Sie sicher, dass alle Informationen relevant sind Ich bin ein großer Anhänger zweckdienlicher Dokumentation. Zu viele Betriebsdokumente enthalten so viele belanglose Informationen, dass es schwer ist, die wirklich wichtigen Punkte zu finden. Erstellen Sie Dokumentation nicht nur um der Dokumentation willen. Müssen Sie wirklich die Anzahl der Objekte in jeder Organisationseinheit oder jeden Zugriffssteuerungseintrag (Access Control Entry, ACE) der Zugriffssteuerungsliste für die Organisationseinheit einbeziehen? Zur Dokumentation von Organisationseinheiten genügen in der Regel die folgenden Informationen:

• Name der Organisationseinheit
• Kurze Beschreibung
• Ersteller oder Kontaktperson bezüglich Informationen oder Änderungen
• Erstellungsdatum

Erschweren Sie Aktualisierungen nicht unnötig Wenn Sie ein komplexes Microsoft Word-Dokument mühsam aktualisieren müssen, ist es wahrscheinlicher, dass Sie die Eingabe von Aktualisierungen aufschieben. Es ist in Ordnung, wenn Sie die Eingabe kleinerer Änderungen zurückstellen, wenn Sie wissen, dass Sie demnächst eine größere Menge von Aktualisierungen eingeben müssen. Leider werden diese kleinen Änderungen häufig vergessen oder einfach immer wieder aufgeschoben, sodass die Aufgabe nie erledigt wird. Daher muss sich das Dokument äußerst einfach aktualisieren lassen, damit Sie nicht entmutigt werden. In den meisten Fällen erfüllt eine einfache Microsoft Excel®-Tabelle mit wenigen Spalten diesen Zweck einwandfrei.

Fügen Sie Kommentare in das Objekt selbst ein Organisationseinheitsobjekte verfügen über ein Beschreibungsattribut, in das Sie Kommentare aufnehmen können. Statt die Kommentare in das Entwurfsdokument zu schreiben, sollten Sie in Betracht ziehen, sie in das Beschreibungsattribut einzufügen, damit andere Benutzer sofort erkennen können, welchem Zweck die Organisationseinheit dient. Wenn Sie weitere Details einbeziehen müssen, fügen Sie eine kurze Beschreibung in das Beschreibungsattribut sowie weitere Einzelheiten in das Dokument für die Organisationseinheit ein.

Automatisieren Sie die Dokumentation Es kann ein Skript geschrieben werden, um die Inhalte der Organisationseinheitsstruktur in eine Textdatei, eine Excel-Tabelle oder sogar eine HTML-Datei auszugeben. Dieses Skript könnte im Rahmen eines geplanten Tasks immer nachts ausgeführt werden. Dies kann äußerst nützlich sein, wenn Sie Kommentare in das Beschreibungsfeld der Organisationseinheit einfügen. Dann müssen Sie lediglich das Beschreibungsattribut in die Datei ausgeben und verfügen automatisch über eine vollständig dokumentierte Organisationseinheitsstruktur, die immer auf dem neuesten Stand ist. Wenn Sie bei jeder Ausführung des Skripts eine neue Datei erstellen, statt das vorhandene Dokument zu überschreiben, erhalten Sie ein Verlaufsprotokoll der Änderungen, die im Laufe der Zeit an der Organisationseinheitsstruktur vorgenommen wurden.

Leider erkennen die meisten Administratoren die Bedeutung einer gründlichen Dokumentation der Organisationseinheitsstruktur erst, wenn sie wirklich darauf angewiesen sind. Dann ist es zu fortgeschrittener Stunde ohne Durchführung einer Wiederherstellung fast unmöglich festzustellen, welche Organisationseinheiten versehentlich gelöscht wurden.

Warten Sie nicht, bis Ihnen das passiert. Ich empfehle nachdrücklich, dass Sie in diesem Bereich proaktiv handeln und sofort mit der Erstellung eines Dokuments zu den Organisationseinheiten beginnen und eine Person benennen, die für seine Aktualisierung verantwortlich ist. Wenn Sie die Regel beherzigen, dass sich die Dokumentation problemlos aktualisieren lassen sollte, ist dies auf lange Sicht eine vergleichsweise kleine Aufgabe. 

Ken St. Cyr ist als Berater für Microsoft tätig und verfügt über 10 Jahre Erfahrung in der IT-Branche. Er entwickelt und implementiert seit der Einführung von Active Directory darauf basierende Verzeichnislösungen.

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