Jump to content

Running PowerShell from Autoit doesn't always work


PawelD
 Share

Recommended Posts

Hello,

I wrote a PowerShell script which changes the PC name. Since that script contains domain admin credentials I wrapped it in AutoIT. I honestly can't understand why it works only some of the times?

Some of the times on a new Windows 10 PC it will work just fine, and other times it comes up with a PowerShell window saying it doesn't recognise basic PS commands? Testing this on a VM, worked fine yesterday. Today I flattened that VM and imaged again to test some more things further down the line and now it doesn't work again.

Also made another script which re-formats a drive. Same story, PowerShell says it doesn't recognise a get-disk command where if I type it in manually it works :)

Here's the script, maybe you can tell me what's wrong with it:

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <EditConstants.au3>
#include <StaticConstants.au3>
#include <file.au3>
#include <array.au3>
#include <Constants.au3>
#include <FileConstants.au3>

$computername = InputBox ( "PC Name" ,"Please enter the PC name",@ComputerName )
            if stringlen ( $computername ) <> 12 Then
                Do
                    msgbox ( 0, "Invalid Name" , "Store PCs have 12 characters" )
                    $computername = InputBox ( "PC Name" , "Please enter the PC name", $computername )
                Until stringlen ( $computername ) = 12

            endif

$storerole = StringMid ( $computername, 6 , 3 )
            if StringIsAlpha ( $storerole ) = 0 Then
                Do
                    msgbox ( 0, "Invalid Name" , "Store role contains numbers or name too short, please correct" )
                    $computername = InputBox ( "PC Name" , "Please enter the PC name", $computername )
                    $storerole = StringMid ( $computername, 6 , 3 )
                Until StringIsAlpha ( $storerole ) <> 0 And stringlen ( $computername ) = 12
            endif


$cmd = "$user = 'domain\username'"&@CRLF& _
        "$password = 'AdminPassword'"&@CRLF& _
        '$securepassword = ConvertTo-SecureString $password -AsPlainText -force'&@CRLF& _
        '$credential = New-Object System.Management.Automation.PSCredential($user, $securepassword)'&@CRLF& _
        'Rename-Computer -ComputerName . -NewName '&$computername&' -DomainCredential $credential'

RunAsWait("user","domain","password",0,'PowerShell.exe -command '&$Cmd, "", @SW_MAXIMIZE)

image.png.2e7f10ad9be91fd7d5dee2dc2fb16b55.png

 

Link to comment
Share on other sites

  • Moderators

Without seeing the PS code it is a bit difficult to troubleshoot. Hard coding the domain creds in an AutoIt script is not exactly secure, however. You would probably be better off simply creating an encrypted key ahead of time and then calling it in your PS Script. You could do something like this to create your key:

# Prompt you to enter the username and password
    $credObject = Get-Credential

# The credObject now holds the password in a ‘securestring’ format
    $passwordSecureString = $credObject.password

# Define a location to store the AESKey
    $AESKeyFilePath = “MyPath\aeskey.txt”

# Define a location to store the file that hosts the encrypted password
    $credentialFilePath = “MyPath\credpassword.txt”

# Generate a random AES Encryption Key.
    $AESKey = New-Object Byte[] 32
    [Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($AESKey)

# Store the AESKey into a file. ACL on the file to allow only select people to read
    Set-Content $AESKeyFilePath $AESKey # Any existing AES Key file will be overwritten
    $password = $passwordSecureString | ConvertFrom-SecureString -Key $AESKey
    Add-Content $credentialFilePath $password

You can then call it in your script or through a module like so:

#Path to AES Key
    $AESKeyFilePath = 'MyPath\aeskey.txt'

#Path to Secure File
    $SecurePwdFilePath = 'MyPath\credpassword.txt'

#User account login 
    $userUPN = "Domain\Admin" 

#use key and password to create local secure password
    $AESKey = Get-Content -Path $AESKeyFilePath 
    $pwdTxt = Get-Content -Path $SecurePwdFilePath
    $securePass = $pwdTxt | ConvertTo-SecureString -Key $AESKey

#create a new psCredential object with required username and password
    $creds = New-Object System.Management.Automation.PSCredential($userUPN, $securePass)

The important thing is, once you create the AES key and Secure Password files, change the ACLs immediately so that only the script can read them.

"Profanity is the last vestige of the feeble mind. For the man who cannot express himself forcibly through intellect must do so through shock and awe" - Spencer W. Kimball

How to get your question answered on this forum!

Link to comment
Share on other sites

Also the PS code is below. Works as intended when ran from PS directly. Wanted to use AutoIT to 'hide' credentials in an exe file and also get an easy msg box for entering the name :)

$user = 'domain\username'
$password = 'AdminPassword'
$securepassword = ConvertTo-SecureString $password -AsPlainText -force
$credential = New-Object System.Management.Automation.PSCredential($user, $securepassword)
Rename-Computer -ComputerName . -NewName $computername -DomainCredential $credential

All commands above are standard, no need to import any modules etc.

Link to comment
Share on other sites

2 hours ago, PawelD said:

RunAsWait("user","domain","password",0,'PowerShell.exe -command '&$Cmd, "", @SW_MAXIMIZE)

That was the problem I think. Replaced it with a simple RunWait and it seems to be happy. I found out that the particular domain admin user I chose to run this as doesn't have local logon rights so script operation was probably dependant on how quickly the group policy got applied, hence the unpredictable behaviour.

Thanks for your help, I'll definitely take your post on board regarding using encrypted keys.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...