1 comments

Exchange ActiveSync and Owner Rights Permissions

Published on Wednesday, January 4, 2012 in ,

One of the problems with delegating permissions for a file system or Active Directory objects is the fact that the creator of the object is also the owner of an object.

Suppose you got someone who is a member of a group which grants him permission to create objects. This delegation would set the user who created the object as the owner of that object. Because he’s the owner he has full control regardless the delegation which is configured. Now suppose this person is removed from the group for one reason or another. In that case that person still has full control on the object he created because he is “owner”!...

This is where owner rights come in. You can restrict what permissions you get when you are the owner of the object. At my customers site this was configured to be just “read”. The owner rights principal is something from Windows 2008 and onwards. So when you are member of the group which got delegated permission you got: delegated to group permissions + owner right permissions = full control + read.
However once you are removed from the delegated group you have owner right permissions = read

Here’s some info from TechNet: http://technet.microsoft.com/en-us/library/dd125370(WS.10).aspx

How did we apply it in our environment?:

Added the “Owner Rights” entry with the following SACL on some top level OU’s: “Read (List Contents, Read all properties, Read permissions)” on “this object and all descendent objects”

So how does Exchange ActiveSync (EAS) comes into play? Well we seemed to have issues when user wanted to configure their device. They’d Always seem to end up with an error. On the CAS server we had the following error:

Log Name: Application

Source: MSExchange ActiveSync
EventID: 1053

Exchange ActiveSync doesn't have sufficient permissions to create the "<user object distinguished name>" container under Active Directory user "Active Directory operation failed on <Domain Controller FQDN>. This error is not retriable. Additional information: Access is denied. Active directory response: 00000005: SecErr: DSID-031521D0, 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

I don’t have the time right now to go deeper into the troubleshooting process and the solution. In short this is what we noticed and what we did:

Whenever a user tries to configured an ActiveSync device, an object is created in Active Directory below the user object. More specifically a msExchActiveSyncDevices container object. And below this one an object is created for each device configured with ActiveSync.

  • User [e.g. JohnDoe001]
    • msExchActiveSyncDevices [container]
      • msExchActiveSyncDevice [device#1]
      • msExchActiveSyncDevice [Device#2]

The problem here is that the security for a newly created msExchActiveSyncDevices object is not correct. The Exchange schema prep should add the Exchange Servers with some permissions. In an environment without the Owner Rights configured everything works as the Exchange Servers are also the owners of these objects and thus have full control permissions.

The following procedure was performed so that we could leave the Owner Rights in place

  1. Right-click the domain root and choose properties. Open the security tab:
  2. Advanced => Add
  3. Select the “Exchange Servers” principal
  4. Check the permissions as shown in the screenshot:
    • List contents
    • Read all properties
    • Write all properties
    • Read Permissoins
    • Modify Permissions
    • Modify Owner

image

Make sure to select “Descendant msExchActiveSyncDevices” in the Apply to section.

Related Posts

1 Response to Exchange ActiveSync and Owner Rights Permissions

Anonymous
27 November, 2012 19:45

This fix worked for me temporarily, but I still had trouble with other users after a while, probably due to AdminSDHolder, but running setup /preparead on the Exch2010 server did sort it out by replacing all proper AD permissions in the domain. Just FYI.