Summary: Learn the functional and operational differences between sites that are secured with Windows authentication and those that are secured with forms authentication. This article is part 3 of 3. (17 printed pages)
Applies to: Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0
Contents
- Introduction to Differences Between Forms Authentication and Windows Authentication
- Crawling Content
- Integrating with the 2007 Microsoft Office System
- Selecting the "Sign me in automatically" Check Box at Logon
- Opening Documents in Internet Explorer
- User Profile Imports
- Resolving Names
- Using an LDAP Provider
- Using the Microsoft Single Sign-On Service
- Conclusion
- Additional Resources
Read also:
Introduction to Differences Between Forms Authentication and Windows Authentication
There are several functional and operational differences between sites that are secured with Windows authentication and those that are secured with forms authentication. The following sections highlight several of the more important differences that you should be aware of as you plan your implementation.
| This article assumes that Microsoft Office SharePoint Server Service Pack 1 (SP1) is installed. For more information, see Updates Resource Center for SharePoint Products and Technologies. |
Note:Crawling Content
The crawl process for Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 content (in this article series, collectively referred to as SharePoint Products and Technologies) is designed to use Windows authentication. When Office SharePoint Server 2007 was released, it was not able to crawl content that was secured with forms authentication. In Service Pack 1, SharePoint Products and Technologies includes the ability to set special crawl rules that describe cookie-based authentication so those sites can be crawled. However, it does a simple crawl of the content only, and does not capture security information or the kind of rich metadata that the crawler can gather when using the native SharePoint protocol handler.
For those reasons, whether or not you have applied Service Pack 1, it is recommended that you crawl SharePoint sites protected by forms authentication by using the native SharePoint protocol handler. If your Web application already includes a zone that is secured with Windows authentication, in most cases you can use that zone for crawling. If your Web application has only a single zone and it is secured with forms authentication, you need to extend it into a new zone by using Windows authentication to support the native protocol handler. For more information, see Prepare to Crawl Host-Named Sites That Use Forms Authentication (Microsoft TechNet).
When you extend the Web application into a new zone, remember the following rules:
For those reasons, whether or not you have applied Service Pack 1, it is recommended that you crawl SharePoint sites protected by forms authentication by using the native SharePoint protocol handler. If your Web application already includes a zone that is secured with Windows authentication, in most cases you can use that zone for crawling. If your Web application has only a single zone and it is secured with forms authentication, you need to extend it into a new zone by using Windows authentication to support the native protocol handler. For more information, see Prepare to Crawl Host-Named Sites That Use Forms Authentication (Microsoft TechNet).
When you extend the Web application into a new zone, remember the following rules:
- If you are using only Windows SharePoint Services, the Default zone must be secured with Windows authentication. If the Default zone is secured with forms authentication and a secondary zone uses Windows authentication, the crawler will not be able to index it.
- If you are using Office SharePoint Server 2007, the Default zone can be secured with Windows authentication, but it does not have to be. You can use forms authentication for the Default zone and extend a separate zone for Windows authentication. However, you must change the start address in the default content source to the URL for the Windows authentication zone. When a new Web application is created, a start address is automatically added that uses the URL for the Default zone. Office SharePoint Server 2007 gives you the flexibility to change the values in the list of start addresses, but Windows SharePoint Services does not.
To change the start address
- Open your browser and navigate to the Shared Services Provider (SSP) Web site.
- Click the Search Settings link.
- Click the Content sources and crawl schedules link.
- Click the Local Office SharePoint Server sites link.
- In the Edit Content Source page that opens, in the Start Addresses section, edit the addresses in the box.
- Click OK to save your changes.
Integrating with the 2007 Microsoft Office System
Office SharePoint Server 2007 and Windows SharePoint Services 3.0 users who also have the 2007 Microsoft Office system of applications installed enjoy a high level of integration between the 2007 Office system and SharePoint Products and Technologies. Many of those integration features, however, depend on Windows authentication. Without Windows authentication, some integration points do not work, and others are changed considerably. To help minimize user confusion, SharePoint Products and Technologies offer a mode in which certain menu items that require Windows authentication are removed. In the Central Administration Web site, on the Authentication Provider page, this mode is controlled via the Enable Client Integration box.
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:
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:
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.
- Some toolbar items no longer appear:
- New Document
- Open in Outlook
- Open In Windows Explorer
- Export to Spreadsheet
- Open with Database Program
- New Document
- Explorer View option is hidden.
- Create an Access View option is hidden.
- In picture libraries, the following functionality is removed:
- Upload Multiple
- Edit Picture
- Download
- Send To
- Upload Multiple
- On the Edit Control Block (ECB) menu, the drop-down menu that appears when you click items in document libraries, the following items are removed:
- Edit in Word
- Edit in Excel
- Edit in PowerPoint
- Discuss
- Connect To Outlook
- Edit in Word
- In slide libraries the following functionality is removed:
- Publish Slide
- Send to PowerPoint
- Publish Slide
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.
More Here
Courtesy:http://msdn.microsoft.com/en-us/library/bb977430(office.12).aspx