Publishing Claims Aware Web Applications via Unified Access Gateway (UAG) SP1


This walkthrough outlines the process of publishing a claims aware application through UAG SP1.

Links to building pre-requisite components

The publishing process consists of the following:

1. Configure UAG with ADFS 2.0 Authentication Server

2. Creating UAG HTTPS trunk protected via the ADFS 2.0

3. Adding a claims aware application to the UAG trunk

Request SSL Certificate for UAG trunk which will publish the web applications

Note that the domain portion of the Subject of the certificate should match the domain portion of both the ADFS Server and the published application.


Based on the screenshot the FQDN of the ADFS server and the published application must reside in the space. Put in other words, the domain portions of the Subject field of the UAG trunk certificate should match the Subject fields of on the certificates protecting the ADFS (STS) and the published application.

For more details on this see Forefront UAG and AD FS 2.0 supported scenarios and prerequisites (Topology prerequisites)


Create ADFS 2.0 Authentication Server




Assuming that the DNS name of your ADFS Server is the location of the FederationMetadata.xml will be

Click on Retrieve Metadata


In most cases this warning could be ignored since by default ADFS will sign the FederationMetadata.xml with a self-singed Token Signing certificate.

More details can be found here


Save and Activate Configuration

Create HTTPS Trunk




The public name of the trunk must match the subject name of the certificate requested for the UAG. If a wild card certificate was requested only the domain portion of the name must match.




For the the rest of the wizard you can proceed with the default settings. Of course, in production environment you need to evaluate your requirements for assigning UAG end-point scanning policies.

Save and Activate Configuration

Notice that a new application of type Active Directory Federation Services 2.0 was added to the trunk. This application creates a channel through which a user will be authenticated to the portal, in other words UAG Portal will play a role of a claims aware application. User attempting to connect to the portal will first be redirected to the ADFS server in charge of authenticating users to this app. If authentication to the application is successful the user will be given access to the portal.

Of course, for this to work we need to setup a trust relationship between UAG portal and ADFS server, which we will do in the next section.


Important note on the Certificate Revocation List Distribution Point of the certificate protecting the ADFS Server. The UAG server not only needs to trust the SSL certificate of the ADFS Service, but also needs to be able to validate that the certificate is not revoked by checking the CRL Distribution Point. This is not an issue if you are using a commercial certificate, but if you are testing in a lab environment check the CRL Distribution Points of the ADFS Service certificate and ensure that at least one such point is accessible to UAG. In my case the UAG and the issuing CA are in the same forest hence the default LDAP CRL Distribution Point is accessible, but this is not always the case.



Add Relying Party Trust for UAG on DMZ ADFS Server

Copy the FederationMetadata.xml file from UAG server to the ADFS server.

See this link for more information


On the ADFS Server, which we configured as the Authentication server in UAG, perform the following steps.



This steps assumes that the FederationMetadata.xml from the UAG server was copied to the local drive on ADFS server.





Click Next


Click Close

Add a new Rule




The only mandatory claim type in our configuration is Name, since we specified it during the configuration of the Authentication server on UAG. The value of this claim will be used by UAG for logging purposes.

Having the Role claim populated with Active Directory groups is convenient since it will allow us to control access to the applications inside the UAG portal based on AD group membership, but this choice is arbitrary, any other claim could be used to control access.


Publish DMZ Web Application

This guide assumes that you already have a claims aware application integrated with the same ADFS server. In this section we will publish such application via UAG.





Choose the endpoint protection settings in accordance with your requirements.


ADFS servers could be deployed in a farm configuration, in such case use the load-balancing feature of UAG to distribute the load among the farm members.


Not the “/” at the end of the /site1/, it seems to be important.


Ironically we don’t seem to need to enable SSO. Since both the portal ADFS application and the application we are publishing are integrated with the same ADFS server, by virtue of authenticating to the Portal first the client will have a cookie proving that it already was authenticated. This cookie in effect accomplishes SSO.


Note trailing / in the /site1/ also ensure that the URL stats with https://



Save and Activate UAG configuration


Disable IIS Extended Protection on ADFS Server

When ADFS server is handling authentication requests behind a reverse proxy Extended Protection needs to be disabled on IIS.

More information on this here:



Testing Access to the DMZ Web Application

Before testing from a client sitting behind UAG ensure the following:

1. Client can resolve UAG Portal public names and ADFS Server public name. Both of those need to resolve to the UAGs external IP.


2. The CA which issued the SSL certificates for both the Portal and ADFS servers is trusted by the client


3. Unless the client can access CRL Distribution Points disable CRL validation in the browser.