Microsoftは2025年10月21日（米国時間）、Windows 11 24H2以降およびWindows Server 2025に対する最近の更新プログラムによる仕様変更の影響により、サポートされない方法で構築されたデバイス間で、Kerberos認証やNTLM認証のエラーが発生する可能性に関するサポート情報を公開しました。個人のデバイスや、適切な方法でインストール/展開された企業のデバイスには影響しない問題です。

重複する SID による Kerberos および NTLM 認証エラー｜サポート（Microsoft）

仕様変更で認証エラー、その影響範囲

　サポートされない方法で構築されたデバイスとは、マシンSID（マシンID）のリセットを伴わない方法で同じイメージから展開されたデバイスのことを指します。サポートされる方法は、システム準備ツールを使用してイメージを一般化（sysprep /oobe /generalize /shutdownを実行）したうえで、その複製を展開する方法です。マシンSIDとは、Windowsセットアップによって生成される一意の（通常、世界で唯一の）識別子です（ただし例外があります。それはドメインコントローラーです。ドメインコントローラーはすべて、最初のドメインコントローラーのマシンSIDから生成される同じドメインSIDを持ちます）。

　2025年8月のオプションの更新プログラム（2025-08 D）以降がインストールされた環境では、同じマシンSIDを持つデバイス間でKerberos認証やNTLM認証がエラーで失敗するようになります。この問題は更新プログラムの不具合ではなく、設計（仕様）変更の影響です。2025-08 D以降の更新プログラムでは、SIDに対するチェックを強制するセキュリティ保護策が追加されるという仕様変更が行われました。その影響で、同じマシンSIDを持つデバイス間で問題が発生するようになったわけです。

　影響を受ける可能性があるデバイスは、以下のWindowsバージョン、ビルドを実行するデバイスですが、通常の方法でインストールまたはイメージ展開されたWindowsは同じマシンSIDを持つことはないので、影響を受けることはありません。

• Windows 11 24H2（2025-8 D、OSビルド26100.5074以降）
• Windows 11 25H2（GA、OSビルド26200.6584以降）
• Windows Server 2025（2025-09 B、OSビルド26100.6584以降）

　仕様変更の影響を仮想マシン（VM）で再現させてみました。まず、2025年7月（2025-07 B、OSビルド26100.4946）まで更新されたWindows Server 2025のVMのイメージを用意しました。その仮想ハードディスクファイル（.vhdx）を複製し、別のVMのOSディスクとして割り当て、起動後、コンピューター名だけを変更しました。2台のVMを起動して、VM間でリモートデスクトップ（RDP）接続や共有フォルダーの（SMB）接続に問題はありません（画面1）。なお、マシンSIDの確認には、Windows SysinternalsのPsGetSidツールを使用しました。

PsGetSid｜Sysinternals（Microsoft）
https://learn.microsoft.com/ja-jp/sysinternals/downloads/psgetsid
https://live.sysinternals.com/psgetsid.exe（Webから直接実行）

　PsGetSidを使用しなくても、PowerShellで次のコマンドラインを実行して取得することができます。ユーザーやグループのSIDは、「マシンSID-RID」（マシンSID-500など）なので、Get-LocalUserで取得した最初のユーザーまたはグループの最後のハイフンまでの文字列がマシンSIDになります。

画面1　Windows Server 2025（2025-07 B）のデバイス（VM）間では、同じマシンIDでもRDP接続やSMB接続に問題は生じない

　Windows Updateを実行して最新の更新プログラム（2025-10 B）をインストールした後に、同じようにRDP接続やSMB接続を試みると、どちらも認証に失敗するようになります（画面2）。このとき、認証をブロックした側の「システム」イベントログには、ローカルセキュリティ機関（LSA）のイベントID「6167」エラーイベントが記録されます（画面3）。

画面2　Windows Updateを実行して、OSビルドを最新にすると、同じマシンSIDのデバイス間の認証は失敗するように

画面3　マシンSIDの重複が原因の認証エラーは、認証する側（RDPやSMBの接続先）の「システム」イベントログにイベントID「6167」エラーイベントとして記録される

　認証エラーは、仕様変更の結果であり、不適切な方法でクローンされたデバイス以外には影響しません。そのため、Microsoftは元の挙動に戻すような更新プログラムを提供するとはないでしょう。最初に示したサポート情報には、この問題に一時的に対処できる特別なグループポリシーを、Microsoftビジネスサポート経由で入手できると説明されています。影響を受ける場合は、サポートに問い合わせてください。

“マシンIDの重複神話”が神話でなくなる

　“マシンSIDの重複神話”は、Windows Sysinternalsの生みの親の一人であり、現在はMicrosoft Azureの最高技術責任者（CTO）兼テクニカルフェローであるマーク・ルシノビッチ氏が、2009年に自身のブログに投稿した記事です。この記事は、Windows Sysinternalsでかつて提供されていたマシンSIDの変更ツール「NewSID」の提供終了に合わせて、その理由とSysprepの重要性について説明したものです。

マシン SID の重複神話｜Microsoft Learn
The Machine SID Duplication Myth (and Why Sysprep Matters)｜Microsoft Learn

　この記事では、かつて（マーク氏の記事が書かれたのは2009年であることを考慮してください）、Windowsコンピュータが持つマシンSIDは、ネットワーク上で一意でなければならない、重複してはならないと長い間信じられてきましたが、実際にはSIDが重複しても問題にならないことを説明するものです。マイクロソフトがサポートするSysprepの方法は、マシンSIDをリセットしますが、それはあまり重要ではなく、Sysprepが他にもマシン固有の状態をリセットするということのほうが重要であると指摘しています。マシンSIDの重複は問題にならなくても、他のマシン固有の設定の状態の重複は特定のアプリケーションで問題が発生する可能性があるからです。

　“マシンSIDの重複神話”の公開以降、マシンSIDは重複しても問題にならないということは定説となりました。しかし、マシンSIDは重複してもかまわないという話だけが広がり、それが結果として、Sysprep以外の方法、つまりサポートされない方法が多用される可能性を生んでしまったのかもしれません。

　しかし、2025-08 D以降の仕様変更により、もはやマシンSIDが重複してはならないという“神話”は、現実になってしまいました。Windows SysinternalsのNewSIDはもう利用できないので、影響を受けたからと言って簡単にマシンSIDをリセットすることはできません。SysprepはマシンSIDをリセットできる正式な方法ですが、Sysprepはイメージを一般化するために構築したWindowsインストールに対して実行するものです。運用中のデバイスで実行しても、エラー（致命的なエラー）で失敗するでしょう。たとえ成功したとしても、マシン固有の状態がすべてリセットされてしまうため、コンピューター名から何からすべて再構築する必要があります。影響を受けた場合は、前述したようにMicrosoftのサポートに問い合わせてください。