COM Component and Security

[Lewis Wang [MSFT]]

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
[url]http://groups.google.com/groups?q=Session_end&hl=zh-CN&lr=lang_zh-CN|lang_zh[/url]
-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!TK2MSFTN GP11.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.GetCurre nt.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,
|
|
|

[Lior Amar]

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
>

[url]http://groups.google.com/groups?q=Session_end&hl=zh-CN&lr=lang_zh-CN|lang_zh[/url]

> -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!TK2MSFTN GP11.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.GetCurre nt.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,
> |
> |
> |
>

[Lewis Wang [MSFT]]

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
[url]http://support.microsoft.com/?id=306158#3[/url]


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!tk2msftn gp13.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
| >
|
[url]http://groups.google.com/groups?q=Session_end&hl=zh-CN&lr=lang_zh-CN|lang_zh[/url]
| >
-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!TK2MSFTN GP11.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.GetCurre nt.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,
| > |
| > |
| > |
| >
|
|
|

[Lior Amar]

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
> [url]http://support.microsoft.com/?id=306158#3[/url]
>
>
> 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!tk2msftn gp13.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
> | >
> |
>

[url]http://groups.google.com/groups?q=Session_end&hl=zh-CN&lr=lang_zh-CN|lang_zh[/url]

> | >
> -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!TK2MSFTN GP11.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.GetCurre nt.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,
> | > |
> | > |
> | > |
> | >
> |
> |
> |
>

[Lewis Wang [MSFT]]

Hi Lior,

Thanks for your update. I am checking this issue, and will get back to you
with my findings.

Best regards,
Lewis
--------------------
| From: "Lior Amar" <lior_amar@hotmail.com>
| References: <#$9Ut9#cDHA.2860@TK2MSFTNGP11.phx.gbl>
<iryd0ShdDHA.2000@cpmsftngxa06.phx.gbl>
<#R5NG9hdDHA.2932@tk2msftngp13.phx.gbl>
<#NjRSZ5dDHA.2080@cpmsftngxa06.phx.gbl>
| Subject: Re: COM Component and Security
| Date: Wed, 10 Sep 2003 13:30:04 -0400
| Lines: 228
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
| X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
| Message-ID: <umhwvD8dDHA.3240@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!TK2MSFTN GP11.phx.gbl
| Xref: cpmsftngxa06.phx.gbl
microsoft.public.dotnet.framework.aspnet.security: 6621
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
|
| 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
| > [url]http://support.microsoft.com/?id=306158#3[/url]
| >
| >
| > 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!tk2msftn gp13.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
| > | >
| > |
| >
|
[url]http://groups.google.com/groups?q=Session_end&hl=zh-CN&lr=lang_zh-CN|lang_zh[/url]
| > | >
| >
-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!TK2MSFTN GP11.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.GetCurre nt.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,
| > | > |
| > | > |
| > | > |
| > | >
| > |
| > |
| > |
| >
|
|
|
|

[MSFT]

Hi Lior,

Based on my understanding, you have two concerns about the problem?

1. When you do following, will it affect ASP.NET application and cause some
problems:
Retrieve the current .NET security token handle:
....GetCurrentIdentity.Token.ToInt32
Call ImpersonateLoggedOnUser(.NETToken)
Latebind to COM object
RevertToSelf

2. Can we do ImpersonateLoggedOnUser in session start and do RevertToSelf
in session end.

For question 1, it wouldn't do any "bad thing" to ASP.NET, as you see if
this KB article:

[url]http://support.microsoft.com/?id=306158[/url]

The way to impersonate in the sample code is similar to yours

For question 2, I think it may not be possible. ASPNET may use different
thread to handle different request. It is recommended that call
ImpersonateLoggedOnUser and RevertToSelf in one method.

Does this answer your question?

Luke
Microsoft Online Partner Support

Get Secure! [url]www.microsoft.com/security[/url]
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Lior Amar]

Thanks Luke and Lewis,

It pretty much confirms what I thought and what I implemented. I only
impersonate before a COM call and revert right afterwards. Should be
documented somewhere that APSNET will run in the proper security context but
that late bound COM objects wont. It's a pain to figure out why things
aren't working.

Anyway, answers my question.

Thanks,

Lior


"MSFT" <lukezhan@online.microsoft.com> wrote in message
news:Gz3lBbFfDHA.3192@cpmsftngxa07.phx.gbl...

> Hi Lior,
>
> Based on my understanding, you have two concerns about the problem?
>
> 1. When you do following, will it affect ASP.NET application and cause

some

> problems:
> Retrieve the current .NET security token handle:
> ...GetCurrentIdentity.Token.ToInt32
> Call ImpersonateLoggedOnUser(.NETToken)
> Latebind to COM object
> RevertToSelf
>
> 2. Can we do ImpersonateLoggedOnUser in session start and do RevertToSelf
> in session end.
>
> For question 1, it wouldn't do any "bad thing" to ASP.NET, as you see if
> this KB article:
>
> [url]http://support.microsoft.com/?id=306158[/url]
>
> The way to impersonate in the sample code is similar to yours
>
> For question 2, I think it may not be possible. ASPNET may use different
> thread to handle different request. It is recommended that call
> ImpersonateLoggedOnUser and RevertToSelf in one method.
>
> Does this answer your question?
>
> Luke
> Microsoft Online Partner Support
>
> Get Secure! [url]www.microsoft.com/security[/url]
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>
>