PSU Setup for IT and Employee Facing Apps

We use Entra but you could also use Active Directory leveraging role based access. If you are using Entra Id, you can use the role based claims. If using Active Directory have Owner groups or use the managed by attribute on groups to see who can update a group would be my suggestion.

Hello simon,

The guidance from pss127 is a good starting point. Using Microsoft Entra ID or Active Directory authentication together with PowerShell Universal roles can help control who can access the employee-facing App.

Because the same PSU instance also runs privileged IT automation, I would recommend evaluating a few additional controls before exposing it to employees:

- Use a dedicated PSU role for the employee App and restrict access to only the required App and resources.
- Validate authorization in the backend operation, not only by hiding pages or controls in the UI.
- Use an allowlist of groups that the App is permitted to modify.
- Run the Active Directory operation through a dedicated identity with only the delegated permissions required for those specific groups.
- Record who requested each change, what group was modified, and whether the operation succeeded.
- Consider a separate PSU instance if stronger isolation from the existing administrative automation is required.

To provide a more specific recommendation, could you confirm your PSU version, hosting method, current authentication provider, whether access will be internal or internet-facing, and whether employees need access only to the App?

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

Best regards,
Ruben Tapia

In addition to what's been said you can also integrate PSU with claims-based OIDC, SAML or WS-Federation providers. I prefer this to Active Directory-groups as it abstracts the security-model away from Active Directory to more modern systems with better control and logging (in my opinion).

Personally I run our PSU instance with OIDC, and you don't need to specifically use Entra ID, you could also use Keycloak or other providers, we use a custom one ourself. You could also use ADFS, and it does support OIDC, but you're probably gonna have an easier time going with the WS-Federation setup in terms of ease. The underlying technology is different, but the idea of claims-based access is not.

Once that is all said and done, You would create your roles, personally I like to prefix them to separate them from built-in PSU-roles and denote what they're for, so as per your example I might go with a role like DistributionGroup.Write to denote write-access to distribution groups and restrict access based on this. To grant access to these types of resources I'm currently looking into using the Portal-feature for this purpose, and it seems to integrate very well with roles.