Windows Server 2025 の LocalKDC サービスが起動しない原因と対処方法【KB5048667・WHfB・NTLM 対応】

2024 年 12 月の累積更新 KB5048667 を適用したあと、Windows Server 2025 の「Kerberos Local Key Distribution Center(LocalKDC)」サービスが突然起動できなくなった――そんな報告が世界中から上がっています。ですが現時点では、LocalKDC 自体がまだ「未 GA(一般提供前)」の機能であり、サービスを停止・無効化して運用を続けるのが Microsoft サポートの公式推奨です。本記事では、この挙動の背景と、安全に運用を続けるための具体的な対処手順を整理します。

目次

Windows Server 2025 で LocalKDC サービスが起動しない問題とは

発生する環境ときっかけ

本件は主に、以下のような条件で発生していると報告されています。

  • 対象 OS:Windows Server 2025(24H2, OS ビルド 26100 系)
  • きっかけ:2024 年 12 月 10 日公開の累積更新「KB5048667」(OS ビルド 26100.2605)の適用後
  • 一部の Windows 11 24H2 クライアントでも類似の症状との報告
  • 2025 年 1 月以降の累積更新(KB5050009 / KB5051987 など)を重ねても改善しないケースあり

典型的な症状は次のとおりです。

  • 「Kerberos Local Key Distribution Center」サービス(サービス名:LocalKDC)が 自動 起動に変更される
  • 手動で開始しようとすると、メッセージ ダイアログで
    「他のサービスやプログラムで使用されていないため自動的に停止します」(英語 UI: “Some services stop automatically if they are not in use by other services or programs.”)と表示され、すぐに停止する
  • KB5048667 をアンインストールしても、今度は 「開始中(START_PENDING)」のまま固まる
  • イベント ログ Microsoft‑Windows‑Kerberos‑Local‑Key‑Distribution‑Center/Operational に、関連イベントが一切出力されないことも多い

これだけ見ると「Kerberos が壊れた」「Active Directory 認証そのものに問題が出ているのでは?」と不安になりますが、実際には多くの環境で 通常の AD/Kerberos 認証やドメイン ログオンはそのまま機能している ことが確認されています。

具体的な症状と影響範囲の整理

項目状態・症状観測される影響
LocalKDC サービスのスタートアップ更新前は「無効」/更新後に「自動」に変化起動試行時に即停止、または START_PENDING のままハング
イベント ログOperational ログにエラーが一切記録されないことがある原因調査が困難になり、障害と誤認しやすい
AD へのログオン多くの環境で DC/メンバー サーバーとも通常どおりLocalKDC の停止そのものは、現状ほぼ影響なし
Windows Hello for Business
Cloud Kerberos trust
一部の環境でサインインや SSO が動作しなくなったという報告一時的にパスワード サインインへフォールバックする必要が出る
Cisco ISE など LDAP 連携AD バインドが失敗し、ネットワーク認証が通らない事例LDAP サイン/チャンネル バインド ポリシーの強化と絡んで発生

Microsoft の公式回答:LocalKDC はまだ GA(一般提供)されていない

サポート ケースでの正式コメント

2025 年 3 月、Microsoft Q&A に投稿された質問に対し、サポート ケースの結果を共有する形で 受理された回答 が公開されました。そこでは次のように説明されています。

  • プロダクト グループの分析によると、Local KDC 機能は現時点では GA(一般提供)ではない
  • OS 上には LocalKDC サービスが見えているが、実際には feature gate により機能が有効化されていない
  • 12 月以降の更新によりスタートアップの種類が「自動」に変わった結果、サービスが起動を試みて失敗し、イベント ログに警告が出るだけ の状態になっている。
  • 推奨対応は次の 2 点:
    • すべての Windows Server 2025 で LocalKDC サービスを無効化する(あるいは手動にする)
    • 更新プログラムの適用は継続する(セキュリティ修正を止めない)

同時に、KB5048667 の公式サポート記事の「既知の問題」セクションには、LocalKDC に関する記載は一切ありません。記事上は「現時点で既知の問題はない」と明記されています。

観点内容
機能ステータスLocal KDC 機能は 未 GA。サービスは見えるが、機能は feature gating により無効。
正式な既知の問題KB5048667 の「Known issues in this update」に LocalKDC は記載なし。
サポートの推奨LocalKDC サービスは 無効 または 手動 に設定し、更新は止めない
影響範囲LocalKDC は新機能であり、無効化しても既存アプリやサービスへの影響は想定されていない

Steve Syfuhs のコメントと「feature gating」

同じ Q&A のスレッドでは、Windows の暗号/認証チームに所属するエンジニア Steve Syfuhs 氏のブログや Reddit へのコメントも紹介されています。そこで示されているポイントは次のとおりです。

  • LocalKDC と IAKerb は、Windows 11 / Windows Server 2025 にコンポーネントとしては存在しているが、まだ有効化されていない
  • 「ドキュメントが存在しないのは意図的であり、機能をまだ有効化していない。サービスが見えているのは feature gating の副産物に過ぎない」とされている。
  • したがって、LocalKDC サービスの起動に失敗しても、現行のドメイン コントローラー/クライアントの Kerberos 認証には影響しない

また、2025 年の FOSDEM カンファレンスで公開されたスライドでも、「IAKerb と Local KDC は Windows 11 24H2 と Windows Server 2025 ではまだ実装されていない」 と明記されており、現行ビルドではロールアウト途中であることが裏付けられます。

LocalKDC / IAKerb が担う役割と NTLM 廃止のロードマップ

では、まだ GA されていない LocalKDC / IAKerb は、何のために追加されようとしているのでしょうか。Microsoft の公式ブログ「The evolution of Windows authentication」や各種記事では、次のような位置づけが示されています。

  • IAKerb:ドメイン コントローラーへ直接到達できないクライアントでも、DC と通信できるサーバー経由で Kerberos 認証を行えるようにする拡張。
  • Local KDC:各マシン上の Security Account Manager (SAM) を利用して、ローカル アカウントのリモート認証を Kerberos で行えるようにする 機能。
  • これらを SPNEGO(Negotiate)スタックに統合し、Kerberos → IAKerb/LocalKDC → NTLM の順でフォールバックすることで、NTLM 環境を段階的に縮退させる狙いがある。
技術主な役割LocalKDC 問題との関係
NTLMレガシなチャレンジレスポンス認証。将来的に廃止予定。LocalKDC/IAKerb が GA するまで、完全な無効化は現実的ではない
Kerberos(従来)AD ドメイン コントローラーを前提としたチケット ベース認証。LocalKDC の停止とは無関係に動作。KDC サービスは別物。
IAKerbDC に直接届かないクライアントのための Kerberos プロキシ。LocalKDC とセットで展開予定。現時点ではまだ有効化されていない。
LocalKDCSAM 上のローカル アカウントを Kerberos で認証するためのローカル KDC。サービスが見えているが、未 GA により機能は無効。エラーは「見かけ上」のもの。

よくある誤解の整理

「LocalKDC が起動しない=Kerberos 全体が壊れた」ではない

LocalKDC は、従来のドメイン KDC(kdc サービス)とは別の新機能です。Q&A スレッドやコミュニティの報告でも、LocalKDC サービスが停止していても DC/クライアントの Kerberos 認証は正常に機能している ことが繰り返し共有されています。

そのため、「サービスが起動しない=ドメインが壊れた」と早合点して、DC をロールバックしたり再構築したりするのは避けるべきです。

「RPC がすべて非推奨」になったわけではない

同じ議論の中で、「RPC が非推奨だから Kerberos / LocalKDC に全面移行しないといけない」という誤解も散見されます。しかし、Microsoft エンジニアからは次のような補足があります。

  • 非推奨なのは RPC over HTTP(ncacn_http) であり、
  • RPC over TCP(ncacn_ip_tcp)や RPC over SMB(ncacn_np)は引き続き利用されている

したがって、LocalKDC の起動に失敗しているからといって「RPC をすべて排除する」といった極端な対応をとる必要はありません。

IAKerb/LocalKDC が GA する前に NTLM を完全停止するのは現実的でない

NTLM は確実に「終焉」に向かっていますが、2025 年時点でも多くのシナリオで依然として必要です。Microsoft 自身も、IAKerb と LocalKDC を有効化したうえで段階的に NTLM を削減していくロードマップを示しています。

LocalKDC がまだ機能していない状況で NTLM を全面的に無効化すると、

  • 古いアプリケーションや一部のネットワーク機器
  • ローカル アカウントでの管理共有、RDP など
  • 一部の Wi-Fi / VPN 認証(MS-CHAPv2)

といった箇所で、想定外の認証失敗が発生し得ます。現実的には、NTLM の使用状況を可視化し、優先度の高いところから Kerberos へ移行 していくことが重要です。

すぐできる対処:LocalKDC を「手動」または「無効」で運用する

PowerShell でサービス状態を確認・変更する

まずは、LocalKDC サービスがどのような状態になっているかを確認します。

Get-Service LocalKDC

サービスが Running 以外(Stopped / StartPending など)で、スタートアップの種類が AutomaticAutomatic (Delayed) になっている場合は、次のコマンドで停止したうえで 手動 もしくは 無効 に変更します。

Stop-Service LocalKDC -ErrorAction SilentlyContinue
Set-Service  LocalKDC -StartupType Manual   # または Disabled

GUI で行う場合は、services.msc を開き、「Kerberos Local Key Distribution Center」 をダブルクリックして「スタートアップの種類」を 手動 または 無効 に変更し、「適用」を押します。

イベント ログの確認(出なくても異常ではない)

LocalKDC に関するイベント ログは以下のパスにあります。

  • アプリケーションとサービス ログ → Microsoft → Windows → Kerberos-Local-Key-Distribution-Center → Operational

しかし、多くの環境では ここに何も記録されないままサービスが起動失敗する ことが報告されています。これは、機能自体がまだ有効化されていないことに起因する挙動と思われ、ログが出ないこと自体を異常と捉える必要はありません

GPO でスタートアップ種別を一律制御してイベント ノイズを減らす

複数台の Windows Server 2025 を運用している場合は、GPO(グループ ポリシー)で LocalKDC のスタートアップを一律に制御すると、起動のたびにイベント ログへ警告が出力される「ノイズ」を減らせます。

設定対象設定パス推奨値
LocalKDC サービスのスタートアップコンピューターの構成 > 基本設定 > コントロール パネルの設定 > サービスService Name: LocalKDC
Startup: Manually または Disabled

ドメイン全体に適用する前に、テスト OU で動作検証を行うことを強く推奨します。

ロールバック(更新のアンインストール)は原則非推奨

実際の報告では、12 月/1 月の更新をアンインストールすると LocalKDC の症状が解消するケースもある一方で、

  • ADFS サーバーが黒画面になりログオン不能になる
  • 再起動後にサーバーに接続できなくなる

といった副作用が発生した事例も報告されています。

さらに、KB5048667 は「内部 OS 機能に対するセキュリティ改善」を含む更新であり、既知の問題としては公式に何も挙げられていません。 したがって、検証用 VM 以外でのロールバックは避け、本番環境では更新適用を継続する のが安全です。

Windows Hello for Business Cloud Trust / LDAP 連携への影響

WHfB Cloud Kerberos trust での既知のトラブル

前述の Q&A スレッドには、LocalKDC の問題発生と同時に Windows Hello for Business (WHfB) Cloud Kerberos trust が動作しなくなった という報告が複数寄せられています。

Microsoft 自身も別の更新(2025 年 4 月のセキュリティ更新など)で、Windows Hello(特に Key trust モデル)と Kerberos のログオンに影響する不具合を認めており、Windows Server 2025 における認証まわりはまだ「動いてはいるが敏感な状態」と言えます。

Cloud Kerberos trust の構成は、Microsoft Entra Kerberos オブジェクトの作成やポリシー設定など、複数の要素に依存するため、LocalKDC 問題とは直接の因果関係が明らかになっているわけではありません。 それでも、以下のような当面の運用策が現実的です。

  • WHfB が機能しないユーザーには、一時的に パスワード サインインへフォールバック する。
  • Cloud trust の有効化ポリシーを一時的にオフにし、従来方式(Key trust / Certificate trust)への切り戻しを検討する。
  • LocalKDC を無効/手動にした状態で、再度 WHfB Cloud trust の挙動を検証しておく。

Cisco ISE や各種アプライアンスが AD にバインドできない問題

同じく Q&A コメントや Netgate フォーラムなどでは、Windows Server 2025 を DC にした環境で、

  • Cisco ISE からの LDAP バインドが失敗する
  • OPNsense / Nextcloud / NethServer などが LDAP 連携できない

といった事例が報告されています。

これらの多くは、Windows Server 2025 で LDAP サインおよびチャンネル バインドがデフォルトで厳格化された ことや、LDAPS(ポート 636)を前提とした構成に変わったことが背景にあります。

Netgate のフォーラムでは、一時的な回避策として、ドメイン コントローラーのセキュリティ オプションを以下のように緩和する例が紹介されています。

ポリシー緩和値の例注意点
DC: LDAP サーバー チャンネル バインド トークンの要件「サポートされている場合(When Supported)」完全な「必須」よりは緩いが、将来的には戻す必要あり。
DC: LDAP サーバー署名の要件「なし(None)」署名を要求しないため、セキュリティは低下する。
DC: LDAP サーバー署名の要件を強制「無効」アプライアンス側が署名/暗号化に対応するまでは一時しのぎとして。
ネットワーク セキュリティ: LDAP クライアント暗号化の要件「暗号化の交渉(Negotiate Sealing)」互換性と暗号化のバランスを取る設定。
ネットワーク セキュリティ: LDAP クライアント署名の要件「署名の交渉(Negotiate Signing)」古いクライアントやアプライアンスとの共存を優先する場合に有効。

これらの緩和策はあくまで 一時的な回避 と割り切り、

  • 可能な限り LDAPS(ポート 636)+証明書 で接続する
  • ベンダー側の「Windows Server 2025 対応ガイド」が出たら、ポリシーを元に戻す

といった中長期計画を併せて検討することが重要です。

トラブルシューティング手順(チェックリスト)

1. LocalKDC の状態とログを確認する

  • Get-Service LocalKDC で状態を確認。
  • Operational ログにエラーがない場合でも、現時点では「正常な(よくある)状態」と考えてよい。
  • サービスは 手動/無効 に設定しておき、起動させようとしない。

2. AD DS / KDC サービスが正常かを切り分ける

  • ドメイン コントローラー上で kdc サービス(「Kerberos Key Distribution Center」)が正常に動作しているか確認する。
  • クライアントからドメイン ログオン、klist get などでチケット取得ができるかテスト。
  • 問題が LocalKDC に限られているのか、AD/Kerberos 全体に及んでいるのかを切り分ける。

3. Windows Hello for Business / Cloud Kerberos trust の切り分け

  • WHfB がうまく動かない端末では、一度パスワード サインインに切り替えて動作確認する。
  • Cloud trust の構成(Entra Kerberos オブジェクト、GPO/Intune 設定)が正しいか、公式ガイドに沿って再確認する。
  • LocalKDC を無効にした状態で、再度 WHfB の有効化を試す(挙動の差分を記録)。

4. LDAP/NTLM まわりのポリシーを棚卸しする

  • Windows Server 2025 では LDAP サインとチャンネル バインドが強化されているため、既存の GPO とセキュリティ ベースラインを確認する。
  • NTLM の監査ログ(Microsoft-Windows-NTLM/Operational)を有効にし、どのアプリや機器が NTLM に依存しているかを洗い出す。
  • アプライアンス側のログ(Cisco ISE / OPNsense / Nextcloud など)と照合し、問題がどのレイヤで発生しているかを明確にする。

長期的な見通しと設計のポイント

NTLM 廃止に向けた「準備フェーズ」と割り切る

現時点で LocalKDC は GA しておらず、「サービスは見えるが実際には動いていない」という宙ぶらりんな状態です。一方で、NTLM 廃止に向けた各種変更(Credential Guard の既定有効化、NTLMv1 のブロックなど)は少しずつ進んでいます。

このギャップを吸収するために、今取るべき現実的な方針は次のようにまとめられます。

  • LocalKDC は「まだ使えない機能」として扱う(サービスは手動/無効)。
  • NTLM を即時全廃しないが、使用状況の可視化と削減計画は今から始める。
  • LDAP/SMB/RDP/VPN など、認証に関わる経路を棚卸しし、Kerberos(+将来の IAKerb/LocalKDC)への移行シナリオ を設計する。
  • Windows Hello for Business、FIDO2、スマート カードなど パスワードレス認証 も並行して検討する。

テスト環境の使い方を変える

Windows Server 2025 のような「認証スタックが大きく変わる」バージョンでは、テスト環境も従来より一段深く作り込む必要があります。

  • 本番と同等の GPO/セキュリティ ベースラインを適用した検証ドメインを用意する。
  • ADFS、NPS、Cisco ISE、各種 Web アプリ、ファイル サーバーなど、「認証に絡むコンポーネント」をできるだけ再現する。
  • 累積更新ごとに WHfB や LDAP 連携の回帰テスト を実施し、問題があれば本番展開前にフィードバックを上げる。

監査ログと可視化ツールを活用する

NTLM や古いプロトコルの利用を減らすには、「どこで使われているか」を把握することが最初の一歩です。

  • Microsoft-Windows-NTLM/Operational ログで NTLM 使用状況を監査する。
  • イベント ID 4024/4025(NTLMv1 派生資格情報の使用/ブロック)を活用し、どのサービスが影響を受けるか確認する。
  • サードパーティの可視化ツールや SIEM にログを取り込み、「アプリケーション単位・ユーザー単位」で依存関係を見える化する。

FAQ(運用者からよく聞かれる質問)

Q. LocalKDC を無効にして本当に大丈夫ですか?

A. Microsoft サポートは、LocalKDC を無効化しても既存のアプリケーションやサービスには影響しないと案内しています。LocalKDC 機能がまだ GA されておらず、サービスが OS に見えているのは feature gate の副産物だからです。

ただし、各社の環境やサードパーティ製品との組み合わせによって挙動が異なる可能性はあるため、自社の検証環境で回帰テストを行ったうえで本番に適用 することを推奨します。

Q. 恒久対処や修正の時期はいつですか?

A. サポート回答によれば、Microsoft は LocalKDC 機能を現在開発中であり、パブリック プレビューの段階になったら公式ドキュメントや記事で案内する としています。ただし、具体的なスケジュールは示されていません。

したがって、現時点では「LocalKDC はまだ使えない機能」と割り切り、サービスを手動/無効にしたうえで、セキュリティ更新の適用を継続する のが現実的な対応になります。

Q. WHfB Cloud Trust が動かなくなりました。LocalKDC が原因ですか?

A. LocalKDC 問題と同時期に WHfB Cloud trust が動作しなくなったという報告は複数ありますが、直接の因果関係は明示されていません。

実務的には、

  • LocalKDC を手動/無効に固定したうえで再検証する
  • WHfB の構成(Cloud trust ポリシー、Entra Kerberos オブジェクト)を公式手順と突き合わせる
  • 一時的にパスワード サインインや他の trust モデル(Key trust / Certificate trust)に切り戻す

といったステップで切り分けを行うのがよいでしょう。

Q. Cisco ISE やその他アプライアンスとの LDAP 連携が動きません。

A. Windows Server 2025 では、LDAP サインやチャンネル バインドがデフォルトでより厳格になっており、古い LDAP クライアントやアプライアンスが接続できなくなるケースがあります。

一時的な回避策として、

  • DC 側の LDAP 関連ポリシーを「交渉」「サポート時のみ」レベルに緩和する
  • LDAPS(ポート 636)+適切な証明書での接続に移行する

といった方法が報告されていますが、いずれもセキュリティとのトレードオフがあります。最終的には、ベンダーが提供する「Server 2025 対応手順」に従いつつ、ポリシーを本来の強度に戻す ことを目標にしてください。

Q. 今、何をすればよいかを一言でいうと?

A. まとめると、現時点での現実解は次の一文に集約できます。

「LocalKDC はまだ使えない」→「サービスは手動/無効で運用し、更新プログラムは止めない」。

そのうえで、周辺の認証連携(WHfB、LDAP、RDP など)に影響が出ている場合は、フォールバックやポリシー緩和で当座をしのぎつつ、NTLM 縮退と LocalKDC/IAKerb の正式提供に備えた設計・テストを進める――これが、2025 年時点で取り得る最も現実的な戦略と言えるでしょう。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次