Update: Judging from the comments I've received, no doubt many has tried this path - however it is IMPORTANT to note that this is NOT A SUPPORTED deployment. Using non-domain account for installing and configuring SharePoint will result in ending up with only ONE web server and ONE database - that's it - NO splitting of roles in the WFE, and NO redundency support, and you CAN'T add more servers.
There has been tons of posts about using Form-based authentication for MOSS (almost all of them are on using the ASP.Net SqlMembership provider). That is really a great improvement over SPS2003. Recently I was helping a customer who had the challenge of deploying MOSS, not just with form-based authentication, but also to deploy SharePoint farm on an SQL server which is not a member of an AD domain.
At first glance, this may not seem possible - the configuration wizard for setting up the configuration database expects a domain account to connect to the database server (workgroup account will work fine if the entire farm is on one single box) - which is not good if we want to use SQL authentication.
Now, here's one of the reason why the SharePoint installation wizard has a checkbox prior to running the configuration wizard:
Right after installation, uncheck this checkbox, or if you did and were halted at the "Specify Configuration Database Settings" page, simply close the wizard. What we need to do now is to go to our SQL Management Studio (or SQL Enterprise Manager for SQL2K), and create four databases manually. Make sure these databases are created with the Latin1_General_CI_AS_KS_WS collation (for the curious, C = Case, A = Accent, K = Kana, W = width, and I/S for Insensitive/Sensitive). These four databases would be: the SharePoint Configuration, SharePoint Admin Contents, Shared Services, and Shared Services Search. Assign the SQL login that we are going to use for MOSS as the dbo for these four databases - let's name them as "SharePoint_Config", "SharePoint_AdminContent", "SharedServices_DB" and "SharedServicesSearch_DB".
Now fire up the command line console and use the following command (from the 12 hive* folder, "bin"):
*12 hive being the %programfiles%\common files\blah blah blah\12 - you get the idea.
PSConfig -cmd -configdb -create -server database_servername -database SharePoint_Config -user domain/username -password password
-dbuser sharepoint_login_username -dbpassword sharepoint_login_password -admincontentdatabase SharePoint_AdminContent
The arguments for:
server - this would be your SQL Database Server's Instance name
database - the database name for SharePoint's configuration (we name it SharePoint_Config here)
user - the windows account used as the server farm's administrator account
dbuser - the SQL login account to connect to the database
admincontentdatabase - the database name for SharePoint's Central Administration site (SharePoint_AdminContent)
Most importantly here are the dbuser and dbuserpassword arguments. These are not available from the configuration wizard UI.
Running the PSConfig command:
Now, we are ready to resume the configuration wizard. Re-start the wizard from the start menu (Start -> Programs -> Office Server -> SharePoint Configuration Wizard...). The configuration wizard is smart enough to detect that we already have the configuration database created:
Unless we want to recreate the databases again, choose not to disconnect from the server farm. Follow the wizard on as per usual installation. Now when it comes to configuring the farm's services, we can easily configure it to use SQL Authentication:
Ditto for every subsequent content databases that the wizard will need to create for every site in our Farm. Now when it comes to setting up the SSP, simply point the database to the ones that were manually created earlier, and supply the SQL Authentication credentials as well.
So, it's actually possible, and quite easy in fact (once you have figured out the command parameters!) to deploy MOSS that connects to SQL using SQL logins! One BIG caveat with this though: We will be limited to ONLY ONE topology, which is 1 MOSS box, and 1 SQL box. That's it - no farms. Not scalable, but not impossible either.