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

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

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

詳細

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

既定では、sIDHistory、password、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)。 アカウント名とセキュリティ ID のマッピングが 1 つもされていません。 sIDHistory を使用した移行後のMigration.log ファイルのこのエラーは、通常、ソース ドメインがターゲット ドメインに存在しない信頼を構成していることを示します。 この問題を解決するには、信頼移行ウィザードを実行してソース ドメインの信頼をマップし、ターゲット ドメイン内のリレーションシップをレプリケートします。

その他の sIDHistory 情報

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