Partager via


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.

clip_image001

Based on the screenshot the FQDN of the ADFS server and the published application must reside in the dmz.net 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

clip_image002

clip_image003

clip_image004

Assuming that the DNS name of your ADFS Server is sts.dmz.net the location of the FederationMetadata.xml will be https://sts.dmz.net/FederationMetadata/2007-06/FederationMetadata.xml

Click on Retrieve Metadata

image

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 https://technet.microsoft.com/en-us/library/gg295298.aspx

clip_image005

Save and Activate Configuration

Create HTTPS Trunk

clip_image006

clip_image007

clip_image008

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.

clip_image009

clip_image010

 

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.

clip_image014

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.

image

 

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 https://technet.microsoft.com/en-us/library/gg274305.aspx

clip_image015

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

 

clip_image016

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

clip_image017

clip_image018

clip_image019

clip_image020

Click Next

clip_image021

Click Close

Add a new Rule

clip_image022

 

image

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.

clip_image024

clip_image025

clip_image026

clip_image027

Choose the endpoint protection settings in accordance with your requirements.

clip_image028

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.

clip_image029

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

clip_image030

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.

clip_image031

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

clip_image032

clip_image033

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: https://technet.microsoft.com/en-us/library/gg470578.aspx

clip_image034

 

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.

clip_image035

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

clip_image037

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

image