If you search the Internet you will find some very good instructions for setting up forms based authentication (FBA) in both Windows SharePoint Services v3 (WSS) and Microsoft Office SharePoint Server 2007 (MOSS2007). I won’t rehash all those instructions here. However I do want to make a couple of observations. One person actually posted about a missing step which involves ensuring that the user account that your SharePoint Application Pool runs under has permission in your SQL Server. I think they assume you are just going to give that user owner rights on your aspnetdb database. I don’t like giving that much permission to a limited user account.
The documentation from Microsoft states give that user read and write permissions on that database, but unknown errors kept occurring. What I ended up doing was adding the run time user to certain roles that aspnet_regsql.exe had set up in the aspnetdb database. Those roles were:
- aspnet_Membership_FullAccess
- aspnet_Personalization_FullAccess
- aspnet_Profile_FullAccess
- aspnet_Roles_FullAccess
I added these in addition to data reader and data writer. There was an additional role called aspnet_WebEvent_FullAccess. I don’t know what that is for so I didn’t set it. I’m sure I’ll run across it in the future.
How did I know that I needed to set those? Well this leads me to my second tip. Some instructions for setting up FBA tell you to only use Visual Studio’s Web Configuration tool to do the initial configuration and set up the user accounts. However, if you create a login page and try to log in using this login page you’ll get some error messages that lead directly to the realization that the user account doesn’t have the right perms.
This login page could be a whole application for user management. Read my next post when I explain why I set up the custom login page to begin with.
