Active Directoryの概念と設計
Active Directory ドメインサービス（AD DS）とは
Active Directory ドメインサービス（AD DS）は、Windows Serverの中核機能であり、企業ネットワーク上のユーザー、コンピュータ、リソースを一元的に管理するディレクトリサービスです。ひとり情シスにとって、AD DSの理解と適切な運用は最も重要なスキルのひとつです。
Active Directoryが解決する課題
AD DSがない環境（ワークグループ）では、以下の問題が発生します。
- 各PCにローカルアカウントを個別作成する必要があり、管理が煩雑
- パスワード変更を全PCで個別に実施しなければならない
- ファイルサーバーのアクセス権をPC単位で管理するため、人事異動時の作業が膨大
- セキュリティポリシーの統一的な適用ができない
- ソフトウェアの一括配布や設定変更ができない
AD DSを導入することで、「ひとつのアカウントで全社リソースにアクセス」するシングルサインオン環境が実現し、管理負荷が劇的に軽減されます。
Active Directoryの論理構造
| 概念 | 説明 | 中小企業での一般的な構成 |
|---|---|---|
| フォレスト | AD DSの最上位の境界。信頼関係の最大範囲 | 通常1つ |
| ドメイン | 管理の基本単位。セキュリティポリシーの適用範囲 | 通常1つ（シングルドメイン） |
| ドメインツリー | 親子関係を持つドメインの階層構造 | 中小企業では不要な場合が多い |
| OU（組織単位） | ドメイン内のオブジェクトを整理するコンテナ。GPOの適用単位 | 部署・拠点・用途別に作成 |
| サイト | 物理ネットワーク（拠点）を表す。レプリケーション制御に使用 | 複数拠点がある場合に設定 |
ポイント：中小企業では「1フォレスト・1ドメイン」のシンプルな構成が推奨されます。マルチドメインはコスト管理の境界分離やセキュリティ要件が特殊な場合にのみ検討してください。複雑な構成は管理負荷を増大させ、ひとり情シスでは維持困難になります。
ドメイン名の設計
ADドメイン名は後から変更が非常に困難なため、慎重に設計する必要があります。
| 方式 | 例 | メリット | デメリット |
|---|---|---|---|
| 内部専用名 | corp.local / ad.example.local | 外部DNSと衝突しない | .localドメインはmDNSと競合する可能性 |
| 外部ドメインのサブドメイン | ad.example.co.jp | DNS構成がシンプル。証明書取得も容易 | 外部DNSとの整合性管理が必要 |
⚠️ 注意
現在のベストプラクティスでは、外部ドメインのサブドメイン（例：ad.example.co.jp）が推奨されています。「.local」ドメインはmacOSのBonjour（mDNS）と競合するため、Macが混在する環境では問題が発生します。また、将来のクラウド連携（Microsoft Entra ID旧Azure AD）を見据えると、外部ドメインとの整合性が重要です。
OU（組織単位）の設計
OUはドメイン内のオブジェクトを論理的に整理するコンテナで、グループポリシー（GPO）の適用単位としても機能します。
📋 具体例
中小企業のOU設計例（従業員50名規模）：
example.co.jp（ドメイン）
├── 本社
│ ├── ユーザー
│ │ ├── 営業部
│ │ ├── 管理部
│ │ └── 技術部
│ └── コンピュータ
│ ├── デスクトップ
│ └── ノートPC
├── 大阪支社
│ ├── ユーザー
│ └── コンピュータ
├── サーバー
├── サービスアカウント
└── 無効アカウント
OU設計のポイントは以下の通りです。
- GPO適用を意識した階層にする（部署別ポリシーが必要ならOU分割）
- ユーザーとコンピュータは別のOUに分ける（異なるGPOを適用するため）
- 退職者用OUを作成し、アカウント無効化後に移動する運用を定める
- サービスアカウント用OUで、システム用アカウントを一般ユーザーと分離する
- 深すぎる階層は避ける（3〜4階層が目安）
ADオブジェクトの種類
| オブジェクト | 説明 | 管理のポイント |
|---|---|---|
| ユーザー | 個人の認証・属性情報を保持 | 命名規則を統一（例：姓.名、社員番号） |
| コンピュータ | ドメイン参加PCの情報を保持 | 命名規則を統一（例：拠点コード-連番） |
| グループ | ユーザー・コンピュータをまとめるコンテナ | アクセス権はグループに付与する |
| 連絡先 | メールアドレスなどの外部連絡先情報 | 社外の取引先などに使用 |
| プリンター | 共有プリンターの情報を公開 | ADに公開するとユーザーが検索・追加可能 |
セキュリティグループ vs 配布グループ
| グループの種類 | 用途 | SID | 具体例 |
|---|---|---|---|
| セキュリティグループ | アクセス権の付与、ポリシーの適用対象 | あり | 経理部フォルダアクセス権、VPN接続許可 |
| 配布グループ | メール配布リスト（Exchange/Microsoft 365） | なし | 全社連絡用メールグループ |
さらにセキュリティグループのスコープには3種類があります。
| スコープ | メンバーに追加できるもの | アクセス権を付与できる範囲 | 使用場面 |
|---|---|---|---|
| ドメインローカル | 同一フォレスト内の任意のオブジェクト | 同一ドメイン内のリソースのみ | ファイルサーバーの権限付与 |
| グローバル | 同一ドメイン内のオブジェクトのみ | フォレスト内の任意のリソース | 部署・役職のグルーピング |
| ユニバーサル | フォレスト内の任意のオブジェクト | フォレスト内の任意のリソース | マルチドメイン環境での横断グループ |
ポイント：中小企業のシングルドメイン環境では、グローバルグループでユーザーをまとめ、ドメインローカルグループでリソースへのアクセス権を付与する「AGDLP（Account → Global → Domain Local → Permission）」の原則を適用するのがベストプラクティスです。
ドメインコントローラー（DC）の冗長化
ドメインコントローラーが停止すると、ユーザー認証やGPO適用ができなくなり、業務全体が停止します。
ひとり情シスの視点：どんなに小規模な環境でも、ドメインコントローラーは最低2台構成にしてください。1台が故障しても認証サービスを維持できます。2台目は物理サーバーでなくても、Hyper-V上の仮想マシンでも構いません。ただし、同一物理ホスト上に2台のDCを配置するのは意味がないため、異なるハードウェア上に配置しましょう。
✅ 完了済み