- 公開日
- 最終更新日
【比較編】AWSでActive Directoryを学ぶ
この記事を共有する
目次
パーソル＆サーバーワークスの髙井です。
AWS を中心としたクラウドインフラの設計・構築・運用を担当しています。
はじめに
Active Directory Domain Services（以下、AD DS）は、Windows 環境でユーザーや端末を一元管理する仕組みです。
本ブログは AD DS シリーズの3本目、最終回です。
入門編・運用編では、EC2 上に自分で AD を建てて運用する「自己管理 AD」を扱いました。
本ブログでは、AWS がマネージドで提供する AWS Managed Microsoft AD に置き換えると、何が同じで何が変わるのかを比較します。
本シリーズは下記の3部構成です。
- 入門編：AD の基礎と、EC2 上へのドメインコントローラー構築
- 運用編：OU 設計、グループ設計（AGDLP）、ユーザー作成、メンバーサーバーのドメイン参加、GPO 適用
- 比較編（本ブログ）：同じ環境を AWS Managed Microsoft AD に置き換えたときの違い
AD の基礎用語（DC、OU、GPO、FSMO、Kerberos、AGDLP など）は入門編・運用編で解説済みのため、本ブログでは説明済みとして進めます。
想定読者
- 自己管理 AD の構築・運用を一通り理解していて、マネージドサービスへの移行を検討している方
AWS Managed Microsoft AD とは
AWS Managed Microsoft AD は、AWS が運用を肩代わりしてくれる本物の Active Directory です。
実体は Windows Server ベースの AD で、AWS が管理アカウント側で DC を動かします。
利用者は AD の中身（ユーザー・グループ・OU・GPO）を運用しますが、DC の OS には触れません。
一言でいうと、AD の運用のうち面倒な部分（DC の冗長化・パッチ・バックアップ）を AWS に任せ、日常の運用だけ自分でやるサービスです。
違い1：DC がどこにあるか
これが最大の構造的な違いです。
- 自己管理 AD：DC は自分のアカウントの EC2 として動く。RDP でログオンでき、OS も自由に触れる
- Managed AD：DC は AWS の管理アカウントで動く。自分の VPC 内に見えるのは ENI だけ
まず、ディレクトリ自体はマネジメントコンソールの Directory Service 画面で確認できます。
作成すると、2台の DC が異なる AZ に自動配置され、冗長構成が最初から出来上がっています。
自己管理 AD では冗長化のために自分で2台目を昇格させる必要がありましたが、その手間がありません。
一方で、この DC は EC2 インスタンス一覧には出てきません。
入門編では DC が自分の EC2 として見えて RDP でログオンできましたが、Managed AD ではそもそも自分のアカウントに DC のインスタンスが存在しないのです。
この構造の結果として、DC への RDP ログオン・エージェント導入・OS 設定変更は一切できません。
入門編で DC に RDP ログオンして操作したことは、Managed AD ではできないということです。
参考: What gets created with your AWS Managed Microsoft AD
違い2：権限がどこまで及ぶか
自己管理 AD では、Administrator が「Domain Admins」や「Schema Admins」に所属し、ドメイン全体を何でも操作できました。
Managed AD では、利用者は 「OU=
「Domain Admins」などの特権グループには入れません（AWS が排他管理します）。
| 操作 | 自己管理 AD | Managed AD |
|---|---|---|
| 自分の OU 配下の OU・ユーザー・グループ管理 | 可 | 可 |
| GPO の作成・リンク | 可 | 可 |
| DNS レコードの管理 | 可 | 可 |
| ドメイン直下へのオブジェクト作成 | 可 | 不可 |
| Domain Admins への所属 | 可 | 不可 |
| スキーマの直接変更 | 可 | 不可（API 経由で拡張） |
| Default Domain Policy の編集 | 可 | 不可（FGPP で代替） |
重要なのは、運用編で実施した日常の運用（OU・グループ・ユーザー・GPO）はそのまま持ち込めるという点です。
作成先のパスを「OU=
「できないこと」は、ドメイン全体に影響する強い操作や、DC そのものに関わる操作に限られます。
補足：できない操作には代替手段がある
直接できない操作の多くは、AWS が用意した別の方法で実現します。
スキーマ拡張は LDIF ファイルの API インポート、パスワードポリシー変更は事前作成された細かいパスワードポリシー（FGPP）、セキュリティログの監査は CloudWatch Logs への転送、といった具合です。
移行を検討する際は、使っている機能にこうした代替手段があるかを確認しておくと見積もり精度が上がります。
参考: AWS Managed Microsoft AD Administrator account and group permissions
違い3：ドメイン参加がパスワード不要になる
自己管理 AD では、運用編で見たとおりメンバーサーバーの参加にドメイン管理者のパスワードを渡していました。
Managed AD では、Systems Manager 経由でパスワードを一切渡さずに参加できます（シームレスドメイン参加）。
インスタンスに付けた IAM ロールの権限で SSM Agent がコンピューターアカウントを作成するためです。
資格情報をインスタンスに置かなくて済むので、セキュリティ面でも有利です。
今回は運用編で使ったメンバーサーバーを、自己管理 AD（corp.ad-practice.local）から Managed AD（aws.ad-practice.local）に参加し直しました。
SSM 経由で実行すると、現ドメインからの離脱と新ドメインへの参加がまとめて行われ、再起動後にはシステムのプロパティ上の所属ドメインが aws.ad-practice.local に変わります。
ドメイン管理者のパスワードを一度も入力することなく、別のドメインへ参加できた点がポイントです。
参考: Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD
どちらを選ぶべきか
運用責任の分担が、選択の決め手になります。
| 作業 | 自己管理 AD | Managed AD |
|---|---|---|
| OS パッチ適用 | 利用者 | AWS |
| バックアップ | 利用者 | AWS（日次自動） |
| DC 障害時の復旧 | 利用者 | AWS（自動置換） |
| マルチ AZ 冗長化 | 利用者（DC 追加） | AWS（既定で2台） |
| ユーザー・グループ・GPO 運用 | 利用者 | 利用者 |
DC を冗長化し、パッチとバックアップを自分で運用するコストを見積もると、多くのケースで Managed AD の方が総コストで有利になります。
一方、下記のような要件があると自己管理 AD しか選べません。
- Domain Admins 相当の権限が必須のアプリを動かす
- DC にサードパーティー製のエージェントを入れたい
- 特定バージョンの Windows Server が必要（Managed AD は固定）
まとめ
本ブログの要点は下記のとおりです。
- Managed AD の DC は AWS 管理アカウントで動くため、RDP ログオンや OS 操作はできません。その代わり冗長化・パッチ・バックアップを AWS が担います
- 利用者の作業範囲は自分専用の OU 配下に限られ、Domain Admins などの特権は AWS が排他管理します
- 日常の AD 運用（OU・グループ・ユーザー・GPO）は自己管理 AD とほぼ同じ操作で持ち込めます
- 直接できない操作（スキーマ拡張・パスワードポリシー・監査ログ）には、API やマネージド機能による代替手段が用意されています
- 選択の決め手は運用責任の分担で、特権や OS 操作が不要なら Managed AD が有利なケースが多いです
3回にわたって、AD の基礎から自己管理での構築・運用、そしてマネージドサービスとの比較まで見てきました。
「自分で全部持つ」と「AWS に預ける」の境界を理解すると、移行の設計判断がしやすくなります。
最後までお読みいただきありがとうございました。
参照ドキュメント
- AWS Managed Microsoft AD
- What gets created with your AWS Managed Microsoft AD
- AWS Managed Microsoft AD Administrator account and group permissions
- AWS Managed Microsoft AD best practices
- Joining an Amazon EC2 Windows instance to your AWS Managed Microsoft AD
この記事は私が書きました
髙井 大暉
記事一覧頑張ってインフラエンジニアやってます。
