This post attempts to describe as simply as possible how to
change a WSS V3.0 application to support Forms Authentication. It assumes that
you already have a Site Collection that uses integrated security created.
1)
We are going to use the Microsoft SQL Server
Membership Provider (AspNetSQLMembershipProvider). First we need to create a
database to use; this is done by executing an application called
aspnet_regsql.exe on the
target server. The application is located in your .NET Framework directory under
the Windows directory. Ours for example is in the
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 directory. The application takes
you through a short ‘wizard’ - the key
dialog is the following where you set the SQL Server name (SQL Server 2000 or
2005) and the database name.
2)
Override the default LocalSqlServer connection
string to point to our new database. We could use our own uniquely named
connection string but then we would need to register our own provider and we are
trying to keep it as simple as possible...Add the following to
the
web.config of the target site (after the </SharePoint> tag would be
fine):
<connectionStrings>
<remove name="LocalSqlServer" />
<add name="LocalSqlServer" connectionString="Data Source=(local;Initial Catalog=WSSASPNETDB;Integrated
Security=SSPI;" />
</connectionStrings>
Note that this connection string uses integrated security. In
order for this to work you will need to give the user that is the identity of
the Application Pool that your target Website runs in has permissions to access
the database that you created. Another option would be to use SQL Server
security and embed the userid/password in the connection string.
3)
Create at least one user in this database (which
will be the Site Administrator) before we change the authentication. There are a
number of ways you can do this, for example if you have a copy of Visual Studio
2005 installed on the server (which
you shouldn’t) you can use the ASP.NET Web Site Administration tool. In
our case we are going to use a WebPart created by
Matthew Cosier hosted on one of the
pages in the existing site (we are going to need this somewhere later anyway if
we want people to be able to register for the site and create a login).
4)
Override the default LocalSqlServer connection
string of the SharePoint Central Admin Website to point to our new database. Add
the following to
the web.config of the SharePoint Admin
site (after the </SharePoint> tag would be fine):
<connectionStrings>
<remove name="LocalSqlServer" />
<add name="LocalSqlServer" connectionString="Data Source=(local;Initial Catalog=WSSASPNETDB;Integrated
Security=SSPI;" />
</connectionStrings>
Again this connection string uses integrated security. In
order for this to work you will need to give the user that is the identity of
the Application Pool that SharePoint Admin runs in has permissions to access the
database that you created. Note that this only works well if there is only one
Forms Authentication WSS site on this machine, if you want to have more you will
have to use a more complex method (out of context for this article).
5)
In SharePoint Central Administration, change the
Authentication Provider for the target Web Application from
Windows to
Forms, enable anonymous
access, and set the Membership Provider and Role Manager to the ASP.NET default
providers.
6)
Sign on to the Site Collection as Administrator
and allow Anonymous access
7)
Change the Administrator of the site from the
Integrated Auth user to the user you added to the database in step 3). If you
set the LocalSqlServer connection string in SharePoint Administrations
web.config properly and if the pool identity that Central Admin uses is
permitted access to the new membership database then when you click check on the
people picker it should be underlined. This makes our new Forms identity Admin
for the Site Collection.
8)
Now when you go back to the site you should be
able to log in as the user you added to the DB and specified as Site Collection
Admin you should be able to perform all admin functions.