none
Script running as Local System not executing correctly RRS feed

  • Question

  • Hi there,

    I've created a script that I'm trying to use as part of a VM deployment. The simplified version of the script is that I'm attempting to have the computer joined to the domain. I'm using the Add-Computer cmdlet and I've been able to manually run the script successfully from the command prompt and everything executes correctly. The problem I'm running into is that the script is executing as Local System since I'm adding the script into the local group policy in Computer Configuration/Windows Settings/Scripts/Startup to have the script launch. Now I had a different script that doesn't do the domain join (Add-Computer) and it executes that way with no issue. It appears that the issue is due to the fact that the user context when this script executes through the local group policy is under the SYSTEM user. I can recreate the issue for debugging purposes by setting up a scheduled task to run the script and select the SYSTEM account to run the task as.  So I'm trying to understand and resolve the issue, which raises two questions for me:

    1. Why is the SYSTEM account not able to execute the Add-Computer cmdlet and how do I see what's actually happening or why it's happening? The script does start but never finishes, and I end up having to terminate with task manager.

    2. How do I deal with this? The solution I'm trying to get working is to use Invoke-Command to launch a new session under a different user context. Would this be the best approach? I've now run into the same issue which appears to be from when Local System is trying to create a New-PSSession object. This code again just stalls at this point and never continues to run.

    My code is listed below that I'm debugging with. Can anyone shed some light into how to deal with the user context issue or get additional debugging information?

    Thanks

    $logfile = "c:\scripts\contextlog.txt"

    If ((Test-Path $logfile) -ne $true) {
        New-Item -Path $logfile -type file -value "Initializing file" 
        }
        
    $testblock = {
        Param($u1, $p1, $logtest)
        Add-Content $logtest "`nAccount details are $u1 with password $p1"
        Add-Content $logtest "`nCodeblock executing as $env:userdomain\$env:username"
        Write-Host "This is inside the code block running under the security context $env:userdomain\$env:username" -f Green;
        }

    $joinAcct = "MYDOMAIN\admin"
    $joinPW = "DOMAINPASSWORD"

    $localacct = "admin"
    $localpass = cat c:\scripts\adminpw.txt | ConvertTo-SecureString
    $LocalCred = New-Object -typename System.Management.Automation.PSCredential -ArgumentList $localacct, $localpass

    Add-Content $logfile "`nCreating Remote Session"
    $localSession = New-PSSession -Credential $LocalCred

    Add-Content $logfile "`nRemote session for user context change"

    Invoke-Command -Session $localSession -ScriptBlock $testblock -ArgumentList $joinAcct,$joinPW,$logfile

    • Edited by MrSparkle16 Wednesday, August 13, 2014 8:19 PM
    Wednesday, August 13, 2014 7:55 PM

Answers

  • I found the resolution to the problem. I was able to to determine that when the script ran, the account (Local System) wasn't able to read the password from the adminpw.txt file. The error that I got when run as Local System was "Key not valid for use in specified state."

    I found out that the issue was that when I created the adminpw.txt file using the read-host command, I did that as a different user. It turns out that in order for the Local System to be able to decrypt the file, this needs to be created with the account that will also decrypt it. I've seen that there are other ways around using encrypted passwords, but they were certainly much more complex than I needed to use for my simple script.

    Hopefully this info will help someone else in the future.

    • Marked as answer by MrSparkle16 Tuesday, August 19, 2014 7:10 PM
    Tuesday, August 19, 2014 7:10 PM

All replies

  • You can only use a domain account to add a computer.

    A computer (LOCAL SYSTEM) cannot add itself to a domain.  Think abot how dumb a security risk that would be.


    ¯\_(ツ)_/¯

    Thursday, August 14, 2014 12:55 AM
  • add-computer -ComputerName somepc -Credential $domaincred -DomainName mydomain -OUPath targetOU -Restart


    ¯\_(ツ)_/¯

    Thursday, August 14, 2014 12:58 AM
  • Thanks for the suggestion, however I am using alternate credentials when using Add-Computer. I had taken that out of the script as shown, as I've been simplifying the code down to isolate my issue. That probably wasn't clear from my initial post.

    Just to clarify, The script itself runs as Local System since it's getting launched by the local computer GPO. Even with providing alternate credentials to the Add-Computer cmdlet, the script doesn't execute the command correctly and the script never actually completes. I know that it is stuck at the Add-Computer cmdlet as I had put some debugging logging to a text file, and that's the last message that appears in the text file.

    In the simplifiction of my code, I was attempting to use Invoke-Command in a different user context to execute the Add-Computer cmdlet. Again, the Add-Computer was removed to simplify for debugging, but I have again run into the same issue where the script running as Local System now hangs at the following line of the script:

    $localSession = New-PSSession -Credential $LocalCred

    Again, I'm able to confirm that from the logging I've put in, and that's the last message that's written to the logfile, and I can see the process still running in Task Manager and I end up having to terminate.

    Hopefully that makes some sense and someone has come across this issue.

    Thursday, August 14, 2014 1:36 AM
  • -credential is domain credential.


    ¯\_(ツ)_/¯

    Thursday, August 14, 2014 1:58 AM
  • I found the resolution to the problem. I was able to to determine that when the script ran, the account (Local System) wasn't able to read the password from the adminpw.txt file. The error that I got when run as Local System was "Key not valid for use in specified state."

    I found out that the issue was that when I created the adminpw.txt file using the read-host command, I did that as a different user. It turns out that in order for the Local System to be able to decrypt the file, this needs to be created with the account that will also decrypt it. I've seen that there are other ways around using encrypted passwords, but they were certainly much more complex than I needed to use for my simple script.

    Hopefully this info will help someone else in the future.

    • Marked as answer by MrSparkle16 Tuesday, August 19, 2014 7:10 PM
    Tuesday, August 19, 2014 7:10 PM
  • What mumbo-jumbo.  Local System cannot be used with a password.  You must use a domain account.


    ¯\_(ツ)_/¯

    Tuesday, August 19, 2014 8:24 PM
  • I think what the OP is trying to say is that that the text-encrypted password (ConvertFrom-SecureString), if encrypted without a key, can only be decrypted (ConvertTo-SecureString) by the user account that encrypted it.

    -- Bill Stewart [Bill_Stewart]

    Tuesday, August 19, 2014 9:42 PM
    Moderator