2 Answers
2

We have IIS6 serving our intranet CMS (the CMS is an ISAPI plugin). This is with the site setup in IIS for integrated windows authentication (for both security & user personalisation).

I want to get gzip compression enabled but due to some of the features we have switched on in our CMS we can't do this via IIS's gzip settings (it crashes upon every request to the CMS if we do).

So, I'm currently testing a setup with an nginx reverse proxy infront of IIS doing the content gzipping.

What works/what doesn't?

IE6/7 auth via this setup still works fine, I didn't have to make any changes.

Firefox however needed a change. Before, without nginx, Firefox had network.automatic-ntlm-auth.trusted-uris set to allow our intranet server to do transparent NTLM auth. Once nginx was part of the mix you'd just get repeatedly shown the site login box and your credentials would never be accepted. However, adding the intranet server to network.negotiate-auth.trusted-uris fixed this (for Firefox on Windows but not on OS X). It seems the authentication method may have changed slightly? Where allowing NTLM auth before worked fine it now seems to be doing SPENGO?

So the current situation with nginx in front of IIS6 has left me with:

Works

IE6 on XP

IE7 on XP

FF3.5 on XP (after changing about:config)

Doesn't work (credentials never accepted)

FF3.5 on OS X

Safari 3 on OS X

Safari 4 on XP

Blackberry 8700 (Simulator)

Blackberry 9000 (Simulator)

At a guess as to why mine (partially) works and yours doesn't... Possibly something crucial to proxying the auth handshake that's in my config but missing from yours? Such as forwarding the real client IP? The relevant server section of my nginx config is below if you want to give it a try.