Securing OWA with Web Application Proxy

Securing OWA with Web Application Proxy

 

One of the first big projects that I had the opportunity to manage was our migration from Exchange 2007 to Exchange 2013.

 

This project came with a few challenges we needed to solve in order to fully migrate from Exchange 2007 to Exchange 2013. One of the biggest concerns was how we were going to secure OWA access. Our current solution was ISA Server which was outdated and not compatible with Exchange 2013. Naturally I looked into Forefront Server which was Microsoft’s replacement product for ISA, until I found that it too was discontinued.

 

I checked into some 3rd party solutions such as Citrix NetScaler VPX and KEMP. Both products would do what we wanted, but the cost associated with each made them undesirable. After doing some more research I found an article on Web Application Proxy utilizing ADFS as a single sign on solution. Since WAP was built into Server 2012 R2, the price point was perfect for us.

 

An added benefit to utilizing WAP with an ADFS solution, was that we now had a base for future SSO implementations for other applications.

 

There are two different ways to setup WAP, claims based, or Kerberos delegation. Kerberos required putting an ADFS Server outside the firewall into the DMZ, possibly exposing your Active Directory environment. This was not something I felt comfortable with, so we went with claims based.

 

Our current environment now mimics this diagram fairly accurately:

 

One of the resources I used to get everything setup was this page. The script will need to be modified to your specific environment, but it’s a good starting point.

Some important points to keep in mind when building out your ADFS environment:

  • Your ADFS server name should be different than your ADFS service name. This will cause errors and prevent a successful deployment.
  • Make sure your SSL certs are not exposing your internal server names. You can use a certificate for external access and a separate one for internal clients/servers.
  • Make sure your DNS servers are setup properly. Recommend using split brain DNS. This simplifies management, and these days there’s no reason to use a .local domain suffix in a production environment.
  • WAP will automatically update the token signing and token decryption certificates. These auto renew on the ADFS Server by default. You can extend the certificate expiration interval and would recommend aligning this with your other certs. This will reduce the downtime required to update the certs on all your applications.
  • When the token signing cert is updated, you need to export it from your ADFS Server and import it into your Exchange servers under “Trusted Root Servers”. Once that is done you need to restart IIS on Exchange and possibly restart WAP services as well. Very important to keep tabs on the certificate expiration dates to prevent any unintended service interruptions.
  • An important note for Android users! Make sure you define your default certificate on your WAP, otherwise Android devices may have issues connecting.
    • Here is a good article that explains what SNI is – LINK
    • Open an admin command prompt on your WAP system and type the following:
      • netsh http add sslcert ipport=0.0.0.0:443 certhash=certthumprint¬†appid={f955c070-e044-456c-ac00-e9e4275b3f04}
      • certthumbprint will be the thumbprint from the SSL cert you intend to use.

Here is the script from the Microsoft Blog page – Use at your own risk! ExchangeADFS Setup script

Please feel free to leave a comment or question below.

Leave a Reply

Your email address will not be published. Required fields are marked *