PS7 should also respect the old Windows PowerShell GPO registry settings

[SteveL-MSFT]

Summary of the new feature/enhancement

As part of the side-by-side work for PSCore6, PSCore6 uses a different set of registry paths for GPO policies. This means admins can set policies separately for Windows PowerShell vs PowerShell Core, but makes it more difficult to manage.

Proposed technical implementation details (optional)

For PowerShell 7, pwsh should look in both paths.

[TravisEz13]

Which policy take precedence?

What if the lower precedence policy says to implement a higher security policy than the higher precedence policy?

We already have the configuration file with the PowerShell Configuration RFC to resolve these, which leads to many issue.

[kilasuit]

In all honesty I think that this should be set to a single location in the v7 timeline unless there is a real need to have different settings applied to Windows PowerShell and PowerShell Core.

With preference being set to apply GPO settings above & additionally to config file settings as this would allow admin defined and user defined settings to work in tandem with no issue, especially when it comes to transcription

[SteveL-MSFT]

For PSCore6, we explicitly wanted side-by-side so it's GPO settings were in a different registry path than Windows PowerShell. However, since we are positioning PowerShell 7 as a replacement for Windows PowerShell, users would expect existing GPO to take effect with PS7. In the case that both the WnPS and PSCore6 GPO settings are set, we should default to the most strict interpretation and log it appropriately. Since we don't know how many users are using the PSCore6 GPO settings, I don't think we can just ignore them since 7 is an iteration over 6.

[kilasuit]

Considering the v6 GPO settings had not been well documented I personally would not expect that many people would be using them.

Also, I personally can't see what benefit having different locations would have brought, other than offering unnecessary complexity & not having a singular location for items like transcription logging which causes 6 not to be caught by users that had set up the GPO locations on existing environments.

This means that currently there is the potential that a malicious actor can install PS v6 in an environment that has implemented the PSv5 over the shoulder transcription logging settings (either via GPO or via RegEdit / PowerShell Script/DSC to add needed reg keys) and find that they have been subject to a breach that has used Pwsh and they have no visibility of this due to the Registry location changes.

Changing this, to me was the wrong decision, and as such I personally think the v6 locations should be deprecated and the v5 ones be the only ones used in PSv7 as this enforces a catch all scenario that would catch PSv5, PSv6 (if you re-released all versions with this change back) and then also PSv7 too going forward too.

[kilasuit]

For those reading this and have used the Registry Keys in https://devblogs.microsoft.com/powershell/powershell-the-blue-team/ for Psv5

There was a change in the v6 time line that changed where these reg keys were set to be different and as such broke Over the Shoulder Transcription when using these keys
You can use the below gist to enable this properly for both PSv5 and Psv6 on windows machines
https://gist.github.com/kilasuit/e7c276ca67929ae54369f726877dab08#file-enable-overtheshoulderpstranscription-ps1

You can also use this configuration in PowerShell.config.json in the PowerShell Location ( C:\Program Files\PowerShell\6\powershell.config.json)

https://gist.github.com/kilasuit/e7c276ca67929ae54369f726877dab08#file-powershell-config-json

Note though that you can use either the powershell.config.json or the Registry keys, as in my testing with both being defined, the regkeys take preference and Override the powershell.config.json with 6.2.0

Ideally I would like it to use both to force transcription set via GPO / RegKeys to 1 location and via the PowerShell.config.json file to be set to another location that I specify.

This would allow both Admin over the shoulder transcription and user level over the shoulder transcription to run in parallel and provides the greatest level of flexibility for both Admins and Users, without users requiring to Add Start-Transcript into their PowerShell Profiles.

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this. Recommendation is to keep the policy settings separate between WinPS and PS7. It would be confusing to see Windows PowerShell when looking for PS7 settings and also new settings for PS7 may come up that wouldn't apply to WinPS5.1. For PS7, we need a separate admx, and we should have an option per setting to "Use Windows PowerShell Policy" so that users can set it for WinPS5.1 and have it respected by PS7. However, if WinPS5.1 ever gets removed, then PS7 policy would be equivalent to not set so could be problematic. Request is to have RFC authored for this.

[TravisEz13]

RFC was created: PowerShell/PowerShell-RFC#180

[SteveL-MSFT]

Fixed via #10468