Some time ago, a customer requested a clear statement from Microsoft Support regarding
“Office integration with FBA (forms based authentication) and MOSS (SharePoint Server 2007)”
On a Document Library in SharePoint 2007, “versioning and check-out required” has been configured. After modifying documents in word (Office 2003) the expected Pop-Up should appear for which you need to type in for example a comment, some fields etc.
Unfortunately the Pop-Up dialog does not appear by using FBA (forms base Authentication).
Well the answer was quickly found and this is the final status:
No version of the Office clients up to 2003 supports Forms Based Authentication.
The features that are removed/hidden when “Client integration is disabled” should not be expected to work (supported) when forms based authentication is enabled.
See this TechNet page (http://technet.microsoft.com/en-us/library/cc288081.aspx) for a description of “Expected behaviors when client integration is disabled”
With SharePoint portal server 2003 and Office 2003, FBA wasn’t supported at all.
See also the “Microsoft SharePoint Products and Technologies Document: Microsoft Office Programs and SharePoint Products and Technologies Integration – Fair, Good, Better, Best”
However, since Service Pack 2 for Office 2007 and SharePoint Server 2007 it is now possible to use more Office integration features with FBA.
This update can be used with Office 2007 on a computer that is running the Windows XP or Windows Vista operating system. If you are using Windows Vista, you also need to install Service Pack 2 for Windows Vista (see Service Pack 2 for Windows Server 2008 and Windows Vista).
NOTE: If you are using Internet Explorer, these new features require at least version 7.0 or higher.
See more here: The Forms Authentication Integration Update for Office 2007
“When Office SharePoint Server 2007 and Microsoft Office 2007 were first released, the Office client applications such as Microsoft Office Word and Microsoft Office Excel could not directly open a document from a site that was secured with forms authentication. This is because, as explained earlier, a 302 HTTP response code is sent back to the client when it tries to open an item in a site using forms authentication. The Office clients were not able to respond to a 302 response code, and as a result would display the actual forms logon page in the application, instead of the requested document.
An update is available for Office 2007 client applications that allow the applications to process a 302 HTTP response code. The applications that are affected by this update are Microsoft Office Word 2007, Microsoft Office Excel 2007, Microsoft Office PowerPoint 2007 and Microsoft Office SharePoint Designer2007. Because of this update, an Office application can display the forms logon page that is being used for the site in a pop-up dialog box. To do this, the application issues a request to the SharePoint site. The server sends a response that indicates its authentication method is forms authentication, including the location of the logon page that the client should use to authenticate. The Office application then renders the HTML from that logon page and enables the user to enter credentials. The credentials are sent via an HTTP POST back to the server. If the server returns a redirect response for the document that was originally requested, the Office application assumes that the identity is successfully established. It then uses the authorization cookie that the HTTP POST gave it to retrieve the document and any associated metadata, and open the item.”
For further information, please see also this posts: Update on SharePoint forms based authentication(FBA) and Office client
On MSDN: Integrating with the 2007 Microsoft Office System
So this finally means that with office 2003 neither FBA with SharePoint Portal Server 2003 nor with SharePoint Server 2007 is supported.
Full supported is only Office 2007 SP2 and FBA with SharePoint 2007 SP2 and the April cumulative update.
The workaround for “persistent cookies” may be applicable for your scenario but initially supported with “commercially reasonable effort”.
(see also related: Persistent cookies are not shared between Internet Explorer 7 and Office applications in Windows Vista )
Regarding supportability please see also here: http://technet.microsoft.com/en-us/library/cc939965.aspx and here “Professional Support for IT Professionals”: http://support.microsoft.com/directory/factsheets/proitpro.doc
*** Update 2009-11-11 ***
I received several emails and questions which I’ll answer here in summarized:
Hi Tony, Tyler and Daryl,
Regarding your questions:
Q1: If I didn’t understand you wrong then full functionality should be achievable with Office 2007+April Office Cumulative Update and MOSS with FBA?
A1: Using FBA with SharePoint 2007 and Office 2007 means only that it is supported in terms of our support policy when experiencing issues there.
The full office integration might work in certain cases but still not the same as using windows auth. See the comments below for more.
Q2: One Clarification: I have a customer who appears to be using Office 2003 with FBA, and the client side integration features appear
to be working for them (sort of).
“So this finally means that with office 2003 neither FBA with SharePoint Portal Server 2003 nor with SharePoint Server 2007 is supported”
Can I take that as meaning FBA does not work, or is not SUPPORTED with O2003 clients?
A2: With Office 2003 it might work in some cases but it is not supported for break/hotfix requests. Only “best effort support” may offered.
A possible workaround is described in the below article, section The Forms Authentication Integration Update for Office 2007
Q3: Does this mean that with the service packs and April CU that FBA gives the same level of functionality as Windows auth??
A3: See A1 and below excerpts
[…] When you configure a zone to use forms authentication, the Enable Client Integration box is cleared by default. If a zone is configured in this way, the following changes occur in functionality:
Support for remote interfaces is turned off. That includes WebDAV, SOAP, and Microsoft Office FrontPage remote procedure calls (RPC). Some functionality is not available, such as Web folders or the Web services for accessing content in that site.[…]
[…] When operating in this mode, users can still work with documents in SharePoint libraries, but they must right-click items and choose to save a copy to disk. They can then edit and update the document, and then upload it and check it back in when they are finished editing. Some organizations might want to use forms authentication, but also require the same level of integration they get when using Windows authentication. There are a couple of possible workarounds in this scenario, but it is helpful to examine why this limitation exists.
When a user accesses a page on a site protected by forms authentication, the server looks for a valid authentication cookie. If no cookie is found, or if the cookie is not valid, the server redirects the browser to the logon page by using an HTTP 302 status code. At this page, the user is allowed to authenticate by using his or her credentials. After the credentials are validated, the server creates a valid authentication cookie and sends it back to the browser, with the originally requested page.
The browser keeps the cookie in memory and sends it back to the server with every subsequent request to that Web server. With each request, the server checks the validity of the cookie to ensure that it is good (that it has not expired or been tampered with), and then processes the request.
Because the authentication cookie is in memory with the browser process, it introduces some limitations:
The cookie is retained only as long as the browser is open; when the browser is closed the cookie is destroyed with everything else in memory that the browser was using.
The cookie belongs to the browser’s application process (such as the .exe file for the browser), and cannot be shared with other processes. Office system applications run in their own processes, for example, msword.exe for Microsoft Office Word. As such, a cookie that a user generated when logging into the site in the browser cannot be shared with Word.
The issues described in this article clarify why the Enable Client Integration option was developed: to help make the end-user experience more uniform and predictable in that environment; however, the user experience is somewhat different for users that are accustomed to SharePoint sites secured with Windows authentication.
Even with those restrictions, there are still a few options that can be used to allow for using forms authentication and yet still provide many or all of the deep integration points with Office applications that are available when using Windows authentication. […]
Another good post is here: Office SharePoint Server 2007 – Forms Based Authentication (FBA) Walk-through – Part 1 – 3
*** Update 2010-03-04 ***
On questions to the “security risk” of having “persistent cookies” here are some other interesting links for more information:
Forms Authentication in SharePoint Products and Technologies (Part 1): Introduction
Forms Authentication in SharePoint Products and Technologies (Part 2): Membership and Role Provider Samples
Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Authentication vs. Windows Authentication
*** Update 2010-11-03 ***
Another related post I published on 24 Feb 2010: SharePoint and Office integration
Hope that this will clarify your questions and the interpretation of the given link resources
Greets, Steve Chen