PLEASE NOTE: this is a personal notepad while TESTING IS COMPLETED. Review the links to become familiar with the concepts. Commentary to follow when Patterns and Practices have been validated.

work in progress…. thanks

Forms Based Authentication in SharePoint – WSS 3.0 and MOSS 2007

Welcome,

In general there is a lot of information on this subject on the Internet. Much of the information however is written presuming a pre-existing foundation of knowledge about ASP.NET, connectionStrings and the like. It’s my hope to fill in the blanks here. The following outline is written to help you (and me) find our way to the best resources available on FBA in SharePoint as well as to educate those interested in SharePoint on the broader subject of Forms Based Authentication for ASP.NET and how it applies to WSS 3.0. I hope you have great success with your own effort!

Questions to consider before implementing FBA (Forms Based Authentication) in SharePoint

1. Are you working on a single machine or in a Server Farm?
2. Are you using SQL 2005 Express or SQL Server 2005 / 2000 as your membership database?
3. If building your own Authentication Page, which AspNetSqlMembershipProvider elements will make use of ?

Consider these and other questions in advance of your study as they will influence the procedure(s) that you develop.

= = = = = = = = = = = = = = = = = = = = =

SharePoint Community on Forms Based Authentication and Membership in SharePoint (WSS 3.0 and MOSS 2007)

BLOG POSTS: The SharePoint community on Forms Based Authentication

The most acknowledged posts (with screenshots) on FBA (Forms Based Authentication) for WSS 3.0. START here to learn FBA and AspNetSqlMembershipProvider as the experts have applied it to SharePoint.

• Steve Peschka – Configuring Multiple Authentication Providers for SharePoint 2007
• Andrew Connell – HOWTO: Configuring a Office SharePoint Server 2007 Publishing Site with Dual Authentication Providers and Anonymous Access
• Harshawardhan Chiplonkar – Forms Based Authentication in MOSS
• Nick Swan – SharePoint 2007 Forms Authentication

WEBCASTS & VIDEOS on FBA in SharePoint

Two comprehensive walkthroughs on setting up Forms Based Authentication in SharePoint

• Ted Pattison Anonymous Access and Forms Authentication in WSS
• TechNet Webcast SharePoint Security from Service Accounts to Item-Level Access (Level 200) (ID:1032305446)
  • POST EVENT RESOURCES: Downloads: 3 items including a downloadable FBA walk-through

  My opinion on the Ted Pattison VIDEO: This Channel 9 video is the most comprehensible and thorough presentation on Forms Based Authentication specifically for SharePoint I’ve seen. The presenter is Ted Pattison (MVP/author and outstanding teacher on the subject). Ted makes the difference by teaching while he presents. Thanks Ted!

  • The FBA WSS 3.0 video is here: http://channel9.msdn.com/ShowPost.aspx?PostID=229709
  • More great SharePoint videos from Ted are here on MSDN: The Office Developer Screencast Virtual Tour
    

    NOTE: There is a step in Ted’s presentation in which he edits the machine.config file and enters connectionStrings to globally direct ALL web applications on his demo box to the aspnetdb SQL database created for forms authentication.??? This is solely an ASP.NET edit! COMMENT: If I understand this correctly, this step makes the most sense only if you’re using one single machine. If Central Administration were moved to a new box, the connectionStrings would be left behind in the machine.config file on the old box and connection to the data store would be lost. SharePoint Configuration Wizard has the ability to relocate Central Administration from machine to machine. In a farm environment it would be better to edit the web.config file for SharePoint Central Administration because the web.config file could then be provisioned again, along with Central Administration itself, using the SharePoint Configuration Wizard. Pushing functionality to new boxes may occur in a Server Farm Environment. In addition, there is backup to consider. Backing up Central Administration does not backup machine.config but does backup the web.config file because it’s a part of Central Administration. Backup is another reason to edit the web.config file instead of machine.config and applies to stand alone SharePoint installations as well as Server Farms. Insure backup of your connectionString elements so that they’ll always be there with Central Administration and your web applications in a backup.

= = = = = = = = = = = = = = = = = = = = =

The ( _blanks_ ) in current posts on FBA and SharePoint

There are some definite BLANK SPOTS in even the best of the current FBA walkthroughs I’ve found. While many of these guides are outstanding (and have definitely lead the way for all of us) I feel the SharePoint community is somewhat taking for granted the knowledge of it’s users especially given the drive to communicate the appeal of Windows SharePoint Services to a broader audience. Be prepared to bring yourself up to date on the following subject matter. I found these to be the missing links in my study of FBA for SharePoint. I suggest reading this information before you begin:

1. aspnet_regsql.exe – what to consider using SQL (Express/Server 2000/Server 2005) with FBA in ASP.NET (WSS 3.0)
   • ScottGu – Forms Authentication in SQL 2000 and SQL Server 2005
   • ScottGu – Security Issues and more… Try not to get lost here! Scott links a lot of stuff on membership, roles, security, etc…
2. Security – Grant database access to the SQL Server Instance used by WSS 3.0 Web Application account
   • MSDN – How To: Use Forms Authentication with SQL Server in ASP.NET 2.0
   • MSDN – Accessing SQL Server from a Web Application
3. connectionStrings – connecting SharePoint to SQL Server for Forms Based Authentication
   • MSDN - How to: Access SQL Server Using Predetermined Credentials
   • MSDN - connectionStrings Element (ASP.NET Settings Schema)
   • TechNet- connectionStrings (Authentication Samples)
4. connectionStrings – encryption and security so your credentials are not in the open
   • Scott Mitchell - Encrypting Configuration Information in ASP.NET 2.0 Applications
   • MSDN - How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0
5. MembershipProvider – insuring membership functionality for the future (it makes the difference)
   • ScottGu - Always set the “applicationName” property when configuring ASP.NET 2.0 Membership and other Providers
   • MSDN SharePoint Blogs – SEARCH the term “membership” – should give latest content
6. SharePoint Security specifics – read this last (a large volume of links specifically on SharePoint secuity)
   • Joelo- Security, Compliance, Server Hardening, and IP Protection
   • Future Content – future content…

= = = = = = = = = = = = = = = = = = = = =

TROUBLESHOOTING TIPS

How troubleshooting from the start makes for a winning effort and confirms each step in the FBA process. Please note these procedures are unofficial, imply no warranties and convey no rights.

Troubleshooting – Forms Based Authentication for SharePoint WSS 3.0 and MOSS 2007

Troubleshooting access to your SQL Server Database for Membership

The bottom line is that setting up FBA in WSS is sometimes not as easy as the community makes it out to be. Harshawardhan Chiplonkar who outlines a number of connectionStrings here puts it this way:

A lot of us who have played with Forms based Authentication with Microsoft Office SharePoint Server 2007 would know, that the steps for setting it up are fairly simple, however, if and when something does go wrong, finding it out is really a mess.

For me personally, the procedure of testing each connectionString while I worked helped me verify my connectivity with the Membership database in SQL before moving to the next step. This essentially banked the winning effort and has definitely proved it’s value to me. Pasting all three sets of connectionStrings at once (as you will see done in demos) does not give an opportunity to observe or isolate a single point of failure. To me, it makes sense to configure and test each link in the chain before racing forward to paste a connectionString in your web application and attempt a logon. For this reason, I suggest the following steps as a guideline to simultaneously troubleshooting and establishing a working Forms Based Authentication in SharePoint:

Note: using the following guideline has enabled me to more consistently succeed at FBA for SharePoint. This ultimately just WORKS!… Following this check by check method has actually reduced my configuration time. Implementing these checks along the way adds little extra effort during setup.

MY PERSONAL METHOD:

1. Install a new separate SQL INSTANCE as your dedicated membership store
2. Run aspnet_regsql.exe either from the command line or in wizard mode to create and provision a databse in your SQL INSTANCE for membership
3. Verify the access you need has been granted to the database itself. Open SQL Management Studio and check the Logins, Users and Security settings in SQL at each node associated with this process (see links at beginning about SQL). Establish access as needed based on the (possibly distinct) needs of:
   • ASP.NET web site that configures and accesses your FBA membership store
   • SharePoint Central Administration (SharePoint community suggests this is seperate account-generally domain admin with dbcreator and sysadmin rights to the SharePoint data store) – a very powerful account capable of accomplishing anything Central Administration needs.
   • Worker Process account for the specific Web Application you intend for FBA (SharePoint community suggests this is least priviledge account – generally domain user)
4. Create the target Web Application for FBA in SharePoint and assign the Worker Process account described above
5. Create -OR- borrow your connectionStrings element
6. Connect ASP.NET web site to SQL DATA STORE via connectionString in web.config
7. TEST – by completing the setup of an Adminstrator account – If it does not work… STOP and complete this step.
8. Connect SharePoint Central Administration to SQL DATA STORE via connectionString in web.config
9. TEST – by using Central Administration to change the target Web Application to the use of Forms Authentcation and the AspNetSqlMembership Provider. Assign the Administrator account in step 7 as site collection administrator. If the name resolves, no waivy red line ~~~~~~~~ under the user name, you are Go. – If it does not work… STOP and complete this step
10. Connect your target Web Application to SQL DATA STORE via connectionString in web.config
11. TEST – by browsing to the appropriate URL for your Web Application and logging on as the Administrator account in step 7 which has been verified to be site collection administrator above in step 9. – if it does not work… STOP and complete this step.
12. Smile

WHY STEP 3 ABOVE IS SO IMPORTANT:

• TechNet clearly outlines the suggested Central Administration, Search Accounts, Crawl and Index Account, and Worker Process Account(s) in this Technical Article
• MSDN outlines how to connect these accounts to SQL Server in this Development Article

THE CONCLUSION IS: “Know your environment!” If the FBA process fails anywhere – IT FAILS HERE… FBA can easily fail due to Login access to SQL resulting from Security/User Permissions in SQL itself. If you are using varying accounts for the servicing of SharePoint (like TechNet suggests), you may have to grant access in SQL to more than once account. Read = > 1. TechNet suggests that the accounts servicing SharePoint are to be different accounts with different privileges!! and yet…. most SharePoint Community posts don’t clearly address the impact of this security guideline on implementing connectionStrings successfully.

SUGGESTIONS IN ESTABLSIHING CONNECTION STRINGS

The connectionStrings mentioned in many blogs outline access based on one of three syntax:

1. uid=DOMAINADMINACCT; pwd=YOURPASSWORD
2. Trusted_Connection=True
3. Integrated Security=SSPI

Take these steps in preparing to implement connectionStrings:

• annotate every account (Central Administration Service Account, Web App Service Account, etc….) you may use (DOMAIN\username) with FBA in SharePoint
• grant the accounts Login access in SQL to the membership data store and then assign them (under Security) as Users in the specific database created by the aspnet_regsql.exe routine
• grant privileges to ddwriter and ddreader to each of those accounts
• note that it is necessary to give the individual Web Application account as well as the Central Administration account aspnet_Membership_FullAccess priviledges under Login > Server Roles
• Lastly, whatever account you are logged in under at the time your run aspnet_regsql.exe is the account that becomes the dbo (database owner) for the data store you create. That account may not be the same account as Central Administration Service Account and/or your Web Application’s Worker Process Account unless you just happened to have a very blessed convergence of potentiality. This means your going to have to ADD those accounts and grant them priviledges.
• If you are running a Farm, and have secured it in various ways…. you may have to go offline and loosen your security to figure things out.

MSDN Articles are must reads on this subject matter:

1. How To: Use Forms Authentication with SQL Server in ASP.NET 2.0
2. How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0
3. How To: Connect to SQL Server Using SQL Authentication in ASP.NET 2.0

= = = = = = = = = = = = = = = = = = = =

In review :

1. 1. Know your accounts
   2. Get SQL happy with each of the relationships
   3. TEST your connectionStrings at each stage listed above and if you’re having trouble, be thoughtful about the requirements that SQL is placing on access and whether the account that is accessing (i.e Web App Worker Process) actually is allowed to access it.

= = = = = = = = = = = = = = = = = = = =

SUPER-TIP: Here’s a great way to test that your Central Administration and Worker Process accounts are accessing your SQL data store

1. Read this article on FBA with SQL if you need a refresher
2. run aspnet_regsql.exe [remember the account you are logged in under will become the dbo (database owner) for the database you create]
3. Launch Visual Web Developer (as suggested by SharePoint Community) and establish your ASP.NET Application Service Web Site for Forms Based Authentication
4. Paste your connectionStrings into the web.config file for the ASP.NET Application Service Web Site you just created
5. Use the uid=DOMAIN\ADMINACCT; pwd=YOURPASSWORD method of authenticating in your connectionString
6. Build the site
7. Go to the Menu and select Website > ASP.NET Configuration – The web browser will launch opening the ASP.net Web Site Administration Tool
8. Click on the Security (link) or (tab)
9. If you have access, you will make it to the next step. IF NOT, you’ll have to address the issue

• HERE’S THE TIP: Check each account that will be used to access the FBA data store one at a time right from the beginning. Simply run the same procedure described above by launching the ASP.net Web Site Administration Tool and clicking on the Security (link) or (tab) but change your connectionString to reflect the different accounts that will be eventually used by SharePoint..
• Before each attempt, change the account described in uid=DOMAIN\ADMINACCT; pwd=YOURPASSWORD portion to each of the following and be sure to rebuild the site before each login attempt:
  1. The account you will login and launch the ASP>NET Application Service Web Site with
  2. The account used as the main account for SharePoint Central Administration
  3. The account used as the Worker Process account for your target Web Application
• Note that if all three of these accounts allow you to launch and administer the ASP.net Web Site Administration Tool than EACH WILL BE ALLOWED INTO THE SQL MEMBERSHIP DATABASE when the time comes for their respective test and obviously later when your running your SharePoint Web Application.

SUPER-SUPER-TIP: The fact that you are using the ASP.net Web Site Administration Tool is also beneficial for this reason: IF access to the Security (link) or (tab) fails, you will get all sorts of event log type feed back on the error page as to WHY! You will not get this when you try to connect from a SharePoint Web Application or from Central Administration. What you get on failure from the Forms logon page in SharePoint is a Troubleshooting link to the office.microsoft.com help engine. And this is not mature error messaging. At best, you could dig through the Server Event Logs but the ASP.net Web Site Administration Tool error pages give all sorts of meaningful information!

This is great for troubleshooting!

FINAL NOTE:

WINDOWS INTEGRATED AUTHENTICATION: Using the < uid=DOMAIN\ADMINACCT; pwd=YOURPASSWORD > method of authenticating can be let go of in favor of the “blanket” < Integrated Security=SSPI > method once all of the accounts have been authenticated. By using < uid=DOMAIN\ADMINACCT; pwd=YOURPASSWORD > first, you can isolate each account an figure out what’s up! Once all is well and you know each account works, you can allow Windows Intergrated Authentication (aka – Integrated Security=SSPI ) to take over. Windows Integrated Authentication is also a security benefit in that once the individual accounts are working, switching to Windows Ingtergrated Authentication means you are no longer passing login information over the network in the open.

= = = = = = = = = = = = = = = = = = = =

… the information and links above have achieved a working FBA on our SharePoint Farm. I’ll finish the remainder soon.. Thanks.

Content PlaceHolder. New content TBD