IIS 7.5 confused between Windows Authentication and Forms Authentication

asp.netiis-7.5

I'm seeing some strange behavior from a Server 2008 R2 box running .net 4 and IIS 7.5 in an integrated app pool.

The root web.config is pretty clear that I want to use windows authentication.

<authentication mode="Windows"/>

no surprises there.

I have a directory that I would like to secure, so I've added the following web.config to that directory:

<configuration>
    <system.web>
        <authorization>
            <allow users="MYDOMAIN\MYUSER" />
            <deny users="*" />
        </authorization>
 </system.web>
</configuration>

Windows Authentication is enabled in IIS, and specified by the root web.config, so I expected the usual Challenge/Response dialog to pop up and ask for a password. Instead I got redirected to a non-existent URL http://mysite.com/Account/Login?ReturnUrl=%2ftestdir

Which seems to be the default login directory for Forms Authentication, which I'm not using so the request returns a 404 error.

ACLs on the underlying directories allow the intended user to access the file.

Anybody seen IIS behave in this manner?

Best Answer

For future reference, this looks like a misunderstanding between authentication modes.

IIS 7+ has two modes - one using a built-in HTTP-level set of authentication options - in <system.webServer>, and one for ASP.Net, in <system.web>.

The ASP.Net behaviours don't become available until you run an ASP.Net handler - whether in Classic or Integrated mode - and then still (usually) apply after the IIS-level system.webServer/security settings.

In the example above, the addition of an ASP.Net page changed the behaviour for (at least) that page, and I'd guess possibly added wildcard handler mappings to handle extensionless URLs through .Net.

There's then also the URL Authorization (IIS, i.e. system.webServer) vs .Net Authorization (.Net, i.e. system.web) rules to consider - in general, pick one set per app and stick to it.

Related Topic