ActiveDirectory: Wie ändere ich die IP-Adresse eines Domänen Controllers

Problem:
Ich musste die IP eines Domänen-Controllers ändern, da ich einen brandneuen Server 2016er DC aufgesetzt habe, aber keine Lust hatte an allen Druckern, DHCP-Scopes etc. die DNS-IP-Adressen anzupassen.

Lösung:
Eigentlich ist das Ändern relativ einfach, jedoch muss man der AD etwas Zeit geben, bis die Replizierung von AD und DNS durch ist. Folgende Schritte habe ich zur Änderung durchgeführt:

1.) Überprüfen Sie die korrekte Funktion der ActiveDirectory VOR der Umstellung (Replikation, dcdiag)
2.) Ändern Sie die IP-Adresse des betroffenen Domänen-Conmtrollers
3.) Führen Sie ein "ipconfig /registerdns" durch um die DNS-Änderungen zu aktualisieren
4.) Führen Sie ein "ipconfig /flushdns" durch um gecachte DNS-Einträge zu verwerfen
5.) Fühbren Sie ein "dcdiag /fix" durch um SPN-Einträge zu korrigieren
6.) WICHTIG: 5 Minuten nichts machen bis alle DNS/DC die neue IP haben (IT-Kaffee-Hol-Regel)
7.) Im DNS prüfen, ob alle Einträge richtig und nur noch die neuen IPs zu finden sind
8.) Auf allen DCs ein "ipconfig /flushdns" durchführen und den DNS-Cache an den DNS-Servern löschen.
8.) ActiveDirectory prüfen mittels Replikation und dcdiag etc.
9.) WICHTIG: Auf allen laufenden, wichtigen Servern (Exchange, SQL etc.) ein "ipconfig /flushdns" ausführen um die veralteten DNS-Einträge zu löschen - sonst kommt es zu eigenartigen Fehlermeldungen
10.) OPTIONAL: DHCP-Einstellungen anpassen, falls sich DNS-Server auch geändert haben
11.) Fertig! Nächster Kaffee...

Falls man, wie ich, zwei DCs ändern muß (alten DC auf neue IP und neuen DC auf alte IP), sollte man immer zwischen den Änderungen Zeit einplanen, damit die AD alles mitbekommt!

ActiveDirectory: Sicheres Schema-Update (ADPREP) mittels Replikations-Pause

Vorgehenweise um ein sicheres ActiveDirectroy-Schema-Update durchzuführen

Viele haben bestimmt schon ein ActiveDirectory-Schema-Update durchgeführt, ohne sich der Risiken bewusst zu sein, oder diese zu ignorieren. Ich hatte vor kurzem das erste Mal einen Stromausfall bei einem Schema-Update - glücklicherweise in einer Demo-Umgebung. Das Schema war danach zerstört und hatte sich aber beim Neustart der Server bereits repliziert - ActiveDirectory komplett zerstört, nur noch Fehlermeldungen beim Zugriff auf Objekte!
Um das zu verhindern, habe ich mir eine Anleitung zusammengebaut, in der ich wie folgt vorgehe:

1.) Verzeichnis-Replikation auf dem Schemamaster deaktivieren
2.) ADPREP durchführen
3.) Testen des Zugriffs auf die AD (ActiveDirectory-Benutzer und -Computer)
4.) Verzeichnis-Replikation wieder aktivieren
5.) Test der ActiveDirectory

Dazu gehe ich wie folgt vor:

1.) Schemamaster finden
Dazu verwende ich den Befehl "netdom query fsmo" und schau, welcher DC der Schemamaster ist

2.) Aktuelle Schema-Version ermitteln
Hierzu verwende ich auf dem Schemamaster den Befehl DSQUERY.
Hier ein Beispiel für die Domäne DEMO.LOCAL
dsquery * CN=Schema,CN=Configuration,DC=DEMO,DC=LOCAL -Scope Base -attr objectVersion

Kleiner Tipp, falls es sich um ein Exchange-Schema-Update handelt - mit diesem Befehl kann ich die Exchange-Version des Schemas auslesen:
dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=DEMO,dc=INTERN -scope base -attr rangeUpper


3.) Verzeichnis-Replikation auf dem Schemamaster deaktivieren
Hierzu verwendet ich die den Befehl "repadmin" um die eingehende und ausgehende Replikation zu deaktivieren:
(SCHEMAMASTER-NAME muss angepasst werden)

repadmin /options SCHEMAMASTER-NAME +DISABLE_OUTBOUND_REPL
repadmin /options SCHEMAMASTER-NAME +DISABLE_INBOUND_REPL

Danach findet man im Ereignisprotokoll die Ereignisse 1113 und 1115, die darauf hinweisen, dass eingehende und ausgehende Replikation vom Benutzer deaktiviert wurde (Ereignisprotokoll VERZEICHNISDIENST)


4.) Schema-Update durchführen
Jetzt führt man das Schema-Update durch mittels diesen drei Befehlen:
adprep /forestprep
adprep /domainprep
adprep /rodcprep


Im Ereignis-Protokoll werden die Aktualisierungen auch mit protokolliert:


5.) Prüfen der neuen Schema-Version
Nun kann man mittels DSQUERY-Befehl prüfen, ob die neue Schema-Version vorliegt
dsquery * CN=Schema,CN=Configuration,DC=DEMO,DC=LOCAL -Scope Base -attr objectVersion
Als Test dann man sich mal auf einen anderen DC einloggen und den Befehl ebenfalls durchführen.
Hier wird man sehen, dass die Schema-Version noch die alte Version ist, da die Replikation nicht aktiv ist!

6.) Testzugriff auf die AD auf dem Schemamaster
Öffnen Sie einige AD-Konsolen auf dem gerade aktualisieren Schemamaster und klicken Sie sich durch, ob es zu Fehlermeldungen kommt. Wenn alles in Ordnung ist, dann können Sie die Replikation wieder aktivieren.

7.) Replikation wieder aktivieren und das Schema global aktualisieren

Starten Sie auf dem Schemamaster mittels der nachfolgenden Befehle wieder die ein- und ausgehende Replikation:

repadmin /options SCHEMAMASTER-NAME -DISABLE_OUTBOUND_REPL
repadmin /options SCHEMAMASTER-NAME -DISABLE_INBOUND_REPL


Das Aktivieren der Replikation wird ebenfalls wieder im Ereignisprotokoll angezeigt:



8.) Prüfen der neuen Schema-Version
Starten Sie die Replikation der DCs manuell oder warten Sie den Zyklus ab. Danach prüfen Sie auf allen bestehenden DCs, ob das Schema übernommen wurde mittels des vorherigen DSQUERY-Befehl.

9.) FERTIG!

Damit haben Sie eine risikoarme Schema-Erweiterung durchgeführt und minimieren das Risiko, dass die ActiveDirectory beschädigt wird.

Quellen für die Hilfestellung:
Directory Services: Upgrading AD DS Schema to Windows Server 2016
ANTARY: Active Directory Schema Version herausfinden




Active Directory - Warnmeldung beim löschen eines Users

Problem : Beim versuch einen Benutzer aus dem Active Directory zu löschen erscheint diese Meldung.

Active Directory fehler beim Löschen

Da ich nicht wusste was das auf sich hat musste ich etwas forschen. Grund war das der User über Active Sync seine Mails auf sein Handy bekommen hat, im laufe der Jahre sind da einige Geräte zusammengekommen.

Lösung : Abfragen der ActiveSync Geräte mit dem Befehl
Get-ActiveSyncDevice | where {$_.userdisplayname –like "*vorname nachname*"}
sind dort welche gelistet müssen diese gelöscht werden. Hier ist der einzeiler der das erledigt.
Get-ActiveSyncDevice | where {$_.userdisplayname –like "*vorname nachname*"} | Remove-ActiveSyncDevice
sollte das nicht funktionieren muss man einen anderen Weg gehen. Wenn z.B. der Benutzer einmal umbenannt wurde kann es nötig sein diesen Weg zu wählen.


Auflisten der ActiveSync Geräte mit
Get-ActiveSyncDevice | where {$_.userdisplayname -like "*vorname nachname*"} | Select-Object Identity
anschließendes löschen der Geräte mit z.B.
Remove-ActiveSyncDevice -Identity "IDENTITY"


Sollte auch dieser Weg nicht funktionieren, kommt z.B. vor wenn das Postfach bereits gelöscht ist, ist das der einfachste Weg.

- Postfach nochmal anlegen
- ActiveSync Geräte entfernen
- Postfach löschen

Quelle :
http://www.mcseboard.de/topic/195314-ad-user-kann-nicht-gel%C3%B6scht-werden/
http://www.ugg.li/exchange-2010-entfernt-mobile-gerate-nicht-das-activesyncdevice-ldapxxxxx-wurde-nicht-gefunden/
https://patrickhoban.wordpress.com/2011/11/22/1344/

DNS Server (Windows 2008 R2) Backup

Um ein Backup eines DNS Servers der unter Windows 2008 R2 (sollte bei anderen Systemen ähnlich sein) läuft, muss man erstmal unterscheiden um welche Art DNS Server es sich handelt. Ist die Zone die gesichert werden soll nicht im Active Directory (AD) integriert reicht hier ein kleiner copy Befehl. Für eine AD integrierte Zone muss man das Tool dnscmd verwenden.

Copy Befehl :
robocopy %systemroot%\system32\dns d:\backups\dns /S /ZB /XJ /R:2 /W:3 


Backup mit dnscmd :
dnscmd /zoneexport domain.de backup\domain.de.backup

Dieser Befehl erstellt die Datei %systemroot%\system32\dns\backup\domain.de.backup wichtig ist hierbei das die Datei nicht überschrieben wird sollte sie bereits existieren. Wenn man die Sicherung in einem Skript automatisiert ablaufen lassen will sollte man die Datei weg kopieren oder mit Datum ablegen.

Wenn man eine AD integrierte Zone wieder herstellen möchte geht man diesen Weg :

dnscmd /zoneadd domain.de /primary /file domain.de.backup /load

Hier gilt es zu beachten das die Datei %systemroot%\system32\dns\backup\domain.de.backup vorhanden ist. Der Parameter /load bewirkt das die Konfiguration aus der vorhandenen Datei übernommen wird. Vergisst man diesen wird eine neue Zonen Datei erstellt und das Backup File ist leer ...

Um diese Zone nun wieder auf AD integriert zu konvertieren nimmt man diesen Befehl :
dnscmd /zoneresettype domain.de /dsprimary


Quelle : mcpmap.com

ActiveDirectroy-CA: Umzug auf neuen Server mit neuem Namen

Problem:
Ich musste meine ActiveDirectory-CA auf einen neuen Server mit neuem Namen umziehen.
Dafür gibt es einige Anleitungen im Netz und ich habe mir eine Anleitung aus diesen gebaut, mit der ich gut gefahren bin.

Lösung:
Grundannahme hier ist der Umzug einer AD-CA von einem Server auf einen neuen, wodurch sich der Computername ändert und der alte Server außer Betrieb geht!

--- AKTIONEN AUF DEM ALTEN SERVER ---

1.) WICHTIG: Vorher Sicherung des alten Servers erstellen!!!
2.) CA-Datenbank und Key sichern


WICHTIG: Export der Konfiguration in einen leeren Ordner
3.) Registry-Key der alten CA sichern: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
4.) Templates exportieren mittels Befehl "certutil.exe –catemplates > templates.txt"
5.) CA deinstallieren oder zumindest deaktivieren


--- AKTIONEN AUF DEM NEUEN SERVER ---
1.) Backup-Ordner vom alten Server auf neuen kopieren (z.B. Desktop)
2.) Privaten Key (.P12-Datei im Backup-Ordner) importieren mittels Kennwort
3.) CA-Dienst als Rolle auf neuen Server installieren (Zertifikatsdienst + Webentrollment)
4.) Konfiguration der zuvor gesicherten CA wiederherstellen über CA-Konsole (Sieht aus wie Sicherung)
5.) Backup der Registry einspielen -WICHTIG: Hier müssen folgende Werte angepasst werden:
- CAServer-Eintrag auf neuen Namen ändern
- Eventuelle Pfadänderungen wie DBDirectory, DBTempDirectory anpassen
(Sollten Sie auf dem alten und neuen Server die Standard-Installation durchgeführt haben, dann ist keine Anpassung der Pfade nötig)
6.) Berechtigungen der CDP und AIA Container mittels ADSI-Editor auf neuen Server drehen
- Hierzu ADSI-Editor mit folgender Verbindung starten: CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
- Hier die Berechtigungen unter Sicherheit für die einzelnen Einträge unter CDP und AIA auf den neuen Server drehen.

Ich hatte noch einen Fehler in der pkiview.msc stehen, dass eine DeltaCRL-Location fehlerhaft ist. Das ist natürlich richtig, da die Location noch auf den alten Zertifikatsserver per http verweist. Man kann dann einfach eine neue komplette Sperrliste veröffentlichen und dann ist der Fehler auch weg! (Siehe Quellen-Link "How to Publish New Certificate Revocation List...")

FERTIG!

Quellen:
How to Publish New Certificate Revocation List (CRL) from Offline Root CA to Active Directory and Inetpub
Windows Root Zertifizierungsstelle migrieren/umziehen
Zertifizierungsstelle verschieben–neuer Servername
“Die Organisationen stecken Millionen von Dollars in Firewalls und Sicherheitssysteme und verschwenden ihr Geld, da keine dieser Maßnahmen das schwächste Glied der Sicherheitskette berücksichtigt: Die Anwender und Systemadministratoren.”
Kevin Mitnick