To this point we have created a database, a connection string, a Web.Config, copied data from the Machine.Config to the Web.Config, changed the Web.Config for our needs and connected to the database, used the Web.Config and connection string to connect with a Visual Studio tool and created users. This is all build-up to our next effort, because if all works as it should, that database will replace the Windows database for the SharePoint site we are using in this example.

1.    With another copy of Visual Studio, open the root of the SharePoint site in question by locating the file root via IIS so you can find the Web.Config.

2.    Open the Web.Config in the site.

3.    Highlight the entire page contents and press Ctrl+m+m, which will collapse the page.

4.    Open Configuration key, then clear a line just above the <SharePoint> opening tag.

5.    Paste the connection strings section from the first Web.Config you have been working on, to this one.

Figure 4: The added connection string

6.    In Figure 4 you can see the addition of the connection string, named LocalSqlServer. This line contains a pointer to the aspnetdb database and references the System.Data.SqlClient assembly.

7.    Now before we continue we need to make a change inside the site. Open the website you are working on by logging in as an administrator. Go to Site Settings, Advanced Permissions, pull down the Settings Tab and click Anonymous Access. Check the Entire Website radio button and click ok. Close out.

8.    Now, open the SharePoint Central Administration website. Go to the Application Management tab, under Application Security select Authentication Providers, use the Web Applications tab to select the application you are after, in my case a very simple and blank site called "siteb."

9.    Click on the Default link and now the information we are presented with, along with our previous actions, puts us close to the completion of our goals.

10. Click on the Forms radio button, which will change the screen in a few ways.

11. Click on Enable Anonymous Access.

12. As you will find in the Machine.Config, add the word "AspNetSqlMembershipProvider " in the membership provider name box.

13. Click save, close out all appropriate open files, open the command prompt and run IISRESET.

14. If you do not already have one, create a basic user on your server. Then open another session to the same server by typing " mstsc /v:<local host name> " and log in as that user.

15. With that user account logged in, reopen the site you are working on, "siteb" in my case.

16. You should now see the front page as an anonymous user.

17. Click on the Sign-In link in the upper right, and you should be presented with SharePoint pre-created login and password box pages.

18. Login as one of the accounts that you had previously made inside SharePoint many steps earlier. Notice that you are logging into Windows as one account, stored in Windows (or ADS) and then you are logging into WSS as a non-Windows user (even as an internet anonymous user, as the goal is), with, of course, the WSS account stored in SQL Server (again, in my case the SQL Server is a named instance, but it could be the main, and maybe even an SQL file).

19. If all goes according to plan, you are done.

20. In conclusion, we have demonstrated the act of switching one WSS site to use an SQL server to store user accounts. The primary reasons for this are two-fold. One is the intent to save money by purchasing less CAL's to allow people into your WSS site (not all situations apply but the intent to do things this way could help you convince bean counters). The second main reason is security related. If a WSS user gets out of the WSS sandbox, at least there is no direct correlation between WSS accounts and Win/ADS accounts. This of course should not be the sole method of security review, although it may help your case in enlisting the security gurus.

21. What we have not covered is also fairly significant. On uncovered detail is the use of multiple SharePoint zones (for example, allowing some users to log into a content site from one direction, such as internal, ADS users, or external SQL accounts). Other uncovered details are highly detailed examples of user permissions and mixing the two together. This will all come together in part two.