Forms-based authentication in WSS 3.0

One of the cool things about the security model in WSS 3.0 is that you're no longer restricted to Active Directory when it comes to authenticating users. Because WSS 3.0 is using ASP.NET 2.0's provider model you can authenticate your users in any way you want, including forms-based authentication.

Forms-based authentication is useful in an extranet scenario where you don't want external users in your Active Directory. But what's really cool is that you can configure SharePoint to use multiple authentication providers for the same site. That means you can have external users of an extranet logging in by typing a username and a password (forms-based authentication) and still provide a seamless user experience for internal users of that same extranet by authenticating them based on their existing Active Directory credentials (windows integrated authentication).

There are two really good posts on how to configure SharePoint to use multiple authentication providers:

• SharePoint Team Blog: Configuring Multiple Authentication Providers for SharePoint 2007.
• Andrew Connell: Configuring a Office SharePoint Server 2007 Publishing Site with Dual Authentication Providers and Anonymous Access.

Now, my whole point of this post was to share a couple things based on my experience with configuring this:

• The first couple of times I configured dual authentication carefully following the instructions in the posts above, it simply wouldn't work for me. I didn't get any useful error messages, SharePoint just didn't want to resolve my forms-based authenticated users. After many hours of frustration I realised that the account that my SharePoint application pool was running under didn't have access to the database where my users were stored. So, after you've created your ASP.NET 2.0 framework database with the aspnet_regsql.exe tool make sure to grant permissions to your SharePoint application pool account.
• Following Andrew Connell's tip, Visual Studio 2005's ASP.NET Configuration Website is a quick and easy way to verify your web.config settings and to add some users into your database. But for your end users, you want to provide a more user friendly and secure way of adding new users. One way of achieving this is to create a new web part page that is only accessible by site owners. Using SharePoint Designer you drop the standard CreateUserWizard ASP.NET 2.0 control onto that page. Remember to set the MembershipProvider property for that control as well as other properties you may want to customise. Similarily, you can also utilise the other standard ASP.NET 2.0 controls, such as ChangePassword, PasswordRecovery, etc.

Update: I just came across this great post on Chandima's Blog. It's another detailed guide on how to configure forms-based authentication. He has also released an early version of a SharePoint feature he is working on. This feature will add user administration functionality to a site using forms-based authentication. Nice work!

Stay tuned to my SharePoint musings: Subscribe via email or RSS.

New SharePoint Designer Team Blog

The SharePoint Designer Team at Microsoft have just started a new blog. They are promising posts on usage scenarios and general positioning of the product. I must admit I was one of those slight sceptics of FrontPage. However, these days I find myself doing more and more cool things in SharePoint quite efficiently using SharePoint Designer. I look forward to learn more good stuff by reading the SharePoint Designer Team Blog.

Version numbering when migrating documents into SharePoint

When creating a new document in (or uploading one to) a SharePoint document library with versioning switched on, the document will be given version number 1.0 in the version history.

When moving documents across to a document management solution based on SharePoint document libraries, your documents will more often than not already have a version history in another system. This could be as simple as having kept a version number manually inside the document itself along with a revision history table.

I have had clients asking about the possibility for initialising the version number that SharePoint gives new documents. By design this is not supported by the SharePoint API and hence it cannot be done. Don't even think about going straight to the database to do it.

So, what do you do about keeping track of your audit trail across the two systems? Here's a couple of options I can think of:

1. Create a custom column with a manually updated version number (or updated automatically by a workflow). Basically continuing the previous version numbering.
2. Only use the new version numbers in SharePoint and then document the mapping between the last version in the previous system and the first version in SharePoint.

The MOSS Records Center

Just a quick one to draw some attention to the Records Center site template that comes with MOSS as I think it's quite cool. It's powerful functionality that's very easy to configure.

There is a brief demo here demonstrating the functionality and how you set it all up in a few simple steps. Following these steps, it will take you less than 15 minutes to build a working demo.

A few things to keep in mind:

• When connecting the Records Center in Central Admin, make sure to enter the address of the Records Center web service and not just the Records Center url.
  (e.g. http://[RecordsCenterUrl]/_vti_bin/officialfile.asmx)
• When setting up the record routing take care the Title matches the content type name exactly and that the Location matches the name of the destination document library in the Records Center.
• The routing of documents into different libraries in the Records Center is all based on content types. Hence, keep the Records Center in mind when you design your content types across your document libraries. The more you leverage content types, the better you can structure and automate your Records Center.