VPN は接続できても SQL Server が Windows 認証を拒否する

トンネルは上がり、サーバーは ping に応答するのに、データベースへのログインは認証エラーで失敗し続けます。この組み合わせは VPN 接続ではよくあることで、ネットワークが壊れていることを意味するとは限りません。到達できるリスナーと受け入れられたログインは別の結果だからです。ゲートウェイを満たした ID が、データベースクライアントが提示する ID とは限りません。どのアカウントが届いたのかを突き止めることが、この作業のすべてです。

症状：サーバーには届くがログインが拒否される

タイムアウトは、パケットがどのリスナーにも届かなかったことを示します。認証エラーは、リスナーが応答して資格情報を拒否したことを示します。この二つのメッセージは別のチームへ回すもので、混同すると問題でもなかったファイアウォール規則に一日を費やすことになります。

エラーがログイン失敗なら、ポートを見るのはやめてください。残る問いは、クライアントがどの Windows ID を提示したのか、サーバーがその ID を受け入れたのか、そしてそれが権限を持つデータベースユーザーに解決されたのかどうかです。

二つの ID、一つのトンネル

VPN アカウントはゲートウェイで認証され、多くの配備ではそこで終わります。データベースクライアントは別に Windows トークンを提示します。これはそれを実行するプロセスから取得されるもので、接続文字列が求める場合は SQL ログインを提示します。ゲートウェイ内のローカル VPN ユーザーは SQL Server をホストするドメインと何の関係もなく、トンネルがその関係を作ることもありません。

個人のマシンを VPN に接続しても、ドメインに参加するわけではありません。ローカルアカウントの名前を変えてパスワードをドメインユーザーに合わせても、参加手続きにはならず、ドメインコントローラーがそのユーザーとして受け入れないトークンが生成されます。

一部の Windows ネイティブのリモートアクセス クライアントは、プロファイルがそのように構成されていれば、ネットワークリソースに対して VPN 資格情報を再利用できます。その動作は特定のクライアントとプロファイルに属するもので、VPN 接続全般の性質ではありません。想定せずに、使用中のクライアントで確認してください。

クライアントが要求したモードを読む

接続文字列が、クライアントが取る認証経路を決めます。統合セキュリティは Windows トークンを使い、ユーザー名とパスワードの組は SQL ログインを選びます。これらはサーバー構成上の別々のモードで、特定の接続試行ではどちらか一方しか有効にできません。

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Windows ログインが失敗したからと SQL ログインに切り替えるのは、ID の問いを隠す回避策で、通常は新しいログインとパスワードの作成が結局必要になります。配備が Windows 認証を要求するなら、モードを維持したまま ID の経路を直してください。SQL ログインにも独自の権限が要るので、回避策は維持すべき二つ目のアカウントを買うことになります。

どのアプリケーションが接続しているかも確認してください。システムアカウントで動くサービス、スケジュールされたタスク、対話的なクエリウィンドウは、同じマシン上で三つの異なるトークンを提示することがあり、最後の一つだけがユーザーが whoami を実行したときに見るものと一致します。

サーバーが実際に何を見たのかを尋ねる

サーバーは、どのログインを解決したのか、接続がどう認証されたのかを教えてくれます。調査対象のセッションの内側でクエリを実行してください。管理者の別の成功した接続は、失敗しているクライアントについて何も証明しません。

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

最初の行は、セッションを開いたログインと現在有効なセキュリティコンテキストを区別します。この二つは偽装の下では異なります。二番目は認証スキームを示すので、KERBEROS、NTLM、SQL は推測ではなく目に見える事実になります。Kerberos を期待した場所で NTLM を報告する接続は、パスワードの問題ではなく、名前解決か SPN の問題です。

エラー番号でさらに絞れます。状態 5 は通常ログイン名がまったく解決されなかったことを、状態 8 は通常パスワードが一致しなかったことを、状態 11 は資格情報が受け入れられたがサーバーへのアクセスが失敗したことを意味します。メッセージ全体ではなく状態を管理者に尋ねてください。メッセージだけでは意図的に曖昧です。

ID が届いても Kerberos が失敗し続ける場合

サーバーが意図した Windows ID を見ていて統合認証がまだ失敗するなら、問題は交換そのものにあります。Kerberos には SQL サービスアカウントに登録されたサービスプリンシパル名と、それに一致する名前でサービスを要求するクライアントが必要です。IP アドレスでの接続は名前ベースの SPN に一致できず、エイリアスはそれも登録されている場合にだけ一致できます。まずクライアントが入力した名前を確認してください。ホスト名では動き IP では失敗する接続は、まさにこの問題を表しています。

管理者には、試行錯誤で重複した SPN を作るのではなく、登録済みの ID とサービスアカウントを見直すよう依頼してください。重複登録は断続的な障害を生み、元の問題より診断が難しくなります。

認証が通った後も、ログインにはデータベースユーザーと権限が必要です。VPN ログインの成功、Windows ログインの成功、特定のテーブルを読む権限は三つの別々の結果であり、チケットを閉じる前にそれぞれを個別に確認する価値があります。