23
Prüfung des Berechtigungskonzepts
Guten Morgen zusammen,
ich habe derzeit die Aufgabe zu prüfen, wie uns Berechtigungskonzept im Unternehmen gestaltet ist.
Wir arbeiten mit dem AD von Microsoft, sodass es sich ja anbieten würde, nach dem AGDLP-Prinzip zu arbeiten.
An sich ist das Prinzip ja echt genial, aber ich finde, dass es punktuelle Schwächen hat, die meiner Meinung nach genau dann entstehen, wenn einzelne Mitarbeiter auf einzelne Ressourcen zugreifen müssen, unabhängig von der Zugehörigkeit zu einer Abteilung oder einer Arbeitsgruppe.
Bezogen auf das Bild: Die Ulla muss auf die CRM-Datenbank zugreifen. Woher weiß der Admin in dem Fall, in welche Global Group die Ulla reingeschoben werden muss? Und selbst wenn Ulla temporär in G-Vertrieb geschoben wird, erhält sie zusätzlich noch andere Berechtigungen, die ggf. kritisch sind (hier auf den Drucker, was bis auf die Redundanz egal ist. Ist Redundanz im Berechtigungskonzept eigentlich problematisch? Hab mal gelesen, dass Accounts nur in einer gewissen Anzahl von Gruppen Mitglied werden können).
Das Problem ergibt sich analog bei neuen Mitarbeitern, die Zugriff auf einzelne Ressourcen brauchen.
Bei mir im Unternehmen ist es jetzt aber so, dass wir grundsätzlich nach dem AGDLP-Prinzip arbeiten, dieses jedoch irgendwie anders implementiert haben. Das ist ja grundsätzlich erstmal nicht schlecht, da AGDLP ja nur eine Vorgabe/Richtlinie ist und man das Prinzip den Strukturen im Unternehmen anpassen muss.
Unsere Gruppen orientieren sich nicht an Abteilungen oder Berechtigungen, sondern sind irgendwie ein Gemisch aus Allem bzw. geben im Namen an, für welche Ressource sie gelten.
Beispiel 1:
Accounts => G-CRM-schreiben => DL-CRM-schreiben => CRM-Datenbank. Dabei wird die Domain-Local Group nur der einen Ressource zugeordnet, also wie oben.
Der Sinn dahinter ist, dass es für die Admins effizienter ist, neue, 'einzelne' Berechtigungen (losgelöst von Abteilungs- oder Arbeitsgruppenzugehörigkeit) zu verteilen oder zu entziehen. Der Admin kann sich hierbei an den Namen der Global Groups orientieren und Accounts so ganz einfach zuordnen.
Jetzt ist es bei uns aber auch so, dass mehrere Accounts nach Abteilungen zusammengefasst werden und dann die entsprechende Domain-Local Group auf mehrere Ressourcen zeigt.
Beispiel 2:
Accounts => G-Abteilung A-schreiben => DL-Abteilung A-schreiben => CRM-Datenbank und Projekt1-xlsx. Die Domain-Local Group wird also mehreren Ressourcen zugeordnet.
Wie gesagt, für die Admins ist dieses von uns praktizierte Prinzip echt gut und ich kann das soweit auch nachvollziehen.
Allerdings überlege ich, ob das so irgendwelche Probleme für die Sicherheit oder Performance geben könnte. Beispielsweise weiß man mit der Zeit nicht, auf welche Ressourcen die Gruppe DL-Abteilung A-schreiben aus Beispiel 2 hinzeigt und sich so zahlreiche, nicht mehr benötigte Berechtigungen für eine Gruppe von Accounts ergeben können. Analog ergibt es sich auch mit einzelnen Accounts, die in mehreren Global Groups zu einzelnen Ressourcen zugeordnet sind (Beispiel 1).
ich habe derzeit die Aufgabe zu prüfen, wie uns Berechtigungskonzept im Unternehmen gestaltet ist.
Wir arbeiten mit dem AD von Microsoft, sodass es sich ja anbieten würde, nach dem AGDLP-Prinzip zu arbeiten.
An sich ist das Prinzip ja echt genial, aber ich finde, dass es punktuelle Schwächen hat, die meiner Meinung nach genau dann entstehen, wenn einzelne Mitarbeiter auf einzelne Ressourcen zugreifen müssen, unabhängig von der Zugehörigkeit zu einer Abteilung oder einer Arbeitsgruppe.
Bezogen auf das Bild: Die Ulla muss auf die CRM-Datenbank zugreifen. Woher weiß der Admin in dem Fall, in welche Global Group die Ulla reingeschoben werden muss? Und selbst wenn Ulla temporär in G-Vertrieb geschoben wird, erhält sie zusätzlich noch andere Berechtigungen, die ggf. kritisch sind (hier auf den Drucker, was bis auf die Redundanz egal ist. Ist Redundanz im Berechtigungskonzept eigentlich problematisch? Hab mal gelesen, dass Accounts nur in einer gewissen Anzahl von Gruppen Mitglied werden können).
Das Problem ergibt sich analog bei neuen Mitarbeitern, die Zugriff auf einzelne Ressourcen brauchen.
Bei mir im Unternehmen ist es jetzt aber so, dass wir grundsätzlich nach dem AGDLP-Prinzip arbeiten, dieses jedoch irgendwie anders implementiert haben. Das ist ja grundsätzlich erstmal nicht schlecht, da AGDLP ja nur eine Vorgabe/Richtlinie ist und man das Prinzip den Strukturen im Unternehmen anpassen muss.
Unsere Gruppen orientieren sich nicht an Abteilungen oder Berechtigungen, sondern sind irgendwie ein Gemisch aus Allem bzw. geben im Namen an, für welche Ressource sie gelten.
Beispiel 1:
Accounts => G-CRM-schreiben => DL-CRM-schreiben => CRM-Datenbank. Dabei wird die Domain-Local Group nur der einen Ressource zugeordnet, also wie oben.
Der Sinn dahinter ist, dass es für die Admins effizienter ist, neue, 'einzelne' Berechtigungen (losgelöst von Abteilungs- oder Arbeitsgruppenzugehörigkeit) zu verteilen oder zu entziehen. Der Admin kann sich hierbei an den Namen der Global Groups orientieren und Accounts so ganz einfach zuordnen.
Jetzt ist es bei uns aber auch so, dass mehrere Accounts nach Abteilungen zusammengefasst werden und dann die entsprechende Domain-Local Group auf mehrere Ressourcen zeigt.
Beispiel 2:
Accounts => G-Abteilung A-schreiben => DL-Abteilung A-schreiben => CRM-Datenbank und Projekt1-xlsx. Die Domain-Local Group wird also mehreren Ressourcen zugeordnet.
Wie gesagt, für die Admins ist dieses von uns praktizierte Prinzip echt gut und ich kann das soweit auch nachvollziehen.
Allerdings überlege ich, ob das so irgendwelche Probleme für die Sicherheit oder Performance geben könnte. Beispielsweise weiß man mit der Zeit nicht, auf welche Ressourcen die Gruppe DL-Abteilung A-schreiben aus Beispiel 2 hinzeigt und sich so zahlreiche, nicht mehr benötigte Berechtigungen für eine Gruppe von Accounts ergeben können. Analog ergibt es sich auch mit einzelnen Accounts, die in mehreren Global Groups zu einzelnen Ressourcen zugeordnet sind (Beispiel 1).
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 419285
Url: https://administrator.de/contentid/419285
Printed on: April 20, 2024 at 13:04 o'clock
23 Comments
Latest comment
Ich würde trotzdem strikt bei dem AGDLP System bleiben.
Wenn ein einzelner Nutzer Sonderrechte braucht dann mache ich den trotzdem nicht in eine Domänenlokale Gruppe sondern erstelle für diesen dann eine Globale Gruppe über die er dann die Sonderrechte erhält.
Quasi wie eine Arbeitsgruppe für nur einen User.
Diese kannst du ja dann auch aussagekräftig benennen wie z.B. G-Sonderrechte_Drucker1
Damit machst du es auch anderen Administratoren leichter wenn diese darauf vertrauen können, das strikt nach AGDLP gearbeitet wird und sie nicht damit rechen müssen in einer Domänenlokalen Gruppe plötzlich einen User zu finden statt einer globalen Gruppe.
Wenn ein einzelner Nutzer Sonderrechte braucht dann mache ich den trotzdem nicht in eine Domänenlokale Gruppe sondern erstelle für diesen dann eine Globale Gruppe über die er dann die Sonderrechte erhält.
Quasi wie eine Arbeitsgruppe für nur einen User.
Diese kannst du ja dann auch aussagekräftig benennen wie z.B. G-Sonderrechte_Drucker1
Damit machst du es auch anderen Administratoren leichter wenn diese darauf vertrauen können, das strikt nach AGDLP gearbeitet wird und sie nicht damit rechen müssen in einer Domänenlokalen Gruppe plötzlich einen User zu finden statt einer globalen Gruppe.
1
Moin,
Auf jeden Fall.
Und dann noch die Globale Gruppe in die entsprechenden anderen Globalen Gruppen aufnehmen, aus denen er die "normalen" Rechte erhält. Ich versuche immer, dass jeder User nur in einer Globalen Gruppe ist. Das macht es einfacher, wenn man neue User bekommt.
hth
Erik
Auf jeden Fall.
Wenn ein einzelner Nutzer Sonderrechte braucht dann mache ich den trotzdem nicht in eine Domänenlokale Gruppe sondern erstelle für diesen dann eine Globale Gruppe über die er dann die Sonderrechte erhält.
Quasi wie eine Arbeitsgruppe für nur einen User.
Diese kannst du ja dann auch aussagekräftig benennen wie z.B. G-Sonderrechte_Drucker1
Quasi wie eine Arbeitsgruppe für nur einen User.
Diese kannst du ja dann auch aussagekräftig benennen wie z.B. G-Sonderrechte_Drucker1
Und dann noch die Globale Gruppe in die entsprechenden anderen Globalen Gruppen aufnehmen, aus denen er die "normalen" Rechte erhält. Ich versuche immer, dass jeder User nur in einer Globalen Gruppe ist. Das macht es einfacher, wenn man neue User bekommt.
hth
Erik
1
Danke für eure Antworten 
Also bei uns werden, sofern es richtig läuft, keine Accounts in Domain-local Groups eingefügt. Die Accounts kommen nur in die Global Groups rein, wobei meiner Meinung nach die Nameskonvention nicht zu 100% stimmt.
Aber ist dieses Vorgehen nicht auch aufwändig? Das sind dann nach meinem Verständnis so verschachtelte Global Groups, wobei Accounts nur auf der untersten Stufe hinzugefügt werden. Wenn einem Benutzer jetzt die Rechte entzogen werden (z.B. auf G-Sonderrechte_Drucker1) dann verschwindet er doch auch automatisch aus den höheren Global Groups und verliert damit all seine Berechtigungen.
Zitat von @Bem0815:
Damit machst du es auch anderen Administratoren leichter wenn diese darauf vertrauen können, das strikt nach AGDLP gearbeitet wird und sie nicht damit rechen müssen in einer Domänenlokalen Gruppe plötzlich einen User zu finden statt einer globalen Gruppe.
Damit machst du es auch anderen Administratoren leichter wenn diese darauf vertrauen können, das strikt nach AGDLP gearbeitet wird und sie nicht damit rechen müssen in einer Domänenlokalen Gruppe plötzlich einen User zu finden statt einer globalen Gruppe.
Also bei uns werden, sofern es richtig läuft, keine Accounts in Domain-local Groups eingefügt. Die Accounts kommen nur in die Global Groups rein, wobei meiner Meinung nach die Nameskonvention nicht zu 100% stimmt.
Zitat von @erikro:
Und dann noch die Globale Gruppe in die entsprechenden anderen Globalen Gruppen aufnehmen, aus denen er die "normalen" Rechte erhält. Ich versuche immer, dass jeder User nur in einer Globalen Gruppe ist. Das macht es einfacher, wenn man neue User bekommt.
Und dann noch die Globale Gruppe in die entsprechenden anderen Globalen Gruppen aufnehmen, aus denen er die "normalen" Rechte erhält. Ich versuche immer, dass jeder User nur in einer Globalen Gruppe ist. Das macht es einfacher, wenn man neue User bekommt.
Aber ist dieses Vorgehen nicht auch aufwändig? Das sind dann nach meinem Verständnis so verschachtelte Global Groups, wobei Accounts nur auf der untersten Stufe hinzugefügt werden. Wenn einem Benutzer jetzt die Rechte entzogen werden (z.B. auf G-Sonderrechte_Drucker1) dann verschwindet er doch auch automatisch aus den höheren Global Groups und verliert damit all seine Berechtigungen.
Moin,
Gerne.
Aber ist dieses Vorgehen nicht auch aufwändig? Das sind dann nach meinem Verständnis so verschachtelte Global Groups, wobei Accounts nur auf der untersten Stufe hinzugefügt werden. Wenn einem Benutzer jetzt die Rechte entzogen werden (z.B. auf G-Sonderrechte_Drucker1) dann verschwindet er doch auch automatisch aus den höheren Global Groups und verliert damit all seine Berechtigungen.
Ja, der Aufwand ist am Anfang sehr hoch, da man eine Menge Hirnschmalz auf die Struktur verwenden muss, um das zu erreichen, was man erreichen will. Aber im täglichen Geschäft ist es dann viel einfacher.
Wenn nun einer Usergruppe das Recht entzogen werden soll, dann wird die globale Gruppe aus der lokalen oder der anderen globalen Gruppe entfernt, aus denen diese Gruppe das Recht erbt (wobei eine globale Gruppe evtl. nur ein Mitglied hat). Damit verliert die Gruppe keineswegs die Rechte, die sie aus anderen Gruppen erbt. Nehmen wir mal Dein Beispiel:
Es gibt eine lokale Gruppe l_rw_Drucker1. Diese lokale Gruppe hat das Recht auf dem Drucker 1 zu drucken.
Es gibt eine globale Gruppe g_verwaltung. Diese Gruppe ist in der lokalen Gruppe l_rw_Drucker1, da dies ihr Standarddrucker ist und alle aus dieser globalen Gruppe drucken können müssen.
Es gibt eine globale Gruppe g_Nachbarbuero_verwaltung (wie auch immer
). Diese globale Gruppe ist in diversen anderen lokalen und globalen Gruppen, aus denen sie Zugriffsrechte erbt. Daran rühre ich nicht.
Jetzt geht der Drucker im Nachbarbüro der Verwaltung kaputt und die Kolleginnen und Kollegen sollen als Notlösung ein paar Tage auf dem Drucker des Nachbarbüros drucken. Also nehme ich einfach die globale Gruppe in die entsprechende lokale auf und gut ist. Wenn der neue Drucker geliefert wurde, dann entferne ich die Gruppe einfach wieder aus der lokalen.
Ein anderes Beispiel aus der Praxis, das ein wenig komplizierter ist:
Es gibt zwei Abteilungen. Für jede Abteilung gibt es einen Ordner, in dem alle aus dieser Abteilung schreiben dürfen. Also habe ich zwei lokale Gruppen, denen die Rechte erteilt werden, und zwei globale Gruppen für die Mitarbeiter der Abteilungen.
Nun haben die beiden Abteilungen jeweils auch eine Abteilungsleitung. Diese Abteilungsleitungen haben jeweils wieder einen Ordner für sich. Also wieder jeweils eine lokale Gruppe für die Rechtevergabe und zwei globale Gruppen, die Mitglieder dieser beiden lokalen sind. Diese beiden globalen Gruppen sind aber auch gleichzeitig Mitglieder der beiden globalen Gruppen der jeweiligen Abteilung, so dass sie alle Rechte erhalten, die auch ein normales Mitglied er Abteilung erhält.
Dann gibt es noch einen gemeinsamen Ordner für die beiden Abteilungsleitungen. Also wieder eine lokale Gruppe und in die kommen die beiden Abteilungsleitungsgruppen.
Nun haben wir noch die Einrichtungsleitung, die natürlich auf alles Zugriff will und auch bekommt. Also ein globale Gruppe für die Leitung, die Mitglied in beiden Abteilungsleitungsgruppen wird, was dazu führt, dass die Rechte aus dieser Gruppe vererbt werden, die diese Gruppe aus anderen Gruppen erbt usw.
So sieht das bei uns aus. Das geht evtl. noch eins, zwei Ebenen tiefer.
Liebe Grüße
Erik
Gerne.
Zitat von @erikro:
Und dann noch die Globale Gruppe in die entsprechenden anderen Globalen Gruppen aufnehmen, aus denen er die "normalen" Rechte erhält. Ich versuche immer, dass jeder User nur in einer Globalen Gruppe ist. Das macht es einfacher, wenn man neue User bekommt.
Und dann noch die Globale Gruppe in die entsprechenden anderen Globalen Gruppen aufnehmen, aus denen er die "normalen" Rechte erhält. Ich versuche immer, dass jeder User nur in einer Globalen Gruppe ist. Das macht es einfacher, wenn man neue User bekommt.
Aber ist dieses Vorgehen nicht auch aufwändig? Das sind dann nach meinem Verständnis so verschachtelte Global Groups, wobei Accounts nur auf der untersten Stufe hinzugefügt werden. Wenn einem Benutzer jetzt die Rechte entzogen werden (z.B. auf G-Sonderrechte_Drucker1) dann verschwindet er doch auch automatisch aus den höheren Global Groups und verliert damit all seine Berechtigungen.
Ja, der Aufwand ist am Anfang sehr hoch, da man eine Menge Hirnschmalz auf die Struktur verwenden muss, um das zu erreichen, was man erreichen will. Aber im täglichen Geschäft ist es dann viel einfacher.
Wenn nun einer Usergruppe das Recht entzogen werden soll, dann wird die globale Gruppe aus der lokalen oder der anderen globalen Gruppe entfernt, aus denen diese Gruppe das Recht erbt (wobei eine globale Gruppe evtl. nur ein Mitglied hat). Damit verliert die Gruppe keineswegs die Rechte, die sie aus anderen Gruppen erbt. Nehmen wir mal Dein Beispiel:
Es gibt eine lokale Gruppe l_rw_Drucker1. Diese lokale Gruppe hat das Recht auf dem Drucker 1 zu drucken.
Es gibt eine globale Gruppe g_verwaltung. Diese Gruppe ist in der lokalen Gruppe l_rw_Drucker1, da dies ihr Standarddrucker ist und alle aus dieser globalen Gruppe drucken können müssen.
Es gibt eine globale Gruppe g_Nachbarbuero_verwaltung (wie auch immer
). Diese globale Gruppe ist in diversen anderen lokalen und globalen Gruppen, aus denen sie Zugriffsrechte erbt. Daran rühre ich nicht.Jetzt geht der Drucker im Nachbarbüro der Verwaltung kaputt und die Kolleginnen und Kollegen sollen als Notlösung ein paar Tage auf dem Drucker des Nachbarbüros drucken. Also nehme ich einfach die globale Gruppe in die entsprechende lokale auf und gut ist. Wenn der neue Drucker geliefert wurde, dann entferne ich die Gruppe einfach wieder aus der lokalen.
Ein anderes Beispiel aus der Praxis, das ein wenig komplizierter ist:
Es gibt zwei Abteilungen. Für jede Abteilung gibt es einen Ordner, in dem alle aus dieser Abteilung schreiben dürfen. Also habe ich zwei lokale Gruppen, denen die Rechte erteilt werden, und zwei globale Gruppen für die Mitarbeiter der Abteilungen.
Nun haben die beiden Abteilungen jeweils auch eine Abteilungsleitung. Diese Abteilungsleitungen haben jeweils wieder einen Ordner für sich. Also wieder jeweils eine lokale Gruppe für die Rechtevergabe und zwei globale Gruppen, die Mitglieder dieser beiden lokalen sind. Diese beiden globalen Gruppen sind aber auch gleichzeitig Mitglieder der beiden globalen Gruppen der jeweiligen Abteilung, so dass sie alle Rechte erhalten, die auch ein normales Mitglied er Abteilung erhält.
Dann gibt es noch einen gemeinsamen Ordner für die beiden Abteilungsleitungen. Also wieder eine lokale Gruppe und in die kommen die beiden Abteilungsleitungsgruppen.
Nun haben wir noch die Einrichtungsleitung, die natürlich auf alles Zugriff will und auch bekommt. Also ein globale Gruppe für die Leitung, die Mitglied in beiden Abteilungsleitungsgruppen wird, was dazu führt, dass die Rechte aus dieser Gruppe vererbt werden, die diese Gruppe aus anderen Gruppen erbt usw.
l_rw_Abteilung
X:\data\data (Pfad, auf den Zugriff gewährt wird)
g_abteilung (globale Gruppe mit direkter Mitgliedschaft)
user1
user2
g_verwaltung (Mitglied der übergeordneten globalen Gruppe g_abteilung)
user3
user4
g_leitung (Mitglied der übergeordneten Gruppe g_verwaltung)
chef1
chef2So sieht das bei uns aus. Das geht evtl. noch eins, zwei Ebenen tiefer.
Liebe Grüße
Erik
1Zitat von @erikro:
Es gibt eine lokale Gruppe l_rw_Drucker1. Diese lokale Gruppe hat das Recht auf dem Drucker 1 zu drucken.
Es gibt eine globale Gruppe g_verwaltung. Diese Gruppe ist in der lokalen Gruppe l_rw_Drucker1, da dies ihr Standarddrucker ist und alle aus dieser globalen Gruppe drucken können müssen.
Es gibt eine globale Gruppe g_Nachbarbuero_verwaltung (wie auch immer ). Diese globale Gruppe ist in diversen anderen lokalen und globalen Gruppen, aus denen sie Zugriffsrechte erbt. Daran rühre ich nicht.
Jetzt geht der Drucker im Nachbarbüro der Verwaltung kaputt und die Kolleginnen und Kollegen sollen als Notlösung ein paar Tage auf dem Drucker des Nachbarbüros drucken. Also nehme ich einfach die globale Gruppe in die entsprechende lokale auf und gut ist. Wenn der neue Drucker geliefert wurde, dann entferne ich die Gruppe einfach wieder aus der lokalen.
Es gibt eine lokale Gruppe l_rw_Drucker1. Diese lokale Gruppe hat das Recht auf dem Drucker 1 zu drucken.
Es gibt eine globale Gruppe g_verwaltung. Diese Gruppe ist in der lokalen Gruppe l_rw_Drucker1, da dies ihr Standarddrucker ist und alle aus dieser globalen Gruppe drucken können müssen.
Es gibt eine globale Gruppe g_Nachbarbuero_verwaltung (wie auch immer
). Diese globale Gruppe ist in diversen anderen lokalen und globalen Gruppen, aus denen sie Zugriffsrechte erbt. Daran rühre ich nicht.Jetzt geht der Drucker im Nachbarbüro der Verwaltung kaputt und die Kolleginnen und Kollegen sollen als Notlösung ein paar Tage auf dem Drucker des Nachbarbüros drucken. Also nehme ich einfach die globale Gruppe in die entsprechende lokale auf und gut ist. Wenn der neue Drucker geliefert wurde, dann entferne ich die Gruppe einfach wieder aus der lokalen.
Dieses Beispiel ist echt gut
Danke Das ist sehr praktikabel, wenn eine gesamte Gruppe von Leuten (G_Nachbarbüro_Verwaltung) die selben Rechte bekommen soll. Wenn jetzt aber beispielsweise einer der Mitarbeiter aus welchem Grund auch immer NICHT auf dem Drucker in der Verwaltung drucken darf, aber sonst alle Rechte behalten soll, dann muss der entsprechende Mitarbeiter aus G_Nachbarbüro_Verwaltung entfernt werden (G_Nachbarbüro_Verwaltung wurde ja zu L_RW_Drucker1 hinzugefügt). Aber dadurch verliert er auch alle anderen Berechtigungen, da er nicht mehr in G_Nachbarbüro_Verwaltung drin ist. Würde dann dieses unten von dir beschriebene Verfahren mit der Vererbung Abhilfe schaffen?
Ich glaub bei solche Sonderfällen muss man echt genau überlegen was man tut...
Ein anderes Beispiel aus der Praxis, das ein wenig komplizierter ist:
Es gibt zwei Abteilungen. Für jede Abteilung gibt es einen Ordner, in dem alle aus dieser Abteilung schreiben dürfen. Also habe ich zwei lokale Gruppen, denen die Rechte erteilt werden, und zwei globale Gruppen für die Mitarbeiter der Abteilungen.
Nun haben die beiden Abteilungen jeweils auch eine Abteilungsleitung. Diese Abteilungsleitungen haben jeweils wieder einen Ordner für sich. Also wieder jeweils eine lokale Gruppe für die Rechtevergabe und zwei globale Gruppen, die Mitglieder dieser beiden lokalen sind. Diese beiden globalen Gruppen sind aber auch gleichzeitig Mitglieder der beiden globalen Gruppen der jeweiligen Abteilung, so dass sie alle Rechte erhalten, die auch ein normales Mitglied er Abteilung erhält.
So in etwa ist das bei uns auch. Das würde bedeuten, auf dein Beispiel bezogen, dass die beiden Abteilungsleiter NICHT Mitglied in den globalen Gruppen der Mitarbeiter sind (zB: G_Abteilung A_alle), richtig? Und dadurch dass die globale Gruppe der Leitung (zB: G_Abteilung A_Leitung) Mitglied in G_Abteilung A_alle ist, bekommt die Leitung die selben Rechte, kann aber flexibler zu anderen lokalen Gruppen zugeordnet werden.
Also würde das so aussehen:
Leitung => G_Abteilung A_Leitung => G_Abteilung A_alle => L_Abteilung A_schreiben
und
Leitung => G_Abteilung A_Leitung => L_Abteilung A_Leitung_schreiben
Dann gibt es noch einen gemeinsamen Ordner für die beiden Abteilungsleitungen. Also wieder eine lokale Gruppe und in die kommen die beiden Abteilungsleitungsgruppen.
Leitung A => G_Abteilung A_Leitung => L_Abteilung AundB_Leitung_schreiben
und
Leitung B => G_Abteilung B_Leitung => L_Abteilung AundB_Leitung_schreiben
ist so richtig oder?
Man kann also die globalen Gruppen in der untersten Stufe also auch flexibel zu anderen lokalen Gruppen hinzufügen. Ich hab irgendwie gedacht, dass die fest mit anderen globalen Gruppen verankert sind :D
Danke für die Erleuchtung
Zitat von @Sheldor:
Dieses Beispiel ist echt gut Danke
Das ist sehr praktikabel, wenn eine gesamte Gruppe von Leuten (G_Nachbarbüro_Verwaltung) die selben Rechte bekommen soll. Wenn jetzt aber beispielsweise einer der Mitarbeiter aus welchem Grund auch immer NICHT auf dem Drucker in der Verwaltung drucken darf, aber sonst alle Rechte behalten soll, dann muss der entsprechende Mitarbeiter aus G_Nachbarbüro_Verwaltung entfernt werden (G_Nachbarbüro_Verwaltung wurde ja zu L_RW_Drucker1 hinzugefügt). Aber dadurch verliert er auch alle anderen Berechtigungen, da er nicht mehr in G_Nachbarbüro_Verwaltung drin ist. Würde dann dieses unten von dir beschriebene Verfahren mit der Vererbung Abhilfe schaffen?
Ich glaub bei solche Sonderfällen muss man echt genau überlegen was man tut...
Dieses Beispiel ist echt gut
Danke Das ist sehr praktikabel, wenn eine gesamte Gruppe von Leuten (G_Nachbarbüro_Verwaltung) die selben Rechte bekommen soll. Wenn jetzt aber beispielsweise einer der Mitarbeiter aus welchem Grund auch immer NICHT auf dem Drucker in der Verwaltung drucken darf, aber sonst alle Rechte behalten soll, dann muss der entsprechende Mitarbeiter aus G_Nachbarbüro_Verwaltung entfernt werden (G_Nachbarbüro_Verwaltung wurde ja zu L_RW_Drucker1 hinzugefügt). Aber dadurch verliert er auch alle anderen Berechtigungen, da er nicht mehr in G_Nachbarbüro_Verwaltung drin ist. Würde dann dieses unten von dir beschriebene Verfahren mit der Vererbung Abhilfe schaffen?
Ich glaub bei solche Sonderfällen muss man echt genau überlegen was man tut...
Bei solchen Sonderfällen bei denen eine oder mehrere Personen explizit Berechtigungen nicht erhalten sollen, die sie aber typischerweise in ihrer Abteilung erhalten würden gibt es noch ein tolles Feature bei NTFS Berechtigungen. Nämlich das "Verweigern".
Verweigern wiegt immer stärker als ein Erlauben.
Sollte also über eine Gruppe einem User eine Erlaubnis vorliegen und über eine andere Gruppe ein Verweigern wiegt wie gesagt das Verweigern Recht stärker und dem User bzw. der Gruppe wird das Recht auch verweigert.
Du kannst also hier dann um AGDLP einzuhalten eine Globale Gruppe G-Druckverbot-auf-Drucker1 machen, diese ist Bestandteil der Domänenlokalen Gruppe DL-Drucker1-Druckverbot und dieser ist per Berechtigung das drucken auf Drucker 1 verweigert.
Gruppennamen sind jetzt nur Beispiele. Aber du kannst auf diese Weise auch Berechtigungen wieder verringern.
Hier noch ein anderes Beispiel in dem man das anwenden kann.
Es gibt in Firma x unter anderem die Abteilungen Vertrieb und Marketing.
In beiden Abteilungen gibt es Azubis, diese sollen nicht selbst drucken dürfen sondern müssen ihre fertigen Dateien erst Korrekturlesen lassen und ein anderer Mitarbeiter druckt das dann für die Azubis.
Die Azubis sind jeweils Teil ihrer Globalen Gruppe für die Abteilung.
Also G-Marketing und G-Vertrieb. Marketing greift auf DL Gruppe DL-Drucker1 zu, Vertrieb auf die DL-Drucker2
Weiterhin sind die Azubis alle Teil der Globalen Gruppe G-Azubis welche Teil der DL Gruppe DL-Druckverweigern ist und diese einen Druck auf jeglichen Druckern verweigert.
Solltest du deine User jeweils nur gerne in einer Globalen Gruppe haben wollen müsstest du das stattdessen wie folgt machen:
Azubi Marketing ist in der Gruppe G-Marketing_Azubi diese ist Teil der Gruppen G-Marketing und DL-Druckverweigern
Azubi Vertrieb ist in der Gruppe G-Vertrieb_Azubi diese ist Teil der Gruppen G-Vertrieb und DL-Druckverweigern
1
Moin,
Gerne.
Sonderfälle heißen deshalb Sonderfälle, weil sie nicht ins Schema passen. Das Ziel ist, nur eine Gruppe pro User. Manchmal kann man dieses Ziel aber nicht erreichen, weil es ein Sonderfall ist, den man zwar auch so einrichten könnte, es aber nicht praktikabel ist. Dann muss ich entweder eine zweite Gruppenmitgliedschaft hinnehmen oder zur allerhöchsten Not direkt für den User Rechte definieren und sie evtl., wie Bem0815 schon sagte, verweigern.
Richtig. Ziel: Nur eine Gruppe/User. Woran man sich gewöhnen muss, ist, dass die, die in der Hierarchie oben stehen, in der Gruppenstruktur unten angesiedelt sind und umgekehrt.
Auch richtig.
Genau.
Leitung A => G_Abteilung A_Leitung => L_Abteilung AundB_Leitung_schreiben
und
Leitung B => G_Abteilung B_Leitung => L_Abteilung AundB_Leitung_schreiben
ist so richtig oder?
Ja. So kann das aussehen. Richtig ist hier ein relativer Begriff. Es kommt immer auf das Ziel an. Aber das Prinzip hast Du verstanden.
Das ist gerade das, was MS mit dem AD eingeführt hat, die Möglichkeit Gruppen zu verschachteln und so eine sehr flexible und nach der Ersteinrichtung sehr einfach zu handhabende Rechteverwaltung zu schaffen.
Gerne
Liebe Grüße
Erik
Gerne.
Das ist sehr praktikabel, wenn eine gesamte Gruppe von Leuten (G_Nachbarbüro_Verwaltung) die selben Rechte bekommen soll. Wenn jetzt aber beispielsweise einer der Mitarbeiter aus welchem Grund auch immer NICHT auf dem Drucker in der Verwaltung drucken darf, aber sonst alle Rechte behalten soll, dann muss der entsprechende Mitarbeiter aus G_Nachbarbüro_Verwaltung entfernt werden (G_Nachbarbüro_Verwaltung wurde ja zu L_RW_Drucker1 hinzugefügt). Aber dadurch verliert er auch alle anderen Berechtigungen, da er nicht mehr in G_Nachbarbüro_Verwaltung drin ist. Würde dann dieses unten von dir beschriebene Verfahren mit der Vererbung Abhilfe schaffen?
Ich glaub bei solche Sonderfällen muss man echt genau überlegen was man tut...
Ich glaub bei solche Sonderfällen muss man echt genau überlegen was man tut...
Sonderfälle heißen deshalb Sonderfälle, weil sie nicht ins Schema passen.
Das Ziel ist, nur eine Gruppe pro User. Manchmal kann man dieses Ziel aber nicht erreichen, weil es ein Sonderfall ist, den man zwar auch so einrichten könnte, es aber nicht praktikabel ist. Dann muss ich entweder eine zweite Gruppenmitgliedschaft hinnehmen oder zur allerhöchsten Not direkt für den User Rechte definieren und sie evtl., wie Bem0815 schon sagte, verweigern.So in etwa ist das bei uns auch. Das würde bedeuten, auf dein Beispiel bezogen, dass die beiden Abteilungsleiter NICHT Mitglied in den globalen Gruppen der Mitarbeiter sind (zB: G_Abteilung A_alle), richtig?
Richtig. Ziel: Nur eine Gruppe/User. Woran man sich gewöhnen muss, ist, dass die, die in der Hierarchie oben stehen, in der Gruppenstruktur unten angesiedelt sind und umgekehrt.
Und dadurch dass die globale Gruppe der Leitung (zB: G_Abteilung A_Leitung) Mitglied in G_Abteilung A_alle ist, bekommt die Leitung die selben Rechte, kann aber flexibler zu anderen lokalen Gruppen zugeordnet werden.
Auch richtig.
Leitung => G_Abteilung A_Leitung => G_Abteilung A_alle => L_Abteilung A_schreiben
und
Leitung => G_Abteilung A_Leitung => L_Abteilung A_Leitung_schreiben
und
Leitung => G_Abteilung A_Leitung => L_Abteilung A_Leitung_schreiben
Genau.
Dann gibt es noch einen gemeinsamen Ordner für die beiden Abteilungsleitungen. Also wieder eine lokale Gruppe und in die kommen die beiden Abteilungsleitungsgruppen.
Leitung A => G_Abteilung A_Leitung => L_Abteilung AundB_Leitung_schreiben
und
Leitung B => G_Abteilung B_Leitung => L_Abteilung AundB_Leitung_schreiben
ist so richtig oder?
Ja. So kann das aussehen. Richtig ist hier ein relativer Begriff.
Es kommt immer auf das Ziel an. Aber das Prinzip hast Du verstanden.Man kann also die globalen Gruppen in der untersten Stufe also auch flexibel zu anderen lokalen Gruppen hinzufügen. Ich hab irgendwie gedacht, dass die fest mit anderen globalen Gruppen verankert sind :D
Das ist gerade das, was MS mit dem AD eingeführt hat, die Möglichkeit Gruppen zu verschachteln und so eine sehr flexible und nach der Ersteinrichtung sehr einfach zu handhabende Rechteverwaltung zu schaffen.
Danke für die Erleuchtung
Gerne
Liebe Grüße
Erik
1Zitat von @Bem0815:
Bei solchen Sonderfällen bei denen eine oder mehrere Personen explizit Berechtigungen nicht erhalten sollen, die sie aber typischerweise in ihrer Abteilung erhalten würden gibt es noch ein tolles Feature bei NTFS Berechtigungen. Nämlich das "Verweigern".
Hier noch ein anderes Beispiel in dem man das anwenden kann.
Es gibt in Firma x unter anderem die Abteilungen Vertrieb und Marketing.
In beiden Abteilungen gibt es Azubis, diese sollen nicht selbst drucken dürfen sondern müssen ihre fertigen Dateien erst Korrekturlesen lassen und ein anderer Mitarbeiter druckt das dann für die Azubis.
Die Azubis sind jeweils Teil ihrer Globalen Gruppe für die Abteilung.
Also G-Marketing und G-Vertrieb. Marketing greift auf DL Gruppe DL-Drucker1 zu, Vertrieb auf die DL-Drucker2
Weiterhin sind die Azubis alle Teil der Globalen Gruppe G-Azubis welche Teil der DL Gruppe DL-Druckverweigern ist und diese einen Druck auf jeglichen Druckern verweigert.
Solltest du deine User jeweils nur gerne in einer Globalen Gruppe haben wollen müsstest du das stattdessen wie folgt machen:
Azubi Marketing ist in der Gruppe G-Marketing_Azubi diese ist Teil der Gruppen G-Marketing und DL-Druckverweigern
Azubi Vertrieb ist in der Gruppe G-Vertrieb_Azubi diese ist Teil der Gruppen G-Vertrieb und DL-Druckverweigern
Bei solchen Sonderfällen bei denen eine oder mehrere Personen explizit Berechtigungen nicht erhalten sollen, die sie aber typischerweise in ihrer Abteilung erhalten würden gibt es noch ein tolles Feature bei NTFS Berechtigungen. Nämlich das "Verweigern".
Hier noch ein anderes Beispiel in dem man das anwenden kann.
Es gibt in Firma x unter anderem die Abteilungen Vertrieb und Marketing.
In beiden Abteilungen gibt es Azubis, diese sollen nicht selbst drucken dürfen sondern müssen ihre fertigen Dateien erst Korrekturlesen lassen und ein anderer Mitarbeiter druckt das dann für die Azubis.
Die Azubis sind jeweils Teil ihrer Globalen Gruppe für die Abteilung.
Also G-Marketing und G-Vertrieb. Marketing greift auf DL Gruppe DL-Drucker1 zu, Vertrieb auf die DL-Drucker2
Weiterhin sind die Azubis alle Teil der Globalen Gruppe G-Azubis welche Teil der DL Gruppe DL-Druckverweigern ist und diese einen Druck auf jeglichen Druckern verweigert.
Solltest du deine User jeweils nur gerne in einer Globalen Gruppe haben wollen müsstest du das stattdessen wie folgt machen:
Azubi Marketing ist in der Gruppe G-Marketing_Azubi diese ist Teil der Gruppen G-Marketing und DL-Druckverweigern
Azubi Vertrieb ist in der Gruppe G-Vertrieb_Azubi diese ist Teil der Gruppen G-Vertrieb und DL-Druckverweigern
Das mit dem Verweigern ist echt ein guter Hinweis
Danke dafür. Aber bei uns im Unternehmen nutzen wir das Verweigern garnicht. Das wurde damals beim Berechtigungskonzept so nicht implementiert. Von dem was ich aus deinem Beispiel so verstehe, mach es schon Sinn mit Verweigern zu arbeiten. Aber da wir das grundsätzlich so nicht bei uns im Betrieb haben, wird es meiner Meinung nach schwer sein die AD-Admins davon zu überzeugen das einzuführen.Ich denke man sollte sowieso nicht zu viel am bestehenden Berechtigungskonzept rütteln, sondern nur kleine Änderungen vornehmen. Würde man das Verweigern einführen, wäre das schon eine große, strukturelle Veränderung, die man dann ja auf alle Geschäftsbereiche anwenden müsste.
Zitat von @erikro:
Moin,
Gerne.
Sonderfälle heißen deshalb Sonderfälle, weil sie nicht ins Schema passen. Das Ziel ist, nur eine Gruppe pro User. Manchmal kann man dieses Ziel aber nicht erreichen, weil es ein Sonderfall ist, den man zwar auch so einrichten könnte, es aber nicht praktikabel ist. Dann muss ich entweder eine zweite Gruppenmitgliedschaft hinnehmen oder zur allerhöchsten Not direkt für den User Rechte definieren und sie evtl., wie Bem0815 schon sagte, verweigern.
Richtig. Ziel: Nur eine Gruppe/User. Woran man sich gewöhnen muss, ist, dass die, die in der Hierarchie oben stehen, in der Gruppenstruktur unten angesiedelt sind und umgekehrt.
Auch richtig.
Genau.
Leitung A => G_Abteilung A_Leitung => L_Abteilung AundB_Leitung_schreiben
und
Leitung B => G_Abteilung B_Leitung => L_Abteilung AundB_Leitung_schreiben
ist so richtig oder?
Ja. So kann das aussehen. Richtig ist hier ein relativer Begriff. Es kommt immer auf das Ziel an. Aber das Prinzip hast Du verstanden.
Das ist gerade das, was MS mit dem AD eingeführt hat, die Möglichkeit Gruppen zu verschachteln und so eine sehr flexible und nach der Ersteinrichtung sehr einfach zu handhabende Rechteverwaltung zu schaffen.
Gerne
Liebe Grüße
Erik
Moin,
Gerne.
Das ist sehr praktikabel, wenn eine gesamte Gruppe von Leuten (G_Nachbarbüro_Verwaltung) die selben Rechte bekommen soll. Wenn jetzt aber beispielsweise einer der Mitarbeiter aus welchem Grund auch immer NICHT auf dem Drucker in der Verwaltung drucken darf, aber sonst alle Rechte behalten soll, dann muss der entsprechende Mitarbeiter aus G_Nachbarbüro_Verwaltung entfernt werden (G_Nachbarbüro_Verwaltung wurde ja zu L_RW_Drucker1 hinzugefügt). Aber dadurch verliert er auch alle anderen Berechtigungen, da er nicht mehr in G_Nachbarbüro_Verwaltung drin ist. Würde dann dieses unten von dir beschriebene Verfahren mit der Vererbung Abhilfe schaffen?
Ich glaub bei solche Sonderfällen muss man echt genau überlegen was man tut...
Ich glaub bei solche Sonderfällen muss man echt genau überlegen was man tut...
Sonderfälle heißen deshalb Sonderfälle, weil sie nicht ins Schema passen.
Das Ziel ist, nur eine Gruppe pro User. Manchmal kann man dieses Ziel aber nicht erreichen, weil es ein Sonderfall ist, den man zwar auch so einrichten könnte, es aber nicht praktikabel ist. Dann muss ich entweder eine zweite Gruppenmitgliedschaft hinnehmen oder zur allerhöchsten Not direkt für den User Rechte definieren und sie evtl., wie Bem0815 schon sagte, verweigern.So in etwa ist das bei uns auch. Das würde bedeuten, auf dein Beispiel bezogen, dass die beiden Abteilungsleiter NICHT Mitglied in den globalen Gruppen der Mitarbeiter sind (zB: G_Abteilung A_alle), richtig?
Richtig. Ziel: Nur eine Gruppe/User. Woran man sich gewöhnen muss, ist, dass die, die in der Hierarchie oben stehen, in der Gruppenstruktur unten angesiedelt sind und umgekehrt.
Und dadurch dass die globale Gruppe der Leitung (zB: G_Abteilung A_Leitung) Mitglied in G_Abteilung A_alle ist, bekommt die Leitung die selben Rechte, kann aber flexibler zu anderen lokalen Gruppen zugeordnet werden.
Auch richtig.
Leitung => G_Abteilung A_Leitung => G_Abteilung A_alle => L_Abteilung A_schreiben
und
Leitung => G_Abteilung A_Leitung => L_Abteilung A_Leitung_schreiben
und
Leitung => G_Abteilung A_Leitung => L_Abteilung A_Leitung_schreiben
Genau.
Dann gibt es noch einen gemeinsamen Ordner für die beiden Abteilungsleitungen. Also wieder eine lokale Gruppe und in die kommen die beiden Abteilungsleitungsgruppen.
Leitung A => G_Abteilung A_Leitung => L_Abteilung AundB_Leitung_schreiben
und
Leitung B => G_Abteilung B_Leitung => L_Abteilung AundB_Leitung_schreiben
ist so richtig oder?
Ja. So kann das aussehen. Richtig ist hier ein relativer Begriff.
Es kommt immer auf das Ziel an. Aber das Prinzip hast Du verstanden.Man kann also die globalen Gruppen in der untersten Stufe also auch flexibel zu anderen lokalen Gruppen hinzufügen. Ich hab irgendwie gedacht, dass die fest mit anderen globalen Gruppen verankert sind :D
Das ist gerade das, was MS mit dem AD eingeführt hat, die Möglichkeit Gruppen zu verschachteln und so eine sehr flexible und nach der Ersteinrichtung sehr einfach zu handhabende Rechteverwaltung zu schaffen.
Danke für die Erleuchtung
Gerne
Liebe Grüße
Erik
Also wenn du sagst, dass ich soweit verstanden hab, bin ich erstmal beruhigt :D danke nochmal.
Ich muss jetzt versuchen, eure allgemeinen Hinweise auf unseren Sachverhalt im Unternehmen zu transferieren
Moin,
ein Recht explizit zu verweigern ist immer nur ultima ratio. Das sollte man wirklich nur in begründeten Ausnahmefällen machen. Ich hatte das bisher nur zwei Mal: Das eine Mal der Azubi, der zwar auf alles der Abteilung bis auf einen Ordner zugreifen können sollte. Da war das mit dem Verweigern einfacher und vor allem sicherer. Das zweite Mal war es der Seniorchef, der immer versehentlich wichtige Dateien gelöscht hat. Dem habe ich dann systemweit das Löschrecht verweigert. Ansonsten reicht ja auch "nicht erteilen".
Liebe Grüße
Erik
ein Recht explizit zu verweigern ist immer nur ultima ratio. Das sollte man wirklich nur in begründeten Ausnahmefällen machen. Ich hatte das bisher nur zwei Mal: Das eine Mal der Azubi, der zwar auf alles der Abteilung bis auf einen Ordner zugreifen können sollte. Da war das mit dem Verweigern einfacher und vor allem sicherer. Das zweite Mal war es der Seniorchef, der immer versehentlich wichtige Dateien gelöscht hat. Dem habe ich dann systemweit das Löschrecht verweigert. Ansonsten reicht ja auch "nicht erteilen".
Liebe Grüße
Erik
1Zitat von @erikro:
Moin,
ein Recht explizit zu verweigern ist immer nur ultima ratio. Das sollte man wirklich nur in begründeten Ausnahmefällen machen. Ich hatte das bisher nur zwei Mal: Das eine Mal der Azubi, der zwar auf alles der Abteilung bis auf einen Ordner zugreifen können sollte. Da war das mit dem Verweigern einfacher und vor allem sicherer. Das zweite Mal war es der Seniorchef, der immer versehentlich wichtige Dateien gelöscht hat. Dem habe ich dann systemweit das Löschrecht verweigert. Ansonsten reicht ja auch "nicht erteilen".
Liebe Grüße
Erik
Warum sollte man denn nicht verweigern? Würde das Konzept dann insgesamt zu komplex und zu fehleranfällig werden?Moin,
ein Recht explizit zu verweigern ist immer nur ultima ratio. Das sollte man wirklich nur in begründeten Ausnahmefällen machen. Ich hatte das bisher nur zwei Mal: Das eine Mal der Azubi, der zwar auf alles der Abteilung bis auf einen Ordner zugreifen können sollte. Da war das mit dem Verweigern einfacher und vor allem sicherer. Das zweite Mal war es der Seniorchef, der immer versehentlich wichtige Dateien gelöscht hat. Dem habe ich dann systemweit das Löschrecht verweigert. Ansonsten reicht ja auch "nicht erteilen".
Liebe Grüße
Erik
Edit: Und vermutlich, weil Verweigern stärker wirkt als Erlauben, oder? Würde dann ja auch den Aufwand erhöhen, wenn es darum geht Berechtigungen zuzulassen, was durch ein Verweigern unterbunden wird.
Zitat von @Sheldor:
Edit: Und vermutlich, weil Verweigern stärker wirkt als Erlauben, oder? Würde dann ja auch den Aufwand erhöhen, wenn es darum geht Berechtigungen zuzulassen, was durch ein Verweigern unterbunden wird.
Zitat von @erikro:
Moin,
ein Recht explizit zu verweigern ist immer nur ultima ratio. Das sollte man wirklich nur in begründeten Ausnahmefällen machen. Ich hatte das bisher nur zwei Mal: Das eine Mal der Azubi, der zwar auf alles der Abteilung bis auf einen Ordner zugreifen können sollte. Da war das mit dem Verweigern einfacher und vor allem sicherer. Das zweite Mal war es der Seniorchef, der immer versehentlich wichtige Dateien gelöscht hat. Dem habe ich dann systemweit das Löschrecht verweigert. Ansonsten reicht ja auch "nicht erteilen".
Liebe Grüße
Erik
Warum sollte man denn nicht verweigern? Würde das Konzept dann insgesamt zu komplex und zu fehleranfällig werden?Moin,
ein Recht explizit zu verweigern ist immer nur ultima ratio. Das sollte man wirklich nur in begründeten Ausnahmefällen machen. Ich hatte das bisher nur zwei Mal: Das eine Mal der Azubi, der zwar auf alles der Abteilung bis auf einen Ordner zugreifen können sollte. Da war das mit dem Verweigern einfacher und vor allem sicherer. Das zweite Mal war es der Seniorchef, der immer versehentlich wichtige Dateien gelöscht hat. Dem habe ich dann systemweit das Löschrecht verweigert. Ansonsten reicht ja auch "nicht erteilen".
Liebe Grüße
Erik
Edit: Und vermutlich, weil Verweigern stärker wirkt als Erlauben, oder? Würde dann ja auch den Aufwand erhöhen, wenn es darum geht Berechtigungen zuzulassen, was durch ein Verweigern unterbunden wird.
IMHO ist der einzige Grund warum man Verweigern evtl. nicht nutzen sollte die Verwirrung die es bei einer Berechtigungsprüfung auslösen könnte. Beispiel:
Ein neuer Admin sieht, dass Benutzer Teil der Gruppe ist die Berechtigungen hat, der User ist aber auch Teil einer Gruppe bei denen die Berechtigung explizit Verweigert wurde. Der Admin übersieht das und wundert sich warum kein Zugriff für den User möglich ist.
Wenn man das aber alles richtig umsetzt und ggfs. noch dokumentiert wäre auch das eigentlich kein Problem.
1Zitat von @Sheldor:
Warum sollte man denn nicht verweigern? Würde das Konzept dann insgesamt zu komplex und zu fehleranfällig werden?
Edit: Und vermutlich, weil Verweigern stärker wirkt als Erlauben, oder? Würde dann ja auch den Aufwand erhöhen, wenn es darum geht Berechtigungen zuzulassen, was durch ein Verweigern unterbunden wird.
Warum sollte man denn nicht verweigern? Würde das Konzept dann insgesamt zu komplex und zu fehleranfällig werden?
Edit: Und vermutlich, weil Verweigern stärker wirkt als Erlauben, oder? Würde dann ja auch den Aufwand erhöhen, wenn es darum geht Berechtigungen zuzulassen, was durch ein Verweigern unterbunden wird.
Genau. Verweigern geht vor. Wenn dann die Gruppenstruktur komplex wird und die Gruppe in einer Gruppe, die dann wieder in einer Gruppe ist, die dann ... Wird irgendwo unterwegs ein Recht verweigert, dann kann ich das nicht mehr durch das Gewähren dieses Rechtes erlauben. Damit kann man sich schön die Karten legen. Bem0815 hat da vollkommen recht. Sowas muss gut dokumentiert werden bzw. noch besser hat man Skripte, die einem dabei helfen, schnell herauszufinden, woher der User welche Rechte hat oder auch nicht.
1Zitat von @erikro:
Genau. Verweigern geht vor. Wenn dann die Gruppenstruktur komplex wird und die Gruppe in einer Gruppe, die dann wieder in einer Gruppe ist, die dann ... Wird irgendwo unterwegs ein Recht verweigert, dann kann ich das nicht mehr durch das Gewähren dieses Rechtes erlauben. Damit kann man sich schön die Karten legen. Bem0815 hat da vollkommen recht. Sowas muss gut dokumentiert werden bzw. noch besser hat man Skripte, die einem dabei helfen, schnell herauszufinden, woher der User welche Rechte hat oder auch nicht.
Zitat von @Sheldor:
Warum sollte man denn nicht verweigern? Würde das Konzept dann insgesamt zu komplex und zu fehleranfällig werden?
Edit: Und vermutlich, weil Verweigern stärker wirkt als Erlauben, oder? Würde dann ja auch den Aufwand erhöhen, wenn es darum geht Berechtigungen zuzulassen, was durch ein Verweigern unterbunden wird.
Warum sollte man denn nicht verweigern? Würde das Konzept dann insgesamt zu komplex und zu fehleranfällig werden?
Edit: Und vermutlich, weil Verweigern stärker wirkt als Erlauben, oder? Würde dann ja auch den Aufwand erhöhen, wenn es darum geht Berechtigungen zuzulassen, was durch ein Verweigern unterbunden wird.
Genau. Verweigern geht vor. Wenn dann die Gruppenstruktur komplex wird und die Gruppe in einer Gruppe, die dann wieder in einer Gruppe ist, die dann ... Wird irgendwo unterwegs ein Recht verweigert, dann kann ich das nicht mehr durch das Gewähren dieses Rechtes erlauben. Damit kann man sich schön die Karten legen. Bem0815 hat da vollkommen recht. Sowas muss gut dokumentiert werden bzw. noch besser hat man Skripte, die einem dabei helfen, schnell herauszufinden, woher der User welche Rechte hat oder auch nicht.
Theoretisch kann aber bei Sonderrechten ohne die Nutzung von "Verweigern" das gleiche passieren. Dass man hier nicht mehr den überblick hat.
IMHO finde ich daher trotzdem, dass "Verweigern" eine passable option ist um das AGDLP-Prinzip einhalten zu können.
Ist aber nur meine Meinung, können andere natürlich etwas anders sehen.
Dokumentieren sollte man aber zumindest die Sonderfälle am besten sowieso.
1
Also eine Dokumentation haben wir bei uns sowieso nicht :D
Und von einer vernünftigen Rückmeldung zum Admin über nicht mehr benötigte Berechtigungen will ich garnicht erst anfangen....
Und von einer vernünftigen Rückmeldung zum Admin über nicht mehr benötigte Berechtigungen will ich garnicht erst anfangen....
Zitat von @Sheldor:
Also eine Dokumentation haben wir bei uns sowieso nicht :D
Und von einer vernünftigen Rückmeldung zum Admin über nicht mehr benötigte Berechtigungen will ich garnicht erst anfangen....
Also eine Dokumentation haben wir bei uns sowieso nicht :D
Und von einer vernünftigen Rückmeldung zum Admin über nicht mehr benötigte Berechtigungen will ich garnicht erst anfangen....
Gut bei dem Thema kommt es natürlich auch ein bisschen auf die Größe an.
Wenn ihr z.B. nur 25 Mitarbeiter seid dann ist das mit den Berechtigungen auch mit Verweigern mit akzeptablem Aufwand auch so noch für einen Admin zu bewältigen.
Wenn ihr dagegen z.B. 500 User seid dann würde ich dringend empfehlen was die Berechtigungen betrifft alles zu dokumentieren. Speziell halt Sonderberechtigungen.
Zitat von @Bem0815:
Gut bei dem Thema kommt es natürlich auch ein bisschen auf die Größe an.
Wenn ihr z.B. nur 25 Mitarbeiter seid dann ist das mit den Berechtigungen auch mit Verweigern mit akzeptablem Aufwand auch so noch für einen Admin zu bewältigen.
Wenn ihr dagegen z.B. 500 User seid dann würde ich dringend empfehlen was die Berechtigungen betrifft alles zu dokumentieren. Speziell halt Sonderberechtigungen.
Zitat von @Sheldor:
Also eine Dokumentation haben wir bei uns sowieso nicht :D
Und von einer vernünftigen Rückmeldung zum Admin über nicht mehr benötigte Berechtigungen will ich garnicht erst anfangen....
Also eine Dokumentation haben wir bei uns sowieso nicht :D
Und von einer vernünftigen Rückmeldung zum Admin über nicht mehr benötigte Berechtigungen will ich garnicht erst anfangen....
Gut bei dem Thema kommt es natürlich auch ein bisschen auf die Größe an.
Wenn ihr z.B. nur 25 Mitarbeiter seid dann ist das mit den Berechtigungen auch mit Verweigern mit akzeptablem Aufwand auch so noch für einen Admin zu bewältigen.
Wenn ihr dagegen z.B. 500 User seid dann würde ich dringend empfehlen was die Berechtigungen betrifft alles zu dokumentieren. Speziell halt Sonderberechtigungen.
Wir sind bei uns etwa 800 - 900 Nutzer, die einen PC-Zugang haben und demnach auch mit Berechtigungen versorgt wird. Skizziert wird nichts bei uns, dokumentiert auch nicht.
Ich versuche gerade für meine Abteilung (8 Leute) ein neues Konzept, basierend auf den Regelungen im Unternehmen und den Strukturen im AD, zu entwerfen und finde das schon komplex. Liegt aber auch an den 'Anforderungen' an die Berechtigungen, die sind hier etwas speziell.
Zitat von @Sheldor:
Wir sind bei uns etwa 800 - 900 Nutzer, die einen PC-Zugang haben und demnach auch mit Berechtigungen versorgt wird. Skizziert wird nichts bei uns, dokumentiert auch nicht.
Wir sind bei uns etwa 800 - 900 Nutzer, die einen PC-Zugang haben und demnach auch mit Berechtigungen versorgt wird. Skizziert wird nichts bei uns, dokumentiert auch nicht.
Geht gar nicht. Wehe dem, wenn die Aufsichtsbehörde zum Datenschutz-Auditing kommt. Dann gibt's an die Ohren.
Zitat von @erikro:
Geht gar nicht. Wehe dem, wenn die Aufsichtsbehörde zum Datenschutz-Auditing kommt. Dann gibt's an die Ohren.
Zitat von @Sheldor:
Wir sind bei uns etwa 800 - 900 Nutzer, die einen PC-Zugang haben und demnach auch mit Berechtigungen versorgt wird. Skizziert wird nichts bei uns, dokumentiert auch nicht.
Wir sind bei uns etwa 800 - 900 Nutzer, die einen PC-Zugang haben und demnach auch mit Berechtigungen versorgt wird. Skizziert wird nichts bei uns, dokumentiert auch nicht.
Geht gar nicht. Wehe dem, wenn die Aufsichtsbehörde zum Datenschutz-Auditing kommt. Dann gibt's an die Ohren.
Es wird automatisch gelogt, was verändert wird und welche Berechtigungen erfragt werden. Aber ob das so reicht, kann ich nicht sagen.
Hallo,
wenn Du alles strikt nach AGDLP machen möchtest, dann schaue VORHER, ob auch jede Software und jedes Gerät damit funktionieren würde. Ich bin damit nämlich letzte Woche gerade vor die Wand gerannt.
Alles schön nach AGDLP geplant und eingerichtet mit zig Gruppen. Dann in unserer Sophos-Firewall die Gruppen entsprechenden Funktionen zugeordnet, z.B. wer VPN machen darf, wer auf die Admin-Oberfläche darf, im Web-Filter eingestellt, wer wann wohin surfen darf, und und und.
Und dann wunderte ich mich, wieso ich mich mit meinem persönlichen Admin-Account nicht am Webinterface anmelden konnte, obwohl ich doch in der Globalen Gruppe der Admins drin war, die wiederum Zugriff auf die Domänen-Lokale-Gruppe für den Zugriff auf die Sophos war. Es konnte auch niemand mehr über den Web-Filter surfen, etc.
Wie sich herausstellte, kann Sophos nur mit EINER Gruppenebene umgehen und supportet keine verschachtelten Gruppen (vom Support bestätigt). Somit ist das ganze AGDLP-Konzept hier für die Katz bzw. muß an mehreren Stellen wieder aufgeweicht werden. *kopf->Tisch*
Andere Software und Geräte brauchte ich dann garnicht mehr zu testen.
Ich kann daher nur eindringlich empfehlen, VORHER alles daraufhin abzuklopfen, ob es auch so funktionieren würde, wie ihr euch das vorstellt.
Wenn ihr NUR Filesystemrechte damit verwalten wollt, dann nur zu
cu,
ipzipzap
wenn Du alles strikt nach AGDLP machen möchtest, dann schaue VORHER, ob auch jede Software und jedes Gerät damit funktionieren würde. Ich bin damit nämlich letzte Woche gerade vor die Wand gerannt.
Alles schön nach AGDLP geplant und eingerichtet mit zig Gruppen. Dann in unserer Sophos-Firewall die Gruppen entsprechenden Funktionen zugeordnet, z.B. wer VPN machen darf, wer auf die Admin-Oberfläche darf, im Web-Filter eingestellt, wer wann wohin surfen darf, und und und.
Und dann wunderte ich mich, wieso ich mich mit meinem persönlichen Admin-Account nicht am Webinterface anmelden konnte, obwohl ich doch in der Globalen Gruppe der Admins drin war, die wiederum Zugriff auf die Domänen-Lokale-Gruppe für den Zugriff auf die Sophos war. Es konnte auch niemand mehr über den Web-Filter surfen, etc.
Wie sich herausstellte, kann Sophos nur mit EINER Gruppenebene umgehen und supportet keine verschachtelten Gruppen (vom Support bestätigt). Somit ist das ganze AGDLP-Konzept hier für die Katz bzw. muß an mehreren Stellen wieder aufgeweicht werden. *kopf->Tisch*
Andere Software und Geräte brauchte ich dann garnicht mehr zu testen.
Ich kann daher nur eindringlich empfehlen, VORHER alles daraufhin abzuklopfen, ob es auch so funktionieren würde, wie ihr euch das vorstellt.
Wenn ihr NUR Filesystemrechte damit verwalten wollt, dann nur zu
cu,
ipzipzap
Nur so meine Meinung.
Das AGDLP Konzept ist eine Empfehlung und KEIN MUSS!!!
Genauso wie ITIL.
Man kann sich danach richten, muss es aber nicht.
[Edit] Zitat eingefügt.
<Zitat>
Ein Nachteil des Konzepts tritt in sehr großen Umgebungen zutage, denn dort führt es schnell zu einer sehr großen Zahl von Gruppen und von Gruppenmitgliedschaften.
</Zitatende>
Gruss Penny
Das AGDLP Konzept ist eine Empfehlung und KEIN MUSS!!!
Genauso wie ITIL.
Man kann sich danach richten, muss es aber nicht.
[Edit] Zitat eingefügt.
<Zitat>
Ein Nachteil des Konzepts tritt in sehr großen Umgebungen zutage, denn dort führt es schnell zu einer sehr großen Zahl von Gruppen und von Gruppenmitgliedschaften.
</Zitatende>
Gruss Penny
Moin,
Anders herum: Nicht die Gruppenstruktur richtet sich nach den Geräten, sondern die Geräte nach der Struktur.
Immer noch nicht? Ich dachte das wäre behoben. Also kann man es in der Windows-Domain weiterhin nicht einsetzen.
Liebe Grüße
Erik
Zitat von @ipzipzap:
wenn Du alles strikt nach AGDLP machen möchtest, dann schaue VORHER, ob auch jede Software und jedes Gerät damit funktionieren würde. Ich bin damit nämlich letzte Woche gerade vor die Wand gerannt.
wenn Du alles strikt nach AGDLP machen möchtest, dann schaue VORHER, ob auch jede Software und jedes Gerät damit funktionieren würde. Ich bin damit nämlich letzte Woche gerade vor die Wand gerannt.
Anders herum: Nicht die Gruppenstruktur richtet sich nach den Geräten, sondern die Geräte nach der Struktur.
Wie sich herausstellte, kann Sophos nur mit EINER Gruppenebene umgehen und supportet keine verschachtelten Gruppen (vom Support bestätigt). Somit ist das ganze AGDLP-Konzept hier für die Katz bzw. muß an mehreren Stellen wieder aufgeweicht werden. *kopf->Tisch*
Immer noch nicht? Ich dachte das wäre behoben. Also kann man es in der Windows-Domain weiterhin nicht einsetzen.
Liebe Grüße
Erik
