Configuring SharePoint Alternate Access Mappings to support SSL offload

When using the BIG-IP LTM system for SSL offload, for each SharePoint Web Application that will be deployed behind LTM, you must configure your SharePoint Alternate Access Mappings and Zones allow users to access non-SSL sites through the BIG-IP LTM SSL virtual server and ensure correct rewriting of SharePoint site links. For SSL offload, the Alternate Access Mapping entries must have URLs defined as https:, where FQDN is the name associated in DNS with the appropriate Virtual Server, and assigned to the SSL certificate within the Client SSL profile.

For each public URL to be deployed behind LTM, you must first modify the URL protocol of the internal URL associated with that URL and zone from http:// to https:: and then recreate the http:// URL. If you only try to add a new URL for HTTPS, it will not function properly.

For more information, see http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=804.

1. To configure SharePoint Alternate Access Mappings
2. From SharePoint Central Administration navigation pane, click Application Management.
3. In the main pane, under Web Applications, click Configure alternate access mappings.
4. From the Internal URL list, click the Internal URL corresponding to the Public URL you want to be accessible through the
   BIG-IP LTM. The Edit Internal URLs page opens.
5. In the URL protocol, host and port box, change the protocol from http:// to https:. You may want to make note of the URL for use in step 7.
6. Click the OK button. You return to the Alternate Access Mappings page.
7. On the Menu bar, click Add Internal URLs.
8. In the URL protocol, host and port box, type the same internal URL used in step 4, but use the http:// protocol. This allows access to the non-SSL site from behind the LTM.
9. Click Save.
   You must also add the new internal URL(s) to the list of Content Sources of Search Administration.
10. From the navigation pane, click Application Management, and then under Service Applications, click Manage service applications.
11. Click the name of your Search Service application. In our example, we are using Microsoft Fast Search Server, so the following examples are based on Fast Search Server.
12. In the navigation pane, click Content Sources.
13. On the Menu bar, click New Content Source.
14. In the Name box, type a name. We type https://sp2010.fast.example.com/.
15. In the Start Addresses section, type the appropriate HTTPS URL. In our example, we type https://sp2010.fast.example.com/. All other settings are optional.
16. Click the OK button.
17. Repeat this entire procedure for each public URL to be deployed behind LTM.

Displaying HTTPS SharePoint Search Results After Configuring Alternate Access Mappings for SSL Offloading

After configuring Alternate Access Mappings in SharePoint 2010 to support SSL offloading, you must perform the following procedure to ensure that search results are properly displayed for https:// queries. The examples below depict modifying the Content Search Service Application; however, you must also perform these steps on your Query Search Service Application.

To ensure HTTPS search results are displayed

1. From SharePoint Central Administration navigation pane, click Application Management.
2. Under Service Applications, click Manage service applications.
3. From the Service Application list, click your Content SSA. If you are using the default content SSA, this is “Regular Search”. If you are using FAST Search, this is the name you gave the content SSA (such as FAST Content SSA).
4. From the navigation pane, under Crawling, click Index Reset.
5. Click the Reset Now button to reset all crawled content.
6. Return to your Content SSA (repeat steps 1-3).
7. From the navigation pane, under Crawling, click Content Sources.
8. Click the content source for which you just reset the search index.
9. From the Edit Content Source page, in the Start Full Crawl section, check the Start full crawl of this content source box and then click the OKbutton.

 

When the crawl is complete, users should receive https:// addresses in their search query results.