Product: PowerShell Universal
Version: 3.7.10
I would like to bump this topic as I’ve seen a couple posts about it but surprisingly, not as much as I think there should be. I’m hoping I have not searched through all the forums or re-read through the various PSU documentations regarding authentication and secrets, enough times and that a solution exists.
My Scenario: Engineer team (me) needs to create PS tools for the ServiceDesk (SD) team. Various SD users have separate elevated accounts e.g. cloud only Exchange Administrator, to perform day to day tasks such as managing mailboxes, distro groups, ect. That same team also has separate on-prem elevated accounts with delegated rights to manage on-prem AD objects.
My Configuration: The way we have PSU configured is that it’s running as a service and the service is running under a domain service account. Authentication is done via OIDC.
Issue 1: ZERO impersonation policy. We can’t grant the domain service account that runs PSU, elevated access both on-prem or in our 365 tenant so that my or the service desk team can run the tools as that service account. Any company that is required to meet Sox compliance hopefully understands this.
Issue 2: Login method. As part of our requirement to be Sox Compliant, our current application configuration is required to be configured to use OIDC authentication. This authentication method does not capture credentials so there is no pscredential object to take advantage of.
Issue 3: Secret management. This is the part where I’m hoping to be corrected on how secrets are used. Again, I’ve read through the secrets documentation and even watched Adam’s demo video. From what I recall, there was a point in the video where Adam said the secrets were stored in the logged in user’s context (depending on which storing method you chose). However, this is not the case with my testing. I created three different secrets each using the three currently available storage methods as my test SD account. All three secrets were available to my both my personal admin account and other test SD account. These results make sense because, if the PSU service is running as the service account, then the service account is responsible for storing the secret. For the option of Windows Credential Manager and PowerShell SecretStore, this is done under the service account’s context and so, anyone with access to that service account can access those secrets (which is all users logged into and running the PSU web app). Furthermore, I am also able to take the PowerShell SecretStore vault password out of the settings.json file and run the PowerShell command Get-Secret to see all those secrets, assuming I’m logged into that server as that domain service account (which all my engineering team will have the ability to do). To Summarize issue # 3, me nor my team should have access to other user’s secrets and other teams to ours.
Issue 4: No current workaround.
Forms Method: Unfortunately, this recommendation proposed by few is quickly thrown out the window as our company requires the solution to be Sox compliant. While the forms login solution would allow me to capture the username and password to create a pscredential object, this is not secure and doesn’t meet the OIDC requirement.
Impersonation allowed if logged: I’ve also seen a few say that impersonation is acceptable by them since you can log events with information about the user who ran the script/job and then cross reference that date/time with an event that the service account created in let’s say Exchange. I assume said users’ companies do not require Sox compliance. This is not an acceptable solution as infosec nor the auditors will be spending hours trying to cross refence two or more logs to see who did what when. Any solution to correctly those two separate events into a single pane of glass would take some special development.
Again, I’m hoping that I’ve overlooked a workaround or do not properly understand how this solution should be used and that someone will come along and set me straight.