Set-Executionpolicy RemoteSigned
Larry__Weiss
http://www.microsoft.com/technet/scriptcenter/topics/msh/cmdlets/set-executionpolicy.mspx
it says of
Set-ExecutionPolicy RemoteSigned
RemoteSigned – Downloaded scripts must be signed by a trusted publisher
before they can be run.
How does PowerShell know that a script was downloaded?
What does "downloaded" mean in this context?
- Larry
Josh Einstein
NTFS alternate data streams I believe) that tag a file as having originated
from the internet zone. For example, when Internet Explorer downloads a
file, it attaches this metadata which is why you get the "always ask before
launching this file" prompt when running an installer you downloaded from
the internet but not one on a CD.
Windows Live Messenger also adds this metadata for files received in IM
conversations and I suspect FireFox 3.0 is probably doing it as well by now.
When you right click a file that originated from the internet and click
properties, you see a button that says "unblock" and that removes the
metadata so the file is treated normally.
It's kind of a hacky version of Unix's "execute" file attribute.
Josh
"Larry__Weiss" <l...@airmail.net> wrote in message
news:#6LLUUBr...@TK2MSFTNGP05.phx.gbl...
Al Dunbar
"Josh Einstein" <joshei...@hotmail.com> wrote in message
news:1B025467-1C64-4860...@microsoft.com...
> Microsoft has a convention for adding metadata to a file (through the use
> of NTFS alternate data streams I believe) that tag a file as having
> originated from the internet zone.
Thanks for the interesting and very plausible explanation. I have had some
experience with ADS (alternate data streams), but in a different context.
The key thing, though, is that they are an NTFS feature. If you copy a file
containing ADS's from an NTFS volume to a FAT volume, the alternate streams
are left behind, typically with a warning message.
If downloaded files are detected by some ADS artifacts, then these should be
removable by copying to a FAT volume and back again, or simply downloading
to a FAT volume to start with. Anyone want to try it?
/Al
Matthias Tacke
> If downloaded files are detected by some ADS artifacts, then these should be
> removable by copying to a FAT volume and back again, or simply downloading
> to a FAT volume to start with. Anyone want to try it?
>
No need to copy, streams.exe from sysinternals can enumerate files with ads
and also remove them.
<http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx>
<http://download.sysinternals.com/Files/Streams.zip>
Downloaded files have a stream "Zone.Identfier".
You can view the content by appending the stream name to the file name,
(Albeit it works here only when redirecting the input and only in cmd.exe)
>Streams *
..
k:\Winstall\Download\LogParser.msi:
:Zone.Identifier:$DATA 26
..
>more <"k:\Winstall\Download\LogParser.msi:Zone.Identifier"
[ZoneTransfer]
ZoneId=3
Here are some articles sheding light on ADS:
<http://www.flexhex.com/docs/articles/alternate-streams.phtml>
<http://www.codeproject.com/KB/winsdk/AlternateDataStream.aspx>
<http://www.codeproject.com/KB/files/ads.aspx>
<http://www.sans.org/reading_room/whitepapers/honors/alternate_data_streams_out_of_the_shadows_and_into_the_light_1503>
--
HTH
Matthias
Larry__Weiss
this protection is not enforced by PowerShell.exe ?
(There is probably a better way to say that...)
- Larry
Josh Einstein wrote:
> Microsoft has a convention for adding metadata to a file (through the
> use of NTFS alternate data streams I believe) that tag a file as having
> originated from the internet zone. For example, when Internet Explorer
> downloads a file, it attaches this metadata which is why you get the
> "always ask before launching this file" prompt when running an installer
> you downloaded from the internet but not one on a CD.
>
> Windows Live Messenger also adds this metadata for files received in IM
> conversations and I suspect FireFox 3.0 is probably doing it as well by
> now. When you right click a file that originated from the internet and
> click properties, you see a button that says "unblock" and that removes
> the metadata so the file is treated normally.
>
> It's kind of a hacky version of Unix's "execute" file attribute.
>
>
> "Larry__Weiss" <l...@airmail.net> wrote...
Alex K. Angelopoulos at
layer of protection. The primary purpose of RemoteSigned, however, is to
prevent remote load and execution across security domains. If you're trying
to guarantee local integrity of files, the best option is to control the
write permissions for the volume or enforce signing.
Given the context, it sounds to me like the issue is that you're trying to
create a secure flash drive with scripts for easy transport for on-site tech
support. Is that what you're after?
"Larry__Weiss" <l...@airmail.net> wrote in message
news:#rG$LlJrJH...@TK2MSFTNGP02.phx.gbl...
Thomas Lee
<alan...@hotmail.com> writes
>If downloaded files are detected by some ADS artifacts, then these
>should be removable by copying to a FAT volume and back again, or
>simply downloading to a FAT volume to start with. Anyone want to try it?
Better yet, use streams.exe from sysinternals.
But I have tried both and they both work.
Thomas
--
Thomas Lee
doct...@gmail.com
Larry__Weiss
I'm just trying to understand the principles of operation involved with
Set-ExecutionPolicy RemoteSigned
I'm pretty sure I now understand how NTFS participates (and FAT32 doesn't).
I don't understand what you mean by "remote load and execution".
- Larry
Alex K. Angelopoulos wrote:
> That's correct; PowerShell simply exploits this functionality as an
> extra layer of protection. The primary purpose of RemoteSigned, however,
> is to prevent remote load and execution across security domains. If
> you're trying to guarantee local integrity of files, the best option is
> to control the write permissions for the volume or enforce signing.
>
> Given the context, it sounds to me like the issue is that you're trying
> to create a secure flash drive with scripts for easy transport for
> on-site tech support. Is that what you're after?
>
> "Larry__Weiss" <l...@airmail.net> wrote...
>> So, if I download a script to a directory on a FAT32 volume,
>> this protection is not enforced by PowerShell.exe ?
>>
Alex K. Angelopoulos at
scenario. Suppose you have access to a share on a remote system on the same
LAN, but it's in a separate security domain (for example, two peered
workstations where you get cross-system access transparently by having
accounts with the same name and password available on both systems). If you
have RemoteSigned as the execution policy on Computer 1 and then try to run
a PowerShell script that physically resides on a visible share on Computer
2, I believe PowerShell squawks about it. I haven't tried that in quite a
while and don't have a VM here to test it, so I may not remember this
precisely...
"Larry__Weiss" <l...@airmail.net> wrote in message
news:e6XDD#MrJHA...@TK2MSFTNGP04.phx.gbl...
RickB
I was going to try to do some experiments along these lines.
By default all machines here use AllSigned.
So I had to temporarily set RemoteSigned.
When I tried to do it I got this message.
Set-ExecutionPolicy : Windows PowerShell updated your execution policy
successfully, but the setting is overridden by a policy defined at a
more specific scope. Due to the override, your shell will retain its
current e
ffective execution policy of "AllSigned". For more information, please
see "Get-Help Set-ExecutionPolicy."
The help only mentions VISTA as needing any extra effort to change the
policy.
I'm an admin on this XP box.
The policy was set back when I was running V1 but now I've got CTP3
installed and I can't seem to change the policy.
What do I need to do? There is no 'run as admin' in XP.
> >>>>> RemoteSigned � Downloaded scripts must be signed by a trusted
Josh Einstein
"However, if the "Turn on Script Execution" Group Policy is enabled for the
computer or user, the user preference is written to the registry, but it is
not
effective, and Windows PowerShell displays a message explaining the
conflict.
You cannot use Set-ExecutionPolicy to override a group policy, even if the
user
preference is more restrictive than the policy."
"RickB" <rbie...@i1.net> wrote in message
news:73f8809b-4cdb-490b...@u9g2000pre.googlegroups.com...
>> >>>>> RemoteSigned � Downloaded scripts must be signed by a trusted
RickB
I am the one who installed PowerShell and set the execution policy to
AllSigned.
Before upgrading to CTP3 I had no problem changing the execution
policy although I rarely ever did.
The setting you refer to must have been set by someone else and for a
completely different reason because only the machines I'm responsible
for use powershell and nobody would have reason to purposely do
something without telling me.
I can't tell from your response what, if anything, I can do.
That is, I don't know how to look at the setting you refer to or what
it needs to be changed to.
Thanks
On Mar 25, 4:53 pm, "Josh Einstein" <josheinst...@hotmail.com> wrote:
> According to the help, this is because of a group policy setting:
>
> "However, if the "Turn on Script Execution" Group Policy is enabled for the
> computer or user, the user preference is written to the registry, but it is
> not
> effective, and Windows PowerShell displays a message explaining the
> conflict.
> You cannot use Set-ExecutionPolicy to override a group policy, even if the
> user
> preference is more restrictive than the policy."
>
> "RickB" <rbiel...@i1.net> wrote in message
Josh Einstein
be pushed from a domain controller to all the machines in a domain or they
can be set locally on a machine. The domain settings override the local
settings, so even as a local admin, if the domain administrator sets a group
policy setting, you're stuck with it as long as your machine is joined to
the domain.
To edit the local group policy settings, you can run mmc.exe then add the
Group Policy Object Editor snapin. To edit the domain-wide group policy, you
have to be a domain administrator and I guess you need to be on the domain
controller.
Josh
"RickB" <rbie...@i1.net> wrote in message
news:74959701-afbc-4eaf...@d19g2000yqb.googlegroups.com...
RickB
> Group policy is kinda like registry settings for a Windows domain. They can
> be pushed from a domain controller to all the machines in a domain or they
> can be set locally on a machine. The domain settings override the local
> settings, so even as a local admin, if the domain administrator sets a group
> policy setting, you're stuck with it as long as your machine is joined to
> the domain.
>
> To edit the local group policy settings, you can run mmc.exe then add the
> Group Policy Object Editor snapin. To edit the domain-wide group policy, you
> have to be a domain administrator and I guess you need to be on the domain
> controller.
>
> Josh
>
>
> - Show quoted text -
Ok, Thanks, That all makes sense.
At the risk of being a bother,
I've been looking at all the settings for some time now.
There are hundreds in a tree of dozens of directories.
Any idea where to look.
I'm not seeing it anywhere.
Perhaps if it is at the domain level I won't?
Josh Einstein
am primarily a developer and rarely bother with admin-related tasks.
"The PowerShellExecutionPolicy.adm file adds the "Turn on script execution"
policy setting to the following paths in Group Policy:
Computer Configuration\Windows Components\Windows PowerShell
User Configuration\Windows Components\Windows PowerShell
For information about the policy settings in Group Policy, navigate to a
policy setting and then click the policy setting's name. A description of
the policy setting appears on the Extended tab of the policy setting.
If you have questions about Windows PowerShell, including this Group Policy
setting, post them on Microsoft.Public.Windows.PowerShell."
If someone had applied that at the domain level, I assume it would affect
you even though you aren't able to see the setting. On my machine where the
above template has not been installed, I don't even have a Windows
Components\Windows PowerShell node.
Josh
"RickB" <rbie...@i1.net> wrote in message
news:56b3dd79-35cc-4ef1...@v38g2000yqb.googlegroups.com...
Thomas Lee
<74959701-afbc-4eaf...@d19g2000yqb.googlegroups.com>,
RickB <rbie...@i1.net> writes
>I am admin on all the machines that use PowerShell.
>I am the one who installed PowerShell and set the execution policy to
>AllSigned.
>
>Before upgrading to CTP3 I had no problem changing the execution
>policy although I rarely ever did.
>The setting you refer to must have been set by someone else and for a
>completely different reason because only the machines I'm responsible
>for use powershell and nobody would have reason to purposely do
>something without telling me.
Well - from what I see here, someone HAS set that policy. And the way
group policy works, GP trumps local setting every time. You are seeing
this behaviour which is by design and will not change.
>I can't tell from your response what, if anything, I can do.
Remove or adjust the policy in GP.
Use Group Policy management to edit the relevant Group Policy object to
remove this policy.
>That is, I don't know how to look at the setting you refer to or what
>it needs to be changed to.
See above.
--
Thomas Lee
doct...@gmail.com
RickB
point I am not clear about.
Does the policy you are referring to, "Turn on Script Execution", set
at group level, specify the execution policy that must be used on all
machines in the group or does it only specify whether execution policy
can be changed.
What I'm interested in is whether someone has, at the group level,
specified 'ALLSIGNED' or have they just restricted me from changing it
and I'm only stuck with ALLSIGNED because I set it that way before
they took my ability to change it away?
Alex K. Angelopoulos at
machine(s)?
(1) Look for the registry key that gets used by the group policy setting.
This is:
HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell
There are two policies of interest here. The first is a DWORD value named
EnableScripts and needs to be 1 for scripts to execute; the other one is
ExecutionPolicy, which will be set to the value used by GP. If the key is
present, GP was set up for PowerShell at some point by someone.
(2) Repeat for the user key,
HKCU\SOFTWARE\Policies\Microsoft\Windows\PowerShell
If one or both exist - which I strongly suspect - then someone did indeed
set up GP for PowerShell at some point. In that case, I would simply
download the PS ADM template, load it, and unapply the PowerShell policies.
You can find the download here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=2917a564-dbbc-4da7-82c8-fe08b3ef4e6d
IF you don't find any policy settings, something else bogus is going on. In
that case, try the following
(3) Look up the registry key for the ExecutionPolicy using regedit and
visually confirm the value. It's under the path
HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
it's named ExecutionPolicy, and the value is the raw string for whatever it
is set to.
(4) See if you can manually modify this value and have any effect - you
almost certainly cannot.
(5) if somehow you've gotten things to work with 4, reboot to make sure the
setting sticks.
I'm guessing that someone did indeed apply a policy, likely by accident. If
not, then it's possible that something flakey is going on with admin and
machine permissions; it will be useful to know where you start hitting the
problem in the steps above.
"RickB" <rbie...@i1.net> wrote in message
news:d5ad430a-9b92-4a56...@y7g2000yqa.googlegroups.com...
Alex K. Angelopoulos at
news:#CoWT8At...@TK2MSFTNGP02.phx.gbl...
> Rick, could you perform the following tests on one of the affected
> machine(s)?
On second thought, do the following FIRST. Check your startup scripts for
lines invoking Set-ExecutionPolicy.
While experimenting with the new -Scope parameter for Set-ExecutionPolicy, I
discovered that I get the same error as you if I've set the policy at the
process level and then try to set it at the user level, etc - this is in the
same session, with the same privileges. I suspect that somehow you're
actually running a Set-ExecutionPolicy that is applied to the process or
user.
RickB
Thank you !
V1 or an earlier CTP must, by default, have used '-scope
LocalMachine'.
CTP3 defaults to '-scope CurrentUser'.
The hierarchy seems to be Process, LocalMachine, CurrentUser.
I found no policy at the Process level but there was one at
LocalMachine.
I could change the LocalMachine policy but only until I set a Process
policy.
Alex K. Angelopoulos at wrote:
RickB
some light can be shed on this question.
I set RemoteSigned and put signed and unsigned files on each of
Novel Share Drive
Windows Share on a Server 2003 machine within my domain
Windows Share on a Server 2003 machine in another domain
The unsigned file, surprisingly, worked on the Novel share but not on
either of the Windows shares.
The fact that it worked from the Novel share surprised me because
Visual Studio gives me headachs if I try to do development with source
on a Novel share, claiming my source is untrusted.
But anyway since both Windows shares are NTFS so I looked for streams
that might influence the result but found none.
Alex K. Angelopoulos at wrote:
> >>>>> RemoteSigned � Downloaded scripts must be signed by a trusted