Blog Home  Home Feed your aggregator (RSS 2.0)  
LDAP://Yusufs.Directory.Blog/ - Thursday, June 11, 2009
Wieviele Sprachen sprechen Sie? Ich spreche bloß eine: LDAP!
 
 Thursday, June 11, 2009

Microsoft stellt das Active Directory Management Gateway Service (AD MGS) für Windows Server 2003 und Windows Server 2008 als separaten Download zur Verfügung.

Wenn das AD MGS installiert ist, stellt es die gleichen Funktionen zur Verfügung wie die Active Directory Web Services (ADWS) unter Windows Server 2008 R2.
Das AD MGS ist das AD-Web Services für Windows Server 2003 und Windows Server 2008. 


Die Installationsvoraussetzungen für das AD MGS wären:

 

Nach der Installation des AD MGS kann ein Windows Server 2003 DC oder Windows Server 2008 DC über die AD-Powershell und
Active Directory Administrative Center (ADAC) von einem Windows 7 Client oder Windows Server 2008 R2 Mitgliedsserver bzw. DC administriert werden.

Das AD MGS steht hier zum Download zur Verfügung:

Active Directory Management Gateway Service (Active Directory Web Service for Windows Server 2003 and Windows Server 2008)


 

Weitere Informationen:
The Active Directory Management Gateway Service is now available
Neues in den AD DS: Active Directory-Webdienste
Die AD-Powershell im Windows Server 2008 R2
Das Active Directory-Verwaltungscenter

Thursday, June 11, 2009 9:41:04 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration | AD-Powershell  | 
 Saturday, June 06, 2009

Wurde bis einschließlich Windows Server 2008 der Domänen- oder Gesamtstrukturfunktionsmodus z.B. von „Windows Server 2003“ auf „Windows Server 2008“ hochgestuft, ist es nicht möglich weder den Domänen- noch Gesamtstrukturfunktionsmodus zurückzustufen. Die einzige Möglichkeit wäre ein Forest-Recovery durchzuführen. Denn das Heraufstufen des Domänen- bzw. Gesamtstrukturfunktionsmodus ist ein irreversibler Vorgang.

Unter Windows Server 2008 R2 ist nun das zurückstufen in einen bestimmten Domänen- sowie Gesamtstrukturfunktionsmodus unter gewissen Voraussetzungen möglich.

Die Funktionsebenen bestimmen zum einen die zur Verfügung stehenden Active Directory-Funktionen innerhalb der Domäne sowie Gesamtstruktur und zum anderen werden die Betriebssystemversionen beschränkt, die auf Domänencontrollern (DCs) ausgeführt werden können.

Weitere Informationen über die Funktionsebenen liefert der folgende Artikel:

Domänen- und Gesamtstrukturfunktionsmodus



Den Domänenfunktionsmodus zurückstufen

Der Domänenfunktionsmodus lässt sich unter bestimmten Voraussetzungen wie folgt zurückstufen:

  • Der aktuelle Domänenfunktionsmodus muss sich auf „Windows Server 2008 R2“ befinden.

  • Der Domänenfunktionsmodus lässt sich ausschließlich auf „Windows Server 2008“ zurückstufen. Ein zurückstufen auf „Windows Server 2003“ oder früher ist unter keinen Umständen möglich.

  • Der Gesamtstrukturfunktionsmodus muss den Domänenfunktionsmodus auf den die entsprechende Domäne zurückgestuft werden soll (also auf „Windows Server 2008“) unterstützen. Das bedeutet, befindet sich der Gesamtstrukturfunktionsmodus auf „Windows Server 2008 R2“, so kann die Domäne nicht auf „Windows Server 2008“ zurückgestuft werden, da der Gesamtstrukturfunktionsmodus nur „Windows Server 2008 R2“ Domänen innerhalb der Gesamtstruktur unterstützt.

  • Der Gesamtstrukturfunktionsmodus muss sich also auf Windows 2000, Windows Server 2003 oder Windows Server 2008 befinden.

  • Der Domänenfunktionsmodus kann zum einen in der AD-Powershell mit dem Commandlet Set-ADDomainMode und zum anderen, mit dem Attribut-Editor in der MMC Active Directory-Benutzer und -Computer (dsa.msc) oder ADSIEdit zurückgestuft werden.

  • Unter Start-Verwaltung gilt es das Active Directory Module for Windows Powershell zu starten. Danach kann mit diesem AD Powershell-Befehl der Domänenfunktionsmodus zurückgestuft werden:
    Set-ADDomainMode <FQDN der Domäne> -DomainMode Windows2008Domain

  • Anschließend muss die Aktion mit einem „J“ bestätigt werden.



  • Leider erscheint in der AD-Powershell keine Meldung das die Aktion durchgeführt wurde. Es wird aber im Verzeichnisdienstprotokoll des DCs die EventID 2039 protokolliert in der bestätigt wird, dass die Neue Domänenfunktionsebene:3 lautet.

  • Die Zahl „3“ gibt den Wert im Attribut msDS-Behavior-Version an, das sich in der Domänenpartition in den Eigenschaften des Containers <DC=Domäne,DC=TLD> befindet.

    Folgende Werte können im Attribut msDS-Behavior-Version eingetragen sein:

    0 = Domänenfunktionsmodus: Windows 2000 gemischt und Windows 2000 pur
    1 = Domänenfunktions: Windows Server 2003 Interim
    2 = Domänenfunktionsebene: Windows Server 2003
    3 = Domänenfunktionsebene: Windows Server 2008
    4 = Domänenfunktionsebene: Windows Server 2008 R2

  • Mit dem Attribut-Editor in der MMC Active Directory-Benutzer und -Computer (dsa.msc) oder ADSIEdit lässt sich der Domänenfunktionsmodus ebenfalls zurückstufen. In der MMC dsa.msc gilt es zuerst unter Ansicht die Erweiterte Features zu aktivieren. Anschließend ruft man mit einem Rechtsklick auf den Domänennamen die Eigenschaften auf und wechselt zum Reiter Attribut-Editor. Dort angelangt, ändert man den Wert im Attribut msDS-Behavior-Version von 4 auf 3. Mit ADSIEdit ist die Vorgehensweise ähnlich. Nach dem Aufruf von ADSIEdit stellt man im ersten Schritt eine Verbindung mit der Domänenpartition (Standardmäßiger Namenskontext) her und ändert im zweiten, den Wert im Attribut msDS-Behavior-Version von 4 auf 3.

  • Der Domänenfunktionsmodus kann natürlich auch in der MMC Active Directory-Benutzer und -Computer (dsa.msc) und Active Directory-Domänen und -Vertrauensstellungen (domain.msc) überprüft werden.

  • In der AD-Powershell lässt sich der DomainMode mit dem Cmdlet Get-ADDomain verifizieren.




Den Gesamtstrukturfunktionsmodus zurückstufen

Der Gesamtstrukturfunktionsmodus lässt sich unter gewissen Voraussetzungen wie folgt zurückstufen:

  • Der aktuelle Gesamtstrukturfunktionsmodus muss sich auf „Windows Server 2008 R2“ befinden.

  • Der Gesamtstrukturfunktionsmodus kann wie der Domänenfunktionsmodus nur auf „Windows Server 2008“ zurückgestuft werden.

  • Optionale Funktionen die nicht mehr deaktiviert werden können, wie der AD-Papierkorb, dürfen nicht aktiviert sein. Zukünftige optionale Funktionen die deaktiviert werden können, lassen sich mit dem AD-Powershell Cmdlet Disable-ADOptionalFeature deaktivieren.

  • Das zurückstufen erfolgt entweder in der AD-Powershell mit dem Cmdlet Set-ADForestMode oder mit ADSIEdit.

  • In dem Active Directory Module for Windows Powershell muss zum zurückstufen des Gesamtstrukturfunktionsmodus dieser Befehl eingegeben werden:
    Set-ADForestMode <FQDN der Root-Domäne> -ForestMode Windows2008Forest

  • Der Vorgang ist mit einem „J“ zu bestätigen.



  • Danach wird im Verzeichnisdienstprotokoll des DCs die EventID 2040 protokolliert mit der Beschreibung, dass die Neue Gesamtstrukturfunktionsebene:3 lautet.

  • Auch hier ist mit der Zahl „3“ der Wert im Attribut msDS-Behavior-Version gemeint, das sich in den Eigenschaften des Containers
    <CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> befindet.

    Die Werte die im Attribut
    msDS-Behavior-Version eingetragen werden können sind:

    0 = Gesamtstrukturfunktionsebene: Windows 2000
    1 = Gesamtstrukturfunktionsebene: Windows Server 2003 Interim
    2 = Gesamtstrukturfunktionsebene: Windows Server 2003
    3 = Gesamtstrukturfunktionsebene: Windows Server 2008
    4 = Gesamtstrukturfunktionsebene: Windows Server 2008 R2

  • Mit ADSIEdit ist zuerst eine Verbindung mit der Konfigurationspartition herzustellen. Anschließend muss der Wert im Attribut msDS-Behavior-Version das sich in den Eigenschaften des Containers <CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> befindet, von 4 auf 3 geändert werden.

  • Außerdem kann man den Gesamtstrukturfunktionsmodus in der MMC Active Directory-Domänen und -Vertrauensstellungen (domain.msc) kontrollieren.

  • In der AD-Powershell lässt sich der ForestMode mit dem Cmdlet Get-ADForest überprüfen.



Weitere Informationen:
Der Active Directory-Papierkorb im Windows Server 2008 R2
Die AD-Powershell im Windows Server 2008 R2

Saturday, June 06, 2009 7:00:35 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration | AD-Powershell  | 
 Wednesday, May 27, 2009
Der Kommandozeilenserver Server Core ist mit Windows Server 2008 eingeführt worden und wird mit Windows Server 2008 R2 weiterentwickelt. Redmond stellt für den Server Core unter 2008 R2 weitere Rollen sowie optionale Features zur Verfügung, die man sich mit oclist anzeigen lassen kann und mit ocsetup bzw. dism installiert werden.

Gerade aber die Erstkonfiguration des Server Core stellt viele Administratoren die lieber mit der Maus arbeiten vor eine Herausforderung. Denn mit Bordmitteln lässt sich der Server Core ausschließlich über die Kommandozeile konfigurieren, in der lange Befehle eingetippt werden müssen (was nicht gerade jedermanns Geschmackssache ist).

Kostenlose Tools im Internet schaffen Abhilfe und helfen dem Administrator, der sich nur schwer von seiner geliebten Maus trennen kann, die langen und aufwändigen Befehle nicht per Hand eintippen zu müssen.

Nun befindet sich jedoch in der Installationsvariante Server Core des Windows Server 2008 R2 das Skript Sconfig.cmd im Verzeichnis %windir%\System32 bereits „on Bord“, das die Erstkonfiguration des Server Core wesentlich erleichtert. Mit dem Skript können die folgenden Konfigurationen des Server Core vorgenommen werden:

  1. Domäne/Arbeitsgruppe
  2. Computername
  3. Lokalen Administrator hinzufügen
  4. Remoteverwaltung konfigurieren
  5. Windows Update-Einstellungen
  6. Updates herunterladen u. installieren
  7. Remotedesktop
  8. Netzwerkeinstellungen
  9. Datum und Uhrzeit
  10. Benutzer abmelden
  11. Server neu starten
  12. Server herunterfahren
  13. Zur Befehlszeile wechseln



Der Administrator kann jetzt einfacher die lokale Konfiguration des Server Core mit Bordmitteln vornehmen, damit in Zukunft die Fernwartung über die MMCs durchgeführt werden kann.

Des Weiteren existiert noch ein neues Kommandozeilentool tzutil.exe mit dem die Zeitzone konfiguriert werden kann.

 

Weitere Informationen:
Windows Server 2008 Core
Tools zum konfigurieren des Server Core
Server Core Installation Option Getting Started Guide
Download details: Server Core Job Aids

Wednesday, May 27, 2009 7:51:44 PM (W. Europe Standard Time, UTC+01:00)  #      Windows Server  | 
 Sunday, May 24, 2009

Eine weitere Neuheit die ab Windows Server 2008 R2 und Windows 7 eingeführt wird, ist die Möglichkeit einen Computer mit Windows Server 2008 R2 oder Windows 7 zur Domäne hinzuzufügen, ohne das die Maschine eine Verbindung zum Netzwerk hat (Offline Domain join). Diese neue Funktion kann ausschließlich ab Windows Server 2008 R2 und Windows 7 eingesetzt werden. Damit ist es möglich an entfernten Standorten die noch keine Anbindung ans Unternehmensnetzwerk haben Windows Server 2008 R2 Mitgliedserver und Windows 7 Clients zur Domäne hinzuzufügen.

Eine weitere Einsatzmöglichkeit für diese Funktion wäre, dass bereits die bestellten Windows 7 Clients direkt vom PC-Lieferanten vorinstalliert und zur Domäne hinzugefügt werden.

Oder bei der Massenanfertigung von virtuellen Maschinen können direkt nach der Betriebssysteminstallation die VMs zur Domäne hinzugefügt werden. Das ganze hat sogar den Vorteil, dass dadurch ein Neustart erspart bleibt der sonst nach dem Hinzufügen einer VM zur Domäne notwendig wäre.

Auch mit Deployment Tools, wie z.B. dem Windows-System-Image Manager (SIM) der Bestandteil des Windows Automated Installation Kit (WAIK) ist, können bereits während der unbeaufsichtigten (unattended) Installation eines Windows Server 2008 R2 und Windows 7 die Systeme zur Domäne hinzugefügt werden. Das ist möglich durch das Bereitstellen der relevanten Daten in der Unattend.xml-Datei, die für das offline domain join notwendig sind. Die Unattend.xml-Datei für Windows Server 2008 R2 und Windows 7 muss um einen weiteren Abschnitt erweitert werden, damit das Hinzufügen zur Domäne bereits während der Betriebssysteminstallation vonstattengehen kann.

Diese neue Funktion ist Dank einem neuen Kommandozeilentool Namens Djoin.exe möglich, dass nur ab Windows Server 2008 R2 und Windows 7 „on Bord“ ist. Mit diesem Kommandozeilentool lässt sich auch der sichere Kanal zwischen einem Windows Server 2008 R2 Mitgliedserver oder Windows 7 Client und einem Domänencontroller zurücksetzen.

Wie üblich bei den Windows-Kommandozeilentools lässt sich mit dem Befehl djoin /? die Hilfe aufrufen, worin die einzelnen Parameter beschrieben werden.


 

Einen Windows Server 2008 R2 oder Windows 7 offline zur Domäne hinzufügen

  • Im ersten Schritt muss von einem Windows Server 2008 R2 (DC oder Mitgliedserver) oder Windows 7 das Computerkonto im AD erstellt werden. Dabei wird eine Textdatei generiert, die lokal auf dem zu hinzuzufügenden Windows Server 2008 R2 oder Windows 7 benötigt wird. Diesen Vorgang bezeichnet man auch als bereitgestellte Installation oder auf englisch provision computer account.
  • Bei der bereitgestellten Installation wird das Computerkonto im AD standardmäßig im Container Computers erstellt. Der Befehl lautet so:
    Djoin.exe /provision /domain <Domänenname> /machine <Computername> /savefile <blob.txt>





  • Soll stattdessen das Computerkonto in einer OU erstellt werden, so müsste der folgende Befehl ausgeführt werden:
    Djoin.exe /provision /domain <Domänenname> /machine <Computername> /machineou <DN der OU> /savefile <blob.txt>





  • Standardmäßig wird mit Ausführen von Djoin.exe das Computerkonto im AD von einem Windows Server 2008 R2 DC erstellt. Durch die Angabe des Parameters /downlevel kann das Computerkonto von einem DC älter als Windows Server 2008 R2 bzw. in einer Windows 2000, Windows Server 2003 oder Windows Server 2008 Domäne erstellt werden:
    Djoin.exe /provision /domain <Domänenname> /machine <Computername> /downlevel /savefile <blob.txt>
  • Der mit diesem Befehl erstellte Base64-codierte Metadaten-Blob (Binary Large Object, die Textdatei) enthält sehr sensible Daten. Diese Datei sollte verständlicherweise sicher aufbewahrt werden, denn in dem Blob ist z.B. das Computerkontokennwort, Informationen über die Domäne einschließlich des Domänennamens, der Name eines Domänencontroller und der Security Identifier (SID) der Domäne enthalten. Daher muss zwingend darauf geachtet werden, dass wenn diese Datei physikalisch (über den Postweg) oder über das Netzwerk transportiert wird, die Sicherheit jederzeit gewährleistet ist und diese Datei nicht in fremde Hände gelangt.

    Der Blob sieht wie folgt aus:




  • Im zweiten Schritt muss auf dem Windows Server 2008 R2 oder Windows 7 der zur Domäne hinzugefügt werden soll, der folgende Befehl in einer Kommandozeile eingegeben werden. Dabei ist es zwingend, dass die CMD explizit als Administrator gestartet wird:
    Djoin.exe /requestodj /loadfile <Pfad zur blob.txt> /windowspath %windir% /localos
  • Zum Schluss ist ein Neustart fällig. Anschließend kann der Rechner ans Netzwerk verkabelt werden und befindet sich automatisch in der Domäne.
  • Mit type blob.txt bekommt man die Datei in der Kommandozeile angezeigt.




Welche Rechte werden benötigt?

Für diese Funktion werden Domänen-Admin Rechte benötigt oder den entsprechenden Personen wurde das Recht Hinzufügen von Arbeitsstationen zur Domäne über die Gruppenrichtlinie erteilt. Besser wäre es jedoch dieses Recht per Objektdelegierung an die jeweiligen Personen zu delegieren.

Clients in die Domäne hinzufügen

 


Wird eine Logdatei erstellt?

Wenn ein Fehler beim ausführen von Djoin.exe auftritt, erhält man in der Protokolldatei %windir%\debug\netsetup.log weitere Informationen.


 

Beitreten zur Domäne während einer unbeaufsichtigten Betriebssysteminstallation

Für das Beitreten zur Domäne während der Betriebssysteminstallation muss zuerst mit Djoin.exe das Computerkonto im AD und vor allem der Base64-codierte Metadaten-Blob generiert werden. Anschließend gilt es die Unattend.xml Datei zu erzeugen und einen neuen Abschnitt in der XML zu erstellen. Der Abschnitt sieht folgendermaßen aus:

<Component>
<Component name=Microsoft-Windows-UnattendedJoin>
<Identification>
<Provisioning>
<AccountData>Inhalt des Base64codierten Metadaten-Blob</AccountData>
</Provisioning>
</Identification>
</Component>

Nach dem fertigstellen der Unattended.xml Datei gilt es den Computer der zur Domäne hinzugefügt werden soll im Windows PE (Windows Preinstallation Environment) zu starten. Danach muss das Setup mit der Angabe der Antwortdatei ausgeführt werden:

Setup /unattend:<Pfad zur Unattended.xml>


 

Den sicheren Kanal (secure channel) mit Djoin.exe zurücksetzen

Wenn der sichere Kanal zwischen einem Windows Server 2008 R2 Mitgliedserver oder Windows 7 Client und einem Domänencontroller nicht mehr funktioniert, entsteht ein typisches Authentifizierungsproblem. Die Lösung für dieses Problem wäre entweder NLTEST auszuführen NLTEST /SC_RESET (NLTEST befindet sich in den Windows Support Tools und ist ab Windows Server 2008 bereits on Bord) oder die Maschine aus der Domäne zu entfernen und erneut hinzuzufügen.

Dieses Problem lässt sich nun auch mit Djoin.exe lösen. Dazu muss man sich entweder an dem betroffenen Windows Server 2008 R2 Mitgliedserver oder Windows 7 Client mit zwischengespeicherten Anmeldeinformationen oder an einem nicht betroffenen Windows Server 2008 R2 Mitgliedserver oder Windows 7 anmelden.

  • Als Erstes muss eine Eingabeaufforderung mit erhöhten Rechten (Start-Alle Programme-Zubehör-Eingabeaufforderung, Rechtsklick --> Als Administrator ausführen) gestartet werden. Danach gilt es diesen Befehl einzugeben:
    Djoin.exe /provision /domain <Domänenname> /reuse /machine <betroffener Computername> /savefile C:\blob.txt

  • Steht kein Windows Server 2008 R2 DC zur Verfügung, so muss der Parameter /downlevel mit angegeben werden:
    Djoin.exe /provision /domain <Domänenname> /reuse /machine <betroffener Computername> /downlevel /savefile C:\blob.txt
  • Wurde der Befehl auf einem nicht betroffenen System ausgeführt, muss der Blob auf das betroffene System kopiert werden.
  • Auf dem betroffenen System gilt es anschließend diesen Befehl, ebenfalls in einer CMD mit erhöhten Rechten auszuführen:
    Djoin.exe /requestodj /loadfile <Pfad zur blob.txt> /windowspath %windir% /localos
  • Zum Abschluss muss der Windows Server 2008 R2 oder Windows 7 neu gestartet werden.
  • Danach sollte der sichere Kanal mit dem folgenden Befehl überprüft werden:
    NLTEST /sc_verify:Domäne.TLD



Hinweis zum Parameter /downlevel

Das Kommandozeilentool Djoin.exe im Windows Server 2008 R2 und Windows 7 verwendet in erster Linie das LDAP-Protokoll um das Computerkonto im AD zu erstellen, was von früheren Betriebssystemversionen so nicht unterstützt wird. Wenn der Parameter /downlevel angegeben wird, wird das SAM-Protokoll verwendet falls das Erstellen des Computerkontos mit dem LDAP-Protokoll fehlschlagen sollte. Daher ist der Parameter /downlevel nur dann erforderlich, wenn kein Windows Server 2008 R2 DC in der Domäne existiert. Denn bei dem Parameter /downlevel wird die SE_MACHINE_ACCOUNT_PRIVILEGE-Berechtigung angewendet, anstatt die direkt auf dem Container erteilten Berechtigungen.

 


Weitere Informationen:
You cannot join a Windows 7 Beta-based or a Windows Server 2008 R2 Beta-based computer to an existing domain, and you receive an error message: "The parameter is incorrect"

Sunday, May 24, 2009 8:12:45 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration  | 
 Sunday, May 10, 2009

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

Sunday, May 10, 2009 8:20:04 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Objektverwaltung  | 
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: