AD移行を伴うFSx for Windows File Serverへの移行シナリオ

ADドメイン移行を伴うFSx for Windows File Serverへの移行手法を紹介します。

#Amazon FSx

#Amazon FSx for Windows File Server

#AWS Managed Microsoft AD

#クラウド移行

南栄樹

2022.09.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

ネクストモードの南です。

ADとファイルサーバの移行先としてAWS Managed Microsoft ADとFSx for Windows File Serverを選択する際、ADドメインの移行が伴う（※）ため、AD移行の影響を考慮してファイルサーバの移行方法を検討する必要が生じます。
※ 移行元と同一のADドメインのドメインコントローラにはなれず、信頼関係しか結べないため

ADドメインの移行を伴う場合において、ファイルサーバのデータをどのようにFSx for Windows File Serverに移行していくのかという検証をしましたので、本記事でご紹介をさせていただきたいと思います。
検証にあたっては以下のAWSの公式ブログで紹介されている移行シナリオを参考にして進めています。

構成

移行元、移行先環境は以下の通りです。移行元はVPCを分けて疑似オンプレ環境としています。

移行元ドメイン（onprem.local）
- 移行元ADサーバ：Windows Server 2016
- 移行元ファイルサーバ：Windows Server 2016
移行先ドメイン（corp.aws-minami.com）
- AWS Managed Microsoft AD
- FSx for Windows File Server

移行概要

移行作業全体の流れとしては以下のようになります。

移行元のADとManaged MS AD間で双方向の信頼関係を結ぶ
移行元のADドメインからManaged MS ADのADドメインへユーザーとセキュリティグループを移行する
移行元のファイルサーバ上のアクセス権限（ACL）をManaged MS ADのADドメイン用に複製する
移行元のファイルサーバからファイルとフォルダをAmazon FSxに移行する

このうち1.と2.については、先に紹介した公式ブログではあらかじめ実施済みのものとして進めていますので、本記事でも詳細は割愛します。
なお、ADの移行方法についても多くの手法がありますが、以下のブログではADMTを使用したADの移行シナリオが紹介されています。今回の環境も以下のブログに沿ってユーザーとセキュリティグループを移行した状態にしています。

今回紹介する移行手法では、ユーザー名、セキュリティグループ名も変更せず移行元のものを引き継いでいることを前提としています。
検証した環境でも移行元と移行先でそれぞれ以下のように同じ名称のユーザー、セキュリティグループを複製した状態にしてあります。

移行元ADドメイン（onprem.local）
2つのOU（TestOU1、TestOU2）を作成しています
移行先ADドメイン（corp.aws-minami.com）
移行元と同名のOU、ユーザー、セキュリティグループを複製

以下では3.と4.の手順について解説をしていきます。

移行元のADとManaged MS AD間で双方向の信頼関係を結ぶ
移行元のADドメインからManaged MS ADのADドメインへユーザーとセキュリティグループを移行する
移行元のファイルサーバ上のアクセス権限（ACL）をManaged MS ADのADドメイン用に複製する
移行元のファイルサーバからファイルとフォルダをAmazon FSxに移行する

手順検証

まず、移行元のファイルサーバ上のアクセス権限（ACL）をManaged MS ADのADドメイン用に複製していきます。

今回の検証ではSubInAclというツールを使用して、移行元ファイルサーバに対して移行先AD用のアクセス権限（ACL）を複製していきます。 ACLの複製後に、移行先AD側のユーザーからもファイルサーバのデータへアクセスができるようになります。

移行元のファイルサーバでは共有フォルダ（C:\sharefolder）配下に各OU用のフォルダを作成し、それぞれ各OUに所属するユーザー、セキュリティグループのみに権限を与えた状態にしています。

移行元ファイルサーバの共有フォルダ構成
```
sharefolder
├─TestOU1
└─TestOU2
```

1. SubInAclのインストール

はじめにSubInAclのインストールを進めていきます。

以下のサイトからインストールファイルをダウンロードします。
補足に記載していますが、古いツールとなるためWayback Machineのアーカイブからダウンロードをする必要があります。

補足：SubInAclについて
Windowsから提供されている無償のツールです。以下の説明にもある通り、今回のようにADドメインの移行が伴う場合に、コマンドラインでファイルやフォルダのアクセス情報（ACL）を置き換えたり複製することができます。
ただ、古いツールなので環境や条件によってはうまく動作しないケースもあると思います。（今回はWindows Server2016環境で検証しましたが、特に問題なく使用できました。）
SubInAclを使用してうまくいかない場合は、あらかじめFSxで移行後のフォルダ作成と適切なACLを付与し、フォルダ毎にデータをコピーする、などの代替手段をご検討ください。

SubInACLは、管理者がファイル、レジストリキー、およびサービスに関するセキュリティ情報を取得し、この情報をユーザーからユーザーへ、ローカルまたはグローバルグループからグループへ、ドメインからドメインへ転送できるようにするコマンドラインツールです。たとえば、ユーザーがあるドメイン (DomainA) から別のドメイン (DomainB) に移動した場合、管理者はユーザーのファイルのセキュリティ情報で DomainA\User を DomainB\User に置き換えることができます。これにより、ユーザーは新しいドメインから同じファイルにアクセスできるようになります。

実際に検証の方を進めていきます。

SubInAclは移行元のファイルサーバにインストールをします。
SubInAclのインストールファイルを移行元のファイルサーバにコピーしたら、インストールファイルをダブルクリックしてインストーラを起動します。

あとはデフォルトのままインストーラを進め、インストールは完了となります。

補足：SubInAclのアンインストール手順
SubInAclのインストーラを再度起動することでアンインストールをすることができます。

2. ファイルサーバのアクセス権限（ACL）の複製

続いて、SubInAclを使ってファイルサーバのACLの複製をしていきます。

補足：
今回の環境ではこちらに記載しているエラーを回避するために暫定対処を実施しています。
他の環境でも同様のエラーが出たという情報があり、再現するケースが多そうなのであらかじめ内容の方をご確認ください。

移行元のファイルサーバで管理者権限でコマンドプロンプトを開き、以下のコマンドを実行してSubInAclのインストール先に移動します。

cd “C:\Program Files (x86)\Windows Resource Kits\Tools”

インストール先のフォルダで、ACLを複製するコマンドを実行します。コマンド構文は下記の通りです。
また、「/testmode」のオプションをつけると、コマンドがテストモードで実行されます。テストモードの場合は実行ログは出力されますが、設定は反映されませんので、まずはテストモードで実行をすることを推奨します。

コマンド構文
```
subinacl /outputlog=<実行ログ用ファイルのパス> /errorlog=<エラーログ用ファイルのパス> /Subdirectories <ACLを複製するフォルダ、ファイル> /migratetodomain=<移行元ドメインのNetBIOS名>=<移行先ドメインのNetBIOS名> [/testmode]
```
- 実行ログ用ファイルのパス：出力先のフォルダは事前に作成が必要
- エラーログ用ファイルのパス：出力先のフォルダは事前に作成が必要
- ACLを複製するフォルダ、ファイル：フォルダ配下すべてを対象にする場合は*(アスタリスク)を指定
- /testmode：テストモード実行時に指定

実際に今回の環境で適用をしていきます。
まずはテストモードでコマンドを実行します。

subinacl /outputlog=C:\temp\SubInAcl_log.txt /errorlog=C:\temp\Err_log.txt /Subdirectories C:\sharefolder\* /migratetodomain=onprem=corp /testmode

コマンドが正しく実行されると、コマンドで指定した実行ログファイルに実行結果が記録されます。実行ログファイルを開くと追加されたACLと対象のフォルダ／ファイルが記載されていますので、想定通りの実行結果となっているか確認します。（テストモードで実行しているので、このタイミングではまだ設定は反映されていません。）

参考：実行ログファイルの出力内容（クリックして展開）

C:\sharefolder\TestOU1 : new ace for corp\group1
C:\sharefolder\TestOU1 : add Perm. ACE corp\group1
C:\sharefolder\TestOU1 : new ace for corp\administrator
C:\sharefolder\TestOU1 : add Perm. ACE corp\administrator
C:\sharefolder\TestOU1 : new ace for corp\user1
C:\sharefolder\TestOU1 : add Perm. ACE corp\user1
C:\sharefolder\TestOU1 : corp\domain users is the new Primary Group 
C:\sharefolder\TestOU1 replace Primary Group onprem\domain users with corp\domain users
C:\sharefolder\TestOU1 (TestMode) : 4 change(s)
C:\sharefolder\TestOU2 : new ace for corp\group2
C:\sharefolder\TestOU2 : add Perm. ACE corp\group2
C:\sharefolder\TestOU2 : new ace for corp\administrator
C:\sharefolder\TestOU2 : add Perm. ACE corp\administrator
C:\sharefolder\TestOU2 : new ace for corp\user2
C:\sharefolder\TestOU2 : add Perm. ACE corp\user2
C:\sharefolder\TestOU2 : corp\domain users is the new Primary Group 
C:\sharefolder\TestOU2 replace Primary Group onprem\domain users with corp\domain users
C:\sharefolder\TestOU2 (TestMode) : 4 change(s)
C:\sharefolder\TestOU1\testfile1.txt : new ace for corp\group1
C:\sharefolder\TestOU1\testfile1.txt : add Perm. ACE corp\group1
C:\sharefolder\TestOU1\testfile1.txt : new ace for corp\administrator
C:\sharefolder\TestOU1\testfile1.txt : add Perm. ACE corp\administrator
C:\sharefolder\TestOU1\testfile1.txt : new ace for corp\user1
C:\sharefolder\TestOU1\testfile1.txt : add Perm. ACE corp\user1
C:\sharefolder\TestOU1\testfile1.txt : corp\domain users is the new Primary Group 
C:\sharefolder\TestOU1\testfile1.txt replace Primary Group onprem\domain users with corp\domain users
C:\sharefolder\TestOU1\testfile1.txt (TestMode) : 4 change(s)
C:\sharefolder\TestOU2\testfile2.txt : new ace for corp\group2
C:\sharefolder\TestOU2\testfile2.txt : add Perm. ACE corp\group2
C:\sharefolder\TestOU2\testfile2.txt : new ace for corp\administrator
C:\sharefolder\TestOU2\testfile2.txt : add Perm. ACE corp\administrator
C:\sharefolder\TestOU2\testfile2.txt : new ace for corp\user2
C:\sharefolder\TestOU2\testfile2.txt : add Perm. ACE corp\user2
C:\sharefolder\TestOU2\testfile2.txt : corp\domain users is the new Primary Group 
C:\sharefolder\TestOU2\testfile2.txt replace Primary Group onprem\domain users with corp\domain users
C:\sharefolder\TestOU2\testfile2.txt (TestMode) : 4 change(s)

実行ログファイルを確認して問題がなければ、テストモードのオプションを外してコマンドを実行します。

subinacl /outputlog=C:\temp\SubInAcl_log.txt /errorlog=C:\temp\Err_log.txt /Subdirectories C:\sharefolder\* /migratetodomain=onprem=corp

実行ログファイルを再度確認し、テストモードと同様の出力結果となっていることを確認します。
また、任意のフォルダを右クリックして [プロパティ]を開き、[セキュリティ]のタブを確認します。
こちらに移行先ADドメインのユーザー／セキュリティグループが追加されていればOKです。

設定変更前
移行元ADドメインのユーザー、セキュリティグループのみが設定された状態
設定変更後
同名の移行先ADドメインのユーザー、セキュリティグループが各フォルダに追加されました

補足：エラー時の対応

コマンドがエラーとなった場合は、エラーログ出力先のファイルからエラー内容の確認をします。

補足：RPCエラー出力時の対応

検証した環境ではRPCに関連するエラーが出力されました。

エラーログファイルの出力内容

1722 Unexpected error  NetUserModalsGet on server \\<Managed MS ADのホスト名>
Error finding domain name : 1722 RPC サーバーを利用できません。

エラー内容的にAWS Managed Microsoft AD側の名前解決ができないことが原因のようですが、正攻法で解消することができませんでした。
そのため、以下のようにhostsファイルで名前解決ができるようにすることでエラー回避をしています。（他にも同様のエラーが再現したという情報があったので、あらかじめこちらの対処を実施してからコマンドを実行するほうが無難かもしれません。）

RPCエラーの暫定対処

移行元のファイルサーバのhostsファイル（C:\windows\system32\drivers\etc\hosts）を開きます。

hostsファイルに以下のようにAWS Managed Microsoft ADのIPアドレスとホスト名を追記して保存します。（2インスタンス分を記載）

<Managed MS ADのIPアドレス1>	<Managed MS ADのホスト名1>
<Managed MS ADのIPアドレス2>	<Managed MS ADのホスト名2>

参考：今回の環境の場合

10.0.3.132	win-ckl9fqn5vu9
10.0.2.107	win-12qo6nqvr4b

AWS Managed Microsoft ADのホスト名は以下で確認できます。

AWS Managed Microsoft AD側ドメインに参加したクライアントで「Active Directoryユーザーとコンピューター」を開く
ドメイン配下の「Domain Controllers」をクリック

ホスト名が確認できたらFQDNでnslookupやpingを実行すれば対応するIPアドレスが確認できます。

3. FSxへの移行

前の項目でAWS Managed Microsoft AD側のユーザーからもファイルサーバのデータへアクセスができる状態になっています。このファイルサーバのデータをACLごとFSxに移行していきます。

公式ブログではDataSyncを使用してファイルサーバのデータをFSxにコピーしていますが、今回はシンプルにRobocopyを使って検証をしました。
Robocopyを使用したFSxへの移行については以下の公式のユーザーガイドを参考にしています。

手順の方を進めていきます。

AWS Managed Microsoft AD側のADドメインに参加している任意のクライアントにログインし、コマンドプロンプトを開きます。
以下のコマンドで移行元ファイルサーバの共有フォルダを任意のドライブレターにマッピングします。

net use Y: \\<移行元ADドメイン>\<共有フォルダ> /user:<移行元ADドメイン>\Administrator

同様に、FSx側の共有フォルダも任意のドライブレターにマッピングします。

net use Z: \\<移行先ADドメイン>\<共有フォルダ> /user:<移行先ADドメイン>\Admin

以下のコマンドを実行し、移行元のファイルサーバのデータコピーを実施します。
/copyオプションでSを含めていますが、これによって前項で複製したACLも含めてコピーすることができます。
また、実際の本番での移行の際は、データコピーの通信によって業務影響を生じさせることがないように、Robocopyで帯域制御をかけることなどをご検討ください。

robocopy Y:\ Z:\ /copy:DATSOU /secfix /e /b /MT:8

コマンド解説
- /copy :: ファイルにコピーする情報 (既定値は /copy:DAT)
  - D :: データ
  - A :: 属性
  - T :: タイムスタンプ
  - S :: セキュリティ（NTFS ACL）
  - O :: 所有者情報
  - U :: 監査情報
- /secfix :: スキップしたファイルも含むすべてのファイルのファイルセキュリティを修正します。
- /e :: 空のディレクトリを含むサブディレクトリをコピーします。
- /b :: バックアップモードでファイルをコピーします。
- /MT[:n] :: n 個のスレッドのマルチスレッドコピーを実行します(既定値 8)

FSxにアクセスして、正常にデータがコピーできていることを確認します。

以上で移行手順は完了となります。
任意の端末にAWS Managed Microsoft AD側のユーザーでログインすれば、FSxへアクセスができる状態になっています。

実際にAWS Managed Microsoft AD側のユーザーでログインした後にFSxにアクセスをしてみますが、user1でログインした場合にはTestOU1のフォルダのみアクセスができ、user2でログインした場合にはTestOU2のフォルダのみアクセスができるようになっており、移行元環境と同じアクセスコントロールを保ったまま移行することができています。

user1でログイン
- TestOU1にはアクセス可能
- TestOU2にはアクセス不可

user2側でも期待値通りの動作になっていました。

おわりに

コストや運用の観点からAWS Managed Microsoft ADは魅力的ですが、ADの移行が絡むと複雑になるため、なかなか選択しづらいというのが実情だと思います。現実的にはAD on EC2 ＋ FSxの構成を採用することが多いと思いますが、EC2の構築や運用保守が必要となり、マネージドサービスの恩恵を最大限に受けることができませんでした。

今回紹介させていただいた移行方式であれば、ADも含めてマネージドサービスを利用することができます。移行時に少なからず手間がかかりますが、長期的に見ると運用負荷やランニングコストの面でメリットが大きい選択肢であると思います。移行の検討をする際に本記事が少しでもお役立つことがあれば幸いです。

また、ネクストモードではオンプレミス環境からのAWSへのクラウドマイグレーションを多数手がけております。クラウドマイグレーションを検討しているが進め方に不安があるという場合には、クラウドマイグレーションの実績が豊富なネクストモードまでぜひご相談ください。