1
AD Gruppen effektiv gestalten
Hallo IT Gemeinde,
unser Unternehmen wächst ständig und damit auch die Herausforderungen an das IT System.
Ich habe eine prinzipielle Frage bezüglich AD Gruppen. Gibt es ein Schemata nachdem man vorgehen kann um ein
modernes Gruppensystem aufzubauen ?
Ich suche eine Vorlage oder einen Leitfaden.
Beispiel:
Unser Domain Forest besteht aus mehreren Domains. Darum haben wir die Syntax für Gruppennamen so vergeben: [Firma][Länderkürzel]_SG_[Abteilung oder Funktion]
Das wären die Sicherheitsgruppen.
Wie sieht es bei Ressourcegruppen aus ?
Benutzt man die eigentlich ?
Zum Beispiel finde ich es sehr praktisch Daten auf einem Fileserver mit Ressourcegruppen zu berechtigen. Eine SG ist dann einfach Mitglied in der RG und schon
hat die Gruppe Zugriff auf die Daten. Warum mir das so gut gefällt ist weil nicht alle Files die Berechtigung durchschreiben müssen was bei einem riesigen Datenbestand
sehr lange dauern kann.
Allerdings braucht man sehr viele RG und auf jeder Ebene mindestens "Vollen Zugriff" und "nur lesen".
Ich bin nicht sicher ob das der richtige Weg ist.
Jetzt kommt auch noch SharePoint ins Spiel (in Sharepoint wollen wir auch mit den AD Gruppen arbeiten und nicht mit den Sharepoint Gruppen)
und ich möchte bevor mir mit diesem neuen System wirklich arbeiten sicherstellen das die Gruppenorganisation im AD so gelöst
ist das sie zukunftssicher ist und effektiv.
Bin für jede Hilfe dankbar !
unser Unternehmen wächst ständig und damit auch die Herausforderungen an das IT System.
Ich habe eine prinzipielle Frage bezüglich AD Gruppen. Gibt es ein Schemata nachdem man vorgehen kann um ein
modernes Gruppensystem aufzubauen ?
Ich suche eine Vorlage oder einen Leitfaden.
Beispiel:
Unser Domain Forest besteht aus mehreren Domains. Darum haben wir die Syntax für Gruppennamen so vergeben: [Firma][Länderkürzel]_SG_[Abteilung oder Funktion]
Das wären die Sicherheitsgruppen.
Wie sieht es bei Ressourcegruppen aus ?
Benutzt man die eigentlich ?
Zum Beispiel finde ich es sehr praktisch Daten auf einem Fileserver mit Ressourcegruppen zu berechtigen. Eine SG ist dann einfach Mitglied in der RG und schon
hat die Gruppe Zugriff auf die Daten. Warum mir das so gut gefällt ist weil nicht alle Files die Berechtigung durchschreiben müssen was bei einem riesigen Datenbestand
sehr lange dauern kann.
Allerdings braucht man sehr viele RG und auf jeder Ebene mindestens "Vollen Zugriff" und "nur lesen".
Ich bin nicht sicher ob das der richtige Weg ist.
Jetzt kommt auch noch SharePoint ins Spiel (in Sharepoint wollen wir auch mit den AD Gruppen arbeiten und nicht mit den Sharepoint Gruppen)
und ich möchte bevor mir mit diesem neuen System wirklich arbeiten sicherstellen das die Gruppenorganisation im AD so gelöst
ist das sie zukunftssicher ist und effektiv.
Bin für jede Hilfe dankbar !
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 113692
Url: https://administrator.de/contentid/113692
Ausgedruckt am: 23.11.2024 um 03:11 Uhr
1 Kommentar
Hallo,
what the Heck are "Ressourcegruppen" (im Deutschen übrigens nur mit einem "s" geschrieben)?
Best Practices zum Gruppendesign gibt es schon, und in Mulit-Domain-Umgebungen sind die sogar wichtig. Da geht es dann um Scope (Local/Global/Universal). Siehe etwa http://technet.microsoft.com/en-us/library/bb726978.aspx
Tatsache ist, dass schnell eine ziemliche Anzahl von Gruppen zusammenkommt - damit muss man irgendwie leben.
Weitere wichtige Erkenntnis ist aber, dass man nicht jedem "Geistesblitz" eines Pseudo-Sicherheitsfanatikers nachkommen kann, der meint, für Verzeichnis xyz\abc\def\ghi müsste man eine Gruppe machen, in der Mitarbeiter 123 nicht enthalten ist, der aber unbedingt auf xyz\abc\def\ und am besten auch xyz\abc\def\ghi\jkl zugreifen können muss. Egal, wie man Gruppen aufbaut: man administriert sich da ganz schnell zu Tode. Einfach weil kein Mensch mehr durchblickt: Weder Administratoren, noch Nutzer (die dann ständig völligen Müll anfordern). In sofern ist das ganze Problem m.E. nach weniger ein technisches, als viel mehr ein organisatorisches (Ermitteln von tatsächlich sinnvollen Gliederungen). Und sehr wichtig ist es auch, später die Anzahl an Sonderfällen gering zu halten. Wenn man z.B. Gruppen hierarchisch verschachtelt (Firma -> ServiceLine -> Abteilung -> Team) sollte man auch nur auf unterester Ebene Mitglieder hinzufügen. Wenn man dann auf einmal anfängt auf mittleren Ebenen Nutzer hinzuzufügen kommt es auf einmal zu den lustigsten Phänomenen.
Gruß
Filipp
what the Heck are "Ressourcegruppen" (im Deutschen übrigens nur mit einem "s" geschrieben)?
Best Practices zum Gruppendesign gibt es schon, und in Mulit-Domain-Umgebungen sind die sogar wichtig. Da geht es dann um Scope (Local/Global/Universal). Siehe etwa http://technet.microsoft.com/en-us/library/bb726978.aspx
Tatsache ist, dass schnell eine ziemliche Anzahl von Gruppen zusammenkommt - damit muss man irgendwie leben.
Weitere wichtige Erkenntnis ist aber, dass man nicht jedem "Geistesblitz" eines Pseudo-Sicherheitsfanatikers nachkommen kann, der meint, für Verzeichnis xyz\abc\def\ghi müsste man eine Gruppe machen, in der Mitarbeiter 123 nicht enthalten ist, der aber unbedingt auf xyz\abc\def\ und am besten auch xyz\abc\def\ghi\jkl zugreifen können muss. Egal, wie man Gruppen aufbaut: man administriert sich da ganz schnell zu Tode. Einfach weil kein Mensch mehr durchblickt: Weder Administratoren, noch Nutzer (die dann ständig völligen Müll anfordern). In sofern ist das ganze Problem m.E. nach weniger ein technisches, als viel mehr ein organisatorisches (Ermitteln von tatsächlich sinnvollen Gliederungen). Und sehr wichtig ist es auch, später die Anzahl an Sonderfällen gering zu halten. Wenn man z.B. Gruppen hierarchisch verschachtelt (Firma -> ServiceLine -> Abteilung -> Team) sollte man auch nur auf unterester Ebene Mitglieder hinzufügen. Wenn man dann auf einmal anfängt auf mittleren Ebenen Nutzer hinzuzufügen kommt es auf einmal zu den lustigsten Phänomenen.
Gruß
Filipp
