As promised, here is part 2 of my series on hooking up Forms based authentication on a SharePoint 2007 site AND integrating your web application with MySites and the Personalization features of Office SharePoint Server 2007.
I am going to assume that you have read and gone through all of the steps in part 1 of the series. The steps below ARE dependent on part 1 and I will be making some references to it. If you have not gone through part 1, I encourage you to read this entire post before trying to implement the solution. There are quite a few caveats and very UNINTUITIVE steps. Since none of this is documented (to my knowledge), I have to say that since it is undocumented, it may be unsupported as well. What I can say for certain, that in my 2 or 3 support calls to Microsoft regarding this issue, I had given up on them helping me. Essentially I was told on more than one occasion that "it's not supposed to work" or "it does not work". Of course after those answers, I had to prove to myself that either it does work or support was right. They do after all claim that this is "pluggable" authentication, and other than the obvious features, like Office integration, or SharePoint Designer integration, I expected all of the functionality to work. The following is the fruit of my labor. As a side note, this effort, although it may seem simple after you go thru the steps, took me about 5 weeks of nights and weekends trying to get the sequence of steps and the steps themselves defined.
One major disappointing caveat is MySite search. Search works fine against the FBA site to which we have a "mirror" intranet version, like we do in our example, but unfortunately we do not have a Windows authentication version of each and every MySite. I guess we could, technically, but really, that's not going to happen. I have heard however, through a very reliable source that Microsoft is working VERY VERY hard on getting the SharePoint search crawler to be able to penetrate forms based authentication sites and just maybe, might have a solution in Q2. I am optimistic about this and can't wait, then we really have a fully searchable FBA solution.
So here goes...
Assumptions
Like any good assumer, I am going to list all of my assumptions here. If you think that anything is missing, please do let me know and I will update this list.
- You have created and configured a Shared Services Provider (SSP) and can link to its setting page using either of the following two methods.
- Click on the Share Services Provider's link in the left navigation in Central Administration.
- Click on the Create or configure this farm's shared services link in the Office SharePoint Server Shared Services section of the Application Management tab in Central Administration, then select Edit Properties from the dropdown menu that appears when you hover over its name.
- The SSP Administrative Site URL and the MySite Location URL are each on their own web applications.
It is possible and sometimes desirable for some to locate their MySite site collections within the same Web Application of the site to which they are associated. What I mean by this is that there are two very different ways in which to setup MySites and they are as follows. Let's pretend for the sake of conversation, that our site is www.microsoft.com.
Method #1 - The site www.microsoft.com is its own Web Application. In turn, www.microsoft.com/mysite is where the MySites site collection is located. The main benefit to this design is that since we are using FBA as our authentication method, the same cookie will work for both sites and we will not have to log into our MySite independently of logging into the main site. The main drawback is that MySites will now be created in the same content database(s) that the www.microsoft.com Web Application is using. This may be an issue when it comes to scaling and capacity planning. Chris Johnson has outlined the steps needed to produce this scenario here.
Method #2 - The site www.microsoft.com is its own Web Application. In turn, my.microsoft.com is where your MySites site collection is located. The main benefit to this is that MySites are stored in a separate Web Application and can be managed independently. The main drawback is that since we are using FBA as out authentication method, we will have to log into our MySite separately, the cookie will not be shared.
Microsoft's best practice dictates that you use Method #2, so that is what I have done in my walkthrough.
- As indicated above, for the purpose of this post, my SSP Administrative Site URL is http://ossdev:23456/ssp/admin.
- As indicated above, for the purpose of this post, my MySite Location URL is http://ossdev:23457.
- You will NOT access the URL in the previous bullet until instructed to do so. This has the potential to create problems, so please resist the urge.
- You will NOT click on the MySite link until instructed to do so. This also has the potential to create problems, so please resist the urge.
Update the Shared Service Provider Administrative Site's web.config File
The web.config file of the Shared Service Provider needs to be updated with the same information you placed into the web.config of your FBA web application.
Determine File Path to web.config.
- Open Internet Information Services (IIS) Manager.
- Expand Web Sites and select the Shared Service Provider's website, in my case, SharePoint_SSP_Default1 - 23456. Yours will most likely be different so be sure you select the right site.
- Right click on the above website and select Properties.
- Select the Home Directory tab.
- In the Local path textbox take note of the entire string. This is the folder on the file system that contains the web.config for the http://ossdev:23456/ssp/admin web application. We will be updating this file next.
- Open Windows Explorer and browse to the folder noted in step 5.
- Make a backup copy of the web.config file.
Add Connection String
- Add the following connection string snippet immediately above the <system.web> tag. Be sure to replace the bolded text with the appropriate values from your environment.
<connectionStrings>
<add name="AspNetDbFBADemoConnectionString" connectionString="Data Source=OSSDEV;Initial Catalog=AspNetDb_FBADemo;Integrated Security=True" />
</connectionStrings>
Add Providers
- Add the following membership provider and role manager elements immediately inside the <system.web> element. Again, be sure to replace the bolded text with the appropriate values from your environment.
<!-- membership provider -->
<membership defaultProvider="FBADemoMember">
<providers>
<add
connectionStringName="AspNetDbFBADemoConnectionString"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
applicationName="/"
requiresUniqueEmail="false"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
name="FBADemoMember"
type="System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>
<!-- role provider -->
<roleManager enabled="true" defaultProvider="FBADemoRole">
<providers>
<add
connectionStringName="AspNetDbFBADemoConnectionString"
applicationName="/"
name="FBADemoRole"
type="System.Web.Security.SqlRoleProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>
- Save and close the web.config file.
- Perform an IISReset and verify that you can still access the SSP.
Update the MySite Host Web Application's web.config File.
The web.config file of the MySite Host Web Application needs to be updated with the same information you placed into the web.config of your FBA web application.
Determine File Path to web.config.
- Open Internet Information Services (IIS) Manager.
- Expand Web Sites and select the MySite Host website, in my case, SharePoint_MySite_Default1 - 23457. Yours will most likely be different so be sure you select the right site.
- Right click on the above website and select Properties.
- Select the Home Directory tab.
- In the Local path textbox take note of the entire string. This is the folder on the file system that contains the web.config for the http://ossdev:23457 web application. We will be updating this file next.
- Open Windows Explorer and browse to the folder noted in step 5.
- Make a backup copy of the web.config file.
Add Connection String
- Add the following connection string snippet immediately above the <system.web> tag. Be sure to replace the bolded text with the appropriate values from your environment.
<connectionStrings>
<add name="AspNetDbFBADemoConnectionString" connectionString="Data Source=OSSDEV;Initial Catalog=AspNetDb_FBADemo;Integrated Security=True" />
</connectionStrings>
Add Providers
- Add the following membership provider and role manager elements immediately inside the <system.web> element. Again, be sure to replace the bolded text with the appropriate values from your environment.
<!-- membership provider -->
<membership defaultProvider="FBADemoMember">
<providers>
<add
connectionStringName="AspNetDbFBADemoConnectionString"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
applicationName="/"
requiresUniqueEmail="false"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
name="FBADemoMember"
type="System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>
<!-- role provider -->
<roleManager enabled="true" defaultProvider="FBADemoRole">
<providers>
<add
connectionStringName="AspNetDbFBADemoConnectionString"
applicationName="/"
name="FBADemoRole"
type="System.Web.Security.SqlRoleProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>
- Save and close the web.config file.
- Perform an IISReset and close all your browser windows, but DO NOT try and access this URL yet.
Assign FBA Admin User Personalization services permissions.
Remember in part 1, we created a handful of FBA users. One of those users (spadmin) was created to be used as an administrator for our FBA site. We are going to re-use that user here to manage the SSP once we "flip" it to Forms Authentication. Yes, that's right, we are going to switch the authentication method of our SSP Administration site to Forms! How else did you think it would wok with FBA users? Ideally, you should probably go and create another user for this, maybe sspadmin or something similar.
- Browser to your SSP Administration Site.
- Click on Personalization services permissions in the User Profile and My Sites section.
- Click on the Add Users/Groups link.
- Type spadmin into the Users/Groups textbox and click the Check Names button
, watch SharePoint resolve the user, then check all of the permissions and click Save. This will ensure that when we make the switch to Forms Authentication on the SSP site, that our FBA admin user will actually be able to perform the operations listed here.
- Perform an IISReset and close all your browser windows.
Switch Authentication Providers for SSP and MySites
- Click on the Authentication providers link in the Application security section on the Application Management tab in Central Administration.
- Verify that the SSP Web Application is selected in the Web Application dropdown in the top right hand corner of the page.
- Click on Default.
- Select Forms as the Authentication Type, and enter the appropriate values for the Membership provider name and the Role manager name as they exist in this web application's web.config, then click OK.
- Perform steps 1 to 4 again for the MySite Web Application.
Update Site Collection Administrator for SSP and MySites
We now need to update the Site Collection Administrators of the SSP and MySite host so we can go make some more changes.
- Click on the Site collection administrators link in the SharePoint Site Management section of the Application Management tab in the Central Administration.
- Switch the Site Collection dropdown to the SSP admin Site Collection. Remember, you may have to switch the Web Application to get the correct list of Site Collections (this is done in the popup). I know of some people who are not too fond of this user interface, myself included). Notice that since we switched the Authentication Type of our SSP to Forms, we will see a squiggly under the Windows account that was previously the Site Collection Administrator.
- Delete the squigglied name (is that a word?) and replace it with spadmin, the FBA admin user we discussed earlier. Click the Check Names button
and watch SharePoint resolve the FBA admin user, then click OK.
- Repeat steps 1 to 3 for the MySite Host Site Collection.
Assign My Site Host Permissions to FBA Users
The following steps were the most unintuitive steps ever, in my opinion, and if anyone can tell me why it is required for FBA/MySite integration, but not for Windows/MySite integration I would love to know. That said, here are the steps.
- Browse to your SSP Administration site.
- You will be prompted with the standard out of the box FBA login form. Log in as spadmin.
- Click on the My Site settings link in the User Profiles and My Sites section on the SSP Home page.
- Click on the My Site Host Permissions link in the loft navigation.
- You will be prompted with the standard out of the box FBA login form. Log in as spadmin. You will be directed to the People and Groups page.
- Click on the Site Permissions link in the left navigation.
- Click on Add Users under the New menu item.
- Add the 3 roles we created in part 1, Administrator, Manager and Employee. Ideally we would have created a role that holds all of the FBA users (maybe call it Everyone). Had we done that in part 1 (we did not and I apologize), we would only have had one role to add here and so long as we always assigned new users to the Everyone role we would never have to come to this page again. As it stands now, if we were to create another user and place them in a new role, they would not be able to create a MySite. I think you get my drift here. Give them Read permission directly and click OK.
Actually, doing this doesn't actually give users permission to create a MySite, but permission to use the MySite Host site should they already have the permission to create a MySite. The next section will grant users permission to create MySites.
- Close all your browser windows.
Grant Personalization Services Permissions
The next set of steps, as mentioned above is to grant our FBA users the appropriate permission to allow them to create MySites and use the personalization features of Office SharePoint Server 2007.
- Browse to your SSP Administration site.
- You will be prompted with the standard out of the box FBA login form. Log in as spadmin.
- Click on the Personalization services permissions link in the User Profiles and My Sites section of the SSP Home page.
- Click on the Add Users/Groups link.
- Type Administrator;Manager;Employee into the Users/Groups textbox and click the Check Names button , watch SharePoint resolve the roles, check only the Create personal site and Use personal features permission, and click Save. This grants these roles the permission to create a MySite and to use the personalization features.
- Your screen should resemble the following screen shot.
- Perform an IISReset and close all your browser windows.
Assign Roles to Default Reader Site Group
Ideally, we don't want users to have to assign other users Read permission just to view the public areas of their MySites. When using Windows authentication, the default is to allow all authenticated users to read other users MySites. Such a group does not exist when using FBA. Had we created some sort of Everyone role, as suggested earlier in this post, in part 1 of the series, we could have leveraged that role, however, since we did not, we will have the same scenario as before manifest itself should we decide to add a new role in the future, after making the following changes. So lesson learned #1 would be to create an Everyone role in your role manager and place all of your users in it.
- Browse to your SSP Administration site.
- You will be prompted with the standard out of the box FBA login form. Log in as spadmin.
- Click on the My Site Settings link in the User Profiles and My Sites section on the SSP Home page.
- Scroll down to the Default Reader Site Group section and type or append Administrator; Manager; Employee into the textbox. You can leave NT AUTHORITY\authenticated users in the textbox or remove it, it does not matter at this point, then click OK.
- Close all your browser windows.
Test You Solution!
Remember, I made allot of assumptions at the beginning of this post. One of those assumptions was that you had completed part 1 of this series. Under the assumption that you have completed part 1, test your solution using these steps.
- Browse to http://fbaextranet.attis.org and first login as spadmin. You should see a My Site link in the top right hand corner of the page. DO NOT CLICK ON IT YET.
- Verify that the Employee role is in the pre-created Visitor SharePoint group and that the Manager role is in the pre-created Member SharePoint group (I have to assume you know how to do this!).
- As I mentioned earlier, since we set our My Site Host site collection up on a separate Web Application than our website, we will need to log to our My Site independently of this site. You may now click on the My Site link!
- Login as spadmin and watch the MAGIC!
- Check it out!
- Close your browser, open a new one and browse to http://fbaextranet.attis.org again.
- Login as Employee1. You should see a My Site link in the top right hand corner of the page. Remember, this user was created in part 1. Click on the My Site link, logon as Employee1 and again, watch the MAGIC!
Caveats
Of course, this solution has a couple of caveats. The biggest issue I have come across is Search. At present time, the crawler simply cannot deal with Forms Authentication yet. This is not a problem for the main website as the crawler simply enters through another zone. The following TechNet article explains how the crawler interacts with multiple zones and authentication modes in great detail. I encourage you to read it. With that said, MySite Search does not work OOB (I say OOB because I am sure someone will come up with a clever solution at some point) because all of the MySites lie behind Forms Authentication.
Now go forth and integrate your Forms Authentication Solutions with MySites and your SSP's. it will be interesting to see if there is going to be a supported or documented solution put forth by Microsoft. I guess we will just have to wait and see!