Group Managed Service Accounts (gMSA) unable to run scheduled task on domain controllers

Question

Hello folks,

I have created a gMSA for this domain and want it to be able to run a scheduled task. We have the exact same process on a different forest working but one forest the DCs there refused to run the identical task. I then tested the process on another server on the problem forest and it worked fine so I know the "-PrincipalsAllowedToRetrieveManagedPassword" group I specified is working and I did confirm all the DCs (3) that I've tried to create this identical task on are part of this group as well.

On both the working system and the non working DCs they both have the same logon as a batch job perms (I noted with the event ID that was the most common). The test task itself just writes a txt file to a local path, I also granted the gMSA rights to that path just incase that's why it's not running.

Every time I try to kick of the task on the non working system (the DCs) I get an Event ID 101 "Task Start Failed" Error Value: 2147943785.

Any ideas given it has logon as a batch rights?

EventLog:
Log Name: Microsoft-Windows-TaskScheduler/Operational
Source: Microsoft-Windows-TaskScheduler
Date: 11/16/2021 1:00:00 PM
Event ID: 101
Task Category: Task Start Failed
Level: Error
Keywords: (1)
User: SYSTEM
Computer: Workstation.xyz.com
Description:
Task Scheduler failed to start "\test" task for user "xyz\gMSAaccount$". Additional Data: Error Value: 2147943785.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-TaskScheduler" Guid="{DE7B24EA-88DD-4A09-888G-5BDADCFA9017}" />
<EventID>101</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>101</Task>
<Opcode>101</Opcode>
<Keywords>0x8000000000000001</Keywords>
<TimeCreated SystemTime="2021-11-16T18:00:00.150012900Z" />
<EventRecordID>371293</EventRecordID>
<Correlation />
<Execution ProcessID="588" ThreadID="7084" />
<Channel>Microsoft-Windows-TaskScheduler/Operational</Channel>
<Computer>Workstation.xyz.com</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData Name="TaskStartFailedEvent">
<Data Name="TaskName">\Test</Data>
<Data Name="UserContext">xyz\gMSAaccount$</Data>
<Data Name="ResultCode">2147943785</Data>
</EventData>
</Event>

Answer 1

Hi,

As you already know the error code would indicate that the account doesn't have run required rights:

Hex: 0x80070569     Int: 2147943785
Severity Code: 10 - Warning,    Source Facility: Win32, Error Code: Hex: 0x0569 Int: 1385

(-2147023511) Logon failure: the user has not been granted the requested logon type at this computer.

This would mean that server is able to retrieve the password and complete the logon, however the right check is failing. I would confirm what rights have been applied to the server that is running the task, using the secpol.msc console, under Local Policies -> User Rights Assignments and check that the gMSA account has been added to the Log on as a batch job and is not included in Deny log on as a batch job right.

You should also be getting an additional event log in the security event log about the logon failure, this might have more details why the authentication failed.

Gary.

Answer 2

Hi Chris,

I setup a large deployment last year with gmsa accounts running as a service iin least privileged mode (vendors always wany system or admin. smh) that included domain controllers. It spans several forests and a couple dozen domains. I ran into an interesting quirk when running a gmsa on domain controllers that may be affecting you based on your post. The services wouldn't start and it looked like access issues. Long story short, every domain in your forest has to have a unique gmsa name. Once you reuse the name in a different domain every thing stops working. I have some ideas why. I brought it up with Microsoft and they couldn't give me an answer. I ended rewriting my deployment and moved on. For DCs the gmsa name standard is gmsaname+firstTwoCharactersOfDomainName. Allowed me to keep the install automated. Hopefully it solves your problem. Not something you might run into in every environment. @Chris Morley @Gary Reynolds

Answer 3

Hi Chris,

I can only think of the obvious things to check i.e. make sure that the name in secpol.msc is the same as the gMSA account, make sure that there are no duplicate accounts with the same name in the forest. It might be worth adding the user to the Allow logon locally in case the task is trying to start a interactive session. As a test it might be worth adding the gMSA to administrators group as a test to confirm if admin rights fixes the problem, which it probably will.

Gary.