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
[PS] C:\Windows\system32>Get-MailboxPermission -identity cos\user1
Identity User AccessRights IsInherited Deny
-------- --- ------------ ----------- ----
COS.local/COS/Use... NT AUTHORITY\SELF {FullAccess, SendAs, ReadPermission} False False
COS.local/COS/Use... COS\user2 {FullAccess False False
[…]
COS.local/COS/Use... COS\Admin1 {FullAccess} True True
COS.local/COS/Use... COS\Admin1 {SendAs} True True
COS.local/COS/Use... COS\Admin1 { ReadPermission } True True
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.
[PS] C:\Windows\system32>Get-MailboxPermission -identity cos\user1
Identity User AccessRights IsInherited Deny
-------- --- ------------ ----------- ----
COS.local/COS/Use... NT AUTHORITY\SELF {FullAccess, SendAs, ReadPermission} False False
COS.local/COS/Use... COS\user2 {FullAccess False False
[…]
COS.local/COS/Use... COS\Admin1 {FullAccess} False False
COS.local/COS/Use... COS\Admin1 {FullAccess} True True
COS.local/COS/Use... COS\Admin1 {SendAs} True True
COS.local/COS/Use... COS\Admin1 { ReadPermission } True True
When you remove the delegated admins permissions the delegated admin is not inherited and is now denied.
[PS] C:\Windows\system32>Get-MailboxPermission -identity cos\user1
Identity User AccessRights IsInherited Deny
-------- --- ------------ ----------- ----
COS.local/COS/Use... NT AUTHORITY\SELF {FullAccess, SendAs, ReadPermission} False False
COS.local/COS/Use... COS\user2 {FullAccess False False
[…]
COS.local/COS/Use... COS\Admin1 {FullAccess} False True
COS.local/COS/Use... COS\Admin1 {FullAccess} True True
COS.local/COS/Use... COS\Admin1 {SendAs} True True
COS.local/COS/Use... COS\Admin1 { ReadPermission } True True
So using proper where I can filter out to just find the bad access.
[PS] C:\Windows\system32>Get-MailboxPermission -identity cos\user1 | where {$_.IsInherited -eq $false -and $_.Deny -eq $true}
Identity User AccessRights IsInherited Deny
-------- --- ------------ ----------- ----
COS.local/COS/Use... COS\Admin1 {FullAccess} False True
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.
[PS] C:\Windows\system32>Get-ADPermission -Identity "COS-Mailboxes" Identity User Deny Inherited -------- ---- ---- --------- COS-Mailboxes COS\Organization... False True COS-Mailboxes COS\Public Folder... False True COS-Mailboxes NT AUTHORITY\SYSTEM False True […] COS-Mailboxes COS\Admin1 True True COS-Mailboxes COS\Admin1 True True COS-Mailboxes COS\Admin1 True True […]
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.
dsacls "CN=COS,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=COS,DC=local" /R COS\Admin1
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.
[PS] C:\Windows\system32>Get-MailboxPermission -identity cos\user1 | where {$_.IsInherited -eq $false}
Identity User AccessRights IsInherited Deny
-------- --- ------------ ----------- ----
COS.local/COS/Use... NT AUTHORITY\SELF {FullAccess, SendAs, ReadPermission} False False
COS.local/COS/Use... COS\user2 {FullAccess False False
[…]
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.