Ist es nun mit dem Windows Server 2008 das endgültige aus für den Windows Internet Naming Service (WINS) Server?
Microsoft sieht diesen Dienst nicht mehr als eine wichtige Rolle an, denn der WINS-Server ist nicht etwa im
Windows Server 2008 unter den Rollen zu finden, sondern, unter den Features. Unter Windows Server 2003 befand sich
der WINS-Server noch neben den Server-Funktionen: Domänencontroller, DNS, DHCP etc.
Mit dem WINS-Dienst werden NetBIOS-Namen in IP-Adressen aufgelöst. Dieser Dienst stellt das Pendant zum
Domain Name System (DNS) dar, denn es arbeitet ähnlich wie das DNS, dynamisch. Ein Unterschied zwischen
DNS und WINS sind die genutzten Ports. DNS verwendet den Port 53 und WINS die Ports 137, 138, 139 und 445.
WINS ist ein älterer Dienst der NetBIOS über TCP/IP (NetBT) nutzt und der elementare Dienst für die Namensauflösung
im Windows 9x bzw. Windows NT Umfeld ist. Mit Einführung von Windows 2000 führte Microsoft das Active Directory ein
und forcierte somit die Nutzung des DNS.
Falls kein WINS-Server in der Domäne zur Verfügung steht, werden NetBIOS-Namen durch Broadcasts aufgelöst. Durch die
Broadcasts kann sich je nach Größe der Umgebung sowie den eingesetzten Applikationen, der Netzwerkverkehr erheblich erhöhen.
Das betreiben eines WINS-Server in der Domäne ist zwar nicht zwingend, es ist aber mehr als empfehlenswert.
Warum? Weil zum einen jede Applikation die eine NetBIOS-Namensauflösung benötigt vom WINS profitiert und zum anderen,
der administrative Aufwand gegenüber dem Nutzen in keinem Verhältnis steht. Wenn z.B. eine Applikation ein langsames
Start- oder Arbeitsverhalten an den Tag legt, könnte das durch einen fehlenden WINS-Server hervorgerufen werden.
Einmal den WINS-Server installiert sowie konfiguriert, produziert er im täglichen Leben kaum Arbeit.
Weitere Beispiele die eine NetBIOS-Namensauflösung benötigen und somit von einem WINS-Server profitieren, wären z.B.:
Was hat das nun mit dem Windows Server 2008 auf sich?
Da das Internet Protokoll in der Version 6 (IPv6) langsam aber sicher Einzug in den Unternehmen erhält und WINS
sowie NetBT nicht das IPv6 Protokoll unterstützen, hat Microsoft im Windows Server 2008 eine weitere neue Funktion,
nämlich die Global Names Zone (GNZ) im DNS eingeführt. Diese neue Funktion kann natürlich auch mit dem IPv4 Protokoll
genutzt werden. Bei der GNZ handelt es sich um eine Forward Lookup Zone (FLZ) mit statischen, globalen Einträgen,
die in erster Linie für größere Umgebungen konzipiert wurde.
Die GNZ ist kein neuer Zonentyp, sondern, dieser zeichnet sich alleine durch seinen reservierten Namen aus.
Diese Zone erlaubt das Auflösen von single-label, den sogenannten kurzen (NetBIOS) Namen, alleine durch den DNS-Dienst.
Somit können nun Unternehmen die auf ein reines IPv6-Netzwerk wechseln, dank der GNZ im DNS, die Namensauflösung mit
nur einer Domänenbezeichnung weiterhin nutzen. Oder wenn ein Unternehmen komplett auf die NetBIOS-Namensauflösung
verzichten und dabei aber trotzdem die single-label Namensauflösung nutzen möchte, dem wird das ebenfalls durch die GNZ ermöglicht.
Natürlich sollte vorher sichergestellt sein, dass nicht doch noch Applikationen existieren, die evtl. hart-codiert eine
NetBIOS-Namensauflösung benötigen. Auch ist diese Funktionalität für die Unternehmen interessant, die das verteilen
von DNS-Suffixen z.B. per GPO nicht als praktikabel ansehen.
Fakt ist aber, die GNZ ist kein Ersatz für den WINS-Dienst!
Da keine dynamischen Updates in der GlobalNames Zone registriert werden können wie im WINS, sollte die single-label
Namensauflösung in der GNZ primär für die wichtigsten Server oder Webseiten konfiguriert werden. Das bedeutet,
die Verwaltung dieser FLZ unterliegt dem Administrator. Dieser muss die Einträge händisch pflegen. Nach der Erstellung
der GlobalNames Zone im DNS, muss der Administrator manuell die Einträge in dieser Zone erstellen, hinzufügen, bearbeiten und entfernen.
Die Gründe für den Einsatz der GlobalNames Zone wären:
- WINS soll nicht mehr verwendet werden.
- Umstellung auf ein reines IPv6 Netzwerk.
- Die Namensauflösung von einfachen, kurzen Namen soll lediglich für wichtige Server und Webseiten möglich sein.
- Alle autorisierenden DNS-Server der Zone laufen unter Windows Server 2008.
- Wenn es sich um eine große Umgebung mit vielen Domänen handelt,
kann das bereitstellen der Suffixsuchlisten auf den Clients sehr aufwändig sein.
- Wenn keine zentrale Verwaltung in großen Umgebungen möglich ist,
kann auch nicht die Eindeutigkeit von Hostnamen sichergestellt werden.
Die Gründe gegen den Einsatz der GlobalNames Zone wären:
- Es werden keine dynamischen DNS-Updates unterstützt!
- Die Einträge in der GNZ müssen manuell gepflegt werden.
- Die GNZ funktioniert ausschließlich auf DNS-Servern die unter Windows Server 2008 laufen.
Die Vorrausetzungen und die Besonderheiten der Global Names Zone wären:
- Alle autoritativen DNS-Server einer Zone müssen unter Windows Server 2008 laufen.
- Die Global Names Zone wird wie eine ganz normale Forward Lookup Zone (FLZ) im DNS implementiert. Der Name der FLZ
muss dabei zwingend GlobalNames lauten. Falls bereits eine FLZ mit diesem Namen existieren sollte, ist diese vorher zu entfernen.
- Die GlobalNames Zone sollte AD-integriert gespeichert sein und auf alle DNS Server in der Gesamtstruktur repliziert werden.
Wenn aber lediglich eine begrenzte Anzahl der Server für die GlobalNames-Zone autorisierend sein soll, kann dazu eine
eigene DNS-Anwendungsverzeichnispartition erstellt werden.
- Alle Einträge in der GNZ sollten als Alias-Einträge (einem sogenannten CNAME-Eintrag) erfolgen.
-
Auf jedem autoritativen DNS-Server in der Domäne und Gesamtstruktur muss ab sofort und für die Zukunft,
der folgende Befehl mit Administratorrechten ausgeführt werden, damit die GNZ-Funktionalität auf den
Windows Server 2008 DNS-Servern gewährleistet ist:
Dnscmd Servername /Config /EnableGlobalNamessupport 1.
Hinweis: Als Servername ist der Name des entsprechenden Servers einzutragen.
Wobei der lokale Server mit einem Punkt angegeben werden kann. Somit entfällt die Eingabe des Servernamen.
Der Befehl würde dann so aussehen: Dnscmd . /Config /EnableGlobalNamessupport 1. Mit diesem Befehl wird in dem Registry-Pfad
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\DNS\Parameters der DWORD-Schlüssel EnableGlobalNamessupport
mit dem Wert 1 erstellt. Natürlich kann dieser Schlüssel manuell in der Registry erstellt werden,
damit sich das Ausführen von DNSCMD erübrigt.
Das einrichten einer GlobalNames Zone
Die GNZ kann entweder über die Benutzeroberfläche oder Kommandozeile eingerichtet werden.
Die Vorgehensweise über die GUI wäre folgende:
- Im ersten Schritt gilt es die DNS-Managementkonsole (dnsmgmt.msc) entweder über „Start - Programme - Verwaltung - DNS“
oder über „Start - Ausführen - dnsmgmt.msc“ aufzurufen.
- Mit einem Rechtsklick auf den Servernamen oder dem Eintrag Forward-Lookupzonen ist die Option Neue Zone… auszuwählen.
- Nach der Willkommensseite ist der Zonentyp zu wählen. Es ist die erste Option Primäre Zone sowie das Kontrollkästchen
Zone in Active Directory speichern (DNS-Server muss als schreibbarer Domänencontroller eingerichtet sein) auszuwählen.
Damit die Zone im AD gespeichert werden kann, muss der DNS-Server auf einem DC installiert sein. Ansonsten kann diese
Option nicht aktiviert werden (sie ist dann ausgegraut).
- Im nächsten Schritt möchte der Assistent auf der Active Directory-Zonenreplikationsbereich Seite wissen, auf welche
Server zum einen diese Zonendaten repliziert und zum anderen, in welcher Anwendungsverzeichnispartition diese Informationen
gespeichert werden sollen. Dabei ist es zwingend notwendig die erste Option
Auf allen DNS-Servern in der Gesamtstruktur:Root-Domäne.TLD zu wählen. Mit dieser Auswahl wird die Zone in der
Anwendungsverzeichnispartition ForestDNSZones gespeichert und wird zudem auf alle DNS-Server in der Gesamtstruktur repliziert.
- Als nächstes ist es notwendig, den Namen der neuen Zone einzutragen. Dieser muss GlobalNames lauten.
Die Schreibweise des Namens ist zu vernachlässigen, denn sie ist in diesem Fall nicht „case-sensitive“.
- Im darauffolgenden Schritt möchte der Assistent wissen, welche Art von dynamischen Updates für diese Zone gelten soll.
Da die GNZ keine dynamischen Updates unterstützt und die Einträge manuell zu pflegen sind, ist die letzte Option
Dynamische Updates nicht zulassen auszuwählen.
- Im letzten Schritt angelangt, wird mit einem Klick auf Fertig stellen der Assistenten beendet.
Anschließend steht die neue Zone zur Verfügung.
Das einrichten der GlobalNames Zone über die Kommandozeile wäre folgende:
Einträge zur GlobalNames Zone hinzufügen
Auch beim Hinzufügen von DNS-Einträgen hat der Administrator die Auswahl zwischen der GUI und der Kommandozeile.
Über die Benutzeroberfläche wird ein Eintrag wie folgt erstellt:
- Mit einem Rechtsklick auf die FLZ GlobalNames ist die Option Neuer Alias (CNAME)… auszuwählen.
- Im Feld Aliasname ist der gewünschte Name einzutragen.
- Im Feld Vollqualifizierter Domänenname des Zielhosts ist der Ziel-Host mit seinem Fully Qualified Domain Name (FQDN) einzutragen.
Der Befehl zum erstellen eines Eintrags über die Kommandozeile sieht so aus:
- Dnscmd /RecordAdd GlobalNames <Name> CNAME <FQDN des Ziel-Hosts>
Ein Windows 2000, XP oder Windows Vista Client hängt in folgender Reihenfolge das DNS-Suffix an:
- Zuerst wird das primäre DNS-Suffix angehängt, außer wenn (z.B. per GPO für XP/Vista-Clients) eine Suffixsuchliste konfiguriert wurde.
Das primäre DNS-Suffix ist standardmäßig der Domänenname, in welcher der Client Mitglied der Domäne ist. Das primäre DNS-Suffix
findet man unter: Systemsteuerung - System - Reiter Computername - Ändern - Weitere…
- Falls keine Suffixsuchliste an den Clients konfiguriert wurde, wird anschließend das Verbindungsspezifische DNS-Suffix
der entsprechenden Netzwerkkarte verwendet.
- Ist eine Suffixsuchliste bei den Clients konfiguriert, so werden einzig und alleine diese anstatt des primären und verbindungsspezifischen
DNS-Suffix angewendet. An Windows XP und Windows Vista Clients können per GPO eine Suffixsuchliste verteilt werden
(Computerkonfiguration-Administrative Vorlagen-Netzwerk-DNS-Client-„Suchliste für DNS-Suffix“).
How to configure a domain suffix search list on the Domain Name System clients
Ergänzend
Die aktuellen Betriebssysteme Windows Vista sowie Windows Server 2008 unterstützen zudem noch das
Link-Local Multicast Name Resolution (LLMNR), auch bekannt als Multicast DNS oder mDNS. Mit diesem neuen Protokoll wird
eine weitere Möglichkeit zur Auflösung von Hostnamen im gleichen Subnet zur Verfügung gestellt. Dies ist insbesondere dann
interessant, wenn kein DNS-Server zur Verfügung steht.
Mehr dazu: Link-Local Multicast Name Resolution
Fazit
Auch unter Windows Server 2008 lautet die Antwort: WINS hat weiterhin seine Daseinsberechtigung!
Weitere Informationen:
DNS Server GlobalNamesZone Deployment
Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality
Bei einer Migration auf Windows Server 2008 führen die Träger der FSMO-Rollen wichtige Aufgaben durch.
Genau genommen handelt es sich dabei um zwei FSMO-Rollen. Zum einen wäre das die Rolle des Schemamasters,
den es nur einmal in der Gesamtstruktur gibt. Dieser erweitert bei einer Migration das Schema in dem neue Attribute
sowie Klassen dem Schema hinzugefügt oder bestehende Attribute verändert werden. Zum anderen wäre da noch der Infrastrukturmaster.
Diese Rolle, die einmal pro Domäne existiert, aktualisiert während einer Migration die bestehende Domäne in dem Berechtigungen
bestehender Objekte bearbeitet werden. Erst wenn diese beiden Rollen die Änderungen die durch das ADPREP hervorgerufen
werden durchgeführt haben, ist es möglich einen Domänencontroller (DC) auf Windows Server 2008 zu aktualisieren bzw. einen
Windows Server 2008 DC zur Domäne hinzuzufügen.
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Welche Rolle nimmt nun der PDC-Emulator bei einer Migration auf Windows Server 2008 ein?
Nun, eine analoge wie bei einer Migration von Windows 2000 auf Windows Server 2003. 
Der PDC-Emulator ist neben den beiden Rollen „RID-Master“ und „Infrastrukturmaster“ die dritte Rolle, die in jeder Active Directory-Domäne existiert.
Diese Rolle nimmt in seiner täglichen Arbeit wichtige Aufgaben wahr.
Unter anderem wären das:
-
Zeitsynchronisation. DCs gleichen sich ihre Zeit vom PDC-Emulator ab.
-
Gruppenrichtlinien werden auf dem PDC-Emulator bearbeitet.
-
Kennwortänderungen von Benutzern werden von dem DC auf dem diese Änderung durchgeführt wurde, bevorzugt zum PDC-Emulator repliziert.
-
Wenn ein Anmeldeversuch eines Benutzers fehlschlagen sollte, wird in letzter Instanz das Kennwort vom PDC-Emulator überprüft.
-
Kontosperrungen werden vom PDC-Emulator durchgeführt.
Findet eine Migration statt, so bekommt der PDC-Emulator eine weitere wichtige Aufgabe die im Folgenden erläutert wird.
Falls in einer Windows 2000 Domäne ein Windows Server 2003- oder Windows Server 2008 Domänencontroller hinzugefügt
und auf diesem die Rolle des PDC-Emulators verschoben wird, werden diverse neue Sicherheitsprinzipale erstellt und bestehende
Gruppenzugehörigkeiten verändert. Das gleiche erfolgt natürlich auch, wenn der Träger des PDC-Emulators per In-place Upgrade
auf Windows Server 2003 aktualisiert wurde.
Es werden die folgenden Builtin-Gruppen in jeder Domäne erstellt:
-
Builtin\Erstellungen eingehender Gesamtstrukturvertrauensstellung
-
Builtin\Distributed COM Users
-
Builtin\Leistungsprotokollbenutzer
-
Builtin\Netzwerkkonfigurations-Operatoren
-
Builtin\Remotedesktopbenutzer
-
Builtin\Systemmonitorbenutzer
-
Builtin\Terminalserver-Lizenzserver
-
Builtin\Windows-Autorisierungszugriffsgruppe
Zusätzlich werden die nachfolgend genannten Gruppenzugehörigkeiten in jeder Domäne aktualisiert:
-
Der Builtin-Gruppe\Prä-Windows 2000 kompatibler Zugriff wird das Objekt ForeignSecurityPrincipal\Authentifizierte Benutzer hinzugefügt.
-
Befindet sich aber das Objekt ForeignSecurityPrincipal\Jeder bereits in der Builtin-Gruppe\Prä-Windows 2000 kompatibler Zugriff,
so werden die Objekte ForeignSecurityPrincipal\ANONYMOUS-ANMELDUNG und ForeignSecurityPrincipal\Authentifizierte Benutzer hinzugefügt.
-
Das Objekt ForeignSecurityPrincipal\NETZWERKDIENST wird zu der Builtin-Gruppe\Leistungsprotokollbenutzer hinzugefügt, aber nur,
wenn der PDC-Emulator auf einen Windows Server 2003 DC aktualisiert bzw. verschoben wird. Das gilt nicht für einen Windows Server 2008 DC.
-
Die Builtin-Gruppe\Windows-Autorisierungszugriffsgruppe wird um das neue Mitglied
ForeignSecurityPrincipal\DOMÄNENCONTROLLER DER ORGANISATION ergänzt.
Den Container ForeignSecurityPrincipal kann man sich z.B. in der MMC „Active Directory-Benutzer und -Computer“ anschauen.
Allerdings werden die darin gespeicherten Objekte erst dann angezeigt, wenn in dem Snap-In unter Ansicht die Option
Erweiterte Funktionen aktiviert wurde.
Wird der Windows 2000 Domänencontroller der Root-Domäne auf dem der PDC-Emulator liegt per In-place Upgrade auf
Windows Server 2003 aktualisiert oder die Rolle auf einen Windows Server 2003 bzw. Windows Server 2008 DC verschoben,
so werden weitere Objekte der Klasse ForeignSecurityPrincipal im Container WellKnown Security Principals erstellt.
Der Container befindet sich in der Konfigurationspartition.
Die neuen Objekte wären:
-
Digest Authentication
-
Local Service
-
-
-
-
-
-
Bei einer Migration von Windows 2000 oder Windows Server 2003 auf Windows Server 2008
werden weitere Sicherheitsprinzipale erstellt sowie Gruppenzugehörigkeiten aktualisiert.
Neue Well-Known und Builtin-Gruppen werden erzeugt sowie bestehende Gruppenzugehörigkeiten verändert, wenn folgendes zutrifft:
Beim verschieben einer FSMO-Rolle wird im Verzeichnisdienstprotokoll die Event-ID 1458 protokolliert.
Leider fehlt in diesem Eintrag der Hinweis, welche Rolle verschoben wurde!
Die Veränderungen wären wie folgt:
Diese Builtin- sowie lokalen Sicherheitsgruppen werden in jeder Domäne erstellt:
-
Builtin\Ereignisprotokollleser
-
-
Builtin\Kryptografie-Operatoren
-
Builtin\Zertifikatdienst-DCOM-Zugriff
-
Users\Abgelehnte RODC-Kennwortreplikationsgruppe
-
Users\Domänencontroller ohne Schreibzugriff
-
Users\Zulässige RODC-Kennwortreplikationsgruppe
-
Users\Krbtgt_<ID> (wird nur erstellt, wenn ein RODC zu einer Windows Server 2003/2008 Domäne hinzugefügt wurde)
-
Users\Domänencontroller der Organisation ohne Schreibzugriff (diese Gruppe wird nur in der Root-Domäne erstellt)
Die neuen Gruppenzugehörigkeiten in jeder Domäne wären:
-
Das Sicherheitsprinzipal ForeignSecurityPrincipals\IUSR wird zur Builtin-Gruppe IIS_IUSRS hinzugefügt
-
Das Sicherheitsprinzipal ForeignSecurityPrincipals\NETZWERKDIENST wird aus der Builtin-Gruppe\Leistungsprotokollbenutzer entfernt
-
Die folgenden Gruppen werden der Gruppe Abgelehnte RODC-Kennwortreplikationsgruppe hinzugefügt:
-
-
-
Domänencontroller ohne Schreibzugriff
-
-
-
Richtlinien-Ersteller-Besitzer
-
-
In der Root-Domäne werden in der Konfigurationspartition die folgenden Objekte im Container WellKnown Security Principals erstellt:
-
-
-
Das Objekt Well-Known-Security-Id-System wird umbenannt zu System
Es ist stets empfehlenswert die FSMO-Rollen einer Domäne (insbesondere den PDC-Emulator) auf den DC,
der das aktuellere Serverbetriebssystem ausführt zu verschieben. Wird das nicht getan, so werden die entsprechenden
Sicherheitsprinzipale nicht erstellt. Dabei sollte aber beachtet werden, falls man sich dazu entscheidet die FSMO-Rollen
zu trennen (was in vielen Umgebungen nicht notwendig ist), dass es dabei ebenfalls einiges zu beachten gilt:
Die FSMO-Rollen verschieben
Weitere Informationen:
Well-known security identifiers in Windows operating systems
Immer wieder stolpere ich über Missverständnisse, welche Rolle der Domänen- respektive Gesamtstrukturfunktionsmodus in einer
bestehenden Umgebung spielt. Gerade im Zusammenhang wenn eine Migration bevor steht oder ein Windows 2000 Domänencontroller (DC)
in eine Windows Server 2003 Domäne hinzugefügt werden soll, kommen Administratoren des Öfteren ins straucheln.
Gerade auf dem Windows Server 2008 Launch in Frankfurt am Main fiel mir in den Gesprächen immer wieder auf,
dass es Missverständnisse mit den einzelnen Funktionsebenen gibt.
Als mit Windows 2000 das Active Directory in seiner ersten Version eingeführt wurde, musste Microsoft die Interoperabilität innerhalb
der Domänen zwischen den verschiedenen Serverbetriebssystemen die auf Domänencontrollern installiert sein können sicherstellen.
Demzufolge wurde mit Windows 2000 die Funktionsebenen, genauer, der Domänenfunktionsmodus eingeführt. Mit Windows Server 2003
kam zusätzlich der Gesamtstrukturfunktionsmodus hinzu. Durch die jeweiligen Funktionsebenen konnte gewährleistet werden,
dass Domänencontroller (DC) auf älteren Serverbetriebssystemen auch mit DCs die auf neueren Serverbetriebssystemen laufen,
zusammen innerhalb einer Domäne existieren können. Weiterhin konnte mit den Funktionsebenen sichergestellt werden,
dass Domänen sowie Gesamtstrukturen in einem bestimmten Modus betrieben werden können, um so die jeweils zur Verfügung stehenden
(neuen) Funktionen nutzen zu können. Denn dadurch, dass das Serverbetriebssystem stetig weiterentwickelt wird, werden mit jeder
neuen Version neue Funktionen der Domäne sowie der Gesamtstruktur hinzugefügt. Das bedeutet im Umkehrschluss,
dass die Vorgängerversionen die Neuerungen die mit jeder neuen Serverbetriebssystem-Version dem Active Directory hinzugefügt werden,
nicht kennen und somit auch nicht nutzen können.
Folglich wird mit den Funktionsebenen die Möglichkeit geschaffen, einerseits DCs mit verschiedenen Serverbetriebssystem-Versionen
innerhalb der Domäne zu betreiben und andererseits, neue Funktionen dem Active Directory hinzuzufügen. Der Administrator kann selbst
entscheiden wann er in die nächsthöhere Ebene wechselt, um von den Vorteilen die der höhere Modus bietet zu profitieren. Dies kann er
selbstverständlich nur dann tun, wenn die Voraussetzung für den höheren Modus gegeben sind. Den Unternehmen wird somit die Möglichkeit
geschaffen, eine sanfte Migration z.B. von Windows NT zu Windows 2000 oder Windows Server 2003 durchzuführen und parallel NT-BDCs,
Windows 2000 DCs und Windows Server 2003 DCs zu betreiben. Anschließend kann die sukzessive Migration der einzelnen DCs auf das neuere
Serverbetriebssystem durchgeführt und am Ende der Modus umgestellt werden.
NT-BDCs können neben Windows Server 2008 DCs nicht mehr existieren!
Stattdessen können Windows 2000 DCs sowie Windows Server 2003 DCs neben Windows Server 2008 DCs bestehen.
Der Domänenfunktionsmodus legt den Modus einer Domäne und somit die einzusetzenden Domänencontroller in dieser Domäne fest.
Dieser Modus kann nur dann heraufgestuft werden, wenn alle Domänencontroller einer Domäne eine gewisse Serverbetriebssystem-Version
ausführen, die für den höheren Modus notwendig ist.
Das bedeutet konkret, möchte man in den einheitlichen Domänenfunktionsmodus
Windows 2000 pur wechseln, so müssen alle DCs dieser Domäne unter Windows 2000, Windows Server 2003/2003R2,
Windows Server 2008 oder Windows Server 2008 R2 laufen. Es dürfen keine NT-BDCs mehr in der Domäne existieren,
da ansonsten die Möglichkeit des Heraufstufen nicht gegeben ist.
Befindet sich die Domäne im Modus Windows Server 2003, so ist es nicht mehr möglich einen Windows 2000 DC,
geschweige denn NT-BDC zur Domäne hinzuzufügen, sondern nur noch Windows Server 2003/2003 R2 und Windows Server 2008/2008 R2 DCs.
Oder wenn man in den Domänenfunktionsmodus Windows Server 2008 wechseln möchte um von den neuen Features zu profitieren
(Password Settings Objects - kurz PSO - oder die DFS-Replikation für das SYSVOL-Verzeichnis), so müssen alle DCs dieser Domäne
unter Windows Server 2008 oder Windows Server 2008 R2 laufen. Sonst ist das Heraufstufen der Domäne nicht möglich.
Möchte man den AD-Papierkorb der unter Windows Server 2008 R2 zur Verfügung steht nutzen, so muss sich der Gesamtstrukturfunktionsmodus
auf Windows Server 2008 R2 befinden. In diesem Modus können dann nur Windows Server 2008 R2 DCs oder höher existieren.
Wie bereits erwähnt, wurde im Active Directory von Windows Server 2003 neben dem Domänenfunktionsmodus zusätzlich der
Gesamtstrukturfunktionsmodus eingeführt. Mit diesem zusätzlichen Modus auf Gesamtstrukturebene wird zwischen einer Windows 2000,
Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2 Gesamtstruktur klar unterschieden.
Der Gesamtstrukturfunktionsmodus legt den Modus einer Gesamtstruktur fest. Das Heraufstufen ist nur dann möglich,
wenn sich alle Domänen in dieser Gesamtstruktur in einem bestimmten Domänenfunktionsmodus befinden.
In den Gesamtstrukturfunktionsmodus Windows 2000 lässt sich nur dann wechseln, wenn sich alle Domänen im Domänenfunktionsmodus
„Windows 2000 pur“ oder höher befinden. Auf den Gesamtstrukturfunktionsmodus Windows Server 2003 kann nur dann gewechselt werden,
wenn sich alle Domänen im Domänenfunktionsmodus Windows Server 2003 oder höher befinden.
Das gleiche gilt natürlich auch für den Gesamtstrukturfunktionsmodus Windows Server 2008. Dort kann in diese Ebene nur gewechselt werden,
wenn alle Domänen im Domänenfunktionsmodus Windows Server 2008 oder höher sind. Um in den Gesamtstrukturfunktionsmodus
Windows Server 2008 R2 zu wechseln, müssen sich alle Domänen im Domänenfunktionsmodus "Windows Server 2008 R2" oder höher befinden.
Hinweis: Wenn sich die Domänen in einer Windows Server 2003 Gesamtstruktur im Domänenfunktionsmodus „Windows 2000 pur“ befinden,
werden diese automatisch auf den Domänenfunktionsmodus „Windows Server 2003“ heraufgestuft, sobald man den
Gesamtstrukturfunktionsmodus auf Windows Server 2003 stuft. Vorausgesetzt, es befinden sich in allen Domänen der
Gesamtstruktur ausschließlich Windows Server 2003 DCs.
Das gleiche trifft im Übrigen auf eine Windows Server 2008 Gesamtstruktur zu. Wenn dort die Domänen im einheitlichen
Domänen-Modus „Windows 2000“ oder „Windows Server 2003“ sind und sich ausschließlich Windows Server 2008 DCs in
den Domänen befinden, werden alle Domänen auf den Domänenfunktionsmodus Windows Server 2008 gestuft, sobald der
Gesamtstrukturfunktionsmodus auf Windows Server 2008 gestuft wird.
Das bedeutet im Klartext, befinden sich alle Domänen in der Gesamtstruktur in einem "einheitlichen Modus" und werden die Betriebssysteme
die auf den DCs laufen von dem höheren Modus unterstützt, so werden alle Domänen automatisch in den höheren Domänenfunktionsmodus heraufgestuft,
sobald man den Gesamtstrukturfunktionsmodus heraufstuft.
Die Funktionsebenen auf Domänen- sowie Gesamtstrukturebene haben einzig und allein Einfluss auf die Domänencontroller.
Mitgliedsserver sowie Clients sind davon unbetroffen und können in jedem Modus Mitglied der Domäne sein. Auch im
Domänenfunktionsmodus „Windows Server 2003“ können Windows NT Mitgliedsserver weiterhin existieren.
Wichtig ist, wurde der Domänen- oder Gesamtstrukturfunktionsmodus einmal heraufgestuft, kann der Modus nicht mehr zurückgestuft werden!
Das Heraufstufen der Domäne bzw. Gesamtstruktur ist ein irreversibler Vorgang!
Eine Ausnahme besteht jedoch seit Windows Server 2008 R2. Ist der AD-Papierkorb nicht aktiviert, kann der Domänen- sowie Gesamtstrukturfunktionsmodus
nur auf "Windows Server 2008" zurückgestuft werden (Details unter "Weitere Informationen").
Für das Heraufstufen des Domänenfunktionsmodus werden Domänen-Administrator Rechte benötigt.
Die Heraufstufung wird von dem DC durchgeführt, der die FSMO-Rolle des PDC-Emulators innehat.
Egal mit welchem DC der Administrator mit der MMC „Active Directory-Benutzer und -Computer“ oder
„Active Directory-Domänen und -Vertrauensstellungen“ verbunden ist, zum Zeitpunkt des Heraufstufens
verbindet sich der DC mit dem PDC-Emulator.
Zum Heraufstufen des Gesamtstrukturfunktionsmodus werden Organisations-Admin Rechte benötigt.
Dieser Vorgang wird vom Schema-Master durchgeführt. Auch hier ist die Durchführung die gleiche,
wie beim Heraufstufen der Domäne. Falls der DC mit dem der Administrator nicht die Rolle des
Schemamasters innehat, verbindet sich der DC mit diesem, der dann die Gesamtstruktur herauf stuft.
Welche Vorteile in Bezug auf Funktionen und Sicherheit die einzelnen Funktionsebenen mit sich bringen,
wird auf den folgenden Seiten beschrieben:
Understanding AD DS Functional Levels
How to raise domain and forest functional levels in Windows Server 2003
Domain and forest functionality
How Active Directory Functional Levels Work
Den Domänen- bzw. Gesamtstrukturfunktionsmodus kann man während dem Betrieb umstellen und es ist auch kein Neustart notwendig!
Mit wenigen Mausklicks wird die Domäne bzw. Gesamtstruktur umgestellt. Bei dem Aktualisierungsprozess wird einiges an Netzwerkverkehr in der
Domäne bzw. Gesamtstruktur erzeugt, daher sollte darauf geachtet werden die Heraufstufung nicht im Hochbetrieb durchzuführen.
Bestehende Vertrauensstellungen, sei es zu Windows NT, Windows 2000, Windows Server 2003 oder Windows Server 2008
sind davon nicht betroffen bzw. haben mit dieser Umstellung kein Problem und funktionieren weiterhin.
Über die MMCs lässt sich das Heraufstufen des Domänenfunktionsmodus entweder über das Snap-In
„Active Directory-Benutzer und -Computer“ (dsa.msc) oder „Active Directory-Domänen und -Vertrauensstellungen“ (domain.msc)
durchführen, wobei die Gesamtstruktur ausschließlich im Snap-In „Active Directory-Domänen und -Vertrauensstellung“ heraufgestuft
werden kann. Mit einem Rechtsklick auf den FQDN steht in der jeweiligen MMC die Option Domänenfunktionsebene heraufstufen…
zur Verfügung. Zum Heraufstufen der Gesamtstruktur muss in der MMC domain.msc mit einem Rechtsklick auf den Eintrag
Active Directory-Domänen und -Vertrauensstellung die Option Gesamtstrukturfunktionsebene heraufstufen… ausgewählt werden.
Danach können jeweils die zur Verfügung stehenden Ebenen eingestellt werden.
Beide Ebenen lassen sich ebenfalls durch bearbeiten (mit LDP.exe oder ADSIEdit.msc) des Attributs msDS-Behavior-Version heraufstufen.
Für den Gesamtstrukturfunktionsmodus ist im Attribut msDS-Behavior-Version, das sich in den Eigenschaften des Containers
<CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> befindet, der entsprechende Wert einzutragen.
Für den Domänenfunktionsmodus findet man das Attribut msDS-Behavior-Version in den Eigenschaften des Containers <DC=Domäne,DC=TLD>.
Folgende Werte können im Attribut msDS-Behavior-Version eingetragen werden:
0 = Domänenfunktionsebene: Windows 2000 gemischt und Windows 2000 pur
0 = Gesamtstrukturfunktionsebene: Windows 2000
1 = Domänenfunktionsebene: Windows Server 2003 Interim
1 = Gesamtstrukturfunktionsebene: Windows Server 2003 Interim
2 = Domänenfunktionsebene: Windows Server 2003
2 = Gesamtstrukturfunktionsebene: Windows Server 2003
3 = Domänenfunktionsebene: Windows Server 2008
3 = Gesamtstrukturfunktionsebene: Windows Server 2008
4 = Domänenfunktionsebene: Windows Server 2008 R2
4 = Gesamtstrukturfunktionsebene: Windows Server 2008 R2
Im Übrigen ist durch das bearbeiten des Attributs msDS-Behavior-Version dies die einzige Möglichkeit, die Gesamtstrukturfunktionsebene
„Windows Server 2003 Interim“ zu wählen, wenn kein Inplace-Update von Windows NT durchgeführt wurde. Findet kein Inplace-Update
von Windows NT statt, steht dieser Modus nicht zur Verfügung.
Es gibt die folgenden Domänenfunktionsebenen:
Windows 2000 gemischt
Dieser Modus existiert in Windows 2000 und Windows Server 2003 Domänen.
Es können NT-BDCs, Windows 2000 DCs und Windows Server 2003 DCs in diesem Modus bestehen.
Windows 2000 pur
Diese Ebene besteht in Windows 2000, Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2 Domänen.
Darin können Windows 2000, Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2 DCs existieren.
Windows Server 2003 Interim
Die Auswahl des Modus „Windows Server 2003 Interim“ steht ausschließlich nur zur Auswahl, wenn von einer NT-Domäne
per Inplace-Update auf Windows Server 2003 aktualisiert wird. In diesem Modus können NT-BDCs sowie Windows Server 2003 DCs existieren.
Windows Server 2003
Dieser native Modus besteht in Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 Domänen.
Neben Windows Server 2003 DCs können auch Windows Server 2008 sowie Windows Server 2008 R2 DCs in der Domäne betrieben werden.
Windows Server 2008
In diesem Domänenfunktionsmodus können sich Windows Server 2008 DCs und Windows Server 2008 R2 DCs befinden.
Windows Server 2008 R2
Dieser Domänenfunktionsmodus kann lediglich Windows Server 2008 R2 DCs beinhalten!
Als Gesamtstrukturfunktionsebenen gibt es:
Windows 2000
In dieser Gesamtstrukturebene können die folgenden Domänenfunktionsebenen existieren:
- Windows 2000 gemischt
- Windows 2000 pur
- Windows Server 2003
- Windows Server 2008
- Windows Server 2008 R2
Windows Server 2003 Interim
Hier können Windows Server 2003 Interim, Windows Server 2003 und Windows Server 2008 Domänen
(im Domänenfunktionsmodus Windows Server 2003) bestehen.
Windows Server 2003
Dieser Modus kann Domänen im Domänenfunktionsmodus Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 beinhalten.
Windows Server 2008
Dieser Gesamtstrukturmodus legt fest, dass ausschließlich Windows Server 2008 und Windows Server 2008 R2 Domänen in der Gesamtstruktur bestehen können.
Windows Server 2008 R2
In diesem Gesamtstrukturfunktionsmodus können ausschließlich Windows Server 2008 R2 Domänen in der Gesamtstruktur bestehen.
Weitere Informationen:
Den Domänen- sowie Gesamtstrukturfunktionsmodus mit der AD-Powershell hochstufen
Den Domänen- und Gesamtstrukturfunktionsmodus zurückstufen
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Der Read-Only Domänencontroller ist ein DC der für Standorte konzipiert wurde, die keine physikalische Sicherheit dem DC und somit
auch der Domäne bzw. Gesamtstruktur bieten können. Wie es im Namen bereits zu lesen ist, handelt es sich dabei um einen DC der
ausschließlich nur eine Leseberechtigung auf die Active Directory-Daten hat. Falls Änderungen im Active Directory durchgeführt werden sollen,
leitet der RODC diesen Vorgang auf einen beschreibbaren DC weiter. Das gilt auch für Aktualisierungen im DNS.
Zusätzlich stellt die einseitige (unidirektionale) Replikation eine weitere Sicherheitsfunktion dar. Auf dem RODC findet nur eine
eingehende (Inbound)-Replikation statt. Es wird nichts vom RODC zu einem beschreibbaren DC repliziert. Die einseitige Replikation
wird für die Active Directory-Domain Services und für die DFS-Replikation des SYSVOL-Verzeichnisses angewendet.
Weitere Details zum RODC werden in diesem Artikel erläutert:
Read-Only Domain Controller (RODC)
Die Voraussetzungen um den ersten RODC in der Domäne zu installieren
-
Der Modus für die Gesamtstruktur muss sich mindestens auf Windows Server 2003 oder höher befinden,
damit die Linked Value Replikation (LVR) zur Verfügung steht.
-
Der RODC kann sich die Domänenpartition ausschließlich von einem beschreibbaren Windows Server 2008
oder Windows Server 2008 R2 Domänencontroller replizieren. Daher muss sich bereits ein beschreibbarer
Windows Server 2008/2008 R2/Core/Core R2 Domänencontroller in der Domäne befinden. Wenn das nicht der Fall wäre,
würde die Option zum erstellen eines RODC an entsprechender Stelle nicht zur Verfügung stehen.
-
Das Active Directory Preparation Tool (ADPREP) muss mit dem Parameter /RODCPREP ausgeführt worden sein.
Dabei werden die Berechtigungen (Security Descriptor, SD) von allen DNS-Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) in der Gesamtstruktur aktualisiert. Der Befehl muss mit Organisations-Administrator Rechten durchgeführt werden und kann auf irgendeinem DC ausgeführt werden. Dieser DC muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen von ADPREP /Rodcprep werden die einzelnen Infrastrukturmaster der Domänen kontaktiert, um die Berechtigungen der Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren.
Error message when you run the "Adprep /rodcprep" command in Windows Server 2008: "Adprep could not contact a replica for partition DC=DomainDnsZones,DC=Contoso,DC=com"
-
Wird für die bereitgestellte Installation zuerst das RODC-Computerkonto in der OU Domain Controllers im AD DS erstellt,
darf der zukünftige RODC nicht bereits Mitglied der Domäne sein.
Die Installation eines RODC auf einem Windows Server 2008 (Vollinstallation) durch den DCPROMO-Assistenten
Der Read-Only Domänencontroller kann auf mehrere Varianten bereitgestellt werden.
Die eine Variante wäre die Installation des RODCs durch das Ausführen des DCPROMO-Assistenten. Dies kann von einem
Domänen- bzw. Organisations-Administrator durchgeführt werden. Dabei kann der Server entweder ein standalone- oder
Mitgliedsserver sein. Nach der Betriebssysteminstallation kann der Administrator direkt das DCPROMO aufrufen und somit
den Server zum RODC stufen. Die Installation gestaltet sich nicht sonderlich anders als die Installation eines beschreibbaren DCs.
Es ist lediglich darauf zu achten, dass beim ausführen des DCPROMO-Assistenten die Option
Schreibgeschützter Domänencontroller (RODC) auf der Seite der Domänencontrolleroptionen ausgewählt wird.
Empfehlenswert wäre es, nach dem Aufruf von DCPROMO die Option Installation im erweiterten Modus verwenden auszuwählen.
Ich empfehle diese Option bei jeder DC-Installation zu aktivieren. Erst durch den erweiterten Modus erscheint die zusätzliche
Auswahl (bei einer RODC-Installation) Richtlinie für Kennwortreplikation angeben (Password Replication Policy, kurz PRP),
in der festgelegt werden kann welche Kennwörter auf den RODC repliziert werden dürfen und welche verwehrt bleiben.
Die Replikation der Kennwörter von einzelnen Benutzern, Gruppenmitgliedern oder Computern können auf dem RODC zugelassen
bzw. verwehrt werden. Dabei bleiben standardmäßig die Kennwörter administrativer Konten dem RODC verwehrt.
Wenn dabei ein Benutzerkonto in der abgelehnten- sowie zulässigen RODC-Kennwortreplikationsgruppe Mitglied ist,
so hat die abgelehnte Gruppe Vorrang!
Die Konfiguration der Kennwort-Replikation kann natürlich auch im Nachhinein jederzeit geändert und muss nicht unbedingt während
der Installation festgelegt werden. Weitere Optionen die erst mit aktivieren des erweiterten Installationsmodus erscheinen, wäre die
IFM-Option und die Auswahl eines Quelldomänencontrollers mit dem die Replikation über das Netzwerk durchgeführt werden soll.
Die Installation eines RODC auf einem Windows Server 2008 Core
Der RODC kann ebenfalls auf einer Installation des Windows Server Core bereitgestellt werden. Da das Heraufstufen zu einem
RO-/DC auf einem Windows Server Core nicht wie gewohnt über die GUI des DCPROMO-Assistenten durchgeführt werden kann,
ist der Administrator gezwungen die Installation, entweder durch die einzelne Eingabe der Parameter in der Kommandozeile
(DCPROMO /unattend /ReplicaOrNewDomain=ReadOnlyReplica…) oder mit einer Antwortdatei durchzuführen.
Eine Beispiel-Antwortdatei zum Heraufstufen eines RODCs befindet sich am Ende dieses Artikels:
Windows Server 2008 Core
Die bereitgestellte Installation eines RODC
Eine andere Variante wäre die Installation eines RODCs in zwei Schritten durchzuführen. Dabei erstellt ein Domänen- bzw.
Organisations-Administrator im ersten Schritt zuerst das RODC-Computerkonto im Active Directory und bekommt dabei die Möglichkeit,
die vor Ort Installation sowie die Verwaltung des RODCs entweder von einem Domänen-Administrator durchführen zu lassen
oder an einen Benutzer oder besser einer Benutzergruppe dieses Privileg zu delegieren. Zur leichteren Administration sollte
eine Benutzergruppe angegeben werden. Die Delegierung an dieser Stelle hat den positiven Nebeneffekt, dass der Benutzer
oder die Gruppe denen dieses Recht delegiert wurde, gleichzeitig auch der lokale Administrator des Systems ist. Die Änderungen
am System, sei es Treiberaktualisierungen, Softwareinstallationen oder Hardwaretausch kann von nun an von einem normalen Benutzer
durchgeführt werden, der keine Rechte auf das Active Directory hat. In den vorherigen Server-Versionen stellte genau dieses
Szenario in verteilten Umgebungen oftmals ein Problem dar. Im zweiten Schritt wird durch das Ausführen von DCPROMO auf dem
Server die RODC-Installation endgültig abgeschlossen.
Die Vorgehensweise für die bereitgestellte Variante wäre folgende
-
In der MMC Active Directory-Benutzer und -Computer ist auf einem beschreibbaren Windows Server 2008 Domänencontroller,
mit einem Rechtsklick auf der OU Domain Controllers die Option Konto für schreibgeschützten Domänencontroller vorbereiten… auszuwählen.
-
Auf der Willkommensseite gilt es die Option Installation im erweiterten Modus verwenden zu aktivieren.
-
-
Als nächstes werden die Anmeldeinformationen eines Domänen- oder Organisations-Administrators benötigt. Wenn man auf dem
System, auf der man das RODC-Computerkonto erstellt als Domänen-Administrator angemeldet ist, reichen die aktuellen
Anmeldeinformationen aus und es müssen keine alternativen Anmeldeinformationen eingegeben werden. Ansonsten werden
alternative Anmeldeinformationen benötigt. Wenn die angegebenen Anmeldeinformationen nicht über die benötigten Rechte verfügen,
folgt eine Warnung mit dem Hinweis, dass das angegebene Benutzerkonto in keines der genannten Gruppen Mitglied ist. Es ist zwar
trotzdem möglich mit dem Assistenten fortzufahren, aber spätestens nach der Zusammenfassung erscheint erneut der Hinweis,
dass die eingegeben Anmeldeinformationen nicht ausreichen. Aber auch hier bekommt man dann die Option,
ein berechtigtes Benutzerkonto einzugeben.
-
Auf der nächsten Seite muss der Computername des zukünftigen RODCs eingetragen werden. Des Weiteren wird der Hinweis angezeigt,
dass der Computername an dieser Stelle vergeben werden muss. Weiterhin wird darauf hingewiesen, dass der Server erst mit Ausführen
von DCPROMO zur Domäne hinzugefügt werden darf. Falls der Server zu diesem Zeitpunkt bereits Mitglied der Domäne wäre,
würde an dieser Stelle eine Fehlermeldung erscheinen:
-
Nun muss der Standort ausgewählt werden, an dem der RODC eingesetzt werden soll.
-
Im darauffolgenden Schritt ist die Auswahl der zusätzlichen Domänencontrolleroptionen zu treffen. Es stehen insgesamt drei Optionen
zur Auswahl, wobei die letzte Option Schreibgeschützter Domänencontroller (RODC) aktiviert und ausgegraut ist. Die beiden anderen
Optionen wären DNS-Server und Globaler Katalog (was vorteilhaft wäre diese aktiviert zu lassen).
-
An dem nächsten Punkt angelangt, kann man die Richtlinie für die Kennwortreplikation bearbeiten. Die Kennwortreplikation beeinflusst
das Anmeldeverhalten eines Benutzers bei nicht erreichen eines beschreibbaren DCs.
Der genaue Vorgang wird auf diesen Seiten erklärt:
Appendix B: How the Authentication Process Works with RODCs
Password Replication Policy
Wichtig an dieser Stelle wäre zu erwähnen, möchte man das der RODC einen Benutzer (oder Dienstkonto) eigenständig authentifiziert,
ohne das ein beschreibbarer DC kontaktiert werden soll (z.B. wenn die WAN-Verbindung unterbrochen ist), so muss neben dem Kennwort
des Benutzerobjekts noch das Computerkontokennwort an dem sich der Benutzer anmeldet, bereits auf den RODC repliziert worden sein.
Natürlich müssen die betroffenen Benutzer- sowie Computerkonten vorher in der Richtlinie für die Kennwortreplikation zugelassen werden.
Falls das Kennwort eines Benutzers (und/oder Computerkontos, an dem sich der Benutzer anmeldet) nicht auf den RODC repliziert wurde
und es entsteht eine WAN-Störung, kann sich der Benutzer zu diesem Zeitpunkt lediglich mit seinen zwischengespeicherten
Benutzerinformationen (cached Credentials) anmelden. Das kann der Benutzer wiederum nur, wenn er sich vorher einmal von
dem Computer aus, erfolgreich an der Domäne authentifiziert hat.
Der RODC trägt sich bekanntermaßen als Key Distribution Center (KDC) im Active Directory für seinen Standort ein und somit kann der
RODC dem Client das Ticket-Granting Ticket (TGT) ausstellen.
Die Replikation der Kennwörter lässt sich manuell anstoßen. Zum einen ist das mit Repadmin möglich. Der Befehl dazu lautet:
Repadmin /Rodcpwdrepl <RODC*> <beschreibbarer DC> <DN des Benutzerkontos> <DN des Clients>
Repadmin /rodcpwdrepl
Zum anderen lässt sich die Replikation der Kennwörter auch über die grafische Oberfläche realisieren. Dazu gilt es in der MMC
Active Directory-Benutzer und -Computer die Eigenschaften des RODC-Computerkontos zu öffnen. Dort im Reiter
Kennwortreplikationsrichtlinie ist die Option Erweitert auszuwählen. In der erweiterten Kennwortreplikation hat man nun die
Möglichkeit über die Auswahl von Kennwörter auffüllen… die entsprechenden Kennwörter sofort zu replizieren.
-
Der Assistent fragt als nächstes nach einem Benutzer oder einer Gruppe, die das Recht delegiert bekommen sollen den RODC
fertig zu installieren (durch Ausführen von DCPROMO). Zudem wird darauf hingewiesen das die angegeben Konten über lokale
Administratorberechtigungen verfügen. Erfolgt an dieser Stelle keine Eingabe, so kann die Installation des RODCs ausschließlich
von einem Domänen- oder Organisations-Administrator abgeschlossen werden.
Erneut der Hinweis; Die hier angegebenen Konten bekommen keine weiteren Rechte auf das AD!
-
Es folgt die Zusammenfassung in der die gewählten Einstellungen überprüft werden können.
-
Anschließend wird mit Fertig Stellen der Vorgang zum erstellen des RODC-Computerkontos abgeschlossen.
Zum Fertigstellen der RODC-Installation ist es als letzten Schritt notwendig, an dem zukünftigen RODC den DCPROMO-Assistenten auszuführen.
Die Vorgehensweise wäre folgende:
-
Mit dem Befehl Dcpromo /UseExistingAccount:Attach gilt es unter Start - Ausführen den DCPROMO-Assistenten aufzurufen.
-
Falls man die Installation mit Hilfe einer Install from Media (IFM) -Sicherung durchführen möchte, sollte die Option
Installation im erweiterten Modus verwenden aktiviert werden. Auch wenn man explizit einen DC auswählen möchte
von dem die Replikation erfolgen soll, ist der erweiterte Modus zu aktivieren.
-
Im nächsten Schritt muss die Domäne angegeben werden zu der der RODC hinzugefügt werden soll. Zusätzlich sind die
alternativen Benutzerinformationen eines Benutzers anzugeben, der beim erstellen des RODC-Computerkontos das Recht der
Installation delegiert bekommen hat (siehe oben Punkt 9). Natürlich kann hier auch der Domänen-Administrator angegeben werden.
-
Danach muss das bereits erstellte RODC-Computerkonto ausgewählt werden.
-
Wurde der erweiterte Modus auf der Willkommensseite ausgewählt, kann an dieser Stelle eine Sicherung angegeben werden.
-
Falls keine Sicherung angegeben wird, kann als nächstes ein Quelldomänencontroller ausgewählt werden,
von dem aus die Replikation ausgeführt wird.
-
Auf der nächsten Seite kann der Pfad zur Active Directory-Datenbank, den Protokolldateien und dem SYSVOL-Verzeichnis konfiguriert werden.
-
Dann muss ein Kennwort für den Wiederherstellungsmodus für Verzeichnisdienste vergeben werden.
-
Zum Schluss erfolgt die Zusammenfassung der Einstellungen die vorgenommen wurden, bevor es dann mit der Installation beginnt.
Die Verwaltung des RODC
Die Information wer den RODC lokal administrieren darf wird im Active Directory, genauer, im Attribut managedBy das sich im RODC-Computerkonto
befindet gespeichert. Ist es notwendig die lokale Verwaltung des RODCs an einen anderen Benutzer bzw. Benutzergruppe zu delegieren, so kann
diese Einstellung in den Eigenschaften des RODC-Computerkontos, im Reiter Verwaltet von vorgenommen werden.
Oder es wird im Reiter Attribut-Editor der Distinguished Name des Benutzers (oder der Benutzergruppe) direkt im
Attribut managedBy eingetragen, der zukünftig den RODC verwalten soll.
Zusätzlich wird in der Registry auf dem RODC im folgenden Pfad:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RODCROLES
im Schlüssel RepairAdmin die SID des Benutzers/der Benutzergruppe gespeichert, die im Attribut managedBy eingetragen wurde.
Eine andere Variante einen lokalen Administrator zu definieren wäre über die beiden Kommandozeilentools DSMGMT.exe oder NTDSUTIL.exe.
Dadurch können auch feinere Rechte gesetzt werden, in dem z.B. der Domänen-Benutzer in die Gruppe der Sicherungs-Operatoren
oder Server-Operatoren auf dem RODC hinzugefügt wird.
Dieses erreicht man durch folgende Vorgehensweise:
- Start - Ausführen - DSMGMT.exe oder NTDSUTIL.exe (die Eingabe der folgenden Befehle gelten sowohl für DSMGMT als auch für NTDSUTIL)
- Local Roles
- Add <DOMÄNE>\<Domänen-Benutzer> Server-Operatoren
Mit Show Role Server-Operatoren können die Mitglieder dieser Gruppe angezeigt werden.
Wenn ein Benutzer über diese Methode zu einer Gruppe hinzugefügt wurde, wird im o.g. Registry-Pfad ein weiterer
Schlüssel erstellt, das als Wert die SID des Benutzers enthält. Der Schlüssel trägt als Namen das letzte Oktett der Well-Known SID von der
entsprechenden Gruppe, in der der Benutzer hinzugefügt wurde. Wird z.B. ein Benutzer zu der Builtin-Gruppe Server-Operatoren hinzugefügt,
so lautet der Name des erstellten Schlüssels 549. Wird hingegen der Benutzer zu der Builtin-Gruppe Konten-Operatoren hinzugefügt,
so trägt der Schlüssel den Namen 548.
Well-known security identifiers in Windows operating systems
Wird der Benutzer mit dem Befehl Remove <DOMÄNE>\<Domänen-Benutzer> <Gruppe>
aus der Gruppe entfernt, bleibt der erstellte Schlüssel zwar bestehen, jedoch wird der als Wert eingetragene SID entfernt.
Weitere Informationen:
Read-Only Domain Controllers and Account Lockouts
Performing a Staged RODC Installation
Applications That Are Known to Work with RODCs
Als Microsoft mit Windows 2000 das Active Directory in der ersten Version einführte, waren damals die Ansprüche an dem
Verzeichnisdienst andere als heute. Insbesondere was die Active Directory-Replikation oder das Replikationsaufkommen angeht,
hatte man seinerzeit noch eine andere (geringere) Vorstellung darüber. Es kristallisierte sich heraus, dass sich dieses Verhalten
noch verbessern lässt. Denn sowohl unter Windows 2000 als auch Windows Server 2003 (abhängig vom Gesamtstrukturfunktionsmodus)
werden sämtliche Werte eines mehrwertigen (multi-valued) Attributs auch dann repliziert, wenn lediglich ein einziger Wert geändert wurde.
In einem mehrwertigen bzw. multi-valued Attribut werden, wie es der Name bereits verrät, mehrere Werte in einem Attribut gespeichert.
In Windows 2000 findet dabei ausschließlich eine Replikation auf Attribut-Ebene und nicht auf der Wert-Ebene (per Value) statt.
Die Replikation auf Attribut-Ebene hat den Nachteil, dass zum einen ein dadurch überflüssig hohes Replikationsaufkommen
entsteht und zum anderen, dass Risiko eines Replikationskonflikts sich erhöht. Bekanntermaßen findet im Active Directory
eine Multimaster-Replikation statt was soviel bedeutet, dass auf jedem Domänencontroller zur gleichen Zeit eine Änderung
durchgeführt werden kann, die dann durch die AD-Replikation auf die anderen DCs repliziert wird.
Wenn nun bei diesem Replikationsverhalten zur gleichen Zeit auf verschiedenen DCs einer Domäne, der Wert des gleichen
Attributs verändert wird, würde ein Replikationskonflikt entstehen und somit eines der Änderungen verworfen werden.
Wie sich das Active Directory im Falle eines Replikationskonflikts verhält, wird im folgenden Artikel erläutert:
Active Directory-Replikationskonflikt
Das Verhalten trifft natürlich nur dann zu, wenn sich mindestens zwei Domänencontroller in der Domäne befinden.
Ansonsten würde keine Replikation stattfinden .
Das oft zitierte Beispiel das man zu diesem Thema liest, wären Gruppenmitgliedschaften, was nachfolgend noch
genauer erläutert wird. Das Beispiel mit den Gruppenmitgliedschaften bietet sich deshalb an, da es sich zum einen
um ein mehrwertiges Attribut (Member) handelt und zum anderen in der Praxis darin viele Werte gespeichert werden.
Denn in größeren Unternehmen stößt man genau an diesem Punkt auf Probleme.
Als Beispiel nehmen wir an, es existiert eine Benutzergruppe mit 4.950 Benutzern. Das mehrwertige Attribut Member des
Gruppenobjekts enthält somit 4.950 Einträge. Im Attribut Member sind die Distinguished Names der einzelnen Mitglieder aufgelistet.
Das können Einträge von Benutzern, anderen Gruppen oder Computern sein. Im Benutzerobjekt hingegen befinden sich die
Einträge der Gruppenmitgliedschaften im mehrwertigen Attribut MemberOf. Wenn nun dieser Benutzergruppe ein weiterer Benutzer
hinzugefügt wird, werden alle 4.951 Einträge im Attribut Member auf die anderen DCs repliziert und nicht nur der einzig
hinzugekommene Eintrag. Schließlich wird auf Attribut- und nicht auf der Wert-Ebene repliziert.
In einem anderen Beispiel gehen wir davon aus, dass eine Benutzergruppe simultan auf zwei DCs verändert wird.
Es existiert eine GruppeA mit den Benutzern: User1 und User2. Administrator1 fügt der GruppeA einen neuen Benutzer User5
hinzu und zeitgleich fügt Administrator2 auf einem anderen DC User9 hinzu. Somit kommt es zu einem Replikationskonflikt,
wobei eines der Änderungen verworfen wird.
Das Member- und MemberOf-Attribut stellen zusammen ein Linked-Attribut (verknüpftes Attribut) Paar dar.
Linked-Attribute stellen eine besondere Beziehung im Active Directory zueinander dar, denn sie bestehen aus zwei Attributen,
dem Forward- sowie Back-Link. Verändert der Administrator im Forward-Link einen Wert, aktualisiert das Active Directory
automatisch den Back-Link. Das beinhaltet natürlich auch das Löschen von Werten.
Das Member-Attribut im Gruppenobjekt ist ein Forward-Link und das Attribut MemberOf eines Benutzerobjekts stellt den Back-Link dar.
Back-Links werden von jedem DC selbst verwaltet und können auch nicht vom Administrator bearbeitet werden. Es ist ein sogenanntes
system-only Attribut und wird auch nicht auf andere DCs repliziert. Ein Back-Link und sein Wert werden zum Zeitpunkt der Abfrage generiert.
Solche Attribute tragen den Namen "constructed". Der Administrator kann nur den Forward-Link, in dem Fall dass
Member-Attribut eines Gruppenobjekts das auf andere DCs repliziert wird bearbeiten.
Neben dem unnötigen Replikationsaufkommen unter Windows 2000 kommt noch hinzu, dass eine Benutzergruppe mit mehr
als 5.000 Mitgliedern nicht unterstützt wird. Diese Grenze von 5.000 kommt daher, weil eine Aktualisierung im Active Directory
in einem einzigen Vorgang durchgeführt werden muss und eben dabei ca. 5.000 Werte aktualisiert werden können.
Anders ausgedrückt, die Active Directory Jet Database Engine kann lediglich mit einer bestimmten Anzahl an Werten
während eines Schreibvorgangs bzw. eines Replikationszyklus umgehen.
In größeren Umgebungen kann aber diese Grenze von 5.000 Mitgliedern pro Benutzergruppe ein Problem darstellen.
Der Weg diese Barriere zu umgehen wäre mit Gruppenverschachtelungen zu arbeiten.
Daraufhin wurde im Windows Server 2003 dieses Verhalten verbessert. Microsoft hat die sogenannte Linked-Value Replikation
(zu Deutsch, verknüpfte Wertreplikation) eingeführt. Mit dieser Funktion wird nur noch der geänderte Wert eines
mehrwertigen Attributs repliziert, aber nicht mehr die unveränderten Werte. Die AD-Replikation findet nun auf der Wert-Ebene statt.
Diese neue Funktion trägt sowohl zur effizienteren Replikation, als auch der Konfliktvermeidung eines mehrwertigen Attributs bei.
Bei der LVR-Replikation werden bei einem Objekt zuerst die nicht verknüpften Attribute (non-Linked Attributs) und anschließend
die verknüpften Attribute (Linked Attributes) repliziert.
Im oben genannten ersten Beispiel mit den 4951 Mitgliedern einer Benutzergruppe, würde durch die LVR-Replikation lediglich
der geänderte Wert (der hinzugekommene Benutzer) repliziert werden und nicht mehr alle Werte. Auch unter Windows NT
würde der PDC lediglich den veränderten Wert zum BDC übertragen.
Im zweiten Beispiel wären die Benutzer: User1, User2, User5 und User9 nach der LVR-Replikation in der GruppeA.
Die Linked Value Replikation ist aber erst verfügbar, wenn sich der Gesamtstrukturfunktionsmodus auf Windows Server 2003 Interim
oder Windows Server 2003 befindet. Nur dann kommt die verbesserte Replikationstechnik zum Einsatz.
Somit wird auch die künstliche Grenze von 5.000 Mitgliedern pro Benutzergruppe aufgehoben.
Eine Gruppe im Gesamtstrukturfunktionsmodus Windows Server 2003 kann im sieben stelligen Bereich Mitglieder enthalten.
Allerdings ist die unterstützte Anzahl der Änderungen die innerhalb eines Schreibvorgangs durchgeführt werden können 5.000.
Denn wenn z.B. per Skript oder Management-Tool eine Gruppe mit weit mehr als 5.000 Mitgliedern erstellt wird, läuft man Gefahr
einen „out of version store“-Fehler zu erhalten. Daher sollte beim automatisierten einrichten von Gruppen darauf geachtet werden,
diesen Wert nicht zu überschreiten.
Als Bestätigung, dass nach dem Heraufstufen der Gesamtstruktur auf Windows Server 2003 nun die LVR-Replikation eingesetzt wird,
findet man im Verzeichnisdienstprotokoll aller Domänencontroller in der Gesamtstruktur die EventID 1695.
Leider profitieren aber die bereits bestehenden Werte in einem mehrwertigen Attribut nach dem Heraufstufen der Gesamtstruktur
nicht von der LVR-Replikation. Lediglich neu hinzugekommene Werte in diesem Modus nutzen den Vorteil der LVR-Replikation.
Überprüfen lässt sich das mit dem Tool Repadmin, das sich in den Windows Support Tools befindet.
Gibt man in einer Kommandozeile den folgenden Befehl ein: Repadmin /showobjmeta <DC-Name> <DN der Gruppe>
erscheint eine Ausgabe die wie folgt aussieht:
Entscheidend dabei ist die Spalte Type. Der Eintrag LEGACY zeigt, dass dieser Wert vor dem Heraufstufen der Gesamtstruktur bereits existierte.
Somit profitiert dieser Wert nicht von der LVR-Replikation.
Im nächsten Schritt wird der bestehenden Gruppe ein weiterer Benutzer hinzugefügt.
Es ist zu erkennen, dass in der Spalte Type bei User11 der Status sich auf PRESENT befindet. Da dieser Eintrag im
Gesamtstrukturfunktionsmodus Windows Server 2003 hinzugefügt wurde, profitiert der Wert auch von der LVR-Replikation.
Ein weiterer Status wäre ABSENT. Dieser Eintrag wird angezeigt, wenn ein Mitglied im Gesamtstrukturfunktionsmodus
Windows Server 2003 zu einer Gruppe hinzugefügt und entfernt wurde.
Wenn ein Benutzerobjekt aus dem Active Directory gelöscht wird, ist die Wiederherstellung samt Gruppenmitgliedschaften
eine heikle Angelegenheit. Wenn es sich aber um eine Windows Server 2003 SP1 Umgebung handelt, erleichtert einem das
NTDSUTIL bei der Wiederherstellung der Informationen von Gruppenmitgliedschaften das Leben. Denn die Wiederherstellung
von Gruppenmitgliedschaften basiert auf LDAP Data Interchange Format (LDIF) Dateien. Der genaue Vorgang wird im folgenden Artikel beschrieben.
How to restore deleted user accounts and their group memberships in Active Directory
Damit alle Werte eines mehrwertigen Attributs von der LVR-Replikation profitieren, ist es notwendig alle Werte neu zu schreiben.
Dazu müssen die Werte zuerst entfernt und anschließend erneut hinzugefügt werden.
Neben skriptbasierten Lösungen kann einem das LDIFDE behilflich sein oder aber die im Windows Server 2003
enthaltenen Tools DSGET und DSMOD. Mit diesem Befehl werden alle Werte neu geschrieben:
Dsget group <DN der Gruppe> -members | Dsmod group <DN der Gruppe> -chmbr
Active Directory - Abfrage
Anschließend werden mit der Abfrage von Repadmin, alle Werte im Attribut Member mit dem Status PRESENT angezeigt.
Weitere Informationen:
Verknüpfte Attribute
How to raise domain and forest functional levels in Windows Server 2003
Group Objects (Windows)
Microsoft Windows 2000 Scripting Guide - Modifying Multivalued Attributes
Enumerating Groups That Contain Many Members (Windows)
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|