There are couple of important things to note here:
#MAC MAIL EXCHANGE 2016 UNABLE TO VERIFY MAC#
Once I got to this point where I was fairly confident that the issue could be presence of “Via” header, I set “Additional L7 Header” from default value of “X-ClientSide” to “None”:Īll there was left to do at this point, was to launch Mail client on Mac and watch it connect. At some point in our discussions, someone had mentioned that inserting “Via” headers are known to negatively impact Mac Mail client.Īs the saying goes, it takes a while to find the root cause, fix is usually quick. When I saw these headers, I remembered the discussion I had with my talented support engineers at KEMP. KEMP LoadMaster uses X-ClientSide header by default. SNAT is recommended when load balancing Exchange servers. The X-ClientSide (or X-Forwarded-For) header is used by proxies and load balancers to preserve original client IP address when SNAT is in use. In this case that is the IP address of the load balancer. The “Via” header indicates presence of a proxy between client and server. While the headers gives you idea of what in included in a normal POST request from the client, for me, the first and last headers were very important. Here’s the most relevant piece of data from the trace file (I have removed unnecessary headers for brevity): When the error occurred, numerous xml files were created by IIS. Now that the trace is enabled and rule configured to capture HTTP 400 error condition, I launched Mac Mail client and reproduced the issue. I had it configured this way only for troubleshooting purpose in my lab and no production data was in flight during testing.
I don’t recommend this configuration in production and KEMP LoadMaster default setup uses more secure ciphers. I was able to decrypt client side traffic due to load balancer configuration of ciphers that didn’t use PFS. Due to newer ciphers which use PFS (Perfect Forward Secrecy) I couldn’t decrypt data being received from load balancer by the server despite having the private key used to encrypt the information. I needed to correlate this with the data being received on the Exchange server. The response included data that was requested by POST operation. Notice how the pattern looks similar to Mac Mail’s second POST request, however, it ends with 200 OK. POST /ews/exchange.asmx 401 Unauthorized POST /ews/exchange.asmx 401 Unauthorized POST /ews/exchange.asmx 200 OK
When comparing that with Outlook for Mac, the pattern looked like the following: However, this time the pattern followed multiple 401 responses from server and ended with 400.
At this point Mac Mail client started with another POST operation to EWS. Notice how initial dialog included challenge response for NTLM authentication and ended with 200 OK. POST /ews/exchange.asmx 401 Unauthorized POST /ews/exchange.asmx 401 Unauthorized POST /ews/exchange.asmx 400 Bad Request
POST /ews/exchange.asmx 401 Unauthorized POST /ews/exchange.asmx 200 OK Looking at the trace captured using Wireshark on the client machine, I noticed the following HTTP dialog:
#MAC MAIL EXCHANGE 2016 UNABLE TO VERIFY FOR MAC#
Microsoft Outlook for Mac did not have issue connecting to Exchange even before we changed 100-continue handling to be RFC-7231 compliant.Īt this point, I decided to look at the network trace. Since we addressed the 100-continue handling in Part 1 of this article, ExRCA tests did not indicate any more issues. Let’s see what we can do to get the Mac Mail to connect successfully to Exchange servers.
0 kommentar(er)
