9

We're getting ready to start migrating some of our IIS6 sites to IIS7, and the application currently uses Forms Authentication. We have started getting some requests from various sites to use the Windows Authentication for the users. While this is easy enough to implement (and I've shown internally that there is no issue with the app, as expected) the question then is how to continue to keep Forms authentication for when Integrated Windows doesn't work. I've seen several walkthroughs on how to have it configured on IIS6, and I could do the same thing on IIS7, but then I have to turn on Classic Mode processing. Any solution should also be back portable to IIS6, if possible, to keep the build tree simple.

So what are my options on this? Do I setup the app with Integrated Windows Authentication in IIS7, Forms Auth in the web.config, and redirect 401 errors to an "error page" allowing them to login using forms, then back to the regular app?

The case when Forms is likely to be needed is going to be reserved for Contract workers, our support staff, and if someone needs to access it on their site from their Extranet. So primarily it's for our staff to login to check functionality and confirm bug reports. I suggested we just maintain that for our support staff to work, we need a Windows login that will always be live, and then we'll just enforce local responsibility on who can login to the site, but I'm told that we would do better to have Forms Authentication.

Any thoughts? I can post some of the links of the articles I've already read through if that would help the forum better narrow my needs.

tl;dr: How to do mixed mode authentication (forms, windows) in IIS7 without changing to classic pipeline and still be able to use the build in IIS6 if possible.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
jcolebrand
  • 15,889
  • 12
  • 75
  • 121
  • Would it be better (a-la http://stackoverflow.com/questions/2432845/asp-net-mvc-and-mixed-mode-authentication ) to have two separate "projects" under my main build that are strictly for issuing machine specific cookies per Web.config MachineKey and thus keep the authentication mechanisms separate from the app usage and retain Forms on the main app? That might be the easiest route to take. – jcolebrand Mar 29 '10 at 15:19
  • Presumably I need to do something like this: http://www.15seconds.com/Issue/050203.htm but that seems so barbaric when it could all reside under one stack. – jcolebrand Mar 29 '10 at 17:19
  • Also, for anyone reading this after I posted the original question and a few responses: If the user navigates to the site and does NOT enter their credentials to the 401 response they get kicked back to an ASP.NET default 401 error page. I haven't figured out how to redirect them at that point to my forms default page (but maybe I quit looking too soon?) – jcolebrand Apr 27 '10 at 14:22

3 Answers3

7

No, that's not quite right, but I can't do a code block in a comment reply, so I'll post a new answer ...

The following code block allows me to control anon access from IIS7 without having to muck about in the metabase (where GUI changes on IIS6 get applied)

<location path="WindowsLogin.aspx" >
    <system.web>
        <authorization>
            <deny users="?" />
            <allow users="*" />
        </authorization>
    </system.web>
    <system.webServer>
        <security>
            <authentication>
                <anonymousAuthentication enabled="false" />
                <windowsAuthentication enabled="true" />
            </authentication>
        </security>
    </system.webServer>
</location>
jcolebrand
  • 15,889
  • 12
  • 75
  • 121
2

thanks for getting back to me, I have been playing round with several of the implementations on and off for a few weeks now, that I've read about on the internet (javascript, 401, 2 virtual directories) but still havnt really found anything that works as I wanted. We will be potentially rolling it out to more than one client-each with different hardware/setups even different versions of iis, so wanted it to be as generic as possible. Ive come up against a brick wall on a couple of the suggested solutions...

when you say for IIS7+ you removed anon access in web config, I assume like this: -

<location path="Authent/WinLogin.aspx" > 
  <system.webServer>
    <security>
      <authorization>
        <add accessType="Deny" users="?" />
      </authorization>
    </security>
  </system.webServer>
</location>
jcolebrand
  • 15,889
  • 12
  • 75
  • 121
kmoo01
  • 43
  • 2
1

I spent a few days trying to get this to work, with a slight difference... I wanted the first login screen to present the forms login with an button underneath "Login With Windows Authentication".

I eventually gave up on all these techniques, as I never could quite get the satisfactory results. My workaround was as follows, and works perfectly:

  • Create a separate website "LoginWithIntegratedSecurity"
  • Set this up with integrated security
  • This web site creates a temporary "User Hash Key" in the database, which identifies the user
  • Redirects back to LogonPage in Forms Authentication website with Hash key in url
  • LogonPage in Forms Authentication checks for Hash key, and logs user in after database check

So if the User clicks the button "Login with windows Authentication", the server redirects to the windows authentication site (passing the "ReturnUrl"). This site challenges and logs in user, then redirects back, again passing the "ReturnUrl" as well as the HashKey.

This all happens very fast, and appears pretty seamless.

I know its a hacky workaround, but for my case it worked well.

Paul Grimshaw
  • 19,894
  • 6
  • 40
  • 59
  • wow, that's a huge workaround. I have two files in my directory, with different levels of authentication. – jcolebrand Jan 06 '12 at 14:53
  • Yes, I guess so. But this Hash Key login is useful for several other bits and pieces, such as synchronising logins and links from other systems. I also didn't want external (none integrated) users to be confronted with a Integrated credentials prompt. – Paul Grimshaw Jan 06 '12 at 16:24
  • So how do you prevent them from seeing that? – jcolebrand Jan 06 '12 at 16:42
  • 1
    By having a "Login with Windows" button underneath the Forms logon, so external users can logon with the forms, while internal users can click on this button, which redirects server side to a blank integrated security page, which pops up the prompt (if need be) and then redirects back with the hash key. The only bit of the integrated security page that users ever see is the popup. – Paul Grimshaw Jan 06 '12 at 21:14
  • By the way, I imagine you know this already, but just in case, I saw a reasonable workaround for getting back to the login screen from the 401, which is described here http://msdn.microsoft.com/en-us/library/ms972958.aspx. – Paul Grimshaw Jan 06 '12 at 21:18
  • Yeah, but that only works if you do it by the server, right, not by the app? I need that per app. I seem to recall trying that once and it was by the server and I gave up, because what I had worked... – jcolebrand Jan 06 '12 at 21:26
  • As a final point, to avoid internal users not needing to click through this extra step, I check the incoming IP address against our database of our office fixed IPs, and if a match is found the redirect to integrated happens immediately. This allows internal users to jump straight in, while they can still logon with the extra click when accessing from home etc. – Paul Grimshaw Jan 06 '12 at 21:29
  • If only I could do that with mine. Ours is a vertically integrated app that runs at many sites, and I can't make my app hinge on IP addresses, or I would. – jcolebrand Jan 06 '12 at 21:32