VPN 経由の SQL Server が今でも NTLM にフォールバックするのはなぜか

接続は機能し、ログインも受け入れられているのに、全員が Kerberos を期待していたところで SQL Server は NTLM を使っています。この結果は VPN の欠陥ではありません。トンネルは経路を提供するだけであり、スキームを決めたのはクライアントが要求した名前、ディレクトリに登録されたプリンシパル、そしてクライアントが実際に取得できたチケットです。三つの条件が同時に成立する必要があり、どれが譲ったかはセッション自体が語ります。誰かがサービス プリンシパル名を編集する前に、それを読んでください。

セッションは実際に得られたスキームを示す

認証スキームはサーバーやトンネルではなく接続に属するため、確認は対象のセッションの内側で実行する必要があります。レポートを生成したのと同じクライアント、ツール、アカウントから下のクエリを実行し、結果の横にターゲット名とトランスポートを記録してください。

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

データベース ホスト上のローカル SSMS ウィンドウから得た行はまったく別の接続を表すので、クエリはクライアント側から実行しなければなりません。出力はタイムスタンプとともに保存してください。次に読む人はいつ取得したのかを尋ねるからです。複数のアプリケーションが一つのエンドポイントを共有する場合は、それぞれからサンプルを取ってください。二つのアプリケーション間のデータ ソースの違いが、しばしば物語のすべてだからです。

第一の条件: 名前は SPN と一致するか

Kerberos は名前付きサービスを認証するため、クライアントは特定のプリンシパルに対するチケットをディレクトリに要求します。TCP プロバイダーの文書化された形式は MSSQLSvc/ に完全修飾ホスト名が続き、既定のインスタンスではポートも続きます。名前付きインスタンスは MSSQLSvc/db01.corp.example:SQLPROD を登録し、接尾辞は番号ではなくインスタンス名になります。別名、別の場所で解決される CNAME、裸の IP アドレス経由でリスナーに到達すると要求名が変わり、一致するプリンシパルのない要求には返すチケットがありません。

あるアプリケーションは一方のネットワークで動作し、もう一方ではフォールバックするのはそのためです。DNS の応答、別名レコード、hosts のエントリがクライアントの使った名前を変えていたのです。登録に触れる前に、要求名とディレクトリが保持している名前を比較してください。

第二の条件: SPN は正しいアカウントにあるか

SPN は SQL サービスを実行するアカウントに属する必要があり、クライアントのアカウントや、偶然にコンピューター オブジェクトに属してはいけません。SQL Server は、サービス アカウントに書き込み権限があれば起動時に自身の SPN を登録できます。これは便利であり、サービス アカウントの変更後に重複が現れる仕組みでもあります。

期待する名前をディレクトリに問い合わせ、次にそのアカウントが実際に所有しているものを一覧にしてください。どのオブジェクトがエントリを保持しているかは、名前がフォレストのどこかに存在するかより重要です。不一致はログインが問題ではなかったことを意味し、Microsoft の SPN ガイド は形式と、ドメイン管理者がエントリを作成しなければならないケースを文書化しています。

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

別のエントリを追加することは安全な実験ではありません。重複や競合する登録は、動作していたクライアントを壊す可能性があるため、変更前に所有権を確認し、変更後にも再確認してください。

第三の条件: クライアントはそもそもチケットを取得できるか

クライアントがドメイン コントローラーに到達できない、または使える資格情報コンテキストがない場合、正しい SPN は無意味です。交換には VPN 経由の KDC と DNS が必要で、SQL ポートだけをルーティングするトンネルはまさにこの段階で失敗します。到達性は、目の前のファイアウォールからではなく、同じマシンと同じアカウントから検証しなければなりません。

マシン上と、アプリケーションを実行するアカウントの下でチケット キャッシュを調べてください。昇格したウィンドウからのマシン全体の一覧は、別のユーザーとして動作するサービスについて何も語りません。そのユーザーのキャッシュが空であることは、不便ではなく発見です。

klist
klist -li 0x3e7

次に、フォールバックが何をしてよいかを決めます。ポリシーが Kerberos を要求するなら、NTLM は明示的に拒否しなければなりません。黙ったフォールバックは構成エラーを、要件に違反する動作中の接続に変えてしまうからです。一部のアプリケーションで NTLM が許容されるなら、それらを名指しし、すべての NTLM セッションをインシデントとして扱うのをやめてください。

起動方法の変更は一つの変数であり、修正ではない

別の資格情報で SSMS を起動すると、意図しない送信 ID を治せる場合があり、それは実際に存在する問題の分類です。ただしターゲット名、登録、チケットの経路については何も証明せず、サーバーが受け入れたものも変えません。

比較は統制してください。同じエンドポイント、同じプロバイダー、既知の実行コンテキストで、そのうえでスキームを調べる新しい接続を確立します。受け入れられたログインとそのデータベース権限は別々に確認してください。アクセスと認証は異なる理由で失敗します。

Kerberos が必須の場合は、最初の経路がなぜフォールバックしたかを記録し、修正を一つ適用して、同じクライアントからクエリを再実行します。起動方法の変更後にクエリが成功したことはアクセスの証拠であり、認証要件が満たされた証拠にはまだなりません。