Elevating trust on a locally deployed .NET application

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

dmcaylor - 17 Mar 2008 17:31 GMT

Let me preface this by saying I do not know .NET from .NUT.

We have a .NET 1.1 vendor application that need to be deployed to
several thousand XP workstations.
Users have restricted accounts on these workstations. (i.e. not power
users or admins)

The initial application MSI is installed remotely by an admin account.
It installs a "bootstrap" file that the users run directly. When run,
the bootstrap connects to a Unix webserver and pulls down the current
executable for the application.

My problem is with rights. Neither the bootstrap.exe or the client.exe
will install or run correctly unless the user is an administrator.
Both the bootstrap and client try to create files under C:\WINDOWS
\assembly\NativeImages1_v1.1.4322\System, System.Design,
System.Draving, System.Windows.Forms, & System.Xml. They both also
attempt to modify C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG
\security.config.cch, and enterprise.config.cch.

When running under a restricted user account, all of those attempted
creates/writes fail. The programmer who wrote the application is no
longer with the vendor, and their solution is to make everyone an
admin (not going to happen). This is a core application, and I do not
have the option of shucking it out the door.

So, I need to know how to elevate the trust for these executables on
several thousand workstations. Neither executable has been given a
strong name by the vendor, so I don't think CASPOL will work? Also,
although the bootstrap is installed by an admin account at the time of
deployment, the client.exe does not get downloaded to the local PC
until the user runs the bootstrap. So there is no file available to
elevate trust on.

The .Net 1.1 config tools mention creating an MSI to deploy security
changes, but it appears to make a copy of all my security settings,
not just those related to this app.

Thanks. Any assistance would be appreciated.

Reply to this Message

Joe Kaplan - 17 Mar 2008 17:53 GMT

This won't have anything to do with CAS or CASPOL as it is local Windows
permissions that are the issue here. CAS can only further reduce the
permissions that the OS itself grants. It cannot elevate above what the OS
grants.

So, what you need to do is to find a way to get this deployment done using
an admin account. There are generally ways to do this sort of thing with
MSI and group policy and such, but it looks as if the original deployment
mechanism was implemented such that you can't take advantage of that.
Ideally, the initial deployment that runs with the elevated permissions
would perform all of the actions that require high permissions such as ngen
(which is what is likely writing to native images) and whatever XML policy
changes are being implemented to change the local .NET CAS policies.

This might be something that could be worked into a startup script GPO or
something, but that isn't really my specialty at all. Perhaps asking the
question in one of the group policy newsgroups would be good? Sorry I don't
have a better answer.

Joe K.

Signature

Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

> Let me preface this by saying I do not know .NET from .NUT.
>
[quoted text clipped - 35 lines]
>
> Thanks. Any assistance would be appreciated.

Reply to this Message

dmcaylor - 17 Mar 2008 19:32 GMT

On Mar 17, 12:53 pm, "Joe Kaplan"
<joseph.e.kap...@removethis.accenture.com> wrote:

> This won't have anything to do with CAS or CASPOL as it is local Windows
> permissions that are the issue here. CAS can only further reduce the
[quoted text clipped - 61 lines]
>
> - Show quoted text -

Joe,

The install goes as such

An MSI is deployed via SMS. This MSI installs the bootstrap.exe, and
populates reg keys.

The bootstrap.exe loads a full screen application that requires user
authentication, so it cannot be launched after the MSI.
After authentication it pulls down the client.exe if it does not exist
and loads it. During the load the client attempts to self configure,
but cannot.

I can script modify rights for the config directory, but there is more
than just NTFS rights at work here. If I manually elevate the trust on
bootstrap.exe before it is run, using the .NET 1.1 wizards, then the
bootstrap registers/installs its "components" sucessfully without
being denied access. (I don't know if "components" is the right term
here. "Assemblies" perhaps?) I've checked this with ProcessMonitor.
However, the client.exe still has the same problem, and would need to
be manually elevated as well.

So I need to :

Elevate bootstrap.exe, which is deployed, but has not yet been
run.
Elevate client.exe, which will not be downloaded locally until
the bootstrap runs successfully.

Sorry. I know this is clear as mud.

Reply to this Message

Rate this thread:

Elevating trust on a locally deployed .NET application

Free Magazines