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:

<TD><%=repository_name%>&nbsp;<%=GetString(109,”Password:”)%></TD>

to

<TD><%=GetString(109,”Password:”)%></TD>

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

Advertisements

Trend Micro Deep Security v8 is out Friday


With the release of Trend Micro Deep Security v8 out this Friday the 27th January and Trend Manager v8 already available for download, I thought I would document my current list of issues I hope will be fixed in the new release.

Areas that could be improved:

  • When you Prepare an ESX Host, there is no mention in the window of which host you are preparing. It gets extremely confusing when you are trying to prepare a large cluster as immediately after preparing the esx host, the next action is to deploy the virtual appliance and there is no indicator of which host you are working so you don’t know which virtual appliance you are deploying or what to name it.
  • Leading on from the point above it would be great if this process could be automated. Why do you have to manually deploy the filter to a single host at a time. You should be able to select a cluster and select Deploy filter. Their solution doesn’t scale well! I pity the fool who has 50 node cluster to roll Trend out too.
  • It would be great to be able to deploy the Trend agent (and now that I mention it, vShield Endpoint agent) to VMs from within Trend Manager. Maybe I missed something here, but I don’t think that is a feature currently.
  • Every time I vmotion a VM the status changes to ‘virtual machine unprotected during move to another ESX.’  I spend my whole team clearing ‘warnings/errors’ as there is often a spurious message being displayed which means you cannot see the current status of the VM. There really needs to be an extra column for Alerts to separate these messages from the Status column as these messages often have no bearing on the status.
  • In the quick start guide there is no mention of the DRS rules or groups that should be configured to ensure that the virtual appliances remain on the correct hosts as well as the preferred HA settings to ensure the virtual appliances are left ‘powered on’ under the isolation response settings.
  • The current version of DS does not support wildcards so you have to exclude the whole folder (D:\WINDOWS\NTDS) — you cannot for instance, exclude NTDS*.* from the D:\WINDOWS\NTDS folder. This is AV 101. Not sure why it wasn’t included!

I welcome any additions to this list!

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

Updates:

  1. Check the protocols and encryption available via the best  public website checker – http://ssllabs.com
  2. Install JVM for web monitor in IE – http://java.com/en/download/manual.jsp
  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: computer.contoso.com, 192.168.1.23</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

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.