Summary of the new feature/enhancement

Background

Currently the PowerShell policies assume that if there is a "." (period) in a PowerShell script's path, that it is in the internet zone. This presents the user with a warning when running PowerShell scripts are from a FQDN path (like \\server.domain.com).

In PowerShell versions up to v5.1, Windows Domain Administrators could define specific domains to be added to the Local Intranet Zone. Once added, PowerShell would then "trust" these paths when the ExecutionPolicy=Unrestricted and not present the user a security warning for each script that is run from these trusted paths.

#7458 revealed that PowerShell Core (v6 and v7) intentionally removed the legacy IE API that was previously used to check the Local Intranet zones, and was replaced to check for just "." (periods). As per @TravisEz13 in #7458 I am creating this new feature request to discuss and address this problem.

Impact Of Changes Made In PowerShell Core

Many Windows environments use a feature called Folder Redirection such that the user's "Documents" folder is "redirected" to a server (so it appears to the user that their Documents folder is on their computer, but it really lives on the server). Many environments that use folder redirection redirect to a FQDN UNC path like \\server.domain.com\Users\username\Documents. Since these paths contain "." (periods), any script run from the user's Documents folder is presented with the PowerShell Security warning. This warning message also appears if the user has a PowerShell profile and starts PSv7, which presents this message each time:

Security warning
Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your
computer. If you trust this script, use the Unblock-File cmdlet to allow the script to run without this warning
message. Do you want to run \\server.domain.com\Users\username\Documents\PowerShell\Microsoft.PowerShell_profile.ps1?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D"):

So in any environment where either Folder Redirection is being used to a FQDN UNC path, or if the environment presents users their User/Department folders on a FQDN UNC path, this will trigger security warnings and will present problems to the end user if they try to run scripts from these locations. (At this time, we cannot deploy PowerShell v7 in our environment due to this problem).

Additional details about the problem and the discussion are available in #7458.

Goal

Allow Windows Domain Administrators to configure what FQDN hosts are safe and not trigger a warning when using the Unrestricted execution policy. This would allow Windows Domain Administrators to set up PowerShell v7 so that users are still presented the security warning when running scripts from untrusted paths, but do not trigger this security warning when scripts are run from trusted paths when the ExecutionPolicy is set to Unrestricted.

Windows Domain Administrators will also need the ability to add trusted/safe hosts via the PowerShell Core Group Policies to help deploy these trusted hosts to all domain computers.

While the ability to trust FQDN hosts would solve the immediate problem and is the main problem I am hoping to have addressed, it would also be helpful if PowerShell administrators had the flexibility to not just add FQDN hosts (and all shares/files on it), but also specify paths with subfolders and wildcards. So for instance PowerShell Administrators could either choose to trust a FQDN host like server.domain.com, but also have the flexibility to trust a path like \\server.domain.com\Users\*\Documents\PowerShell*.

Proposed technical implementation details

@SteveL-MSFT and @TravisEz13 suggested the following proposal to help address this problem in #7458:

A list of allowed host filters, that allow PowerShell Wildcards in the powershell.config.json.

And thank you for your time with this!