Trusted Subsystem, WCF and IIS 5 – revisited

In my last post, I tried to get the following scenario to work:

One thing I didn’t add was that I’m running IIS in Windows XP, in IIS 5.  In this article on CodePlex, which I originally modeled my solution after and a couple of folks pointed out, it recommends setting both the ASP.NET identity (outside the Trusted Zone) and the App Pool identity to the Service account identity.

Now, in my case, I don’t care about who calls my service, nor do I want any requirement on their side to provide any transport security.  The article also recommends this, but I don’t need it.

The real problem came from me running in IIS 5.  In IIS 5, the aspnet_wp process runs as MACHINEASPNET, which examining WindowsIdentity.GetCurrent() confirmed.  Even though I set the identity in IIS to use the service account as anonymous user, WCF by default uses the process identity, not any other identity.  WCF has no knowledge of the host environment, by default, so it doesn’t know it’s hosted in ASP.NET or IIS normally.

To do a Trusted Subsystem model under IIS 5, I had to make the following changes:

  • Set the anonymous account to the service account, turn off any other security (like Integrated Windows Security)
  • Turn on impersonation in the web.config (<identity impersonate=”true” />)
  • Turn on ASP.NET compatibility for the service hosting environment and each individual service

The last part is critical, and detailed in this MSDN article.  I’ve had to do that before, when designing JSON services for an AJAX application, where the services needed access to HttpContext.Session.

Once ASP.NET compatibility is turned on, WCF requests now go through the ASP.NET pipeline, which means the normal ASP.NET impersonation model.  From the article:

WCF services run using the current identity of the ASP.NET impersonated thread, which may be different than the IIS process identity if ASP.NET impersonation has been enabled for the application.

With the full ASP.NET impersonation set up, and the correct identity set up in IIS, WCF could now take the identity of the ASP.NET impersonated thread.  Even though Thread.CurrentPrincipal reflected the service identity, WCF won’t use it unless I set up the compatibility mode.

Of course, if I had been developing in a Workstation 2008 machine, or something with IIS 6 or 7, this wouldn’t be a problem.  Setting the App Pool identity is the process identity.  In IIS 5, the identity is configured elsewhere.  In any case, it’s all working now locally.  I guess this means it’s finally time to upgrade to Workstation 2008.

Thanks to everyone for all the pointers!

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in WCF. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • jdn

    Cool, glad to see this was resolved.

    This is the sort of thing that will help future people (future people? people in the future?) so this is great to post.


  • @jdn

    That’s me, “headache prevention service” – I get headaches, so you don’t have to :)

  • myaeger

    I was hoping your suggestions worked but I still get “Login failed for user ”. The user is not associated with a trusted SQL Server connection. “. I set the anonymous account for the web app to a domain account that has full access to the db. I also made sure all other forms of auth where unchecked. I added to the web.config. lastly I added to part of the web config. I’m stumped so if anyone has any ideas I’d love to hear about it.

    oh, and my sql server connection string is: Server=;Database=;Integrated Security=True


  • sspoonless

    I experienced recently that the anonymous account overrides . Turn off anonymous and put your identity in the app pool (or web.config).