Microsoft führt mit dem Windows Server 2008 eine neue Installationsart ein.
Man könnte sagen, dass es ein abgespeckter Server ist. In dieser Installationsart steht z.B. weder der Windows Explorer,
noch eine GUI-Shell zur Verfügung. Bei dieser Variante der Installation, stehen lediglich einige wenige Serverrollen zur Verfügung.
Die Rede ist vom Windows Server Core. Die möglichen Rollen die auf einem Windows Server Core installiert werden können,
wären unter anderem: AD DS, AD LDS, DHCP, DNS, Hyper-V, Datei- Druck- sowie Webserver.
Welche Rollen oder Funktionen noch auf einem Server Core unterstützt werden, zeigt diese Seite:
Server Core Installation of Windows Server 2008
Dem Administrator steht nach der Betriebssysteminstallation lediglich eine Kommandozeile (CMD) zur Verfügung.
Für die Administratoren die sich schwer von der Maus trennen können (und wollen), hat Microsoft ebenfalls vorgesorgt.
Es besteht die Möglichkeit, sich remote über die MMCs auf einen Server Core zu verbinden, um diesen dann über die Snap-Ins zu administrieren.
Neben der Fernwartung durch die MMCs, lässt sich der Server Core mit den folgenden Punkten administrieren:
Darüber hinaus werden die Microsoft Operations Manager- sowie Systems Management Server-Agents, ebenso auf dem Server Core unterstützt.
Demzufolge das weniger Dienste und Applikationen auf einem Server Core laufen, reduziert sich die Verwaltung sowie Wartung des Servers.
Die Anzahl der zu installierenden Patches/SPs reduziert sich dabei ebenfalls, denn es gilt weniger Dienste abzusichern.
Der Server Core benötigt auch viel weniger Festplattenkapazität und ist schneller im Startverhalten als eine Vollinstallation.
Dadurch das weniger Funktionen bereitgestellt werden können, bietet der Server Core eine geringe Angriffsfläche an.
Folglich ist das Aufstellen eines solchen Servers z.B. in Umgebungen die eine hohe Sicherheitsanforderung haben, von Interesse.
Ein anderes Einsatzszenario wären Standorte. Dort wird oftmals ebenfalls ein Server vor Ort benötigt, sei es nun einen
Domänencontroller oder Mitgliedsserver, der aber dafür weniger Dienste als ein Server in der Zentrale bereitstellen muss.
Zusätzlich kommt noch hinzu, dass vor Ort in den Standorten meistens weniger IT Know-How als in der Zentrale zur Verfügung steht.
Auch in diesem Fall, würde sich das Aufstellen eines Server Cores vor Ort anbieten.
Falls vor Ort ein DC gewünscht ist, der nicht die gleiche physikalische Sicherheit wie ein DC in der Zentrale genießt,
würde sich eher der Read-Only Domain Controller (RODC) anbieten. Eine weitere Empfehlung wäre, Bitlocker einzusetzen.
Der Windows Server Core wurde in erster Linie für Umgebungen mit mehreren Servern entwickelt.
Der Großteil der Konfiguration des Server Cores, erfolgt mit dem Kommandozeilentool NETSH.
Anzeigen sowie installieren der Rollen bzw. optionalen Features
Mit Oclist werden nicht nur die zur Verfügung stehenden Serverrollen sowie die
optionalen Features angezeigt, sondern natürlich auch die bereits installierten.
Mit Ocsetup können die zur Verfügung stehenden Rollen sowie Features installiert- oder deinstalliert werden.
Zum installieren lautet die Syntax:
start /w ocsetup <Rolle>
start /w ocsetup <Feature>
Zum deinstallieren lautet es:
start /w ocsetup <Rolle> /uninstall
start /w ocsetup <Feature> /uninstall
Achtung: Die Installation der einzelnen Rollen bzw. Features mit Ocsetup ist - warum auch immer - case sensitive!
Die Einschränkungen des Server Core
-
Es ist nicht möglich, auf einen Server Core von früheren Server-Version
(Windows 2000 Server oder Windows Server 2003/R2) zu aktualisieren
-
Eine Vollinstallation vom Windows Server 2008 kann nicht auf den Server Core konvertiert werden.
-
Der Server Core kann ebenfalls nicht zu einer Vollinstallation konvertiert werden.
-
Der Server muss mit der gewünschten Version neu installiert werden.
-
Die verfügbaren APIs werden ausschließlich für die Entwicklung von Monitoring sowie Management Tools supportet.
-
Es existiert keine Explorer-Shell.
-
Es ist auch kein .Net Framework verfügbar. Im Windows Server 2008 R2 sind jedoch Teile des .NET Frameworks enthalten.
-
Der Server Core ist nicht die Plattform, auf dem die Entwicklung von Applikationen stattfinden sollte.
-
Es wird nicht die Windows Powershell unterstützt. Erst ab Windows Server 2008 R2 wird die Powershell auf dem Server Core unterstützt.
-
Es existieren keine MMCs auf dem Server Core.
Die Installation des Server Core
Das lokale Administrator-Kennwort vergeben
- Nach der Betriebssysteminstallation wird man nach der Eingabe des Benutzernamens Administrator (ohne Kennwort) aufgefordert,
ein Kennwort für den lokalen Administrator, dass den lokalen Sicherheitsrichtlinien entspricht, einzugeben (z.B. Pa$$w0rd!).
- Mit Eingabe von net user administrator * kann ein neues Kennwort vergeben werden.
Die Auflösung verändern
-
Standardmäßig existiert nach der Betriebssysteminstallation eine Auflösung von 640x480.
Dies kann in der Registry wie folgt geändert werden:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\<GUID>\0000\
Der Wert im Schlüssel DefaultSettings.XResolution muss bearbeitet werden (z.B. 1280 Dezimal).
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\<GUID>\0000\
Der Wert im Schlüssel DefaultSettings.YResolution muss bearbeitet werden (z.B. 1024 Dezimal).
Unter Video existieren mehrere GUIDs. Die richtige GUID ist diejenige, die das Unterverzeichnis VolatileSettings beinhaltet.
Den Computernamen ändern
- Während der Betriebssysteminstallation wird dem Server automatisch ein Computername vergeben.
Da aber bereits in vielen Unternehmensnetzwerken eine festgelegte Namenskonvention existiert, passt der vergebene Name
sicherlich nicht in die meisten Umgebungen. In Erfahrung kann man den Computernamen mit dem Befehl
Hostname oder IPCONFIG –ALL bringen.
-
Ein neuer Computername kann mit folgendem Befehl vergeben werden:
Netdom Renamecomputer ALTERCOMPUTERNAME /Newname:NEUERCOMPUTERNAME
Die anschließende Sicherheitsfrage ist mit einem Y zu bestätigen.
Im Anschluss ist ein Neustart mit dem Befehl shutdown –r bzw. shutdown –r –t 0 fällig.
Man kann aber auch direkt beide Befehle in einem zusammenfassen.
Das ganze würde dann so aussehen:
Netdom Renamecomputer ALTERCOMPUTERNAME /Newname:NEUERCOMPUTERNAME /Force /Reboot:ZahlinSekunden
Ist der Server Core bereits ein Mitgliedsserver, so lässt sich der Computername auf diese Weise ändern:
Netdom Renamecomputer ALTERCOMPUTERNAME /NewName:NEUERCOMPUTERNAME /userd:<Domäne\Administrator> /passwordd:*
Die IPv4 Adresse eintragen
-
Bevor eine IP-Adresse eingetragen werden kann, muss sichergestellt sein, dass der Treiber für die Netzwerkkarte installiert wurde.
Wird beim Aufruf von IPCONFIG lediglich der Eintrag Windows-IP-Konfiguration angezeigt, so ist die Netzwerkkarte nicht installiert.
Es sollte der Eintrag „Ethernet-Adapter LAN-Verbindung“ auftauchen.
Mit dem folgenden Befehl:
Netsh int ipv4 set addr "LAN-Verbindung" static 192.168.178.10 255.255.255.0 192.168.178.1
wird die IPv4-Adresse 192.168.178.10, dass Subnetz 255.255.255.0 und das Gateway 192.168.178.1 vergeben.
Wichtig an dieser Stelle wäre zu erwähnen, dass der Name der LAN-Verbindung bekannt sein muss!
Diesen erfährt man mit dem Befehl Netsh int ip sh int oder durch IPCONFIG –ALL.
Denn auf einem englischen System lautet dieser: Local Area Connection.
-
Eine andere Vorgehensweise zum vergeben der IPv4-Adresse wäre, zuerst mit dem Befehl Netsh interface ipv4 show interfaces
den Wert in der Spalte idx für die Netzwerkverbindung herauszufinden und anschließend mit dem Befehl (alles in einer Zeile)
Netsh int ipv4 set address name="<IDX-Wert>" source=static address=192.168.178.10 mask=255.255.255.0
gateway=192.168.178.1 die IP-Adresse einzutragen.
Das IPv6-Protokoll deaktivieren
- Wenn das IPv6-Protokoll nicht verwendet wird, kann es deaktiviert werden.
Dazu gilt es mit Regedit die Registry aufzurufen und im Pfad
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\ den Schlüssel DWORD-32Bit
(sowohl auf einem 32Bit als auch auf einem 64Bit System) DisabledComponents mit dem Hex-Wert 0xFFFFFFFF zu erstellen.
Nach einem Neustart ist das IPv6-Protokoll deaktiviert.
Eine DNS-Server IP-Adresse eintragen/entfernen
- Die IP-Adresse eines bestehenden DNS-Servers lässt sich wie folgt eintragen:
Netsh int ip set dns "LAN-Verbindung" static 192.168.178.5 primary
-
Einen weiteren DNS-Server trägt man mit diesem Befehl ein:
Netsh int ip add dns "LAN-Verbindung" 192.168.178.6
-
Entfernen lässt sich eine DNS-Server Adresse mit diesem Befehl:
Netsh int ip delete dns "LAN-Verbindung" 192.168.178.6
-
Alle DNS-Server Adressen lassen sich folgendermaßen entfernen:
Netsh int ip delete dns "LAN-Verbindung" all
Eine WINS‑Server IP-Adresse eintragen/entfernen
-
Ein WINS-Server lässt sich auf diese Art eintragen:
Netsh int ip add winsserver "LAN-Verbindung" 192.168.178.5
-
Einen zweiten WINS-Server kann man wie folgt eintragen:
netsh interface ipv4 add winsserver name="Local Area Connection" address=10.0.0.12 index=2
-
Entfernen lässt sich ein WINS-Eintrag mit diesem Befehl:
Netsh int ip delete wins "LAN-Verbindung" 192.168.178.5
-
Möchte man alle WINS-Einträge entfernen, so geht das folgendermaßen:
Netsh int ip delete wins "LAN-Verbindung" all
Den Server zu/aus der Domäne hinzufügen/entfernen
- Mit diesem Befehl, lässt sich der Server Core zum Mitgliedsserver einer Domäne hinzufügen:
Netdom join <ComputerName> /domain:<DomänenName> /userd:Administrator /passwordd:Pa$$w0rd!
- Aus der Domäne lässt sich der Server Core wie folgt nehmen:
Netdom remove /d:<Domäne> <PC-Name Core>
Den Server Core zum Domänencontroller heraufstufen (promoten)
- Das Active Directory lässt sich auf einem Server Core nicht wie die anderen Rollen mit Ocsetup,
sondern ausschließlich durch den Dcpromo-Assistenten installieren. Der Aufruf von Dcpromo, kann auf einem
Server Core nicht wie auf den normalen Server-Versionen gestartet, sondern muss entweder mit einer Antwortdatei
oder durch die unbeaufsichtigte Installation Dcpromo /unattend aufgerufen werden.
- Mit der Angabe einer Antwortdatei wird der Server Core wie folgt zum Domänencontroller (DC) gestuft:
DCPROMO /unattend:E:\DCCorepromote.txt
Durch die Antwortdatei, kann auf dem Server Core das DNS gleich mit installiert sowie der globale Katalog
aktiviert werden (was beides zu empfehlen wäre). Zur Arbeitserleichterung kann man sich beim Ausführen von Dcpromo
auf einem vollinstallierten Server, am Ende des Assistenten die Einstellungen exportieren lassen.
Wie eine solche Antwortdatei aussehen könnte, steht am Ende dieses Artikels.
- Der Befehl für einen zusätzlichen Server Core DC, könnte bei der unbeaufsichtigten Variante wie folgt aussehen (alles in einer Zeile):
dcpromo /unattend /replicaOrNewDomain:replica /replicaDomainDNSName:intra.dikmenoglu.de
/sitename:Default-First-Site-Name /InstallDns:yes /CreateDNSDelegation:no /confirmGC:yes /UserDomain:intra.dikmenoglu.de
/UserName:intra.dikmenoglu.de\Administrator /Password:DomänenAdminKennwort /databasePath:"C:\Windows\Ntds"
/logPath:"C:\Windows\Ntds" /sysvolpath:"C:\Windows\Sysvol" /safeModeAdminPassword:SchweresPa$$w0rd!
/rebootOnCompletion:yes
Promotion Operation
-
Wird der Server Core, der erste Windows Server 2008 Domänencontroller in einer Windows 2000 oder
Windows Server 2003 Gesamtstruktur, so muss vorher das ADPREP von der Windows Server 2008 DVD
(aus dem Verzeichnis DVD-Laufwerk:\Sources\Adprep) ausgeführt werden. Microsoft empfiehlt vorher das Verzeichnis
Adprep auf den Server zu kopieren und anschließend, dass ADPREP von dort zu starten. Damit sollen Lesefehler des
DVD-Laufwerks vorgebeugt werden, die während dem Ausführen von ADPREP auftreten könnten.
Das ADPREP ist zuerst auf dem Schemamaster mit dem Parameter /FORESTPREP und auf dem Infrastrukturmaster in
der Domäne, zu der der Windows Server 2008 hinzugefügt werden soll, mit den Parametern „/DOMAINPREP /GPPREP“ auszuführen.
Soll der Server Core der erste Windows Server 2008 als RODC in einer Windows Server 2003 Gesamtstruktur werden
(dazu muss sich der Gesamtstrukturfunktionsmodus auf Windows Server 2003 befinden), so gilt es vorher das
ADPREP mit dem Parameter /RODCPREP lediglich ein einziges Mal für die Gesamtstruktur (und nicht in jeder Domäne) auszuführen.
Den Server Core zum Mitgliedsserver herunterstufen (demoten)
-
Herunterstufen (demoten) zu einem Mitgliedsserver lässt sich der Server Core DC ebenfalls, entweder mit DCPROMO
und einer Antwortdatei (siehe unten stehende Antwortdatei Beispiele) oder durch die unbeaufsichtigte Variante.
Der Aufruf mit einer Antwortdatei, sieht so aus: DCPROMO /unattend:E:\DCCoredemote.txt
-
Das Herunterstufen zu einem Mitgliedsserver bei der unbeaufsichtigten Variante, könnte auf einem zusätzlichen Server Core DC
der nicht die FSMO-Rollen trägt, wie folgt aussehen (alles in einer Zeile):
dcpromo /unattend /AdministratorPassword:"Pa$$w0rd!" /IgnoreIsLastDnsServerForZone:yes
/IgnoreIsLastDCInDomainMismatch:yes /RebootOnSuccess:yes
Demotion Operation
DHCP-Server installieren/deinstallieren
-
Möchte man den DHCP-Server auf einem Server Core installieren, so lässt sich das mit diesem Befehl realisieren:
start /w ocsetup DHCPServerCore
-
Deinstallieren lässt sich der DHCP mit einem /uninstall am Ende: start /w ocsetup DHCPServerCore /uninstall
-
Die Konfiguration des DHCP-Servers (Bereiche, Optionen etc.) erfolgt über NETSH oder remote von
einem anderen Server aus, mit dem DHCP Snap-In.
-
Die DHCP-Konfiguration über NETSH könnte wie folgt aussehen:
netsh dhcp server 192.168.178.5 add scope 192.168.178.0 255.255.255.0 DHCPCore CoreBereich
Den DHCP-Bereich festlegen
netsh dhcp server 192.168.178.5 scope 192.168.178.0 add iprange 192.168.178.1 192.168.178.254
Ausschlussbereich
netsh dhcp server 192.168.178.5 scope 192.168.178.0 add excluderange 192.168.178.40 192.168.178.60
Die Router-Option setzen
netsh dhcp server 192.168.178.5 scope 192.168.178.0 set optionvalue 003 IPADDRESS 192.168.178.1
Den DNS-Server setzen
netsh dhcp server 192.168.178.5 scope 192.168.178.0 set optionvalue 006 IPADDRESS 192.168.178.5 192.168.178.6
Den DHCP-Bereich aktivieren
netsh dhcp server 192.168.178.5 scope 192.168.178.0 set state 1
-
Der Dienst des DHCP-Servers wird nach der Installation nicht gestartet.
Des Weiteren steht der Starttyp des DHCP-Servers in der Dienstesteuerung nach der Installation, auf Deaktiviert.
-
Um den DHCP-Server Dienst zu starten, ist folgender Befehl auszuführen: net start dhcpserver
-
Den Starttyp stellt man mit diesem Befehl auf Automatisch:
sc config dhcpserver start= auto (Achtung: Nach dem Gleichheitszeichen muss ein Leerzeichen folgen!)
-
Deaktiveren lässt sich der Starttyp so: sc config dhcpserver start= disabled
-
Befindet sich der Server Core in einer Active Directory Umgebung, so muss der DHCP-Server zusätzlich noch
im Active Directory autorisiert werden. Auch dies lässt sich über NETSH (neben der DHCP-MMC auf einem
vollwertigen Server) realisieren. Der Befehl zum autorisieren lautet:
netsh dhcp add server Lhcore01.intra.dikmenoglu.de 192.168.178.5
-
Wenn hingegen ein DHCP-Server aus der Liste der autorisierten DHCP-Server im Active Directory entfernt werden soll,
so lautet der Befehl: netsh dhcp delete server Lhcore01.intra.dikmenoglu.de 192.168.178.5
DNS-Server installieren/deinstallieren
- Den DNS-Server installiert man wie folgt: start /w ocsetup DNS-Server-Core-Role
- Deinstallieren lässt sich der DNS-Server auf diese Weise: start /w ocsetup DNS-Server-Core-Role /uninstall
-
Der DNS-Server lässt sich zum einen mit dem Kommandozeilen-Tool dnscmd und zum anderen remote mit dem DNS Snap-In konfigurieren.
WINS-Server installieren/deinstallieren
- Der WINS-Server lässt sich folgendermaßen installieren: start /w ocsetup WINS-SC
- Die Deinstallation des WINS-Servers, lässt sich auf die Art durchführen: start /w ocsetup WINS-SC /uninstall
Hyper-V auf einem Server Core installieren
- Das Hyper-V lässt sich auf einem Windows Server 2008 Enterprise - Server Core wie folgt installieren:
bcdedit /set hypervisorlaunchtype auto (dieser Befehl ist nicht zwingend, aber ohne ihn sind zwei Neustarts fällig)
start /w ocsetup Microsoft-Hyper-V
- Von einem vollwertigen Server auf dem das Hyper-V ebenfalls installiert ist, kann nun das Hyper-V auf dem Server Core
konfiguriert werden. Microsoft arbeitet aber zurzeit an einer MMC für Windows Vista/Windows Server 2008 Vollinstallation.
Die Druckdienste installieren/deinstallieren
- Die Druckdienste können wie folgt installiert: start /w ocsetup Printing-ServerCore-Role
- …und auf diese Art deinstalliert werden: start /w ocsetup Printing-ServerCore-Role /uninstall
Den Server Core aktivieren
- Der Server Core kann mit diesem Befehl aktiviert werden: Cscript C:\Windows\system32\SLmgr.vbs –ato
- Das Ablaufdatum der Lizenz, kann man wie folgt herausfinden: Cscript C:\Windows\system32\slmgr.vbs -xpr
- Falls zum Zeitpunkt der Aktivierung keine Internetverbindung besteht, kann durch einen gebührenfreien Anruf
(Deutschland Tel.: 0800-284 828 3) bzw. den gebührenpflichtigen Anruf (Deutschland Tel.: 069-500 700 25)
bei Microsoft der Server telefonisch aktiviert werden. Eine andere Möglichkeit wäre mittels dem Key Management Server (KMS)
die Aktivierung zu vollziehen. Die Rufnummern für die einzelnen Länder stehen im übrigen in der Datei phone.inf,
dass sich im folgenden Pfad befindet: %windir%\system32\slui\phone.inf.
- Die Installations-ID für die telefonische Aktivierung, kann so herausgefunden werden: Cscript C:\Windows\system32\slmgr.vbs -dti
- Anschließend kann der Server manuell aktiviert werden: Cscript c:\windows\system32\slmgr.vbs –atp GUID <Bestätigungs-ID>
Die AD LDS installieren
- Die Active Directory Lightweight Directory Services lassen sich auf diese Art installieren:
start /w ocsetup DirectoryServices-ADAM-ServerCore
Die Windows Remote Shell aktivieren
- Die Windows Remote Shell (WinRS) lässt sich so aktivieren: WinRM quickconfig
- Durch die Bestätigung mit Y wird die WinRS endgültig aktiviert.
- Nun kann von einem Remote-Host durch Aufruf des folgenden Befehls in einer Kommandozeile,
der Server Core aus der CMD heraus, administriert werden: winrs -r:<ServerCore> cmd
Eine neue Kommandozeile CMD öffnen
- Hat man aus Versehen die Kommandozeile geschlossen, kann man durch drücken von STRG+SHIFT+ENTF den Taskmanager
aufrufen und mit einem neuen Task die CMD erneut aufrufen. Oder im Taskmanager ABMELDEN wählen und sich neu an dem
System anmelden. Ein Neustart bringt die CMD natürlich genauso zum Vorschein.
- Deshalb wäre es sinnvoll gleich zu Beginn der Anmeldung, eine weitere CMD mit start cmd /separate zu starten.
Die Windows Firewall konfigurieren
- netsh advfirewall
Die Energieeinstellungen konfigurieren
- Powercfg
Die Windows Updates konfigurieren
- Um die automatischen Windows Updates zu aktivieren, gilt es diesen Befehl einzugeben:
Cscript C:\Windows\system32\Scregedit.wsf /au 4
- Deaktivieren lassen sich die Windows Updates wie folgt: Cscript C:\Windows\system32\Scregedit.wsf /au 1
- Die aktuelle Einstellung kann wie folgt herausgefunden werden: Cscript C:\Windows\system32\Scregedit.wsf /au /v
Die Systeminformationen anzeigen lassen
- Die Systeminformationen lassen sich durch die Eingabe von systeminfo.exe anzeigen.
Die Zeit/Zeitzone sowie Regions- und Sprachoptionen konfigurieren
- Das Datum, die Zeit oder die Zeitzone lassen sich durch die Eingabe von control timedate.cpl konfigurieren.
- Die gewünschte Regions- und Sprachoptionen kann man mit dem Befehl control intl.cpl auswählen.
Die Installation von Treibern
- Wenn der Treiber im Server Core enthalten ist, wird der Treiber für die Hardware automatisch bei der Betriebssysteminstallation installiert.
Oder wenn die Hardware nachträglich eingebaut wird, installiert sich der Treiber dank Plug and Play (PNP) automatisch.
-
Ist der Hardware-Treiber nicht im Betriebssystem enthalten, so gilt es diesen beim Hersteller zuerst herunterzuladen.
Falls keine Windows Server 2008 Treiber vom Hersteller bereitgestellt werden, reicht oftmals der Treiber für Windows Vista aus.
Der heruntergeladene Treiber sollte entweder entpackt und wie folgt installiert werden:
Pnputil –i –a <Pfad>\<Treiber>.inf
..oder der Treiber (evtl. eine Setup.exe) lässt sich direkt vom USB-Sick/CD auf dem Server Core ausführen und installieren.
- Wird eine bestehende z.B. on-Board Intel Netzwerkkarte nicht bei der Betriebssysteminstallation gleich mit installiert,
ist zuerst der entsprechende Treiber herunterzuladen (der Treiber für Windows Vista), diesen auf einen USB-Sick bzw. CD
zu packen und anschließend die heruntergeladene Setup.exe auszuführen. Der Assistent für den Treiber der einen durch die
Installation führt, ist der gleiche wie auf einem vollwertigen Server.
Wenn jemandem die langen und aufwändigen Befehle in der Kommandozeile zum konfigurieren des Server Core nicht so sehr liegt, der sollte sich einmal diese Tools anschauen:
Tools zum konfigurieren des Server Core
Beispiele einer Antwortdatei
Erster DC einer neuen Gesamtstruktur:
[DCInstall]
; New forest promotion
ReplicaOrNewDomain=Domain
NewDomain=Forest
NewDomainDNSName=intra.dikmenoglu.de
ForestLevel=3
DomainNetbiosName=DIKMENOGLU
DomainLevel=3
InstallDNS=Yes
CreateDNSDelegation=No
ConfirmGc=Yes
DatabasePath=C:\Windows\NTDS
LogPath=C:\Windows\NTDS
SYSVOLPath=C:\Windows\SYSVOL
SafeModeAdminPassword=SchweresPa$$w0rd!
; Run-time flags (optional)
; CriticalReplicationOnly=Yes
RebootOnCompletion=Yes
TransferIMRoleIfNecessary=No
Zusätzlicher Domänencontroller:
[DCInstall]
; Replica DC promotion
ReplicaOrNewDomain=Replica
ReplicaDomainDNSName=intra.dikmenoglu.de
SiteName= Default-First-Site-Name
InstallDNS=Yes
CreateDNSDelegation=No
ConfirmGc=Yes
UserDomain=intra.dikmenoglu.de
UserName=dikmenoglu\administrator
Password=Pa$$w0rd!
DatabasePath="C:\Windows\NTDS"
LogPath="C:\Windows\NTDS"
SYSVOLPath="C:\Windows\SYSVOL"
SafeModeAdminPassword=SchweresPa$$w0rd!
; Run-time flags (optional)
; CriticalReplicationOnly=Yes
RebootOnCompletion=Yes
Erster DC einer neuen Sub-Domäne:
[DCInstall]
; New child domain promotion
ReplicaOrNewDomain=Domain
NewDomain=Child
ParentDomainDNSName=intra.dikmenoglu.de
ChildName=child
DomainNetbiosName=CHILDDOMAENE
DomainLevel=2
SiteName=Mainz
InstallDNS=Yes
CreateDNSDelegation=Yes
ConfirmGc=Yes
DNSDelegationUserName=dikmenoglu\administrator
DNSDelegationPassword=*
UserDomain=intra.dikmenoglu.de
UserName=dikmenoglu\administrator
Password=Pa$$w0rd!
ReplicationSourceDC=LHDCON01.intra.dikmenoglu.de
DatabasePath="C:\Windows\NTDS"
LogPath="C:\Windows\NTDS"
SYSVOLPath="C:\Windows\SYSVOL"
SafeModeAdminPassword=SchweresPa$$w0rd!
; Run-time flags (optional)
RebootOnCompletion=Yes
RODC:
[DCInstall]
; Read-Only Replica DC promotion
ReplicaOrNewDomain=ReadOnlyReplica
ReplicaDomainDNSName=intra.dikmenoglu.de
; RODC Password Replication Policy
PasswordReplicationDenied="VORDEFINIERT\Administratoren"
PasswordReplicationDenied="VORDEFINIERT\Server-Operatoren"
PasswordReplicationDenied="VORDEFINIERT\Sicherungs-Operatoren"
PasswordReplicationDenied="VORDEFINIERT\Konten-Operatoren"
PasswordReplicationDenied="DIKMENOGLU\Abgelehnte RODC-
Kennwortreplikationsgruppe"
PasswordReplicationAllowed="DIKMENOGLU\Zulässige RODC-Kennwortreplikationsgruppe"
PasswordReplicationAllowed=Gruppe1
PasswordReplicationAllowed=Benutzer1
PasswordReplicationAllowed=ComputerName1
DelegatedAdmin="DIKMENOGLU\RODC-Admins"
SiteName=Default-First-Site-Name
InstallDNS=Yes
ConfirmGc=Yes
CreateDNSDelegation=No
UserDomain=intra.dikmenoglu.de
UserName=intra.dikmenoglu.de\Administrator
Password=Pa$$w0rd!
; In der nächsten Zeile kann man einen Quell-DC angeben,
; mit dem die AD-Replikation stattfinden soll.
ReplicationSourceDC=LHDCON01.intra.dikmenoglu.de
DatabasePath="C:\Windows\NTDS"
LogPath="C:\Windows\NTDS"
SYSVOLPath="C:\Windows\SYSVOL"
SafeModeAdminPassword=SchweresPa$$w0rd!
; Run-time flags (optional)
; CriticalReplicationOnly=Yes
RebootOnCompletion=Yes
Einen Domänencontroller herunterstufen (demoten):
[DCINSTALL]
AdministratorPassword="Pa$$w0rd!"
IgnoreIsLastDnsServerForZone=Yes
IgnoreIsLastDCInDomainMismatch=Yes
RebootOnSuccess=Yes
Gesamtstrukturfunktionsmodus (ForestLevel):
0 = Windows 2000
Wenn diese Gesamtstrukturfunktionsebene gewählt wird, dann kann sich der Domänenfunktionsmodus (DomainLevel) der einzelnen
Domänen im Modus Windows 2000 pur (0), Windows Server 2003 (2) und Windows Server 2008 (3) befinden.
2 = Windows Server 2003
In dieser Gesamtstrukturfunktionsebene können Domänen im Domänenfunktionsmodus Windows Server 2003 (2) und
Windows Server 2008 (3) existieren.
3 = Windows Server 2008
In dieser Gesamtstrukturfunktionsebene können ausschließlich Domänen in der Domänenfunktionsebene
Windows Server 2008 (3) in der bestehenden Gesamtstruktur existieren.
4 = Windows Server 2008 R2
In dieser höchsten Gesamtstrukturfunktionsebene können ausschließlich Domänen in der Domänenfunktionsebene
Windows Server 2008 R2 (4) in der bestehenden Gesamtstruktur existieren.
Weitere Informationen:
Server Core Installation Option of Windows Server 2008 Step-By-Step Guide
Determining if Server Core is Running (Windows)
How to Use Netsh.exe to Authorize, Unauthorize and List DHCP Servers in Active Directory
Jeder der mit der Additional Account Info DLL (acctinfo.dll) schon einmal gearbeitet hat, weiß diese zusätzlichen Angaben zu schätzen.
Die zusätzlichen Angaben werden in einem weiteren Reiter, in den Benutzereigenschaften angezeigt. Diese DLL befindet sich in den
Account Lockout and Management Tools. Dort ist sie mit der Versionsnummer 1.0.0.1111 vorhanden. Nach dem registrieren dieser DLL,
taucht in den Eigenschaften eines Benutzerobjekts eine weitere Registerkarte auf. Dieser Reiter erscheint nur auf der Maschine,
auf dem diese DLL registriert wurde (und steht somit nicht domänenweit auf jedem Client/Server zur Verfügung). Dort steht z.B.
wann die letzte Benutzeranmeldung erfolgt ist oder wann das Kennwort des Benutzers ausläuft.
Siehe: Die letzte Benutzeranmeldung herausfinden
Der Reiter taucht aber nur dann auf, wenn das Benutzerobjekt direkt (Doppelklick auf das Benutzerobjekt) oder über eine
gespeicherte Abfrage aufgerufen wird. Wird hingegen die Active Directory Suche verwendet, erscheint dieser Reiter nicht.
Das kommt daher, da die Version 1.x lediglich eine Erweiterung in Form einer weiteren Registerkarte in den Eigenschaften des Benutzerobjekts ist.
Die Suche im Active Directory erfolgt z.B. im Snap-In Active Directory-Benutzer und -Computer mit einem Rechtklick auf einer OU oder auf den FQDN.
Des Weiteren ist in der Version 1.x ein Fehler enthalten, denn es zeigt einen Wert im Last-Logon-Timestamp an, obwohl sich die
Domäne nicht im Domänenfunktionsmodus Windows Server 2003 befindet.
Es existiert mittlerweile eine neuere Version dieser DLL und trägt den Namen Acctinfo2.dll (beachtet unten stehende Anmerkung).
In der neueren Version ist die acctinfo2.dll nicht nur ein weiterer Reiter, sondern ein Display Specifier. Dadurch taucht nun auch bei
einer Suche der Reiter auf. Mit dieser Version der DLL, wird desweiteren nicht mehr der Last-Logon-Timestamp im Reiter angezeigt,
sondern erst, wenn sich die Domäne tatsächlich im Domänenfunktionsmodus Windows Server 2003 befindet. Außerdem werden
zusätzliche Informationen bereitgestellt.
Installation
Die Acctinfo2.dll muss zuerst ins Verzeichnis %windir% verschoben werden.
Im nächsten Schritt ist diese DLL, entweder unter Start - Ausführen oder in einer Kommandozeile mit dem Befehl
regsvr32 acctinfo2.dll zu registrieren.
Als nächstes ruft man ADSIEdit (aus den Windows Support Tools) auf und navigiert in der Konfigurationspartition zu folgendem Pfad:
CN=user-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=Domäne,DC=TLD
Hinweis: Läuft der Windows Server mit einer englischen Betriebssystem Version, so lautet die Länderkennung nicht CN=407 sondern CN=409.
Dort angelangt, sind die Eigenschaften von CN=user-Display aufzurufen.
Anschließend gilt es im Attribut adminPropertyPages den folgenden Eintrag hinzuzufügen:
2,{5969F63F-CACF-40bf-8891-CA580EB589E9}
Am Anfang des Eintrags (2,..) ist ein freier oder der nächst höhere Wert zu wählen, gefolgt von einem Komma und der GUID
der Acctinfo2.dll (in geschweiften Klammern).
Danach steht ab sofort der neue Reiter in den Benutzereigenschaften zur Verfügung.
Weiterhin ist es möglich, dass beide Versionen (1.x sowie 2.x) nebeneinander existieren.
Anmerkung: Die aktuelle und von Microsoft unterstütze AcctInfo.dll ist in den Account Lockout and Management Tools enthalten und kann
kostenlos heruntergeladen werden. Wann und ob Microsoft die Version 2.x veröffentlichen wird (zum Download bereitstellt), ist zum jetzigen
Zeitpunkt nicht bekannt. Sobald es Nähere Informationen darüber geben wird, werde ich es hier veröffentlichen.
Update: 27.04.2010
Es gibt mittlerweile auch eine (nicht supportete!) x64Bit Version der acctinfo2.dll.
In einer Active Directory Umgebung findet zwischen den Domänencontrollern eine Multimaster-Replikation statt.
Dadurch kann auf jedem Domänencontroller (DC) eine Änderung durchgeführt werden, die Dank der AD-Replikation an alle DCs repliziert wird.
Das Active Directory (genauer KCC) reagiert dabei schnell auf etwaige Veränderungen in der Gesamtstrukturtopologie und findet
- sofern irgendwie möglich - oftmals eine Lösung.
Nun kann es in einer Umgebung mit mehreren DCs und mehreren Administratoren vorkommen, dass zur gleichen Zeit an einem Objekt,
dass gleiche Attribut auf verschiedenen DCs bearbeitet wird. Ein Replikationskonflikt wird anhand der Versions-Nummer (versionID) des
veränderten Attributs erkannt. Im Gegensatz zu der Update Sequence Number (USN), worin serverspezifische Werte gespeichert werden,
wird in der Versions-Nummer eines Attributs ein eindeutiger Wert gespeichert.
Wird nun ein Attribut auf DC2 verändert, bevor die zur gleichen Zeit getätigte Änderung von DC1 repliziert wurde,
entsteht somit ein Replikationskonflikt. Angenommen auf DC1 wird in den Eigenschaften eines Benutzerobjekts im Feld Büro die
Zimmer-Nummer 2.12 und zur gleichen Zeit auf DC2 die Zimmer-Nummer 2.21 eingetragen. Wenn nun DC3 beide Änderungen gleichzeitig erhält,
muss bestimmt werden, welche Änderung repliziert wird.
Das Active Directory wendet dann die folgenden drei Regeln an, um festzulegen welche Änderung repliziert werden soll:
-
Das modifizierte Attribut mit der höheren Versions-Nummer (versionID) überschreibt die Änderung mit der niedrigeren Versions-Nummer.
Sind in beiden Fällen, beide Versions-Nummern identisch, folgt die nächste Regel.
-
Enthalten beide Änderungen die gleiche versionID, wird die Änderung mit dem späteren Zeitstempel (Timestamp) akzeptiert und somit
würde die Änderung mit dem früheren Zeitstempel überschrieben werden. Ist in beiden Fällen auch der Zeitstempel gleich
(was in seltenen Fällen zutrifft), kommt die dritte und letzte Regel ins Spiel.
-
Falls beide Änderungen sowohl die gleiche versionID, als auch den gleichen Zeitstempel haben, wird die Änderung,
die seine Herkunft auf dem DC mit der niedrigeren GUID hat akzeptiert. Somit wird der Schreibvorgang vom DC mit der höheren GUID überschrieben.
In einem anderen Fall kann es zu einem Replikationskonflikt kommen, wenn ein Objekt auf zwei verschiedenen DCs mit dem
gleichen Namen zur gleichen Zeit erstellt wird, wie es z.B. beim hinzufügen eines Clients zur Domäne vorkommen kann.
Oder beim gleichzeitigen erstellen zweier Benutzerobjekte, mit dem gleichen Namen. Denn wenn zwei DCs zur gleichen Zeit
ein Objekt mit dem gleichen Namen im Active Directory erstellen, kommt es ebenfalls zum Konflikt.
Das Active Directory wendet in diesem Fall ebenfalls die o.g. drei Regeln an, mit dem Unterschied, dass das nicht akzeptierte
Objekt nicht überschrieben, sondern umbenannt wird. Der Relative Distinguished Name (RDN) des Objekts, bekommt einen
eindeutigen Namen der folgendermaßen aussieht: <Original RDN>CNF:<ObjectGUID>. Die Zeichen CNF stehen dabei für
Conflict (Konfliktobjekt). Danach folgt ein Doppelpunkt, gefolgt von der Objekt GUID.
Der Administrator kann dann bestimmen, welches Objekt beibehalten und welches gelöscht werden soll.
Über eine benutzerdefinierte Abfrage lassen sich alle Konfliktobjekte anzeigen. Der Filter dazu lautet (CN=*CNF:*).
Es gibt aber noch eine dritte Situation, in dem es zu einem Konflikt kommen kann. Erstellt ein Administrator z.B. einen Benutzer in einer OU
und ein anderer Administrator löscht im gleichen Moment auf einem anderen DC diese OU, wird das Benutzerobjekt trotzdem erstellt
obwohl der übergeordnete Container entfernt wurde. Das AD löst in diesem Fall den Konflikt, in dem es das Benutzerobjekt in
einem versteckten Container Namens LostAndFound erstellt. Der Domänen-Benutzer der sich im Container LostAndFound befindet,
kann sich wie jeder andere Benutzer an der Domäne anmelden. Der Administrator sollte aber aus administrativen Gründen
den Benutzer in eine andere OU verschieben. Der Container LostAndFound kommt erst dann zum Vorschein,
wenn in der MMC Active Directory-Benutzer und -Computer unter "Ansicht" die Option Erweiterte Funktionen aktiviert wurde.
Weitere Informationen:
Avoiding Replication Issues When Designing Applications that Use Active Directory
Troubleshooting Directory Data Problems
Eine weitere Funktion die im Windows Server 2008 erweitert wurde, ist die Möglichkeit der Protokollierung.
Was in Windows 2000 oder Windows Server 2003 noch spärlich war, wurde im neuen Server-Betriebssystem verfeinert.
Früher wurde lediglich protokolliert, wer welches Objekt bzw. Attribut verändert hat. Die eigentlichen Werte
(alter Wert/neuer Wert) blieben aber einem verborgen. Dieses Verhalten wurde im Windows Server 2008 geändert
und man bekommt nun detailliert in der Ereignisanzeige die veränderten Werte zu sehen.
Hinweis: Eine Protokollierung ist vom Betriebsrat/Datenschutzbeauftragten zu genehmigen!
In Windows 2000 und Windows Server 2003 existiert lediglich die globale Überwachungsrichtlinie, die unter Windows 2000 Active Directory-Zugriff überwachen
und unter Windows Sever 2003 Verzeichnisdienstzugriff überwachen lautet. In Windows Server 2008 existiert die globale Überwachungsrichtlinie weiterhin,
die jedoch in weitere vier Unterkategorien unterteilt wurde.
Die Unterkategorien wären:
-
Verzeichnisdienständerungen (Directory Services Changes)
-
Verzeichnisdienstreplikation (Directory Services Replication)
-
Detaillierte Verzeichnisdienstreplikation (Detailed Directory Services Replication)
-
Verzeichnisdienstzugriff (Directory Services Access)
Somit kann der Administrator gezielter einen der verfügbaren Bereiche überwachen, ohne von den restlichen Bereichen
die ihn ohnehin nicht interessieren, unnötig mit Informationen überflutet zu werden. Das bringt aber einen Nachteil mit sich.
Wenn man lediglich z.B. die Unterkategorie Verzeichnisdienständerungen (wahrscheinlich die meist gewünschten Informationen)
konfigurieren möchte, muss man das auf jedem einzelnen DC in der Domäne durchführen. Diese Einstellung wird nicht repliziert.
Wird dagegen die globale Richtlinie <Verzeichnisdienstzugriff überwachen> in der Default Domain Controllers Policy konfiguriert,
werden automatisch auch alle Unterkategorien mit den eingestellten Optionen aktiviert. Diese Einstellungen wiederum,
werden auf alle DCs in der Domäne repliziert.
Wenn danach die globale Richtlinie wieder in ihren Ursprungszustand Nicht definiert gebracht wird, werden dabei nicht die
Unterkategorien mit in ihren Ursprungszustand versetzt. Diese bleiben mit ihren aktuell gesetzten Einstellung weiterhin bestehen.
Die globale Überwachungsrichtlinie in Windows Server 2008 ist standardmäßig nicht definiert. Lediglich die Unterkategorie
Verzeichnisdienstzugriff ist als einzige, standardmäßig mit der Option Erfolgreich und zwar auf jedem DC aktiviert.
Idealerweise konfiguriert man die globale Richtlinie mit den gewünschten Optionen,
in der Default Domain Controllers Richtlinie unter:
Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\
Überwachungsrichtlinie\<Verzeichnisdienstzugriff überwachen>.
Die Unterkategorie Verzeichnisdienstzugriff im Windows Server 2008, spiegelt im Prinzip die globale Richtlinie aus
Windows 2000/Windows Server 2003 wieder. Lediglich die Ereignis-ID ändert sich unter Windows Server 2008 jedoch von 566 zu 4662.
Zum konfigurieren der Unterkategorien muss nicht die globale Richtlinie definiert werden. Diese lassen sich auch einzeln konfigurieren.
Die Unterkategorien lassen sich aber weder in einer GUI anzeigen, noch in einer GUI konfigurieren. Diese lassen sich ausschließlich
über die Kommandozeile anzeigen sowie konfigurieren. Das Kommandozeilen-Tool das dafür verwendet wird lautet Auditpol.
Wie bei allen Kommandozeilen Tools von Microsoft, lässt sich die Liste der verfügbaren Parameter mit dem Befehl „Auditpol /?“ anzeigen.
Mit den erweiterten Protokollierungsmöglichkeiten in Windows Server 2008, werden nun die Werte in den Attributen,
vor- und nach dem verändern aufgezeichnet. Oder wenn ein Objekt innerhalb einer Domäne verschoben wird,
wird der Distinguished Name (DN) des alten sowie neuen Standorts vom Objekt protokolliert. Falls das Objekt in eine andere
Domäne verschoben werden sollte, wird auf dem Ziel-DC das erstellen eines Objekts protokolliert (sofern konfiguriert).
Das sind nur ein paar Beispiele, es gibt aber noch einige mehr.
Hinweis: Bei einer Kennwort-Änderung wird weder das alte, noch das neue Kennwort protokolliert!
Die neuen Protokollierungsmöglichkeiten, die der Windows Server 2008 mit sich bringt, werden durch die globale
Überwachungsrichtlinie (samt Unterkategorien), der System Access Control List (SACL) eines Objekts sowie durch
das Schema (genauer, durch das Attribut Search-Flags des jeweiligen Objekts) implementiert.
Die Änderungen die an einem Sicherheitsprinzipal (wie es z.B. ein Benutzer-Objekt darstellt) protokolliert werden,
wären: Das erstellen von Objekten, Änderungen, verschieben oder wiederherstellen von Objekten.
Die Informationen werden dabei im Sicherheitsprotokoll der DCs protokolliert.
Eine Objektänderung wird z.B. mit der Unterkategorie „Verzeichnisdienständerungen“ protokolliert.
Die Unterkategorien lassen sich mit folgendem Befehl anzeigen:
Auditpol /list /subcategory:DS-Zugriff
Möchte man sich die Unterkategorien mit den eingestellten Optionen anzeigen lassen,
so lässt sich dies, mit diesem Befehl herausfinden:
Auditpol /get /category:DS-Zugriff
Der folgende Befehl zeigt an, mit welcher Option eine Unterkategorie aktiviert ist:
Auditpol /get /subcategory:<Unterkategorie>
Die Unterkategorie Verzeichnisdienständerungen lässt sich mit der Option Erfolgreich, mit diesem Befehl aktivieren:
Auditpol /set /subcategory:Verzeichnisdienständerungen /success:enable
Soll hingegen neben den erfolgreichen, auch die fehlgeschlagenen Versuche einer Verzeichnisdienständerung
aufgezeichnet werden, so konfiguriert man das mit diesem Befehl:
Auditpol /set /subcategory:Verzeichnisdienständerungen /success:enable /failure:enable
Alle Unterkategorien lassen sich mit diesem Befehl zurücksetzen:
Auditpol /clear
Wird ein Objekt bearbeitet, so protokolliert die Ereignisanzeige die Event-ID 5136.
Beim erstellen eines Objekts, wird im Ereignisprotokoll die Event-ID 5137 verzeichnet.
Wenn ein Objekt wiederhergestellt wird, zeichnet das Ereignisprotokoll die Event-ID 5138 auf.
Das verschieben eines Objekts, wird die Event-ID 5139 protokolliert.
Möchte man z.B. den Standard-Container Users bezgl. Änderungen überwachen, so gilt es diese Punkte auszuführen:
-
Zuerst ist die Unterkategorie Verzeichnisdienständerungen mit der gewünschten Option
(erfolgreich und/oder fehlgeschlagen) auf allen DCs zu aktivieren.
-
Oder wer möchte, aktiviert die globale Richtlinie Verzeichnisdienstzugriff überwachen in der Default Domain Controllers Richtlinie.
-
In den Eigenschaften des Containers Users gilt es im Reiter Sicherheit die erweiterten Sicherheitseinstellungen
aufzurufen. Dort angelangt, kann im Reiter Überwachung der zu überwachende Benutzer bzw. die Gruppe hinzugefügt
und die zu überwachenden Einstellungen ausgewählt werden.
-
Anschließend kann auf dem DC unter dem Punkt Windows-Protokolle, im Sicherheitsprotokoll der Ereignisanzeige,
die Aufzeichnungen kontrolliert werden.
-
In einer Umgebung mit mehreren DCs müsste man nun auf jedem einzelnen DC das Sicherheitsprotokoll überprüfen.
Diese Arbeit kann man sich mit einem professionellen Werkzeug, wie es z.B. der Microsoft Operations Manager - kurz MOM -
darstellt, erleichtern. Sicherlich werden aber noch kostenlose Tools folgen bzw. bereits verfügbare Tools (EventComBMT)
für den Windows Server 2008 aktualisiert und freigegeben.
Weitere Informationen:
Security audit events for Microsoft Windows Server 2008 and Microsoft Windows Vista
Windows Server 2008 Auditing AD DS Changes Step-by-Step Guide
One-Stop Shop for Auditing in Windows Server 2008 and Windows Vista
Security audit events for Microsoft Windows Server 2008 and Microsoft Windows Vista
Special Groups Auditing via Group Policy Preferences
Verzeichnisdienstzugriff überwachen
Security auditing settings are not applied to Windows Vista client computers when you deploy a domain-based policy
How to use Group Policy to configure detailed security auditing settings for Windows Vista client computers in a Windows Server 2003 domain or in a Windows 2000 domain
HOW TO: Audit Active Directory Objects in Windows 2000
Wer kennt das nicht. Man unterhält sich während der Benutzerpflege im Active Directory mit seinen Kollegen über
das gestrige Fußball-Spiel oder hängt während dessen am Telefon und versucht an einem kniffligen Problem Hilfe zu leisten,
so das man abgelenkt ist und dabei alte Benutzerkonten entfernt. Schnell wurden zwei-Klicks im Snap-In
Active Directory-Benutzer und -Computer am falschen Benutzer-Objekt getätigt und schon wurde der falsche Benutzer gelöscht.
Das ist ärgerlich. Zumal wenn es sich auch noch um das Benutzerkonto einer wichtigen Person (des CEO vielleicht?) handelt.
Oder es wird irrtümlich ein anderes Objekt gelöscht etc.
Was passiert nun genau im Hintergrund, mit dem aus Versehen gelöschten Objekt?
Welche Änderungen am Objekt während des Löschvorgangs durchgeführt werden oder welche Attribute
im Tombstone erhalten bleiben, zeigt der folgende Artikel:
Lingering Objects (veraltete Objekte)
Doch bevor das Objekt gelöscht wird und somit in den versteckten Container Deleted Objects
(in der Verzeichnispartition, in der das Objekt gelöscht wurde) wandert, wird anhand bestimmter Kriterien geprüft ob das Objekt
tatsächlich gelöscht werden darf. Diese Kriterien wären unter anderem:
-
Der Benutzer der das Objekt löschen möchte hat die benötigten Rechte
-
Das Objekt wurde nicht bereits gelöscht und somit befindet sich das Attribut Is-Deleted des Objekts, nicht auf dem gesetzten Wert True
-
Das System-Flags Attribut (0x80000000) des Objekts verhindert nicht das löschen
-
Das Objekt enthält keine untergeordneten Objekte (ansonsten erscheint eine Fehlermeldung, siehe: Computerkonto löschen)
-
-
Es handelt sich nicht um ein Schemaobjekt, wie es Attribute und Klassen darstellen. Denn diese können weder
entfernt und somit auch nicht wiederhergestellt werden. Denn wenn das möglich wäre, könnten Inkonsistenzen in der
Active Directory-Datenbank (NTDS.dit) entstehen. Unter Umständen bestehen nämlich Abhängigkeiten z.B. auf das zu löschende Attribut.
Die einzige Möglichkeit wäre, dass Attribut Is-Defunct zu nutzen, um das entsprechende Attribut bzw. die Klasse zu deaktivieren
Wird nun das Objekt gelöscht, verschwindet es nicht sofort aus der Active Directory-Datenbank (NTDS.DIT).
Das Active Directory markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf den Wert TRUE gesetzt wird.
Dabei werden von dem Objekt die meisten Attribute auf ewig entfernt. Anschließend wandert das Objekt in den Container
Deleted Objects (der in fast allen Verzeichnispartitionen existiert) und wird ab diesem Zeitpunkt als Tombstone (zu deutsch: Grabstein) bezeichnet.
Im Container Deleted Objects erhält das Tombstone einen speziellen Relative Distinguished Name (RDN),
der so aussieht: „CN=<alter RDN>\0ADEL:<Object-GUID>“.
Das gelöschte Objekt verbleibt in dem Container so lange, bis die Tombstone Lifetime (TSL) abgelaufen ist.
Die TSL beträgt standardmäßig bei einer ursprünglich erstellten Windows 2000 sowie Windows Server 2003 Gesamtstruktur 60 Tage.
Beim erstellen einer Gesamtstruktur mit Windows Server 2003 SP1, beträgt die TSL 180 Tage. Erst nach Ablauf der TSL Zeit,
wird das Objekt nun endgültig vom Garbage Collection Prozess (der alle 12 Stunden läuft) aus dem Active Directory entfernt.
Das gelöschte Objekt wandert deshalb zuerst in den Container Deleted Objects, damit die Replikation genug Zeit hat,
diese Information des Löschens auch wirklich an alle DCs zu kommunizieren.
Welche Möglichkeiten hätte man nun, um das Objekt wiederherzustellen?
Zum einen funktioniert das natürlich durch eine autoritative Wiederherstellung und zum anderen bietet das Active Directory
unter Windows Server 2003 die Möglichkeit, den Tombstone, der also noch im Active Directory existiert, wiederzubeleben.
Für eine autoritative Wiederherstellung ist es ratsam, eine möglichst aktuelle System State-Sicherung des entsprechenden DCs
zu verwenden (Stichwort: Registry). Es darf keine System State-Sicherung die älter als die TSL ist, verwendet werden.
Was auch noch wichtig ist und von vielen Administratoren nicht beachtet wird, ist der Pfad zum Objekt,
also der sogenannte Distinguished-Name (DN). Dieser muss bekannt sein.
Der Nachteil bei dieser Variante der Wiederherstellung wäre, der Domänencontroller muss im Modus
„Verzeichnisdienste wiederherstellen“ gestartet werden und wäre somit für die Dauer der Wiederherstellung offline.
Der Vorteil wiederum wäre, dass z.B. ein Benutzer-Objekt mit den Einstellungen die es zum Zeitpunkt der Sicherung hatte,
wiederhergestellt wird (Stichwort: Object-GUID und Object-SID).
Einen Kern des Problems, stellen beim rücksichern von Benutzer- sowie Gruppen-Objekten, die Gruppenmitgliedschaften dar.
Dieses wird aber im folgenden KB-Artikel ausführlich behandelt. Insbesondere mit Windows Server 2003 SP1 hat sich dieses
Verhalten verbessert, was das wiederherstellen von Backlinks betrifft.
How to restore deleted user accounts and their group memberships in Active Directory
Um in den Modus Verzeichnisdienste wiederherstellen zu gelangen, gilt es beim Starten des DCs auf die F8-Taste zu drücken,
damit diese Auswahlmöglichkeit überhaupt erscheint. Erst in diesem Modus ist das Active Directory offline und kann gewartet werden.
Dort angelangt, muss zuerst das System State rückgesichert und anschließend mit NTDSUTIL das gewünschte Objekt
autoritativ wiederhergestellt werden. Denn erst mit anwenden von NTDSUTIL wird die Versionsnummer
des Objekts um 100.000 erhöht. Damit wird sichergestellt, dass zum einen das Objekt von keinem anderen DC erneut gelöscht
und zum anderen, dieses Objekt auf alle anderen DCs repliziert wird. Viele Administratoren machen an dieser Stelle oftmals einen Fehler,
denn sie starten nach dem rücksichern des System States direkt den DC im normalen Modus ohne mit
NTDSUTIL das Objekt autoritativ wiederherzustellen.
Es sei denn, es handelt sich um eine Domäne mit nur einem DC (was ohnehin grob fahrlässig wäre).
Denn dann gäbe es keinen anderen DC, der die Rücksicherung überschreiben würde und man bräuchte NTDSUTIL nicht anzuwenden.
Einen Tombstone wiederbeleben
Das wiederbeleben eines Tombstones hat gegenüber einem neu erstellen eines Benutzer-Objekts einen großen Vorteil.
Im Tombstone ist nämlich (unter anderem) die Object-GUID sowie Object-SID enthalten. Somit wären beim wiederbeleben
die Verweise in den ACLs der Netzwerk-Ressourcen (z.B. Freigaben etc.) weiterhin gültig und müssten nicht neu vergeben werden.
Denn beim erstellen eines Sicherheitsprinzipals (so wie es ein Benutzer-Objekt darstellt), wird auch bei der Eingabe der
gleichen Benutzerdaten wie z.B. der gleiche Benutzeranmeldename etc. eine andere Object-GUID sowie Object-SID vergeben.
Deshalb ist das neue Objekt ein „anderes“, da es sich von der GUID und SID des originalen Objekts unterscheidet.
Des Weiteren ist es auch nicht notwendig, wie bei der autoritativen Wiederherstellung, den DC offline zu schalten.
Der Nachteil bei dieser Variante wiederum wäre, dass Objekt wird mit einigen wenigen Attributen wiederhergestellt
und die fehlenden Informationen z.B. bei einem Benutzer-Objekt, müssten erneut in den Benutzereigenschaften ein gepflegt werden.
Im Active Directory Schema ist vorgegeben, welche Attribute im Tombstone erhalten bleiben. Im Tombstone werden vor allem
keine Attribute der Gruppenzugehörigkeit oder das memberOf-Attribut eines Benutzer-Objekts gespeichert. Daher ist das
wiederbeleben eines Tombstones, zum wiederherstellen der Gruppenmitgliedschaften nicht geeignet.
Tipp: Genau an dieser Stelle, setzt das Skript Werding an.
Durch das vierte Bit im Search-Flags Attribut (in Dezimal 8) allerdings, lassen sich weitere Attribute im Tombstone speichern.
Somit lässt sich im Active Directory-Schema beeinflussen, welche zusätzlichen (neben den hartcodierten) Attribute im
Tombstone erhalten bleiben. Bei der Installation eines Exchange-Servers z.B. werden zusätzliche Attribute im Tombstone gespeichert.
Damit ein Tombstone zum Leben erweckt werden kann, muss zum einen das Attribut Is-Deleted regelrecht entfernt werden
(den Wert auf FALSE setzen reicht in diesem Fall nicht aus) und zum anderen, muss das Distinguished-Name-Attribut vom
Objekt geändert werden. Erst jetzt ist es möglich, dass Objekt in einen anderen Container zu verschieben. Doch auch bevor das
durchgeführt werden kann, wird überprüft, ob die notwendigen Kriterien für zum durchführen dieser Aufgabe erfüllt werden.
Diese wären unter anderem:
- Das Benutzerkonto mit dem das Objekt wiederhergestellt werden soll, muss über das Recht des Wiederbelebens eines Tombstone verfügen
- Natürlich kann der Benutzer nicht sein eigenes Benutzer-Objekt wiederherstellen
- Das Attribut Is-Deleted des Objekts muss auf den Wert TRUE gesetzt sein
Um einen Tombstone wiederzubeleben, lässt sich das z.B. mit ADRestore (einem Kommandozeilen-Tool aus dem Hause Microsoft)
oder LDP.exe aus den Windows Support Tools erledigen. Im Internet gibt es noch eine Menge Dritt-Anbieter Tools mit denen ein
Tombstone wiederbelebt oder das Active Directory gesichert und wiederhergestellt werden kann.
Zum speichern und wiederherstellen wichtiger Attribute, könnte auch das in Windows Server 2003 integrierte LDIFDE verwendet werden.
Als weitere Möglichkeit, kann unter Windows Server 2003 eine API verwendet werden, um einen Tombstone wiederzubeleben.
Im ersten Schritt, wird das gelöschte Objekt abgerufen und im zweiten wieder hergestellt:
Retrieving Deleted Objects (Windows)
Restoring Deleted Objects (Windows)
Beispiel:
Damit eine OU autoritativ wiederhergestellt werden kann, müssen folgende Schritte durchgeführt werden:
-
Der DC muss zuerst im Modus "Verzeichnisdienste wiederherstellen" gestartet werden (F8 beim starten)
-
Nach der Anmeldung ist ein aktuelles System State z.B. mit NTBACKUP vom DC rückzusichern
-
Anschließend darf kein Neustart durchgeführt werden
-
In der Kommandozeile muss NTDSUTIL aufgerufen und folgende Befehle eingegeben werden:
authotitative restore
restore subtree <Distinguished Name der gelöschten OU>
Der Distinguished Name (DN) für eine OU Benutzer direkt unter der Domäne intra.dikmenoglu.de würde so aus:
OU=Benutzer,DC=intra,DC=dikmenoglu,DC=de
-
Zu guter Letzt ist durch Eingabe von „quit“ (insgesamt zweimal) das NTDSUTIL und mit „exit“ die Kommandozeile zu verlassen.
Nach einem Neustart ist die OU erneut im Active Directory verfügbar.
Für eine autoritative Wiederherstellung eines Benutzer-Objekts, muss anstatt „restore subtree DN“,
dass Kommando „restore object DN“ verwendet werden.
Weitere Informationen:
Wie stelle ich das AD wieder her?
Notfallwiederherstellung: Active Directory-Benutzer und -Gruppen
Useful shelf life of a system-state backup of Active Directory
How To Use the Backup Program to Back Up and Restore the System State in Windows 2000
How to perform an authoritative restore to a domain controller in Windows 2000
How to Recover from a Deleted Domain Controller Machine Account in Windows 2000
How to perform a disaster recovery restoration of Active Directory on a computer with a different hardware configuration
Das Geheimnis der Tombstone Lifetime
The effects on trusts and computer accounts when you authoritatively restore Active Directory
HOW TO: Back Up the System State Data of a Remote Computer in Windows 2000
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|