Forefront UAG 2010 SP2 released

I just noticed Forefront UAG 2010 SP2 has been released as of last week 06/08/2012.

Looks to contain lots of fixes as well as improved support for Apple IOS 5.x and Android 4.x devices.

See release notes from UAG product blog here or you can just download it here.

Warning — This update requires all your clients to install  a new version of the ActiveX endpoint component plugin. If you don’t want your clients updating the ActiveX components or you push out the UAG components via msi then do not deploy this update!

Updated 21st August 2012:

My experience with the upgrade was not completely painless.

I installed the patch on my secondary UAG server in about 3 minutes and rebooted. No worries there.

I then installed the patch on my primary UAG server – the patch took a good 20 minutes to install and after the reboot (which isn’t necessary but I don’t trust Windows), when logging into to test, my trunk web pages were not being displayed correctly. I was getting the usual ‘Server Error in SecureTrunk application’ message.

What else to do except stop the World Wide Web Publishing service, rename the \von\Conf\WebSites folder and reactivate my trunk confiugration from within UAG Management Console to recreate the trunk web site folders to try fix.

Still didn’t work.

I suspected my old friend – the group policy security settings forcing FIPS compliance: ‘System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing.’ I disabled this via GPO and rebooted. This seemed to resolve the issue.

Why had this setting changed? Not sure – my web.config file looked unaltered – it was still set to use 3DES encryption which is FIPS compliant.

Not sure but I’m going to find out!

How to modify NAS-IP-ADDRESS attribute on Forefront UAG

By default the UAG will pass in the NAS-IP-ADDRESS attribute.

RADIUS NAS-IP-Address Attribute is really useful as it allows an arbitrary IP address to be used as RADIUS attribute 4, NAS-IP-Address, without changing the source IP address in the IP header of the RADIUS packets.

Why would you want to change this from

Some older RADIUS servers need the NAS-IP-ADDRESS attribute to match the source IP address header in the RADIUS packets, so modifying this attribute to the IP address of your internal interface on the UAG will fix this problem.

  1. My repository in UAG is called ‘Identityguard’
  2. Copy \von\InternalSite\samples\ to (in my case into the \von\InternalSite\inc\CustomUpdate\ folder.
  3. Then if you want to update the NAS-IP-ADDRESS field to the UAG internal interface, set: param_ip.Value = “10.x.x.x”

This is documented in this KB article – KB960302.

Alternatively if you are trying to integrate the UAG with Risk Based Authentication features included with Entrust IdentityGuard Enterprise Server, you will want the UAG to pass remote access client’s IP addresses in the NAS-IP-ADDRESS field.

Here’s how:

  1. My repository in UAG is called ‘Identityguard’
  2. Copy \von\InternalSite\samples\ to (in my case into the \von\InternalSite\inc\CustomUpdate\ folder.
  3. If you want to set the NAS-IP-ADDRESS field to the Client’s IP address set:  param_ip.Value = g_source_ip

and client source IP addresses will be passed through to the IdentityGuard Server now.

ForeFront UAG doesn’t recognise Trend Micro Deep Security 8 as compliant Anti Virus

I just noticed a new issue today with Microsoft’s ForeFront UAG and Trend Micro Deep Security.

The UAG does not recognise the Trend Micro Deep Security Agent as a compliant antivirus product  and therefore any clients using the Trend Micro Deep Security agent will not gain privileged session access to the UAG.

Interestingly enough, the UAG ForeFront Endpoint Scanner detects the Trend Firewall component.

To confirm this is from a physical desktop with the DS agent installed. The DS agent is offering anti-malware protection, not a Deep Security Virtual Appliance, so the UAG should be able to detect it.

I can understand virtual servers or desktops not being recognised there will not be way for the UAG to verify whether the client has AV services running on it.

What I have done is following the instructions here to try and customise the endpoint components detection script.

Thankfully the detection script DETECTION.VBS already has Trend Micro Office Scan so I have added a new check ‘DetectTrendMicroDeepSecurityAntiVirus’ in the script for Trend Micro Deep Security to validate whether it is installed and running but determining whether it is up to date is beyond me.

I have escalated to Trend Engineering to see if they can assist.


Trend DS 8 not detected in UAG Endpoint Detection


UAG and FIPS Compliance – How to implement 3DES in your SSLF environment

During the hardening of our DMZ domain we had applied the recommended Windows Server 2008 R2 SSLF Specialized Security Limited Functionality templates. What most people will know about the joys of implenting hardening policies is that you are bound to break every single application and the UAG is no exception.

If you apply the local security policy setting (as you should) “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” you will break the UAG.  The problem is as documented here. What you are doing by enabling this security policy is informing applications that they should only use cryptographic algorithms that are FIPS 140 compliant and in compliance with FIPS approved modes of operation.

In my case I could hit my login page fine but as soon as I got authenticated and passed through to the portal in my trunk I saw an error message:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
[HttpException (0x80004005): Unable to validate data.]
   System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo, Boolean signData)  +4308283

Yep, it was a complete mystery to me too.

The reason it happens is because ASP.NET 2.0 uses the RijndaelManaged implementation of the AES algorithm when it processes view state data. The RijndaelManaged implementation has not been certified by the National Institute of Standards and Technology (NIST) as compliant with the Federal Information Processing Standard (FIPS). Therefore, the AES algorithm is not part of the Windows Platform FIPS validated cryptographic algorithms and web pages are not served correctly.

The workaround is to configure ASP.NET to use 3DES instead of RijndaelManaged AES and is documented here:

  1. In a text editor such as Notepad, open the application-level Web.config file. In my case this was D:\Program Files\Microsoft Unified Access Gateway\von\PortalHomePage\web.config
  2. In the Web.config file, locate the <system.web> section.
  3. Add the following <machineKey> section to in the <system.web> section: <machineKey validationKey=”AutoGenerate,IsolateApps” decryptionKey=”AutoGenerate,IsolateApps” validation=”3DES” decryption=”3DES”/>
  4. Save the Web.config file.
  5. Restart the Microsoft Internet Information Services (IIS) service. To do this, run the following command at a command prompt: iisreset
  6. If you have additional UAG servers in an array, run iisreset on the other UAG servers.
  7. Test connection to your trunk. If you can login succesfully and hit your portal page, continue to next step.
  8. Enable the “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” GPO setting.
  9. Run gpupdate /force on all servers in your array.
  10. Re-Test connection to your trunk. If you can login succesfully and hit your portal page, continue to next step.

Microsoft never make it easy, eh!

UAG Array and External Load Balancer – Trunk cannot be activated due to the following: Invalid Internal IP address. Please choose a different IP.

This is a quick post to document an issue with the UAG if you have an array and you are using an external load balncer and therefore do not have the Forefront UAG integrated load balancing enabled.

What I initially tried to do was use the same IP addresses for my HTTP redirect trunk as my HTTPS trunk, so I had an HTTPS trunk ‘Trunk1’ already configured listening on public interface and  I was trying to configure the UAG to redirect HTTP traffic, listening on the same IP address

Not asking a lot I thought? Unfortunately this configuration cannot be actiavted if you are using a UAG array and external load balancer and you will get the error message ‘Trunk cannot be activated due to the following: Invalid Internal IP address. Please choose a different IP.’

You have to configure separate IP addresses for your HTTP trunks, even if they are only redirecting traffic to your HTTPS trunks.

I ended up adding to my public interface network adapter (Dont add another network adapter, just add an IP address on the existing adapter) and reconfigured my HTTP trunk to listen on and redirect all traffic to Trunk1 on

As most Enterprises will be using an external load balancer this issue should come up in your enterprise environment.

This is caveat is documented at the bottom of this Technet article.

UAG – How to remove the Authentication name from the password field

Usually on the UAG logon screen the Authentication name will be prefixed in the password field.

For instance if you have integrated with Active Directory and you have put the NetBIOS name as the Authentication name for your Active Directory authentication, your NetBIOS name will be advertised on your logon page.

If you want to tighten security and remove the Authentication name, you will need to edit the Login.asp file and remove the following text:




or if you wanted to prefix your company name, just edit String 109 in the relevant languages file. See this post for more info.

UAG – Top 10 Things to do after you’ve installed it

The UAG needs a lot of tweaking after you’ve installed it, here is a list of my top 10 things to do to get started:

  1. Make sure you have SP1 update 1 installed – KB2585140.
  2. If something is not working (like a Remote Desktop link), run the Best Practice Analyser. This will highlight any issues, like certificate errors that are stopping the application from working.
  3. Increase the default session timeouts – ‘Inactive session timeout=300 seconds’ and ‘Trigger automatic logoff after 60 mins’. Way to low for most environments. Increase to suit yours.
  4. Enable access for mobile users – This is disabled by default.
  5. Customise your portal – Not easy to do, but the sooner you brand it the better.
  6. Integrate with a two factor authentication product to increase security.
  7. When adding Active Directory integration update the search root and scope to include the domain only, i.e. the root, enable subfolders and leave nested groups blank so every group in the domain is queried. Takes longer but less hassle for Ops teams.
  8. Once you have configured authorisation don’t move the groups to another OU in Active Directory or your authorisation will break.
  9. To clean up the logon page, remove the language bar, deselect ‘Enable users to select a language’ from the Authentication -> Trunk configuration settings.
  10. Update the language files to customise all the logon and portal text.

And 1 to remember!

  1. If you are going to modify your Login.asp file make sure when you update the user logon page fields you do NOT use a leading forward slash, e.g. ‘/CustomUpdate/Login.asp’ is incorrect. The correct format is ‘/CustomUpdate/Login.asp’. Read a full outline here


  1. Check the protocols and encryption available via the best  public website checker –
  2. Install JVM for web monitor in IE –
  3. Disable TCP chimney, Receive Side Scaling and Taskoffload to resolve client endpoint issues as per this post:


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:,</String>

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