vADC Forum

Reply
Occasional Contributor
Posts: 43
Registered: ‎11-26-2012

Microsoft Exchange and ZXTM :: Delivering a Secure Mobile Solution

(Originally posted July 23, 2006)

Frequent Contributor
Posts: 321
Registered: ‎11-29-2012

Re: Microsoft Exchange and ZXTM :: Delivering a Secure Mobile Solution

Overview

Increasingly, our modern-day workforce requires upward-mobility. It follows that a businesses infrastructure requirements are radically changing to suit their employees' needs. Zeus' Extensible Traffic Manager was designed to co-exist in a mobile environment; sustaining, securing and accelerating the infrastructure a work-force requires to reliably conduct business day-to-day.

Infrastructure software widely deployed to assist with a business' work-mobility is

<a target="_blank" href="http://www.microsoft.com/exchange/en-us/mobile-email-with-exchange-activesync.aspx">Microsoft's Outlook Web Access</a>

.

210iAFAAAA5B6DEAAEDB.png

Integration with ZXTM

Outlook Web Access can be quickly, easily and securely integrated into ZXTM. We recommend that you allow ZXTM to handle the SSL decryption; reducing the cpu stress to your Exchange back-end(s). A HTTP protocol server, listening on port 443, should be setup to handle traffic to your Exchange server. ZXTM will now take care of the rest!


WebDAV Conformity, Exchange and SSL Decryption

Zeus has discovered a requirement to implement a trafficscript solution in situations where a non-standard WebDAV resource is invoked. RFC2518 states that:

There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names.

In certain circumstances, a client will issue a request for /exchange instead of /exchange/. As per the RFC, a webserver will correctly respond by issuing a

<a target="_blank" href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2">301 object permanently moved</a>

header. Let us confirm this by using httpclient .

root@zahn# ./httpclient -m HEAD http://www.zeus.com/about

HTTP/1.1 301 Moved Permanently

Vary: Accept-Encoding

Connection: close

Content-Length: 212

Date: Sun, 23 Jul 2006 03:51:38 GMT

Location: http://www.zeus.com/about/

A client request complete with a trailing slash meets with a different server response code:

root@zahn# ./httpclient -m HEAD http://www.zeus.com/about/

HTTP/1.1 200 OK

In normal circumstances, a client receiving a http 301/302 status code would transparently obey the instruction and a correct GET request issued, complete with trailing slash. With ZXTM performing its magic and taking care of all SSL transactions, a back-end Exchange server is now only HTTP aware. As a consequence, the re-direct issued by Microsoft IIS will be a HTTP based URI. IIS is acting perfectly correctly, but unfortunately the request by the client will not succeed as an Exchange server is often only configured for secure (HTTPS) connections. To confirm this, let's make a HTTP request to a secure site with ZXTM in front, performing SSL-decryption, but without a trailing slash. If what we have talked about above is correct, we will see a Location: banner for a (non-secure) HTTP re-direct.

root@zahn:# ./httpclient -m HEAD -3

<a target="_blank" href="https://www.zeus.com/internal-test">https://www.zeus.com/internal-test</a>

HTTP/1.1 301 Moved Permanently

Content-Length: 212

Date: Sun, 23 Jul 2006 04:05:11 GMT

Connection: close

Location:

<a target="_blank" href="http://www.zeus.com/internal-test/">http://www.zeus.com/internal-test/</a>

So, our real-world test confirms the theory.


TrafficScript Provides a Solution

TrafficScript is a feature-rich scripting language, that presents a quick and easy solution to this problem. The following response rule will inspect traffic, actioning a Location: header re-write on 301 or a 302 status code.

$status = http.getResponseCode();

if (($status == 301) || ($status == 302)) {

        $location = http.getResponseHeader("Location");

        $new_location = string.regexsub ($location, "http://(.?)(/.)",

"https://$1$2");

        http.setResponseHeader("Location", $new_location);

}

Now, with this rule enabled, let's perform our previous test:

root@zahn:# ./httpclient -m HEAD -3

<a target="_blank" href="https://www.zeus.com/internal-test">https://www.zeus.com/internal-test</a>

HTTP/1.1 301 Moved Permanently

Content-Length: 212

Date: Sun, 23 Jul 2006 04:10:53 GMT

Connection: close

Location:

<a target="_blank" href="https://www.zeus.com/internal-test/">https://www.zeus.com/internal-test/</a>

As you can observe, the Location header has successfully been re-written to re-direct the client to a HTTPS URI. Trafficscript in place, you can now allow ZXTM to securely and reliably interact with Microsoft Exchange, working to deliver a first-class mobile business solution for your customers.

Join the Community

Get quick and easy access to valuable resource designed to help you manage your Brocade Network.