はじめに

現職で、ADのReplace案件の一環で、ADのDC昇格作業を担当することになりました。
それにあたって、自社環境で検証することになりましたので、その検証のポイントをまとめます。
※今回は既存のドメインに新しいADサーバを立てて、その後その新ADサーバをDCに昇格。という手順ではなく、ゼロから構築しています。

環境

AWS上でEC2を三台立てて実施
OS:Windows Server2019
Active Directry:Windows Server2016

作業概要

事前準備

Windows erver2019がインストールされたEC2インスタンスを三台構築する。
それぞれホスト名を

・ExistingAD
・NewAD
・Member

とし、それぞれ以下を実施
・ADサーバー：ADをインストール
・メンバーサーバ：ドメイン参加

バックアップ

Existing/NewADサーバのバックアップをWindows Server Backupで実施

NewADサーバのDC昇格

サーバマネージャ上から、NewADサーバをDCに昇格

動作確認

前提知識

ADとは

Active Directory（AD）はWindows Serverに備わっている機能で、システム管理者がユーザーや共通リソースをまとめて管理することができるシステムです。
こいつがあると、認証やポリシーを一括管理できるので、非常に便利です。

AD認証の仕組み

AD認証の仕組みを理解するにあたって、WORKGROUP環境とドメイン環境の違いを理解する必要があります。
・WORKGROUP環境
→リソースや認証が各サーバで管理される方法です。低コストかつ容易ですが、組織内のサーバの数が多くなると管理工数が莫大になるというデメリットがあります。
例えば、パスワードポリシーの変更などが必要になった場合、すべてのサーバでそれぞれ対応する必要があります。（AWSリソースであるなら、いろいろやり方はありそうですが）

・ドメイン環境
→ユーザーやコンピューターをドメインに参加させることにより、リソースを一元管理する方法です。
こちらは、ドメインコントローラーという専用のサーバが必要になります。

WORKGROUP環境のユーザーをローカルユーザと呼び、ドメイン環境のユーザーをドメインユーザと呼びます。
このドメインユーザは、ドメインに参加しているどのコンピューターにログインが可能になります。
ドメインユーザの表記は以下のようになります。

{NetBIOS名}¥{ユーザー名}
{ドメイン名}¥{ユーザー名}  or  {ユーザー名}@{ドメイン名}

例えば、exampleというドメインに参加しているドメインユーザの名前は
example¥user
user@example

のような表記になります。

認証にはkerberosというプロトコルが使用されます。
LDAPとkerberosの違いがややこしいですが、
kerberos→認証のためのプロトコル
LDAP→LDAPサーバ(今回はDC）にアクセスするためのプロトコル

となります（たぶん）
①PC起動あと、SRVレコードで使用したいサービスの提供先を調べる
➁kerberos認証で、認証と認可プロセスを踏む
→
・KDC(Key distribution center)のAS(Authentication service)に認証をお願い
・TGT(Ticket Granting Ticket)をASに払い出してもらう
・KDCのTGS(Ticket Granted Service）という機能にサービスチケットの払い出しを要求
・TGSがサービスチケットを払い出す

③サービスチケットと、必要なプロトコル（ファイルサーバだったらSMB、LDAPサーバだったら、LDAP）で使用したいサービスにアクセス

みたいな流れになります。
※AS→認証＋認可（本人確認をし、TGTを発行）
TGS→認可（サービスチケットを発行）
となります。（これも自信ない）

グローバルカタログとは

グローバルカタログとは、フォレスト内で使用される頻度の高い情報を格納しているドメインコントローラをさします。
よほどのことがない限りは、ADインストール時にこのグローバルカタログも一緒にインストールすることをお勧めします。

window server backupとは

Windows Server バックアップは Windows Server OS に標準搭載されているバックアップ機能であり、以下のバックアップが実行可能です。

・ベアメタルバックアップ
・システム状態のバックアップ
・ボリューム単位でのバックアップ
・ファイル単位でのバックアップ
・仮想マシンのバックアップ (Hyper-V ホストの場合)
ちなみに、ベアメタルとは

ベアメタルバックアップとは

データのみのバックアップと異なり、丸ごと(OS,システム,データ)バックアップをする方法です。

役割と機能のインストールについて

こちらは補足情報です。

作業詳細

事前準備

まずは、AWSコンソール上から以下のEC2を構築していきます。
・ExistingAD
・NewAD
・Member

そのあとExistingADとNewADにそれぞれActive Directoryをインストールしていきます。
GUIからでもインストールは可能なのですが、今回は以下のサイトを参考にコマンドにて実施しました。

そのあとExsitingADをDCに昇格させます。
※本来すでに存在しているADを用いて本検証を実施できればよかったのですが、今回は一から作成することにしました。

参考のリンクはこちらです。
今回はpractice.system.comというドメインにしてあります。

続いて、以下のリンクに従ってMemberサーバ、NewADサーバをドメイン参加させます。

はい、これで準備が整いました。
ちなみに、この時点でNewADのローカルユーザでは、NewADサーバにログインできなくなっているので注意です。
一応以下のコマンドでMemberサーバにドメインユーザーでログイン後、ExistingADサーバが問題なく見えているか確認もします。

   nltest /dsgetdc:practice.system.com
　 nltest /dclist:practice.system.com

以下のリンクにドメインコントローラ診断系のコマンドがまとまっています

NewADサーバのDC昇格

以下リンクに従って、NewADをDCに昇格させます。
本昇格の手順は、以下のPowershellスクリプトでも実施可能です。

# AD DS 配置用の Windows PowerShell スクリプト 
#
Import-Module ADDSDeploymentInstall-ADDSForest `
-CreateDnsDelegation:$false `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "Win2016" `
-DomainName "contoso.com" `
-DomainNetbiosName "CONTOSO" `
-ForestMode "Win2016" `
-InstallDns:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SysvolPath "C:\Windows\SYSVOL" `
-Force:$true

コマンドで動作確認

こちらの以下リンクに従って、動作確認を実行します。

SYSVOLとNETLOGONについて馴染みがなかったので、少し調べてみました。
イメージができたわけではないですが、とりあえずこれらフォルダがレプリケーションされていなければいけなんだな。と理解することにしました。