ADMTv2 を使用したフォレスト間 sIDHistory 移行のトラブルシューティング方法

この記事では、Active Directory 移行ツール バージョン 2 (ADMTv2) を使用してフォレスト間の sIDHistory 移行をトラブルシューティングする方法について説明します。

適用対象:  Windows Server 2012R2
元の KB 番号:   322970

詳細情報

ADMTv2 を使用してフォレスト間のユーザーまたはグループの移行の一部として sIDHistory を移行する場合、基本移行要件を満たす構成が必要です。

既定では、sIDHistory、パスワード、および objectGUID は、フォレスト内移行中にすべて保持されますが、フォレスト間の複製には当てはめではありません。

フォレスト間操作には組み込みのセキュリティ コンテキストが存在しないので、フォレストの境界を越えて操作のセキュリティを保護するための手順を実行する必要があります。

構成

フォレスト間移行操作の基本的な要件は次のとおりです。

sIDHistory を使用しないウィザード ベースの基本的なユーザーアカウントとグループ アカウントの移行

  • ソース ドメインは、ターゲット ドメインを信頼する必要があります。
  • ADMTv2 を実行しているユーザー アカウントには、ソース ドメインの管理者権限が必要です。
  • ADMT ユーザー アカウントには、ターゲット コンテナーにユーザー オブジェクトまたはグループ オブジェクトを作成するための委任されたアクセス許可が必要です。
  • ドメイン間に DNS (ホスト名) と NetBIOS の名前解決が存在している必要があります。

sIDHistory 移行には、次の追加の依存関係が必要です

  • ソース ドメインとターゲット ドメインの両方のアカウント管理の成功と失敗の監査。
  • ソース ドメインは、このユーザーとグループ管理の監査を呼び出します。
  • {SourceNetBIOSDom}$$$ という 名前のソース ドメイン内の空のローカル グループ。
  • レジストリ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport キーは、ソース ドメインプライマリ ドメイン コントローラーで 1 に設定する必要があります。
  • レジストリ構成後に、ソース ドメインプライマリ ドメイン コントローラーを再起動する必要があります。
  • Windowsには、移行先ドメインで委任された MigratesIDHistory 拡張権限または管理者権限を持つユーザー資格情報が必要です。 これらの資格情報は、sIDHistory 移行が有効になっているときにウィザードに追加します。

ドメイン コントローラーまたは Windows Server 管理ツール パックがインストールされているコンピューターで、MigrateSidHistory 拡張を委任するには、次の手順を実行します。

  1. [ スタート] ボタンをクリックし、[ 管理ツール]、[ Active Directory ユーザーとコンピューター] の順にクリックします。
  2. MigrateSidHistory 拡張を委任するドメインの名前を右クリックし、[制御の委任] をクリックして[制御の委任ウィザード] ウィンドウ を開 きます。
  3. [次へ]をクリックし、[追加] をクリックし、[ユーザー、コンピューター、またはグループの選択] ダイアログ ボックスに追加するユーザーまたはグループの名前を入力し 、[OK] をクリックし、[次へ] をクリック します
  4. [委任するカスタム タスクの 作成] オプションを クリックして選択し、[次へ] を クリックします
  5. [このフォルダー、このフォルダー内 の既存 のオブジェクト、およびこのフォルダー内の新しいオブジェクトの作成] オプションが選択され、[次へ] をクリック します。
  6. [全般] オプション が選択 されている場合は、[アクセス許可] ボックスの一覧で [SID 履歴 の移行] をクリックし、[次へ] を クリックします
  7. 情報が正しいか確認し、[完了] を クリックします
    • 移行する sID は、プライマリ sID として、または別のオブジェクトの sIDHistory 属性として、ターゲット フォレストに存在しない可能性があります。

コマンド ラインまたはスクリプト インターフェイスを使用して sIDHistory を移行する場合の追加要件

  • コマンド ラインまたはスクリプトからの sIDHistory 移行を使用してユーザーまたはグループの移行を開始する場合は、コマンドまたはスクリプトをターゲット ドメインのドメイン コントローラーで実行する必要があります。
  • 移行を実行しているユーザー アカウントには、ソース ドメインとターゲット ドメインの両方で管理者権限が必要です。

グループ マッピングと結合ウィザードの特別な要件

  • グループ マッピングと結合中に sIDHistory を移行する場合は、ソース グループのスコープがターゲット グループのスコープと一致している必要があります。

トラブルシューティング

フォレスト間の sIDHistory 移行のトラブルシューティングに使用できる最も基本的な手順は、ユーザー アカウント移行ウィザードまたはグループ アカウント移行ウィザードを使用してテスト モード移行を実行する方法です。

テスト モードの移行中に、ADMTv2 は次の依存関係を検証します。

  • {SourceNetBIOSDom}$$$ ローカル グループが作成されます。
  • ソース プライマリ ドメイン コントローラーまたはプライマリ ドメイン コントローラー エミュレーターの TcpipClientSupport がオンになっている。
  • 両方のドメインでの監査が有効です。

必要に応じて、ADMT は設定されていないこれらの依存関係を修復できます。 これらの設定を修復または構成するには、ADMT の実行に使用するアカウントに、タスクを実行するのに十分なアクセス許可が各ドメインに必要です。

ウィザードだけがこれらのチェックと修正を実行します。 コマンド ラインインターフェイスとスクリプト インターフェイスは、これらのチェックを実行せず、正しい構成なしでは動作しません。

フォレスト間の sIDHistory 移行に関する一般的なエラー メッセージ

"ハンドルが無効です (エラー コード = 6)。"

このエラーは、移行ツールが移行元プライマリ ドメイン コントローラーの RPC エンドポイントにバインドできない RPC の問題を示します。 以下のいずれかの原因が考えられます。

  • ソース プライマリ ドメイン コントローラーまたはプライマリ ドメイン コントローラー エミュレーターの TcpipClientSupport が有効になっていない。
  • TcpipClientSupport が構成された後、プライマリ ドメイン コントローラーまたはプライマリ ドメイン コントローラー エミュレーターは再起動されていません。
  • DNS または NetBIOS の名前解決が機能していません。

ドメインの監査と TcpipClientSupport を確認する方法が見えなかった。 Sid を移行できない。 指定したローカル グループが存在しません。

通常、このエラーは、{SourceNetBIOSDom}$$$$ 名を持つユーザーまたはグローバルまたはユニバーサル グループが既に存在することを示します。 ADMT は通常、その名前のローカル グループを作成しますが、セキュリティ プリンシパルが既に名前を持つ場合は作成できません。

ドメインの監査と TcpipClientSupport を確認する方法が見えなかった。 Sid を移行できない。 アクセスが拒否されました。

通常、このエラーは、ADMT の実行に使用するユーザー アカウントに、一方または両方のドメインで移行を実行するための十分なアクセス許可を持たなかったかどうかを示します。ドメイン名の参照に失敗しました。rc=1332。 アカウント名とセキュリティの間のマッピングは実行されません。 sIDHistory を使用した移行後の Migration.log ファイルのこのエラーは、通常、ソース ドメインがターゲット ドメインに存在しない信頼を構成したことを示します。 この問題を解決するには、移行の信頼ウィザードを実行して、ソース ドメイン内の信頼をマップし、ターゲット ドメイン内のリレーションシップをレプリケートします。

その他の sIDHistory 情報

sIDHistory は、Active Directory のセキュリティ プリンシパルの複数値属性で、最大 850 の値を保持できます。 以前のバージョンの Windows を実行しているドメイン コントローラーとの下位互換性を提供するために、sIDHistory 属性は、Windows の機能レベルで動作しているドメインでのみ使用できます。

一部のサード パーティベンダー製品では、混在モード ドメインで sIDHistory を有効にできます。 これらのクレームは、パブリック API の正当な使用を表すのではありません。 このようなツールを使用するドメイン管理者は、Active Directory の展開をサポートされていない状態に置くリスクがあります。

フォレスト内の移行中に、LDAP_Renameオブジェクトの移動を担当します。 この理由から、移行されたオブジェクトは、objectGUID やパスワードなどの重要な識別データを保持します。 これは、DSAddSidHistory を呼び出してターゲット ドメイン内の属性を設定するフォレスト間移行の場合ではありません。 フォレスト間の複製ではパスワードの移行を有効にできますが、この種類の移行では objectGUID は常に失われます。

どちらの場合も、移行されたオブジェクトには、ターゲット ドメインによって新しい sID が割り当てられます。 元の sID が、新しいドメインの移行されたオブジェクトの sIDHistory 属性に追加されます。 これが発生した後、標準の Active Directory 管理ツールを使用して sIDHistory 属性を変更または削除することはできません。 sIDHistory 属性が SAM によって所有されている場合、これは許可されません。 スクリプトまたは公開されていない Microsoft の内部ツールを使用して、sIDHistory をクリアできます。

sIDHistory は移行ツールであり、セキュリティ プリンシパルに無期限に接続することを意図していません。 sIDHistory を移行すると、ドメイン移行プロセスを大幅に容易にし、簡素化することができますが、実稼働企業で sIDHistory を実装する前に考慮する必要がある重要なセキュリティ上の問題があります。

セキュリティ Windowsは、sIDHistory およびグループ sID を含む最大 1,023 の sID を保持できます。 Kerberos には 73-sID バッファー Windows Kerberos が含むため、Kerberos も制限されます。 このサイズは、エンタープライズ全体のレジストリ変更によって 2 倍にできます。 これらの制限を超える場合、MaxTokenSize の制限に違反し、Kerberos 認証の失敗や、ポリシーの不安定なアプリケーションや存在しないアプリケーションなど、予期しない結果につながる可能性があります。 これらの問題を回避するには、ドメイン移行後にリソース アクセスを維持するための長期的なソリューションとして、sIDHistory の代わりにセキュリティ変換を使用します。