kaineanung 14 Geschrieben 3. Dezember 2019 Melden Geschrieben 3. Dezember 2019 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! Â
lefg 276 Geschrieben 3. Dezember 2019 Melden Geschrieben 3. Dezember 2019 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.
daabm 1.479 Geschrieben 3. Dezember 2019 Melden Geschrieben 3. Dezember 2019 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.
lefg 276 Geschrieben 3. Dezember 2019 Melden Geschrieben 3. Dezember 2019 (bearbeitet) 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. bearbeitet 3. Dezember 2019 von lefg
NorbertFe 2.415 Geschrieben 3. Dezember 2019 Melden Geschrieben 3. Dezember 2019 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? ;)
magheinz 111 Geschrieben 4. Dezember 2019 Melden Geschrieben 4. Dezember 2019 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.Â
kaineanung 14 Geschrieben 4. Dezember 2019 Autor Melden Geschrieben 4. Dezember 2019 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? Â
magheinz 111 Geschrieben 4. Dezember 2019 Melden Geschrieben 4. Dezember 2019 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 leseï»żn 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 oï»żbwohl 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.Â
kaineanung 14 Geschrieben 4. Dezember 2019 Autor Melden Geschrieben 4. Dezember 2019 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.
Dukel 478 Geschrieben 4. Dezember 2019 Melden Geschrieben 4. Dezember 2019 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.
kaineanung 14 Geschrieben 4. Dezember 2019 Autor Melden Geschrieben 4. Dezember 2019 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?
magheinz 111 Geschrieben 4. Dezember 2019 Melden Geschrieben 4. Dezember 2019  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.Â
lefg 276 Geschrieben 4. Dezember 2019 Melden Geschrieben 4. Dezember 2019 (bearbeitet) 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. bearbeitet 4. Dezember 2019 von lefg
kaineanung 14 Geschrieben 4. Dezember 2019 Autor Melden Geschrieben 4. Dezember 2019 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... Â
Dukel 478 Geschrieben 4. Dezember 2019 Melden Geschrieben 4. Dezember 2019 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).
Empfohlene BeitrÀge
Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto fĂŒr unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden