Git’te NTLM Kapanıyor: Azure DevOps Server İçin Kritik Uyarı

Geçen hafta radara şöyle bir haber düştü: Eylül 2026’da libcurl içinden NTLM desteği tamamen kalkıyor. Kulağa uzak bir detay gibi geliyor, evet. Ama tarihi bir yere not etmekte fayda var; (inanın bana). Git, HTTP/HTTPS trafiğinde libcurl’ü kullanıyor, dolayısıyla bu iş doğrudan sizi de ilgilendiriyor, özellikle de on-prem Azure DevOps Server ile uğraşıyorsanız.

Yanı, Bakın şimdi… İlk duyduğumda benim kafamdan geçen şey şu öldü: “Zaten Kerberos kullanıyoruz, bize dokunmaz.” Güzel cümle, ama dur bir saniye — sahada işler çoğu zaman o kadar temiz gitmiyor, çünkü kimlik doğrulama zincirinin içinde beklemediğiniz başka bir halka çıkabiliyor ve sonra insan “hmm, bunu atlamışız” deyip kalıyor. Neden derseniz? Hemen oraya geleceğim.

İşin aslı şu: NTLM artık eski bir hikâye ve libcurl tarafında bunun yavaş yavaş kenara alınması sürpriz değil. Yine de pratikte etkisi olabilir; mesela bazı araçlar, ara katmanlar ya da yıllardır dokunulmayan kurulumlar hâlâ NTLM’e yaslanıyor olabilir (özellikle eski entegrasyonlarda bu tip sürprizler çıkıyor) (yanlış duymadınız). Neyse uzatmayalım, önce kök nedeni netleştirelim.

Evet, doğru duydunuz.

Ne Değişiyor, Kısaca?

Curl tarafında bu işin üçü bir süredir belli gibiydi. Eylül 2026 deyince olay netleşti; o tarihten sonra libcurl NTLM handshake yapamayacak. Kulağa ufak bir detay gibi geliyor, ama değil. Git de HTTP tarafında bu kütüphaneyi kullandığı için, git clone, git fetch, git push gibi komutlar NTLM’ye yaslanan sunucular karşısında pat diye duracak.

Azure DevOps Server’a gelirsek, hani eski TFS’in on-prem kuzeni var ya, orada Windows Integrated Authentication hem Kerberos’u hem NTLM’yi kabul ediyor. Peki neden risk var? (belki yanılıyorum ama) Çünkü istemci sunucuya “Negotiate” (SPNEGO) ile gidiyor. Kerberos tutmazsa sistem çoğu zaman sessizce NTLM’ye kayıyor; kullanıcı da bunu fark etmiyor, sız de aylarca “biz zaten Kerberos kullanıyoruz” diye geziyorsunuz, halbuki altta başka şey dönüyor olabilir.

Çalışıyor olması, doğru şekilde çalışıyor olması anlamına gelmiyor. Kerberos zannedip NTLM ile gidiyorsanız, Eylül 2026 sabahı ekipçe bir sürpriz sizi bekliyor.

Kimler Bu İşten Etkilenecek?

Bunu yaşayan biri olarak söyleyeyim, Etkileneceklerin listesi, ilk bakışta kısa gibi dürüyor ama değil. Aslında epey uzuyor. Ama şu senaryolar var ya, işte onlar özellikle riskli:

• IIS’te hem Negotiate hem de NTLM açık ve NTLM fallback olarak duruyorsa
• Kerberos uçtan uca doğru kurulmamışsa — eksik SPN kayıtları, yanlış DNS alias’ları, load balancer arkasında hatalı konfig, delegation eksikleri (bence en önemlisi)
• Non-domain-joined makineler, workgroup makineleri veya kurumsal ağın dışındaki build agent’lar (DC’ye görüş hattı yok)
• CI/CD pipeline’larında çalışan service account’lar — genelde Kerberos ticket alamazlar, NTLM’ye kaçarlar
• Eski Git istemci sürümlerini “sorunsuz çalışıyor” diye tutan ekipler

Şöyle söyleyeyim, Açık konuşayım, kurumsal müşterilerde en sık gördüğüm hata şu: DevOps Server bir load balancer arkasına konuyor, ama SPN kayıtları makinelerin kendi hostname’ine bağlı kalıyor. Peki sonra ne oluyor? Kerberos handshake patlıyor gibi düşünün, Negotiate sessizce NTLM’ye düşüyor, kimse de dönüp bakmıyor. Beş yıl böyle gidiyor. Ta ki bir gün… Evet.

Türkiye Perspektifi: Bu Bizi Neden Daha Çok Vurur?

Açık konuşayım: Türkiye’deki kurumsal BT tarafı, on-prem Azure DevOps Server konusunda dünyanın geri kalanına göre biraz daha temkinli gidiyor. Bankacılıkta, telekomda, kamuda, savunma sanayinde işin rengi farklı; buluta geçiş var. Öyle hop diye değil, ağır ağır ilerliyor. Mantıklı değil mi? BDDK regülasyonları, KVKK, veri lokalizasyonu derken TFS/Azure DevOps Server hâlâ birçok yerde omurga gibi dürüyor.

Bu da şu anlama geliyor: Global istatistiklerde “kullanıcıların %70’i cloud’a geçti” diyebilirsiniz, tamam, güzel; ama Türkiye’de bu oran bence çok daha aşağıda kalıyor. Dolayısıyla NTLM kapanışının çıkaracağı ses bizde daha sert duyulacak. Bilhassa de de Active Directory tarafında yıllardır el sürülmemiş SPN yapıları var, delegation zincirleri var, DNS kayıtları var (bazısı öylece yatıyor), bunları toparlamak da üç günlük iş değil, açık söyleyeyim en az birkaç aylık uğraş.

Çok konuştum, örnekle göstereyim.

Bir de işin şu tarafı var: Türkiye’de orta ölçekli birçok şirkette Active Directory resmen bir “senior sysadmin”in kafasında yaşıyor. O kişi ayrılınca geride kalan ekip SPN nedir diye bakakalıyor. Evet. Şimdi hem NTLM’yi kapatmak gerekiyor hem de Kerberos’u düzgün kurmak lazım — üstelik belgesi eksik bir AD üzerinde. Bu baya proje çıkarır. Şaka değil.

Gerçekten Kerberos mu Kullanıyorsunuz? Nasıl Anlarız?

İşin düğümü burada. Sunucuyla konuşan Git istemcisi Kerberos mu kullanıyor, yoksa sessiz sedasız NTLM’ye mi kayıyor, bunu net görmeden sağlıklı yorum yapmak zor. Burada, peki neden? Çünkü dışarıdan her şey yolunda gibi dürüyor, ama içeride bambaşka bir auth akışı dönüyor olabilir; ben böyle birkaç ortamda, özellikle de kurumsal proxy ve tarayıcı etkisi işin içine girince, ilk bakışta “tamam” sanılan şeyin aslında NTLM çıktığını gördüm.

Bunu biraz açayım.

1. Git Trace ile Handshake’i İzlemek

Modern Git for Windows sürümlerinde trace açınca hangi auth mekanizmasının devreye girdiği baya net görünüyor. Bir terminal açın, şu komutları çalıştırın, sonra da çıktıyı dikkatle okuyun; bazen küçük bir satır, bütün hikâyeyi değiştiriyor: (buna dikkat edin)

set GIT_TRACE_CURL=1
set GIT_CURL_VERBOSE=1
git clone https://devops.sirket.local/Collection/Proje/_git/Repo

Çıktıda Authorization: Negotiate YII... gibi uzun bir base64 blob görürseniz, büyük olasılıkla Kerberos tarafındasınız (SPNEGO ticket üzerinden gidiyor). Ama Authorization: NTLM TlRMTVNTUA... görürseniz — NTLM devrede demektir. TlRMTVNTUA kısmı base64 içinde “NTLMSSP” imzasının başlangıcıdır, yanı o ipucu aslında oldukça açık. Evet, bu kadar basit görünüyor; ama pratikte insan bazen gözünün önündekini kaçırıyor.

Bence burada en çok insanı uğraştıran yer DNS tarafı. Ciddi söylüyorum. En çok da de şu CNAME meselesi, her seferinde ayrı bir sürpriz çıkarıyor; Kerberos hostname’i ticket içine olduğu gibi yazdığı için alias kullandığınızda istemci bazen alias’a gidiyor, bazen hedef A kaydına bakıyor (Windows sürümüne göre değişebiliyor, registry ayarı devreye giriyor, hatta client davranışı bile farklılaşıyor), yanı işin aslı mümkünse direkt A kaydıyla ilerlemek daha az baş ağrıtıyor.

Şöyle söyleyeyim, Evet.

SPN tarafında da şöyle bir şey var: kayıt doğru hesapta değilse sistem bunu affetmiyor. setspn -L ile kontrol edin, duplicate var mı bakın, sonra da gerçekten o service account üzerinde mi dürüyor diye göz gezdirin; küçük gibi duran bu detay yüzünden saatler gidebiliyor. Hani ne farkı var diyorsunuz, değil mi? Sız de yaşamışsınızdır belki.

Kısacası, peki neden? Bu konuyla ilgili Pure Virtual C++ 2026 Konuşmaları Açıklandı: Program Belli yazımıza da göz atmanızı tavsiye ederim.

Küçük bir detay: IIS Authentication kısmında da sırayı bozmayın. Negotiate önde olacak, NTLM işe en sona itilecek ya da gerekiyorsa tamamen kaldırılacak; çünkü NTLM üstte kalırsa sistem gayet sakın bir şekilde fallback yapıyor. Sız de “neden Kerberos çalışmadı?” diye ekrana bakıp kalıyorsunuz. Açık konuşayım, bu kısım ilk kurulumda idare eder gibi görünür ama üretimde ufak bir hata büyüyüp can sıkabiliyor. Bu konuyla ilgili Agent Harness ile Ajana Veri Vermek: Onay ve Hafıza Dahil yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için VS Code’da Copilot Browser Tools GA: Ajanlar Artık Sörfçü yazımıza bakabilirsiniz.

İlginç olan şu ki, Load balancer olan senaryolarda işe olay biraz daha karışıyor. Session persistence olmadan kullanıcı bir node’dan ötekine savrulursa oturum bozuluyor; üstüne bir de SPN sadece node hostname’lere yazıldıysa LB hostname boş kalıyor ve Kerberos yine yolunu şaşırıyor. Neyse uzatmayalım, burada hedef işim ile gerçek akışın aynı çizgide olması lazım.

Şimdi, tam da öyle. Bu konuyla ilgili Gemini 2.5 Pro ve Gemini 3 Flash Copilot’tan Çıkıyor yazımıza da göz atmanızı tavsiye ederim.

Enterprise vs Küçük Ekip: Farklı Yol Haritaları

Küçük Ekipseniz (10-50 geliştirici)

Sizin için en az baş ağrıtan yol büyük ihtimalle buluta çıkmak. Yanı Azure DevOps Services tarafına geçmek. Orada Entra ID (eski Azure AD) authentication var, PAT var, OAuth var; NTLM diye bir dert de kalmıyor. Küçük ekiplerde lisans maliyeti de öyle uçmuyor, kullanıcı başı aylık birkaç dolar civarı gidiyor. Sız hiç denediniz mi? Açık konuşayım, TL bazında bakınca bir sistem yöneticisinin Kerberos’la iki hafta boğuşmasının faturası, çoğu zaman 3 yıllık cloud aboneliğini geçiyor.

İç link olarak bakabileceğiniz iyi bir referans: Azure DevOps’ta SQL Projeleri: Pipeline Kurmanın Temelleri yazımda pipeline mimarisine nasıl baktığımı görebilirsiniz. Neden önemli bu? Orada işin temel taşlarını biraz daha net anlatmıştım, burada işe konu biraz daha kimlik doğrulama tarafına kayıyor (evet, doğru duydunuz) Bu konuyla ilgili SharePoint Copilot Apps Geliyor: SPFx’in AI Dönemine Giriş yazımıza da göz atmanızı tavsiye ederim.

Kurumsal Yapıdaysanız (500+ geliştirici, on-prem şart)

Vallahi, Regülasyon, veri lokalizasyonu, kurum içi politika derken on-prem’de kalmanız gerekiyorsa, iş biraz daha uğraştırıyor. Ama panik yok. Önce resmî çıkarın; kaç Git istemcisi var, kaç build agent çalışıyor, hangi service account’lar ortalıkta dolaşıyor? Hepsini tek tek listeleyin. Sonra da bakın bakalım gerçekten neye bağlısınız.

1. Envanter çıkar: Kaç Git istemcisi, kaç build agent, hangi service account’lar var? Hepsini listele.
2. Auth telemetrisi topla: IIS loglarında 3 ay boyunca hangi auth mekanizmasının kullanıldığını sayısal olarak çıkar. “Günde 12.000 istekten 8.400’ü NTLM” gibi net bir tablo istiyorsun.
3. Kerberos’u pilot ortamda kur: Prod’a dokunmadan bir test collection’da SPN + delegation + IIS providers sıralamasını doğru yap.
4. Aşamalı geçiş: Önce bir takım, sonra bir departman, sonra tümü.
5. NTLM’yi kapat: IIS’te NTLM provider’ını en sona koy veya tamamen kaldır. Bu son adım — cesaret ister.

Peki neden bu kadar uğraşıyoruz? Çünkü sayı görmeden ilerlemek biraz kör yürümek gibi oluyor. Mesela üç ay boyunca IIS loglarına bakıp “günde 12.000 isteğin 8.400’ü NTLM” sonucunu alırsanız, tartışma bitiyor; yoksa herkes kendi kafasına göre konuşuyor ve iş uzayıp gidiyor.

Bunu biraz açayım.

Şöyle ki, Evet.

Burada küçük ama önemli bir detay var: build agent’ı sadece “çalışıyor” diye bırakmak yetmiyor, çünkü arka planda kimlik tarafı yanlışsa sorun ilk gün görünmüyor ama sonra pat diye karşınıza çıkıyor; o yüzden gMSA planını erkenden yapmak baya iş görüyor.

Kendi deneyimimden konuşuyorum, Neyse, çok dağıtmadan söyleyeyim: küçük ekipte bulut genelde daha rahat ettiriyor, kurumsalda işe önce ölçüp biçmek gerekiyor. Sonrası zaten adım adım geliyor (ben de ilk duyduğumda şaşırmıştım)

Peki Ya “Eski Git İstemcisinde Kalıp Sorunu Erteleyelim” Diyenler?

Bazı ekipler şöyle düşünüyor: “Biz Git 2.40 civarında kalırız, libcurl güncellenmez, NTLM de aynen devam eder.” Kağıt üstünde fena durmuyor. Ama işin aslı, sahada o kadar rahat yürümüyor; bir yerde güvenlik duvarına tosluyorsunuz, sonra da herkes birbirine bakıyor.

Bir kere güvenlik açıkları geliyor, CVE’ler çıkıyor, SIEM tarafı da boş durmuyor. 3 ay geçmeden eski Git sürümleri rapora düşüyor. Sizden güncelleme isteniyor; öbür tarafta geliştirici laptop’ünü yeniliyor, otomatik güncel Git kuruluyor (ve evet, o makine bir anda çalışmaz hâle gelebiliyor), yanı mesele sadece “bir sürüm eski kaldı” işi değil.

İkincisi biraz daha can sıkıcı: geliştirici deneyimi. Bugün sorun yok gibi görünür, yarın biri cihaz değiştirir, öbürü yeni imajla gelir, derken aynı repo için iki farklı davranış görmeye başlarsınız. E sonra? Herkes “benimde niye öldü da sende olmadı” diye bakınır, asıl zaman kaybı da orada başlar.

Ve işler burada ilginçleşiyor.

Üçüncüsü, borç büyüyor. Şimdi ertelediğiniz şey küçük gibi dürüyor olabilir ama iki yıl sonra önünüze daha kabarık geliyor; üstelik sadece teknik olarak değil, ekip alışkanlığı olarak da ağırlaşıyor. Hani şu “sonra bakarız” dediğimiz işler var ya, işte onlar genelde en pahalıya patlayanlar oluyor (eh, fena değil)

Kısacası: erteleme çözüm değil, bildiğiniz teknik borç. Ben bu yaklaşımı önermem. Açık konuşayım, sertifikasyon tarafında da bunu net gördüm (AZ-500 hazırlığında NTLM’nın neden deprecate olduğu detaylıca işleniyor), Microsoft bu konuda geri adım atacak gibi durmuyor. Tam da öyle.

PAT ve HTTPS Alternatifi: Ara Çözüm mü?

Azure DevOps Server, PAT (Personal Access Token) desteği veriyor. Yanı NTLM/Kerberos yerine token bazlı auth kullanabiliyorsunuz. Git credential manager PAT’ı kaydediyor, sız de HTTP Basic auth üstünden akışı sürdürüyorsunuz; kısa vadede iş görüyor, açık konuşayım.

Ama bir durun. PAT’lar süreli oluyor, rotasyon istiyor, kurumsal tarafta da ayrı bir uğraş çıkarıyor; ayrıca bazı organizasyonlarda PAT politikaları baya sıkı, hatta üretim ortamına PAT ile push etmeyi direkt kapatan yerler gördüm. Yanı PAT bir plan B, ama plan A Kerberos olmalı. Karıştırmayın.

Ve işler burada ilginçleşiyor.

Bu arada güvenlik tarafını biraz daha geniş görmek isterseniz, Azure DevOps Server Haziran Yamaları: Sahadan Notlar ve Geçiş Rehberi yazıma da bakın derim — patch stratejisi ile auth geçişini aynı takvime koymak, hani çoğu zaman sonradan baş ağrısı çıkarmıyor.

Bir de Şunu Söyleyeyim: Neden Zaten Kaldırılıyor?

NTLM, 90’ların sonundan kalma bir protokol (şaşırtıcı ama gerçek). Hani şu eski sistemlerde “idare eder” diye tutulan şeylerden biri var ya, tam o kafa (yanlış duymadınız). Challenge-response yapısı bugün kullandığımız kripto beklentilerinin baya gerisinde kalıyor; pass-the-hash saldırılarına kapı aralıyor, replay tarafında da pek iç açıcı durmuyor, MFA ile de açık konuşayım hiç iyi anlaşmıyor (inanın bana) — valla güzel iş çıkarmışlar —

Doğrusu, Yanı modern güvenlik dünyasında NTLM biraz yaşayan fosil gibi. Evet. Microsoft da bunu yıllardır yavaş yavaş kenara itiyor zaten. Windows 11’in son sürümlerinde NTLM’yi sınırlayan yeni politikalar geldi,. Libcurl’ün NTLM’yi kaldırması da tek başına bir karar değil, ekosistemin topluca aynı yöne dönmesinin parçası. Biletinizi ya alırsınız, ya kalırsınız.

Şimdi gelelim işin can alıcı noktasına.

Legacy protokolleri kapatmak ilk başta can sıkar, ama uzun vadede güvenlik postürünüzü toparlar; audit tarafında da bu geçiş boşuna beklenmiyor (NIST, ISO 27001, PCI-DSS gibi çerçeveler modern auth mekanizmalarına işaret ediyor), yanı işin aslı herkes biraz daha temiz bir kimlik doğrulama düzeni görmek istiyor.

Aksiyon Planı: İlk Hafta Ne Yapmalı?

Ne yalan söyleyeyim, Uzun uzun anlattım ama işin sonunda hep aynı yere geliyoruz: somut bir aksiyon planı lazım. Bugünden itibaren, hani sırayla gidelim, şu adımları öneririm:

1. Bu hafta: IIS loglarını 7 gün boyunca detaylı logla. NTLM/Kerberos oranını çıkar.
2. Önümüzdeki 2 hafta: AD ekibi ile toplan. SPN envanteri çıkarın. Duplicate ve eksik SPN’leri bulun.
3. 1. ay: Test ortamında Kerberos’u uçtan uca kur. Bir pilot geliştirici grubu ile doğrula.
4. 2-4. aylar: Build agent’ları gMSA’ya taşı. Non-domain-joined makineler için PAT stratejisi yaz.
5. 5-6. aylar: Kademeli olarak tüm kullanıcıları geçir. IIS’te NTLM provider’ını en alta çek.
6. Eylül 2026’dan önce: NTLM provider’ını IIS’ten tamamen kaldır. Doğrula.

Araya gireyim: Yanı kabaca bir yıllık yol haritası bu. Şimdiden başlamak lazım, başka türlü yetişmiyor. Eylül 2026 yakın gibi durmuyor ama kurumsal tarafta 12 ay göz açıp kapayıncaya kadar geçiyor, hele bir de AD, IIS. Build tarafı iç içe geçmişse… Neyse, uzatmayayım; erteleyen kaybediyor.

Peki neden?

Çünkü böyle işler “sonra bakarız” denince uzuyor da uzuyor, önce küçük bir log işi kalıyor sanıyorsun, sonra SPN temizliği çıkıyor (orada da duplicate kayıtlar, eksik servis hesapları falan), ardından test ortamında Kerberos doğrulaması derken zaman bir anda eriyor gider.

Evet.

Şahsen, Açık konuşayım, burada mesele sadece teknik geçiş değil; ekiplerin aynı sayfaya gelmesi, build süreçlerinin bozulmaması. Kullanıcı tarafında sessizce ilerlemek gerekiyor, yoksa güzel görünen plan ilk haftada duvara çarpabiliyor.

Sız ne dersiniz?

Sıkça Sorulan Sorular

NTLM’nın Git’ten kaldırılması Azure DevOps Services (cloud) kullanıcılarını etkiler mi?

Hayır, sizi doğrudan ilgilendiren bir şey yok aslında. Azure DevOps Services zaten Entra ID (Azure AD), OAuth ve PAT bazlı authentication kullanıyor. Yanı NTLM cloud sürümde zaten yoktu. Bu değişiklik tamamen on-prem Azure DevOps Server (ve hani eski TFS kurulumları) için geçerli.

Kerberos yerine sadece HTTPS + PAT kullansam yeterli olur mu?

Garip gelecek ama, Küçük ekipler için? Evet, döner. Ama PAT’ların süre sınırı var, rotasyon zorunluluğu var, bir de üstüne kurumsal yönetim yükü biniyor. Açıkçası kurumsal ortamlarda tavsiye edilen yol Kerberos; PAT işe ikinci plan olarak, mesela build agent ve otomasyon senaryolarında değerlendirilebilir.

SSH ile Git kullansam bu sorunu tamamen atlayabilir mıyım?

Teoride evet, mümkün. Azure DevOps Server SSH desteği veriyor. Ama şunu da göz ardı etmemek lazım: SSH key yönetimi, key rotation ve merkezî denetim politikaları ayrı bir dert. Eğer zaten SSH altyapınız oturmuşsa geçerli bir alternatif bence. Yoksa doğrudan Kerberos’a odaklanın.

Eski Git istemcisinde kalarak NTLM desteğini korumak güvenli mi?

Net bir şekilde hayır. Hem güvenlik açıklarına davetiye çıkarıyor hem de sürdürülebilir bir şey değil. Eski Git sürümlerinde biriken CVE’ler zamanla ciddi risk oluşturuyor ve compliance denetimlerinden de geçmiyor. Tecrübeme göre bu yol kısa vadede bir “bant” gibi görünüyor ama çözüm kesinlikle değil.

Build agent’lar için en iyi auth yöntemi nedir?

Group Managed Service Account (gMSA) ile çalıştırmak en temiz yol. Böylece agent bir domain hesabına bağlı oluyor ve Kerberos ticket alabiliyor (yanlış duymadınız). gMSA parola yönetimini de AD’ye devrediyor, yanı sız elle şifre yönetmek zorunda kalmıyorsunuz. Kurumsal ortamlarda benim ilk önerim çoğu zaman bu oluyor.

Kaynaklar ve İleri Okuma

Vallahi, Upcoming Change: NTLM Removal in Git (libcurl) – Microsoft DevBlogs

Azure DevOps Server için Kerberos Kurulumu – Microsoft Learn

curl Project – NTLM Deprecation Notes

Bence, Windows Server Kerberos Authentication Overview – Microsoft Learn

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

VSTest Newtonsoft.Json Bağımlılığını Atıyor: Ne Değişiyor?2 May 2026

Prompt Injection’ı Durdurmak: Agent Framework’te FIDES20 May 2026

Teams’te Çalışan Ajanlar: İşin Olduğu Yerde Başlamak8 Haz 2026

MSSQL Extension v1.43: Azure SQL'i VS Code'dan Kurmak Artık Mümkün28 Haz 2026