Active Directory のクラウド移行｜Microsoft Azure を使った具体的な操作手順を詳しく解説

業務では様々なシステムが使われるため、企業では多くのサーバーが運用されています。それらのサーバーがサポート切れになるタイミングではリプレイスが必要になりますが、最近ではオンプレミスを脱却してクラウド化が選択されることも多くなっています。

中でも、Active Directory（以下、ADと記載します）はBCPの観点からもクラウド化されることが多いため、今回は、ADを Microsoft Azure に移行する手順を分かりやすくご紹介したいと思います。

以下の手順に従って、実際の操作画面をお見せしながらご説明します。

1. VM作成
2. VPN（ExpressRoute）設定
3. ADインストール
4. ドメインコントローラー（DC）昇格
5. FSMO転送
6. DNSの変更
7. DNS委任レコードの移行
8. オンプレミスのDC降格

ADそのものがどういうものなのかは、こちらのコラムで紹介しておりますので基本をおさらいしたい方はぜひご覧ください。

サーバーの構築といえばオンプレミスと考える方も多いと思いますが、昨今ではクラウド上で構築する企業も増えてきています。ADは重要なサーバーのため2台構成が一般的ですが、そのうちどちらかもしくは両方をクラウドへ移行することは、BCPの観点からも有効です。

オンプレミスにあるAD1号機・2号機ともにクラウドへ移行する構成です。

社内にドメイン参加しているサーバーがない場合にオススメの構成ですが、2台ともクラウドに構築するためネットワークの品質が重要となります。

クライアントPCはキャッシュ機能もあるため問題ありませんが、社内にサーバーが多数ある場合はAD1号機はオンプレミスに残した方がよいでしょう。

AD2号機のみをクラウド化します。

これにより、通常のハードウェアの運用・保守のコストを抑えつつもBCP対策が可能です。例えば、本社東京にあるAD1号機、2号機をクラウドの西日本リージョンに構築します。これによって東京本社の災害によりAD1号機が稼働しなくなっても、西日本リージョンにあるAD2号機をマスターとして稼働させることができます。

こちらの構成はBCP観点からも初めてクラウド化を検討する方におススメです。

ここからは実際にADを Azure に移行する際の流れと手順を説明していきます。

お客様の中にはADの移行作業について苦手意識を持たれてる方も少なくなく、1号機2号機とも移行する手順を掘り下げて、できるだけ丁寧に説明していきたいと思います。

※お客様環境によって詳細な手順が異なる場合があるため、あくまでも参考として捉えてください。

Azure 上でVnet（仮想ネットワーク）の構築と仮想サーバーとなるVM（OS：Windows Server）を作成していきます。

VPNゲートウェイとローカルゲートウェイと呼ばれるリソースで、Azure のネットワーク情報とオンプレミスのネットワーク情報を設定します。ここではオンプレミスサーバーでも設定が必要です。

※ExpressRouteの場合はキャリアやベンダーとのやり取りが必要です。

ここからがAD移行作業に関する手順です。

まずは Azure 上に構築したVMに接続して、ADをインストールします。

サーバーマネージャーを開き、[ 管理 > 役割と機能の追加 ] をクリックします。

機能の追加ウィザードを進めます。

[ 役割ベースまたは機能ベースのインストール ] を選択し、次へ進みます。

サーバーを確認してこのまま次に進みます。

次に以下の２つの役割をインストールします。

• Active Directory ドメインサービス（ADDS）
• DNSサーバー

ADDSはインターネット上のオブジェクトに関する情報を格納します。DNSサーバーとADDSが連携して動作するようになります。

各種確認が表示されますが、[ 機能の追加 ] を選択します。

DNSインストール時には、[ 静的IPではない ] 警告が表示されますが、この点は続行してOKです。

※Azure はDHCP側で固定IP扱いとなることが理由です。

[ 次へ ] を選択し、ウィザードを進めます。

[ 機能の選択 ] についてはこのまま進めます。

ADDSの Entra ID（旧称：Azure AD）連携については、今回は設定しないため無視します。

注意事項を確認して、[次へ ] を選択します。

インストールを実施します。

完了を確認します。

ADをインストールするだけでは機能しませんので設定を続けていきます。どのドメインでサーバーをドメインコントローラーにするかを設定します。

ドメイン昇格する際、既存ドメインコントローラーからの情報を同期するので、Azure 上に作成したサーバーのDNSを一時的に既存ドメインコントローラーに向けます。

Azure コンソールから①で作成したVMを選択し、[ ネットワーク設定 > ネットワークインターフェース/IP構成 > DNSサーバー ] をクリックします。

カスタムを選択して、既存ドメインコントローラーのIPアドレスを入力して保存します。

設定後、OSを再起動してください。

続いて、OS内部の設定を行います。サーバーマネージャーからフラグマークを選択し、[ このサーバーをドメインコントローラーに昇格する ] をクリックします。

[ 既存のドメインにドメインコントローラーを追加する ] を選択します。ドメインを入力して、資格情報の [ 変更 ] をクリックします。

資格情報としてローカルコンピューターの Administrators グループに所属するユーザーを使用します。

ディレクトリサービス復元モードのパスワードを入力します。

DNSオプションを確認して次に進みます。

レプリケーションオプションも確認して、次へ進みます。

保存先を確認します。

オプションも確認します。

以上で設定が完了します。

インストール時に、再起動が行われます。

再起動が完了した後、ドメインコントローラーに昇格されていることを確認します。

コマンドプロンプトで確認を行います。

> dsquery server -forest

このコマンドで2台の既存ドメインコントローラーと今回新しく作成したドメインコントローラーが追加されていることを確認できます。

> repadmin /showrepl

このコマンドで Active Directory データベースの複製に問題ないことを確認します。

> netdom /query fsmo

このコマンドで現在FSMOは既存ドメインコントローラーにあることを確認します。

ドメインコントローラー2号機を作成する際はここまでの手順で完了です。

FSMOとはドメインもしくはフォレスト内の特定の1台だけに割り当てられる特別な5つの役割のことです。操作マスターとも呼ばれます。

このFSMOをオンプレミスのADからクラウドのADに転送します。

管理者権限にて PowerShell を起動し、次のコマンドを実行します。

※ホスト名はご自身のものに変更してください。

> Move-ADDirectoryServerOperationMasterRole -Identity "[ホスト名]" -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster

PDC エミュレーター、RID マス ター、インフラストラクチャーマスター、スキーママスター、ドメイン名前付け操作マスターを移動するか確認 のメッセージが表示されます。それぞれに対して「y」を入力し、Enter キーを押します。 移動に成功するとエラーなどは表示されずに終了します。

> Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster | fl

このコマンドでPDC エミュレーター、RIDマスター、インフラストラクチャーマスターが移行先のADに変更されたことを 確認します。

> Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster | fl

このコマンドでスキーママスター、ドメイン名前付け 操作マスターが移行先のADに変更されたことを確認します。

ここで Azure 上に作成したVMのDNS設定を既存ドメインコントローラーに向けていたものから自分自身に向けます。ループバックアドレス（『127.0.0.1』IPv4の場合）を設定します。既存ドメインコントローラーに向けていたIPアドレスは削除して大丈夫です。

この時既存ドメインコントローラーのDNS設定で新規ドメインコントローラーのIPアドレスに変更します。

ADサーバーをDNSとして利用している企業も多いですが、このタイミングでオンプレミスADに向いている状態から Azure 側ADに向けなおす必要があります。忘れずに行ってください。

[ サーバーマネージャー ] を起動します。[ ツール > DNS ] をクリックします。

[ DNSマネージャー ] が表示されます。[ 前方参照ゾーン > ドメイン名 ] の [ _msdcs ]を開きます。[ _msdcs ] を右クリックし、プロパティをクリックします。

ネームサーバーで既存ドメインコントローラーを選択して [ 削除 ] をクリックします。既存のドメインコントローラーが複数登録されている場合は全て削除します。

[ 追加 ] をクリックします。

[ 新規ネームサーバーレコード ] が表示されます。[ サーバーの完全修飾ドメイン名（FQDN）] に新規サーバーのFQDNを入力し、[ 解決 ] をクリックします。

[ OK ] をクリックし、完了します。

※2号機がある場合は、同じ手順にて登録を行います。

[ DNSマネージャー ] に戻り、名前が [（親フォルダーと同じ）]、種類が [ Name Server（NS）] のレコードとしてDCが登録されたことを確認します。

オンプレミスに存在しているADの機能を削除します。

• Active Directory のFSMO機能が Azure 上に作成したVMに移動が完了している
• クライアント側のDNS設定について、降格予定のサーバーIPが削除されている

降格予定のADサーバーにログインを行ってください。

サーバーマネージャーを開き、[ 役割と機能の削除 ] を選択します。

続いて、[ Active Directory ドメインサービス ] を削除します。

ADサーバーの降格が必要となるメッセージが表示されるため、続いて降格に入ります。

降格ウィザードが開始されます。このまま [ 次へ ] を選択します。

以下ホスト情報について [ 削除の続行 ] を選択し、[ 次へ ] を選択します。

任意の新たな Administrator パスワード（ローカルユーザーの Administrator）を設定します。

オプションを確認し、降格を実行します。

再起動を実施します。

再度RDP接続し、ログインができることを確認してください。

以上でADの Azure 移行作業は完了です。イメージは掴んでいただけましたでしょうか。

最後に少しだけ注意点に触れて終わりにしたいと思います。

Windows Server のOSがあるように、ADにも機能レベルと呼ばれるものがあります。機能レベルによって Active Directory ドメインサービスのドメインまたはフォレストで使用できる機能が決まったり、ドメインまたはフォレスト内のドメインコントローラーで実行できる Windows Server のOSが決まります。

※ただし、機能レベルによってドメインやフォレストに参加しているワークステーションやメンバーサーバーで実行できるOSが影響を受けることはありません。

特に機能レベルが 2003 の場合は Windows Server 2019/2022 は利用できないため注意が必要です。

また、機能レベルにはドメイン機能レベルとフォレスト機能レベルの2種類あります。ドメインおよびフォレストの機能レベルを、その環境でサポートできる最高値に設定することで可能な限り多くのADDS機能を使用できます。この2つは別のレベルにすることが可能ですが、ドメイン機能レベルがフォレスト機能レベルを下回ることはできませんので注意が必要です。

◯：ドメインの機能レベル　＞　フォレストの機能レベル

✕：ドメインの機能レベル　＜　フォレストの機能レベル

レプリケーション方式にはFRSとDFSRの2つの方式があります。

Windows Server 2008 以上のドメイン機能レベルでは、DFSR を使用して、ドメインコントローラー間で SYSVOL フォルダーの内容をレプリケートします。

ただし、ドメインの機能レベルが Windows Sever 2003 の場合は FRS 方式のみ、Windows Server 2016 の場合は DFSR のみのサポートのため注意が必要です。

ADを移行する際、移行元と移行先のレプリケーション方式を合わせる必要があるため、例えば Windows Server 2003 のドメイン機能レベルから Windows Server 2008 以上のドメイン機能レベルのサーバーに移行する場合は事前に既存のレプリケーション方式も FRS から DFSR に変更する必要があります。

DHCPはIPを振り分ける重要なサーバーです。クラウドにあげることはできますが、ADの機能に問題が発生しOSの再インストールが必要になったときには、DHCPの機能まで不必要に巻き込まれてしまう可能性がありますのでオススメはしません。

基本的には、オンプレミス側でDCHPサーバーを構築したり、ルーターの機能で動かすことのほうが多いです。

ADの障害で再昇格が必要となる場合、ADCSを一度アンインストールする必要があります。

今回は2つ上げましたが、基本的に複数の機能を同じサーバーに統合してしまうと、障害が起きたとき別の機能も同時に破損してしまう可能性があります。また原因の切り分けが難しくなる可能性があり復旧に時間が掛かってしまうので機能ごとにサーバーを立てることが望ましいです。

以上で本コラムは終了となります。参考になりましたでしょうか。