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
Please also mark the comments that contributed to the solution of the article
Content-Key: 337506
Url: https://administrator.de/contentid/337506
Printed on: May 8, 2024 at 05:05 o'clock
3 Comments
Latest comment
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