Share via

Exchange Server/Online: The ACE doesn't exist on the object

  • Article

Introduction:

All those who administer MICROSOFT EXCHANGE SERVER or MICROSOFT OFFICE 365 might have seen this warning:

CAN'T REMOVE THE ACCESS CONTROL ENTRY ON THE OBJECT "CN=USER,OU=DOMAIN.ONMICROSOFT.COM,OU=MICROSOFT EXCHANGE HOSTED ORGANIZATIONS,DC=NAMPRXXXXXX,DC=XXXX,DC=OUTLOOK,DC=COM" FOR ACCOUNT "NAMPRXXXXXX\XXXXXXX-XXXXXXXXXXXX" BECAUSE THE ACE DOESN'T EXIST ON THE OBJECT.

Common Affected Areas

We usually come across this warning when we are trying to remove a delegate permission from some other user's mailbox. This permission could be of anything. It could be:

  1. Removing a user account's "FULL ACCESS / SEND AS / SEND ON BEHALF OF" permission, who got full access of another mailbox (Now, another mailbox can be any kind of mailbox, i.e. Shared, Resource or another user)
  2. Removing a user account's "SEND AS" permission from some Distribution Group.
  3. Removing a user account's "SEND AS" permission from some External Contact.

Above are just 3 examples. This warning could appear on many other permission related tasks. Ugly face of this warning is OUR OBJECTIVE IS NOT ACHIEVED. We get a message from the server that permission removed successfully, but when we go to the same user account again, we see THE PERMISSION IS STILL THERE.

Root Cause

Root Cause of the warning is an orphaned SID is pending on the mailbox which is conflicting with rest all delegate user's permissions.

This is confusing, hence below is the whole scenario.

Scenario:

  • User Alpha: He is the trustee. He's got "Full Access" permission on another user's mailbox, who is called "User Beta".
  • User X: Same like User Alpha, he is also a trustee and has the same permission on User Beta's mailbox. He is leaving the organization soon.
  • User Beta: Just a casual user mailbox. On his mailbox, User Alpha and User X have full access.

Hence, when we run the command to see full access permission on User Beta's mailbox, we see both names (Alpha and X)

*PS C:\ GET-MAILBOXPERMISSION -IDENTITY USERBETA@CLOUDMATRIX.CU.CC

RUNSPACEID : XXXXXXXX-XXXX-XXXX-XXX-XXXXXXXXXXXX

IDENTITY : USERBETA

USER : USERALPHA@CLOUDMATRIX.CU.CC

ACCESSRIGHTS : {FULLACCESS}

ISINHERITED : FALSE

DENY : FALSE

RUNSPACEID : XXXXXXXX-XXXX-XXXX-XXX-XXXXXXXXXXXX

IDENTITY : USERBETA

USER : USERX@CLOUDMATRIX.CU.CC

ACCESSRIGHTS : {FULLACCESS}

ISINHERITED : FALSE

DENY : FALSE

*

Here comes the twist.

As mentioned above, User X was going to leave the organization. Hence, he did and we deleted User X from our organization. But, before deleting, we forgot to remove his access from User Beta's Mailbox.

User X's access was still pending on User Beta's Mailbox (we forgot to remove) as well as User X is not found in the organization (we deleted the account). Exchange converts the entry of User Beta's Mailbox into another attribute called SID (SECURITY IDENTIFIER). This SID entry will be always there. Hence, if we run the same above mentioned command again in PowerShell (to see full access permission on User Beta's mailbox ), we see:

  1. One entry of User Alpha (which contains the email address of User Alpha as he is still in organization)
  2. Another entry of User X (It is actually the SID because Exchange cannot find the email address of User X as he was deleted.)

In PowerShell, we see:

*PS C:\ GET-MAILBOXPERMISSION -IDENTITY USERBETA@CLOUDMATRIX.CU.CC

RUNSPACEID : XXXXXXXX-XXXX-XXXX-XXX-XXXXXXXXXXXX

IDENTITY : USERBETA

USER : USERALPHA@CLOUDMATRIX.CU.CC

ACCESSRIGHTS : {FULLACCESS}

ISINHERITED : FALSE

DENY : FALSE

RUNSPACEID : XXXXXXXX-XXXX-XXXX-XXX-XXXXXXXXXXXX

IDENTITY : USERBETA

USER : S-1-5-21-2412119505-3560892057-1500426294-21386775

ACCESSRIGHTS : {FULLACCESS}

ISINHERITED : FALSE

DENY : FALSE

*                                                           

Or Else, 

*PS C:\ GET-MAILBOXPERMISSION -IDENTITY USERBETA@CLOUDMATRIX.CU.CC

RUNSPACEID : XXXXXXXX-XXXX-XXXX-XXX-XXXXXXXXXXXX

IDENTITY : USERBETA

USER : USERALPHA@CLOUDMATRIX.CU.CC

ACCESSRIGHTS : {FULLACCESS}

ISINHERITED : FALSE

DENY : FALSE

RUNSPACEID : XXXXXXXX-XXXX-XXXX-XXX-XXXXXXXXXXXX

IDENTITY : USERBETA

USER : NAMPRXXXXXX\USERXXXXXX-XXXXXXXXX

ACCESSRIGHTS : {FULLACCESS}

ISINHERITED : FALSE

DENY : FALSE*

After this state, even if you use PowerShell to remove User Alpha's permission from User Beta's mailbox, it will produce this warning:

CAN'T REMOVE THE ACCESS CONTROL ENTRY ON THE OBJECT "CN=USER,OU=DOMAIN.ONMICROSOFT.COM,OU=MICROSOFT EXCHANGE HOSTED ORGANIZATIONS,DC=NAMPRXXXXXX,DC=XXXX,DC=OUTLOOK,DC=COM" FOR ACCOUNT "NAMPRXXXXXX\XXXXXXX-XXXXXXXXXXXX" BECAUSE THE ACE DOESN'T EXIST ON THE OBJECT.

Resolution

Simply remove the SID first, and you have permanently resolved the issue.

Below is the method with which we can eliminate it.

  • Get the orphaned SID. Run the command.

GET-MAILBOXPERMISSION -IDENTITY USERBETA@CLOUDMATRIX.CU.CC | SELECT USER | FL

  • Run the command, and remove the entry of the orphaned SID from User Beta's mailbox.

REMOVE-MAILBOXPERMISSION -IDENTITY USERBETA@CLOUDMATRIX.CU.CC -USER "SID WHICH WE GOT" -ACCESSRIGHTS FULLACCESS

Once done, syncing among all servers is also important. If you have your own Exchange server, then make sure that the changes are synced to all servers. If you are using OFFICE 365, then give it a couple of hours to sync between all Microsoft servers.