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
Das Active Directory (AD) speichert seine Daten bekanntermaßen in einer Datenbank. Das Herzstück des AD ist die Datenbankdatei, die standardmäßig im Verzeichnis %windir%\NTDS\ gespeichert wird. Diese transaktionale Datenbank und die zugehörige Datenbank-Engine „Extensible Storage Engine (ESE)“, trägt den Namen NTDS.DIT. Dabei steht das „NTDS“ für New Technology Directory Services und das „DIT“ für Directory Information Tree.
Jeder Domänencontroller (DC) in einer Einzel- und Multidomänen-Gesamtstruktur hält seine eigene Kopie dieser AD-Datenbank (NTDS.dit), die kontinuierlich durch lokale Änderungen und durch die Replikationspartner aktualisiert wird. Die AD-Datenbank verändert sich in der Größe zum einen durch die lokalen Änderungen auf dem DC selbst und zum anderen durch die Änderungen die von den Replikationspartnern repliziert werden. Es ist zwingend notwendig, dass die AD-Daten konsistent zwischen den DCs durch die AD-Replikation gehalten werden. Aber die AD-Datenbankdatei ist ohnehin nie bis auf das letzte Bit zwischen mehreren DCs identisch.
Es gibt AD-Daten, die nicht zwischen den DCs repliziert werden. Denn z.B. werden die Indizes die eine performante LDAP-Suche ermöglichen lokal auf jedem DC erstellt. Dies kann bereits zu einem gewissen Maß an Größenunterschied in jeder AD-Datenbankdatei führen. Das einzige was repliziert wird ist die Anweisung, dass ein Attribut im AD indiziert werden soll. Wird in den Eigenschaften eines Attributs im Schema Snap-In die Option Attribut in Active Directory indizieren markiert, repliziert sich diese Änderung bei der nächsten Replikation der Schemapartition auf alle DCs in der Gesamtstruktur.
Die Gründe warum auf zwei DCs die AD-Datenbank unterschiedlich groß ist, sind:
-
Der Whitespace oder zu Deutsch: Der freie Speicherplatz in der AD-Datenbank. Dies trifft dann zu, wenn ein weiterer DC zur Domäne hinzugefügt wird. Wenn ein Server als zusätzlicher DC zu einer Domäne hinzugefügt wird kann es durchaus sein, das die AD-Datenbank des neuen DCs wesentlich kleiner ist als auf den bestehenden DCs. Das ist dann ein klares Indiz für den Whitespace der in der AD-Datenbank auf den bestehenden DCs existiert. Denn wird ein weiterer DC zur Domäne hinzugefügt, wird selbstverständlich nur die Nettokapazität der AD-Datenbank auf den neuen DC repliziert und nicht zusätzlich der unnötige Whitespace.
-
AD-Replikationsprobleme. Bestehen auf einem DC Replikationsprobleme, sei es mit einer oder mit allen Verzeichnispartitionen, bekommt dieser keine Aktualisierungen von seinen Replikationspartnern mehr mit.
-
In einer Multidomänen-Gesamtstruktur ist auf einem DC der globale Katalog (GC) aktiviert und auf dem anderen nicht. Oder auf einem DC wurde der GC „unbemerkt“ deaktiviert.
Die Ursachen in der Praxis sind in der Regel der Whitespace und AD-Replikationsprobleme, die den Unterschied zwischen den AD-Datenbankdateien ausmachen.
Der Whitespace in der AD-Datenbank
Der Whitespace in der AD-Datenbank entsteht folgendermaßen.
Wenn ein AD-Objekt gelöscht wird, verschwindet es nicht sofort aus der AD-Datenbank. Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf TRUE gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer entfernt und wandert anschließend in den Container „Deleted Objects“ (der in fast allen Verzeichnispartitionen existiert). Ab diesem Zeitpunkt wird das gelöschte Objekt als Tombstone (zu deutsch: Grabstein) bezeichnet.
Die gelöschten Objekte bleiben nun so lange im Container „Deleted Objects“ und somit in der AD-Datenbank erhalten, bis die Tombstone-Lifetime (TSL) abgelaufen ist. Erst wenn ein gelöschtes Objekt die TSL überschritten hat wird es endgültig vom Garbage Collection Prozess aus der AD-Datenbank entfernt. Der Garbage Collection Prozess läuft standardmäßig im 12-Stunden-Takt auf jedem DC in der Gesamtstruktur. Die Zeit lässt sich zwar verändern, jedoch ist das beim täglichen Betrieb nicht notwendig.
Ändern könnte man die Zeit durch das Attribut garbageCollPeriod, welches sich in den Eigenschaften des folgenden Containers befindet (die Angabe der Zeit muss in Stunden erfolgen):
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Wenn die Objekte unwiderruflich aus dem AD entfernt wurden, entsteht freier Speicherplatz (der sogenannte Whitespace) in der AD-Datenbank. Die Datenbankseiten auf denen die Objekte gespeichert waren, werden als frei markiert. Physikalisch wird aber dadurch die AD-Datenbank auf der Festplatte nicht kleiner. Stattdessen werden beim Hinzufügen neuer AD-Objekte diese auf den freien Datenbankseiten geschrieben, ohne dabei eine Speicheroptimierung bei späteren Abfragen dieser Objekte zu berücksichtigen. Durch das wiederbeschreiben der freien Datenbankseiten wird die Gesamtgröße der AD-Datenbank nicht größer. Zwar findet standardmäßig alle 12-Stunden durch den Garbage Collection Prozess auf jedem DC eine Onlinedefragmentierung der AD-Datenbank im laufenden Betrieb statt, jedoch wird dabei die AD-Datenbank ebenfalls nicht kleiner. Ob die Onlinedefragmentierung zweimal am Tag auch wirklich stattfindet, kann im Verzeichnisdienstprotokoll auf jedem DC kontrolliert werden. Denn beim Starten der Onlinedefragmentierung wird die EventID 700 und wenn sie abgeschlossen wurde, die EventID 701 protokolliert.
Bei der Onlinedefragmentierung werden lediglich die leeren Datenbankseiten neu angeordnet um einen zusammenhängenden freien Speicherplatz in der AD-Datenbank zu schaffen. Somit wird die durch die endgültige Löschung der AD-Objekte bedingte Fragmentierung der AD-Datenbank beseitigt und dadurch der Zugriff auf das AD optimiert bzw. beschleunigt. Bei den heutigen Festplattenpreisen ist es aber auch keineswegs tragisch das die AD-Datenbank physikalisch nicht kleiner wird. Dennoch ist es aus Performancegründen empfehlenswert, dass die AD-Datenbank „nur“ so groß ist, damit sie noch in den Arbeitsspeicher des DCs geladen werden kann.
Wie viel freier Speicherplatz in der AD-Datenbank tatsächlich existiert, kann durch eine Registry-Einstellung herausgefunden werden. Dazu gilt es im folgenden Registry-Schlüssel diese Einstellung vorzunehmen:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics
"6 Garbage Collection" = 1 (REG_DWORD)
Anschließend wird beim nächsten Durchlauf des Garbage Collection Prozesses, im Verzeichnisdienstprotokoll des DCs die EventID 1646 protokolliert. In dem Eintrag wird der freie Speicherplatz neben der Gesamtgröße der AD-Datenbank angegeben.
Es reicht in der Regel aus diese Registry-Einstellung nur auf einem DC in der Domäne zu konfigurieren, da sicherlich der freie Speicherplatz auf allen bestehenden DCs (bei gleicher DC Konfiguration) gleich ist.
Eine andere Variante mit der man sich einen tieferen Einblick über die Größe des freien Speicherplatzes in Form von leeren Datenbankseiten sogar der einzelnen Indizes in der AD-Datenbank verschaffen kann, wäre mit Esentutl. Dazu muss jedoch das AD offline sein. Bis einschließlich Windows Server 2003 muss hierzu der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. Unter Windows Server 2008 lässt sich dagegen der Dienst Active Directory-Domänendienste samt den abhängigen Diensten im laufenden Betrieb mit dem Kommandozeilenbefehl net stop ntds /y anhalten. Danach wird mit dem Befehl Esentutl /ms <Pfad zur Ntds.dit> oder durch das Aufrufen von Esentutl aus dem NTDS-Verzeichnis C:\Windows\NTDS>Esentutl /ms ein detaillierter Auszug der Ntds.dit erstellt. Es ist auch möglich die AD-Datenbank aus einer System State-Sicherung an einer alternativen Stelle wiederherzustellen, um diese AD-Datenbank zum überprüfen des freien Speicherplatzes zu nutzen. In der AD-Datenbank wird jede Tabelle zusammen mit der Anzahl der Datenbankseiten die es besitzt, samt der Anzahl der leeren Datenbankseiten die zur Verfügung stehen aufgelistet.
Damit die AD-Datenbank physikalisch kleiner wird, ist eine Offlinedefragmentierung notwendig. Natürlich müsste die Offlinedefragmentierung auf jedem DC erfolgen, damit die AD-Datenbank auf jedem DC auch physikalisch kleiner wird. Aber in den allermeisten AD-Umgebungen ist eine Offlinedefragmentierung nicht nötig. Wobei es jedoch in größeren AD-Gesamtstrukturen wiederum des Öfteren notwendig sein kann, eine Offlinedefragmentierung durchzuführen.
Wann ist eine Offlinedefragmentierung empfehlenswert?
-
Nach einer größeren Löschaktion im AD ist es empfehlenswert, wenn nach Ablauf der Tombstone-Lifetime die gelöschten Objekte endgültig aus der AD-Datenbank entfernt wurden, eine Offlinedefragmentierung der AD-Datenbankdatei durchzuführen.
-
In einer Multidomänen-Gesamtstruktur ist es ratsam, nach der Deaktivierung des globalen Katalogs auf einem DC eine Offlinedefragmentierung der AD-Datenbank durchzuführen.
-
Des Weiteren ist nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2008 eine Offlinedefragmentierung empfehlenswert. Nach einem Inplace-Update von Windows 2000 entsteht in der AD-Datenbankdatei eine erhebliche Menge an freiem Speicherplatz. Das ist aufgrund einer Verbesserung ab Windows Server 2003 möglich, worin eindeutige „security descriptors“ nur einmal (Single Instance Store) und nicht jedes Mal wenn sie verwendet werden in der AD-Datenbank gespeichert werden.
-
Wenn die DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) umgezogen werden, wie es z.B. nach einer Domänenaktualisierung von einer Windows 2000 Domäne zu einer Windows Server 2003 bzw. Windows Server 2008 Domäne der Fall sein könnte, entsteht ebenfalls freier Speicherplatz in der AD-Datenbank (genauer in der Domänenpartition). Die Größe der AD-Datenbank lässt sich dann mit einer Offlinedefragmentierung verkleinern.
Die Größe unter anderem der AD-Datenbank kann man sich mit dem folgenden Befehl anzeigen lassen:
FOR /f %i IN ('Dsquery Server -Domain %userdnsdomain% -o Rdn') DO dir \\%i\Admin$\NTDS
Eine Offlinedefragmentierung durchführen
Die Gesamtgröße der AD-Datenbank wird ausschließlich nur durch eine Offlinedefragmentierung verringert. Diese sollte beim Entfernen einer größeren Anzahl an AD-Objekten, nach dem Entfernen eines globalen Katalogs in einer Multidomänen-Gesamtstruktur, nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2003R2/2008 und nach dem Umzug der DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartition durchgeführt werden.
Die Offlinedefragmentierung wird folgendermaßen durchgeführt:
-
Zuerst sollte eine System State-Sicherung des DCs durchgeführt werden.
-
Damit eine Offlinedefragmentierung der AD-Datenbank auf einem DC durchgeführt werden kann, muss unter Windows 2000 und Windows Server 2003 der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. In diesen Modus gelangt man, wenn während der Bootphase des DCs die F8-Taste betätigt und die Option „Verzeichnisdienstwiederherstellung“ ausgewählt wird.
-
Ab Windows Server 2008 ist das Starten im Modus „Verzeichnisdienstwiederherstellung“ nicht notwendig (was aber möglich wäre). Ab einem Windows Server 2008 DC kann der Dienst Active Directory-Domänendienste im laufenden Betrieb entweder in der Dienstesteuerung (services.msc) oder in der Kommandozeile mit dem Befehl net stop ntds /y samt den abhängigen Diensten angehalten werden.
Active Directory-Domänendienste (AD-DS)
-
In der Eingabeaufforderung oder unter „Start-Ausführen“ gilt es das NTDSUTIL aufzurufen.
-
Ab Windows Server 2008 muss als erstes mit dem Befehl Activate Instance NTDS die NTDS-Instanz aktiviert werden. Unter Windows 2000 und Windows Server 2003/2003R2 muss dieser Schritt übersprungen werden.
-
Als nächstes gilt es den Befehl Files einzugeben.
-
In der „file maintenance“ Ebene werden mit dem Befehl info die aktuellen Informationen über den Pfad und der Größe der AD-Datenbank sowie der zugehörigen Protokolldateien angezeigt. Der Pfad zur AD-Datenbankdatei sollte notiert werden (zumindest sollte man ihn sich merken).
-
Mit dem Befehl compact to <Laufwerk>:\<Verzeichnis> wird eine neue, komprimierte AD-Datenbankdatei im angegebenen Verzeichnis erstellt. Es sollte ein Laufwerk und Verzeichnis an dem ausreichend Speicherplatz zur Verfügung steht ausgewählt werden, um die komprimierte neue AD-Datenbankdatei Ntds.dit zu speichern. Falls im Namen des Verzeichnispfads Leerzeichen enthalten sind, muss der Pfad in Anführungszeichen stehen. Z.B. compact to "C:\Neu NTDS".
-
Sobald die Offlinedefragmentierung abgeschlossen ist, gilt es mit der zweimaligen Eingabe von quit das NTDSUTIL zu verlassen.
-
Nun muss die neu erstellte defragmentierte Datenbankdatei "Ntds.dit" über die alte Datei "Ntds.dit" im aktuellen Pfad zur Active Directory-Datenbank (der in Schritt vier notiert bzw. gemerkt wurde), kopiert werden. Anschließend sind noch die alten Protokolldateien (*.log) zu löschen.
-
Das Kopieren der Datenbankdatei kann auch über die Kommandozeile mit folgendem Befehl erfolgen: Copy „C:\Neu NTDS\Ntds.dit“ „C:\Windows\NTDS\Ntds.dit“
Die darauffolgende Sicherheitsabfrage muss mit einem „j“ bestätigt werden.
-
Die alten Protokolldateien können in der Kommandozeile mit diesem Befehl gelöscht werden:
Del „C:\Windows\NTDS\*.log“
-
Danach gilt es den DC neu zu starten. Unter Windows Server 2008 wird mit net start ntds der Dienst Active Directory-Domänendienste samt den abhängigen Diensten gestartet.
-
Zum Schluss sollte noch eine System State-Sicherung mit der neuen Größe der Ntds.dit durchgeführt werden.
AD-Replikationsprobleme
Ein weiterer Grund warum zwischen zwei DCs die AD-Datenbank unterschiedlich groß ist, könnten AD-Replikationsprobleme sein. Hinweise ob es bei der AD-Replikation Probleme gibt, liefert bereits das Verzeichnisdienstprotokoll der DCs. Ein entscheidender Faktor bei der AD-Replikation ist die Tombstone-Lifetime (TSL). Denn DCs müssen sich mindestens einmal während der TSL mit ihren Replikationspartnern repliziert haben, da ansonsten Lingering Objects (herumlungernde Objekte) in der AD-Datenbank des DCs entstehen und die Replikationspartner den „veralteten“ DC von der AD-Replikation ausschließen.
Lingering Objects (veraltete Objekte)
Oftmals handelt es sich bei Replikationsproblemen um DNS-Probleme, denn für eine AD-Umgebung ist das DNS essentiell. Bevor ein DC die AD-Replikation startet führt dieser zuerst ein DNS-Lookup durch. Somit stellt der DC zwei Dinge sicher, zum einen das sein Replikationspartner online und funktionstüchtig ist und zum anderen, das die Namensauflösung funktioniert. Daher muss bei Replikationsproblemen die Umgebung genauestens untersucht und verifiziert werden, um welche Probleme es sich tatsächlich handelt.
Das nützlichste Werkzeug für die Überprüfung und Problembehandlung bei der AD-Replikation ist für alle Serverversionen Repadmin. Bis einschließlich „Windows Server 2003“ befindet sich Repadmin noch in den Windows Support Tools (auf der Server CD im Verzeichnis Support\Tools) und ab „Windows Server 2008“ ist es „on Bord“. Dieses Tool stellt quasi das Schweizer Messer für die AD-Replikation dar. Mit diesem Kommandozeilentool lässt sich die Replikationstopologie aus der Sicht jedes einzelnen DCs anzeigen.
Den Zustand der AD-Replikation kann man z.B. mit diesem Repadmin-Befehl überprüfen:
Repadmin /Replsum * /Bysrc /Bydest /Sort:Error
Die Replikationsinformationen auf einem DC lassen sich auch in eine CSV-Datei importieren, damit diese Datei z.B. in Excel geöffnet und leichter durchsucht werden kann. Der Befehl ist wie folgt:
Repadmin /showrepl * /csv > C:\Repadmin.csv
Eine andere Methode um Differenzen zwischen den AD-Datenbanken aufzudecken, ist neben Repadmin das DSASTAT. Details dazu liefert der folgende Artikel:
Domänencontroller vergleichen
Es könnte aber auch sein, dass ein Problem in der AD-Datenbank auf einem DC existiert. Dieses lässt sich mit einer Überprüfung der AD-Datenbankdatei herausfinden. Dazu sollte die Integrität der Ntds.dit mit NTDSUTIL untersucht und falls bei der Überprüfung Probleme gemeldet werden, könnten diese sich evtl. mit einem Fixup beheben lassen.
Siehe:
Die Active Directory-Datenbank reparieren
Die unterschiedliche Größe der AD-Datenbank zwischen globalen Katalogen
Wenn in einer Multidomänen-Gesamtstruktur auf einem DC der globale Katalog (GC) aktiviert wird, werden alle AD-Objekte aus allen Domänen in den GC repliziert. Im GC wird die vollständige Domänenpartition (alle Objekte samt allen Attributen) der eigenen Domäne gespeichert, in der sich der GC befindet. Die Domänenpartitionen der anderen Domänen werden ebenfalls in den GC repliziert, es werden jedoch nicht alle Attribute der Objekte gespeichert. Nur die Attribute die für eine Suchoperation relevant sein könnten (z.B. der DN eines Objekts) werden gespeichert.
Wird auf einem DC der GC aktiviert, gibt sich dieser nach Beendigung der Replikation im DNS als solcher bekannt. Das der DC endgültig ein GC ist, wird im Verzeichnisdienstprotokoll mit der EventID 1119 (was zwingend erscheinen muss!) protokolliert.
Ob das Heraufstufen eines DCs zum GC erfolgreich abgeschlossen wurde, lässt sich anhand des folgenden Artikels ermitteln:
Globaler Katalog – Sein oder nicht sein
Falls das Heraufstufen zum GC ordnungsgemäß abgeschlossen wurde und sich die lokale AD-Datenbankdatei dennoch von anderen GCs in der Größe wesentlich unterscheidet (z.B. 50%), so könnte ein DNS- und/oder Replikationsproblem vorliegen. Auch hierbei muss dann ein tiefergehendes Troubleshooting betrieben und die AD-Replikation mit Repadmin untersucht werden. Bei der Fehlersuche sollte die erste Anlaufstelle die Ereignisanzeige des DCs sein, DCDIAG sollte ausgeführt werden und bei Verdacht auf DNS-Probleme könnte man neben dem DCDIAG (mit den DNS-Parametern) noch das DNSLint ausführen.
Weitere Informationen:
Die Tombstone Lifetime
Globaler Katalog (Global Catalog - GC)
Die Protokollierung des Active Directory`s konfigurieren
Extensible Storage Engine Architecture
The Active Directory database garbage collection process
Performing offline defragmentation of the Active Directory database
Im Windows Server 2008 R2 ist ein weiteres neues Werkzeug integriert, das sich Active Directory-Verwaltungscenter (dsac.exe) nennt. Die neue Managementkonsole mit flexiblen Filtermöglichkeiten basiert auf der Powershell Version 2 und stellt im Prinzip eine grafische Shell für die Powershell dar. Denn nach dem die auszuführende Aufgabe in der Konsole ausgewählt wurde, führt dsac.exe die entsprechenden AD-Cmdlets aus. Jede Lese- und Schreibaktion im AD-Verwaltungscenter wird über die AD-Powershell durchgeführt. Das neue Werkzeug verringert den allgemeinen administrativen Aufwand, der in einer AD-Umgebung täglich zu bewältigen ist. Mit dieser neuen aufgabenbasierten Managementkonsole, beginnt im neuen Server-Betriebssystem die MMC 4 Ära.
Die im Vergleich zu der MMC „Active Directory-Benutzer und -Computer“ abgespeckte Managementkonsole „Active Directory-Verwaltungscenter“, ist in erster Linie eher an den Systemadministrator bzw. an den First-Level Support gerichtet. Denn es stehen nicht die gleichen Funktionen wie in der MMC Active Directory-Benutzer und -Computer (dsa.msc) zur Verfügung. Daher kann der AD-Administrator nicht auf die MMC dsa.msc verzichten (auch wenn es theoretisch möglich wäre). Die Personen denen die entsprechenden Rechte im AD delegiert wurden, können mit der neuen Konsole effektiver ihren täglichen Routineaufgaben nachgehen als mit der MMC dsa.msc. Gerade in größeren AD-Umgebungen mit mehreren Domänen spielt dieses Werkzeug seine Stärken aus.
Das AD-Verwaltungscenter ist, neben der AD-Powershell, von dem Dienst Active Directory-Webdienste (ADWS) abhängig, das erst ab Windows Server 2008 R2 zur Verfügung steht. Dsac.exe ist nicht auf die RPC- oder LDAP-Schnittstelle angewiesen. Daher muss in den vertrauten Domänen oder in der vertrauten Gesamtstruktur mindestens ein Windows Server 2008 R2 DC existieren oder das AD Management Gateway Service muss auf einem Windows Server 2003 DC bzw. Windows Server 2008 DC installiert sein, damit dsac.exe remote ausgeführt werden kann. Auf dem Windows Server 2008 R2 DC auf dem dieser Dienst läuft, darf der TCP-Port 9389 von der evtl. aktivierten lokalen Windows-Firewall nicht blockiert werden. Läuft der Dienst AD-Webdienste nicht oder ist dieser wegen einer Firewall nicht erreichbar, funktioniert das dsac.exe nicht.
Damit eine Windows Server 2003 oder Windows Server 2008 Umgebung mit dem AD-Verwaltungscenter (neben der AD-Powershell) administriert werden kann, muss das AD Management Gateway Service installiert werden:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Das AD-Verwaltungscenter kann lediglich zur Verwaltung von AD DS-Domänen und nicht von AD LDS-Umgebungen eingesetzt werden!
Welche Funktionen stehen im AD-Verwaltungscenter gegenüber der MMC „AD-Benutzer und -Computer“ nicht zur Verfügung?
- Ein Drag & Drop ist nicht möglich.
- Es steht keine Delegierungsfunktion zur Verfügung.
- Die FSMO-Rollen der Domäne können nicht angezeigt werden, wie in der MMC dsa.msc.
Was kann mit dem AD-Verwaltungscenter alles durchgeführt werden?
- Mit dem AD-Verwaltungscenter können neue Benutzerkonten erstellt oder bestehende verwaltet werden.
- Es können neue Gruppenkonten erstellt oder bestehende verwaltet werden.
- Es können mehrere Objekte gleichzeitig ausgewählt und bearbeitet werden.
- Neue OUs können erstellt bzw. bestehende verwaltet werden.
- Auch neue Computerkonten können erstellt oder bestehende verwaltet werden.
- Es ist möglich in der gleichen dsac.exe Instanz, sich mit mehreren Domänen oder Domänencontrollern zu verbinden und sich die AD-Informationen anzuzeigen bzw. Änderungen durchzuführen.
- Durch die vorgegebenen oder eigens kreierten Filter (bei der globalen Suche) können lediglich die benötigten AD-Objekte angezeigt werden.
- Im Gegensatz zu dsa.msc lässt sich aus dem AD-Verwaltungscenter neben dem Domänen- nun auch der Gesamtstrukturfunktionsmodus heraufstufen.
Die Installation des AD-Verwaltungscenter
Das AD-Verwaltungscenter kann ausschließlich auf Windows Server 2008 R2 und Windows 7 Clients, auf folgende Varianten installiert werden:
- Durch das Installieren der AD DS-Rolle auf einem Windows Server 2008 R2.
- Durch das Heraufstufen eines Windows Server 2008 R2 zu einem Domänencontroller.
- Durch das Installieren der RSAT auf einem Windows Server 2008 R2.
- Durch das Installieren der RSAT auf einem Windows 7 Client.
Das AD-Verwaltungscenter wird zusammen mit dem „Active Directory-Modul“ für die Windows PowerShell und dem .NET Framework 3.5.1 installiert. Diese beiden Komponenten sind, neben dem Dienst AD-Webdienste, die Voraussetzung damit das AD-Verwaltungscenter eingesetzt werden kann.
Das Arbeiten mit dem AD-Verwaltungscenter
Wenn das AD-Verwaltungscenter gestartet wird, sticht das zurücksetzen der Benutzerkennwörter sowie das entsperren von Benutzerkonten ins Auge. Diese beiden Optionen sind einer der meisten Fehlerquellen mit denen sich der Administrator im täglichen Leben beschäftigen muss. Des Weiteren sieht man in der linken Hälfte der Managementkonsole den Navigationsbereich. Dort kann man sich durch die einzelnen Container durch hangeln. Die oft besuchten Container werden dabei für den schnellen Zugriff direkt angezeigt.
Das Erstellen eines neuen Benutzerkontos sieht wie folgt aus. Es lassen sich die Kontooptionen, Organisationsinformationen, Gruppenmitgliedschaften und Profileinstellungen in einem Schritt konfigurieren.
In der Domäne oder in einer bestimmten OU lassen sich die Objekte anhand der vorgegebenen Filtermöglichkeiten sogar mit zusätzlichen Attributen anzeigen.
Natürlich kann man auch entsprechende Suchkriterien für Computerkonten auswählen.
Bei der globalen Suche kann man sich mit den vorgegebenen oder selbst erstellten Filtermöglichkeiten die gewünschten Objekte anzeigen lassen. Dabei kann man auch nach der Auswahl der vorgegebenen Filtermöglichkeiten, den echten LDAP-Filter anzeigen lassen.
Des Weiteren ist es wie im Windows Explorer möglich, durch die Eingabe eines bestimmten LDAP-Pfads in der Adresszeile direkt in die gewünschte OU zu navigieren.
Es ist schon irgendwie komisch. Zuerst war das Single
Dasein, dann kam die Zweisamkeit mit der Liebe meines Lebens und nun mein Weltwunder.
Mein Weltwunder entstand in 268 Tagen in einer warmen
und geschützten Umgebung.
Meine Frau und ich bekamen am 18. März 2009 um 04:44
Uhr unser erstes Baby. Unser Stammhalter kam mit 3.200g und 49cm zur Welt. Mama
und Kind sind wohl auf und wir alle gewöhnen uns (oder versuchen es zumindest)
an unsere neue Rolle.
Aber früher… ja damals war alles anders. Der stolzeste
Papa den je dieser Planet gesehen hat, kam nämlich mit einem Kampfgewicht von
4.550g und 57cm zur Welt. 
Es war und ist schon ein unbeschreibliches und vor
allem faszinierendes Erlebnis. Den Moment der Geburt mit Worten zu beschreiben,
ist einfach nicht möglich. Nur wer diesen Moment selbst miterlebt hat, weiß was
ich meine. Für mich war es definitiv der schönste und bewegenste Moment in
meinem Leben. Das erste „schreien“ unseres Sohnes, hat sich tief in meinem
Herzen eingebrannt.
Sehr geehrte Damen und Herren, Ladies and Gentlemen, Bayanlar ve Baylar, Mesdames
et Messieurs, unser neustes Mitglied unserer Familie heißt: Kaan Arda Dikmenoglu
Das in
den Initialen des Namen das AD
auftaucht, war kein Kriterium bei der Wahl des Namen.
Endlich wird es in Zukunft auch einen Best Practice Analyzer (BPA) für die Active Directory Domain Services (kurz AD DS-BPA) geben. Der BPA der bereits seit längerem für verschiedene Microsoft Produkte existiert (Siehe Abschnitt „Weitere BPAs“), ist für viele Administratoren ein unverzichtbares Werkzeug. Denn mit dem BPA lassen sich Konfigurationsprobleme schnell und einfach aufspüren.
Der BPA für die AD DS-Rolle wird erstmals im Windows Server 2008 R2 eingeführt und hilft dem Administrator dabei, Best Practices bei der Konfiguration der AD DS-Umgebung zu implementieren. Ein oder mehrere DCs lassen sich gegen eine Reihe von vordefinierten Best Practices überprüfen. Der AD DS-BPA erstattet nach der Durchführung Bericht, ob der DC mit den Best Practices kompatibel oder nicht konform ist.
Wenn die AD DS-Umgebung installiert und alles Notwendige konfiguriert wurde, ist es empfehlenswert die durchgeführten Konfigurationen anschließend auf Fehler zu überprüfen. Doch dies ohne den AD DS-BPA zu verifizieren ist gar nicht so einfach und dauert unter Umständen viele Stunden. Aber mit dem neuen AD DS-BPA lassen sich schnell und einfach Konfigurationsfehler und Schwachstellen in der AD DS-Umgebung auf Knopfdruck aufspüren.
Der AD DS-BPA lässt sich zum einen über die grafische Oberfläche und zum anderen, über die Powershell-Kommandozeile ausführen. In der grafischen Oberfläche befindet sich der AD DS-BPA ausschließlich im Server Manager des Windows Server 2008 R2. Der Server Manager ist erstmals auch in den RSAT für den Windows 7 Client enthalten.
Der BPA scannt die AD DS-Rolle so wie sie auf dem Windows Server 2008 R2 DC konfiguriert ist. Nach der Durchführung werden im Server Manager in den Reitern „Nicht Kompatibel“ und „Kompatibel“ die Ergebnisse angezeigt. Ein Ergebnis kann dabei als „Schweregrad“ Fehler, Warnung oder Kompatibel enthalten.
Bei Fehlern die im Reiter „Nicht Kompatibel“ angezeigt werden und somit gegen die „Best Practices“ verstoßen (wenn z.B. kein DNS-Server für die Domäne erreichbar ist), werden in der Beschreibung die Punkte „Problem“, „Auswirkung“ und „Lösung“ angezeigt. Durch die genauen Angaben erfährt man, welche Auswirkung das gefundene Problem hat und vor allem, wie es sich lösen lässt.
Die Ergebnisse können gefiltert werden, indem einzelne Berichte für die zukünftigen Durchführungen des BPA vorübergehend ausgeschlossen und zu einem späteren Zeitpunkt erneut einbezogen werden.
Im AD DS-Umfeld steht der BPA unter Windows Server 2008 R2 vorerst für die folgenden Rollen zur Verfügung:
- Active Directory Certificate Services
- Active Directory Domain Services
- DNS Server
Der BPA wird über die “Windows Updates” stetig verbessert und erweitert.
Was ist möglich?
- Der AD DS-BPA lässt sich über den Server Manager oder über die Powershell, nur auf Windows Server 2008 R2 DCs ausführen.
- Der AD DS-BPA kann über den Server Manager oder über die Powershell lokal und remote auf einem Windows Server 2008 R2 Vollinstallation, Windows Server 2008 R2 RODC und Windows Server 2008 R2 Core ausgeführt werden.
- Auf einem Windows Server 2008 R2 Core kann lokal der AD DS-BPA ausschließlich über die Powershell ausgeführt werden, da der Server Manager in der grafischen Oberfläche auf einem Windows Server 2008 R2 Core nicht existiert.
- Von einem Windows 7 Client worauf das RSAT (Remote Server Administration Tools) installiert ist, kann der AD DS-BPA über den Server Manager oder über die Powershell remote auf einem Windows Server 2008 R2 Vollinstallation oder Windows Server 2008 R2 Core ausgeführt werden.
- Nur über die Powershell können mehrere Rollen zur gleichen Zeit überprüft werden (z.B. die AD DS- und DNS-Rolle).
Was ist nicht möglich?
- Der Server Manager vom Windows Server 2008 R2, worin sich der AD DS-BPA befindet, lässt sich nicht auf Windows 2000, Windows Server 2003/2003 R2 oder Windows Server 2008 installieren.
- Der AD DS-BPA lässt sich nicht über den Server Manager remote auf einen Windows 2000 DC, Windows Server 2003/2003 R2 DC und Windows Server 2008 DC ausführen.
- Der AD DS-BPA lässt sich nicht über die Powershell remote auf einen Windows 2000 DC, Windows Server 2003/2003 R2 DC und Windows Server 2008 DC ausführen.
Wie wird der AD DS-BPA im Server Manager installiert?
Sobald auf einem Windows Server 2008 R2 Vollinstallation die AD DS-Rolle installiert und dieser zum Domänencontroller gestuft wird, steht der AD DS-BPA automatisch im Server Manager zur Verfügung. Es ist auch nicht notwendig weitere Komponenten zu installieren um den AD DS-BPA zu nutzen.
Auf einem Windows Server 2008 R2 Core kann der AD DS-BPA lokal ausschließlich über die Powershell ausgeführt werden.
Die Bestandteile des AD DS-BPA
Der Server-Manager im Windows Server 2008 R2 beinhaltet eine Engine mit dem der AD DS-BPA ausgeführt wird. Dabei besteht der AD DS-BPA aus den folgenden Komponenten:
- AD DS-BPA PowerShell Skript: Das Skript sammelt AD DS-Konfigurationsdaten und speichert sie in ein XML-Dokument.
- XML-Schema: Das Schema definiert das Format des XML-Dokuments, das vom AD DS-BPA PowerShell Skript erzeugt wurde.
- AD DS-BPA Regeln: Die Regeln definieren die Best Practice-Konfiguration einer AD DS Umgebung.
- AD DS-BPA Leitfaden: Diese Informationen helfen dem Administrator ihre AD DS-Umgebung entsprechend den Best Practices zu konfigurieren.
Die Funktionsweise des AD DS-BPA
Wenn der AD DS-BPA auf einem DC ausgeführt wird, werden die folgenden Schritte durchgeführt:
- Die BPA Engine sammelt in der bestehenden AD DS-Umgebung mit dem „AD DS-BPA Powershell Skript“ Informationen über die AD DS-Konfiguration und speichert sie in ein XML-Dokument.
- Danach wird das XML-Dokument gegen das „XML-Schema“ validiert.
- Nach dem Anwenden der „AD DS-BPA Regeln“ auf das XML-Dokument wird anschließend ein Bericht anhand des „AD DS-BPA Leitfaden“ erstellt.
Den AD DS-BPA lokal in der grafischen Oberfläche ausführen
Der AD DS-BPA lässt sich mit der Maus im Server Manager eines Windows Server 2008 R2 DCs Vollinstallation ausführen. Dort findet man ihn nach Auswahl der Rolle Active Directoy-Domänendienste in der Zusammenfassung.
Das Ausführen des AD DS-BPA lokal auf einem Windows Server 2008 R2 DC Vollinstallation, in der AD-Powershell
In der Powershell-Kommandozeile lässt sich der AD DS-BPA ebenfalls ausführen.
- Als erstes gilt es das Server Manager-Modul mit dem folgenden Befehl in die Powershell-Sitzung zu importieren.
Import-Module ServerManager
- Im zweiten Schritt muss das BPA-Modul mit diesem Befehl importiert werden.
Import-Module BestPractices
- Mit diesem Befehl werden alle verfügbaren BPAs aufgelistet.
Get-BPAModel
- Nach der Durchführung des AD DS-BPA werden die Ergebnisse mit diesem Befehl angezeigt.
Get-BPAResult Microsoft/Windows/DirectoryServices
- Die AD DS-Rolle wird mit diesem Befehl überprüft.
Invoke-BPAModel Microsoft/Windows/DirectoryServices
- Einzelne Ergebnisse werden mit diesem Befehl ausgeschlossen bzw. erneut einbezogen.
Set-BPAResult
Den AD DS-BPA remote im Server Manager ausführen
Mit dem Server Manager lässt sich nun auch unter Windows Server 2008 R2 wie es bei MMCs üblich ist, remote eine Verbindung zu anderen Servern aufbauen. Das war vor Windows Server 2008 R2 nicht möglich. Der Server Manager steht unter Windows Server 2008 R2 sowie auf dem Windows 7 Client nach dem Installieren der RSAT zur Verfügung.
Doch bevor man sich mit dem Server Manager zu einem anderen DC verbinden kann, muss der zu verwaltende DC dies vorher zulassen. Das Zulassen für die Remoteverwaltung kann ebenfalls im Server Manager erfolgen. Die notwendigen Einstellungen werden bei aktivierter Windows-Firewall automatisch vorgenommen.
Über die Powershell muss auf dem zu verwaltenden DC zuerst der Befehl set-executionPolicy -executionPolicy remotesigned ausgeführt werden. Alle dazu benötigten Windows-Firewalleinstellungen werden durch diesen Befehl Configure-SMRemoting.ps1 -force -enable vorgenommen.
Anschließend lässt sich die AD DS-Rolle auf einem beschreibbaren Windows Server 2008 R2 DC, Windows Server 2008 R2 RODC oder Windows Server 2008 R2 Core DC von der Ferne aus überprüfen.
Den AD DS-BPA lokal auf einem Windows Server 2008 R2 Core DC ausführen
Ein lokales Ausführen des AD DS-BPA auf einem Windows Server 2008 R2 Core DC ist nur über die Powershell möglich. Die Powershell ist jedoch standardmäßig nicht installiert. Dazu müssen die folgenden Features installiert werden:
-
start /w ocsetup NetFx3-ServerCore
-
start /w ocsetup ServerCore-WOW64
-
start /w ocsetup MicrosoftWindowsPowerShell
-
start /w ocsetup MicrosoftWindowsPowerShell-WOW64
-
start /w ocsetup ActiveDirectory-PowerShell
Achtung: Die Featurenamen sind case sensitive!
Nach der Installation der Features, lässt sich die Powershell aus dem Verzeichnis %windir%\system32\windowspowershell\v1.0 mit dem Befehl powershell aufrufen. Anschließend gilt es die folgenden Powershell-Module zu laden:
- import-module activedirectory
- import-module servermanager
- import-module bestpractices
Überprüfen lässt sich danach die AD DS-Rolle mit diesem Befehl:
Get-WindowsFeature AD-Domain-Services | invoke-bpamodel
Die Ergebnisse nach der Durchführung des AD DS-BPAs lassen sich mit diesem Befehl anzeigen:
Get-WindowsFeature AD-Domain-Services | get-bparesult
Den AD DS-BPA remote auf einem Windows Server 2008 R2 Core DC ausführen
Bevor man den AD DS-BPA von der Ferne aus über den Server Manager oder über die AD-Powershell auf einem Windows Server 2008 R2 Core ausführen kann, muss zuerst auf dem Server Core die Fernadministration erlaubt werden. Mit dem folgenden Befehl werden die entsprechenden Konfigurationen in der Windows-Firewall vorgenommen: winrm quickconfig.
Anschließend kann man mit dem Server Manager oder über die Powershell von einem Windows Server 2008 R2 oder von einem Windows 7 Client (mit installierten RSAT) remote den AD DS-BPA auf einem Windows Server 2008 R2 Core DC ausführen.
Weitere BPAs für verschiedene Microsoft Produkte
Für Gruppenrichtlinien, Exchange, ISA, SQL und einige mehr gibt es den BPA schon seit längerer Zeit.
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|