Booches.nl

ISA 2006 Link Translation

Web pages returned from a Web server published by a Microsoft® Internet Security and Acceleration (ISA) Server 2006 Web publishing rule may include links containing internal names of computers or Web sites and internal paths to Web content. Because external clients cannot resolve these internal names, these links will be broken unless the internal names are replaced by the public names of published Web sites. ISA Server includes a built-in Web filter named Link Translation Filter, which uses mappings to translate internal names in links on Web pages to publicly resolvable names. Each mapping translates an internal URL (or part of a URL) to a public equivalent. For example, a mapping can translate the internal URL http://team to the public URL https://www.team.contoso.com. Link translation mappings are stored in tables called link translation dictionaries.

Today I had a problem where the remote user wanted to request the following URL https://www.booches.nl/configuration/service.jsp. This URL isn’t allowed and needed to be redirected. ISA’s Link Translation was the solution for me. I configured the following Link Translation.

The following Link Translation rule translates the URL above in https://www.booches.nl/configuration/denied.html.

It works for me!!!

ISA 2006 Web Chaining

ISA Web Chaining rules define how traffic will be handled by the proxy server. Web request to specific destination can be handled in different ways by ISA:

1. Retrieve directly from the destination / internet;
2. Forward to an upstream proxy server;
3. Redirect the request to a specific server / web page;

The most popular use for Web Chaining is to chain branch office ISA firewalls with main office ISA firewalls. But also combining two ISP connections is a commonly used scenario for Web Chaining. I often use Web Chaining from ISA server with some kind of upstream proxy server. A lot of organizations use ISA as proxy server and some kind of dedicated appliance (maybe in DMZ environment) as content scanner.

With Web Chaining you can forward all request to the upstream proxy server, which will retrieve the specified destination from the internet. Specific website could have problems with being forwarded to the upstream server. I normally use Web Chaining to directly retrieve these website from the internet without being forwarded to the upstream proxy.

To create a Web Chaing Rule, open the ISA Management Console and navigate to Networks. In the center of the Management Console you will find a tab called Web Chaining. The default Web Chaining rule is configured to forward all request to an upstream proxy server.

The following screenshots tell you how to configure an additional Web Chaining rule to directly retrieve the destination (www.4ip.nl) from the internet.

	Start the creation of a Web Chaining rule by clicking on Task – Create new Web Chaining rule. This will start the New Web Chaining Rule Wizard. Enter a valid name for the newly created Web Chaining Rule.
	Select the destination to which this Web Chaining Rule will apply. I configured an URL set containing the URL: http://www.4ip.nl/*
	On the Request Action page, you configure how you want the Web requests to that particular destination routed by the ISA firewall. The default setting is to route the request directly to the destination Web site. This is exactly what I would like to accomplish. The last step is Finishing the New Web Chaining Rule Wizard.

The newly created Web Chaining Rule is placed above the Default Web Chaining rule in the Web Chaining tab. The rules are matched sequentially, so now all traffic matching the configured URL set will be retrieved directly from the internet. All other traffic will be forwarded to the upstream proxy server.

Change password through LDAPS on ISA server

Today I received the question about allowing users to changes his/her password through webmail, whereby webmail is published via an ISA server 2006 reverse proxy. This is possible, but it requires the configuration of LDAPS to authenticate users.

I started by configuring a Certificate Authority (CA) on a member server in the domain. During the installation of CA a root certificate is generated. You need to export this root certificate with private key. Next I imported the certificate on the reverse proxy server, but didn’t mark the private key as exportable. So the root certificate cannot be exported from the reverse proxy server with its private key in the future. I checked if binding to the Active Directory is possible by using the tool ldp.exe.

The last part is configuring LDAP Validation in ISA. Go to Configuration –> General –> Specify RADIUS and LDAP Servers. First you need to add a LDAP server set, like shown in the following picture.

Important when configuring the LDAP server set is the usage of the FQDN as LDAP server hostname. This FQDN should be exactly the same compared to the FQDN mentioned in the imported root certificate.

The last step is configuring the LDAP server mapping, which is also shown below.

Because I don’t want to add a domain name during the login procedure on the OWA login page, like DOMAIN\USER, I use the Login Expression wildcard character * and link that to the configured LDAP server set. Now you can login with just username and password, instead of domain\username and password.

Next I configure a OWA Publishing policy like always, but on the Listener I use LDAP as authentication mechanism. On the Listener Forms tab you can enable or disable the options:

• Allow users to change their passwords;
• Remind users that their passwords will expire in this number of days;

These options add some extra option to the OWA login page. Another step to configure is the allowed users. In most environments I use the group Domain Users as allowed OWA group, because mostly all users are allowed to use OWA, else you need to configure a separate user group in Active Directory. On the Users tab you remove the All Authenticated Users and click Add. You need to define a new user group, like shown below.

This means that if you are member of the group Domain Users, you are allowed to use OWA.

The last step is configuring the public path. When logged in to OWA, you have the option to change your password through the options page. To use this feature, you need to added another path to the Path configuration in the reverse proxy server. The path, which should be added, is /iisadmpwd/*, where the External Path is the same as the Internal Path.

Over at isaserver.org, Thomas Shinder wrote a great post about using LDAPS with OWA and multiple domains. The article is called LDAP Pre-Authentication with ISA 2006 Firewalls: Using LDAP to Pre-Authenticate OWA Access.

Automatic Log In Reverse Proxy with FBA

Recently I configured another ISA 2006 server as reverse proxy to publish the Exchange 2007 OWA environment on a secure way to the internet. The customer where I configured the reverse proxy is migrating from Novell GroupWise to Microsoft Exchange.

During the migration period, the customer has specific requirements when connecting to the webmail environment from the internet. The customer is using GroupWise and OWA next to each other. He build an own log in page for webmail. The user enters this credentials, which are check against a directory with the help of LDAP. Depending on the LDAP group the user is member of, he is redirected to GroupWise webmail or OWA.

The problem was that when the client gets redirected to OWA, he had to provide his credentials a second time to log in to OWA. The customer wants to use Single Sign On, so the user credentials should be automatically posted on the OWA sign in page. The customer has the option to edit his own sign in page, so specific parameters can be added when redirecting the client to the ISA 2006 reverse proxy.

I had to figure out, which URL is posted to the ISA reverse proxy after the user credentials are entered in the web browser. I started to search the internet and different forums, but the solution wasn’t found. So there was nothing else left, than starting the good old sniffer and capture the complete process. I always use WireShark as sniffer, which is a very powerful tool. I added a filter so only the traffic to and from the ISA 2006 server is captured.

I started the sniffer, logged in on the ISA 2006 server, stopped the sniffer and started analyzing the sniffer results. After some digging I found the POST statement, which is displayed below.

Looking at the POST statements, I now knew the exact URL which is posted to the ISA 2006 server. I copied the URL to notepad, changed the username and password to another account. Copied the new URL and pasted that one in my browser and HIEHOE. After hitting enter, I don’t get any sign in page, but get directly to my webmail. So exactly as the customer wants.

The default POST URL has the following format:

https://<DNS name>/CookieAuth.dll?Logon?curl=Z2Fowa&flags=0&forcedownlevel=0& formdir=1&trusted=0&username=<username>&password=<password>
&SubmitCreds=Log+On

Exchange 2007 with ISA 2006

Today I have be working on publishing Microsoft Exchange Outlook WebAccess and Active Sync to the Internet. We had some discussions with some Microsoft Consultants about a secure way to publish Outlook Web Access to the Internet, especially the authentication part of such a solution.

Some people are talking about publishing OWA directly to the Internet. In my opinion, this results in a major security thread, because you directly publish a TCP/80 and TCP/443 connection from the Exchange server to the Internet. An vulnerability or exploit in these services could end up in an hacker who takes over the Exchange server.

A second solution is placing a front-end server in a DMZ segment, but making the server a domain member for authentication. In my opinion still a security leak, because somebody who hacks the DMZ server has maybe the ability to hack or corrupt the Active Directory.

The third solution, and the solution we advise, is using a Microsoft ISA 2006 server as a front-end server in the DMZ. We configure a RADIUS or LDAPS (if you would like the option to change the password) connection to a RADIUS server or a domain member on the internal LAN segment. This ensures a secure way of authenticating users and even if somebody hacks the ISA server, he still hasn’t hacked a domain member server or a vulnerability in TCP/80 or TCP/443 of the Exchange server.

I have had a lot of help of an article on isaserver.org from Thomas Shinder while configuring the solution. I had some problems with publishing Active Sync. Ended up with enabling Basic Authentication on the Active Sync virtual directory (Microsoft-Server-ActiveSync).