This topic describes the Active Directory Federation Services (AD FS) 2.0 topology when partner employees access applications published by Forefront Unified Access Gateway (UAG) using non-federated authentication. In this topology, partner employees authenticate to the Forefront UAG trunk using federated authentication and to the published application using non-federated authentication, for example, Kerberos constrained delegation (KCD). This topology enables you to provide a single sign-on (SSO) experience for partner employees. It also allows you to define authorization rules for published applications in Forefront UAG that are based on the incoming claims.
The following diagram shows the main components in the system.
In this topology:
- Forefront UAG is configured as a relying
party of the corporate AD FS 2.0 server (Resource
Federation server in the diagram).
- A separate Active Directory Domain Services
(AD DS) server is used within the corporation; however, you
can configure AD FS 2.0 to run on your AD DS
- The corporate AD FS 2.0 server is
configured to trust the partner federation server (Account
Federation server). This trust is a federated trust, not a domain
- A web application has been published through
Forefront UAG. You can publish the application using either host
address translation (HAT) or alternate publishing name (APN). See
with AD FS 2.0 topologies.
When users from the partner organization attempt to access the published application, the following simplified flow occurs:
- The partner users attempt to access the
published application using claims-based authentication by
accessing the Forefront UAG portal and then clicking the published
- Forefront UAG redirects the web browser
request to the Resource Federation server to authenticate the
- The Resource Federation server shows the home
realm discovery page to users on which they must choose the
organization to which they belong; in this case, the partner
- The Resource Federation server redirects the
web browser to the Account Federation server where users
authenticate using their own credentials, after which they receive
a security token. Some authentication schemes prompt for
- Users are silently redirected several times
and automatically authenticated using the security token created by
the Account Federation server to the Resource Federation server and
then to Forefront UAG.
If the published application supports the Kerberos version 5 protocol, Forefront UAG can perform SSO to the application using Kerberos constrained delegation – the user is not required to enter credentials.
If the published application uses NTLM, on first using the application, users must enter credentials for the AD DS server in the resource organization. When accessing a second application through the Forefront UAG portal that uses NTLM and the same AD DS server, Forefront UAG can perform SSO.
- After the first successful connection to the
Forefront UAG portal, the Resource Federation server stores a
cookie on the user’s computer. The cookie is stored by default for
30 days; the duration is configurable in the web.config file on the
Resource Federation server. During this time, users are not
required to answer identification questions on the home realm
discovery page; that is, choosing the organization to which they
To deploy this topology complete the following tasks:
- Configuring an AD FS 2.0
- Creating a portal trunk
for AD FS 2.0
- Creating a Relying Party
Trust using Federation Metadata
- Creating a rule to
pass-through or filter an incoming claim
- Creating a rule to
transform an incoming claim
- Configuring single
sign-on with Kerberos constrained delegation to non-claims-aware
applications. If the published application uses NTLM, to
provide SSO, on the Application Properties dialog box,
enable SSO and configure an authentication server for SSO.