Out of Process execution and .NET

  • Thread starter Thread starter charlie
  • Start date Start date
C

charlie

Sorry for the cross-posting but I really need some help here. I posted
before but didn't get any responses so I am trying my luck again.

I have a fairly simple scenario that is complicated by the ASPNET userid
security model and my need to access network file shares.

We currently have an executable that performs a data merge with data from a
database into some RTF documents. Then, it takes the RTF doc and converts
it to a PDF doc. All this works fine from the command line. It also works
fine when everything (RTF doc and resulting PDF doc) reside on the webserver
machine.

However, if I change the location of the RTF doc from the local machine to a
network file share, I get file access exceptions. I understand that this is
because the ASPNET account is local and does not have network permissions.
However, I have tried impersonating and that does not work either. I have
impersonated at the application level using Web.Config file and at the code
block level using the WindowsImpersonationContext object.

The sequence of processes is:
1) Call the web service to perform the Document Merge
2) The web service makes a call to a Remoting Server
3) The MegerEngine.exe program is executed from the Remoting server
4) Control is passed back to the web service and then confirmation is
returned to the calling user.

The code I am executing is:

Process p = new Process();
p.StartInfo.FileName = @"c:\temp\MergeEngine.exe";
p.StartInfo.Arguments = @"c:\temp\rtfmerge\test1.ini";
p.Start();
p.WaitForExit();

The only difference between successful execution and failure is access a
network file share. The reference to the network file share is in the INI
file that is passed as a parameter to MergeEngine.exe.

I have also tried using asserts but that has not proven successful either.
I would greatly appreciate any insight.
Charlie
 
I think you need to revist impersonation. I've had to do something along
the same lines, and impersonation made it happen.

The account that you used for impersonation, was it a domain account? If
so, did you put the domain in the impersonation string?

What I did was create a Domain account that ASP.net runs as, and gave that
user access to the shares it needed to write to.

Michael
 
"charlie" <[email protected]> expressed
thusly:


Hi Charie,
I have a fairly simple scenario that is complicated by the ASPNET
userid security model and my need to access network file shares.
Click to expand...

Please help me understand a few things...

It seems that a client would call a web service which would then invoke
an EXE in a separate process to perform the merge and transform the
resultant RTF file (with the fields populated from data in a database)
into a PDF. Is this correct?
The only difference between successful execution and failure is access
a network file share. The reference to the network file share is in
the INI file that is passed as a parameter to MergeEngine.exe.
Click to expand...

This makes since because the process is created with the security token
of the logon which created it. By default the token of the ASPNET logon
doesn't have network access privilege.

I've done something like this before, and I used COM+ and Impersonation
to solve the heavy lifting of moving files around the network. You can do
this with .Net... create a COM+ app running under an account with
sufficient privileges that will make the PDF and copy it into a cache on
the webserver... the cache can be dynamically managed with a speed/space
optimization strategy, and give a boost to performance to boot...
Finally, tailor authorization to the COM+ impersonated account on the
needed shares to minimize risk.

HTH. Let me know if I am off base...

-rory 8)
 
What I did was create a Domain account that ASP.net runs as, and gave
that user access to the shares it needed to write to.

Michael
Click to expand...

Hi Michael,

For the benefit of the readership, please let me state that this will work,
but generally leaves a security weakness. A better way might be to do such
work in a COM+ application, which is impersonated in the same way, but the
privileges are isolated from the anonymous account running web pages by
only those methods which are exposed from the COM+ app.

-rory 8)
 
Yes very true. I do beleive that the account was setup in such a way as to
have very limited priviledges on the domain as well as a very strong
password.

The COM+ solution is probably a better way to impliment this solution.

Michael
 
You are correct in your understanding. The reason for the separate .EXE is
twofold:
1) it already exists and works just fine
2) as an out of process .EXE it cleans up after itself - apparently, some of
the dlls it uses did not clean up after themselves when executed in process
in the old ASP application.

I am toying with a new approach that basically bypasses the security
restrictions I have encountered. I will impersonate a Domain Account so
that I can copy the RTF files locally (this works just fine), then perform
the .EXE merge and conversion. When all is said and done, I will clean up
the files that were copied locally.

I will also investigate the COM+ approach but I have a feeling that the old
garbage collection issues will come up again. This is a process that will
get quite a bit of activity during peak periods so I can't have memory
leaks.

Thanks for your suggestions. I will post my results when they have been
tested out and proven to work.

Charlie
 
"charlie" <[email protected]> expressed in the message known
far and
wide by the name @newssvr11.news.prodigy.com
thusly:

Hi charlie,
I am toying with a new approach that basically bypasses the security
restrictions I have encountered. I will impersonate a Domain Account
so that I can copy the RTF files locally (this works just fine), then
perform the .EXE merge and conversion. When all is said and done, I
will clean up the files that were copied locally.
Click to expand...

I would really advocate for a different approach, since this is
a
security weakness of the highest sort.
I will also investigate the COM+ approach but I have a feeling that
the old garbage collection issues will come up again. This is a
process that will get quite a bit of activity during peak periods so I
can't have memory leaks.
Click to expand...

I don't think so, since COM+ was actually engineered for .Net
and the
CLR in mind... (actually, it was going to be part of it, but
the
development of the CLR lagged, and COM+ could be delivered with
benefits
to the emerging trend of distributed applications).

One of the things that COM+ can do is to keep objects
instantiated and
running in a pool. This is a boon for distributed apps, like an
ASP.Net
app, since it calls the COM+ object to do some work, and then
disconnects, but the object sticks around waiting to service
more
clients. You can have the COM+ objects impersonating whatever
account
you want that has network rights wherever you would like
(though I would
still advocate a Domain User with specifically tailored rights,
rather
than a blanket Domain Admin account), and enforces specific
access
restrictions based on client and on role (COM+ role-based
security is
very fine-grain). Object recycling and memory issues are dealt
with in
the best possible manner with these techniques, in a proven
execution
environment.

Here's what I did: I created a .Net app in C# which uses
System.EnterpriseServices (a.k.a. COM+) to keep a number of
objects
running which will copy files from one place on the network to
somewhere
else. I created an ASP.Net application which impersonates the
caller
(using the Windows Principal available through NTLM
authentication). If
the caller is a privileged account (Domain Admin) then the
ASP.Net
application calls the COM+ component in the Admin role, and
files can be
copied or moved literally anywhere, since we have
administrative shares
on all our computers. When the account is not privileged, it is
mapped
to a different COM+ role, and only file copying from one
specific share
on a certain machine to another specific share on the web app
box can be
accomplished. Very secure yet flexible, since it relies on the
Domain to
authenticate the principal, and leverages the intrinsic objects
available in the ASP.Net application. COM+ roles would also
allow us to
add another role in the future and add Domain users and/or
groups to
accomplish copy/move operations to other machines.
Thanks for your suggestions. I will post my results when they have
been tested out and proven to work.

Charlie
Click to expand...

I hope to hear of your work...

kindly,
-rory 8)
 
Rory -

Thanks for the push in the COM+ direction. That did the trick and it is
working as it should. Also the security issues are much better addressed
with a COM+ server.

Once again, thanks for suggestion.
Charlie
 
Back
Top