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

Question

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.

Solution 4

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”;
}

View more solutions

Comments

[Ben Pilbrow]

Is User1 a privileged user by any chance (i.e Domain Admin, Enterprise Admin, Account Operator)?

[user3783502]

No, they are just a member of Domain Users and Print Operators.

[Ben Pilbrow]

Ah, print operators is another one of those protected groups. I'm not in a position to update my answer at the minute - gimme a couple of hours. In the mean time, I suspect your problem is related to the adminSDHolder thread - Google that if you want more info, but don't do anything rash! I recommend this awesome post for some good detail.

[user3783502]

Right - I'd never heard of the adminSDHolder before. I have tried removing the user from Print Operators, but the Powershell command fails at the same place.

[user3783502]

UPDATE: My other post does not work long term as you suggested. ADSIEdit DOES have the adminCount set to 1, so I've changed it to 0. Will update this when the adminSDHolder thread runs.

[Andreas Reiff]

Note: To see the "security" tab in the user's properties, you first need to enable viewing advanced options in the menu.