Grrr..bad day! Sorry about the re-repost; it seems there's more than one 
place to configure an alias. 

Hi,

I'm having a problem with a web service; specifically a custom 
UsernameTokenManager which needs to access a remote database. The web 
service is set up in IIS to use anonymous access with a UserID and Password 
provided, and the web.config file is set up to impersonate and use windows 
authentication; the problem comes when the request is sent to the service.

The web service needs to access a database on a remote server, and needs to 
use the UserID and Password held in the IIS config; the problem is during 
testing I'm noticing that during my authentication phase (my custom 
UsernameTokenManager class) the database access is done via the ASPNET 
user - once this has been authenticated then the rest of the application 
uses the correct UserID and Password for data access. I'm (guessing) that 
this would be using the NetworkService account on Server 2003.

The production SQL Server database will not accept the ASPNET or 
NetworkService accounts, access must be done through the UserID and Password 
provided in IIS.

I'm pretty much pulling my hair out now trying to work out how/why is the 
UsernameTokenManager class is running under the default account; how can I 
change this to run under the specified account settings for the rest of the 
application?

Cheers,
Dave

{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Hi Dave,
\par 
\par Seems you used to suffer some problem on MSDN account setting, anyway, you've got the managed alias configured correctly now, welcome back:)
\par 
\par From your description, you're encountering some problem of the WSE usernameTokenmanager's security context when accessing a remote SQL database. You found your imperosonated anonymous account is not used when accessing the remote server(but used the worker process account), correct?
\par 
\par Though I haven't ever impersonate anonymous account in webservice and WSE, I think the behavior here could be caused by two possible things:
\par 
\par 1. the ASP.NET webservice pipeline haven't perform the impersonate at the point WSE call the token manager(WSE is injected at SOAP extension stage)
\par 
\par 2. the WSE runtime has manually call Reverttoself to change security context back to the process identity.
\par 
\par I think #1 is more possible here.  For the problem here, a possible workaround is manually put code in the Custom usernameTokenmanager to perform the impersonation. To programmatically impersonate, you need clear text username/password credentials, here is a msdn article about programamatic impersonate:
\par 
\par #How To: Use Impersonation and Delegation in ASP.NET 2.0
\par http://msdn2.microsoft.com/en-us/library/ms998351.aspx
\par 
\par 
\par Sincerely,
\par 
\par Steven Cheng
\par 
\par Microsoft MSDN Online Support Lead
\par 
\par  
\par 
\par ==================================================
\par 
\par Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notifications.
\par 
\par  
\par 
\par Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx.
\par 
\par ==================================================
\par  \tab 
\par 
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par 
\par }

{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Hi Dave,
\par 
\par How are you doing? Have you got any progress on this or does the suggestion in previous reply helps you a little? If there is still anything we can help, please don't hesitate to post here.
\par 
\par Sincerely,
\par 
\par Steven Cheng
\par 
\par Microsoft MSDN Online Support Lead
\par 
\par 
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par 
\par 
\par 
\par 
\par 
\par }

Hi Steven,

Thanks for your response; sorry I haven't got back to you sooner - got a bit 
tied up in an implementation elsewhere! I haven't yet had time to have more 
than a cursory read through the entire MSDN article you pointed out, but 
from what I've read I'm thinking that I may still have a problem.

Your reading of the situation was spot on, and I believe that the WebService 
is behaving as you stated in point 1. My intermediate solution was to set 
the authentication mode to windows and impersonate the user, storing the 
username and password in the web.Config file (as I think it mentions in the 
How To document); this was then encrypted. The UsernameToken class then uses 
this username and password to authenticate (as does the rest of the 
application).

I should mention at this point that I'm testing on WinXP, but the behaviour 
is the same on Win2K3; I noticed the article has a section specifically on 
Windows Server 2003, so I'll concentrate on that over the next couple of 
days.

I'm probably missing something really basic here (as is usually the way!), 
as I can't understand why the UsernameToken class, compiled and included as 
part of the dll hosted in the IIS session with the IIS Authentication set to 
anonymous and the username and password provided, is deciding to revert to 
the default ASPNet/Network Service user.

As you mentioned as your second point, the other option is that the WSE 
runtime has manually reverted, although I can't see why it would do it for 
one setting and not the other!

I'm not too keen on having the web.config file holding the Username and 
Password, even if it is encrypted; ideally we'd be using the IIS Anonymous 
access username and password.

I'll post back once I've had a time to go through the article in more detail 
(hopefully the next couple of days!); my last remaining hope is configuring 
an application pool in IIS6 on Server 2003 to use a specific user ID will 
force all applications under it to use the same ID!

If you need any more information or have any other ideas, please let me 
know!!!

As I've said, I'm probably missing something totally basic - I'll post back 
once I've managed to get a Windows Server 2003 machine to test on.

Thanks for your help!

Cheers,
Dave

{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Thanks for your followup Dave,
\par 
\par I'm sorry to hear that the problem still remains.  As for the following things you mentioned:
\par 
\par ===============
\par My intermediate solution was to set 
\par the authentication mode to windows and impersonate the user, storing the 
\par username and password in the web.Config file (as I think it mentions in the 
\par How To document); this was then encrypted. The UsernameToken class then uses 
\par this username and password to authenticate (as does the rest of the 
\par application).
\par ===============
\par 
\par do you mean you use the following like configuration to impersonate the ASP.NET appliation running under your specific account?
\par 
\par <identity impersonate="true" userName="domain\\username" password="password..." />
\par 
\par If so, I'm afraid this won't work either (just like you try impersonating the anonymous account configured in IIS), the impersonation of ASP.NET always take place in the fixed stage during ASP.NET webservice(or web application)'s sever-side processing pipeline, at that time, the usernameTokenManager has already done the authentication(not be able to utilize the impersonated security context).
\par 
\par Have you tried using the code to programmatically do the impersonate and use those code in your custom UsernameTokenManager's implementeation code?
\par 
\par I mean you can add programmatic impersonate code in your custom token authenticator's code(where you connect to database to query user info);
\par 
\par http://msdn2.microsoft.com/en-us/library/ms730079.aspx
\par 
\par e.g.
\par 
\par =====in your custom token's impelementation========
\par 
\par public bool authenticate_method(username , password)
\par \{
\par      //begin impersonate
\par   
\par  connect to remote database and verify the user account here
\par 
\par     //revert back
\par \}
\par 
\par 
\par Anyway, please don't hesitate to post here if you have any questions or anything unclear on this.
\par 
\par Sincerely,
\par 
\par Steven Cheng
\par 
\par Microsoft MSDN Online Support Lead
\par 
\par 
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par 
\par 
\par 
\par 
\par }

{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Hi Dave,
\par 
\par How are you going on this issue? Does my last reply still help some?
\par 
\par As always, if you need any further help from us, please feel free to post in the newsgroup.
\par 
\par Sincerely,
\par 
\par Steven Cheng
\par 
\par Microsoft MSDN Online Support Lead
\par  \tab 
\par 
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }