Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Is User1 a privileged user by any chance (i.e Domain Admin, Enterprise Admin, Account Operator)? –  Ben Pilbrow Apr 13 '11 at 9:17
    
No, they are just a member of Domain Users and Print Operators. –  Kieran Walsh Apr 13 '11 at 9:25
    
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. –  Ben Pilbrow Apr 13 '11 at 9:38
    
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. –  Kieran Walsh Apr 13 '11 at 10:09
add comment

2 Answers

up vote 3 down vote accepted

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): AD Failure

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

AD Properties

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

enter image description here

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

share|improve this answer
add comment

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.

share|improve this answer
    
Thanks for responding Ben. The Exchange Organization Management group does not exist. If I run "dsquery group -name exch*" I get these groups returned:"Exchange All Hosted Organizations", "Exchange Install Domain Servers", "Exchange Servers", "Exchange Trusted Subsystem", "Exchange Windows Permissions", "ExchangeLegacyInterop". Does that make sense? –  Kieran Walsh Apr 12 '11 at 21:53
    
BTW, I get the same errors when I try to use the EMS. Thanks –  Kieran Walsh Apr 12 '11 at 21:58
    
Hmm, that's odd. Setup should create a new OU called Microsoft Exchange Security Groups and drop a load of groups in there, Exchange Organization Management being one of them. I thought that was part of standard setup, but now you're making me wonder whether it's an option :/ –  Ben Pilbrow Apr 12 '11 at 22:07
    
Gah, I'm an idiot. It's just Organization Management in that OU I mentioned. –  Ben Pilbrow Apr 12 '11 at 22:08
    
Thanks Ben, so that is the group that I mentioned in the original post and I am a member of that. I did only add myself to that yesterday, so rebooted the server as well in the meantime - "just in case". Still the exact same problem though :( Very strange. –  Kieran Walsh Apr 13 '11 at 7:57
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.