Posts Tagged ‘IPhone’

Exchange Activesync Issue: Device is able to authenticate, however it will not sync.

In Exchange, IOS, Server Activesync on October 26, 2011 at 11:31

We have recently taken our solution for Exchange email on IOS devices into production. We are using client certificate authentication on TMG and we use MobileIron to manage the devices and handle the certificate enrollment on the devices.

We had an issue where our root CA’s crl had expired, which as could be expected led to a situation where no one could sync their email. After tackling that problem one user was still not able to sync. That user had been part of the pilot group so we first cleaned up the certficate clutter for that user account, but he was still not able to sync.

As I mentioned before, we use client certificate authentication on TMG, but no delegation to our CAS servers. And since the authentication on TMG worked as expected for that user we decided to examine the logs on the CAS server.

In IIS logs the following error was logged:

2011-10-25 13:29:25 W3SVC1 *.*.*.* POST /Microsoft-Server-ActiveSync/default.eas User=hartj&DeviceId=Appl*********&DeviceType=iPhone&Cmd=SendMail&SaveInSent=T&Log=V121_LdapC0_LdapL0_RpcC9_RpcL15_Ers1_Pk0_Error:DeviceIsBlockedForThisUser_ 443 *******\[USERNAME] *.*.*.* Apple-iPhone3C1/901.334 403 0 0
This confirmed that the authentication worked, because otherwise the device would not be able to get to the CAS server in the first place. So we turned to Google 🙂 This led us to this excellent article on the german site EAS Authentizirung
This article described blocking access to Activesync based on IMEI or device ID. When the device id is not present in the ActivesyncAllowedDeviceIDs attribute the DeviceIsBlockedForThisUser is logged in the IIS logs and in tthe event viewer:
The article on blocking devices also showed us how to fix this issue – we manually added the DeviceID to the user using the set-casmailbox command:
Set-CasMailbox [USER] –ActiveSyncAllowedDeviceIDs [DEVICEID].
We still have no clue why this happened – either something went wrong while we were troubleshooting the certificate issues or somehow the device partnership was corrupt ( even though we had deleted that manually before with no result).

Microsoft Server Activesync, Iphone and client certificates issues

In Exchange, Unified Communications on November 16, 2010 at 16:32

At my company we are currently performing a pilot to see if we can offer corporate email to users through an Iphone. We decided to go for a simple setup: one dedicated Exchange 2007 Client Access Server facing the Internet (behind a firewall of course) using HTTPS and client certificates on the Iphones. There are plenty of guides out there that discuss this topic (with or without client certificates and with reverse proxy server infront of the CAS server) so I’m not going to elaborate on that .We did take some standard security measures like using the Microsoft SCW, enabling the Windows Firewall on the external interface and install a virus scanner on the CAS server itself. We were using Iphone 4’s with IOS 4.1 and Exchange 2007 sp1 RU 9.

After we had rolled out the profiles the Iphone’s were syncing fine, but sometimes users weren’t able to connect to the server. One particular symptom that came up every now and then was that messages containing attachments wouldn’t send but would get stuck in the device’s Outbox. Some messages would remain stuck indefinitely while other would send after a certain time period.

On the CAS server itself I noticed the following error in the Application event log:

And in the System Log:

There were also some entries in the httperr1.log:

2010-11-15 22:47:19 60140 443 HTTP/1.1 POST /Microsoft-Server-ActiveSync?User=MY USERNAME&DeviceId=MYDEVICE&DeviceType=iPhone&Cmd=Ping – 1 Connection_Abandoned_By_AppPool MSExchangeSyncAppPool

At times we would also see Connection_Dropped_By_AppPool MSExchangeSyncAppPool and the same error as above but with the actual send and save command string.

Doing some research (aka using Google/Bing) gave me some information about IIS deadlocks and I found the following suggestions:

– Add another CPU if you have a single CPU VM

– Adjust the machine.config file for the .NET version mentioned in the event log

We tested both and that had no impact.

Additional troubleshooting steps we took were:

– Remove Anti virus, disable Windows Firewall -> No effect whatsoever

– We checked the session time-out on the Firewall, because Direct Push uses very HTTP sessions -> The firewall had a time-out value of 30 minutes and since the Direct Push sessions last about 15 minutes that couldn’t be the cause of our problems either

– Upgraded one of the Iphone’s to the IOS 4.2 GM -> Nada

After that Icontacted PSS in order to jointly investigate the issue. They looked at the logs and we performed a trace but nothing really came up.

Then I decided to have another look myself. I fired up Wireshark, exported the key of the SSL certificate and traced and decrypted the conversations between the device and the CAS server. In the conversations I noticed the following HTTP response:

So apparently the web server had problems with the size of the request. Searching Technet I found this article:

If a client sends a long HTTP request, for example, a POST request, to a Web server running IIS 6.0, the IIS worker process might receive enough data to parse request headers, but not receive the entire request entity body. When the IIS worker process detects that client certificates are required to return data to the client, IIS attempts to renegotiate the client connection. However, the client cannot renegotiate the connection because it is waiting to send the remaining request data to IIS.

If client renegotiation is requested, the request entity body must be preloaded using SSL preload. SSL preload will use the value of the UploadReadAheadSize metabase property, which is used for ISAPI extensions. However, if UploadReadAheadSize is smaller than the content length, an HTTP 413 error is returned, and the connection is closed to prevent deadlock. (Deadlock occurs because a client is waiting to complete sending a request entity, while the server is waiting for renegotiation to complete, but renegotiation requires that the client to be able to send data, which it cannot do).”

I’ve tried enlarging the UploadReachAheadSize to 64k but as could be expected (the attachment was much larger than that) that didn’t help. And just as the article says, increasing this value would create an attack surface on our server. So I followed the link on the bottom of the article to this article:

The SSLAlwaysNegoClientCert property controls SSL client connection negotiations. If this property is set to true, any time SSL connections are negotiated, the server will immediately negotiate a client certificate, preventing an expensive renegotiation. Setting SSLAlwaysNegoClientCert also helps eliminate client certificate renegotiation deadlocks, which may occur when a client is blocked on sending a large request body when a renegotiation request is received.”

I then used the adsutil script to set that value and voila! The messages were sent normally and the errors stopped occuring.

If you want apply either of those settings you should remember to restart the IIS Admin service and not just reset IIS.

I’ve seen several posts on the web dealing with the same issue or at least the same symptom. They might be related to our issue and I think that the UploadReachAheadSize could also affect sending email messages when no client certificates are being used.