Local Password Tool
Not planned
A utility to change the local administrator password and enable the account would be great. Much like the logoffusers tool.
-
In case you needed something to use right now, here's a simple script from a batch file that i'm using.
---------Start--------
net user administrator /active:yes
net user administrator <password>
--------End-----------
First line enables the administrator account.
Second line sets the password.
Other commands for "Net user" can be located here: http://support.microsoft.com/kb/251394
-
The reason we haven't done this is that we don't want to place a default password that someone just deploys without changing.
You can, however, very easily build this package. Create a new Package, add a Command Step. Delete the original Install Step. Use the following commands in your Command Step. Obviously, replace the NewPassword! with your new password.
net user Administrator NewPassword!
net user Administrator /active:yesSee attached image.
-
Thanks Brandon. I fired up Wireshark on a remote computer and scanned for the password, but we're in the middle of a enterprise domain migration and I seem to be having trust issues with the service account credentials I normally use in PDQ, or any credentials for that matter.
I'll keep you posted as well as subscribing to this thread.
-
Actually, for those trust relationship issues, you don't actually need to detach from AD (which in itself can cause issues especially, if the local admin credentials aren't known). Instead run the Network ID wizard from the same tab in System Properties. It will then resync the computer account with AD. Can't recall if it results in any reboots when using the Network ID wizard but the detaching process does, which might not be desirable (two reboots under Win7 - one when removing from AD and another when adding back in. you can skip the first reboot with WinXP). And an easy way to get past the Trust Relationship error when trying to login - unplug the network cable and turn off wifi, then login (Windows will then revert to using the cached credentials without testing the trust relationship). -
What about creating and compiling a powershell script that contains the password - then transferring this to the local computer and running it locally? This way the password is compiled in the powershell exe - and then run locally so that the password is not transferred over the wire?
-
PowerShell is not a viable option here. Unless you specify a key (which brings up all sorts of key management issues), PowerShell uses DPAPI. The upshot of that is the password can only be decrypted on the same machine it was encrypted upon AND in the same user context. That is not a viable deployment scenario.
-
Hi Guys
MS have addressed this issue with Local Administrator Password Solution (LAPS): https://technet.microsoft.com/en-us/library/security/3062591.aspx
Our friends at 4sysops have a great guide on how to implement:
https://4sysops.com/archives/introduction-to-microsoft-laps-local-administrator-password-solution/But as always it would be a charm to download the msi's directly from AA, instaed of having to build the packages ourself. Dont we all love click->import :-)
So I hereby suggest that we get the LAPS installers in PDQ deploy.
Post is closed for comments.
Comments
14 comments