NTLM verdwijnt in Git/libcurl: Azure DevOps Server-teams hebben een echt migratieplan nodig

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

De aankomende NTLM-verwijdering in libcurl is een van die veranderingen die technisch oogt maar eigenlijk organisatorisch is. Als je Git-over-HTTPS-pad naar Azure DevOps Server nog steeds afhankelijk is van NTLM, is je probleem geen tooling, het is identiteitsschuld.

Oorspronkelijke bron: https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/

Microsoft doet er goed aan hier hard op te duwen. NTLM heeft bekende cryptografische zwakheden en zou geen moderne enterprise-standaard moeten zijn. Het gevaarlijke deel is dat veel omgevingen geloven dat ze Kerberos gebruiken terwijl ze eigenlijk overleven op stille SPNEGO-terugval naar NTLM. Die illusie verdwijnt in september 2026.

Mijn mening: behandel dit niet als een “clientversie”-probleem. NTLM-vlaggen opnieuw inschakelen, oude Git-builds vastpinnen, of hopen dat fallback beschikbaar blijft, is een kortstondige workaround met langetermijnrisico. Als je herstelstrategie downgrade-en-uitstellen is, verhoog je actief de operationele broosheid.

Een praktische migratievolgorde zou bot en meetbaar moeten zijn.

Verifieer eerst het huidige authenticatiegedrag nu. Voer trace-gebaseerde controles en ticket cache-validatie uit in echte ontwikkelaars- en build-agentcontexten, inclusief off-domain- en remote-netwerkpaden. Fix ten tweede Kerberos end-to-end: SPN’s, DNS-aliassen, load balancer-instellingen, delegatie en bereikbaarheid van domeincontrollers. Identificeer ten derde vroeg scenario’s zonder domeinlidmaatschap of workgroup-scenario’s en ontwerp een SSH-baan waar Kerberos niet betrouwbaar gemaakt kan worden.

Je hebt ook duidelijkheid over eigenaarschap nodig. Beveiligingsteams zouden beleidsbasislijnen moeten definiëren, maar platform-engineering moet implementatiegereedheid bezitten. Dit kan geen bijtaak zijn voor individuele repo-beheerders. Het vereist gecoördineerde veranderingen over IIS, AD, netwerkrand, CI-agents en richtlijnen voor ontwikkelaarswerkstations.

Eén subtiel risico is automatisering. Build-agents en serviceaccounts draaien vaak in contexten waar Kerberos-tickets ontbreken of ongeldig zijn, zelfs wanneer menselijke gebruikers prima functioneren. Als je alleen interactieve ontwikkelaarsworkflows test, mis je de meest kritieke breekpunten.

De opbrengst is reëel. Schoon overstappen naar Kerberos of SSH voorkomt niet alleen storingen, het vermindert ook het aanvalsoppervlak en stemt identiteitscontroles af op moderne compliance-verwachtingen. De teams die nu met deze overgang beginnen, zullen september als een non-event behandelen. De teams die wachten, zullen authenticatiefouten debuggen onder releasedruk.

Dit is geen waarschuwing om te archiveren. Het is een deadline om tegen te presteren.

Pull requests reviewen in Visual Studio is precies het soort frictieverlaging dat ik prettig vind

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

Dit artikel is automatisch vertaald. Lees het origineel hier.

De browser heeft al veel te lang te veel van de code review-workflow overgenomen.

Daarom ben ik erg blij om te zien dat Visual Studio verder gaat met end-to-end pull request review binnen de IDE.

Dit is zo’n functie die misschien geen grote krantenkoppen oplevert, maar die de dagelijkse ontwikkeling absoluut kan verbeteren.

De belangrijkste waarde is simpel: minder context switching

Wanneer je review-loop deels in de IDE en deels in de browser leeft, stapelt de frictie zich op:

open de PR ergens anders
inspecteer de wijzigingen in één tool
ga terug naar de solution voor dieper onderzoek
switch nog eens om te reageren of goed te keuren

Dat is niet rampzalig. Het is gewoon inefficiënt.

Als Visual Studio je laat openen, inspecteren, commenten, approven en mergen vanuit dezelfde werkomgeving, dan is dat een echte productiviteitswinst.

De optie om te reviewen zonder checkout is extra fijn

Een deel dat ik bijzonder prettig vind, is de mogelijkheid om te reviewen zonder de PR-branch te checken.

Dat klinkt klein, maar is perfect voor:

snelle reviewrondes
feedbackverzoeken tijdens onderbrekingen
je huidige branch en lokale staat intact houden

Dat is precies het soort flexibiliteit dat goede code review-tools nodig hebben.

Mijn mening

Dit is geen revolutionaire functie.

Het is iets beters: iets praktisch.

Voor teams die het grootste deel van hun dag in Visual Studio doorbrengen, betekent sterkere PR-reviewondersteuning minder workflow-onderbrekingen en een soepeler pad van inspectie naar actie.

Dat is in mijn boek een waardevolle verbetering.

Originele publicatie: Pull requests reviewen zonder Visual Studio te verlaten

Git | The .NET Blog

NTLM verdwijnt in Git/libcurl: Azure DevOps Server-teams hebben een echt migratieplan nodig

Pull requests reviewen in Visual Studio is precies het soort frictieverlaging dat ik prettig vind

De belangrijkste waarde is simpel: minder context switching

De optie om te reviewen zonder checkout is extra fijn

Mijn mening