IIS, SQL, impersonate not functioning...

[Jeremy Kercheval]

I have a web service application which needs to do some processing which can
be lengthy at times. I originally went with using a delegate in the Web
Service call, however that approach is not without problems (apparently the
HttpContext is released by aspnet_wp). So, I used the
[SoapDocumentMethodAttribute(OneWay=true)] attribute. This solved some of
my problems, but when we tested the solutions using Windows Authentication
we found that the impersonated user wasn't set.
In my web.config I have the following set <identity impersonate="true"
userName="domain\username" password="apassword"></identity> where the
domain\username and passord are good. For all calls that do not have the
OneWay attribute, everything works fine, on the call where it is set we get
only the MACHINE/ASPNET account which does not have access to the database.
Is this a bug?
Does anyone know of a good solution to this problem? We are thinking about
setting IIS to "RunAs", but users may not care for that solution.

Thanks,
Jeremy

[Jeremy Kercheval]

Yanhong,
Thanks for the reply. I tried the one asynchronous approach (Server-Side
Asynchronous Web Methods) which I got from
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service10012002.asp[/url].
There seems to be a problem in general when using this approach if you are
doing any tracing though. From what I have been able to observe, when you
call the Web Service method asynchronously on the Server Side, once you call
BeginInvoke and the call returns, the ASP.NET worker process lets go of the
HttpContext that it associated with the thread. So, when you call a trace
statement or use the Context in any other way during the asynchronous call
you get an exception. I could deal with this by not doing any tracing and
ensuring that I get any objects from the HttpContext before I invoke the
thread, but I was concerned that there may be other problems with this that
were not immediately apparent, so I opted for the
[SoapDocumentMethodAttribute(OneWay=true)] attribute - of course this was
before I realized that it was broken.

As to the security and impersonate:

When we use the [SoapDocumentMethodAttribute(OneWay=true)] attribute and we
use NT Authentication for SQL Server combined with impersonation="true" for
identity (and of course a valid domain user and password) we get the
following SqlException error that says
"
System.Data.SqlClient.SqlException: Login failed for user '(null)'. Reason:
Not associated with a trusted SQL Server connection.
at System.Data.SqlClient.ConnectionPool.GetConnection (Boolean&
isInTransaction)
at
System.Data.SqlClient.SqlConnectionPoolManager.Get PooledConnection(SqlConnec
tionString options, Boolean& isInTransaction) at
System.Data.SqlClient.SqlConnection.Open() at ..."

Where all other calls are authenticated appropriately. I have tested this
by verifying that the current Identity during all other calls is the
identity we set in the web.config file, where the identity during the OneWay
method is the MACHINENAME\ASPNET which is the default identity - not the
identity in the web.config file. This should be very easy to repro.

I am using the SoapToolkit 3.0 from a C++ client, and I believe that I can
write a asynchronous solution from the client perspective, but I shouldn't
need to... at least I don't think I should, but if that's what I need to do
then I will.

Thanks,
Jeremy

"Yan-Hong Huang[MSFT]" <yhhuang@online.microsoft.com> wrote in message
news:7dwh%23OLXDHA.2000@cpmsftngxa06.phx.gbl...

> Hello Jeremy,
>
> If the web method takes a long time, I suggest you use asynchronous web

thread calling. There is a sample in MSDN:

> "XML Web Services: Windows Forms Client-Asynchronous XML Web Service

Sample"

>

[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbref/html/vbsamwebserviceswindowsformsclient-[/url]

> asyncwebservicesample.asp
>
> For the security issue, asp.net web service should use the same model as

asp.net web application. So the thread should

> use that domain user account to access database. Could you please use SQL

Profiler to log activities to check which

> identity is used to access sql server under these situations?
>
> Thanks very much.
>
> Best regards,
> Yanhong Huang
> 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.

>
> --------------------
> !From: "Jeremy Kercheval" <jkercheval@expressmetrix.com>
> !Subject: IIS, SQL, impersonate not functioning...
> !Date: Tue, 5 Aug 2003 12:09:40 -0700
> !Lines: 21
> !X-Priority: 3
> !X-MSMail-Priority: Normal
> !X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
> !X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> !Message-ID: <e$iunU4WDHA.212@TK2MSFTNGP12.phx.gbl>
> !Newsgroups: microsoft.public.dotnet.framework.aspnet.security
> !NNTP-Posting-Host: 64.122.98.98
> !Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP12.phx.gbl
> !Xref: cpmsftngxa06.phx.gbl

microsoft.public.dotnet.framework.aspnet.security: 6121

> !X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
> !
> !I have a web service application which needs to do some processing which

can

> !be lengthy at times. I originally went with using a delegate in the Web
> !Service call, however that approach is not without problems (apparently

the

> !HttpContext is released by aspnet_wp). So, I used the
> ![SoapDocumentMethodAttribute(OneWay=true)] attribute. This solved some

of

> !my problems, but when we tested the solutions using Windows

Authentication

> !we found that the impersonated user wasn't set.
> !In my web.config I have the following set <identity impersonate="true"
> !userName="domain\username" password="apassword"></identity> where the
> !domain\username and passord are good. For all calls that do not have the
> !OneWay attribute, everything works fine, on the call where it is set we

get

> !only the MACHINE/ASPNET account which does not have access to the

database.

> !Is this a bug?
> !Does anyone know of a good solution to this problem? We are thinking

about

> !setting IIS to "RunAs", but users may not care for that solution.
> !
> !Thanks,
> !Jeremy
> !
> !
> !
> !
>
>

[Yan-Hong Huang[MSFT]]

Hello Jeremy,

Thanks for the quick response.

We will look into it and reply you as soon as possible.

Best regards,
Yanhong Huang
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.

--------------------
!From: "Jeremy Kercheval" <jkercheval@expressmetrix.com>
!References: <e$iunU4WDHA.212@TK2MSFTNGP12.phx.gbl>
<7dwh#OLXDHA.2000@cpmsftngxa06.phx.gbl>
!Subject: Re: IIS, SQL, impersonate not functioning...
!Date: Thu, 7 Aug 2003 11:23:11 -0700
!Lines: 125
!X-Priority: 3
!X-MSMail-Priority: Normal
!X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
!X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
!Message-ID: <#fi4$DRXDHA.652@TK2MSFTNGP10.phx.gbl>
!Newsgroups: microsoft.public.dotnet.framework.aspnet.security
!NNTP-Posting-Host: 64.122.98.98
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP10.phx.gbl
!Xref: cpmsftngxa06.phx.gbl
microsoft.public.dotnet.framework.aspnet.security: 6168
!X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
!
!Yanhong,
!Thanks for the reply. I tried the one asynchronous approach (Server-Side
!Asynchronous Web Methods) which I got from
![url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/[/url]
html/service10012002.asp.
!There seems to be a problem in general when using this approach if you are
!doing any tracing though. From what I have been able to observe, when you
!call the Web Service method asynchronously on the Server Side, once you
call
!BeginInvoke and the call returns, the ASP.NET worker process lets go of the
!HttpContext that it associated with the thread. So, when you call a trace
!statement or use the Context in any other way during the asynchronous call
!you get an exception. I could deal with this by not doing any tracing and
!ensuring that I get any objects from the HttpContext before I invoke the
!thread, but I was concerned that there may be other problems with this that
!were not immediately apparent, so I opted for the
![SoapDocumentMethodAttribute(OneWay=true)] attribute - of course this was
!before I realized that it was broken.
!
!As to the security and impersonate:
!
!When we use the [SoapDocumentMethodAttribute(OneWay=true)] attribute and we
!use NT Authentication for SQL Server combined with impersonation="true" for
!identity (and of course a valid domain user and password) we get the
!following SqlException error that says
!"
!System.Data.SqlClient.SqlException: Login failed for user '(null)'. Reason:
!Not associated with a trusted SQL Server connection.
!at System.Data.SqlClient.ConnectionPool.GetConnection (Boolean&
!isInTransaction)
!at
!System.Data.SqlClient.SqlConnectionPoolManager.Ge tPooledConnection(SqlConne
c
!tionString options, Boolean& isInTransaction) at
!System.Data.SqlClient.SqlConnection.Open() at ..."
!
!Where all other calls are authenticated appropriately. I have tested this
!by verifying that the current Identity during all other calls is the
!identity we set in the web.config file, where the identity during the
OneWay
!method is the MACHINENAME\ASPNET which is the default identity - not the
!identity in the web.config file. This should be very easy to repro.
!
!I am using the SoapToolkit 3.0 from a C++ client, and I believe that I can
!write a asynchronous solution from the client perspective, but I shouldn't
!need to... at least I don't think I should, but if that's what I need to do
!then I will.
!
!Thanks,
!Jeremy
!
!"Yan-Hong Huang[MSFT]" <yhhuang@online.microsoft.com> wrote in message
!news:7dwh%23OLXDHA.2000@cpmsftngxa06.phx.gbl...
!> Hello Jeremy,
!>
!> If the web method takes a long time, I suggest you use asynchronous web
!thread calling. There is a sample in MSDN:
!> "XML Web Services: Windows Forms Client-Asynchronous XML Web Service
!Sample"
!>
![url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbref/html[/url]
/vbsamwebserviceswindowsformsclient-
!> asyncwebservicesample.asp
!>
!> For the security issue, asp.net web service should use the same model as
!asp.net web application. So the thread should
!> use that domain user account to access database. Could you please use SQL
!Profiler to log activities to check which
!> identity is used to access sql server under these situations?
!>
!> Thanks very much.
!>
!> Best regards,
!> Yanhong Huang
!> 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.
!>
!> --------------------
!> !From: "Jeremy Kercheval" <jkercheval@expressmetrix.com>
!> !Subject: IIS, SQL, impersonate not functioning...
!> !Date: Tue, 5 Aug 2003 12:09:40 -0700
!> !Lines: 21
!> !X-Priority: 3
!> !X-MSMail-Priority: Normal
!> !X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
!> !X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
!> !Message-ID: <e$iunU4WDHA.212@TK2MSFTNGP12.phx.gbl>
!> !Newsgroups: microsoft.public.dotnet.framework.aspnet.security
!> !NNTP-Posting-Host: 64.122.98.98
!> !Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP12.phx.gbl
!> !Xref: cpmsftngxa06.phx.gbl
!microsoft.public.dotnet.framework.aspnet.security :6121
!> !X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
!> !
!> !I have a web service application which needs to do some processing which
!can
!> !be lengthy at times. I originally went with using a delegate in the Web
!> !Service call, however that approach is not without problems (apparently
!the
!> !HttpContext is released by aspnet_wp). So, I used the
!> ![SoapDocumentMethodAttribute(OneWay=true)] attribute. This solved some
!of
!> !my problems, but when we tested the solutions using Windows
!Authentication
!> !we found that the impersonated user wasn't set.
!> !In my web.config I have the following set <identity impersonate="true"
!> !userName="domain\username" password="apassword"></identity> where the
!> !domain\username and passord are good. For all calls that do not have
the
!> !OneWay attribute, everything works fine, on the call where it is set we
!get
!> !only the MACHINE/ASPNET account which does not have access to the
!database.
!> !Is this a bug?
!> !Does anyone know of a good solution to this problem? We are thinking
!about
!> !setting IIS to "RunAs", but users may not care for that solution.
!> !
!> !Thanks,
!> !Jeremy
!> !
!> !
!> !
!> !
!>
!>
!
!
!

[Jeremy Kercheval]

Nope, during synchronous execution there are no problems.

Jeremy

"Jeremy Jones" <jcjonesonline@microsoft.com> wrote in message
news:K27fEnFYDHA.2548@cpmsftngxa06.phx.gbl...

> Hi Jeremy,
>
> Are you seeing this as an issue when doing this synchronously?
>
> This posting is provided "AS IS" with no warranties, and confers no

rights.

>