> Any ideas? I am 100% certain that my ignorance is the cause of this but I
> don't know where to look. My setup looks like this:
> Add child code group A to Local Intranet code group
> Add child node B to code group A
> B represents different groups within the enterprise who will build managed
> ActiveX controls
> Add child node C to B
> C represents actual ActiveX controls
> C has strong naming member condition and custom permission set
> Custom permission set has registry, security, ui, web access, reflection
> permissions
>
> caspol -resolvegroups <url>pocactivex.dll gives me this.
>
> Level = Machine
>
> Code Groups:
>
> 1.  All code: FullTrust
>   1.2.  Zone - Intranet: LocalIntranet
>      1.2.1.  Zone - Intranet: LocalIntranet
>         1.2.1.1.  Url - <url>/*: POCActiveX Permissions
>
>            1.2.1.1.1.  Site - <url>: POCActiveX Permissions
>         1.2.1.2.  All code: Nothing
>         1.2.1.3.  All code: Nothing
>
> Level = User
>
> Code Groups:
>
> 1.  All code: FullTrust
>
> Success
>
> -------------------------------
>
> As an experiment, I've tried adding an incorrect version number to the
> strong name assembly policy, the activex control still loads correctly. I
> abandoned working on my development machine and use two servers to
> eliminate my machine as the culprit. No joy.
>
>
> --
> ________________________
> Warm regards,
> Alvin Bruney [MVP ASP.NET]
>
> [Shameless Author plug]
> Professional VSTO.NET - Wrox/Wiley
> The O.W.C. Black Book with .NET
> www.lulu.com/owc, Amazon
> Blog: http://www.msmvps.com/blogs/alvin
> -------------------------------------------------------
>
>
>

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:A7DDCBEE-6C89-4297-9D4F-A5927F5B1DAF@microsoft.com...
> "Alvin Bruney [MVP]" <www.lulu.com/owc> wrote in message
> news:uitM1XMvGHA.3428@TK2MSFTNGP02.phx.gbl...
>>I have a managed user control in a web form. No matter how I set the CAS
>>policy at the machine level, the managed user control always runs.
>
> Are you trying to prevent it from running?  If not, what's the problem?
> (Just asking 'cause most of the complaints we get in this neck of the
> woods involve stuff not running. <g>)
>
>> The only setting that seems to make a difference is machine/all_code
>> which is currently set to full trust.
>
> Was that intentional?  The default permission set for this code group is
> Nothing.  If you're trying to troubleshoot CAS permission problems, I'd
> recommend resetting your CAS policy (after making a backup of your current
> policy, if necessary).
>
>
>> Any lesser setting and the ActiveX control does not work.
>
> (Assuming you're actually trying to make your control run when full trust
> isn't granted to Machine\All_Code...)
>
> From what you've included below, it looks like your intention is to use
> URL and/or site evidence to grant additional permissions to the control
> assembly.  (BTW, the nesting of site evidence under URL evidence is a bit
> odd since the site is less specific than the URL, but that's very unlikely
> to be directly related to your current problem.  You've also got a bunch
> of extra code groups in there but, again, this isn't likely to be
> contributing to your current problem.)
>
> A couple of things to check:
>
> 1.  Is your URL correct?  The CLR won't map from one URL to another that
> points at the same resource, so you must be using an exact match.
>
> 2.  Is your permission set sufficient?  One easy way to test this would be
> to assign the FullTrust permission set to your URL-based code group.  If
> this allows the control to run but your custom permission set doesn't, the
> custom set is presumably too restrictive.
>
>
>
>> Any ideas? I am 100% certain that my ignorance is the cause of this but I
>> don't know where to look. My setup looks like this:
>> Add child code group A to Local Intranet code group
>> Add child node B to code group A
>> B represents different groups within the enterprise who will build
>> managed ActiveX controls
>> Add child node C to B
>> C represents actual ActiveX controls
>> C has strong naming member condition and custom permission set
>> Custom permission set has registry, security, ui, web access, reflection
>> permissions
>>
>> caspol -resolvegroups <url>pocactivex.dll gives me this.
>>
>> Level = Machine
>>
>> Code Groups:
>>
>> 1.  All code: FullTrust
>>   1.2.  Zone - Intranet: LocalIntranet
>>      1.2.1.  Zone - Intranet: LocalIntranet
>>         1.2.1.1.  Url - <url>/*: POCActiveX Permissions
>>
>>            1.2.1.1.1.  Site - <url>: POCActiveX Permissions
>>         1.2.1.2.  All code: Nothing
>>         1.2.1.3.  All code: Nothing
>>
>> Level = User
>>
>> Code Groups:
>>
>> 1.  All code: FullTrust
>>
>> Success
>>
>> -------------------------------
>>
>> As an experiment, I've tried adding an incorrect version number to the
>> strong name assembly policy, the activex control still loads correctly. I
>> abandoned working on my development machine and use two servers to
>> eliminate my machine as the culprit. No joy.
>>
>>
>> --
>> ________________________
>> Warm regards,
>> Alvin Bruney [MVP ASP.NET]
>>
>> [Shameless Author plug]
>> Professional VSTO.NET - Wrox/Wiley
>> The O.W.C. Black Book with .NET
>> www.lulu.com/owc, Amazon
>> Blog: http://www.msmvps.com/blogs/alvin
>> -------------------------------------------------------
>>
>>
>>
>

"Alvin Bruney [MVP]" <www.lulu.com/owc> wrote in message
news:OI2CZ8YvGHA.3912@TK2MSFTNGP03.phx.gbl...
> After much work, I figured this out. Thanks for the help.
>
> Couple things were going wrong.
> Running the application differently (IE, Inetmgr, VS studio) caused the
> controls to run under different zones which means depending on which one I
> used, the policy was different.
> Forgot the Allowpartialtrusted attributes which caused the assembly to
> fail to load when strongly named because IE runs a partially trusted host.
> Incorrect version evidence not matching server assembly and a couple of
> other things that I am too embarassed to list...
>
> I've got my head wrapped around this CAS thing now. The only thing that
> bugs me is it doesn't seem that policy can be applied at the parent level
> when the child is set to full trust. Consider a group C with full trust
> that is a child of B with Nothing who is a child of A with Nothing
> permissions. I'd really like the option to prevent the control from
> loading at child B level, but it seems with child C full trust, this is
> not possible. It's easy to do at level C but it would be nice to have that
> option at parent levels for enterprise administration purposes since
> several hundred controls may fall into the same group.
> --
> ________________________
> Warm regards,
> Alvin Bruney [MVP ASP.NET]
>
> [Shameless Author plug]
> Professional VSTO.NET - Wrox/Wiley
> The O.W.C. Black Book with .NET
> www.lulu.com/owc, Amazon
> Blog: http://www.msmvps.com/blogs/alvin
> -------------------------------------------------------
>
>
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:A7DDCBEE-6C89-4297-9D4F-A5927F5B1DAF@microsoft.com...
>> "Alvin Bruney [MVP]" <www.lulu.com/owc> wrote in message
>> news:uitM1XMvGHA.3428@TK2MSFTNGP02.phx.gbl...
>>>I have a managed user control in a web form. No matter how I set the CAS
>>>policy at the machine level, the managed user control always runs.
>>
>> Are you trying to prevent it from running?  If not, what's the problem?
>> (Just asking 'cause most of the complaints we get in this neck of the
>> woods involve stuff not running. <g>)
>>
>>> The only setting that seems to make a difference is machine/all_code
>>> which is currently set to full trust.
>>
>> Was that intentional?  The default permission set for this code group is
>> Nothing.  If you're trying to troubleshoot CAS permission problems, I'd
>> recommend resetting your CAS policy (after making a backup of your
>> current policy, if necessary).
>>
>>
>>> Any lesser setting and the ActiveX control does not work.
>>
>> (Assuming you're actually trying to make your control run when full trust
>> isn't granted to Machine\All_Code...)
>>
>> From what you've included below, it looks like your intention is to use
>> URL and/or site evidence to grant additional permissions to the control
>> assembly.  (BTW, the nesting of site evidence under URL evidence is a bit
>> odd since the site is less specific than the URL, but that's very
>> unlikely to be directly related to your current problem.  You've also got
>> a bunch of extra code groups in there but, again, this isn't likely to be
>> contributing to your current problem.)
>>
>> A couple of things to check:
>>
>> 1.  Is your URL correct?  The CLR won't map from one URL to another that
>> points at the same resource, so you must be using an exact match.
>>
>> 2.  Is your permission set sufficient?  One easy way to test this would
>> be to assign the FullTrust permission set to your URL-based code group.
>> If this allows the control to run but your custom permission set doesn't,
>> the custom set is presumably too restrictive.
>>
>>
>>
>>> Any ideas? I am 100% certain that my ignorance is the cause of this but
>>> I don't know where to look. My setup looks like this:
>>> Add child code group A to Local Intranet code group
>>> Add child node B to code group A
>>> B represents different groups within the enterprise who will build
>>> managed ActiveX controls
>>> Add child node C to B
>>> C represents actual ActiveX controls
>>> C has strong naming member condition and custom permission set
>>> Custom permission set has registry, security, ui, web access, reflection
>>> permissions
>>>
>>> caspol -resolvegroups <url>pocactivex.dll gives me this.
>>>
>>> Level = Machine
>>>
>>> Code Groups:
>>>
>>> 1.  All code: FullTrust
>>>   1.2.  Zone - Intranet: LocalIntranet
>>>      1.2.1.  Zone - Intranet: LocalIntranet
>>>         1.2.1.1.  Url - <url>/*: POCActiveX Permissions
>>>
>>>            1.2.1.1.1.  Site - <url>: POCActiveX Permissions
>>>         1.2.1.2.  All code: Nothing
>>>         1.2.1.3.  All code: Nothing
>>>
>>> Level = User
>>>
>>> Code Groups:
>>>
>>> 1.  All code: FullTrust
>>>
>>> Success
>>>
>>> -------------------------------
>>>
>>> As an experiment, I've tried adding an incorrect version number to the
>>> strong name assembly policy, the activex control still loads correctly.
>>> I abandoned working on my development machine and use two servers to
>>> eliminate my machine as the culprit. No joy.
>>>
>>>
>>> --
>>> ________________________
>>> Warm regards,
>>> Alvin Bruney [MVP ASP.NET]
>>>
>>> [Shameless Author plug]
>>> Professional VSTO.NET - Wrox/Wiley
>>> The O.W.C. Black Book with .NET
>>> www.lulu.com/owc, Amazon
>>> Blog: http://www.msmvps.com/blogs/alvin
>>> -------------------------------------------------------
>>>
>>>
>>>
>>
>
>

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:C76D1350-F741-4670-99DC-E5620E8C2678@microsoft.com...
> It is possible.  There are two general ways to go about this:
>
> 1.  If enterprise-specified CAS restrictions are set at the enterprise
> policy level, neither the machine nor user levels will be able to override
> the restrictions to grant additional permissions.
>
> 2.  Any given code group can be marked as exclusive
> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconattributesofcodegroups.asp),
> which will prevent code that meets the code group membership conditions
> from being granted any additional permissions via other groups.
>
> The main problem with either of the above is that any user that can add a
> child code group to the machine policy level can also alter these supposed
> "protections".  This means that their main benefit is to prevent naïve
> modifications to policy (for example, by application installation packages
> that blindly add code groups to grant additional permissions to the
> distributor's assemblies).
>
>
>
> "Alvin Bruney [MVP]" <www.lulu.com/owc> wrote in message
> news:OI2CZ8YvGHA.3912@TK2MSFTNGP03.phx.gbl...
>> After much work, I figured this out. Thanks for the help.
>>
>> Couple things were going wrong.
>> Running the application differently (IE, Inetmgr, VS studio) caused the
>> controls to run under different zones which means depending on which one
>> I used, the policy was different.
>> Forgot the Allowpartialtrusted attributes which caused the assembly to
>> fail to load when strongly named because IE runs a partially trusted
>> host.
>> Incorrect version evidence not matching server assembly and a couple of
>> other things that I am too embarassed to list...
>>
>> I've got my head wrapped around this CAS thing now. The only thing that
>> bugs me is it doesn't seem that policy can be applied at the parent level
>> when the child is set to full trust. Consider a group C with full trust
>> that is a child of B with Nothing who is a child of A with Nothing
>> permissions. I'd really like the option to prevent the control from
>> loading at child B level, but it seems with child C full trust, this is
>> not possible. It's easy to do at level C but it would be nice to have
>> that option at parent levels for enterprise administration purposes since
>> several hundred controls may fall into the same group.
>> --
>> ________________________
>> Warm regards,
>> Alvin Bruney [MVP ASP.NET]
>>
>> [Shameless Author plug]
>> Professional VSTO.NET - Wrox/Wiley
>> The O.W.C. Black Book with .NET
>> www.lulu.com/owc, Amazon
>> Blog: http://www.msmvps.com/blogs/alvin
>> -------------------------------------------------------
>>
>>
>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
>> news:A7DDCBEE-6C89-4297-9D4F-A5927F5B1DAF@microsoft.com...
>>> "Alvin Bruney [MVP]" <www.lulu.com/owc> wrote in message
>>> news:uitM1XMvGHA.3428@TK2MSFTNGP02.phx.gbl...
>>>>I have a managed user control in a web form. No matter how I set the CAS
>>>>policy at the machine level, the managed user control always runs.
>>>
>>> Are you trying to prevent it from running?  If not, what's the problem?
>>> (Just asking 'cause most of the complaints we get in this neck of the
>>> woods involve stuff not running. <g>)
>>>
>>>> The only setting that seems to make a difference is machine/all_code
>>>> which is currently set to full trust.
>>>
>>> Was that intentional?  The default permission set for this code group is
>>> Nothing.  If you're trying to troubleshoot CAS permission problems, I'd
>>> recommend resetting your CAS policy (after making a backup of your
>>> current policy, if necessary).
>>>
>>>
>>>> Any lesser setting and the ActiveX control does not work.
>>>
>>> (Assuming you're actually trying to make your control run when full
>>> trust isn't granted to Machine\All_Code...)
>>>
>>> From what you've included below, it looks like your intention is to use
>>> URL and/or site evidence to grant additional permissions to the control
>>> assembly.  (BTW, the nesting of site evidence under URL evidence is a
>>> bit odd since the site is less specific than the URL, but that's very
>>> unlikely to be directly related to your current problem.  You've also
>>> got a bunch of extra code groups in there but, again, this isn't likely
>>> to be contributing to your current problem.)
>>>
>>> A couple of things to check:
>>>
>>> 1.  Is your URL correct?  The CLR won't map from one URL to another that
>>> points at the same resource, so you must be using an exact match.
>>>
>>> 2.  Is your permission set sufficient?  One easy way to test this would
>>> be to assign the FullTrust permission set to your URL-based code group.
>>> If this allows the control to run but your custom permission set
>>> doesn't, the custom set is presumably too restrictive.
>>>
>>>
>>>
>>>> Any ideas? I am 100% certain that my ignorance is the cause of this but
>>>> I don't know where to look. My setup looks like this:
>>>> Add child code group A to Local Intranet code group
>>>> Add child node B to code group A
>>>> B represents different groups within the enterprise who will build
>>>> managed ActiveX controls
>>>> Add child node C to B
>>>> C represents actual ActiveX controls
>>>> C has strong naming member condition and custom permission set
>>>> Custom permission set has registry, security, ui, web access,
>>>> reflection permissions
>>>>
>>>> caspol -resolvegroups <url>pocactivex.dll gives me this.
>>>>
>>>> Level = Machine
>>>>
>>>> Code Groups:
>>>>
>>>> 1.  All code: FullTrust
>>>>   1.2.  Zone - Intranet: LocalIntranet
>>>>      1.2.1.  Zone - Intranet: LocalIntranet
>>>>         1.2.1.1.  Url - <url>/*: POCActiveX Permissions
>>>>
>>>>            1.2.1.1.1.  Site - <url>: POCActiveX Permissions
>>>>         1.2.1.2.  All code: Nothing
>>>>         1.2.1.3.  All code: Nothing
>>>>
>>>> Level = User
>>>>
>>>> Code Groups:
>>>>
>>>> 1.  All code: FullTrust
>>>>
>>>> Success
>>>>
>>>> -------------------------------
>>>>
>>>> As an experiment, I've tried adding an incorrect version number to the
>>>> strong name assembly policy, the activex control still loads correctly.
>>>> I abandoned working on my development machine and use two servers to
>>>> eliminate my machine as the culprit. No joy.
>>>>
>>>>
>>>> --
>>>> ________________________
>>>> Warm regards,
>>>> Alvin Bruney [MVP ASP.NET]
>>>>
>>>> [Shameless Author plug]
>>>> Professional VSTO.NET - Wrox/Wiley
>>>> The O.W.C. Black Book with .NET
>>>> www.lulu.com/owc, Amazon
>>>> Blog: http://www.msmvps.com/blogs/alvin
>>>> -------------------------------------------------------
>>>>
>>>>
>>>>
>>>
>>
>>
>