Logo faq-o-matic.net
Logo faq-o-matic.net

Domänen-Double für Testzwecke

von veröffentlicht am2. Mai 2016, 06:48 Uhr Kurzlink und Zitatlink einblenden
Kategorie Kategorie: Active Directory, Demo, PowerShell   Translate with Google Translate Translate EN   Die angezeigte Seite drucken

Vor fast zehn Jahren haben wir ein Verfahren beschrieben, mit dem sich Active-Directory-Testumgebungen erzeugen lassen, die in den wichtigsten Aspekten den echten Domänen entsprechen. In manchen Situationen reichen nämlich ein, zwei Testbenutzerkonten nicht aus, sondern es kommt auf die OU- und Gruppenstruktur an.

Unser damaliger Artikel hat dazu zwei Skripte aus den “GPMC Sample Scripts” eingesetzt:

[Active-Directory-Double als Testumgebung | faq-o-matic.net]
http://www.faq-o-matic.net/2006/12/17/active-directory-double-als-testumgebung/

Dieses Verfahren kann man immer noch gut einsetzen – es hat aber einen Nachteil: Die alten GPMC-Skripte kommen nicht mit Kommas in den Objektnamen klar. Während man dies bei den Benutzerkonten noch ausgleichen kann (das nötige Reparaturskript findet sich in unserem obigen Artikel), scheitern die Skripte endgültig, wenn es Kommas in den OU-Namen gibt.

Daher haben wir eine neue Lösung entwickelt, die mit beliebigen Sonderfällen bei den Objektnamen klarkommen sollte. Sie beschränkt sich auf den Ex- und Import von Benutzerkonten, Gruppen und der OU-Struktur. Anders als die GPMC-Skripte nimmt es die Gruppenrichtlinien nicht mit (die man aber auch nur selten im Labor braucht). Dafür berücksichtigt es mehr Details bei den Benutzerkonten.

Das Verfahren läuft in drei Schritten ab:

  1. Export der Objekte aus der Quelldomäne – üblicherweise aus der produktiven Domäne.
  2. Import der Objekte in die Zieldomäne – das ist die Laborumgebung.
  3. Optional: Aktivieren der importierten Benutzer und Setzen eines Standard-Kennworts

Wichtig: Das Verfahren ist ausdrücklich nur gedacht, um Objektstrukturen in eine Testumgebung zu übertragen! Es ist kein Migrationsverfahren für produktive Zwecke.

Unsere Lösung nutzt hauptsächlich das bordeigene Werkzeug csvde.exe, das schon seit Windows 2000 gute Dienste leistet, wenn es um den Ex- und Import von AD-Objekten geht. Das Tool hat allerdings zwei wichtige Einschränkungen: Es kann keine Kennwörter setzen, und es scheitert beim Ex- und Import von Gruppenmitgliedern, sobald die Gruppen etwas größer sind. Das verwandte Tool ldifde.exe könnte zwar die Gruppenmitglieder verarbeiten, aber es scheitert meist daran, die nötigen Ersetzungen bei den Domänennamen auszuführen. Für diese beiden Zwecke muss also die PowerShell ran.

Hier ist der Download:

Download: Import-ADObjectsForLab: PowerShell script for AD lab object creation  Import-ADObjectsForLab: PowerShell script for AD lab object creation (4,9 KiB, 942-mal heruntergeladen, letzte Änderung am 6. März 2016)

Einige kleine Anpassungen der Skripte sind erforderlich, bevor sie einsetzbar sind.

Export aus der Quelldomäne

Dieser Schritt ist aus Sicht der Sicherheit weitgehend unkritisch, denn er erzeugt nur Textdateien. Diese enthalten aber unter Umständen personenbezogene Daten. Kennwörter sind im Export auf keinen Fall enthalten.

Kopiere das Skript Export-ADObjectsForLab.ps1 in einen beliebigen Ordner und öffne es ist einem Texteditor. In dem Abschnitt “CUSTOMIZE HERE” trägst du in die Variable $OUtoStart den LDAP-Namen (distinguishedName) der OU ein, von dem aus die Objekte exportiert werden sollen. Soll der Export die ganze Domäne betreffen, dann gib den LDAP-Namen der Domäne an. Beispiel:

$OUtoStart = 'OU=Firma,DC=lab,DC=faq-o-matic,DC=net'

Speichere das bearbeitete Skript.

Anmerkung: In den drei folgenden Zeilen kannst du die Attribute anpassen, die der Export enthält. Dabei solltest du die erforderlichen Attribute aber nicht entfernen. Für das Hinzufügen eignen sich nur einwertige Attribute (single-valued), und zwar vorrangig Textfelder. In den meisten Fällen dürfte die vorhandene Auswahl ausreichen.

Starte die PowerShell oder die PowerShell ISE mit einem Konto, das im AD die Objekte lesen kann (ein normales Benutzerkonto reicht üblicherweise aus). Wechsle in den Skriptordner. Sofern noch nicht geschehen, musst du die Ausführung von Skripten zulassen:

Set-ExecutionPolicy RemoteSigned

Dann führe das Skript aus:

.\Export-ADObjectsForLab.ps1

Im Skriptordner sollten sich nun vier Dateien befinden:

  • OUs.txt
  • Users.txt
  • Groups.txt
  • Members.txt

Sofern erfoderlich, setze die Ausführungsrichtlinie der PowerShell zurück:

Set-ExecutionPolicy Restricted

Import in die Zieldomäne

Achtung: Dieser Schritt importiert zahlreiche Objekte in die Zieldomäne. Dies wirkt sich auf die Sicherheit der Domäne aus. Das geschieht auf eigene Gefahr!

Kopiere das Skript Import-ADObjectsForLab.ps1 in einen beliebigen Ordner auf einem Rechner in der Zieldomäne. Öffne das Skript mit einem Texteditor.

Das Skript importiert OUs, Benutzer und Gruppen. Wenn die Zieldomäne anders heißt als die Quelldomäne, musst du den Skriptcode in dem Bereich “CUSTOMIZE HERE” anpassen. Trage die LDAP-Namen (distinguishedName) der Quell- und der Zieldomäne in die Variablen $FromDN und $ToDN ein. Beispiel:

$FromDN = 'DC=lab,DC=faq-o-matic,DC=net'
$ToDN = 'DC=MSC,DC=demo'

Falls beide Domänen denselben Namen haben oder falls du die Objekte wieder in die Quelldomäne importierst, lasse beide Strings leer. Beispiel:

$FromDN = ''
$ToDN = ''

Speichere das Skript. Kopiere dann die vier Textdateien aus der Quelldomäne in den Skriptordner:

  • OUs.txt
  • Users.txt
  • Groups.txt
  • Members.txt

Starte die PowerShell oder die PowerShell ISE mit einem Konto, das über Domänen-Admin-Rechte verfügt. Wechsle in den Skriptordner. Setze, falls erforderlich, die Ausführungsrichtlinie so, dass du das Skript ausführen kannst:

Set-ExecutionPolicy RemoteSigned

Dann führe das Skript aus:

.\Import-ADObjectsForLab.ps1

Das Skript nutzt csvde.exe, um die OUs, Benutzer und Gruppen zu erzeugen. Dann fügt es per PowerShell die Gruppenmitglieder hinzu; hierbei erscheint ein Fortschrittsbalken. Der Vorgang kann eine ganze Weile dauern.

Abschließend setze, falls erforderlich, die Ausführungsrichtlinie wieder zurück:

Set-ExecutionPolicy Restricted

Benutzerkonten aktivieren

Achtung: Dieser optionale letzte Schritt aktiviert die Benutzerkonten und setzt bei allen dasselbe Kennwort. Dies betrifft die Sicherheitseinstellungen der Domäne!

Das Importskript hat alle Benutzerkonten deaktiviert und mit leerem Kennwort erzeugt. Um sie zu aktivieren, musst du ein Kennwort setzen und die Konten dann aktiv schalten. Das letzte Skript führt dies in einer Laborumgebung in einem Schritt durch.

Kopiere das Skript Set-PasswordForAllLabUsers.ps1 in einen beliebigen Ordner auf einem Rechner in der Zieldomäne. Öffne das Skript mit einem Texteditor.

Trage im Bereich “CUSTOMIZE HERE” die OU ein, in der die Objekte liegen. Beispiel:

$OUtoStart = 'OU=Firma,DC=lab,DC=faq-o-matic,DC=net'

Trage in die Variable $LabPassword das Standardkennwort ein. Beispiel:

$LabPassword = 'abc123!'

Speichere das Skript. Starte die PowerShell oder die PowerShell ISE mit einem Konto, das über Domänen-Admin-Rechte verfügt. Wechsle in den Skriptordner. Setze, falls erforderlich, die Ausführungsrichtlinie so, dass du das Skript ausführen kannst:

Set-ExecutionPolicy RemoteSigned

Dann führe das Skript aus:

.\Set-PasswordForAllLabUsers.ps1

Das Skript verlangt eine Bestätigung, um loszulegen. Es zeigt einen Fortschrittsbalken an.

Abschließend setze, falls erforderlich, die Ausführungsrichtlinie wieder zurück:

Set-ExecutionPolicy Restricted

© 2005-2023 bei faq-o-matic.net. Alle Rechte an den Texten liegen bei deren Autorinnen und Autoren.

Jede Wiederveröffentlichung der Texte oder von Auszügen daraus - egal ob kommerziell oder nicht - bedarf der ausdrücklichen Genehmigung durch die jeweiligen Urheberinnen oder Urheber.

Das Impressum findet sich unter: http://www.faq-o-matic.net/impressum/

Danke, dass du faq-o-matic.net nutzt. Du hast ein einfaches Blog sehr glücklich gemacht!