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

Advertisements

Entrust IdentityGuard First Impressions


If you haven’t heard of Entrust IdentityGuard you should do some reading. It is a very good alternative to RSA SecurID backed up by a market leader in PKI. The impression you get of RSA is that they are arrogant, complacent and with regards to their pricing,  trying to bend you over a barrel as often as possible. Fortunately for enterprise customers there is an alternative!

With Entrust you are dealing with a company that is keen to break into the two factor market, offers a competitive package, provides software that includes a wide range of authentication methods built-in, will replace all your existing RSA tokens for free; and the tokens they do sell you, cost 1/10th the price of RSA. Even better they never expire. Additionally their support costs are not extortionate.

Its not perfect for sure, for example, it has got to be the most complicated SQL database install I have ever witnessed. If any Entrust developers are reading this, for god sake man, include the database creation and permissioning into the IdentityGuard installer.

It was written in Linux and ported to Windows, so if you are a Windows junkie like me its a bit of a struggle. Also it uses Apache Tomcat rather than IIS. Ever issued certificates for Tomcat? Not fun, but regardless of these minor points it kicks RSA’s ass.

I’ve used RSA for years and it is much more granular and after that initial period of confusion, it definitely grows on you. I would definitely recommend at least 5 days consulting time to make sure it is installed and configured optimally. I had 3 days onsite with a consultant and barely touched the surface.

Apart from IdentityGuard the only other component you will need is their IdentityGuard Self-Service module which sits in your DMZ and offers users the ability to manage their remote access authentication options remotely.

If you haven’t yet, check out their potential cost savings calculator.