LoginSignup
4

More than 5 years have passed since last update.

異なるドメインへACLを保持したデータ移行方法

Posted at

Windows Server 2008 R2のAD環境からWindows Server 2012 R2のAD環境へ、以下の要件のデータ移行を行う機会がありましたので、その手法をメモしておきます。

要件

[要件1] ユーザ、グループを異なるドメインへ移行する。

[要件2] ファイルやディレクトリを異なるドメインへ移行する。

[要件3] 移行するファイルやディレクトリのACLは保持する。

制約

[制約1] 異なるドメイン間で信頼関係を結ぶことはできない。

[制約2] 移行するデータはNAS(LinuxのSambaベース)で中継する。

実現手順概要

異なるドメインへのデータ移行ではActive Directory 移行ツール(ADMT)を使用する方法が王道だと思いますが、異なるドメイン間で信頼関係を結ぶことができないという制約があり、ADMTは断念しました。
ADMTを使わずに、かつLinuxベースのNASを中継するため、要件3の実現にはACLの設定時にSIDの変換が必要になります。

  • (手順1) データ移行元のユーザ/グループのエクスポート
  • (手順2) データ移行先へユーザ/グループのインポート
  • (手順3) データ移行元のユーザ/グループのSID情報の取得
  • (手順4) データ移行先のユーザ/グループのSID情報の取得
  • (手順5) 手順3と手順4の成果物を利用して、同じユーザ/グループのSIDの変換テーブルの作成
  • (手順6) データ移行元のACL情報の取得
  • (手順7) 手順5と手順6の成果物を利用してACL情報の更新
  • (手順8) データ移行元からNASへのデータ移行
  • (手順9) NASからデータ移行先へのデータ移行
  • (手順10) 手順7の成果物を利用してACL情報の適用

実現手順詳細

(手順1) 移行元ADサーバのコマンドプロンプトで以下のコマンドを実行します。
> csvde -u -f user.csv -r objectCategory=user
> csvde -u -f group.csv -r objectCategory=group

(手順2) 移行先ADサーバのコマンドプロンプトで以下のコマンドを実行します。
> csvde -i -f user.csv
> csvde -i -f group.csv

(手順3) 移行元ADサーバのコマンドプロンプトで以下のコマンドを実行します。
> dsquery group | dsget group -dn -sid
> dsquery user | dsget user -dn -sid

(手順4) 移行先ADサーバのコマンドプロンプトで以下のコマンドを実行します。
> dsquery group | dsget group -dn -sid
> dsquery user | dsget user -dn -sid

(手順5) 手順3と4の出力結果を元にSID変換テーブルを作成します。

ユーザ/グループ 移行元のSID 移行先のSID
CN=User_A,CN=Users,DC=Domain_A,DC=local S-1-5-21-0123456789-0123456789-0123456789-1001 S-1-5-21-9876543210-9876543210-9876543210-1001
CN=User_B,CN=Users,DC=Domain_A,DC=local S-1-5-21-0123456789-0123456789-0123456789-1002 S-1-5-21-9876543210-9876543210-9876543210-1002
CN=Group_A,CN=Users,DC=Domain_A,DC=local S-1-5-21-0123456789-0123456789-0123456789-1501 S-1-5-21-9876543210-9876543210-9876543210-1501
CN=Group_B,CN=Users,DC=Domain_A,DC=local S-1-5-21-0123456789-0123456789-0123456789-1502 S-1-5-21-9876543210-9876543210-9876543210-1502

(手順6) データ移行元サーバのコマンドプロンプトでACL情報の取得します。
> cd <データ移行元ディレクトリ>
> icacls * /t /save <任意のディレクトリ>\acl.txt

(手順7) 手順5と手順6の成果物を利用してACL情報の更新
acl.txtをコピーしacl_new.txtを作成します。
acl_new.txtをメモ帳で開き、手順5の変換テーブルに沿ってSIDを置換していきます。

置換前のSID 置換後のSID
S-1-5-21-0123456789-0123456789-0123456789-1001 S-1-5-21-9876543210-9876543210-9876543210-1001
S-1-5-21-0123456789-0123456789-0123456789-1002 S-1-5-21-9876543210-9876543210-9876543210-1002
S-1-5-21-0123456789-0123456789-0123456789-1501 S-1-5-21-9876543210-9876543210-9876543210-1501
S-1-5-21-0123456789-0123456789-0123456789-1502 S-1-5-21-9876543210-9876543210-9876543210-1502

(手順8) データ移行元のコマンドプロンプトで以下のコマンドを実行します。
> robocopy \\<NASのIP>\共有フォルダ <移行元ディレクトリ> /mir /DCOPY:T

(手順9) データ移行先のコマンドプロンプトで以下のコマンドを実行します。
> robocopy \\<NASのIP>\共有フォルダ <移行元ディレクトリ> /mir /DCOPY:T

(手順10) データ移行先のコマンドプロンプトで以下のコマンドを実行します。
手順7で作成したacl_new.txtをデータ移行先サーバの任意のディレクトリへ配置します。

> cd <データ移行先ディレクトリ>
> icacls . /restore <任意のディレクトリ>\acl_new.txt

なお、手順9でのデータ移行時に、robocopyコマンドを実行したユーザのデフォルトのACLが付与されるため、厳密に移行前と同じACLにはなりません。
今回のケースでは手順9の移行時に付与されたデフォルトのACLはそのまま付与して問題ないためそのままにしていますが、それが許容されないケースでは、icaclsコマンド等でACLの削除が必要になります。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4