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

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

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.

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.

Encountered this 'inheritance not enabled' on a user's account, while trying to setup migration to o365. Couldn't import Exchange properties. Wrote this little routine to enable 'inheritable permissions' checkbox.

$user = Get-ADuser -Filter "(displayname -eq "Joe Cool")
$ou = [ADSI](“LDAP://” + $user)
$sec = $ou.psbase.objectSecurity
If ($sec.get_AreAccessRulesProtected()) {
   $isProtected = $false ## allows inheritance
   $preserveInheritance = $true ## preserver inhreited rules
   $sec.SetAccessRuleProtection($isProtected, $preserveInheritance)
   $ou.psbase.commitchanges()
   Write-Host “$user is now inherting permissions”;
}

The above solutions didn't resolve my issue but this one did: http://support.risualblogs.com/blog/2012/02/07/the-user-has-insufficient-access-rights-error-when-trying-to-set-send-as-permissions-on-a-mailbox-in-exchange-2010/

The particular AD user account that I was trying to set Send As perms on didn't have inheritable permissions checked in AD.