なぜ、世界中の企業は「AD」に依存しているのか?
こんにちは!「LINUX工房」管理人の「リナックス先生」です。
前回は、Windows Serverの管理における「PowerShell」の重要性と、Linuxとの思想の違いについて学びました。
今回からは、いよいよWindows Serverの核心部分に入っていきます。
皆さんの会社にも、きっとありますよね。
朝、PCにログインするときに入力するパスワード。
あれを管理しているのが「Active Directory(アクティブディレクトリ)」、通称ADです。
先生、正直ADってただの「ユーザー管理ツール」ですよね?
Linuxなら /etc/passwd とかOpenLDAPで十分じゃないですか。
なんでわざわざ高いライセンス料を払ってWindows Serverでやるんですか?
僕、ADの構築を任されたんですけど、「ドメイン」とか「フォレスト」とか用語がRPGみたいで全然頭に入ってこないです……。
コウ君、それは大きな誤解よ。
ADは単なるユーザーリストじゃないわ。
「誰が(User)」「どのPCを使って(Computer)」「何をしていいか(Policy)」を一元管理する、巨大な統合データベースなの。
ADがなければ、社員100人のPC設定を1台ずつ手作業で変更することになるわよ?
今回も、その道のプロに解説してもらいましょう。ウィンドウズ先生!
はい、ウィンドウズ先生です。
Linuxエンジニアの方にとって、ADは「ブラックボックス」に見えるかもしれません。
しかし、蓋を開けてみれば、中身は「DNS + LDAP + Kerberos」という、皆さんおなじみの標準技術の集合体なんです。
マイクロソフト独自の魔法ではありません。
この講座で、ADの「中身」を理解し、正しく構築・設計できるスキルを身につけましょう。
本記事では、Active Directoryの仕組み、用語の整理、そして実際にドメインコントローラーを構築するまでの手順を、Linuxエンジニアの視点で分かりやすく解説します。
🟦 Windows Server入門講座(全8回)カリキュラム
現在地:【第2回】Active Directory (AD) 構築。世界を支配する認証基盤の仕組み
- 【第1回】Linux脳を解き放て。GUIの誘惑とPowerShellという「武器」
- 【第2回】Active Directory (AD) 構築。世界を支配する認証基盤の仕組み
- 【第3回】ファイルサーバーと権限管理。chmod 777が存在しない世界(NTFS/ReFS)
- 【第4回】Windows版Webサーバー「IIS」入門。Nginx使いが知るべき作法の違い
- 【第5回】WSL2とWindows Terminal。Windows上でLinuxを飼い慣らすハイブリッド開発環境
- 【第6回】更新プログラムとの戦い。WSUS構築とWindows Updateの完全制御
- 【第7回】トラブルシューティングとイベントビューア。grepできないログをどう読むか
- 【第8回】Hyper-Vとコンテナ。WindowsコンテナとDockerの共存戦略
第1章:Active Directoryの正体。Linux用語で翻訳する
ADを理解するために、新しい概念を覚える必要はありません。
皆さんが知っているLinuxの技術に置き換えてみましょう。
1. データベースは「LDAP」である
ADのユーザー情報やコンピュータ情報は、LDAP(Lightweight Directory Access Protocol)というプロトコルでアクセスできるデータベースに格納されています。
Linuxで言う「OpenLDAP」とほぼ同じです。
実際、Linuxサーバーから ldapsearch コマンドでADの情報を検索することも可能です。
2. 認証は「Kerberos」である
ユーザーがパスワードを入力してログインする時、裏ではKerberos(ケルベロス)認証が動いています。
一度ログインすれば、ファイルサーバーやプリンターを使うたびにパスワードを入力しなくても済む「シングルサインオン(SSO)」を実現する技術です。
これもLinuxの標準技術ですね。
3. 名前解決は「DNS」である
ここが最重要ポイントです。
「ADはDNSなしでは1秒も動かない」と言っても過言ではありません。
クライアントPCは、「ログインしたいけど、認証サーバーはどこ?」という情報を、すべてDNS(SRVレコード)に問い合わせて解決します。
ADを構築するということは、同時にDNSサーバーを構築するということでもあります。
💡 ウィンドウズ先生のワンポイント
LinuxエンジニアがAD構築でハマる原因のNo.1は「DNS設定の不備」です。
ドメインコントローラー(サーバー)自身のDNS参照先は、Google(8.8.8.8)ではなく、自分自身(127.0.0.1)に向けるのが鉄則です。
そうしないと、自分自身がADのサービスを提供していることをDNSに登録できず、誰もログインできなくなります。
第2章:RPGのような用語を攻略する
コウ君が混乱していた「ドメイン」「ツリー」「フォレスト」といった用語を整理します。
これは「会社の組織図」に例えると分かりやすいです。
ドメイン (Domain)
ADの基本単位です。「株式会社〇〇」という一つの組織だと思ってください。
セキュリティの境界線であり、管理の範囲です。
ドメインコントローラー(DC)というサーバーによって管理されます。
組織単位 (OU: Organizational Unit)
ドメインの中にある「部署」です。
「営業部」「開発部」「総務部」といったフォルダのような入れ物を作り、そこにユーザーやPCを整理して入れます。
グループポリシー(設定の一括適用)は、このOU単位で適用します。
ツリー (Tree) と フォレスト (Forest)
- ツリー: 親会社と子会社のように、連続した名前空間を持つドメインの集まり。
例:親example.com─ 子dev.example.com - フォレスト: 全く別の名前空間を持つドメイン同士も含めた、AD全体の集合体。
例:example.comとdummy.netが提携して、お互いのユーザーを信頼する場合など。
※中小規模の構築であれば、「フォレスト=ドメイン=1つの会社」というシンプルな構成(シングルフォレスト・シングルドメイン)で十分です。
第3章:設計の勘所。ドメイン名をどうするか?
ADを構築する際、最初に決めなければならないのが「ドメイン名」です。
ここで失敗すると、後から変更するのはOS再インストールレベルの大工事になります。
❌ 悪い例: `.local` を使う
昔の解説書にはよく corp.local のように書かれていましたが、現在は非推奨です。
MacやLinuxで使用される「mDNS(Bonjour)」というプロトコルと競合し、名前解決が遅くなったり不安定になったりする原因になります。
❌ 悪い例: 公開ドメインと同じにする
会社のWebサイトが example.com だからといって、ADドメイン名を example.com にするとトラブルになります。
社内から会社のWebサイト(wwwなし)を見ようとした時、DNSが「それはADサーバーのことだ」と勘違いしてしまい、Webサイトに繋がらなくなる「スプリットブレインDNS」問題が発生します。
⭕ 推奨例: サブドメインを使う
ad.example.com や corp.example.com 、intra.example.com のように、社内専用のサブドメインを使います。
これならインターネット上のドメインと衝突せず、管理もスムーズです。
第4章:実践!ドメインコントローラーの構築
それでは実際にサーバーを構築しましょう。
ADのデータベースを持ち、認証を担当するサーバーを「ドメインコントローラー(DC)」と呼びます。
前提条件:
- OS: Windows Server 2022 / 2025
- IPアドレス: 固定IP(例: 192.168.1.10)
- DNS設定: 優先DNSを自分自身(127.0.0.1)に設定
Server Coreで構築するのがプロの流儀ですが、今回は概念を理解するためにGUIでの手順を紹介します。
もちろん、後ほどPowerShellでの「一撃構築コマンド」も教えますよ。
手順1:役割のインストール
- 「サーバーマネージャー」を開き、「役割と機能の追加」をクリック。
- 「Active Directory ドメイン サービス」にチェックを入れます(必要な機能も同時に追加)。
- インストールが完了するのを待ちます。
手順2:ドメインコントローラーへの昇格
役割を入れただけでは、まだただのサーバーです。「昇格(Promote)」作業が必要です。
- サーバーマネージャーの右上の旗アイコンに「!」が出るのでクリックし、「このサーバーをドメインコントローラーに昇格する」を選択。
- 「新しいフォレストを追加する」を選択(新規構築の場合)。
- ルートドメイン名を入力(例:
corp.linux-kobo.com)。 - ディレクトリサービス復元モード(DSRM)のパスワードを設定(緊急時に使う重要なパスワードです)。
- あとは「次へ」連打でOK。前提条件チェックが通り、「インストール」をクリックすると、自動的に再起動します。
再起動後、ログイン画面のユーザー名が CORP\Administrator になっていれば成功です!
【プロの流儀】PowerShellで構築する場合
GUIでポチポチやるのが面倒なLinuxエンジニアの皆さんは、以下のコマンドを実行してください。
これだけで全工程が完了します。
# 1. AD機能のインストール
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
# 2. 新しいフォレストの作成と昇格(パスワード入力を求められます)
Install-ADDSForest `
-DomainName "corp.linux-kobo.com" `
-DomainNetbiosName "CORP" `
-InstallDns:$true `
-NoRebootOnCompletion:$false `
-Force:$true
Ansible等で自動化する場合も、このコマンドレットを使用します。
第5章:ユーザーとコンピュータの管理
AD構築後は、「Active Directory ユーザーとコンピューター(ADUC)」という管理ツールを使います。
スタートメニューの「Windows 管理ツール」の中にあります。
OU(組織単位)を作る
デフォルトの「Users」コンテナに全社員を入れるのはやめましょう。管理不能になります。
ドメイン名を右クリック→新規作成→「組織単位(OU)」で、部署ごとの箱を作ります。
例:Employees OUの下に Sales, Dev, Admin OUを作るなど。
ユーザーを作る
作成したOUを右クリック→新規作成→「ユーザー」。
ここで設定したIDとパスワードが、社員がPCにログインする時の情報になります。
PowerShellでのユーザー一括作成
新入社員が100人入ってきました。手作業で登録しますか?
LinuxエンジニアならCSVから流し込みたいですよね。
# users.csv (Name, SamAccountName, Department) を読み込んで作成
Import-Csv "C:\users.csv" | ForEach-Object {
New-ADUser `
-Name $_.Name `
-SamAccountName $_.SamAccountName `
-UserPrincipalName "$($_.SamAccountName)@corp.linux-kobo.com" `
-Path "OU=$($_.Department),OU=Employees,DC=corp,DC=linux-kobo,DC=com" `
-AccountPassword (ConvertTo-SecureString "InitialP@ss123" -AsPlainText -Force) `
-Enabled $true
}
これがWindows管理の楽しさです。
第6章:クライアントPCを参加させる
最後に、社員のPC(Windows 10/11 Pro以上)をドメインに参加させます。
※Homeエディションは参加できないので注意してください。
- PCのDNS設定を変更する:
PCのネットワーク設定で、DNSサーバーのアドレスを「今回構築したADサーバーのIP」に変更します。
これをしないと「ドメインが見つかりません」というエラーになります(超頻出トラブル)。 - ドメイン参加設定:
「設定」→「システム」→「バージョン情報」→「システムの詳細設定」→「コンピュータ名」タブ→「変更」。 - 「所属するグループ」で「ドメイン」を選択し、
corp.linux-kobo.comと入力。 - ADの管理者IDとパスワードを求められるので入力。
- 「ドメインへようこそ」と出れば成功。再起動します。
これで、このPCはADの管理下に入りました。
どのPCからでも、自分のIDでログインできるようになります。
まとめ:ADは「インフラの心臓」である
お疲れ様でした!
第2回は、Active Directoryの仕組みと構築手順について解説しました。
今回の重要ポイント:
- ADは「LDAP + Kerberos + DNS」のセットである。
- ドメイン構築時はDNS設計が命。「.local」は使わない。
- クライアントのDNS参照先をADサーバーに向けるのを忘れない。
- PowerShellを使えば、大量のユーザー管理もスクリプト化できる。
AD構築おめでとうございます。
でも、実はこれで終わりではありません。
ADサーバーが1台だけだと、それが故障した瞬間に全社員がログインできなくなります。
本番環境では必ず「2台以上のDC」を用意して冗長化する必要があります。
このあたりのレプリケーション設計も、LinuxのDBレプリケーションと考え方は同じですよ。
さて、ユーザー認証基盤ができたら、次に必要なのは「データを保存する場所」です。
Windowsのファイルサーバーは、LinuxのSambaとは異なる、非常に強力かつ詳細な権限管理システム(NTFSアクセス許可)を持っています。
次回、第3回は「ファイルサーバーと権限管理。chmod 777が存在しない世界(NTFS/ReFS)」です。
「フルコントロール」と「変更」の違い、継承の仕組み、そして最新のファイルシステムReFSについて解説します。お楽しみに!
▼ AD環境を構築して実験しよう ▼
ドメインコントローラーを立てる
「おすすめVPS」
AD設計スキルを活かす
「ITエンジニア転職」

コメント