Fixing stuck Exchange delegated access

Recently ran into an issue where an admin account had stuck delegated access to user accounts.  Even after removing the access the admin would still see the user account showing in Outlook.  Force updating the Offline Address Book and others didn’t fix it.  PowerShell showed that the admin account was still there with deny permissions

As seen, the permission are inherited and not explicitly implied.  The below example is what it looks like when the delegated admin had access. The delegated admin is not inherited and not denied.

When you remove the delegated admins permissions the delegated admin is not inherited and is now denied.

So using proper where I can filter out to just find the bad access.

Applying Remove-MailboxPermission to the end of that query properly removes them and after proper time removes itself from Outlook.  So we need to trace this down to figure out where its coming from.  So I checked the mailbox permissions to see if it was applied there.

So digging even more I checked Active Directory Users and Computers under the “Microsoft Exchange System Objects” OU and looked at all the SystemMailbox objects permissions.  None of them had any weird permissions.  Additionally it isn’t easy to tell which object belongs to which mailboxes, loading up ADSI Edit and connecting to the “Default naming Content” and opening the “Microsoft Exchange System Objects” gets you back to the SystemMailbox objects and you can get the properties to find the name of the mailbox object.

So, next I connected to ADSI Edit again and the “Configuration” context and went to the “Services” > “Microsoft Exchange”.  I checked permissions here, the admin account didn’t exist.  Digging down one more to the “COS” (The name of the exchange organization) I found the admin account had permissions implied here.  Below the “COS” is the objects for the Exchange mailbox databases.
Now trying to remove the admin permissions the GUI would give me a dialog stating that it would change 100+ permissions on all child objects.  That was a scary message as the last thing I wanted to do was break all child objects or change permissions on them.

After reading around I found the dsacls command (Technet article) and found a way to remove permissions.

Running the command didn’t seem to change any child permissions from what I can see and removed the admin user from having inherited permissions.  Now removing or adding delegated access does not leave the user around in Outlook.

The only logic I can figure out is Exchange Control Panel fails to properly remove delegated access because the user exists already under some sort of access to the mailbox.  Because it gets confused I think it is changing it to a deny access rather than deleting it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.