[horde] Activesync | WP7 cannot sync

[Michael J Rubinsky]

Quoting Martin Hochreiter <linuxbox at wavenet.at>:

> Am 29.01.2012 17:20 schrieb Michael J Rubinsky:
>> Quoting Martin Hochreiter <linuxbox at wavenet.at>:
>>
>>> Hi!
>>>
>>> I have a massive problem with one user and its wp 7(.5) phone.
>>>
>>> If I configure active sync, as I did on the iphone, wm 6.5 and android
>>> it ends in that error message on the phone:
>>>
>>>
>>> xxx.xxxx.xxx requires that certain security policies be enforced  
>>> before you can sync your information. Contact a support person or  
>>> your service provider. Last tried x minutes ago. Error code:
>>> The error code is 0x85010013.
>>>
>>> I tried to force provision - to turn of provision (but still if  
>>> provision is turned off completely
>>
>> You should only get that message if you have forced provisioning  
>> and either the phone doesn't support the configured security  
>> requirements (unlikely since this is a Windows phone), or the user  
>> didn't enable/refused to enable the requested features. Another  
>> possibility is that maybe these newer phones don't fully support  
>> the older EAS 2.5 style of provisioning rules. The newer protocol  
>> versions use a different format when pushing out the rules to the  
>> device. I'll have to look into that when I get back home. Horde  
>> currently only supports up to version EAS 2.5.
>>
>>> there is this line "PROVISION request received for user user_user"  
>>> in the log)
>>
>> Was this log generated while provisioning support was completely  
>> disabled? It doesn't look like it was; If you look at the entry  
>> where it is "checking policykey for...", the user should not be  
>> immediately logged off after that check if provisioning is  
>> disabled. Additionally, the device should NEVER send a PROVISION  
>> request unless told to do so by the server and this should never  
>> happen with provisioning support disabled.
>>
>> Otherwise, if this was done during "Allow"  provisioning, this  
>> issue sounds similar to an issue early android devices had, in that  
>> they would incorrectly send a POLICYKEY of zero, even though the  
>> device did not support PROVISION. We work around this in code by  
>> sniffing versions and device strings. Though I would really be  
>> surprised that this is the issue, seeing how it's a Windows phone  
>> and, presumably, designed to work well with other Microsoft  
>> technology.
>>
>> Can you provide a wireshark trace or tcpdump of the conversation? I  
>> don't have access to a Windows phone and it's the only way I can  
>> see exactly what is being sent.
>>
> I will try to get a wireshark trace for you - as it isnt my phone I  
> is a little bit complicated - but I will do
>
> Meanwhile:
> I tried many combinations ( with ssl/without ssl - force provision,  
> allow provision, disable provision - allow provision with pin/force  
> provision with pin) without any success.
> I enclose the whole log of my tries today - unfortunately I cant  
> tell anymore what logs are belong to what combinations and i have  
> not logged everything
> as I was searching for the error in the password first ... maybe you  
> see more out of them
>
> It is a htc with the latest updates but you dont have any options to  
> controll anything related to active sync on the phone.
> I found that article http://support.microsoft.com/kb/2464593 and so  
> I see the only solution in "method 3" - but as i said - it seems to  
> me that regardless of what the
> provision is set in horde - the phone requests that....

The KB article confirms what I said was the original issue - the  
device is unable to support one of the requested policies. I'm still  
not sure why the phone is requesting PROVISION if it's disabled on the  
server, but the KB article sheds some light on why the provision is  
being rejected by the device. The list of supported policies does not  
include the "CodewordFrequency" policy. This policy sets the number of  
unlock attempts before the device prompts in some way to determine  
that it's an actual human trying to unlock the device (and not some  
automated process). You can try setting this to zero, though I'm not  
100% sure that it will help since this will still send the policy to  
the device, just with a value of zero.

I'll tweak the code to avoid sending that policy string altogether if  
it's set to zero. I'll also have to check what type of response the  
client is sending when it can't enforce all the policies. It could be  
we are not catching that response if provisioning is set to "Allow".   
If provisioning is set to "Allow", we should catch this response and  
effectively turn off provisioning for that device.

Should be able to get to these tomorrow.

<snip log>
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org