Wednesday, 18 February 2009

Resource Guide for Microsoft Active Directory Communications and ISA Server Firewalls

Based upon my work with ISA Server for various implementations, I often have to create firewall policies that permit Active Directory communications to traverse different ISA Server networks.

I thought it would be useful to try and create a quick blog entry that captures some of the key information in order to provide a basic resource guide. This mainly includes the necessary protocol sets that are required for the two most common types of Active Directory communication, namely:

  • Domain Member Communications (From Domain Members to Domain Controllers)
  • Domain Controller Replication Communications (From Domain Controllers to Domain Controllers)

Please Note: For information on Active Directory communications when using forest trusts, please see my previous blog entry called Using ISA Server 2006 to Protect Active Directory One-Way Forest Trusts.

So, considering the first scenario:

Domain Member Communications – Required Protocols

  • DNS (53/tcp and 53/udp)
  • Kerberos-Adm (UDP) (749/udp)
  • Kerberos-Sec (TCP) (88/tcp)
  • Kerberos-Sec (UDP) (88/udp)
  • LDAP (389/tcp)
  • LDAP UDP (389/udp)
  • LDAP GC (Global Catalog) (3268/tcp)
  • Microsoft CIFS (TCP) (445/tcp)
  • Microsoft CIFS (UDP) (445/udp)
  • NTP (UDP) (123/udp)
  • PING (ICMP Type 8)
  • RPC (all interfaces) (135/tcp)

and the second scenario:

Domain Controller Replication Communications – Required Protocols

  • DNS (53/tcp and 53/udp)
  • Kerberos-Sec (TCP) (88/tcp)
  • Kerberos-Sec (UDP) (88/udp)
  • LDAP (389/tcp)
  • LDAP (UDP) (389/udp)
  • LDAPS (636/tcp)
  • LDAP GC (Global Catalog) (3268/tcp)
  • LDAPS GC (Global Catalog) (3269/tcp)
  • Microsoft CIFS (TCP) (445/tcp)
  • Microsoft CIFS (UDP) (445/udp)
  • NetBios Datagram (138/udp)
  • NetBios Name Service (137/udp)
  • NetBios Session (139/tcp)
  • NTP (UDP) (123/udp)
  • PING (ICMP Type 8)
  • RPC (all interfaces) (135/tcp)

Please Note: The protocol names defined above are based upon the default display names used in ISA Server, and they may be different for other firewalls. Respective udp/tcp ports are therefore provided in brackets for clarity.

Due to the default behaviour of the ISA Server RPC filter, you can simply use the in-built RPC (all interfaces) protocol and ISA Server will automatically handle the dynamic nature of the RPC protocol and RPC endpoint mapper requests. However, if you are using other firewalls, you many need to replace the RPC (All interfaces protocol with the following two protocols:

  • RPC Endpoint Mapper (135/tcp)
  • RPC Dynamic Ports (1024-65535/tcp)

Please Note: Alternatively, you may wish to define static port ranges for RPC, as discussed in the follow Microsoft knowledgebase article How to configure RPC dynamic port allocation to work with firewalls.

I have read that it is possible to remove some of the above “less desirable” protocols, Ping/ICMP for example. However, in my experience this can often lead to adverse effects in terms of performance; whereby delays can occur with authentication and Active Directory user/group/computer enumeration. I believe this is due to some form of protocol fallback where you have to wait for a denied protocol (Ping/ICMP for example) to timeout before an alternative protocol (LDAP Ping for example) is tried instead. Hence overall functionality is not impaired, but it is necessary to wait for timeouts to occur, which is not ideal unless absolutely necessary.

Finally, it is recommended to use route-based network relationships between all ISA networks that involve Active Directory communications, as this negates potential issues that can occur when using Network Address Translation (NAT).

A list of appropriate references is provided below for further bedtime reading :)

Active Directory focused:

How to configure a firewall for domains and trusts

Active Directory in Networks Segmented by Firewalls

Active Directory Replication over Firewalls

Domain and Forest Trust Tools and Settings

Service overview and network port requirements for the Windows Server system

Restricting Active Directory replication traffic and client RPC traffic to a specific port

Windows 2000 Resource Kit Tool: Rpccfg.exe (RPC Configuration Tool)

ISA Server focused:

Segmenting Networks with ISA 2004 – Filtering access to Domain Controllers

Allowing Intradomain Communications through the ISA Firewall (2004)

Using ISA Server 2006 to Protect Active Directory One-Way Forest Trusts

So, not exactly ground-breaking information, but hopefully handy for those looking for a concise list of Active Directory related protocols (with associated references) when defining ISA Server firewall policies.

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:


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:


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:


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:


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


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


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



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



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



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




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:


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)


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!