Azure VM/AVDからオンプレSQL ServerリンクサーバーでANONYMOUS LOGONになる原因と対処（Credential Guard・デリゲーション）

Azure VM や Azure Virtual Desktop（AVD）からオンプレミスの SQL Server に SSMS で接続すると、通常接続は成功するのに「リンクサーバーのテスト接続」だけが NT AUTHORITY\ANONYMOUS LOGON で失敗する――。本記事では、SPN やデリゲーション設定が一見正しく見えても解消しない理由を、Kerberos のダブルホップと Credential Guard の観点から整理し、現場で迷わない確認手順と解決策（推奨構成まで）をまとめます。

よくある症状：通常接続はOK、リンクサーバーだけが失敗する

今回のパターンは、ネットワーク疎通や SQL の基本設定の問題に見えにくいのが厄介です。ポイントは「1ホップは通るが、2ホップ目で崩れる」ことです。

シナリオ	クライアント	SQL への通常接続	リンクサーバー（テスト接続 / クエリ）	代表的なエラー
シナリオ1	オンプレ VM 上の SSMS	問題なし	問題なし	―
シナリオ2	Azure VM / AVD 上の SSMS	問題なし	テスト接続のみ失敗（またはリンク経由が不安定）	`The test connection to the linked server failed.` `Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.` `OLE DB provider "SQLNCLI11" ... "Invalid connection string attribute".`

SQL Server 側ログで、Azure 側からの経路だけ NTLM（しかも NTLM v1 が混在）しているのが見えた場合、かなり強いヒントになります。リンクサーバー経由の認証は「委任（デリゲーション）」が絡むため、Kerberos の成立条件が少しでも崩れると ANONYMOUS LOGON に転びやすいからです。

最重要の考え方：リンクサーバーは「ダブルホップ」になりやすい

SSMS での通常接続は、基本的に「クライアント → SQL Server」の 1ホップです。一方、リンクサーバーは、クエリ実行の流れが次のようになりがちです。

処理の流れ	ホップ数	求められる条件	崩れたときの典型
SSMS → リンク元 SQL に Windows 認証で接続	1ホップ	Kerberos または NTLM でログイン成立	通常接続自体が失敗することもある
リンク元 SQL → リンク先 SQL に「利用者の資格情報」で接続（委任）	2ホップ	Kerberos + デリゲーション（SPN/委任/チケットが揃う）	リンク先が利用者を匿名として扱い `ANONYMOUS LOGON`

つまり、通常接続が成功しても「リンクサーバーだけ失敗」は十分あり得ます。特に、リンクサーバーのテスト接続は “リンク元 SQL がリンク先へ代理で接続できるか” を直接叩くため、ダブルホップ問題が露呈しやすい傾向があります。

今回の結論：Credential Guard 有効 × 無制限委任（unconstrained delegation）が噛み合っていなかった

事象の整理は次の通りです。

SQL Server のサービスアカウントは「ドメインアカウント」と「MSA（Managed Service Account）」が混在
それらの SQL サービスアカウントに 無制限委任（フルデリゲーション / unconstrained delegation） が設定されていた
一方で、Azure VM / AVD 側（あるいは関連する中継側）に Credential Guard が有効化されていた

ポイント
Credential Guard が有効な環境では、無制限委任で期待する形の「資格情報の委任」が成立しません。結果として、クライアント（Azure VM / AVD）→ リンク元 SQL → リンク先 SQL のダブルホップで、リンク先が利用者を NT AUTHORITY\ANONYMOUS LOGON として扱う状態になります。

そのため、個別接続（1ホップ）は正常だが、リンクサーバー（2ホップ目）だけが失敗という、現場で最も混乱しやすい形になっていました。

「Invalid connection string attribute」は主因ではないことが多い

エラーに Invalid connection string attribute が混じると、リンクサーバーの「プロバイダー文字列」や「プロバイダー設定」を疑いたくなります。もちろん設定不備が原因のケースもありますが、今回のように同時に ANONYMOUS LOGON が出ている場合は、まず認証（委任）の破綻を疑うのが近道です。

実務的には、次の順で切り分けると迷いが減ります。

同じリンクサーバー定義で、クライアント環境だけ変えて再現するか
リンク元 SQL の接続が Kerberos か NTLM か（auth_scheme）
ダブルホップが成立しているか（リンク先で誰として見えているか）
Credential Guard / Remote Credential Guard / 制約ポリシーの影響を確認
最後にプロバイダー（SQLNCLI11 等）やプロバイダー文字列を見直す

まずはここを確認：失敗している“場所”を特定するチェック手順

リンク元 SQL への接続が Kerberos になっているか（最初の1ホップ）

Azure VM / AVD 上の SSMS からリンク元 SQL に接続後、リンク元 SQL で次を確認します。

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

期待値は auth_scheme = KERBEROS です。ここが NTLM の場合、ダブルホップ以前に「そもそも Kerberos で入れていない」可能性が高く、リンク先で匿名化しやすくなります。

リンク先 SQL では誰として見えているか（2ホップ目の実態）

リンク元 SQL からリンク先へ問い合わせ、リンク先側の接続情報（誰としてログインしているか）を確認します。環境により書き方は変わりますが、考え方は「リンク先で見えているログインを取る」です。

EXEC ('SELECT SYSTEM_USER AS system_user, ORIGINAL_LOGIN() AS original_login;') AT [リンクサーバー名];

ここで NT AUTHORITY\ANONYMOUS LOGON 相当の挙動や、想定ユーザーが出てこない場合、委任が崩れています。

Azure / AVD 側で“委任できないチケット”になっていないか

クライアント（Azure VM / AVD）上で、チケット取得状況を確認します。

klist
klist sessions

ここで「チケットがある」だけでは安心できません。Credential Guard や RDP の設定によっては、委任に使えない形での認証になっていることがあります（例：ダブルホップに必要な委任ができない）。

Credential Guard が有効かどうか（現場での見分け方）

最短での見分けは次のいずれかです。

システム情報（msinfo32） の「デバイスガード」関連の表示
PowerShell で Device Guard / Credential Guard の状態を確認

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

AVD のセッションホストは、セキュリティベースライン適用で Credential Guard が有効になっていることがあります。また、RDP 側の機能（Remote Credential Guard）によっても「資格情報の扱い」が変わるため、AVD 特有の差分として要注意です。

“Azure側で追加で見るべき”チェックポイント（AVD含む）

SPN やデリゲーションが一通り揃っているのに Azure VM / AVD だけ失敗する場合、オンプレと Azure で差が出やすいのは「認証の前提条件」と「セキュリティ機能・ポリシー」です。以下を上から順に確認すると整理しやすいです。

チェック項目	見る理由	確認の目安	崩れていると起きやすいこと
ドメイン参加形態（Domain Join / Hybrid Join など）	Kerberos 前提が崩れると NTLM へフォールバックしやすい	Azure VM / AVD がオンプレ AD と整合して参加しているか	通常接続は通るが、リンクサーバーで匿名化
DNS（特に SQL 名が正しく解決されるか）	SPN と名前解決がズレると Kerberos が成立しにくい	FQDN/短縮名/エイリアスの使い分けを統一	Azure 経路だけ NTLM になる
時刻同期	Kerberos は時刻ずれに弱い	Azure VM/AVD/オンプレ全体で整合	Kerberos 失敗 → NTLM へ
NTLM 制限ポリシー（NTLMv1 混在など）	環境差で認証方式が変化する	Azure 側だけ LAN Manager レベルや制限が異ならないか	ログに NTLMv1 が出る / ダブルホップが失敗
Credential Guard / Remote Credential Guard	無制限委任や資格情報の扱いを変えるため、ダブルホップに直撃	AVD セッションホスト・クライアント双方の設定を確認	リンク先が ANONYMOUS LOGON になる
“委任不可”なユーザー属性	ユーザー側属性でも委任を止められる	「委任不可」「保護されたユーザー」等に該当しないか	特定ユーザーだけリンクサーバーが失敗

実際に有効だった対処：Credential Guard を無効化すると復旧した

今回のケースでは、Credential Guard を無効化したことで、Azure VM / AVD からのリンクサーバーのテスト接続とデータ取得が正常化しました。現場感としては、次のような「条件が揃っているのにダメ」が解消されます。

SPN が登録されている（重複もない）
SQL サービスアカウント／コンピューターアカウント側の委任設定も済んでいる
klist 上は Kerberos チケットが見える
時刻同期も問題ない
それでも Azure VM / AVD 経路だけリンクサーバーが ANONYMOUS LOGON

ただし、Credential Guard の無効化はセキュリティ要件とトレードオフになります。運用・監査要件が厳しい環境では「無効化で解決」は採りづらいことも多いため、次の推奨案が現実的です。

推奨される代替案：制約付きデリゲーション（Constrained Delegation）へ移行する

Credential Guard を有効に保ったまま、リンクサーバー（ダブルホップ）を成立させたい場合は、設計を「無制限委任」依存から外すのが基本方針です。実務上の落としどころは次のいずれかです。

選択肢	概要	メリット	注意点
制約付きデリゲーションへ変更	委任先（リンク先 SQL の SPN）を明示して最小権限で委任	セキュリティ要件に合わせやすい／設計が説明しやすい	委任先 SPN を漏れなく登録・更新する運用が必要
リソースベースの制約付きデリゲーション（RBCD）	委任を「委任される側」で制御するモデル	権限委譲や運用設計によっては管理しやすい	構成理解が必要／適用範囲の整理が必須
リンクサーバーのセキュリティを「固定資格情報」にする	「このセキュリティコンテキストで接続」を使い、委任を回避	ダブルホップ自体を回避できる	監査・権限制御の設計が必要（誰が実行しても同一資格情報になる）

制約付きデリゲーション移行の実務手順（やることを具体化）

制約付きデリゲーションの作業は、抽象論だと迷子になりがちです。現場での手順を「決める → 設定する → 検証する」に落とします。

決める：どのアカウントが“委任する主体”か

リンクサーバーで 2 ホップ目の接続を発生させるのは、通常 リンク元 SQL Server の SQL サービスアカウントです。したがって、委任設定の主対象は以下になります。

リンク元 SQL Server の SQL Server サービスが動いているアカウント（ドメインユーザー / MSA / gMSA）
（構成によって）リンク元 SQL Server のコンピューターアカウント

設定する：委任先としてリンク先 SQL の SPN を明示する

Active Directory 上で対象アカウントの「委任」設定を、次の方向へ寄せます。

「任意のサービスへの委任を許可（無制限）」ではなく、「指定したサービスにのみ委任を許可（制約付き）」へ
委任先に リンク先 SQL Server のサービス（MSSQLSvc の SPN）を追加

リンク先が複数インスタンス／ポート／名前（短縮名と FQDN）を持つ場合、SPN の表現ゆれが原因でハマります。次の観点で “必要な SPN が網羅されているか” を確認します。

観点	例	抜けると起きること
FQDN と短縮名	`server01.contoso.local` と `server01`	Azure 側の名前解決差で Kerberos が成立しない
既定ポート / 名前付きインスタンス	1433 / 動的ポート	一部の経路・一部の接続だけ失敗
重複 SPN	別アカウントに同一 SPN が登録されている	Kerberos が不安定化し NTLM フォールバック

検証する：テスト接続の前に“auth_scheme”で合否を見切る

リンクサーバーの「テスト接続」だけを繰り返すと、状況が整理しにくくなります。次の順で「どこまで Kerberos が成立しているか」を見ながら進めるのが安定です。

Azure VM / AVD → リンク元 SQL：auth_scheme = KERBEROS を確認
リンク元 SQL → リンク先 SQL：リンク先で “誰として見えるか” を確認
最後に SSMS の「テスト接続」や実クエリ（OPENQUERY / 4部構成名）を確認

SQLNCLI11 を使っているなら、将来を見据えてプロバイダーも見直す

今回の本筋は認証（委任）ですが、リンクサーバーで SQLNCLI11 を使っている環境では、後々の OS 更新や暗号スイート更新で別の不具合に遭遇しやすくなります。可能であれば、組織の標準に沿って OLE DB ドライバー（Microsoft の新しい OLE DB Driver for SQL Server）への移行計画を持っておくと、長期運用が楽になります。

ただし、プロバイダーを変えてもダブルホップの本質は消えません。まずは Kerberos とデリゲーションの成立（特に Credential Guard の影響）を解消し、その後にプロバイダーや接続オプションを整える順番が安全です。

調査を高速化する：sqlcheck ユーティリティで“論点”を一気に洗う

SPN・デリゲーション・認証方式（Kerberos/NTLM）を手作業で追うと、環境が大きいほど見落としが増えます。今回の原因特定では、Microsoft の sqlcheck ユーティリティが有効でした。

現場で役に立つのは、次のような“論点をまとめて可視化する”使い方です。

接続経路ごとの認証方式の傾向（Kerberos になっているか / NTLM に落ちていないか）
SPN の登録状況と矛盾（不足・重複）
委任設定の状態（無制限委任に依存していないか、制約付きへ移行できるか）

「設定は全部やったはずなのに…」という局面ほど、ツールのまとめ表示が効きます。今回も、Credential Guard と無制限委任の組み合わせがボトルネックになっていることを早期に絞り込めました。

再発防止の設計ポイント：Azure/AVD を足した瞬間に破綻しないために

結論から設計する：ダブルホップを許すなら“制約付き”を基本にする

Azure VM や AVD を導入すると、セキュリティベースラインや VBS（仮想化ベースのセキュリティ）関連の機能が入りやすくなります。結果として「オンプレだけの頃は動いていた無制限委任」が、ある日突然 “期待通りに動かない” ことがあります。

そのため、リンクサーバーで Windows 統合認証のダブルホップを成立させたい場合は、最初から次の方針で揃えると強いです。

SQL サービスアカウントは 制約付きデリゲーション を基本とする
委任先は 必要な MSSQLSvc の SPN のみに限定する
“Azure 側だけ NTLM” を発見したら、DNS/SPN/ポリシー/CG をセットで疑う

どうしても設計変更が難しい場合の現実的な回避策

組織の制約でデリゲーション設計をすぐ変えられない場合、短期的な回避策として次の選択肢が残ります。

回避策	何を回避しているか	向いているケース	注意点
リンクサーバーのログインを固定（明示資格情報）	利用者資格情報の委任（ダブルホップ）	バッチ処理など、実行主体を割り切れる	権限・監査の設計が必須
SQL 認証を使う設計へ寄せる	Windows 認証の委任	委任の運用が難しい/監査要件で分離したい	パスワード管理・接続管理の運用が必要
実行環境（中継）をオンプレ側に寄せる	Azure/AVD のセキュリティ差分	短期的に業務影響を止めたい	根本解決ではない（将来的に再発しうる）

トラブルシュートの最短ルート：このチェック表で詰まる場所を特定する

観測された事実	示唆	次にやるべき確認	有効になりやすい対処
通常接続は成功、リンクサーバーだけ `ANONYMOUS LOGON`	ダブルホップ（委任）失敗が濃厚	リンク元の `auth_scheme` 確認、リンク先で誰として見えるか確認	制約付きデリゲーションへ、または固定資格情報へ
オンプレ VM は成功、Azure VM/AVD だけ失敗	Azure 側のポリシー/機能差分	Credential Guard / Remote Credential Guard、NTLM制限、DNS差分	Credential Guard を無効化（暫定）or 制約付き委任（推奨）
SQL ログで Azure 側だけ NTLM v1 が混在	Kerberos 成立していない、または途中でフォールバック	SPN 重複/不足、接続名（FQDN/短縮名/エイリアス）、ポート、名前解決	SPN 是正、接続名統一、必要に応じて NTLM ポリシー整備
SPN と委任は設定済みに見えるのに改善しない	“設定の正しさ”以外が阻害（CG など）	Credential Guard の有効化状況、委任の方式（無制限依存か）	無制限委任をやめて制約付き委任へ

まとめ：なぜ Azure VM / AVD だけリンクサーバーが失敗したのか

今回の直接要因は、Credential Guard 有効のクライアント（Azure VM / AVD）環境から、無制限委任に依存した構成でリンクサーバー（ダブルホップ）を成立させようとしていた点にあります。通常接続（1ホップ）は通るため見落としやすい一方、リンクサーバー（2ホップ）では委任が成立せず、リンク先 SQL Server で NT AUTHORITY\ANONYMOUS LOGON として扱われて失敗しました。

解決の方向性は明確です。

短期的に復旧を優先するなら：Credential Guard を無効化して従来通り動かす
セキュリティと両立するなら：制約付きデリゲーションへ移行し、委任先 SPN を明示して最小権限化する

“SPN とデリゲーションは正しいはず” の思い込みを一度外し、クライアント側のセキュリティ機能（Credential Guard / AVD の認証方式）を含めてダブルホップの前提を点検すると、同種のトラブルは再現性高く解消できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure VM/AVDからオンプレSQL ServerリンクサーバーでANONYMOUS LOGONになる原因と対処（Credential Guard・デリゲーション）

よくある症状：通常接続はOK、リンクサーバーだけが失敗する

最重要の考え方：リンクサーバーは「ダブルホップ」になりやすい

今回の結論：Credential Guard 有効 × 無制限委任（unconstrained delegation）が噛み合っていなかった

「Invalid connection string attribute」は主因ではないことが多い

まずはここを確認：失敗している“場所”を特定するチェック手順

リンク元 SQL への接続が Kerberos になっているか（最初の1ホップ）

リンク先 SQL では誰として見えているか（2ホップ目の実態）

Azure / AVD 側で“委任できないチケット”になっていないか

Credential Guard が有効かどうか（現場での見分け方）

“Azure側で追加で見るべき”チェックポイント（AVD含む）

実際に有効だった対処：Credential Guard を無効化すると復旧した

推奨される代替案：制約付きデリゲーション（Constrained Delegation）へ移行する

制約付きデリゲーション移行の実務手順（やることを具体化）

決める：どのアカウントが“委任する主体”か

設定する：委任先としてリンク先 SQL の SPN を明示する

検証する：テスト接続の前に“auth_scheme”で合否を見切る

SQLNCLI11 を使っているなら、将来を見据えてプロバイダーも見直す

調査を高速化する：sqlcheck ユーティリティで“論点”を一気に洗う

再発防止の設計ポイント：Azure/AVD を足した瞬間に破綻しないために

結論から設計する：ダブルホップを許すなら“制約付き”を基本にする

どうしても設計変更が難しい場合の現実的な回避策

トラブルシュートの最短ルート：このチェック表で詰まる場所を特定する

まとめ：なぜ Azure VM / AVD だけリンクサーバーが失敗したのか

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure VM/AVDからオンプレSQL ServerリンクサーバーでANONYMOUS LOGONになる原因と対処（Credential Guard・デリゲーション）

よくある症状：通常接続はOK、リンクサーバーだけが失敗する

最重要の考え方：リンクサーバーは「ダブルホップ」になりやすい

今回の結論：Credential Guard 有効 × 無制限委任（unconstrained delegation）が噛み合っていなかった

「Invalid connection string attribute」は主因ではないことが多い

まずはここを確認：失敗している“場所”を特定するチェック手順

リンク元 SQL への接続が Kerberos になっているか（最初の1ホップ）

リンク先 SQL では誰として見えているか（2ホップ目の実態）

Azure / AVD 側で“委任できないチケット”になっていないか

Credential Guard が有効かどうか（現場での見分け方）

“Azure側で追加で見るべき”チェックポイント（AVD含む）

実際に有効だった対処：Credential Guard を無効化すると復旧した

推奨される代替案：制約付きデリゲーション（Constrained Delegation）へ移行する

制約付きデリゲーション移行の実務手順（やることを具体化）

決める：どのアカウントが“委任する主体”か

設定する：委任先としてリンク先 SQL の SPN を明示する

検証する：テスト接続の前に“auth_scheme”で合否を見切る

SQLNCLI11 を使っているなら、将来を見据えてプロバイダーも見直す

調査を高速化する：sqlcheck ユーティリティで“論点”を一気に洗う

再発防止の設計ポイント：Azure/AVD を足した瞬間に破綻しないために

結論から設計する：ダブルホップを許すなら“制約付き”を基本にする

どうしても設計変更が難しい場合の現実的な回避策

トラブルシュートの最短ルート：このチェック表で詰まる場所を特定する

まとめ：なぜ Azure VM / AVD だけリンクサーバーが失敗したのか

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル