AutomoxAutomox
Find & Share WorkletsSolved

Local Powershell command works, but not via Automox.

Eric_Ferrari
December 3, 2021 at 9:49 am UTC
#community#powershell

Hi,

I am trying to run the following command with Powershell to remove a specific user from the Administrators group:

1 line
Remove-LocalGroupMember -Group Administrators -Member chnlocaladmin

When I run this with elevated permissions (SYSTEM) in Powershell on the machine itself, it works perfectly fine. However, deploying it via a worklet in Automox does not work. 

My worklet:

Evaluation Code:

1 line
1. Exit 1

Remediation Code:

1 line
1. Remove-LocalGroupMember -Group Administrators -Member chnlocaladmin

When I run this manually, the local user is still part of the administrators groups. I gave it a few minutes to run and still nothing. Running the same command locally works fine. 

Any ideas what could be going wrong?

This discussion is archived and closed to replies. Continue it in the Automox Community Slack.

Discuss on Slack

Replies (6)

jack.smithDecember 9, 2021
#1

I’ve used the following to gain insight into what might be going on.

 

start-transcript C:\windows\temp\worklet-transcript.txt

stop-transcript

 

Could also try to fallback to net commands.

 

net localgroup Administrators user.name /DELETE

Eric_FerrariDecember 16, 2021
#2

Thank you so much! 

The net command worked. Just confused as to why it didn’t like the the other command. 

jack.smithDecember 16, 2021
#3

It could have something to do with this

The Microsoft.PowerShell.LocalAccounts module is not available in 32-bit PowerShell on a 64-bit system.

from

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/remove-localgroupmember?view=powershell-5.1

 

Which if you find that to be true I’d encourage you check-out the 64-bit registry workaround here https://support.automox.com/help/enforce-windows-registry-settings-worklet. Keep in mind when using this method, EDR tools might pick it up as suspicious traffic as this executes the code as an encoded command. I’ve had fun building filters for Automox commands issued this way as this is very handy for some registry keys.

 

powershell7 lines
#### 64-bit code

$scriptBlock = {
    Remove-LocalGroupMember -Group Administrators -Member chnlocaladmin
}

$64bit = & "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -WindowStyle Hidden -NoProfile -NonInteractive -Command $scriptBlock
Eric_FerrariDecember 16, 2021
#4

Thanks for the info. 

Unfortunately, our EDR already flags the commands being run regardless. I’ve set up the worklet to run on a schedule, so we’ll be monitoring the alerts and then we’ll tinker with the detections if need be.

Thanks again!

Eric_FerrariDecember 17, 2021
#5

@jack.smith  After doing some more testing, it seems as though the users are unable to sign into their pre-existing local user accounts after restarting and now defaults to the new local admin account. 

I have a worklet that adds a local administrator account:

bash24 lines
$Username = "chnlocaladmin"
$Password = "password"

$group = "Administrators"

$adsi = [adsi]"WinNT://$env:COMPUTERNAME"
$existing = $adsi.Children | where {$_.SchemaClassName -eq 'user' -and $_.Name -eq $Username }

if ($existing -eq $null) {

    Write-Host "Creating new local user $Username."
    & NET USER $Username $Password /add /y /expires:never

    Write-Host "Adding local user $Username to $group."
    & NET LOCALGROUP $group $Username /add

}
else {
    Write-Host "Setting password for existing local user $Username."
    $existing.SetPassword($Password)
}

Write-Host "Ensuring password for $Username never expires."
& WMIC USERACCOUNT WHERE "Name='$Username'" SET PasswordExpires=FALSE

I then remove the administrators group from their existing local user accounts using the net commands you suggested that looks like this:

1 line
net localgroup Administrators "Firstname Surname" /DELETE

When the user restarts their machine, it presents them with the ‘chnlocaladmin’ account and doesn’t give them the option to switch to their other user account. Have I mistaken ‘/DELETE’ as a command that actually removes the entire local account or just the administrators group? 

From my testing, I saw the local admin account created and also removed the administrators group from my test local user account. After restarting, I had no problems. So very confused as to why these users don’t have the option to sign into their normal user accounts now? 

These machines are not domain joined, just standard Win 10 build with local user account in a WORKGROUP. 

Any ideas? 

Eric_FerrariDecember 17, 2021
#6

Disregard, the users were not part of the ‘Users’ group so when it removed their admin, it left them with no assigned group. A mistake made by their local IT but I have managed to resolve this now. 

Back to all discussions