Jump to content

Fileserver-Struktur: Wie macht ihr das mit den (zusätzlichen) Berechtigungen und überhaupt mit der Struktur?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo Leute,

wir sind gerade dabei die Struktur unserer Fileserver-Architektur zu ändern im Zuge der Migration von W2K3 auf W2K16.
Ich soll ein Konzept erarbeiten und dann sehen wir weiter.

Die Ordnerstruktur auf dem Fileserver ist der Firmenhierarchie nachempfunden. Dies ist so historisch bedingt weil vor vielen Jahren es noch überschaubar war und man konnte es leichter 'handeln' als jetzt. Daher ist das dann immer mehr gewachsen und es ist ausgeartet. Nach langem Suchen und intensiver Informationsbeschaffung kam ich zum Schluß: das wird so nicht empfohlen und man sollte es lieber 'Projektbasierend' gestalten. Max. 2-3 Ebenen und nicht starr an Teams, Gruppen und der Gleichen orientieren wie so eine Firma aufgebaut ist.

Ok, habe ich verstanden. Alles wird zu Projekten, die Projektordner haben eine Sicherheitsgruppe in der andere Gruppen oder Userobjekte enthalten sind und der 'Einstiegspunkt' ist eine Freigabe die für alle gilt (bisher hat jede Gruppe, jeder Teamleiter und jeder Koordinator seine eigene Freigabe gehabt welche dann als sein Netzlaufwerk gemappt wurde).

Wenn dies NICHT das gängige Konzept ist dann bitte hier einschreiten. Ich habe vor einigen Monaten hier und einem anderne Forum diesbezüglich mich beraten lassen und das ist dabei herausgekommen. Ich gehe davon aus das dies so der durschschnittliche Standard darstellt wenn ich halbwegs alles richtig verstanden hatte.

Auch bin ich weg von haufenweise Berechtigungen auf der NTFS-Ebene zu setzen sondern die 'wer darf und wer nicht' der AD zu überlassen (Verkettung der Sicherheitsgruppen -> Koordinatorgruppe ist Mitglied der Teamleitergruppe, Teamleitergruppe ist Mitglied der Teamgruppe und auf NTFS-Ebene gibt es dann eine Sicherheitsgruppe die auf ihrem Ordner berechtigt ist).
In Projekten bzw. deren Projektordnern sowieso.

Nochmals: wenn ich mit diesem Konzept auf dem Holzweg bin, dann bitte ich um neue und bessere Konzepte bzw. Meinungen. Ich weiß nur das eine Firmen-Orninagram auf der Fileserver nicht wünschenswert ist (so der Tenor hier und im anderen Forum).

So, soweit so gut.

Jetzt kommt aber die Frage die mich sozusagen als letzter 'möglicher Stolperstein' beschäftigt:
Es gibt immer Leute oder Gruppen die in bestimmten Ordnern nur lesend zugreifen sollen.
Somit kann ich diese Leute ja nicht der Projekt-Sicherheitsgruppe zuweisen denn die dürfen ja mehr.
Wie macht ihr daß das es überschaubar und verwaltbar bleibt?
Mir scheint das Konzept hier nicht ganz aufzugehen. Denn wir haben ein Projekt 'VERTRIEBSDATEN' und dort diverse Unterprojekte. Jetzt soll eine Person, die nicht Mitglied der Sicherheitsgruppe 'VERTRIEBSDATEN' ist, aber in einem der Unterordner (die als Unterprojekte bezeichnet werden können) lesend zugreifen können.
Wie macht ihr das? Wie löst man das am Besten?


IST-Zustand:

Root
  - Team 1
     - Teamleiter 1
        - Koordinator 1 Team 1
          - Gruppenleiter 1 Team 1
             - Gruppe 1 Team 1
          - Gruppenleiter 2 Team 1
             - Gruppe 2 Team 1
        - Koordinator 2 Team 1
          - Gruppenleiter 3 Team 1
             - Gruppe 3 Team 1
  - Team 2
     - Teamleiter 2
        - Koordinator 1 Team 2
          - Gruppenleiter 1 Team 2
             - Gruppe 1 Team 2
  - Team 3
     - Teamleiter 3
        - Koordinator 1 Team 3
          - Gruppenleiter 1 Team 3
             - Gruppe 1 Team 3
        - Koordinator 2 Team 3
          - Gruppenleiter 2 Team 3
             - Gruppe 2 Team 3
usw..


Jeder dieser Order hat eine Freigabe und dient als Mappings-Einstiegpunkt der einzelnen User die in den entsprechenden Sicherheitsgruppen sind.

Davon wollen wir, auf die Empfehlung diverser User von mcseboard.de und eines anderen Borads, wegkommen.

Angedacht ist folgendes:

- root
  - Team 1
     - Teamleiter 1
     - Koordinator 1 Team 1
     - Koordinator 2 Team 1
     - Gruppenleiter 1 Team 1
     - Gruppenleiter 2 Team 1
     - Gruppenleiter 3 Team 1
     - Gruppe 1 Team 1
     - Gruppe 2 Team 1
     - Gruppe 3 Team 1
  - Team 2
     - Teamleiter 2
     - Koordinator 1 Team 2
     - Gruppenleiter 1 Team 2
     - Gruppe 1 Team 2
  - Team 3
     - Teamleiter 3
     - Koordinator 1 Team 3
     - Koordinator 2 Team 3
     - Gruppenleiter 1 Team 3
     - Gruppenleiter 2 Team 3
     - Gruppe 1 Team 3
     - Gruppe 2 Team 3
  - Projekte
     - Projekt 1
     - Projekt 2
     - Projekt 3

Somit wird alles fast ganz flach, jeder wird nach root gemappt und sieht nur die Ordner auf die er berechtigt ist und muss sich durchklicken (was ja bei max. 2 Unterordner kein Problem darstellen sollte). Auch der Schwenk hin zu Projekten statt zu Gruppenordnern sieht man hier. Klar soll jede Gruppe auch ein Ordner haben für Daten der Gruppenbelange, aber das wird relativ wenig und alles verlagert sich auf die Projekt-Ordner (z.B. Vertriebsdaten wird ein Projekt mit eigener Sicherheitsgruppe auf der AD in denen dann die Mitglieder bestimmt werden. Sei es einzelne User oder ganze Gruppen).

So, das nochmals bildlich dargestellt wie ich das damals von Foristen aus mcseboard.de und einem anderen Board verstanden hatte.
Wenn ich auf dem Holzweg bin dann bitte einschreiten...


Ich habe nun in einer Testumgebung das alles so nachgebildet und es scheint echt gut zu funktionieren und es ist viel einfacher zu managen. Vor allem in den Projekten können die Leute aus verschiedenen Firmengruppen nun teilhaben was sich bisher als extrem schwierig gestaltet hat (Ausnahmen bilden und Leuten mühselig Rechte auf der NTFS-Ebene vergeben daß sie sich a) durchklicken können bis zum entsprechenden Ordner und b) dort separat Berechtigungen hatten -> wird mit der Zeit unübersichtlich und unhandlebar).
Jetzt einfach Mitglied der entsprechenden Sicherheitsgruppe (= Projektgruppe) werden und plötzlich sieht man es und kann teilhaben.


ABER, und das ist jetzt meine Frage, wie sieht es mit den Leuten aus die in Projekt 1 nichts sehen sollen, aber in einem Unterordner des Projektes (sozusagen das Unterprojekt 1) lesend zugreifen können sollen?

Muss ich dann in "Projekt 1-Ordner" dem User 'nur auflisten'-Berechtigung geben und dann auf dem Unterordener 'Unterprojekt 1' lesen-Berechtigung?
Das wird sich dann aber auch schnell als unüberschaubar heraustellen und schwer verwaltbar...
Aber eine andere Idee habe ich nicht. Somit die Frage: ist das so ok? Ist das so normal? Wie macht ihr das?

Ich hoffe das mir jemand nun kurz vor der Ziellinie hilft damit das Migrationsprojekt des Fileservers nun umgesetzt werden kann.

Danke schon einmal im Voraus für eure Hilfe! Danke das ihr bisher überhaupt gelesen habt bei so viel Text!

Link zu diesem Kommentar

ich kann Dir nur sagen wie wir das machen. Wir vergeben KEINERLEI Rechte unterhalb der jeweiligen Projektverzeichnisse, Workgroups, Process, DB Ordner ...

 

wir haben bei uns im DFS

 

Department 

 - Accounting

 - Einkauf

 ...

Workgroups

 - WK 1

 - WK 2

...

Projects

 - PJ 1

 - PJ 2

...

 

Process

...

 

Database

...

 

Für die jeweiligen Unterverzeichnisse gibt es i.d.R. drei Gruppen ... Read, Read/Write, Manage - Mange sind die Mitarbeiter, die die Gruppe Read und Read/Write pflegen und verwalten. Derjenige, der eine Workgroup, Projekt Verzeichnis, etc. beantragt ist i.d.R. der Verantwortliche. Bei uns pflegen viele der jeweiligen Verantwortlichen die Mitglieder der R und R/W Gruppe selbst (schafft uns einiges an Arbeit vom Hals)

 

In den Department Verzeichnissen sind NUR Abteilungsmitarbeiter zugelassen. Wird/Sollen Daten für andere zugänglich gemacht werden müssen diese in eine Workgroup, Projekt oder Prozessordner ... je nach Typ halt.

 

Damit fahren wir eigentlich ganz gut - man bekommt halt viel Gruppen/Verzeichnisse (ca.2000 aber eben klar gegliedert) zusammen. Wir haben ABE auf den Shares aktiv - also sehen die Mitarbeiter auch nur die Sachen, für die sie Rechte haben.. Ich finde das Modell was da meine Vorgänger und mein jetziger Kollege da ausgeknobelt haben ganz gut und flexibel. Irgendwann kommen immer mal wieder User ums Eck, die Rechte in Unterverzeichnisse gesetzt haben wollen, aber das wird von uns immer verweigert - auch gegenüber GF oder ALs. Gibt es einfach nicht! Wichtig ist nur, dass sich die Admins da einig sind - gibt immer mal wieder User, die probieren die Anfrage beim Kollegen, wenn der nein sagt, kommen sie zu mir und ich sag auch nein :D 

 

 

bearbeitet von Squire
Link zu diesem Kommentar
vor 10 Minuten schrieb Squire:

ich kann Dir nur sagen wie wir das machen. Wir vergeben KEINERLEI Rechte unterhalb der jeweiligen Projektverzeichnisse, Workgroups, Process, DB Ordner ...

Das will ich ja gerade wissen: wie ihr das macht. Damit kann ich mich ja orientieren und schauen was es so alles gibt. Wir waren uns vor einiger Zeit aber alle hier einig daß es so, wie wir das nun machen, niemand machen sollte. Damit meine ich das Firmen-Organigram abbilden auf dem Fileserver.

vor 12 Minuten schrieb Squire:

wir haben bei uns im DFS

 

Department 

 - Accounting

 - Einkauf

 ...

Workgroups

 - WK 1

 - WK 2

...

Projects

 - PJ 1

 - PJ 2

...

 

Das kommt ja dann in etwa hin wie ich mir das vorgestellt hatte.

Ich hätte eben nur statt einem Odernder "Department" gleich die paar 'Departements' (sind bei uns 5 Teams) unter Root nebeneinander aber den Rest dann doch noch einmal Gruppiert mit 'Projekt' und dann die einzelnen Projekte darunter (die sprechende Namen haben).

 

Also in etwa so:

- Team 1

  - Gruppe 1-1

  - Gruppe 1-2

  - Gruppe 1-3

- Team 2

  - Gruppe 2-1

  - Gruppe 2-2

  - Gruppe 2-3

- Team 3

 - Gruppe 3-1

usw.

- Projekte

  - Projekt 1

  - Projekt 2

usw.

- Ungesichert

vor 20 Minuten schrieb Squire:

Für die jeweiligen Unterverzeichnisse gibt es i.d.R. drei Gruppen ... Read, Read/Write, Manage - Mange sind die Mitarbeiter, die die Gruppe Read und Read/Write pflegen und verwalten. Derjenige, der eine Workgroup, Projekt Verzeichnis, etc. beantragt ist i.d.R. der Verantwortliche. Bei uns pflegen viele der jeweiligen Verantwortlichen die Mitglieder der R und R/W Gruppe selbst (schafft uns einiges an Arbeit vom Hals)

 

Ok, DAS wollte ich jetzt sehen. So ähnlich ist es mir schon durch den Kopf geschwirrt nur das ich eine AD-Sicherheitsgruppe habe die alles darf (wie eim EP beschrieben) und eine die nur lesen darf.

Dann hätte jede Projekt-Gruppe 2 AD-Sicherheitsgruppen. Eine normale und eine 'nur lesen'-Gruppe.

ABER: dann kann ich das zwar managen wer im dem Projekt alles darf und wer nur lesen darf indem ich die entsprechende Mitgliedschaft vergebe. Das Problem mit meiner 'Ausnahme' das jemand erst im Unterordner lesen darf, kann ich so auch nicht 'mit System' lösen sondern muss manuell auf dem Projektordner 'nur Ordner auflisten' vergeben und dann auf den Unterordner 'lesen' vergeben.

Mit diesem Ansatz kann ich 'nur' (was ja trotzdem ein Fortschritt wäre) auf gleicher Ordnerebene bestimmen ob wer nur lesen oder auch schreiben und ändern kann.

 

Das mit dem Verantwortlichen der Gruppe und vor allem des selber Pflegens verstehe ich nicht ganz. Oder vielleicht verstehe ich es und kann es nur nicht glauben:

hat da dann der Verantwortliche Nicht-ITler die Active Direcotory Tools (RSAT) installiert und kann Benutzer und Gruppen managen? Nee, das muss ich komplett falsch verstanden haben...

Wir haben hier hochqualifizierte Leute die wirklich gut in ihrem Job sind, aber den Knopf am Monitor zum PC-Ausmachen drücken... denen gebe ich sicherlich kein Management-Tool der IT in die Hand... Also, wie meinst du daß das die das Pflegen?

 

 

 

Zu den ABEs auf den Shares:

würden wir dann auch haben. Das bedeutet aber lediglich das die Ordner ausgeblendet werden auf die man keine Berechtigung hat, richtig? Oder war das auch noch für was anderes?

vor 40 Minuten schrieb Squire:

Wichtig ist nur, dass sich die Admins da einig sind - gibt immer mal wieder User, die probieren die Anfrage beim Kollegen, wenn der nein sagt, kommen sie zu mir und ich sag auch nein :D

Das kommt mir sooo bekannt vor. Ich glaube das dies eine allgemeine Vorgehensweise weltweit ist :D

Link zu diesem Kommentar

@daabm: genauso ist es - deshalb gibt es unterhalb der einzelnen Apteilungs, Workgroups, Projektverzeichnisse KEINERLEI Rechteaufbrüche. Es gibt Lesen und es gibt Modify - fertig! Sonst verwaltet man sich dumm und dusselig - das kann man vielleicht in einer kleinen Klitsche mit 5 Usern machen aber nicht in größeren Unternehmen.

 

@kaineanung: Departments sind bei uns die Abteilungsverzeichnisse - diese sind innerhalb der einzelnen Abteilungen Rechte mäßig NICHT untergliedert. Es gilt der gleiche Grundsatz wie bei allen anderen Verzeichnissen.

 

Zitat

ABER: dann kann ich das zwar managen wer im dem Projekt alles darf und wer nur lesen darf indem ich die entsprechende Mitgliedschaft vergebe. Das Problem mit meiner 'Ausnahme' das jemand erst im Unterordner lesen darf, kann ich so auch nicht 'mit System' lösen sondern muss manuell auf dem Projektordner 'nur Ordner auflisten' vergeben und dann auf den Unterordner 'lesen' vergeben.

Mit diesem Ansatz kann ich 'nur' (was ja trotzdem ein Fortschritt wäre) auf gleicher Ordnerebene bestimmen ob wer nur lesen oder auch schreiben und ändern kann.

 

Halte ich NICHT für sinnvoll. Wie der Kollege geschrieben hat: keep it simple. 

 

Auf den Rechnern sind keine RSAT Tools installiert - das ist auch nicht notwendig, da Windows das Gruppenverwaltungstool immer an Board hat.

 

Die Verwaltungsgruppen heißen bei uns wie die Verzeichnisse mit entsprechenden Suffix ro bz. rw, damit finden die Poweruser ihre pflegeberechtigten Gruppen entsprechend leicht über die Suche

 

Machst Du Doppelklick auf die Netzwerkumgebung: image.thumb.png.f91ffcb4231fa077b00674f482a7a07a.png 

bearbeitet von Squire
Link zu diesem Kommentar
vor 14 Stunden schrieb daabm:

Ich frage mich, ob "Unterordner von Projekt 1 lesen, aber das Projekt 1 selbst nicht" sinnvoll zu begründen ist.

"Keep it simple" wäre meine Devise.

Ich weiß das. Leider weiß das der Chef nicht... und solange es 'nur' in einem Unterordner so ist bleibt es ja verwaltbar und überschaubar.

Es ist so daß eine Userin irgendwas für die Chefs machen muss wo sie Informationen aus dem Unterordner benötigt wo nur die Chefs zugreifen können sollen. Dies aber eben nur auf diesen Unterordner und nur lesend.

Ich werde versuchen eine andere Lösung für das Problem zu finden, aber falls ich es nicht schaffe, wollte ich lediglich wissen ob es eine systematische Lösung für das Problem gibt.

Ich habe vor einigen Monaten von ABEs nichts gewusst. Ich hatte aber dieses Problem und die entsprechende Frage hier gestellt welches das aktivieren der ABE gelöst hat.

Also gab es eine systematische Lösung damals für mein Problem.

Ich dachte vielleicht gibt es ja wieder so eine Lösung für mein aktuelles Problem.

Aber Recht habt ihr: sollte man vermeiden und 'keep it simple'. Wenn ich es schaffe es zu vermeiden: gut, wenn ich es nicht schaffe: dann bleibt mir eben in diesem Falle nichts übrig als manuell dafür zu sorgen daß die entsprechende Userin da lesend zugreifen können soll.

 

Zu meiner Struktur die ich aufgezeigt habe:

da ist nichts großes anzumahnen? Ich gehe davon aus daß dies gemeint ist mit 'nicht Firmenorganigram abbilden sondern flache Strukturen, am Besten Projektorierentier anzubieten?

Ich habe jetzt Gruppenordner die flach sind und Projekt-Ordner denen man Firmenweit Mitgliedschaft vergeben kann.

Das ist in etwa so wie bei euch? Wenn das so für uns passt und umsetzbar ist, dann sind wir auch in einer modernen Struktur angekommen?

 

Nur noch zurück zum Thema 'Poweruser die die Gruppen selber verwalten':

Das die Tools an Board sind (was ich so nicht wusste) ist eine Sache. Das diese Poweruser IT-Tools nutzen dürfen ist eine ganz andere Sache.

Die sehen ja Domänenweit alle AD-Objekte (User, Sicherheitsgruppen, Computer) und können 'schindluder' damit treiben.

Dies kann unabsichtlich sein, aber auch absichtlich. Ihr seid sicher das ihr ausserhalb der IT jemanden solch ein Werkzeug anvertraut?

 

Ich bin mir immer noch nicht sicher ob wir vom gleichen reden?

.

.

.

Ok, ich habe es mir mal angeschaut und sehe das es nur eine Light-Version ist von der Verwaltung der AD.

Kann das eigentlich JEDER so sehen oder braucht er entsprechende Berechtigung? Welche wäre das?

Kann man da auch eingrenzen das ein Verantwortlicher nur in seinem Verantwortungsbereich, sprich nur in 'seinen AD-Sicherheitsgruppen' jegliche AD-User hinzufügen oder löschen kann?

 

 

Link zu diesem Kommentar
1 hour ago, kaineanung said:

Ich weiß das. Leider weiß das der Chef nicht.

Lass den Chef die Gruppen verwalten ;)

1 hour ago, kaineanung said:

Nur noch zurück zum Thema 'Poweruser die die Gruppen selber verwalten':

Das die Tools an Board sind (was ich so nicht wusste) ist eine Sache. Das diese Poweruser IT-Tools nutzen dürfen ist eine ganz andere Sache.

Die sehen ja Domänenweit alle AD-Objekte (User, Sicherheitsgruppen, Computer) und können 'schindluder' damit treiben.

Dies kann unabsichtlich sein, aber auch absichtlich. Ihr seid sicher das ihr ausserhalb der IT jemanden solch ein Werkzeug anvertraut?

Die User können natürlich nur die Objekte bearbeiten, auf die sie Rechte haben.

Link zu diesem Kommentar

Ich möchte mal auf mein Kommentar im folgenden Thread von Dir aufmerksam machen: (the golden rules of permission administration)

Da ging es doch m.M.n. Inhaltlich um das selbe Thema. 

 

 

 

EDIT:

vor 23 Stunden schrieb kaineanung:

Nochmals: wenn ich mit diesem Konzept auf dem Holzweg bin, dann bitte ich um neue und bessere Konzepte bzw. Meinungen. Ich weiß nur das eine Firmen-Orninagram auf der Fileserver nicht wünschenswert ist (so der Tenor hier und im anderen Forum).

Das würde ich so nicht sehen. Es spricht auch keiner von einem starren Organigramm.

 

Ich würde mich in die Sicht des Benutzers, der jeweiligen Abteilung, versetzen und ggf. mit den Benutzern reden. In der Regel benötigen sie einen "Workingspace" zum gemeinschaftlichen Arbeiten. Manchmal auch etwas abteilungsübergreifendes. So kann man ein gutes Gefühl bekommen, was denn wirklich benötigt wird und was daran vorbei geht. Wenn alle Informationen zusammengetragen sind, ist es leichter ein Konzept dafür zu erstellen.

Link zu diesem Kommentar

@kaineanung: Wie und was Du letztlich umsetzt ist allein Deine Sache - Du musst schließlich damit leben und arbeiten!

 

Was die Chefs angeht - nicht alles was technisch umsetzbar ist, ist auch sinnvoll. Das ist letztlich erhöhter Pflegeaufwand und benötigt deutlich mehr Verwaltungsarbeit. Das ist nicht einfach so daher gesagt - du wirst Spaß haben wenn Deine User dann aus dem speziell geschützten Verzeichnis Dateien eine Ebene höher ziehen oder in ein anderes Verzeichnis verschieben - da werden nämlich die NTFS Rechte mitgenommen. Stell Dich dann mal darauf ein, dass Du relativ regelmäßig die Rechte neu setzen darfst weil irgendwer auf einzelne Sachen nicht mehr zugreifen kann.

 

zu den AD Objekten - ja und ... meinetwegen sehen Sie unsere zig tausend Gruppen und OUs ... machen können Sie damit nix - sie können ja nur ihre eigene Gruppen verwalten (dafür gibt es ja den Haken) 

 

image.png.4597a886230d21eeaa5ac6e44426eb36.png

 

bearbeitet von Squire
Link zu diesem Kommentar
vor 9 Stunden schrieb kaineanung:

Die sehen ja Domänenweit alle AD-Objekte (User, Sicherheitsgruppen, Computer) und können 'schindluder' damit treiben.

Dies kann unabsichtlich sein, aber auch absichtlich. Ihr seid sicher das ihr ausserhalb der IT jemanden solch ein Werkzeug anvertraut?

 Warum sollte da jemand Schindluder treiben können? Wir haben ein Multimandaten-AD mit über 1000 Mandanten, die können da natürlich auch per dsa.msc/gpmc.msc zugreifen. Jeder sieht nur, was er sehen soll, und er kann nur ändern, was er ändern können soll.

Wenn ein Nicht-Admin Schreibzugriff auf AD-Objekte hat, dann habt ihr ganz am Anfang schon was falsch gemacht :-)

Link zu diesem Kommentar

@kaineanung

War denn schon was brauchbares für Dich dabei und konnte man Dir einige Missverständnisse aufzeigen? Wo brauchst du noch Unterstützung?

 

Ich hab nochmal über das Thema nachgedacht. Viele Netzlaufwerke von Firmen sind chaotisch aufgebaut, weil sie "gewachsen" sind. So wird das gerne genannt. Vielleicht auch als kleine Entschuldigung lange nichts unternommen zu haben. Auf den Standpunkte könnte man sich stellen. Auf den zweiten Blick aber zu undifferenziert. Nicht jede Firma hat die selben Anforderungen oder Bedürfnisse. Als Externer ist das immer schwierig zu bewerten. Auch starre Strukturen "leben" und sollten durch den Admin Stück für Stück weiterentwickelt werden.

 

Hier kann ich mich nur wieder selber Zitieren:

Zitat

Ich würde mich in die Sicht des Benutzers, der jeweiligen Abteilung, versetzen und ggf. mit den Benutzern reden. In der Regel benötigen sie einen "Workingspace" zum gemeinschaftlichen Arbeiten. Manchmal auch etwas abteilungsübergreifendes. So kann man ein gutes Gefühl bekommen, was denn wirklich benötigt wird und was daran vorbei geht. Wenn alle Informationen zusammengetragen sind, ist es leichter ein Konzept dafür zu erstellen.

 

Als kleinster gemeinsamer Nenner hat sich immer ein gemeinsamer Ordner für Abteilungen und ein Projektverzeichnis für Projekte als sinnvoll erwiesen. Letzteres hab ich bei uns z.B. automatisiert.

Link zu diesem Kommentar
vor 22 Stunden schrieb kaineanung:

Es ist so daß eine Userin irgendwas für die Chefs machen muss wo sie Informationen aus dem Unterordner benötigt wo nur die Chefs zugreifen können sollen.

 

Mein Gedanke eben: Beispielsweise auf den Ordner Chef bekommen Zugriff die Sicherheitsgruppen:

 

1. Chef_Full, Mitglied der Sicherheitsgruppe ist der User Chef

2. Helper_read_only, Mitglied wird bei Bedarf ein Gehilfe

bearbeitet von lefg
Link zu diesem Kommentar
Am 20.6.2020 um 10:05 schrieb MurdocX:

@kaineanung

War denn schon was brauchbares für Dich dabei und konnte man Dir einige Missverständnisse aufzeigen? Wo brauchst du noch Unterstützung?

 

Ich hab nochmal über das Thema nachgedacht. Viele Netzlaufwerke von Firmen sind chaotisch aufgebaut, weil sie "gewachsen" sind. So wird das gerne genannt. Vielleicht auch als kleine Entschuldigung lange nichts unternommen zu haben. Auf den Standpunkte könnte man sich stellen. Auf den zweiten Blick aber zu undifferenziert. Nicht jede Firma hat die selben Anforderungen oder Bedürfnisse. Als Externer ist das immer schwierig zu bewerten. Auch starre Strukturen "leben" und sollten durch den Admin Stück für Stück weiterentwickelt werden.

 

Hier kann ich mich nur wieder selber Zitieren:

 

Als kleinster gemeinsamer Nenner hat sich immer ein gemeinsamer Ordner für Abteilungen und ein Projektverzeichnis für Projekte als sinnvoll erwiesen. Letzteres hab ich bei uns z.B. automatisiert.

 

Ich bin mir nicht sicher ob ich das Alles jetzt auch komplett 'erfasst' habe. Wenn ja: ich denke ich weiß was zu tun ist.

Wenn nein, kann ich die Frage erst stellen wenn es klar wird das ich noch irgendwas nicht bedacht hatte oder neue Probleme auftauchen.

Momentan werde ich in unserer Testumgebung die 'fast finale' Sturktur erstellen und der Geschäftführung vorführen damit die dann entscheiden wohin wir wollen.

 

Ich würde es wie im Eingagpost umsetzen:

 

root

|

-- Ungesichert

|

-- T2 (das ist bei uns der Verkauf)
   |

   -- Mgmt (Der 'Arbeitsordner des Teamleiters T2)

   |

   -- T2K1 ('Arbeitsordner' der Koorinators 1 des Teams 2)

   |

   -- T2K2 ('Arbeitsordner' der Koorinators 2 des Teams 2)

   |

   -- T201GL (Gruppenleiterordner der Gruppe 201

   |

   -- T201 (Gruppenordner der Gruppe 201)

   |

   -- T202GL

   |

   -- T202

   |

   -- usw.

|

-- T3

|

-- usw.

|

-- Projekte

   |

   -- 3D Druck

   |

   -- Projekt X

   |

   -- Gesundheitskreis

   |

   -- usw.

 

Auf den Gruppen und Teamorndern gibt es lediglich eine AD-Sicherheitgruppe und die ist mit Änderungrechte ausgestattet. (Die Gruppenordner haben keine 'Read Only User).

Auf dem 'ungesichert'-Ordner kann man Daten austauschen die in keine andere Kategorie fallen. Wird nicht gesichert und jeder Domänen-User hat Änderungs-Berechtigung.

Der Ordner 'Projekte' hat erstmal 'nur Ordner-Auflisten' Berechtigung für alle Domänen-User. Darunter dann die einzelnen Projekte auf die 2 AD-Sicherheitsgruppen vergeben werden. Ein 'rw-acces' und ein 'ro-access'. Jenachdem wer was machen darf landet in der entsprechenden Gruppe. Ist man in keiner der Gruppe, so wird das Projekt gar nicht aufgelistet.

Ist ein Benutzer also in keinem einzigen Projekt enthalten, so bleibt für ihn der Ordner 'Projekte' leer.

 

Und die allergrößte Änderung die ich im Vergleich zu heute hätte:

Nicht jeder User bekommt aufgrund seiner Gruppenzugehörigkeit ein Laufwerk gemappt direkt in sein Gruppenordner, sondern jeder bekommt ein Laufwerksmapping direkt in root rein und darf sich dann durchklicken bis zu seinen Ordnern. Da es ja nicht mehr 7 Ebenen gibt sondern 2 ist das vertretbar.

 

Momentan hätten wir ein I-Laufwerk das in das 'ungesichert'-Ordner verknüpft für alle Domänen-User. Dann haben wir ein F-Laufwerk welches in die einzelnen Gruppen mappt. Somit steht dann hinter F: -> \\fileserver\root$\T2\T2K1\T201GL\T201 (oder auch \\fileserver\T201$ da wir Shares auf die einzelnen Gruppenordnern haben -> sehr viele Shares da viele Gruppen).

Bei neuer Struktur würde f: dann wie folgt aussehen: \\fileserver\root$ und zwar für jeden.

(root$ heisst es nicht wirklich, will es aber damit nur verdeutlichen. Heissen tut es Firmenname$)

 

 

So, ist heir irgendwas unlogisches dabei? Habe ich das auch mit dem Laufwerksmapping so richtig verstanden und richtig umgesetzt?

ich weiß das 'richtig' relativ ist unv von Anforderung zu Anforderung anders ist und von Vorlibe zu Vorliebe anders. Aber so grob in etwa ist es so wie ihr das meistens auch umgesetzt habt?

Link zu diesem Kommentar

zwei Dinge ...

 

zum Ungesichert Ordner ... so was in der Art haben wir auch (mit vorgegebenen Abteilungskürzelverzeichnissen). Aber - der Ordner und die Struktur wird JEDE Nacht gelöscht und neu erstellt. Sonst bekommt man in kürzester Zeit ein nicht mehr aufzulösendes Datengrab.

 

zweitens würde ich auf einen DFS namespace gehen und weg von den Laufwerksbuchstaben oder \\server\freigabe ... mit DFS kannst Du später auf einen oder anderen Server migrieren, wenn es denn nötig ist ... Spart viel Arbeit und Mühe!

Link zu diesem Kommentar
vor 19 Minuten schrieb Squire:

zwei Dinge ...

 

zum Ungesichert Ordner ... so was in der Art haben wir auch (mit vorgegebenen Abteilungskürzelverzeichnissen). Aber - der Ordner und die Struktur wird JEDE Nacht gelöscht und neu erstellt. Sonst bekommt man in kürzester Zeit ein nicht mehr aufzulösendes Datengrab.

 

zweitens würde ich auf einen DFS namespace gehen und weg von den Laufwerksbuchstaben oder \\server\freigabe ... mit DFS kannst Du später auf einen oder anderen Server migrieren, wenn es denn nötig ist ... Spart viel Arbeit und Mühe!

 

Gute Idee mit dem regelmäßigem Löschen. Werde ich mal vorschlagen. Und wenn es nicht jeden Tag ist dann jedes WE oder im schlimmsten Fall an jedem Monatsanfang.

 

Was das mit der DFS statt Laufwerksbuchstaben oder Shares angeht: wie sieht das dann aus? Wo findet man im Windows-Explorer dann seine Daten? Wo sind die gespeichert und wie wird das gesichert?

 

(Zur Sicherung: da alles auf VMware läuft, ist es bei uns Veeam mit wem wir unsere Daten sichern werden.)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...