Export (0) Print
Expand All

Prerequisites

Published: January 11, 2010

Updated: February 15, 2013

Applies To: Unified Access Gateway

This topic describes the prerequisites for publishing SharePoint applications through Forefront Unified Access Gateway (UAG) and known issues and limitations when publishing SharePoint applications.

  • Prerequisites—Describes the software requirements before publishing SharePoint applications and other prerequisites; including information about Alternate access mappings, public host names, server certificates, and rich clients.

  • Known issues and limitations—Describes the known issues and limitations that you may encounter when publishing SharePoint applications through Forefront UAG.

Prerequisites

Host-named site collections

Host-named site collections provide a scalable web hosting solution with each site collection assigned to a unique DNS name. In a web hosting deployment, each host-named site collection has its own easy to remember host name URL, such as http://customer1.contoso.com, http://customer2.contoso.com, or http://www.customer3.com.

SharePoint Server 2013 provides the ability to use managed paths with host-named site collections, and the ability to use off-box SSL termination with host-named site collections. For more information, see Plan for host-named site collections.

noteNote:
Forefront UAG supports host-named site collections in SharePoint Server 2013. Host-named site collections are not relevant for earlier versions, such as SharePoint Server 2010, SharePoint Server 2007, or SharePoint Portal Server (Office 2003). Host-named site collections cannot be used in conjunction with alternate access mappings.

Alternate access mappings

Alternate access mappings (AAM) enable SharePoint Server 2013, SharePoint Server 2010, and SharePoint Server 2007 to map web requests to the correct web applications and sites, and they enable the SharePoint Server to serve the correct content back to the user. For example, in a setup where internal users access a SharePoint site at http://hr/ and remote users access the same SharePoint site at https://HRportal.woodgrovebank.com through Forefront UAG, the SharePoint Server replies to both internal and remote users with identical content. The Forefront UAG server responds with identical content, even though external users submit a protocol (HTTPS) and a host header (HRportal.woodgrovebank.com) that are different from the protocol and host header submitted by internal users. For additional information about alternate access mappings, see Plan alternate access mappings (Office SharePoint Server).

noteNote:
Forefront UAG supports AAM in SharePoint Server 2013, SharePoint Server 2010, and SharePoint Server 2007. AAM is not relevant for earlier versions, such as SharePoint Portal Server (Office 2003).

Public host names

When you publish SharePoint Products and Technologies via Forefront UAG, each SharePoint web application is associated with a unique public-facing host name, which is used to access the application remotely.

A SharePoint web application that is published through the Forefront UAG trunk shares the trunk's definitions in addition to some of the trunk's functionality, such as the logon and logoff pages. This means that the application's public host name must reside under the same parent domain as the trunk's public host name; that is, the application and the trunk are subdomains of the same parent domain. However, the public hostname used for the SharePoint application and the Forefront UAG trunk must not be identical, to allow Forefront UAG to properly identify requests that are directed to the SharePoint application.

The following table shows sample public host names of Forefront UAG trunks, and the valid and invalid public host names for the SharePoint web applications that you publish through each sample trunk.

 

Forefront UAG trunk’s public host name Trunk’s parent domain Examples of valid public host names for SharePoint web application Examples of invalid public host names for SharePoint web application

uag.woodgrovebank.com

woodgrovebank.com

hrportal.woodgrovebank.com

hrportal.a.b.woodgrovebank.com

hrportal.uag.woodgrovebank.com

hrportal.com

uag.woodgrovebank.com

uag.ext.example.com

ext.example.com

hrportal.ext.example.com

hrportal.a.b.ext.example.com

hrportal.uag.ext.example.com

hrportal.com

hrportal.example.com

uag.ext.example.com

When you select an application's public host name, you must also consider the limitations that are associated with the trunk's server certificate. For information about server certificates, see Server certificates.

Server certificates

During the initial configuration of an HTTPS trunk in Forefront UAG, you select the trunk's server certificate. All the public host names that are used in the trunk must be covered by this certificate, including the trunk's public host name and the public host names of all the applications that are accessed via the trunk.

The following types of certificates support multiple host names:

  • Wildcard certificate—Forefront UAG supports wildcard certificates at the domain level and subdomain level. Wildcard certificates in the form *.uag.contoso.com, or *.contoso.com are supported. Forefront UAG will issue an alert if wildcard certificates are in the form *.*.contoso.com.

  • Subject Alternative Name certificate—Includes a primary domain and a list of other domains that are covered by the certificate. There is no difference between the primary and secondary domain, and there is no limitation on the number of host names that you can use. Note, however, that if host names are added to the trunk, you might need to issue or install a new certificate if the existing one doesn’t include the new name, and select a new certificate for the trunk.

For information about how to import a certificate into Forefront UAG, see Install an Internet Server Certificate (IIS 7) and Import a Server Certificate (IIS 7). You assign the certificate to the Forefront UAG website when you create or edit the Forefront UAG trunk through which you publish the SharePoint web application.

About rich clients and MSOFBA

When publishing SharePoint applications in your portal, certain rich clients can authenticate directly with the SharePoint site’s authentication server, instead of authenticating to the portal and then opening the SharePoint site. This authentication uses 401-responses from the application, rather than using forms-based authentication in the browser.

In addition, if end users access your published SharePoint applications by using certain rich clients (for example, when re-opening a recently-opened document from within Word) you can use MSOFBA. MSOFBA is a protocol that provides forms based authentication, instead of basic or NTLM authentication, when you use Office client applications.

When rich clients authenticate directly using basic or NTLM authentication or MSOFBA, end users can open Office documents that are published on your SharePoint site directly from the client application, without using the Forefront UAG portal and without accessing the published SharePoint site via the browser first. Rich client authentication and MSOFBA are described by the following flows:

  • Rich client direct authentication to SharePoint site—When an end user attempts to open an Office document that is published on your SharePoint site, a credentials dialog box is shown by the Office application. This allows the user to authenticate against the authentication server configured in the Forefront UAG Management console as the authentication server for your published SharePoint site

  • MSOFBA authentication—When rich clients attempt to open an Office document that is published on your SharePoint site, but the rich client is not attempting to open the document in an Internet Explorer browser window that is already authenticated to Forefront UAG, the Office application displays a login page (the portal login page).

To allow rich clients to authenticate directly to your SharePoint application, on the Authentication page of the Add Application Wizard, select the Allow rich clients to bypass trunk authentication check box. To use MSOFBA, you must also select the Use Office Forms Based Authentication for Office client applications check box.

ImportantImportant:
When you allow rich clients to bypass trunk authentication, they bypass all forms of trunk authentication: one-time password (OTP), smartcard, customized authentication flows, and so on.

When you select these check boxes, the behavior (basic or NTLM authentication or MSOFBA) is applied to all SharePoint applications that you publish in the trunk. In addition, in Forefront UAG SP2 and SP3, users can authenticate to a trunk using MSOFBA when the trunk uses Active Directory Federation Services (AD FS) 2.0 for authentication.

ImportantImportant:
If you use different authentication servers for each SharePoint application, after end users access files on one SharePoint site, they must close their Office client application before they can access files on the other SharePoint site.

noteNote:
If you configure your SharePoint applications to use MSOFBA, you should ensure that the SharePoint site is not configured to use forms-based authentication.

Client endpoint requirements

In order to use MSOFBA for end users to authenticate to your published SharePoint application, end user computers must be running one of the following operating systems:

  • Windows 8

  • Windows 7.

  • Windows Vista.

  • Windows XP with Service Pack 3.

    noteNote:
    Versions of Internet Explorer prior to Internet Explorer 8 are not supported.

MSOFBA is supported only with the following releases of Microsoft Office:

Known issues and limitations

Single sign-on (SSO)

  • To provide access to SharePoint sites to computers that do not have the Forefront UAG Client Components installed, the domain of the SharePoint site must be in the Trusted Sites list of Internet Explorer, and Internet Explorer must be configured so that the Trusted sites zone does not run in protected mode. In this configuration, end users can log on to the site using single sign-on (SSO). If the SharePoint site is not in the Trusted Sites list, end users cannot log on using SSO. In this case, SSO refers to SSO between the browser and the Office application that was launched when attempting to open a document on the SharePoint site.

  • SSO does not work when end users attempt to open documents on a SharePoint site using a non-Internet Explorer browser.

Mobile devices

  • When end users access a SharePoint 2010 site from a mobile device using the Office Mobile client, to allow the device to download documents from a SharePoint site, you must make the following URL set changes:

    1. In the Forefront UAG Management console, open the Advanced Trunk Configuration dialog box, and click the URL Set tab.

    2. In the URL list, scroll to InternalSite_Rule54, and in the Methods column, add the HEAD method.

    3. In the URL list, scroll to SharePoint14AAM_Rule47, and in the Methods column, add the HEAD method.

    4. On the Advanced Trunk Configuration dialog box, click OK, and then activate the configuration.

  • When end users open an Excel file on a SharePoint site from their mobile device, the file opens correctly. If they then go to a different SharePoint site, the first time they try to open an Excel file it may not open as expected; end users must click the file again to open it.

General

  • You cannot change the Logoff URL on the Authentication tab of the Advanced Trunk Configuration to point to a SharePoint site URL.

  • If you publish a SharePoint 2010 application, after end users sign in to the SharePoint site, they cannot sign in as a different user after clicking Sign in as Different User.

  • In some circumstances, when Office clients access Office files published via Forefront UAG with a browser using the WebDAV user agent, client authentication might not work as expected. In Office 2007, clients might be continuously prompted for credentials. In Office 2010, clients may be prompted three times for credentials before the requested file is opened.

  • When you use endpoint policies to prevent users from uploading documents to your SharePoint sites, users are unable to do the following:

    • Uploading a new document through a web browser.

    • Checking in a new version of a document.

    However, regardless of the endpoint policy that you apply, the following actions are not blocked:

    • Creating a new document by clicking New or New Document on the SharePoint site.

    • Editing and saving a document on the SharePoint site. For example, clicking Edit in Microsoft Word for a previously uploaded Word document, or adding a picture or a macro to the document and clicking Save.

    • Uploading a new document through the Microsoft Office Upload Center or SharePoint workspace.

  • If you allow rich clients to authenticate directly with the SharePoint site’s authentication server or if you allow MSOFBA, when end users attempt to access files in their client application, the files may not open. This can occur when they attempt to access files using the Open dialog and in File name they enter the full path of the file (including the file name). In this case they may receive multiple credential requests and the file may not open. Instead, users should enter only the path to the folder where the file is located, press ENTER, and then in the file list, they should double-click the file.

  • The following Office applications are not supported when publishing SharePoint with Forefront UAG:

    • Publishing InfoPath forms on a SharePoint site

    • Office Picture Manager

    • OneNote

    • Microsoft Query

    • Upload Center

    • Visio

    • Publisher

    • Access

    • Groove

    • Apps for SharePoint 2013

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft