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.

A short post to summarize the state of the matter revealed in my prior two posts (Part 1, Part 2) on the bizarre behaviours I've been encountering on behalf of my customer, Envision IT, with respect to SharePoint 2010 Claims Based Authentication. As indicated in my last post, we have initiated a support ticket with Microsoft to explore the issues we've seen (captured in a screencast that can be found in Part 2). This was sent to Premier Support, along with corresponding ULS logs: In the end, they had no explanation for what was causing the problems. 

So, I asked for an escalation to the next level which should be initiated some time today - I have no preconceived expectations here, but it would be nice to know why, precisely, FBA/CBA is such an untameable monster. In the interim, my customer opened a second support ticket to walk through setting up FBA on one of their integration servers that was acting ornery and not allowing the setting of permissions for Forms Based Users.

A bizarre (to me) outcome of this was the discovery that you don't need to add FBA users via User Policy in Central Administration for them to access a site collection. That's really, really, really interesting. Because just about every ounce of documentation that I've ever come across for setting up Claims requires this step to allow your FBA/Sql users into your web app. Even my first level of support indicated this as a required step. So what gives with that?

All this underscores a wide amount of confusion and lack of concise documentation from Microsoft on how to configure these environments successfully and repeatedly. Additionally, there is also the matter of IIS 7 integration when it comes to configuring the environments - effectively, you're better off modifying the web.config files for Central Admin, the Security Token Service and the target Web App manually rather than through IIS Manager. Part 4 should come later today or tomorrow.

Ongoing…

Following up on my earlier post, here’s the latest installment of my Riddle of the Three Failing SharePoint 2010 FBA Web Applications.  As you’ll recall, I’ve been experiencing some baffling authentication errors with SharePoint Claims Authentication web apps which prompted me to configure a “clean room” test on a VM that consisted of three vanilla publishing web apps, each set up for claims auth using a standard ASP.NET SQL Membership database.

What I discovered was that as I configured the web apps, things began to fail once I completed setting up the last one.  I found that the second web app wouldn’t let me in, then the first then all three.  For no apparent reason.

I escalated this to open a support ticket with Microsoft on the issue, which is ongoing.  However, I did want to show what we’re seeing as it is a variant on the above scenario.  Support believed the issue could be with the way we were configuring our connection strings and providers through IIS Manager, and recommended using modifications to web.config.  Six and one half dozen, I think, but ok.  Then things got weird.

So – same deal:  Three web apps, port 80, 85 and 90.  This time, port 90, the last one configured, works as advertised - solid.  The first two fail in a strange way where accessing one affects the other requiring authentication using Windows credentials and signing in as an FBA user once access is granted.  Sign out, however, and your FBA creds get denied.

The following screencast shows what we’re seeing – again, if you can set up a similar test environment to corroborate or refute, this would be helpful!  We’re running the RTM code and back-ended to a SQL 2008 R2 database.

I’ve been working on a frustrating problem with SharePoint 2010 RTM that I’m at a loss to explain.  Initially, I thought it was me not having a thorough understanding of how to configure claims for forms-based auth.  But now, after a few months of repeating the same steps over-and-over-and-over, I’m fairly confident that I do understand it – and I’ve successfully set up single web apps without issue (but which, in the end, display the same failings I describe below in time).

I’m now at the point where I keep doing the same thing expecting a different result – and we all know what that is the definition of. ;-)

As an aside – it is totally frustrating to see that documentation – and I mean SOLID !#$%^&* DOCUMENTATION from MSFT has been almost entirely lacking for configuring FBA using claims, and what does exist is pre-beta this, RC that and RTM the other.  Completely unacceptable.

The Scenario:

What I’ve been seeing is a couple of weird behaviours.  They all distill to authentication problems – either I can’t add users via the people picker, the dialog textbox or both, and those I do add may or may not get denied after being added via User Policy to the web app.

In an effort to clear this up, I created three identical web applications (Publishing template) on a virtual machine, each configured for claims based auth on the default zone:  http://localhost, http://localhost:85, http://localhost90 .  Each of these point to three different ASP.NET membership databases on a separate SQL 2008 box which were created using the aspnet_regsql wizard.

In IIS, I created connection strings and membership providers for each DB in the usual way – if you don’t know what the “usual way” is, there are a few blog posts that can help clarify what I mean.  Essentially, there’s a Texas two-step hokey-pokey you need to do to add the providers for Users and Roles (groups) to ensure you get users from each ASP.NET membership DB.

After you do this for the target Web Application, you need to add corresponding entries in the web.configs for the Central Administration and Security Token Service web application.

In terms of process, I created and configured each web app sequentially – I wanted to see when and where things started to go sideways as web apps were added.

The Results:

The web app on port 80 was created and configured without issue – and I was able to get my test user, fbacchapman, to authenticate via the default login form without issue.  I repeated the process for the web app on port 85.

Then, I added my final web app on port 90.  Everything was going well until I tried logging-in with my test user, fbacchapman4.  Access denied!  The user has been added to the web app, everything is fine – he just can’t authenticate.

Then something really bizarre happened:  I went back to my first web app on port 80 and tried logging in again with my fbacchapman user.  Access denied!

Update: Failure x 3

Returning to the web applications today, I discovered that, for some inexplicable reason, all three now deny access to FBA users that should work!  To show what I’m seeing, I’ve recorded a screencast that you can download here from my SkyDrive.

The Challenge to You, Gentle Reader:  Repeat the Configuration – Prove or Disprove

I’d like to know if anyone else can replicate this configuration of three web apps configured for claims auth failing on the same box.  For no outwardly explicable reason.

Via AgileJournal:  Seven Agile Team Practices that Scale

This is a great piece that could be used as a primer to distribute to new customers and teams you’re trying to win-over into the agile column to help them stop their losses using tired, thrash-and-burn, over-the-cubicle-wall, hit-and-run, command-and-control practices.  Read the article for explanations for each:

1. Iteration Foundation
2. The Define-Build-Test Component Team
3. Smaller and More Frequent Releases
4. Two-Level Planning
5. Concurrent Testing
6. Continuous Integration
7. Regular Reflection and Adaptation

These are the practices of world-class, top-flight teams.  They’re easy to talk about, tough to put into practice because it’s hard work and unfortunately there’s a lot of folks who’d rather wring their hands than get to it.  It’s precisely the reason why, I suspect, Ken Schwaber recently opined on Twitter, “Picking places to use Scrum? Look for projects where everyone's on board. Otherwise you waste time/resources dealing with malcontents.”

This said, I believe any team can aspire to these practices and do them to a fairly high degree of competency.  Just like getting off the couch and doing a run can have immediate benefits to your health, teams that start to employ these practices can begin to realize a complete change in how they deliver value that, quite simply, will leave their competition in the dust.