4

I have a custom claims-based login page which works correctly in Firefox, Chrome, and IE 10. The login page is a standard "choose your login type" scenario that redirects to _windows for Windows logins.

When a user on IE9 or earlier chooses the Windows option and authenticates correctly, they are sent back to the login page. If they click the Windows link they again go back to the login page.

BUT, if we wait some time (don't know how much yet - 1 minute? 2 minutes?) then the Windows link takes them back to the original site. If the user puts the direct site URL in after authenticating, then that also works.

So it appears that the authentication and authorization is working, but that IE9 and earlier are waiting to figure that out somehow. I'm thinking it's a cookie timing issue of some sort but I can't figure out what it is.

What is the best way to solve this?

Improve this question
1
  • This isn't normal behaviour, I use the same login configuration on several installations. It possibly is something to do with your login page. Trace what is happening with Fiddler2 turning on https decoding and take a look where the delay is. IE9 also has network tracing which you can use for taking a peak at what is being requested.
    – Hugh Wood
    Dec 7, 2012 at 19:37

1 Answer 1

Reset to default
0

I should have posted this sooner. We figured out that on the production server, we had missed turning on the Claims to Windows Token Service. Not sure how that remotely maps to the behavior we were seeing, but that was what fixed it.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.