- 公開日
- 最終更新日
【入門編】AWSでActive Directoryを学ぶ
この記事を共有する
目次
パーソル＆サーバーワークスの髙井です。
AWS を中心としたクラウドインフラの設計・構築・運用を担当しています。
はじめに
Active Directory Domain Services（以下、AD DS）は、Windows 環境でユーザーや端末を一元管理する仕組みです。
オンプレミスからのクラウド移行案件では必ずと言っていいほど登場しますが、名前は知っていても「中で何が動いているのか」までは説明しづらいサービスでもあります。
本ブログでは、AD DS の基本用語をできるだけ端的に整理したうえで、EC2 上に実際に AD を構築して動かしてみます。
深い自動化の作り込みには踏み込まず、「AD とは何か」を理解し、AWS 上で構築するときに気をつけるポイントを押さえることをゴールにしています。
本シリーズは下記の3部構成を予定しています。
- 入門編（本ブログ）：AD の基礎と、EC2 上へのドメインコントローラー構築
- 運用編：OU 設計、グループ設計（AGDLP）、ユーザー作成、メンバーサーバーのドメイン参加、GPO 適用
- 比較編：同じ環境を AWS Managed Microsoft AD に置き換えたときの違い
想定読者
- AWS の基本的なサービス（VPC、EC2 など）を触ったことがあり、Active Directory はこれから学ぶという方
そもそも Active Directory とは
AD DS を一言でいうと、「誰が」「どの端末で」「何をできるか」をまとめて管理する仕組みです。
社内の全ユーザーとパソコンを1か所で管理し、1つの ID でログオンできるようにするためのものと考えると分かりやすいです。
まずは登場する用語を整理します。ここを押さえておくと、構築後の画面が読めるようになります。
押さえておきたい基本用語
| 用語 | 意味 |
|---|---|
| ドメイン | ユーザーや端末をまとめる管理の単位。「corp.example.local」のような名前を持つ |
| ドメインコントローラー（以下、DC） | ドメインの本体となるサーバー。認証を処理し、アカウント情報を保持する |
| OU（Organizational Unit） | ユーザーや端末を整理する入れ物。後述する GPO を適用できる |
| オブジェクト | ユーザー、グループ、コンピューターなど、AD で管理する実体 |
| GPO（グループポリシー） | ユーザーや端末に設定を強制する仕組み。パスワードポリシーや画面ロックなど |
AD は DNS の上で動く
AD を理解するうえで外せないのが、AD が DNS に強く依存しているという点です。
クライアントは「このドメインの DC はどこにいるのか」を DNS に問い合わせて探します。このとき使われるのが SRV レコードです。
SRV レコードは「LDAP や Kerberos といったサービスが、どのサーバーのどのポートで動いているか」を教える DNS レコードで、AD はこれを使って DC を自動的に発見させています。
そのため、DNS がおかしいと AD もログオンできなくなります。
AD のトラブルの多くが DNS 起因なのはこのためです。
今回構築する構成
今回の入門編で扱うのは、下記のドメインコントローラーを1台建てるところまでです。
メンバーサーバーのドメイン参加は運用編で扱います。
使用リソース一覧
| リソース | 用途 |
|---|---|
| VPC | ネットワークの分離 |
| Private Subnet | ドメインコントローラーの配置。 |
| EC2（t3.medium） | ドメインコントローラー |
| EC2 Instance Connect Endpoint | 踏み台サーバーなしでの RDP 接続 |
| VPC エンドポイント | インターネットを経由しない AWS API アクセス |
Internet Gateway も NAT Gateway も持たない、閉じたネットワークにしています。
DC はインターネットに露出させたくないケースが実案件でも多いためです。
AWS API へのアクセスはすべて VPC エンドポイント経由になります。
セキュリティグループで許可するもの
今回の入門編（DC の構築と接続）で必要になる通信は、下記のとおりです。
DC 用のセキュリティグループに設定します。
| 対象 | プロトコル / ポート | 用途 |
|---|---|---|
| DC（インバウンド） | TCP 3389 | EC2 Instance Connect Endpoint 経由の RDP 接続 |
| DC（インバウンド） | TCP / UDP 53 | DNS の名前解決 |
| VPC エンドポイント（インバウンド） | TCP 443 | VPC 内から AWS API への HTTPS アクセス |
| DC（アウトバウンド） | すべて | VPC エンドポイントへの到達、AD DS が使う動的ポート |
RDP のインバウンドは、送信元を接続元（EC2 Instance Connect Endpoint のセキュリティグループ）に絞ると安全です。
メンバーサーバーの参加や認証に必要な LDAP・Kerberos・SMB などのポートは、運用編で扱います。
AWS 上に AD を構築する
EC2 に Windows Server を立て、AD DS の役割をインストールしてフォレストを作成すると DC になります。
構築方法には、PowerShell コマンドで進めるやり方と、GUI（サーバーマネージャー）で進めるやり方の2通りがあります。
コマンドで構築する場合
自動化やスクリプト化を前提とするなら、下記のように PowerShell で完結します。
AD DS と DNS の役割をインストールします。
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Install-WindowsFeature -Name DNS -IncludeManagementTools
フォレストを作成して DC に昇格します。
Install-ADDSForest `
-DomainName 'corp.ad-practice.local' `
-DomainNetbiosName 'CORP' `
-InstallDns:$true `
-Force:$true
昇格が完了すると再起動が入り、再起動後には DC として動きはじめます。
GUI で構築する場合（今回はこちら）
今回は、それぞれの操作が何をしているのかを見ながら進めたいので、GUI（サーバーマネージャー）で構築します。
※ DC 用の EC2 に RDP で接続して作業を実施しました。
1. 役割をインストールする
サーバーマネージャーの「役割と機能の追加」から、Active Directory ドメイン サービスを選んでインストールします。
これが先ほどのコマンドの「Install-WindowsFeature」に相当します。
この時点ではまだ部品が入っただけで、DC にはなっていません。
2. DC に昇格する
インストール後、サーバーマネージャー上部の通知（旗マーク）から「このサーバーをドメイン コントローラーに昇格する」を選び、昇格ウィザードを進めます。
ここが「Install-ADDSForest」に相当します。
- 「新しいフォレストを追加する」を選択し、ルートドメイン名に「corp.ad-practice.local」を入力
- 機能レベルと DNS サーバーの設定を確認（DNS も一緒にインストールされます）
- ディレクトリ復元モード（DSRM）のパスワードを設定
コマンドでは1行に隠れていた「フォレストを新規作成する」「DNS を同居させる」「DSRM パスワードを決める」といった設定が、GUI では1つずつ確認しながら選べます。
3. 昇格が完了すると自動で再起動する
前提条件のチェックが通ると昇格が実行され、自動的に再起動します。
再起動後、このサーバーは DC として動きはじめます。
メンバーサーバー側は、この DC を DNS の参照先に設定したうえでドメインに参加させます。
流れ自体はシンプルですが、AWS 上でやるといくつか引っかかりやすいポイントがあります。
AWS で構築するときの注意点
手動で構築する場合に押さえておきたい注意点は、下記の3点です。
| 注意点 | 内容 |
|---|---|
| 昇格で再起動が入る | AD DS の昇格処理は必ず再起動を伴う。手動なら再起動後に自動で処理が続くため問題ない |
| DNS 参照先を自分自身に向ける | DC は自分が DNS サーバーを兼ねる。昇格前にループバック（127.0.0.1）へ向ける。GUI ウィザードで DNS を同時導入する場合は自動設定される |
| DC のスペックをケチらない | AD DS はアカウント情報をメモリーにキャッシュするため、t3.medium（4 GB）程度を下限にすると安定する |
構築した AD を確認する
構築できたら、AD が正しく動いているかを確認しておくと安心です。
下記は必須の作業ではありませんが、気になる場合に確認できるコマンドとして紹介します。
DC として稼働しているかを見たいときは、下記で確認できます。
ドメイン名やホスト名が期待どおりに表示されれば稼働しています。
Get-ADDomainController | Format-List Name, Domain, Forest, IPv4Address, IsGlobalCatalog
DNS の SRV レコードが引けるかを見たいときは、下記で確認できます。
DC のホスト名とポート（LDAP は 389）が返ってくれば、クライアントが DC を発見できる状態です。
Resolve-DnsName -Name '_ldap._tcp.dc._msdcs.corp.ad-practice.local' -Type SRV
ドメイン直下の構造を見たいときは、下記で確認できます。
Get-ADObject -SearchBase (Get-ADDomain).DistinguishedName -SearchScope OneLevel -Filter * | Select-Object Name, ObjectClass
ここで1つ、実務で重要な点があります。
新規ドメインには「Users」と「Computers」という入れ物が最初から用意されていますが、これらは OU ではなく container で、GPO をリンクできません。
そのため実運用では、自前で OU を作り、そこにユーザーや端末を移動して GPO を適用します。「なぜわざわざ OU を作るのか」の答えがここにあります。
まとめ
手を動かして AD を1つ建ててみると、用語と実物がつながって理解が一気に進みました。
次回の運用編では、今回構築した DC に対して OU を設計し、AGDLP に沿ったグループ設計とユーザー作成、メンバーサーバーのドメイン参加、GPO の適用までを実際の画面で進めます。
参照ドキュメント
- Connect to your instances using EC2 Instance Connect Endpoint
- Prerequisites for creating an AWS Managed Microsoft AD
- Microsoft: How to configure a firewall for Active Directory domains and trusts
この記事は私が書きました
髙井 大暉
記事一覧頑張ってインフラエンジニアやってます。
