PSU 1.3.1 - Run As Service Account - PSCredentials Variable not set in Vault

Hello !

I’ve been trying multiple things lately about the Run As feature as well as running PSU under a service account in IIS, here is what I noticed.

When PSU is run on IIS with LocalSystem (App Pool account):

You can get PSCredentials variable when run as the default account (LocalSystem I assume)

If you run a script AS an Identity defined as a variable, PSCredentials variables ain’t accessible

As I’m trying to use robust PSSession to keep an open connection to vCenter / Horizon, mostly to save the login time that are aweful with powerCLI, this can be done as LocalSystem…

Then I tried the documented options “Run As Service Account” thinking that the issues related to accessing identity in the vault were linked to the fact that the dashboard was running with LocalSystem and thus those variable were located in LocalSystem’s vault and weren’t accessible as long as I want to start a script as another identity.
But is seems like, when the dashboard is running as another identity than LocalSystem that PSCredential variable ain’t creating at all even tho the dashboard is telling me otherwise, showing successful creation results.

Here is the error message I get when I’m trying to create a PSCredential variable when the dashboard run as another account than LocalSystem:

2020-09-01T09:02:37.3682174+02:00 0HM2E8JH9CT21:00000003 [ERR] An unhandled exception has occurred while executing the request. (48a46595)

System.Exception: Failed to set variable in secret management.

at UniversalAutomation.VariableController.Post(Variable variable) in D:\a\universal\universal\src\UniversalAutomation\Controllers\VariableController.cs:line 64

at lambda_method(Closure , Object )

at Microsoft.Extensions.Internal.ObjectMethodExecutorAwaitable.Awaiter.GetResult()

at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.AwaitableObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)

at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)

at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)

at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)

at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)

at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()

— End of stack trace from previous location where exception was thrown —

at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)

at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)

at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)

at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()

— End of stack trace from previous location where exception was thrown —

at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Logged|17_1(ResourceInvoker invoker)

at Microsoft.AspNetCore.Routing.EndpointMiddleware.g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)

at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)

at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)

at Universal.Server.Middleware.RoutingMiddleware.Invoke(HttpContext httpContext, IPolicyEvaluator policyEvaluator) in D:\a\universal\universal\src\Universal.Server\Middleware\RoutingMiddleware.cs:line 88

at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)

at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)

at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)

at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)

at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)

I don’t know if it’s the expected behavior or not, thus my question. but it feels like a bug.

@adam can you give a look ?

It’s pretty blocking for what we’re trying to achieve and I wonder if I should look for a workaround on that particular topic or if it could be done entirely in PSU.

Many thanks in advance for your help and feel free to let me know if you need any aditional information.

Cheers !

Seems like, I went too fast and forgot a configuration on the app pool : Process Model / Load User Profile : True was set to false, as soon as the correct configuration was made, the identity was registering properly. I’ll keep investigating

The Running As Service Account is killing the Run Script as capability though. I’ll have to find another way to handle those pssessions I guess.

Did you found a solution ? I’m going trough the same thing. Running as service account and need to run the scripts with other user. No solution so far :frowning: