It seems as though, regardless of what a given resource is actually trying to do on a server, that a given local or domain account that you want to use with PsDscRunAsCredential needs interactive logon rights?
Logon failure: the user has not been granted the requested logon type at this
+ CategoryInfo : AuthenticationError: (:) , CimException
+ FullyQualifiedErrorId : Win32Error:1385
+ PSComputerName : localhost
It seems sort of silly that DSC would impose that restriction given that if I take the same local / domain account and perform the same action as the DSC resource would through PS Remoting (non-interactive) that I can accomplish that.
In our particular enterprise environment we've clamped down on static password, interactive logon domain accounts via OU group policies for security reasons. (And interactive management accounts rotate passwords daily.) You sort of need more static-ish passwords for DSC automation, though, so you can see where the pain point comes in...
Anyone else run into this particular dilemma? I'm considering posting something on UserVoice about this particular item.
I haven't run into it, but I suspect it's less a DSC-specific restriction and more about how Windows has to assert a new token when it tries to launch processes. But... to pull the thread a bit, what privileges are you attempting to use with an account that's getting that error? And does adding interactive logon definitely fix it?
I basically swap out the account I'm using for a different account that does have interactive logon, and it works fine (this is all in a dev VM btw, not a real setup yet). I'll know for sure in a couple days when our security team processes my request to get a few dedicated setup accounts for DSC out of the "deny interactive logon" group policy we have. Currently those accounts do not work but I suspect once they've been granted interactive that they will work.