Windows 11でKerberos認証エラー「Cannot generate SSPI context」が発生する理由と解決策｜MSSQLSvc SPNとポート指定の落とし穴
Windows環境でSQL Serverへ接続する際、Kerberos認証が原因で接続エラーが発生するケースは少なくありません。特にWindows 11のセキュリティ強化環境では、従来問題なく動作していた構成でも突然接続できなくなることがあります。
本記事では、Windows 11クライアントからSQL Serverへ接続する際に発生する「Cannot generate SSPI context」エラーの原因と、その背後にあるKerberos認証およびSPN（Service Principal Name）の挙動について詳しく解説します。さらに、実際の検証から見えてきた解決方法や運用時の注意点も整理します。
Windows 11環境で発生するSQL Server接続エラー
Windows 11クライアントからSQL Serverへ接続する際、SQL Server Management Studio（SSMS）で以下のようなエラーが表示される場合があります。
「The target principal name is incorrect. Cannot generate SSPI context」
このエラーはKerberos認証の失敗によって発生する典型的なメッセージです。特に以下のような環境で発生しやすくなります。
・Windows 11クライアント
・セキュリティベースラインGPOを適用
・Credential Guard有効
・RC4暗号無効化
・SHA1 PKINIT無効化
興味深い点として、同じGPOを適用しているWindows 10クライアントでは問題が発生しないケースがあることです。また、Windows 11でもセキュリティ強化を行っていない場合は正常に接続できます。
つまり、Windows 11のセキュリティ仕様とKerberos認証の組み合わせが、この問題の鍵となっています。
klistコマンドで確認できるKerberosチケットエラー
Kerberos認証の問題を調査する際、よく利用されるのが「klist」コマンドです。
Windows 11の問題が発生する環境では、次のコマンドを実行するとエラーが確認できます。
klist get MSSQLSvc/my.fully.qualified.name:1433
実行結果として次のエラーが表示されます。
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x3bc4
Hash generation for the specified version and hash type is not enabled on server.
このメッセージは、Kerberosチケット生成時に指定されたハッシュアルゴリズムがサーバー側で有効になっていない可能性を示しています。
しかし、実際には環境内でAES-256によるKerberosチケットとセッションキーは正常に交渉されています。そのため、単純な暗号方式の不一致とは考えにくい状況です。
SPNのポート指定で挙動が変わる謎
調査を進めると、さらに不可解な現象が確認されます。
以下のSPNではチケット取得に失敗します。
MSSQLSvc/my.fully.qualified.name:1433
一方、ポート番号を省略したSPNでは正常にチケットが取得できます。
MSSQLSvc/my.fully.qualified.name
つまり同じサービスアカウントに登録されているSPNであっても、ポート指定の有無でKerberos認証の結果が変わるのです。
さらに、接続文字列でServerSPNをポート無しのSPNに指定すると、SSMSからの接続も成功します。
この現象はSPN登録ミスのように見えますが、setspnコマンドで確認するとポート付きSPNも正しく登録されています。
Active Directory設定の確認ポイント
この問題を切り分ける際、以下の設定を確認することが重要です。
SPN登録状態
まず、対象SQL ServerのSPNがActive Directoryに正しく登録されているかを確認します。
setspn -Q MSSQLSvc/my.fully.qualified.name
setspn -Q MSSQLSvc/my.fully.qualified.name:1433
両方が同じサービスアカウントに紐づいている必要があります。
Kerberos暗号方式
Active Directoryの属性「msDS-SupportedEncryptionTypes」も確認ポイントです。
一般的な設定例は以下です。
28（AES128 + AES256）
この設定により、KerberosチケットはAES暗号を利用して発行されます。
gMSAのパスワード更新
SQL ServerがgMSA（Group Managed Service Account）を使用している場合、パスワードローテーション後のSPN動作も確認する必要があります。
ただし今回のケースでは、パスワード更新後でも状況は変わらなかったため、直接の原因ではありませんでした。
Windows 11セキュリティポリシーの影響
問題の根本原因として疑われるのが、Windows 11で強化されたKerberos関連ポリシーです。
特に影響が考えられる設定が以下です。
Configure hash algorithms for certificate logon
このポリシーは、KerberosのPKINIT（証明書ベース認証）で使用されるハッシュアルゴリズムを制御します。SHA-1を無効化するなどのセキュリティ強化が可能です。
ただし、この設定は本来スマートカード認証などの証明書ログオン用途に限定されます。通常のKerberosサービスチケット取得とは直接関係しないため、挙動の違いが生じる理由は環境依存の可能性があります。
実用的な回避策
現時点で有効とされる回避策はいくつかあります。
ポート無しSPNを使用する
接続文字列やSQL Serverの設定でServerSPNを以下の形式に変更します。
MSSQLSvc/my.fully.qualified.name
これによりKerberosチケット取得が正常に行われる場合があります。
Kerberosポリシーの確認
以下のGPO設定を確認します。
System\KDC
System\Kerberos
特に証明書ログオン関連のハッシュアルゴリズム設定が影響していないかチェックします。
セキュリティベースラインの再評価
Windows 11 Security Baselineをそのまま適用すると、Kerberos関連の互換性問題が発生することがあります。SQL Server環境では以下の点を見直す価値があります。
・RC4無効化の影響
・PKINIT関連ポリシー
・Credential Guardとの相互作用
まとめ
Windows 11のセキュリティ強化により、Kerberos認証の挙動が従来のWindows 10とは異なるケースが確認されています。特にSQL Server接続においては、SPNのポート指定によってチケット取得結果が変わるという予想外の現象が起きることがあります。
重要なポイントは次の通りです。
・Windows 11ではKerberosのポリシー影響を受けやすい
・SPNはポート指定の有無で挙動が変わる場合がある
・klistでチケット取得を検証すると原因切り分けがしやすい
・回避策としてポート無しSPNを利用できる
企業環境でWindows 11への移行を進める場合、Active DirectoryとKerberosの設定確認は必須です。特にSQL ServerなどKerberos認証に依存するシステムでは、事前検証を行うことで予期しない接続トラブルを防ぐことができます。
