Grundsatzfrage zu Active Directory

[morpheus4711 10]

mein Kollege und ich sind uns nicht einig.

 

Wir haben ein Unternehmen mit zwei Standorten, Die AD-Struktur spiegelt die Firma wieder. Standorte haben eine eigene OU und dann wiederrum pro OU eine OU für die User und Computer

 

Jetzt war mein Gedanke die User und Computer pro Standort in eine OU zu schmeißen und Gruppen zu bilden die den Namen der Funktion haben und da entsprechend die user und Computer zu legen.

 

Spricht dagegen etwas? Oder ist es normal, dass man die User alle in den OUs verteilt?

Weil wenn ich den User in zwei OUs bräuchte hauts ja nimmer hin, dann muss ich wieder über Leseberechtigungen mit den GPOs arbeiten...

 

wie seht Ihr das?

 

Grüße

[NilsK 2.795]

Moin,

 

kannst du das bitte noch etwas genauer erläutern? Wen schmeißt oder legst du wohin? Von was für "Funktionen" sprichst du?

 

Grundsätzlich dienen OUs a) zur administrativen Übersicht, b) zur Zuordnung von Gruppenrichtlinien, c) in großen Umgebungen zur administrativen Delegation. Aus diesem Grund ist es meist sinnvoll, Objektklassen aufzuteilen (User und Computer in getrennte OUs, weil sie getrennte GPOs haben); das ist aber nicht zwingend.

 

Gruppen dienen zur Steuerung von Zugriffsberechtigungen ihrer Mitglieder, idealerweise nach dem A-G-DL-P-Prinzip. Verschachtelungen sind möglich, man sollte das aber nicht übertreiben.

 

Gruß, Nils

[morpheus4711 10]

servus,

 

naja, momentan haben wir

Standort -> User

-> Computer

 

und in OU User und OU Computer sind die einzelnen Objekte drin, dann gibts noch OUs unter User,

statt die "Unter-OUs" würde ich jetzt hergehen und lieber eine Gruppe erstellen, z.B. nur Mail Benutzer(kein Anmeldekonten) und dann da die Gruppe entsprechend der Funktion (nur Mailkonto) reinlegen. Mitglied der Gruppe sind dann alle die nur mailen können aber nicht anmelden mit einem Benutzerkonto.

[NilsK 2.795]

Moin,

 

entweder bemühst du dich um eine verständliche und ausführliche Darstellung, oder ich kann dir leider nicht helfen. Ich verstehe nicht, was du willst.

 

Gruß, Nils

[morpheus4711 10]

was bitte ist daran unverständlich? sags mir und ich versuche da Licht reinzubringen

[NorbertFe 1.835]

Und warum willst du das mit Gruppen statt mit OUs verwirklichen? Welchen Vorteil siehst du darin?

 

Bye

Norbert

[morpheus4711 10]

hmm, scheinbar drücke ich mich echt dumm aus.

 

ich meinte, statt die einzelnen User in entsrechende OUs zu legen, wie z.B. Abteilungen usw.

würde ich alle User eines Standortes in die OU Standort / Users setzen und in die einzelnen Abteilungen (auch OUs, aber natürlich unter den Standort-OUs) würde ich die User die in diese Abteilungen gehören in Gruppen zusammenfassen.

Vorteil ist doch wenn ein User Mitglied mehrere Abteilungen ist kann er in beiden vertreten sein, ansonsten nicht.

[phoenixcp 10]

Hi

 

Das ist eher ne Philosophiefrage welche du hier aufwirfst.

ich meinte, statt die einzelnen User in entsrechende OUs zu legen, wie z.B. Abteilungen usw.

würde ich alle User eines Standortes in die OU Standort / Users setzen und in die einzelnen Abteilungen (auch OUs, aber natürlich unter den Standort-OUs) würde ich die User die in diese Abteilungen gehören in Gruppen zusammenfassen.

Vorteil ist doch wenn ein User Mitglied mehrere Abteilungen ist kann er in beiden vertreten sein, ansonsten nicht.

Ob man nun den OU-Baum nach Standort\Abteilung\User oder nach Standort\User aufbaut und die Abteilungsmitgliedschaften in Gruppen organisiert ist "eigentlich" völlig egal.

ABER: Trotz allem bin ich zum Beispiel ein Freund der "klaren" Aufteilung Standort\Abteilung\User. Alles andere kann man über die MItgliedschaft in entsprechenden Berechtigungsgruppen abbilden. Der Nachteil deiner Idee wird nämlich erst kommen, wenn deine Abteilungen unterschiedliche GPO's bekommen sollen, was durchaus ein gelebter Anwendungsfall ist.

 

wenn ein User Mitglied mehrere Abteilungen

Ich verzichte bewusst darauf, diese Aussage nochmal aus der Sicht eines Consultants für Identity Management zu beleuchten, ok? Sonst wird es nämlich richtig übel... ;)

[morpheus4711 10]

ok, aber was wenn der User ständig die Abteilung wechselt?

[phoenixcp 10]

Dann musst du in beiden Konstrukten ran. Bei dem einen musst du ihn von einer OU in eine andere verschieben, bei dem anderen musst du in eine andere Gruppe packen und aus einer anderen Gruppe herausnehmen.

Und mal ehrlich: Wieviele deiner User wechseln "ständig" die Abteilung? Wieviele User betreust du überhaupt?

 

Bzw: was bedeutet denn bei dir ständig?

[NilsK 2.795]

Moin,

 

hmm, scheinbar drücke ich mich echt dumm aus.

 

was soll man darauf jetzt antworten? ;)

Ein bisschen Sorgfalt würde durchaus helfen. Wir kommunizieren hier schriftlich, da muss man sich schon mehr Mühe geben als wenn man zusammensitzt.

 

ich meinte, statt die einzelnen User in entsrechende OUs zu legen, wie z.B. Abteilungen usw. würde ich alle User eines Standortes in die OU Standort / Users setzen

 

Soweit, so klar, so sinnvoll.

 

und in die einzelnen Abteilungen (auch OUs, aber natürlich unter den Standort-OUs) würde ich die User die in diese Abteilungen gehören in Gruppen zusammenfassen.

 

Schon wieder. Dieser Halbsatz gibt schon syntaktisch keinen Sinn. Was ist da jetzt Gruppe, was ist OU?

 

Ich mutmaße: Du hast pro Abteilung eine OU. In diesen OUs willst du nun Gruppen speichern, die zu der Abteilung gehören. Richtig? Kann man machen. Darin sehe ich aber erst mal wenig Vorteile, es sei denn, du hast pro Abteilung -zig Gruppen.

 

Vorteil ist doch wenn ein User Mitglied mehrere Abteilungen ist kann er in beiden vertreten sein, ansonsten nicht.

 

Abteilungen würde ich normalerweise auch nicht als OUs abbilden, weil sie in den meisten Unternehmen gar keine Relevanz für die IT-Administration haben. Falls das bei euch doch so ist, könnte man das natürlich machen.

 

Meist lege ich bei Kunden für sowas einfach eine OU "Gruppen" an, in die dann die Gruppen kommen. Zu welcher Abteilung die Gruppe gehört, kann man dann besser im Namen und im Feld "Beschreibung" abbilden.

 

Wobei es bei meinen Kunden auch eher selten ist, dass ein Mitarbeiter gleichzeitig mehreren Abteilungen angehört.

 

Gruß, Nils

[phoenixcp 10]

Abteilungen würde ich normalerweise auch nicht als OUs abbilden, weil sie in den meisten Unternehmen gar keine Relevanz für die IT-Administration haben.

Genau dort fängt dann die Philosophie an. Und davon hat jeder seine eigene. Je nach Administrationsmodell hat auch die Abteilung schon eine Relevanz für die IT-Administration, ggf. muss man das dann auch noch weiter in dieTiefe (Teams, Arbeitsgruppen, etc.) aufbrechen. Aber das muss man individuell für jeden Kunden neu entscheiden.

 

Wobei es bei meinen Kunden auch eher selten ist, dass ein Mitarbeiter gleichzeitig mehreren Abteilungen angehört.

Jetzt setz ich doch mal die Identity Management Brille auf und hole mal ein Stück weit aus.

 

Es gibt (aus IM-Sicht) eigentlich garkeine Zugehörigkeit eines Mitarbeiters zu einer Abteilung. Es gibt im eigentlichen Sinne einen Mitarbeiter, der eine oder mehere Stellen besetzt. Diese Stellen sind jeweils einer Abteilung zugeordnet. Darüber lässt sich natürlich eine Rückabbildung herstellen, aber eine Zuordnung eines Mitarbeites zu mehreren Abteilungen macht einfach keinen Sinn. Jetzt gibt es verschiedene Wege, wie man vom Mitarbeiter zum User kommen kann:

A) Der Mitarbeiter hat pro besetzter Stelle einen Account mit den jeweiligen spezifischen Berechtigungen und Gruppenmitgliedschaften. Dieses Szenario kommt meist in stark regulierten Unternehmen oder Behörden zum Einsatz und dient der Einhaltung von Compliance-Regelwerken. Man spricht dann hierbei Master- und Slaveidentitäten, Zweikonten oder wie auch immer man das gerne bezeichnen möchte.

 

B) Der Mitarbeiter hat einen User, der alle Berechtigungen aller Stellen die er besetzt vereinigt. Hierbei laufe ich aber Gefahr, das je nach Ausübung der Arbeiten ein Rechtekonflikt entstehen kann. Die Lösung wäre dann der Einsatz der Variante A.

 

So, ich leg die Brille schon wieder beiseite, sollte nur ein kleiner Einblick in meine Denke an dieser Stelle werden, die sich aber durchaus in Teilen auf den Anwendungsfall des TO übertragen lässt.

[NilsK 2.795]

Moin,

 

So, ich leg die Brille schon wieder beiseite, sollte nur ein kleiner Einblick in meine Denke an dieser Stelle werden, die sich aber durchaus in Teilen auf den Anwendungsfall des TO übertragen lässt.

 

Letzteres ist deine Unterstellung. Leider sieht sich der TO aber nicht in der Lage, das mal ordentlich darzulegen. In sofern bleibt es eher Vermutung.

 

(Trotzdem danke für die Ausführungen. Falls du mal einen OU-Design-Artikel veröffentlichen willst ... ;))

 

Gruß, Nils