Re: Out of Process execution and .NET

From: Rory Plaire (_no_spam_no_rplaire_no_spam_no__at_peak.org)
Date: 11/06/03

  • Next message: Brian Mahloch: "Forms Authentication Cookie via IP Only" 
    Date: Wed, 05 Nov 2003 15:00:03 -0800

    "charlie" <charlie@nunya.com> expressed in the message known
    far and
    wide by the name news:Dp9qb.293$y84.246677627
    @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.

    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.

    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
    >

    I hope to hear of your work...

    kindly,
    -rory 8)

  • Next message: Brian Mahloch: "Forms Authentication Cookie via IP Only"

    Relevant Pages

    • Re: How to use WindowsPrincipal properly??
      ... > If you want to check if the user is in the local computers security group ... > used by the general public you have to use Basic Authentication of course. ... You can logon a set account ... > WindowsIndentity which is then used to Impersonate. ...
      (microsoft.public.dotnet.framework.aspnet.security)
    • Re: Security
      ... web.config file to impersonate a domain user that has access to the database ... registry the domain user and password. ... have Windows Integrated Security set. ... user while running the code under the impersonated account. ...
      (microsoft.public.dotnet.framework.aspnet)
    • RE: Queryinterface Error
      ... AS for the problem you described, it is likely due to security issue. ... the current logon user account. ... IIS: Integrited windows? ... By default, if we didn't use impersonate, asp.net will run under the ...
      (microsoft.public.dotnet.framework.aspnet)
    • Re: NTLM Win2000 and Impersonation
      ... >> account which is part of Administrator group everything ... >> returned security context is used to retrieve a token ... >> impersonate an Administrator. ...
      (microsoft.public.platformsdk.security)
    • Re: NTLM Win2000 and Impersonation
      ... > I am using NTLM in Win2000 to impersonate an Administrator ... > account which is part of Administrator group everything ... > returned security context is used to retrieve a token ...
      (microsoft.public.platformsdk.security)