Wenn ein Domänencontroller (DC) ausgetauscht wird, ist darauf zu achten, dass alle Dienste sowie Daten von einem anderen Server bzw. DC übernommen werden. Das trifft auch für die FSMO-Rollen zu. Falls der FSMO-Rolleninhaber ausgetauscht werden sollte, gilt es die FSMO-Rollen entweder durch die grafische Oberfläche oder durch das im Betriebssystem enthaltene Kommandozeilentool NTDSUTIL manuell zu verschieben.
Das händische verschieben der Rollen hat den Vorteil, dass der Administrator bestimmen kann auf welchen DC die Rollen verschoben werden. Somit weiß der Administrator genau, auf welchem DC sich die Rollen befinden. Ein weiterer Vorteil des manuellen Verschiebens wäre, falls ein Unternehmen AD-lastig arbeitet und die FSMO-Rollen somit mehr beansprucht werden, kann der Administrator die Rollen auf eine leistungsfähige Maschine verschieben oder ggf. auf mehrere DCs verteilen.
Die Rollen müssen aber nicht beim Herunterstufen des Rolleninhabers zwingend manuell verschoben werden. Denn die FSMO-Rollen werden mit Ausführen von DCPROMO seit Windows 2000 RTM, also seit der Einführung des Active Directory, während des DCPROMO-Vorgangs automatisch auf einen anderen DC übertragen. Die Rollen können aber nur dann einem anderen DC übergeben werden, wenn das DNS ordnungsgemäß funktioniert, sowie der Rolleninhaber Verbindung zur Domäne und somit zu seinen Replikationspartnern hat. Dabei geht der Rolleninhaber folgendermaßen vor:
-
Wurden die FSMO-Rollen vor dem herunterstufen nicht manuell verschoben, wird das „Operational Attribute“ GiveAwayAllFsmoRoles gesetzt. Das veranlasst den Rolleninhaber dazu, andere DCs ausfindig zu machen damit die Rollen die er trägt, auf einen anderen DC übertragen werden können.
-
Für die Wahl des zukünftigen Rolleninhabers werden die folgenden Regeln angewendet:
- Bevorzugt wird ein DC am gleichen Standort ausgewählt.
- Es wird ein DC zu dem eine RPC-Verbindung besteht gesucht.
- Es wird ein Server verwendet, zu dem eine asynchrone Verbindung (z.B. über das SMTP-Protokoll) existiert.
-
Natürlich können dabei die drei domänenspezifischen Rollen RID-Master, PDC-Emulator sowie Infrastrukturmaster nur innerhalb der Domäne verschoben werden.
-
Die beiden gesamtstrukturweiten Rollen Schemamaster sowie Domänennamenmaster können auf jeden DC in der Gesamtstruktur verschoben werden. Dabei spielt es keine Rolle, in welcher Domäne sie sich befinden.
Erreicht der Rolleninhaber während des Herunterstufens keinen weiteren DC, so schlägt zum einen das automatische Verschieben der Rollen und zum anderen das Herunterstufen fehl.
Wird der Rolleninhaber durch die erzwungene Herabstufung mit DCPROMO /Forceremoval heruntergestuft, so erhält der Administrator ab Windows Server 2003 SP1 für jede Rolle die der DC inne hat, eine Warnmeldung. Diese Rollen müssen dann im Nachhinein auf einem anderen DC offline übertragen werden.
Der Nachteil des automatischen Verschiebens der Rollen ist die nicht Vorhersagbarkeit der Ziel-DCs auf die die FSMO-Rollen verschoben werden (Ausnahme es existieren nur genau zwei DCs).
Doch auch bei dieser Variante müssen die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen ab Windows Server 2003 (wie z.B. ForestDNSZones und DomainDNSZones) manuell auf einen anderen DC verschoben werden. Diese werden nicht automatisch auf einen anderen DC übertragen. Näheres dazu erläutert der folgende Artikel:
Die Infrastrukturmaster der Anwendungsverzeichnispartitionen
Weitere Informationen:
Die FSMO-Rollen verschieben
How Operations Masters Work: Active Directory
Flexible Single Master Operation Transfer and Seizure Process
Es gab einmal ein 32Bit Serverbetriebssystem…
Im Herbst 2009 erscheint das nächste Serverbetriebssystem (Codename Windows Server 7) aus dem Hause Microsoft Namens Windows Server 2008 R2. Somit bleibt Microsoft seiner Roadmap treu und veröffentlicht alle vier Jahre ein Major Release sowie dazwischen nach zwei Jahren ein Minor Release. Dabei wurden die R2-Versionen erstmals mit Windows Server 2003 R2 eingeführt, wobei damals das R2 auf zwei CDs ausgeliefert wurde und es im nächsten Serverbetriebssystem eine DVD ist.
Wie bereits im Vorfeld angekündigt, setzt Microsoft seine Ankündigung nun um. Es heißt: Ade 32Bit Serverbetriebssystem.
Das nächste Serverbetriebssystem Windows Server 2008 R2 wird es ausschließlich nur in der x64Bit Version geben. Die Administratoren müssen sich dabei aber keine großen Gedanken machen, denn die Hardware der letzten drei bis vier Jahre ist x64bittig.
Was sind die Active Directory-Neuerungen im Windows Server 2008 R2?
Welche Neuerungen es im Allgemeinen bisher im Windows Server 2008 R2 geben wird, kann bereits hier nachgelesen werden.
Windows Server 2008 R2 Reviewers Guide
Weitere Informationen:
Windows Server 2008: R2
Windows Server 2008 R2 Active Directory: What's Coming Up?
Der Kommandozeilen-Server, als Server Core bekannt, kann mit Bordmitteln nur über die Kommandozeile konfiguriert werden. Remote lässt sich der Server Core auch über die MMCs verwalten, natürlich nur, wenn dieser aus der Ferne erreichbar ist. Wie der Server Core manuell konfiguriert wird, zeigt der folgende Artikel:
Windows Server 2008 Core
Es gibt aber auch schon die ersten kostenlosen Tools im Internet (bis auf den CoreConfigurator), damit die Erstkonfiguration des Server Core einfach durchgeführt werden kann. Es müssen keine langen und aufwändigen Befehle mehr eingegeben werden. Dabei kommen auch die Freunde der Maus auf ihre Kosten.
Der Server CoreConfigurator
Über den Server CoreConfigurator werden sich die Administratoren freuen, die lieber mit der Maus arbeiten als mit der Tastatur. Die grafische Oberfläche lässt das konfigurieren der wichtigsten Einstellungen zu, damit anschließend die Administration weitestgehend remote erfolgen kann.
Die Konfigurationen die mit diesem Tool durchgeführt werden können, sind aus dem Screenshot ersichtlich.
Der CoreConfigurator steht leider nicht mehr kostenlos zum Download zur Verfügung.
Stattdessen kann das erweiterte Tool kostenpflichtig für 99 Dollar auf der folgenden Seite erworben werden:
Core Configurator
Das Tool: CoreConfig
Dieses Tool bietet ebenfalls eine grafische Oberfläche. Es lässt sich aber nicht mit der Maus, sondern mit dem Ziffernblock der Tastatur bedienen. Auch mit diesem Tool kann die Erstkonfiguration des Server Core recht einfach vorgenommen werden. Aber im Gegensatz zum CoreConfigurator ist dieses Tool nicht kompiliert. Es stellt eine Ansammlung an Skripten dar.
Dieses Tool steht zum einen als CAB-Datei und zum anderen als ISO-Datei zur Verfügung. Nach dem entpacken der CAB-Datei kann dieses Tool direkt von einem USB-Stick ausgeführt werden. Das Tool lässt sich mit dem Aufruf von Setup-Core.wsf starten.
Download: Windows 2008 Server Core Configurator
Das Kommandozeilentool: Core Configurator Console
Das Tool Core Configurator Console (CCC) ist ein Kommandozeilentool. Nach dem Download kann die Datei zuerst auf einen USB-Stick und anschließend auf den Server Core kopiert werden, wobei es auch direkt vom USB-Stick ausgeführt werden kann. Das Tool an sich ist eine einzige Batch-Datei, das es in der Kommandozeile mit ccc.bat aufzurufen gilt. Auch mit diesem Werkzeug lassen sich die elementaren Einstellungen vornehmen, damit der Server Core remote administriert werden kann.
Für Windows Server 2008: Core Configuration Console
Für Windows Server 2008 R2: CCC R2
Windows Server 2008 R2 Core Configurator 2.0
Das Open Source Tool "CoreConfig" wurde weiterentwickelt und steht nun in der Version 2.0 zur Verfügung.
Mit dieser Version lässt sich die Erstkonfiguration eines "Windows Server 2008 R2 Core" über eine grafische Oberfläche konfigurieren.
Download: Core Configurator 2.0
Das "on Bord" Skript Sconfig.cmd in Windows Server 2008 R2
Die Konfiguration des Windows Server 2008 R2 Core
Mit der Tombstone Lifetime (zu Deutsch Grabstein Lebenszeit) wird bestimmt, wie lange ein gelöschtes Objekt noch in der Active Directory-Datenbank (NTDS.dit) gespeichert wird. Wenn ein Objekt gelöscht wird, verschwindet es nicht sofort aus der AD-Datenbank. Stattdessen wird das Objekt als gelöscht markiert, in dem das Attribut is-Deleted auf True gesetzt wird. Des Weiteren werden die meisten Attribute entfernt und das Objekt wird wie folgt umbenannt:
CN=<alter RDN>\0ADEL:<Object-GUID>.
Nach dem umbenennen wird das Objekt in den versteckten Container Deleted Objects der entsprechenden Verzeichnispartition verschoben. Ab diesem Zeitpunkt wird das gelöschte Objekt als Tombstone (Grabstein) bezeichnet. Anschließend werden diese Änderungen auf alle anderen Domänencontroller (DC) repliziert. Erst wenn die Tombstone Lifetime (TSL) überschritten wurde, wird das Objekt endgültig aus der AD-Datenbank entfernt.
Dieser Prozess ist deshalb notwendig, damit sichergestellt ist das auch jeder DC bei einer aufwändigen (weltweiten) Replikationstopologie, von dieser Löschung informiert wird. Endgültig gelöscht wird das Objekt dann nach Ablauf der TSL von dem Garbage Collection Prozess, der standardmäßig auf allen Domänencontrollern (DC) alle 12 Stunden läuft. Diese Zeit kann zwar verändert werden, jedoch besteht in der Praxis i.d.R. kein Bedarf dies zu tun.
Weiterhin bestimmt die TSL auch, wann sich spätestens ein DC einmal mit seinen Replikationspartnern repliziert haben muss, ehe Replikationsprobleme entstehen.
Wann wird die Tombstone Lifetime festgelegt?
Die TSL wird mit dem Installieren des ersten DCs in einer Gesamtstruktur und zwar für alle Domänen festgelegt. Die TSL kann nicht pro Domäne konfiguriert werden. Der Wert der TSL kann aber jederzeit manuell verändert werden (wozu Organisations-Admins Rechte benötigt werden), was jedoch begründet sein sollte. Dabei spielt weder der Domänenfunktionsmodus, noch der Gesamtstrukturfunktionsmodus eine Rolle.
Der Active Directory-Installationsassistent DCPROMO erzeugt aus der Datei schema.ini die TSL für die Gesamtstruktur. Unter Windows 2000 sowie Windows Server 2003 befindet sich diese Datei im Verzeichnis %systemroot%\system32 und unter Windows Server 2008 im Verzeichnis
%systemroot%\winsxs\x86_microsoft-windows-d..rvices-domain-files_31bf3856ad364e35_6.0.6001.18000_none_9b0b0e3a43600e0c
Der DCPROMO-Assistent nutzt diese Datei als Vorlage und entnimmt daraus seine Angaben, um das Basisschema entsprechend dem Serverbetriebssystem zu erstellen.
Vor dem Heraufstufen des ersten DCs, kann man die TSL in der schema.ini kontrollieren. Der Eintrag in der Datei lautet: tombstoneLifetime=<Wert in Tagen>.
Die TSL beträgt unter:
-
Windows 2000 (mit allen SPs) = 60 Tage
-
Windows Server 2003 ohne SP = 60 Tage
-
Windows Server 2003 mit Service Pack 1 = 180 Tage
-
Windows Server 2003 R2 mit Service Pack 1, installiert mit beiden R2-CDs = 60 Tage
-
Windows Server 2003 R2 mit Service Pack 1, installiert nur mit der ersten R2-CD = 180 Tage
-
Windows Server 2003 mit Service Pack 2 = 180 Tage
-
Windows Server 2003 R2 mit Service Pack 2 = 180 Tage
-
Windows Server 2008 = 180 Tage
-
Windows Server 2008 R2 = 180 Tage
Überprüfen und Bearbeiten der Tombstone Lifetime
Kontrollieren kann man das Attribut tombstoneLifeTime mit Dsquery wie folgt. Der Befehl lautet:
Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" -attr tombstoneLifetime
Falls kein Wert angezeigt wird, dann gilt der Standardwert von 60 Tagen. Ansonsten gilt der angezeigte Wert in Tagen.
Die TSL lässt sich auch mit ADSIEdit überprüfen und bearbeiten. Dazu gilt es, zuerst zum folgenden Container zu navigieren:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Dort befindet sich in den Eigenschaften des Containers das Attribut tombstoneLifetime. Ist dort ein Wert gesetzt, beträgt die TSL den eingetragenen Wert in Tagen. Steht im Attribut als Wert hingegen <Not Set>, so beträgt die TSL den Standardwert von 60 Tagen.
Mit der AD-PowerShell kann man die TSL folgendermaßen überprüfen:
Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" -Properties tombstoneLifetime | Select tombstoneLifetime | FL
Mit diesem Befehl lässt sich die TSL in der AD-PowerShell bearbeiten:
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“tombstoneLifetime” = Wert}
Hinweis: Das installieren eines Service Packs oder das Aktualisieren des Serverbetriebssystems verändert niemals den Wert der Tombstone Lifetime!
Auf was ist zu achten?
-
Die TSL darf keinen niedrigeren Wert enthalten, als die Replikation benötigt um alle DCs über einen Löschvorgang zu informieren. Ansonsten entfernt der Garbage Collection Prozess das gelöschte Objekt endgültig aus der AD-Datenbank, bevor alle Replikationspartner von der Löschung informiert wurden. Dies würde zu Inkonsistenzen in der AD-Datenbank führen.
-
Eine System State-Sicherung die älter als die TSL ist, darf nicht mehr verwendet werden. Die TSL gibt das maximale Alter einer Systemstatus-Sicherung an. Wird ein DC während der TSL mit einer Systemstatus-Sicherung die das Benutzerobjekt Yusuf enthält wiederhergestellt, nachdem das Objekt Yusuf gelöscht wurde, so würde der gelöschte Status von dem Objekt Yusuf auf den wiederhergestellten DC repliziert werden. Das Benutzerobjekt Yusuf wäre weiterhin nicht vorhanden, da die Wiederherstellung während der TSL durchgeführt wurde. Falls der DC nach der TSL wiederhergestellt werden würde, wäre das Benutzerobjekt Yusuf jedoch vorhanden. Denn auf den anderen DCs wäre das Objekt bereits aus der AD-Datenbank vom Garbage Collection Prozess entfernt worden. Das Benutzerkonto würde aber nur auf dem wiederhergestellten DC existieren. Dieser Zustand führt zu Inkonsistenzen in der AD-Datenbank und das Benutzerobjekt Yusuf wäre ein Lingering Object (herumlungerndes Objekt).
-
Ein DC darf nicht länger als die TSL offline sein. Wenn dies der Fall sein sollte, bekommt der nicht erreichbare DC von den mittlerweile gelöschten Objekten nichts mit und so kommt es dann zu Lingering Objects.
Welche Auswirkung hat das Erhöhen der Tombstone Lifetime?
-
Eine Systemstatus-Sicherung hat eine längere Nutzungsdauer.
-
Das Heraufstufen eines Servers durch die IFM-Funktion (Install from Media) zu einem DC hat durch das erhöhen der TSL, ebenfalls eine höhere Nutzungsdauer.
-
Ein DC kann länger offline bleiben und kann dadurch, nach einer längeren Offlinezeit wieder erfolgreich zur Domäne hinzugefügt werden.
-
Die gelöschten Objekte (Tombstones) bleiben länger auf den DCs erhalten und können dadurch ab Windows Server 2003, länger wiederhergestellt werden. Dadurch erhöht sich aber auch die Größe der AD-Datenbank.
Fazit: Die TSL sollte wenn möglich nicht verändert werden. Falls ein triftiger Grund besteht die TSL doch zu ändern, sollte der Wert nicht allzu groß gewählt werden.
Weitere Informationen:
The default tombstone lifetime (TSL) value remains at 60 days instead of increasing to 180 days in Windows Server 2003 R2
The Active Directory database garbage collection process
Es ist empfehlenswert, dass jedes Unternehmen eine Kennwortrichtlinie einsetzt, die entsprechend konfiguriert ist
(Komplexität, Kennwortchronik, Kennwortlänge, Kennwortalter etc.).
Kennwortrichtlinien, die für Domänen-Benutzer gelten sollen, müssen auf Domänenebene verlinkt werden. Wenn eine Kennwortrichtlinie auf einer Organisationseinheit (OU) verlinkt wird, betrifft das lediglich die lokalen Benutzerkonten auf den Clients. Bis Windows Server 2003 kann es dabei pro Domäne nur eine Kennwortrichtlinie geben. Besteht der Bedarf für einen Standort eine eigene Kennwortrichtlinie zu definieren, so musste für diesen Standort eine Sub-Domäne erstellt werden. Anders war dieses Ziel mit Bordmitteln nicht lösbar. Erst ab Windows Server 2008 lassen sich mehrere Kennwortrichtlinien pro Domäne mit Bordmitteln einrichten und nennen sich dort "Password Settings Objects" kurz PSO. In einer Windows Server 2003 Umgebung kann man mehrere Kennwortrichtlinien pro Domäne nur mit Dritt-Anbieter Tools realisieren, wie z.B. Specops Password Policy oder nFront Password Filter.
Möchte ein Unternehmen das bisher keine Kennwortrichtlinie im Einsatz hatte, dieses nun nachholen, sollte die Einführung einer Kennwortrichtlinie sorgfältig geplant und die Benutzer ausführlich informiert werden. Es ist ratsam nach der Konfiguration der Kennwortrichtlinie, im Reiter Konto die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ in allen Benutzerkonten zu aktivieren. Denn schließlich existierte bisher keine Sicherheitsanforderung bei der Kennwortwahl, so dass es höchste Zeit wird dieses schnellstmöglich zu aktivieren.
Ist allerdings eines der Flags im userAccountControl Attribut, nämlich die Option „Kennwort läuft nie ab“ aktiviert, so ist ein zusätzliches aktivieren der Option Benutzer muss Kennwort bei der nächsten Anmeldung ändern nicht möglich. Es dürfte jedem klar sein, dass sich diese beiden Optionen widersprechen. Wird die Option „Kennwort läuft nie ab“ aktiviert, so wird mit einem Hinweis die evtl. bereits aktivierte Option „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ deaktiviert.
Wird in den Kennwortrichtlinien die Einstellung „Maximales Kennwortalter“ konfiguriert, so kann es passieren, dass die Benutzer bei ihrer nächsten Anmeldung aufgefordert werden ihr Kennwort zu ändern, ohne dass die Option „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ gesetzt ist. Denn angenommen ein Benutzer verwendet sein Kennwort, das bereits 200 Tage alt ist und es wird ein maximales Kennwortalter von 180 Tagen definiert, so erhält dieser Benutzer bei seiner nächsten Domänenanmeldung die Aufforderung sein Kennwort zu ändern. Das Alter des Kennworts wird vom Attribut Pwd-Last-Set errechnet. In dem Attribut wird ein 64Bit Integer Wert des Zeitpunkts der letzten Kennwortänderung gespeichert. Umrechnen lässt sich dieser Wert mit dem Befehl: w32tm /ntte <Wert>.
Es gibt aber eine Option, die verhindert, dass nach der Konfiguration eines maximalen Kennwortalters die Benutzer mit einem älteren Kennwort dies nicht bei der nächsten Domänenanmeldung ändern müssen.
-
In den Benutzerkonten ist zuerst die Kontooption Benutzer muss Kennwort bei der nächsten Anmeldung ändern zu aktivieren.
-
Danach gilt es die gewählte Option mit Übernehmen zu bestätigen.
-
Anschließend muss die soeben aktivierte Kontooption erneut deaktiviert und mit Übernehmen oder OK bestätigt werden.
Wird in den Eigenschaften eines Benutzerkontos im Reiter Konto die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ gesetzt, so erhält das Attribut pwdLastSet im entsprechenden Benutzerobjekt den Wert „0“. Wenn anschließend der Haken wieder entfernt wird, erhält das Attribut als Wert, dass Datum sowie die Uhrzeit von dem Moment, in dem diese Einstellung durchgeführt wurde.
In den Benutzerobjekten lässt sich die Kontooption z.B. durch ein Skript aktivieren oder deaktivieren. Eine andere Variante wäre zuerst die Benutzer mit STRG auszuwählen, dann mit einem Rechtsklick auf die Benutzerobjekte die Eigenschaften aufzurufen, um danach im Reiter Konto die entsprechende Option auszuwählen bzw. zu deaktivieren.
Verifizieren kann man das durch Überprüfen des Attributs pwdLastSet im Benutzerobjekt, mit dem Befehl: w32tm /ntte <Wert aus pwdLastSet>.
Dort sollte dann das aktuelle Datum stehen.
Wann das Kennwort zuletzt gesetzt wurde, kann man auch wie folgt kontrollieren: Net User <username> /Domain.
Oder mit der Account Info DLL (kurz Acctinfo.dll).
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|