Jan 17 2011

MSExchange ActiveSync EventID 1053

In this article we will fix a problem we had with Exchange 2010 when synchronising mail on a mobile device using ActiveSync. When attempting the synchronisation we had the following error message (Source MSExchange ActiveSync, ID 1053) on the CAS server’s eventlog.

Exchange ActiveSync doesn’t have sufficient permissions to create the “CN=<user name>,OU=<OU Name>,DC=ldap389,DC=info” container under Active Directory user “Active Directory operation failed on <dc-name>.ldap389.info. This error is not retriable. Additional information: Access is denied.
Active directory response: 00000005: SecErr: DSID-03151E04, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
“.
Make sure the user has inherited permission granted to domain\Exchange Servers to allow List, Create child, Delete child of object type “msExchangeActiveSyncDevices” and doesn’t have any deny permissions that block such operations.


A possible resolution to solve this problem is given in this post, but in our case the allow inheritable permissions checkbox was already ticked on the account’s security tab. The problem occured because the account object class was InetOrgPerson and not user.

When you have a look at the permissions added by the Exchange 2010 schema extension described in this Technet article

you will notice that the msExchActiveSyncDevice object creation/deletion for “Exchange Servers” is allowed on accounts with the user class but not with the InetOrgPerson class. For other kinds of permissions both object classes are taken into consideration:

To fix the problem you just need to apply onto the InetOrgPerson objects the same permissions as the User objects:

You might want to apply this security setting on your entire domain (dc=ldap389,dc=info) if use of the InetOrgPerson class has become widespread.

Thanks to my colleague UtOpiK and the team working on the Exchange 2010 project for pointing this bug out.

Update 15/02/2013: Issue solved with Exchange 2010 SP3, there is a reference to this post in KB2552121 :-).

This post is also available in: French

8 Comments

  • By chetan, June 17, 2011 @ 12:32 pm

    how do you apply this to all the users or for a OU?

  • By ldap389, June 17, 2011 @ 4:50 pm

    You apply the right to InetorgPerson objects (users). It can be done at the single user, OU or domain level

  • By ewall, January 28, 2012 @ 8:44 pm

    Good post on this topic, especially since the use of the InetOrgPerson class is a bit more rare.

    What I am still unable to find is the exact permissions that the Exchange Servers group needs on the user (or InetOrgPerson) objects to allow this to work all the time… On all my domains, the AdminSDHolder object is already propagating the create & delete child perms of msExchangeActiveSyncDevices objects, but apparently that’s still not enough, because adding ActiveSync clients only works while permission inheritance is enabled (before SDProp overwrites it again).

    Any thoughts?

  • By ldap389, January 30, 2012 @ 9:28 pm

    Hello,

    By default inheritance is enabled, so your case is even more rare 🙂 I suggest you enable inheritance because the msExchActiveSyncDevice objects are a subcontainer of your InetOrg account.
    Anyway, if you need the exact permissions on the InetorgPerson object for the Exchange servers group, you can use the following Psh commands on an account which is working (inheritance enabled, replace CN=TempUser,CN=Users,DC=Fabrikam,DC=com):

    (Get-ACL ‘AD:\CN=TempUser,CN=Users,DC=Fabrikam,DC=com”).Access | where {$_.IdentityReference -match “Exchange Servers”} | ft Activedirectoryrights,AccessControlType,ObjectType -A

    ObjectType will be a GUID, you might want to get it’s friendly name with the following function (replace c975c901-6cea-4b6f-8319-d67f45449506):

    $RawGuid = ([guid]’c975c901-6cea-4b6f-8319-d67f45449506′).toByteArray()

    get-adobject -fi {schemaIDGUID -eq $rawGuid} -SearchBase (Get-ADRootDSE).schemaNamingContext -prop schemaIDGUID | Select name,@{Name=’schemaIDGUID’;Expression={[guid]$_.schemaIDGUID}}

    Use the ActiveDirectory PsH module, for more info, visit this link.

    Hope this answer your question.

  • By ewall, March 16, 2012 @ 8:45 pm

    Just wanted to say: thanks for the tip! Helpful stuff you’ve got here.

  • By gcarter, June 5, 2012 @ 8:21 pm

    Great info! Worked like a charm!

  • By sirclicksalot, November 27, 2012 @ 7:41 pm

    Although I’m sure i was doing something wrong, both this solution and the permission inherit fix linked to in the above article did not fix it for me, but running setup /preparead on the Exch2010 server did sort it out by replacing all proper AD permissions in the domain. Just FYI.

  • By slickguy, July 25, 2013 @ 4:35 pm

    Do not listen to the last comment by sirclicksalot

Other Links to this Post

RSS feed for comments on this post. TrackBack URI

Leave a comment

*

WordPress Themes

Blossom Icon Set

Software Top Blogs