ADの昇格についてまとめてみた

## はじめに
現職で、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に備わっている機能で、システム管理者がユーザーや共通リソースをまとめて管理することができるシステムです。
こいつがあると、認証やポリシーを一括管理できるので、非常に便利です。

https://www.sbbit.jp/article/cont1/37798

#### 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→認可（サービスチケットを発行）
となります。（これも自信ない）

https://milestone-of-se.nesuke.com/sv-advanced/activedirectory/kerberos-spnego/

https://milestone-of-se.nesuke.com/sv-advanced/activedirectory/domain-and-local-users/

https://www.infraexpert.com/study/security18.html

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

https://bizlog.tech/ad-globalcatalog-check/

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

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

https://jpwinsup.github.io/blog/2022/03/22/Storage/Backup/Windows-Server-Backup-Overview/

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

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

https://wa3.i-3-i.info/word18070.html

https://insights-jp.arcserve.com/bare-metal-recovery#:~:text=%E3%83%99%E3%82%A2%E3%83%A1%E3%82%BF%E3%83%AB%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97(%E3%83%99%E3%82%A2%E3%83%A1%E3%82%BF%E3%83%AB%E5%9B%9E%E5%BE%A9%E3%81%AE,%E7%8A%B6%E6%85%8B%E3%82%92%E7%A2%BA%E4%BF%9D%E3%81%97%E3%81%BE%E3%81%99%E3%80%82

#### 役割と機能のインストールについて
こちらは補足情報です。

https://dev.classmethod.jp/articles/some-ways-to-install-windows-roles-and-features/

https://soma-engineering.com/coding/powershell/export-windowsfeature-csv/2018/07/17/


## 作業詳細
#### 事前準備
まずは、AWSコンソール上から以下のEC2を構築していきます。
・ExistingAD
・NewAD
・Member

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

https://www.server-world.info/query?os=Windows_Server_2019&p=active_directory&f=1

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

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

https://www.rem-system.com/win2019-adsetup/

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

https://win2012r2.com/2020/04/05/active-directory-%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%99%E3%82%8B/

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

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

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

https://bizlog.tech/ad-dcdiag-command/

#### 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

https://bizlog.tech/ad-dcpromo-manual/

#### コマンドで動作確認

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

https://social.technet.microsoft.com/Forums/ja-JP/d995fdc0-0036-48f0-9adf-302c2104886e/1248912513124521253112467125311248812525125401252165288dc65289?forum=Wcsupportja

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

https://kb.synology.com/ja-jp/DSM/tutorial/Why_are_there_sysvol_netlogn_folders