EventID 40960（Kerberos 0x80090311）「No authority could be contacted for authentication」の原因と対策｜SonicWALLでGPO・NETLOGON/SYSVOLが失敗する

Windows 10 クライアントで EventID 40960（LSASRV）「No authority could be contacted for authentication / 0x80090311」が大量発生し、ログオンはできるのに GPO や共有アクセスだけ失敗する――。AD や DNS は正常に見えるのに Kerberos だけが壊れるとき、盲点になりやすい“拠点間ファイアウォール”の落とし穴と、再現性の高い切り分け・恒久対策をまとめます。

現象：ログオンはできるのに共有・GPOだけ失敗する

複数拠点の Windows 10 クライアントで、次のような症状が同時に発生している場合、原因はクライアント設定（再参加や資格情報の削除）ではなく、拠点間のネットワーク経路に潜んでいることが少なくありません。

• 以前は拠点ごとにローカル DC があったが、撤去して本社サイト DC（Windows Server 2016 等）へ直接接続する構成になった
• クライアントのセキュリティイベントに LSASRV / EventID 40960 が大量出力される
• ドメインへのログオン自体は可能（ただし後述の注意点あり）
• ドライブ割り当て（共有）や GPO 適用が失敗する
• \\ドメイン名\NETLOGON / \\ドメイン名\SYSVOL にアクセスすると資格情報入力を求められ、正しい ID/パスワードでもアクセス拒否
• gpupdate /force で「ドメイン コントローラーへのネットワーク接続がないため…」などのエラー
• nltest /dclist:domain で SEC_E_DOWNGRADE_DETECTED (0x80090350) や ERROR_NO_BROWSER_SERVERS_FOUND (6118) が出ることがある

一方で、DC 側の dcdiag / repadmin は概ね正常、クライアントの DNS も AD DNS を参照しており nslookup や ping ドメイン名 は通る。つまり「名前解決はできるのに、Kerberos 認証だけが失敗する」という、切り分けが難しい状況に見えます。

EventID 40960 / 0x80090311 が示すもの

EventID 40960（LSASRV）に出る代表的なメッセージは次の形です。

The Security System detected an authentication error for the server cifs/xxxx.
The failure code from authentication protocol Kerberos was
“No authority could be contacted for authentication. (0x80090311)”.

ここで重要なのは、失敗しているのが「cifs/xxxx（＝SMB/ファイル共有）」など特定サービスへの Kerberos 認証である点です。ユーザーがログオンできているからといって、ログオン後に必要な Kerberos（チケット取得・更新・サービスチケットの要求）が正常に通っているとは限りません。

なぜ「ログオンできるのに GPO/共有だけダメ」になるのか

見え方	内部で起きがちなこと	結果
PC 起動後にドメインユーザーでログオンできる	キャッシュ資格情報でログオンが成立している（DC へのリアルタイム認証が不要な場合がある）	ログオンは通るが、ログオン後の通信で破綻が表面化する
共有（NETLOGON/SYSVOL）にアクセスすると資格情報要求	Kerberos のサービスチケット取得に失敗し、NTLM へのフォールバックや再認証が発生	資格情報を入れても拒否、もしくは遅延・不安定
GPO が適用されない	GPO は LDAP（ポリシー判定）＋ SMB（ポリシーファイル取得）が両方必要。どちらかの認証が壊れると失敗	gpupdate が失敗し、ログオンスクリプトやドライブ割り当てにも影響

このタイプの障害は、「DNS は通る」「DC 自体は健康」という条件を満たしながら、拠点間の FW/UTM が“Kerberos に必要な通信”だけを壊しているときに起きやすいのが特徴です。

まず押さえる：Kerberos と AD 通信の要点

切り分けの精度を上げるために、Kerberos と AD の通信要点を最小限だけ整理します。

• Kerberos（TCP/UDP 88）：クライアントは DC（KDC）からチケットを受け取り、サービス（例：CIFS/SMB）に提示してアクセスする
• LDAP（TCP/UDP 389）：ユーザー・コンピューターの情報参照、GPO 判定、グループメンバーシップなど
• SMB（TCP 445）：SYSVOL/NETLOGON を含む共有へのアクセス（GPO の実体ファイル取得もここ）
• DNS（TCP/UDP 53）：DC 発見（SRV レコード）、ドメイン名解決の前提
• 時刻同期（UDP 123）：Kerberos は時刻ズレに厳しい（数分単位のズレで失敗し得る）

今回のように「DNS も疎通も問題なさそう」に見えるのに Kerberos が死ぬ場合、TCP/UDP 88 が単純に閉じている以外にも、次のような“通っているのに壊れる”系が疑わしくなります。

• UTM/NGFW の アプリケーション制御が Kerberos に関連するシグネチャを誤検知して遮断
• IPS の 侵入防止シグネチャが MSRPC/SMB/Kerberos の一部を落とす
• SSL/TLS 検査や DPI が暗号化ネゴシエーションを妨害し、結果として認証が失敗
• VPN 経路の MTU が小さく、Kerberos パケット断片化や再送で破綻

症状から疑う場所を絞る早見表

同じ EventID 40960 でも、出方によって疑うべき箇所が変わります。次の表で「今の状況がどこに寄っているか」をまず確認します。

症状	優先して疑う	理由	最短で効く確認
ログオンはできるが、GPO/共有だけ失敗	拠点間 FW/UTM（App Control / IPS / DPI）	ログオンはキャッシュで通り得るが、GPO/共有はログオン後の Kerberos/SMB が必須	DC 宛の 88/389/445 の疎通＋FW ログ（ブロック記録）確認
NETLOGON/SYSVOL で資格情報要求→拒否	SMB(445) と Kerberos(88) の組み合わせ	GPO の実体は SMB で取得。認証が Kerberos で崩れると再認証が発生	Test-NetConnection DC -Port 445 と -Port 88
gpupdate /force が「ネットワーク接続がない」	DC 発見・認証経路（DNS SRV / 88 / 389）	GPO 処理は DC を見つけ、LDAP で判定し、SMB で取得する	nltest /dsgetdc:domain とイベントログの同時確認
nltest /dclist で 0x80090350 や 6118 が混在	ネットワーク品質（途中で落とされる／改変される）	「ときどき成功」や「コマンドにより挙動が違う」は経路依存が濃厚	同一端末で時間帯・回線を変えた再現テスト、FW ルールの一時例外

結論：SonicWALL の App Control が「Encrypted Key Exchange(EKE)」をブロックしていた

今回の事例で最終的に判明した主因は、拠点と本社をつなぐ SonicWALL ファイアウォールの設定でした。SonicWALL の App Control 機能で「Encrypted Key Exchange（EKE）」がブロックされており、Kerberos 認証に必要な暗号化されたやり取り（鍵交換や前提となるネゴシエーション）が途中で遮断されていました。

その結果、クライアントは DC と正常に Kerberos のハンドシェイクを完了できず、EventID 40960 の 0x80090311 が大量発生。ログオン後に必要な処理である以下が連鎖的に崩れました。

• GPO の適用（LDAP/SMB の一連処理）
• ドライブ割り当て（共有アクセス）
• NETLOGON/SYSVOL 参照（グループポリシー関連）

SonicWALL 側で「EKE をブロックしない」設定に変更したところ、上記の症状が一斉に正常化し、問題は解決しました。

対処：SonicWALL/UTM で Kerberos を壊さないための実務手順

ここからは SonicWALL に限らず、UTM/NGFW 全般で同様の事故を避けるための「考え方」と「実際の作業順」を、運用目線でまとめます。

まず見るべき設定ポイント

機能	起こりやすい事故	チェック観点	実務的な対応例
App Control（アプリ制御）	Kerberos/SMB/RPC をシグネチャ誤検知で遮断	“Encrypted Key Exchange(EKE)”“Kerberos”“MSRPC”“SMB/CIFS”系のブロック有無	該当シグネチャを許可、または DC 宛通信を例外（バイパス）
IPS（侵入防止）	特定パケットのみ落とし、断続的障害になる	ブロックログに DC の IP/クライアントの IP が出ていないか	誤検知シグネチャの除外、ポリシー強度の調整
DPI/SSL 検査	暗号化ネゴシエーションが成立せず認証が失敗	検査対象のプロトコル範囲、例外設定の可否	AD/認証系トラフィックは検査対象外にする
ルーティング/VPN（経路）	MTU 由来の断片化・再送で Kerberos が不安定	拠点回線、VPN オーバーヘッド、Path MTU	MTU 調整、PMTUD 設定、断片化関連の最適化

最短で直すための現場手順（おすすめ順）

• FW/UTM のブロックログを確認し、クライアント→DC の通信で落ちているものがないか見る（特に 88/389/445）
• App Control/IPS の該当シグネチャを「検知のみ」に一時変更し、症状が消えるかで因果関係を取る
• 原因シグネチャが特定できたら、本番は「例外（バイパス）」または「許可」で恒久化する
• あわせて必要ポートの許可と、MTUの確認を実施し、別要因の混在を潰す

ポイントは「全部オフにして直った」では終わらせないことです。AD 通信は範囲が広いので、最終的にはDC 宛の通信を“必要最小限の許可”に落とし込み、さらに誤検知しやすいアプリ制御/IPS の例外で安定させます。

Kerberos/AD で最低限押さえるべきポート一覧

「88 だけ開ければよい」と思われがちですが、GPO と共有（NETLOGON/SYSVOL）まで含めて安定させるには、関連ポートをセットで見直すのが安全です。

用途	プロトコル/ポート	方向	主な役割	運用メモ
Kerberos	TCP/UDP 88	Client → DC	チケット要求・認証	UDP が不安定なら TCP に寄ることもあるため両方確認
LDAP	TCP/UDP 389	Client → DC	ディレクトリ参照、GPO 判定	GPO の「適用判定」は LDAP 依存。通っても途中で落ちると不安定
SMB	TCP 445	Client → DC / ファイルサーバ	SYSVOL/NETLOGON、共有アクセス	NETLOGON/SYSVOL の参照不可はまず 445 と認証経路を疑う
Kerberos パスワード変更	TCP/UDP 464	Client → DC	パスワード変更/セット	パスワード変更でだけ失敗する場合に効く
DNS	TCP/UDP 53	Client → AD DNS	DC 発見（SRV）と名前解決	外部 DNS が混ざると DC 発見が崩れる。クライアントは必ず AD DNS を参照
時刻同期	UDP 123	Client → NTP（多くは DC）	Kerberos の時刻要件を満たす	拠点回線で時刻がズレると“ときどき失敗”が起きる
RPC 基本	TCP 135	Client → DC	一部の管理/照会	ドメイン参加・一部処理で必要になる。環境依存で影響が出る

補足として、管理系処理や特定の機能（リモート管理、証明書、自動登録、特定のスクリプトや WMI など）まで含めると、RPC の動的ポートや追加ポートが関わることがあります。まずはGPO と共有が安定する最低限（88/389/445/53/123 など）を確実にし、必要に応じて範囲を広げるのが実務的です。

MTU が原因になるパターンと確認方法

VPN 越し・拠点間回線では、MTU が小さくなりやすく、Kerberos のパケットが断片化して失敗するケースがあります。特に「たまに成功する」「時間帯で変わる」「同一拠点内の端末でも差が出る」など不安定系の挙動があるときは、MTU の確認は効果的です。

基本の考え方

• イーサネットの MTU 1500 を前提にすると、ping のデータサイズ 1472（= 1500 – 28）で断片化しないのが目安
• VPN オーバーヘッドがあると、実効 MTU が 1400 台まで下がることがある
• Kerberos/SMB/LDAP はサイズが大きくなることがあり、断片化や再送で失敗しやすい

確認コマンド例（クライアントから DC 宛）

コマンドプロンプトで次を実行します（管理者権限推奨）。

• ping DCのFQDN -f -l 1472
• 通らない場合は -l 1464、-l 1452…と下げ、断片化せずに通る最大値を探す

ping の -l 値	意味（概算）	読み取り	次のアクション
1472 で成功	Path MTU 1500 相当	MTU 起因の可能性は低め	FW/UTM の制御・ポートを優先確認
1472 で失敗、より小さい値で成功	Path MTU が 1500 未満	VPN/回線で MTU が削られている	VPN 装置側の MTU/MSS 調整、PMTUD の見直し
小さくしても不安定	単純 MTU 以外の問題	経路でのパケット破棄・検査の影響が濃厚	IPS/App Control の一時緩和、ログ・パケットキャプチャ

MTU は「一応通る」状態でも、負荷や再送の増加で Kerberos のタイムアウトや認証失敗に寄ることがあります。数字が怪しいときは、まず経路設計（VPN オーバーヘッド）を疑い、装置側で MSS クランプなどの設定も含めて調整します。

実際に効果が高い切り分け手順（現場で迷わない順）

「AD 健全性に問題がないのに Kerberos だけ失敗する」状況で、遠回りになりにくい確認順をまとめます。各確認は、同一端末で“変更前/変更後”を比較すると原因が浮き上がります。

クライアント側の確認（短時間でできる）

目的	コマンド例	期待される結果	NG のときの示唆
DC 発見（DNS/サイトの基本）	nltest /dsgetdc:domain	DC 名・サイト・フラグが返る	DNS SRV、経路、FW での遮断
セキュアチャネル	nltest /sc_verify:domain	成功する	端末アカウント不整合、DC 到達性、暗号周り
Kerberos チケット確認	klist	TGT やサービスチケットが表示される	チケット取得ができていない、または期限/更新が失敗
チケットのクリア（再現性を上げる）	klist purge	チケット削除後、アクセス時に再取得される	再取得が失敗すると EventID 40960 に直結しやすい
GPO の再適用	gpupdate /force	完了する（エラーが減る）	LDAP/SMB/Kerberos のどこかが壊れている
ポート疎通	Test-NetConnection DCのFQDN -Port 88 Test-NetConnection DCのFQDN -Port 389 Test-NetConnection DCのFQDN -Port 445	TCPTestSucceeded が True	FW で閉塞、もしくは途中装置が落としている

共有（NETLOGON/SYSVOL）での“決定打”テスト

この事例のように、\\ドメイン名\NETLOGON / \\ドメイン名\SYSVOL が怪しい場合は、次の観点でテストすると原因が絞れます。

• ドメイン名指定とホスト名指定の両方で試す
  
  • \\domain.local\SYSVOL
  • \\DCのFQDN\SYSVOL
• アクセスした瞬間に EventID 40960 が出るなら、共有アクセス時の Kerberos が落ちている可能性が高い
• 資格情報入力を求められる場合、Kerberos が成立せず別経路（NTLM/再認証）へ落ちているサインになり得る

DC 側の確認（「DC は正常なのに…」を確定させる）

DC 側で dcdiag / repadmin が正常という情報は、切り分け上とても有効です。ただし、そこで止まらず「DC は健康＝ネットワークか装置」という結論に繋げるため、次のポイントを押さえます。

• dcdiag /v /e：全 DC の全体健全性を確認
• repadmin /showrepl：レプリケーションが破綻していないことを確認
• DNS（SRV レコード）や時刻同期が運用設計通りかを確認

DC 健全性が概ね問題ないのに、特定拠点からのみ Kerberos が落ちる場合、原因は拠点間の経路（FW/VPN/UTM）に寄ります。

「ドメイン再参加しても直らない」から読み取れること

この種の障害で、クライアントをドメインから外して再参加しても改善しないケースは多いです。これは、端末側のマシンアカウント不整合が主因ではなく、認証の通信自体が通らない（または途中で壊される）ことを示唆します。

よくある対処	効くケース	効かない（今回寄り）ケース	見極めポイント
ドメイン再参加	マシンアカウント破損、セキュアチャネル不整合	拠点間 FW/UTM が Kerberos/SMB を遮断	nltest /sc_verify が時々成功するのに共有だけ死ぬ
資格情報マネージャ削除	保存済み認証情報が誤っている	Kerberos チケット自体が取れない	EventID 40960 が増え続ける
DNS を直す	外部 DNS 混入、SRV 不整合	DNS は通るが、認証通信が途中で落ちる	nslookup は成功するが 88/445 が不安定

つまり「再参加してもダメ」は、ネットワーク機器側へ疑いを移す合図として価値があります。

再発防止：拠点 DC を撤去した後にやるべき設計・運用チェック

拠点 DC 撤去は、AD の“構成”よりも、拠点間ネットワークやセキュリティ機器の“振る舞い”に影響が出やすい変更です。再発防止の観点では、次のチェックが効きます。

拠点間セキュリティ機器の「AD 通信例外」を設計に組み込む

• App Control / IPS / DPI を“全面的に強くする”ほど、業務認証の誤検知は起きやすい
• DC 宛の通信は、業務上必須であることが明確なので、例外（バイパス）や許可ルールを用意する
• 例外の作り方は「拠点サブネット → DC サブネット」「プロトコル/ポート限定」「ログは残す」が現実的

拠点回線での“最低限の AD 到達性”を定期監視する

定期監視は難しく考えなくて構いません。たとえば、拠点代表端末や監視サーバから以下が定期的に成功するかを見るだけでも、障害の早期検知に役立ちます。

• Test-NetConnection DC -Port 88 / -Port 389 / -Port 445
• nltest /dsgetdc:domain
• gpupdate /target:computer /force（影響が出ない範囲で）

DNS と時刻同期は“問題なかったとしても”固定化する

今回の原因は FW 側でしたが、Kerberos 障害の多くは DNS と時刻が絡みます。拠点側で運用がブレると切り分けが難しくなるため、次を標準化します。

• クライアント DNS は必ず AD DNS（DC） を参照（外部 DNS を混ぜない）
• 拠点の時刻同期は「どこを参照するか」を統一し、ルータ/UTM の NTP 設定も含めて整合させる

ログオンできる＝認証が正常、ではないと周知する

運用現場で判断を誤らせやすいのが「ログオンできてるから AD は大丈夫」という思い込みです。拠点障害時はキャッシュ資格情報でログオンできることがあるため、NETLOGON/SYSVOL と GPO の適用可否を“AD 健全性の指標”として見る運用に切り替えると、復旧判断が早くなります。

この症状が出たときの結論の出し方（短くまとめ）

最後に、同様の Kerberos エラー（EventID 40960 / 0x80090311）で迷わないための結論を整理します。

• AD/DNS が一見正常でも、拠点間 FW/UTM が Kerberos の暗号化通信を誤ってブロックすると、EventID 40960 が大量発生する
• その結果、ログオン後の共有アクセス（CIFS/SMB）や GPO 適用（LDAP＋SMB）が連鎖的に失敗し、NETLOGON/SYSVOL で資格情報要求やアクセス拒否が起こり得る
• 特に SonicWALL などのアプリ制御/IPS で Encrypted Key Exchange（EKE）等のシグネチャが関与すると、通信が“通っているように見えて壊れる”状態になりやすい
• 対策は、FW 側の該当ブロックを解除し、あわせてKerberos 必須ポート（88）を含む AD 通信全般とMTUを見直すこと

「ログオンはできるのに GPO と共有だけ死ぬ」状況は、端末をいじるほど泥沼化しやすい典型です。まずは拠点間の FW/UTM を疑い、App Control/IPS のブロックログと 88/389/445 の疎通、そして MTU をセットで確認する――これが最短で解決に近づく手順です。