LDAP://Yusufs.Directory.Blog/ - Objektdelegierungen einrichten

Objektdelegierungen einrichten

In dem Artikel Delegierte Berechtigungen im AD verstehen wurden die Hintergründe bei der Objektdelegierung erläutert,
worauf auch auf die techische Umsetzung kurz eingegangen wurde. In diesem Artikel soll dieser Punkt weiter erläutert werden.

Die Delegierungsfunktionen im Active Directory bieten dem Administrator die Möglichkeit, administrative Aufgaben an andere
Benutzer zu delegieren. Durch die Objektverwaltung werden eine Reihe von Sicherheitsproblemen beseitigt. Diese Funktion
die seit Windows 2000 existiert macht es möglich, dass Benutzer im Active Directory nur die Berechtigungen, die sie auch
tatsächlich für ihre tägliche Aufgabe benötigen erhalten. Die Verwaltung der Objekte kann somit an andere Benutzer
übergeben werden und hat den Vorteil, dass dadurch die Administration dezentral verteilt werden kann. Der Administrator muss
nicht alle Active Directory-Aufgaben selbst durchführen. Der Sicherheitsaspekt ist dabei ebenfalls nicht zu verachten,
denn es existieren auch heute noch zu viele Domänen-Administratoren in den Unternehmen die es nicht geben müßte,
Dank der Objektverwaltung.

Viele Unternehmen schöpfen die Möglichkeiten der Delegierung nicht aus. Einige Unternehmen sind sich dessen garnicht bewußt
was hinter dieser Funktion steckt und andere wiederum scheuen sich davor, ein entsprechendes Delegierungskonzept abgestimmt
auf die unternehmerischen Anforderungen zu entwerfen. Dabei ist die Planung eines Delegierungskonzepts nicht kompliziert,
es muss lediglich klar sein was erreicht werden soll. Daher ist es unausweichlich zu dokumentieren, welche Berechtigungen
die Benutzer erhalten sollen bevor es an die technische Umsetzung geht. Welche Benutzer sollen welche Berechtigungen
für welche Verwaltungsaufgaben erhalten. Welche Aufgaben können delegiert werden und welche Arbeiten sollten von der
IT-Abteilung durchgeführt werden. Es benötigt auch ein Grundverständinis für die rollenbasierte Administration um das ideale
Delegierungsmodell zu entwickeln. Denn das Active Directory ist als Verzeichnisdienst geradezu prätestiniert eine rollenbasierte
Administration aufzubauen. Zugangsberechtigungen können der Rolle eines Mitarbeiters und nicht seinem Namen zugeordnet werden.

Einige Grundregeln die es bei dem Konzept zu beachten gilt wären:

Delegierungen sollten immer auf Gruppen angewendet werden und nicht auf einzelne Personen. Das gestaltet die zukünftige
Administration erheblich einfacher, denn es können flexibler Benutzer zu der Gruppe mit den bereits delegierten Berechtigungen
hinzugefügt oder wieder entfernt werden. Somit müssen z.B. die gleichen Berechtigungen eines ausgeschiedenen Mitarbeiters
nicht erneut seinem Nachfolger delegiert werden. Der Nachfolger muss lediglich der Gruppe hinzugefügt werden und kann dann
die gleichen Aufgaben wahrnehmen.
Die Domänen-Administratoren sollten mit einem normalen Benutzerkonto angemeldet sein, um nicht mit zu hohen Berechtigungen
permanent angemeldet zu sein. Erst wenn administrative Arbeiten durchzuführen wären, sollte man sich mit einem
administrativen Konto anmelden.
Die Option „Ausführen als“ (Run as) sollte genutzt werden. Das macht das eine oder andere anmelden
als Domänen-Administrator überflüssig.

Ein wesentlich wichtiger Punkt beim Entwerfen eines Delegierungskonzepts ist auch eine entsprechende OU-Struktur zu Planen,
die den Ansprüchen des Unternehmens genügt. Denn das Einrichten von Organisationseinheiten (OU) hat zweierlei Vorteile.
Zum einen lassen sich auf OUs Gruppenrichtlinien anwenden und zum anderen dienen OUs als Vewaltungsbereich innerhalb
des Active Directorys. OUs tragen im Delegierungskonzept eine wichtige Rolle, denn durch das Erstellen von OUs werden die Rechte
über Objekte auf diese Ebene begrenzt. Das bedeutet konkret, soll der First-Level Support alle Benutzer aus dem Verkauf und nur
diese administrieren (Benutzerkonto erstellen/löschen, Konto entsperren, Kennwort zurücksetzen, Gruppenmitgliedschaften ändern etc.),
so könnten alle Benutzer aus dem Verkauf in eine OU verschoben und dem First-Level Support die entsprechenden Rechte
auf diese OU delegiert werden.

Es gilt zuerst das Delegierungskonzept zu erarbeiten sowie zu dokumentieren, ehe es dann in einer Testumgebung getestet
und anschließend evaluiert werden sollte. Erst dann kann es zur technischen Umsetzung in der produktiven Umgebung übergehen.
Jedes Unternehmen für sich ist zwar individuell, doch die meisten Aufgaben bei der Active Directory-Administration sind in allen
Unternehmen gleich. Es müssen Objekte erstellt (z.B. Benutzerkonten), bearbeitet und gelöscht werden. Deshalb kann auf vielen
Unternehmen ein einmal entworfenes allgemeingültiges Delegierungsmodell angewendet werden.

Bekanntermaßen stellen oftmals in den Unternehmen gerade die Unternehmenspolitik oder das beschneiden der Rechte einzelner
IT-Mitarbeiter eine Herausforderung dar. Trotzalledem ist es im Sinne der Unternehmenssicherheit Pflicht ein Delegierungskonzept
zu implementieren, anstatt mit Domänen-Administratorrechten im Web zu surfen oder E-Mails zu bearbeiten.

Die technische Umsetzung eines Delegierungsmodells kann dabei mit Boardmitteln auf die drei folgenden Varianten realisiert werden:

In der grafischen Oberfläche (GUI) durch den Assistenten zum Zuweisen der Objektverwaltung.
Ebenfalls in der GUI, durch direktes Bearbeiten der Discretionary Access Control List (DACL) im security descriptor eines Objekts.
Mit dem Kommandozeilentool DSACLS.

Objektverwaltung zuweisen

Die meistverbreiteste Variante zum Einrichten von Delegierungen dürfte der Delegierungs-Assistent sein, den sicherlich viele
Administratoren kennen. Der Assistent lässt sich aus dem Kontextmenü (Rechtsklick), z.B. auf den Standard-Containern
Computers sowie Users oder aber auch auf Domänen- bzw. OU-Ebene, im Snap-In Active Directory-Benutzer und -Computer
durch die Option Objektverwaltung zuweisen… aufrufen.

Der Assistent startet mit der Begrüßungsseite. Im nächsten Schritt muss mit Hinzufügen ein Benutzer oder besser eine Gruppe
ausgewählt werden, der die Rechte auf das Objekt delegiert werden sollen. Danch folgt der entscheidende Schritt, nämlich das
Zuweisen der Aufgaben bzw. die Vergabe der Rechte auf das Objekt.

An diesem Schritt muss entschieden werden, ob dem Benutzer oder der Gruppe eine allgemeine oder eher eine benutzerdefinierte
Aufgabe delegiert werden soll. Dabei bietet der Assistent standardmäßig unter Windows Server 2003 zehn sowie unter Windows Server 2008
neun allgemeine Aufgaben im Standard-Container Users an. Auf einer OU sind es hingegen zwölf unter Windows Server 2003 sowie elf
allgemeine Aufgaben unter Windows Server 2008. Dabei ist die gleichzeitige Aktivierung mehrerer Aufgaben auf jeder Ebene möglich.
An dieser Stelle sei angemerkt, dass dieser Schritt unter Windows 2000 nicht auf dem Standard-Container Users existiert,
dafür aber auf einer OU (mit sechs allgemeinen Aufgaben). Unter Windows 2000 sind insgesamt sieben allgemeine Aufgaben definiert.

In Windows Server 2003 und Windows Server 2008 sind die einzelnen Schritte im Assistenten gleich.

Wird z.B. die Aufgabe Erstellt, entfernt und verwaltet Benutzerkonten ausgewählt, erhält die Gruppe die dieses Recht
delegiert bekommt, Vollzugriff auf die Benutzerkonten in dem Container auf dem der Delegierungsassistent ausgefürt wurde.
Bei der Aktivierung der Aufgabe Setzt Benutzerkennwörter zurück und erzwingt Kennwortänderung bei der nächsten Anmeldung
erhält die Gruppe die erweiterte Berechtigung Kennwort zurücksetzen sowie Lese- und Schreibrechte auf das Attribut Pwd-Last-Set
auf Benutzerkonten. Oder bei der Aufgabe Erstellt, löscht und verwaltet Gruppen werden den Benutzern Vollzugriff auf
Gruppen-Objekt erteilt. Die einzelnen allgemeinen Aufgaben dürften aber selbsterklärend sein.

Wenn eine allgemeine Aufgabe ausgewählt wurde, erscheint im nächsten Schritt die Zusammenfassung und mit einem Klick
auf Fertig stellen wird der Assistent beendet.

Für viele Administratoren dürfte die Aufgabe Benutzerdefinierte Tasks zum Zuweisen erstellen interessant sein. Denn bei der
Aktivierung einer allgemeinen Aufgabe, werden eine Reihe von Berechtigungen vergeben was bedeutet, dass auf mehreren Attributen
Berechtigungen vergeben werden. Soll jedoch ein einzelnes Recht (sofern möglich) delegiert werden, so ist die benutzerdefinierte
Variante genau das richtige. Hier können Berechtigungen auf einzelne Attribute vergeben werden.

Bei der benutzerdefinierten Variante können die gleichen Berechtigungen wie unter den allgemeinen Aufgaben vergeben werden.
Jedoch stehen unter den benutzerdefinierten Aufgaben viel mehr Optionen zur Auswahl. Dort können unter anderem neben
Berechtigungen auf Benutzer-, Computer- oder Gruppenkonten, auch Rechte auf Kontaktobjekte,
PSO (unter Windows Server 2008, Password Settings Objects), OU-, Standort-, Standortverknüpfungs-, Subnetz-
und Verbindungs-Objekte vergeben werden.

Falls nun der benutzerdefinierte Task ausgewählt wurde, müssen weitere Angaben getroffen werden.

Es muss festgelegt werden, ob die Verwaltungsaufgaben für den aktuellen Ordner mit allen bestehenden und den neu zu
erstellenden Objekten gelten soll oder nur für bestimmte Objeke im Ordner. In der Praxis sollen meistens einzelne Rechte
auf bestimmte Objekte vergeben werden, daher ist an dieser Stelle die zweite Option zu wählen.

Für viele Administratoren dürfte die Option "Benutzer"-Objekte interessant sein.
Denn gerade der tagtägliche Benutzersupport benötigt einiges an Support. ;-)

Anschließend müssen im nächsten Schritt die Berechtigungen vergeben werden, wobei die Berechtigungen in drei Bereiche unterteilt sind:

Allgemein: Hier können allgemeine Berechtigungen, wie z.B. Vollzugriff, Lesen, Schreiben etc. vergeben werden.
Eigenschaftenspezifisch: Ist dieser Bereich aktiviert, können Berechtigungen auf einzelne Attribute vergeben werden.
Bei der benutzerdefinierten Delegierung dürfte dieser Bereich in Frage kommen.
Erstellen/Löschen der Berechtigungen von bestimmten untergeordneten Objekten: In diesem Bereich wird die Vergabe
von Berechtigungen, für das Erstellen und Löschen von allen verfügbaren Objekten, bezogen auf das im vorherigen Schritt
ausgewählten Objekts, gestattet.

Hier drei Beispiele:

Soll der Benutzersupport das Recht auf einem Container erhalten, in den Eigenschaften der Benutzerkonten im Reiter Konto
die Option Konto läuft ab zu konfigurieren, so ist bei der benutzerdefinierten Aufgabe das Objekt „Benutzer-Objekte“
auszuwählen und im nächsten Schritt dann die „Eigenschaftenspezifische-Option“ accountExpires schreiben zu aktivieren.

Dabei wird der Schreibzugriff auf das Attribut Account-Expires für "Benutzer"-Objekte gesetzt.
Was auch eher eine lästige Aufgabe des Benutzersupports sein dürfte, ist das Entsperren von Benutzerkonten bei zu oft
falsch eingegebenen Kennwörtern. Wie oft das Kennwort falsch eingegeben werden darf und ob der Benutzer nach einer
gewissen Zeit erneut sein Glück versuchen kann oder ob ein Administrator die Sperrung aufheben muss, wird alles in der
Kennwort-Richlinie auf Domänenebene gesteuert. Damit nun der Benutzersupport das einzelne Recht zum entsperren von
Benutzerkonten erhält, muss ebenfalls bei der benutzerdefinierten Vorgehensweise zuerst die Option „Benutzer-Objekte“
ausgewählt und im darauffolgenden Schritt die „Eigenschaftenspezifische-Berechtigung“ lockoutTime schreiben ausgewählt werden.

Danach kann der Support in den Eigenschaften der Benutzerkonten im Reiter Konto den Haken bei der Option Konto ist gesperrt
(unter Windows Server 2003) oder Kontosperrung aufheben (unter Windows Server 2008) entfernen.

Bei dieser Delegierung wird ebenfalls der Schreibzugriff auf das Attribut Lockout-Time für "Benutzer"-Objekte gesetzt.
Damit der Benutzersupport im Reiter Konto die Anmeldezeiten in den Benutzerkonten konfigurieren kann, müssen diesmal
bei der benutzerdefinierten Variante zuerst die „Benutzer-Objekte“ aktiviert und anschließend die
„Eigenschaftenspezifische-Berechtigung“ logonHours schreiben aktiviert werden.

Auch in diesem Fall wird der Schreibzugriff auf das Attribut Logon-Hours für "Benutzer"-Objekte gesetzt.

Anschließend folgt im letzten Schritt des Assistenten die Zusammenstellung, in der die vorgenommenen Einstellungen überprüft
werden können. Mit einem Klick auf Fertig stellen wird der Assistent beendet.

Das waren drei recht einfache Aufgaben für die Delegierung. Es können natürlich noch weit tiefere Berechtigungen delegiert
werden (z.B. für die AD-Replikation). Ein guter Einstieg in das Thema Delegierung (mit sehr vielen Beispielen) sind diese beiden Whitepaper:

Best Practices for Delegating Active Directory Administration
Best Practices for Delegating Active Directory Administration Appendices

Nach der Delegierung ist es noch notwendig, dem Benutzersupport die AD-Snap-Ins zur Verfügung zu stellen. Dazu ist das AdminPak,
idealerweise nur die AD-Snap-Ins Active Directory-Benutzer und -Computer (dsa.msc),
Active Directory-Domänen und -Vertrauensstellungen (domain.msc) sowie Active Directory-Standorte und -Dienste (dssite.msc),
auf einem Windows 2000/XP-Client zu installieren. Im ersten Schritt gilt es von einem Windows 2000 oder Windows Server 2003 aus
dem Verzeichnis „windir%\system32\“ bzw. von der Windows 2000/Windows Server 2003 CD aus dem Verzeichnis I386 die Datei
Adminpak.msi lokal auf den Windows 2000/XP-Client zu kopieren und im zweiten, mit dem folgenden Befehl lediglich die AD-MMCs zu installieren:
C:\Pfad zur Adminpak.msi> msiexec /i adminpak.msi ADDLOCAL=FeADTools /qb

How to use Adminpak.msi to install a specific server administration tool in Windows

Auf einem Vista SP1 Client müssen zuerst die Remote Server Administration Tools installiert werden. Dann ist in der Systemsteuerung
unter „Programme und Funktionen“ auf der linken Seite die Aufgabe „Windows-Funktionen ein- oder ausschalten“ auszuwählen.
Nun kann im darauf erscheinenden Fenster unter dem Punkt Remote Server Administration Tools - Role Administration Tools -
Active Directory Domain Services Tools die Komponente Active Directory Domain Controller Tools eingeschaltet werden.
Anschließend erscheinen unter Systemsteuerung\Verwaltung die drei AD-Snap Ins.

Wie können nun zu einem späteren Zeitpunkt die Benutzer in der GUI angezeigt werden, denen Berechtigungen auf Objekte erteilt wurden?

Wurden mit dem Objektdelegierungsassistenten Rechte an einen Benutzer oder an eine Gruppe delegiert, bietet der Assistent
zu einem späteren Zeitpunkt keine Möglichkeit an die delegierten Berechtigungen anzuzeigen. Stattdessen muss in der
MMC Active Directory-Benutzer und -Computer unter Ansicht die Option Erweiterte Features aktiviert werden, damit in den
Objekteigenschaften der Reiter Sicherheit erscheint.

Anschließend werden im Reiter Sicherheit die berechtigten Personen auf das Objekt angezeigt. Im Reiter Sicherheit erscheint
mit einem Klick auf Erweitert die DACL (erweiterten Sicherheitseinstellungen) des Objekts. Dort werden mit Auswahl des
Benutzers bzw. der Gruppe und einem Klick auf Bearbeiten, die exakten Berechtigungen des Benutzers/der Gruppe angezeigt.
Die bereits vergebenen Berechtigungen lassen sich auch mit DSACLS in der Kommandozeile anzeigen, was weiter unten erläutert wird.

Sollen hingegen die delegierten Berechtigungen von einem Sicherheitsprinzipal (Benutzer, Gruppen) entzogen werden,
so genügt es das Sicherheitsprinzipal aus der ACL (oder aus der DACL) des Objekts zu entfernen.

Der Objektdelegierungsassistent

Bearbeiten der Discretionary Access Control List (DACL)

In den Eigenschaften eines Objekts wird der Reiter Sicherheit, von dem aus man in die erweiterten Sicherheitseinstellungen gelangt,
standardmäßig mit Absicht nicht angezeigt. Der Administrator soll zum delegieren von Berechtigungen den Assistenten verwenden,
damit das Durchsetzen der Vererbung durchgeführt wird. Der Administrator der im Active Directory weniger versiert ist sollte
weitestgehend den Assistenten verwenden. Für viele Administratoren ist diese Vorgehensweise ausreichend, für andere wiederum nicht.
Der erfahrene Administrator der weiß was er tut, kann anstatt den Assistenten zu verwenden direkt im security descriptor
(in den erweiterten Sicherheitseinstellungen) eines Objekts die Delegierung vornehmen.

Denn der Delegierungsassistent macht nichts anderes, als den Administrator durch die erweiterten Sicherheitseinstellungen eines Objekts durchzuleiten.

Damit wie im o.g. ersten Beispiel der Benutzersupport in den Eigenschaften der Benutzerkonten die Option Konto läuft ab
konfigurieren kann, gilt es die Eigenschaften von dem Standard-Container Users oder einer OU aufzurufen. Im Reiter Sicherheit,
der nur erscheint wenn in der MMC Active Directory-Benutzer und -Computer unter „Ansicht“ die Option „Erweiterte Features“
aktiviert ist, wird anschließend mit Erweitert die DACL des Containers aufgerufen. Mit Hinzufügen gibt man dann die
gewünschte Gruppe an. Im darauffolgenden Fenster Berechtigungseintrag für <Sicherheitsprinzipal>
(was das Access Control Entry, kurz ACE darstellt) ist im Reiter Eigenschaften im Feld Übernehmen für die Einstellung
Untergeordnete „Benutzer“-Objekte (unter Windows Server 2003 heißt es „Benutzer“-Objekte) auszuwählen. Zum Schluss gilt
es in der Spalte Zulassen die Berechtigung „accountExpires“ schreiben auszuwählen.

Oder wenn der Benutzersupport gesperrte Benutzerkonten entsperren soll, ist bei gleicher Vorgehensweise die Berechtigung
„lockoutTime“ schreiben und im Fall der Anmeldezeiten die Berechtigung „logonHours“ schreiben zuzulassen.

Wird die Delegierung der Berchtigungen auf einer OU ausgeführt die weitere untergeordnete OUs enthält, kann mit der Option
Berechtigungen nur für Objekte und/oder Container in diesem Container übernehmen bestimmt werden, ob die vergebenen
Berechtigungen vererbt werden sollen oder nur für diese eine OU gelten.

Wenn man sich das Fenster Berechtigungseintrag für… genauer ansieht, dürften einem die Einstellungen bereits durch den
Delegierungsassistenten bekannt vorkommen.

Natürlich muss man vor der Delegierung wissen, welches Attribut delegiert werden soll. Hinter welchem Feld im Snap-In
Active Directory-Benuzter und -Computer welches Attribut steckt, erfährt man auf dieser Seite:

User Object User Interface Mapping (Windows)

Ein anderer Weg wäre, einen Export des Objekts mit CSVDE oder LDFIDE durchzuführen,
um herauszufinden welche Attribute delegiert werden sollen:

LDIFDE - LDAP Data Interchange Format Data Exchange

DSACLS

Die Active Directory-Objektberechtigungen lassen sich neben der grafischen Oberfläche, auch mit dem Kommandozeilentool
DSACLS anzeigen sowie bearbeiten. Wer zum delegieren von Berechtigungen die Kommandozeile bevorzugt oder das anpassen
von Berechtigungen mit einem Skript erledigen möchte, der kann dies mit DSACLS tun. Mit diesem Befehlszeilenprogramm ist es
möglich an einer Vielzahl von Objekten gleichzeitig die Berechtigungen, dass bedeutet die Zugriffssteuerungseinträge
(Access Control Entries, ACEs) in der Zugriffssteuerungsliste (Access Control List, ACL) anzuzeigen und zu verändern.

Mit DSACLS lassen sich auch die Berechtigungen von Objekten im „Active Directory Lightweight Directory Services“
(kurz AD LDS, ehemals ADAM) Umfeld bearbeiten.

Unter Windows 2000 sowie Windows Server 2003 befindet sich das DSACLS in den Windows Support Tools, die sich wiederum auf
der Windows 2000 sowie Windows Server 2003 CD im Verzeichnis Support\Tools befinden und im Windows Server 2008 bereits integriert ist.

Der Befehl für DSACLS sieht folgendermaßen aus (alles in einer Zeile):

Dsacls "<Containerpfad>" /I:S /G "<Domäne>\<Gruppe>":<Berechtigungen>;<Attribute>;<Objekt>

Dabei gilt Folgendes:

Mit <Containerpfad> wird der Distinguished Name (DN) des Objekts (z. B. der Container Users oder eine Organisationseinheit)
angegeben, worauf die Berechtigungen gelten sollen.
Mit dem Parameter </I:Option> wird die Konfiguration für die Vererbung vorgenommen. Bei den Optionen kann man
zwischen drei Möglichkeiten wählen:

P = Bei dieser Option werden die Berechtigungen auf einer Ebene angewandt.
S = Hierbei werden die Berechtigungen nur auf untergeordnete Objekte vererbt (Subobjects).
T = Mit dieser Option werden die Berechtigungen für das angegebene Objekt und alle darunterliegenden Objekte vererbt.
Durch den Parameter </G> (was für Grant steht) wird die Berechtigung zum „Zulassen“ für <Domäne>\<Gruppe> gesetzt.
Zum verweigern wäre der Parameter </D> (Denied) anzugeben.
Mit der Angabe <Domäne>\<Gruppe> wird die Gruppe angegeben, an die Berechtigungen delegiert werden sollen.
Durch die Angabe von <Berechtigungen> werden der angegebenen Gruppe die entsprechenden Berechtigungen erteilt.
Die möglichen Berechtigungen die im Zusammenhang mit den Parametern </G> und </P> verwendet werden können, wären:

CA = Control Access
CC = Create all child Objects
DC = Delete all Child Objects
DT = Delete Subtree
GA = Generic All
GE = Generic Execute
GR = Generic Read
GW = Generic Write
LC = List Contents
LO = List Object
RC = Read permissions
RP = Read all Properties
SD = Delete
WD = Modify Permissions
WO = Modify Owner
WP = Write all Properties
WS = Write Self
Auf welches Attribut die vergebenen Berechtigungen wirken sollen, wird mit dem Eintrag <Attribute> bestimmt.
Der Eintrag <Objekt> gibt das Objekt an (Benutzer, Gruppe, etc.), mit dem das Attribut verknüpft ist.

Sollen die drei in der grafischen Oberfläche aufgeführten Beispiele mit Dsacls durchgeführt werden, so lauten die Befehle wie folgt.

Der Gruppe First Level Support wird in der Domäne intra.dikmenoglu.de mit diesem Befehl das Recht delegiert, unterhalb des
Standard-Containers Users die Option Konto läuft ab in den Eigenschaften der Benutzerkonten zu konfigurieren:
Dsacls „CN=Users,DC=intra,DC=dikmenoglu,DC=de“ /I:S /G “intra.dikmenoglu.de\First Level Support”:WP;accountExpires;User.

Die Sperrung der Benutzerkonten unterhalb des Containers Users kann der First Level Support mit diesem Befehl aufheben:
Dsacls „CN=Users,DC=intra,DC=dikmenoglu,DC=de“ /I:S /G “intra.dikmenoglu.de\First Level Support”:WP;lockoutTime;User.

Mit diesem Befehl kann der First Level Support die Anmeldezeiten in den Eigenschaften der Benutzerkonten einstellen:
Dsacls „CN=Users,DC=intra,DC=dikmenoglu,DC=de“ /I:S /G “intra.dikmenoglu.de\First Level Support”:WP;logonHours;User.

Weitere Dsacls-Beispiele

Die bereits delegierten Berechtigungen lassen sich komfortabler auf der Kommandozeile anzeigen als in der GUI.
Dort lassen sich die aktuellen Berechtigunen eines Objekts mit folgendem Befehl anzeigen: Dsacls <DN des Objekts>.

Möchte man sich die Berechtigungen des Standard-Container Users anzeigen lassen
(wobei der DNS-Name der Domäne intra.dikmenoglu.de lautet), so heißt der Befehl:
Dsacls CN=Users,DC=intra,DC=dikmenoglu,DC=de.
Soll das Feld Beschreibung in den Eigenschaften eines Clients im Standard-Container Computers delegiert werden,
so ist dieser Befehl auszuführen:
Dsacls "CN=Computers,DC=intra,DC=dikmenoglu,DC=de" /G "<Domäne>\<Gruppe>":WP;description;computer /I:S.
Wenn das Recht zum zurücksetzen von Benutzer-Kennwörtern unterhalb einer OU vergeben werden soll,
so lautet der Befehl folgendermaßen:
Dsacls "OU=OU-Name,DC=intra,DC=Domäne,DC=TLD" /I:S /G <Domäne>\<Gruppe>:CA;Reset Password;User.
Die Benutzergruppe Techniker erhält unterhalb einer OU mit diesem Befehl die Berechtigung, die Gruppenmitgliedschaften zu pflegen:
Dsacls "OU=OU-Name,DC=intra,DC=Domäne,DC=TLD" /I:S /G <Domäne>\Techniker:WP;member;group.

Danach kann die Gruppe Techniker in den einzelnen Gruppen die unterhalb der angegebenen OU existieren,
Benutzer entfernen sowie hinzufügen.
Die delegierten Berechtigungen einer Person lassen sich auf folgende Weise entfernen:
Dsacls <DN des Objekts> /R <Domäne>\<Benutzername>.

Am Beispiel des Containers Users würde der Befehl also so lauten:
Dsacls CN=Users,DC=intra,DC=dikmenoglu,DC=de /R intra.dikmenoglu.de\Yusuf.

Hinweis: Alle Parameter von DSACLS sind case sensitive und werden groß geschrieben!

Des Weiteren eignet sich das DSACLS auch sehr gut, um die standardmäßige Sicherheitseinstellungen eines Objekts wiederherzustellen.
Die standardmäßigen Sicherheitsinformationen erhält jedes Objekt durch das Active Directory-Schema. Jedes erstellte Objekt erhält
durch das im entsprechenden classObject enthaltene Attribut Default-Security-Descriptor seine Sicherheitsinformationen.

Das bedeutet konkret, wenn z.B. ein Benutzer erstellt wird, werden die Sicherheitsinformationen vom Attribut defaultSecurityDescriptor
das in der Klasse User enthalten ist, auf das Benutzerkonto angewendet. Die Klasse User befindet sich in der Schemapartition, im Pfad:
CN=User,CN=Schema,CN=Configuration,DC=intra,DC=dikmenoglu,DC=de.

So erhält nun jedes Objekt bei seiner Erstellung durch den defaultSecurityDescriptor der jeweiligen Klasse seine Sicherheitsinformationen.
Die Sicherheitsinformationen werden im Attribut defaultSecurityDescriptor im SDDL-String Format angegeben. Ausserdem bekommt das
Objekt durch die darüberliegenden Einheiten (Domäne, OU) weitere Berechtigungen vererbt.

Wenn nun im laufe der Zeit viele Berechtigungen auf einem Objekt vergeben wurden und man selbst keinen Überblick mehr darüber hat,
lassen sich die Sicherheitseinstellungen für das Objekt auf die im Schema definierten Standardeinstellungen zurücksetzen.
Der Befehl dazu lautet: Dsacls <DN des Objekts> /S.

Weitere Informationen:
Delegierte AD-Berechtigungen anzeigen und entfernen
How to Use Dsacls.exe in Windows Server 2003 and Windows 2000
Using Scripts to Delegate Control of Active Directory: Working with Property Sets
Windows-Verwaltung: Delegieren von Befugnissen in Active Directory
Bewährte Methoden zum Delegieren der Active Directory-Verwaltung
How to change the default permissions on GPOs in Windows 2000 and Windows Server 2003

Sunday, June 01, 2008 1:39:58 PM (W. Europe Standard Time, UTC+01:00)

Active Directory | Objektverwaltung |