こんにちは、今回はシリーズ第３回クライアントとサーバーのドメイン参加について解説いたします！

はじめに

こんにちは！シリーズ第3回「クライアントとサーバーのドメイン参加」へようこそ。

前回（第2回）では、Active Directoryドメイン環境の構築手順について、ドメインコントローラーのセットアップからDNS設定まで詳しく解説しました。ドメイン環境の「土台」が整ったところで、今回はいよいよ実際にコンピューターをドメインに参加させる手順に進みます。

「ドメインユーザーアカウントを作ったのに、なぜかログインできない」「新しいPCを追加したけど、ドメイン認証が使えない」といった経験はありませんか？実は、Active Directoryの世界では、ユーザーアカウントを作成しただけでは不十分で、そのユーザーが使用するコンピューター自体もドメインに「参加」させる必要があるのです。

本記事では、このドメイン参加について、単なる手順の説明にとどまらず、「なぜドメイン参加が必要なのか」「裏側で何が起きているのか」という本質的な仕組みまで、初心者の方にも分かりやすく解説していきます。Windows PCはもちろん、Windows ServerやLinuxサーバーのドメイン参加方法、そして参加後に自動適用されるグループポリシーの仕組みまで、実践的な内容を網羅しています。

特に、企業でAIセキュリティツールやクラウドサービスを導入する際、このドメイン参加の仕組みを理解していることは、トラブルシューティングの際に大きな武器となります。それでは、Active Directoryの中核となる「信頼関係」の世界を一緒に探求していきましょう！

連載の構成

第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎

第2章：ドメイン環境の構築 - 検証環境の構築手順

【★今回です★】第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順

第4章：プロキシサーバーと統合Windows認証

第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法

第6章：トラブルシューティング - よくある問題と解決方法

第7章：セキュリティとベストプラクティス - 本番環境での考慮事項

第8章：実践的な構成例 - AIセキュリティツールとの統合事例

第3章：クライアントとサーバーのドメイン参加

3.1 ドメイン参加の基本

3.1.1 なぜドメイン参加が必要か

多くの初心者の方が誤解しがちなのが、

「ユーザーがドメインアカウントを持っていれば、どのPCからでもログインできる」

という考えです。

実は、ユーザーがアカウントをもっていても、そのユーザーが使うPCもドメインに参加している必要があるんです。

【よくある勘違い】
新入社員：「私のドメインアカウント（tanaka_t）をもらいました！」
新入社員：「これで会社のどのPCでも使えるんですよね？」
IT管理者：「いいえ、そのPCがドメインに参加している必要があります」
新入社員：「え？PCも参加が必要なの？」

（現実世界に例えると）
新入社員：「社員証をもらいました！」
新入社員：「これで会社のどの建物にも入れるんですよね？」
警備員：「いいえ、その建物が会社の管理下にある必要があります」
新入社員：「なるほど...」

ドメイン参加していないPCでの状況を見てみましょう。

【未参加PCでのログイン試行】
田中：「このPCにログインしたい」
（ログイン画面）
ユーザー名：tanaka_t
パスワード：********
サインイン先：このコンピューター ← ドメインが選択できない！

田中：「あれ？ドメインが選べない」
PC：「私はドメインを知りません。ローカルアカウントしか受け付けません」

田中：「じゃあ、手動で入力... JP\tanaka_t」
PC：「JP？何それ？知らないドメインです」

ドメイン参加済みPCでの状況は全く異なります。

【参加済みPCでのログイン】
田中：「このPCにログインしたい」
（ログイン画面）
ユーザー名：tanaka_t
パスワード：********
サインイン先：JP ← ドメインが選択可能！

PC：「JPドメイン（jp.qualiteg.com）のtanaka_tさんですね」
PC→DC（ドメインコントローラー）：「この人、本物？」
DC：「パスワード確認...はい、本物の田中さんです」
PC：「確認取れました。どうぞログインしてください」
田中：「やった！」

ドメイン参加の本質的な意味を理解しましょう。

【信頼関係の確立】
IT管理者：「ドメイン参加とは、PCとドメインの間に信頼関係を作ることです」

参加前：
PC：「私は独立したコンピューターです」
DC：「知らないPCだ。信用できない」

参加プロセス：
管理者：「このPCをドメインに参加させます」（管理者権限で実行）
DC：「管理者の認証確認...OK、このPCを仲間として登録します」
PC：「これから私はjp.qualiteg.comドメインの一員です」

参加後：
PC：「私はjp.qualiteg.comドメインのPC-001です」
DC：「ああ、PC-001君か。君は信頼できる仲間だ」

ドメイン参加のメリットを見てみましょう。

【管理面でのメリット】
社長：「全PCをドメイン参加させる手間をかける価値はある？」
IT管理者：「大きなメリットがあります」

1. 統一管理
IT管理者：「グループポリシーで全PCを一括設定できます」
例：「全PCで10分操作なしでロック画面」を一度の設定で実現

2. シングルサインオン
田中：「朝一度ログインしたら、ファイルサーバーもメールも追加認証不要！」

3. ローミングプロファイル
田中：「どのPCでログインしても、自分のデスクトップ環境が再現される」

4. セキュリティ
IT管理者：「誰がいつどのPCを使ったか、すべて記録されます」

社長：「なるほど、管理が格段に楽になるんだ」

3.1.2 コンピューターアカウントとは

ADでは、ユーザーだけでなくコンピューター自体もアカウントとして管理されます。これは多くの人が理解しにくい概念かもしれません。

【コンピューターも社員？】
新人：「コンピューターアカウントって何ですか？人じゃないのに」
IT管理者：「会社組織で例えてみましょう」

会社の管理対象：
- 正社員（田中さん、山田さん）→ ユーザーアカウント
- 会社の車（社用車1号、2号）→ コンピューターアカウント

総務：「社用車も管理番号があって、誰が使えるか決まってますよね」
IT管理者：「同じように、PCも管理対象として登録が必要なんです」

コンピューターアカウントの実際を見てみましょう。

【AD管理ツールで見ると】
IT管理者：「Active Directory ユーザーとコンピューター を開いてみましょう」

jp.qualiteg.com
├── Users（ユーザー）
│   ├── tanaka_t（田中太郎）
│   ├── yamada_h（山田花子）
│   └── Administrator（管理者）
└── Computers（コンピューター）
    ├── PC-001$  ← $マークがコンピューターアカウントの印
    ├── PC-002$
    └── SERVER-01$

新人：「本当だ！PCも一覧に載ってる」
IT管理者：「コンピューター名の最後に$が付くのが特徴です」

コンピューターアカウントの認証情報について理解しましょう。

【コンピューターにもパスワードがある】
新人：「でも、PCがパスワード入力するところ見たことない」
IT管理者：「実は裏で自動的にやってるんです」

コンピューターアカウントの特徴：
- アカウント名：PC-001$
- パスワード：（120文字のランダムな文字列）
- パスワード変更：30日ごとに自動更新

新人：「120文字！？」
IT管理者：「人間が覚える必要はありません。PCが自動管理します」

実際の動作：
毎朝PCが起動時...
PC：「おはようございます。PC-001$です」
PC：「私のパスワードは... Xk9#mP2$... （120文字）」
DC：「パスワード確認...OK、本物のPC-001$だ」

コンピューターアカウントの役割を見てみましょう。

【なぜコンピューターアカウントが必要？】
営業：「ユーザーの認証だけじゃダメなの？」
IT管理者：「セキュリティ上、PCの認証も必要なんです」

シナリオ1：悪意のあるPCを防ぐ
悪意のある人：「偽PCを会社のネットワークにつなごう」
偽PC：「田中さんがログインしようとしています」
DC：「ちょっと待て、お前誰だ？コンピューターアカウントは？」
偽PC：「...ありません」
DC：「信頼できないPCからのアクセスは拒否」

シナリオ2：正規のPC
PC-001：「田中さんがログインしようとしています」
DC：「PC-001$か、君は登録済みの信頼できるPCだね」
DC：「田中さんの認証も確認。ログインOK」

コンピューターアカウントでできることを理解しましょう。

【コンピューターアカウントの権限】
新人：「コンピューターアカウントは何ができるの？」
IT管理者：「実は色々できるんです」

1. 自身の情報をDNSに登録
PC-001：「私のIPアドレスが変わったので、DNS更新します」
DNS：「PC-001$からの要求か...信頼できるので更新OK」

2. グループポリシーの取得
PC-001：「最新のポリシーをください」
DC：「PC-001$用のポリシーはこれです」

3. ユーザー認証の仲介
PC-001：「田中さんの認証をお願いします」
DC：「信頼できるPC-001$からの要求なので処理します」

4. 自身のパスワード変更
PC-001：「30日経ったので、パスワード変更します」
DC：「OK、新しいパスワードを設定しました」

3.1.3 管理者権限の必要性

ドメイン参加には必ず管理者権限が必要です。これは、セキュリティ上の重要な仕組みです。

【なぜ管理者権限が必要？】
一般社員：「私のPCなんだから、私がドメイン参加させたい」
IT管理者：「残念ながら、それはできません」
一般社員：「なんで？」

（現実世界で例えると）
一般社員：「私の机なんだから、私が社長室に置きたい」
総務：「それは総務の許可が必要です」
一般社員：「そういうことか...」

権限がない場合の動作を見てみましょう。

【一般ユーザーでドメイン参加を試みる】
田中（一般ユーザー）：「このPCをドメイン参加させよう」

システムのプロパティ → ドメイン変更
ドメイン：jp.qualiteg.com を入力
[OK]をクリック

エラーメッセージ：
「ドメインに参加するための権限がありません。
 ドメイン管理者に連絡してください。」

田中：「やっぱりダメか...」

管理者権限での参加を見てみましょう。

【管理者による参加作業】
IT管理者：「では、私が参加させましょう」

認証ダイアログ：
「jp.qualiteg.com ドメインに参加するための資格情報」
ユーザー名：Administrator
パスワード：************

↓

「jp.qualiteg.com ドメインへようこそ」

IT管理者：「参加完了です。再起動してください」

では、なぜこの仕組みが必要なのでしょうか。以下の例でみてみましょう。

【セキュリティの観点】
セキュリティ担当：「もし誰でもドメイン参加できたら？」

悪夢のシナリオ：
悪意のある人：「自分のPCを勝手にドメイン参加」
悪意のPC：「私は正規のドメインメンバーです」
悪意のPC：「社内の情報を収集...」

現実：
悪意のある人：「ドメイン参加したい」
システム：「管理者権限は？」
悪意のある人：「...ない」
システム：「却下」

セキュリティ担当：「だから管理者権限が必要なんです」

また権限の種類と使い分けを見てみましょう。

【ドメイン参加に使える権限】
新人：「Administratorしか参加させられない？」
IT管理者：「いえ、いくつかの選択肢があります」

1. Domain Admins（ドメイン管理者）
- 最高権限
- 何でもできる
- 通常は使わない（権限が強すぎる）

2. Administrator
- デフォルトの管理者
- ドメイン参加可能

3. Account Operators
- アカウント管理に特化
- ドメイン参加可能
- ユーザー作成も可能

4. 委任された権限
- 特定のOU（組織単位）にのみ参加可能
- 最小権限の原則

IT管理者：「通常は専用アカウントを作ります」

さらに実際の運用での工夫を見てみましょうか。

【ドメイン参加専用アカウント】
IT部長：「ヘルプデスクスタッフにAdministratorパスワードは教えたくない」
IT管理者：「専用アカウントを作りましょう」

作成するアカウント：
- 名前：join_domain
- 所属グループ：Account Operators
- 用途：ドメイン参加のみ

運用ルール：
1. ヘルプデスクはこのアカウントでドメイン参加
2. 他の管理作業はできない
3. パスワードは定期的に変更
4. 使用履歴を監査

IT部長：「これなら安心だ」

3.2 ドメイン参加の手順

本節では、ドメインに参加する手順をみていきたいとおもいます。

3.2.1 Windows PCのドメイン参加

まずWindows 10/11のPCをドメインに参加させる手順を、実際の画面操作に沿って説明いたしますね

【新しいPCが届いた日】
総務：「新入社員用のPCが届きました」
IT管理者：「では、ドメイン参加させましょう」

事前準備チェックリスト：
☑ PCがネットワークに接続されている
☑ IPアドレスを取得している（DHCPまたは固定）
☑ DNSサーバーがDCを指している
☑ ドメイン管理者のID/パスワードを用意
☑ コンピューター名を決めている

基本的な参加手順（GUI）を見てみましょう。

【ステップ1：システムのプロパティを開く】
IT管理者：「まず、システムのプロパティを開きます」

方法1：
- Windowsキー + Pause/Break

方法2：
- スタート → 設定 → システム → 詳細情報 → 「このPCの名前を変更」

方法3：
- エクスプローラーで「このPC」を右クリック → プロパティ

コンピューター名の変更と同時に参加する手順を見てみましょう。

【ステップ2：ドメイン参加】
現在の状態：
コンピューター名：DESKTOP-ABC123（ランダムな名前）
ワークグループ：WORKGROUP

IT管理者：「まず、分かりやすい名前に変更します」

[変更]ボタンをクリック

コンピューター名：PC-101（新しい名前）
所属するグループ：
○ ワークグループ
● ドメイン：[jp.qualiteg.com]

[OK]をクリック

認証ダイアログの操作を見てみましょう。

【ステップ3：認証情報の入力】
ダイアログ：「ドメインに参加するための資格情報を入力」

（間違えやすいパターン）
新人IT：「ユーザー名... Administrator でいいですよね」
エラー：「ログオンに失敗しました」
先輩：「ドメイン名も含めて入力して」

正しい入力方法：
1. JP\Administrator
2. Administrator@jp.qualiteg.com

パスワード：************

[OK]をクリック

成功時の動作を理解しましょう。

【参加成功】
メッセージ：「jp.qualiteg.com ドメインへようこそ」

裏で起きていること：
1. PC→DC：「PC-101として参加したい」
2. DC：「管理者認証OK。PC-101$アカウントを作成」
3. DC→PC：「参加を承認。これがあなたのパスワード（120文字）」
4. PC：「パスワードを安全に保存しました」

IT管理者：「では再起動しましょう」

PowerShellでの参加方法も見てみましょう。

【上級者向け：PowerShell】
IT管理者：「大量のPCを参加させる時はPowerShellが便利」

# 管理者権限でPowerShell起動
# 基本コマンド
Add-Computer -DomainName "jp.qualiteg.com" -Credential JP\Administrator

# オプション付きの例
Add-Computer -DomainName "jp.qualiteg.com" `
             -NewName "PC-101" `
             -Credential (Get-Credential) `
             -OUPath "OU=Computers,OU=Tokyo,DC=jp,DC=qualiteg,DC=com" `
             -Restart

新人：「OUPathって何ですか？」
IT管理者：「参加時に特定のOU（組織単位）に配置できます」

3.2.2 Windows Serverのドメイン参加

Windows Serverをドメインに参加させる手順は、基本的にはクライアントPCと同じですが、サーバー特有の考慮事項があります。

【ファイルサーバー構築の日】
IT部長：「新しいファイルサーバーを構築して」
IT管理者：「まず、ドメインに参加させます」

サーバー特有の確認事項：
- 固定IPアドレスを設定済み？
- ホスト名は命名規則に従っている？
- 役割/機能のインストール前？後？

では、サーバーでの参加手順を見てみましょう。

【サーバーマネージャーからの参加】
1. サーバーマネージャーを開く
2. 「ローカルサーバー」をクリック
3. コンピューター名の横の「WORKGROUP」をクリック

現在：
コンピューター名：WIN-RANDOMSTRING
ワークグループ：WORKGROUP

変更後：
コンピューター名：FS-01（ファイルサーバー01）
ドメイン：jp.qualiteg.com

次に、メンバーサーバーとDCの違いを理解しましょう。

【役割による違い】
新人：「このサーバーもDCになるんですか？」
IT管理者：「いいえ、メンバーサーバーです」

サーバーの種類：
1. ドメインコントローラー（DC）
   - AD DSロールをインストール
   - ドメインに「昇格」
   - 認証を提供する側

2. メンバーサーバー
   - ドメインに「参加」
   - 認証を受ける側
   - ファイル、Web、DBなどのサービス提供

新人：「同じドメインでも役割が違うんですね」

ドメイン参加のタイミングも重要です。ここでは参加タイミングについて理解みていきましょう

【いつドメイン参加すべきか】
新人：「SQL Serverインストール後に参加でいいですか？」
先輩：「ちょっと待って！」

推奨される順序：
1. OS インストール
2. ネットワーク設定（固定IP）
3. ドメイン参加 ← ここ！
4. 役割/機能のインストール
5. アプリケーションのインストール

理由：
- 多くのアプリはドメイン環境を前提に設定
- サービスアカウントがドメインアカウントの場合が多い
- 後から参加すると設定変更が必要

3.2.3 Linux サーバーのドメイン参加

実は、LinuxサーバーもWindows ADドメインに参加できます。

これにより、LinuxでもADの認証基盤を活用できます。

【Linuxサーバーもドメインに？】
開発者：「Linux使いたいけど、認証は別管理？」
IT管理者：「いえ、LinuxもADに参加できます」
開発者：「え、Microsoftの技術なのに？」
IT管理者：「Sambaというソフトウェアを使います」

必要なパッケージのインストール（Ubuntu/Debian）を見てみましょう。

【準備作業】
# パッケージの更新
sudo apt update
sudo apt upgrade

# 必要なパッケージのインストール
sudo apt install samba winbind libnss-winbind libpam-winbind krb5-user

インストール中の質問：
「Default Kerberos version 5 realm:」
→ JP.QUALITEG.COM（大文字で入力）

「Kerberos servers for JP.QUALITEG.COM:」
→ dc01.jp.qualiteg.com dc02.jp.qualiteg.com

「Administrative server for JP.QUALITEG.COM:」
→ dc01.jp.qualiteg.com

Kerberosの設定を行います。

【/etc/krb5.conf の編集】
IT管理者：「Kerberosの設定をします」

[libdefaults]
    default_realm = JP.QUALITEG.COM
    dns_lookup_realm = false
    dns_lookup_kdc = true

[realms]
    JP.QUALITEG.COM = {
        kdc = dc01.jp.qualiteg.com
        kdc = dc02.jp.qualiteg.com
        admin_server = dc01.jp.qualiteg.com
    }

[domain_realm]
    .jp.qualiteg.com = JP.QUALITEG.COM
    jp.qualiteg.com = JP.QUALITEG.COM

テスト：
kinit administrator@JP.QUALITEG.COM
（パスワード入力）
klist（チケット確認）

Sambaの設定とドメイン参加を行います。

【/etc/samba/smb.conf の設定】
[global]
    workgroup = JP
    security = ADS
    realm = JP.QUALITEG.COM
    
    # Winbind設定
    winbind enum users = yes
    winbind enum groups = yes
    winbind use default domain = yes
    winbind refresh tickets = yes
    
    # UID/GIDマッピング
    idmap config * : backend = tdb
    idmap config * : range = 10000-19999
    idmap config JP : backend = rid
    idmap config JP : range = 20000-29999

実際の参加コマンドを実行します。

【ドメイン参加実行】
# DNSテスト
host -t SRV _ldap._tcp.jp.qualiteg.com

# ドメイン参加
sudo net ads join -U Administrator
Enter Administrator's password: ********

成功時のメッセージ：
Using short domain name -- JP
Joined 'LINUX-FS-01' to dns domain 'jp.qualiteg.com'

# 確認
sudo net ads testjoin
Join is OK

# Winbindサービスの起動
sudo systemctl enable winbind
sudo systemctl start winbind

# 動作確認
wbinfo -u（ドメインユーザー一覧）
wbinfo -g（ドメイングループ一覧）

NSS/PAMの設定を行います。

【認証統合の設定】
# /etc/nsswitch.conf の編集
passwd: compat winbind
group:  compat winbind

# PAMの自動設定
sudo pam-auth-update
[*] Winbind NT/Active Directory authentication

# テスト
id JP\\tanaka_t
uid=20001(tanaka_t) gid=20000(domain users) groups=20000(domain users)

開発者：「おお、ADのユーザーで認識された！」

3.2.4 トラブルシューティング

ドメイン参加時には様々なエラーが発生する可能性があります。
ここでは、よくある問題と解決方法を見ていきましょう

【エラー1：ドメインが見つからない】
エラーメッセージ：
「ドメイン jp.qualiteg.com に接続できませんでした。
 ドメインが存在しないか、接続できません。」

新人：「ドメイン名は合ってるのに...」
先輩：「DNSの設定を確認しよう」

DNS関連の確認を行います。

【DNS設定の確認手順】
1. IPアドレス設定の確認
ipconfig /all

確認ポイント：
DNSサーバー：192.168.1.1 ← ルーターを見てる！

先輩：「これが原因。DCのIPにしないと」

正しい設定：
DNSサーバー：192.168.1.10（DC01のIP）

2. 名前解決のテスト
nslookup jp.qualiteg.com
nslookup -type=SRV _ldap._tcp.jp.qualiteg.com

成功時：
Server:  dc01.jp.qualiteg.com
Address: 192.168.1.10

_ldap._tcp.jp.qualiteg.com    SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc01.jp.qualiteg.com

ネットワーク接続の確認を行います。

【エラー2：ネットワークパスが見つからない】
確認手順：
1. DCへのping
ping dc01.jp.qualiteg.com

失敗時：
「dc01.jp.qualiteg.com が見つかりません」
→ DNS問題

「要求がタイムアウトしました」
→ ファイアウォールまたはネットワーク問題

2. ポートの確認
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 389
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 445

必要なポート：
- 389 (LDAP)
- 445 (SMB)
- 88 (Kerberos)
- 135 (RPC)

認証エラーの対処を行います。

【エラー3：認証に失敗しました】
症状：
「指定されたドメインにログオンできませんでした。
 ユーザー名またはパスワードが正しくありません。」

チェックリスト：
1. ユーザー名の形式
   × administrator（ローカルと混同）
   ○ JP\administrator
   ○ administrator@jp.qualiteg.com

2. パスワードの確認
   - 大文字小文字の区別
   - NumLockの状態
   - キーボード配列（US/JP）

3. アカウントの状態
   - ロックアウトされていないか
   - 有効期限が切れていないか
   - 権限があるか

時刻同期の問題を確認します。

【エラー4：Kerberos関連のエラー】
症状：
「コンピューターアカウントが見つからないか、
 アクセスが拒否されました」

最も多い原因：時刻のズレ

確認方法：
# クライアント側
w32tm /query /status

# 時刻差の確認
w32tm /stripchart /computer:dc01.jp.qualiteg.com

5分以上ずれている場合：
# 即座に同期
w32tm /resync /computer:dc01.jp.qualiteg.com

# NTPサーバーの設定
w32tm /config /manualpeerlist:"dc01.jp.qualiteg.com" /syncfromflags:manual

既存のコンピューターアカウントの問題を解決します。

【エラー5：既にアカウントが存在する】
症状：
「コンピューターアカウント JP\PC-101 は既に存在します」

原因：
- 以前参加していたPCを再インストール
- 同じ名前の別PCが存在

解決方法：
1. AD管理ツールで確認
   「Active Directory ユーザーとコンピューター」
   → Computers → PC-101$ を探す

2. 古いアカウントの削除（管理者作業）
   右クリック → 削除

3. または別の名前で参加
   PC-101 → PC-101B

IT管理者：「定期的に使われていないアカウントは削除しましょう」

ドメイン参加後の確認を行います。

【正常に参加できたかの確認】
1. システムのプロパティ
   フルコンピューター名：PC-101.jp.qualiteg.com
   ドメイン：jp.qualiteg.com

2. コマンドでの確認
   systeminfo | findstr /B "Domain"
   Domain: jp.qualiteg.com

3. ログオン画面の確認
   サインイン先に「JP」が表示される

4. イベントログの確認
   イベントビューアー → システム
   ソース：NetJoin
   イベントID：4096
   「このコンピューターはドメインに正常に参加しました」

新人：「これで確実に参加できたことが分かりますね」
IT管理者：「はい、次はドメインユーザーでログインテストです」

3.3 ドメイン参加後の動作

3.3.1 信頼関係の確立

ドメイン参加が完了すると、コンピューターとドメインの間に「信頼関係」が確立されます。

お互いを信用し合う特別な関係となります

【信頼関係とは】
新人：「信頼関係って具体的に何ですか？」
IT管理者：「銀行口座に例えてみましょう」

銀行口座の例：
1. 口座開設（ドメイン参加）
   - 本人確認（管理者認証）
   - 口座番号発行（コンピューターアカウント作成）
   - 暗証番号設定（コンピューターパスワード）

2. ATM利用時（ログイン時）
   - カード挿入（コンピューター認証）
   - 暗証番号入力（ユーザー認証）
   - 取引可能（アクセス許可）

IT管理者：「銀行とあなたの間の信頼関係と同じです」

信頼関係の技術的な仕組みを理解しましょう。

【共有シークレット】
IT管理者：「PCとDCは『共有シークレット』を持ちます」

参加時に起きること：
1. DC：「あなた用のパスワードを生成しました」
   パスワード：Xk9#mP2$...(120文字)

2. PC：「受け取りました。安全に保存します」
   保存場所：LSA（Local Security Authority）シークレット

3. 以降の通信：
   PC：「私はPC-101$です。証明します」
   PC：（共有シークレットで署名したデータを送信）
   DC：「署名を検証...確かにPC-101$ですね」

新人：「お互いしか知らない秘密で認証するんですね」

さて実際の信頼関係の確認方法を見てみましょう。

【信頼関係のテスト】
コマンドプロンプト（管理者権限）で実行：
nltest /sc_query:jp.qualiteg.com

正常な場合：
Flags: 30 HAS_IP  HAS_TIMESERV
Trusted DC Name \\DC01.jp.qualiteg.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success
The command completed successfully

問題がある場合：
Trust Verification Status = 1717 0x6b5 RPC_S_UNKNOWN_IF
→ 信頼関係が壊れている

また、逆に、信頼関係が壊れる原因を理解しましょう。

【信頼関係の破損】
ユーザー：「昨日まで使えたのに、ログインできません！」
エラー：「このワークステーションとプライマリドメインとの
        信頼関係に失敗しました」

よくある原因：
1. PCを長期間起動していなかった
   PC：「3ヶ月ぶりに起動」
   DC：「パスワードが古すぎる。信用できない」

2. システムの復元/バックアップからの復旧
   PC：「1ヶ月前の状態に復元しました」
   DC：「パスワードが巻き戻ってる！偽物だ」

3. 同じ名前で再参加
   別PC：「私がPC-101$です」
   DC：「新しいPC-101$か。パスワード更新」
   元PC：「私がPC-101$です」
   DC：「パスワードが違う！偽物だ」

今度は信頼関係の修復方法を見てみましょう。

【修復方法】
方法1：再参加（確実だが手間）
1. ワークグループに戻す
2. 再起動
3. ドメインに再参加
4. 再起動

方法2：PowerShellで修復（効率的）
# 管理者権限で実行
Test-ComputerSecureChannel -Repair -Credential JP\Administrator

成功時：
True

# より詳細な修復
Reset-ComputerMachinePassword -Server DC01 -Credential JP\Administrator

3.3.2 コンピューターアカウントのパスワード管理

コンピューターアカウントのパスワードは、人間が管理するものではなく、自動的に管理されます。

【自動パスワード変更】
新人：「PCのパスワードって誰が変えてるの？」
IT管理者：「PC自身が自動的に変更します」

デフォルトの動作：
- 変更間隔：30日
- パスワード長：120文字
- 変更時刻：ランダム（負荷分散のため）

パスワード変更の流れを見てみましょう。

【30日後の深夜2時】
PC-101：「パスワード変更の時期だ」
PC-101：「新しいパスワードを生成... Yt7&nB9#...（120文字）」
PC-101→DC：「パスワード変更したいです」
DC：「現在のパスワードで認証してください」
PC-101：「現在のパスワードは Xk9#mP2$...」
DC：「確認しました。新しいパスワードは？」
PC-101：「Yt7&nB9#... です」
DC：「変更しました」
PC-101：「新パスワードを保存...完了」

パスワード変更の設定確認を行います。

【レジストリでの確認】
場所：HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

重要な値：
- DisablePasswordChange：0（変更有効）/ 1（変更無効）
- MaximumPasswordAge：30（日数）
- RefusePasswordChange：0（DC側で変更を受け付ける）

確認コマンド：
reg query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

パスワード変更を無効にする場合を見てみましょう。

【特殊な環境での設定】
仮想化担当：「テンプレートVMはパスワード変更されると困る」
IT管理者：「その場合は無効化できます」

グループポリシーでの設定：
コンピューターの構成
└ ポリシー
  └ Windows の設定
    └ セキュリティの設定
      └ ローカルポリシー
        └ セキュリティオプション
          └ ドメインメンバー：コンピューターアカウントの
            パスワード変更を無効にする：有効

注意：
IT管理者：「セキュリティリスクがあるので、通常は推奨しません」

古いパスワードの保持について理解しましょう。

【パスワード履歴】
IT管理者：「実は前回のパスワードも覚えています」

理由：
- ネットワーク遅延での不整合を防ぐ
- レプリケーション中の認証を保証

動作：
PC：「新パスワードで認証します」
DC2：「まだ古いパスワードしか知らない...」
PC：「では古いパスワードで」
DC2：「OK、認証成功」

（その後レプリケーションで同期）

3.3.3 グループポリシーの適用

ドメイン参加後の最大のメリットの一つが、グループポリシーによる一括管理です。

【グループポリシーとは】
社長：「全社員のPCで、USBメモリを使用禁止にしたい」
IT管理者：「グループポリシーなら一発です」

グループポリシーなしの場合：
- 500台のPCを1台ずつ設定
- 新入社員のPCも個別設定
- 設定漏れのリスク

グループポリシーありの場合：
- 1箇所で設定
- 全PCに自動適用
- 新規参加PCも自動適用

ポリシー適用のタイミングを理解しましょう。

【いつ適用される？】
1. コンピューター起動時（コンピューターポリシー）
PC起動：「おはようございます」
PC→DC：「最新のコンピューターポリシーください」
DC：「これが最新版です」
PC：「適用しました」

2. ユーザーログオン時（ユーザーポリシー）
田中ログオン：「ログインします」
PC→DC：「田中さん用のポリシーください」
DC：「田中さんは営業部なので、これです」
PC：「適用しました」

3. 定期更新（90分±30分）
PC：「定期更新の時間だ」
PC→DC：「ポリシーの更新ありますか？」
DC：「Version 15からVersion 16に更新されてます」
PC：「差分を適用」

4. 手動更新
管理者：「今すぐ適用したい」
gpupdate /force

ポリシーの優先順位を理解しましょう。

【LSDOU順序】
新人：「複数のポリシーがある場合は？」
IT管理者：「LSDOUの順序で適用されます」

L - Local（ローカル）
S - Site（サイト）  
D - Domain（ドメイン）
OU - Organizational Unit（組織単位）

例：
1. ローカルポリシー：「壁紙は青」
2. ドメインポリシー：「壁紙は緑」
3. 営業部OU：「壁紙は赤」

結果：赤（最後に適用されたOUが勝つ）

実際のポリシー例を見てみましょう。

【よく使うポリシー】
IT管理者：「実際の設定例を見てみましょう」

1. パスワードポリシー
場所：コンピューターの構成 → Windows の設定 → 
      セキュリティの設定 → アカウントポリシー
設定：
- パスワードの長さ：8文字以上
- 複雑さの要件：有効
- 履歴：24世代

2. スクリーンセーバー
場所：ユーザーの構成 → 管理用テンプレート → 
      コントロールパネル → 個人用設定
設定：
- スクリーンセーバーを有効にする
- タイムアウト：600秒（10分）
- パスワードで保護する

3. Windows Update
場所：コンピューターの構成 → 管理用テンプレート → 
      Windows コンポーネント → Windows Update
設定：
- 自動更新を構成する：4-自動ダウンロードしインストール
- インストール日：0-毎日
- インストール時刻：03:00

ポリシー適用の確認方法を見てみましょう。

【適用状況の確認】
# 適用されているポリシーの確認
gpresult /r

コンピューターの設定
適用されたグループポリシーオブジェクト：
    Default Domain Policy
    営業部コンピューターポリシー

ユーザーの設定
適用されたグループポリシーオブジェクト：
    Default Domain Policy
    営業部ユーザーポリシー

# より詳細なレポート（HTML形式）
gpresult /h c:\temp\gpreport.html

ポリシーのトラブルシューティングを行います。

【ポリシーが適用されない時】
ユーザー：「他の人のPCは設定変わったのに、私のは変わらない」

確認手順：
1. 手動更新
   gpupdate /force

2. イベントログ確認
   イベントビューアー → アプリケーションとサービスログ →
   Microsoft → Windows → GroupPolicy

3. DCとの通信確認
   nltest /dsgetdc:jp.qualiteg.com

4. ポリシーの継承確認
   - OU構造での位置
   - 継承のブロック設定
   - WMIフィルター

よくある原因：
- 「このポリシーを無効にする」が設定されている
- WMIフィルターで対象外
- 継承がブロックされている
- まだレプリケーションされていない

これらの仕組みにより、ドメイン参加したコンピューターは、組織のポリシーに従って自動的に管理されるようになります。

素晴らしい第3回の記事ですね！Active Directoryのドメイン参加について、初心者にも分かりやすく解説されています。以下、まとめと次回予告を作成しました。

今回のまとめ

第3回では、Active Directoryの核心となる「ドメイン参加」について詳しく解説しました。

ドメイン参加は単に「ネットワークに接続する」だけではなく、コンピューターとドメインコントローラーの間に「信頼関係」を確立する重要なプロセスです。ユーザーアカウントだけでなく、コンピューター自体もアカウントとして管理され、120文字もの複雑なパスワードで自動的に認証が行われていることを学びました。

Windows PCやサーバーだけでなく、LinuxサーバーもSambaを使用してADドメインに参加できることで、異種混在環境でも統一的な認証基盤を構築できます。また、ドメイン参加後はグループポリシーによって組織全体のセキュリティポリシーを一括適用できるようになり、管理の効率化とセキュリティの向上を同時に実現できることを理解いただけたかと思います。

トラブルシューティングでは、DNS設定の重要性、時刻同期の必要性、信頼関係の維持など、実際の運用で遭遇する問題と解決方法も押さえました。これらの知識があれば、ドメイン参加に関する多くの問題に対処できるようになるでしょう。

次回予告：第4章 プロキシサーバーと統合Windows認証

次回は、いよいよ企業ネットワークの要となる「プロキシサーバーと統合Windows認証」について解説します！

多くの企業では、セキュリティとアクセス制御のためにプロキシサーバーを導入しています。しかし、「プロキシ経由だと毎回パスワードを聞かれる」「特定のアプリケーションが認証できない」といった問題に悩まされることも多いのではないでしょうか。

第4回では、SquidやIISを使用したプロキシサーバーの構築から、Active Directoryと連携した統合Windows認証（IWA）の実装まで、実践的な内容を分かりやすく解説します。Kerberos認証とNTLM認証がプロキシ環境でどのように動作するか、なぜ「シングルサインオン」が実現できるのか、その仕組みを理解することで、より安全で使いやすい企業ネットワークを構築できるようになります。

特に、AIセキュリティツールやクラウドサービスとの連携において、プロキシ認証は避けて通れない重要な要素です。次回も具体的な設定例と豊富な図解で、複雑な認証の仕組みを分かりやすくお伝えします。

それでは、第4回でお会いしましょう！