Start PowerShell As A Group Managed Service Account

user_1915598 0
Viewed 5553

How do I start PowerShell with a gMSA account. I right click on the PowerShell icon, run as different user, then input domain\msa$ with no password. It errors out about credentials being incorrect.

I've installed the service account on the machine and running the Test-ADServiceAccount return true. I've granted it the 'log on as a service' and 'log on as a batch job' permissions (I don't really think this was needed but tried it anyway and it didn't work).

Any ideas?

gmsa windows-server-2016 powershell
2 Answers

There are different ways to set up tasks running a PS script with a gMSA, this is what I personally do because I find it easy to do.

  1. First you need to develop your .ps1 to download the file from your FS with your user or with a service account with permissions to download the file.
  2. Once the script is tested and running correctly, set up and test a Scheduled Task with your user or service account used in step 1. It's a good idea to configure all the triggers / extra configurations beforehand because once you update the scheduled task you can't modify it without doing all the process again.
  3. Once the Scheduled Task is fully functional and all triggers set, you proceed to update the task using the gMSA instead of your user or service account. I personally use this:
$taskName = "My Scheduled Task Name"
$gMSAName = (Get-ADServiceAccount gMSA_Name).sAMAccountName # Or hardcode your gMSA Name with a $ at the end
$runLevel = "Highest" # Limited, etc
$principal = New-ScheduledTaskPrincipal -UserID $gmsaName -LogonType Password -RunLevel $runLevel

Set-ScheduledTask -TaskName $taskName -Principal $principal

After running this and if everything went OK, once you re-open the Task Scheduler and search for your task you should see the name of your gMSA here:

task_sched

Remember, once you update the task if you need to edit it later, Task Scheduler will force you to use a different user and the whole process of updating the task via PS will have to be repeated.

To have in consideration:

  • The gMSA will need the same permissions as you or your service account over the File Share to read / modify / etc.
  • The server where the task will run has to be a member of the associated Security Group of your gMSA:
(Get-ADServiceAccount gMSA_Name -Properties PrincipalsAllowedToRetrieveManagedPassword).PrincipalsAllowedToRetrieveManagedPassword

This is the associated AD Group and your task server MUST be a member of this group in order to use the gMSA.

user_153395440

psexec DOES work, at least interactively. On the machine where the gMSA is 'installed' use this:

psexec -u DOMAIN\gMSA_acct$ powershell.exe

When prompted for password just hit enter. That will launch Powershell as the gMSA. You can verify with a WHOAMI from that session.

If there is a commandline switch to make psexec skip the prompt for password (or possibly using <NUL STDIN redirect) you can make this work non-interactively as well.

However this doesn't change the recommendation to run the task as the gMSA. That is 100% correct, you should NOT be running tasks as LocalSystem, especially if you need to access remote resources. Perhaps the file copy task can be split out from the rest.

user_187846080
Related