Re: Enterprise Policy URL Condition
From: Darren Mombourquette (dmombour_at_hotmail.com)
Date: 08/30/03
- Next message: STom: "Passing Security Context to remote objects"
- Previous message: Drebin: "Re: HTTPS with WebResponse class"
- In reply to: Marcelo Birnbach [MS]: "Re: Enterprise Policy URL Condition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 29 Aug 2003 19:00:14 -0700
Hi Marcelo,
I am doing both. I have an asp.net web application that contains a
couple of embeded user controls, and a couple of client side apps that
will be run directly off the server. Up until now we have been
shipping a simple utility with our product that sets a machine level
policy on the users machine for a URL condition of
"http://serveraddress/*" and grant full trust. This seems to be all
that is nescessary to grant full trust to any application either
embeded or run directly off the server and it has been working well
thus far. The other issues you refer to when talking about embeded
controls I believe have to do with using other policy types with
embeded controls such as strong name conditions.
My goal is to have the administrator run a utility on the domain that
would create an Enterprise policy URL condition for the same URL,
saving them from running the utility on all client machines. Some of
our customers have hundreds of clients and this would save them
considerable amounts of time.
I have run tests internally with Enterprise Policies on our own
domain, they seem to work for a Strong Name condition but not for a
the URL condition, it never seems to be evaluated.
Yes I am aware that a policy of http://machinename/* and
http://10.1.1.1/* are two different policies even though they are the
same machine.
The tests I ran were as follows:
First put an myapp.exe that is strong named on a network share. Tried
to run it - a security exception is thrown. (Expected)
Created an Enterprise Level policy on the domain with a strong name
condition. Tried to run the app again - Succeeded. (Expected)
Second my myapp.exe in a virtual directory on a webserver at
http://10.1.1.1/myapp.exe. Tried to run it - Security exception.
(Expected)
Created a MACHINE policy URL condition for "http://10.1.1.1/*". Tried
to run it - Succeeded. (Expected)
Deleted this MACHINE policy and created an ENTERPRISE policy on our
domain with the same condition. Tried to run it. Security exception.
(NOT Expected)
Is there a piece of the puzzle that I'm missing here?
Thanks,
Darren
"Marcelo Birnbach [MS]" <mbirnbac@online.microsoft.com> wrote in message news:<e0qd#ebbDHA.2960@tk2msftngp13.phx.gbl>...
> How are you starting your application? Are you running an exe from a server
> or just embedding a managed control in an html page? If you are doing the
> second, then you need to be aware of some other issues (you have to give
> permissions to the AppDomain where the control is created)
>
> When you refer as "http://serveraddress/", is that the IP address of the
> server? If you modify policy using the IP address and then you access the
> assembly using the server name, then the code group is not going to match
> since the IP address and the server name are not equivalent when resolving
> security policy.
>
> Thanks,
> Marcelo
>
> "Darren Mombourquette" <dmombour@hotmail.com> wrote in message
> news:e48606a8.0308270725.12b279fa@posting.google.com...
> > Hi Matt,
> > I just checked my enterprise.config file and it looks fine. My URL
> > condition did not get escaped in the config file, it is written as
> > Url="http://serveraddress/*" which appears to be correct.
> > Because if I create a local "Machine policy" for any URL it works fine
> > using this notation and when checking the config file is does not get
> > escaped.
> > I looked at your previous post and you have written the notation to be
> > "http://serveraddress/.*" I don't believe the . before the * is the
> > correct notation.
> > Anyway I did try to escape my * and entered
> > Url="http://serveraddress/\*" in my config file and it still did not
> > work with clients of the domain.
> >
> > Darren
> >
> >
> > "Matt L" <matt@nospam.com> wrote in message
> news:<020401c36bf4$5f9a0ef0$a301280a@phx.gbl>...
> > > I just posted a similar question, and the problem is that
> > > the statement "http://ourwebserver/*" becomes escaped
> > > to "http://ourwebserver/\*" in the security file. In
> > > otherwords, the '*' becomes a literal and the only URL
> > > that matches is literallyl "http://ourwebserver/*", which
> > > is nothing. The only workaround I have found so far is to
> > > hand edit the security.config file to
> > > change "http://ourwebserver/\*"
> > > to "http://ourwebserver/*". Be warned that any additional
> > > modifications to the permission set using the
> > > configuration MMC snap-in will cause your hand changes to
> > > be lost.
> > >
> > > Matt
> > >
> > > >-----Original Message-----
> > > >Hello,
> > > >I am trying to set an Enterprise policy based on a URL
> condition for
> > > >our WebServer and the policy does not seem to take effect
> on client
> > > >machines.
> > > >What I did was this:
> > > >On our domain I created two security policies in the
> Enterprise Level.
> > > >One a strong name condition based on our company public
> key. And
> > > >another a URL condition with the following setting
> > > >"http://ourwebserver/*" and I granted full trust to both
> and set the
> > > >level final attribute.
> > > >Now the strong named security policy works. When I try to
> run .net
> > > >apps that are strong named off of a network share the
> policy is
> > > >evaluated and the app runs successfully. But when I try
> to run an app
> > > >via a URL off of our webserver the code isn't trusted.
> > > >
> > > >Can you not use a URL condition for an Enterprise Policy?
> > > >
> > > >Thanks,
> > > >Darren Mombourquette
> > > >.
> > > >
- Next message: STom: "Passing Security Context to remote objects"
- Previous message: Drebin: "Re: HTTPS with WebResponse class"
- In reply to: Marcelo Birnbach [MS]: "Re: Enterprise Policy URL Condition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|