I can't seem to wrap my head around this one. The IIS docs (and countless forum posts) are quite clear about the rights needed to run an IIS app pool, which include batch logon rights (Log on as a batch job). I've confirmed this when running an app pool as a domain account, where the worker process won't start if the domain account doesn't have this right.
However, when I run an app pool using the built-in "app pool identity" (IIS AppPool\[app pool name]), the pool runs fine even if this identity does not have the batch logon rights (it spins up, services requests, etc. without issue). This particular right is locked down via domain GPO and neither this identity, nor the IIS_IUSRS local group (which, as I understand it, the built-in app pool accounts are granted membership in dynamically at runtime) has this right.
Now, IIS did automatically grant certain other rights to the app pool identities (and does so anytime a new app pool is created), such as "Generate security audits", "Log on as a service", etc. But these obviously don't substitute for the fact that it is missing "Log on as a batch job". Running the "accesschk" tool from the SysinternalsSuite confirms that these accounts do not have this right.
This link describes the default permission in IIS v7+, and notes that app pool identities are granted certain rights, and that the IIS_IUSRS local group is granted "Log on as a batch job" by default (which explains why the app pool identities work out of the box):
But, I still can't understand how they could work properly in an environment where the batch logon right is locked down via domain GPO and neither the IIS_IUSRS group nor the app pool identities have been included in the policy.
This is observed on Server 2012R2 (IIS v8.5), and interestingly, when I dug around a bit I also see the same behavior with app pools running as NetworkService in Server 2016 (IIS v10) (same environment - batch logon right locked down via domain GPO, and NetworkService not included in that policy).
So it would seem that for some reason, local accounts are not subject to needing the batch logon right to run an app pool. Of course, if we try to run the pool under a domain account without these rights it will absolutely fail. I thought it at first it was only the app pool "virtual accounts", but that wouldn't explain the same behavior with NetworkService - so maybe only built-in local accounts? I don't know.
Is anyone able to shed any light on this?