libcurl における NTLM 削除の予定は、技術的に見えて実際には組織的な変更である。Azure DevOps Server への Git over HTTPS パスが依然として NTLM に依存している場合、問題はツールではなく、ID 負債である。
Microsoft がここで強く推し進めるのは正しい。NTLM には既知の暗号上の弱点があり、現代のエンタープライズのデフォルトであるべきではない。危険な部分は、多くの環境が Kerberos を使用していると信じている一方で、実際には NTLM への SPNEGO フォールバックに静かに依存していることである。その幻想は2026年9月に消える。
私の見解:これを「クライアントバージョン」の問題として扱ってはならない。NTLM フラグの再有効化、古い Git ビルドの固定、フォールバックが利用可能であり続けることへの期待は、長期的リスクを伴う短命な回避策である。是正戦略がダウングレードと遅延であるなら、あなたは積極的に運用の脆弱性を高めている。
実践的な移行シーケンスは、率直で測定可能であるべきである。
- 今すぐ現在の認証動作を検証する。 実際の開発者およびビルドエージェントのコンテキスト（オフドメインおよびリモートネットワークパスを含む）で、トレースベースのチェックとチケットキャッシュ検証を実行する。
- Kerberos をエンドツーエンドで修正する: SPN、DNS エイリアス、ロードバランサー設定、委任、ドメインコントローラーの到達可能性。
- 非ドメイン参加またはワークグループシナリオを早期に特定し、Kerberos を確実にできない場所に SSH レーンを設計する。
また、所有権の明確さも必要である。セキュリティチームはポリシーベースラインを定義すべきだが、プラットフォームエンジニアリングが実装の準備責任を持つ必要がある。これは個々のリポジトリ管理者のサイドタスクではありえない。IIS、AD、ネットワークエッジ、CI エージェント、開発者ワークステーションガイダンスにわたる協調的な変更が必要である。
ひとつの微妙なリスクは自動化である。ビルドエージェントとサービスアカウントは、人間のユーザーが問題ない場合でも、Kerberos チケットがないか無効なコンテキストで実行されることが頻繁にある。対話型の開発者ワークフローだけをテストすると、最も重要なブレークポイントを見逃すことになる。
良い面もある。Kerberos または SSH にクリーンに移行することは、障害を回避するだけでなく、攻撃対象領域を減らし、ID 制御を最新のコンプライアンス期待値に整合させる。今この移行を開始するチームは、9月を何でもないこととして扱える。待つチームは、リリース圧力の下で認証障害のデバッグを行うことになる。
これはアーカイブするための警告ではない。それは実行すべき期限である。
