Jump to content
kaineanung

Migration vom Fileserver und dabei weg vom Organigramm

Recommended Posts

Hallo Leute,

 

wir sollen gleich nach der Migration unserer Domäne von W2K3 auf W2K16 auch den Fileserver (welcher bisher auf dem DC lief) auf ein W2K16 bringen (dieser wird gleich als VMWare-VM erstellt).

Der bisherige Fileserver hatte das Organigramm der Firma abgebildet und auf diesem Board wurde ich in dem Thema DC-Migration darauf hingewiesen daß man Organigramme niemals als OUs und nicht als Filestruktur abbilden solle.

 

So, nun habe ich mir ein paar Gedanken darüber gemacht und soll in meinem Testnetz ein Server aufsetzen wie es richtig gehen sollte so daß dies mein Vorgesetzter seinen Chefs beim nächsten Meeting demonstrieren kann.

 

Das war bisher so:

Nehmen wir an wir hätten bisher diese Ordner:

T3 = Ordner des Teamleiters des Team 3

T3K1 = Ordner des Koordinators (welchem mehrere Gruppen unterstehen) des Unterteams 1

TGL301 = Ordner der Gruppenleiters 301

T301 = Ordner der Gruppe 301

 

So, bisher waren diese Ordner wie die Struktur der Firma verschachtelt:

T3 -> T3K1 -> TGL301 -> T301

Und in jeder Dateiebene ist die entsprechende Berechtigung mit Vererbung hinzugekommen so daß der Teamleiter T3 alle untergebenen Ordner sehen und ändern konnte, alle Koordinatoren (T3K1, T3K2, usw.) darunter Ihre Gruppenleiter-Ordner lesen und ändern konnten, alle Gruppenleiter (TGL301, TGL302 usw.)  ihre Ordner und die darunterliegenden lesen und ändern kontnen und schliesslich die Gruppen (T301, T302, usw.) in Ihren Ordnern Dateien lesen und ändern konnten.

 

Ich habe mir hier sagen lassen daß wir das logisch zusammenfassen sollen. Damit denke ich an 'Projektorientiert'. Wir brauchen aber nach wie vor die Ordner für alle Gruppen denn da sind dann Gleitzeitstände und sonstige Gruppenrelevante Dateien enthalten die nichts mit Projekten oder Aufgaben zu tun haben, Somit bleiben diese Ordner ja nach wie vor enthalten, dann aber eben Flach nebeneinander und mit entsprechend manuell festgelegten Berechtigungen statt die Vererbung zu nutzen.

 

Also habe ich Ordner direkt unter 'Gruppenordner' angelegt die nebeneinander liegen (T3, T3K1, T3K2, TGL301, TGL302, T301, T302) und die Berechtigung gesetzt

(T3 -> nur T3-AD-Gruppe,

T3K1 -> T3- & T3K1-AD-Gruppe,

T3K2 -> T3- & T3K2-AD-Gruppe,

TGL301 -> T3- & T3K1- & TGL301-AD-Gruppe,

T301 -> T3- & T3K1- & TGL301- & T301-AD-Gruppe)

 

Natürlich habe ich auch einen Ordner neben 'Gruppenordner' erstellt in welchem dann Ordner bezüglich verschiedener Themen enthalten sind und die Berechtigungen nach Bedarf gesetzt werden. Dann kann das Team 2 mit der Gruppe TGL351 an einem Projekt arbeiten und sonstige Kreuzungen entstehen. Dieser Ornder heisst dann 'Projektordner' und ist der Rootordner.

Dann gibt es noch ein 'Austauschordner' (wir nennen sie auch Müllhalde ;)) in dem jeder Änderungsberechtigung hat (dienst zum zwischenspeichern, austauschen und der Gleichen.

 

Meine Ordnerstruktur der Gruppen sah also bisher in etwa so aus:

Root
  |
 T3
  |-- T3K1
  |    |
  |  TGL301
  |    |-- T301
  |  TGL302
  |    |-- T302
  |
  |-- T3K2
  |    |
  |  TGL321
  |    |-- T321
  |  TGL323
  |    |-- T323
  |
  |-- usw.
 T2
  |
  |-- usw.
 T6
  |-- usw.
 usw.
  |
 T5

 

Jetzt sieht sie so aus:

 

Arbeitsgruppe (Root)
  |
 T3
  |
 T3K1
  |
 T3K2
  |
TGL301
  |
TGL302
  |
TGL321
  |
TGL323
  |
 T301
  |
 T302
  |
 T321
  |  
 T323
  |
 usw.

 

Und das wesentliche ist jetzt in den Projektbezogenen Ordnern:

 Projektordner (root)
  |
Produktgruppe 'Produktname'
  |
Arbeitgruppe X
  |
Projekt Y
  |
Firmen-Ausflug
  |
 usw.

So, dazu habe ich jetzt mehrere Fragen:

1. Ist das 'IN ETWA' so wie sich hier einige Administratoren vorstellen wenn sie meinen daß ich weg vom Organigramm der Firma gehen soll? Themenbezogen, Gruppenbezogen, Projektbezogen und einfach logisch zusammengefasst?

2. Der Root-Ordner, welcher dann JEDEM in der Domäne per GPP gemappt wird, muss ja mindestens 'Domänen-Benutzer' -> 'Lesen' haben. Die darunterliegenden Ordner aber natürlich nicht. Wie mache ich das am Besten dann? Immer daran denken jedem neu angelegten Ordner in der direkt darunter liegenden Ebene das 'Domänen-Benutzer' -> 'Lesen' entziehen oder gibt es da eine andere (einfachere bzw. sinnvollere) Vorgehensweise? Bisher war es ja so das die entsprechenden Ordner (T3 -> Root des Mitglieds der Gruppe T3,.. T301 -> Root des Mitgliedes T301, usw..) direkt gemappt wurden und sich diese Frage ja nie gestellt hat mit dem gemeinsam genutzten Root-Order 'darüber'?

3. Ich sehe ja den Vorteil bei der flachen Gruppenordnern wenn sich im Organigramm was ändert muss man nichts umbiegen (was eine harte Arbeit war) und man hat weniger arbeit. Aber man nutzt die Vererbung der Rechte nicht mehr und muss bei jedem Ordner manuell die Berechtigungen eintragen die wiederrum dem Organigramm entspricht. Wiegt das eine das andere nicht auf? Es muss doch noch mehr Vorteile geben, nur ich komme gerade nicht darauf. Kann mir das jemand noch ein wenig deutlicher erklären bitte?

 

 

Ich hoffe ich bin nicht ganz auf dem Holzweg weil mein Vorgesetzter so ungefähr dieses Bild von mir erklärt bekommen hat und er ist bereit das wir das so umsetzen und wirklich wegkommen vom Organigramm (Was ich bisher für unmöglich hielt daß wir das jemals machen würden).

 

Ich danke euch allen schon einmal jetzt für das sicherlich nicht ganz einfache lesen meiner Frage bis hierher und eurer Mühe!

 

Share this post


Link to post
Share on other sites

Moin

 

Bei "mir" sah es eher aus wie deine ursprüngliche File-Struktur, dass hatte aber nichts mit der Unternehmenstruktur zu tun.. Nur auf Root war die Freigabe. Berechtigungen erteilt durch Sicherheitsgruppen. Die User gehörten dann den Sicherheitsgruppen an. Sichtbar/Nichtsichtbar von Ordern mit Access Based Enumeration, User sahen nur Ordner/Dateinén, auf die sie Berechtigungungen hatten.

Share this post


Link to post
Share on other sites

Auf File-Ebene kommst Du um EINEN Organigrammbasierten Ast meist nicht rum. Aber warum müsst Ihr unbedingt dieses Top-Down-"Machtprinzip" umsetzen? Ist doch komplett out - wenn einer was persönliches hat, soll er's woanders hinstecken, und ansonsten darf jeder alles sehen, was nicht geheim ist.

Share this post


Link to post
Share on other sites
vor 3 Stunden schrieb daabm:

ansonsten darf jeder alles sehen, was nicht geheim ist.

 

Als "geheim" eingestuft sind z.B. Kalkulation, die Schemen und Zahlen dafür. Das betraf auch die Kalkulation der Küche und des Kiosk.

Edited by lefg

Share this post


Link to post
Share on other sites
vor 3 Stunden schrieb daabm:

Auf File-Ebene kommst Du um EINEN Organigrammbasierten Ast meist nicht rum. Aber warum müsst Ihr unbedingt dieses Top-Down-"Machtprinzip" umsetzen? Ist doch komplett out - wenn einer was persönliches hat, soll er's woanders hinstecken, und ansonsten darf jeder alles sehen, was nicht geheim ist.

Warst du das nicht mit need to know? ;)

Share this post


Link to post
Share on other sites
vor 8 Stunden schrieb kaineanung:

auf diesem Board wurde ich in dem Thema DC-Migration darauf hingewiesen daß man Organigramme niemals als OUs und nicht als Filestruktur abbilden solle.

Also sowohl unser Netzlaufwerk hat einen Baum der das Organigramm abbildet als auch unser AD. 

Im Filesystem gibt's daneben einen Baum für übergreifende Gruppen und einen in dem alle Mitarbeiter leseberechtigt sind. 

Ich wüsste auch nicht warum das nicht so sein sollte. 

Share this post


Link to post
Share on other sites
vor 15 Stunden schrieb lefg:

Bei "mir" sah es eher aus wie deine ursprüngliche File-Struktur, dass hatte aber nichts mit der Unternehmenstruktur zu tun.. Nur auf Root war die Freigabe. Berechtigungen erteilt durch Sicherheitsgruppen. Die User gehörten dann den Sicherheitsgruppen an. Sichtbar/Nichtsichtbar von Ordern mit Access Based Enumeration, User sahen nur Ordner/Dateinén, auf die sie Berechtigungungen hatten.

1. Wenn es nichts mit der Unternehmensstruktur zu tun hatte, ja mit welcher Struktur denn dann?

2. Wenn auf Root die Freigabe ist, dann ist da die Lese-Berechtigung für alle. Wie hast du das dann gelöst das lesen in den Unterordnern nicht da war für alle sondern nur für die mit entsprechender AD-Gruppen-Mitgleidschaft? Macht man das dann mit Access Based Enumeration? Diese Technik verhindert das Lesen der Ordner obwohl Lese-Berechtigung für z.B. alle Domänen-Benutzer vorhanden ist?

3. Wieso sagen mir 80% der Administratoren auf diesem Board ich müsse weg vom Organigramm? Das sagen Sie mir schon sehr lange. Ich habe jetzt meinen Vorgesetzten bearbeitet und bearbeitet und stehe kurz vor dem Durchbruch und jetzt ist das alles gar nicht so? Das wäre jetzt fatal für mich denn ich werde nie wieder irgendwas durchsetzen können was die Filestruktur angeht wenn ich das jetzt nicht durchziehe.... Also die Frage nochmals an ALLE hier: WEG vom ORGANIGRAMM der Firma oder nicht? Wenn ja: was sind die Vorteile?

vor 11 Stunden schrieb daabm:

Auf File-Ebene kommst Du um EINEN Organigrammbasierten Ast meist nicht rum. Aber warum müsst Ihr unbedingt dieses Top-Down-"Machtprinzip" umsetzen? Ist doch komplett out - wenn einer was persönliches hat, soll er's woanders hinstecken, und ansonsten darf jeder alles sehen, was nicht geheim ist.

Was meinst du mit EINEM Organigramm Ast nicht herumkommen? Ich habe ein Organigramm welches die Firmenhierarchie abbildet. Hier hieß es auch daß ihr alle nicht mehr als 2 Ebenen, max. 3 Ebenen nutzt im Fileserver 'nach unten'. Was für Organigramm ohne dieses 'Top-Down-Machtprinzip' gibt es denn sonst?

 

Share this post


Link to post
Share on other sites
vor 2 Minuten schrieb kaineanung:

1. Wenn auf Root die Freigabe ist, dann ist da die Lese-Berechtigung für alle. Wie hast du das dann gelöst das lesen in den Unterordnern nicht da war für alle sondern nur für die mit entsprechender AD-Gruppen-Mitgleidschaft? Macht man das dann mit Access Based Enumeration? Diese Technik verhindert das Lesen der Ordner obwohl Lese-Berechtigung für z.B. alle Domänen-Benutzer vorhanden ist?

Root ist die Freigabe. 

Darin befinden sich bei uns nur Ordner. Auf diese sind wie bei lefg die Berechtigungen gesetzt. Alles streng nach AGDLP. 

 

vor 5 Minuten schrieb kaineanung:

Also die Frage nochmals an ALLE hier: WEG vom ORGANIGRAMM der Firma oder nicht? Wenn ja: was sind die Vorteile?

Du brauchst eine wart- und nutzbare Struktur. Ob die sich am Organigramm orientiert oder nicht ist egal. 

Eine offensichtliche hierarchische Struktur flach zu machen und die Hierarchie in den Ordnernamen zu verstecken halte ich für nicht sinnvoll. 

Share this post


Link to post
Share on other sites
vor 8 Stunden schrieb lefg:
vor 11 Stunden schrieb daabm:

ansonsten darf jeder alles sehen, was nicht geheim ist.

 

Als "geheim" eingestuft sind z.B. Kalkulation, die Schemen und Zahlen dafür. Das betraf auch die Kalkulation der Küche und des Kiosk.

Das sollen und dürfen wir nicht beeinflussen: Geheim ist das Mitarbeitergesprächsprotokoll, Die Produktionsstände, die Krankenlisten (falls das ein Gruppenleiter neben unserem ERP oder sonstwo führen sollte), Aufträge die die anderen Abteilungen nichts angehen, usw.. da kann vieles drinnen sein die andere nichts angeht ausser die direkten Vorgesetzten die dann auch Einblick haben.

 

vor 1 Minute schrieb magheinz:

Du brauchst eine wart- und nutzbare Struktur. Ob die sich am Organigramm orientiert oder nicht ist egal. 

Eine offensichtliche hierarchische Struktur flach zu machen und die Hierarchie in den Ordnernamen zu verstecken halte ich für nicht sinnvoll. 

Wenn ich aber Gruppen habe die ihr eigenen Ordner haben, wie und wo packe ich den weg? Die brauchen ja ihren Ordner um Gruppenbelange dort abzuspeichern..

Was ist denn die Alternative? Viele hier reden von 'wart-und nutzbaren Strukturen' oder früher auch 'logisch gegliederte Strukturen'. Wenn das nicht das Firmen-Organigramm ist, was dann?

 

Der Ansatz ist sicherlich so in etwa wie mit meinem 'Projektordner' die dann auch übergreifende Gruppenberechtigungen beinhalten kann. Aber wie mache ich das dann mit den Gruppenordnern? Denn nicht alles ist 'Projekt' und eine Entität.

Share this post


Link to post
Share on other sites
14 minutes ago, kaineanung said:

3. Wieso sagen mir 80% der Administratoren auf diesem Board ich müsse weg vom Organigramm? Das sagen Sie mir schon sehr lange. Ich habe jetzt meinen Vorgesetzten bearbeitet und bearbeitet und stehe kurz vor dem Durchbruch und jetzt ist das alles gar nicht so? Das wäre jetzt fatal für mich denn ich werde nie wieder irgendwas durchsetzen können was die Filestruktur angeht wenn ich das jetzt nicht durchziehe.... Also die Frage nochmals an ALLE hier: WEG vom ORGANIGRAMM der Firma oder nicht? Wenn ja: was sind die Vorteile?

Was meinst du mit EINEM Organigramm Ast nicht herumkommen? Ich habe ein Organigramm welches die Firmenhierarchie abbildet. Hier hieß es auch daß ihr alle nicht mehr als 2 Ebenen, max. 3 Ebenen nutzt im Fileserver 'nach unten'. Was für Organigramm ohne dieses 'Top-Down-Machtprinzip' gibt es denn sonst?

Hier geht es meist um das AD. Dort braucht man die Organisations Struktur nicht, da es beim AD um das Verwalten der Einheiten geht.

In einem Fileserver sieht das ganze anderst aus. Hier kann man ruhig die Organisationsstruktur nachbauen, da die selben Strukturen meist auf die selben Daten zugreifen sollen.

Die Verknüpfung der AD Sgtruktur mit dem Filesystem sind die Gruppen. Hier ist es z.B. einfacher bei einem Abteilungswechsel, einen Benutzer die Gruppen anzupassen und nicht den Benutzer im AD zu verschieben.

Share this post


Link to post
Share on other sites
vor 13 Minuten schrieb Dukel:

Hier geht es meist um das AD. Dort braucht man die Organisations Struktur nicht, da es beim AD um das Verwalten der Einheiten geht.

In einem Fileserver sieht das ganze anderst aus. Hier kann man ruhig die Organisationsstruktur nachbauen, da die selben Strukturen meist auf die selben Daten zugreifen sollen.

Die Verknüpfung der AD Sgtruktur mit dem Filesystem sind die Gruppen. Hier ist es z.B. einfacher bei einem Abteilungswechsel, einen Benutzer die Gruppen anzupassen und nicht den Benutzer im AD zu verschieben.

Mist, ich sollte vielleicht nachdenken meine Gedanken, Wünsche und Aufgaben besser zu kommunizieren bzw. es zu lernen.

Denn das was du gerade gesagt hast, davon bin ich schon immer ausgegangen! Ich hätte aber schwören können daß die Admins hier auch die Filestruktur meinten denn AD war bei mir nie so wirklich geplant in eine Struktur zu pressen. AD ist bei mir momentan absolut Flach (Computer sind im Computer-OU, Benutzer in der Benutzer-OU und das war es).

Wenn ich die Zeit finde werde ich die betreffenden Beiträge finden und euch zeigen daß man mir nahegelegt hat max. 2 oder 3 Ebenen in der Ordnerstruktur haben sollte und alles lieber logisch organisieren und Zusammenführen auf dem FILESERVER. Und das ich ein ABE (Acces Based Enumerationmaun) oder ein ACL oder irgendwie sowas nutzen soll usw. usf..

Das kann ja gar nicht nur in der AD gemeint gewesen....

 

@All

 

Denkt ihr alle also daß ich meine Ordnerstruktur, die sich nach dem Organigramm der Firma richtet, beibehalten soll?

Was mache ich mit den Laufwerksmappings? Auch so beibehalten daß die User in ihrer 'Ebene' einsteigen oder in Root Einsteigen und sie nach unten druchklicken lasse?

Dazu brauche ich dann das ABE damit sie auch nichtmal die anderen Ordner sehen auf die Sie kein Schreibzugriff haben oder so? Sonst wird es ja unübersichtlich für die. ODer wie macht man das dann genau sollte ich sie in Root einsteigen lassen?

Share this post


Link to post
Share on other sites

 

vor 36 Minuten schrieb kaineanung:

Der Ansatz ist sicherlich so in etwa wie mit meinem 'Projektordner' die dann auch übergreifende Gruppenberechtigungen beinhalten kann. Aber wie mache ich das dann mit den Gruppenordnern? Denn nicht alles ist 'Projekt' und eine Entität.

Im Root gibt es bei uns die Ordner

-Abteilungen

-Projekte

-GruppenNA

-Service

 

Ausser in Abteilungen und in einer Ausnahme in GruppenNA werden nur auf der nächsten Ebene Rechte verwaltet. Also GruppenNA/foobar. 

 

In Service haben immer alle Leserecht. 

 

vor 26 Minuten schrieb Dukel:

Hier ist es z.B. einfacher bei einem Abteilungswechsel, einen Benutzer die Gruppen anzupassen und nicht den Benutzer im AD zu verschieben.

Das sehe ich nicht so. 

Bei uns geschieht einfach beides. 

Die OUs Regeln die Organisation, die Gruppen die Weitergehenden Berechtigungen. 

Das powershellscript um neue User anzulegen macht alles automatisch nach Übergabe von Vorname, Nachname, Fachbereich und Befristung(falls befristet). Die Parameter kommen aus einem per Formular erstelltes Ticket. 

Share this post


Link to post
Share on other sites
vor 2 Stunden schrieb kaineanung:

Wenn auf Root die Freigabe ist, dann ist da die Lese-Berechtigung für alle. Wie hast du das dann gelöst das lesen in den Unterordnern nicht da war für alle sondern nur für die mit entsprechender AD-Gruppen-Mitgleidschaft?

 

Nein, kein Lesen für alle!

 

-  Die Vererbung wurde unterbrochen

- Berechtigungen über Gruppenmitgliedschaft

vor 2 Stunden schrieb kaineanung:

Wieso sagen mir 80% der Administratoren auf diesem Board ich müsse weg vom Organigramm?

 

Ich denke, gemeint ist die Struktur der OUs, nicht die des Fileservers.

 

Und ob ein Weg von einer Struktur notwendig, zwingend, das musss der Admin selbst sehen und entscheidend. OUs sind Mittel zur Administration, sie sollen es den Admins einfacher machen, die dafür Kosten niedrig halten.

 

Falls jemand nun solch eine Struktur geerbt hat von Vorgängern oder Dienstleistern, für Computer und eventuell auch für Benutzer, dann muss er selbst erkennen, ob ein Umbau sinnvoll und nötig ist, er sollte erkennen, wie er es benötigt zur Administration.

 

Als wir damals mit Windows 2000 begannen mit einem Workshop hatten wir ein Buch, darin war als Beispiel auch ein Unternehmen abgebildet. Wir machten das zur Probe denn mal so mit, merkten es macht uns viel Arbeit schon beim Anlegen, noch mehr bei Änderungen. Wir hatten das nach Gebäuden und Büros abgebildet. Nun, Computer und Benutzer wanderten, davon erfuhren wir dann zufällig. Das machte also keinen Sinn.

 

Ich hatte auf "meinem" Hof zwei Gebäude-Komplexe und zwei Abteilungen. Es ergab sich und bewährte sich, je Komplex eine Computer OU und je Abteilung eine User-OU. Das diente erstmal nur der Ordnung zur besseren Übersicht, mehr nicht.

Edited by lefg

Share this post


Link to post
Share on other sites
vor 3 Stunden schrieb lefg:

Nein, kein Lesen für alle!

Aber wie können die User dann auf diesen Ordner ein Laufwerk mappen?

Um sich dann durch die Ordnerstruktur durchzuklicken, benötigen die ja mindestens Lesen bzw. Auflisten der Ordner, oder nicht?

 

Wir haben bisher die Freigaben in jedem Ordner gehabt und je nachdem wer sich angemeldet hat wurde sein G-Laufwerk da direkt hingemappt.

Das sah so aus (Einstieg -> Root des G-Laufwerks):

 

Root
  |
 T3  <-- Einstieg der User in der AD-Gruppe T3 (Teamleiter)
  |-- T3K1  <-- Einstieg der User in der AD-Gruppe T3K1 (Koordinatoren)
  |    |
  |  TGL301  <-- Einstieg der User in der AD-Gruppe TGL301 (Gruppenleiter)
  |    |-- T301  <-- Einstieg der User in der AD-Gruppe T301 (Gruppenmitglieder)
  |  TGL302
  |    |-- T302
  |
  |-- T3K2
  |    |
  |  TGL321
  |    |-- T321
  |  TGL323
  |    |-- T323
  |
  |-- usw.
 T2
  |
  |-- usw.
 T6
  |-- usw.
 usw.
  |
 T5

 

Hier im Board wurde mir früher gesagt das ich 1.) die Firma nicht nachbilden soll und max. 2-3 Eben 'runtergehen' soll und 2.) bekommt jeder User nicht sein Ordner gemappt sondern steigt wie jeder andere ganz oben ein und muss sich durchklicken bis zu seinem Ordner.

Also in etwa so:

 

Root  <-- Einstieg aller User. Das Gruppenlaufwerk mit dem Laufwerksbuchstaben 'G' wird immer hierher gemappt.
  |
 T3  <-- Ordner (ohne Inhalte) sichtbar für ganze T3-Gruppe (T3, T3K1, TGL301, T301->T3x-Gruppe), änderbar nur für T3. Alle anderen sehen den Ordnern nicht.
  |-- T3K1  <-- Ordner (ohne Inhalte) sichtbar für ganze T3x-Gruppe, änderbar nur für T3 + T3K1. Alle anderen sehen den Ordnern nicht.
  |    |
  |  TGL301  <-- Ordner (ohne Inhalte) sichtbar für ganze T3x-Gruppe, änderbar nur für T3 + T3K1 + TGL301. Alle anderen sehen den Ordnern nicht.
  |    |-- T301  <-- Ordner (ohne Inhalte) sichtbar für ganze T3x-Gruppe, änderbar nur für T3 + T3K1 + TGL301 + T301. Alle anderen sehen den Ordnern nicht.
  |  TGL302
  |    |-- T302
  |
  |-- T3K2
  |    |
  |  TGL321
  |    |-- T321
  |  TGL323
  |    |-- T323
  |
  |-- usw.
 T2
  |
  |-- usw.
 T6
  |-- usw.
 usw.
  |
 T5

Habe ich das richtig verstanden? Wenn ja: Root muss von jedem lesend zugegriffen werden können (Ordnerauflistung um sich zu seinem Zeug durchzuklicken). T3x-Gruppenmitglieder sollen Aber T2 und den Rest nicht sehen. Wie macht man das ausser manuell auf jeden Unterornder direkt unter Root das lesen-Recht zu entziehen?

 

Und so nebenbei bemerkt: ist unsere bisherige Vorgehensweise nicht praktikabler?

Ich suche auch gerade in den alten Beiträgen die Stellen an denen mir nahegelegt wurde daß mit den max. 2-3 Ebenen und Einstieg aller auf Root und mit irgendwelchen ACL (oder war es das mit dem ABE?) die Ordner zu verstecken vor denen die nicht zu diesem Gruppen-Strang gehören?

Ich habe aber viele Themen eröffnet und manche sind irrelang. Kann dauern bis ich das finde...

 

Share this post


Link to post
Share on other sites

Es kommt drauf an, wie feingranular das sein soll. Das ist für jede Firma Unterschiedlich.

Ich würde schauen, dass das so einfach wie möglich ist. Z.b. jede Abteilung oder Team bekommt sein Laufwerk und jeder aus diesem Team kann darin lesen und schreiben.

Wieso sollen Teamleiter, Koordinatoren und Gruppenleiter nur bestimmte Dinge schreiben dürfen. Evtl. kann man einen Ordner für das Management eines Teams / einer Abteilung machen. Aber das kommt auf die Anforderungen der Abteilung an.

 

Das mit den 2-3 Ebenen hat mit den Rechten zu tun. Es kann schon mehr Ebenen geben, aber je tiefer Rechte vergeben werden, desto komplexer wird das ganze.

 

ABE ist eine Einstellung, dass nur die User die Ordner sehen, auf die sie Rechte haben. Kann man generell aktivieren (früher hat das eine gewisse Last bedeutet und wurde daher nicht immer aktiviert).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


Werbepartner:



×
×
  • Create New...