Wednesday, 27 January 2010

Enabling RSA SecurID Authentication in Forefront UAG

A common requirement for most remote access solutions is the use of two factor authentication (2FA); RSA SecurID 2FA being a common choice for many organisations.

During UAG release candidate testing, it was not possible to utilise RSA SecurID authentication as there was no RSA Windows Agent available for Windows Server 2008 R2 (the platform used by Forefront UAG).

With the full RTM release of the UAG product, RSA still have not released a supported agent for Windows Server 2008 R2, hence I was keen to see if RSA SecurID authentication was supported by Microsoft.

So, does that mean RSA SecurID is not a supported authentication scheme on UAG? No, actually, it doesn’t, as Microsoft have now integrated the agent into the UAG deployment (like they did with ISA/TMG) such that it is not necessary to manually install the RSA Agent as you did with its predecessor, IAG. This is great news and brings UAG nicely in line with ISA/TMG deployments.

However, when attempting to configure RSA SecurID authentication using the Forefront UAG Management console, you may be surprised to receive an error message stating the following: Error message: ACE client is not installed. An example screenshot is shown below.


Now at this point, most UAG admins would probably give up and assume that they need to go and speak to RSA about a Windows agent for Windows Server 2008 R2; only to find that one is not currently available.

However, this error message is actually quite misleading and is something incorrectly left over from IAG. Basically this error can be ignored, as the product now includes the RSA agent as a native DLL, thereby negating the need to install any RSA software.

So, I thought the following walkthrough on configuring Forefront UAG with RSA SecurID may be useful for those early adopters out there, especially as there seems to be limited documentation available for this particular scenario.

Configuring RSA Authentication Manager

As with all RSA integration, the first thing to do is to define an RSA host agent in the RSA Authentication Manager console which will be used to represent the Forefront UAG server (or servers if using an array).

The key requirements here are to define a Network Address that represents the IP address that is bound to the UAG internal interface, and then define the agent type as a Net OS Agent.


Please Note: If you are using an array deployment, it will be necessary to create an RSA host agent entry for every array member to ensure authentication is successful during load balancing or failover conditions.

Depending on your RSA configuration, you may need to define specific Group Activations or enable the Open to All Locally Known Users option.

Preparing the RSA Agent

As UAG has multiple networks interfaces, it is recommended (as with ISA/TMG before it) to define the primary interface that should be used when communicating with the RSA Authentication Manager server; normally the internal interface. This is achieved by adding the the following registry string:


with a value which represents the IP address that is bound to the UAG internal interface, as shown by in the example below.


More info here:

The last thing to do is copy the sdconf.rec file from your RSA environment to the UAG server (or servers if using an array). This file should be placed into the %Windir%\System32 folder as shown below:


Please Note: If you are using an array deployment, it will be necessary to repeat the above steps for every array member to ensure authentication is successful during load balancing or failover conditions.

Configuring Forefront UAG

With the RSA Server configured and the RSA Agent prepared, we can now define a new authentication server within UAG.

Start the Forefront UAG Management console and select Admin from the menu, followed by Authentication and Authorisation servers…

Click Add and select the RSA SecurID server type. You can now define the appropriate details for your environment as shown below:


Please Note: When defining the Server Name: field, be aware that the name chosen here will be displayed to users on the authentication page so should be chosen wisely.

When you click OK, you will still receive the same error message discussed previously; which we now know can be ignored. Therefore, click Yes to continue.

Click OK to finish adding the authentication server. Click on the Activate Configuration option to activate the new changes.

Once activated, UAG will make the appropriate firewall policy changes in TMG to permit the necessary RSA communications, as shown below:


Other UAG Array Considerations

One final note for those using UAG arrays; as we need to define individual RSA agents hosts, this means that it will be necessary for RSA Authentication Manager to create individual node secrets for each array member. Therefore, it is recommended to test authentication for each array member individually to ensure this has been completed successfully. This can be verified by editing the relevant RSA host agent entries in the RSA Authentication Manager console. Each host agent should have the Node Secret Created option enabled if node secrets are successfully present. Node secrets will not be fully created until a successful authentication has taken place on each of the Forefront UAG servers in the array.

Please Note: One final caveat, I am unaware if there is any intelligence built into UAG to compensate for array scenarios when using RSA SecurID authentication. Consequently the steps defined throughout this article are recommended to be completed per array member for completeness.

I imagine Microsoft will fix the unnecessary RSA ACE client error prompt in due course, but until then, I hope this blog article has been useful…


  1. thanks for your blog, works perfect in our environment. there ist just one poor thing:
    if i logon with ActiveDirectory Credentials (username/pw) and rsa-token, logon works
    if i logon with ActiveDirectory Credentials (username/pw) and WRONG rsa-token, logon doesn't work
    if i logon with ActiveDirectory Credentials (username/pw) and ActiveDirectory pw instead of rsa-token, logon works

    Any ideas?

  2. Just a note -

    If you wish to use RSA and AD you have to make that configuration setting on the Authentication Tab of the Trunk.

    Change the setting to:

    - Require users to authenticate to each server
    -- Authenticate to each server with the same name (if you don't want to specify other credentials)

    Great post. Thanks for the info. Works great.

  3. I followed all the steps, but don't see the rule published. do I need to configure the tmg rule manually?

  4. Hi Jason,

    Can we use use this for authorization, i.e. restricting access based on Active directory groups with authentication through RSA?


  5. Jason,

    We recently migrated to MTIPS and aftewards we're getting the 106 web server busy from OWA. We looked at the TMG server and everything seems normal except that I'm not noticing any UDP 5500 traffic under real-time firewall and web proxy logs under "log & report". Please advise.


  6. We have RSA Auth Manager 6.1 integrated with UAG 2010SP3 and the one scenario that does NOT work is when a brand-new user has their AD account in 'force password change on next logon' mode, AND their SecurID token in 'New PIN' mode.

    On the user's first login, they are told their AD password has expired and are prompted to change it. After changing their AD password, they are returned to the UAG Log On screen with "Authentication Failed" displayed. They are NOT prompted to set a SecurID PIN.

    The Auth Manager logs now show the user is in "NextToken" mode.

    From this point forward, all attempts to login result in "Authentication Failed" at the UAG. Looking at the Auth Manager logs, we see "Access Denied: Syntax Error" on all login attempts.

    Has anyone seen this situation? Users who have current AD credentials and are in New PIN mode on Auth Manager are correctly prompted to set a PIN. Users who have an expired AD password are prompted to set a new one. But users with both items unset (e.g. brand NEW users) have this problem.

    1. Hi PJ,

      I've not encountered that specific scenario, so it may be a specific corner case.

      It is probably worth raising a call with MS support to determine if this is by design, a known issue, or perhaps something that can be fixed with an update...