Easiest way to start customising the UAG


The easiest way to begin customising the logon page and portal is to start with the languages.

First, on the Authentication tab of your Trunk settings, deselect ‘Enable users to select a language’. Disabling this option will remove the option to select a language from the logon page, cleaning up the page.

Next, start by copying:

  • \von\InternalSite\Languages\en-US.xml to \von\InternalSite\Languages\CustomUpdates \en-US.xml
  • \von\PortalHomePage\Data\Languages\en-US.xml to \von\PortalHomePage\Data\Languages\CustomUpdates\en-US.xml

These files contain all the text strings that are shown on the Logon Page (InternalSite) and Portal page (PortalHomePage). If you try to manually edit the \InternalSite\Login.asp you will notice none of your changes are reflected as all the strings are referenced in the language files.

Begin by editing these files to reflect your required branding. You don’t have to re-activate the portal each time. The web pages will update automatically.

Couple of quick wins:

  1. If you’re from a country that spells correctly, do a find and replace on ‘authorize’ for ‘authorise’.
  2. Do a find and replace on ‘Microsoft Forefront Unified Access Gateway’ for your portal name.

Some of the more key strings to modify from \InternalSite\ (Logon Page) are:

Details at the bottom of the screen:

<String id=”1″ _locID=”1″><!– _locID_CDATA=”HTM” –><![CDATA[© 2010 Microsoft Corporation. All rights reserved. <a href=’javascript:alert(‘Microsoft Corporation licenses the software and services on this portal to you according to your Microsoft Unified Access Gateway 2010 (the &quot;software&quot;) license. You may not use this portal without a license for the software. Contact your IT administrator for the license terms.’)’>Terms and Conditions.</a>]]></String>

I would remove all of this, so: <String id=”1″ _locID=”1″></String>

Title for the logon page where user enters their credential’s:

<String id=”2″ _locID=”2″>Application and Network Access Portal</String>

Warning and helpful info:

<String id=”4″ _locID=”4″>This site is intended for authorized users only.</String>

<String id=”5″ _locID=”5″><!– _locID_CDATA=”HTM” –><![CDATA[If you experience access problems contact the <a href=’mailto:’>site administrator</a>.]]></String>

Title for Logon Page shown in Browser:

<String id=”829″ _locID=”101″>Microsoft Forefront Unified Access Gateway – Logon Page</String>

Used by Remote Desktop Application (user-defined):

<String id=”857″ _locID=”857″>Examples: computer.contoso.com, 192.168.1.23</String>

Advertisements

UAG SP1 Firefox\Chrome compatibility


If anyone is having issues with users reporting they cannot use Firefox or Chrome browsers with the UAG SP1, where the login screen freezes on ‘Checking for device compliance’, I have the answer.

I found this post which reports that the UAG SP1 Update 1 fixes the issue.

I’ve just deployed KB2585140 and it does indeed fix the issue.

My fault really, I should have updated immediately after installation.

Integrating IdentityGuard two factor OTP with Forefront UAG


I spent the day configuring IdentityGuard two factor OTP authentication with Microsoft’s Forefront UAG SP1.

There are a couple of key points to remember.

When you are using physical or virtual tokens, it is fine to set two authentication options (for example Active Directory and IdentityGuard) in your trunk configuration settings and prompt the user for a single username and two sets of passwords, one for Active Directory and one for IdentityGuard.

The problem with OTP arises because the IdentityGuard server has to first issue a challenge, therefore the user has no response to enter on the logon page if you request a password for IdentityGuard on first logon. The logical solution to this problem is to remove Active Directory authentication from the trunk configuration settings and configure the IdentityGuard server to check the user’s username and password is correct with Active Directory, before issuing the challenge. Although this does work IdentityGuard is not able to pass the user’s group membership back to the UAG, hence none of your application authorisation settings will work.

To get two-factor OTP authentication to work with the UAG and still be able to pass the user’s group membership settings to the UAG, you have to have both authentication methods set –  Active Directory and IdentityGuard. If you set Active Directory 1st you open yourself up to denial of service attacks and the possibility that user’s accounts will be locked out. Best to set the 1st authentication option to IdentityGuard and the 2nd to Active Directory. Additionally you have to edit the first logon page, to remove the password field for IdentityGuard which as we know is not required, as it is a challenge\response that is only available once the user has authenticated with Active Directory.

After the user successfully enters his Active Directory username and password, he will then get his two factor authentication challenge – whether token or OTP. I much prefer having a single logon page, but when you are using OTP this is the best you will get.

The workaround is documented in an Entrust document called Technical Integration Guide for Entrust? IdentityGuard 9.1 and Microsoft Intelligent Application Gateway (IAG) 2007. Starts on page 29 under the heading “To configure Entrust IdentityGuard second-factor and Active Directory authentication.”

I made a couple of small changes to align with UAG best practices to get this to work:  (I have read elsewhere that changing the login.asp name screws things up and also the format of the logon field in trunk settings must be quite particular. no leading forward slash)

1) Copied the \InternalSite\Login.asp to \InternalSite\CustomSite\Login.asp

2) Opened \CustomSite\Login.Asp and located the first occurrence of the line that starts with “for

each repository_name”

3) Followed step 3) as they describe.

4) Confirm step 4) as they describe.

5) Save Login.Asp

6) Login to UAG Manager, click configure your trunk settings and Update your Authentication tab and make sure Active Directory is set 1st and IdentityGuard set 2nd in authentication servers. Also make sure you enable “Users authenticate to each server” and “Authentication to each server with the same username”. And lastly update the “user logon page” and “on-the-fly logon page” fields to ‘CustomUpdate/Login.asp’. Note there is no leading forward slash. Thanks to diary of a newbie for pointing this out.

7) Click OK

8) And lastly as they describe make sure “In Entrust IdentityGuard, ensure that the VPN server definition for UAG has the first-factor authentication method set to “No First-Factor Authentication”. This is because we no are not passing any credentials to Active Directory.

I also found a similar document called Technical Integration Guide for Entrust IdentityGuard 9.3 and Microsoft Forefront Unified Access Gateway (UAG) 2010.

Looks to be updated for the UAG, but still changes the filename to Login_Entrust.asp. If you follow the instructions above it will work flawlessly.

If you don’t have an Entrust account you can get the documents here:

Technical Integration Guide for Entrust IdentityGuard 9.1 and Microsoft Intelligent Application Gateway (IAG) 2007

Technical Integration Guide for Entrust IdentityGuard 9.3 and Microsoft Forefront Unified Access Gateway (UAG) 2010

Also a working Login.asp if you want to try test with this approach.

Note I have changed the name to ‘IdentityGuard’ in this version

<%if repository_name = “IdentityGuard” then%>

as this was the name of my IdentityGuard Authentication Server in the UAG trunk configuration settings