By Dan Holme
Office & SharePoint Pro
Community Manager
When I die, I hope I don't end up in the hot place where they use forms-based authentication
Because I've seen it already. And it is scary. Tonight we made chocolate chip cookies. Not too many because I've got to watch my figure, thank you. And, no, with my workload I couldn't make them from scratch--I cheated and used pre-made cookie dough. When they came out of the oven, they weren't quite cooked through. But you know what? Half-baked chocolate chip cookies are one of my favorite things. Yum! I hope you get to share some half-baked cookies or other sweets with a loved one this week. Half-baked cookies are fantastic. Half baked features are not. And that's why I won't be sharing any love with SharePoint this week. Because last week I lost three valuable days of my ever-shortening life thanks to SharePoint's half-baked forms-based authentication (FBA) feature. And it is not sweet. In fact, it's made me quite bitter. So this week... a rant... Since the latest SharePoint versions were released 14 months ago, I've been successfully running SharePoint sites for small projects and for the small businesses of some friends. The applications use FBA, and of course SharePoint doesn't provide any form of user management for FBA, which is the first sign that FBA wasn't given enough love as a child. I worked around that with an effective and cheap, though sometimes quirky, tool called Membership Manager from Quality Data. Sadly, I've learned, as many others have learned, that when you update an email address in an FBA database, SharePoint doesn't update the email address for the users in the site collection. Who needs to communicate with users, or have SharePoint alerts go to the correct address, anyway? That's a far too obvious gap in a feature that's supposedly designed for supporting extranet scenarios. Week before last, SharePoint FBA just up and quit. The Web applications were just fine (thank goodness). I could switch to Windows authentication and get into the apps and their content--but as soon as I switched back to FBA, no dice. Aha, I thought, the FBA database must be corrupt. Nope. The Membership Manager was still happily working against the database, as was SharePoint's own Central Administration. It got stranger. In the process of rebuilding the Web applications to fix the problem, I found, several times, that a Web app would have the absolutely identical web.config file as another app (except for the machineKey element, of course, which is different per app), and one would work just fine with FBA, and the other would not. No errors were presented in the logs or in the UI. In fact, the UI presented the FBA Sign In page and, regardless of what username or password was entered (including invalid credentials), the page would simply refresh with no sign of any life whatsoever. To make it work I had to redesign my Web apps in a way that is very different from the configuration that worked perfectly well for 14 months. The "old way" just would not work consistently for all Web apps even though, again, the web.config and other configuration was identical. My guess is that there's something in the content database that got out-of-whack. It's really the only possible explanation. But there's no useful documentation I could find to help me figure it out. So I worked around it.
Something was wrong so deep inside of SharePoint that none of the incredibly bright minds I recruited for help could provide any insight. It was just, simply, broken in ways that were inexplicable. Along the road to recovery, we ran into other bumps in which the SharePoint UI would say one thing, and stsadm.exe would say another. Those inconsistencies will be fodder for a future rant.
Now I know there are plenty of sites out there where FBA is in use, and I'm sure I'll get a few nasty grams for sharing the pathetic experience I've had with FBA over the last few days, but here's the point: It shouldn't take a rocket scientist to troubleshoot problems with FBA--and, in this case, even the rocket scientists were baffled. A feature that's designed to support extranet scenarios should be something that can be configured by an IT pro without needing insanely long MSDN articles ( starting with Forms Authentication in SharePoint Products and Technologies (Part 1): Introduction (shouldn't IT pro doc be on TechNet?) or the much-appreciated guidance of community experts like Andrew Connell. And, gee, wouldn't it make sense to actually support user management or at least keeping email addresses synchronized? FBA is an important feature, to be sure, but the difference between half baked and baked makes it costly to implement and support, as I've now learned firsthand. It's decidedly not sweet.
Got some thoughts about FBA? Shoot them my way. Until then, I'm going to eat some more gooey chocolate chip cookies and pretend, for a few hours, that I never once heard of FBA. Hitting the Road
In March & April I am "hitting the road" with a tour to ten cities across the United States. SharePoint Live! is a full day of fantastic, technical content presented by SharePoint experts who aren't tied to any one vendor, so you're sure to get the real scoop from real experience. This particular event is for IT Pros, with two tracks of content (six workshops altogether) covering WSS 3.0 and MOSS 2007. The sessions include: |