fun with FBA...

No, it's not a dirty term.

FBA = Forms Based Authentication - it's a Sharepoint thing.

I've been tasked with creating an extranet for the Board at the regional library organization that I work for.

It's been an education, to say the least.

We are using a separated isolated server to host the extranet with a pristine uncluttered version of Windows Sharepoint Services (WSS) 3.0. Typically when implemented as an intranet, WSS uses windows authentication in conjunction with Active Directory (AD.). When implemented as an extranet, there are security issues with potentially exposing AD to the outside world, so we seek a different means of authenticating users in an extranet. This does of course assume that we still need to authenticate users of the extranet and that we are not simply throwing it open to the world.

The easiest (relatively speaking) alternative means of authentication vs. windows authentication is FBA - Forms Based Authentication. There are some things that are given up when we go this route - most notably a significant level of the integration features that make WSS so appealing for intranet use. However we still retain significant functionality that makes the overall endeavor worthwhile.

To date, while trying to implement FBA, I seem to have run across something that is either so widely known that no one has seen fit to document it, or that is rarely enough encountered that no one has documented it yet.

First some clarification of some confusing points. A basic standalone default installation of WSS 3.0 uses Windows Internal Database (WID) as the underlying data store. WID is a modified instance of SQL Server Express Edition (SSEE) that has some limitations and special characteristics. This is basically the only instance in which WID is used with WSS/Sharepoint. A default standalone installation of Microsoft Office Sharepoint Server (MOSS)(the expensive version of WSS) uses SSEE.

WID, as used for WSS 3.0, does not have some of the limitations of SSEE as used in MOSS. For instance, SSEE has a 4gb size limitation on a db when used with MOSS as well as some limitations on processor and RAM usage. While it is not clear whether there are any limitations on processor and RAM use with WID, it is definite that there are no size limitations on WID databases used with WSS.

However, WID is significantly locked down compared with SSEE. It can not be used by other applications, and there are no managment tools included in the default installation of WSS. The SSEE management tool, SQL Server Management Studio Express can be used to view and edit some very limited features of a WID. However, the process of connecting to a WID is far from intuitive - rather than using a conventional "[name of server]\[name of database]" connection string, it is actually necessary to use a named pipe "\\.\pipe\mssql$microsoft##ssee\sql\query" as the server name to connect to an instance of WID.

Additionally, and this is the issue that really prompted the writing of this post, the limitations of WID when it comes to other applications seems to throw a very big wrench into the works of FBA.

A conventional implementation of FBA will take advantage of the grunt work already done in asp.net2.0 and utilize the Membership, Role Management, and Personalization services. To use these features, we must use aspnet_regsql.exe to create a db to hold the data associated with these services.

However, WID does not seem to allow this db to be created. It appears to work, but an error message is displayed by aspnet_regsql.exe while trying to create the database which refers to SQL error 33003, and to "unable to execute DDL statement".

While the db appears to exist afterwards, it is devoid of content tables and cannot be populated with data in any way.

In essence, it woudl seem that if you wish to use FBA with a default installation of WSS 3.0 with WID, you cannot do it without also installing SSEE to run alongside of WID for the sole purpose of providing the db needed by the authentication provider.