Can't give 'send-as' permissions in Exchange 2010

I'm trying to give 'send-as' permissions to one user in Exchange 2010. Here is the Powershell command I'm running:

Add-ADPermission "User1" -User "Ourdomain\User2" -Extendedrights "Send As"

Powershell returns this error:

Active Directory operation failed on DC.OurDomain.pri. This error is not retriable. Additional information: Access is denied. Active directory response: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 + CategoryInfo : WriteError: (0:Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId : EDBB94A3,Microsoft.Exchange.Management.RecipientTasks.AddADPermission

I've tried multiple alternatives to the Powershell command - ie. using -Identity etc., but that and the EMC wizard all return the same error.

I'm not sure if the "INSUFF_ACCESS_RIGHTS" is referring to me who is running the command or the user I'm giving the send-as rights to?

I've been following the Microsoft Technet "Manage Send As Permissions for a Mailbox" web page here: http://technet.microsoft.com/en-us/library/bb676368.aspx

So have added the two permissions you need to do this:

Organization Management

Recipient Management

But that is not helping. Any ideas?

Update

If I do the following:

• open up "AD Users & Computers" with the "Advanced Features" view
• Go to the properties of User1
• Hit "Advanced" on the Security tab
• Select "Add"
• enter in "User2" and select "Send As" Allow

That works, if I close ADUaC and open it up again and re-check those new permissions they are still there. If I return about 10 minutes later those permissions are now gone - user2 does not show up in the security permissions of user1 at all.

Don't think I've ever seen this kind of AD behaviour before.

Solution 1:

I've finally fixed this.

Interestingly Send-As is an AD permission - not an exchange permission as you might have expected.

Anyway, these are the steps:

Make the target mailbox "shareable" using this command in Powershell on your Exchange Server:

Set-Mailbox user1 -type:shared

If you get this error (same as in my first post):

You will need to find that user in AD and go to the properties >> Security >> Advanced:

You need to ENABLE the option to "Include inheritable permissions from this object's parent":

Once that is done you should be able to complete the folder share script.

Then actually grant the rights using this command:

Add-ADPermission user1 -User Ourdomain\User2 -ExtendedRights "Send As"

Hope that helps others who have the same problem.

Kieran

Solution 2:

Access denied messages usually come from the account running the PowerShell session not having enough permission. I get this all the time when I just launch the Exchange Management Shell instead of doing run as my administrative user account.

Following your update, what I suspect may be happening is that User1 is part of a protected group (Print Operators) so Exchange is not allowing you to grant Send As on User2 because it knows it will only get stripped off in the next hour. It looks like you confirmed that theory by manually adding Send As using ADUC and seeing it taken away a short time later.

On the Domain Controller which runs the PDC Emulator FSMO role, every hour something called the adminSDHolder thread runs. What this does is takes all accounts which are (or have ever been, even if they have subsequently removed) in protected groups (Enterprise Admins, Domain Admins, Account Operators, Print Operators to name a few of the more common ones) and removes all permissions granted on the objects and replaces them with certain explicitly defined permissions. The idea being that a delegated account is not able to wreak havoc and strip a domain admin of their privileges.

I'm not entirely convinced your fix of explicitly granting permission is going to work and won't be reset every hour, but I've been wrong before - so if it does, great! If however the user doesn't need to be in the Print Operators group, I'd recommend you modify their account using ADSI Edit and set the adminCount property to zero. Then enable inheritable permissions on the user object and reset the default permissions. Once you've done that, try your Exchange cmdlet again and with a bit of luck it will work (obviously give enough time for AD replication to occur).

I don't think you'll be able to modify your cmdlet to accommodate for this - like I said, I imagine (not certain though) that it won't let you do it because Exchange knows the permission is only going to get removed shortly afterwards and is trying to save confusion on your part. Under "normal" circumstances (i.e a standard user) the cmdlet should just work without issue because the whole adminSDHolder thread doesn't even come into play.

Solution 3:

Have you seen this KB: Access denied when you try to give user "send-as" or "receive as" permission for a Distribution Group in Exchange Server 2010 or Exchange Server 2013

Cause

By default Exchange Trusted Subsystem is not granted the "modify permissions" permission. This causes the Add-ADPermission cmdlet to fail with an Access Denied error.

Resolution

To work around this issue, add the "modify permissions" permission for the Exchange Trusted Subsystem to the organizational unit (OU) that contains the Distribution Group by following these steps:

1. Open Active Directory Users and Computers.
2. Click View, and then click Advanced Features.
3. Right-click the OU that contains the distribution lists, and then click Properties.
4. In the Security tab, click Advanced.
5. In the Permissions tab, click Add.
6. In the Enter object name to select box, type Exchange trusted subsystem, and then click OK.
7. In the Object tab, select This object and all descendants objects in the Apply onto list, locate Modify Permissions in the Permissions list, and then set it to Allow.
8. Click OK.