大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第6回 よくある問題と解決方法
こんにちは、今回はシリーズ第6回トラブルシューティング - よくある問題と解決方法 について解説いたします！
さて、前回（第5回）は、統合Windows認証がブラウザでどのように動作するかを解説しました。
「イントラネットゾーン」という概念を理解することで、同じサーバーでもURLの書き方（NetBIOS名、FQDN、IPアドレス）によって認証動作が変わる理由が明確になったかと思います。また、Chrome/Firefoxではデフォルトで統合認証が無効になっている理由と、グループポリシーによる一括設定方法も学びました。
しかし、設定が完璧なはずなのに「なぜかうまく動かない」という場面は、実際の現場では必ず訪れます。
「最近、ファイルサーバーへのアクセスが遅い」「金曜日は使えたのに、月曜日の朝にログインできない」「特定のサービスだけKerberosが失敗する」——これらはヘルプデスクに日々寄せられる典型的な問い合わせです。
原因はKerberosの失敗、時刻のずれ、SPNの設定ミス、DNS関連の問題など多岐にわたりますが、体系的にトラブルシューティングすることで必ず解決できます。
今回は、AD環境で頻繁に起きるトラブルをパターン別に整理し、診断コマンドを使った原因特定から具体的な解決手順まで、実践的なトラブルシューティングの流れを解説します。焦らず、一つずつ確認していくことが解決への近道です。それでは始めていきましょう！
連載の構成
- 第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎
- 第2章：ドメイン環境の構築 - 検証環境の構築手順
- 第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順
- 第4章：プロキシサーバーと統合Windows認証
- 第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法
- 【★今回です★】第6章：トラブルシューティング - よくある問題と解決方法
- 第7章：セキュリティとベストプラクティス - 本番環境での考慮事項
- 第8章：実践的な構成例 - AIセキュリティツールとの統合事例
第6章：トラブルシューティング
6.1 認証関連のトラブル
6.1.1 Kerberosが失敗してNTLMにフォールバックする原因
Kerberosは最も安全な認証方式ですが、様々な理由で失敗し、NTLMにフォールバックすることがあります。これは、パフォーマンス低下の原因にもなります。
【典型的な症状】
ユーザー：「最近、ファイルサーバーへのアクセスが遅いんです」
IT管理者：「ログを確認してみましょう」
イベントログ：
Kerberos認証に失敗しました。
NTLMにフォールバックします。
IT管理者：「Kerberosが失敗してますね。原因を調べましょう」
診断コマンドの実行を見てみましょう。
【Kerberos診断】
# 現在のチケット確認
klist
結果（正常な場合）：
キャッシュされたチケット: 2
#0> クライアント: tanaka_t @ JP.QUALITEG.COM
サーバー: krbtgt/JP.QUALITEG.COM @ JP.QUALITEG.COM
暗号化の種類: AES-256-CTS-HMAC-SHA1-96
チケットの有効期限: 2024/01/20 18:00:00
結果（問題がある場合）：
キャッシュされたチケット: 0
→ チケットが取得できていない
# チケット取得のテスト
kinit tanaka_t@JP.QUALITEG.COM
よくある原因1：DNS関連の問題を見てみましょう。
【DNSが原因の場合】
状況：NetBIOS名では動くが、FQDNでは失敗
テスト：
# NetBIOS名
ping fileserver → 成功
アクセス: \\fileserver\share → 成功（NTLM）
# FQDN
ping fileserver.jp.qualiteg.com → 成功
アクセス: \\fileserver.jp.qualiteg.com\share → 遅い（Kerberos失敗→NTLM）
原因調査：
nslookup fileserver.jp.qualiteg.com
→ 正引きOK
nslookup 192.168.1.50
→ 逆引きNG！
IT管理者：「逆引きDNSレコードが missing です」
解決策：
DNSマネージャーで逆引きゾーンにPTRレコード追加
50.1.168.192.in-addr.arpa. → fileserver.jp.qualiteg.com.
よくある原因2：SPN（Service Principal Name）の問題を見てみましょう。
【SPNが原因の場合】
症状：特定のサービスだけKerberosが失敗
確認コマンド：
setspn -L fileserver
結果（問題なし）：
登録されたSPN:
HOST/fileserver
HOST/fileserver.jp.qualiteg.com
結果（問題あり）：
登録されたSPN:
（空）
または重複エラー：
setspn -X
重複したSPNが見つかりました：
HTTP/intranet.jp.qualiteg.com
→ サーバーAとサーバーBの両方に登録
解決策：
# SPN追加
setspn -A HOST/fileserver.jp.qualiteg.com FILESERVER$
# 重複削除
setspn -D HTTP/intranet.jp.qualiteg.com サーバーB
暗号化方式の不一致も見てみましょう。
【暗号化の非互換性】
Windows Server 2019管理者：「新しいDCを追加したら認証が遅くなった」
調査：
# サポートされる暗号化方式の確認
グループポリシー：
ネットワークセキュリティ: Kerberos で許可された暗号化方式の構成
古いサーバー：RC4-HMAC（非推奨）
新しいサーバー：AES256-CTS-HMAC-SHA1-96
問題：
古いアプリ：「RC4しか話せません」
新DC：「RC4は無効化されています」
結果：Kerberos失敗
解決策：
1. 一時的にRC4を有効化（セキュリティリスクあり）
2. アプリケーションのアップデート（推奨）
6.1.2 時刻同期の重要性
Kerberos認証において、時刻同期は極めて重要です。5分以上のずれがあると認証が失敗します。
【時刻ずれによる認証失敗】
月曜日の朝：
田中：「金曜日は使えたのに、ログインできません！」
エラー：「現在、ログオン要求を処理できるログオンサーバーはありません」
IT管理者：「時刻を確認してみましょう」
クライアントPC：2024/01/20 09:00:00
DC：2024/01/20 09:07:00
差：7分
IT管理者：「5分以上ずれてます。これが原因です」
時刻同期の仕組みを理解しましょう。
【Windows時刻同期の階層】
正しい構成：
インターネット時刻サーバー（time.windows.com）
↓
PDCエミュレーター（DC01）
↓
その他のDC（DC02, DC03）
↓
メンバーサーバー、クライアントPC
確認コマンド：
# 時刻源の確認
w32tm /query /source
正常：DC01.jp.qualiteg.com
問題：Local CMOS Clock → 同期していない
# 詳細状態
w32tm /query /status
時刻同期の修正方法を見てみましょう。
【時刻同期の設定】
PDCエミュレーターでの設定：
# 外部時刻源の設定
w32tm /config /manualpeerlist:"time.windows.com,0x9 ntp.nict.jp,0x9" /syncfromflags:manual /reliable:yes /update
# サービス再起動
net stop w32time && net start w32time
# 即座に同期
w32tm /resync /rediscover
その他のDCでの設定：
# PDCエミュレーターから同期
w32tm /config /syncfromflags:domhier /update
クライアントPCでの設定：
# 通常は自動だが、手動設定も可能
w32tm /config /syncfromflags:domhier /update
時刻同期のトラブルシューティングを行いましょう。
【よくある時刻同期の問題】
問題1：ファイアウォールでNTPがブロック
症状：
w32tm /stripchart /computer:time.windows.com
エラー: 0x800705B4 - タイムアウト
解決：
UDP 123番ポートを開放
問題2：仮想マシンの時刻同期競合
症状：
VM：「ホストと同期します」
DC：「いや、NTPと同期して」
結果：時刻が安定しない
解決：
VMware: VMware Toolsの時刻同期を無効化
Hyper-V: 統合サービスの時刻同期を無効化
問題3：大幅な時刻ずれ
症状：
w32tm /resync
コンピューターの再同期コマンドがコンピューターに送信されましたが、
時刻データが利用できなかったためにエラーが発生しました。
原因：差が大きすぎて自動修正を拒否（通常48時間以上）
解決：
# 手動で近い時刻に設定してから同期
net time \\DC01 /set /y
6.1.3 SPN（Service Principal Name）の設定
SPNは、Kerberos認証でサービスを一意に識別するための名前です。正しく設定されていないと、Kerberos認証が失敗します。
【SPNとは何か】
新人：「SPNって何ですか？」
IT管理者：「サービスの住所みたいなものです」
例えで説明：
田中さんの自宅 = HOST/tanaka-pc.jp.qualiteg.com
場所：tanaka-pc.jp.qualiteg.com
用途：HOST（コンピューター）
会社のWebサーバー = HTTP/intranet.jp.qualiteg.com
場所：intranet.jp.qualiteg.com
用途：HTTP（Webサービス）
Kerberos：「HTTP/intranet.jp.qualiteg.comへのチケットをください」
KDC：「SPNを検索...見つかった！チケット発行」
SPNの確認と登録を行いましょう。
【SPNの管理】
# 特定のアカウントのSPN確認
setspn -L IIS_Service
# コンピューターアカウントのSPN確認
setspn -L SERVER01$
典型的なSPN：
HOST/server01
HOST/server01.jp.qualiteg.com
TERMSRV/server01
TERMSRV/server01.jp.qualiteg.com
RestrictedKrbHost/server01
RestrictedKrbHost/server01.jp.qualiteg.com
# IISサーバーのSPN登録例
# アプリケーションプールが特定のアカウントで実行される場合
setspn -A HTTP/webapp.jp.qualiteg.com JP\webapp_svc
setspn -A HTTP/webapp JP\webapp_svc
SPN関連のトラブルを見てみましょう。
【重複SPNの問題】
症状：Webサイトにアクセスすると認証エラー
調査：
setspn -X
処理中...
重複が見つかりました：
HTTP/intranet.jp.qualiteg.com が以下に登録:
- SERVER01$
- intranet_svc
IT管理者：「同じSPNが2つのアカウントに！」
理由：
1. 最初、SERVER01のコンピューターアカウントで動いていた
2. 後でサービスアカウント（intranet_svc）に変更
3. 古いSPNを削除し忘れ
解決：
setspn -D HTTP/intranet.jp.qualiteg.com SERVER01$
→ 古い方を削除
アプリケーションプールとSPNの関係を見てみましょう。
【IISでの実例】
シナリオ：社内ポータルサイトの構築
構成：
- URL: http://portal.jp.qualiteg.com
- アプリケーションプール: PortalAppPool
- 実行アカウント: JP\portal_svc
必要な作業：
1. サービスアカウント作成
New-ADUser -Name "portal_svc" -AccountPassword (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force) -Enabled $true
2. SPN登録
setspn -A HTTP/portal.jp.qualiteg.com JP\portal_svc
setspn -A HTTP/portal JP\portal_svc
3. IISでの設定
- アプリケーションプール → 詳細設定 → ID → portal_svc
- 認証 → Windows認証：有効、匿名認証：無効
4. 確認
setspn -L portal_svc
→ SPNが表示されることを確認
6.1.4 DNS関連の問題
DNS設定の問題は、AD環境でのトラブルの大半を占めます。正しく設定されていないと、認証以前に名前解決で失敗します。
【典型的なDNS問題】
ユーザー：「ファイルサーバーにつながりません」
IT：「pingしてみてください」
ユーザー：「ping fileserver」
結果：ping 要求ではホスト fileserver が見つかりませんでした
IT：「DNSサフィックスを確認しましょう」
ipconfig /all
DNSサフィックス: （空）← 問題！
DNSサフィックスの設定を見てみましょう。
【DNSサフィックスの重要性】
正しい設定：
プライマリDNSサフィックス: jp.qualiteg.com
DNS サフィックス検索一覧: jp.qualiteg.com, tokyo.jp.qualiteg.com
動作の違い：
# サフィックスなし
ping fileserver
→ 「fileserver」を探す → 失敗
# サフィックスあり
ping fileserver
→ 「fileserver.jp.qualiteg.com」を探す → 成功
設定方法：
1. DHCP経由（推奨）
Option 015: jp.qualiteg.com
2. 手動設定
ネットワークアダプター → プロパティ → 詳細設定 → DNS
「この接続のDNSサフィックス」: jp.qualiteg.com
DNSの正引き・逆引き問題を見てみましょう。
【逆引きDNSの重要性】
問題の症状：
- 名前でアクセス: 成功
- IPでアクセス: 認証に時間がかかる
調査：
# 正引きテスト
nslookup server01.jp.qualiteg.com
→ 192.168.1.20
# 逆引きテスト
nslookup 192.168.1.20
→ *** dns1.jp.qualiteg.com can't find 192.168.1.20: Non-existent domain
原因：逆引きゾーンがないか、レコードがない
解決策：
1. DNS管理ツールで逆引きゾーン作成
- 新しいゾーン → 逆引き参照ゾーン
- ネットワークID: 192.168.1
2. PTRレコード追加
- 20 → server01.jp.qualiteg.com.
DNSキャッシュの問題を見てみましょう。
【古いDNS情報によるトラブル】
状況：サーバーのIPアドレスを変更した後
ユーザー：「新しいサーバーにつながらない」
IT：「DNS確認してみましょう」
# DNSサーバーに問い合わせ
nslookup server01.jp.qualiteg.com 192.168.1.10
→ 192.168.1.50（新IP）
# でもpingは古いIPに
ping server01.jp.qualiteg.com
→ 192.168.1.20（旧IP）に ping しています
原因：ローカルDNSキャッシュ
解決：
ipconfig /flushdns
→ DNSキャッシュをクリア
確認：
ipconfig /displaydns
→ キャッシュ内容を表示
条件付きフォワーダーの設定を見てみましょう。
【複数ドメイン環境でのDNS】
シナリオ：会社買収で別ドメインと連携
環境：
- 自社: jp.qualiteg.com（192.168.1.0/24）
- 買収先: acquired.local（192.168.2.0/24）
問題：
nslookup server.acquired.local
→ 見つからない
解決策：条件付きフォワーダー
DNSマネージャー → 条件付きフォワーダー → 新規
- DNSドメイン: acquired.local
- IPアドレス: 192.168.2.10（買収先のDNS）
結果：
acquired.localへの問い合わせは192.168.2.10に転送
6.2 ドメイン参加のトラブル
6.2.1 「ドメインが見つからない」エラー
ドメイン参加時の最も一般的なエラーです。原因は多岐にわたりますが、体系的にトラブルシューティングすることで解決できます。
【典型的なエラーメッセージ】
エラー：
「ドメイン "jp.qualiteg.com" に接続できませんでした。
（ドメインが存在しないか、またはアクセスできません）」
新人IT：「ドメイン名は合ってるのに...」
先輩：「順番に確認していきましょう」
ステップ1：ネットワーク接続の確認を行いましょう。
【基本的な接続確認】
# IPアドレスの確認
ipconfig /all
確認ポイント：
- IPアドレス: 169.254.x.x → DHCPサーバーに届いていない
- IPアドレス: 192.168.1.x → 正常
- DNSサーバー: 192.168.1.1 → ルーターを見ている（NG）
- DNSサーバー: 192.168.1.10 → DCを見ている（OK）
# DCへの疎通確認
ping 192.168.1.10
→ 応答があることを確認
ステップ2：DNS名前解決の確認を行いましょう。
【DNS解決のテスト】
# ドメイン名の解決
nslookup jp.qualiteg.com
正常な応答：
Server: dc01.jp.qualiteg.com
Address: 192.168.1.10
Name: jp.qualiteg.com
Addresses: 192.168.1.10, 192.168.1.11
問題のある応答：
*** dc01.jp.qualiteg.com can't find jp.qualiteg.com: Non-existent domain
# SRVレコードの確認（重要）
nslookup -type=srv _ldap._tcp.jp.qualiteg.com
正常な応答：
_ldap._tcp.jp.qualiteg.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc01.jp.qualiteg.com
ステップ3：ファイアウォールの確認を行いましょう。
【必要なポートの確認】
# PowerShellでポート確認
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 389
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 445
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 88
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 135
必要なポート：
- 88 (Kerberos)
- 135 (RPC Endpoint Mapper)
- 389 (LDAP)
- 445 (SMB)
- 636 (LDAPS)
- 3268 (Global Catalog)
Windowsファイアウォールの一時無効化（テスト用）：
netsh advfirewall set allprofiles state off
※テスト後は必ず有効に戻す
6.2.2 認証エラーの対処法
ドメインは見つかるが、認証で失敗するケースの対処法です。
【認証エラーの種類】
エラー1：
「ログオンに失敗しました: ユーザー名を認識できないか、
またはパスワードが間違っています。」
エラー2：
「指定されたドメインがないか、またはコンタクトできません。」
エラー3：
「現在、ログオン要求を処理できるログオンサーバーはありません。」
ユーザー名の形式問題を見てみましょう。
【正しいユーザー名の形式】
よくある間違い：
× administrator（ドメイン指定なし）
× tanaka_t（一般ユーザー）
× admin（存在しないユーザー）
正しい形式：
○ JP\Administrator
○ Administrator@jp.qualiteg.com
○ jp.qualiteg.com\Administrator
# 現在のドメイン管理者の確認
net group "Domain Admins" /domain
アカウントの状態確認を行いましょう。
【管理者アカウントの問題】
# DCで実行（アカウント状態確認）
net user Administrator /domain
確認ポイント：
- アカウント有効: Yes
- アカウントの有効期限: 無期限
- パスワード有効期限: 無期限
- アカウントロックアウト: No
# ロックアウトされている場合
net user Administrator /active:yes /domain
# パスワードリセット（最終手段）
net user Administrator NewP@ssw0rd /domain
ドメイン参加に使用できるアカウントを確認しましょう。
【権限の確認】
# Domain Adminsグループのメンバー確認
net group "Domain Admins" /domain
# 他に使えるグループ
- Domain Admins（全権限）
- Enterprise Admins（フォレスト全体）
- Account Operators（限定的な権限）
# 委任された権限の確認
dsacls "OU=Computers,DC=jp,DC=qualiteg,DC=com"
→ コンピューターオブジェクト作成権限を確認
6.2.3 ネットワーク設定の確認ポイント
ドメイン参加の成功には、正しいネットワーク設定が不可欠です。
【チェックリスト形式での確認】
IT管理者：「この順番で確認していけば、問題を特定できます」
□ 1. 物理接続
- LANケーブル接続
- リンクランプ点灯
- 正しいVLAN
□ 2. IPアドレス設定
- 固定 or DHCP
- 同一サブネット内
- 重複なし
□ 3. DNS設定
- プライマリDNS = DC
- セカンダリDNS = 別DC（あれば）
- DNSサフィックス設定
□ 4. 疎通確認
- DC へping
- ポート確認
- 名前解決確認
VLANをまたぐ場合の注意点を見てみましょう。
【VLAN環境での考慮事項】
構成例：
- VLAN 10: サーバーセグメント（192.168.10.0/24）
- DC: 192.168.10.10
- VLAN 20: クライアントセグメント（192.168.20.0/24）
- Client: 192.168.20.100
必要な設定：
1. ルーティング
- VLAN間ルーティング有効
- 各VLANのデフォルトゲートウェイ設定
2. ファイアウォール
- VLAN間で必要なポート許可
- 特に135, 445, 389等
3. DNS設定
- クライアントのDNS: 192.168.10.10
- DNSがVLAN越えで到達可能
確認コマンド：
tracert 192.168.10.10
→ 経路確認
プロキシ設定の影響を見てみましょう。
【プロキシが邪魔をするケース】
症状：ブラウザは使えるが、ドメイン参加できない
原因：システムプロキシの設定
確認：
netsh winhttp show proxy
現在の WinHTTP プロキシ設定:
プロキシサーバー: proxy:8080
バイパス一覧: （なし）
問題：DCへの通信もプロキシ経由しようとする
解決策：
netsh winhttp set proxy proxy:8080 bypass-list="*.jp.qualiteg.com;192.168.*"
または完全リセット：
netsh winhttp reset proxy
IPv6の影響を見てみましょう。
【IPv6関連の問題】
症状：名前解決が遅い、不安定
確認：
ipconfig /all
IPv6アドレス: 2001:db8::1234（有効）
IPv4アドレス: 192.168.1.100
問題：IPv6が優先されるが、DCはIPv4のみ
解決策1：IPv6を無効化（一時的）
ネットワークアダプター → プロパティ
□ インターネットプロトコルバージョン6（チェックを外す）
解決策2：IPv4を優先（推奨）
netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 46 4
→ IPv4を優先するポリシー
これらの確認ポイントを順に確認することで、ほとんどのドメイン参加問題を解決できます。重要なのは、あわてずに一つずつ確認していくことです。
次回予告
次回は「第7章 セキュリティとベストプラクティス - 本番環境での考慮事項」
灰、上記タイトルのとおり次回は、「動く」環境を「安全に動く」環境にするための話です。
システムが正常に動作することと、安全に運用されることは別の問題です。認証基盤を本番環境に展開するからこそ、セキュリティの考慮が欠かせません。「Basic認証のパスワードは実はネットワーク上で丸見えになっている」「Domain Adminsに50人も登録されている」「退職者のアカウントがそのまま残っている」——こうした問題は、気づいた時には手遅れになっていることもあります。
次回は、Basic認証が抱える根本的なリスク、パスワード管理・管理者権限の最小化といったベストプラクティス、そして監視・ログ・定期監査の具体的な実装方法まで、本番運用を見据えたセキュリティの全体像をお届けします。
それでは、第7回でお会いしましょう！
