Prerequisites

  • Article

Updated: July 31, 2012

Applies To: Unified Access Gateway

Before you deploy Forefront Unified Access Gateway (UAG) with Active Directory Federation Services (AD FS) 2.0, you should be aware of the prerequisites for deploying your system, the prerequisites for each topology, and the known issues and limitations.

  • Prerequisites

  • Known issues and limitations

Prerequisites

AD FS 2.0 in Forefront UAG requires the following:

  • An AD FS 2.0 server.

  • A federation server proxy.

    Note

    If you are using an AD FS proxy server, it must not be running on the Forefront UAG server.

  • The AD FS 2.0 server is defined as an authentication server in Forefront UAG. When you use an AD FS 2.0 server for trunk or application authentication, it must be the only authentication server.

  • If you want to map external partner accounts to internal accounts using Kerberos constrained delegation, you must use shadowed accounts.

    Note

    To use Kerberos constrained delegation, Forefront UAG must be domain joined. For more information, see Configuring single sign-on with Kerberos constrained delegation

Topology prerequisites

This section lists the prerequisites for each topology.

For all topologies

For topologies providing access to partner employees

General deployment information for your organization

  • Forefront UAG is not required to be a part of the same domain or network as the AD FS 2.0 server, the AD FS proxy server (if used), or the applications that will be published.

  • When you publish applications using HTTPS for communication on the internal and external networks, end users can access the published application from the internal and external networks. Make sure that you select the Use SSO check box and select the AD FS 2.0 authentication repository on the Authentication tab of the Application Properties dialog box.

    When using federated authentication, it is not recommended to publish applications using HTTP for communication on the internal network. However, when internal users access applications published in this manner, they should use the external address because this is the address that is known to the AD FS 2.0 server.

Requirements when publishing the AD FS 2.0 server

If you publish the AD FS 2.0 server through Forefront UAG instead of through the federation server proxy, note the following (also see the Known issues and limitations):

  • Your AD FS 2.0 server and your Forefront UAG server must have the same domain name in the certificates they use for authentication; that is, the public host name of the AD FS 2.0 server must have the same domain name as the certificate that you use when creating the HTTPS portal trunk on Forefront UAG. For example, if you use a wildcard certificate *.contoso.com, your public AD FS 2.0 server name can be adfs2.contoso.com, or fed_auth.contoso.com, but not adfs2.hr.contoso.com.

  • The public host name of the AD FS 2.0 server (defined in Forefront UAG) must be the same as the Federation Service name (defined in the AD FS 2.0 management console).

  • Forefront UAG behaves like a “man in the middle” in AD FS 2.0 deployments. IIS on the AD FS 2.0 server automatically protects against man in the middle attacks using a Channel Binding Token (CBT). However, if the CBT is enabled, you cannot provide access to your remote employees. To turn off CBT, on the AD FS 2.0 server in your organization, run the following command:

    appcmd.exe set config "Default Web Site/ADFS/ls" -section:system.webServer/security/authentication/windowsAuthentication /extendedProtection.tokenChecking:"None" /extendedProtection.flags:"Proxy" /commit:apphost

Client requirements

  • Client computers can be running any supported Windows operating system (see System requirements for Forefront UAG client devices) and can use supported Internet Explorer and Firefox browsers.

    Important

    The following URLs must all be added to the Trusted Sites list:

    • Forefront UAG portal URL

    • Your organization’s AD FS 2.0 Federation Service name

    • Partner Federation Service name

    • SharePoint AAM URL (if applicable)

    • External URL of external URL-aware applications (if applicable)

    • Alternate publishing name (APN) URLs (if applicable)

    Note

    In all of the topologies, when an end user connects to the published application for the first time, they may experience long delays while the access request is redirected between the relevant servers. On subsequent connection attempts from any end user, the delays are significantly reduced.

    Additionally, if the end user security token contains a large number of claims, the user may experience delays when signing in while the claims list is processed.

AD FS claims tracing

Forefront UAG adds all claim values to the Forefront UAG trace file, which can be useful when troubleshooting.

Warning

In many organizations, claim values are created directly from Active Directory attributes; therefore, they can contain personally identifiable information (PII). Therefore, the trace file should be treated as though it contains PII, according to your organization requirements.

Known issues and limitations

  • When using AD FS 2.0 and Forefront UAG, you cannot publish applications that are installed on the AD FS 2.0 server.

  • You cannot end user sessions from the Forefront UAG Web Monitor. If you do end a user session using Web Monitor, single sign-out does not take place and the end user may receive an HTTP 500 error page.

  • If you are using the Forefront UAG server to publish the AD FS 2.0 server:

    • End users cannot use mobile devices to access trunks that use federated authentication.

    • If you need access to the on premises federation server for Office 365 authentication, you cannot use Forefront UAG. You must use an AD FS 2.0 federation server proxy.

    • Active clients that authenticate using the WS-Trust protocol are not supported.

    • When frontend authentication is standard Forefront UAG forms-based authentication (FBA) and the backend application is SharePoint using claims-based authentication, SSO does not work correctly; specifically:

      • When accessing the SharePoint application from the portal with SSO turned on, SSO does not occur and the standard Forefront UAG FBA logon page is displayed.

      • When accessing the SharePoint application from the portal with SSO turned off, the AD FS logon page appears. The user can enter the relevant credentials and can then access the SharePoint application.