Richtlinien für einzelne Benutzer oder Sicherheitsgruppen einrichten:
Das Problem:
Gruppenrichtlinien wirken nur auf Benutzer~ und Computerobjekte im Active Directory.
Folgendes oder ähnliches Szenario funktioniert !!!NICHT!!!:
OU: „Alle meine Angestellten“
In der OU „Alle meine Angestellten“ sind Praktikanten,
die mit weniger Rechten ausgestattet ein sollen:
o Praktikant 1
o Praktikant 2 Mitglieder der Sicherheitsgruppe „Praktikanten“
o Praktikant 3
In dieser OU wird eine weitere OU „Alle Praktikanten“
erstellt, in der sich
die Gruppe der Praktikanten befindet
OU: Alle Praktikanten
o
Sicherheitsgruppe Praktikanten
Wird für die OU „Alle
Praktikanten“ eine Gruppenrichlinien erstellt, in der weitere
Konfigurations-Einstellungen vorgenommen werden, so wirkt sie sich nicht auf die Benutzer Praktikant 1, Praktikant 2
und Praktikant 3 aus.
Es ist nur die Richtlinie auf Ebene der OU „Alle
meine Angestellten“ ausschlaggebend und nur diese Einstellungen
werden vom Benutzer bei der Anmeldung übernommen. (Vererbung übergeordneter
Richtlinien und lokale Richtlinie an dieser Stelle mal aussenvor gelassen).
Jetzt stellt sich also die Frage, wie sich dieses Problem lösen lässt. Es gibt an dieser Stelle 2 Möglichkeiten die sich anwenden lassen.
So geht’s:
Die erste Idee und einfachste Möglichkeit ist es die
Benutzer Praktikant 1, Praktikant 2 und Praktikant 3 in die OU „Alle
Praktikanten“ zu verschieben. Ab diesem Moment liegen die Active Directory
Objekte im richtigen Container und die Gruppenrichtlinien, die auf diesem
Container eingestellt sind kommen zur Anwendung.
OU: Alle Praktikanten
o Sicherheitsgruppe „Praktikanten“
o Praktikant 1
o Praktikant 2
o Praktikant 3
Die
Sicherheitsgruppe „Praktikanten“ hat für die OU keinen weiteren direkten
Nutzen, kann aber für z.B.: NTFS Dateiberechtigungen weiter verwendet werden.
Diese Lösung ist
praktikabel und bietet meiner Meinung nach die übersichtlichste Möglichkeit
Richtlinien zu strukturieren, da pro OU nur eine Richtlinie hinterlegt wird und
es sich so mit geringem administrativem Aufwand nachvollziehen lässt, welche
GruRiLi auf welche Objekte (Benutzer und Computer) zum Einsatz kommt (kommen
soll).
Nachteil ist ganz klar, daß man bei dieser Form bald eine große Anzahl an OU´s
hat, durch die man sich erst einmal durchkämpfen muss und zudem macht eine OU
für nur einen einzigen Benutzer nicht so wirklich Sinn.
Die 2te Möglichkeit bieten Sicherheitsberechtigungen
die sich für jede Gruppenrichtlinie separat konfigurieren lassen und man
belässt die Benutzer/Computerkonten an der Stelle/in der OU wo sie schon sind.
An dieser Stelle fängt man an über Sicherheitsberechtigungen (ACL´s), ähnlich
denen, die man von den NTFS Dateiberechtigungen kennt, bestimmte Benutzer
auszuschliessen, bzw. bestimmten Benutzer Rechte einzuräumen, über die die
„anderen“ nicht verfügen.
1. Schritt:
OU: „Alle meine Angestellten“
Die Benutzer Praktikant X sind keine Mitglieder der Gruppe Angestellte, ebensowenig sind die Benutzer Angestellter X Mitglied der Sicherheitsgruppe Praktikanten. Es findet über die Gruppenzugehörigkeit der jeweiligen Benutzer eine klare Trennung statt. Natürlich können die Benutzer weiterhin über eine gemeinsame Gruppenzugehörigkeit „MeineFirma“ oder anderen globalen Gruppen verfügen. Wichtig ist für uns aktuell nur die klare Abgrenzung der einzelnen Benutzer durch Gruppen.
2. Schritt:
Es werden
für die OU 2 unterschiedliche Richtlinien definiert. Die zusätzliche Richtlinie
beinhaltet die gewünschten erweiterten/eingeschränkten Einstellungen. Das
Gegenteil wäre natürlich auch möglich, wenn man z.B.: an Abteilungsleiter oder
andere „gehobene“ Positionen denkt, die oftmals über weniger restriktive Rechte
verfügen.
Nicht weil sie es verdient haben, sondern weil sie dieses Recht beim Chef eingeklagt haben … diese Grundhaltung muss natürlich nicht parallel zur persönlichen Haltung des Administrators laufen … das nur nebenbei J
Gehen wir
in unserem Beispiel davon aus, daß alle eingestellten Richtlinien für die OU „Alle meine Angestellten“ auch für beide
Sicherheitsgruppen Praktikanten und Angestellte gelten sollen, nur mit dem
Unterschied, daß Praktikanten noch weniger dürfen.
Rufen wir uns an dieser Stelle noch mal den Weg der Vererbung von Richtlinien ins Gedächtnis:
Kommen 2 Richtlinien auf gleicher hierachischer Ebene zur Anwendung so werden die Einstellungen der in der Priorität höher angesiedelten Richtlinie vererbt.
Starker Satz … betrachten wir es mal grafisch:
Auf der OU befinden sich 2 Richtlinien. Diese kann ich „nach oben“ und „nach unten“ sortieren, die die „oben“ steht ist diejenige, von der die Einstellungen geerbt werden, bzw. von der oberen werden die Einstellungen vererbt => nach „unten“ weitergegeben.
Unter
dieser Vorraussetzung müssen in der 2ten Richtlinie nur die Einstellungen
vorgenommen werden, die als zusätzliche Richtlinien oder veränderte
hinzukommen.
Wenn diese Einstellungen vorgenommen sind, kommen die Sicherheitsberechtigungen
zum Einsatz.
Grundsätzlich
arbeite ich an dieser Stelle ohne die Sicherheitsgruppe: „Authentifizierte
Benutzer“ Denn in dieser Gruppe wären wieder „Alle“ drin, die ich an dieser
Stelle nicht einschränken möchte, den per Grundeinstellungen hat diese Gruppe
immer das Recht „Richtlinie übernehmen“ und damit hätten wir keine Trennung
mehr nach Angestellte und Praktikanten.
So sehen die Sicherheitseinstellungen für die Richtlinie Angestellte aus:
- es existiert keine Gruppe „Authentifizierte Benutzer“
- alle Benutzer sind Mitglied der Gruppe „MeineFirma“
- Alle Mitglieder der Gruppe „MeineFirma“ haben das Recht die Richtlinie zu übernehmen
So sehen die Sicherheitseinstellungen für die Richtlinie Praktikanten aus:
- es existiert keine Gruppe „Authentifizierte Benutzer“
- die Gruppe „MeineFirma“ ist aus den Sicherheitsberechtigungen entfernt
- Alle Mitglieder der Gruppe „Praktikanten“ haben das Recht die Richtlinie zu übernehmen