Lokaler Administrator PW ändern
Moin zusammen,
ich habe vor, das lokale Administrator Konto auf Win7 & Win10 Clients zu aktivieren und ihm ein Kennwort zu setzen.
Mein bisheriger Ansatz hierfür ist ein Powershell Script, da noch etwaige andere Aufgaben durchgeführt werden sollen.
Mein derzeitiger Entwurf:
Dabei kommt dann von der Powershell die Rückmeldung
Welche ich schon alleine aus dem Grund nicht verstehe, dass wenn ich den SecureString nicht aus einem Hash bilde, sondern im selben Kontext den String des PW mit ConvertTo-SecureString zu einem Securestring konvertiere nicht diese Meldung bekomme.
Nach ein wenig Googlen habe ich die Aussage gefunden "you just need to decode it before you pass it to setpassword:" (Quelle: https://social.technet.microsoft.com/Forums/windowsserver/en-US/08dea4fd ..)
Somit sieht mein Meisterwerk nun so aus:
Dieser funktioniert auch soweit. Mein Problem ist nur, dass ich, falls das Script mal in die Hände von unauthorisierten Personen gelangt, diesen nicht alle Werkzeuge an die Hand geben mag, um das Passwort der Clients rauszubekommen.
Hätte jemand von euch eine elegantere Methode?
Am liebsten wäre mir natürlich etwas, was ich in Powershell einbetten kann, da ich, wie bereits erwähnt, noch andere Dinge in dem Script ändere.
Vielen Dank schon mal für Eure Anregungen
Oni
ich habe vor, das lokale Administrator Konto auf Win7 & Win10 Clients zu aktivieren und ihm ein Kennwort zu setzen.
Mein bisheriger Ansatz hierfür ist ein Powershell Script, da noch etwaige andere Aufgaben durchgeführt werden sollen.
Mein derzeitiger Entwurf:
$pwhash = '01000000d08c9ddf0115d1118c7a00c04fc297eb010000004350806c89c0564993ba67dc4eaa65570000000002000000000003660000c0000000100000004ea68425aa46bf9ef0c0176cab0ee4670000000004800000a00000001000000046c146556c3cfdd0fff6502955bd612d180000009ddb6c51d0a889539f70aa50125cb368149056312430d6661400000065d86d9b1b73f7a250a5d4deb4ec127b859e8aaf'
$pw = $pwhash | ConvertTo-SecureString
$ObjUser = [ADSI]"WinNT://$env:computername/Administrator"
$objUser.setpassword($pw)
$objUser.userflags = 512
$objUser.setinfo()
Dabei kommt dann von der Powershell die Rückmeldung
Ausnahme beim Aufrufen von "setpassword" mit 1 Argument(en): "Typenkonflikt. (Ausnahme von HRESULT: 0x80020005 (DISP_E_TYPEMISMATCH))"
In Zeile:5 Zeichen:1
+ $objUser.setpassword($pw)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) , MethodInvocationException
+ FullyQualifiedErrorId : CatchFromBaseAdapterMethodInvokeTI
Welche ich schon alleine aus dem Grund nicht verstehe, dass wenn ich den SecureString nicht aus einem Hash bilde, sondern im selben Kontext den String des PW mit ConvertTo-SecureString zu einem Securestring konvertiere nicht diese Meldung bekomme.
Nach ein wenig Googlen habe ich die Aussage gefunden "you just need to decode it before you pass it to setpassword:" (Quelle: https://social.technet.microsoft.com/Forums/windowsserver/en-US/08dea4fd ..)
Somit sieht mein Meisterwerk nun so aus:
$pwhash = '01000000d08c9ddf0115d1118c7a00c04fc297eb010000004350806c89c0564993ba67dc4eaa65570000000002000000000003660000c0000000100000004ea68425aa46bf9ef0c0176cab0ee4670000000004800000a00000001000000046c146556c3cfdd0fff6502955bd612d180000009ddb6c51d0a889539f70aa50125cb368149056312430d6661400000065d86d9b1b73f7a250a5d4deb4ec127b859e8aaf'
$pw = $pwhash | ConvertTo-SecureString
$ObjUser = [ADSI]"WinNT://$env:computername/Administrator"
$objUser.setpassword([System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($pw)))
$objUser.userflags = 512
$objUser.setinfo()
Dieser funktioniert auch soweit. Mein Problem ist nur, dass ich, falls das Script mal in die Hände von unauthorisierten Personen gelangt, diesen nicht alle Werkzeuge an die Hand geben mag, um das Passwort der Clients rauszubekommen.
Hätte jemand von euch eine elegantere Methode?
Am liebsten wäre mir natürlich etwas, was ich in Powershell einbetten kann, da ich, wie bereits erwähnt, noch andere Dinge in dem Script ändere.
Vielen Dank schon mal für Eure Anregungen
Oni
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 337506
Url: https://administrator.de/contentid/337506
Ausgedruckt am: 23.11.2024 um 01:11 Uhr
3 Kommentare
Neuester Kommentar
Moin,
ich regel das zentral per Local Administrator Password Solution (LAPS).
https://www.microsoft.com/en-us/download/details.aspx?id=46899
Funktioniert wunderbar.
ich regel das zentral per Local Administrator Password Solution (LAPS).
https://www.microsoft.com/en-us/download/details.aspx?id=46899
Funktioniert wunderbar.
Zitat von @ArnoNymous:
ich regel das zentral per Local Administrator Password Solution (LAPS).
https://www.microsoft.com/en-us/download/details.aspx?id=46899
Würde ich auch zu raten.ich regel das zentral per Local Administrator Password Solution (LAPS).
https://www.microsoft.com/en-us/download/details.aspx?id=46899
Oder von User @DerWoWusste gibt's hier auch eine Alternative
Sicherer Umgang mit Supportkonten
Mein Problem ist nur, dass ich, falls das Script mal in die Hände von unauthorisierten Personen gelangt, diesen nicht alle Werkzeuge an die Hand geben mag, um das Passwort der Clients rauszubekommen.
Das bringt denen nichts solange sie nicht an das Konto gelangen mit dem der Secure-String erzeugt wurde, denn nur das Konto/Profil des Users welcher den SecureString erstellt hat kann damit das richtige Plaintext-Passwort zurückrechnen.Gruß
Hallo,
Wenn denn auf den PC ueberhaupt solche Konten existent sein sollen ist LAPS wohl der einzige vernuenftige Weg und der Ansatz von @DerWoWusste eine Alternative.
Wir "misten" gerade ein groesseres Netzwerk aus und per "Stallorder" soll es in Zukunft keinerlei lokale Administration an den PC geben. Das ist ein Gejammere dort
BFF
Wenn denn auf den PC ueberhaupt solche Konten existent sein sollen ist LAPS wohl der einzige vernuenftige Weg und der Ansatz von @DerWoWusste eine Alternative.
Wir "misten" gerade ein groesseres Netzwerk aus und per "Stallorder" soll es in Zukunft keinerlei lokale Administration an den PC geben. Das ist ein Gejammere dort
BFF