2025年に入り、一部のWindows環境で「ドメインにログオンできない」「リモートデスクトップ接続が拒否される」「ファイル共有にアクセスできない」といった認証関連の障害が報告されています。これらの事象は、特定の更新プログラム（例：KB5065426など）を適用した後に発生しており、その根本原因の一つとして「マシンSID（マシンID）の重複」が指摘されています。
マシンSIDとは、Windowsが各コンピュータに割り当てる固有の識別子であり、アクセス制御や認証の基礎として利用される重要な情報です。本来はOSインストール時に一意に生成されるものですが、Sysprep（System Preparation Tool）を用いずにディスクイメージを複製した場合などでは、このSIDが複数のマシンで重複することがあります。
これまではマシンSIDの重複によって重大な不具合が起こるケースはほとんどありませんでしたが、Windows 11以降では認証メカニズムの整合性検証が強化され、重複SIDを持つ環境でKerberosやNTLM認証が失敗する事例が明確に確認されています。
本記事では、この問題の背景と技術的な仕組み、発生原因、そして防止策としてのSysprepの重要性について解説します。
マシンSID（マシンID）とは何か
マシンSID（Machine Security Identifier、以下マシンIDとも呼びます）は、Windowsが各コンピュータを識別するために割り当てる固有の識別子です。SID（Security Identifier）はWindowsのセキュリティモデルの基盤を構成する要素であり、ユーザー、グループ、サービス、そしてマシンそのものを一意に識別するために使用されます。
Windowsでは、アクセス制御リスト（ACL）や認証情報の照合においてSIDが参照されます。たとえば、あるフォルダに対してアクセス権を付与すると、その設定はユーザー名ではなく、実際にはユーザーSIDを基準に保持されます。同様に、ローカルコンピュータを識別するためにもSIDが利用され、これが「マシンSID」と呼ばれるものです。
マシンSIDは、Windowsのインストール時に自動的に生成されます。これにより、同一ネットワーク上に複数のマシンが存在しても、それぞれが固有の識別子を持つことになります。しかし、ディスクのクローン作成や仮想マシンのテンプレート展開を行う際に、Sysprep（System Preparation Tool）を使わずにイメージを複製すると、元のSIDがそのまま複製先にも引き継がれ、複数のマシンが同一SIDを共有してしまうことがあります。
一見すると同じ見た目の独立したPCであっても、SIDが重複している場合、Windows内部では「同一マシン」として扱われることがあり、認証やアクセス制御の整合性に問題が生じます。特に、KerberosやNTLMといった認証プロトコルでは、このSIDをもとにマシン間の信頼関係を検証するため、SID重複はログオンエラーや共有アクセスの拒否といった障害を引き起こす要因となります。
つまり、マシンSIDはWindowsのセキュリティ構造を支える根幹的な識別子であり、同一ネットワーク上で重複してはならない値です。運用上は、OSの展開や仮想マシンの複製を行う際に、各マシンが一意のSIDを持つよう管理することが不可欠です。
Sysprepとは何か
（generalize）」するためのプロセスを担います。一般化とは、特定のコンピュータ固有の情報を一時的に削除し、再起動時に新しい環境として再構成できる状態にすることを指します。
Windowsを通常インストールすると、その環境にはマシンSID、ネットワーク設定、デバイスドライバ、イベントログ、ライセンス情報など、ハードウェアやインストール時点に依存した情報が含まれます。これらをそのまま複製して別のマシンに展開すると、同一SIDを持つクローンが複数台生成され、認証やネットワーク上の識別で衝突が発生する可能性があります。Sysprepはこの問題を防ぐため、これらの固有情報を初期化し、次回起動時に新しいSIDや構成情報を自動生成させる役割を果たします。
Sysprepを実行する際には、/generalize オプションを指定するのが一般的です。このオプションにより、マシンSIDを含む固有データが削除され、システムが「未構成状態」となります。その後、再起動時にWindowsが再構成プロセスを実行し、新しい識別子を生成します。これによって、同一イメージから展開された複数のマシンがそれぞれ固有のSIDを持ち、KerberosやNTLMなどの認証メカニズムが正しく動作するようになります。
また、Sysprepは企業や教育機関などで大量のPCを一括展開する際に不可欠な手段です。テンプレートマシンをあらかじめ設定しておき、Sysprepで一般化したイメージを複数のデバイスに展開することで、設定の一貫性と識別の独立性を両立できます。
なお、SysprepはMicrosoftが公式にサポートする唯一の一般化手法であり、過去に存在した「NewSID」などのサードパーティツールは既に非推奨となっています。Sysprepを経ずに複製した環境では、現在のWindows 11以降で報告されているような認証エラーや共有アクセスの不具合が発生する可能性が高いため、運用上は常に一般化済みのイメージを利用することが推奨されます。
マシンSIDの重複が発生するケース
マシンSIDの重複は、Windowsの設計上「SIDがインストール時に一度だけ生成される」という性質に起因します。したがって、同じインストール済みシステムを複数のマシンに複製した場合、すべての複製先が同一のSIDを保持することになります。以下では、実際に重複が発生しやすい典型的なケースを説明します。
1. Sysprepを実行せずにディスクイメージを複製した場合
最も一般的なケースです。
運用現場では、あるマシンを初期設定した後に、その環境をディスクイメージとして他のPCへ複製し、同一構成の端末を短時間で用意することがあります。しかし、Sysprepを実行せずにイメージ化を行うと、元のマシンSIDが複製先にもそのまま引き継がれます。結果として、ネットワーク上で複数のマシンが同じSIDを持つ状態となり、認証処理やアクセス制御に支障をきたす可能性があります。
2. 仮想マシンのテンプレートやスナップショットをそのまま展開した場合
仮想化環境（Hyper-V、VMware、VirtualBox、Proxmox など）では、テンプレートやスナップショットを使って新しい仮想マシンを生成する運用が一般的です。テンプレート作成時にSysprepを実行していない場合、そのテンプレートから派生したすべての仮想マシンが同一SIDを共有します。特にVDI（仮想デスクトップ）やテスト環境では、短時間で多数のインスタンスを立ち上げることが多く、この問題が顕在化しやすくなります。
3. バックアップイメージを別マシンにリストアした場合
システムバックアップを取得し、障害対応や構成複製の目的で別のマシンにリストアする場合にもSID重複は発生します。バックアップにはマシンSIDが含まれており、復元後の環境は元のマシンと同一SIDを持つことになります。特にドメイン参加済みのマシンをこの方法で復元した場合、ドメインコントローラとの信頼関係が失われ、認証エラーを引き起こすことがあります。
4. 非公式ツールでSIDを変更またはコピーした場合
かつては Sysinternals の「NewSID」など、SIDを変更するための非公式ツールが存在しました。しかし、これらのツールは既にMicrosoftのサポート対象外であり、最新のWindowsビルドでは正常に動作しません。さらに、SID以外の関連識別情報（セキュリティデータベースやACL設定など）との整合性を壊す危険性があり、運用環境での使用は推奨されません。
5. 仮想ディスク（VHD/VHDX）を複数の仮想マシンで共有起動した場合
1つの仮想ディスクを複数の仮想マシンで同時に使用する構成でも、SID重複が発生します。ディスク上のシステムは同一のSIDを保持しており、各マシンは内部的に同一識別子として認識されます。そのため、SMB共有や認証トークンの発行時に整合性エラーが発生しやすくなります。
まとめ
マシンSIDの重複は、「OSを新規インストールせず、既存環境をコピー・複製した場合」に必ず発生します。これを防ぐ唯一の確実な方法は、イメージ作成前に Sysprepの/generalizeオプションを実行してSIDを初期化することです。特にドメイン参加環境や仮想化インフラでは、この手順を標準化することが、今後の認証トラブル防止に不可欠です。
なぜ今になって問題が顕在化したのか
マシンSIDの重複は、Windows NTの時代から理論的には存在していた問題です。しかし、長らく実運用上はほとんど問題視されていませんでした。これは、Windowsの認証設計やネットワーク動作が、マシンSIDの重複を直接的に検証することを想定していなかったためです。ところが、Windows 11以降の更新プログラムではセキュリティモデルが強化され、従来黙認されてきた環境が「正しくない構成」として扱われるようになりました。
Windows 10以前では問題が顕在化しなかった理由
Windows 10までのバージョンでは、マシンSIDの重複があっても、通常の運用で深刻な支障が生じることはほとんどありませんでした。ローカル環境では各マシンのアクセス制御リスト（ACL）が個別に管理されており、他のマシンのSIDと衝突しても影響がなかったためです。ドメイン環境でも、認証時にはマシンSIDではなくドメインSIDが優先的に使用されるため、重複は実質的に無視されていました。
このため、過去には「マシンSIDの重複は神話に過ぎない」との見解がMicrosoft自身から示されています。2009年にMark Russinovich（当時Sysinternalsの開発者）が発表したブログ記事「The Machine SID Duplication Myth」では、「同一マシンSIDによる実害は確認されていない」と明言されており、以後も多くの運用現場でSysprepを省略したイメージ展開が行われてきました。
Windows 11以降での変化
しかし、Windows 11（特に24H2以降）では、セキュリティの一貫性検証が強化されました。KerberosやNTLMなどの認証プロトコルにおいて、マシンSIDの一意性がより厳密に参照されるようになり、SIDの重複がある場合には認証を拒否する挙動が導入されています。
特に、2025年8月以降に配信された累積更新プログラム（例：KB5065426など）では、ドメイン参加済みマシンやSMB共有を利用する環境で「SEC_E_NO_CREDENTIALS」や「STATUS_LOGON_FAILURE」といったエラーが頻発する事例が報告されました。Microsoftはこれについて、「重複SIDを持つPC間での認証処理が正しく行えないことを確認した」と公式に説明しています。
背景にあるセキュリティ設計の変化
Windows 11世代では、ゼロトラストモデル（Zero Trust Architecture）の原則に基づき、システム間の信頼関係を明示的に検証する設計へと移行しています。マシンSIDのような基礎的な識別情報についても、これまで以上に厳密な一意性が要求されるようになりました。その結果、これまで問題として顕在化しなかった構成上の欠陥が、セキュリティ上の不整合として表面化したのです。
まとめ
マシンSIDの重複という現象自体は新しいものではありません。しかし、Windows 11およびその後の更新によって、認証処理における整合性検証が強化された結果、「これまで通用していた構成が通用しなくなった」という形で問題が顕在化しました。セキュリティ強化の観点から見れば自然な進化ですが、イメージ展開を前提とする環境では、従来の運用手順の見直しが避けられない状況となっています。
発生している主な事象
マシンSIDの重複によって生じる問題は、主に認証処理の失敗として現れます。特に、Windows Updateの適用後にKerberosまたはNTLM認証が適切に動作しなくなり、ログオンやリモート接続、共有アクセスなどが拒否される事例が確認されています。これらの障害は、企業ネットワークや仮想化環境を中心に報告されており、複数台のマシンが同一SIDを共有している構成で発生する傾向があります。
1. ログオン時の認証エラー
最も多く報告されているのは、ドメインログオンやローカル認証時の失敗です。Windows Update適用後に突然ドメインに参加できなくなり、ユーザーが正しい資格情報を入力してもログオンできない状態となります。イベントログには以下のような記録が出力されます。
- イベントID 4625（ログオン失敗）
「An account failed to log on（アカウントのログオンに失敗しました）」というメッセージとともに、Security ID: NULL SID が表示される場合があります。 - イベントID 4768（Kerberos 認証チケット要求失敗）
Kerberos 認証でチケットが発行されず、KDC_ERR_PREAUTH_FAILED または SEC_E_NO_CREDENTIALS が記録されることがあります。
これらはいずれも、マシンSIDの整合性が失われ、認証トークンが正しく発行・照合できないことが原因とされています。
2. リモートデスクトップ接続（RDP）の失敗
更新プログラム適用後、リモートデスクトップ（RDP）による接続試行時に「ログオン試行が失敗しました（The logon attempt failed）」というメッセージが表示されるケースがあります。
マシンSIDが他の端末と重複している場合、クライアント認証情報の検証段階で不一致が発生し、セッションが拒否されます。これは、ドメイン内でRDPアクセスを制御している環境（グループポリシーやNTLMベースの認証が関係する環境）で特に発生しやすい事象です。
3. ファイル共有やプリンタ共有へのアクセス不能
マシンSIDの重複により、SMB（Server Message Block）通信で行われる認証が失敗し、ファイル共有やプリンタ共有が利用できなくなる事例も確認されています。ユーザーがネットワーク共有フォルダにアクセスしようとすると、認証ダイアログが繰り返し表示されたり、「アクセスが拒否されました」というエラーが発生します。
Microsoft Q&Aフォーラムでは、特に更新プログラム KB5065426 適用後にこの問題が頻発しており、同一SIDを持つマシン間でSMB共有が機能しなくなることが報告されています。
4. サービスアカウントおよびシステム間通信の不具合
ドメイン参加マシン同士で通信するサービス（たとえばIIS、SQL Server、ファイル同期システムなど）でも、認証トークンが無効化され、接続が確立できないケースがあります。これは、内部的にKerberosチケットやNTLMトークンを利用しているため、マシンSIDの重複によって整合性が失われることに起因します。
5. 再起動後にのみ発生するケース
一部の報告では、更新プログラムの適用直後ではなく、再起動後に問題が発生する傾向が見られます。これは、再起動によって新しいセキュリティトークンが生成される際にSID重複が検出され、認証が拒否されるためと考えられます。
まとめ
以上のように、マシンSIDの重複はWindows 11以降の更新によって顕在化し、以下のような認証関連の不具合として表れています。
- ドメインログオンの失敗
- RDP（リモートデスクトップ）接続の拒否
- SMB共有・プリンタ共有のアクセス不能
- サービスアカウントによる通信の停止
いずれのケースも、根本的な原因は「同一マシンSIDを持つ複数の端末が存在すること」にあり、これを解消しない限り再発の可能性が高いと考えられます。
影響を受ける認証メカニズム
マシンSIDの重複による認証エラーは、Windowsが採用する複数の認証メカニズムのうち、特にSIDを識別情報として参照する方式に影響を及ぼします。Windowsネットワークでは、ユーザーやマシンを特定する際にSID（Security Identifier）を用いて整合性を検証しており、このSIDが重複していると、認証トークンやチケットの検証に失敗します。
特に影響が顕著なのは、ドメイン環境で利用される Kerberos 認証 と、ワークグループ環境や一部のレガシーシステムで用いられる NTLM 認証 の2種類です。いずれもマシンSIDを認証情報の一部として扱うため、重複したSIDを持つマシン間では「同一マシンである」と誤認されるか、逆に「信頼できない別マシン」として扱われ、認証に失敗します。
以下では、それぞれの認証メカニズムがどのような仕組みで動作し、どのようにマシンSID重複の影響を受けるのかを解説します。
Kerberos認証
Kerberos認証は、Windowsドメイン環境において標準的に使用されているチケットベースの認証方式です。Active Directory（AD）ドメインコントローラ上の認証サービス（KDC: Key Distribution Center）が中心的な役割を担い、ユーザーおよびマシンの身元をチケットの発行によって保証します。
認証の基本的な流れは、クライアントがKDCに対して認証要求を行い、KDCがクライアントのSIDを含む認証チケット（TGT: Ticket Granting Ticket）を発行するというものです。以後の通信では、このチケットを提示することで、クライアントは再度パスワードを送信することなくサーバーリソースへのアクセスを行うことができます。この仕組みにより、Kerberosは高いセキュリティと効率性を両立しています。
しかし、マシンSIDが重複している環境では、この認証フローが破綻します。Kerberosチケットには、マシンのSIDをもとにした識別情報が含まれており、KDCはこれを照合してクライアントの一意性を検証します。もし複数のマシンが同一SIDを共有している場合、KDCはチケットの発行または更新時に整合性を確認できず、認証を拒否することがあります。その結果、ドメインログオンの失敗、リモートデスクトップ（RDP）接続の拒否、SMB共有へのアクセス不能といった事象が発生します。
特にWindows 11以降では、セキュリティモデルが強化され、チケット発行時のSID検証がより厳密に実施されています。そのため、従来のようにマシンSID重複が黙認されるケースは減少し、SIDの整合性が保証されない環境ではKerberos認証そのものが成立しなくなっています。
要するに、Kerberos認証は「一意なマシンSIDを前提とした信頼関係の上に成り立つ仕組み」であり、この前提が崩れると、ドメイン環境におけるあらゆる認証・アクセス制御が機能しなくなるという点に注意が必要です。
H3: NTLM認証
NTLM（NT LAN Manager）認証は、Kerberosが導入される以前からWindowsで使用されてきたチャレンジ・レスポンス方式の認証プロトコルです。現在でも、ワークグループ環境や一部のレガシーシステム、Kerberosが利用できないネットワーク経路においては、後方互換性のために引き続き使用されています。
NTLM認証は、ユーザーのパスワードを直接送信せず、ハッシュ値を用いてサーバー側とクライアント側で相互に整合性を確認することで成り立っています。クライアントがログオン要求を送信すると、サーバーはランダムなチャレンジ値を返し、クライアントはパスワードハッシュを基にレスポンスを計算します。サーバー側では同様の計算を行い、結果が一致すれば認証が成立します。この仕組みにより、平文パスワードがネットワーク上に流れないという利点があります。
しかし、NTLMは設計上、認証の文脈をSID（Security Identifier）に強く依存しています。特に、マシンアカウントやローカルセキュリティコンテキストを用いた認証では、マシンSIDが認証トークンの生成および検証に関与します。そのため、複数のマシンが同一のSIDを共有している場合、サーバー側ではどのクライアントが本来のリクエスト元であるかを識別できず、結果として「資格情報が無効」「認証に失敗しました」といったエラーを返すことになります。
この問題は特に、SMB（Server Message Block）を利用したファイル共有やプリンタ共有など、NTLM認証を前提とする通信で顕著に現れます。Windows Update（例：KB5065426）以降では、セキュリティ検証が強化されたことにより、同一SIDを持つマシン間でのNTLM認証が明示的に拒否されるようになりました。その結果、従来は動作していた共有フォルダへの接続やリモートリソースのアクセスが突然不能になる事例が多数報告されています。
つまり、NTLM認証においてもKerberosと同様に、マシンSIDの一意性は前提条件です。SIDが重複した環境では、認証トークンの信頼性が損なわれ、ネットワーク越しの認証全体が破綻します。現行のWindowsでは、このような構成がセキュリティ上「不正な状態」として検出されるようになっており、今後はNTLMベースの環境でもSysprepによるSID初期化が不可欠となっています。
どのように対策すべきか
マシンSIDの重複による認証失敗は、Windowsの設計そのものに起因する構造的な問題であるため、根本的な対策は「各マシンが一意のSIDを持つように構成を見直すこと」に尽きます。特に、Sysprepを用いずにディスクイメージや仮想マシンを複製している場合は、展開プロセスの修正が必要です。以下に、代表的な対策手順と運用上の注意点を示します。
1. Sysprepを用いたイメージの一般化
最も基本的かつ確実な対策は、Sysprep（System Preparation Tool）による一般化（/generalize）を実施することです。
Sysprepを実行すると、マシンSIDを含む固有情報が初期化され、次回起動時に新しいSIDが自動的に生成されます。これにより、複数のマシンが同一イメージから展開されたとしても、それぞれが固有の識別子を持つ状態になります。
実行例（管理者権限のコマンドプロンプトで実行）：
sysprep /generalize /oobe /shutdown/generalize はSIDを初期化するオプション、/oobe は初回セットアップ画面を有効化するオプションです。Sysprep実行後に取得したイメージをテンプレートとして利用すれば、安全に複製展開が可能になります。
2. 既存環境でのSID確認と再展開の検討
すでに多数の端末や仮想マシンを展開済みの場合、まず現状のSIDを確認し、重複が存在するかを把握することが重要です。SIDはSysinternalsツールの PsGetSid や PowerShellコマンドを用いて確認できます。
例：
PsGetSid.exeまたは
Get-WmiObject Win32_ComputerSystemProduct | Select-Object UUIDもし同一SIDのマシンが複数確認された場合、再度Sysprepを実施してSIDを再生成するか、OSを再インストールすることが推奨されます。SIDの一部のみを変更する非公式ツールやレジストリ操作は、セキュリティデータベースとの不整合を引き起こす可能性があるため避けるべきです。
3. テンプレートおよび自動展開手順の見直し
仮想化基盤やクローン展開を行う運用では、テンプレート作成時点でのSysprep実施を標準化することが不可欠です。特にVDI環境、Hyper-VやVMwareでのゴールデンイメージ管理、またはクラウド上の仮想マシン展開（Azure、AWSなど）においては、イメージ作成後の「一般化」を怠ると、すべてのインスタンスが同一SIDを共有するリスクがあります。
運用ルールとして、イメージ化前に /generalize を含むSysprep実行を義務化し、テンプレート更新時にその状態を維持することが望ましいです。
4. 一時的な回避策（推奨されない方法）
Microsoftは一部の環境向けに、重複SIDチェックを一時的に無効化するグループポリシーやレジストリ設定を案内しています。しかし、これらはあくまで暫定的な回避策であり、セキュリティリスクを伴います。SID重複自体は解消されないため、将来的な更新で再び認証エラーが発生する可能性が高く、恒久的な解決策にはなりません。
根本的な修正を行うまでの一時的措置としてのみ利用すべきです。
5. 運用ポリシーと検証プロセスの整備
今回の問題を教訓として、イメージ配布やシステム複製のプロセスを運用ポリシーとして明文化し、更新や配布前に検証を行う体制を整えることが望まれます。
特に以下の点を定期的に確認することが効果的です。
- テンプレート作成時にSysprepが確実に実行されているか。
- 展開済みのマシンでSIDが重複していないか。
- 新しいWindows更新プログラムの適用後に認証エラーが発生していないか。
まとめ
マシンSID重複による認証失敗は、Windows 11以降のセキュリティ強化によって顕在化した構成上の不備です。最も有効な対策は、Sysprepによるイメージの一般化を徹底することです。既存環境では、SIDの重複を早期に検出し、再展開やテンプレート修正を通じて正常な識別体系を再構築することが求められます。
運用の効率化とセキュリティの両立のためには、イメージ管理手順を体系的に見直し、SID一意性の確保を組織的な標準として維持することが不可欠です。
おわりに
マシンSIDの重複は、Windowsの仕組み上、古くから存在する潜在的な問題でした。しかし、Windows 11以降の更新プログラムにおいて認証処理の厳格化が進んだ結果、これまで見過ごされてきた構成上の不備が明確な障害として顕在化しました。特に、KerberosやNTLMといったSIDに依存する認証方式においては、重複したSIDを持つマシン間で認証トークンの整合性が失われ、ログオンや共有アクセスの失敗といった深刻な影響が発生しています。
この問題の根本原因は、Sysprepを用いずにディスクイメージや仮想マシンを複製することにあります。Sysprepを実行せずに展開された環境では、複数のマシンが同一の識別子を持つことになり、Windowsのセキュリティモデルが前提とする「一意なSIDによる信頼関係」が崩壊します。その結果、認証基盤が正しく機能しなくなるのです。
対策としては、イメージ展開時に Sysprepの/generalizeオプションを必ず実行すること、および既存環境でSID重複が疑われる場合には PsGetSidなどを用いて確認し、再展開または再構成を行うこと が推奨されます。また、仮想化や自動デプロイを行う運用環境では、テンプレート作成時に一般化プロセスを標準化し、再利用するすべてのイメージが一意のSIDを生成できる状態であることを保証することが重要です。
本件は、単なる一時的な不具合ではなく、Windowsのセキュリティ設計の根幹に関わる構成管理上の問題です。今後の環境構築においては、効率性だけでなく、SIDの一意性を含むセキュリティ整合性の維持を重視した運用へと移行することが求められます。
参考文献
- Kerberos and NTLM authentication failures due to duplicate SIDs
https://support.microsoft.com/en-us/topic/kerberos-and-ntlm-authentication-failures-due-to-duplicate-sids-76f7394d-c460-4882-9ed1-d27e0960f949 - The SID debate: To Sysprep or not to Sysprep
https://www.infoworld.com/article/2300705/the-sid-debate-to-sysprep-or-not-to-sysprep.html - Windows: Network login problems with cloned SIDs
https://www.heise.de/en/news/Windows-Network-login-problems-with-cloned-SIDs-10794484.html - Mark Russinovich explains “the machine SID duplication myth”
https://www.markwilson.co.uk/blog/2009/11/mark-russinovich-explains-the-machine-sid-duplication-myth.htm
