We are trying to get windows server actions set up without giving the associated service account local admin over the server. Everything works fine when the service account is a local admin. When it isn’t, we get wsman fault 5: access denied. This happens with all windows server actions, not just PTA.
I have set up permissions to allow the service account to run scripts through WinRM, and when I call winrm manually from another server it works without issue, but through SailPoint it always fails.
Nothing of note shows up in event viewer, ccg debug logs or pag debug logs. On windows, it looks like the service account logs into the server, does nothing, logs out, never calling the script.
Anyone else had any luck setting up PTA without local admin rights? Or any ideas on how to get more detailed logs for PTA on the VAs, specfically pag.log?
Exact error from workflow:
{“error”:{“detailCode”:“500.1 Downstream Error”,“message”:{“locale”:“en-US”,“localeOrigin”:“DEFAULT”,“text”:“Unhandled Error: Received a WSManFault message. (Code: 5, Machine: XXXXXXX.XXXX.com, Reason: Access is denied., Provider: Config provider, Provider Path: %systemroot%\\system32\\WsmSvc.dll)”}},“result”:null,“warnings”:null}
I had this exact issue but don’t remember the exact solution (I got moved off the project) - what I do remember is we had an Ask an Architect session with SailPoint, and what came from that was guidance from the product team that the assumption is this feature needs the user to be a local admin.
I think in this case the client had some sort of delta from their group policy that they were looking to change so that the user could be in the Remote Management Users group instead of admin.
This was also an article that is intended to address it but IDK if it actually fixes it - worth trying out though
Have you looked at the file permissions where the script is housed? This from windows would cause this behavior. If for example the scripts lived in you super user account home directory and the service account try to access that location without admin it would get an access denied. Because that account does not have permissions to look into the home directory of that user. By being a local admin it allows that user to look into another users home directory.
That is where I would look first then I would try to use psremoting to see if I can trigger it that way. The other thing that might get you as well is the double hop authentication. That is why the requirements are that the PTA have direct access to the server so that is not the problem but i would still very and take ISC out of the picture and get everything working for that service account before trying to replicate the process in workflow. Hope this helps.
We have tested it without ISC in the picture, that’s where the confusion lies. It works when I don’t use ISC. I am able to PSRemote in as that service account and execute the script with no issue, it’s only when the VAs initiate the connection that we start to have issues. It’s very strange. I’ll double check those permissions though, it’s always possible that something weird was missed, thanks!