If you’ve been following this series (Part 1, 2, 3) you know the issue: I’ve got a SharePoint 2010 VM with three web applications, each enabled for Claims Authentication using three separate ASP.NET Membership SQL Databases. One out of the three works reliably (ie. login/off/as another user) while the other two require a weird hokey-pokey of authenticating in using Windows credentials before letting the FBA credentials work.
Today, I was on a call with “D”, the Escalation Support Engineer assigned to my customer’s case. He demonstrated to me how he was able to get three 2010 web apps, each with their own SQL Membership Database all working. Up and down, left and right, no questions asked. Baffling to me.
So, we do an EasyShare on my VM and I demonstrate the problem once more: Port 80, works fine. Port 85 and 90, only work after using Windows credentials.
“Could you try using the machine name in the browser address bar instead of ‘localhost’ ?”, “D” asks.
“Sure.”
And dammit. It worked. Each of the three web apps allowed me to sign-in/out and in again as another user.
“D” isn’t done, however. He tries using ‘localhost’ on his end.
“They all work on my VM whether I use ‘localhost’ or the machine name,” says “D”.
Raising More Questions than Answered
Well, ain’t that just peachy. So, the apparent “fix” for my environment is to not use ‘localhost’. But even that’s not quite right as the port 80 web app works up and down irrespective of the means I put into the addressbar. So, I’m left even more confused: Why on Earth is there no consistency in a vanilla environment?
I’ve got homework to do, before I can come to a closer definitive resolution. “D” has asked me to re-build my web apps using his recommended web.configs – that will take an hour or so. Then I need to ping him again to see where this goes.
What. Fun.