Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Security > IIS 6.0 Bug?

Reply
Thread Tools

IIS 6.0 Bug?

 
 
Dominick Baier
Guest
Posts: n/a
 
      09-13-2006
Hi,

which framework version are you using. Impersonation tokens are not always
propagated to async operations.

In 1.1 they are never propagated. In 2.0 you can control that via a config
setting

http://www.leastprivilege.com/WhatIsAspnetconfig.aspx

---
Dominick Baier, DevelopMentor
http://www.leastprivilege.com

> Hi,
>
> I apologize for the extensive cross-posting but I'm getting desparate.
>
> We have a web page calling one or another web service. Both web
> service communicate with Sharepoint 2003, and both temporarily change
> impersonation using WindowsImpersonationContext class and then revert
> back with WindowsImpersonationContext.Undo() to typically save
> documents with the correct user name.
>
> Calling the web services synchronously works fine, but we need it to
> work asynchronously (typically creating and saving a document before
> the web services do some work on it).
>
> The problem is, instead of reverting to the original user,
> WindowsImpersonationContext ends up as the user running the
> Application
> Pool
> for the web page. I have been unable to find out anything why this
> happens.
> Furthermore, I created a new Application Pool for the web page,
> thinking perhaps sharing the same pool was the problem, but before I
> could attach it to the web page the problem appeared to solve itself,
> for a short time.
>
> Doing some extensive testing I have concluded this:
> WindowsImpersonationContext.Undo() works for a short time if a dummy
> application pool (not used by anything) is STARTED
> WindowsImpersonationContext.Undo() works for a short time if a dummy
> application pool (not used by anything) is STOPPED
> When it works, it seems to work as long as only one web service is
> called,
> and it stops working as soon as the other web service is called.
> ????
>
> The only google result I could come up with related to this does not
> have a solution or email address
>
> http://www.derkeiler.com/Newsgroups/...net.security/2
> 005-02/0223.html
>
> Any idea, suggestions or something to try is extremely welcome
>
> - Morten
>



 
Reply With Quote
 
 
 
 
Dominick Baier
Guest
Posts: n/a
 
      09-13-2006
then i am not sure what your problem is...

if you think it is not impersonation related - you have to tell me more about
the problems you are seeing.

---
Dominick Baier, DevelopMentor
http://www.leastprivilege.com

> We use .Net 2.0, and upon further studies, it is not connected to
>
> WindowsImpersonationContext since only one web service uses that.
>
> What configuration is required?
>
> We use an encrypted identity section
>
> <trust level="Full" originUrl=""/>
> <identity configProtectionProvider="RsaProtectedConfiguratio nProv
> ider">
> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
> xmlns="http://www.w3.org/2001/04/xmlenc#">
> <EncryptionMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
> <EncryptionMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
> <KeyName>Rsa Key</KeyName>
> </KeyInfo>
> <CipherData>
>
> <CipherValue>IKGgtOuiQqSL6KZOurRXMNSJxNioerQcyGGS3 Ng2y6Sg
> snjZqWQMztRTALlkbaVQM3zsh4BSnACU4pN+s1tWHDV1EKSyfC M7m5R5G54vUvF+oqj9MV
> tZ
> 12QVhv2i2hun95oHNtgAgYJjVbzAudcKMTe/phWP61iXqTgxKKNc+xw=</CipherValue>
>
> </CipherData>
> </EncryptedKey>
> </KeyInfo>
> <CipherData>
>
> <CipherValue>RrRnNXdcQQozeNEGPuinT9aaRT2M9RGgOBe1O 9/u9IIAzOfl
> IZRr2UN0jWfiGk+WduHx/kM3ZN2s05k3/gQMcwZhykXHRFLAcURapxzjBRqz2HBh2ad05Q
> =
> =</CipherValue>
> </CipherData>
> </EncryptedData>
> </identity>
> and
>
> <authentication mode="Windows"/>
> <authorization>
> <allow users="*"/>
> </authorization>
> - Morten
>
> On Wed, 13 Sep 2006 11:46:50 +0200, Dominick Baier
>
> <dbaier@pleasepleasenospam_leastprivilege.com> wrote:
>
>> Hi, which framework version are you using. Impersonation tokens are
>> no
>>

> t
>
>> always propagated to async operations.
>>
>> In 1.1 they are never propagated. In 2.0 you can control that via a
>>
>> config setting
>>
>> http://www.leastprivilege.com/WhatIsAspnetconfig.aspx
>>
>> ---
>> Dominick Baier, DevelopMentor
>> http://www.leastprivilege.com
>>> Hi,
>>> I apologize for the extensive cross-posting but I'm getting desparat

> e.
>
>>> We have a web page calling one or another web service. Both web
>>> service communicate with Sharepoint 2003, and both temporarily
>>> change
>>>
>>> impersonation using WindowsImpersonationContext class and then
>>> revert
>>>
>>> back with WindowsImpersonationContext.Undo() to typically save
>>> documents with the correct user name.
>>> Calling the web services synchronously works fine, but we need it to
>>> work asynchronously (typically creating and saving a document before
>>> the web services do some work on it).
>>> The problem is, instead of reverting to the original user,
>>> WindowsImpersonationContext ends up as the user running the
>>> Application
>>> Pool
>>> for the web page. I have been unable to find out anything why this
>>> happens.
>>> Furthermore, I created a new Application Pool for the web page,
>>> thinking perhaps sharing the same pool was the problem, but before I
>>> could attach it to the web page the problem appeared to solve
>>> itself,
>>> for a short time.
>>> Doing some extensive testing I have concluded this:
>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
>>> application pool (not used by anything) is STARTED
>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
>>> application pool (not used by anything) is STOPPED
>>> When it works, it seems to work as long as only one web service is
>>> called,
>>> and it stops working as soon as the other web service is called.
>>> ????
>>> The only google result I could come up with related to this does not
>>> have a solution or email address
>>> http://www.derkeiler.com/Newsgroups/...otnet.security

> /2
>
>>> 005-02/0223.html
>>> Any idea, suggestions or something to try is extremely welcome
>>> - Morten



 
Reply With Quote
 
 
 
 
Morten Wennevik
Guest
Posts: n/a
 
      09-13-2006

Hi,

I apologize for the extensive cross-posting but I'm getting desparate.

We have a web page calling one or another web service. Both web service
communicate with Sharepoint 2003, and both temporarily change impersonation
using WindowsImpersonationContext class and then revert back with
WindowsImpersonationContext.Undo() to typically save documents with the
correct user name.

Calling the web services synchronously works fine, but we need it to work
asynchronously (typically creating and saving a document before the web
services do some work on it).

The problem is, instead of reverting to the original user,
WindowsImpersonationContext ends up as the user running the Application
Pool
for the web page. I have been unable to find out anything why this
happens.

Furthermore, I created a new Application Pool for the web page, thinking
perhaps sharing the same pool was the problem, but before I could attach it
to the web page the problem appeared to solve itself, for a short time.

Doing some extensive testing I have concluded this:
WindowsImpersonationContext.Undo() works for a short time if a dummy
application pool (not used by anything) is STARTED
WindowsImpersonationContext.Undo() works for a short time if a dummy
application pool (not used by anything) is STOPPED
When it works, it seems to work as long as only one web service is called,
and it stops working as soon as the other web service is called.

????

The only google result I could come up with related to this does not have a
solution or email address

http://www.derkeiler.com/Newsgroups/...5-02/0223.html

Any idea, suggestions or something to try is extremely welcome

- Morten
 
Reply With Quote
 
Morten Wennevik
Guest
Posts: n/a
 
      09-13-2006
We use .Net 2.0, and upon further studies, it is not connected to
WindowsImpersonationContext since only one web service uses that.

What configuration is required?

We use an encrypted identity section

<trust level="Full" originUrl=""/>
<identity configProtectionProvider="RsaProtectedConfiguratio nProvider">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>IKGgtOuiQqSL6KZOurRXMNSJxNioerQcyGGS3 Ng2y6SgsnjZqWQMztRTALlkbaVQM3zsh4BSnACU4pN+s1tWHDV 1EKSyfCM7m5R5G54vUvF+oqj9MVtZ12QVhv2i2hun95oHNtgAg YJjVbzAudcKMTe/phWP61iXqTgxKKNc+xw=</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
<CipherData>
<CipherValue>RrRnNXdcQQozeNEGPuinT9aaRT2M9RGgOBe1O 9/u9IIAzOflIZRr2UN0jWfiGk+WduHx/kM3ZN2s05k3/gQMcwZhykXHRFLAcURapxzjBRqz2HBh2ad05Q==</CipherValue>
</CipherData>
</EncryptedData>
</identity>

and

<authentication mode="Windows"/>
<authorization>
<allow users="*"/>
</authorization>


- Morten

On Wed, 13 Sep 2006 11:46:50 +0200, Dominick Baier
<dbaier@pleasepleasenospam_leastprivilege.com> wrote:

> Hi, which framework version are you using. Impersonation tokens are not
> always propagated to async operations.
>
> In 1.1 they are never propagated. In 2.0 you can control that via a
> config setting
>
> http://www.leastprivilege.com/WhatIsAspnetconfig.aspx
>
> ---
> Dominick Baier, DevelopMentor
> http://www.leastprivilege.com
>
>> Hi,
>> I apologize for the extensive cross-posting but I'm getting desparate.
>> We have a web page calling one or another web service. Both web
>> service communicate with Sharepoint 2003, and both temporarily change
>> impersonation using WindowsImpersonationContext class and then revert
>> back with WindowsImpersonationContext.Undo() to typically save
>> documents with the correct user name.
>> Calling the web services synchronously works fine, but we need it to
>> work asynchronously (typically creating and saving a document before
>> the web services do some work on it).
>> The problem is, instead of reverting to the original user,
>> WindowsImpersonationContext ends up as the user running the
>> Application
>> Pool
>> for the web page. I have been unable to find out anything why this
>> happens.
>> Furthermore, I created a new Application Pool for the web page,
>> thinking perhaps sharing the same pool was the problem, but before I
>> could attach it to the web page the problem appeared to solve itself,
>> for a short time.
>> Doing some extensive testing I have concluded this:
>> WindowsImpersonationContext.Undo() works for a short time if a dummy
>> application pool (not used by anything) is STARTED
>> WindowsImpersonationContext.Undo() works for a short time if a dummy
>> application pool (not used by anything) is STOPPED
>> When it works, it seems to work as long as only one web service is
>> called,
>> and it stops working as soon as the other web service is called.
>> ????
>> The only google result I could come up with related to this does not
>> have a solution or email address
>> http://www.derkeiler.com/Newsgroups/...net.security/2
>> 005-02/0223.html
>> Any idea, suggestions or something to try is extremely welcome
>> - Morten
>>

>
>




--
Happy Coding!
Morten Wennevik [C# MVP]
 
Reply With Quote
 
Morten Wennevik
Guest
Posts: n/a
 
      09-13-2006
Well, the problem is that user running the web page does not always carry
over to the web service. I'm not responsible for the web services, only
the web page so I have misread the logs thinking
WindowsImpersonationContext was to blame, but the other web service uses
only <identity impersonate="true"/>.

I discovered the links after sending the last mail. Going to try that.

-Morten


On Wed, 13 Sep 2006 12:11:14 +0200, Dominick Baier
<dbaier@pleasepleasenospam_leastprivilege.com> wrote:

> then i am not sure what your problem is...
>
> if you think it is not impersonation related - you have to tell me more
> about the problems you are seeing.
>
> ---
> Dominick Baier, DevelopMentor
> http://www.leastprivilege.com
>
>> We use .Net 2.0, and upon further studies, it is not connected to
>> WindowsImpersonationContext since only one web service uses that.
>> What configuration is required?
>> We use an encrypted identity section
>> <trust level="Full" originUrl=""/>
>> <identity configProtectionProvider="RsaProtectedConfiguratio nProv
>> ider">
>> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
>> xmlns="http://www.w3.org/2001/04/xmlenc#">
>> <EncryptionMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
>> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
>> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
>> <EncryptionMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
>> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
>> <KeyName>Rsa Key</KeyName>
>> </KeyInfo>
>> <CipherData>
>> <CipherValue>IKGgtOuiQqSL6KZOurRXMNSJxNioerQcyGGS3 Ng2y6Sg
>> snjZqWQMztRTALlkbaVQM3zsh4BSnACU4pN+s1tWHDV1EKSyfC M7m5R5G54vUvF+oqj9MV
>> tZ
>> 12QVhv2i2hun95oHNtgAgYJjVbzAudcKMTe/phWP61iXqTgxKKNc+xw=</CipherValue>
>> </CipherData>
>> </EncryptedKey>
>> </KeyInfo>
>> <CipherData>
>> <CipherValue>RrRnNXdcQQozeNEGPuinT9aaRT2M9RGgOBe1O 9/u9IIAzOfl
>> IZRr2UN0jWfiGk+WduHx/kM3ZN2s05k3/gQMcwZhykXHRFLAcURapxzjBRqz2HBh2ad05Q
>> =
>> =</CipherValue>
>> </CipherData>
>> </EncryptedData>
>> </identity>
>> and
>> <authentication mode="Windows"/>
>> <authorization>
>> <allow users="*"/>
>> </authorization>
>> - Morten
>> On Wed, 13 Sep 2006 11:46:50 +0200, Dominick Baier
>> <dbaier@pleasepleasenospam_leastprivilege.com> wrote:
>>
>>> Hi, which framework version are you using. Impersonation tokens are
>>> no
>>>

>> t
>>
>>> always propagated to async operations.
>>> In 1.1 they are never propagated. In 2.0 you can control that via a
>>> config setting
>>> http://www.leastprivilege.com/WhatIsAspnetconfig.aspx
>>> ---
>>> Dominick Baier, DevelopMentor
>>> http://www.leastprivilege.com
>>>> Hi,
>>>> I apologize for the extensive cross-posting but I'm getting desparat

>> e.
>>
>>>> We have a web page calling one or another web service. Both web
>>>> service communicate with Sharepoint 2003, and both temporarily
>>>> change
>>>> impersonation using WindowsImpersonationContext class and then
>>>> revert
>>>> back with WindowsImpersonationContext.Undo() to typically save
>>>> documents with the correct user name.
>>>> Calling the web services synchronously works fine, but we need it to
>>>> work asynchronously (typically creating and saving a document before
>>>> the web services do some work on it).
>>>> The problem is, instead of reverting to the original user,
>>>> WindowsImpersonationContext ends up as the user running the
>>>> Application
>>>> Pool
>>>> for the web page. I have been unable to find out anything why this
>>>> happens.
>>>> Furthermore, I created a new Application Pool for the web page,
>>>> thinking perhaps sharing the same pool was the problem, but before I
>>>> could attach it to the web page the problem appeared to solve
>>>> itself,
>>>> for a short time.
>>>> Doing some extensive testing I have concluded this:
>>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
>>>> application pool (not used by anything) is STARTED
>>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
>>>> application pool (not used by anything) is STOPPED
>>>> When it works, it seems to work as long as only one web service is
>>>> called,
>>>> and it stops working as soon as the other web service is called.
>>>> ????
>>>> The only google result I could come up with related to this does not
>>>> have a solution or email address
>>>> http://www.derkeiler.com/Newsgroups/...otnet.security

>> /2
>>
>>>> 005-02/0223.html
>>>> Any idea, suggestions or something to try is extremely welcome
>>>> - Morten

>
>




--
Happy Coding!
Morten Wennevik [C# MVP]
 
Reply With Quote
 
Morten Wennevik
Guest
Posts: n/a
 
      09-13-2006
IT WORKS

That was indeed the problem, identity tokens not carrying over during
asynchronous calls. Wonderful, I swear I have grown lot of gray hairs
over this problem. All our other asynchronous test worked fine, but none
of them did impersonated in the original page. Creating new
networkcredentials seems to create a proper token anyway.

Thank you so much!
Tusen, tusen takk!

- Morten

On Wed, 13 Sep 2006 12:11:14 +0200, Dominick Baier
<dbaier@pleasepleasenospam_leastprivilege.com> wrote:

> then i am not sure what your problem is...
>
> if you think it is not impersonation related - you have to tell me more
> about the problems you are seeing.
>
> ---
> Dominick Baier, DevelopMentor
> http://www.leastprivilege.com
>
>> We use .Net 2.0, and upon further studies, it is not connected to
>> WindowsImpersonationContext since only one web service uses that.
>> What configuration is required?
>> We use an encrypted identity section
>> <trust level="Full" originUrl=""/>
>> <identity configProtectionProvider="RsaProtectedConfiguratio nProv
>> ider">
>> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
>> xmlns="http://www.w3.org/2001/04/xmlenc#">
>> <EncryptionMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
>> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
>> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
>> <EncryptionMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
>> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
>> <KeyName>Rsa Key</KeyName>
>> </KeyInfo>
>> <CipherData>
>> <CipherValue>IKGgtOuiQqSL6KZOurRXMNSJxNioerQcyGGS3 Ng2y6Sg
>> snjZqWQMztRTALlkbaVQM3zsh4BSnACU4pN+s1tWHDV1EKSyfC M7m5R5G54vUvF+oqj9MV
>> tZ
>> 12QVhv2i2hun95oHNtgAgYJjVbzAudcKMTe/phWP61iXqTgxKKNc+xw=</CipherValue>
>> </CipherData>
>> </EncryptedKey>
>> </KeyInfo>
>> <CipherData>
>> <CipherValue>RrRnNXdcQQozeNEGPuinT9aaRT2M9RGgOBe1O 9/u9IIAzOfl
>> IZRr2UN0jWfiGk+WduHx/kM3ZN2s05k3/gQMcwZhykXHRFLAcURapxzjBRqz2HBh2ad05Q
>> =
>> =</CipherValue>
>> </CipherData>
>> </EncryptedData>
>> </identity>
>> and
>> <authentication mode="Windows"/>
>> <authorization>
>> <allow users="*"/>
>> </authorization>
>> - Morten
>> On Wed, 13 Sep 2006 11:46:50 +0200, Dominick Baier
>> <dbaier@pleasepleasenospam_leastprivilege.com> wrote:
>>
>>> Hi, which framework version are you using. Impersonation tokens are
>>> no
>>>

>> t
>>
>>> always propagated to async operations.
>>> In 1.1 they are never propagated. In 2.0 you can control that via a
>>> config setting
>>> http://www.leastprivilege.com/WhatIsAspnetconfig.aspx
>>> ---
>>> Dominick Baier, DevelopMentor
>>> http://www.leastprivilege.com
>>>> Hi,
>>>> I apologize for the extensive cross-posting but I'm getting desparat

>> e.
>>
>>>> We have a web page calling one or another web service. Both web
>>>> service communicate with Sharepoint 2003, and both temporarily
>>>> change
>>>> impersonation using WindowsImpersonationContext class and then
>>>> revert
>>>> back with WindowsImpersonationContext.Undo() to typically save
>>>> documents with the correct user name.
>>>> Calling the web services synchronously works fine, but we need it to
>>>> work asynchronously (typically creating and saving a document before
>>>> the web services do some work on it).
>>>> The problem is, instead of reverting to the original user,
>>>> WindowsImpersonationContext ends up as the user running the
>>>> Application
>>>> Pool
>>>> for the web page. I have been unable to find out anything why this
>>>> happens.
>>>> Furthermore, I created a new Application Pool for the web page,
>>>> thinking perhaps sharing the same pool was the problem, but before I
>>>> could attach it to the web page the problem appeared to solve
>>>> itself,
>>>> for a short time.
>>>> Doing some extensive testing I have concluded this:
>>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
>>>> application pool (not used by anything) is STARTED
>>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
>>>> application pool (not used by anything) is STOPPED
>>>> When it works, it seems to work as long as only one web service is
>>>> called,
>>>> and it stops working as soon as the other web service is called.
>>>> ????
>>>> The only google result I could come up with related to this does not
>>>> have a solution or email address
>>>> http://www.derkeiler.com/Newsgroups/...otnet.security

>> /2
>>
>>>> 005-02/0223.html
>>>> Any idea, suggestions or something to try is extremely welcome
>>>> - Morten

>
>




--
Happy Coding!
Morten Wennevik [C# MVP]
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
IIS 6 vs IIS 5 ASP.NET Performance Issues JMaelstrom ASP .Net 2 04-30-2010 04:32 PM
IIS 6.0 win2003, IIS users moe_rodrigue MCSE 1 04-01-2004 07:37 AM
IIS 6.0 vs IIS 5.1 Hai Nguyen ASP .Net 1 03-02-2004 06:22 AM
ASP.NET application works in IIS PWS, but not in remote IIS. Matthew Louden ASP .Net 3 11-07-2003 09:58 PM
.NET IIS to IIS credentials problem... Grind Boy ASP .Net 4 08-14-2003 12:59 PM



Advertisments