- 公開日
- 最終更新日
【運用編】AWSでActive Directoryを学ぶ
この記事を共有する
目次
パーソル＆サーバーワークスの髙井です。
AWS を中心としたクラウドインフラの設計・構築・運用を担当しています。
はじめに
Active Directory Domain Services（以下、AD DS）は、Windows 環境でユーザーや端末を一元管理する仕組みです。
本ブログは AD DS シリーズの2本目です。
入門編で構築したドメインコントローラー（以下、DC）を使い、実際に OU・グループ・ユーザーを作り、メンバーサーバーをドメインに参加させて GPO を適用するところまでを、GUI 中心で進めます。
本シリーズは下記の3部構成です。
- 入門編：AD の基礎と、EC2 上へのドメインコントローラー構築
- 運用編（本ブログ）：OU 設計、グループ設計（AGDLP）、ユーザー作成、メンバーサーバーのドメイン参加、GPO 適用
- 比較編：同じ環境を AWS Managed Microsoft AD に置き換えたときの違い
AD の基礎用語（DC、OU、GPO、SRV レコード、Kerberos など）は入門編で解説済みのため、本ブログでは説明済みとして進めます。
想定読者
- 入門編を読み終えた方、または AD の基本用語を理解していて、実際の運用の流れを知りたい方
今回の作業と構成
入門編では DC を1台建てるところまでを扱いました。
本ブログでは、その DC に対して下記を順に実施します。
- OU を設計して作る
- AGDLP でグループを設計する
- ユーザーを作って所属させる
- メンバーサーバーをドメインに参加させる
- GPO を作って適用を確認する
作業は GUI（Active Directory ユーザーとコンピューター、以下 ADUC）で進めます。
入門編の DC に加えて、メンバーサーバーがドメインに参加する構成です。
なお、実運用では DC に直接ログオンせず、管理ツール（RSAT）を入れたメンバーサーバーから AD を操作するのが定石です。
比較編で扱う AWS Managed Microsoft AD ではそもそも DC にログオンできないため、本ブログでもメンバーサーバーから操作する形で進めます。
1. OU を設計して作る
新規ドメインには「Users」「Computers」という置き場が最初から用意されていますが、これらは container であり OU ではありません。
container には GPO をリンクできないため、実運用では自前で OU を作り、そこにオブジェクトを配置します。
ADUC でドメイン名を右クリックし、「新規作成」から「組織単位」を選んで作成します。
今回は「JP」を作り、その下に「Users」「Groups」「Servers」の3つを作ります。
2. AGDLP でグループを設計する
AGDLP は Microsoft が推奨する権限設計のパターンです。
「人の束（Global グループ）」を「権限の束（DomainLocal グループ）」に入れ、権限の束をリソースの ACL に登録する、という順番で設計します。
こうすると、人事異動は人の束のメンバーを入れ替えるだけで済み、ACL を触らずに運用できます。
「Groups」OU の中に、性質の違うグループを2つ作ります。
| グループ名 | スコープ | 役割 |
|---|---|---|
| SEC-Sales-Members | グローバル | 営業部の人をまとめる（人の束） |
| SEC-FileShare-Sales-RW | ドメインローカル | 営業用共有への読み書き権限を表す（権限の束） |
作成後、ADUC では権限の束のプロパティの「メンバー」タブから、人の束を追加します。
この時点では権限の束はまだ何の権限も持っていません。
グループ名の「RW」は役割を表すラベルにすぎず、実際にファイル共有の ACL にこのグループを登録して初めて権限が発生します。
リソースができる前に「箱」を先に用意しておくのが AGDLP の進め方です。
3. ユーザーを作って所属させる
「Users」OU の中にユーザーを作ります。
ADUC の「新規作成」から「ユーザー」を選び、下記を入力します。
- 姓 / 名：Yamada / Taro
- ユーザーログオン名（UPN）：tyamada@corp.ad-practice.local
作成後、「所属するグループ」タブから「SEC-Sales-Members」（人の束）に追加します。
ここで押さえておきたいのが、AD のアクセス制御は名前ではなく SID（セキュリティ識別子） で行われるという点です。
ユーザーを別ドメインに作り直すと SID が変わるため、既存のファイルサーバーの ACL からアクセスできなくなります。
これを回避する仕組みが SID History で、AD 移行ツールの ADMT が自動で行います。
なお、ユーザーは作成時に自動で「Domain Users」グループに所属します。
これは全ユーザー共通の基盤グループで、そのまま使います。
4. メンバーサーバーをドメインに参加させる
DNS 参照先を DC に向ける
メンバーサーバーがドメインを見つけられるよう、ネットワークアダプターの設定で、DNS 参照先を DC の IP アドレス（今回は 10.1.0.10）に向けます。
入門編で「AD は DNS の SRV レコードで DC を発見する」と説明しました。
メンバーサーバーが DC を見つける経路がまさにこれで、DNS 参照先を DC に向けないとドメインを発見できません。
ドメインに参加する
システムのプロパティからドメイン参加を実行し、「corp.ad-practice.local」を指定します。
参加時にドメイン管理者の資格情報を求められ、参加後は再起動が入ります。
↓
再起動後、「CORP\tyamada」でログオンできれば参加成功です。
ログオン後、コマンドプロンプトで下記を実行し、チケット（TGT）が表示されれば Kerberos 認証が成立しています。
klist
AD の既定の認証は Kerberos で、パスワードそのものをネットワークに流さない仕組みです。
コラム：初回ログオンでつまずきやすい点
作成したてのドメインユーザーで RDP ログオンすると弾かれることがあります。多くは「認証」と「認可」の切り分けで解けます。
パスワードが通らない（資格情報が機能しない）のは認証の問題で、初回パスワード変更の要求やパスワード複雑性（アカウント名を含むと拒否される）が原因になりがちです。
一方「ログインを許可されていない」と出るのは認可の問題で、ドメインユーザーは既定でメンバーサーバーの RDP 権限を持たないため、対象サーバーの「Remote Desktop Users」に追加する必要があります。
5. GPO を作って適用を確認する
グループポリシー管理（GPMC）で GPO を作成し、「Users」OU にリンクします。
今回はスクリーンセーバーのタイムアウトを強制する設定を入れます。
参加したメンバーサーバーで、コマンドプロンプトから下記を実行し、ポリシーを更新して適用状況を確認します。
gpupdate /force
gpresult /r /scope:user
「Applied Group Policy Objects」に「JP-Users-Baseline」が表示されれば適用成功です。
まとめ
本ブログの要点は下記のとおりです。
- 既定の「Users」「Computers」は container で GPO をリンクできないため、自前で OU を設計します
- グループは AGDLP で設計すると、人事異動に強い構成になります
- AD のアクセス制御は SID で行われるため、ドメイン移行では SID History の考慮が必要になります
- メンバーサーバーは DNS 参照先を DC に向けてからドメイン参加します。認証は Kerberos で通ります
次回の比較編では、ここまで自己管理で構築してきた AD を AWS Managed Microsoft AD に置き換えると、何ができて何ができなくなるのかを比較します。
最後までお読みいただきありがとうございました。
参照ドキュメント
- Active Directory 管理ツールのインストール
- Microsoft: グループポリシーの処理順序)
- Microsoft: How to configure a firewall for Active Directory domains and trusts
この記事は私が書きました
髙井 大暉
記事一覧頑張ってインフラエンジニアやってます。
