Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 5,972 | Comments: 44,508

filter by tags archive

The evil tricks of “It Works On My Machine”, in reverse

The following is quite annoying. I am trying to make an authenticated request to a web server. In this instance, we are talking about communication from one IIS application to another IIS application (the second application is RavenDB hosted inside IIS).

The part that drives me CRAZY is that I am getting this error when I am trying to make an authenticated request, but using the exact same code and credentials, from another machine, I can make this work just fine.


It took me a while to figure out that most important part, when running locally, I was running under my own account, when running remotely, the application run under IIS account. The really annoying part was that even when running on IIS locally, it still worked locally and failed remotely.

It took me even longer to figure out that the local IIS was configure to run under my own account as well Sad smile

Once that discovery was made, I was able to figure out what is wrong and implement a work around (run the remote IIS site under a custom user name). I know that the actual problem is something relating to permissions on certificate store, but I have no idea how, or, for that matter, which certificate?

This is plain old HTTP auth, no SSL, client certs, etc. I am assuming that this is raised because we are using Windows Auth, but I am not sure what is going on here with regards to which certificate should I grant to which user, or even how to do this.

Any ideas?



start->run->mmc->File->Add/remove snapin -> Certificates->Select account

Than select certificate you want to use, right click->Manage private keys...

Than add App pool of aplication than you want to grant permissions to: iis AppPool\


evil blog engine truncated my example. So you add apppool as user like this: iis apppool\[name of application pool] and click Check Names


Have you set identity impersonate="true" in the web.config?


Hi Ayende,

if I am correct you are doing an authenticated web request from a server to itself? It might be that you are affected by the loopback check they added in .NET 3.5 SP1. It has bitten us in the *ss as well.

See this link for the loopback check they added (and a possible fix): http://msdn.microsoft.com/en-us/library/cc982052(v=vs.90).aspx

This URL has some more fixes: http://support.microsoft.com/kb/896861

Ayende Rahien

Frank, Oh yes, I run into that, for sure, but that wasn't the only thing. I cannot figure out the package credentials thingie at all. Once I work around that, I got the loopback nonsense.

David Tellander


this sounds a lot like an issue that turned my hair gray a couple of months ago. In order to pass credentials from server1 to server2 one must use Kerberos authentication, since NTLM does not support delegation of impersonated credentials.

A couple of links that describe what you'll need to configure if this turns out to be your problem:

http://msdn.microsoft.com/en-us/library/ms998355.aspx http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx

Mike Brown

You have run into a security limitation in Windows. It's for your own good, if any application was able to wave your kerberos token around willy nilly it'd be easier for a cracker to elevate privileges. This situation only arises when you cross machine boundaries and then cross application boundaries (same machine or not). This is why you don't see the problem locally.

You want to set a Server Principal Name on the first leg of the trip so that it can do full delegation. This involves running the application under an account and using the setspn command. This article on technet shows the steps http://technet.microsoft.com/en-us/library/cc786828(WS.10).aspx (ignore the fact that it refers to server 2003 it works in 2008 and 08R2 as well).

Hope this helps.

Bogdan Cucosel

If runnning with impersonation you should check out Kerberos Delegation and like Mike said set the spn accordingly.

Ferret Chere

Without meaning to sound like a snot about it, it's mildly reassuring to see that even developers of your skill and experience get flustered by “It Works On My Machine” at times.

Comment preview

Comments have been closed on this topic.


  1. Paying the rent online - one day from now
  2. Reducing parsing costs in RavenDB - about one day from now

There are posts all the way to Aug 04, 2015


  1. Production postmortem (5):
    29 Jul 2015 - The evil licensing code
  2. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats