Ein weit verbreitetes Missverständnis ist, das ein Ereignis, welches die dringende AD-Replikation auslöst, sofort an alle Domänencontroller (DC) repliziert wird. Genau genommen handelt es sich bei einer dringenden AD-Replikation (urgent replication) noch nicht einmal um eine echte sofortige Replikation. In Wirklichkeit wird lediglich die Benachrichtigung, dass Änderungen auf dem Quell-DC vorliegen, an erster Stelle der Replikationswarteschlange hinzugefügt.

Genau wie bei der standortinternen (Intra-Site) Replikation, basiert die dringende AD-Replikation auf Änderungsbenachrichtigungen (change notification). Außer das beim Eintreten eines wichtigen Ereignisses die Benachrichtigung unverzüglich versendet wird, statt 15 Sekunden (bzw. 300 Sekunden unter Windows 2000) abzuwarten. Diese Änderungsbenachrichtigung wird sofort an alle Replikationspartner versendet, noch bevor die in der Replikationswarteschlange anstehenden Änderungsbenachrichtigungen verschickt werden. Jeder DC, der eine dringende Aktualisierung erhält, leitet diese ebenfalls umgehend an seine Replikationspartner weiter. Durch diese Vorgehensweise ist sichergestellt, dass alle DCs am gleichen AD-Standort innerhalb von Sekunden aktualisiert werden.

Durch die dringende AD-Replikation erhalten die Replikationspartner in gewohnter Weise sofort eine Änderungsbenachrichtigung über das RPC over IP Protokoll. Aufgrund des hohen Replikationsaufkommens werden bei der dringenden AD-Replikation standardmäßig die AD-Standortgrenzen nicht überschritten. Das lässt sich jedoch konfigurieren.

Ereignisse, die eine dringende AD-Replikation auslösen

Die dringende AD-Replikation wird bei Eintreten bestimmter Ereignisse standardmäßig nur innerhalb eines AD-Standorts durchgeführt. Dabei ist es unabhängig, unter welchem Betriebssystem die DCs betrieben werden. Ist allerdings die standortübergreifende Änderungsbenachrichtigung in der Standortverknüpfung (Site-Link) aktiviert, werden diese Ereignisse auch unverzüglich zwischen den AD-Standorten repliziert.

Siehe dazu:

Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren

Die Mitglieder einer Gruppe werden im mehrwertigen Attribut member des AD-Objekts der Gruppe gespeichert. Bei diesem Attribut handelt es sich um das Forward-Link Attribut und das Pendant dazu ist das mehrwertige Attribut memberOf, das im Benutzerobjekt gespeichert ist und als Back-Link bezeichnet wird.

Mehr über verknüpfte Attribute gibt es hier: Verknüpfte Attribute

Möchte man die Mitglieder einer bestimmten Gruppe in eine andere kopieren, so hat man neben skriptbasierten Lösungen folgende Möglichkeiten

In der AD-PowerShell

In einem Einzeiler sieht der AD-PowerShellbefehl zum Kopieren der Mitglieder einer Gruppe in eine andere so aus:

Get-ADGroupMember <Quell-Gruppe> | Select sAMAccountName | ForEach { Add-ADGroupMember <Ziel-Gruppe> -Members $_.sAMAccountName }

Was in größeren und weltweiten AD-Umgebungen für selbstverständlich gehalten wird, sieht in kleineren und mittelständischen Unternehmen (KMUs) ganz anders aus.

Diese Frage wird oft gestellt: Warum sollte der Server ausschließlich als DC betrieben werden und kann der DC nicht weitere Dienste oder Applikationen zur Verfügung stellen?

Die Antwort darauf lautet: Ja, ein DC kann und darf weitere Dienste zur Verfügung stellen. Beispielsweise ist seitens Microsoft auch unterstützt, Applikationen wie z.B. Exchange oder SQL auf einem DC zu installieren. Doch es ist keineswegs empfohlen weitere Dienste oder Applikationen auf einem DC zu betreiben. Die Gründe folgen.

Viele Administratoren bringen an dieser Stelle nun den Einwand, dass der SBS doch das Paradebeispiel dafür ist. Ein SBS muss ein DC und darf nicht ein Mitgliedsserver sein. Des Weiteren existieren doch auch Exchange und SQL auf einem SBS. Die Antwort auf diese Argumentation lautet jedoch: Der SBS ist ein Spezialfall und ist gezielt für die Produktpositionierung so konzipiert worden. Mit dem SBS 2008 (Premium) wurde das entsprechend angepasst, in dem bspw. eine extra Windows Server Lizenz für die SQL Serverinstallation mitgeliefert wird.

Ein Schelm, wer Böses dabei denkt, dass der SBS kein echter Server sei.

Die Gründe weshalb es empfohlen ist, den Server nur als dedizierten DC zu betreiben und keine anderen Dienste zur Verfügung zu stellen sind:

• Performance: Werden auf einem DC weitere Applikationen und Dienste installiert, kostet das Ressourcen. Damit steigt das Risiko, dass wenn sich viele Benutzer zur gleichen Zeit an der Domäne authentisieren, dem DC nicht genügend Ressourcen zur Verfügung stehen um jede Authentisierung eines Benutzers erfolgreich durchzuführen. Wenn intensiv mit AD-Abfragen gearbeitet wird, können die fehlenden Ressourcen den DC unnötig auslasten und von Nachteil sein.
  
  
• Sicherheit: Werden auf einem DC Applikationen oder Dienste installiert, muss man bei entsprechender Rollentrennung dem Betreuer dieser Applikation bzw. der Dienste Rechte auf dem DC einräumen. Oftmals wird dann der Benutzer in die Gruppe der BuiltIn\Administratoren oder in die Gruppe der Domänen-Admins hinzugefügt, was beides selbstverständlich keineswegs gewünscht ist. Denn zum einen sind das zu viele Rechte die man dem Benutzer einräumt und zum anderen, birgt das Gefahren. Der Benutzer, wenn der DC auch noch der Einzige in der Domäne ist, könnte die Domäne gefährden.
  
  Mit Einführung von Windows Server 2008 und dem RODC hat man die Situation entschärft, was die Sicherheit der AD DS anbetrifft. Der Administrator für die Anwendung kann auf einem RODC lokale Adminrechte erhalten und hat dennoch keine weiteren Rechte auf die AD DS.
  
  Es sollten alle Server hinter Schloss und Riegel stehen und nur Befugten sollte der Zugang erlaubt sein. Doch aus AD-Sicht ist es nicht weiter tragisch wenn „nur“ der Applikationsserver anstatt eines DCs unter dem Schreibtisch steht.
  
  
• Rollentrennung: Folgt man der Empfehlung und betreibt dedizierte DCs, kann man in einem Problemfall einen DC in einer Umgebung mit mehreren DCs einfach ersetzen. Ist jedoch auf dem DC eine wichtige Applikation installiert, gestaltet sich der Austausch besonders schwierig!
  
  
• Stabilität: Das Installieren von Applikationen und Diensten gefährdet die Stabilität eines DCs (RWDC und RODC). Denn bereits das Installieren eines zusätzlichen nicht kompatiblen (Drucker?) Treibers kann zu Instabilitäten führen, so dass es regelmäßig zum BSOD (Blue Screen of Death) kommt. Dies kann natürlich auch zum Totalausfall des Active Directories führen, bspw. durch Inkonsistenzen die durch solche Abstürze entstehen. Wenn sich in der Domäne mehrere DCs befinden, kann man einen dedizierten DC im laufenden Betrieb herunterstufen, den Computernamen ändern und anschließend wieder zum DC heraufstufen. Ob das die installierte Applikation auf dem DC verkraftet ist fraglich. Ein installierter Exchange Server verhindert dies sehr wirkungsvoll.
  
  

Das sind die Hauptargumente warum es ein dedizierter DC sein sollte. Natürlich ist die Welt da draußen alles andere als rosarot und die Realität in der Praxis sieht anders aus. Man muss selbstverständlich unterscheiden, ob es sich um ein fünf-Mann oder um ein weitweites Unternehmen mit 500.000 Mitarbeitern handelt. In einem fünf Mann Unternehmen ist das Budget für IT-Kosten meist knapp und mit einem dedizierten DC würde man in solch einer Umgebung sicherlich mit Kanonen auf Spatzen schießen.

Daher gilt für Unternehmen die sich aus welchen Gründen auch immer keinen dedizierten DC leisten (können oder wollen), folgende Empfehlung:

• Was die Performance des DCs anbetrifft, sollte eine Applikation bzw. Dienst vor dem Einsatz auf einem DC in einer produktiven Umgebung, ausgiebig in einer Testumgebung möglichst realitätsgetreu getestet werden. Das wichtigste dabei ist das Monitoring. Erst wenn die Tests nach mehreren Tagen zufriedenstellende Ergebnisse geliefert haben, sollte man die Applikation oder den Dienst auf dem DC in der produktiven Umgebung installieren. Bei den Tests die als Referenz dienen, sollte man über mehrere Tage die Auslastung des DCs (CPU, RAM, HDD, NIC) zu verschiedenen Zeitpunkten verteilt über den Tag aufzeichnen. Wurde die Applikation bzw. der Dienst auf dem produktiven DC installiert, sollte man die Auslastung des DCs ständig mit der Referenz vergleichen.

  Natürlich ist das ein Kraftakt den sich ein Unternehmen mit 5 Angestellten zwei Mal überlegt, ob er diese Tests durchführen soll bzw. kann. Ich kann es aber jedem nur ans Herz legen!
  
  
• Derjenige der die Applikation bzw. den Dienst auf einem DC mit Domänen-Adminrechten betreut, muss vertrauenswürdig sein. Schließlich kann der Betreuer mit Domänen-Adminrechten der Domäne schaden bis hin zu zerstören! Die Virtualisierung ist eine Möglichkeit, die einem bei der Rollentrennung behilflich sein kann.
  
  
• Es sollten ausschließlich vertrauenswürdige Applikationen und Dienste die vorher ausgiebig getestet wurden auf einem DC installiert werden. Dabei sollte die Datensicherung mit höchster Priorität sichergestellt sein. Sowohl die tatsächliche Durchführung einer funktionierenden System State Sicherung auf der einen Seite, als auch die Sicherung der Daten auf der anderen Seite sollte stets überprüft werden.

Deshalb lautet die Empfehlung: Wann immer möglich sollte ein dedizierter DC eingesetzt werden! Ist das aus welchen Gründen auch immer nicht möglich, sollten vorher ausreichende Tests und eine regelmäßig Datensicherung durchgeführt werden. Dabei sollte die regelmäßige Überprüfung des Gesundheitszustands des DCs nicht vernachlässigt werden (Eventlog, DCDIAG etc.).

Warum Exchange nicht auf einem DC installiert werden sollte

Das Installieren von Exchange auf einem DC ist zwar seitens Microsoft supportet, es wird jedoch nicht empfohlen!

Die Gründe die zusätzlich zu den oben genannten Punkten gegen das Installieren von Exchange auf einem DC sprechen sind:

• Wiederherstellung: Beide Technologien, AD und Exchange erfordern im Falle eine Rücksicherung eine hohe Aufmerksamkeit. Für die Rücksicherung beider Technologien müssen bestimmte Arbeitsschritte durchgeführt werden. Erschwerend kommt dann noch hinzu, dass bei einem Servercrash die Zeit für die Rücksicherung eine umso größere Rolle spielt. Wenn der DC der Einzige in der Domäne ist, dann umso mehr. Deshalb ist es aus Wiederherstellungsgründen einfacher, lediglich eine Technologie rücksichern zu müssen.
  
  
• Abhängigkeit: Exchange benötigt zwingend ein funktionierendes AD! Wenn auf einem (wo möglich Einzigen?) DC ein Problem besteht, hat das evtl. Auswirkungen auf Exchange. Wenn sich das DC-Problem nicht lösen lässt, steht unter Umständen Exchange nicht zur Verfügung.
  
  
• Sicherheit: Stellt man den Benutzern Outlook Web Access (OWA) zur Verfügung, hat der Benutzer durch den IIS aus dem Internet per HTTP Zugriff auf den DC. Doch meistens ist das nicht gewünscht, dass ein DC von extern egal über welches Protokoll erreichbar ist.
  
  

  Der Exchange Administrator ist standardmäßig Mitglied in der Gruppe BuiltIn\Administratoren und ist dadurch Administrator auf den DCs! Das ist natürlich zwecks Rollentrennung und vor allem in größeren Umgebungen mit verteilter Administration nicht erwünscht.

  Alle Exchange Dienste werden als LocalSystem ausgeführt, was ein größeres Sicherheitsrisiko darstellt wenn eine Sicherheitslücke entsteht. Existiert z.B. ein Sicherheitsloch im AD das einem Angreifer den Zugriff auf das AD erlaubt, kann dieser auch auf Exchange (und umgekehrt) zugreifen.
  
  
• Ressourcen: Werden die zur Verfügung stehenden Ressourcen auf dem Exchange Server knapp (CPU, RAM, HDD, NIC), leidet darunter auch der DC. Denn läuft z.B. Exchange aus welchen Gründen auch immer voll, hat nicht nur Exchange ein Problem sondern auch der DC! Oder wenn sich ein Exchange-Dienst aufhängt und somit den ganzen Server auslastet, zieht das auch den DC in Mitleidenschaft so das dieser unter Umständen keine Anfragen mehr beantworten kann.
  
  
• Neustart: Es kann bis zu zehn Minuten dauern den DC herunterzufahren bzw. neu zu starten. Denn standardmäßig wird der Dienst LSASS.exe in dem das AD ausgeführt wird eher beendet, bevor die Exchange Dienste die vom AD abhängig sind beendet werden. Dadurch kommt es zu mehreren Timeouts und deshalb zu dem langsamen Verhalten. Eine mögliche Abhilfe für dieses Problem ist die Exchange-Dienste (insbesondere den Informationstore) manuell zu stoppen, bevor der DC heruntergefahren oder neu gestartet wird.
  
  

• DCPROMO: Des Weiteren ist das Ausführen von DCPROMO auf einem Exchange Server nicht supportet! Das bedeutet, wurde Exchange auf einem DC installiert, darf der DC nicht heruntergestuft werden. Zuerst müsste Exchange deinstalliert werden, ehe der DC anschließend heruntergestuft werden kann. Oder wenn Exchange auf einem Mitgliedsserver installiert wurde, darf dieser nicht mit DCPROMO zum DC heraufgestuft werden.

  Siehe (unter dem Abschnitt "Directory Server Architecture\Installing Exchange 2010 on Directory Servers"):

  Exchange 2010 System Requirements: Exchange 2010 Help
  
  

• Exchangeabhängigkeit vom GC: Selbst wenn man mehr als einen DC/GC in der Domäne besitzt, wird Exchange immer den DC/GC nutzen, auf dem es installiert ist. Das bedeutet im Umkehrschluss, dass Exchange den Betrieb einstellt, sollte mit der DC Funktion auf dem Server etwas im Argen liegen.

  Exchange resident on domain controller that is not a global catalog server

Fazit: Als Best Practice ist es empfehlenswert einen dedizierten DC zu betreiben und Exchange auf einem Mitgliedsserver anstatt auf einem DC zu installieren. Ist das aus organisatorischen Gründen (Kosten etc.) nicht möglich, ist eine funktionierende Datensicherung neben dem Monitoring das Mindeste das regelmäßig durchgeführt werden sollte! Bei der Rollentrennung und bei der Installation von Exchange ist die Virtualisierung eine hilfreiche Option.

Virtualization Support Wizard
Exchange Server Supportability Matrix

Weitere Informationen:
Wie viele DCs pro Domäne werden benötigt?
Die Besonderheiten eines Small Business Server`s (SBS)
Images als Sicherung?
Zwei wichtige IDs eines DCs: DC GUID und InvocationId
Security Considerations for a SQL Server Installation

Bis einschließlich Windows Server 2003 kann mit Bordmittel nur eine Kennwort- und Kontosperrungsrichtlinie innerhalb einer Domäne auf Domänenbenutzer wirken. Damit die Richtlinien auf Domänenbenutzer wirken, müssen diese zwingend auf Domänenebene verlinkt werden. Wenn stattdessen die beiden Richtlinien auf eine Organisationseinheit (OU) verlinkt werden, wirkt sich das lediglich auf die Computer die sich in dieser OU befinden aus und die Kennwortvorgaben gelten somit nur für die lokalen Benutzerkonten, die sich auf diesen Computern befinden!

Möchte man bis Windows Server 2003 mit Bordmittel mehrere Kennwortrichtlinien nutzen, muss man weitere Domänen erstellen, was natürlich den Ressourceneinsatz sowie den Verwaltungsaufwand wesentlich erhöht. Man kann sich aber auch zusätzliche Kennwortfilter erstellen oder weicht auf Dritt-Anbieter Lösungen aus.

Die Kennwort- und Kontosperrungsrichtlinie sollten in allen Serverversionen stets in der Default Domain Policy (DDP) konfiguriert werden, nicht zuletzt, da die DDP standardmäßig ohnehin schon auf der Domänenebene verlinkt ist. Ein weiterer viel wichtiger Punkt ist, das man in den Eigenschaften der Domänenpartition die Attribute die für beide Richtlinien relevant sind (maxPwdAge, minPwdAge, minPwdLength, pwdHistoryLength, pwdProperties, lockoutDuration, lockOutObservationWindow, lockouThreshold etc.) auf dem PDC-Emulator auch direkt konfigurieren kann. Die Konfiguration der Kennwortvorgaben muss nicht zwingend in der DDP vorgenommen werden. Durch einen automatisierten Prozess werden dann die Änderungen die man in den Attributen vorgenommen hat vom PDC-Emulator in die beiden Richtlinien, aber nur in die DDP übertragen!

Es gilt zu beachten, dass die Kennwortoptionen unter den Computerkonfigurationen in der Gruppenrichtlinie und nicht wie man annehmen könnte, unter den Benutzerkonfigurationen konfiguriert wird! Die Benutzerobjekte können mit den Kennworteinstellungen nichts anfangen. Die Kennwortoptionen werden nur von Computerobjekten verwertet und befinden sich unter:

Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kennwortrichtlinien

und

Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kontosperrungsrichtlinien

Die fein abgestimmten Kennwortrichtlinien

Seit Windows Server 2008 ist es mit Bordmittel nun endlich möglich, mehrere Kennwort- und Kontosperrungsrichtlinien für verschiedene Benutzergruppen innerhalb einer einzigen Domäne zu erstellen. Genau genommen sind es keine weiteren Richtlinien, sondern Active Directory (AD) Objekte. Die AD Objekte nennen sich Kennworteinstellungsobjekte und lauten im Fachjargon Password Setting Objects, kurz PSO.

Mit dieser Funktion die auch als granulare Kennwort- und Kontosperrungsrichtlinien oder als fein abgestimmte/abgestufte Kennwortrichtlinien (auf Englisch: Fine-Grained Password Policy, FGPP) bezeichnet wird, können getrennte Kennwort- und Kontosperreinstellungen für bestimmte Benutzer in der Domäne eingerichtet werden. Standardmäßig können die Mitglieder der Gruppe Domänen-Admins verschiedene Kennwortbeschränkungen und Kontosperreinstellungen für verschiedene Benutzertypen in der Domäne einrichten. Das Erstellen und administrieren von PSOs kann aber auch an eine entsprechende Gruppe delegiert werden.

Durch die beiden neuen Objektklassen Password Settings Container (PSC) und Password Settings die dem AD-Schema ab Windows Server 2008 hinzugefügt wurden, ist das Erstellen und Speichern von PSOs möglich. Der PSC in dem die PSOs für die Domäne gespeichert werden wird standardmäßig im Container System erstellt, dass sich in jeder Domänenpartition befindet. Der LDAP-Pfad zum PSC lautet CN=Password Settings Container,CN=System,DC=Domäne,DC=de.

Aktiviert man in der MMC Active Directory-Benutzer und -Computer unter Ansicht die „Erweiterten Features“, kommt der System Container in dem sich der PSC befindet zum Vorschein. Das systemflags Attribut in den Eigenschaften des PSCs verhindert, dass der Container weder verschoben, noch umbenannt oder gar gelöscht werden kann.

Die Voraussetzungen

• Der Domänenfunktionsmodus muss sich mindestens auf der Ebene Windows Server 2008 befinden! Der Gesamtstrukturfunktionsmodus wiederum kann sich z.B. auf der Ebene Windows Server 2003 befinden. Somit dürften sich in der Gesamtstruktur noch Domänen mit Windows Server 2003 DCs befinden, die dann aber keine PSOs einsetzen können!
  
  
• PSOs können nur auf Benutzerobjekte, globale Sicherheitsgruppen und auf inetOrgPerson-Objekte angewendet werden. Die Gruppenbereiche „Lokal (in Domäne)“ und „Universal“ sowie der Gruppentyp „Verteiler“ werden nicht berücksichtigt! Es ist empfehlenswert PSOs lediglich auf globale Gruppen zu verlinken. Dadurch müssen die Benutzer die eine andere Kennwortvorgabe erhalten sollen, nur noch zur entsprechenden Gruppe hinzugefügt werden.
  
  
• Auf eine OU können PSOs nicht direkt angewendet werden! Stattdessen kann man eine Schattengruppe (shadow group) verwenden, die der OU logisch zugeordnet ist. Eine Schattengruppe ist nichts anderes als eine globale Sicherheitsgruppe. Alle Benutzer einer OU werden dann zu dieser Schattengruppe hinzugefügt und die PSO wird dieser Schattengruppe zugewiesen. Wird ein Benutzer aus einer OU in eine andere verschoben, muss die Mitgliedschaft der Schattengruppe angepasst werden, falls der Benutzer die PSO der neuen OU zugewiesen bekommen soll.
  
  
• Auf einen Benutzer kann immer nur ein einziges PSO wirken!
  
  
• PSOs können nur im PSC erstellt werden!
  
  
• Das ein und dasselbe PSO kann auf mehrere Benutzer und/oder Gruppen angewandt werden, die sich in der gleichen Domäne befinden wie das PSO.
  
  
• Es gibt kein eigenes Bordmittel für PSOs. Ein PSO kann nicht in der MMC Active Directory-Benutzer und -Computer erstellt werden, lediglich das Anzeigen ist möglich. PSOs können mit Bordmittel mit der MMC ADSIEdit, mit dem Kommandozeilentool LDIFDE, LDP oder der AD-PowerShell erstellt und administriert werden. Zusätzlich gibt es aber im Internet kostenlose Tools, die einem das Leben mit den PSOs erleichtern.

Die Attribute eines PSO

Ein PSO in dem die Kennwortvorgaben und Kontosperreinstellungen konfiguriert werden, hat Attribute für alle Kennwortoptionen, die ebenfalls in der DDP festgelegt werden können (bis auf die Kerberos-Einstellungen).

In einem PSO existieren die Attribute für die folgenden Kennwort- und Kontosperreinstellungen:

Verknüpfte Attribute
Die konstruierten Attribute abfragen

Die PSO-Attribute mit einer Zeitangabe

Es gibt im PSO vier Attribute die als Wert eine Zeitangabe im Form von Tage:Stunden:Minuten:Sekunden verlangen.
Die vier Attribute sind:

- msDS-MaximumPasswordAge
- msDS-MinimumPasswordAge
- msDS-LockoutObservationWindow
- msDS-LockoutDuration

Erstellt man ein PSO in der AD-PowerShell oder mit ADSIEdit, muss man die Zeitangabe nach der Vorgabe tt:ss:mm:ss konfigurieren. Möchte man jedoch ein oder mehrere PSOs mit LDIFDE erstellen, so müssen die Werte in diesen Attributen im I8-Format angegeben werden! Im I8-Format wird die Zeit in Intervallen von -100 Nanosekunden (Schema: attributeSyntax = 2.5.5.16 (I8)) gespeichert. Unter Windows Server 2003 wird in der Default Domain Policy genau diese Zeiteinheit für die entsprechenden Zeit-bezogenen Attribute verwendet. Um in diesen vier Attributen die entsprechenden Werte zu konfigurieren, gilt es die Zeitangabe in Tage, Stunden oder Minuten in die Intervalle von -100 Nanosekunden zu konvertieren. Anschließend muss dem konvertierten Ergebnis noch ein negatives Vorzeichen (das Minuszeichen „-„) vorangestellt werden.

Zum umrechnen der Zeit können die folgenden Umrechnungsformel verwendet werden, um die entsprechenden I8-Werte zu erhalten:

Tage: Die Umrechnungsformel für einen Tag lautet = -24*60*60*(10^7) = -864000000000.
Demzufolge würde der Wert für fünf Tage so lauten: -4320000000000 (5*864000000000).

Stunden: Eine Stunde wird wie folgt umgerechnet: -60*60*(10^7) = -36000000000.
Der Wert für zwei Stunden lautet -72000000000 (2*36000000000).

Minuten: Die Formel für eine Minute lautet = -60*(10^7) = -600000000.
Sollen 30 Minuten ins I8-Format konvertiert werden, so lautet das Ergebnis -18000000000 (30*600000000).

Welches PSO wird angewendet und hat Vorrang, falls mehrere PSOs infrage kommen?

PSOs können sowohl Benutzerobjekten als auch globalen Sicherheitsgruppen zugewiesen werden. Der Richtlinienergebnissatz (RSOP) kann jedoch nur für das Benutzerobjekt berechnet werden. Sind mehrere PSOs mit einem Benutzer oder einer globalen Gruppe verknüpft, wird der RSOP wie folgt berechnet:

• Es wird zuerst geprüft, ob ein PSO direkt mit dem Benutzerkonto verknüpft ist. Ist das der Fall, wird dieses PSO angewendet. Sind mehrere PSOs direkt mit dem Benutzerkonto verknüpft, gewinnt das PSO, das den niedrigsten Wert im Attribut msDS-PasswordSettingsPrecedence enthält! Existieren mehrere PSOs mit demselben Wert im Attribut msDS-PasswordSettingsPrecedence, wird das PSO auf das Benutzerkonto angewendet dessen GUID niedriger ist!
  
  
• Wenn kein PSO direkt mit dem Benutzerobjekt verknüpft ist, werden die Mitgliedschaften in den globalen Sicherheitsgruppen des betreffenden Benutzers überprüft. Existiert darunter eine Gruppe das mit einem PSO verknüpft ist, wird das PSO auf Umwege auf das Benutzerkonto angewendet. Befindet sich der Benutzer in mehreren globalen Gruppen auf denen verschiedene PSOs verknüpft sind, wird das PSO auf das Benutzerkonto angewendet, das den niedrigsten Wert im Attribut msDS-PasswordSettingsPrecedence hat! Wenn mehrere PSOs mit demselben Wert im Attribut msDS-PasswordSettingsPrecedence existieren, wird das PSO auf das Benutzerkonto angewendet dessen GUID niedriger ist!
  
  
• Wenn kein PSO direkt oder indirekt per globaler Sicherheitsgruppe mit einem Benutzerobjekt verknüpft ist, werden die Kennwort- und Kontosperrungsrichtlinien aus der Default Domain Policy angewandt! Deshalb sollten immer die Kennwort- und Kontosperrungsrichtlinien in der DDP konfiguriert werden, um eine Mindestanforderung an die Benutzerkennwörter zu stellen.
  
  
• Existiert ein PSO das direkt oder indirekt mit einem Benutzerobjekt verknüpft ist, hat das PSO stets vor der DDP Vorrang! Erst wenn ermittelt wurde, dass letztendlich einem Benutzerobjekt kein PSO zugewiesen wurde, greifen die Kennwortbeschränkungen aus der DDP.
  
  
• Welches PSO letzten Endes auf ein Benutzerkonto angewendet wird, entscheidet das RSOP! Denn ein weiteres neues constructed Attribut das dem Benutzerobjekt ab Windows Server 2008 hinzugefügt wurde, lautet msDS-ResultantPSO. In diesem Attribut ist der DN des PSOs gespeichert, das letztendlich nach den o.g. Regeln auf den Benutzer angewandt wird.
  
  Mehr über constructed Attribute gibt es hier:
  Die konstruierten Attribute abfragen
  
  

• Es gibt jedoch drei Einstellungen die direkt im Benutzerobjekt vorgenommen werden können, um stets die Kennwortvorgaben eines PSOs auszuhebeln. Die drei Optionen lassen sich mit den Flags des userAccountControl Attributs konfigurieren und sind:

  - Kennwort läuft nie ab
  - Kennwort mit umkehrbarer Verschlüsselung speichern
  - Kennwort nicht erforderlich
  
  How to use the UserAccountControl flags to manipulate user account properties
  
  Im Übrigen setzen diese drei Flags die Kennwortvorgaben die in der DDP konfiguriert sind, ebenso außer Kraft!

PSOs mit der AD-PowerShell erstellen und verwalten

Unter „Windows Server 2008“ konnten PSOs mit Bordmittel lediglich mit ADSIEdit, LDIFDE sowie LDP erstellt und administriert werden. Ab „Windows Server 2008 R2“ können PSOs mit einem weiteren Bordmittel, mit dem State of the Art Werkzeug der AD-PowerShell erstellt und verwaltet werden.

Auch unter Windows Server 2003 und Windows Server 2008 kann man die AD-PowerShell nach vorheriger Installation der AD-Management Gateway Services nutzen.

Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008

Zum Überprüfen und konfigurieren der Kennwort- und Kontosperrungsrichtlinie in der DDP gibt es ebenfalls die beiden AD-PowerShell Cmdlets Get-ADDefaultDomainPasswordPolicy und Set-ADDefaultDomainPasswordPolicy. Das Cmdlet Get-ADDefaultDomainPasswordPolicy mit dem die Kennwortoptionen direkt aus den Attributen (und nicht aus der DDP) die sich in der Domänenpartition befinden abgerufen werden, zeigt die Kennwortvorgaben die mit der DDP verteilt werden an.

Das Cmdlet Set-ADDefaultDomainPasswordPolicy ändert nicht etwa die Kennworteinstellungen in der DDP, sondern direkt die Attribute die sich in der Domänenpartition befinden. Wie die einzelnen Kennwortoptionen zum Konfigurieren in der AD-PowerShell lauten, erfährt man mit dem Befehl Get-Help <Cmdlet> -Full. Also z.B. Get-Help Set-ADDefaultDomainPasswordPolicy –Full.

Das Active Directory (AD), das auf dem Extensible Storage Engine (ESE) Datenbankmodul basiert organisiert Objekte in einer hierarchischen Baumstruktur und stellt die Hierarchie der Objekte für eine Gesamtstruktur. Das AD speichert die transaktionale Datenbank intern in drei Tabellen: Datentabelle (Data-Table), Verknüpfungstabelle (Link-Table) und in der erweiterten Sicherheitseinstellungen Tabelle (Security Descriptor-Table, kurz SD-Table). Die beiden wichtigsten Tabellen in der sich die Daten des AD befinden ist die Datentabelle, die alle Objekte sowie Attribute enthält und die Verknüpfungstabelle, in der die Beziehungen zwischen den Objekten gespeichert werden.

Siehe auch: Verknüpfte Attribute

In der Datentabelle wird jedes Attribut und jedes Objekt in einer einzelnen Zeile, mit einer Spalte pro Attribut gespeichert. Das bedeutet, jede Zeile in der Datentabelle entspricht einem Attribut bzw. Objekt. Die Einträge die sich auf einem Domänencontroller (DC) in der Datentabelle befinden, sind aus der Schema-, Konfigurations-, Anwendungs- und Domänenpartition. Die Datentabelle eines globalen Katalogs (GC) enthält neben den Einträgen aus den bereits erwähnten Verzeichnispartitionen, zusätzlich noch die Einträge aus allen anderen Domänenpartitionen innerhalb der Gesamtstruktur. Denn bekanntermaßen werden alle Objekte aus allen Domänen innerhalb einer Gesamtstruktur, lediglich mit den Attributen die für eine Suche relevant sind in den GC repliziert.

Um jede Zeile in der Datentabelle eindeutig identifizieren zu können, verwendet das AD als eindeutige Kennung das Distinguished Name Tag (DNT). Bei dem DNT handelt es sich um einen vier Byte (32Bit) Integer Wert und dieser wird zum internen Verweis auf Attribute und Objekte verwendet. Der Distinguished Name Tag ist eine lokale Kennung der nicht zwischen den DCs repliziert wird und lautet bei jedem DC anders.

Der DNT gibt die Zeile in der AD-Datenbank an, in der das Attribut bzw. Objekt gespeichert ist. Jedes Objekt das erstellt wird erhält im DNT eine fortlaufende Nummer. Oder wenn z.B. ein Benutzer einer Gruppe hinzugefügt wird, speichert das AD den DNT des Benutzerobjekts im member Attribut der Gruppe und nicht den Distinguished Name (DN). Dadurch das sich der DNT selbst beim Umbenennen eines Objekts nicht ändert kann ein Benutzerobjekt umbenannt werden, ohne dass das AD alle Gruppen durchsuchen muss um den DN des Benutzers in jedem member Attribut der Gruppe aktualisieren zu müssen.

Im AD hat jedes Objekt genau ein übergeordnetes Objekt und ein Verweis auf das übergeordnete Objekt ist mit dem Objekt selbst gespeichert. Für die Beziehung zwischen den über- und untergeordneten Objekten speichert das AD in einer zusätzlichen Spalte innerhalb der Datentabelle den Parent Distinguished Name Tag (PDNT). In dieser Spalte wird der DNT vom übergeordneten Objekt gespeichert. Die Auflösung der Beziehung zwischen den über- und untergeordneten Objekten ist optimiert, da der DNT und PDNT indizierte Felder in der AD-Datenbank sind.

Um sich das genauer vor Augen zu führen empfiehlt es sich einen Export der AD-Datenbank mit LDP zu generieren. Diese Möglichkeit, einen Export der AD-Datenbank und das sogar im laufenden Betrieb durchzuführen, existiert seit Windows 2000 und ist dank des speziellen Attributs dumpdatabase möglich, das nur für diesen Zweck existiert. Nach dem man LDP gestartet hat, muss man sich zunächst mit einem DC verbinden. Dazu wählt man in LDP unter dem Menüpunkt Remotedesktopverbindung die Option Verbinden… und gibt den gewünschten DC an, von dem aus ein Export der lokalen AD-Datenbankkopie durchgeführt werden soll. Danach muss man ebenfalls unter dem Menüpunkt Remotedesktopverbindung die Option Gebunden… wählen, um sich mit dem AD zu binden. Anschließend gilt es unter dem Menüpunkt Durchsuchen die Option Ändern aufzurufen. Nun muss im Feld Attribut das Attribut dumpdatabase eingetragen werden. Im Feld Werte können die gewünschten Attribute angegeben werden die mit exportiert werden sollen. Das Feld darf dabei nicht leer bleiben und es muss mindestens ein Attribut angegeben werden. Standardmäßig werden unter Windows Server 2008 R2 bereits diese Werte exportiert: DNT - PDNT - CNT - NCDNT - OBJ – DelTime - RecTime - INST - RDNTyp – RDN. Hat man die entsprechenden Attribute eingegeben, muss im Bereich Vorgang die Option Hinzufügen gewählt und mit einem Klick auf Eingabe die getätigten Einträge in die Eingabeliste übernommen werden. Mit einem Klick auf Ausführen wird der Export dann durchgeführt.

Je nach Anzahl der Attribute, Objekte und Größe der AD-Datenbank kann der Export einige Zeit in Anspruch nehmen. Daher ist es empfehlenswert, den Export auf einem DC zu einem Zeitpunkt zu generieren, wenn gerade keine größere Last auf dem DC besteht!

Die exportierte Datei mit dem Dateinamen NTDS.dmp kann mit einem Texteditor geöffnet werden (z.B. Notepad) und wird im gleichen Verzeichnis erstellt, in der sich auch die AD-Datenbank NTDS.dit befindet (standardmäßig %windir%\NTDS).

Was passiert denn nun in der AD-Datenbank wenn ein Objekt, z.B. ein Benutzer gelöscht wird?

Es heißt wenn ein Objekt, z.B. ein Benutzer gelöscht wird, wandert es in den versteckten Container Deleted Objects das sich in der Domänenpartition befindet.
Näheres zum Container Deleted Objects liefert der folgende Artikel:

Der Container Deleted Objects

Doch bevor das Objekt überhaupt gelöscht wird, findet anhand bestimmter Kriterien eine Überprüfung statt, ob das Objekt auch tatsächlich gelöscht werden darf.
Welche Kriterien das hauptsächlich sind, steht im diesem Artikel:

Active Directory Wiederherstellung

Anlässlich des Erscheinens der aktuellen ADMT Version 3.2 findet ihr hier eine Übersicht die aufzeigt:

• Welche ADMT Version sich auf welchem Serverbetriebssystem installieren lässt.
• Mit welcher ADMT Version man von welcher Quell-Domäne zu welcher Ziel-Domäne migrieren kann.
• Auf welchen Systemen sich der ADMT Agent installieren lässt.

Seit der Veröffentlichung von Windows Server 2008 R2 konnte die bis dahin aktuelle ADMT Version 3.1 nicht auf einem Windows Server 2008 R2 installiert werden. Möchte man die bestehende Windows 2000, Windows Server 2003 oder Windows Server 2008 Umgebung mit ADMT in eine Windows Server 2008 R2 Domäne migrieren, muss dazu die ADMT Version 3.1 auf einem Windows Server 2008 installiert werden.

Nun hat aber Redmond die ADMT Version 3.2 veröffentlicht. Diese Version lässt sich ausschließlich auf einem Windows Server 2008 R2 installieren.

Active Directory Migration Tool version 3.2

Das aktualisierte ADMT-Handbuch findet man hier:

Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains

Mit ADMT 3.2 können Migrationen von folgenden Quell-Domänen durchgeführt werden:

- Windows Server 2003
- Windows Server 2008
- Windows Server 2008 R2

Mit Windows Server 2008 führte Microsoft eine neue Funktion ein mit der es möglich ist, eine Momentaufnahme (im englischen Snapshot genannt) des Active Directory (AD) im laufenden Betrieb auf einem DC zu erstellen und das sogar ohne den Betrieb zu beeinflussen. Ein AD-Snapshot kann dann zu Analyse- und Vergleichszwecken bereitgestellt werden. Aber auch zum Begutachten eines früheren Datenbestands eignet sich diese Technik hervorragend. Des Weiteren hat der Administrator mit dieser Funktion die Möglichkeit, ohne den DC im Modus Verzeichnisdienste wiederherstellen starten zu müssen, Daten aus dem AD-Snapshot zu exportieren und in der produktiven Umgebung zu importieren. Dabei ist lediglich ein Lese- und kein Schreibzugriff auf ein AD-Snapshot möglich! Mit dieser Technik die auf dem Volumenschattenkopiedienst (VSS) beruht, kann man in wenigen Augenblicken auf einfache Weise, punktgenaue AD-Snapshots der lokalen Kopie der AD-Datenbank (NTDS.dit) erstellen. Genau genommen wird ein Snapshot des gesamten Volumes erstellt, auf der sich die AD-Datenbank samt -Protokolle und dem SYSVOL-Verzeichnis befindet. Dabei können AD-Snapshots manuell oder automatisiert auf DCs, die mindestens unter Windows Server 2008 laufen erstellt werden. Der Domänenfunktionsmodus hat keine Relevanz.

Es gilt zu beachten, dass ein AD-Snapshot keine vollständige Kopie der AD-Datenbank enthält! Vielmehr stellt ein AD-Snapshot eine Sammlung von Datenträgerblöcken in der AD-Datenbank dar, die seit dem letzten AD-Snapshot geändert wurden. Durch zusammenfügen der Blöcke mit der lokalen Kopie der AD-Datenbank, kann der Volumenschattenkopiedienst die lokale Verzeichnisdatenbank zum Zeitpunkt der Erstellung des Snapshots darstellen.

Ein AD-Snapshot wird mit dem Kommandozeilentool NTDSUTIL erstellt. Man könnte zwar auch ein Snapshot im Betriebssystem erstellen, doch nur wenn das AD-Snapshot mit NTDSUTIL erstellt wird ist sichergestellt, dass die AD-Datenbank konsistent ist!

AD-Snapshots die mit Windows Server 2008 R2 fortgeführt werden helfen dem Administrator zu bestimmen, welche AD-Sicherung die gewünschten wiederherzustellenden Daten enthält. Auch wenn man lediglich überprüfen möchte, welche Werte ein Objekt bzw. ein Attribut vor einer Änderung hatte, eignet sich dieses Verfahren. In den AD Versionen vor Windows Server 2008 muss der Administrator mehrere Sicherungssätze rücksichern um zu bestimmen, welche Sicherung die wiederherzustellenden Daten enthält. Dazu ist es zwingend notwendig, dass der DC im Modus Verzeichnisdienst-wiederherstellen neu gestartet wird. Der Nachteil an den vorherigen AD-Versionen ist auch, dass es keine Möglichkeit gibt die AD-Daten die zu verschiedenen Zeitpunkten erstellt wurden zu vergleichen.

Aber: Ein AD-Snapshot ist nicht zur alleinigen Datensicherung geeignet! Er ist nur als Ergänzung gedacht! Denn aus einem AD-Snapshot können Daten bzw. Objekte nur sehr eingeschränkt mit Bordmittel (mit CSVDE oder LDIFDE) oder aufwändig mit Skripts exportiert und in die produktive AD-Umgebung importiert werden.

Ein AD-Snapshot erstellen

Für das Erstellen eines AD-Snapshots werden Domänen-Admin Rechte benötigt. Auf einem DC wird ein AD-Snapshot in der Kommandozeile mit NTDSUTIL wie folgt erstellt:

C:\>NTDSUTIL
NTDSUTIL: Snapshot
Snapshot: Activate Instance NTDS
Aktive Instanz wurde auf "NTDS" festgelegt.
Snapshot: Create
Snapshot wird erstellt...
Der Snapshotsatz {5b9dae90-de11-43b2-a8bb-e842b44ffb62} wurde erfolgreich generiert.
Snapshot:

Ein AD-Snapshot lässt sich auch mit einem Einzeiler erzeugen. Fügt man den folgenden Befehl z.B. in eine Batchdatei und lässt in einem geplanten Task die Batch ausführen (mit entsprechenden Rechten), kann man so das Erstellen von AD-Snapshots zusätzlich zur regelmäßigen System State-Sicherung automatisieren:

Wer für die Administration von Gruppenrichtlinien in einem Windows Netzwerk zuständig ist, der sollte und wird die Gruppenrichtlinien-Verwaltungskonsole (auf Englisch: Group Policy Management Console, kurz GPMC) kennen. Installiert man sich unter Windows XP und Windows Server 2003 die GPMC das separat heruntergeladen werden muss, stehen einem 32 Skripte im Verzeichnis %PROGRAMFILES%\GPMC\Scripts zur Verfügung. Mit diesen GPMC-Skripts kann man viele alltägliche Gruppenrichtlinien-Aufgaben leicht und automatisiert durchführen. Viele Gruppenrichtlinien-Administratoren werden diese Skripte zu schätzen wissen.

Doch mit Vista und Windows Server 2008 stehen die GPMC-Skripte erst mal nicht zur Verfügung. Die GPMC steht zwar ab Vista nach der Installation der Remote Server Administration Tools (RSAT) und unter Windows Server 2008, erst nach Aktivierung der Gruppenrichtlinienverwaltung in den Features weiterhin zur Verfügung, doch die GPMC Skripte fehlen hingegen. Stattdessen stellt Microsoft die GPMC Skripte als separaten Download für Vista und Windows Server 2008 zur Verfügung. Nach der Installation stehen die GPMC Skripte in gewohnter Weise zur Verfügung.

GPMC Sample Scripts

• Backup-GPO: Mit diesem Cmdlet sichert man das angegebene Gruppenrichtlinienobjekt (GPO) oder alle Gruppenrichtlinienobjekte in einer angegebenen Domäne in ein Sicherungsverzeichnis. Dabei muss das Sicherungsverzeichnis bereits existieren.
  
  
• Copy-GPO: Dieses Cmdlet erstellt eine neue GPO und kopiert die Einstellungen aus der Quell-GPO in die neue GPO. Mit diesem Cmdlet kann eine GPO aus einer Domäne in eine andere Domäne innerhalb der gleichen Gesamtstruktur kopiert werden.
  
  
• Get-GPInheritance: Informationen zur Gruppenrichtlinienvererbung für eine angegebene Domäne oder Organisationseinheit kann man sich mit diesem Cmdlet ausgeben lassen.
  
  
• Get-GPO: Eine bestimmte GPO oder alle GPOs innerhalb einer Domäne kann man sich mit diesem Cmdlet anzeigen lassen.
  
  
• Get-GPOReport: Hiermit wird ein Bericht im XML- oder HTML-Format generiert, in dem die Eigenschaften und Richtlinieneinstellungen für eine angegebene GPO oder für alle GPOs einer Domäne angezeigt werden. Dieses Cmdlet eignet sich ideal zu Dokumentationszwecken. Möchte man alle Richtlinieneinstellungen aller GPOs innerhalb der Domäne in eine HTML Datei exportieren, so gilt es diesen Befehl auszuführen: Get-GPOReport -All -Domain <Domäne.de> -ReportType HTML -Path C:\GPOReport\GPOReport.html. Das Zielverzeichnis muss bereits existieren, sonst erhält man eine Fehlermeldung.
  
  
• Get-GPPermissions: Die Berechtigungen für einen oder mehrere Sicherheitsprinzipale kann man mit diesem Cmdlet in der angegebenen GPO abrufen.
  
  
• Get-GPPrefRegistryValue: Dieses Cmdlet zeigt eine oder mehrere Registrierungseinstellungen die unterhalb der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO getätigt wurden an.
  
  
• Get-GPRegistryValue: Bei diesem Cmdlet werden eine oder mehrere registrierungsbasierte Richtlinieneinstellungen aus der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO abgerufen.
  
  
• Get-GPResultantSetOfPolicy: Mit diesem Cmdlet kann man die Richtlinienergebnissatz-Informationen für einen Benutzer, einen Computer oder für beide in eine Datei im HTML- oder XML-Format ausgeben lassen.
  
  
• Get-GPStarterGPO: Ein bestimmtes oder alle Starter-GPOs werden mit diesem Cmdlet angezeigt.
  
  
• Import-GPO: Dieses Cmdlet importiert die Einstellungen aus einer gesicherten GPO in die angegebene Ziel-GPO. Dabei kann sich das Ziel-GPO in einer anderen Domäne oder in einer anderen Gesamtstruktur befinden als die Sicherungs-GPO und muss vorher nicht existieren.
  
  
• New-GPLink: Eine GPO wird auf eine Organisationseinheit (OU), einen AD-Standort oder auf die Domäne mit diesem Cmdlet verlinkt.
  
  
• New-GPO: Eine neue GPO wird mit diesem Cmdlet erstellt.
  
  
• New-GPStarterGPO: Mit diesem Cmdlet wird eine neue Starter-GPO erstellt.
  
  
• Remove-GPLink: Dieses Cmdlet entfernt eine GPO-Verklinkung von einer OU, einem AD-Standort oder von der Domäne.
  
  
• Remove-GPO: Eine GPO wird mit samt allen Verlinkungen, mit diesem Cmdlet gelöscht.
  
  
• Remove-GPPrefRegistryValue: Eine oder mehrere Registrierungseinstellungen werden aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO mit diesem Cmdlet entfernt.
  
  
• Remove-GPRegistryValue: Um eine oder mehrere Registrierungsbasierte Richtlinieneinstellungen aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO zu entfernen, muss dazu dieses Cmdlet verwendet werden.
  
  
• Rename-GPO: Mit diesem Cmdlet kann man eine GPO umbenennen bzw. der GPO einen anderen Anzeigenamen zuweisen. Dabei bleibt die GUID der umbenannten GPO erhalten.
  
  
• Restore-GPO: Dieses Cmdlet stellt eine GPO-Sicherung in der Domäne wieder her, in der sie ursprünglich gespeichert wurde. Ist die ursprüngliche Domäne oder die GPO nicht mehr in der Domäne vorhanden, tritt ein Fehler auf.
  
  
• Set-GPInheritance: Die Vererbung einer GPO kann mit diesem Cmdlet deaktiviert werden. Oder die Deaktivierung der Vererbung für eine angegebene OU oder Domäne lässt sich ebenfalls mit diesem Cmdlet aufheben.
  
  
• Set-GPLink: Die Eigenschaften einer GPO-Verknüpfung lassen sich mit diesem Cmdlet festlegen.
  
  
• Set-GPPermissions: Die Berechtigungen einer GPO oder für alle GPOs innerhalb einer Domäne lassen sich mit diesem Cmdlet bearbeiten.
  
  
• Set-GPPrefRegistryValue: Dieses Cmdlet konfiguriert eine Registrierungseinstellung unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO.
  
  
• Set-GPRegistryValue: Mit diesem Cmdlet konfiguriert man eine oder mehrere registrierungsbasierte Richtlinieneinstellungen unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO.

Die Hilfe zu jedem einzelnen Cmdlet lässt sich mit Get-Help <Cmdlet> -Full anzeigen. Also z.B.: Get-Help Get-GPOReports -Full.

Auch an dieser Stelle zeigt sich: Die Zukunft spricht PowerShell!

Weitere Informationen:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
AD-PowerShell Befehle

Befinden sich alle Benutzer die alle aus einer bestimmten Gruppe entfernt werden sollen in der gleichen OU,
so kann man alle Benutzer in einem Schritt mit dem folgenden AD-PowerShell Befehl aus der Gruppe entfernen:

Weitere Informationen:
AD-PowerShell Befehle

Das Active Directory (AD) stets zu pflegen, ist eines der Aufgaben eines AD-Administrators. Mit der Zeit entstehen Leichen was die Computerkonten im AD betrifft. Clients die verschrottet wurden, sind vorher nicht aus der Domäne entfernt worden. Aber auch wenn Clients oder Mitgliedsserver aus der Domäne entfernt und zu einer Arbeitsgruppe (AG) hinzugefügt werden, wird nicht automatisch das Computerkonto im AD gelöscht. Es wird lediglich deaktiviert und bleibt im AD bestehen. Im Nachgang muss dann das Computerkonto manuell entfernt werden.

State oft the Art löscht man die Computerkonten mit der AD-PowerShell. Weitere Möglichkeiten findet man im folgenden Artikel:

Computerkonto löschen

# Alle deaktivierten Computerkonten, also alle Computer (Clients und Mitgliedsserver) die aus der Domäne entfernt und in eine AG hinzugefügt oder manuell deaktiviert wurden, werden mit diesem Befehl angezeigt:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object | FT Name -A

Sollen die deaktivierten Computerkonten aus einer bestimmten Organisationseinheit (OU) angezeigt werden, so gilt es diesen Befehl zu verwenden:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object | FT Name -A

# Alle deaktivierten Computerkonten werden auf Nachfrage, nacheinander mit diesem Befehl gelöscht:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object| Remove-ADComputer

Deaktivierte Computerkonten aus einer bestimmten OU werden auf Nachfrage mit diesem Befehl entfernt:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object| Remove-ADComputer

Sollen alle deaktivierten Computerkonten auf einmal ohne Nachfrage gelöscht werden, so muss der Parameter „-Confirm:“ mit dem Wert „$False“ mit angegeben werden. Sprich:
Search-ADAccount –AccountDisabled -ComputersOnly | Remove-ADComputer -Confirm:$False


Ohne Nachfrage werden die deaktivierten Computerkonten aus einer OU wie folgt gelöscht:
Search-ADAccount –AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False

# Alle Computer die sich seit 180 Tagen nicht am AD angemeldet haben werden mit dem folgenden Befehl angezeigt. Damit der Parameter AccountInactive verwendet werden kann, muss sich jedoch der Domänenfunktionsmodus mindestens auf der Ebene “Windows Server 2003” befinden:
Search-ADAccount -AccountInactive –Timespan 180 –ComputersOnly | Sort-Object | FT Name -A

Möchte man sich alle Computer aus einer bestimmten OU anzeigen, die sich seit 180 Tagen nicht mehr am AD angemeldet haben, so sieht der Befehl folgendermaßen aus:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A

Gelöscht werden die Computerkonten dann wie folgt:
Search-ADAccount -AccountInactive –Timespan 180 -ComputersOnly | Remove-ADComputer -Confirm:$False

Aus einer bestimmten OU werden die Computerkonten so entfernt:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False

# Alle Computer die seit dem 01.01.2010 inaktiv sind und sich nicht mehr am AD angemeldet haben, werden wie folgt angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Sort-Object | FT Name -A

Alle Computer aus einer bestimmten OU, die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, werden so angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A

Alle Computerkonten die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, lassen sich dann mit diesem Befehl löschen:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Remove-ADComputer -Confirm:$False

Die Computer einer bestimmten OU, die seit dem 01.01.2010 inaktiv sind, werden wie folgt gelöscht:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Remove-ADComputer -Confirm:$False

Weitere Informationen:
Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen
AD-PowerShell Befehle

Zwei wichtige IDs eines Domänencontrollers (DC) sind der DC GUID (Globaly Unique Identifier) und der Datenbank GUID. Beide IDs sind wichtige Bestandteile bei der AD-Replikation. Mit dem Kommandozeilenbefehl Repadmin /Showrepl <DC> kann man sich beide IDs anzeigen lassen. Gibt man den <DC> nicht an, wird der Befehl gegen den DC ausgeführt, auf dem man den Repadmin Befehl ausführt. Führt man den Befehl auf einem Windows Server 2003 DC aus, so erhält man diese Ausgabe auf dem ersten DC einer Gesamtstruktur:

Auf einem Windows Server 2008 R2 DC sieht das Ergebnis auf dem ersten DC wie folgt aus:

Jeder DC besitzt eine eindeutige DC GUID innerhalb einer Gesamtstruktur, der auch als Directory Service Agent GUID (kurz DSA-GUID) bekannt ist. Mit der DC GUID der im Attribut objectGUID gespeichert ist, wird der DC in der Gesamtstruktur identifiziert. Dabei spielt es auch keine Rolle in welcher Domäne sich der DC innerhalb einer Gesamtstruktur befindet. Der DC GUID eines DCs ist in der Gesamtstruktur einmalig und ändert sich solange der DC existiert (im Gegensatz zu der invocationId) niemals! Es sei denn, der DC wird zuerst herunter- und anschließend wieder zum DC heraufgestuft. Denn der DC GUID eines DCs wird beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Natürlich ist das manuelle bearbeiten des DC GUIDs ebenso nicht möglich, weil das Attribut objectGUID system-only ist. Das Attribut objectGUID findet man in den Eigenschaften des „NTDS Settings“ Objekts unterhalb des entsprechenden DC-Objekts in der Konfigurationspartition und ist als ein Oktett-String gespeichert. Der LDAP-Pfad zum “NTDS Settings” Objekt lautet: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.

Die objectGUID wird unter anderem auch dazu verwendet, um die Reihenfolge der DCs einer ringförmigen Replikationstopologie zu bestimmen und ist außerdem bei der Wahl des Bridgeheadservers eines AD-Standorts von Bedeutung. Damit der DC für seine Replikationspartner erreichbar ist, erstellt dieser mit der objectGUID in der Forward Lookup Zone _msdcs.Root-Domäne im DNS einen CNAME Eintrag.

Beim heraufstufen eines Servers zu einem DC wird der AD-Datenbank (NTDS.dit) ebenfalls eine GUID zugeordnet, die als Datenbank GUID bezeichnet wird. Diese GUID wird dazu verwendet, um die AD-Datenbank eines DCs bei einem Replikationsaufruf zu identifizieren. Bei der Datenbank GUID handelt es sich um das Attribut invocationId und befindet sich so wie die objectGUID ebenfalls in der Konfigurationspartition, in den Eigenschaften des NTDS Settings Objekts eines DCs im LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne. Auch die invocationId wird wie die objectGUID beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Replikationspartner nutzen die invocationId und die Update Sequence Number (USN) um die aktuellen Änderungen für die AD-Replikation zu bestimmen.

Die invocationId des ersten DCs mit dem die Gesamtstruktur erstellt wurde, hat den gleichen Wert wie die objectGUID. Bei allen weiteren DCs einer Gesamtstruktur werden unterschiedliche Werte in den beiden Attributen objectGUID und invocationId gespeichert.

Im Gegensatz zur objectGUID ändert sich die invocationId wenn:

• eine neue Anwendungsverzeichnispartition erstellt wird. Oder wenn eine bestehende Anwendungsverzeichnispartition entfernt und erneut erstellt wird.
  
  
• der DC mit einer gültigen Sicherung und einer unterstützten Rücksicherungsmethode (supportet von Microsoft!) rückgesichert wird. Eine gültige Sicherung ist eine Sicherung die mit einer Sicherungssoftware durchgeführt wurde, dass das entsprechende API des Betriebssystems verwendet und somit das AD in Kenntnis setzt, dass eine Sicherung durchgeführt wurde. Nur wenn eine gültige und somit eine supportete Sicherung mindestens vom System State durchgeführt wird, erspart man sich je nach Umgebung größeren Schaden im Fall einer Rücksicherung! Ab Windows Server 2003 SP1 kann man mit dem Kommandozeilenbefehl Repadmin /Showbackup überprüfen, ob eine Verzeichnispartition jemals supportet gesichert wurde.
  
  Eine unterstützte Rücksicherung findet in Abstimmung mit der AD-Replikation statt. Denn nur wenn das AD durch eine ordnungsgemäß durchgeführte System State Sicherung und einer supporteten Rücksicherungsmethode rückgesichert wird, erhält die invocationId auf dem rückgesicherten DC einen neuen Wert. Dadurch erkennen alle anderen DCs, dass die Metadaten für die AD-Replikation zu dem rückgesicherten DC hinfällig sind und das die AD-Replikation ab dem durchgeführten Sicherungsdatum mit dem der DC rückgesichert wurde, neu aufgebaut und durchgeführt werden muss. Einige Sicherungsprogramme (bis Windows Server 2003 NTBACKUP und ab Windows Server 2008 Wbadmin, ARCServe…) führen eine ordnungsgemäße Sicherung und Rücksicherung des System States durch und darauf kommt es an!
  
  Das entscheidende bei der Rücksicherung ist nun mal, dass die invocationId einen neuen Wert erhalten muss! Das ist genau der Nachteil bei Image-Programmen. Beim klassischen Imagen zieht man sich eine eins zu eins Kopie des DCs. Sollte es nun zum Rückspielen des Images kommen, erhält die invocationId keinen neuen Wert und somit erfahren je nach Umgebung die Replikationspartner auch nicht, dass ein DC rückgesichert wurde und das die Replikation mit dem rückgesicherten DC neu aufgebaut werden muss. Beim rücksichern eines Images schafft man sich ein USN Rollback, was je nach Fall zu einem größeren Schaden für die AD-Umgebung bedeutet! Im günstigsten Fall hätte man sich lediglich den zurück-geimageten DC zerstört. Diesen müsste man dann gewaltsam herunterstufen und anschließend die Metadaten des AD bereinigen (siehe weiterführende Informationen). Im ungünstigsten Fall hätte man mindestens doppelte RIDs verteilt, nicht mehr gültige Computerkontokennwörter und keine funktionierende AD-Replikation mit diesem DC mehr!
  
  Wenn eine unterstützte Rücksicherung stattgefunden hat, wird der nicht mehr gültige Wert aus dem Attribut invocationId in das Attribut retiredReplDSASignatures (das sich ebenfalls im NTDS Settings Objekt eines DCs befindet) gesetzt.
  
  Auch eine IFM (Install from Media) Installation eines DCs kommt einer Rücksicherung eines DCs gleich. Denn bei einer IFM-Installation wird der Wert aus dem Attribut invocationId das von der Sicherung stammt, in das Attribut retiredReplDSASignatures auf dem neuen DC geschrieben. Der Grund dafür ist, wenn ein Verbindungsobjekt für die Replikation erstellt wird, überprüft der neue DC sein Attribut retiredReplDSASignatures um festzustellen ob das Attribut einen Wert enthält, der mit den invocationIds im Up-To-Dateness Vector (UTDV) des Ziel-DCs übereinstimmt. Durch diese Vorgehensweise ist sichergestellt, dass nur eine Teilmenge der AD-Datenbank, nämlich nur die Änderungen die ab der Sicherung durchgeführt wurden repliziert wird.

Durch die ausschließlich ordnungsgemäß durchgeführte Sicherung und der Rücksicherungsmethode wird ein USN Rollback und somit Schaden verhindert! Wenn man sich nicht sicher ist ob das eingesetzte Sicherungsprogramm eine unterstützte Sicherung sowie Rücksicherung durchführt, sollte man ein klärendes Telefonat mit dem Hersteller führen. Von ungültigen Sicherungsmethoden wie das Rücksichern eines Images, VM-Images und VM-Snapshots (mindestens auf Servern die transaktionale Datenbanken bereitstellen wie ein DC, Exchange und SQL) sollte man stets Abstand halten und wird seitens Microsoft auch nicht supportet!

Auf einem DC ist es Pflicht mindestens das System State zu sichern und das kann man bereits mit Windows-Bordmittel (NTBACKUP, Wbadmin) durchführen!

Weiterführende Informationen:
Domänencontroller-Installation von einer Sicherung
Images als Sicherung?
Das Active Directory gewaltsam vom DC entfernen
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen
Der RID-Master und sein RID-Pool
Lingering Objects (veraltete Objekte)
How to detect and recover from a USN rollback in Windows Server 2003
How To Convert a String Formatted GUID to a Hexadecimal String Form For Use When Querying the Active Directory

Der Distinguished Name (DN) der einzelnen Verzeichnispartitionen die auf einem Domänencontroller (DC) gespeichert sind, werden in den folgenden Attributen gespeichert. Diese Attribute gehören zur nTDSDSA-Objektklasse und befinden sich in den Eigenschaften des „NTDS Settings“ Objekts des jeweiligen DCs. Zu finden ist das Objekt in diesem LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.

Die im Verlauf dieses Artikels verwendeten Abfragen werden unter anderem über alle AD-Standorte hinweg durchgeführt. Möchte man die Abfrage auf einen bestimmten AD-Standort eingrenzen, so muss im Filter der gewünschte AD-Standort mit angegeben werden. Also anstatt "CN=Sites,CN=Configuration,DC=Root-Domäne" muss es dann so lauten: "CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne".

In welchen Attributen ist die Information gespeichert, welche Verzeichnispartitionen sich auf einem DC befinden?

hasMasterNCs = In diesem mehrwertigen (multivalue) Attribut werden die DNs der beschreibbaren Verzeichnispartitionen die sich auf einem DC befinden gespeichert. Diese sind standardmäßig die Schema-, Konfigurations- und Domänenpartition. In diesem Attribut werden aber keine Anwendungsverzeichnispartitionen gespeichert, wie z.B. die beiden DNS-Partitionen ForestDNSZones sowie DomainDNSZones. Auf RODCs enthält dieses Attribut logischerweise keinen Wert, da auf einem RODC keine beschreibbaren Verzeichnispartitionen gespeichert sind da der RODC auf alle Verzeichnispartitionen lediglich das Leserecht besitzt!

hasPartialReplicaNC = In diesem mehrwertigen Attribut werden die DNs der Domänenpartitionen aus den anderen Domänen innerhalb einer Gesamtstruktur gespeichert, die sich auf einem DC befinden. Das Attribut enthält nur dann einen Wert, wenn zum einen mehr als eine Domäne in der Gesamtstruktur existiert und zum anderen, auf dem DC der globale Katalog (GC) aktiviert wurde! Da ein GC lediglich das Leserecht auf die Domänenpartitionen aus anderen Domänen hat, sind in diesem Attribut die DNs der Domänenpartitionen worauf ausschließlich das Leserecht besteht gespeichert. Da man auf einem RODC auch den GC aktivieren kann, werden bei der Abfrage nach diesem Attribut auch RODCs angezeigt.

msDS-HasDomainNCs = In diesem einwertigen (single-value) Attribut das erst ab Windows Server 2003 existiert, wird der DN der Domänenpartition die sich auf einem DC befindet gespeichert. RODCs verwenden ebenfalls dieses Attribut und werden demzufolge auch bei Abfragen mit angezeigt.

msDS-hasFullReplicaNCs = In diesem mehrwertigen Attribut das nur von einem RODC genutzt wird, sind die DNs der Verzeichnispartitionen: Schemapartition, Konfigurationspartition, Domänenpartition (in der sich der RODC befindet) sowie den beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones gespeichert.

msDS-hasMasterNCs = In diesem mehrwertigen Attribut werden sämtliche DNs der beschreibbaren Verzeichnispartitionen die sich auf einem DC befinden gespeichert. Standardmäßig enthält das Attribut ab Windows Server 2003 die DNs der folgenden Verzeichnispartitionen: Schemapartition, Konfigurationspartition, Domänenpartition sowie die beiden Anwendungsverzeichnispartitionen DomainDNSZones (der eigenen Domäne) und ForestDNSZones. Da ein RODC keine beschreibbaren Verzeichnispartitionen vorhält, erscheinen bei der Abfrage nach diesem Attribut demzufolge auch keine RODCs!

Dem Administrator steht seit Windows Server 2003 die gespeicherte Abfrage im Snap-In Active Directory-Benutzer und -Computer (dsa.msc) zur Verfügung. Mit dieser Funktion hat man die Möglichkeit, Suchanfragen zu speichern. Die gespeicherten Abfragen stehen dann für erneute Suchanfragen zu einem späteren Zeitpunkt zur Verfügung. Komplexe Abfragen müssen somit nicht jedesmal neu erstellt werden und können bei gleichbleibenden Bedingungen jedesmal genutzt werden. Mit einer gespeicherten Abfrage können auch benutzerdefinierte Abfragen erstellt werden, die einen LDAP-Suchfilter enthalten.

Alle erstellten Abfragen werden im Ordner Gespeicherte Abfragen gespeichert. Dort können sie bearbeitet und gelöscht werden. Die gespeicherten Abfragen werden jedoch nur in der MMC gespeichert, in der sie durchgeführt wurden und dort auch nur unter dem angemeldeten Benutzer. Fügt man die dsa.msc in eine neue MMC (Start-Ausführen-MMC) hinzu, kann dieses Snap-In als MSC-Datei mit samt den gespeicherten Abfragen gespeichert und auf einer anderen Maschine verwendet bzw. den IT-Kollegen zur Verfügung gestellt werden.

Die gespeicherten Abfragen kann man aber auch als XML-Datei exportieren und auf einer anderen Maschine importieren. Mit einem Rechtsklick auf die gespeicherte Abfrage kann aus dem Kontextmenü die Abfrage mit der Option Abfragedefinition exportieren… als XML-Datei exportiert werden. Auf einer anderen Maschine lässt sich anschließend mit einem Rechtsklick auf den Ordner Gespeicherte Abfrage oder auf einem selbst erstellen Ordner die Option Abfragedefinition importieren… auswählen, um danach die XML-Datei zu importieren.  

In der folgenden ZIP-Datei sind 72 gespeicherte Abfragen, sortiert nach Benutzer-, Gruppen-, Computer-, Drucker und Exchange-Abfragen als XML-Datei gespeichert.

Weitere Informationen:
Wie finde ich heraus wo sich ein Objekt befindet?
Die Active Directory-Attribute hinter den Feldnamen
Active Directory - Abfrage
AD-PowerShell Befehle

Den Security Descriptor (SD - die erweiterten Sicherheitseinstellungen) vom Container Deleted Objects, den es in der Domänen-, Konfigurations- sowie den beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones sowie ForestDNSZones gibt, kann man nicht so ohne weiteres abfragen bzw. auslesen.

Gibt man im Feld „Besitzer“ z.B. nicht explizit den „Administrator“ (also den Domänen-Admin) an, wird als Besitzer die Gruppe „Domäne\Domänen-Admins“ für den Deleted Objects Container in der Domänenpartition eingetragen.

Nach der Besitzübernahme sieht man die eingetragenen ACEs. Es gibt lediglich zwei ACEs. Die Gruppe Builtin\Administratoren die das Leserecht besitzt und NT-AUTORITÄT\System, das den Vollzugriff besitzt.

Weitere Informationen:
Der Container Deleted Objects
Der Active Directory-Papierkorb im Windows Server 2008 R2

Neben dem CSVDE das seit Windows 2000 „on Bord“ existiert, kann mit der AD-PowerShell und einer Comma-Separated Value (CSV)-Datei ebenfalls ein Massenimport- sowie -export von Objekten durchgeführt werden. CSVDE steht bis einschließlich Windows Server 2003 nur auf einem Serverbetriebssystem zur Verfügung. Erst ab Windows Vista steht das CSVDE in den Remote Server Administration Tools (kurz RSAT) auf dem Client zur Verfügung. Doch auch unter Windows 2000 und Windows XP ist es möglich die Csvde.exe von einem Server aus dem Verzeichnis „%windir%\system32“ auf eine Admin-Workstation zu kopieren, um das Kommandozeilentool unter diesen beiden Clientversionen zu verwenden. Denn CSVDE steht weder im Adminpak, noch in den Windows Support Tools zur Verfügung.

CSVDE zum Im- und Export verwenden

Mit CSVDE, das im Übrigen für Comma Separated Value Data Exchange steht, können Daten im kommaseparierten Format importiert sowie exportiert werden. CSVDE liest beim Import die Informationen aus einer Datendatei und erstellt anschließend AD-Objekte entsprechend den Anweisungen in der Datendatei. Es können jedoch keine bestehenden Objekte geändert werden. Nur das Hinzufügen von neuen Objekten ist möglich! Mit CSVDE können auch keine Benutzerkennwörter gesetzt werden.