COLUMN

2022.10.19 ｜ Writer：ちばちゃん

オンプレミスのADサーバーをAWSに移行する時の課題と注意点セミナーレポート

ADサーバーのクラウド移行をご検討の方、お悩みの方はこちらからお問い合わせください。

2021年7月20日に開催されました「オンプレミスのADサーバーをAWSに移行する時の課題と注意点」のセミナーの模様をレポートさせて頂きます。

当日にお聞きいただけなかった方のご参考となれば幸いです。また、レポートをご覧になっての疑問点や質問事項などございましたら、お問い合わせを頂ければと思います。

１．オンプレミスActive Directoryサーバーの課題点と移行計画
２．AWSで Active Directory を利用する構成と移行方法
３．AWS移行後のActive Directoryの運用
４．NTT東日本によるパブリッククラウド関連サービス
５．Q＆A
６．まとめ
７．おわりに

１．オンプレミスActive Directoryサーバーの課題点と移行計画

とあるオフィス環境を例として、オンプレミスでActive Directoryサーバーが運用されている環境で課題となっているポイントをまとめ、その内容について解説しました。

オンプレミスActive Directoryサーバーの課題点とは

保守・運用の課題

Active Directory自体のハードウェアをどのように保守・運用するか

BCP対策についての課題

データセンターやサーバー室が被災した時にどうやって事業を継続していくか

冗長構成についての課題

支店や事務所と拠点との間に引かれたWANの回線が逼迫した際に備え、どう構成するか

以上がActive Directoryの課題点と考えられます。これらを解決していくためのクラウドの構成について解説していきました。

移行方針の検討

「移行方針の検討」というところで、一般的なAWSへの移行から着目していく。

AWSの移行は、まず「何をしたいのか？」というような目的を必ず明らかにして、「どのような戦略で行くか」という理解から始める。

これにより移行で取るべき戦略が変わる。

【移行の目的例】

運用稼働を削減したい
トータルコストを削減したい
ハードウェアのサポート切れに対応したい
そもそものビジネスモデルを新しくしたい

Active Directoryの場合の移行戦略

Active Directoryの場合、「Replatform」と「Rehost」というような形での移行となるため、核となるビジネスのプロセスに余り変わりはない。

そのため主な戦略は以下の２つとなる。

マネージドサービスを検討する
今あるオンプレミスサーバーをAmazon EC2に置き換える

Active Directoryの移行優先度

AWSの移行は緊急度の高いもの、移行難度の低いものと、順に検討していくのがおすすめ。

【緊急度の高いもの】

データ消失がビジネスリスクになる
ハードウェアのサポート切れ、OSのサポート切れが迫っている

　⇒身近に迫っているものは緊急度高い

【移行難易度が低いもの】

並行運用が可能
夜間の利用が少なく一時的に停止が可能
データ移行手段が複数ある
業務プロセスに影響の少ないもの

移行優先順位は優先緊急度の高いもの、移行難易度の低いものから検討

ファイルサーバーやActive Directoryサーバー、アプリケーションサーバーというような順番で決められていくパターンが多い。

これらは少しずつ移行してクラウドのノウハウを蓄積していくという方法がおすすめ。

Active Directoryの移行

緊急度の高いもの、移行難度の低いものと言う観点から、以下のようにActive Directoryは、優先的に移行できるものとなっている。

緊急度の観点：中

冗長化することが一般的のため、データ消失リスクは低め
一般的に冗長化されていることが多いので、１台ずつ移行できるため、リスクが低い

　移行難易度の観点：中

並行運用が可能

既存 Active Directory サーバーと並行運用

夜間一時的に止めることが可能
データ移行手段が複数ある

移行ツール例

CloudEndure Migration

Active Directory Migration Tool (ADMT)

マスタ移行・昇格

業務プロセスの影響は少ないが、一方でクライアントのDNS等設定変更が必要なケースがある

これはオンプレミスの移行の場合と同じくAWSの移行でもあり得るパターンとなっている

Active DirectoryはIaaSまたはPaaSでの構築がおすすめ

オンプレミスはサービスレベルを自身で決められる反面、設計をはじめ、検討項目が多く、構築のリードタイムが長くなりやすい。

IaaS/PaaS は設計の自由度と料金面で柔軟性が確保でき、構築のリードタイムも短くできる。

	オンプレミス構築	IaaS/PaaS
データの所有権	自身	自身(AWSの場合)
可用性	自身で設計	自身で設計
セキュリティ	自身で設計	責任共有モデルに準ずる
容量・性能	自身で設計	自身で設計
伸縮性	リードタイムあり	即時対応可
保守対応	全て自身で設計	責任共有モデルに準ずる
料金	初期費サーバー・ネットワーク物品費・設定費 Active Directory 設定費	Active Directory設定費
料金	運用費サーバー保守料金(固定費用) データセンタ・サーバー室利用料(固定費用) Active Directory運用費	Active Directory運用費クラウド利用料(従量課金)

Active Directoryと Azure AD の違い

Active Directoryには他にAzure ADというものがある。

Azure ADとは

Azure AD は SaaS の ID 管理ユーザ管理やシングルサインオンを目的としており、利用目的が異なる
既存の置き換えではなく、既存のActive DirectoryとAzure ADを組み合わせて使用されることが多い

ADサーバーのクラウド移行をご検討の方、お悩みの方はこちらからお問い合わせください。

２．AWSで Active Directory を利用する構成と移行方法

次にAWSでActive Directoryを利用する際に構築可能な３つのパターンについて構成例を交えて紹介しました。

IaaS、PaaSで構築するということから、多くは以下の３つのパターンとなる。

	Active Directory サーバー on EC2	AWS Directory Service (Simple AD)	AWS Directory Service (Managed Microsoft AD)
おススメケース	オンプレミスWindows Server での運用とあまり変えたくない人向け	小規模なディレクトリやAWS 内で完結する方向け	高い可用性と耐久性が必要なActive Directory を新たに構築したい方向け
OSの保守・運用	自身で設計	AWS側で管理 (Samba4 ベース)	AWS側で管理 (Windows Server 2012 R2 ベース)
セキュリティ	自身で設計	CloudTrailを利用した監査ログの取得が可能自動アップデート	CloudTrailを利用した監査ログの取得が可能自動アップデート
バックアップ	自身で設計	AWS側で設計手動でスナップショット取得も可	AWS側で設計手動でスナップショット取得も可
可用性と耐久性	自身で設計	AWS側で設計	AWS側で設計
ユースケース	Active Directory 最新版の機能を使いたいハイブリッド構成かつシングルドメイン	小規模なユーザ管理、高度なグループポリシーを使用しない AWS 内で完結する	高い可用性と耐久性が必要オンプレとは信頼関係でよい

①Active Directory サーバー on EC2

オンプレミスWindows ServerをAmazon EC2で立てるため、殆ど変えることなく使うことが出来る。

オンプレミスWindows Server での運用とあまり変えたくない方におすすめ。

Amazon EC2(以下、EC2)

安全でサイズ変更が可能なコンピューティング環境

vCPU やメモリに加えて、ネットワーク帯域や GPU の有無など環境に合わせて選択可能
WindowsやLinux など複数の OS から選択可能

メリット

Windows Server の標準機能が利用可能

⇒他の Windows 対応アプリケーションファイルサーバー等と重畳させることも可能

操作手順はオンプレミスとあまり変わらない

(OS を変えた場合はGUIが変わるので、操作手順は変わる)

Windows Server 2019 を利用した場合 Active Directory の最新版の機能を利用可

デメリット

OS 以上のレイヤは運用保守の検討が必要 (Windows Update など)
冗長化も可能だが、 EC2 を複数台立てた上で冗長化設計が必要
大規模な環境などで高性能なEC2や冗長化対応などでEC2を3台以上で利用すると、高額な料金になる場合がある

２つのサブネット、またはアベイラビリティゾーンを分けて構築をすることで冗長化を行ってロケーションの冗長化を実現

２つのサーバーをマスタとスタンバイに分けて構築することも可能

拠点とAWS間をVPNで接続し、拠点のクライアントとEC2のIPアドレスに分けて接続

②AWS Directory Service (Simple AD)

小規模なディレクトリやAWS 内で完結する場合におすすめ。

Simple AD

Samba4互換のマネージド AD サービス

スモール最大 500 ユーザ、ラージ最大 5,000 ユーザをサポート
2つのアベイラビリティゾーンで冗長化、どの時点まで戻しますか？というポイントインタイムリカバリの実行可能
Samba4互換なので一般的なMicrosoft Active Directoryの機能を使用可

メリット

手軽に可用性や対障害性を向上させることができる
ユーザの一括移行がデータのin/outで実現することが可能
従量課金で利用可能(東京リージョンの場合、ドメインコントローラ1つあたりスモール 0.08USD/h ラージ 0.24USD/h)

デメリット

AWS 外のコンポーネントの管理ができない
既存ドメインとの信頼関係の設定不可
ユーザ管理用に別途 EC2 インスタンスが必要

Amazon WorkSpacesという仮想デスクトップサービスが拠点のクライアントと繋がる形になる。

ドメイン参加できるのはAWSの中だけなので、WorkSpacesから接続してくる必要がある。

以上のような形で、少し構成に工夫が必要と言うのが、注意点となる。

③AWS Directory Service (Managed Microsoft AD)

高い可用性と耐久性が必要なActive Directory を新たに構築する際におすすめ。

Managed Microsoft AD

Windows Server 2012 R2のマネージド Active Directory サービス

Standard(最大30,000オブジェクト、Enterprise(最大 500,000)をサポート
2つのアベイラビリティゾーンで冗長化、ポイントインタイムリカバリを実行可能
マルチリージョンでのレプリケーション可能なので、複数のリージョンで冗長化や復旧実行するような大規模な障害にも対応が可能

メリット

手軽に可用性や対障害性を向上させることができ、大規模な運用が可能
信頼関係を結ぶことができるため、既存のAD と簡単に統合可能
Amazon WorkDogsなどのAWS 各種サービスとのシングルサインオンが利用可能

デメリット

Windows Server 2016 以降に追加されたActive Directoryの機能は利用不可
シングルフォレスト・シングルドメイン構成が必須
WindowsのAdministrator 権限は利用不可。別途AdminがAWSから付与される
Simple ADと比較すると料金やや高め

(東京リージョンの場合、 Standard 0.146USD/h、Enterprise 0.445USD/h)

拠点側のADサーバーと信頼関係を結んでおけば、ハイブリッドで使うことも可能。

AD Connectorというサービスを使うことでAD同士の相互認証も実現可能。

ハイブリッド方式

ここまでがAWSだけを使ったサービスの話でしたが、もしも、AWSを使っているリージョンで障害が発生し、ADが利用不可となった場合、ユーザがクライアントを使えなくなる事態が考えられます。

そのような事態に対応するには、AWSだけではなくハイブリッドで使うという選択肢を取ることができます。

ここからは、拠点とAWSの双方を使用するハイブリット方式の解説をしました。

１つ目のタイプ

拠点のActive Directoryは残しておき、新たにAWS側のManaged Microsoft ADを使用する場合。

２つのドメインを作成することで、信頼関係を構築するというような形を取ることが出来る。

こうした形態では以下のような管理を行う

拠点のコンピューターの管理はオンプレミスのActive Directoryで行う
AWSに移行したサーバーの管理はAWSのクラウドの方での管理を行う

２つ目のタイプ

Active Directoryはハイブリッドで使用するが、同じドメインとしたい場合。

この場合は、Active DirectoryにManaged Microsoft ADを使わずにActive Directoryサーバーon EC2を使用する。

この際、冗長化のため2台作成し、更に管理用のEC2を１台用意した３台で１つのドメインとして構築する。

これにより、万が一どちらかの拠点が使えなくなってしまった場合でも相互に保管が可能となる。

また、基本は例えばAWSを使い、もし何かあった時にオンプレミスの方を使うと言うようなことも可能になる。

AWSへの経路のセキュリティ確保

AWSと拠点間の接続の経路の話を簡単に紹介いたしました。

拠点とAWS間は安全に繋ぐ経路が必要になってきます。こういったところの経路につきましては暗号化やVPN等の方式が使うことが出来ます。

インターネット接続を利用の場合

経路でのセキュリティ確保は行わず、httpsによる暗号化通信でセキュリティを確保

最も手軽で安価

セキュリティレベルは最も低い

インターネットVPNを利用

一般のインターネット回線上にVPNトンネルを仮想的に構築

閉域ネットワークより安価で導入しやすい

インターネット接続環境としては高いセキュリティレベルを確保

閉域ネットワークを利用の場合

IP-VPNで閉域ネットワークを利用

通信事業者が独自に保有する閉域ネットワークを仮想的な専用ネットワークとして複数のユーザで共用し利用するサービス

NTT東日本のサービスを使って閉域ネットワークと一緒に繋ぐことも可能

インターネットVPNより高価

専用線を利用

最も高価

セキュリティレベルは一番高い

Active Directoryのデータ移行

構成に応じて利用できる移行ツールは異なるため、状況に応じて利用する。

	Active Directory サーバー on EC2	AWS Directory Service (Simple AD)	AWS Directory Service (Managed Microsoft AD)
Cloud Endure Migration	△データ同期 ※切替時 DB 不整合に注意	×	×
ADMT+PES	△(Windows 2012 以前)	×	◎
データエクスポートデータインポート	◎	◎	◎
マスタ移行・昇格	◎	×	×

【参考】その他設計上の注意点

フォレスト/ドメイン/OU設計/サイトトポロジ

これまでのActive Directoryの設計方針と同じ。

アプリケーション側のActive Directoryの設計は、これまでの思想と同じなので従来と変わらずに考えていく必要がある。

VPC/ネットワーク関連

アベイラビリティゾーンを 1つの個別データセンターとしてみなし、複数のアベイラビリティゾーンに配置を推奨
オンプレミスとAWSの間のネットワーク間に冗長構成の検討を推奨
セキュリティグループの制御を行う

（必要なポート：https://learn.microsoft.com/ja-jp/archive/blogs/jpntsblog/563 )

オンプレミスに対してAWSから名前解決が必要な場合は、DNSサーバーやフォワーダの設計を行う
FSMO(Flexible Single Master Operation：ドメインコントローラの操作マスタ)は冗長構成をとれないので、「スタンバイ操作マスタ」を用意する

バックアップリストア関連

EC2 の場合、Windows Server上のVolume Shadow Copyサービスを有効化するかActive Directory 互換のバックアップツールを使用する
バックアップデータが保管されているボリュームのスナップショット取得の自動化を行う
ドメインコントローラ全体のスナップショットは取得しない (DB 不整合を起こすため

管理端末関連

インターネットから管理端末の操作が必要な場合、踏み台サーバーやリモートデスクトップ可能な端末を用意する

３．AWS移行後のActive Directoryの運用

運用について、考慮が必要な運用作業は各パターンによって異なる。

考慮が必要な運用作業

	Active Directory サーバー on EC2	AWS Directory Service (Simple AD)	AWS Directory Service (Managed Microsoft AD)
ハードウェアの保守・運用	AWS側で管理	AWS側で管理	AWS側で管理
OSの保守・運用	必要	AWS側で管理	AWS側で管理
Windows Updateの適用	必要	AWS側で管理	AWS側で管理
バックアップ	必要	AWS側で管理	AWS側で管理
ユーザ追加等	必要	必要	必要

Active Directoryサーバー on EC2の場合

OS以上の機能を管理する必要がある

AWS Directory Service (Simple AD、Managed Microsoft AD)の場合

バックアップやWindows Updateといったような管理についてはAWS側で実施

どのサービスを使っても、ユーザ追加やグループポリシーといったようなActive Directoryの機能についてはユーザ自身で実装していく必要がある。

運用の効率化（アウトソース）

Windows Update 等、定常作業は自動化を検討する。

非定常作業だがユーザ追加をしたい、アクセス権を変えたい、グループポリシーをいじりたいなどの保守運用にかかわる作業についてはアウトソースも検討する。

NTT東日本の運用サービスの中でもActive Directoryのユーザ追加や削除を行っています。

また、AWSの設定変更や監視や障害の一時対応と言った様な事も行っています。

こちらも定常作業となってくるので、アウトソースが検討出来るようになっています。

例えばAWSの設定変更ですと、「EC2のスペックを変えたい」「EBSの容量を少し増やしたい」「セキュリティグループの追加の設定をして、セキュリティを高めたい」の他に「拠点が増えたのでVPNを増やしたい」と言うよう事も出来ます。

また、以下のようなケースでもアウトソースが検討できるようになっています。

システムの正常性の監視
AWSの基盤側なのか、それ以上のレイヤなのかを切り分け、もし万が一の場合、一時対応として再起動や停止起動の実施

ADサーバーのクラウド移行をご検討の方、お悩みの方はこちらからお問い合わせください。

４．NTT東日本によるパブリッククラウド関連サービス

NTT東日本では、パブリッククラウドに関連するさまざまなサービスをご提供しております。

AWSのアカウントの提供サービスなら、①アカウント提供
AWSのネットワークならば、②クラウドゲートウェイサービス（閉域接続）

お客さま拠点からAWSに至るまでのネットワークについてのご相談が可能です

今回のセミナーのテーマであるActive Directoryの構築や移行から移行後の運用についての相談なら、④クラウド導入・運用サービス

５．Q＆A

　最後にQ&Aの時間を設けて、参加者からの質問に対し、回答しました。その質問と回答内容を紹介します。

Q1移行までの所要時間について

Answer

移行の方式や、接続されているクライアントの台数に左右されます。
ここではクライアントの設定変更は含まずに回答します。
単純にマスタ昇格や同期であれば、早いものなら数時間。クライアントの台数が多い場合は数日かかります。
また、データを新しく入れての切り替える場合、結局は新しい新規の構築になるため、数週間単位となります。

Q2Amazon EC2でWindows Server 2019を立ち上げたが、English版しか選択肢が無かったためEnglish版で利用している。
この場合、オンプレミスのWindows Server 2012日本語版とのAD同期時に気を付ける点などあったら教えて欲しい。

Answer

Windows Server 2019 Japanese版はコミュニティAMIで提供されています。ami-0e742307f99887019を選択することで利用が可能となります。
Active Directory自体は英語版と日本語版大きく変わることはありませんが、Windows Server 2012とWindows Server 2019などのバージョンの異なるActive Directoryの場合、注意すべき部分は機能レベルなります。
Windows Server 2012で使われている機能レベルをチェックし、それがWindows Server 2019で対応している機能レベルかどうかを確認することが一つポイントになります。
例えば、Windows Server 2012には「元々がWindows Server 2003で使われた機能だった」というケースもあり機能レベルがかなり低いものが中には存在します。
移行先のWindows Server 2019で対応していない場合は、一旦オンプレミスのWindowsのActive Directoryの機能レベルを上げてから対応するようにしましょう。

Q3移行期間を長く取り、オンプレミスとクラウドのADを両方並行運用した場合、どのような連携をオンプレとクラウドで設定しなければならないか。

Answer

どのようなケースを想定されているか不明ですが、一つ考えられるのはそのままEC２に移行されるパターンが多いと思います。
この場合、マスタのどちらかを昇格、降格して１つのドメインにして、データ同期をして頂ければと思います。
また、使われていない時間帯にマスタをオンプレミスとクラウドに切り替えると言う設定する必要があるかと思います。

Q4各拠点にある端末のドメイン参加はAWSのマネージドなADサービスだと出来ないのか？

Answer

Simple ADでは出来ません。
ただ、Managed Microsoft ADを使用している場合は、新しいドメインを作る際に各拠点にある端末をMicrosoft ADへ参加することが可能となっています。

Q5移行についてデータエクスポート・データインポート方式とした場合、SIDは既存ADから変更されてしまうのか？

Answer

その通りです。変更されてしまいます。

Q6ドメインコントローラ自体のスナップショットは取らないようにとあるが、これはEC2のスナップショットのことか？

Answer

その通りです。EC2のスナップショットのことです。
工夫点として、ユーザデータが入っているボリュームとOSやActive Directoryのボリューム（EBS）を分けるのが良いと思います。

Q7オンプレミスではドメインコントローラは複数台推奨だが、AWSも複数台構成は可能か？

Answer

AWSでも複数台の構成は推奨となっております。
AWSでは更に複数のドメインコントローラを別々のアベイラビリティゾーンに分けて頂くことを推奨しています。
これを行うことで複数のデータセンターで冗長しているのと同じような効果が得られます。

Q8AWS環境のみでのActive Directoryサーバー利用の場合、クライアントPCからインターネットに接続不能となった場合は具体的にどのような不具合が発生するか？
また、逆に不具合が発生しない部分はどこか？

Answer

インターネットに接続不能の場合は、既存のネットワークのWANの不調と同じく、ドメインに参加できないので、ローカルユーザでしかログインが出来ない状況になります。
不具合が発生しない部分は難しいところでありますが、クライアントPCに不具合が無いという事であれば、クライアントPCのローカルユーザであれば、そのまま使えるという回答となります。

Q9AWS上のActive DirectoryではRadius認証は可能か？

Answer

AWSのActive Directoryで例えば、EC2上であれば、Radiusサーバーを立てる事は可能です。
また、Managed Microsoft ADでもRadiusは利用可能となっています。