Re: COM Component and Security

From: Lior Amar (lior_amar_at_hotmail.com)
Date: 09/10/03


Date: Wed, 10 Sep 2003 13:30:04 -0400


Yeah but that's a total HACK and totally negates the purpose of NT
authentication. I can have my app run as an Administrator and never have
another security problem also!

Maybe I haven't made it clear what the problem is. It's not that my ASPX
page is not impersonating, it is. It's doing a bang up job doing it. The
problem is when I late bind to a COM object, it runs as the process level
token (ASPNET). Now imagine a software that validates permissions on
internal objects against NT Users role membership. This means that NTUserA
which has NTRoleA will get access to ObjectA. How is this COM object
supposed to be able to do this when its thread is not impersonating. That
means that if I do a LookupAccountName or LookupAccountSid I'll get the
ASPNET user and not my NT user. Of course if I get that then when I start
reading his security context and look for the Role SID, I'll never find it
cause the Thread is running as ASPNET.

My problem is that in my DOTNET world my Security Token (which should be on
my thread) is proper. When I jump out of the DOTNET world into the COM world
my Security Token is wrong. So to solve this problem, I've done the
impersonation and reverting myself. This works just fine but the question is
how does this affect ASPNET? How does me changing the Security Context on
the Thread itself affecting ASPNET? Because I'm pretty sure that the ASPNET
thread is running as ASPNET until it tries to access anything at the OS
level that requires NT Validation. At that point it impersonates and reverts
back. And if I had to guess exactly what ASPNET is doing then I would say
that it's calling the CoImpersonateClient and CoRevertToSelf constantly.

Thanks,

Lior

"Lewis Wang [MSFT]" <v-lwang@online.microsoft.com> wrote in message
news:#NjRSZ5dDHA.2080@cpmsftngxa06.phx.gbl...
> Hi Lior,
>
> Yes, it will affect the way ASPNET functions. After reverting, it restores
> the authentication information on a thread to the authentication
> information on the thread before impersonation began.
>
> If the COM is developed by yourself, you may use COM+ instead of COM to
> work around this issue.
>
> You may go to the Component Services in Administrative Tools and right
> click on the COM+ component, select properties. On the activation tab,
> select "server application" and on the Identity tab, set a user account
> with enough privilege.
>
> You may check the following link for more information:
> INFO: Implementing Impersonation in an ASP.NET Application
> http://support.microsoft.com/?id=306158#3
>
>
> Hope this helps.
>
> Best regards,
> Lewis
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> --------------------
> | From: "Lior Amar" <lior_amar@hotmail.com>
> | References: <#$9Ut9#cDHA.2860@TK2MSFTNGP11.phx.gbl>
> <iryd0ShdDHA.2000@cpmsftngxa06.phx.gbl>
> | Subject: Re: COM Component and Security
> | Date: Mon, 8 Sep 2003 11:40:15 -0400
> | Lines: 116
> | X-Priority: 3
> | X-MSMail-Priority: Normal
> | X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> | X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> | Message-ID: <#R5NG9hdDHA.2932@tk2msftngp13.phx.gbl>
> | Newsgroups: microsoft.public.dotnet.framework.aspnet.security
> | NNTP-Posting-Host: ostnet.net 66.201.203.233
> | Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
> | Xref: cpmsftngxa06.phx.gbl
> microsoft.public.dotnet.framework.aspnet.security:6587
> | X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
> |
> | Ok so I wouldn't do it on the Session_End but that wasn't really my
> | question. Assuming you're reverting at the right time, will it affect
the
> | way ASPNET functions if I do this? I'm more worried about a catch 22
then
> | anything else.
> |
> | Thanks,
> |
> | Lior
> |
> | "Lewis Wang [MSFT]" <v-lwang@online.microsoft.com> wrote in message
> | news:iryd0ShdDHA.2000@cpmsftngxa06.phx.gbl...
> | > Hi Lior,
> | >
> | > If you want to revert back at the end of a session, you may clearly
> | > understand Session_End. For more information, please check the
following
> | > link:
> | >
> | > HttpModule gets InProc Session_Start, not Session_End
> | >
> |
>
http://groups.google.com/groups?q=Session_end&hl=zh-CN&lr=lang_zh-CN|lang_zh
> | >
> -TW|lang_nl|lang_en&ie=UTF-8&oe=UTF-8&selm=nLLrkvRcDHA.2108%40cpmsftngxa06
> | .p
> | > hx.gbl&rnum=1
> | >
> | > Please let me know if you need more information. Thanks.
> | >
> | > Best regards,
> | > Lewis
> | > This posting is provided "AS IS" with no warranties, and confers no
> | rights.
> | >
> | > --------------------
> | > | From: "Lior Amar" <lior_amar@hotmail.com>
> | > | Subject: COM Component and Security
> | > | Date: Fri, 5 Sep 2003 16:52:37 -0400
> | > | Lines: 49
> | > | X-Priority: 3
> | > | X-MSMail-Priority: Normal
> | > | X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> | > | X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> | > | Message-ID: <#$9Ut9#cDHA.2860@TK2MSFTNGP11.phx.gbl>
> | > | Newsgroups: microsoft.public.dotnet.framework.aspnet.security
> | > | NNTP-Posting-Host: ostnet.net 66.201.203.233
> | > | Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
> | > | Xref: cpmsftngxa06.phx.gbl
> | > microsoft.public.dotnet.framework.aspnet.security:6558
> | > | X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
> | > |
> | > | I've been learning more and more about the way .NET and APSNET
handles
> | > | security and impersonation. The more I learn about it the more I see
> the
> | > | value of it in the future when .NET "might" run on Linux or Unix. I
> | > | understand that impersonation in ASPNET is not what most of us are
> used
> | to
> | > | in impersonation.
> | > |
> | > | Ask anybody who's worked on security in Windows what impersonation
> means
> | > and
> | > | he'll probably point you out to ImpersonateLoggedOnUser,
> SetThreadToken,
> | > | LookupAccountName etc... . He'll explain to you that the Process has
a
> | > | specific security context but that every thread in that process can
> run
> | in
> | > | its own security context. Knowing this thread level security context
> to
> | > be a
> | > | fact, the developer would architect his webapp or distributed system
> | with
> | > | that in mind. The best part is if he looks at the
> | > | System.Security.Principal.WindowsIdentity.GetCurrent.Name he would
> get a
> | > | confirmation that ASPNET is impersonating the logged on user. But
what
> | > | happens if he make a late bound call to a COM object? Well from what
I
> | > found
> | > | out, the COM object is running as the ASPNET security context (or
> | whatever
> | > | user you set in the Machine.Config). This makes absolute sense once
> you
> | > | understand that security is handled by the CLR and not directly by
the
> | OS
> | > | (at one point or another it is the OS but the CLR does its magic
> there).
> | > |
> | > | Finally, my question (I can be long winded at times)...If I force
the
> | > THREAD
> | > | to impersonate before I call out to a late bound COM object will I
> cause
> | > | ASPNET to go nuts? In my tests it seems all great. Now I'm doing
this
> | just
> | > | before calling out and reverting back after the call. Of course if
> this
> | > | doesn't cause a problem, the next obvious question is can I put it
at
> | the
> | > | Session Start and revert back at the end of a session?
> | > |
> | > | Here's how I'm going about it, in case it affects the end result:
> | > |
> | > | 1. Retrieve the current .NET security token handle:
> | > | ....GetCurrentIdentity.Token.ToInt32
> | > | 2. Call ImpersonateLoggedOnUser(.NETToken)
> | > | 3. Latebind to COM object
> | > | 4. RevertToSelf
> | > |
> | > | When I do this, the COM object reports running in the correct
security
> | > | context. If I don't do this then the Security context is whatever
> ASPNET
> | > is
> | > | configured to run as.
> | > |
> | > | Now, I remember reading something a while ago about the Security
Token
> | > being
> | > | deleted or something about the CLR invalidating it. Something that's
> | > making
> | > | me wonder if my approach is valid. Then again, I might just be
> imagining
> | > | things! Or maybe I'm just missing something SO OBVIOUS and making my
> | life
> | > | difficult when .NET already has the feature built into it.
> | > |
> | > | Lior,
> | > |
> | > |
> | > |
> | >
> |
> |
> |
>



Relevant Pages

  • Re: COM Component and Security
    ... Hi Lior, ... | Subject: Re: COM Component and Security ... | ASPNET user and not my NT user. ... |> information on the thread before impersonation began. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: COM Component and Security
    ... it will affect the way ASPNET functions. ... Implementing Impersonation in an ASP.NET Application ... | Subject: Re: COM Component and Security ... Assuming you're reverting at the right time, ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Confusion about authentication and impersonation.
    ... >> If I use windows authentication, what is the effect of the ... >> impersonation if I set the impersonate of the identity element to ... >> ASP.NET working process run under the ASPNET account? ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Queries in regards Intranet Security.
    ... reading the part "Intranet Security: ... For Authentication: ... Use Integrated Windows Auth at IIS. ... Use Windows Auth at ASP.NET (With Impersonation = False) ...
    (microsoft.public.dotnet.security)
  • Few Questions in regards Intranet Security.
    ... reading the part "Intranet Security: ... For Authentication: ... Use Integrated Windows Auth at IIS. ... Use Windows Auth at ASP.NET (With Impersonation = False) ...
    (microsoft.public.dotnet.framework.aspnet.security)