Hi Folx,
we are new to PowerShell Universal and just starting to explore possibilities, usages, etc.
Hence, I wanted to ask you guys about your concepts / good practices on security, especially on PSU authentication vs. app access / AD management and so on (and in particular considering proper tiering access models).
In traditional management it’s quite obvious: you authenticate against your management tools (e.g. RSAT) with proper admin accounts. Assuming some tier0 admin account for AD on-prem.
How do you handle this with PSU?
Do you have separate PSU instances according to your tiers and environment (also e.g. separating Cloud tier0 and on-prem tier0)?
Do you use delegated service accounts to perform the actions in AD or Entra? But if so, what about losing the transparency in your access logs?
At the moment we are primarily exploring using PSU on the one hand for automated management tasks (e.g. normalizing PIM groups, cleaning up temporary groups) but also on building an admin task platform for all aroung joiner-mover-leaver-processes.
Following some modern fundamentals, we are aiming to implement API-first, so first creating an API and then building some portal app for it.
Thanks and looking forward to gain insights on your approaches.
We use CyberArk to store accounts in an API safe. No accounts exist on any PSU instance, the accounts are retrieved on-demand from CyberArk. CyberArk must authorize each PSU server and each server uses a certificate to authenticate using a REST API. We have many domains/environments including Dev vs Production instances.
I will say for some functionality it can be quite difficult to use accounts on demand because of the double-hop issue. For example, trying to use DFS PowerShell commands. Get-DfsnRoot or Get-DfsnFolderTarget do not support a Credential. They want a CIM session. Those type of sessions will fail because of the double-hop unless you enable CredSSP, which is insecure. For us, CredSSP was not an option.
So, we have to use PsExec.exe to run a process that calls PowerShell exe with the credentials. PsExec.exe does not have the double-hop issue.
However, PsExec.exe captures all output and we have to create json files and filter out unwanted output. Once you have it down, it works great, but there is a learning curve.
NOTE: PSU also supports Microsoft’s version of a safe where credentials are stored securely on each server, but managing those credentials with many PSU instances was not great for us. If you don’t have many PSU instances, this can be a simple and effective method.
thanks a lot for your insights, really appreciated!
Storing the accounts / credentials in some external vault is also something we are now looking at.
However, I am more thinking of a chicken-egg-issue regarding tiering models.
OnPrem (or cloud) user management tasks should be considered as “tier 0” actions, as they can screw up quite a lot in your domain / realm.
So admins would need to authenticate with their tier-0 account to PSU…something I would like to avoid (at least unless I have more insights on how PSU handles these things internally).
You mentioned different PSU instances…do you also separate PSU servers regarding their “tier level”? So that e.g. you have a tier-1-PSU + tier-0-PSU which are not mixed up?
In general I would prefer that PSU doesn’t store any credential at all and users always have to authenticate anyway for their dedicated actions (to avoid session-takeover).
Sure, except scheduled jobs …