Active Directory: Best Practice zur OU-Struktur

Es gibt gar keine “richtige” oder “beste” OU-Struktur für eine Active-Directory-Domäne. Trotzdem gibt es aber ziemlich viel, was man “nicht so gut” machen kann. Nach langem Zögern stelle ich daher hier eine Beispiel-Struktur vor, die als Grundlage für eigene Designs dienen kann.

Ein Grundfehler zieht sich durch sehr viele AD-Umgebungen, seit Microsoft Ende der Neunzigerjahre mit ersten Beispielen und Schulungen an die Öffentlichkeit gegangen ist: Viele Admins versuchen seither nämlich, das Organigramm des Unternehmens mit OUs in der Domäne abzubilden. Schnell stellen sie dann fest, dass das ziemlich umständlich für den Admin ist. Und kurz darauf kommt dann die Erkenntnis, dass sich das Organigramm schon wieder geändert hat, aber niemand hat den Admins Bescheid gesagt.

Die Erkenntnis: Die OU-Struktur im AD ist nicht für das Organigramm da, sondern für die Administration. Die IT-Administration hat in aller Regel völlig andere Kriterien als das Business, und das ist auch gut so. Die AD-Struktur soll also den Admins helfen, nicht den Mitarbeitern. Mitarbeiter bekommen die OUs ohnehin praktisch nie zu Gesicht, Manager auch nicht. Hier stellt sich dann aber auch schon das Problem mit “Best Practice”: da auch die IT-Administration von Unternehmen zu Unternehmen sehr unterschiedlich ist, wird es kein Modell geben, das zu allen passt. Wie oben schon angemerkt, gibt es ein paar Konstrukte, die sich in vielen Situationen bewährt haben und von denen aus man dann selbst planen kann.

Die wichtigste Grundidee, der viele Designs folgen, ist die Objektorientierung. Das ist ein großes und eigentlich unpassendes Wort, aber es wird von vielen verwendet. Gemeint ist: Als Grundstruktur auf der “obersten” Ebene orientiert man sich an den typischen Objektklassen, die für die Administration wichtig sind: Benutzer, Gruppen und Computer. Da sich die Administration dieser Klassen voneinander sehr unterscheidet, eignen sie sich als oberstes Kriterium. Innerhalb der Klassen führt man dann weitere Unterteilungen ein, wobei auch für die nächste Unterebene einige Dinge sich bewährt haben.

Der zweite wichtige Gedanke, der sich in der Gliederung “ganz oben” finden sollte: Die Administration eines Netzwerks ist etwas grundsätzlich anderes als die Nutzung. Administrative Objekte (Admin-Benutzerkonten, Admin-Gruppen und auch Admin-Rechner) sollten also von den normalen produktiven Objekten deutlich getrennt sein. Hier kann es dann aber auch schon etwas komplexer werden, denn in großen Unternehmen gibt es oft eine zentrale Administration, die von dezentralen Admins unterstützt wird. Das lässt sich unterschiedlich abbilden.

Viele AD-Administratoren fragen in Design-Workshops, an welcher Stelle denn Abteilungen und Standorte ins Spiel kommen. Das kommt darauf an – und zwar darauf, wie wichtig diese Konstrukte wirklich für die Administration sind. Macht es einen großen Unterschied für die Admins, ob ein User in der Produktion arbeitet oder im Vertrieb? Gelten unterschiedliche Abläufe für Rechner in Hamburg und in München? Dann sind das wichtige Kriterien. Spielt das aber keine wichtige Rolle, dann sind vielleicht andere Punkte relevant – etwa die Unterscheidung zwischen einem Notebook und einem Arbeitsplatz-PC. In manchen Unternehmen ist es für die IT auch unwichtig, in welcher Abteilung ein User arbeitet – mit einer Ausnahme, und das ist die Finanzbuchhaltung. Auch dafür lassen sich passende Unterstrukturen bauen.

Mögliche Leitfragen für die Struktur:

• Wer ist im Tagesgeschäft dafür zuständig, bestimmte Objekte zu verwalten?
  Sind es immer dieselben Personen (dann unterteilt man eher nicht), oder sind bestimmte Personen für bestimmte Teile zuständig (dann würde man die Struktur so aufteilen, dass jeder seine Objekte gut im Griff hat)?
• Sollen administrative Berechtigungen und Zuständigkeiten aufgeteilt werden?
  Wenn etwa ein User-Helpdesk für bestimmte Anwenderkonten zuständig ist, dann sollten diese Konten sich in einer gemeinsamen OU-Struktur befinden, damit man dem Helpdesk einfach Berechtigungen darauf erteilen kann.
• Gibt es für bestimmte Teile der Infrastruktur zugeschnittene Prozesse?
  Automatisierungen, Gruppenrichtlinien, Skripte usw. lassen sich einfacher aufbauen, wenn sie nur auf einen OU-Zweig (oder nur auf wenige) zugreifen müssen.
• Welche Kriterien bilden die Grundlage für die Organisation innerhalb der IT-Abteilung?
  Tatsächlich sind diese Kriterien auch die wichtigsten für das AD. Gibt es ein eigenes Team für die SQL-Server, dann sollten diese ihre Objekte an einer zentralen Stelle finden. Sind alle Admins für alle Server zuständig, dann ist es weniger sinnvoll, die Server auf viele OUs aufzuteilen.

Hier nun ein Beispielentwurf, der sich für AD-Designworkshops als Ausgangpunkt bewährt hat. Nota bene: als Ausgangspunkt. Ich habe viele Kunden mit diesem Modell beraten, das dann zur Grundlage eines individuellen Entwurfs wurde. Es gibt aber keinen einzigen Kunden, der genau dieses Modell ohne Änderung umgesetzt hat.

• dom2.dom1.de

  • Administration
    (Benutzerkonten für Admins, unabhängig von der konkreten Aufgabe. AD-Berechtigung nur für ausgewählte Admin-Gruppen.)
    • Zentral
    • Dezentral
    • Externe
  • Service-Konten
    (Benutzerkonten für Dienst-Anmeldungen. AD-Berechtigung nur für ausgewählte Admin-Gruppen.)
  • Benutzer
    (Standard-Benutzerkonten ohne Admin-Rechte. AD-Berechtigung nur für ausgewählte Admin-Gruppen; Service-Desk mit wenigen Berechtigungen.)
    • <Kriterium 1>
    • <Kriterium 2>
    • Externe
    • …
  • Gruppen
    (Container für alle Gruppen)
    • Administration
      (Gruppen, die zur Administration berechtigen. AD-Berechtigung nur für ausgewählte Admin-Gruppen.)
      • Server-Admins
        (Eine Gruppe pro Server, die den lokalen Administratoren hinzugefügt wird.)
      • Funktionsrollen
        (Gruppen, die direkt Berechtigungen im AD oder auf Systemen erhalten. Mitglieder sind typisch nur Admin-Gruppen, eher keine Admin-User.)
      • Organisatorische Rollen
        (Gruppen, die Admins nach organisatorischen Kriterien zusammenfassen, z.B. Exchange-Admins.)
    • Berechtigungen
      (Gruppen, die Zugriffsberechtigungen für User auf Daten und Systeme erteilen. Mitglieder sind typisch nur Gruppen, eher keine User.)
      • Dateisystem
      • Applikationen
    • Organisatorisch
      (Gruppen, die User nach organisatorischen Kriterien zusammenfassen, z.B. Personalabteilung.)
  • Computer-Quarantäne
    (Container für neu aufgenommene Computer, die noch nicht in der Ziel-OU sind.
    GPO: Nur bestimmte Anmeldungen möglich, keine Useranmeldung)
  • Server
    (Ab hier werden z.B. per GPO Anmelde- und Administrationsrechte für Server erteilt sowie Sicherheitseinstellungen gesetzt.)
    • <Servergruppe 1>
    • <Servergruppe 2>
    • Standortlokal
      • <Standort 1>
      • <Standort 2>
  • Clients
    (Ab hier werden z.B. per GPO Anmelde- und Administrationsrechte für Clients erteilt sowie Sicherheitseinstellungen gesetzt.)
    • <Admin-Kriterium 1>
      (z.B. PCs mit höheren Sicherheitsanforderungen)
      • <ggf. Standort 1>
      • <ggf. Standort 2>
    • <Admin-Kriterium 2>
      (z.B. PCs mit normalen Sicherheitsanforderungen)
      • <ggf. Standort 1>
      • <ggf. Standort 2>
  • Ressourcen