NTLM Завершается в Git/libcurl: Командам Azure DevOps Server Нужен Реальный План Миграции

Emiliano Montesdeoca — Mon, 20 Jul 2026 00:00:00 +0000

Предстоящее удаление NTLM в libcurl — одно из тех изменений, которые выглядят техническими, но на самом деле являются организационными. Если ваш путь Git over HTTPS к Azure DevOps Server все еще зависит от NTLM, ваша проблема не в инструментах, а в долге по идентификации.

Оригинальный источник: https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/

Microsoft права, настаивая на этом. NTLM имеет известные криптографические слабости и не должен быть современным корпоративным стандартом по умолчанию. Опасная часть в том, что многие среды считают, что используют Kerberos, когда на самом деле они выживают за счет тихого отката SPNEGO к NTLM. Эта иллюзия исчезнет в сентябре 2026 года.

Мое мнение: не рассматривайте это как проблему «версии клиента». Повторное включение флагов NTLM, закрепление старых сборок Git или надежда на доступность отката — это краткосрочный обходной путь с долгосрочным риском. Если ваша стратегия исправления — это даунгрейд и задержка, вы активно увеличиваете операционную хрупкость.

Практическая последовательность миграции должна быть прямой и измеримой.

Во-первых, проверьте текущее поведение аутентификации сейчас. Запустите trace-проверки и валидацию кэша билетов в реальных контекстах разработчиков и билд-агентов, включая пути вне домена и удаленных сетей. Во-вторых, исправьте Kerberos end-to-end: SPN, DNS-алиасы, настройки балансировщика нагрузки, делегирование и доступность контроллера домена. В-третьих, идентифицируйте сценарии без присоединения к домену или рабочие группы на раннем этапе и спроектируйте SSH-путь там, где Kerberos не может быть надежным.

Вам также нужна четкость в отношении ответственности. Команды безопасности должны определить базовые политики, но платформенная инженерия должна владеть готовностью реализации. Это не может быть побочной задачей для отдельных администраторов репозиториев. Требуются скоординированные изменения в IIS, AD, на сетевом периметре, CI-агентах и руководствах для рабочих станций разработчиков.

Один тонкий риск — автоматизация. Билд-агенты и сервисные аккаунты часто работают в контекстах, где билеты Kerberos отсутствуют или недействительны, даже когда у людей-пользователей все работает. Если вы тестируете только интерактивные рабочие процессы разработчиков, вы пропустите самые критичные точки отказа.

Плюс реален. Чистый переход на Kerberos или SSH не только избегает поломок, но и уменьшает поверхность атаки и приводит управление идентификацией в соответствие с современными ожиданиями комплаенса. Команды, которые начнут этот переход сейчас, будут рассматривать сентябрь как рядовое событие. Команды, которые будут ждать, будут отлаживать ошибки аутентификации под давлением релиза.

Это не предупреждение для архивации. Это дедлайн для исполнения.

Kerberos | The .NET Blog

NTLM Завершается в Git/libcurl: Командам Azure DevOps Server Нужен Реальный План Миграции