Exchange 2013 CU2 redirection of OWA from HTTP to HTTPS

There's a lot of mis-information out there on the net right now about how to properly do redirection of the Outlook Web Access URL from an HTTP request to an HTTPS request. Most of this is due to how Exchange and OWA have changed over the past few versions... but some of this confusion comes from Microsoft itself, and their Technet articles! If you check out the Technet article "Simplify the Outlook Web App URL" at http://technet.microsoft.com/en-us/library/aa998359%28v=exchg.150%29.aspx, the article guides you through modifying the SSL settings, changing the HTTP redirect option, then going back through and cleaning up the mess you made in IIS due to properties inheritance on sub directories of the default website. What's worse, it doesn't even work!

 As it turns out, this process is actually just a copy/paste from the Exchange 2010 process: http://social.technet.microsoft.com/wiki/contents/articles/921.simplify-the-outlook-web-app-url-in-exchange-server-2010.aspx

So... what's the right way to do this? A custom error page! It's so much simpler than all of the mess above, and the changes that are made to IIS7 to make it happen are much less intrusive, requiring no cleanup or anything.

1) First of all, log into your Exchange 2013 CU2 CAS server and open IIS7.

2) In the IIS7 Management Console, expand sites and select the Default Web Site (not the Exchange Back End site!)

3) In the center area, double click on the Error Pages icon, then on the right hand side under Actions click on "Add".

4) In the Add Custom Error Page window, under status code, enter 403.4. For the response action, select the third option "Respond with a 302 redirect" and under the Absolute URL field enter your full url, such as https://email.domain.com/owa. Don't forget the /owa on the end! Click OK to close the window.

5) Open up a command prompt and type "iisreset" to apply the changes.

That's it! Now try browsing to http://email.domain.com and validate that you are indeed redirected to https://email.domain.com/owa. So much easier! The other real benefit is that you can leave the "require SSL" box checked on the default website and OWA subdirectory using this process, and you don't have to mess with the HTTP redirect option, which has the tendency to break all of your subdirectories by applying the redirection to them as well!

Port Address Translation and NAT in Cisco ASA 9.1

I spent way too much time on this issue not to make an entry about it... hopefully this will save someone else the 12 hours of my life that Cisco snatched away from me with this little gem.

I recently had the (dis)pleasure of upgrading an older Cisco ASA 5510 from ASA 8.3 to the latest release... ASA 9.1. The system was stuck several revisions behind due to the memory limitations they imposed after 8.3, which required adding 1GB of memory to the system. The upgrade went well enough, no errors and internet access worked fine on first boot... however... it was quickly noted that outgoing email wasn't working. A bit of poking around revealed that the customer's spam filtering smart host, which was situated in the DMZ, was not sending email over the IP it was NAT'ed to... it was sending it out over the interface IP instead, causing SPF failures and mail rejection.

I spent hours building and rebuilding the NAT (which is completely different from the syntax in 8.3 mind you, so there was some learning curve here)... the lack of documentation online for our particular situation only exacerbated the problem. The key here was that the customer had a single external IP address that was previously responsible for both SMTP and HTTPS traffic... however... they had two internal hosts, a spam filter for SMTP in the DMZ, and an Exchange server for HTTPS in the LAN. In 8.3, it was a simple matter of doing a dynamic PAT for each host, assigning the IP that we wanted to NAT to and specifying the port it should use, with a matching ACL. Not so in 9.1!

Anyway, I'll spare you the endless futile attempts to figure out what eventually worked... and jump right into the code. First, I had to create TWO objects for each host that I wanted to have a PAT to (you'll see why in a minute):

object network Barracuda 

   host 192.168.12.3

object network Exchange 

   host 192.168.11.11 

object network Exchange-SPAT 

   host 192.168.11.11 

object network Barracuda-SPAT 

  host 192.168.12.3

 
Next, I set up my access control lists:

access-list outside_in extended permit tcp any4 object Exchange eq https

access-list outside_in extended permit tcp any4 object Barracuda eq smtp

access-list DMZ_access_in extended permit tcp object Barracuda object Exchange eq smtp

 Finally, I created my NATs:

!

object network Barracuda

nat (DMZ,OUTSIDE) dynamic ExchangeExtIP

object network Exchange

nat (INSIDE,OUTSIDE) dynamic ExchangeExtIP

object network Exchange-SPAT

nat (INSIDE,OUTSIDE) static ExchangeExtIP service tcp https https

object network Barracuda-SPAT

nat (DMZ,OUTSIDE) static ExchangeExtIP service tcp smtp smtp

! 

nat (INSIDE,OUTSIDE) after-auto source dynamic any interface

nat (DMZ,OUTSIDE) after-auto source dynamic any interface

So... see what I did there? In the NAT statements, I ended up having to NAT the ip of each server TWICE... once as dynamic to the external IP address I wanted it to be NAT'ed to in the first two nat statements, and then again to the same ip as the first NAT, except this time specifying the incoming port for each server as static. Clear as mud? Yeah, same for me.

Apparently, this causes the incoming traffic to utilize the second two NAT statements (effectively the PAT statement from the 8.3), but the other two regular NAT statements are required to have the machines use the same IP for outgoing traffic.

The final two NAT statements above are just my regular interface dNAT entries, telling all other LAN and DMZ devices to utilize the interface IP for outgoing traffic.

Hopefully this helps someone else out there!