Möchte man Rechte an ein Sicherheitsprinzipal wie z.B. an einen Benutzer oder besser an eine Gruppe im Active Directory (AD) delegieren, kann man das über den Objektdelegierungsassistenten, die Discretionary Access Control List (kurz DACL) oder mit dem Kommandozeilentool DSACLS durchführen.
Objektdelegierungen einrichten
Führt man die Delegierung über die grafische Oberfläche (GUI) mit dem Delegierungsassistenten oder über die DACL durch, ist es durchaus möglich, dass das gewünschte Attribut auf das man die entsprechenden Rechte erteilen möchte in der GUI nicht angezeigt wird. Denn standardmäßig wird nicht jedes Attribut in der GUI angezeigt, um die Liste der angezeigten Attribute übersichtlich zu halten.
Das ist aber auch nicht weiter tragisch, da es ohnehin empfohlen ist die Delegierung mit DSACLS durchzuführen. Denn somit hat man es zum einen mit der Dokumentation einfacher und zum anderen, lassen sich die erteilten Rechte im AD schnell wieder entfernen. Im Gegensatz zur GUI existieren in der Kommandozeile keine Beschränkungen und in Verbindung mit einem Skript, können Delegierungen einfach durchgeführt werden. Bei der Delegierung mit dem Kommandozeilentool muss man natürlich das Attribut kennen, auf das man Rechte erteilen möchte.
Siehe auch:
Die Active Directory-Attribute hinter den Feldnamen
Wer die Delegierung doch lieber über die GUI durchführen möchte, der kann die gefilterten Attribute die standardmäßig nicht angezeigt werden zum Vorschein bringen. Dazu muss die Datei „dssec.dat“ die sich seit Windows 2000 im Verzeichnis „%systemroot%\System32\“ befindet bearbeitet werden.
Möchte man z.B. die Attribute physicalDeliveryOfficeName (das Feld “Büro” in den Eigenschaften eines Benutzerobjekts) oder sn (Nachname eines Benutzers) zum Vorschein bringen, muss in der Datei „dssec.dat“ im Abschnitt [User] hinter den jeweiligen Attributen die Zahl 7 auf 0, 1 oder 2 geändert werden.
Die Zahlen bedeuten:
7 = Das Attribut wird in der GUI nicht angezeigt.
0 = Es werden die Eigenschaften „lesen“ und „schreiben“ für das Attribut angezeigt.
1 = Es wird nur die Schreib-Eigenschaft eines Attributs angezeigt.
2 = Es wird nur die Lese-Eigenschaft eines Attributs angezeigt.
Wurde die Datei dssec.dat bearbeitet, muss anschließend die MMC Active Directory-Benutzer und -Computer neu gestartet werden, damit das gewünschte Attribut angezeigt wird.
Eine andere Variante ist, dass man bei der Objektdelegierung über die GUI beim erstellen eines benutzerdefinierten Tasks nicht beim "Zuweisen der Verwaltung von" die Option "Benutzer"-Objekte auswählt, sondern die Objektklasse "InetOrgPerson"-Objekte. Danach hat man auch Zugriff und die standardmäßig nicht eingeblendeten Attribute und kann diese an die entsprechende Gruppe delegieren.
Mit DSACLS könnte man das Schreibrecht auf das Attribut physicalDeliveryOfficeName (Feldname: Büro) einer Gruppe wie folgt erteilen:
DSACLS "<DN der OU>" /G "<Gruppe>:WP;physicalDeliveryOfficeName;user" /I:S
Das Schreibrecht auf die Nachnamen aller Benutzer die sich in einer OU befinden, lässt sich einer Gruppe folgendermaßen delegieren:
DSACLS "<DN der OU>" /G "<Gruppe>:WP;sn;user" /I:S
Weitere Informationen:
Der Objektdelegierungsassistent
Das aktivieren/deaktivieren eines Benutzerkontos delegieren
Delegierte AD-Berechtigungen anzeigen und entfernen
How to modify the filtered properties of an object
Möchte der Administrator eine LDAP-Abfrage durchführen oder eine Objektdelegierung im Active Directory (AD) einrichten, so muss er wissen welches Attribut hinter dem Feld z.B. in der MMC Active Directory-Benutzer und –Computer (dsa.msc) dahinter steckt, damit er seine Aufgabe durchführen kann.
Die Attribute die hier aufgezeigt werden beziehen sich auf die Felder in der MMC dsa.msc.
Die Attribute hinter den Feldern eines Benutzerkontos
Die Registerkarte: Allgemein
Die Registerkarte: Adresse
Die Registerkarte: Konto
Die Registerkarte: Profil
Die Registerkarte: Rufnummern
Die Registerkarte: Organisation
Die Registerkarte: Mitglied von
Die Übersicht in der MMC "dsa.msc"
Die Attribute hinter den Feldern eines Gruppenkontos
Die Registerkarte: Allgemein
Die Registerkarte: Mitglieder
Die Registerkarte: Mitglied von
Die Registerkarte: Verwaltet von
Die Attribute hinter den Feldern einer Organisationseinheit (OU)
Die Registerkarte: Allgemein
Die Registerkarte: Verwaltet von
Die Attribute in der Registerkarte "Objekt"
Diese Registerkarte kommt in den Eingenschaften einer OU, eines Benutzer-, Gruppen- oder Computerkontos erst dann zum Vorschein, wenn im Snap-In Active Directory-Benutzer und -Computer unter Ansicht die Option Erweiterte Funktionen aktiviert wurde.
Die Attribute hinter den Feldern eines Computerkontos
Die Registerkarte: Allgemein
Die Registerkarte: Betriebssystem
Die Registerkarte: Mitglied von
Die Registerkarte: Standort
Die Attribute hinter den Feldern eines Druckers
Die Registerkarte: Allgemein
Die Attribute hinter den Feldern eines "Kontakts"
Die Registerkarte: Allgemein
Die Registerkarte: Adresse
Die Registerkarte: Rufnummern
Die Registerkarte: Organisation
Weitere Informationen:
Gespeicherte Abfragen
Active Directory - Abfrage
All Attributes (Windows)
All Classes (Windows)
Mappings for the Active Directory Users and Computers Snap-in (Windows)
Im Active Directory (AD) lassen sich Berechtigungen durch die folgenden Möglichkeiten an die entsprechenden Personen delegieren:
-
Durch den Assistenten zum Zuweisen der Objektverwaltung.
-
Durch das Bearbeiten der Discretionary Access Control List (DACL) im security descriptor des Objekts.
-
Mit dem Kommandozeilentool DSACLS.
Bis auf den Delegierungsassistenten lassen sich mit den beiden anderen Methoden die vergebenen AD-Berechtigungen zum einen anzeigen und zum anderen auch entfernen. Anzeigen sowie Löschen lassen sich die Rechte auch mit dem Kommandozeilentool DSREVOKE.
Der Objektdelegierungsassistent
Ein ungeübter Administrator sollte stets den Delegierungsassistenten verwenden, um die notwendigen Berechtigungen an die gewünschten Personen zu delegieren. Doch leider lassen sich die bereits delegierten Rechte auf einem Objekt durch den Objektdelegierungsassistenten weder anzeigen, noch entfernen. Der Assistent dient einzig und alleine dem vergeben von AD-Berechtigungen.
Der Objektdelegierungsassistent
Die Discretionary Access Control List (DACL)
Über die DACL lassen sich zum einen die Zugriffsrechte auf ein bestimmtes AD-Objekt vergeben sowie entfernen und zum anderen, kann man sich die vergebenen Berechtigungen anzeigen lassen. Damit man sich die vergebenen Berechtigungen z.B. auf einer Organisationseinheit (OU) in der grafischen Oberfläche anzeigen lassen kann, muss zuerst in der MMC Active Directory-Benutzer und -Computer unter Ansicht die Option Erweiterte Funktionen aktiviert werden. Danach erscheint in den Eigenschaften der OU der Reiter Sicherheit. Anschließend kann im security descriptor, den erweiterten Sicherheitseinstellungen der OU, die Person ausgewählt und mit einem Klick auf Bearbeiten… die gesetzten Berechtigungen eingesehen werden. Sollen die vergebenen Berechtigungen dem Benutzer entzogen werden, so ist der Benutzer aus der ACL (Access Control List) im Reiter Sicherheit des Objekts, zu entfernen. Ist es hingegen erforderlich bloß eine einzelne Berechtigung z.B. auf ein einziges Attribut dem Benutzer zu entziehen, so kann lediglich der ACE (Access Control Entrie) Eintrag aus der DACL entfernt werden.
Das Kommandozeilentool DSACLS
Der versierte Administrator kann recht einfach und das sogar automatisiert in einem Skript, wiederkehrende Berechtigungen im AD und in AD LDS (Active Directory Lightweight Directory Services, ehemals ADAM) mit DSACLS delegieren. Denn über die Kommandozeile lassen sich die Berechtigungen auf einem AD-Objekt mit DSACLS, das sich unter Windows 2000 sowie Windows Server 2003 in den Windows Support Tools befindet (z.B. auf der Windows Server 2003 CD im Verzeichnis Support\Tools) und ab Windows Server 2008 bereits im Betriebssystem integriert ist, ebenfalls vergeben sowie entfernen. Der Vorteil an diesem Tool ist, dass man aufwändige Berechtigungen skriptbasiert delegieren und im Fehlerfall die vergebenen Berechtigungen leichter entfernen kann.
Mit dem folgenden Befehl werden die Berechtigungen für die OU „IT“ (im dsa.msc) in einer TXT aufgelistet:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=de > C:\Dsacls.txt
Das DSACLS eignet sich auch sehr gut dazu, um die standardmäßige Sicherheitseinstellungen eines Objekts wiederherzustellen. Die standardmäßigen Sicherheitsinformationen erhält jedes Objekt durch das Active Directory-Schema. Denn 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=kaan,DC=dikmenoglu,DC=de.
Dadurch erhält nun jedes Objekt bei seiner Erstellung durch den defaultSecurityDescriptor der jeweiligen Klasse seine Sicherheitsinformationen. Die Sicherheitsinformationen werden im Attribut defaultSecurityDescriptor im security descriptor definition language Format (SDDL-String) angegeben. Ausserdem bekommt das Objekt durch die darüberliegenden Einheiten (Domäne, OU) weitere Berechtigungen vererbt.
Hat man an einem AD-Objekt die Berechtigung so verändert das man den Überblick verloren hat, so lassen sich die Sicherheitseinstellungen die für diese Objektklasse im Schema des AD definiert ist wie folgt wiederherstellen: Dsacls <DN des Objekts> /S
Die Standardberechtigungen der OU IT in der Domäne kaan.dikmenoglu.de lassen sich wie folgt zurücksetzen:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=de /S
Befinden sich im Distinguished Name (DN) des Objekts Leerzeichen, muss dieser in „Anführungszeichen“ gesetzt werden.
Hinweis für Windows Server 2008: Wird mit dem Parameter /S unter Windows Server 2008 die Berechtigungen eines Objekts zurückgesetzt, erhält man in der Kommandozeile die Fehlermeldung Falscher Parameter und die Meldung Der Befehl wurde nicht erfolgreich ausgeführt. Aber die Berechtigungen werden trotzdem zurückgesetzt. Der Befehl funktioniert.
Die Berechtigungen eines einzelnen Benutzers oder einer Gruppe lassen sich mit diesem Befehl entfernen:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=de /R <DNS- oder NetBIOS Name der Domäne>\<sAMAccountName des Benutzers oder der Gruppe>
Der Befehl mit dem DNS-Namen der Domäne sieht dann so aus:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=DE /R kaan.dikmenoglu.de\Yusuf
Der Benutzer oder die Gruppe kann auch mit dem userPrincipalName (UPN) angegeben werden:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=DE /R Yusuf@kaan.dikmenoglu.de
Achtung: Die Parameter in Dsacls sind case-sensitive!
Das Kommandozeilentool DSREVOKE
Die vergebenen Berechtigungen können in Form von ACEs (Access Control Entries) auch mit dem Kommandozeilentool DSREVOKE angezeigt und entfernt werden. Dieses Tool muss aber zuerst von Microsoft heruntergeladen werden und kann anschließend unter allen Serverversionen eingesetzt werden (auch unter Windows Server 2008!). ACLs werden (nicht so wie bei DSACLS) bei diesem Tool nicht berücksichtigt.
Die einzelnen ACEs eines Benutzers oder einer Gruppe lassen sich mit diesem Befehl anzeigen:
Dsrevoke /Report <DN des Objekts> <NetBIOS Name (nicht DNS-Name!) der Domäne>\<sAMAccountName eines Benutzers oder einer Gruppe>
Welche Berechtigungen der Benutzer Yusuf auf der OU IT in der Domäne kaan.dikmenoglu.de hat, lässt sich wie folgt anzeigen:
Dsrevoke /Report OU=IT,DC=kaan,DC=dikmenoglu,DC=de Kaan-Dikmenoglu\Yusuf
Die an den Benutzer Yusuf delegierten AD-Berechtigungen auf der OU IT lassen sich mit diesem Befehl entfernen:
Dsrevoke /Remove OU=IT,DC=kaan,DC=dikmenoglu,DC=de Kaan-Dikmenoglu\Yusuf
Die anschließende Sicherheitsabfrage zum Löschen muss mit einem “y” bestätigt werden.
Alle Berechtigungen eines Benutzers oder einer Gruppe ab einem bestimmten Container wie z.B. einer OU und somit auch von den darunterliegenden Objekten werden mit diesem Befehl entfernt:
Dsrevoke /Remove /root:<DN der OU> <NetBIOS Name der Domäne\sAMAccountName>
Download details: DSREVOKE.EXE
Weitere Informationen:
Delegierte Berechtigungen im AD verstehen
Objektdelegierungen einrichten
Das aktivieren/deaktivieren eines Benutzerkontos delegieren
How to Use Dsacls.exe in Windows Server 2003 and Windows 2000
When you use the Dsrevoke command-line tool to report permissions for all the organizational units in a Windows Server 2003-based domain, the tool may not return all the access control entries
Damit der tägliche Benutzersupport nicht alleine auf den Schultern des Administrators lastet, kann er diverse Aufgaben
im Active Directory an den First Level Support oder an EDV-versierte Mitarbeiter delegieren.
Siehe auch:
Objektdelegierungen einrichten
Der Objektdelegierungsassistent
Delegierte Berechtigungen im AD verstehen
Nun kann es auch erforderlich werden, lediglich das Recht zum aktivieren bzw. deaktivieren eines Benutzerkontos
im Active Directory zu delegieren. Der Haken an diesem Vorhaben ist, dass nicht ein dediziertes Recht oder Attribut zum delegieren
dieser Anforderung existiert. Die Option Konto ist deaktiviert um das es hier geht, findet man in den Eigenschaften eines Benutzerkontos
im Reiter Konto unter den Kontooptionen.
Die Kontooptionen werden dabei weitestgehend über das Attribut User-Account-Control gesteuert, das sich aus einer Bitmaske zusammensetzt.
Das Attribut userAccountControl existiert sowohl in Benutzer- als auch in Computerkonten. Wenn z.B. ein Benutzerkonto erstellt wird,
hat das userAccountControl den Wert 512 (Hex: 0x0200). Je nachdem ob und welche Optionen in den Kontooptionen zusätzlich aktiviert werden,
verändert sich auch der Wert im userAccountControl. Standardmäßig enthält das userAccountControl eines Clients den Wert 4096 (Hex: 0x1000).
Dadurch das im userAccountControl verschiedene Werte enthalten sein können, unterscheidet es sich wesentlich von anderen Attributen
die lediglich einen Wert enthalten können. Die einzelnen Werte die das userAccountControl enthalten kann, werden in diesem Artikel erläutert:
How to use the UserAccountControl flags to manipulate user account properties
Wenn nun einem Sicherheitsprinzipal (so wie es z.B. Benutzer oder Gruppen darstellen) das Schreibrecht für das Attribut userAccountControl
auf einem Container delegiert wird, erhält das Sicherheitsprinzipal auf eine Reihe von Kontooptionen das Schreibrecht, auf die im Container
befindlichen Benutzerobjekte. Nach der Delegierung stehen dem Sicherheitsprinzipal folgende Kontooptionen zur Verfügung:
Die Delegierung für das userAccountControl kann in der MMC Active Directory-Benutzer und -Computer (ADBuC) durch den
Objektdelegierungsassistenten durchgeführt werden. Mit einem Rechtsklick auf den entsprechenden Container gilt es zuerst
die Option Objektverwaltung zuweisen… auszuwählen. Nach der Willkommensseite ist der Benutzer oder idealerweise
eine Gruppe auszuwählen, die für die Verwaltung der Kontooptionen zuständig sein soll. Danach gilt es die Option
Benutzerdefinierte Tasks zum Zuweisen erstellen und anschließend unter der Option Folgenden Objekten im Ordner
lediglich die „Benutzer“-Objekte auszuwählen. Im darauffolgenden Schritt gilt es dann nur die Option Eigenschaftenspezifisch
und unter den Berechtigungen die Option userAccountControl schreiben zu aktivieren.
Neben dem Assistenten kann die Berechtigung userAccountControl schreiben auch in der Discretionary Access Control List (kurz DACL)
des Containers, an die Gruppe delegiert werden. Dazu ruft man mit einem Rechtsklick auf dem gewünschten Container die Eigenschaften
auf und wechselt zum Reiter Sicherheit. Der Reiter Sicherheit erscheint nur, wenn in der MMC ADBuC unter Ansicht die Option
„Erweiterte Funktionen“ aktiviert wurde. Mit einem Klick auf „Erweitert“ gelangt man zu den erweiterten Sicherheitseinstellungen,
der sogenannten DACL. Dort angelangt, gilt es mit „Hinzufügen“ zuerst eine Gruppe und im Reiter „Eigenschaften“ im Feld
„Übernehmen für“ die „Benutzer“-Objekte auszuwählen. Zum Schluss muss die Berechtigung
„userAccountControl“ schreiben zugelassen werden.
Über die Kommandozeile lässt sich die Delegierung mit dem Tool DSACLS, das sich unter Windows 2000 sowie Windows Server 2003
in den Windows Support Tools befindet und im Windows Server 2008 bereits integriert ist, einrichten. Der Befehl lautet wie folgt:
DSACLS “<Containerpfad>” /I:S /G “<Domäne>\<Gruppe>”:WP;userAccountControl;User
Die Kontooptionen können aber noch weiter eingeschränkt werden. Der Zugriff auf die beiden Optionen Kennwort läuft nie ab
sowie Kennwort mit umkehrbarer Verschlüsselung speichern kann in einem zweiten Schritt, der Gruppe verweigert werden.
Dazu sind zuerst auf der Domänenebene die Eigenschaften aufzurufen. Danach ruft man im Reiter „Sicherheit“ mit einem Klick
auf „Erweitert“ die erweiterten Sicherheitseinstellungen auf. Mit „Hinzufügen“ gilt es die Gruppe auszuwählen, die im ersten Schritt
das Schreibrecht auf das userAccountControl erhalten hat. Im Reiter „Objekt“ ist im Feld „Übernehmen für“ die Option
„Nur dieses Objekt“ zu wählen. Anschließend gilt es die beiden erweiterten Berechtigungen, die erst seit Windows Server 2003
zur Verfügung stehen, zu verweigern:
Man achte auf die grandiosen und vor allem eindeutigen Bezeichnungen!
Weitere Informationen:
Delegierte AD-Berechtigungen anzeigen und entfernen
Minimum permissions are needed for a delegated administrator to force password change at next logon procedure
Viele Administratoren die eine Active Directory Umgebung betreuen, werden bereits den Objektdelegierungsassistenten kennengelernt haben.
Dieser Assistent der sich zum einen in der MMC Active Directory-Benutzer und -Computer und zum anderen,
in der MMC Active Directory-Standorte und -Dienste aufrufen lässt, ist dem Administrator bei der Zuweisung von
Active Directory-Berechtigungen behilflich. Mit dem Assistenten können bei den zur Verfügung stehenden allgemeinen Tasks,
schnell Berechtigungen für einige typische Fälle zugewiesen werden. An dieser Stelle bietet der Assistent aber nur einen
kleinen Teil der Möglichkeiten an.
Der Assistent ist dabei nur eine von insgesamt drei möglichen Varianten, um Benutzern entsprechende Rechte im Active Directory zu delegieren.
Die beiden anderen Varianten wären, dass direkte bearbeiten der erweiterten Sicherheitseinstellungen (im security descriptor) eines Objekts
und das Kommandozeilentool DSACLS. Wobei gerade die Administratoren, die sich nicht so sehr im Active Directory auskennen,
den Delegierungsassistenten verwenden sollten.
Weitere Details werden in den beiden folgenden Artikeln erläutert:
Objektdelegierungen einrichten
Delegierte Berechtigungen im AD verstehen
Was viele Administratoren nicht wissen ist, das beim Ausführen des Delegierungsassistenten an dem Punkt
Zuzuweisende Aufgaben die dort aufgeführten allgemeinen Tasks, aus einer Textdatei stammen.
Diese Textdatei die den Namen delegwiz.inf trägt, existiert auf jedem Domänencontroller (und jedem Mitgliedsserver) und ist
jederzeit veränderbar. Die Datei delegwiz.inf befindet sich unter Windows 2000 sowie Windows Server 2003 im Verzeichnis
%windir%\Inf und unter Windows Server 2008 im Verzeichnis %windir%\system32.
Standardmäßig sind dort unter Windows 2000 bereits sieben und unter Windows Server 2003 sowie Windows Server 2008
13 Aufgaben vordefiniert. Je nachdem in welcher MMC und auf welcher Ebene der Delegierungsassistent ausgeführt wird,
variiert die Anzeige der allgemeinen Tasks. Die vordefinierten allgemeinen Aufgaben dienen dazu, eine Reihe von Berechtigungen
und nicht gezielt ein einzelnes Recht zu vergeben.
Der Administrator kann weitere Vorlagen in die delegwiz.inf Datei eintragen, um sich damit seine tägliche Arbeit zu erleichtern.
Denn wiederkehrende Aufgaben können in die Datei delegwiz.inf mit aufgenommen werden und stehen dann, ab sofort für die Zukunft
als weitere allgemeine Tasks zur Verfügung. Unter Windows Server 2008 muss zuerst der Administrator den Besitz der delegwiz.inf Datei
übernehmen und anschließend die Rechte anpassen. Danach kann die Datei auch unter Windows Server 2008 bearbeitet werden.
Es dürfte jedem klar sein, dass das erweitern der delegwiz.inf Datei durch zusätzliche Aufgaben dann auch nur auf dem einen DC erscheinen,
auf dem die Datei bearbeitet wurde. Auf den anderen DCs steht die hinzugefügte neue Aufgabe selbstverständlich nicht zur Verfügung.
Entweder man richtet dann die Delegierung im Active Directory nur über diesen einen DC für die Zukunft ein oder fügt die Änderung
in der delegwiz.inf auf allen anderen DCs hinzu. Eine andere Möglichkeit wäre die bearbeitete Datei im Nachhinein auf alle anderen
DCs zu kopieren.
Wenn man sich nun die Datei delegwiz.inf genauer anschaut, ist der Aufbau einer allgemeinen Aufgabe immer gleich.
Die wesentlichen Punkte einer Vorlage wären:
-
Für welche Container-Klasse steht die allgemeine Aufgabe zur Verfügung.
-
Die Beschreibung für die allgemeine Aufgabe.
-
Welche Berechtigungen werden erteilt, wenn die allgemeine Aufgabe delegiert wird.
Hier ein Beispiel aus der delegwiz.inf:
[DelegationTemplates]
Templates = template1, template2,…
;---------------------------------------------------------
[template1]
AppliesToClasses=domainDNS,organizationalUnit,container
Description="Erstellt, entfernt und verwaltet Benutzerkonten"
ObjectTypes=SCOPE, user
[template1.SCOPE]
user=CC,DC
[template1.user]
@=GA
;---------------------------------------------------------
Der Aufbau der Vorlage sieht folgendermaßen aus:
-
Bei dem Hinzufügen einer neuen Vorlage muss unter der Zeile [DelegationTemplates] zuerst ein neuer Eintrag template mit
einer fortlaufenden Nummer hinzugefügt werden. Dort sind bereits unter Windows Server 2003/2008 13 Einträge vorhanden.
Demzufolge muss beim Hinzufügen einer neuen Aufgabe der Eintrag template14 ergänzt werden.
Der nächste Eintrag würde dann template15 lauten usw.
-
Es folgt unter der gestrichelten Linie in eckigen Klammern die Angabe der Vorlagennummer [template14], die in der Zeile
[DelegationTemplates] angegeben wurde. Mit diesem Eintrag wird eine neue Vorlage eröffnet.
-
Die nächste Zeile AppliesToClasses gibt an, für welche Klassen diese Vorlage bei dem Einrichten einer Delegierung vorhanden sein soll.
Die einzelnen Klassen werden durch ein Komma getrennt. Falls also der Eintrag AppliesToClasses=organizationalUnit existiert
bedeutet dies, das diese Vorlage bei dem Ausführen des Delegierungsassistenten nur auf einer Organsationseinheit (OU) angezeigt wird.
Es können folgende Klassen eingetragen werden: container (dabei wird die Vorlage auf einem Container wie z.B. auf den
Standard-Containern Computers oder Users angezeigt), domainDNS (hier erscheint die Vorlage beim Ausführen des
Delegierungsassistenten auf der Domänenebene), organizationalUnit (die Vorlage erscheint auf einer Organisationseinheit) und
site (hierbei erscheint die Vorlage auf Standortebene).
ACHTUNG: Diese Werte sind case sensitive. Das bedeutet, bei den Einträgen ist auf die Groß-/Kleinschreibung zu achten!
Würde also als Wert anstatt organizationalUnit diese Schreibweise verwendet werden OrganizationalUnit,
so würde die Vorlage nicht auf OU-Ebene angezeigt werden.
-
Der nächste Eintrag Description dient zur Beschreibung dieser Vorlage. Der hier eingetragene Text wird beim Ausführen des
Delegierungsassistenten bei den allgemeinen Tasks angezeigt.
-
In der Zeile ObjectTypes können mehrere Werte enthalten sein. So könnten z.B. die Werte ObjectTypes=SCOPE, user eingetragen sein.
Hier werden die einzelnen Objekt-Klassen deren Berechtigungen angepasst werden sollen angegeben. Bei mehreren Einträgen werden
diese durch ein Komma getrennt. Die eigentlichen Berechtigungen werden dann jeweils in einer eigenen Zeile angegeben.
Mit dem Eintrag SCOPE wird definiert, für welche Objekte die zu vergebenen Berechtigungen gelten sollen.
Nämlich für „Dieses und alle untergeordneten Objekte“. Dabei ist es nicht zwingend, dass dieser Eintrag existiert.
-
Die Angabe von user=CC,DC unterhalb von [template1.SCOPE] gibt die zu vergebenen Berechtigungen an und zwar für die vorher
angegebene Klasse: ObjectTypes=SCOPE. Die Berechtigungen die im Security Descriptor Definition Language (SDDL)-String anzugeben
sind, CC sowie DC, stehen für „Create Child“ und „Delete Child“. Child steht in diesem Fall für Benutzerobjekte. Das bedeutet,
hier wird die Berechtigung für das erstellen sowie löschen von Benutzerkonten (user) vergeben.
-
Unterhalb des Eintrags [template1.user] existiert der Eintrag @=GA. Das @-Symbol gibt an, dass die Berechtigung auf allen Attributen
des Objekts, das in der Zeile ObjectTypes angegeben wurde, vergeben werden soll. Die Berechtigung GA steht für „Generic All“,
was Vollzugriff bedeutet. Der Eintrag @=GA bedeutet also, das der „Vollzugriff auf Benutzerobjekte“ gewährt wird. Möchte man
anstatt auf allen Attributen, bloß auf einem oder wenigen Attributen eines Objekts Berechtigungen vergeben, so kann dies mit
Angabe der Attribut-Namen und der gewünschten Berechtigung erreicht werden. Also z.B. so: lockoutTime=WP.
Siehe auch:
How to customize the task list in the Delegation Wizard
Soll z.B. das Entsperren von Benutzerkonten durch eine allgemeine Aufgabe delegiert werden,
so gilt es in der delegwiz.inf Datei diese Vorlage zu ergänzen:
;---------------------------------------------------------
[template14]
AppliesToClasses=domainDNS,organizationalUnit,container
Description="Benutzerkonten entsperren"
ObjectTypes=user
[template14.user]
lockoutTime=WP
;----------------------------------------------------------
Oder wenn man die Berechtigung zum verschieben von Computerkonten delegieren möchte, so kann die folgende Vorlage
dazu verwendet werden. Allerdings gilt es dann diese Aufgabe auf dem Quell- sowie Ziel-Container durchzuführen.
;---------------------------------------------------------
[template15]
AppliesToClasses=domainDNS,organizationalUnit,container
Description="Computerkonten verschieben"
ObjectTypes=SCOPE, computer
[template15.SCOPE]
computer=CC,DC
[template15.computer]
cn=WP
name=WP
;----------------------------------------------------------
Wer die Berechtigung zum verschieben von Objekten restriktiver handhaben möchte, der kann dies auf folgende Weise erledigen.
Zum verschieben eines Active Directoy-Objekts, sei es z.B. ein Benutzer-, Computer oder Gruppenkonto,
müssen die Rechte wie folgt gesetzt sein:
-
Es muss das Recht DELETE CHILD (DC) auf dem Quell-Container gesetzt werden.
-
Das Recht WRITE PROPERTIES (WP) für die beiden Eigenschaften RDN (das wäre das Attribut „name“)
sowie CN auf dem Quell-Container ist zu setzen.
-
Auf dem Ziel-Container muss das Recht CREATE CHILD (CC) gesetzt werden.
Nun könnte man die ersten beiden Punkte in einer Vorlage und den dritten Punkt in einer eigenen Vorlage erstellen. Denn es wird weder
das Recht CC im Quell-Container, noch die beiden Rechte DC und WP im Ziel-Container benötigt. Demzufolge muss auf dem Quell-Container
die Aufgabe mit den ersten beiden Punkten und auf dem Ziel-Container die Aufgabe mit dem dritten Punkt ausgeführt werden.
Falls das Recht Benutzerkonten zu verschieben delegiert werden soll, so reicht es die Einträge computer durch user
in dem template15 zu ersetzen.
Microsoft stellt auf dieser Seite insgesamt 70(!) Vorlagen zur Verfügung.
Dadurch stellt der Delegierungsassistent ein Werkzeug dar, womit sich viele alltägliche Delegierungsaufgaben lösen lassen.
Weitere Informationen:
Delegierte AD-Berechtigungen anzeigen und entfernen
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
Langsam aber sicher werden nun die letzten NT-Domänen in den Unternehmen zu einer Active Directory Umgebung migriert.
Die Administratoren die bereits seit längerem eine Active Directory Umgebung betreuen, haben sich bereits einiges an Wissen
die sie für eine Administration einer Active Directory-Domäne benötigen aufgebaut und andere wiederum, werden es noch tun.
In den Unternehmen die bereits seit längerem eine Active Directory Umgebung besitzen, wird langsam aber sicher der Ruf nach
gezielter Vergabe von Berechtigungen im Active Directory lauter und stärker. Gerade wenn Unternehmen fusionieren bzw. seit Jahren
stetig gewachsen sind, ist es zwingend notwendig gezielte Berechtigungen den Benutzern zu vergeben.
Im täglichen Leben des Administrators fallen viele Aufgaben an, die er möglichst zeitnah und zielgerecht auszuführen hat. Dabei hat er
bei der Ausführung seiner Aufgaben stets darauf zu achten, dass die Benutzer oder die IT-Support-Einheiten nur die Rechte in einem
Netzwerk erhalten, die sie für ihre Arbeit benötigen. Denn wenn Personen zu viele Rechte besitzen, kann das durchaus bedeuten das
im Endeffekt der Administrator dadurch einen unnötigen Mehraufwand hat. Daher lautet die Devise für den Administrator, nur soviel Rechte
zu vergeben wie sie auch tatsächlich benötigt werden, auch wenn das im ersten Moment mehr Arbeit für den Administrator bedeutet,
anstelle den Benutzer einfach in eine administrative Gruppe zu stecken und somit ggf. zuviele Rechte zu vergeben.
Eine weitere Grundregel wäre dabei, alle Benutzer die eine gleiche Anforderung haben (z.B. den Zugriff auf eine Ressource),
zu einer Sicherheitsgruppe hinzuzufügen und dieser Gruppe den Zugriff auf die Ressource zu gewähren, anstatt jedem einzelnen Benutzer
die Rechte auf die Ressource zu erteilen. Dabei hat sich das A-G-DL-P Prinzip etabliert. Oder anstelle den einzelnen Mitarbeitern aus dem
First-Level Support Domänen-Administrator Rechte zu geben, sollten die benötigten Rechte im Active Directory über die Objektverwaltung
oder mit dem Kommandozeilentool DSACLS entsprechend delegiert werden. Dabei ist es empfehlenswert, auch hier idealerweise einer
Sicherheitsgruppe die Rechte im Active Directory zu delegieren und nicht einzelnen Personen.
Damit ein Administrator das richtige Delegierungskonzept für seine Active Directory Gesamtstruktur erarbeiten kann,
muss er sich dessen bewußt sein, was technisch möglich ist und was nicht. Er sollte dabei auch die Hintergründe kennen.
Was passiert nun im Hintergrund, wenn einem Benutzer oder einer Sicherheitsgruppe Rechte im Active Directory durch die
Objektverwaltung oder durch das Kommandozeilentool DSACLS delegiert werden? Und woher weiß das Active Directory,
das der Benutzer der eine Aufgabe durchführen möchte, das auch darf?
Um diese Fragen zu beantworten, müssen in diesem Zusammenhang die Begriffe SID,
Access Token, ACL, ACE, SD, DACL, SACL und SDDL erläutert werden.
Security Identifier (SID)
Jedes Sicherheitsprinzipal wie Benutzer, Gruppen, Computer usw. erhalten beim erstellen in einer Active Directory-Umgebung
oder auch lokal, eine einmalige Objekt-GUID sowie Objekt-SID. Der Security Identifier (zu deutsch, Identifikationsnummer),
der Teil des security descriptors ist, dient zur eindeutigen Kennzeichnug eines Objekts (z.B. eines Benutzers). Der leserfreundliche Name
eines Sicherheitsprinzipal ist eher für den Menschen gedacht, da er sich Namen einfacher merken kann, als eine Zahlenkombination.
Jede Berechtigung die einem Benutzerkonto für den Zugriff auf Objekte bzw. Ressourcen zugewiesen wird, werden vom
Windows-Betriebsystem immer direkt der SID zugewiesen. Oder werden einem Benutzer Aufgaben im Active Directory delegiert,
werden die Berechtigungen ebenfalls direkt der SID zugewiesen.
Wird der Benutzer in eine andere Domäne verschoben, so ändert sich seine SID.
Denn in der SID ist auch die betreffende Domäne hinterlegt. Ein SID ist ein Zahlen-Array mit einer variablen Länge,
das sich wie folgt zusammensetzt:
S-1-5-21-956547467-2769573453-2154042951-500
S = SID
1 = Die Revisionsnummer
5 = Identifier Authority
21-956547467-2769573453-2154042951 = Domäne
500 = Benutzer (in diesem Beispiel, der Administrator)
Access Token
Wenn ein Sicherheitsprinzipal (security principal) wie es ein Benutzer darstellt, seinen Benutzernamen sowie das Kennwort im
Logon-Fenster an einem Client eingibt, werden diese Anmeldeinformationen an einen Domänencontroller (DC), den der Client
durch das DNS mitgeteilt bekommt, übermittelt. Der DC überprüft ob das richtige Kennwort passend zum Benutzernamen
eingegeben wurde. Falls dies der Fall sein sollte, erstellt der DC während dem Anmeldeprozess ein Access Token und falls nicht,
erhält der Benutzer eine Fehlermeldung das der Benutzername oder das Kennwort falsch sei. Das Token wird dabei vom
Local Security Authority (LSA) Prozess des DCs erstellt. Das Access Token enthält Informationen über die
Identität und Privilegien des Sicherheitsprinzipal. In dem Access Token sind die folgenden SIDs und Informationen enthalten:
-
Die SID des Benutzers (der Benutzername sAMAccountName oder UPN ist Schall und Rauch für die Systeme,
viel wichtiger ist die SID die dahintersteckt).
-
Falls vorhanden, die SID-History des Benutzers (von Migrationen).
-
Die SIDs von jeder domänenlokalen Gruppe, worin der Benutzer direkt oder transitiv Mitglied ist.
-
Die SIDs jeder gloablen Gruppe, in denen der Benutzer direkt sowie verschachtelt Mitglied ist und die SID-History der globalen Gruppen.
-
Die SIDs der universellen Gruppen in denen der Benutzer direkt sowie verschachtelt Mitglied ist, samt der SID-History
der universellen Gruppen. Dabei werden die Informationen zu den universellen Gruppenmitgliedschaften des Benutzers,
vom globalen Katalog (GC) geliefert.
-
Die SIDs von jeder BuiltIn Gruppe, in der der Benutzer direkt oder transitiv Mitglied ist.
-
Die SIDs von jeder lokalen Gruppen, in der der Benutzer direkt oder transitiv Mitglied ist.
-
Eine Liste mit Privilegien.
-
Andere Zugriffsinformationen.
Das Access Token hat allerdings eine Beschränkung. In einem Token für einen Sicherheitsprinzipal können maximal
1.024 Einträge enthalten sein. Daher sollte unbedingt darauf geachtet werden, das gerade wenn Benutzerkonten
über Jahre hinweg existieren und diese bereits mehrere Migrationen hinter sich haben, unbedingt die SID-History
nach jeder Migration zu bereinigen [1]. Sonst kann das später zu Problemen führen.
Bekommt der Benutzer bei der Windows-Anmeldung folgenden Fehler:
The system cannot log you on due to the following error:
During a logon attempt, the user`s security context accumulated too many security IDs
so liegt der Fehler darin, dass der Benutzer in zu vielen Gruppen enthalten ist oder die SID-History zu viele Einträge enthält.
Welche SIDs in dem Access Token enthalten sind, kann man sich mit dem Kommandozeilentool Whoami anzeigen lassen.
Der Befehl dazu lautet Whoami /All.
Wichtig ist zu wissen, dass Access Token wird nur ein einziges Mal und zwar während der Benutzeranmeldung erstellt.
Wird nun der Benutzer während seiner Benutzersitzung zu weiteren Gruppen hinzugefügt und es zeigt sich, dass der Benutzer
weiterhin auf die neue Ressource keinen Zugriff erhält, so sollte sich der Benutzer erneut anmelden, damit die neuen
Gruppeninformationen und somit die neuen Berechtigunen im Token enthalten sind.
Das Access Token in dem alle SIDs des Benutzers enthalten sind, ist quasi der Ausweis eines Benutzers im Netzwerk.
Jedes Objekt bzw. jede Ressource enthält auf der anderen Seite eine Zugriffskontrollliste (Access Control List, ACL).
Zu sehen ist die Zugriffskontrollliste in den Eigenschaften eines Objekts, im Reiter Sicherheit. In der Zugriffskontrollliste
eines Objekts stehen die SIDs (in Form von Namen) der zugriffsberechtigten Personen drin. Darin sind die Benutzer oder Gruppen
mit ihren entsprechenden Zugriffsrechten enthalten. Möchte nun ein Benutzer auf ein Objekt zugreifen, überprüft das
Windows-Betriebssystem das Access Token des Benutzers, mit der Zugriffskontrollliste des Objekts. Findet sich eine SID
die im Token enthalten ist auch in der Zugriffskontrollliste des Objekts wieder, erhält der Benutzer Zugriff auf das Objekt,
mit seinen dort definierten Rechten.
[1] How To Use Visual Basic Script to Clear SidHistory
Access Token Limitation
Access Control List (ACL)
Die Access Control List (zu deutsch, Zugriffskontrollliste), zu der die beiden Typen DACL und SACL gehören,
besteht aus Access Control Entries Einträgen. Die beiden ACL-Typen DACL und SACL befinden sich im security descriptor des
Objekts und sind Bestandteil der ACL. Die ACL ist eine Liste von festgelegten ACEs die spezifizieren, ob und mit welchen Rechten
der Zugriff auf ein Objekt erlaubt, verweigert oder erfolgreich bzw. fehlgeschlagen überwacht wird. Die Zugriffskontrollliste die in
den Eigenschaften eines jeden Objekts - im Reiter Sicherheit - zu finden ist, steuert den Zugriff auf ein Objekt. Damit der Reiter
Sicherheit in den Eigenschaften eines Benutzerkontos erscheint, ist in der MMC „Active Directory-Benutzer und -Computer“ (ADBuC)
unter „Ansicht“ die Option „Erweiterte Funktionen“ zu aktivieren.
Der Aufbau einer ACL sieht wie folgt aus:
ACL Size
Hier wird die Größe des zugewiesenen Speichers für die ACL gespeichert. Die Größe des Speicherbedarfs hängt von der Anzahl und Größe
der jeweiligen ACEs ab. Dabei kann eine ACL maximal 64kb groß werden. Das würde etwa 1820 ACEs entsprechen, wobei die Anzahl der
ACEs wiederum abhängig von der Größe der ACEs ist. Aus Performancegründen sollte die ACL so klein wie möglich sein und nicht bis
an ihre maximale Grenze wachsen.
ACL Revision
In diesem Eintrag wird die Revisionsnummer für die Datenstruktur der ACL gespeichert.
ACE Count
An dieser Stelle wird die Anzahl an ACEs in der ACL angegeben. Ist als Wert Null eingetragen, bedeutet dies, dass die ACL
keine ACEs enthält - es ist leer. Wobei eine leere DACL sich von einer Null-DACL unterscheidet. Bei einer leeren DACL erhält keiner
einen Zugriff auf das Objekt, aber eine Null-DACL gibt jedem uneingeschränkten Zugriff auf das Objekt.
Daher sollte diese Einstellung vermieden werden.
ACE
Dieser Eintrag enthält eine Liste mit den ACEs. Möchte ein Benutzer auf ein Objekt zugreifen,
werden die ACEs in der Reihenfolge in der sie aufgelistet sind kontrolliert.
Access Control Entries (ACEs)
Die einzelnen ACEs im security descriptor eines Objekts, werden in den erweiterten Sicherheitseinstellungen eines Objekts
angezeigt und legen den Zugriff entweder auf das gesamte Objekt oder auf ein einzelnes Attribut fest. Durch ACEs können
Zugriffsrechte präzise, bis auf ein einzelnes Attribut vergeben werden. Somit kann z.B. einem Benutzer oder einer Gruppe lediglich
das Recht zum lesen für das Feld Beschreibung (Attribut Description) eines Objekts erteilt werden, aber nicht das Schreibrecht.
Ehe mit dem Bearbeiten oder Erstellen von ACEs begonnen wird, sollte sich vorher der Aufbau und die Funktionsweise des
ACEs näher angeschaut werden.
Der Aufbau eines ACEs sieht wie folgt aus:
Access Mask
In der AccessMask werden die Rechte definiert, wobei es für jeden Objekttyp unterschiedliche Rechte gibt. Hier können die
gewünschten Berechtigungen ausgewählt werden, wie z.B. Vollzugriff, alle Eigenschaften lesen und schreiben, Besitzer ändern usw.
oder die zu überwachenden Ereignisse konfiguriert werden. Durch die AccessMask werden zum einen die zu vergebenen
Berechtigungen und zum anderen, die zu überwachenden Ereignisse festgelegt, abhängig von der durchzuführenden Aufgabe.
AceType
An dieser Stelle können die entsprechenden Berechtigungen zugelassen bzw. verweigert werden (der Typ ist ACCESS_ALLOWED_ACE (0)
oder ACCESS_DENIED_ACE (1)) oder die erfolgreiche bzw. fehlgeschlagene Überwachung aktiviert werden
(der Typ lautet immer SYSTEM_AUDIT_ACE). Es wird also definiert, ob für ein Objekt oder für eine Eigenschaft
die Berechtigung oder Überwachung festgelegt werden soll.
Trustee
Im Trustee wird der Benutzer bzw. die Gruppe (das Ziel) festgelegt (genauer, die SID in Form des Namen),
für den die Berechtigung oder die Überwachung gelten soll.
Aceflags
Die Aceflags definieren die Vererbungsoptionen, je nachdem ob in der ACE Berechtigungen oder Überwachungen konfiguriert wurden.
Diese Einstellung kann im Feld Übernehmen für: der ACE, dort betrifft es die ersten drei Einträge Nur dieses Objekt,
Dieses und alle untergeordneten Objekte, Nur untergeordnete Objekte, vorgenommen werden.
Flags
Alle ACEs enthalten die Eigenschaft Flags, durch das der ACE erkennt, welches Feld ObjectType oder InheritedObjectType
zusätzlich noch gesetzt ist.
ObjectType
Hier wird angegeben, auf welchen Objekttyp oder welches Attribut sich das ACE bezieht.
Als Wert wird die GUID des Objekts oder des Attributs gespeichert.
InheritedObjectType
Dieses Feld im ACE gibt die GUID des Objekts an, das den betreffenden ACE erben soll.
Diese Optionen sind in den Eigenschaften eines Objekts - im Reiter Sicherheit - dort auf Erweitert klicken -
im Reiter Berechtigungen (DACL)/oder im Reiter Überwachung (SACL) auf Hinzufügen… klicken - danach den Benutzer oder die Gruppe
auswählen bzw. eingeben - anschließend erscheint das Fenster „Berechtigungseintrag für… oder Überwachungseintrag für…“
was das ACE darstellt, zu finden.
Security Descriptor (SD)
Im Active Directory das auf Objekten basiert, wie es z.B. Benutzer, Grupppen, Computer, Container, Standorte usw. darstellen,
besitzen alle Objekte sogenannte security descriptors (zu deutsch, Sicherheitsbeschreibungen). Die Werte der Sicherheitseinstellungen
(wer darf mit welchen Rechten auf das Objekt zugreifen) werden in jedem Active Directory Objekt, in der Eigenschaft
nTSecurityDescriptor gespeichert. Der Wert im nTSecurityDescriptor wird als SDDL-String gespeichert, den man sich z.B. mit
LDP.exe oder dem „Active Directory Explorer“ anzeigen lassen kann. In dieser Eigenschaft werden alle Sicherheitsinformationen
für das Objekt gespeichert. Das Windows Betriebssystem verwendet security descriptors um den Zugriff auf eine Ressource zu steuern.
In den security descriptors wird folgendes festgelegt:
-
Es werden die Benutzer sowie Gruppen angezeigt, die Zugriff auf das Objekt haben.
-
Weiterhin werden die Berechtigungen angegeben, mit denen ein Benutzer oder eine Gruppe Zugriff auf das Objekt erhält.
-
Es werden die Ereignisse auf den Objekten definiert, die überwacht werden sollen.
-
Es wird der Besitzer des Objekts angegeben.
-
Weiterhin enthält der SD Informationen darüber, welche Rechte das Objekt von übergeordneten Containern vererbt bekommt.
Es existieren selbstverständlich nicht nur im Active Directory diese security descriptors. Ganz im Gegenteil, man findet sie an
vielen Stellen auf einem System wieder, z.B. in Dateien und Verzeichnissen die auf einem NTFS-Dateisystem gespeichert sind,
Freigaben, Drucker, Registry etc. Im Prinzip existieren security descriptors auf allen Objekten, auf denen eine Zugriffssteuerung
konfiguriert werden kann. Dabei befinden sich die Sicherheitsbeschreibungen in den erweiterten Sicherheitseinstellungen eines
Objekts (in den Eigenschaften eines Objekts - im Reiter Sicherheit - dort auf Erweitert).
Der security descriptor ist eine binäre Datenstruktur mit einer variablen Länge und besteht im wesentlichen aus den folgenden Teilen:
- Der Header beinhaltet eine Revisionsnummer und eine Reihe von Optionen die beschreiben, welche Eigenschaften vorhanden
sind und welche hinzugefügt oder geändert wurden.
- In der Discretionary Access Control List (DACL) werden die einzelnen Zugriffsrechte für ein bestimmtes Objekt, in Form von
Access Control Entries (ACEs) festgelegt. In der DACL sind die Benutzer und/oder Gruppen eingetragen, denen der Zugriff auf
das Objekt erlaubt oder verweigert wird. Werden einem Benutzer oder einer Gruppe Aufgaben im Active Directory delegiert,
so werden automatisch die SIDs der Personen in die DACL der Objekte geschrieben. Der Inhalt bzw- die Einträge in der
DACL werden vom Besitzer kontrolliert.
- Die SACL ist vergleichbar mit der DACL, allerdings mit dem Unterschied, dass die SACL für die Protokollierung - anstatt für
den Zugriff auf ein Objekt zuständig ist. In der System Access Control List (SACL) sind die Überwachungseinstellungen enthalten.
Auch hier befinden sich ACEs, die den definierten erfolgreichen oder fehlgeschlagenen Zugriff protokollieren. Findet ein Zugriff
auf ein Objekt statt für den die Protokollierung aktiviert wurde (sei es erfolgreich oder fehlgeschlagen), verzeichnet das
Betriebssystem im Sicherheitslog einen Eintrag.
- Der Security Identifier (SID) des Besitzers (Owner). Der Besitzer eines Objekts kann die Berechtigungen bearbeiten und anderen
Benutzern Rechte auf das Objekt erteilen.
- Ein weiterer Bestandteil ist der SID der primären Gruppe des Besitzers
(existiert aus Kompatibilitätsgründen zu Unix/Macintosh Systemen).
Security Descriptor Definition Language (SDDL)
Die Security Descriptor Definition Language stellt ein Textformat dar, das zur Beschreibung von security descriptors dient.
In diesem String, der natürlich jederzeit veränderbar ist, werden die Sicherheitsinformationen in Form von Access Control Lists (ACLs)
samt den einzelnen Access Control Entries (ACEs) eines Objekts, im nTSecurityDescriptor gespeichert. Microsoft verwendet
die SDDL immer dann, wenn ein security descriptor im String-Format definiert werden soll.
Die nachfolgend genannte kryptische Zeichenkette stellt einen SDDL-String dar (alles in einer Zeile):
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)
(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)
Solch einen SDDL-String findet man z.B. dann wieder, wenn einem Benutzer das Recht vergeben werden soll,
dass Eventlog eines DCs lesen zu können. Dazu existiert im folgenden Registry-Pfad des DCs:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\* in dem jeweiligen Schlüssel
(Application, Directory Service, DNS Server…) ein REG_SZ Eintrag mit dem Namen CustomSD [2]. Dort fndet sich als Wert solch
ein SDDL-String wieder. Oder in den Security Templates im Verzeichnis %windir%\security\templates trifft man ebenfalls
einen SDDL-String an. Eine andere Stelle an der man einen SDDL-String vorfindet, wäre in der Eigenschaft nTSecurityDescriptor
eines jeden Active Directoy Objekts.
Auf ein Active Directoy Objekt wirken mehrere Berechtigungen. Wird ein Objekt im Active Directory erstellt, erhält es standardmäßig
gewisse Sicherheitsinformationen, im SDDL-String, die im Schema im Attribut Default-Security-Descriptor festgelegt sind.
Zusätzlich erbt das erstellte Objekt weitere Berechtigungen, durch die darüberliegenden Einheiten (Container, OU, Domäne).
Anschließend kann der Administrator jederzeit noch die Berechtigungen des Objekts modifizieren.
Gerade für Administratoren die evtl. durch Skripte ihre tägliche Arbeit erleichtern möchten, ist es unerlässich zu verstehen,
wie ein SDDL-String sich zusammensetzt. Denn schließlich lässt sich die Delegierung von Rechten im Active Directory, im SDDL-String,
natürlich auch per Skript setzen. Des Weiteren ist es unerlässich einen SDDL-String zu verstehen, wenn mit dem
Active Directory-Kommandozeilentool DSACLS Rechte im Active Directory händisch oder per Skript delegiert bzw. gelesen werden sollen.
Auch um Security Templates zu lesen und zu bearbeiten ist es zwingend, die Syntax verstanden zu haben.
Kommen wir nun zur Erläuterung eines SDDL-Strings.
In einem SDDL-String werden die Zeichen fortlaufend durchgeschrieben und nicht durch Leerzeichen getrennt.
Die Länge eines SDDL-Strings ist nicht hartcodiert und kann variieren.
Die Schreibweise eines nTSecurityDescriptor SDDL-Strings würde so aussehen:
O:Owner-SIDG:Group-SIDD:DACL-Flags(ACE1- String)( ACE2- String)(…usw.)S:SACL-Flags(ACE1- String)( ACE2- String)(…usw.)
Jeder nTSecurityDescriptor SDDL-String besteht aus fünf Teilen. Diese wären:
- Header: Der Header enthält Eigenschaften (Flags) die beschreiben,
ob das Objekt die Vererbung von DACL und SACL erlaubt oder blockiert.
-
Owner: Der Besitzer eines Objekts trägt in einem SDDL-String das Präfix „O:“. Dieser Wert gibt an,
welcher Trustee der Besitzer des Objekts ist. Hier die Erläuterung der geläufigsten SID-Strings (Abkürzungen)
die der Wert Owner (sowie G:Group-SID) enthalten kann: AN = Anonymous
AO = Account Operators
AU = Authenticated Users
BA = Builtin Administrators
BO = Backup Operators
CG = Creator Group
CO = Creator Owner
DA = Domain Administrators
DU = Domain Users
EA = Enterprise Admins
LA = Local Administrator Account
SA = Schema Administrators
SO = Server Operatoren
SY = Local System
WD = Everyone (World)
Die komplette Liste der SID-Strings befindet sich auf dieser Seite:
SID Strings (Windows)
Im o.g. SDDL-String ist in der kryptischen Zeichenkette als Owner der Eintrag „O:BA“ enthalten und dieser steht für
„Builtin Administrators“. Statt des SID-Strings kann auch eine SID verwendet werden,
z.B. so: O:S-1-5-21-956547467-2769573453-2154042951-500G:SYD:(…).
-
Primary Group: Die primäre Gruppe erhält in einem SDDL-String das Präfix „G:“. Dieser Wert enthält den SID-String
der primären Gruppe eines Objekts. Der Wert des Owner und der Primary Group entspricht einer einzigen SID.
Der Eintrag „G:SY” bedeutet, dass die primäre Gruppe Local System lautet.
-
DACL: Die DACL wird in einem SDDL-String mit einem „D:“ eingeleitet.
-
DACL-Flags: Dieser Wert ist ein security descriptor control Flag, das auf das DACL angewendet wird.
Dieser Eintrag kann mehrere Werte enthalten (z.B. D:PAI), muss aber keine enthalten. Folgende Wert lassen sich dabei eintragen:
P = SDDL_PROTECTED. Das SE_DACL_PROTECTED Flag ist gesetzt.
AR = SDDL_AUTO_INHERIT_REQ. Das SE_DACL_AUTO_INHERIT_REQ Flag ist gesetzt.
AI = SDDL_AUTO_INHERITED. Das SE_DACL_AUTO_INHERITED Flag ist gesetzt.
-
SACL: Die SACL wird im SDDL-String als „S:“ gekennzeichnet.
-
SACL-Flags : Dieser Wert ist ein security descriptor control Flag das auf das SACL angewendet wird und ebenfalls (wie DACL-Flags)
keine feste Länge hat. Bei dem SACL-Flags String werden die gleichen Werte wie bei dem DACL-Flags String verwendet.
-
ACE-String: Der ACE-String der in Klammern gesetzt ist, beschreibt einen ACE im security descriptor für den DACL und SACL.
Der ACE-String lautet beim DACL sowie SACL gleich und setzt sich aus den folgenden sechs Feldern
(jeweils getrennt durch ein Semikolon) zusammen, die nicht alle gesetzt sein müssen:
(ACE-Type;ACE-Flags;Rights;ObjectGUID;Inherit-ObjectGUID;Account-SID)
- Als ACE-Type könnten unter anderem A für Allow oder D für Deny eingetragen sein, was den Optionen „Zulassen“ oder „Verweigern“
im security descriptor des Objekts entspricht. Bei einem Eintrag der SACL könnte als Wert AU für Audit (Überwachung) eingetragen sein.
- Falls das Objekt ein Container sein sollte kann mit dem ACE-Flags String angegeben werden,
das sich das ACE nur auf den Container oder seinen Inhalt bezieht.
- Der Rights String gibt die Berechtigungen für den ACE an.
- Der String ObjectGUID hat als Wert die GUID einer Objektklasse, eines Attributs oder Attribut Sets.
- Im Inherit-ObjectGUID kann sich die GUID einer Objektklasse befinden. Falls es gesetzt ist, bezieht sich die Vererbung
auf den ACE der untergeordneten Einträge der Objektklasse.
- Im sechsten Teil Account-SID wird der Name des Benutzer- oder Gruppenkontos angegeben (Trustee), auf dem sich die
Berechtigungen auswirken. Als Wert kann entweder ein SID-String (z.B. DA) oder die SID in Form von S-1-5-21 angegeben werden.
Ein ACE-String könnte dabei in der Praxis so aussehen: (A;;WP;;;DU) und hat dabei folgende Bedeutung:
- ACE-Type lautet in dem String A, was für „Zulassen“ steht.
- Ein Wert im ACE-Flags ist nicht gesetzt.
- Als Berechtigung wurde der Wert WP (Write_Property) vergeben, was „Schreibberechtigung“ im Active Directory-Objekt bedeutet.
- Es ist keine ObjektGUID eingetragen.
- Ebenfalls ist der Wert Inherit-ObjektGUID nicht eingetragen.
- Die Berechtigung wurde an DU (Domain_Users) vergeben, das für „Domänen-Benutzer“ steht.
Mit dem Kommandozeilentool SC kann man sich unter anderem die Sicherheitsinformationen von Diensten anzeigen lassen.
Der security descriptor des Dienstes NTDS auf einem Windows Server 2008 DC sieht so aus:
C:\SC SDSHOW NTDS
D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
(A;;CCLCSWLORC;;;BO)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
Man kann erkennen, dass neben dem DACL auch die SACL durch das S: gesetzt ist.
Die Zugriffsrechte eines Active Directory Objekts werden dabei, durch die folgenden ACE-Strings geregelt:
CC = Create all child Objects
CR = All extended Rights
DC = Delete all Child Objects
DT = Delete Subtree
LC = List Contents
LO = List Object
RC = Read permissions
RP = Read all Properties
SD = Delete
SW = All Validated Writes
WD = Modify Permissions
WO = Modify Owner
WP = Write all Properties
Alle Werte die in einem ACE-String enthalten sein können, werden auf der folgenden Seite erläutert:
ACE Strings (Windows)
[2] How to set event log security locally or by using Group Policy in Windows Server 2003
Objektverwaltung zuweisen
Die technische Umsetzung einer Active Directory-Delegierung über die GUI, wird im Snap-In
Active Directory-Benutzer und -Computer durchgeführt. Mit einem Rechtsklick auf den Standardcontainer Users oder einer OU,
ruft man mit der Auswahl von Objektverwaltung zuweisen… den Assistent zum Zuweisen der Objektverwaltung auf
(der bereits seit Windows 2000 existiert). Nach Auswahl des Benutzers oder der Gruppe kann im darauffolgenden Schritt die Wahl
zwischen einem allgemeinen und benutzerdefinierten Task getroffen werden. Bei dem benutzerdefinierten Task gilt es auf den
darauffolgenden beiden Schritten, zum einen den Objekttyp für die Delegierung auszuwählen und zum anderen, die gewünschten
Berechtigungen die auf Attributebene aktiviert werden können auszuwählen.
Der gewiefte Administrator kann den Delegierungsassistenten im ADBuC überspringen und direkt in den erweiterten
Sicherheitseinstellungen des Containers (auch eine OU ist ein Container) die entsprechenden Berechtigungen vergeben.
Denn der Assistent für die Objektverwaltung macht auch nichts weiter, als die Personen mit den vergebenen Berechtigungen
im security descriptor des Containers einzutragen.
Um auf die Anfangsfrage zurückzukommen was im Hintergrund passiert, wenn einem Benutzer oder einer Sicherheitsgruppe
Rechte im Active Directory delegiert werden, ist nichts weiter, als das die Benutzer mit den vergebenen Rechten im
security descriptor des Objekts eingetragen werden.
Die bereits delegierten Rechte auf einem Objekt zeigt einem der Objektverwaltungs-Assistent leider nicht an.
Stattdessen ist in der MMC „ADBuC“ unter Ansicht die Option „Erweiterte Funktionen“ zu aktivieren, damit in den Eigenschaften
eines Objekts der Reiter Sicherheit erscheint. Danach kann in den erweiterten Sicherheitseinstellungen (im security descriptor)
die Person ausgewählt und mit einem Klick auf Bearbeiten… die gesetzten Berechtigungen eingesehen werden. Sollen die
vergebenen Berechtigungen dem Benutzer entzogen werden, so gilt es lediglich den Benutzer aus der ACL des Objekts zu entfernen.
Einen Assistenten für das Entfernen von Berechtigungen gibt es nicht.
Über die Kommandozeile lassen sich die Berechtigungen mit dem Tool DSACLS, das sich in den Windows Support Tools befindet
(z.B. auf der Windows Server 2003 CD im Verzeichnis Support\Tools), ebenfalls ansehen sowie vergeben. Mit dem folgenden Befehl
werden die Berechtigungen für den Standardcontainer USERS (im ADBuC) aufgelistet:
Dsacls CN=Users,DC=intra,DC=dikmenoglu,DC=de.
Alles was mit dem Assistenten delegiert werden kann, lässt sich auch in einem Skript mit DSACLS realisieren.
Die Syntax zu dem Tool wird in der Hilfe erläutert, die sich mit dem Befehl Dsacls -? aufrufen lässt.
Die vergebenen Berechtigungen können in Form von ACEs auch mit dem Kommandozeilentool DSREVOKE angezeigt und entfernt werden.
Objektdelegierungen einrichten
Der Objektdelegierungsassistent
Delegierte AD-Berechtigungen anzeigen und entfernen
Zusammenfassung
Das Delegierungskonzept sollte sorgfältig geplant, in einer Testumgebung getestet und ganz wichtig, dokumentiert werden.
In der Planungsphase sollten diese Fragen geklärt werden:
- Welche Berechtigungen sollen die entsprechenden Personen erhalten?
Dabei werden idealerweise Berechtigungen Gruppen und nicht einzelnen Personen zugewiesen.
- Ist die gewünschte Berechtigung die delegiert werden soll technisch realisierbar?
- Wenn es technisch realisierbar ist, können mit den Standard-MMCs wie z.B. „Active Directory-Benuzter und -Computer“
die Aufgaben durchgeführt werden?
Wenn ein entsprechendes Konzept erarbeitet, getestet und implementiert wurde, gestaltet sich die tägliche Administration
in der Praxis mit dem geringsten Aufwand, wobei die Benutzer nur mit den notwendigsten Rechten ausgestattet werden.
Das Delegierungskonzept sollte dabei nicht übertrieben werden, ganz nach dem Motto „soviel wie nötig - so wenig wie möglich“.
Denn wenn unüberlegt Berechtigungen delegiert werden, kann das unter Ümständen zu Performance-Einbußen im Active Directory führen.
Large Numbers of ACEs in ACLs Impair Directory Service Performance
Des Weiteren sollte bei dem Delegierungskonzept unbedingt darauf geachtet werden,
dass einem der AdminSDHolder nicht in die Quere kommt.
Delegated permissions are not available and inheritance is automatically disabled
Weitere Informationen:
Security Descriptors and Access Control Lists Technical Reference
Security Descriptor Definition Language (Windows)
Best Practices for Delegating Active Directory Administration
Best Practices for Delegating Active Directory Administration Appendices
Best practices and guidance for writers of service discretionary access control lists
Well-known security identifiers in Windows operating systems
Seit der Einführung des "Active Directory" mit Windows 2000, können standardmäßig "authentifizierte Benutzer" 10 Clients in die Domäne aufnehmen.
Im weiteren Verlauf wird beschrieben, welche beiden Möglichkeiten dem Administrator zur Verfügung stehen um diese Konfiguration zu ändern
und wie die notwendige Berechtigung zum "Hinzufügen der Clients zur Domäne" an die entsprechenden Personen erteilt werden können.
Die Gruppenrichtlinie
In der Default Domain Controllers Richtlinie ist das Benutzerrecht festgelegt, wer Arbeitsstationen zur Domäne hinzufügen darf.
Der Pfad ist folgender:
Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\
Zuweisen von Benutzerrechten\Hinzufügen von Arbeitsstationen zur Domäne
Diese Richtlinie enthält standardmäßig bereits die Gruppe Authentifizierte Benutzer.
Somit ist es jedem Domänen-Benutzer möglich, 10 Clients in die Domäne hinzuzufügen.
Weitere Benutzer und/oder Gruppen können jederzeit in die Richtlinie hinzugefügt werden.
Dieses Verhalten ist aber meistens (wegen der Unternehmensrichtlinie) nicht gewünscht.
Nicht nur, dass der Domänen-Benutzer sein privates Laptop – das nicht den Sicherheitsrichtlinien des Unternehmens entspricht –
mitbringen und zur Domäne hinzufügen könnte, sondern, er kennt bereits das lokale Administrator Kennwort und kann sich damit lokal anmelden.
Danach hat er die Möglichkeit, seinen Domänen-Account (unter Angabe seiner Domänen-Benutzer Daten) der lokalen Gruppe Administratoren hinzufügen.
Um dies zu unterbinden, könnte man aus der o.g. Richtlinie die Gruppe „Authentifizierte Benutzer“
entfernen und lediglich autorisierte Benutzer aus der IT-Abteilung hinzufügen.
Das Kontingent von 10 Arbeitsstationen, wird im Attribut MS-DS-Machine-Account-Quota das sich in den Eigenschaften
der Domänenpartition befindet festgelegt. Dieser Wert lässt sich mit ADSIEdit verändern. Wird im Attribut als Wert "0" eingetragen,
können die in der Richtlinie eingetragenen Benutzer oder Gruppen keine Arbeitsstationen mehr zur Domäne hinzufügen.
Das im Attribut definierte Kontingent, gilt ausschließlich für die Benutzer und Gruppen die in der o.g. Richtlinie definiert sind.
Sie gilt nicht für Benutzer oder Gruppen, die die Berechtigung zum Erstellen von Computerobjekten delegiert bekommen haben.
Wie viele Arbeitsstationen der Benutzer bereits zur Domäne hinzugefügt hat, wird anhand des Attributs MS-DS-Creator-SID,
dass sich in den Eigenschaften der Computerkonten befindet errechnet. In diesem Attribut wird die ObjectSID (als ein "Octet Stream")
des Benutzers eingetragen, natürlich nur, wenn die Grenze des im Attribut MS-DS-MachineAccountQuota eingetragenen Werts (standardmäßig 10)
noch nicht erreicht wurde. Das überprüfen geht recht schnell, da das Attribut MS-DS-Creator-SID indiziert ist.
Wird ein Client der vom Benutzer zur Domäne hinzugefügt wurde aus der Domäne entfernt, deaktiviert sich lediglich das Computerkonto im AD.
Das Computerkonto bleibt jedoch weiterhin im AD bestehen. Erst wenn das Computerkonto aus dem AD gelöscht wird,
kann der Benutzer einen weiteren Client zur Domäne hinzufügen.
Falls aber ein Benutzer dem die Berechtigung "Erstellen von Computerobjekten" delegiert wurde oder ein administratives Konto (Domänen-Admin)
einen Client zur Domäne hinzufügt, erhält anschließend das Attribut MS-DS-Creator-SID im Computerkonto keinen Wert!
Wenn nun ein Client mithilfe des Benutzerrechts "Hinzufügen von Arbeitsstationen zur Domäne" zur Domäne hinzugefügt wurde,
wird als Besitzer des Computerkontos die Gruppe "Domänen-Admins" eingetragen. Das Computerkonto befindet sich
nicht im Besitz desjenigen, der den Client zur Domäne hinzugefügt hat. Natürlich wird aber im Attribut MS-DS-Creator-SID
die ObjektSID des Benutzers eingetragen.
Besitzt ein Benutzer das Recht Hinzufügen von Arbeitsstationen zur Domäne und wurde ihm zusätzlich die Berechtigung zum Estellen
von Computerkonten in der Domäne delegiert, wird der Client basierend auf der delegierten Berechtigung zur Domäne hinzugefügt und nicht
basierend auf dem Benutzerrecht.
Die Erklärung zu der o.g. Richtlinie lautet wie folgt:
Mit dieser Sicherheitseinstellung wird festgelegt, welche Gruppen oder Benutzer Arbeitsstationen zu einer Domäne hinzufügen können.
Diese Sicherheitseinstellung ist nur für Domänencontroller gültig. Standardmäßig besitzt jeder
authentifizierte Benutzer dieses Recht und kann bis zu 10 Computerkonten in der Domäne erstellen.
Durch Hinzufügen eines Computerkontos zur Domäne kann der Computer an der Active Directory-Vernetzung teilnehmen.
Wenn eine Arbeitsstation zum Beispiel einer Domäne hinzugefügt wird, kann diese Arbeitsstation Konten und Gruppen erkennen,
die in Active Directory vorhanden sind.
Standardwert: "Authentifizierte Benutzer" bei Domänencontrollern.
Hinweis: Benutzer, die für den Active Directory-Container "Computer" die Berechtigung zum Erstellen von Computerobjekten
besitzen, können auch in der Domäne Computerkonten erstellen. Der Unterschied ist, dass auf Benutzer, die über Berechtigungen
für den Container verfügen, die Einschränkung zum Erstellen von maximal 10 Benutzerkonten nicht zutrifft. Darüber hinaus sind
die Computerkonten, die mithilfe von "Hinzufügen von Arbeitsstationen zur Domäne" erstellt wurden, im Besitz von
Domänenadministratoren, während bei Computerkonten, die mithilfe der Berechtigungen für den Container "Computer" erstellt wurden,
der Ersteller des Computerkontos der Besitzer ist. Wenn ein Benutzer über Berechtigungen für den Container verfügt und auch das Benutzerrecht
"Hinzufügen von Arbeitsstationen zur Domäne" besitzt, wird der Computer basierend auf den Berechtigungen für den Container "Computer" und nicht
basierend auf dem Benutzerrecht hinzugefügt.
Die Objektdelegierung
Idealerweise delegiert man über die Objektverwaltung in der MMC Active Directory-Benutzer und Computer (dsa.msc) einem Benutzer (besser einer Gruppe) die Berechtigung "Fügt einen Computer einer Domäne hinzu", anstatt die Werte in der o.g. Gruppenrichtlinie zu verändern. Dazu kann man mit einem Rechtsklick auf den Domänennamen in der dsa.msc den Objektdelegierungsassistenten aufrufen. Die entsprechende Berechtigung wird dann durch einen "allgemeinen Task" delegiert.
Diese Vorgehensweise hat aber einen Nachteil. Da der Objektdelegierungsassistent auf "Domänenebene" ausgeführt wurde,
können die Benutzer die diese Berechtigung erhalten haben in der MMC dsa.msc in jedem Container (dazu zählen auch OUs)
Computerkonten erstellen. Für viele Administratoren sind das (zurecht) zu viele Berechtigungen, denn die Benutzer sollen nur die
nötigsten Berechtigungen erhalten. Aber dieser allgemeine Task steht standardmäßig weder auf dem Standard-Container Computers,
noch in einer OU zur Verfügung. Das kommt daher, da in der Datei delegwiz.inf im [template6] lediglich der Eintrag
AppliesToClasses=domainDNS existiert. Dieser Eintrag lässt sich bearbeiten, so das die allgemeine Aufgabe
"Fügt einen Computer einer Domäne hinzu" auch auf dem Standard-Container Computers und
auf OUs zur Verfügung steht. Das würde dann folgendermaßen aussehen:
;----------------------------------------------------------
[template6] <-- ACHTUNG: Bei dieser Vorlage muss auf die Groß- und Kleinschreibung geachtet werden!
AppliesToClasses=domainDNS,organizationalUnit,container
Description="Fügt einen Computer einer Domäne hinzu"
ObjectTypes=SCOPE,computer
[template6.SCOPE]
;Berechtigung um Computerobjekte zu erstellen
computer=CC
[template6.computer]
;Berechtigungen für das Hinzufügen eines Computers zur Domäne
CONTROLRIGHT="Validated write to DNS host name","Account Restrictions","Reset Password","Validated write to service principal name"
;----------------------------------------------------------
Nach der Bearbeitung der Datei kann nun die Delegierung z.B. auf dem Standard-Container Computers
durchgeführt werden. Danach kann der Benutzer der diese Berechtigung erteilt bekommen hat, vom Client aus
diesen zur Domäne hinzufügen.
Der Benutzer kann einen Client auch dann zur Domäne hinzufügen, wenn dieser zuvor vom Domänen-Admin (!)
zur Domäne hinzugefügt und später wieder entfernt wurde. Das Computerobjekt im AD bleibt weiterhin im Besitz
des Domänen-Admins. Jedoch kann der Benutzer der diese Berechtigung erteilt bekommen hat, einen Client der zuvor
vom Domänen-Admin aus der Domäne entfernt wurde, erneut zur Domäne hinzufügen.
Zur Erinnerung: Wird ein Client von der Domäne zu einer Arbeitsgruppe hinzugefügt, bleibt das Computerkonto im AD
bestehen und wird nicht gelöscht!
Wird jedoch diese Berechtigung auf einer OU delegiert, so muss der Benutzer zuerst in der entsprechenden OU
das Computerkonto erstellen und kann erst dann, den Client zur Domäne hinzufügen.
Die Delegierung muss nicht zwangsläufig über den Assistenten eingerichtet werden. Stattdessen kann die Delegierung
auch durch das Bearbeiten der "Discretionary Access Control List (DACL)" des Containers oder mit DSACLS eingerichtet werden.
Für die Delegierung über die DACL, ist nach Hinzufügen des entsprechenden Benutzers oder der Gruppe, im Feld "Übernehmen für"
die Option Dieses und alle untergeordneten Objekte auszuwählen. Bei den Berechtigungen gilt es dann
die Option "Computer" erstellen zuzulassen. Auch hierbei gilt, wird die Delegierung im Standard-Container Computers eingerichtet,
kann der Benutzer den Client vom Client aus zur Domäne hinzufügen. Andernfalls muss zuerst das Computerkonto in der OU erstellt werden,
ehe der Client zur Domäne hinzugefügt werden kann.
Objektdelegierungen einrichten
Benutzer die über diese Berechtigung verfügen, können unbegrenzt Clients zur Domäne hinzufügen.
Versierte Administratoren können diese Berechtigung (Computerobjekte erstellen) natürlich auch automatisiert mit DSACLS vergeben.
Weitere Informationen:
Der Objektdelegierungsassistent
Delegierte Berechtigungen im AD verstehen
Delegierte AD-Berechtigungen anzeigen und entfernen
Default Limit to Number of Workstations a User Can Join to the Domain
Domain Users Cannot Join Workstation or Server to a Domain
"You Have Exceeded the Maximum Number of Computer Accounts" Error Message When You Try to Join a Windows XP Computer to a Windows 2000 Domain
|
Copyright © 2010 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|