Exchange 2010 iApp problems with Mac OSX 10.8 Mail App

Hi Josh, there's an RC2 version of the template on DevCentral now that includes a few fixes and updates: https://devcentral.f5.com/wiki/iApp.Microsoft-Exchange-2010-and-2013-iApp-Template.ashx

 

 

The template should create either an OA or EWS pool, depending on selections made at run time. Is the OA or EWS pool healthy and if so, do other EWS requests also fail (free/busy from a MAPI client, for example)?

 

 

Can you connect directly to EWS using the EWS Editor: http://ewseditor.codeplex.com/

 

 

Can you paste the contents of your _combined_persist_rule here?

 

thanks

 

Mike

 

Mike,

 

 

I'll try RC2 when I can, but this is a production environment so it may be tricky to upgrade. What is the best way to upgrade? Do I need to completely rebuild the iApps?

 

 

OA pools are healthy. EWS requests, such as free/busy from MAPI clients are working correctly.

 

 

I was able to use EWSEditor w/ AutoDiscover to connect properly.

 

 

Thanks,

 

 

Josh

 

iRule:

 iRule to select pool and persistence method when all HTTP-based services are
 accessed through the same virtual server. This iRule uses an HTTP header
 inserted by a BIG-IP Edge Gateway for persistence (if that header is present)
 Otherwise it will set persistence according to traditional methods.
when HTTP_REQUEST {
    switch -glob -- [string tolower [HTTP::path]] {
    "/microsoft-server-activesync" {
         Direct all ActiveSync clients to a common pool; use Auth
         header value if it exists (Basic auth only, which is the
         default); otherwise we fall back to client IP
        if { [HTTP::header exists "APM_session"] } {
            persist uie [HTTP::header "APM_session"] 7200
        } elseif { [HTTP::header exists "Authorization"] } {
            persist uie [HTTP::header "Authorization"] 7200
        } else {
            persist source_addr
        }
        pool FC_EX2010_DC1_CAS_as_pool3
        
        CACHE::disable
        return
    }
    "/owa*" {
         Outlook Web Access
        if { [HTTP::header exists "APM_session"] } {
            persist uie [HTTP::header "APM_session"] 7200
        } else {
            persist cookie insert 0
        }
        pool FC_EX2010_DC1_CAS_owa_pool3
        return
    }
    "/ecp*" {
         Exchange Control Panel.
        if { [HTTP::header exists "APM_session"] } {
            persist uie [HTTP::header "APM_session"] 7200
        } else {
            persist cookie insert 0
        }
        pool FC_EX2010_DC1_CAS_owa_pool3
        return
    }
    "/ews*" {
         Exchange Web Services.
        if { [HTTP::header exists "APM_session"] } {
            persist uie [HTTP::header "APM_session"] 7200
        } else {
            persist source_addr
        }
        pool FC_EX2010_DC1_CAS_oa_pool3
        
        CACHE::disable
        return
    }
    "/oab*" {
         Offline Address Book. Persistence is not required for OAB
        pool FC_EX2010_DC1_CAS_oa_pool3
        return
    }
    "/rpc/rpcproxy.dll" {
        if { [HTTP::header exists "APM_session"] } {
            persist uie [HTTP::header "APM_session"] 7200
        } elseif { [string tolower [HTTP::header "Authorization"]] starts_with "basic" } {
            persist uie [HTTP::header "Authorization"] 7200
        } else {
            persist source_addr
        }
         Outlook Anywhere.
        pool FC_EX2010_DC1_CAS_oa_pool3
        
        CACHE::disable
        return
    }
    "/autodiscover*" {
         Autodiscovery. No Persistence.
        pool FC_EX2010_DC1_CAS_ad_pool3
        return
    }
    default {
         This final section takes all traffic that has not otherwise
         been accounted for and sends it to the pool for Outlook Web App
        if { [HTTP::header exists "APM_session"] } {
            persist uie [HTTP::header "APM_session"] 7200
        } else {
            persist source_addr
        }
        pool FC_EX2010_DC1_CAS_owa_pool3
    }}
}
when HTTP_RESPONSE {
    if { [string tolower [HTTP::header values "WWW-Authenticate"]] contains "negotiate"} {
        ONECONNECT::reuse disable
        ONECONNECT::detach disable
        NTLM::disable
    }
        if {[HTTP::header exists "Transfer-Encoding"]} {
        HTTP::payload rechunk
    }
} 

Since it seems like other EWS requests are making it through the BIG-IP and the iRule looks OK, I would focus on the client side of the connection. I assume that the Mac is indeed configured to use SSL. You may want to tcpdump the client side traffic to get a better idea of what's happening there; you'll need the private key for the cert used by that virtual server to decrypt the traffic. F5 support can assist with that.

Ok, I may need to open a case. We are also getting reports of several Android devices not able to send mail (they can receive normally). The Android device just reports "Unable to report to server"

 

 

I did have to disable strict updates on the iApp so I could add the CA's chain certificate to the SSL profile. Could this be causing any issue? This had to be done to get rid of lots of Android warnings regarding SSL.

The disabling of strictness shouldn't cause any issues with performance or functionality. Please do open a case, and if you like you can send me the case number in a private message so I can track the progress.

Dropped you an email with a case number.

 

 

Thanks!

Mike,

 

 

I'm seeing what may be something strange in the ssldump. The client makes several autodiscover requests which Exchange answers with a HTTP/401. The first response has a Set-Cookie header:

 

 

Set-Cookie: BIGipServerFC_EX2010_DC1_CAS.app~FC_EX2010_DC1_CAS_ad_pool3=2690390700.20480.0000; path=/

 

 

The next post has a Cookie header:

 

 

Cookie: BIGipServerFC_EX2010_DC1_CAS.app~FC_EX2010_DC1_CAS_ad_pool3=2690390700.20480.0000

 

 

The response to this POST is another HTTP/401.

 

 

Next, the client tries to POST again, this time the POST has an "Authorization" header that appears to contain an NTLM token. Exchange, again, returns a HTTP/401 with a WWW-Authenticate header included in the response this time.

 

 

Now the client does another POST to autodiscover, this time with a different "Authorization" header. Finally, Exchange returns a HTTP/200.

 

 

Now that the autodiscover process is complete, the client POSTs to /ews/exchange.asmx. There is no "Authorization" header present in this request, and Exchange returns another HTTP/401 Unauthorized. This same POST/response/401 cycle happens several times. Occasionally before the Exchange server responds with a HTTP/401, I see this in the capture:

 

 

POST /ews/exchange.asmx HTTP/1.1

 

...

 

...

 

27 13 0.0498 (0.0000) C>SV3.1(632) application_data

 

---------------------------------------------------------------

 

IdOnly---------------------------------------------------------------

 

27 14 0.0501 (0.0003) C>SV3.1(22) Alert

 

level warning

 

value close_notify

 

27 0.0501 (0.0000) C>S TCP FIN

 

27 0.0512 (0.0010) S>C TCP FIN

 

25 13 0.1433 (0.1071) C>SV3.1(22) Alert

 

level warning

 

value close_notify

 

25 0.1433 (0.0000) C>S TCP FIN

 

25 0.1433 (0.0000) S>C TCP FIN

 

26 13 0.0970 (0.0611) C>SV3.1(22) Alert

 

level warning

 

value close_notify

 

26 0.0970 (0.0000) C>S TCP FIN

 

26 0.0971 (0.0000) S>C TCP FIN

 

New TCP connection 28: 172.28.1.234(49220) <-> 172.26.137.125(443)

 

 

 

Then, the SSL session ends and the POST cycle starts again. I don't actually see the 401 in this response. As far as I can tell the POST to /ews/exchange.asmx never succeeds. Exchange either returns a HTTP/401, or I see this weird SV3.1(22) Alert/close_notify snippet. Any idea what this means? It only happens with these MAC clients.

 

 

Thanks!

 

Hi Josh, the authentication sequence for Autodiscover is correct, although I see that there is an error in our iRule (we shouldn't be sending a cookie back for Autodiscover requests, since it doesn't require persistence). We'll get that updated in the next version of the template.

 

 

Do you see any auth headers being sent by the Mac client for EWS requests? In the 401 response, is there an auth header advertising which methods the server is supporting?

 

 

Also, does the cert configured on the CAS (and BIG-IP) include the host name that the Mac clients are requesting in the EWS POSTs?

 

Mike

Mike,

 

 

Yes, I do see some headers like this in a few of the EWS requests:

 

 

Cookie: exchangecookie=dcd880f3e5184c4792d326f2db310b08

 

Connection: keep-alive

 

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

 

 

A 401 is returned from Exchange. Immediately following is another POST for EWS, this time with another Auth header:

 

 

POST /ews/exchange.asmx HTTP/1.1

 

Host: something.ex.com

 

User-Agent: Mac OS X/10.8.3 (12D78); ExchangeWebServices/3.0 (157); Mail/6.3 (1503)

 

Content-Length: 612

 

Accept: */*

 

Content-Type: text/xml; charset=utf-8

 

Accept-Language: en-us

 

Accept-Encoding: gzip, deflate

 

Cookie: exchangecookie=dcd880f3e5184c4792d326f2db310b08

 

Connection: keep-alive

 

Authorization: NTLM TlRMTVNTUAADAAAAGAAYAEAAAADcANwAWAAAAAAAAAAAAAAADgAOADQBAAASABIAQgEAAAAAAAAAAAAABYIIACGR89qbiUSBwBo8kjJ3V5xgGbFr0Ke/j9/CxY6Q7HE18Kj5IR0IZF0BAQAAAAAAAKCfmhSAXM4BYBmxa9Cnv48AAAAAAgAEAE4AQQABABoAVwBSAFgAWABFAE4AVABFAFgATQBCADAAMQAEABwAbgBhAC4AZgBvAGwAbABlAHQAdAAuAGwAYQBuAAMAOABXAFIAWABYAEUATgBUAEUAWABNAEIAMAAxAC4AbgBhAC4AZgBvAGwAbABlAHQAdAAuAGwAYQBuAAUAFgBmAG8AbABsAGUAdAB0AC4AbABhAG4ABwAIAKFcaRSAXM4BAAAAAAAAAABzAGcAdQBtAGIAbABlAGwAbwBjAGEAbABoAG8AcwB0AA==

 

 

The response then has the "weird" stuff instead of a 401:

 

 

6 13 0.0415 (0.0000) C>SV3.1(632) application_data

 

---------------------------------------------------------------

 

IdOnly---------------------------------------------------------------

 

6 14 0.0415 (0.0000) C>SV3.1(22) Alert

 

level warning

 

value close_notify

 

6 0.0415 (0.0000) C>S TCP FIN

 

6 0.0431 (0.0016) S>C TCP FIN

 

 

Yes, the cert does include the hostname that the Mac clients are requesting in the EWS POSTs.

 

 

Josh