Eines der Schutzmechanismen der AD-Replikation ist die strict replication consistency (strikte Replikationskonsistenz), die standardmäßig bei einer Migration von NT 4.0 auf Windows Server 2003 oder wenn ein Forest ab Windows Server 2003 erstellt wurde, aktiviert ist. Die Funktion der „strict replication consistency“ steht ab Windows 2000 Server SP3 (sogar schon mit Post-SP2 Hotfix) zur Verfügung, diese ist aber unter Windows 2000 standardmäßig deaktiviert!
Was es mit der strict replication consistency auf sich hat und wann diese vor allem zum Einsatz kommt, wird in dem folgenden Artikel detailliert erläutert:
LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte)
Kurz gesagt verhindert die „strict replication consistency“, dass Lingering Objects (herumlungernde/veraltete Objekte) von einem (veralteten) Domänencontroller (DC) der sich länger als die Tombstone-Lifetime nicht mehr mit seinen Replikationspartnern repliziert hat, zurück zu den (aktuellen!) Replikationspartnern repliziert werden.
Ein Forest der unter Windows Server 2003 oder höher installiert wurde, verfügt über einen speziellen operativen GUID, der standardmäßig aber nicht in einem Forest mit Windows 2000 Wurzeln existiert!
Wird ein Server zum DC hochgestuft, überprüft dieser ob das folgende Objekt existiert:
CN=94fdebc6-8eeb-4640-80de-ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain>
Erst wenn dieser Container zum Zeitpunkt des heraufstufen existiert, aktiviert der künftige DC die „strict replication consistency“ automatisch.
Ab Windows Server 2003 SP1 kann man die „strict replication consistency“ auf einem einzelnen DC mit dem folgenden REPADMIN-Befehl aktivieren: Repadmin /regkey <DC> +strict.
Auf allen DCs im Forest lässt sich die „strict replication consistency“ wie folgt aktivieren: Repadmin /regkey * +strict
Das bedeutet jedoch, jedes Mal wenn weitere DCs (in einen Forest mit Windows 2000 Wurzeln) hinzukommen, muss jedes Mal auf dem DC die „strict replication consistency“ mit dem Befehl „Repadmin /regkey <DC> +strict“ aktiviert werden.
Eine elegantere Variante ist, damit ab sofort auf allen künftigen DCs automatisch die „strict replication consistency“ aktiviert ist, man erstellt den operativen Container in der Konfigurationspartition manuell.
Mit ADSIEdit kann man das folgendermaßen erledigen:
- Nachdem ADSIEdit gestartet und der Eintrag ADSI Edit auf der linken Seite markiert wurde, gilt es zuerst auf Action und anschließend auf Connect to… zu klicken.
- Im darauf erscheinenden “Connection Settings” Dialogfenster kann man dann im Bereich Connection Point im Feld Select or type a Distinguished Name or Naming Context den folgenden LDAP-Pfad, sprich den Distinguished Name des folgenden Containers angeben und anschließend mit OK bestätigen: CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain>
- Als nächstes gilt es mit einem Rechtsklick auf CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain> die Option New -> Object... auszuwählen.
- Als class muss der Eintrag container ausgewählt werden.
- Im nächsten Schritt muss als Value dieser Wert eingegeben warden: 94fdebc6-8eeb-4640-80de-ec52b9ca17fa.
- Danach sollte man auf auf More Attributes klicken und unter Select a property to view die Option showInAdvancedViewOnly auswählen.
- Zusätzlich sollte im Bereich Attribute Values im Feld Edit Attribute als Wert TRUE eingetragen und mit SET bestätigt werden.
- Mit einem abschließenden Klick auf OK und Finish hat man dann das Objekt 94fdebc6-8eeb-4640-80de-ec52b9ca17fa erstellt. Ab sofort wird nun bei einem neuen DC der in einer Gesamtstruktur mit Windows 2000 Wurzeln hochgestuft (promotet) wurde, die „strict replication consistency“ automatisch aktiviert.
Wem jedoch dieser Vorgang zu heikel ist, der kann auch regelmäßig (evtl. in einem geplanten Task) den REPADMIN – Befehl ausführen, damit auf allen neuen DCs auch die „strict replication consistency“ aktiviert wird: Repadmin /regkey * +strict
Mit der folgenden GPO-ADM Datei lässt sich das ebenfalls lösen:
CLASS MACHINE
CATEGORY "Strict Replication Consistency"
KEYNAME "System\CurrentControlSet\Services\NTDS\Parameters"
POLICY "Enable Strict Replication Consistency"
EXPLAIN "This enables Strict Replication Consistency”.
VALUENAME "Strict Replication Consistency"
VALUEON NUMERIC 1
VALUEOFF DELETE
END POLICY
END CATEGORY
Wird anschließend diese GPO auf die OU “Domain Controllers” verlinkt, wird ebenfalls auf jedem neuen DC die „strict replication consistency“ automatisch aktiviert.
Weitere Informationen:
Event ID 1388 or 1988: A lingering object is detected: Active Directory
Der Unterschied zwischen einer beschreibbaren und nur lesbaren Verzeichnispartition (auf Englisch Naming Context, kurz NC) liegt im Attribut instanceType. Dieses Attribut besteht aus einer Bitmaske und existiert in den Eigenschaften jeder Verzeichnispartition. Ist das dritte Bit (Hex = 0x4; Dezimal = 4) im Attribut instanceType, in den Eigenschaften einer Verzeichnispartition auf einem DC gesetzt, so ist die Verzeichnispartition auf diesem DC beschreibbar. Falls das dritte Bit nicht gesetzt ist, ist die Verzeichnispartition auf diesem DC nur lesbar.
Da ein Read-Only Domänencontroller (RODC) nur einen lesenden Zugriff auf die Active Directory-Datenbank (NTDS.DIT) und somit auf alle Verzeichnispartitionen hat, ist logischerweise in allen Verzeichnispartitionen die sich auf einem RODC befinden das dritte Bit in instanceType nicht gesetzt!
Auch in den fremden Domänenpartitionen die sich im globalen Katalog befinden, ist das dritte Bit in instanceType nicht gesetzt!
Überprüfen kann man das mit dem Schweizer Messer Werkzeug für die AD-Replikation Repadmin. Führt man den Befehl Repadmin /showrepl /verbose in der Kommandozeile aus, erhält man solch eine Ausgabe:
In der Ausgabe werden alle Verzeichnispartitionen aufgelistet, die der DC repliziert. Die Verzeichnispartitionen in denen der DC das Schreibrecht besitzt, sind mit WRITEABLE gekennzeichnet. Die Verzeichnispartitionen in der der DC lediglich das Leserecht besitzt, sind nicht mit WRITEABLE gekennzeichnet.
Ob eine Verzeichnispartition auf einem bestimmten DC nur lesbar oder beschreibbar ist, kann man mit dem folgenden AD-PowerShellskript überprüfen:
######################################################
#
# AD-PowerShellskript zum überprüfen ob eine Verzeichnispartition
# nur lesbar oder beschreibbar ist.
#
# Von: Yusuf Dikmenoglu 05/2011
#
# http://blog.dikmenoglu.de
#
######################################################
# Hier den distinguishedName der entsprechenden Verzeichnispartition (= NC = Naming Context) angegeben
$searchbase = "DC=ad2008R2,DC=dikmenoglu,DC=de"
# Wenn man einen NC von einem globalen Katalog (GC) abfragen möchte, muss man bei "-Server" den FQDN
# des DCs und den GC-Port angeben. Also: "R2DCON01.ad2008R2.dikmenoglu.de:3268"
Get-ADObject -Server R2DCON01 -LDAPFilter "(instanceType=*)" -SearchBase $Searchbase -SearchScope base -Properties instanceType | ForEach-Object {
if ($_.instanceType -band 4){
write-host $_.ncName "Beschreibbare Verzeichnispartition: $Searchbase"
}
else{
write-host $_.ncName "Lesbare Verzeichnispartition: $Searchbase"
}
}
Weitere Informationen:
Welche Verzeichnispartitionen befinden sich auf einem DC?
Instance-Type Attribute
Read-Only Domain Controller (RODC)
Hin und wieder kommen Administratoren auf die scheinbar glorreiche Idee, Domänencontroller (DC) zwecks der Ausfallsicherheit Clustern zu wollen. Zuerst einmal ist es lobenswert, dass sich Administratoren Gedanken über die Ausfallsicherheit von DCs machen. Schließlich sind DCs das Herz einer jeden AD Domäne und diese soll auch bei einem DC-Ausfall weiter funktionieren, möglichst ohne das Backup bemühen zu müssen.
Jedoch lässt sich technisch die DC-Funktionalität gar nicht Clustern. Die DC-Funktion ist nicht clusterfähig (cluster-aware)! Das muss sie aber auch nicht, da DCs die das „Active Directory“ (AD) bereitstellen über einen anderen Mechanismus redundant gehalten werden. Dieser Mechanismus ist die „AD-Replikation“.
Die hohe Verfügbarkeit sowie Ausfallsicherheit der DC-Funktionalität wird alleine durch den Einsatz von mehr als einem DC gewährleistet! Denn existieren in einer Domäne mehr als ein DC, replizieren sich die DCs die AD-Datenbank untereinander. Da DCs stets online sind, wird die Ausfallsicherheit und hohe Verfügbarkeit bereits durch die AD-Replikation und ohne einen Cluster zu bilden erreicht.
Wie viele DCs pro Domäne werden benötigt?
Aber selbstverständlich lässt sich ein Cluster auf zwei DCs installieren, ohne die DC-Funktionalität selber zu Clustern. Das könnte der Administrator in Erwägung ziehen, um beispielsweise eine Applikation geclustert zu betreiben. Warum allerdings das Betreiben von zusätzlichen Diensten bzw. Applikationen auf einem DC alles andere als eine gute Idee ist, stellt dieser Artikel dar:
Warum es ein dedizierter DC sein sollte!
Weitere Informationen:
Windows 2000, Windows Server 2003, and Windows Server 2008 cluster nodes as domain controllers
Cluster Service May Not Start if Domain Controller Is Unavailable
When a Windows Server 2003 cluster node is a domain controller, you may receive an error message when you add domain users to the cluster file share
Die NO-GOs und Empfehlungen zu virtuellen DCs
Setzt man Password Setting Objects (kurz PSOs) auch bekannt als fein abgestimmte Kennwortrichtlinien ein, kann es zu Verwirrungen bei der Meldung die Windows liefert kommen, wenn ein Benutzer ein Kennwort vergeben möchte das nicht den Vorgaben des ihm zugewiesenen PSO entspricht.
Welche Voraussetzungen existieren müssen damit PSOs eingesetzt werden können oder wie PSOs konfiguriert werden, steht neben weiteren Details im folgenden Artikel:
Password Setting Objects erstellen und verwalten
Damit man nicht aufs Glatteis durch die von Windows erzeugte Meldung geführt wird und um PSOs erfolgreich zu implementieren, hier ein paar wichtige Hinweise:
- Versucht ein Benutzer auf den ein PSO verlinkt wurde, auf einem Windows XP Client oder Windows Server 2003 sein Kennwort zu ändern, erhält er diese Meldung:
In diesem Fall hat der Benutzer erfolglos versucht sein Kennwort zu ändern. Das neue Kennwort entsprach nicht den Vorgaben aus dem PSO. Daher ist es folgerichtig, dass eine Meldung erscheint. Allerdings stammen die Kennwort-Anforderungen in dem Dialogfenster aus der Domänenrichtlinie Default Domain Policy, die auf Domänenebene verlinkt ist! Die Meldung hat sich leider mit Einführung von PSOs nicht verändert. Es erscheint kein eigenes Dialogfenster, in dem die Kennwortvorgaben des PSO enthalten sind!
- Versucht der Benutzer auf einem Windows 7 Client oder Windows Server 2008/R2 sein Kennwort zu ändern, erhält er bei nicht Einhaltung der Kennwortvorgaben aus dem PSO diese Meldung:
Auch diese Meldung ist irreführend, denn es wird auf die Kennwortrichtlinie der Domäne, also auf die Default Domain Policy verwiesen, in der standardmäßig die Kennwortvorgaben auf Domänenebene definiert sind. Eine andere Meldung mit den Kennwortvorgaben der PSO erscheint weiterhin nicht!
- Versucht der Administrator, das Kennwort eines Benutzers auf den ein PSO verlinkt wurde zu ändern, erscheint diese Meldung:
Diese Meldung ist ebenfalls trügerisch, denn angeblich entspricht das neue Kennwort nicht den Anforderungen der Kennwortrichtlinien. Abgesehen davon das es sich bei dem PSO nicht um eine Kennwortrichtlinie sondern um ein AD-Objekt handelt, erscheint einmal mehr kein Hinweis auf das PSO!
-
Führt man auf dem Client unter Start – Ausführen das Resultant Set of Policy (RSoP) aus, werden dort die Kennwortvorgaben wieder aus der Default Domain Policy angezeigt! Daher bringt ein RSOP.msc für die Überprüfung eines PSO nichts! Denn da es sich bei den PSOs nicht um Gruppenrichtlinien (GPOs) handelt, werden diese auch nicht im RSOP angezeigt. Und abgesehen davon ist RSOP.msc zum Überprüfen von GPOs nicht mehr State oft the Art und sollte ab Windows 7 und Windows Server 2008 R2 auch nicht mehr verwendet werden. Besser ist es in der Kommandozeile diesen Befehl zu verwenden: GPResult /h GPO-Report.html.
- PSOs dürfen erst erstellt werden, wenn sich der Domänenfunktionsmodus bereits im Modus Windows Server 2008 oder höher befindet. Wenn PSOs erstellt werden bevor sich der Domänenfunktionsmodus mindestens in der Ebene Windows Server 2008 befindet, werden diese auch nach dem Hochstufen nicht angewendet!
- Ob und welches PSO auf einen Benutzer verlinkt ist, sollte mit dem Kommandozeilenbefehl dsget user <DN des Benutzers> -effectivepso kontrolliert werden. Beispielsweise: dsget user " CN=Yusuf Dikmenoglu,OU=IT,DC=ad2008R2,DC=Dikmenoglu,DC=de" -effectivepso
In Active Directory-Umgebungen mit komplexen Gruppenstrukturen kann es zu Problemen bei der Benutzeranmeldung, genauer mit dem Access Token kommen.
Der KDC (Key Distribution Center) der standardmäßig auf jedem DC läuft, sendet nach der erfolgreichen Benutzerauthentisierung (erfolgreiche Eingabe von Benutzername und Kennwort) ein PAC (Privilege Attribute Certificate) im Ticket Granting Ticket (TGT) mit. Wenn der Client ein TGT erhält, wird das PAC vom Local Security Authority (LSA) Prozess auf dem Client dazu verwendet, um das Access Token zu erstellen. Im Access Token ist die SID des Benutzerobjekts, die SIDs der SIDHistory sowie die direkten und verschachtelten Sicherheits-Gruppenmitgliedschaften des Benutzers enthalten. Im Access Token werden ausschließlich die Mitgliedschaften in Sicherheitsgruppen und nicht in Verteilergruppen berücksichtigt! Das Access Token hat aber ein Limit von maximal 1024 Einträgen und dieser Wert lässt sich nicht verändern!
In bestimmten Szenarien kann die Kerberos-Authentifizierung fehlschlagen, wenn ein Benutzer bereits Mitglied in 70 bzw. 120 Gruppen ist.
Authentication Fails Due to User PAC: Logon and Authentication; Security Services
New resolution for problems with Kerberos authentication when users belong to many groups
Um dem Problem einer fehlgeschlagenen Benutzerauthentisierung auf die Schliche zu kommen, kann man das Kommandozeilenbefehl Whoami mit dem Parameter /all oder das Cmdlet Get-ADAccountAuthorizationGroup in der AD-PowerShell dazu verwenden. Durch beide Varianten wird das Access Token ausgewertet.
Alle Gruppenmitgliedschaften eines Benutzers exportieren
Der Nachteil von Whoami /all ist jedoch, dass man den Inhalt des Access Token nur dann auswerten kann, wenn man als der entsprechende Benutzer schon angemeldet ist. Wenn man sich allerdings erst gar nicht anmelden kann, bringt einem das Whoami /all herzlichst wenig. Die Alternative ist die AD-PowerShell. Denn damit kann man von einem x-beliebigen Rechner die Gruppenmitgliedschaften eines Benutzers auswerten, sofern die AD-PowerShell installiert ist.
Es gibt aber noch eine weitere Alternative, nämlich NTDSUTIL! Auch mit NTDSUTIL ist es so wie mit der AD-PowerShell möglich, die Gruppenmitgliedschaften eines Benutzers auszuwerten.
Unter Windows Server 2003 RTM und Windows Server 2003 SP1 steht die „Evaluierung der Gruppenmitgliedschaften“ in NTDSUTIL erst nach der Installation des Hotfix 906208 zur Verfügung.
When you try to log on to a Windows Server 2003-based domain by using a domain user account, the logon request fails
Erstmalig wurde das Problem in NTDSUTIL unter Windows Server 2003 SP2 behoben!
Die Gruppenmitgliedschaften eines Benutzers lassen sich mit NTDSUTIL wie folgt Anzeigen:
-
Im ersten Schritt gilt es in einer Kommandozeile oder unter „Ausführen“ (Windows-Taste + R) das NTDSUTIL aufzurufen.
-
Danach muss man mit group membership evaluation auf die Ebene Evaluierung der Gruppenmitgliedschaft wechseln.
-
Anschließend wird mit dem Befehl run <Domäne.Tld> <Benutzer> unter Windows Server 2003 im Verzeichnis C:\Dokumente und Einstellungen\<Benutzername> und ab Windows Server 2008 unter C:\Users\<Benutzername> eine Datei Namens <Benutzername>-<Datum/Uhrzeit>.tsv erstellt, in der alle Gruppenmitgliedschaften des angegebenen Benutzers aufgelistet sind. Die Datei lässt sich mit Notepad oder dem Editor öffnen.
-
Die Datei mit den Gruppenmitgliedschaften vom angegebenen Benutzer, sieht wie folgt aus:
Weitere Informationen:
Output is incomplete when you use the Group Membership Evaluation feature of the Ntdsutil.exe tool in Windows Server 2003
Alle Mitglieder einer Gruppe in eine neue Gruppe kopieren
AD-PowerShell Befehle
Gespeicherte Abfragen
Active Directory – Abfrage
Die Virtualisierung hat längst Einzug in vielen Unternehmen genommen. Sei es Dateiserver, Druckserver oder Applikationsserver, Dank der Virtualisierung lassen sich alle Serverrollen virtualisieren. Nicht nur das dadurch in Bezug auf Green IT Rechnung getragen wird, durch die Virtualisierung lassen sich auch die Hardwarekosten deutlich senken.
Welche Dienste unter welchem Hypervisor supportet werden, kann man hier in Erfahrung bringen:
Windows Server Catalog
Grundsätzlich lassen sich auch die Infrastrukturserver wie Domänencontroller (DC), Exchange Server und SQL Server virtualisieren. Doch gerade bei diesen Serverrollen und insbesondere bei virtuellen DCs (vDCs), gibt es einiges mehr im Betrieb zu beachten als bei physikalischen Servern. Sonst kann es unter Umständen und je nach Größe der Umgebung im Extremfall, in einem Desaster enden! Bei vDCs muss man die Stolperfallen kennen, alleine schon aus dem Grund, da bei physikalischen Servern viele Möglichkeiten erst gar nicht zur Verfügung stehen. Dabei spielt es keine Rolle, welcher Hypervisor (Hyper-V, ESX…) sich im Einsatz befindet.
Die Virtualisierung von DCs hat aber auch, neben Green IT und der Hardwareersparnis, weitere Vorteile. Sichert man einen vDC auf einer anderen Hardware zurück, kann man sich die Hardware-Abstraktion zunutze machen, da man weniger Treiberprobleme hat, als wenn man einen physikalischen DC auf einer anderen Hardware rücksichert. Auch bei der Rollentrennung hilft die Virtualisierung.
Die GOs und NO-GOs bei virtuellen DCs
-
Die Zeit: Die Zeitsynchronisation innerhalb einer AD Umgebung ist von großer Bedeutung! Denn Microsoft setzt in einer AD Umgebung seit Windows 2000 das Authentifizierungsprotokoll Kerberos in der Version 5 ein und dieses toleriert standardmäßig eine Zeitdifferenz von gerade einmal fünf Minuten. Weicht die Zeit mehr als fünf Minuten ab, verliert das Kerberos Ticket Granting Ticket (kurz TGT) seine Gültigkeit.
Der für die Zeit verantwortliche DC einer Gesamtstruktur ist der DC, der die FSMO-Rolle des PDC-Emulators in der Root-Domäne innehat! Man sollte den PDC-Emulator der Root-Domäne gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen lassen. Auf der Firewall muss dazu der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden soll. Der PDC-Emulator muss aber nicht seine Zeit mit einer externen Quelle abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig. Sie muss nur innerhalb einer Gesamtstruktur synchron sein!
Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Mitgliedsserver synchronisieren sich ihre Zeit mit ihrem Anmeldeserver, also von dem DC, bei dem sich der Client bzw. Mitgliedsserver authentisiert. Dieser muss nicht zwingend der PDC-Emulator sein.
Die PDC-Emulatoren der Subdomänen holen sich wiederum ihre Zeit, vom PDC-Emulator der Root-Domäne. Der PDC-Emulator der Root-Domäne ist die maßgebliche Zeitquelle für die Gesamtstruktur.
Die Zeitsynchronisation mit einer Quelle aus dem Internet, wird auf dem PDC-Emulator der Root-Domäne mit dem folgenden Befehl eingerichtet:
w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES
Wenn an W32time nichts verstellt wurde (per GPO), hat man anschließend eine funktionierende Zeitsynchronisation! Es sollte darauf geachtet werden, dass virtuelle Maschinen und gerade vDCs ihre Zeit nicht vom Hostsystem (was zum Beispiel unter Hyper-V in den Integrationsdiensten der VM standardmäßig der Fall ist), sondern von der Domäne übernehmen. Oder wenn es gewünscht ist das die vDCs ihre Zeit vom Hostsystem übernehmen, so sollte darauf geachtet werden das auf dem Hostsystem derselbe Zeitserver konfiguriert ist, der auch auf dem PDC-Emulator konfiguriert wurde.
-
Kein AD in der Hyper-V Parent Partition: Das Ausführen von DCPROMO auf einem Hyper-V Host ist ein NO-GO, erst recht nicht wenn bereits VMs auf dem Host in Betrieb sind! Auch wenn es technisch möglich ist in der Parent Partition zusätzliche Dienste auszuführen, ist es mitnichten empfohlen dies zu tun. Da unter Hyper-V sich die Treiber für die Hardware in der Parent Partition befinden und der gesamte I/O für den Speicher- sowie Netzwerkzugriff von und zu den VMs durch die Parent Partition verläuft, sollte man den Hyper-V Host nicht unnötig noch mit weiteren Diensten an seine Leistungsgrenzen bringen. Deshalb sollte der Hyper-V Host ausschließlich zur Verwaltung der VMs dienen und keineswegs zum DC gestuft werden!
Befinden sich alle in der Domäne verfügbaren vDCs auf demselben Host, wäre da noch bei einem Neustart des Hosts das Henne-Ei Problem. Ist der Host ein vDC und würden alle in der Domäne verfügbaren vDCs auf demselben Host betrieben werden, würde der Neustart des Hosts länger dauern. Denn nach einem Neustart des Hosts muss zuerst das AD-integrierte DNS auf den vDCs zur Verfügung stehen. Da bei einem Neustart aber kein DC der die DNS-Zone zur Verfügung stellt bereitsteht, kommt es zu erheblichen Verzögerungen während eines Neustarts. Wenn es sich um einen Hyper-V Cluster handelt und alle in der Domäne verfügbaren vDCs befinden sich auf dem Cluster, so hat man bei einem Neustart größere Probleme, da der Cluster ohne einen DC nicht startet!
-
Die Ausfallsicherheit: Die Ausfallsicherheit beim AD ist bereits dann gewährleistet, wenn mindestens zwei DCs innerhalb einer Domäne existieren. Natürlich sollten in einer virtualisierten Umgebung nicht alle in der Domäne verfügbaren vDCs auf demselben Host betrieben werden, sonst hat man einen Single Point of Failure (SPoF). Die Erklärung dürfte selbsterklärend sein, denn wenn der einzig verfügbare Host beispielsweise wegen einem Hardwaredefekt ausfallen sollte, würde kein vDC mehr zur Verfügung stehen und die Domäne wäre erst mal verloren. Daher ist es ratsam vDCs mindestens auf mehrere Hosts zu verteilen, wenn nicht noch zusätzlich ein physikalischer DC existiert (was zu empfehlen ist!).
Wie immer gilt, in jeder Domäne sollten sich mindestens zwei DCs befinden! Wie viele DCs pro Domäne werden benötigt?
-
Mindestens ein physikalischer DC: Es ist empfehlenswert mindestens einen physikalischen DC in der Domäne zu betreiben. Denn wenn alle DCs einer Domäne virtuell wären, ist man gegen einen Ausfall des Hypervisors (beispielsweise durch ein Windows Update) nicht geschützt. Fällt der Hypervisor aus und existieren ausschließlich vDCs, wäre die Domäne verloren. Des Weiteren ist es empfehlenswert, dass der physikalische DC die Rolle des PDC-Emulators wegen der Zeitsynchronisation innehat. Empfehlenswert ist es auch, neben dem PDC-Emulator noch die beiden gesamtstrukturweiten FSMO-Rollen Schemamaster sowie Domänennamenmaster auf den physikalischen DC zu verschieben. Die FSMO-Rollen verschieben
-
Kein Snapshot von vDCs erstellen: Allgemein ist das Erstellen eines Snapshots eine nützliche Funktion. Ein Snapshot ist eine Momentaufnahme einer VM. Vor einer Konfigurationsänderung einer VM, kann man einen Snapshot erstellen und nach einer fehlgeschlagenen Konfigurationsänderung, zum vorherigen Zustand Dank des Snapshots zurückkehren. Diese Funktion sollte aber mit Bedacht und nur auf supporteten VMs eingesetzt werden!
Da es sich beim AD um ein verteiltes Datenbanksystem handelt, darf das Snapshotfeature zum Sichern und Wiederherstellen eines vDCs keineswegs verwendet werden (nicht zu verwechseln mit dem NTDSUTIL-Snapshot)! Erst recht nicht in einer AD Umgebung mit mehr als einem DC! Ein Snapshot ist auf einem vDC, egal welcher Hypervisor eingesetzt wird, stets zu 100% nicht supportet(!) und ist ein striktes NO-GO! Denn damit verursacht man in einer AD Umgebung mit mehr als einem DC ein USN Rollback und gefährdet somit die Datenkonsistenz. Sichert man einen Snapshot zurück, wird das Betriebssystem und die AD Datenbank in einen früheren Zustand versetzt und genau durch diese Vorgehensweise, erzeugt man ein USN Rollback. Wurde ein vDC mit einem Shapshot zu einem vorherigen Stand rückgesichert, stellen ab sofort die Replikationspartner die AD-Replikation zu und von diesem vDC ein. Des Weiteren richtet das Rücksichern eines Snapshots auf einem vDC unter Umständen (RID-Master) einen erheblichen Schaden an.
Auch wenn man vorher alle DCs einer Domäne herunterfährt und danach von einem vDC ein Snapshot erstellt, bleibt die Problematik dieselbe. Sobald man einen Snapshot auf einem vDC in einer AD Umgebung mit mehr als einem DC zurücksichert, entsteht ein USN Rollback. Dabei ist es irrelevant, ob die vDCs online oder offline sind. Wenn ein Snapshot auf einem vDC zurückgesichert wird, ist mindestens der rückgesicherte vDC zerstört. Snapshots dienen auch keineswegs als Datensicherung! Auf virtuellen DCs sollte so wie auf physikalischen DCs, regelmäßig auf mindestens zwei vDCs eine System State Sicherung durchgeführt werden.
-
Kein Klon erstellen: Das Klonen eines vDCs, im Form von Duplizieren der virtuellen Festplatte (z.B. VHD), ist weder supportet und genauso wie ein SnapShot, ein striktes NO-GO! Denn wenn ein Klon in derselben Gesamtstruktur wie das Original online geht, sind die Folgen Katastrophal! Lediglich den Computernamen und die IP-Adresse zu ändern, bringt überhaupt nichts. Denn entscheidend ist der Directory Service Agent-GUID (kurz DSA-GUID), auch bekannt als objectGUID. Dieser lässt sich nicht ändern und ist in der Gesamtstruktur eindeutig.
Ferner existieren doppelte RIDs (Relative Identifiers) und doppelte SIDs. Handelt es sich bei dem geklonten vDC auch noch um den FSMO-Rolleninhaber und speziell um den RID-Master bzw. PDC-Emulator, sind die Probleme viel schlimmer! Der Anruf beim Microsoft Produkt Support Service (MSPSS) ist jedenfalls sicher.
Der RID-Master und sein RID-Pool
Zu Sicherungszwecken ist ein Klon so wie ein Snapshot, ebenfalls ganz und gar nicht geeignet und ist auch nicht supportet! Denn die Problematik ist dieselbe wie beim Rücksichern eines Snapshots. Wird ein Klon wiederhergestellt, versetzt man den vDC zu einem früheren Zustand. Auch hierbei entsteht ein USN Rollback und in einer Umgebung mit mehr als einem DC, stellen die Replikationspartner umgehend die AD-Replikation ein.
Es sollte auch vermieden werden, einen Klon in einer angeblich abgeschotteten Testumgebung zu starten, um verschiedene Tests durchzuführen. Denn das Risiko ist zu groß, das irgendwann einmal die Testumgebung aus welchen Gründen auch immer, doch Verbindung zur Produktivumgebung erhält. Möchte man sich eine Template-VM erstellen, sollte unbedingt nach der Betriebssysteminstallation SYSPREP (und nicht NEWSID!) ausgeführt werden. Denn erst wenn Sysprep (unter Windows Server 2008 R2 im Verzeichnis %windir%\System32\sysprep) ausgeführt wurde, wird die VM anonymisiert. Erst danach darf das Template geklont werden.
-
Keine Image-basierte Sicherung durchführen: Eine Image-basierte Sicherung kann beispielsweise sein, wenn ein vDC automatisiert heruntergefahren, danach kopiert und anschließend automatisiert hochgefahren wird. Oder wenn mit einem Drittanbieter Werkzeug ein Image eines vDCs erstellt wird. Die Wiederherstellung durch solch eine Sicherungsart ist ebenfalls nicht supportet und ist zugleich ein striktes NO-GO! Denn bei einer Wiederherstellung würde man so wie bei einem Snapshot oder Klon, dass Betriebssystem und die AD Datenbank in einen früheren Zustand versetzen. Die USN Rollback Problematik und vor allem der Schaden, mindestens an dem zurück geimageten vDC, ist sicher!
Deshalb gilt hier das gleiche wie bei einem Snapshot und bei einem Klon: Finger weg von dieser nicht supporteten Sicherungsart! Images als Sicherung?
-
Die vDC-Sicherung: Wie bei physikalischen DCs, sollte auf mindestens zwei vDCs das System State regelmäßig gesichert werden.
Es gibt aber noch zwei weitere Methoden, die zum Sichern und Wiederherstellen eines vDCs unterstützt werden:
1. Das Ausführen der Windows Server-Sicherung im Gastbetriebssystem ist supportet.
2. Das Ausführen der Windows Server-Sicherung auf dem Hyper-V Host ist supportet. Denn dadurch wird der VSS Writer (Volume Shadow Copy Service, Volumeschattenkopie-Dienst) des Gastbetriebssystems aufgerufen, um sicherzustellen, dass die Sicherung ordnungsgemäß durchgeführt wird.
Durch diese beiden Methoden, genauso wie beim Wiederherstellen einer System State-Sicherung, wird die invocationId der AD-Datenbank im Gast-vDC zurückgesetzt. Das ist zwingend notwendig, damit in einer AD Umgebung mit mehreren DCs die Replikationspartner bei einer Wiederherstellung eines DCs erkennen, dass ein DC ordnungsgemäß (supportet!) wiederhergestellt wurde. Die AD-Replikation wird dann ab dem Zeitpunkt des Sicherungsdatums, mit dem wiederhergestellten vDC neu aufgebaut.
Das elementare für die erfolgreiche Wiederherstellung eines DCs ist, dass die invocationId der AD-Datenbank zurückgesetzt werden muss! Denn nur so ist sichergestellt, dass der Neuaufbau der AD-Replikation in einer AD Umgebung mit mehreren DCs erfolgreich verläuft. Das ist auch der Grund, warum ein Snapshot, Klon oder Image eines DCs nicht supportet ist, da bei diesen Methoden die invocationId nicht zurückgesetzt wird! Zwei wichtige IDs eines DCs: DC GUID und InvocationId
-
Virenscanner auf dem Host: Ist auf dem Hostsystem (Hyper-V, KVM…) ein Virenscanner installiert, sollten die Verzeichnisse in denen sich zum einen die Virtuellen Festplatten (VHD…) und zum anderen die Konfigurationsdateien befinden, vom Echtzeitscanner (On-Access) des Virenscanners ausgeschlossen werden. Unter Hyper-V sind das standardmäßig die beiden Verzeichnisse C\Users\Public\Documents\Hyper-V\Virtual Hard Disks und C:\ProgramData\Microsoft\Windows\Hyper-V. Wurden andere Verzeichnisse festgelegt, sollten diese vom Echtzeitscanner ausgeschlossen werden.
Natürlich sollten auch in den VMs bestimmte Verzeichnisse vom Echtzeitscanner ausgeschlossen werden. Welche das sind, steht hier: Antivirenprogramm
-
DCs offline konvertieren (P2V): Das online Konvertieren (Physical-to-Virtual, kurz P2V) eines DCs ist nicht supportet! Wenn man einen physikalischen DC konvertieren möchte, muss der DC ausgeschaltet (heruntergefahren, nicht angehalten oder ausgesetzt) und offline konvertiert werden! Denn ausschließlich die offline Konvertierung eines DCs (unter Hyper-V z.B. mit dem System Center Virtual Machine Manager, kurz VMM) ist der einzige Weg, welcher auch von Microsoft supportet wird. Nach der offline Konvertierung darf der physikalische DC nie mehr in der Domäne gestartet werden! Aber ein P2V ist bei einem DC ohnehin nicht empfehlenswert. Empfohlen ist es auf dem Host einen zusätzlichen DC zu installieren und den physikalischen DC herunterzustufen.
- Die VM-Sicherheit: Bei dem Thema „Sicherheit“ gelten für einen vDC mindestens die gleichen Sicherheitsregeln, wie für physikalische DCs. Weiterhin muss klar definiert sein, wer beispielsweise unter Hyper-V den Host administrieren darf. Denn wer Zugriff auf die virtuellen Festplatten (und somit auf die vDCs) hat, könnte diese kopieren und hätte prinzipiell Zugriff auf alle Kennwörter! Deshalb muss der Zugriff auf die virtuellen Festplatten von vDCs genauso eingeschränkt sein, wie der Zugriff auf physikalische DCs!
-
Einen virtuellen DC niemals anhalten und niemals den Status speichern: Ein virtueller DC sollte niemals angehalten (pausiert) und es sollte niemals der Status gespeichert werden! Denn wenn ein vDC angehalten oder der Status gespeichert wird, friert man de facto die Uhrzeit und das Datum des vDCs ein. Genau das kann aber beim Wiedereinschalten des vDCs zum Problem werden, so dass die Replikationspartner die AD-Replikation mit diesem vDC einstellen und dadurch Lingering Objects (zu Deutsch, herumlungernde Objekte) entstehen. Ein vDC sollte stets heruntergefahren werden. Lingering Objects (veraltete Objekte)
- Virtuelle Festplatten mit fixer Größe konfigurieren: Es ist empfehlenswert, eine virtuelle Festplatte mit einer festen Größe zu konfigurieren. Konfiguriert man eine dynamische virtuelle Festplatte, muss man beim sizing des Hosts ohnehin die maximale Größe, die man bei einer dynamischen virtuellen Festplatte angegeben hat kalkulieren.
- Keine differenzierende virtuelle Festplatte konfigurieren: Man sollte es tunlichst vermeiden, eine differenzierende virtuelle Festplatte für einen vDC zu implementieren! Dadurch ist es zu einfach, den vDC in einen früheren Zustand zu versetzen.
Nicht einen vDC unter Hyper-V exportieren: Das Exportieren eines vDCs unter Hyper-V sollte nicht durchgeführt werden.
Weitere Informationen:
Warum es ein dedizierter DC sein sollte!
Ein AD-Schnappschuss erstellen
Das Active Directory gewaltsam vom DC entfernen
Die Tombstone Lifetime
Running Domain Controllers in Hyper-V
Things to consider when you host Active Directory domain controllers in virtual hosting environments
DC’s and VM’s – Avoiding the Do-Over
Using Domain Controller Virtual Machines
Der Infrastrukturmaster ist dafür verantwortlich, die Integrität der Objektreferenzen zwischen domänenübergreifenden Objekten innerhalb einer Gesamtstruktur aktuell zu halten. Beispielsweise bei domänenübergreifenden Gruppenmitgliedschaften.
Fügt man in einem Single-Domain Forest ein Sicherheitsprinzipal, wie es ein Benutzer, eine Gruppe oder ein Computer darstellt, zu einer Gruppe hinzu, wird der Distinguished Name (DN) des Sicherheitsprinzipals ins member Attribut (Forward-Link) der Gruppe hinzugefügt. Das AD erstellt im Gegenzug ohne ein zusätzliches Objekt einen Back-Link (das memberOf Attribut im Sicherheitsprinzipal) und referenziert damit das Sicherheitsprinzipal, das zur Gruppe hinzugefügt wurde. Benennt man ein Sicherheitsprinzipal um, verschiebt oder löscht es, wird automatisch das member Attribut der Gruppe aktualisiert. Da der Infrastrukturmaster seine Aufgabe erst in einem Multi-Domain Forest wahrnimmt, befindet er sich in einem Single-Domain Forest in einem inaktiven Zustand, da es für ihn keine Arbeit gibt.
Möchte man aber innerhalb eines Multi-Domain Forest beispielsweise den BenutzerA aus der DomäneA zur GruppeB aus der DomäneB hinzufügen, so hat das AD ein Problem. Denn das AD kann keinen Back-Link zu einem Objekt erstellen, das sich in einer anderen Domäne und somit in einer anderen Domänenpartition befindet. Das AD löst dieses Problem durch das Erstellen eines Phantomobjekts. Mit Phantomobjekten (nicht zu verwechseln mit Tombstones, Lingering Objects oder Foreign Security Principals) ist es möglich, Objekte in anderen Domänen innerhalb der Gesamtstruktur zu referenzieren. Innerhalb der AD-Datenbank wird eine Referenz auf das Objekt als ein Zeiger auf das Phantomobjekt repräsentiert. Phantomobjekte werden also erst dann erstellt, wenn in der Gesamtstruktur mehr als eine Domäne existiert und zwischen zwei Objekten, die sich in verschiedenen Domänen befinden, eine Verknüpfung besteht!
Phantomobjekte werden aber nur vom Infrastrukturmaster erstellt. Deshalb ist es der Infrastrukturmaster aus der DomäneB, der ein Phantomobjekt für BenutzerA erstellt. Das Gruppenobjekt „GruppeB“ verweist mit dem Phantomobjekt auf das Benutzerobjekt „BenutzerA“. Dabei enthält das Phantomobjekt eine minimale Menge an Informationen, damit ein DC das ursprüngliche Objekt (BenutzerA) an seinem ursprünglichen Ort referenzieren kann. Jedes Phantomobjekt in der AD-Datenbank enthält vom referenzierten Objekt die folgenden Informationen: objectGUID, objectSID (für Verweise auf Sicherheitsprinzipale) und den DN des Objekts.
Der Infrastrukturmaster ist auch für die Verwaltung eines Phantomobjekts verantwortlich. Wenn das Sicherheitsprinzipal (BenutzerA), auf das sich ein Phantomobjekt bezieht, umbenannt, verschoben oder gelöscht wird, aktualisiert der Infrastrukturmaster das Phantomobjekt. Dazu vergleicht der Infrastrukturmaster in regelmäßigen Abständen die Phantomobjekte mit den Informationen vom globalen Katalog (GC). Stellt der Infrastrukturmaster dabei eine Abweichung fest, aktualisiert er das Phantomobjekt. Die Aktualisierung repliziert er dann zu seinen Replikationspartnern innerhalb der Domäne, die ebenfalls eine Kopie des Phantoms besitzen. Ohne diese Vorgehensweise würden die eigentlichen Änderungen an den referenzierten Objekten (z.B. BenutzerA wird umbenannt) nicht an das gegenüberliegende Objekt (GruppeB) übertragen werden.
Da der globale Katalog regelmäßig Aktualisierungen für alle Objekte in der Gesamtstruktur erhält, sind die Daten auf dem GC stets auf dem aktuellen Stand. Dadurch das ein GC bereits über ein Teilreplikat aller Objekte in der Gesamtstruktur besitzt, speichert er auch keine Phantomobjekte. Denn er kennt bereits jedes Objekt aus allen Domänen innerhalb der Gesamtstruktur und somit existieren keine Verweise auf Objekte, die ein GC nicht kennt. Daher darf der Infrastrukturmaster in einem Multi-Domain Forest nicht einem GC zugewiesen werden, denn er würde keine Unterschiede erkennen. Der Infrastrukturmaster leistet seine Arbeit innerhalb seiner Domäne ausschließlich an DCs, die kein GC sind.
Wird allerdings in einem Multi-Domain Forest auf jedem DC in der Domäne, in der auf dem Infrastrukturmaster der GC aktiviert wurde ebenfalls der GC aktiviert, werden auf keinem der DCs dieser Domäne jemals Phantomobjekte erstellt. Daher erübrigt sich das Aktualisieren der Phantomobjekte. Denn alle DCs dieser Domäne kennen bereits durch das Aktivieren des GC alle Objekte in der Gesamtstruktur und somit hat der Infrastrukturmaster nichts zu tun. In solch einem Fall wird der Infrastrukturmaster ebenfalls in einen inaktiven Zustand versetzt.
Die FSMO-Rollen verschieben
Übrigens wird das Entfernen eines Phantomobjekts nicht vom Infrastrukturmaster, sondern vom Garbage Collection Prozess durchgeführt.
Weitere Details zu Phantomobjekten liefert der folgende Artikel:
Phantome im Active Directory
Wenn der AD-Papierkorb in der Gesamtstruktur aktiviert ist
Ist allerdings der AD-Papierkorb aktiviert, der sich erst ab dem Gesamtstrukturfunktionsmodus „Windows Server 2008 R2“ aktivieren lässt, ist die Funktion des Infrastrukturmasters nicht mehr länger an einen einzelnen DC gebunden! Die Aufgabe des Infrastrukturmasters ist jetzt auf alle DCs in der Gesamtstruktur verteilt. Jeder DC in einem Multi-Domain Forest ist für die Aktualisierung seiner domänenübergreifenden Objektverweise, sprich, für das Phantomobjekt das sich in seiner lokalen AD-Datenbank befindet, verantwortlich. In dem Fall, dass das referenzierte Sicherheitsprinzipal umbenannt, verschoben oder gelöscht wird, aktualisiert jeder DC sein Phantomobjekt.
Wenn also der AD-Papierkorb aktiviert ist, hat der Infrastrukturmaster keine Aufgaben mehr und es ist irrelevant, welcher DC die FSMO-Rolle des Infrastrukturmaster innehat!
Der Active Directory-Papierkorb im Windows Server 2008 R2
Weitere Informationen:
Verknüpfte Attribute
Die verknüpften Attribute abfragen
Lingering Objects (veraltete Objekte)
Globaler Katalog (Global Catalog - GC)
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Phantoms, tombstones and the infrastructure master
7.1.5.5 Infrastructure FSMO Role
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 }
Möchte man den Befehl mit Hilfe einer Variablen ausführen, so lautet der Befehl wie folgt:
$Gruppe = Get-ADGroupMember <Quell-Gruppe> | Select sAMAccountName
$Gruppe | ForEach { Add-ADGroupMember <Ziel-Gruppe> -Members $_.sAMAccountName }
Wenn es gewünscht ist einen bestimmten Benutzer zu den gleichen Gruppen hinzufügen in denen bereits ein anderer Benutzer Mitglied ist,
so kann man das ebenfalls mit der AD-PowerShell erledigen.
Den Benutzer Kaan kann man mit dem folgenden AD-PowerShellbefehl zu den gleichen Gruppen hinzufügen, in denen Yusuf Mitglied ist:
Get-ADPrincipalGroupmembership Yusuf | % {Add-ADPrincipalGroupmembership Kaan -MemberOf $_}
Mit den ds*-Tools
Mit den ds*-Tools die sich seit Windows Server 2003 on Bord befinden, lassen sich ebenfalls die Mitglieder einer Gruppe in eine andere Gruppe kopieren.
Mit den beiden Tools dsget sowie dsmod lässt sich das wie folgt bewerkstelligen:
dsget group "DN der Quell-Gruppe" -members | dsmod group "DN der Zielgruppe" -addmbr -c
Mit einer gespeicherten Abfrage
Durch eine gespeicherte Abfrage kann man ebenfalls alle Mitglieder einer Gruppe in eine andere kopieren.
Dazu erstellt man in der MMC Active Directory-Benutzer und -Computer eine gespeicherte Abfrage mit diesem benutzerdefinierten Filter:
(objectCategory=user)(memberOf=CN=<Quell-Gruppe>,OU=<OU>,DC=Domäne,DC=de)
Ist die Abfrage erfolgt, markiert man mit STRG+A alle Benutzer, ruft mit einem Rechtsklick die Option "Einer Gruppe hinzufügen..." aus und wählt
anschließend die entsprechende Ziel-Gruppe aus.
Gespeicherte Abfragen
Gespeicherte Abfragen für dsa.msc
In der Kommandozeile mit dem Tool NET
Mit dem Kommandozeilentool NET müssen zuerst alle Benutzer der entsprechenden Gruppe in eine Textdatei exportiert werden.
Der Befehl dazu lautet folgendermaßen:
Net Group <Quell-Gruppe> /Domain > C:\Benutzer.txt
Danach kann man automatisiert mit einer FOR-Schleife die exportierten Benutzer zur Zielgruppe wie folgt importieren:
FOR /F "delims=" %i IN (C:\Benutzer.txt) DO (Net Group <Ziel-Gruppe> %i /Add /Domain)
Das funktioniert jedoch nur mit globalen und universellen Sicherheits- sowie Verteilergruppen.
Domänenlokale Sicherheits- sowie Verteilergruppen werden ignoriert.
Mit LDIFDE
Mit Ldifde lassen sich die Mitglieder einer bestimmten Gruppe wie folgt in eine andere Gruppe kopieren.
Dazu muss im ersten Schritt mit dem folgenden Befehl ein Export der Mitglieder aus der Quell-Gruppe durchgeführt werden:
Ldifde -f C:\Mitglieder.txt -r "(sAMAccountName=<Quell-Gruppe>)" -l member
Nach dem Export erhält man eine Datei mit folgendem Inhalt:
dn: CN=<Quell-Grupp>,OU=<OU>,DC=Domäne,DC=de
changetype: add
member: CN=Yusuf,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
member: CN=Kaan Dikmenoglu,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
member: CN=Aysim Dikmenoglu,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
Die Exportdatei muss dann wie folgt angepasst werden (der Bindestrich am Ende ist zwingend notwendig!):
dn: CN=<Ziel-Gruppe>,OU=<OU>,DC=Domäne,DC=de
changetype: modify
add: member
member: CN=Dikmenoglu\,Yusuf,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
member: CN=Kaan Dikmenoglu,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
member: CN=Aysim Dikmenoglu,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
-
Der Import muss dann mit diesem Befehl erfolgen:
Ldifde -i -f C:\Mitglieder.txt
LDIFDE - LDAP Data Interchange Format Data Exchange
Weitere Informationen:
Alle Benutzer einer OU aus einer bestimmten Gruppe entfernen
Alle Gruppenmitgliedschaften eines Benutzers exportieren
Active Directory - Abfrage
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äßige 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:
- Vorrang: Das Attribut msDS-PasswordSettingsPrecedence dient zum Lösen von Konflikten, wenn auf ein Benutzer- oder Gruppenobjekt mehrere PSOs verlinkt sind. Dieses Attribut entscheidet letztendlich darüber welches PSO angewendet wird, falls mehrere PSOs auf ein Benutzer- oder Gruppenobjekt verlinkt sind. Das PSO, das den niedrigsten Wert in diesem Attribut enthält wird angewendet. Existieren mehrere PSOs mit dem gleichen Wert, gewinnt das PSO dessen GUID niedriger ist! Als Werte wird jeder Wert akzeptiert, der größer als 0 ist.
- Kennwörter mit umkehrbarer Verschlüsselung speichern: Diese Option wird im Attribut msDS-PasswordReversibleEncryptionEnabled konfiguriert. Als Werte können FALSE und TRUE vergeben werden. Es versteht sich von selbst, dass man der Empfehlung folgen und hier als Wert FALSE vergeben sollte. Ansonsten würden die Kennwörter im Klartext abgespeichert werden, was ein erhebliches Sicherheitsrisiko darstellt!
- Kennwortchronik erzwingen: Für diese Option ist das Attribut msDS-PasswordHistoryLength zuständig. Hiermit wird die Anzahl der zu speichernden Kennwörter festgelegt. Wird als Wert 10 konfiguriert, werden die letzten 10 Kennwörter die der Benutzer vergeben hatte gespeichert. Wenn der Benutzer aufgefordert wird ein neues Kennwort zu vergeben, darf es kein Kennwort von den letzten 10 Kennwörtern sein. Der Wert muss zwischen 0 und 1024 liegen. Wird als Wert 0 vergeben, werden keine Kennwörter gespeichert.
-
Kennwort muss Komplexitätsvoraussetzungen entsprechen: Hinter dieser Option steckt das Attribut msDS-PasswordComplexityEnabled. Als Werte können hier FALSE (Deaktiviert) und TRUE (Aktiviert) vergeben werden, wobei TRUE empfohlen ist. Mit dieser Option wird festgelegt, dass das Kennwort komplex sein muss.
Komplex bedeutet:
1. Das Kennwort darf nicht den Kontonamen des Benutzers oder mehr als zwei Zeichen enthalten, die nacheinander im vollständigen Namen des Benutzers vorkommen.
2. Das Kennwort muss mindestens sechs Zeichen lang sein.
3. Das Kennwort muss Zeichen aus drei der folgenden Kategorien enthalten: - Großbuchstaben (A bis Z)
- Kleinbuchstaben (a bis z)
- Zahlen zur Basis 10 (0 bis 9)
- Nicht alphabetische Zeichen (zum Beispiel !, $, #, %)
- Minimale Kennwortlänge: Die minimale Kennwortlänge wird im Attribut msDS-MinimumPasswordLength konfiguriert. In diesem Attribut muss angegeben werden, aus wie vielen Zeichen das Kennwort mindestens bestehen muss. Als Wert kann 0 bis 255 vergeben werden, wobei mit 0 der Benutzer selbst die Länge seines Kennworts bestimmen kann.
- Minimales Kennwortalter: Das minimale Kennwortalter im PSO konfiguriert man im Attribut msDS-MinimumPasswordAge. Dieses Attribut gibt vor, wie alt ein Kennwort mindestens sein muss ehe es geändert werden darf. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Soll der Benutzer erst nach fünf Tagen sein Kennwort ändern dürfen, so muss als Wert 5:00:00:00 eingetragen werden. Man kann aber auch als Wert mit Klammern (Nie) oder 0 eingeben, um kein Mindestalter zu definieren. Dadurch kann der Benutzer noch am selben Tag sein Kennwort erneut ändern. Der Wert von msDS-MinimumPasswordAge muss „kleiner als“ oder „gleich“ dem Wert von msDS-MaximumPasswordAge sein.
- Maximales Kennwortalter: Das Attribut das hinter dieser Option steckt lautet msDS-MaximumPasswordAge. Mit dieser Option wird angegeben, nach wie vielen Tagen spätestens der Benutzer sein Kennwort ändern muss. Dieser Wert muss „gleich“ oder „größer“ als der Wert im Attribut msDS-MinimumPasswordAge sein. Die Zeitangabe muss in diesem Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) eingegeben werden. Vergibt man als Wert mit Klammern (Nie), läuft das Kennwort des Benutzers nicht ab. Als Wert kann nicht 0 konfiguriert werden.
Des Weiteren existieren im PSO Attribute, mit denen man die folgenden Kontosperreinstellungen konfigurieren kann:
- Kontensperrungsschwelle: Die Anzahl maximal möglicher Fehlversuche bei der Benutzeranmeldung bestimmt das Attribut msDS-LockoutThreshold. Als Wert kann man 0 bis 65535 eintragen, wobei 0 diese Option deaktiviert. Dann erfolgt niemals eine Kontosperrung. Das ist allerdings aus Sicherheitsgründen, z.B. wegen Brute Force Attacken nicht zu empfehlen!
- Zurücksetzungsdauer des Kontosperrungszählers: Wie lange die fehlgeschlagenen Anmeldeversuche zwischengespeichert werden, bevor der Kontosperrungszähler auf 0 zurückgesetzt wird, bestimmt das Attribut msDS-LockoutObservationWindow. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden. Möchte man als Wert 30 Minuten eintragen, so gilt es die Zeit wie folgt einzugeben 00:00:30:00. Der Wert von msDS-LockoutObservationWindow darf nicht „größer“ als der Wert von msDS-LockoutDuration sein, höchstens „gleich“! Denn es ist nicht möglich, den Kontosperrungszähler länger aktiv zu halten als die Zeit, die das Konto gesperrt und somit im Attribut msDS-LockoutDuration konfiguriert ist.
- Kontosperrdauer: Wie lange ein Benutzerkonto nach den Anmeldefehlversuchen (es zählt der Wert im Attribut msDS-LockoutThreshold) gesperrt werden soll, ehe es automatisch entsperrt wird, definiert man im Attribut msDS-LockoutDuration. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Wird als Wert mit Klammern (Nie) eingetragen, entsperrt sich das Benutzerkonto nicht automatisch. Stattdessen muss ein Administrator manuell das Konto entsperren. Der Wert im Attribut msDS-LockoutDuration darf nicht „kleiner“ sondern höchstens „gleich“ sein, als der Wert in msDS-LockoutObservationWindow.
Ferner existiert im PSO zusätzlich noch dieses Attribut:
-
PSO-Link: Im PSO-Link hinter dem das mehrwertige Attribut msDS-PSOAppliesTo steckt, konfiguriert man auf welche Objekte das PSO angewendet werden soll. Das bedeutet, ein PSO kann auf mehrere Benutzer und/oder Gruppen angewendet werden. In diesem Forward-Link muss der LDAP-Pfad bzw. der Distinguished Name (DN) des Objekts eingetragen werden, auf dem das PSO wirken soll.
Das Pendant zum Forward-Link ist das Back-Link, dass Attribut msDS-PSOApplied. In diesem Back-Link das den Benutzer und Gruppenobjekten ab Windows Server 2008 hinzugefügt wurde, ist das PSO bzw. wenn mehrere PSOs auf ein Benutzerobjekt direkt oder indirekt infrage kommen, sind die PSOs enthalten, mit dem das Objekt verknüpft ist. Welches PSO dann letztendlich auf ein Benutzerkonto angewandt wird, entscheidet der Richtlinienergebnissatz (Resultant Set of Policy, RSOP), genauer das Attribut msDS-ResultantPSO das sich ebenfalls in den Eigenschaften eines Benutzerobjekts befindet. Back-Links werden als constructed Attributes bezeichnet was nichts anderes bedeutet, als dass diese Art von Attribut von jedem DC selbst veraltet wird und der Wert eines solchen Attributs auch nicht vom Administrator bearbeitet werden kann. Es ist ein system-only Attribut und wird auch nicht auf andere DCs repliziert. Des Weiteren wird ein Back-Link und sein Wert erst zum Zeitpunkt der Abfrage generiert.
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.
Zum Administrieren der PSOs in der AD-PowerShell stellt Microsoft diese acht Cmdlets zur Verfügung:
- Add-ADFineGrainedPasswordPolicySubject
- Get-ADFineGrainedPasswordPolicy
- Get-ADFineGrainedPasswordPolicySubject
- Get-ADUserResultantPasswordPolicy
- New-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Set-ADFineGrainedPasswordPolicy
- Mit diesem Einzeiler lässt sich ein PSO wie folgt erstellen:
New-ADFineGrainedPasswordPolicy –Name “PSO für die GF” –Precedence 20 –ComplexityEnabled $true –Description “Dieses PSO gilt nur für die GF” –Displayname “GF-PSO” –LockoutDuration “0.00:15:00” –LockoutObservationWindow “0.00:15:00” –LockoutThreshold 15 -MaxPasswordAge "60.00:00:00" -MinPasswordAge "5.00:00:00" -MinPasswordLength 8 -PasswordHistoryCount 10 -ReversibleEncryptionEnabled $false
- Ist das PSO erstellt, muss es anschließend mit dem folgenden Befehl an einen Benutzer oder eine Gruppe wie folgt zugewiesen werden:
Add-ADFineGrainedPasswordPolicySubject <Name der PSO> <Benutzer/Gruppe>
- Einzelne Optionen lassen sich in einem bestehenden PSO folgendermaßen ändern:
Set-ADFineGrainedPasswordPolicy “CN=<Name der PSO>,CN=Password Settings Container,CN=System,DC=Domäne,DC=de” –Precedence 15 -MinPasswordLength 12
- Alle PSOs mit den konfigurierten Kennwortoptionen lassen sich mit diesem Befehl Anzeigen:
Get-ADFineGrainedPasswordPolicy -Filter { Name -Like "*" }
- Welches PSO letzten Endes auf einen Benutzer wirkt und wie die einzelnen Kennwortoptionen konfiguriert sind, erfährt man mit diesem Befehl:
Get-ADUserResultantPasswordPolicy <Benutzer>
- Mit der AD-PowerShell kann man sogar abfragen, auf welche Benutzer- und/oder Gruppenobjekte ein bestimmtes PSO verlinkt ist. Der Befehl lautet:
Get-ADFineGrainedPasswordPolicySubject <Name der PSO>
- Um die Verlinkung einer PSO von einem Benutzer oder von einer Gruppe zu entfernen, muss dieser Befehl ausgeführt werden:
Remove-ADFineGrainedPasswordPolicySubject <Name der PSO> -Subjects <Benutzer/Gruppen> -Confirm:$False
- Eine PSO kann man in der AD-PowerShell so löschen:
Remove-ADFineGrainedPasswordPolicy <Name der PSO> -Confirm:$False
Ein PSO mit ADSIEdit erstellen
Die Attribute eines PSO, müssen zwingend in dieser Reihenfolge bei der Erstellung mit ADSIEdit konfiguriert werden.
Das Erstellen eines PSOs erfolgt mit Bordmittel in ADSIEdit wie folgt:
- Zuerst verbindet man sich in ADSIEdit mit der Domänenpartition und navigiert zum Container CN=Password Settings Container,CN=System,DC=Domäne,DC=de.
- Mit einem Rechtsklick auf den PSC kann man unter Neu - Objekt… ein PSO, das zur Klasse msDS-PasswordSettings gehört erstellen.
- Mit einem Klick auf Weiter muss der Common-Name im Attribut cn angegeben werden. Der CN ist ein Name, der das PSO eindeutig identifiziert (z.B. „PSO für GF“ etc.).
- Im nächsten Schritt muss der Password Settings Precedence, der Wert für das Attribut msDS-PasswordSettingsPrecedence angegeben werden. Der Wert (der größer 0 sein muss!) der hier eingetragen wird entscheidet darüber, welches PSO auf das Objekt letztendlich angewendet wird, falls mehrere PSOs auf das Objekt verlinkt sind. Das PSO das den niedrigsten Wert in diesem Attribut enthält, wird auf das Objekt angewendet. Existieren mehrere PSOs mit dem gleichen Wert, gewinnt das PSO dessen GUID niedriger ist.
- Dann muss für die Option Password reversible encryption status for user accounts im Attribut msDS-PasswordReversibleEncryptionEnabled entweder als Wert FALSE (was empfohlen ist!) oder TRUE eingegeben werden.
- Als nächstes muss bei der Option Password History Length for user accounts ein Wert zwischen 0 und 1024 im Attribut msDS-PasswordHistoryLength vergeben werden.
- Bei der Option Password complexity status for user accounts muss im Attribut msDS-PasswordComplexityEnabled als Wert FALSE oder TRUE vergeben werden. Wobei TRUE die empfohlene Einstellung ist.
- Danach gibt man bei der Option Minimum Password Length for user accounts im Attribut msDS-MinimumPasswordLength die Mindestlänge, die ein Kennwort zwingend haben muss an! Es kann ein Wert zwischen 0 und 255 vergeben werden.
- Nun muss im Attribut msDS-MinimumPasswordAge für die Option Minimum Password Age for user accounts das minimale Kennwortalter angegeben werden, ehe es vom Benutzer geändert werden darf. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden (z.B. 7:00:00:00 für sieben Tage). Wird als Wert mit Klammern (Nie) eingetragen, wird kein Mindestalter definiert.
- Im darauffolgenden Schritt muss man in der Option Maximum Password Age for user accounts im Attribut msDS-MaximumPasswordAge diesmal das maximale Alter eines Kennworts eingeben. In diesem Attribut wird definiert, nach wie vielen Tagen spätestens der Benutzer sein Kennwort ändern muss! Auch hier muss die Zeitangabe im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Es dürfte jedem klar sein, dass dieser Wert gleich oder höher sein muss als der Wert im Attribut msDS-MinimumPasswordAge.
- Bei der nächsten Option Lockout threshold for lockout of user accounts muss im Attribut msDS-LockoutThreshold der Wert für die Kontosperrschwelle eingegeben werden. Wie oft der Benutzer sein Kennwort falsch eingeben darf ehe sein Benutzerkonto gesperrt wird, legt man in diesem Attribut fest. Als Wert kann zwischen 0 und 65535 gewählt werden. Gibt man als Wert 0 ein, wird das Benutzerkonto nie gesperrt.
- Mit der Option Observation Window for lockout of user accounts bestimmt man im Attribut msDS-LockoutObservationWindow, wie lange die Anmeldefehlversuche gespeichert werden sollen, ehe der Kontosperrungszähler zurückgesetzt wird. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden. Möchte man die Zeit auf 20 Minuten festlegen, so muss der Wert folgendermaßen konfiguriert werden 00:00:20:00.
- Zum Schluss muss man noch für die Option Lockout duration for locked out user accounts im Attribut msDS-LockoutDuration die Kontosperrdauer angeben. Das Format der Zeitangabe muss so aussehen Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss). Wenn also der Benutzer sein Kennwort mehr als der Wert, der im Attribut msDS-LockoutThreshold definiert ist falsch eingegeben hat und das Benutzerkonto für zehn Minuten gesperrt werden soll, muss man diesen Wert eintragen 00:00:10:00.
- Nun gelangt man auf die letzte Seite, auf der man zum einen Fertig stellen und zum anderen auf Weitere Attribute klicken kann. Mit einem Klick auf Weitere Attribute öffnet sich ein weiteres Dialogfenster in dem man die Benutzer und Gruppen angeben kann, mit denen dieses PSO verknüpft werden soll. Dort gilt es im Feld Anzuzeigende Eigenschaften den Eintrag Optional und im Feld Anzuzeigende Eigenschaft das Attribut msDS-PSOAppliesTo auszuwählen. Daraufhin muss im Feld Attribut bearbeiten der DN des Objekts angegeben werden, auf dem das PSO angewendet werden soll. Da es sich hierbei um ein mehrwertiges Attribut handelt, können mehrere Objekte angegeben werden, auf denen dasselbe PSO wirken soll. Wenn ein DN eingetragen wurde, muss der Wert mit Hinzufügen in das Feld Wert(e) übernommen werden. Wurden alle Werte eingetragen, gelangt man mit OK zum Dialogfeld Objekt erstellen zurück.
- Mit einem Klick auf Fertig stellen wird nun endlich das PSO im „Password Settings Container“ erstellt. Falls ein Attribut einen ungültigen Wert enthält, erscheint nach dem Klick auf Fertig stellen eine Fehlermeldung.
Nach dem bestätigen der Fehlermeldung mit OK kann man im Dialogfenster Objekt erstellen zurück zum bemängelten Attribut navigieren, um den Wert zu korrigieren. Die Verdächtigen sind dabei die Attribute, die eine Zeitangabe in Form von Tage:Stunden:Minuten:Sekunden enthalten. Z.B. darf der Wert im Attribut msDS-LockoutObservationWindow nicht größer sein (höchstens gleich) als der Wert im Attribut msDS-LockoutDuration. Auch das UAC kann schuld sein. Das ADSIEdit sollte explizit als Administrator gestartet werden.
PSOs mit LDIFDE erstellen
Es gibt auch eine skriptbasierte Alternative, mit dem PSOs erstellt werden können. Das Erstellen von PSOs kann auch mit dem Kommandozeilentool LDIFDE automatisiert durchgeführt werden.
Die Einträge in der LDF Datei müssen folgendermaßen aussehen:
dn:CN=PSO,CN=Password Settings Container,CN=System,DC=Domäne,DC=de
changetype:add
objectClass:msDS-PasswordSettings
msDS-MaximumPasswordAge:-51840000000000 (entspricht 60 Tage)
msDS-MinimumPasswordAge:-1728000000000 (entspricht 2 Tage)
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:20
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-36000000000 (entspricht 60 Minuten)
msDS-LockoutDuration:-36000000000 (entspricht 60 Minuten)
msDS-LockoutThreshold:0
msDS-PasswordSettingsPrecedence:10
msDS-PSOAppliesTo:CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de
Der Import erfolgt mit diesem Befehl:
Ldifde -i -f C:\PSO.ldf
Weitere Informationen:
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Domänen- und Gesamtstrukturfunktionsmodus
LDIFDE - LDAP Data Interchange Format Data Exchange
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
Wenn die Kriterien erfüllt und das Objekt gelöscht werden darf, werden folgende Änderungen am dem gelöschten Objekt vorgenommen:
Lingering Objects (veraltete Objekte)
In Wirklichkeit wird in der AD-Datenbank das Objekt das gelöscht wurde, also z.B. ein Benutzer nicht verschoben. Stattdessen bleibt das Objekt nach dem Löschen weiterhin in der AD-Datenbank an seinem Platz bestehen! Lediglich die Beziehung zu dem übergeordneten Objekt, also der PDNT im gelöschten Objekt ändert sich. Das gelöschte Objekt erhält in der Spalte PDNT den DNT vom Container Deleted Objects.
Im Übrigen trifft das nicht nur auf das Löschen von Objekten zu. Auch wenn ein Objekt in eine andere OU verschoben wird, bleibt das Objekt weiterhin an seinem Ursprungsort in der AD-Datenbank bestehen. Das Einzige was sich auch hier ändert, ist die Beziehung zum übergeordneten Objekt, also der Wert in der Spalte PDNT.
Schauen wir uns das im folgenden Beispiel an:
Das Benutzerobjekt Yusuf Dikmenoglu enthält in der Spalte DNT den Wert 3702. Das Objekt befindet sich also in der Zeile 3702. In der Spalte PDNT ist als Wert 3697 eingetragen. Im PDNT ist der DNT vom übergeordneten Objekt gespeichert. Schaut man sich nun in der Spalte DNT die Zeile 3697 an wird schnell klar, das sich der Benutzer Yusuf Dikmenoglu in der OU „IT“ befindet.
Löscht man jetzt das Benutzerobjekt Yusuf Dikmenoglu, bleibt das Objekt weiterhin in der Zeile 3702 bestehen. Der Wert in der Spalte PDNT, sprich die Beziehung zum übergeordneten Objekt ändert sich jedoch! Das übergeordnete Objekt des gelöschten Benutzerobjekts Yusuf Dikmenoglu ist jetzt nicht mehr die OU „IT“, sondern der Container Deleted Objects in der Domänenpartition.
Wie zu erkennen ist wurde der Wert in der Spalte PDNT im gelöschten Benutzerobjekt Yusuf Dikmenoglu, von 3697 auf 1802 geändert.
Was an dieser Stelle auch zu erkennen ist, der Relative Distinguished Name (RDN) des gelöschten Benutzerobjekts hat einen eindeutigen Namen erhalten. Das gelöschte Objekt erhält intern den Namen <alterRDN>DEL:<objectGUID>. Durch das Hinzufügen der objectGUID ist sichergestellt, dass das Objekt auch im gelöschten Status einen einmaligen Namen innerhalb der AD-Datenbank besitzt und somit eindeutig zu identifizieren ist. Das ist auch notwendig, denn wenn es ein zweites Benutzerobjekt Yusuf Dikmenoglu geben würde das ebenfalls gelöscht wird, müssen beide Objekte im Container Deleted Objects identifiziert werden können. Diese Vorgehensweise ist insbesondere für das wiederherstellen des Tombstones oder aus dem AD-Papierkorb zwingend notwendig!
Weitere Informationen:
Die unterschiedliche Größe der AD-Datenbank
Domänencontroller vergleichen
Phantome im Active Directory
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
Unter Windows 7 und Windows Server 2008 R2 steht die GPMC ohne die GPMC Skripte in den RSAT auch zur Verfügung. Es gibt jedoch keinen separaten Download der GPMC Skripte für Windows 7 und Windows Server 2008 R2. Aber die GPMC Skripte für Vista und Windows Server 2008 lassen sich auch unter Windows 7 und Windows Server 2008 R2 weiterhin nutzen. Wer allerdings für die Administration der Gruppenrichtlinien zukunftsorientiert sein möchte, der nutzt die PowerShell! Microsoft stellt 25 Cmdlets allein für Gruppenrichtlinien bereit, mit denen weitestgehend die gleichen Administrationsaufgaben durchgeführt werden können wie mit den GPMC Skripts. Die GPO Cmdlets die in der Zukunft erweitert werden, sind die Nachfolger der GPMC Skripts.
Damit die 25 GPO Cmdlets zur Verfügung stehen, müssen diese zuerst mit dem PowerShellbefehl Import-Module GroupPolicy geladen werden. Das Laden der GPO Cmdlets muss sowohl in der AD-PowerShell, als auch in der Windows PowerShell v2 durchgeführt werden. Man kann sich natürlich ein PowerShell-Profil erstellen, damit beim Starten der AD-/PowerShell die GPO Cmdlets beim Öffnen der PowerShell Konsole automatisch geladen werden. Nach dem Import kann man sich die folgenden 25 GPO Cmdlets mit Get-Command *-GP* anzeigen lassen. Startet man dagegen die Konsole Windows PowerShell Modules, wird beim Starten der Konsole unter anderem automatisch das GPO-Modul geladen.
Die 25 GPO Cmdlets sind:
- 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:
$Benutzer = Get-ADUser -Filter * -Searchbase "OU=<Benutzer>,DC=Domäne,DC=de"
Remove-ADGroupMember -identity <Gruppe> -Member $Benutzer -Confirm:0
Befinden sich in der OU in der sich die Benutzer befinden auch Benutzer, die nicht Mitglied der entsprechenden Gruppe sind, schlägt der Befehl fehl.
Wenn sich alle Benutzer die Mitglied der Gruppe "Consultants" sind in der OU "IT" befinden, so lautet der Befehl wie folgt:
$Benutzer = Get-ADUser -Filter * -Searchbase "OU=IT,DC=Domäne,DC=de"
Remove-ADGroupMember -identity Consultants -Member $Benutzer -Confirm:0
Dabei spielt es weder eine Rolle um welchen Gruppenbereich es sich dabei handelt (Global, Lokal (in Domäne), Universal),
noch ob es sich um eine Sicherheits- oder Verteilergruppe handelt.
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
Mit Windows Server 2008 führte Redmond den Read Only Domänencontroller (kurz RODC) ein. Der RODC der für Außenstellen die eine geringe bis keine physikalische Sicherheit den Servern bieten können konzipiert wurde, ist ein Domänencontroller (DC) der ausschließlich einen lesenden Zugriff auf die Active Directory-Domänendienste (AD DS) hat. Der RODC kann keine Änderungen in den AD DS und im AD-integrierten DNS vornehmen (RODNS). Clients oder Applikationen die einen Lesezugriff auf die AD DS benötigen erhalten Zugriff auf den RODC, während Clients oder Applikationen die einen Schreibvorgang in die AD DS durchführen wollen, diesen nicht auf dem RODC durchführen können sondern vom RODC an einen beschreibbaren DC verwiesen werden.
Der RODC besitzt ein vollständiges Replikat der AD-Datenbank, mit allen Attributen und Objekten die sich auch auf einem beschreibbaren DC befinden. Neben dem Unterschied das der RODC lediglich das Leserecht auf die AD-Datenbank hat, werden im Gegensatz zu einem beschreibbaren DC standardmäßig auch keine Benutzer- oder Computeranmeldeinformationen auf dem RODC gespeichert, außer das eigene Computerkonto sowie ein besonderes krbtgt-Konto für diesen RODC. Damit die Anmeldeinformationen der entsprechenden Benutzer-, Computer- und Dienstkonten auf dem RODC gespeichert werden können, muss das explizit in der Kennwortreplikationsrichtlinie (Password Replication Policy, kurz PRP) auf einem beschreibbaren DC gestattet werden, damit der RODC Authentifizierungs- und Dienstticketanforderungen eigenständig verarbeiten kann. Mit der Kennwortreplikationsrichtlinie wird bestimmt, ob die Anmeldeinformationen eines Benutzer- oder Computerkontos von einem beschreibbaren DC auf den RODC repliziert werden können.
Weitere Informationen zum RODC bekommt man in den folgenden beiden Artikeln:
Read-Only Domain Controller (RODC)
Die Installation eines RODC
Der gefilterte Attributsatz vom RODC
Diverse Applikationen könnten die AD-Domänendienste als Datenspeicher verwenden und sensible Daten darin speichern. Oder evtl. möchte man einfach nicht, dass bestimmte Daten von Benutzern (z.B. die Adressdaten oder die Personalnummer) auf einen RODC repliziert werden. Natürlich sollen diese kritischen Daten ebenfalls geschützt sein und nicht auf einem RODC gespeichert werden, falls der RODC kompromittiert, gestohlen oder die Sicherheit gefährdet wird. Und für genau diesen Anwendungstyp gibt es den gefilterten Attributsatz. Der gefilterte Attributsatz (auf Englisch: Filtered Attribute Set, kurz FAS) ist ein dynamischer Attributsatz, die nie auf einen RODC in der Gesamtstruktur repliziert werden da sie sensible oder vertrauliche Daten enthalten. Der gefilterte Attributsatz kann aber erst ab Windows Server 2008 konfiguriert werden.
Damit ein Attribut das wichtige Daten enthält nicht auf einen RODC repliziert wird, sollten die folgenden Schritte durchgeführt werden:
-
Das entsprechende Attribut sollte zu dem gefilterten Attributsatz (FAS) hinzugefügt werden. Damit wird verhindert, dass das Attribut an die RODCs in der Gesamtstruktur repliziert wird. Die Konfiguration des gefilterten Attributsatzes betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden!
-
Des Weiteren sollte das Attribut als vertraulich gekennzeichnet werden. Dies ist eine weitere Sicherheitseinstellung das konfiguriert werden sollte, wenn man nicht möchte das ein sensibles Attribut zu einem RODC repliziert werden soll! Ein Attribut wird als vertraulich gekennzeichnet, in dem die Leseberechtigung für das entsprechende Attribut für die Gruppe Authentifizierte Benutzer entfernt wird. Somit können diese Attribute von den Mitgliedern der Gruppe Authentifizierte Benutzer (das betrifft alle Benutzer- sowie Computerkonten, inklusive RODCs) nicht mehr gelesen werden. Auch die Konfiguration eines vertraulichen Attributs betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden! Doch bevor ein Attribut als vertraulich gekennzeichnet wird, sollte der Vorgang in einer Testumgebung ausgiebig getestet werden!
-
Der Gesamtstrukturfunktionsmodus sollte sich aus Sicherheitsgründen mindestens auf Windows Server 2008 befinden. Denn die Attribute die sich im gefilterten Attributsatz befinden, werden nur von DCs die mindestens unter Windows Server 2008 laufen berücksichtigt! Windows Server 2003 DCs ignorieren die Konfiguration das ein Attribut geschützt ist und replizieren die Attribute die sich in dem gefilterten Attributsatz befinden trotzdem auf einen RODC. Die Domänenpartition in der sich der RODC befindet wird zwar erst ab einem beschreibbaren Windows Server 2008 DC auf den RODC repliziert, doch wenn auf dem RODC der globale Katalog (ROGC) aktiviert wird, baut sich eine eigene Replikationstopologie für die Replikation des GCs auf. Existieren in der Gesamtstruktur noch weitere Domänen mit Windows Server 2003 GCs in denen ebenfalls ein gefilterter Attributsatz konfiguriert wurde, ist es durchaus möglich das ein Windows Server 2003 GC den gefilterten Attributsatz aus seiner Domäne zu einem RODC repliziert.
-
Das Hinzufügen eines systemkritischen Attributs zum gefilterten Attributsatz ist nicht möglich! Ein systemkritisches Attribut ist ein Attribut, das z.B. für die ordnungsgemäße Funktion der AD DS oder für das Kerberos-Authentifizierungsprotokoll benötigt wird. Erst wenn in den Eigenschaften des entsprechenden Attributs im Attribut schemaFlagsEx, das aus einer Bitmaske besteht, das Flag FLAG_ATTR_IS_CRITICAL aktiviert ist, handelt es sich um ein systemkritisches Attribut. Dieses Flag existiert aber erst seit Windows Server 2008 und Windows Server 2003 DCs würden diese Einstellung ignorieren. Daher ist es umso mehr wichtig, dass sich nicht nur der Schemamaster auf mindestens einem Windows Server 2008 DC, sondern der Gesamtstrukturfunktionsmodus sich zwingend im Modus Windows Server 2008 oder höher befindet. Denn wäre der Schemamaster ein Windows Server 2003 DC, würde sich ein systemkritisches Attribut dem gefilterten Attributsatz scheinbar erfolgreich hinzufügen lassen. Aber da ein Windows Server 2003 DC die Konfiguration eines gefilterten Attributsatzes sowieso nicht kennt, sollte in einer Gesamtstruktur in der ein gefilterter Attributsatz genutzt wird ein Windows Server 2003 DC ohnehin nicht mehr existieren!
Die technische Umsetzung wie ein Attribut zum gefilterten Attributsatz hinzugefügt wird, findet wie folgt statt
-
Um ein Attribut zum gefilterten Attributsatz hinzuzufügen und somit die Replikation des entsprechenden Attributs zu einem RODC zu verwehren, muss im zu schützenden Attribut das zehnte Bit (also Bit 9) im searchFlags Attribut gesetzt werden. Im searchFlags Attribut kann unter anderem bestimmt werden, dass ein Attribut zum gefilterten Attributsatz hinzugefügt wird und das es vertraulich ist. Im searchFlags Attribut das aus einer Bitmaske besteht, muss im zehnten Bit als Wert in Hexadezimal 0x200 und in Dezimal 512 eingetragen werden. Anschließend wird das entsprechende Attribut zu keinem RODC in der Gesamtstruktur repliziert.
-
Im Attribut searchFlags liegt auch das Geheimnis, warum ein Windows Server 2003 DC die Attribute im gefilterten Attributsatz nicht berücksichtigt. Denn das zehnte Bit, also Bit 9 in searchFlags ist erst mit Windows Server 2008 und der Einführung des RODCs hinzugekommen.
-
Soll ein Attribut zum gefilterten Attributsatz hinzugefügt werden, sollte es auch als vertraulich deklariert werden. Als vertraulich deklariert und somit die Leseberechtigung den Authentifizierten Benutzern entzogen, wird ein Attribut durch das Setzen des achten Bits (Bit 7) ebenfalls im searchFlags Attribut. Dieses Flag kam mit Windows Server 2003 SP1 hinzu. Daher sollte darauf geachtet werden, dass wenn mit diesem Flag Attribute als vertraulich definiert werden, alle DCs in der Gesamtstruktur mindestens unter Windows Server 2003 SP1 installiert sind. Alle älteren Serverversionen ignorieren die Kennzeichnung als vertraulich! Im achten Bit des searchFlags Attributs muss als Wert in Hexadezimal 0x080 und in Dezimal 128 eingetragen werden.
-
Demnach erhält also searchFlags als Wert 640 in Dezimal (in Hexadezimal 0x280), damit zum einen das gewünschte Attribut zum gefilterten Attributsatz hinzugefügt und zum anderen, als vertraulich definiert wird. Trägt man als Wert 641 ein, wird zugleich das Attribut indiziert. Sollten bereits andere Flags im searchFlags Attribut konfiguriert sein, müssen die Werte addiert werden!
Den gefilterten Attributsatz abfragen
Standardmäßig befinden sich die folgenden Attribute ab Windows Server 2008 im gefilterten Attributsatz:
ms-FVE-KeyPackage
ms-FVE-RecoveryPassword
ms-PKI-AccountCredentials
ms-PKI-DPAPIMasterKeys
ms-PKI-RoamingTimeStamp
ms-TPM-OwnerInformation
Um die Attribute die sich im gefilterten Attributsatz befinden abzufragen, muss eine Abfrage nach dem Attribut searchFlags mit dem Wert 512 (das zehnte Bit in searchFlags) durchgeführt werden.
Die Abfrage mit der AD-PowerShell könnte wie folgt lauten
Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties searchFlags | Where {$_.searchFlags -band 512} | Select Name,searchFlags | Sort Name | FT -Autosize -Wrap
Auch mit diesem AD-PowerShell Befehl lassen sich die gefilterten Attribute anzeigen:
Get-ADObject -LDAPFilter "(&(ObjectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=512))" -SearchBase “CN=Schema,CN=Configuration,DC=Root-Domäne” -SearchScope Subtree | Select Name | Sort Name | FT -Autosize -Wrap
Mit LDP lässt sich der gefilterte Attributsatz folgendermaßen anzeigen
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN die Schemapartition und als Filter (searchFlags:1.2.840.113556.1.4.803:=512) angeben.
Weitere Informationen:
How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
Anhang D: Schritte zum Hinzufügen eines Attributs zu einem Attributsatz mit RODC-Filter
Search-Flags Attribute
Bevor der erste Server, der mit einem neueren Serverbetriebssystem installiert ist als die bereits bestehenden Domänencontroller (DCs) einer Gesamtstruktur, als DC zur Gesamtstruktur hinzugefügt werden kann, muss vorher zwingend mit dem Active Directory Preparation Tool (ADPREP) das Active Directory-Schema aktualisiert werden. Erst nachdem ADPREP ausgeführt wurde, kann der neue Server als DC zur Gesamtstruktur hinzugefügt werden. Dabei muss ADPREP stets von der CD/DVD ausgeführt werden, mit dem der neue Server installiert wurde. Möchte man also einen Windows Server 2008 oder Windows Server 2008 R2 in eine Windows 2000 bzw. Windows Server 2003 Gesamtstruktur hinzufügen, so muss das ADPREP von der Windows Server 2008 bzw. Windows Server 2008 R2 DVD ausgeführt werden.
ADPREP muss aber nur dann ausgeführt werden, wenn der Server mit dem neueren Serverbetriebssystem zum DC gestuft werden soll! Wird der neue Server lediglich als Mitgliedsserver zur Domäne hinzugefügt, so muss das ADPREP nicht ausgeführt werden.
Soll der Server, der mit einem neuerem OS (Operating System = Betriebssystem) installiert ist als die existierenden DCs, zu einer bestehenden Domäne als zusätzlicher DC hinzugefügt werden, muss zuerst ADPREP /FORESTPREP auf dem Schemamaster und anschließend ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster in der Domäne ausgeführt werden, zu der der neue Server als DC hinzugefügt werden soll.
Wird jedoch mit dem neuen Server eine neue Subdomäne in einer bestehenden Gesamtstruktur erstellt, muss lediglich das ADPREP /FORESTPREP ausgeführt werden. Das ADPREP /DOMAINPREP /GPPREP muss und kann in diesem Szenario nicht ausgeführt werden, da es keine zu aktualisierende Domäne gibt. Schließlich wird mit dem neuen DC erst eine (weitere) Subdomäne erstellt.
Weitere Details beschreibt der folgende Artikel:
Das Active Directory Preparation Tool - ADPREP
Fehler die beim Ausführen von ADPREP auftreten können
- Wenn das Ausführen von ADPREP aus welchen Gründen auch immer fehl schlagen sollte, ist es empfehlenswert als erstes immer ins ADPREP-Protokoll zu schauen. Das ADPREP-Log wird im Verzeichnis %windir%\System32\Debug\Adprep\Logs erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.
-
Bevor der erste Server mit neuerem OS als die bereits existierenden DCs, als DC zur Gesamtstruktur hinzugefügt werden kann, muss zuerst das ADPREP /FORESTPREP in der Kommandozeile auf dem Schemamaster ausgeführt werden. Das Benutzerkonto mit dem dieser Befehl ausgeführt wird, muss Mitglied in den Gruppen Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet. Wenn ADPREP /FORESTPREP auf dem Schemamaster mit den notwendigen Rechten ausgeführt wurde und es trotzdem zu einem Fehler führt, weil ADPREP keinen Kontakt zum Schemamaster herstellen konnte (in seltenen Fällen), sollte der Schemamaster zuerst auf einen anderen DC und erneut zurück verschoben werden. Anschließend ist der Befehl ADPREP /FORESTPREP nochmals auszuführen.
-
Befindet sich das Benutzerkonto beim ausführen von ADPREP hingegen nicht in den entsprechenden Gruppen, kommt es zu diesem Fehler: Adprep encountered a Win32 error.
Error code: 0x5 Error message: Access is denied
Das Benutzerkonto muss zum ausführen von ADPREP /FORESTPREP Mitglied in den folgenden Gruppen sein:
- Schema-Admins< | |