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


概要


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

詳細


ADMTv2 を使用して、フォレスト間のユーザーまたはグループ移行の一環として sIDHistory を移行する場合、基本となる移行の必要条件に合わせて構成を行う必要があります。


デフォルトでは、フォレスト内の移行時には sIDHistory、パスワード、および objectGUID はすべて保持されますが、これはフォレスト間の複製時には該当しません。


フォレスト間の操作にはビルトインのセキュリティ コンテキストがないため、フォレストの境界を越える操作のセキュリティを保護する手段を講じる必要があります。

構成

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

sIDHistory を含まないウィザード ベースの基本的なユーザーおよびグループ アカウントの移行

  • 移行元ドメインは、移行先ドメインを信頼している必要があります。
  • 移行元ドメインでは、Microsoft Windows NT 4.0 Service Pack 4 (SP4) 以降が動作している必要があります。
  • 移行先ドメインは、Microsoft Windows 2000 ネイティブ モードまたはそれ以降である必要があります。
  • ADMTv2 を実行するユーザー アカウントは、移行元ドメインで Administrator の権限を持っている必要があります。
  • ADMT のユーザー アカウントは、移行先コンテナにユーザー オブジェクトまたはグループ オブジェクトを作成するための委任されたアクセス許可を持っている必要があります。
  • ドメイン間に DNS (ホスト名) 名前解決および NetBIOS 名前解決が必要です。

sIDHistory の移行に必要なその他の依存関係

  • 移行元および移行先ドメインの両方に関するアカウント管理の成功または失敗の監査。
  • Windows NT 4.0 移行元ドメインは、このユーザーおよびグループ管理の監査を呼び出します。
  • {SourceNetBIOSDom}$$$ という名前の移行元ドメイン内の空のローカル グループ。
  • 移行元ドメインのプライマリ ドメイン コントローラでHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport レジストリ キーを 1 に設定する必要があります。
  • レジストリの構成後に、移行元ドメインのプライマリ ドメイン コントローラを再起動する必要があります。
  • 移行先ドメインが Windows 2000 ドメインの場合、Windows のセキュリティには、移行先ドメインの Administrator の権限を持つユーザー資格情報が必要となります。sIDHistory の移行をオンにする場合、ウィザードでこれらの資格情報を追加します。
  • 移行先ドメインが Windows Server 2003 ドメインの場合、Windows のセキュリティには、委任された MigratesIDHistory の拡張された権利または移行先ドメインの Administrator の権限を持つ、ユーザー資格情報が必要となります。
  • 移行する sID が、移行先フォレストに (他のオブジェクトのプライマリ sID または sIDHistory 属性として) 重複して存在しないようにする必要があります。

コマンド ラインまたはスクリプト インターフェイスで sIDHistory を移行する場合のその他の条件

  • コマンド ラインまたはスクリプトから、sIDHistory の移行と共にユーザーまたはグループの移行を開始する場合は、移行先ドメインのドメイン コントローラ上でコマンドまたはスクリプトを実行する必要があります。
  • 移行を実行するユーザー アカウントは、移行元および移行先ドメインの両方の Administrator の権限を持っている必要があります。

グループのマッピングおよび結合ウィザードの特別な必要条件

  • グループのマッピングおよび結合時に 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 の間のマッピングは実行されませんでした。
このエラーは、sIDHistory の移行を伴う移行後に Migration.log ファイルに出力され、通常、移行元ドメインで構成した信頼が移行先ドメインに存在しないことを示しています。この問題を解決するには、信頼の移行ウィザードを実行して、移行元ドメインに信頼をマッピングしてから、移行先ドメインに関係を複製します。

sIDHistory に関する補足情報

sIDHistory は、Active Directory のセキュリティ プリンシパルの複数値をもつ属性で、850 個までの値を保持します。以前のバージョンの Windows が動作するドメイン コントローラとの下位互換性を実現するため、sIDHistory 属性は Windows 2000 ネイティブ モードまたはそれ以降の機能レベルで動作するドメインでのみ使用できます。


一部のサードパーティ製品では、混在モード ドメインで sIDHistory をオンにできますが、これは公開されている API の正当な使用方法ではありません。ドメイン管理者がこのようなツールを使用すると、その Active Directory の運用環境はサポート対象外となり、リスクが生じます。


フォレスト内の移行時には、LDAP_Rename がオブジェクトを移動する役目を果たします。このため、移行されたオブジェクトは、objectGUID やパスワードなどの重要な ID データを保持します。これは、DSAddSidHistory を呼び出して移行先ドメインに属性を設定する、フォレスト間の移行とは異なります。フォレスト間の複製でパスワードの移行をオンにできますが、このような移行の際には objectGUID は常に失われます。


いずれの場合も、移行先ドメインによって、移行されたオブジェクトに新しい sID が割り当てられます。元の sID は、新しいドメインの移行されたオブジェクトの sIDHistory 属性に追加されます。この後、標準の Active Directory 管理ツールを使用して、sIDHistory 属性が変更または削除されない場合があります。これが許可されない理由は、sIDHistory 属性が SAM に所有されているためです。スクリプトまたはマイクロソフトの非公開社内ツールを使用することで、sIDHistory を消去できます。


sIDHistory は移行用のツールであり、セキュリティ プリンシパルに永続的に関連付けられるものではありません。sIDHistory の移行によってドメイン移行プロセスが大幅に簡略化されますが、実運用環境に sIDHistory を導入する前に、セキュリティ上重要な副次効果があることを考慮する必要があります。


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

関連情報


この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 322970 (最終更新日 2003-04-03) をもとに作成したものです。