This is the first in what I'm hoping will be a series of posts focused on giving the full story for different pieces of SharePoint functionality. SharePoint is a very powerful product with a laundry list of features and functionality. When planning a project the question comes up as to whether SharePoint can do something, the answer is often viewed as yes or no. In many cases, the answer should be "it depends on what you expect."
A good example of this is the decision to use Forms Based Authentication (FBA) with SharePoint. Because SharePoint 2007 is built on top of ASP.NET 2.0, developers and admins can use FBA to allow users, who's identity information is stored in SQL (or ADAM another non-AD db), to authenticate to SharePoint.
This is very attractive because many times companies want users who are not in their AD to authenticate to SharePoint. Most often, I see this used for Internet site or Extranet scenarios. The option to use FBA opens a lot of possibilities for what you can do with SharePoint.
I spend a lot of time in the
Microsoft TechNet SharePoint Forums and also often get calls from clients who want to use FBA simply because they want to allow external users to authenticate to SharePoint. This is one of those times where it is important to set expectations properly.
FBA does provide a mechanism where external users can authenticate to your SharePoint server without having to be in AD, but there are some tradeoffs that I don't see mentioned very often (if ever):
1) It is complex to setup and configure. There's a lot more to it than just flipping a switch
2) Management of users isn't the greatest. There are some 3rd party utilities out there that can help out with this though. I often install this to help make things easier:
3) MOSS cannot crawl web applications using FBA so you'd need to use a dual authentication configuration to ensure that search works. For more information on that, Andrew Connell has a great post about this:
4) **This is the one I never see anyone bring up** Users who authenticate via FBA do not have the same level of functionality available to them as users who authenticate with a Windows Authentication method. Essentially the client integration features won't work:
- Links that start client applications are not visible.
- Documents are opened in the browser. Documents cannot be opened by client applications.
- Users cannot edit documents on the site directly from the client applications. However, users can download the document, edit the document locally, and then upload the document.
For more information take a look at "Expected Behavior When Client Integration is disabled" in this link:
You can always attempt to use some type of workaround, but the point of this post is to explain that FBA isn't a silver bullet. Anything can be done given enough time and money, but the goal here is to set expectations and give the whole story.
If you have a situation where you want to give external users access to SharePoint and maybe FBA doesn't sound right for you, consider setting up a separate OU in AD for your external users and set a policy that doesn't allow them to authenticate locally to your domain. Or you could always spin up a separate AD with a one-way trust.
Setting expectations is key to any SharePoint implementation. Take the time to do proper planning and it will make your life easier and lead to happier end users!