Ayende @ Rahien

Refunds available at head office

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.

image

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?

Comments

grega_g
06/14/2011 10:08 AM by
grega_g

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\

grega_g
06/14/2011 10:11 AM by
grega_g

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

enslam
06/14/2011 10:17 AM by
enslam

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

Frank
06/14/2011 11:47 AM by
Frank

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
06/14/2011 11:50 AM by
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
06/15/2011 11:49 AM by
David Tellander

Hi,

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
06/15/2011 01:09 PM by
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
06/16/2011 12:22 PM by
Bogdan Cucosel

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

Ferret Chere
06/17/2011 01:34 AM by
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.

Comments have been closed on this topic.