次の方法で共有


不十分なアクセス権によるエラーのトラブルシューティング

問題

ほとんどのユーザーに対して、Active Directory への受信ユーザー プロビジョニングは、期待どおりに動作しています。 ただし、一部のユーザーには、プロビジョニング ログで次のエラーが表示されます:

ERROR: InsufficientAccessRights-SecErr: The user has insufficient access rights.. Access is denied. \nError Details: Problem 4003 - INSUFF_ACCESS_RIGHTS. 
OR

ERROR: 
"Message":"The user has insufficient access rights.",
"ResponseResultCode":"InsufficientAccessRights",
"ResponseErrorMessage":"00002098: SecErr: DSID-03150F94, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0",
The user has insufficient access rights.

このプロビジョニング ログは、HybridSynchronizationActiveDirectoryInsufficientAccessRights というエラー コードを表示します。

原因

デフォルトで、プロビジョニング エージェント GMSA アカウント provAgentgMSA$ には、ドメイン内のすべてのユーザー オブジェクトに対する読み取り/書き込みアクセス許可があります。 上記のエラーにつながる原因としては、次の 2 つがあります。

  • 原因 1: ユーザー オブジェクトが、ドメイン レベルのアクセス許可を継承していない OU の一部である。
  • 原因 2: ユーザー オブジェクトが、保護された Active Directory グループに属している。 設計上、ユーザー オブジェクトは、AdminSDHolder という特殊なコンテナーに関連付けられているアクセス許可によって管理されます。 これが、保護された Active Directory グループに 属するこれらのアカウントを、provAgentgMSA$ アカウントが更新できない理由となっています。 オーバーライドにより、provAgentgMSA$ アカウントへの書き込みアクセス権をユーザー アカウントに明示的に付与しようとしても、それは機能しません。 委任されたアクセス許可の誤用から特権ユーザー アカウントを保護するために、SDProp と呼ばれるバックグラウンド プロセスが存在します。これは、60 分ごとに実行され、保護されたグループに属するユーザーが、必ず AdminSDHolder コンテナーで定義されているアクセス許可によって管理されるように保証しています。 ドメイン 管理 グループに provAgentgMSA$ アカウントを追加する方法も機能しません。

解決方法

まず、問題の原因を確認します。 原因 1 が問題の原因であるかどうかをチェックするには:

  1. [Active Directory ユーザーとコンピューターの管理] コンソールを開きます。
  2. 対象のユーザーに関連付けられている OU を選択します。
  3. 右クリックし、[プロパティ] - >[セキュリティ] -> [詳細設定] と移動します。 [継承の有効化] ボタンが表示されている場合は、原因 1 が問題の原因であることがわかります。
  4. [継承を有効にする] をクリックし、この OU に対して、ドメイン レベルのアクセス許可が適用されるようにします。

    注意

    上層のドメイン レベルから、影響を受けるアカウントを保持している OU のレベルまで、 階層全体を忘れずに確認します。 ドメイン レベルで適用されるアクセス許可が、最終的なオブジェクトにまで縦方向に継承されるように、すべての親 OU およびコンテナーで、継承が有効になっている必要があります。

原因 1 が問題を起こしているのでなければ、この問題は、原因 2 に起因していると考えられます。 解決方法としては、2 種類を想定できます。

オプション 1: 保護された AD グループから影響を受けているユーザーを削除する この AdminSDHolder アクセス許可によって管理されているユーザーの一覧を見つけるために、Cx は次のコマンドを呼び出すことができます。

Get-AdObject -filter {AdminCount -gt 0}

参照アーティクル:

  • 次に、AdminCount フラグをクリアし、影響を受けるユーザーに対して継承を再度有効にする際に使用できる、PowerShell スクリプトの例 を示します。
  • この 「記事- 孤立したアカウントを検索する」 に記載されている手順を使用して、孤立したアカウント (保護されたグループに含まれていないが、AdminCount フラグが 1 に設定されているアカウント) を検索します

オプション 1 は常に機能するとは限りません

セキュリティ記述子伝達 (SDPROP) プロセスという名前のプロセスがあり、これは、PDC エミュレーターの FSMO ロールを保持しているドメイン コントローラーで 1 時間ごと実行されています。 AdminCount 属性を 1 に設定するのは、このプロセスです。 SDPROP の主要な機能は、高い特権を持つ Active Directory アカウントを保護することです。権限が低いユーザーまたはプロセスが、誤ってでも意図的にでも、このアカウントを削除したり、その権限を変更したりできないようにしています。 セキュリティ記述子伝達 (SDPROP) プロセスという名前のプロセスがあり、これは、PDC エミュレーターの FSMO ロールを保持しているドメイン コントローラーで 1 時間ごと実行されています。 AdminCount 属性を 1 に設定するのは、このプロセスです。 SDPROP の主な機能は、高い特権を持つ Active Directory アカウントを保護することです。 SDPROP プロセスは、権限の低いユーザーやプロセスによってアカウントが削除されたり、権限が誤ってあるいは意図的に変更されたりしないようにします。

原因についての詳細な説明のための参照記事:

オプション 2: AdminSDHolder コンテナーのデフォルトのアクセス許可を変更する

オプション 1 が実現可能ではなく期待どおりに機能しない場合は、AdminSDHolder コンテナーのデフォルトの許可が、AD 管理者とセキュリティ管理者により変更できるようになっているか、Cx に確認を依頼します。 この 記事 では、AdminSDHolder コンテナーの重要性について説明します。 AdminSDHolder コンテナーのアクセス許可を更新するための内部承認を Cx が取得した後、そのアクセス許可を更新する方法には、2 つの種類があります。

  • この記事で説明しているように、ADSIEditを使用する。
  • DSACLS コマンド ライン スクリプトを使用する。 ここに示すスクリプトの例は、出発点として使用でき、また、Cx はこれを要件に従って調整できます。

$dcFQDN = "<FQDN Of The Nearest RWDC Of Domain>"
$domainDN = "<Domain Distinguished Name>"
$domainNBT = "<Domain NetBIOS Name>"
$dsaclsCMD = "DSACLS '\\$dcFQDN\CN=AdminSDHolder,CN=System,$domainDN' /G '$domainNBT\provAgentgMSA$:RPWP;<Attribute To Write To>'"
Invoke-
Expression $dsaclsCMD | Out-Null

オンプレミスの AD アクセス許可のトラブルシューティングに関する、より詳細なヘルプを Cx が必要としている場合は、Windows Server サポート チームに問い合わせてください。 「Microsoft Entra Connect に関する AdminSDHolder の問題」にあるこの記事には、DSACLS の使用方法に関する他の例が記載されています。

オプション 3: provAgentgMSA アカウントにフル コントロールを割り当てる

provAgentGMSA アカウントに、フル コントロールのアクセス許可を 割り当てます。 ユーザー オブジェクトが保護されたユーザー グループに属していない場合に、ユーザー オブジェクトをあるコンテナー OU から別のコンテナー OU に移動する際に問題が発生する場合は、この手順をお勧めします。

このシナリオでは、Cx に次の手順を完了するように依頼し、移動操作を再度テストします。

  1. 管理者として AD ドメイン コントローラーにログインします。
  2. 管理者として run して PowerShell コマンド ラインを開きます。
  3. PowerShell プロンプトで次の DSACLS コマンドを実行して、汎用オール/フル コントロール を、プロビジョニング エージェント GMSA アカウントに付与します。 dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

dc=contoso,dc=com は、ご使用のルート ノードまたは適切な OU コンテナーに置き換えます。 カスタム GMSA を使用している場合は、provAgentgMSA の DN 値を更新します。

オプション 4: GMSA アカウントをスキップし、手動で作成したサービス アカウントを使用する このオプションは、GMSA でのアクセス許可の問題が調査され解決するまで、ブロックを一時的に解除するための回避策としてのみ使用する必要があります。 推奨されるのは、GMSA アカウントを使用することです。 レジストリ オプションを設定して GMSA 構成をスキップ し、手動で作成され適切なアクセス許可が与えられたサービス アカウントを使用するように、Microsoft Entra Connect プロビジョニング エージェントを再構成できます。

次のステップ