Is log on as a batch job required for gMSA accounts?

Hi,

PrincipalsAllowedToRetrieveManagedPassword is required to allow GMSA password retrieved on target server. Without that the GMSA password cannot be used even if GMSA account has permissions to logon as the barch and logob as service permission.

Please don't forget to mark helpful answer as accepted

Hi @Daniel ,

I can answer at least part of this question - the machine being in the PrincipalsAllowedToRetrieveManagedPassword list is required when the gMSA is installed or when the password changes. So the machine will locally cache the password once installed, and as a result - if you were to remove the machine from PrincipalsAllowedToRetrieveManagedPassword after that point, any services using the gMSA could continue running on that machine in theory until the password rotates again (which happens every 30 days by default). At that time, the machine would need to retrieve the new password from AD and would not be able to since it is no longer in this list, and then the service would crash/fail.

As far as your other question however - why gMSAs don't appear to need to be explicitly granted the "log on as a batch job" right in order to do things that normally require this, such as running scheduled tasks or IIS app pools - that I do not know. I can say with confidence it has nothing to do with -PrincipalsAllowedToRetrieveManagedPassword nor with the -DNSHostName option...DNSHostName is really just a holdover from the computer account lineage of a gMSA (since a gMSA is sort of a blend between a computer and user account, so it inherits some properties of both)...just set it to the FQDN of the gMSA (e.g. gmsa.domain.com).

But back to the batch logon rights thing - I've found only this thread and the other one you linked talking about this, and indeed it does seem to be the case in my environment as well. In addition, this seems to be the case not only for gMSAs but also for the built-in IIS app pool identities - see my other question here from 6 years ago asking this question that unfortunately nobody had the answer to:

https://serverfault.com/questions/949257/why-do-the-built-in-iis-apppool-accounts-not-need-batch-logon-rights-to-run

UPDATE: After doing some more testing and research just now, I think I may have figured out why this is the case (at least for IIS).

If we use the accesschk tool from Sysinternals to check the token contents of the process in question (w3wp.exe in my case, which is the IIS app pool worker process), when the process is running under a traditional domain account we can see that one of the "groups" listed is NT AUTHORITY\BATCH. This is a "special identity group" that contains all users and/or processes that are accessing the system as a batch job or through the batch queue.

An example command to check this would be something like:

accesschk <PID> -p -f

(where <PID> is the process ID of the process in question)

Now if we run the same command against the PID of an IIS worker process from an app pool configured to run as a gMSA, we see something different - it is NOT a member of NT AUTHORITY\BATCH; rather, it is a member of NT AUTHORITY\SERVICE instead. NT AUTHORITY\SERVICE, as you might suspect, is another "special identity group" which indicates the user/process is accessing the system as a service. The same is true if we run the app pool as ApplicationPoolIdentity.

BTW, more on these "special identities" (NT AUTHORITY\BATCH and NT AUTHORITY\SERVICE) can be found here:

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-special-identities-groups#batch

So with the above results, we can confirm there is an internal difference in how these "virtual accounts" (gMSAs and IIS app pool identities) are interacting with the system when compared to traditional domain accounts. This difference accounts for the discrepancy in permission requirements. I would presume the gMSA thus would require "log on as a service" rights (which mine already had) in order to run the IIS app pools, rather than "log on as a batch job" as is normally required. I did not get a chance to test with either IIS nor a scheduled task when the gMSA did not have "log on as a service" rights - I would expect it to fail, but it's late so I'll leave that for another day =)

Hope this helps.

Edited after further testing to convert comment to an answer and add more details.

Thank you @rpi_dwillis77 for the thorough answer! It's been a while since I thought of this tbh but I liked the answer and the recap.