Friday, 6 February 2009

Customising ISA Server 2006 HTML Forms - Part 2: Restructuring the Default RSA SecurID Form

Continuing on from Part 1 of this article series, this article extends the customisation process when using HTML Forms authentication specifically with RSA SecurID.

After using this form myself as an “end user” a feature of the default form stood out immediately in terms of usability:

When using the Collect additional delegation credentials in the form option, the RSA SecurID credentials are presented at the top of the form. Although this seems insignificant at first, this can lead to a frustrating experience for the user when the RSA tokencode is nearing expiry, as it is possible for the tokencode to change as you are typing your Active Directory credentials into the bottom section of the form. This can subsequently lead to authentication errors and annoyed users!

Therefore, this blog entry provides an overview of addressing this issue to provide, in my opinion and from customer feedback, a much better overall user experience.

A great feature of using HTML forms with RSA SecurID is the ability to combine both RSA credentials and Windows (Active Directory) credentials within a single form. The RSA credentials are used to validate the users identify and the Windows credentials are used for ISA Server authentication delegation to the published server. This provides a great user experience as users only see a single web form, where they enter all of their credentials in one place, followed by the published application. Simple, logical and easy to support.

This feature is enabled by configuring the Collect additional delegation credentials in the form setting on the Authentication tab of the web listener in question, as shown below:

CollectDelegation

However, due to the default form design, the primary authentication method, in this case RSA SecurID, is used as the first set of credentials requested by the form. Additional fields are then added below, in order to define the delegation credentials which need to be used. If you think about the processing logic behind the form, this layout actually makes total sense, however if you consider the user input logic, especially with a time sensitive password, things are not quite so logical.

The default layout (using the customisation features from Part 1) for the default ISA HTML form is shown below:

rsaform

So, in order to make the form a little more user friendly we need to rearrange the credential fields into a more logical flow.

When using RADIUS OTP or RSA SecurID authentication validation methods, the form structure is defined within the usr_pwd_pcode.htm file located in the ISA\HTML folder as shown below:

RSAhtmlfile

Hence, this is the file that needs modifying. In Part 1, we discussed using the style sheets to apply changes for look and feel. However, as we are now looking at changing the actual form structure, we need to actually modify the HTML code which is a little more involved.

To best explain the process I have used a utility called Compare It! which allows you to compare (obviously!) two files side by side to look for changes that have been made. Hopefully this will provide a good step-by-step view of what elements need changing/deleting etc. and provide a good ‘before and after’ feel.

In the screenshots below, you will see two windows; the left window shows the original version of the file and the right window shows the modified version. For clarity, the differences are highlighted in light green.

To keep with good coding practice, you will also see that comments have been added to the modified version so I can track what has been changed.

Please Note: Before you begin editing the file, I would suggest you make a backup copy of the usr_pwd_pcode.htm file so you can restore the default form, if necessary.

So, let’s begin making changes!

Here’s a quick summary of what we plan to do:

  • Remove the Internal Network Credentials section from the form completely.
  • Move the Internal Network Credentials Password field under the username field, so that username and password are entered prior to the RSA SecurID passcode.
  • Cleanup the form to remove the (commonly) unwanted option of Use a different user name.
  • Cleanup the HTML code to remove unneeded JavaScript variables to prevent JavaScript errors in the browser.

The first thing we need to do is find the password field in the HTML code. The relevant code is shown in green in the following screenshots:

 rsacompare10

So, we need to cut and paste this code so that it appears after the username field as shown below:

 rsacompare3

Next we need to remove the horizontal line from above the Internal Network Credentials area. This is done by commenting out the following line:

 rsacompare4

Next we comment out the table that displays the Internal Network Credentials (show explanation) text and link:

rsacompare5

rsacompare6

Next we comment out the table that shows the unwanted Use a different user name check box:

rsacompare7

rsacompare8

Next we remove the normally hidden username field that appears after selecting the Use a different user name check box: 

rsacompare9

rsacompare10

Finally, we need to do some cleanup to remove unused variables which will cause JavaScript errors:

rsacompare1

rsacompare2

 

So we are finishing editing and the file can be save.

If all of that looked a little too painful, you can download a pre-edited version of the usr_pwd_pcode.htm from here which contains all the necessary changes discussed above.

In addition, you can also download a pre-edited version of the default Exchange HTML form with the same changes here (Note: you will need to rename the file from usr_pwd_pcode_owa.htm to usr_pwd_pcode.htm once downloaded).

So, with the changes saved and the Microsoft Firewall Service restarted, we now have the following customised HTML form:

rsacustom

Hopefully you will agree that this is a much cleaner looking form with a much better logical flow in terms of the user authentication experience.

As can be seen from the above screenshot, the default form fields have also been renamed to use more standard looking approach. This is simply achieved by modifying the L_Username_Text and L_Passcode_text strings in the strings.txt file, as covered in Part 1.

strings (2)

strings1

So, with the 'look and feel' elements covered, and some basic restructuring of the less intuitive default RSA forms, you should be able to get customising today - hope you enjoyed it!

7 comments:

  1. Hi Jason,

    Nice article! I've been configuring an OTP web listener recently (not SecurID) but have noticed that if you use a custom form on a web publishing rule (lets call it WEB), that if some reason the user fails to login correctly (e.g. presses logon by mistake), that ISA falls back to the default style/form ... i.e. the standard usr_pcode.htm and not the customised one being used.

    Any idea why ISA is reverting to the standard usr_pcode.htm rather than the customized one after a failed logon? Is this a bug?

    Cheers,
    Mylo

    ReplyDelete
  2. Hi Jason,

    Nice article! I've been configuring an OTP web listener recently (not SecurID) but have noticed that if you use a custom form on a web publishing rule (lets call it WEB), that if some reason the user fails to login correctly (e.g. presses logon by mistake), that ISA falls back to the default style/form ... i.e. the standard usr_pcode.htm and not the customised one being used.

    Any idea why ISA is reverting to the standard usr_pcode.htm rather than the customized one after a failed logon? Is this a bug?

    Cheers,
    Mylo

    ReplyDelete
  3. >> Mylo

    Hey Mylo,

    Funnily enough I have noticed that too. This is exactly why I prefer making changes via the CSS and not directly editing the HTML (see part 1 of my customising series). However, in this case we DO need to edit the HTML.

    Let me have a look into it...

    Cheers

    JJ

    ReplyDelete
  4. @ Mylo & Jason

    Did you ever identify a ix or the behaviour described above? I have just customised our HTML logon forms only to find that my new URLs disappear upon clicking "Log on".

    Thanks in advance or any advice you could provide - great post.

    ReplyDelete
  5. >> Ben/Mylo

    I have just checked if I get the same behaviour with one of our customer deployments and I can't reproduce it, which is confusing.

    Let me have a look into it to try and see what is different...

    Maybe I missed something in my forms files??? Hopefully it shouldn't be too difficult to fix ;)

    Cheers

    JJ

    ReplyDelete
  6. >> Mylo/Ben

    I have tested this in my lab and I cannot reproduce the problem you are having.

    Are you sure you have carried out the branding process described in Part 1 BEFORE updating the customised usr_pwd_pcode.htm file from Part 2?

    You need to complete customisation from both Part 1 *and* Part 2 to get the correct result.

    Cheers

    JJ

    ReplyDelete
  7. You guys may find this interesting!!!

    FIX: A user who enters an empty user name or password on a customized logon form is redirected to the default error page of ISA Server 2006 instead of a customized error page

    http://support.microsoft.com/kb/968380/

    Cheers

    JJ

    ReplyDelete