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

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

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.

Weitere Informationen:
How to use CSVDE.EXE to back up and restore connection agreements

Wenn ein Administrator ein Objekt im AD löscht, sollte er das bewusst tun und ein versehentliches löschen sollte nie vorkommen. Jedoch passieren die meisten Missgeschicke gerade im Alltag versehentlich, obwohl die Microsoft Werkzeuge (z.B. die MMCs Active Directory-Benutzer und -Computer sowie Active Directory-Standorte und -Dienste, dsrm, AD-PowerShell etc.) eine Sicherheitsabfrage stellen, ob man das Objekt auch wirklich löschen möchte. Handelt es sich bei dem zu löschenden Objekt um eine OU in dem weitere Objekte enthalten sind (Benutzer, Gruppen, OUs etc.), wird sogar noch eine weitere Sicherheitsabfrage gestellt.

Ein Objekt vor dem versehentlichen Löschen schützen

Damit ein Objekt nicht ausversehen gelöscht werden kann, sollte man ab Windows Server 2008 von der Option Objekt vor zufälligem Löschen schützen (auf Englisch: Protect object from accidental deletion) regen Gebrauch machen. Es ist empfehlenswert diesen Schutz mindestens auf OU-Ebene anzuwenden, sie vererbt sich aber nicht auf die untergeordneten Objekte wie z.B. auf untergeordnete OUs oder auf Benutzer-, Gruppen oder Computerobjekte die sich innerhalb der OU befinden. Einzelne Objekte wie Benutzerobjekte, Sicherheits- sowie Verteilergruppen- und Computerobjekte lassen sich ebenfalls vor dem versehentlichen Löschen schützen. Auch die Objekte in der MMC Active Directory-Standorte und -Dienste (AD-Standorte, Subnetze) lassen sich vor dem versehentlichen Löschen schützen.

Die Option Objekt vor zufälligem Löschen schützen lässt sich in den Eigenschaften eines Objekts im Reiter „Objekt“ aktivieren. Dieser Reiter kommt aber in der MMC „Active Directory-Benutzer und -Computer“ erst dann zum Vorschein, wenn unter „Ansicht“ die Option „Erweiterte Features“ aktiviert wurde.

Unter Windows 2000 und Windows Server 2003 existiert zwar die Möglichkeit zum aktivieren der Option „Objekt vor zufälligem Löschen schützen“ nicht, doch man kann natürlich auch unter Windows 2000 und Windows Server 2003 ein Objekt vor dem versehentlichen löschen schützen. Denn das aktivieren der Option „Objekt vor zufälligem Löschen schützen“ bewirkt nichts anderes, als das im Security-Descriptor des Objekts das "Verweigerungsrecht" zum "Löschen" für "Jeder" gesetzt wird. Genau das kann man auch unter Windows 2000 und Windows Server 2003 z.B. auf einer OU oder einem Benutzerobjekt konfigurieren.

Daraus kann man erkennen, dass das Benutzerobjekt am 14.11.2009 um 23:05:08 Uhr auf dem DC R2DCON01 gelöscht wurde. Nun kann man hoffen, dass auf dem DC der erwähnte Zeitpunkt im Sicherheitsprotokoll noch nicht überschrieben wurde. Wenn der Eintrag noch existiert, findet man in der Beschreibung des Eventlogeintrags den Übeltäter.

Weitere Informationen:
Der Container Deleted Objects
Repadmin /showobjmeta

In einigen Attributen wie z.B. badPasswordTime, Last-Logon, Last-Logon-TimeStamp oder pwdLastSet wird ein Large Integer Wert (im Integer8 Format) gespeichert. Da man mit solch einem Wert herzlich wenig anfangen kann, muss dieser in unser Zeitformat umgerechnet werden. Das geht mit den Windows Support Tools oder mit Bordmitteln wie folgt.

Weitere Informationen:
Delegierte Berechtigungen im AD verstehen
Active Directory – Abfrage
AD-PowerShell Befehle
Token-Groups Attribute (Windows)
How to enumerate a user's security group membership using Visual Basic or Visual Basic Script

Der RID-Master ist neben der Rolle des PDC-Emulators und Infrastrukturmasters die Rolle, die in jeder Domäne einer Gesamtstruktur existiert. Diese Betriebsmasterrolle weist einen eindeutigen Pool von 500 „relative identifier“ (RIDs) an jeden Domänencontroller innerhalb einer Domäne, für das Erstellen von Objekten zu. Der RID-Master kann keine RIDs domänenübergreifend verteilen. Wozu auch? Denn jede Domäne hat schließlich seinen eigenen RID-Master.

Jeder Domänencontroller (DC) verwendet RIDs um Sicherheitsprinzipale wie z.B. Benutzer-, Gruppen- oder Computerkonten (also SIDs) etc. zu erstellen. Ein „security identifier“ (kurz SID) setzt sich aus der Domänen-SID, diese SID ist für alle Objekte innerhalb einer Domäne identisch und einer eindeutigen „relativen ID“ (kurz RID) zusammen.

Bisher konnte der Domänen- sowie Gesamtstrukturfunktionsmodus über die grafische Oberfläche, zum einen über die MMC Active Directory-Benutzer und -Computer und zum anderen über die MMC Active Directory-Domänen und -Vertrauensstellung hochgestuft werden. Der Domänenfunktionsmodus lässt sich entweder in der MMC Active Directory-Benutzer und -Computer oder Active Directory-Domänen und -Vertrauensstellung hochstufen. Der Gesamtstrukturfunktionsmodus hingegen lässt sich ausschließlich in der MMC Active Directory-Domänen und -Vertrauensstellung hochstufen.

Weitere Details werden im folgenden Artikel erläutert:

Domänen- und Gesamtstrukturfunktionsmodus

Seit Windows Server 2008 gibt es ein neues Feature, das bei der Domänenanmeldung den Zeitpunkt der letzten interaktiven Anmeldung anzeigt.

Bisher hat man seit der Einführung des Active Directory mit Windows 2000 die Möglichkeit den Zeitpunkt der letzten Domänenanmeldung eines Benutzers, durch das Attribut Last-Logon herauszufinden. Der Nachteil an diesem Attribut ist, dass es nicht zwischen den Domänencontrollern (DCs) repliziert wird. Somit muss man jeden DC in der Domäne einzeln abfragen um das aktuellste Datum zu erhalten. Mit Windows Server 2003 hat Microsoft dann das Attribut Last-Logon-Timestamp eingeführt, das sogar zwischen den DCs repliziert wird. Weitere Einzelheiten werden im folgenden Artikel erläutert:

Die letzte Benutzeranmeldung herausfinden

Für das Anzeigen der „letzten interaktiven Domänenanmeldung“ wurden dem AD-Schema ab Windows Server 2008 vier Attribute hinzugefügt, als die wären:

1. msDS-FailedInteractiveLogonCount: In diesem Attribut wird die Anzahl der fehlgeschlagenen Anmeldeversuche seit der Aktivierung dieser Funktion gespeichert.
   
   
2. msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon: Die Anzahl der fehlgeschlagenen interaktiven Anmeldeversuche bis zur letzten erfolgreichen Anmeldung werden in diesem Attribut gespeichert.
   
   
3. msDS-LastFailedInteractiveLogonTime: Der Zeitpunkt des letzten fehlgeschlagenen Anmeldeversuchs wird in diesem Attribut gespeichert.
   
   
4. msDS-LastSuccessfulInteractiveLogonTime: Wann die letzte erfolgreiche Anmeldung und somit die korrekte Kombination aus Benutzername und Kennwort eingegeben wurde, wird in diesem Attribut gespeichert.

Mit dieser neuen Funktion kann der Mitarbeiter einfach erkennen, ob evtl. sein Benutzerkonto kompromittiert wurde oder dieser ein Opfer einer Brute-Force Attacke ist.

Es sollte unbedingt vor dem Einsatz dieser Funktion ein ausgiebiger Test in einer Testumgebung durchgeführt werden!

Wenn im Active Directory (AD) Objekte gelöscht werden, verschwinden diese nicht sofort aus der AD-Datenbank (NTDS.dit). Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf den Wert TRUE (Wahr) gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer entfernt. Anschließend wandert das Objekt in den Container „Deleted Objects“ (der in fast allen Verzeichnispartitionen existiert) und wird ab diesem Zeitpunkt als Tombstone (zu deutsch: Grabstein) bezeichnet. Im Container Deleted Objects erhält das Tombstone einen speziellen Distinguished Name (DN), der so aussieht: „CN=<alter RDN>\0ADEL:<Object-GUID>“. Der DN des gelöschten Benutzerobjekts „Yusuf Dikmenoglu“ sieht z.B. so aus: CN=Yusuf Dikmenoglu\0ADEL:4b506a93-d721-4cbf-87dc-565939cf07af,CN=Deleted Objects,DC=blog,DC=dikmenoglu,DC=de

Das gelöschte Objekt wandert deshalb zuerst in den Container Deleted Objects, damit jeder Domänencontroller (DC) z.B. in einer weltweit verteilten Umgebung von der Löschung des Objekts in Kenntnis gesetzt wird, ehe das Objekt endgültig aus dem AD gelöscht wird. Gerade in größeren AD-Umgebungen mit einem komplexen Replikationszeitplan, ist diese Vorgehensweise für das Löschen von Objekten zwingend. Denn würde das Objekt nach dem löschen direkt aus der AD-Datenbank entfernt werden, würden die anderen DCs von dieser Löschung nichts mitbekommen und es entständen Lingering Objects (zu Deutsch: herumlungernde Objekte).

Lingering Objects (veraltete Objekte)

Das gelöschte Objekt verbleibt im Container Deleted Objects so lange, bis die Tombstone Lifetime (TSL) abgelaufen ist. Die TSL beträgt standardmäßig bei einer ursprünglich erstellten Windows 2000 sowie Windows Server 2003 Gesamtstruktur 60 Tage. Beim erstellen einer Gesamtstruktur ab Windows Server 2003 SP1 oder ab Windows Server 2003 R2 SP2 beträgt die TSL 180 Tage. Erst nach Ablauf der TSL Zeit, wird das Objekt nun endgültig vom Garbage Collection Prozess der standardmäßig alle 12 Stunden auf jedem DC läuft, aus dem AD entfernt.

Die Tombstone Lifetime

Dabei können Objekte aus der Konfigurations-, Domänen- und Anwendungsverzeichnispartition (wie z.B. ForestDNSZones und DomainDNSZones) gelöscht werden, aber nicht aus der Schemapartition! Schemaobjekte (Attribute und Klassen) können nicht entfernt werden, höchstens deaktiviert.

Ab Windows Server 2003 kann ein gelöschtes Objekt, sprich das Tombstone mit wenigen Attributen reanimiert werden. Wurde ein Objekt gelöscht, wird der DN vom Ursprungsort des Objekts im Attribut lastKnownParent eingetragen. Ein Objekt das autoritativ wiederhergestellt wurde, enthält ebenfalls im Attribut lastKnownParent den Ursprungsort. Oder wenn ein Objekt in den Container LostAndFound verschoben wird (bei einem Konflikt), der in den Verzeichnispartitionen Konfigurationspartition, Domänenpartition und Anwendungsverzeichnispartitionen wie die beiden DNS-Partitionen ForestDNSZones und DomainDNSZones existiert, wird im Attribut lastKnownParent ebenso der Ursprungsort des Konfliktobjekts eingetragen. Beim verschieben oder kopieren eines Objekts wird kein Wert im Attribut lastKnownParent eingetragen.

Wenn nun in der Domäne blog.dikmenoglu.de der Benutzer „Yusuf“ der sich in der OU „IT“ befindet gelöscht wird, enthält das Attribut lastKnownParent des gelöschten Benutzerobjekts im Container Deleted Objects der Domänenpartition den folgenden Wert:
OU=IT,DC=blog,DC=dikmenoglu,DC=de

Dadurch lassen sich wiederhergestellte Tombstones, autoritativ wiederhergestellte Objekte oder Konfliktobjekte die sich im Container LostAndFound befinden ausfindig machen, in dem man eine Abfrage nach dem Attribut lastKnownParent durchführt und dabei diesen LDAP-Filter verwendet:
(&(objectclass=*)(lastKnownParent=*))

Möchte man sich lediglich Benutzerkonten anzeigen lassen, so kann man z.B. bei einer benutzerdefinierten gespeicherten Abfrage diesen Filter verwenden:
(objectcategory=person)(lastKnownParent=*)

Den Container Deleted Object mit LDP anzeigen

Der versteckte Container Deleted Objects wird weder in der MMC Active Directory-Benutzer und -Computer, noch in ADSIEdit.msc angezeigt. Stattdessen kann man sich mit LDP.exe oder z.B. dem AD Explorer den Container Deleted Objects anzeigen lassen. Wobei der Container in den Anwendungsverzeichnispartitionen lediglich mit LDP angezeigt werden kann und nicht mit dem AD Explorer. Natürlich können aber auch andere LDAP-Browser verwendet werden.