So I’ve been trying to track down a weird permissions issue when trying to use PSU to make some changes to our domain group policy object.
I figured that it was just my delegation of a service account that was not working correctly, and finally I logged onto the PSU server, started a PowerShell (5.1) session under the service account, and ran the commands expecting the same access denied message, but to my surprise it actually worked.
It would appear that running the same user and same commands under PSU is doing something that is limited the permissions the account has? Not sure why or how that would work, but that is what I am seeing. Any ideas?
I did find what appears to be an error message from the Hangfire job screen. The odd part is that it appears I’m getting output of Access is denied for just a couple of lines at the end, the rest of the script can run fine, so I would think it’s not actually access denied creating the process or anything, but somewhere it’s causing it.
System.ComponentModel.Win32Exception
Access is denied.
System.ComponentModel.Win32Exception (5): Access is denied.
at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.WaitForExitCore(Int32 milliseconds)
at System.Diagnostics.Process.WaitForExit(Int32 milliseconds)
at PowerShellUniversal.ChildProcess.WaitForExit(Int32 ms) in C:\actions-runner\_work\universal\universal\src\PowerShellUniversal\Models\ChildProcess.cs:line 123
at UniversalAutomation.Services.GrpcExecutionService.Dispose() in C:\actions-runner\_work\universal\universal\src\Universal.Server\Services\Automation\GrpcExecutionService.cs:line 168
at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.Dispose()
at Hangfire.AspNetCore.AspNetCoreJobActivatorScope.DisposeScope()
at Hangfire.JobActivatorScope.Dispose()
at Hangfire.Server.CoreBackgroundJobPerformer.Perform(PerformContext context)
at Hangfire.Server.BackgroundJobPerformer.<>c__DisplayClass9_0.<PerformJobWithFilters>b__0()
at Hangfire.Server.BackgroundJobPerformer.InvokePerformFilter(IServerFilter filter, PerformingContext preContext, Func`1 continuation)
at Hangfire.Server.BackgroundJobPerformer.InvokePerformFilter(IServerFilter filter, PerformingContext preContext, Func`1 continuation)
at Hangfire.Server.BackgroundJobPerformer.PerformJobWithFilters(PerformContext context, IEnumerable`1 filters)
at Hangfire.Server.BackgroundJobPerformer.Perform(PerformContext context)
at Hangfire.Server.Worker.PerformJob(BackgroundProcessContext context, IStorageConnection connection, String jobId)
I was thinking that this was a different issue, but maybe it is related, since it is related to group policy, but I get the following folder structure created after running command using group policy. The actual cache file is under the SchCache folder, but omitted for the post.
So just a little more troubleshooting, it appears that adding the Service Account for PSU to the local admins group does not fix this, but adding the run-as account for the script to the local admins group does fix it so it will not get the access denied.
