It is possible to switch to gMSAs for most of your scripting needs, and this guide will walk through setting that up.

You need to add a KDS root key to use gMSAs. If you have not done that yet, you can do it with the below command running as a Domain Administrator:

Add-KDSRootKey -EffectiveImmediately

Please refer to the Microsoft Docs for any issues on this.

With a gMSA - you set up either an AD account or group to retrieve the password. When working with automation tools like Jenkins, Azure Automation, SMA, or any others, you'll generally have scripts start out as the user running the service. For the purposes of this document, we'll assume this is what's going on.

I've historically made the choice to use an AD group as the "password retriever" because then it's easy to add or remove accounts as needed and give them access to all your service accounts. This is helpful for troubleshooting, or if you use the local system account to launch scripts.

It's the same steps either way:

$ADGroupName = 'Not Password Retrievers' # to fool the hackers
$GMSAName = 'gMSASQLRead'
$DomainFqdn = 'home.lab'
$ServiceAccount = New-ADServiceAccount -Name $GMSAName -DNSHostName "$GMSAName.$($DomainFqdn)" -PrincipalsAllowedToRetrieveManagedPassword $ADGroupName -Enabled $true

Here I first set the AD group that's going to be able to retrieve the password, then name my gMSA account, and list out the domain FQDN. Lastly, I create the gMSA.

This is all you need to do to create your gMSAs. Any user or device in the AD group "Not Password Retrievers" will have access to the passwords.

Note: Many guides will also have you "Install" the gMSA to the system you'll use it on. This is not required for any account used through the GMSACredential module.

Once you have your accounts set up correctly, retrieving the password is easy! Simply run:

$Cred = Get-GMSACredential -GMSAName 'gMSASQLRead' -Domain 'Home.Lab'

to get a usable PSCredential. The only "gotcha" is the above command needs to be run from an account that has permissions to get the gMSA password.

I've had some issues in the past using gMSA credentials, so included with this module is a command Invoke-GMSACommand which is set up with a standard way to use them.

Simply run:

$Results = Invoke-GMSACommand -Credential $Cred -ScriptBlock {
    # Code to query remote SQL server
}

And things will work great, kinda... Because gMSA accounts are service accounts with restricted rights, you can't always just spin up a process to run as that account. So what the above command does is it clones your current user token and then only uses the gMSA token for network connections. So basically, anything you attempt to do locally (like access file system on c:) will use the current user, and anything you do remotely (like access file system on \server\c$) will use the gMSA user.

This sounds complex, but the main thing to know is as long as you're not planning to use the gMSA to access local resources, that's all you need. If you want to use the gMSA to access local resources, you can always do:

Invoke-Command -ComputerName localhost -Credential $Cred -ScriptBLock {  }

The above command will also work against remote computers with the gMSA command, but in my experience other teams will look at you funny if you ask them to enable PowerShell remoting on their SQL box to run a SQL query.

And that's it!

If there are any problems, please feel free to open an issue.