I have installed multiple reverse proxy servers based on Microsoft ISA 2006. These reverse proxy servers are mainly deployed to publish services like Outlook WebAccess, PDA synchronization, SharePoint or regular websites. Services like Outlook WebAccess are published using secure session protected by SSL certificates. Microsoft ISA server uses “Listeners” to match and intercept traffic from public users.
I have seen multiple ISA publishing rules with only match traffic when the user enters the specific URL in the browser. Let’s take OWA as an example. When users would like to access OWA, they need to enter the following URL: https://webmail.booches.nl/owa. The base URL is webmail.booches.nl and users need to add /owa manually, because internally the Exchange server is configured with a virtual directory called owa. Sometimes I see Listeners configured for HTTP and HTTPS and all HTTP traffic is redirected to HTTPS.
Is this solution user-friendly? What happens when the users makes a typo and enters http://webmail.booches.nl/ower? I try to configure the publishing rules to be user-friendly and I always configure separate Listeners for HTTP and HTTPS traffic. When publishing OWA I configure 3 firewall policy rules.
The first rule uses a Listener, which is configured for HTTP-only traffic and doesn’t use authentication. The firewall policy is intended for All Users and there is no authentication delegation.
|Action for HTTP and HTTPS redirect is to block the request and redirect the request to the correct URL for OWA|
|The Listener for HTTP is configured without Authentication method and the rule is intended for All Users|
|The public path contains /*|
The second rule uses a Listener for HTTPS-only traffic and uses HTML Forms Authentication with LDAP, RADIUS or another authentication method. The associated firewall policy is intended for all Authenticated Users and uses authentication delegation based on Basic Authentication or Negotiate (NTLM / Kerberos) authentication.
|The Listener for HTTPs is configured with FBA as authentication method and the rule is intended for Authenticated Users. The authentication delegation is configured for Basic Authentication or Negotiate|
|The public path configuration contains the appropriate Exchange virtual directories|
The third firewall policy uses the same Listener as the second rule, but doesn’t use authentication delegation and is intended for all users. The configuration of the path, users and authentication delegation is the same as the first rule.
When you need to publish additional services, like ActiveSync or Outlook Anywhere, you have to add the specific publishing rules between the second and the third rule, so the redirection doesn’t mess up your publishing.
This setup is very user-friendly, at least that’s my opinion. The public user only needs to type the base URL (webmail.booches.nl) correct and he is always redirected to the OWA sign-in page. Service like ActiveSync or Outlook Anywhere are automatically configured to use the correct public path (/Microsoft-Server-ActiveSync or /rpc).
Lately I noticed something strange. I configured an ISA server as reverse proxy for OWA. The customer demanded the ability for users to change their password through OWA. I configured the OWA listener with LDAPS authentication against the Active Directory and enabled the option to select “I want to change my password after logging on” like shown below.
I tested the environment by logging in and changing the password. Everything looks okay and the password is changed correctly. I tried some extra test. I opened another browser and tried to login with the old password, which succeeded. I could now login with the old and the new password.
Strange to me…..so I tried some more test. The customer is using an SSL portal with RADIUS authentication to the same Active Director. So I tried to log in with the old and new password. I guess you know the answer. It was possible to login with both password. Another test was login in to the network components, which also use RADIUS against the Active Directory. Again the test were positive.
The last test was login in on a workstation. With this test, I could only login in with the new password and not the old one. Strange to me…… After one hour I tried again, and this time it was only possible to login with the new password.
I guess there is some kind of period where you can use both password. Maybe someone noticed this before and knows more about it…
Microsoft IAS server is often used as RADIUS server to authenticate VPN users or in conjunction with ISA reverse proxy to authenticate OWA users or PDA synchronization.
Today I had to install an ISA reverse proxy server with ISA 2006 Standard and Exchange 2007. I wanted to install Microsoft IAS as RADIUS server to authenticate the OWA users. Normally I install IAS on one, but preferably, on two domain controllers. I logged in on a domain controller through RDP. I noticed that the OS of the domain controller was Windows Server 2008.
Cool, finally working with a Windows Server 2008. After getting familiarized with the new view and layout, I started to search for a way to add the needed Windows component IAS. After searching for a while I found how to add Windows component. Looking at the complete list, I couldn’t find the Internet Authentication Service.
Oops, did Microsoft remove the IAS functionality from its server platform??? After googling for a second, I found that IAS has been replaced by Network Policy and Access Server service in Windows 2008.
Microsoft TechNet told me the following:
Network Policy Server (NPS) is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy in Windows Server 2008. NPS is the replacement for Internet Authentication Service (IAS) in Windows Server 2003.
As a RADIUS server, NPS performs centralized connection authentication, authorization, and accounting for many types of network access, including wireless and virtual private network (VPN) connections. As a RADIUS proxy, NPS forwards authentication and accounting messages to other RADIUS servers. NPS also acts as a health evaluation server for Network Access Protection (NAP). Source
After installing NPS, I started the configuration. You really have to get familiar with the way Windows Server 2008 works. There are a lot of different wizard and multiple configuration options to choose from. Everything looks a bit more fancy. NPS is not only a replacement for IAS, but has also many enhancements.
More information about installing and configuration Network Policy Server can be found in the article Understanding the new Windows Server 2008 Network Policy Server on WindowsNetworking.com. Here you can read that NPS has a lot of functions related to Network Access Protocol (NAP). A very detailed example of using NPS to perform NAP can be found in Brian Posey’s series An Introduction to Network Access Protoction.
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>
I implemented different ISA 2006 Reverse Proxy servers in conjunction with Microsoft Exchange 2003 or Windows Exchange 2007.
Today I configured ISA 2006 with Exchange 2007. I configured the Reverse Proxy server as I did always. And the connection from outside the network works perfectly. On the internal Exchange server I configured Basic and Integrated Authentication on the OWA virtual directory. The problem is that internal users now automatically log in to their webmail box when entering the URL from the Exchange server.
This is not the desired configuration, because internal users should be able to open other people’s mailboxes by logging in as that user. The customer also has an ISA 2006 on the internal network for forwarding proxy purposes.
I decided to publish Exchange 2007 on the internal ISA 2006 server as well. The configuration should use Form Based Authentication (FBA) over HTTP. After configuring and trying the connection, the user can’t access the ISA logon page. In the logging you find that Authentication over HTTP isn’t allowed.
Error Code: 403 Forbidden. ISA Server is configured to block HTTP requests that require authentication. (12250)
This is a default setting in ISA 2006 which can be disable. To allow Authentication over HTTP go to the Listener configuration. Go to the Authentication tab and Select Advanced. In the next tab enable the option Allow client authentication over HTTP. This option enables the using FBA over HTTP.