gMSA / scheduled task - no mapping between account names and security ids was done

Question

gMSA / scheduled task - no mapping between account names and security ids was done

s0p4L1ne 15

Hello,

I am trying to setup a scheduled task that will run a script, and I want to use gMSA. I have followed this tutorial: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/windows-server-2012-group-managed-service-accounts/ba-p/255910 and I search on all Microsoft social technet forum and other tech forums without success.

The KDS root key is active
The gMSA is created
My computer is allowed to retrieve gMSA password
I can change the default local system user to gMSA account for a random service (in my example I successfully change the service account for glpi-agent)
The gMSA is allowed to logon as a batch job and as a service
The gMSA is member of the local Administrators group
Test-ADServiceAccount gMSAaccount is returning True
I correctly use the $ for the gMSA account name
I tried registering the Scheduled task as Normal user and Admin user with same result.

My powershell commands:

$TaskAction = New-ScheduledTaskAction -Execute C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -Argument 'powershell_script.ps1' -WorkingDirectory C:\User\username\Desktop 
$TaskPrincipal = New-ScheduledTaskPrincipal -UserID LAB\gMSA_powershell$ -LogonType Password -RunLevel Highest
Register-ScheduledTask gmsaPowerShell -Action $TaskAction -Principal $TaskPrincipal

It result with error: "no mapping between account names and security ids was done"

What am I missing here ?

Thank you for your help !

Michael Liben 261 Reputation points

2023-08-14T22:24:49.6933333+00:00

Try adding the gMSA via the GUI. When searching for the gMSA, make sure the "From this location" is scoped for "Entire directory." ,Click the "Object type" button and deselect the object types so only Service Accounts is selected. Locate the gMSA and select. Save the task.

No need for membership in local administrators' group; that's far too much privilege. It someone modifies the script that is called by the task s/he can run rampant. Logon as batch should be sufficient.
s0p4L1ne 15 Reputation points

2023-11-09T08:16:48.3266667+00:00

You can not create a scheduled task with gMSA from the GUI, you can only do this from PowerShell.
Michael Liben 261 Reputation points

2023-11-09T12:49:04.73+00:00

You can definitely add a gMSA through the GUI. When you first save the task, save it with an account that has rights to create a task, e.g., local admin. Then reopen the task, change the "when running the task, use the following user account." Locate the gMSA account by setting the location to "Entire Directory" and selecting object type to "Service Account." Highlight the service account you are assigning, click "OK" and without entering a password, save the task.

If you subsequently edit the task, you'll repeat the process of saving task with local admin account and reopening to assign the gMSA account.
David 5 Reputation points

2024-01-01T21:22:37.89+00:00

Michael, yes, you can select the account via the gui, but it will not let you actually save the task without providing a password. Leaving the password field blank and attempting to continue anyway returns the message: "Task Scheduler cannot apply your changes. The user account is unknown, the password is incorrect, or the user account does not have permission to modify the task."

As such, too, editing a task after the fact requires you changing the user to one that you can actually save it as, then running cmd or ps to change the user back.

3 answers

Your answer

Michael Liben 261 Reputation points

2023-08-14T22:24:49.6933333+00:00

Try adding the gMSA via the GUI. When searching for the gMSA, make sure the "From this location" is scoped for "Entire directory." ,Click the "Object type" button and deselect the object types so only Service Accounts is selected. Locate the gMSA and select. Save the task.

No need for membership in local administrators' group; that's far too much privilege. It someone modifies the script that is called by the task s/he can run rampant. Logon as batch should be sufficient.
s0p4L1ne 15 Reputation points

2023-11-09T08:16:48.3266667+00:00

You can not create a scheduled task with gMSA from the GUI, you can only do this from PowerShell.
Michael Liben 261 Reputation points

2023-11-09T12:49:04.73+00:00

You can definitely add a gMSA through the GUI. When you first save the task, save it with an account that has rights to create a task, e.g., local admin. Then reopen the task, change the "when running the task, use the following user account." Locate the gMSA account by setting the location to "Entire Directory" and selecting object type to "Service Account." Highlight the service account you are assigning, click "OK" and without entering a password, save the task.

If you subsequently edit the task, you'll repeat the process of saving task with local admin account and reopening to assign the gMSA account.
David 5 Reputation points

2024-01-01T21:22:37.89+00:00

Michael, yes, you can select the account via the gui, but it will not let you actually save the task without providing a password. Leaving the password field blank and attempting to continue anyway returns the message: "Task Scheduler cannot apply your changes. The user account is unknown, the password is incorrect, or the user account does not have permission to modify the task."

As such, too, editing a task after the fact requires you changing the user to one that you can actually save it as, then running cmd or ps to change the user back.

Answer 1

Neidhart Patrick 10

I had the same Problem and i just fixed it. Just add a "$" sign at the End for Example [DOMAIN]\gmsa$

that did the trick for me

Answer 2

David 5

The only suggestion I can make (as I just ran into something similar myself) is to make sure your domain name is correct and valid when creating the $TaskPrincipal var. I encountered the same error while following a separate set of instructions for sMSA account creation and made the mistake of not changing the word "DOMAIN" in their script that I copy/pasted to my actual domain name. :P

Answer 3

SD Casati Riccardo 0

Hello,

I tried your scheduled task it worked for me.

I think that your problem is about the creation of the gMSA. Could you paste here how you configure your gMSA?

Regards,

Riccardo

s0p4L1ne 15 Reputation points

2023-11-09T09:29:12.4266667+00:00

Hi,

First I create the gMSA on Domain Controller:

New-ADServiceAccount -Name "gMSA-task1" -Description "Test" -DNSHostname "gMSA-task1.lab.lan" -ManagedPasswordIntervalInDays 30 -PrincipalsAllowedToRetrieveManagedPassword "COMPUTER-1" -Enabled $True

Then I associated the gMSA to the computer:

Add-ADComputerServiceAccount -Identity "COMPUTER-1" -ServiceAccount gMSA-task1

As we are in Tiering environment (with Tier0, Tier1 and Tier2),

We have Tier2Admin group which is member of Local Administrators group on each Tier2 workstation.

The gMSA is member of the Tier2Admin

There is a GPO setting up and allowing all Tier2Admin to open session as a service or as a Task.

On the computer side:

I install the RSAT AD Module with offline method:

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 -LimitAccess -Source \\share\soft\SW_DVD9_NTRL_Win10_2004_64Bit_MultiLang_FOD_1_X22-21311

Then I check if the gMSA is known

Test-ADServiceAccount gMSA-task1

And I install it:

Install-ADServiceAccount gMSA-task1

And when I launch the PowerShell script to create the task, it says "no mapping between account names and security ids was done"

I did all the steps without issue, I can even use the gMSA on the computer to run a service, it just does not work with PowerShell and I do not know why...
s0p4L1ne 15 Reputation points

2023-11-10T07:49:15.9133333+00:00

The goal to achieve is to run a specific application with the gMSA-account for a non-admin user through Scheduled Task, maybe the issue is here, as non-admin user can not run scheduled task.

But the no mapping errors is happening even from elevated powershell. Its not about permission.
Michael Liben 261 Reputation points

2023-11-10T16:52:53.9533333+00:00

To run as the other user, you'll need to store those credentials in a way the gMSA can retrieve. Try another scheduled task that encrypts the password in a file encrypted with the gMSA key. Then within the script, the gMSA can retrieve the password and log on as the unprivileged user.

Run a variation of this as a scheduled task configured to run as the gMSA. then the gMSA account can retrieve and decrypt the password.

ConvertTo-SecureString -String 'MySecretPassword' -AsPlainText -Force | ConvertFrom-SecureString | Out-File "D:\EncryptedCredsText\EncPwd.txt"

Then you can retrieve/decrypt with the following and use the $pass as secure string for the user's credential

$pass = Get-Content "D:\EncryptedCredsText\EncPwd.txt" | ConvertTo-SecureString

Share via

gMSA / scheduled task - no mapping between account names and security ids was done

3 answers

Your answer