Repository navigation
$PROFILE on a shared folder gives security warning if remote system has periods in the name #7458
Description
Tested on 6.1.0-preview.4 6.1rc, 6.1 release, and 6.2-preview.1
Steps to reproduce
- Have your IT department force sticking your profile on a shared drive.
- Ensure your executionpolicy is Unrestricted
- Start pwsh
Expected behavior
My profile loads, as it does with 6.0.3
Actual behavior
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
\\Wherever\whatever$\UD3\myusername\My Documents\PowerShell\Microsoft.PowerShell_profile.ps1?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D"):
If I say [R]un Once, my profile will load, but I will get the same message for every module in my profile.
Environment data
$PSVersionTable
Name Value
---- -----
PSVersion 6.1.0-preview.4
PSEdition Core
GitCommitId 6.1.0-preview.4
OS Microsoft Windows 10.0.14393
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
get-executionpolicy
Unrestricted
Activity
iSazonov commentedon Aug 8, 2018
Bill Loytty (@weloytty) Have you tried using a signed file?
weloytty commentedon Aug 8, 2018
No, because it's my profile and I mess with it a lot. (I have run Unblock-File $PROFILE though, since that's what the error message tells me to do, and I get the same behavior once I have done that)
I also end up with my modules folder on a UNC share too, and I get the same behavior. I could move my profile to $profile.AllUsersCurrentHost, but I'd prefer to keep the 6.0.3 behavior.
iSazonov commentedon Aug 9, 2018
Bill Loytty (@weloytty) Could you please compare the scenario with Windows PowerShell?
weloytty commentedon Aug 9, 2018
Windows powershell behaves the same way that pwsh 6.0.3 does, it loads my profile with no warnings
iSazonov commentedon Aug 9, 2018
Steve Lee (@SteveL-MSFT) Could you please comment the use case? I'd expect that we could trust signed scripts at least.
kvprasoon commentedon Aug 9, 2018
Ilya (@iSazonov) and Bill Loytty (@weloytty) I think this behavior is correct as the script is still residing in a remote location. Execution policy is always for a script which is available locally(no matter from where it is developed). Correct me if I'm wrong.
SteveL-MSFT commentedon Aug 9, 2018
The default ExecutionPolicy is
RemoteSignedand a network share isRemoteso this behavior isby-design. Other than signing the script, the other solution is to change your execution policy.weloytty commentedon Aug 9, 2018
Steve Lee (@SteveL-MSFT) It's by design even if my executionpolicy is Unrestricted?
`
PS C:\Users\someone> get-executionpolicy
Unrestricted
PS C:\Users\someone> .$PROFILE
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 \na.something.com\WLNC-UD$\UD3\someone\My
Documents\PowerShell\Microsoft.PowerShell_profile.ps1?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D"):
`
SteveL-MSFT commentedon Aug 9, 2018
Your profile script is both unblocked and executionpolicy is unrestricted? Can you try
bypassexecution policy?weloytty commentedon Aug 9, 2018
Correct, I have run unblock-file $PROFILE and execution policy is unrestricted.
-ExecutionPolicy Bypass worked as expected (no prompt when running profile).
I've attached a transcript of what happens, starting from cmd
7548.txt
SteveL-MSFT commentedon Aug 14, 2018
Bill Loytty (@weloytty) thanks for the details, I'll see if I can repro this locally. I would suggest removing the network paths in your transcript to something generic like
\\server\shareas to not make internal information publicweloytty commentedon Sep 14, 2018
problem still exists in RTM
KurtDeGreeff commentedon Sep 16, 2018
I also have the same problem over here with RTM version, ExecutionPolicy = Unrestricted
For every loaded module and $profile I have to confirm it and there is no option to Confirm All
I even tried adding the UNC path to Trusted Sites but no success. Any help how to solve this? I didn't have this issue with the previous version.. Many thanks
SteveL-MSFT commentedon Sep 18, 2018
Kurt De Greeff (@KurtDeGreeff) can you be more specific about "previous version"? It would help to know when this was changed so we can find the change that caused this. Thanks.
30 remaining items
iSazonov commentedon Apr 15, 2020
It seems some non-MSFT applications utilize the IE feature. Perhaps there is a public api?
aakash-shah commentedon Apr 15, 2020
Another thing to note is that the zones can be queried via the registry from the following locations:
Computer: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains
Computer Group Policy Set: HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey
User: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains
User Group Policy Set: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey
Values set to 1 indicate a Local Intranet zone.
So even if the IE API can't be used, these registry locations can be queried to calculate sites in the Local Intranet zone.
Perhaps this may be easier to reference versus trying to build out a new mechanism to store trusted locations.
Thanks!
iSazonov commentedon Apr 15, 2020
aakash-shah You referenced IE regkeys for non-enhanced protection mode.
TravisEz13 commentedon Apr 15, 2020
Why do you want to make it harder to run from a random UNC path. Please include some reason for this. This seems arbitrary and cruel to your users. I really need to understand your reasoning to make sure attempting to fix this make sense.
Update:
Actually, that statement shows enough of your reasoning. You want to make it harder. Let's accept this as your goal and move on.
TravisEz13 commentedon Apr 15, 2020
Implementing our own algorithm to parse the registry keys would likely introduce a very large number of bugs, when we have one now.
TravisEz13 commentedon Apr 15, 2020
This still ignores the fact that IE will not ship on many editions of windows going forward.
If we need this feature, let's design it for compatibility. Not so we have to rewrite it in 7.2.
aakash-shah commentedon Apr 15, 2020
I may be assuming incorrectly here, but even if IE isn't installed, Windows still references and uses these settings for Windows Explorer. For instance if you open a file from a FQDN path, and that path is not in the Local Intranet zone, it gives you some extra warnings when opening Office files. After we add the Windows domain FQDN paths to the Local Intranet zone, it corrects that problem, and files from the FQDN UNC paths open as expected in Windows Explorer with no warnings. I haven't tested removing IE, but I assume this will need to continue to work since even though the Local Intranet settings are accessible from within IE, they apply in other areas of Windows too.
If my understanding is incorrect about this changing when IE is removed, please let me know.
Thanks!
SteveL-MSFT commentedon Apr 15, 2020
We can't rely on IE APIs. What I propose is that we add definitions of trusted remote systems in our powershell.config.json file.
TravisEz13 commentedon Apr 15, 2020
I agree with Steve Lee (@SteveL-MSFT) . We can add it to the powershell.config.json. Have PowerShell wildcard support. This is design uses existing code that would be less likely to have new bugs.
aakash-shah commentedon Apr 15, 2020
Steve Lee (@SteveL-MSFT) , Travis Plunk (@TravisEz13) Can we use Group Policy to add trusted remote systems into the powershell.config.json file? If not available today, can support for this be added so that IT admins have a way to easily add support for this in our environments? Group Policy support will help IT admins significantly, and help improve adoption of PSv7.
So that I understand this better, would these trusted remote systems be defined using the DNS name only, or would we also need to specify the entire path? For instance, would we define "server.domainname.com", or would we define something like "\server.domainname.com\users*\Documents\PowerShell"? If this is already documented somewhere, feel free to point me to it.
Thanks!
TravisEz13 commentedon Apr 15, 2020
I'd suggest that someone file a new feature request so that we can start with a clean issue that we can discuss the merits of this proposal.
Title: Add ability to configure internet zone server names for execution policy
Summary of the new feature/enhancement
Background
Currently the policies assume that if there is a
.in the name it is internet.This feature is needed to warn users if they are leaving the internet zone unintentionally.
Goal
The goal would be allow the PowerShell Administrators to configure what hosts are safe and will not trigger a warning by execution policy.
Proposed technical implementation details (optional)
powershell.config.json.Note: On Windows
powershell.config.jsoncan already be configured via Group Policy. See PowerShell Policyaakash-shah commentedon Apr 16, 2020
Travis Plunk (@TravisEz13) Steve Lee (@SteveL-MSFT) Thank you very much for your time in reviewing this thread and replying to my comments/questions! As requested, I've created #12336. Please let me know if there is anything else I should add.
Thanks!
aakash-shah commentedon Apr 16, 2020
Ilya (@iSazonov) Yes you are correct! I missed the IE ESC keys under [HKLM | HKCU]\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains. Thanks for pointing that out!
AhmedAbdelrazzak commentedon Sep 5, 2021
Steve Sanderson (@Steve) Lee
you made my day,
your recommendation about removing the dots solved my issue as I was writing the path as follow "10.x.x.x"
Thank you very much