¶ 🔐 Active Directory 認証確認
¶ 🧭 このページについて
本ページでは、Active Directory 環境における認証状態を確認する手順を整理する。
Active Directory の障害は、最終的に「ログオンできない」「共有にアクセスできない」「グループポリシー（GPO）が適用されない」といった形で利用者に影響として現れる。
Active Directory の認証は、以下の複数の仕組みによって成立している。
- DNS（名前解決）
- レプリケーション（アカウント情報の同期）
- SYSVOL（GPO 配布用の共有領域）
- 時刻同期（Kerberos 認証の前提条件）
これらのいずれかに問題がある場合、認証は正常に動作しない。
そのため本手順では、単一のコマンド結果だけで判断するのではなく、
クライアント視点で段階的に確認を行い、認証が正常に成立しているかを総合的に判断する。
¶ 🖥 対象サーバー（仮称）
| 項目 | 内容 |
|---|---|
| ドメイン名 | example.com |
| ドメインコントローラー | DC01（PDC エミュレーター） |
| ドメインコントローラー | DC02（追加ドメインコントローラー） |
| クライアント | CLIENTPC |
※本ページでは説明のため仮称を使用している
※実環境ではドメイン名およびサーバー名を適宜読み替えること
¶ 🎯 確認対象
| 対象 | 実施理由 |
|---|---|
| クライアントPC | 実際のログオン結果（最終結果）を確認するため |
| ドメインコントローラー | 認証基盤の異常切り分けのため |
※基本はクライアントPCで実施する
¶ 🔍 確認方針
Active Directory の認証は、複数の要素が連携することで成立している。
そのため、ログオンの成否だけで判断するのではなく、
以下の観点を段階的に確認することが重要である。
- 認証チケット（Kerberos）が正常に取得できているか
- どのドメインコントローラーで認証されているか
- クライアントとドメインの信頼関係が維持されているか
- ドメインコントローラーが正常に検出されるか
- 認証結果として GPO が適用されているか
- Kerberos の前提となる時刻同期が正常か
これらを総合的に確認することで、
認証基盤全体の状態を正確に把握できる。
¶ 1️⃣ Kerberos チケット確認
¶ 🖥 CLIENTPC
¶ 【目的】
クライアントに Kerberos チケットが発行されているかを確認し、
ログオン認証および Active Directory との通信が正常に成立しているかを判断する。
¶ 【実行コマンド】
# Kerberos チケット一覧を確認（ログオン認証の成立を確認）
C:\Windows\System32\klist.exe
¶ 【結果】
PS C:\> C:\Windows\System32\klist.exe
キャッシュされたチケット: (複数)
#0> サーバー: krbtgt/EXAMPLE.COM
#1> サーバー: LDAP/DC01.example.com
¶ 【解説】
- klist コマンドは、クライアントが保持している Kerberos チケットを確認するためのコマンドである
- 「krbtgt」はログオン時に取得されるチケット（TGT：Ticket Granting Ticket）を示す
- 「LDAP」はドメインコントローラーとの通信時に使用されるサービスチケットを示す
Kerberos 認証では、ログオン時に TGT を取得し、その後アクセス先ごとにサービスチケットを取得する仕組みとなっている。
¶ 【判定】
正常
- krbtgt（TGT）が存在している
- LDAP などのサービスチケットが存在している
- ドメインコントローラー名（KDC）が確認できる
- チケットの有効期限が切れていない
¶ 【まとめ】
Kerberos チケットが正常に発行されており、
ログオン認証およびドメインコントローラーとの通信は正常に成立している。
この確認により、認証処理の初期段階（ログオン認証）が正常であることを判断できる。
¶ 2️⃣ ログオンサーバー確認
¶ 🖥 CLIENTPC
¶ 【目的】
どのドメインコントローラーで認証が実行されているかを確認し、認証経路が正常に機能しているかを判断する。
¶ 【実行コマンド】
# 現在のログオンで使用されたドメインコントローラーを確認（PowerShell）
$env:LOGONSERVER
# 現在のログオンで使用されたドメインコントローラーを確認（コマンドプロンプト）
echo %LOGONSERVER%
¶ 【結果】
[cmd]
C:\> echo %LOGONSERVER%
\\DC02
[PowerShell]
PS C:\> $env:LOGONSERVER
\\DC02
¶ 【解説】
- LOGONSERVER は、ログオン時に使用されたドメインコントローラー名を示す環境変数である
- クライアントはログオン時にいずれかのドメインコントローラーへ接続し、認証処理を実行している
この値を確認することで、実際にどのドメインコントローラーが使用されているかを把握できる。
¶ 【判定】
正常
- ドメインコントローラー名（例：\DC02）が取得できる
- 実在するドメインコントローラーである
- Kerberos 確認（klist）の結果と整合している
¶ 【まとめ】
ログオンに使用されたドメインコントローラーが正常に取得できており、認証処理は適切なドメインコントローラーを通じて実行されている。
この結果から、認証経路（クライアント → ドメインコントローラー）は正常であると判断できる。
¶ 2️⃣ ログオンサーバー確認
¶ 🖥 CLIENTPC
¶ 【目的】
どのドメインコントローラーで認証が実行されているかを確認し、
認証経路が正常に機能しているかを判断する。
¶ 【実行コマンド】
# 現在のログオンで使用されたドメインコントローラーを確認（PowerShell）
$env:LOGONSERVER
# 現在のログオンで使用されたドメインコントローラーを確認（コマンドプロンプト）
echo %LOGONSERVER%
¶ 【結果】
[cmd]
C:\> echo %LOGONSERVER%
\\DC02
[PowerShell]
PS C:\> $env:LOGONSERVER
\\DC02
¶ 【解説】
- LOGONSERVER は、ログオン時に使用されたドメインコントローラー名を示す環境変数である
- クライアントはログオン時にいずれかのドメインコントローラーへ接続し、認証処理を実行している
この値を確認することで、実際にどのドメインコントローラーが認証に使用されたかを把握できる。
¶ 【確認ポイント】
- ドメインコントローラー名（例：\DC02）が表示される
- 実在するドメインコントローラーである
- Kerberos 確認（klist）の結果と整合している
¶ 【判定】
正常
- ドメインコントローラー名が取得できる
- klist の結果と一致している場合、認証経路は正常
- 想定外のドメインコントローラーが表示される場合は、DNS / サイト設定 / 負荷分散の影響を考慮する
¶ 【まとめ】
ログオンに使用されたドメインコントローラーが正常に取得できており、認証処理は適切なドメインコントローラーを通じて実行されている。
この結果から、認証経路（クライアント → ドメインコントローラー）は正常であると判断できる。
¶ 3️⃣ セキュアチャネル確認
¶ 🖥 CLIENTPC
¶ 【目的】
クライアントとドメイン間のセキュアチャネル（信頼関係）が正常に維持されているかを確認する。
セキュアチャネルは、クライアントがドメインに参加し続けるために必要な通信経路であり、異常がある場合はログオン不可や認証エラーの原因となる。
¶ 【実行コマンド】
# セキュアチャネル（ドメインとの信頼関係）を確認
C:\Windows\System32\nltest.exe /sc_verify:example.com
¶ 【結果】
PS C:\> C:\Windows\System32\nltest.exe /sc_verify:example.com
信頼された DC 名 \\DC02.example.com
信頼された DC 接続状態 Status = 0 0x0 NERR_Success
信頼の確認 Status = 0 0x0 NERR_Success
コマンドは正常に完了しました
¶ 【解説】
- nltest /sc_verify は、クライアントとドメイン間の信頼関係（セキュアチャネル）を検証するコマンドである
- 「信頼された DC 名」は接続先のドメインコントローラーを示す
- Status = 0（NERR_Success）は正常に通信および認証が行われていることを意味する
この確認により、クライアントがドメインに正常に参加しているか、およびドメインコントローラーとの通信が正常であるかを判断できる。
¶ 【判定】
正常
- 接続先ドメインコントローラーが表示される
- Status = 0（NERR_Success）が表示される
- コマンドが正常に完了する
¶ 【まとめ】
クライアントとドメイン間のセキュアチャネル（信頼関係）は正常に維持されている。
この結果から、ドメイン参加状態および認証基盤との通信は正常であると判断できる。
¶ 4️⃣ DC 検出確認
¶ 🖥 SV-RDS
¶ 【目的】
クライアントが利用可能なドメインコントローラーを正常に検出できるかを確認し、認証先の探索処理（DCロケータ）が正常に動作しているかを判断する。
DC検出は DNS（SRVレコード）に依存するため、ここで異常がある場合は DNS またはドメインコントローラーの障害が疑われる。
¶ 【実行コマンド】
# 利用可能なドメインコントローラーを検出
C:\Windows\System32\nltest.exe /dsgetdc:example.com
¶ 【結果】
PS C:\> C:\Windows\System32\nltest.exe /dsgetdc:example.com
DC: \\DC02.example.com
アドレス: \\192.168.1.10
ドメイン GUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ドメイン名: example.com
フォレスト名: example.com
DC サイト名: Default-First-Site-Name
本サイト名: Default-First-Site-Name
フラグ: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST
コマンドは正常に完了しました
¶ 【解説】
- nltest /dsgetdc は、クライアントが利用可能なドメインコントローラーを検索するコマンドである
- 検出処理は DNS の SRV レコードを基に実行され、最適なドメインコントローラーが自動的に選択される
本結果では、ドメインコントローラー（例：DC02）が選択されており、IPアドレスやドメイン名、サイト名が正常に取得できている。
また、「コマンドは正常に完了しました」と表示されていることから、DC検出処理は正常に完了していると判断できる。
¶ 【判定】
正常
- ドメインコントローラー名が取得できている
- IPアドレスが取得できている
- ドメイン名およびフォレスト名が正しい
- コマンドが正常に終了している
- サイト名が想定通りである
¶ 【まとめ】
クライアントは利用可能なドメインコントローラーを正常に検出できている。
本結果より、DNS（SRVレコード）および DCロケータの動作は正常であり、認証先の探索処理に問題はないと判断できる。
¶ 5️⃣ GPO 適用確認
¶ 🖥 CLIENTPC
¶ 【目的】
認証結果としてグループポリシー（GPO）が正しく適用されているかを確認し、
Active Directory 全体の動作が正常であるかを最終的に判断する。
GPO の適用結果は、認証・SYSVOL・レプリケーションの状態を総合的に反映するため、
最終的な確認ポイントとなる。
¶ 【実行コマンド】
# クライアントに適用されたグループポリシーを確認
C:\Windows\System32\gpresult.exe /r
¶ 【結果】
PS C:\> C:\Windows\System32\gpresult.exe /r
コンピューター設定
-------------------
グループ ポリシーの適用元: DC02.example.com
適用されたグループ ポリシー オブジェクト
-----------------------------------------
Default Domain Policy
SEC_C_Domain_AccountPolicy
（その他の GPO が表示される）
ユーザー設定
-------------
適用されたグループ ポリシー オブジェクト
-----------------------------------------
（適用された GPO が表示される）
¶ 【解説】
- gpresult /r は、クライアントに適用されたグループポリシーの結果を表示するコマンドである
- 「グループ ポリシーの適用元」は、ポリシー適用処理を行ったドメインコントローラーを示す
- 「適用されたグループ ポリシー オブジェクト」は、実際に適用された設定の一覧である
この結果により、認証後の処理が正常に完了しているかを確認できる。
¶ 【判定】
正常
- グループ ポリシーの適用元（ドメインコントローラー）が表示される
- 適用された GPO が一覧表示される
- 想定した GPO が含まれている
- エラーが表示されていない
¶ 【補足】
「次の GPO はフィルターで除外されたため適用されませんでした」と表示される場合がある。
これは、セキュリティグループや WMI フィルターによる制御であり、意図した設定であれば正常な動作である。
👉 除外された GPO は「設計通りの動作かどうか」で判断する
¶ 【まとめ】
クライアントに対して GPO が正常に適用されており、適用元ドメインコントローラーも正しく取得できている。
この結果から、認証処理・SYSVOL・レプリケーションを含めた Active Directory 全体の動作は正常であると判断できる。
¶ 6️⃣ 時刻同期確認
¶ 🖥 CLIENTPC / ドメインコントローラー
¶ 【目的】
Kerberos 認証に必要な時刻同期が正常に行われているかを確認する。
Kerberos は時刻差に厳しく、クライアントとドメインコントローラー間で時刻がずれている場合、認証エラーの原因となる。
¶ 【実行コマンド】
# 時刻同期状態を確認
C:\Windows\System32\w32tm.exe /query /status
¶ 【結果】
PS C:\> C:\Windows\System32\w32tm.exe /query /status
ソース: DC02.example.com
最終正常同期時刻: （時刻が表示される）
階層: （表示される）
¶ 【解説】
- w32tm /query /status は、時刻同期の状態を確認するコマンドである
- 「ソース」は現在参照している時刻同期先（NTPサーバーまたはドメインコントローラー）を示す
Active Directory 環境では、クライアントは通常ドメインコントローラーと時刻同期を行う。
この結果により、Kerberos 認証の前提条件である時刻同期の状態を確認できる。
¶ 【判定】
正常
- 同期元（ソース）がドメインコントローラーである
- 最終正常同期時刻が更新されている
- エラーが表示されていない
¶ 【まとめ】
クライアントおよびドメインコントローラー間で時刻同期は正常に行われている。
この結果から、Kerberos 認証の前提条件である時刻同期は満たされており、認証基盤に問題はないと判断できる。
¶ 🔍 切り分けの流れ
以下は、ログオン不可などの障害が発生した場合の基本的な切り分けの流れである。
¶ 7️⃣ 最終確認
¶ 🧭 確認内容
本手順で実施した各確認結果をもとに、
Active Directory の認証状態を総合的に評価する。
本ページでは、以下の観点から認証の状態を確認している。
- Kerberos チケットの取得状態
- ログオンに使用されたドメインコントローラー
- セキュアチャネル（信頼関係）の状態
- ドメインコントローラーの検出可否
- グループポリシー（GPO）の適用状態
- 時刻同期の状態
¶ 【判定】
本手順において、すべての確認項目が正常であることを確認した。
- Kerberos チケット（TGT / サービスチケット）が正常に取得されている
- ログオンに使用されたドメインコントローラーが取得できている
- セキュアチャネル（信頼関係）が正常に維持されている
- ドメインコントローラーが正常に検出されている
- GPO が正常に適用されている
- 時刻同期が正常に行われている
以上より、Active Directory における認証処理は正常に動作していると判断できる。
¶ 【解説】
本確認では、認証の成否を単一のコマンド結果で判断するのではなく、複数の観点から段階的に状態を確認している。
まず、Kerberos チケットの取得状況を確認することで、ログオン認証が正常に成立しているかを把握する。
そのうえで、ログオンサーバーおよびセキュアチャネルの確認を行い、どのドメインコントローラーが使用されているか、またクライアントとドメイン間の信頼関係が正常に維持されているかを確認する。
さらに、DC 検出確認により、DNS（SRVレコード）を含めたドメインコントローラーの探索処理が正常に機能しているかを確認し、認証先の選択に問題がないことを確認している。
最後に、GPO 適用確認および時刻同期確認を通じて、認証後の処理が正常に完了していること、ならびに Kerberos 認証の前提条件が満たされていることを確認する。
これらの確認結果に一貫性があることから、認証基盤は正常に動作している状態であると判断できる。
¶ 【まとめ】
本手順により、Active Directory の認証状態を段階的に確認し、認証・通信・信頼関係・GPO・時刻のすべての観点で問題がないことを確認した。
特に、Kerberos チケットおよび GPO 適用の確認により、認証処理が実際に機能していることを確認できている点が重要である。
以上より、本環境の Active Directory は正常に運用可能な状態である。