HOWTO: Configuring a Office SharePoint Server 2007 Publishing Site with Dual Authentication Provider

[LEFT][CODE]http://www.andrewconnell.com/blog/articles/HowToConfigPublishingSiteWithDualAuthProvidersAndAnonAccess.aspx[/CODE][I]This article was been updated for WSS v3 / MOSS 2007 RTM on December 11, 2006. In addition, additional information was added and changed in the section [B]Enabling Anonymous Access[/B] when the article was updated for RTM.[/I]
Content-centric sites that are managed via a Content Management System typically have very specific requirements. The owners of the content of a content-centric site usually spend most of their time behind the company firewall and login to their corporate Active Directory. Ideally these users need to have a single-sign-on (SSO) experience where they don't have to remember a special username and password to simply login to a Content Management System to author and manage the content on the company Web site. The public-facing portion of the site needs to allow visitors to browse the site anonymously. However, there may be certain areas of the site that require the user to login. These may include premium content, registration, or an e-commerce solution. While the familiar username/password dialog is acceptable in a corporate setting, it is frowned upon on the public realm of the Internet. Therefore, many companies prefer to implement some type of forms authentication where users login using a username or email address and password to gain access to protected areas.
Web Content Management (WCM), one piece in the Enterprise Content Management (ECM) strategy included in Microsoft Office SharePoint Server (MOSS) 2007 adds the capability of hosting and managing content-centric sites to the SharePoint platform. MOSS 2007 is built on top of Windows SharePoint Services (WSS) v3 which is in turn built on top of ASP.NET 2.0. This means that WSS v3 (and MOSS 2007) have full access and utilize everything that ASP.NET 2.0 has to offer… including the pluggable authentication model. It is this pluggable authentication that I will leverage to provide multiple authentication options for a single Web site. In this article I want to demonstrate how to configure a Publishing Site (aka: WCM site) in MOSS 2007 for the previously described common scenario companies encounter with content-centric sites. The goal is to provide an experience that achieves three requirements:

[LIST][*]Allow content owners/authors to authenticate on the site using their corporate Active Directory credentials in order to manage the Web site's content.[*]Allow unauthenticated, anonymous users, to browse the unrestricted areas of the Web site.[*]Require anonymous user to provide a friendly Web-based form to login in order to consume restricted content.[/LIST]
I'll demonstrate how all three goals can be achieved using MOSS 2007 and WSS v3 in this article. First I'll set up a database to store the information for users accessing the Web site from the Internet. Once that's configured, I'll create two Web applications and a Publishing Site; each Web application, or IIS Web site, will be configured for a specific type of authentication mechanism (Windows Authentication [AD] and Forms Authentication). Then I'll configure both Web applications so they can access the users and roles that will be granted rights within the site (typically read or contribute rights to protected areas of the site). Once both sites are configured to communicate with the forms authentication-based user and role store, I'll configure one Web application to allow users to sign-in and authenticate via a common Web-based form. The last step will be to configure the site for anonymous access so they can browse the site and consume the content. Finally, I'll show you how to require a login for a specific area of the site.
[I]This article is not written as a step-by-step instruction manual on how to configure your site for anonymous access with dual authentication mechanisms. It assumes some experience with WSS v3 and MOSS 2007. While the subject of this article deals with configuring a Publishing Site (aka: Web Content Management Site), everything translates to any type of WSS v3-based site including MOSS sites.[/I]
[B]Setting Up ASP.NET 2.0 Forms Authentication User & Role Data Store[/B]

Before we can do anything, we first need to create a database that will store all the information, credentials, roles, and users for the forms based authentication site. Then we'll add a single user to this database which we'll use for testing later. Nothing in this step has anything to do with SharePoint as its just plain ASP.NET 2.0.
[B]Create the ASP.NET 2.0 Database[/B]

Before we can do anything else, we need to create a database that will store the users and roles. Microsoft has provided a utility, [COLOR=#ff0000][FONT=Courier New]aspnet_regsql.exe,[/FONT][/COLOR] that will create this database for you. It can be found here: [COLOR=#ff0000]%windir%\Microsoft.NET\Framework\v2.0.5027[/COLOR]. Executing this file will trigger a wizard that will walk you through creating the ASP.NET 2.0 database. I've named my database [B]AcAspNetDb[/B] and configured it for Windows Authentication, as shown in Figure 1 below. [CENTER][IMG]http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-1.gif[/IMG]
[I]Figure 1 – aspnet_regsql.exe wizard (click for larger image)[/I] [/CENTER]
[B]Configure Membership & Role Providers[/B]

Now that our database is configured, we need to add a single user. In my opinion, the best way to do this is to create a new Web site project in Visual Studio 2005. Why? Because not only does it have an easy way to access the ASP.NET 2.0 administration Web site that will let us add users and roles, but we'll also ensure our database connection strings, membership, and role providers are correctly configured before we bring SharePoint into the equation. I'll use these same connection string and providers in the SharePoint sites later… so we have a good foundation to copy from. Open Visual Studio 2005 and select [B]File[/B] -> [B]New[/B] -> [B]Web Site[/B]. In the [B]New Web Site[/B] dialog, select the template [B]ASP.NET Web Site[/B], set the location to [B]File System[/B]. I like to put all my Web sites in the [COLOR=#ff0000][drive]:\Inetpub[/COLOR] directory so I'll put mine in the following directory: [COLOR=#ff0000][drive]:\Inetpub\AC FBA Utility Site [/COLOR](FBA = Forms Based Authentication). The language is irrelevant so you can pick anything… we won't write a single line of code.
[CENTER][IMG]http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-2.gif[/IMG]
[I]Figure 2 – Visual Studio 2005 New Web Site dialog[/I] [/CENTER]
Now, add a [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] file to the site. By default, you'll see a [COLOR=#ff0000][FONT=Courier New]<connectionStrings />[/FONT][/COLOR] node within the [COLOR=#ff0000]<configuration>[/COLOR] node. Here you want to specify a connection string to the database you just created in the previous step. For me, I'll replace the node with the following:
[CODE] 1: <connectionStrings> 2: <add name="[B]AcSqlConnString[/B]" 3: connectionString="server=[YourSqlServerName];database=AcAspNetDB;
Integrated Security=SSPI;" 4: providerName="System.Data.SqlClient" 5: /> 6: </connectionStrings>
[/CODE]
With the connection string set up, now we need to specify the membership and role providers. In this article I'm using the ASP.NET SQL membership and role providers, so I need to add the following to the [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] file, within the [COLOR=#ff0000][FONT=Courier New]<system.web>[/FONT][/COLOR] node:
[CODE] 1: <!-- membership provider --> 2: <membership defaultProvider="[B]AcAspNetSqlMembershipProvider[/B]"> 3: <providers> 4: <add name="[B]AcAspNetSqlMembershipProvider[/B]" 5: type="System.Web.Security.SqlMembershipProvider, System.Web,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 6: connectionStringName="[B]AcSqlConnString[/B]" 7: enablePasswordRetrieval="false" 8: enablePasswordReset="true" 9: requiresQuestionAndAnswer="false" 10: applicationName="/" 11: requiresUniqueEmail="false" 12: passwordFormat="Hashed" 13: maxInvalidPasswordAttempts="5" 14: minRequiredPasswordLength="1" 15: minRequiredNonalphanumericCharacters="0" 16: passwordAttemptWindow="10" 17: passwordStrengthRegularExpression="" 18: /> 19: </providers> 20: </membership> 21: 22: <!-- role provider --> 23: <roleManager enabled="true" defaultProvider="[B]AcAspNetSqlRoleProvider[/B]"> 24: <providers> 25: <add name="[B]AcAspNetSqlRoleProvider[/B]" 26: type="System.Web.Security.SqlRoleProvider, System.Web,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 27: connectionStringName="[B]AcSqlConnString[/B]" 28: applicationName="/" 29: /> 30: </providers> 31: </roleManager>
[/CODE]
There are a few things you should take note of from the above code (marked in bold). First, note the [B]name[/B] and [B]connectionString[/B] attribute for the providers. When you install the .NET Framework 2.0, default connection strings and providers are specified in the [COLOR=#ff0000][FONT=Courier New]machine.config[/FONT][/COLOR] file (located in the [COLOR=#ff0000]%windir%\Microsoft.NET\Framework\v2.0.5027\CONFIG[/COLOR]). You want to make sure you use unique names here and not the names that Microsoft has included as the default names in the [COLOR=#ff0000][FONT=Courier New]machine.config[/FONT][/COLOR] file. If you elect to reuse their names, you'll need to explicitly remove each one by name (via the [COLOR=#ff0000]<remove />[/COLOR] node) or clear all predefined connection strings and providers (via the [COLOR=#ff0000]<clear />[/COLOR] node). To make it easy, I specified unique names, as indicated in bold.
With everything configured, launch the ASP.NET 2.0 Web administration site from within Visual Studio 2005: [B]Website[/B] -> [B]ASP.NET Configuration[/B]. When the site loads, the first order of business is to switch it from Integrated Authentication to Forms Authentication. To do this, select the [B]Security[/B] link and then select the [B]Select Authentication Type[/B] link in the [B]Users[/B] container. If it isn't selected already, make sure [B]From The Internet[/B] (aka: Forms Authentication) is selected and click [B]Done[/B].
[B]Create A User[/B]

Next, we need to add a user that we'll later use for testing. Select [B]Security[/B] again and then select [B]Create User[/B]. I'm going to create a new user with the [B]User Name[/B] of [B]andrewconnell[/B] and [B]Password[/B] of [B]password[/B]. Note I don't have to enter a strong password because of some of the settings I changed in the membership provider in the code above. The [B]E-mail[/B] address isn't important, so I'll just enter [B]andrewconnell@foo.com[/B] and click [B]Create User[/B]. Finally, let's make sure the markup in our [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] file is correct for our membership and role provider. To do this, select the [B]Provider[/B] tab and then select [B]Select a Different Provider For Each Feature (Advanced)[/B]. You should see the membership and role provider that we specified in our [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR]. Selecting the [B]Test[/B] link for either should confirm they are successfully talking to the database.
At this point, we now have our ASP.NET 2.0 user and role database store configured. More importantly we should have a good template [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] containing the connection string, membership provider and role provider settings that we can copy from when modifying the [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] files for our SharePoint sites. Now we need some Web applications to configure!
[B]Creating Two Web Applications, One For Each Authentication Mechanism[/B]

We need some sites to configure for authentication right? I mean, that's the point of the article right? Duh!
[B]Creating the [URL]http://extranet[/URL] IIS Web site[/B]

First step is to create a new Web application just like you would any other time. From SharePoint's [B]Central Administration[/B] Web site, select the [B]Application Management[/B] tab, then [B]Create or Extend Web Application[/B] and then [B]Create a New Web Application[/B]. I'm guessing if you're reading this article, you know how to create a new Web application from here… so I'll spare the details, but I want to point out is that I specified the following:
[LIST][*]Set the [B]Description[/B] as [B]SharePoint – Extranet 80[/B][*]Set the [B]Port[/B] to [B]80[/B][*]Set the [B]Host Header[/B] to [B]extranet[/B][*]Picked [B]NTLM[/B] as the [B]Authentication Provider [/B][*]Specified [B]Anonymous Access[/B] to [B]No[/B][/LIST]
After creating the Web application, I then created a new site collection in the Web application naming the site [B]Acme[/B] and picking the [B]Publishing Portal[/B] site template. If you're having problems and want to see exactly what I selected, you can view [URL="http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-3.gif"]Figure 3[/URL] displaying the [B]Create New Web Application[/B] page or [URL="http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-4.gif"]Figure 4[/URL] displaying the [B]Create Site Collection[/B] page.
At this point we now have a site, configured for [B]Windows Authentication[/B], named [B]ACME[/B] at [B][URL]http://extranet[/URL][/B]. This is the site our content owners will use to authenticate using their Active Directory corporate accounts in order to add, edit, and manage the content on our Publishing site. Make sure everything is working by browsing to the [URL]http://extranet[/URL] Acme site. You should see the Welcome control and the Site Actions menu in the upper right-hand corner of the page. [I]Assuming everything is working, we have now satisfied the first goal listed in the introduction above! [/I]
[B]Creating the [URL]http://internet[/URL] IIS Web site[/B]

Now we need to extend our Web application to another IIS Web site. This is the site our anonymous, or Internet users, will use to access the site. This site will need to be available to anonymous users as well as provide a mechanism for them to authenticate against, via Forms Authentication, in order to access restricted areas of the site (such as a member's only section). To extend the Acme Web application to another IIS Web site, from SharePoint's [B]Central Administration[/B], select the [B]Application Management[/B] tab, then [B]Create or Extend Web Application[/B] and then [B]Extend an Existing Web Application[/B]. Again, I'll spare you from the details and highlight only a few important points on this page:
[LIST][*]Make sure you select the Web application you want to extend… in our case we want [B]SharePoint – Extranet 80[/B]. Use the Web Application selector at the top of the page to pick the correct application.[*]Set the [B]Description[/B] as [B]SharePoint – Internet 80[/B][*]Set the [B]Port[/B] to [B]80[/B][*]Set the [B]Host Header[/B] to [B]internet[/B][*]Picked [B]NTLM[/B] as the [B]Authentication Provider [/B][*]Specified [B]Anonymous Access[/B] to [B]No[/B][*]Set the [B]Load Balanced URL Zone[/B] to [B]Internet[/B][/LIST]
[I]We'll enable anonymous access later.[/I] Again, if you are having problems, you can see exactly what I selected from [URL="http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-5.gif"]Figure 5[/URL]. Now we have a site that we can configure for our Internet users to access anonymously and also login via Forms Authentication. However, before we do that, there are a few configuration tasks we have to do.
[B]Configure The Web Applications To Communicate With The ASP.NET 2.0 Forms Authentication Data Store[/B]

Once you have a Web application created that will host a site, you will need to change its authentication provider to not use Windows Authentication but instead use Forms Authentication as well as configure the site so it can communicate with our user and role data store… the [B]AcAspNetDb[/B] we created earlier. To do this, we'll use the connection string, membership provider, and role provider we created and already tested in our utility Web site's [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] file.
[B]Configure [URL]http://extranet[/URL] & [URL]http://internet[/URL][/B]

First, we'll modify the two IIS Web sites ([B][URL]http://extranet[/URL][/B] and [B][URL]http://internet[/URL][/B]) [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] files to include the connection string, membership provider, and role provider information so they can both communicate with our user and role store. It's obvious why the [B][URL]http://internet[/URL][/B] site would need these changes, but why make them to the [B][URL]http://extranet[/URL][/B] site when we're going to use it for Forms authentication? If we didn't, it would be somewhat difficult and inconvenient (but not impossible) when we needed to grant any special permissions in the Acme Web application to one of the users or roles in our data store. This way, one of our content owners can authenticate using his/her Active Directory credentials and still grant a user who will authenticate via Forms Authentication access within the site. Open the [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] file for the [B][URL]http://extranet[/URL][/B] Web site, found in the following directory (if you let SharePoint specify the Web site root directory... otherwise, retrieve it from your specified path): [COLOR=#ff0000]c:\Inetpub\wwwroot\wss\VirtualDirectories\extranet80[/COLOR]. Add the [COLOR=#ff0000]<connectionStrings>[/COLOR] node, listed above, just after the closing [COLOR=#ff0000]</SharePoint>[/COLOR] tag and opening [COLOR=#ff0000]<system.web>[/COLOR] tag. Then add the membership and role provider markup, listed above, just after the opening [COLOR=#ff0000][FONT=Courier New]<system.web>[/FONT][/COLOR] tag and save your changes. Do the same thing for the [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] for the [B][URL]http://internet[/URL][/B] Web site, found here: [COLOR=#ff0000]c:\Inetpub\wwwroot\wss\VirtualDirectories\internet80[/COLOR].
[B]Configure SharePoint Central Administration[/B]

Now both Web applications are configured to communicate with the data store. There's one last step we have to do… we need to add the same information to the SharePoint's [B]Central Administration[/B] Web site's [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] file. Why? We need to make sure the [B]Central Administration[/B] Web site can communicate with the data store in case we want to do any security management of the users and roles in the data store such as configuring policies for the Web application. Repeat the steps above for the [B]Central Administration's[/B] [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] which should be found here: [COLOR=#ff0000]c:\Inetpub\wwwroot\wss\VirtualDirectories\[#####][/COLOR]. You need to make one small change… change the [B]defaultProvider[/B] attribute on the [COLOR=#ff0000][FONT=Courier New]<roleManager>[/FONT][/COLOR] node to [B]AspNetWindowsTokenRoleProvider[/B]. This is necessary because Central Administration still uses Windows Authentication for the role provider. The [COLOR=#ff0000]<roleManager>[/COLOR] node for the Central Administration's [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR] should look like this:
[CODE] 1: <!-- role provider --> 2: <roleManager enabled="true" defaultProvider="[B]AspNetWindowsTokenRoleProvider[/B]"> 3: <providers> 4: <add name="[B]AcAspNetSqlRoleProvider[/B]" 5: type="System.Web.Security.SqlRoleProvider, System.Web,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 6: connectionStringName="[B]AcSqlConnString[/B]" 7: applicationName="/" 8: /> 9: </providers> 10: </roleManager>
[/CODE]
Now we're finally ready to configure the [B][URL]http://internet[/URL][/B] site for Forms Authentication!
[B]Enabling Forms Authentication On One Web Application[/B]

Flipping the switch to Forms Authentication is very simple… it's just all the prep work that's the complicated part. Browse to SharePoint's [B]Central Administration[/B] Web site, select the [B]Application Management[/B] tab, and then select [B]Authentication Providers[/B]. First, ensure you are working with the correct Web application by checking the selector in the upper right-hand corner of the [B]Authentication Providers[/B] page (as shown in Figure 6). Once you're on the correct Web application, select the [B]Internet[/B] zone link (as shown in Figure 6).
[CENTER][IMG]http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-6.gif[/IMG]
[I]Figure 6 – Authentication Providers page[/I] [/CENTER]
[I]Note that even though we've selected the [B][URL]http://extranet[/URL][/B] Web application, we are really modifying the [B][URL]http://internet[/URL][/B] IIS Web site because that's the one mapped to the [B]Internet[/B] zone. [/I]
On the [B]Edit Authentication[/B] page, we are going to change the [B]Internet[/B] zone for the [B][URL]http://extranet[/URL][/B] Web application to the following settings:

[LIST][*][B]Authentication Type[/B]: Forms[*][B]Enable Anonymous Access[/B]: checked[*][B]Membership Provider Name[/B]: AcAspNetSqlMembershipProvider[*][B]Role Manager Name[/B]: AcAspNetSqlRoleProvider[/LIST]
Notice that the names of the [B]Membership Provider Name[/B] and [B]Role Manager Name[/B] are the names of the providers we entered in the [COLOR=#ff0000][FONT=Courier New]web.config[/FONT][/COLOR]'s. Now you see why we had some pre-configuration work to do before we actually made the switch. Refer to [URL="http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-7.gif"]Figure 7[/URL] to see all settings I selected on the [B]Edit Authentication[/B] page.
We now have two different ways for users to get to our Acme Web application:

[LIST][*]Via [B][URL]http://extranet[/URL][/B], authenticating using Windows Authentication (using their Active Directory credentials)[*]Via [B][URL]http://internet[/URL][/B], anonymously or authenticating using Forms Authentication[/LIST]
Ah.. but we're not quite finished. Even though the [B][URL]http://internet[/URL][/B] Web site is now configured to allow anonymous users, the Acme Web application has not been set to grant permission for anonymous users to browse the site. You can prove this by trying to browse to [B][URL]http://internet[/URL].[/B] You'll immediately get redirected to the default SharePoint Forms Authentication [B]Sign In[/B] page, as shown in Figure 8.
[CENTER][IMG]http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-8.gif[/IMG]
[I]Figure 8 – SharePoint's default Forms Authentication Sign In Page[/I] [/CENTER]
Let's prove that the Forms Authentication is actually working with our data store. First we need to add our user to the site. To do this, browse to the [B][URL]http://extranet[/URL][/B] Web site, select [B]Site Actions[/B], then [B]Site Settings[/B], then [B]People And Groups[/B]. Select the [B]New[/B] button to add a user to the site. On the [B]Add Users: Acme[/B] page, enter the username of the user we created previously: [B]andrewconnell[/B]. Then click the [B]Check Names[/B] icon (little icon with a blue check just below the [B]Users/Groups[/B] input box… or press [CTRL]+[K]). In the [B]Give Permission[/B] section, select [B]Add Users To A SharePoint Group[/B] and select [B]Acme Visitors [Read][/B] and finally click [B]OK[/B]. We've now granted our user access to the site.
To test, open a new browser window and browse to [B][URL]http://internet[/URL][/B]. You should immediately get sent to the SharePoint Sign In page. Enter the account's credentials ([B]andrewconnell[/B]/[B]password[/B]) and click [B]Sign In[/B]. You'll then get signed in and redirected back to the homepage of the site. You can see you're logged in because you can now see the Welcome control in the upper right-hand corner of the site. Notice how you can't see the [B]Site Actions[/B] menu? That's because we only have the rights assigned to [B]Visitors[/B], which means we can't do anything to the site but browse it.
Last step… let's open the site up for anonymous users…
[B]Enabling Anonymous Access[/B]

In order for anonymous users to have access to the Acme Web application and browse the site, we need to turn anonymous access on. In our case though, we only want to turn anonymous access on for the external (or [B][URL]http://internet[/URL][/B]) site. Before we do this, we should create a new account in our ASP.NET 2.0 database that we can use as an administrative account to make changes to our external site. First, create a new account using the same process in the [B]Setting Up ASP.NET 2.0 Forms Authentication User & Role Data Store: Create A User [/B]section above. I'm going to create this account with the following credentials:

[LIST][*][B]Username: [/B]FbaAdmninistrator[*][B]Password: [/B]password[/LIST]
Next, we need to grant this user ownership-level rights to our [B][URL]http://internet[/URL][/B] site. WSS v3 introduces a new capability where we can specify a user to have full control over a site via Web Application policies. These policies trump any permission setting within the site itself. We'll use this to set a policy to grant the FbaAdministrator full control over our [B][URL]http://internet[/URL][/B] site. Browse to [B]Central Administration[/B], select the [B]Application Management[/B] tab, then [B]Policy for Web application[/B] under the [B]Application Security[/B] section. Make sure you've selected the correct [B]Web Application[/B] from the selector in the upper-right corner of the page (in our case, we want to select [B][URL]http://extranet[/URL][/B]). Next, select [B]Add Users[/B] from the toolbar. On the [B]Add Users[/B] page, select the [B]Internet[/B] zone (because this is the zone we specified for our [URL]http://internet[/URL] Web Application) and click [B]Next[/B]. Finally, enter the user [B]FbaAdministrator[/B] in the [B]Choose Users[/B] step, select [B]Full Control[/B] in the [B]Choose Permissions[/B] step, and click [B]Finish[/B]. Now you can login to the [URL]http://internet[/URL] site and have full control over the site, just like the site owners have.
Now we can setup anonymous access for our [URL]http://internet[/URL] site. To do this, browse to the [B][URL]http://internet[/URL][/B] Web site, login using the [B]FbaAdministrator [/B]account we just created and configured, select [B]Site Actions[/B], then [B]Site Settings[/B], then [B]Modify All Site Settings[/B]. On the [B]Site Settings[/B] page, select [B]Advanced Permissions[/B]. On the [B]Permissions: Acme[/B] page, select [B]Settings[/B], and then select [B]Anonymous Access[/B] (see Figure 9). On the [B]Change Anonymous Access Settings: Acme[/B] page, select [B]Entire Web Site[/B] and click [B]Ok[/B].
[CENTER][IMG]http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-9.gif[/IMG]
[I]Figure 9 – Anonymous Access menu option on the Permissions Settings menu[/I] [/CENTER]
To test, open a new browser window and browse to [B][URL]http://internet[/URL][/B]. You should go straight to the Web site as an anonymous user! You can tell you aren't signed in because there's a [B]Sign In[/B] link in the upper right-hand corner of the site where the [B]Welcome[/B] control usually is. [I]We have now satisfied the second goal listed in the introduction above! [/I]
[B]Configuring A Section Of the Site For Authenticated Users Only[/B]

Our last goal was to configure a section of the site so that users must be authenticated to have access to that section's, or site's, content. To do this, we'll have to go back into our site as through the [B][URL]http://extranet[/URL][/B]. Because the site is now set up for anonymous access, you won't automatically be signed in, so you'll have to click the [B]Sign In[/B] link in the upper right-hand corner. Because we created the site using the Publishing Portal template, there's a subsite named Press Releases in our site collection.
Let's make it so this site requires the user to login. Select [B]Site Actions[/B] and then [B]Manage Content and Structure[/B]. On the [B]Site Content and Structure[/B] page, select [B]Press Releases[/B] from the left-hand navigation tree and then select [B]Advanced Permissions[/B] (see Figure 10).
[CENTER][IMG]http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-10.gif[/IMG]
[I]Figure 10 – Press Releases Advanced Permissions[/I] [/CENTER]
Next, we'll break the permission inheritance with the parent site and then remove anonymous access to the Press Releases site. First, select [B]Actions[/B] and then [B]Edit Permissions[/B]. You'll be prompted to accept your changes… select [B]OK[/B]. Next, [B]Select Settings[/B], then [B]Anonymous Access[/B], then on the [B]Change Anonymous Access Settings[/B] page, select [B]Nothing[/B] and click [B]OK[/B].
Now let's test it… open a new browser window and navigate to [B][URL]http://internet[/URL][/B]. Notice how the Press Releases section isn't on the horizontal navigation (see Figure 11)? Now sign in using the [B]Sign In [/B]link in the upper right-hand corner and watch how the Press Releases section now appears since we're authenticated (see Figure 12)! We have now satisfied the third goal listed in the introduction above!
[CENTER][IMG]http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-11.gif[/IMG]
[I]Figure 11 – Unauthenticated User With Press Releases Site Hidden[/I] [/CENTER]
[CENTER][IMG]http://www.andrewconnell.com/blogcontent/HOWTO-WcmDualAuthProvider/figure-12.gif[/IMG]
[I]Figure 12 – Authenticated User With Press Releases Site Visible[/I] [/CENTER]
[B]Conclusion[/B]

In this article I have demonstrated how you can create a Publishing Site in MOSS 2007 and configure it for two types of authentication and at the same time allow anonymous users to browse the site. So where would you go from here? Some possible next steps would include creating a self-registration system for users to create their own accounts and have these accounts automatically registered on the site under a specific role so no additional management action is required by the site owners.
[B][COLOR=#ff0000][Update 3/28/2007]: [/COLOR][/B]Make sure you check out Tony Starr's post on the Sharepoint Team Blog ([URL="http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx"]part 1[/URL] & [URL="http://blogs.msdn.com/sharepoint/archive/2007/03/19/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-2-of-3.aspx"]part 2[/URL]). Also, as you can see from the comments on this post, many people think MySites are broken when you use FBA. [URL="http://devcow.com/blogs/jdattis"]Dan Attis[/URL] has a great write up on how to get MySites working with FBA here. Make sure you check it out ([URL="http://devcow.com/blogs/jdattis/archive/2007/02/23/Office_SharePoint_Server_2007_Forms_Based_Authentication_FBA_Walkthrough_Part_1.aspx"]part 1[/URL] & [URL="http://devcow.com/blogs/jdattis/archive/2007/03/01/Office_SharePoint_Server_2007_Forms_Based_Authentication_FBA_w_MySites_Walkthrough_Part_2.aspx"]part 2[/URL]). The issue deals with the fact you probably don't have a profile provider setup.
[[B][COLOR=#ff0000]Update 5/1/2008 @ 730a[/COLOR][/B]]: I now have a Visual How To screencast on MSDN that demonstrates this same process: [FONT=Arial]http://msdn2.microsoft.com/en-us/library/cc441429.aspx[/FONT]

[/LEFT]