Exchange 2010で「送信者」権限を付与できません

Exchange 2010の1人のユーザーに「送信者」アクセス許可を与えようとしています。実行しているPowershellコマンドは次のとおりです。

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

Powershellは次のエラーを返します。

DC.OurDomain.priでActive Directory操作が失敗しました。このエラーは再試行できません。追加情報：アクセスが拒否されました。Active Directoryの応答：00000005：SecErr：DSID-031521D0、問題4003（INSUFF_ACCESS_RIGHTS）、データ0 + CategoryInfo：WriteError：（0：Int32）[Add-ADPermission]、ADOperationException + FullyQualifiedErrorId：EDBB94A3、Microsoft.Exchange.Management.RecipientTasks。 AddADPermission

私はPowershellコマンドの複数の代替手段を試しました-すなわち。-Identityなどを使用しますが、それとEMCウィザードはすべて同じエラーを返します。

「INSUFF_ACCESS_RIGHTS」がコマンドを実行している私を指しているのか、送信者権限を与えているユーザーを指しているのかわかりません。

Microsoft Technetの「メールボックスの送信者としてのアクセス許可の管理」 Webページをフォローしています：http : //technet.microsoft.com/en-us/library/bb676368.aspx

これを行うために必要な2つの権限を追加しました。

組織管理

受信者管理

しかし、それは助けにはなりません。何か案は？

更新

次のことを行う場合：

• [高度な機能]ビューで[ADユーザーとコンピューター]を開きます
• User1のプロパティに移動します
• [セキュリティ]タブの[詳細設定]をクリックします
• 「追加」を選択します
• 「User2」に入力し、「送信」を選択します

ADUaCを閉じて再度開き、新しいアクセス許可を再度確認すると、ADUaCがまだ存在します。約10分後に戻った場合、これらの権限は失われています。user1はuser1のセキュリティ権限にまったく表示されません。

これまでにこの種のADの動作を見たことはないと思います。

これをようやく修正しました。

おもしろいことに、送信者はADの許可であり、期待どおりの交換許可ではありません。

とにかく、これらは手順です：

Exchange ServerのPowershellで次のコマンドを使用して、ターゲットメールボックスを「共有可能」にします。

Set-Mailbox user1 -type:shared

このエラーが発生した場合（最初の投稿と同じ）：

ADでそのユーザーを見つけ、プロパティ>>セキュリティ>>詳細に移動する必要があります。

「このオブジェクトの親から継承可能な権限を含める」オプションを有効にする必要があります。

それが完了すると、フォルダ共有スクリプトを完了することができるはずです。

次に、このコマンドを使用して実際に権限を付与します。

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

同じ問題を抱えている他の人を助けることを願っています。

キーラン

通常、アクセスが拒否されたメッセージは、PowerShellセッションを実行しているアカウントが十分な権限を持っていないことから発生します。これは、管理ユーザーアカウントとして実行するのではなく、Exchange管理シェルを起動するだけで常に得られます。

更新後、User1は保護されたグループ（Print Operators）の一部であるため、ExchangeではUser2にSend Asを許可することはできません。ADUCを使用して手動でSend Asを追加し、少し後に削除されることを確認して、その理論を確認したようです。

PDC Emulator FSMOの役割を実行するドメインコントローラーでは、1時間ごとにadminSDHolderスレッドと呼ばれるものが実行されます。これは、保護されたグループ（Enterprise Admins、Domain Admins、Account Operators、Print Operatorsを使用して、いくつかのより一般的なものに名前を付ける）にあるすべてのアカウントを取得し、すべて削除しますオブジェクトに付与された許可を特定の明示的に定義された許可に置き換えます。委任されたアカウントは大混乱を引き起こし、ドメイン管理者の特権を剥奪できないという考えです。

明示的に許可を付与する修正が機能し、1時間ごとにリセットされないことを完全に確信しているわけではありませんが、以前は間違っていました。ただし、ユーザーがPrint Operatorsグループに属している必要がない場合は、ADSI Editを使用してアカウントを変更し、adminCountプロパティをゼロに設定することをお勧めします。次に、ユーザーオブジェクトで継承可能な権限を有効にし、デフォルトの権限をリセットします。それが完了したら、Exchangeコマンドレットをもう一度試してください。少し運があれば動作します（明らかにADレプリケーションが発生するのに十分な時間を与えてください）。

これに対応するためにコマンドレットを変更できるとは思わない-私が言ったように、許可は削除されるだけだとExchangeが知っているので、それを許可しないと想像します（確かではありません）その後まもなく、あなたの混乱を防ごうとしています。「通常の」状況（標準ユーザー）では、adminSDHolderスレッド全体が機能しなくなるため、コマンドレットは問題なく機能するはずです。

このKBを見たことがありますか：Exchange Server 2010またはExchange Server 2013の配布グループにユーザーに "送信者"または "受信者"のアクセス許可を与えようとするとアクセスが拒否されました

原因

デフォルトでは、Exchange Trusted Subsystemには「アクセス許可の変更」権限が付与されていません。これにより、Add-ADPermissionコマンドレットがアクセス拒否エラーで失敗します。

解決

この問題を回避するには、次の手順に従って、Exchange信頼済みサブシステムの "アクセス許可の変更"アクセス許可を、配布グループを含む組織単位（OU）に追加します。

1. Active Directoryユーザーとコンピューターを開きます。
2. [表示]をクリックし、[拡張機能]をクリックします。
3. 配布リストを含むOUを右クリックし、[プロパティ]をクリックします。
4. [セキュリティ]タブで、[詳細設定]をクリックします。
5. [権限]タブで、[追加]をクリックします。
6. [選択するオブジェクト名を入力してください]ボックスに「Exchange信頼できるサブシステム」と入力し、[OK]をクリックします。
7. [オブジェクト]タブで、[適用先]リストで[このオブジェクトとすべての子孫オブジェクト]を選択し、[アクセス許可]リストで[アクセス許可の変更]を見つけて、[許可]に設定します。
8. OKをクリックします。

o365への移行をセットアップしようとしたときに、ユーザーのアカウントでこの「継承が有効になっていません」が発生しました。Exchangeプロパティをインポートできませんでした。この小さなルーチンを書き、「継承可能なアクセス許可」チェックボックスを有効にします。

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

上記の解決策は私の問題を解決しませんでしたが、これは解決しました：http : //support.risualblogs.com/blog/2012/02/07/the-user-has-insufficient-access-rights-error-when-trying-交換するメールボックスにアクセス許可として送信する-2010 /

Send As permsを設定しようとした特定のADユーザーアカウントには、ADでチェック可能な継承可能なアクセス許可がありませんでした。