views:

1251

answers:

6

My company has a web application hosted on a client's machine that uses forms authentication in ASP.net. When visiting the website http://www.client.com/Application and trying to authenticate on the login page the user gets redirected back to the login page. When accessing it via http://localhost/Application the authentication works fine and the user is able to get into the site. We cannot replicate this behavior in our development environment so we're pretty sure it has something to do with their server/environment.

The problem only happens when using Internet Explorer (tested with ie 6, 7, 8). When the client tries to get on with firefox, the authentication works fine.

I created a debug page that the logon page redirects to after a call to FormsAuthentication.SetAuthCookie that displays information about the authentication cookie. When hitting it in Internet Explorer, the authentication cookie does not exist. When hitting it in FireFox it does.

Has anyone encountered something like this before or have any suggestions about what could be the problem?

EDIT:

Web.config

<authentication mode="Forms">
  <forms name=".ASPXAUTH" loginUrl="Login.aspx" />
</authentication>
<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>   

 <!-- Page used to display authentication cookie information -->
 <location path="AuthDebugPage.aspx">
   <system.web>
     <authorization>
      <allow users="?"/>
     </authorization>      
   </system.web>
 </location>

LogOn.aspx.vb

If (adAuth.IsAuthenticated(Domain, txtUserName.Text, txtPassword.Text)) Then          

  Dim AuthDebug As Boolean =      System.Configuration.ConfigurationSettings.AppSettings("AuthDebug")

  If AuthDebug Then
    FormsAuthentication.SetAuthCookie(SystemUserName, False)
    Response.Redirect("AuthDebugPage.aspx")
  Else
    FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, False)
  End If
End If

The admin of their domain looked through the group policy to see if they were pushing anything down to their nodes that prevented users from accepting cookies on IE and he didn't find anything. He also took a machine off the domain and cleaned it of all group policy and still had the same trouble authenticating in internet explorer.

+1  A: 

It is extremely unlikely that Forms Authentication, in Microsoft .NET since 2002, is breaking with Microsoft Internet Explorer, as a general rule. This is clearly something environmental.

The thing to do is watch the network with Fiddler or something and see what's going on. Then do the same with Firefox, and compare.

Once you see the difference, try to figure out how that difference could be limited to IE.

John Saunders
I don't think this is really a feasible solution because the server is in their control and the admins of that server would go o.O at fiddler.
Dustin Hodges
I don't see how you can possibly solve the problem if you don't find out what the problem is.
John Saunders
IIS log will help some.
John Saunders
A: 

Speaking of IIS, have you checked the authentication method that IIS is trying to use on the site instance? I believe Firefox will convince IIS to use "basic" authentication, while IE would try to use its fancy Windows authentication, etc.

Also, do you have the site's IP/hostname specified in the HOSTS file? That might make a difference one way or another (sometimes good, sometimes bad).

ajh1138
A: 

Like ajh1138 said, it's possible that IE is negotiating to "integrated auth" while FireFox is using HTTP auth or plain old form-POST.

IE may be mapping to an actual Windows username (such as the user running IE), and that user may not have access to that web page (even when the anonymous user does). That could produce the behavior you described.

Marsh Ray
+2  A: 

As John said it was something environmental. We turned on cookieless authentication and that worked just fine so users were being authenticated correctly. One of our customers discovered that when they used just the IP address to access the website (e.g. http://111.111.111.111) that the website behaved properly and they were able to get past the login page but when they used the DNS name it did not. Turned out their zones in internet explorer did allow enough trust to outside sites (which the DNS name resolved too) as it did local intranet sites to have cookies.

Dustin Hodges
+1  A: 

Site I'm developing had similar problem loggin in with all IEs except only one that was run from Win 7.

The actual problem was that the host name i was using had underscores, which should not be used. Maybe some windows policy prevents from creating cookies for invalid hosts.

Juhani Markkula
Thanks - this was our issue.
Daniel Skinner
A: 

Para los usuarios que leen en español, esta fue la solucion al problema

http://www.devjoker.com/contenidos/catss/426/IIS-6-y-la-Autenticacion-integrada.aspx

Carolina