IIS 6.0 Bug?

[Dominick Baier]

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]

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.

 

[Morten Wennevik]

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/microsoft.public.dotnet.security/2005-02/0223.html

Any idea, suggestions or something to try is extremely welcome

- Morten

 

[Morten Wennevik]

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="RsaProtectedConfigurationProvider">
<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>IKGgtOuiQqSL6KZOurRXMNSJxNioerQcyGGS3Ng2y6SgsnjZqWQMztRTALlkbaVQM3zsh4BSnACU4pN+s1tWHDV1EKSyfCM7m5R5G54vUvF+oqj9MVtZ12QVhv2i2hun95oHNtgAgYJjVbzAudcKMTe/phWP61iXqTgxKKNc+xw=</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
<CipherData>
<CipherValue>RrRnNXdcQQozeNEGPuinT9aaRT2M9RGgOBe1O9/u9IIAzOflIZRr2UN0jWfiGk+WduHx/kM3ZN2s05k3/gQMcwZhykXHRFLAcURapxzjBRqz2HBh2ad05Q==</CipherValue>
</CipherData>
</EncryptedData>
</identity>

and

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


- Morten

 

[Morten Wennevik]

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

 

[Morten Wennevik]

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