2

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?

Crust3
  • 493
  • 1
  • 6
  • 19
  • I don't think this is possible, at least, not in my experience. gMSAs can be used to run as a scheduled task or service among other things. `However, services that run on top of the Cluster service can use a gMSA or a sMSA if they are a Windows service, an App pool, a scheduled task, or natively support gMSA or sMSA.` – Santiago Squarzon Mar 12 '21 at 17:07
  • 1
    My ultimate goal is to download a file from a file share. Is there a way to pass in the gmsa account as the credential object? I've tried it with a blank password, a space for a passowrd and neither worked (this is using the New-PSDrive cmdlet). – Crust3 Mar 12 '21 at 17:19
  • I'll add an answer to your question so I have room to explain things. – Santiago Squarzon Mar 12 '21 at 17:32

2 Answers2

2

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.

Santiago Squarzon
  • 41,465
  • 5
  • 14
  • 37
  • Thanks for the answer! The task that I'm trying to integrate this with runs as a local system account (it's a scheduled task). That task is responsible for importing my script and running some powershell commands. This is where the access to file share comes in. I can give the local system account access to the file share and it works. But ultimately trying to utilize the gmsa account has been in vain so far. Looking back at my questions, I failed to mention about the task running as local system so I apologize if that took you down the wrong path of investigation. – Crust3 Mar 12 '21 at 20:56
  • Ok then, if the task is already running fine then you only need to give your gMSA permissions over the remote file share and permissions to run as task on your local server and update the task to run as the gMSA and that's it. – Santiago Squarzon Mar 12 '21 at 21:05
  • That's the bit I can't change. The task is created by a program and has to run as the local system account. I am going down the path of maybe uisng psexec or net use to see if they support gmsa – Crust3 Mar 12 '21 at 21:35
  • I think, you didn't get my point. You cannot impersonate as a gMSA account, `net use`, `psexec`, `system.management.automation.pscredential` none of these will work. If the task is running as System because for some reason is doing something else on the local system where it need Administrator permission you can get the exact same result by giving Administrator permission to your gMSA account over the local machine. – Santiago Squarzon Mar 12 '21 at 21:39
1

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.

You could use -p ~ to enter an empty password. This way no interaction is needed.

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.

Community
  • 1
  • 1
GarMul
  • 11
  • 1