Exchange 2013: Correcting mailbox delegation - Full Access

Not sure how to correct this issue.  I have an Admin that setup the Exchange 2013.  The admins account is now added to every new account (Resources, shared mailboxes etc.)  I know how to remove the auto mapping so it does not show in the admin OWA and outlook. 

I would like to just correct the setting so the account is not automatically added. (Tester is not the real name of the account.)

Mailbox delegation

April 22nd, 2015 9:37am

If I understand correctly, this should do the trick:

Get-Mailbox -ResultSize Unlimited | Remove-MailboxPermission -User tester -AccessRights FullAccess

Free Windows Admin Tool Kit Click here and download it now
April 22nd, 2015 4:33pm

Hi,

This admin account is added to full access list of new mailbox automatically?

How do you create new mailbox?

Please check are there any tasks in task schedule.

Best Regards

April 23rd, 2015 3:45am

Hi Friday77,

Check the AdminAuditLogs to see by who and when it is getting added.

View the administrator audit log

Search the role group changes or administrator audit logs

Search-AdminAuditLog -StartDate 05/04/2015 -EndDate 10/04/2015 -ObjectID contoso.com/Users/NewUSerName1
Search-AdminAuditLog -Cmdlets Add-MailboxPermission -Parameters AccessRights -StartDate 05/04/2015 -EndDate 10/04/2015

Normally this wouldn't be the case, however you might want to have a look at this as well.

Get-CmdletExtensionAgent "Mailbox Permissions Agent"

Cmdlet extension agents are components in Microsoft Exchange Server 2013 invoked by Exchange 2013 cmdlets when the cmdlets run.

Agents can modify, replace, or extend functionality of Exchange Management Shell cmdlets. An agent can provide a value for a required parameter that isn't provided on a command, override a value provided by a user, perform other actions outside of the cmdlet workflow while a cmdlet runs, and more.

You can use the Scripting agent cmdlet extension agent in Exchange 2013 to insert your own scripting logic into the execution of Exchange cmdlets. Using the Scripting agent, you can add conditions, override values, and set up reporting.

Every Exchange 2013 server includes the file ScriptingAgentConfig.xml.sample in the <installation path>\V15\Bin\CmdletExtensionAgents folder. This file must be renamed to ScriptingAgentConfig.xml on every Exchange 2013 server if you enable the Scripting Agent cmdlet extension agent.

If its still .xml.sample, no need to worry about it.

Free Windows Admin Tool Kit Click here and download it now
April 23rd, 2015 4:26am

Hi, Friday77.

Did the solutions above help you? Please respond us.

Best Regards.

April 24th, 2015 5:24am

Lynn,

Was out of the office,  will let you know soon.

Free Windows Admin Tool Kit Click here and download it now
May 4th, 2015 8:54am

Ok I have check what some poster suggested.  But have not come up with any answers how my co-worker is getting added to every exchange object that is created.  The ScriptingAgentConfig.xml.sample is not touched on any of the servers.

I do understand how to remove his permissions but would be better if they were not added in the first place.  I have check his ad permissions and don't see him any groups that could cause this.

May 21st, 2015 6:52pm

Hi Friday77,

Just realized I had missed a common scenario, where this happens.

To confirm run the below cmdlet for a any user like User1.


[PS] C:\Scripts>Get-MailboxPermission User1

Identity             User                 AccessRights                                                IsInherited Deny
--------             ----                 ------------                                                ----------- ----
contoso.com/User... NT AUTHORITY\SELF    {FullAccess, ReadPermission}                                False       False
contoso.com/User... contoso\Administ... {FullAccess}                                                True        True
contoso.com/User... contoso\Domain A... {FullAccess}                                                True        True

As you can see there are lots of access permissions on the mailbox 'User1'. Now if you focus on the'IsInherited' attribute, the $True indicates its coming from top DOmain or OU level or Database, ORg level and $false indicates this permission has been assigned at this level.

When you are saying its automatically getting added, I would believe its not getting added, but is gettting inherited from top level.

To check and remove inherited permissions user ADSIEDIT.msc -Configuration

Browse down to Services\Microsoft Exchange\<Name of your Exchange Organization>\Administrative Groups\Exchange Administrative Group (FYDIBOHF23SPDLT)\Servers

Refer to this article for more de

Free Windows Admin Tool Kit Click here and download it now
May 22nd, 2015 7:10am

Hi Friday77,


Few more points:

When you are using GUI and trying to remove a Top-Level Inherited permission, it may seem to be removing the user permission.
But in actual it is adding\setting Deny:$true for that user on the mailbox, because you can't just remove a inherited object without breaking the inheritance or removing the user from top level.

Below command runs when you minus '-' the user in EAC:

(Refer this article "Exchange Admin Center Cmdlet Logging In Exchange Server 2013 SP1" to find out how I got this)

Add-MailboxPermission -Identity 'User1' -User 'Tester' -AccessRights 'FullAccess' -InheritanceType 'All' -Deny:$true

You can validate this, by running the below command again

[PS] C:\Windows\system32>Get-MailboxPermission User1

Identity             User                 AccessRights                                                 IsInherited Deny
--------             ----                 ------------                                                 ----------- ----
contoso.local/contoso/Use... contoso\Tester         {FullAccess}                                                 False       True


May 22nd, 2015 11:22am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics