次の方法で共有

How to configure Active Synch Trunk for Non-Windows Mobile phones sending out large email attachments

  • [アーティクル]

Accessing corporate emails via Active Synch trunk though IAG is a pretty cool feature. Being in Customer Service and Support Security we come across very diverse and interesting scenarios. A few days ago there was a support call about Active Synch trunk where users were not able to send out pretty heavy emails using their cell phones through IAG. It turned out to be a problem with emails having attachments size of 200K or greater - anything smaller works fine. On further scoping it turned out to be a very specific incident where users are using non-Windows mobile phones only.

Interestingly, some tweaking of an underlying component could make things work as expected so to understand where to look I had to investigate a bit. The OEM Partner who was working with me confirmed the following cell phones models (Nokia E66,E70,E71 Sony-Ericsson P1,P990i, Z770, C902, iPhone) seem to be reporting this behavior.

 

I started working towards identifying the component responsible for this behavior. To start with I had to see what’s happening inside the filter engine so I enabled the verbose logging to reproduce the scenario and then dumped the communication. Enabling tracing of the component involved actually gives quite a lot of detail about IAG activity to better understand how the request is being handled and parsed. It does show lots of function calls and if you do not have source code in front of you then it doesn’t make much sense but if you ignore the function calls and stick to HTTP communication straight away its pretty easy to understand and could make sense out of it.

In this scenario I am interested in looking inside the URLFilter so here are steps required to enable verbose tracing for the URL filter:

 

1. Browse to C:\Whale-Com\e-Gap\von\InternalSite\inc\trace.inc

2. Modify trace_on = false to trace_on = true and save the file

3. Browse to C:\Whale-Com\e-Gap\common\conf\trace.ini

4. Go to the last line of the file and add the following lines:

 

[Trace\WhlFilter]

*=xheavy

 

[note: please turn off this tracing as soon as you are done, as this will generate heavy logging on system]

 

My intention here was to look at the conversation between three entities, Mobile device, IAG filter and the back end CAS Server (Active Synch). Starting with request sent from Mobile phone to IAG filter and then from Filter to Webserver and then response all the way back from web server to IAG filter and eventually to mobile device.

 

 

 

So far all looks as expected. Moving further I can see the response coming back from the CAS server to IAG web filter and again nothing looks wrong here. Web server responded back with HTTP 200.

Now if all looks normal and expected then where is the problem ?

 

 

I decided to deep dive inside the filter engine on the same transactions (conversation) for analysis and uncover each and every expected function call for this communication.

 

 

This is quite a hectic job to analyze the engine tracing as it could contain a lot of data to look at but to keep things simple for this blog post I am cutting short lots of details. Here I was inside the engine, so I looked for errors in the functions that are being called, and found what I was looking for.
Debugging the engine stack showed me the following line in the trace:

 

* at line 0, file "ActiveSyncLogin.asp".

** 15.01.09 13:42:25.761 INTERNALSITE:GENERAL T3276

ERROR: Failed to access [https://187.67.43.10:80/Microsoft-Server-ActiveSync?User=faisal&DeviceId=IMEI372924929164255&DeviceType=IMEI372924929164255&SaveInSent=T&Cmd=SendMail] [007~ASP 0104~Operation not Allowed~]

 

Of course the last bit [007~ASP 0104~Operation not Allowed~] caught my attention and I reverted to my favourite search engine live.com and gave a search on this string and there you go with the exact response.

 

  [007~ASP 0104~Operation not Allowed~] showed interesting bit of information that suggests an amount of data that is larger than the value of the AspMaxRequestEntityAllowed property in the IIS metabase .

If a Content-Length header is present and if the Content-Length header specifies an amount of data that is larger than the value of the AspMaxRequestEntityAllowed property in the IIS metabase. The default value for the AspMaxRequestEntityAllowed property is 204,800 bytes.

 

This is documented in a KB article written for IIS https://support.microsoft.com/kb/327659 .

 

Since IIS is the underlying webserver on which IAG is mounted it was clear that metabase restriction on the webserver was blocking larger email attachments through Active Synch trunk. I increased the value to the required size and there we go, end users using non-Windows mobile could now send email attachments of the desired size through IAG active synch trunk as expected.

Please note best practice is not to tweak IIS metabase unless you know what you are doing but for this particular problem it was acceptable for our support partner and his end customers. Last but not least I don’t know how Windows Mobile handle this scenario but they work fine with larger attachments.

 

Faisal HussainCISSP, MCSE Security, MCSE, MCSA, MCTS

CSS Security - Microsoft UK

Comments