May 13, 2019

6138

WDS unattended

Servus,

ich möchte mein Win10 Image im WDS gerne mit unattended File versehen, damit ich vor allem die nervigen Datenschutzfragen los werde aber auch sonst das ganze automatisiere. Klappt auch soweit aber leider joined er jetzt nicht mehr der domain. Im Netz habe ich enige gefunden die das gleiche Problem haben aber der einzige Workaround war ein PS Script ins Image einzubetten was den Join macht. Ich möchte aber nur ungern meine DomainAdmin Credentials in einem File speichern und ausliefern (selbst wenn es dann automatisch löschen lasse). Kennt jemand einen Weg das in der XML zu realisieren am besten mit den Anmeldeinformationen die beim PXE Boot eh schon mitgegeben wurden, so wie es ohne XML eben auch läuft.

Vielen Dank im Voraus!

Please also mark the comments that contributed to the solution of the article

Content-Key: 451126

Url: https://administrator.de/contentid/451126

Printed on: April 26, 2024 at 13:04 o'clock

22 Comments

Latest comment

Ich verstehe deinen Gedankenansatz zum Thema Sicherheit hier nicht wirklich.

Ob das ganze jetzt in einem PS Script ist oder in einer XML, in beiden Fällen sind die Credentials eines Admin Kontos in Klartext angeben.
Also keinerlei Sicherheitsgewinn wenn du von PS zu XML wechselst.

Und was meinst du denn mit Anmeldeinformationen beim PXE boot?
Beim PXE boot wird vom DHCP der PXE Server und die Imagefile auf einem TFTP übergeben sonst nichts.
Und von diesen Daten kann auch nichts übernommen werden.

Hm, soweit ich weiß kann man unter Powershell Passwortangaben verschlüsseln, sodass das Passwort NICHT im Klartext übermittelt wird.
Da kann ein Powershellexperte mehr dazusagen.

Gruss Penny.

Moin,

in der PS kannst Du das Passwort verschlüsselt übergeben. Hier ein kleines Skript zum Erzeugen der Textdatei:

# Skript zum Erzeugen einer verschlüsselten Passwortdatei

$Secure = Read-Host -AsSecureString -prompt "Password:"  
$encrypted = ConvertFrom-SecureString -SecureString $Secure -key (1..16)
$encrypted | out-file Encrypted.txt

Das Ganze kannst Du dann in einem anderen Skript so benutzen:

$pw = Get-Content Encrypted.txt | ConvertTo-SecureString -key (1..16)

$cred = New-Object System.Management.Automation.PSCredential("Benutername", $pw)  

add-computer -computername local_machine -domainname ace.com -credential $cred -restart -force

Um das Ganze noch sicherer zu machen, lege ich die Rechner im AD immer vor dem Einbinden an und vergebe das Recht, die Rechner in die Domain einzufügen an einen eingeschränkten User, der ansonsten nichts darf. Das verhindert dann auch noch, dass man beim händischen Einfügen sich vertippt.

hth

Erik

P.S.: Bitte beachten, dass bei Skripts, die in einer anderen Umgebung laufen, absolute Pfade angesagt sind, damit das Skript die Dateien auch findet.

Hallo Bem0815,

der WDS ist ein PXE Server von Microsoft welcher nach dem Start die Authentifizierung abfragt und diese Informationen im Normalfall benutzt um automatisch der Domäne beizutreten bei der Installation. Das funktioniert normalerweise auch aber leider nicht mit dem XML.

Ich möchte weder im XML File noch im Powershellscript die Anmeldeinformationen hinterlegen. Nicht als Securestring und schon zwei Mal nicht im Klartext. Aber selbst wenn wäre es besser die Informationen geschützt auf dem Server abzulegen (XML) als mit jedem Image (PS) auf die Clients zu pushen. Ich suche nach einer Möglichkeit um das Standardverhalten bei der Nutzung des XML Files in gang zu bekommen.

Ist mir schon bekannt wie ein WDS über PXE bootet, das hat aber an der Stelle nichts mehr mit PXE boot zu tun ;)
Wenn diese Daten vom WDS übergeben werden sind wir schon längst im Image und über PXE hinaus.

Einen der beiden Tode wirst du aber sterben müssen. Mir ist keine alternative bekannt.
Am besten nutzt du die Verschlüsselung vom Passwort in PS wie es bereits vorgeschlagen wurde.

Zitat von @LeeX01:

Hallo Bem0815,

der WDS ist ein PXE Server von Microsoft welcher nach dem Start die Authentifizierung abfragt und diese Informationen im Normalfall benutzt um automatisch der Domäne beizutreten bei der Installation. Das funktioniert normalerweise auch aber leider nicht mit dem XML.

Was heißt das jetzt genau? Machst Du PXE Boot aus der Cloud? Entschuldige, das klingt verworren.
Wenn Du einen WDS Server intern in der Domäne einsetzt, ist das doch egal. WDS und MDT kommen beide von Microsoft. Und es gibt große Unternehmen, welche MDT einsetzen.

Gruss Penny.

Hi Erik,

das wird bei uns leider nicht funktionieren, da viele Leute mit unterschiednlichen Accounts arbeiten. Ich würde das Passwort nur sehr ungern als SecureString im Image ablegen. Das könnte man sehr leicht raus holen und missbrauchen oder es kann Probleme geben wenn das Passwort geändert wird.

Beste Grüße

Zitat von @LeeX01:

Hi Erik,

das wird bei uns leider nicht funktionieren, da viele Leute mit unterschiednlichen Accounts arbeiten. Ich würde das Passwort nur sehr ungern als SecureString im Image ablegen. Das könnte man sehr leicht raus holen und missbrauchen

Nein kann man nicht. Mir ist jedenfalls KEINE Methode dazu bekannt. Mal sehen was ein Powershellexperte dazu schreibt.

Beste Grüße

Gruss Penny.

Hallo Penny,

Ein WDS ist ein Server von Microsoft, welcher...
Unser WDS steht im Haus. MDT ist (bisher) nicht im Einsatz.

Grüße

Moin,

Zitat von @LeeX01:

Hi Erik,

das wird bei uns leider nicht funktionieren, da viele Leute mit unterschiednlichen Accounts arbeiten.

Was ich meinte, war ein User, der nur dafür da ist, Computer in die Domain einzubinden und sonst nichts in der Domain darf. Den kannst Du ja hart in das Skript schreiben.

Ich würde das Passwort nur sehr ungern als SecureString im Image ablegen. Das könnte man sehr leicht raus holen und missbrauchen

Nö.

oder es kann Probleme geben wenn das Passwort geändert wird.

Dann setze das Flag "Kann Passwort nicht ändern."

Liebe Grüße

Erik

Zitat von @Penny.Cilin:

Nein kann man nicht. Mir ist jedenfalls KEINE Methode dazu bekannt. Mal sehen was ein Powershellexperte dazu schreibt.

Das ich das Passwort nicht zurück bekomme in Klartext ist klar aber wenn die Inforationen im Script sind kann ich das Script so abändern dass die Authentifizierungsinformationen einfach für etwas anderes benutzt werden.

Was ich meinte, war ein User, der nur dafür da ist, Computer in die Domain einzubinden und sonst nichts in der Domain darf. Den kannst Du ja hart in das Skript schreiben.

Das wäre eine Option

Moin,

Zitat von @Penny.Cilin:

Zitat von @LeeX01:
das wird bei uns leider nicht funktionieren, da viele Leute mit unterschiednlichen Accounts arbeiten. Ich würde das Passwort nur sehr ungern als SecureString im Image ablegen. Das könnte man sehr leicht raus holen und missbrauchen

Nein kann man nicht. Mir ist jedenfalls KEINE Methode dazu bekannt. Mal sehen was ein Powershellexperte dazu schreibt.

Das Passwort zu entschlüsseln, dürfte unmöglich sein. Mir wäre auch nicht bekannt, dass das geknackt wurde. Allerdings besteht die Gefahr, dass jemand, der die Datei abfischt, diese nutzt, um sich ein Credential zu erzeugen und dann zum Beispiel so:

New-PSDrive -Name x: -PSProvider FileSystem -Root unc-pfad -Credential $cred -persist -scope Global

Zugriff auf eine Freigabe zu verschaffen. Dazu muss er dann aber wissen, zu welchem User die Datei gehört.

Deshalb ja auch mein Vorschlag, die Computer nicht von einem Admin-Account, sondern von einem, der nur das darf, einbinden zu lassen. Dann ist die Gefahr auch vom Tisch. Selbst wenn jetzt jemand die Datei abfischt und herausfindet, welcher User dazu gehört, hat er nichts gewonnen.

Liebe Grüße

Erik

Hallo LeeX01,

wenn du mit den nervigen Datenschutzfragen die Express Settings (z.B. Positionsbestimmung, Handschrifterkennung,..) bei der installation meinst, das kannst du mit der Option ProtectYourPC "3" abschalten.

Im Windows System Image Magerer kann man bei den Eigenschaften von Password die Option PlainText auf false stellen, dann wird das Passort verschlüsselt abgespeichert. Die Passwörter in der Datei werden von Windows bei der Installation zusätzlich gelöscht. Keine Ahnung, wie sicher das ist.

Gruss Blair

Moin,

Ich möchte aber nur ungern meine DomainAdmin Credentials in einem File speichern und ausliefern (selbst wenn es dann automatisch löschen lasse).

wenn ich diesen Satz schon lese, stellt es mir die Haare auf. Für solche Zwecke nutzt man einen separaten Servicebenutzer. Dieser hat keine weiteren Gruppenzugehörigkeiten als Domänen-Benutzer. Über eine Delegierung im Active Directory gibst du ihm die notwendigen Rechte um Computer in die Domäne aufzunehmen.

Gruß,
Dani

Zitat von @Dani:

Moin,

Ich möchte aber nur ungern meine DomainAdmin Credentials in einem File speichern und ausliefern (selbst wenn es dann automatisch löschen lasse).

wenn ich diesen Satz schon lese, stellt es mir die Haare auf. Für solche Zwecke nutzt man einen separaten Servicebenutzer.

Sach ich doch schon die ganze Zeit.

Das wäre in der Tat die sinnvollste Variante.

Mit XML würde das soweit ich das mal gelesen haben in dieser Form mit Windows 10 auch nicht mehr korrekt funktionieren, aber schlagt mich nicht falls ich da falsch liege :D

Dabei ging es wohl um folgendes Problem in der Setuproutine:

Windows 10 generiert nach dem Sysprep in der Phase 7 (OOBE) noch einmal einen neuen Computernamen, obwohl in der Phase 4 (specialize) der Domain-Join bereits mit einem anderen Computernamen erfolgreich vollzogen wurde.

Sprich wenn das Setup dann durchgelaufen ist, ist der PC dennoch nicht in der Domäne, da der PC Name sich still und heimlich geändert hat ohne dass der DC davon etwas weiß.

Sorry, dass ich hier nochmal reingrätsche. Aber ein Passwort, das als SecureString abgelegt ist, kann locker in Klartext zurückgeholt werden:

#verschlüsselte Passwortdatei erzeugen:
$Secure = Read-Host -AsSecureString -prompt "Password:"  
$encrypted = ConvertFrom-SecureString -SecureString $Secure -key (1..16)
$encrypted | out-file Encrypted.txt


#Passwort extrahieren:
$password = Get-Content "Encrypted.txt" | ConvertTo-SecureString -key (1..16)  
$cred = New-Object -Typename System.Management.Automation.PSCredential -Argumentlist "AnyGuy",$password  
$cred.GetNetworkCredential().password

Glück auf

Ankh

Aber ein Passwort, das als SecureString abgelegt ist, kann locker in Klartext zurückgeholt werden:

Aber nur mit dem Account mit dem der Secure-String auch erstellt wurde

. Denn die Verschlüsselung basiert auf einem Token das in einem sicheren Bereich des Useraccounts des Users abgelegt wird der den Secure-String als Plaintext erstellt hat.

Hiermit geht das Extrahieren übrigens auch direkt

[System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR((ConvertTo-SecureString -String (Get-Content "C:\encrypted.txt" -raw))))

Aber nur mit dem Account mit dem der Secure-String auch erstellt wurde

. Denn die Verschlüsselung basiert auf einem Token das in einem sicheren Bereich des Useraccounts des Users abgelegt wird der den Secure-String als Plaintext erstellt hat.

Richtig! Danke für die Ergänzung.

Das läßt sich m.W. aber mit der Zugabe von -Key / -SecureKey ändern.

Das läßt sich m.W. aber mit der Zugabe von -Key / -SecureKey ändern.

Das führt das ganze dann aber adabsurdum, da kannst du dann auch gleich das Passwort mit ins Skript schreiben

Zitat von @140913:
Das führt das ganze dann aber adsabsurdum, da kannst du dann auch gleich das Passwort mit ins Skript schreiben

Was wieder einmal beweist, dass Scriptsprachen und Passwörter nicht in den selben Topf gehören.

German Question Windows 10 Microsoft