https://thedotnetblog.com/pl/tags/azure-devops-server/Articles, tutorials and insights from the .NET community.Hugopl@thedotnetblog (The .NET Blog)@thedotnetblogMon, 20 Jul 2026 00:00:00 +0000https://thedotnetblog.com/pl/news/emiliano-montesdeoca/ntlm-git-libcurl-azure-devops-server-action-plan/Mon, 20 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/pl/news/emiliano-montesdeoca/ntlm-git-libcurl-azure-devops-server-action-plan/Wrześniowe 2026 usunięcie NTLM to nie drobny problem kompatybilności; to termin architektury tożsamości dla lokalnych środowisk Azure DevOps Server.<p>Nadchodzące usunięcie NTLM w libcurl to jedna z tych zmian, która wygląda technicznie, ale jest organizacyjna. Jeśli twoja ścieżka Git przez HTTPS do Azure DevOps Server wciąż polega na NTLM, twój problem to nie narzędzia, to dług tożsamościowy.</p> <p>Oryginalne źródło: <a href="https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/">https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/</a></p> <p>Microsoft ma rację, naciskając mocno w tym obszarze. NTLM ma znane słabości kryptograficzne i nie powinien być domyślnym standardem korporacyjnym. Niebezpieczną częścią jest to, że wiele środowisk wierzy, że używa Kerberos, podczas gdy w rzeczywistości przetrwają na cichym SPNEGO fallback do NTLM. Ta iluzja znika we wrześniu 2026.</p> <p>Moja opinia: <strong>nie traktuj tego jako problemu „wersji klienta&quot;</strong>. Ponowne włączanie flag NTLM, przypinanie starych wersji Git lub liczenie, że fallback pozostanie dostępny, to krótkotrwałe obejście z długoterminowym ryzykiem. Jeśli twoja strategia naprawcza to degradacja i opóźnienie, aktywnie zwiększasz kruchość operacyjną.</p> <p>Praktyczna sekwencja migracji powinna być bezpośrednia i mierzalna.</p> <ul> <li><strong>Zweryfikuj obecne zachowanie auth teraz.</strong> Przeprowadź kontrolę opartą na śledzeniu i walidację pamięci podręcznej biletów w prawdziwych kontekstach programistów i agentów kompilacji, w tym ścieżek poza domeną i zdalnej sieci.</li> <li><strong>Napraw Kerberos end-to-end:</strong> SPN, aliasy DNS, ustawienia load balancera, delegacja i osiągalność kontrolera domeny.</li> <li><strong>Zidentyfikuj scenariusze poza domeną i workgroup wcześnie</strong> i zaprojektuj pas SSH tam, gdzie Kerberos nie może być niezawodny.</li> </ul> <p>Potrzebujesz też jasności własności. Zespoły bezpieczeństwa powinny definiować bazowe polityki, ale inżynieria platformowa musi być odpowiedzialna za gotowość implementacyjną. To nie może być poboczne zadanie dla indywidualnych adminów repozytoriów. Wymaga skoordynowanych zmian w IIS, AD, krawędzi sieciowej, agentach CI i wskazówkach dla stacji roboczych programistów.</p> <p>Jednym subtelnym ryzykiem jest automatyzacja. Agenci kompilacji i konta usługowe często działają w kontekstach, w których bilety Kerberos są nieobecne lub nieprawidłowe, nawet gdy użytkownicy ludzie działają dobrze. Jeśli testujesz tylko interaktywne przepływy programistów, przeoczysz najbardziej krytyczne punkty awarii.</p> <p>Korzyść jest realna. Czyste przejście na Kerberos lub SSH nie tylko unika awarii, ale <strong>redukuje powierzchnię ataku i dopasowuje kontrole tożsamości</strong> do nowoczesnych oczekiwań zgodności. Zespoły, które rozpoczną tę transformację teraz, będą traktować wrzesień jako nie-wydarzenie. Zespoły, które będą czekać, będą debugować awarie uwierzytelniania pod presją wydania.</p> <p>To nie jest ostrzeżenie do zarchiwizowania. <strong>To termin do wykonania.</strong></p>