構想１年半、実作業3ヶ月掛かりましたが、「異なるドメイン間で、SID History付きでアカウントを移行する。」という設定作業がとうとう完成しました。
（もっとも、いくつか走っている設定作業の内の１つであり、これだけやっていた訳ではありませんが。。。。）
本当に、長かった！！！
最終的には、設定できましたが、下記に躓いた点を列記します。
Netでも散々、調べたのですが、サーバOSのVersionによって、設定方法が微妙に違う点もあり、また、網羅的に書いてあるサイトもない様なので、戸惑いました。
下記の記載が、同じ問題を抱えるEngineerの役に立つことを願いつつのアップです。
下記の記載が、同じ問題を抱えるEngineerの役に立つことを願いつつのアップです。
長文です。
***********************************************************************
OS環境詳細
Domain A のドメインコントロ-ラー ： Windows2003R2SP２
(VMWare ESXi 4.0試用版上で仮想化）
Domian B のドメインコントロ-ラー ： Windows2003R2SP２
（VMWare Server 2.0無償版で仮想化）
* 異なるAD間の信頼関係の締結や、SID Historyの移行に関しては、各種資料がNetに溢れているが、Windows2000サーバやNTサーバでは、信頼関係の設定方法が微妙に違っており、中途半端に読むと逆に、混乱します。
Windows2003サーバに関して、明確に書かれた資料を読むべきと考えます。
【作業全体の流れ】
作業全体の流れは、下記の通りです。
移行作業詳細手順概要） 日本語
移行作業詳細手順） 詳細・英語
ポイントは、「ADMTの、Account Migration Wizard を動かすだけではダメで、Security Translation Wizard、Computer Migration Wizard, さらに、再度、User Account Wizardをも、動かさないといけない。」と言う事だと判明。
（下記、引用）=============================================================
1. Migrate managed service accounts. Managed service accounts must be migrated before computers.
2. Migrate all the user accounts with the account enabled in the source domain, disabled in the target domain, with complex password selected, and with no attributes migrated.
3. Translate local user profiles for a batch of users.
4. Migrate workstations in batches that correspond to the user account batches.
5. Before you migrate the batch of user accounts, verify that local profile and workstation migration succeeded for all users in the batch. Do not migrate any user account for which profile or workstation migration failed. This will result in users overwriting their existing profiles when they log on to the target domain.
6. Remigrate user accounts in batches with the account set to expire in the source domain in seven days, the target account enabled, with password migration selected, and all attributes migrated.
7. After each batch, remigrate all global groups to update any group membership changes.
8.Notify users in the batch to log on to the target domain.
9.After all users are migrated, run a final global group migration to update any group membership changes.
==========================================================================
【躓いた点】
1）VMWare ESXi4.0（試用版）と、VMwareサーバ2.0をテスト環境に使い、同一の仮想化モジュール(Windows2003R2sP2のvmdkファイル）を、コピーして、それを両サーバでコンフィグした上で、使用していたが、同一モジュールを使用するため、SIDが一致してしまう事があるらしい。
http://support.microsoft.com/kb/930218/en-us
そうなると、別々のマシンに乗った、Windows2003サーバであるにも関わらず、Windows的には、同一のサーバ上の同一ユーザー（同一SID）が存在すると認識してしまうらしく、異なるAD間での信頼関係が結べないという状況が発生した。
兎に角、SIDが重複すると、各種問題が発生するので、「ESXiと、VMサーバとで、別個にWindows2003をフレッシュインストールすべき。」と気がつくのに時間が掛かった。
2）信頼関係の入力方向と出力方法の概念の理解に時間が掛かった。
信頼関係の概要、及び、設定手順。
http://www.techrepublic.com/article/solutionbase-active-directory-domains-and-trusts-console/5160515
3）当初は、「信頼関係を結んだDomain Controller同士で、アカウントの移動を行えば、自動的にSID Historyも移行する。」と考えていたが、「Domain間の信頼関係締結と、移動アカウントのSID Historyの引継ぎは、別個の問題である。」と気がつくのに、非常に時間が掛かった。
Windows2003サーバの場合、異なるAD間で信頼関係を結んだ場合（フォレスト間信頼）、SIDフィルタは、Defaultで有効になるので、アカウント移行後に、移行元ADに於いて、アクセス権のあったリソースにアクセスできなくなってしまう。
したがって、移行元のADに於いて、SIDフィルタ設定を無効にする必要があり、
その無効にする為のツールが、Netdomコマンドツール。
要は、移行元ADにて、SIDフィルタをDisableにしないと、SID History付きで、アカウントIDの別ドメインへの移行（Domain A→ Domain B）が出来ない。
従って、SID Filteringを解除する必要がある。
アカウントの移行には、SIDフィルタリングを信頼元ADで無効後、信頼先ADにて、ADMTを使い、Account IDを一つずつ移行するとう言う作業が必要。
How to disable SID Filtering
SID History Filteringの概要
（下記の記述があります。）
======================================＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Windows Server 2003 automatically enables SID filter quarantining on all external trusts that are created by a Windows Server 2003 domain controller. External trusts that are created using domain controllers running Windows 2000 Server with Service Pack 3 (SP3) or earlier must be manually configured to enable SID filter quarantining.
Although it is not recommended, you can disable security identifier (SID) filter quarantining for an external trust by using the Netdom.exe tool. You should consider disabling SID filter quarantining only in the following situations:
· You have an equally high level of confidence in the administrators who have physical access to domain controllers in the trusted domain and the administrators with such access in the trusting domain.
· You have a strict requirement to assign universal groups to resources in the trusting domain, even when those groups were not created in the trusted domain.
· Users have been migrated to the trusted domain with their SID histories preserved, and you want to grant those users access to resources in the trusting domain based on the SIDHistory attribute.
==================================================================
４）移動アカウントに於いて、SID Historyを引き継ぐためには、SIDフィルターを移動元ADサーバで無効にする必要がある。
（Windows2003では、Defaultで有効になっている。）
しかしながら、SIDフィルターを無効にするのは、ADMTツールではなく、別ツール（Netdom.exe)が必要である。」と気がつくのに、非常な時間が掛かった。
移行元ADでの実際のコマンド
===================================＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
C:\Program Files\Support Tools>Netdom trust local /domain:global /quarantine:No
/userD:administrator /passwordD:password
Setting the trust to not filter SIDs.
The command completed successfully.
==================================＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
5）「異なるAD間でのSID Historyを含むアカウント移行」に於いて、当初はPassword
も移行する予定であったが、Password移行には、Password Export Server（PES)を構築する等、別途、大規模作業が必要であることが判明した。
PESサーバの設置が大作業であることに気がつくのに、時間が掛かった。
*************************************************************************
LDIFDE doesn’t support importing Passwords. To change user’s password you need to convert from Plain Text to Base64 character. We can use a utility to convert from Plain Text to Base64.
上記２つの文書より、下記が自明。
- AD間で、PasswordのExportは、できない。
- PasswordのImportは出来るが、「Passwordを一旦、Plain Textで入手し、それを、Base64形式にツールを使って、エンコードし、Import先ADに入れる。」と言う処理が必要なので、簡単にはできない。（あるいは、Password Export Server（PES）を建てる等の処理が必要。）
*********************************************************************
6）「異なるAD間でのSID Historyを含むアカウント移行」に於いては、ユーザプロファイルの移行も目指したが、すべてのユーザープロファイルが移行できる訳ではないことが判明した。
（例えば、EFSフォルダにアクセスする為のPrivate Keyは、アカウント移行ではサポートされない等。）
この事実に気がつくのに、非常な時間が掛かった。
下記の記述から、EFSで使うPrivate Keyは、Exportされない事を確認。
=====================================＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
You cannot migrate every user property when you migrate user accounts. For example, Protected Storage (Pstore) contents for Windows NT 4.0 workstations, including Encrypting File System (EFS) private keys, are not migrated by the Active Directory Migration Tool (ADMT) when you migrate user accounts. To migrate Pstore contents, you must export and import keys during the migration process.
========================================＝＝＝＝＝＝＝
７）テスト環境は、当初、Netscreen 5GTで構築していたが、５GTでは、DMZ Segmentを構築できないと気がつくのに、時間が掛かった。
結局、SSG5を使い、LAN側、WAN側、DMZの３セグメントを普通に構築した。
数百ページに及び、NetscreenのManualをよく読んで、やっと、５GTの機能が限定されたものと気づいた。
Netscreenのマニュアルは、ここ。
→→→ http://www.juniper.net/techpubs/software/screenos/screenos4x/translated/
************************************************************************
0 件のコメント:
コメントを投稿