Local Password Tool

Comments

14 comments

  • TonsOFun

    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

     

     

    0
    Comment actions Permalink
  • Shane Corellian

    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:yes

    See attached image.

    0
    Comment actions Permalink
  • Shane Corellian

    TonsOFun, thanks for answering already. I didn't catch that. 

    -Shane

     

    0
    Comment actions Permalink
  • George Kehl

    Can you make it so there is a prompt for the password?

    net user Administrator *

    0
    Comment actions Permalink
  • Karson VanMeeteren

    If you leverage the remote command feature of PDQ deploy and the posted "net user" command, is the password still sent as plaintext over the wire?  Or, does the remote command feature have some sort of security layer that masks the commands?

    0
    Comment actions Permalink
  • Brandon Rewis

    Karson,

    I will research whether or not the password is encrypted when sent via remote command. I will let you know what I find.

    0
    Comment actions Permalink
  • Karson VanMeeteren

    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.

     

    0
    Comment actions Permalink
  • Shawn Anderson

    Trust issues would normally mean that the trust relationship between the computer and domain have been broken. You can quickly fix this by detaching the computer from AD and then rejoining it. That should restore the trust relationship. (This more commonly occurs on VM's.)

    0
    Comment actions Permalink
  • Joel Johnson
    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).
    0
    Comment actions Permalink
  • Alan Olmsted

    Was there ever an answer to Karson's question about the password being encrypted or plain text?  Thanks.

    0
    Comment actions Permalink
  • Shane Corellian

    Hi Alan,

    No, there isn't encryption for remote commands. 

    0
    Comment actions Permalink
  • John Dole

    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?

    0
    Comment actions Permalink
  • Bob McCoy

    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.

    0
    Comment actions Permalink
  • Claus Jensen

    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.

     

     

     

    0
    Comment actions Permalink

Please sign in to leave a comment.