Active Directory-Organisationseinheitsdesign für <500 Benutzer, 4 Standorte

Wir möchten unserer AD-Hierarchie (Win 2003) eine logische Struktur hinzufügen. Wir haben eine einzige Domain und rund 500 Benutzer. Alle Benutzer und Computer sind derzeit in einer Organisationseinheit organisiert. Alle Sicherheits- und Verteilergruppen befinden sich in einer zweiten Organisationseinheit. Die Gruppenmitgliedschaft erfolgt im Wesentlichen auf Einzelbenutzerbasis ohne Verschachtelung von Gruppen.

Meine Fragen:

1. Lohnt es sich für eine Organisation dieser Größe, eine Hierarchie von Organisationseinheiten basierend auf Abteilung, Geografie und / oder Objektklasse (dh Computer, Benutzer, Gruppen) zu definieren und die Benutzer, Computer und Gruppen in die entsprechenden Organisationseinheiten zu verschieben?
2. Wenn ja, wie würden Sie die Hierarchie strukturieren, z. B. Abteilung-> Standort-> Objektklasse?
3. Sollten wir gegebenenfalls Gruppen verschachteln, um eine bessere Zuordnung zu Unternehmensanwendungsrollen und Exchange-Adresseinträgen zu erreichen?

Hier sind die wichtigsten Grundsätze der Empfehlung von Microsoft für das logische AD-Design:

• Entwerfen Sie zuerst für die Delegierung von Steuerelementen, da dies auf AD-Berechtigungen basiert und die unflexibelste zu ändernde Achse ist. Wenn Sie keine Kontrolldelegation durchführen, machen Sie sich darüber keine Sorgen (aber ich würde es trotzdem planen - selbst in einer so kleinen Organisation müssen möglicherweise bestimmte Benutzer in Zweigstellen Kennwörter zurücksetzen. usw).

• Entwerfen Sie den zweiten für die Anwendung der Gruppenrichtlinie. Durch Filtern der Gruppenrichtlinienanwendung nach Sicherheitsgruppenmitgliedschaft kann ein Gruppenrichtlinienobjekt nur auf eine Teilmenge der Benutzer- oder Computerobjekte angewendet werden, die unter dem Punkt liegen, mit dem es im Verzeichnis verknüpft ist. Daher verfügt diese Achse über eine größere Flexibilität als die AD-Berechtigungen.

• Design schließlich für Organisation und Benutzerfreundlichkeit. Machen Sie es sich einfach, Dinge für sich und andere Administratoren zu finden.

Denken Sie beim Entwerfen an jede dieser Überlegungen und priorisieren Sie sie wie empfohlen. Es ist einfach, Dinge später (vergleichsweise) zu ändern, und Sie werden es beim ersten Versuch nie "richtig machen". Bevor ich meinen ersten Domänencontroller DCPROMO mache, zeichne ich normalerweise die vorgeschlagene Struktur auf Papier oder einem Whiteboard und gehe mögliche Verwendungsszenarien durch, um festzustellen, ob mein Design "hält". Es ist eine großartige Möglichkeit, Probleme in einem Design auszuräumen.

(Vergessen Sie auch nicht die Gruppenrichtlinienanwendung für die Site-Objekte. Sie müssen vorsichtig mit domänenübergreifenden Gruppenrichtlinienobjektanwendungen sein, wenn Sie Gruppenrichtlinienobjekte an Standorten verknüpfen. Wenn Sie jedoch eine einzelne Domänenumgebung verwenden, können Sie eine Menge großartiger Ergebnisse erzielen Funktionen zum Verknüpfen von Gruppenrichtlinienobjekten mit Websites. Arbeiten Sie einige Beispielszenarien damit durch. Ich finde, dass es sich hervorragend zum Laden von Software mit "standortspezifischen" Einstellungen oder zum Bereitstellen bestimmter Anmeldeskripts für Benutzer eignet, wenn Sie sich in bestimmten Fällen bei Computern anmelden physische Standorte über die Verarbeitung von Loopback-Gruppenrichtlinien.)

Ich habe Benutzer, Computer und Gruppen immer in separate Organisationseinheiten aufgeteilt, aus dem einfachen Grund, dass dies die Verwaltung erleichtert.

Wenn Sie keinen zwingenden Grund für eine bestimmte AD-Struktur haben, entwerfen Sie Ihre AD aus administrativer Sicht. Überlegen Sie, wo Sie Richtlinien anwenden werden.

Wenn Sie die meisten Ihrer Richtlinien auf Abteilungsebene anwenden, verwenden Sie Abteilung \ Standort \ Objekt

Wenn Sie die meisten Ihrer Richtlinien auf Standortebene anwenden, verwenden Sie Standort \ Abteilung \ Objekt

Wenn Sie es anders machen würden, müssten Sie Ihre Richtlinien in mehreren Organisationseinheiten verknüpfen, was unnötige Arbeit erfordert.

Das Verschachteln von Gruppen ist vollkommen in Ordnung und erleichtert die Verwaltung von AD erheblich.

Ich tendiere dazu, AD-Strukturen zu entwerfen, um die Verwaltung zu vereinfachen, anstatt die physische Unternehmensstruktur widerzuspiegeln, aber beide sind oft gleich.

Ich denke, wenn ich meine AD erneut neu gestalten müsste, würde ich einige Dinge anders machen, aber ich habe Folgendes festgestellt:

Benutzer - Teilen Sie die Abschlussarbeiten in Abteilungen auf, aber auch mit einem oder mehreren Bereichen für Zeitarbeits- oder Agenturmitarbeiter. Der Ort für diese wird nicht so wichtig sein, da sich die Leute zweifellos bewegen werden.

Computer - Teilen Sie diese in Standorte und Unterstandorte auf. Dh OfficeComputers / LondonOffice / Room103 (Finanzen). Dies bedeutet, dass Sie Einstellungen auf einen Standort oder ein Büro anwenden können - beispielsweise auf einen anderen Proxyserver oder andere Antiviren-Einstellungen (natürlich nur, wenn das AV-Verwaltungsprogramm AD verwendet) - ohne sich neu zu organisieren, und das hoffentlich nicht öffnen müssen Dose Würmer, die Loopback-Verarbeitung ist.

Ich fand es auch nützlich, die eingebauten Benutzer- oder Computergruppen nicht zu verwenden, keine technischen Probleme, sondern nur, damit Sie leicht erkennen können, wo sich die Dinge nicht befinden sollten.

Schließlich teilen Sie auch Ihre Server auf, ich habe mich für Standort / Rolle entschieden, was anscheinend recht gut funktioniert hat.

Wie bereits beantwortet, ist hier meine Ansicht für ein kleines Beispiel, wohlgemerkt, es gibt kein Richtig oder Falsch, alles hängt von den Bedürfnissen ab - dh Organisation oder Standort zuerst? Ich bevorzuge zuerst die organisatorische Rolle, auch für Computer / Server-Rollen. Ich mag auch die Möglichkeit, auf eine einzelne Organisationseinheit hinzuweisen, um alle Mitarbeiter und keinen Müll zum Auffüllen von Intranet-Mitarbeiterlisten zu erhalten. Fühlen Sie sich frei zu bearbeiten!

• Personen (Benutzer / Typ = Person)
  • Intern
    • Abteilung A.
      • Standort X.
      • Standort Y.
    • Abteilung B.
    • Abteilung C.
  • Extern
    • Firma 1
    • Firma 2
• Maschine (Benutzer / Typ = alle einschließlich Computer)
  • Klient
    • Laptops
    • Desktops
  • Server
    • Anwendung
      • Standort T.
      • Standort V.
    • Infrastruktur
    • Datenbank
  • Bedienung
  • Verwaltungskonten (falls verwendet)
• Listen (Gruppen & Kontakte)
  • Kontakt
  • Verteilung
  • Sicherheit

In diesem Fall würde ich sie nur nach Standort aufteilen. Die resultierende OU-Struktur würde ungefähr so ​​aussehen:

Location1
-Computers
-Groups
-Users

Location2
-Computers
-Groups
-Users

usw.

Ich sehe hier keine Notwendigkeit für weitere Abteilungen, z. B. nach Abteilungen, da dies zusätzlichen Verwaltungsaufwand verursachen würde, ohne wirklich viel dafür zu geben. Durch die Aufteilung nach Standort können Sie jedoch die Delegierung an jedem Standort implementieren.

Eine Richtlinie, die ich verwende, lautet: Benutzer; nach HR-Chartflow-Gruppen organisieren; organisieren nach Workflow Computer; nach geografischem Standort organisieren

Die anderen Antworten in diesem Thread sind allerdings auch sehr gut.