Microsoft faseert authenticatieprotocol NTLM uit

Microsoft kondigt aan dat het verouderde authenticatieprotocol NT Lan Manager in toekomstige versies van Windows standaard wordt uitgeschakeld. Het bedrijf raadt organisaties aan om over te stappen naar moderne alternatieven zoals Kerberos.

In de eerste fase van deze uitfasering heeft Microsoft NTLM versie 1 volledig verwijderd uit Windows Server 2025 en Windows 11 24H2. Dat laat het bedrijf weten in een blogpost. De nog gebruikte NTLM versie 2 wordt in deze versies gemarkeerd als 'verouderd'. Systeembeheerders kunnen NTLM ook al blokkeren voor SMB-verbindingen. SMB is een netwerkprotocol dat wordt gebruikt voor het delen van bestanden, printers en andere netwerkbronnen tussen computers.

Om de overgang te vergemakkelijken heeft Microsoft beveiligingsverbeteringen doorgevoerd in verschillende diensten. Zo is Extended Protection for Authentication standaard ingeschakeld in Exchange Server 2019 CU14 en de nieuwste Windows Server 2025. Deze maatregel beschermt tegen zogenaamde 'NTLM relay'-aanvallen, waarbij aanvallers authenticatiegegevens onderscheppen en misbruiken.

De uitfasering van NTLM maakt deel uit van Microsofts Secure Future Initiative, dat gericht is op het versterken van de standaardbeveiliging van Windows-systemen. Het bedrijf adviseert organisaties om hun afhankelijkheid van NTLM in kaart te brengen en een migratiestrategie op te stellen.

Reacties (68)

[Llopigat]

moderne alternatieven zoals Kerberos

Kerberos is modern???

Het is ook een legacy protocol uit dezelfde periode als NTML, origineel uit 1989 (later zijn er wel wat nieuwere versies geweest). Het heeft heel veel zwakke punten die uitgebuit worden met trucjes zoals "Kerberoast" en "Pass the hash".

Wat modern is is cloud based SSO zoals SAML.

[Reactie gewijzigd door Llopigat op 10 december 2024 12:27]

[beerse]

Leeftijd is geen variabele bij het bepalen van de kwaliteit van zaken. Dat geldt ook voor de kwaliteit van protocollen. Ook of iets modern is of ouderwets maakt daarbij niets uit.

Wel relevant is dat kerberos bewust is ontwikkeld bet het oog op het primaire doel: authenticatie. En dat met een wiskundig-bewezen veilige hanshake. Daarbij staat kerberos open voor het veranderen van gebruikte encryptie en dergelijke zodat ze kan mee groeien met de ontwikkelingen.

En als je het over single-sign-on hebt, daarbij wordt kerberos ook vaak gebruikt. Kijkend naar de details/verschillen tussen kerberos en saml: kerberos is voor authenticatie en saml is voor identificatie. Met kerberos wordt bepaald dat jij bent die je beweert wie je bent: hoor jij bij het gebruikte account. Met saml wordt bepaald wat je bent en wat je daarmee mag: Wat is jou functie in deze omgeving. Daarmee zijn kerberos en saml eerder aanvullend.

[Llopigat]

Het probleem is dat Kerberos bedacht is in een tijd dat we heel anders over security dachten. Daardoor is het zo kwetsbaar voor dergelijke aanvallen waar toen gewoon niet bij stil werd gestaan. Zoals veel snellere (en GPU) processing waardoor het bruteforcen van hashen mogelijk is.

Dat leidt tot dit soort problemen: https://www.crowdstrike.c...berattacks/kerberoasting/ en https://www.crowdstrike.c...cks/pass-the-hash-attack/
Die zijn ook heel lastig te detecteren bovendien omdat het als legitieme toegang wordt gezien.

[beerse]

Die voorbeelden van jou laten nu net mooi zien dat kerberos daarop is voorbereid: De gebruikte versleugeling kan worden aangepast. Bij kerberoasting wordt de wachtwoord hash met brute kracht teruggerekend tot een wachtwoord. Dat kan vooral bij de antieke hash versleutelingen. Kerberos gebruikt daar zo veel mogelijk de huidige hash versleutel technieken voor.

Vergelijk het met het gebruik van https: Daar gebruiken we al lang geen ssl meer voor, we zijn allemaal al lang over op het gebruik van tls1.3. Laat staan dat we de 'lege/blanco' versleuteling gebruiken (dus eigenlijk geen versleuteling). Zo zit dat ook met het hashen van wachtwoorden van kerberos. De hash methodes van 1988 zijn al lang vervangen.

[Reactie gewijzigd door beerse op 10 december 2024 13:11]

[Llopigat]

Mja in theorie wel. In de praktijk komen deze aanvallen nog steeds enorm veel voor omdat er altijd wel wat oude meuk in je bedrijfsomgeving zit. En je kan dat pas omzetten als alles weg is.

En de kwetsbaarheid is dat hashing uberhaupt mogelijk is. Dat je een gehasht paswoord van een ander account kan opvragen als domein user.

[Reactie gewijzigd door Llopigat op 10 december 2024 13:25]

[bzuidgeest]

Het is aan de gebruiker om zijn omgeving te onderhouden. Als je oude meuk in je omgeving hebt kan je dat niet om Microsoft afschuiven. Als je echt iets hebt dat nog steeds NTLM v1 nodig hebt, dan is het tijd voor een stevig gesprek.

[Llopigat]

Ja alleen als dat gesprek gaat over iets dat miljoenen aan produktie runt, dan kan je er ook niet zo veel mee. Heel veel fabrikagespullen hebben totaal andere afschrijfduren dan een gemiddelde IT oplossing, helaas.

[Jee-Bee]

Je schuift nu OT de IT in.
Meestal creëert dit meer problemen als die er daarvoor waren...

[bzuidgeest]

Je hoeft ze ook niet totaal af te schrijven. Ooit van upgrades gehoort?
Om maar niet te spreken over dat fabricage (vanuit gegaan dat je daarmee op proces automatisering doelt) spul lang niet altijd aan het internet hangt of überhaupt genetwerkt is. En dat maakt de hele discussie nutteloos.

Maar zelfs als dat netwerk enabled is kan je dat prima upgraden, kost alleen wat meer moeite. En je moet het serieus afvragen of je kritieke spullen wel zo onveilig will laten.

[nst6ldr]

Mja in theorie wel. In de praktijk komen deze aanvallen nog steeds enorm veel voor omdat er altijd wel wat oude meuk in je bedrijfsomgeving zit.

Dus jouw kritiek op kerberos komt erop neer dat het onveilig is als men het niet goed onderhoudt. Dan gaat SAML je ook niet helpen, die keys gaan op gegeven moment ook niet meer sterk zijn. Wil je dan over op een compleet nieuw protocol, of juist een protocol gebruiken die ondersteuning biedt voor recente algoritmes? Kerberos an sich is slechts beide protocol en cryptografisch model waar niks mis mee is, die "heel veel zwakke punten" klinkt me vooral als onbegrip in de oren.

[Llopigat]

Dus jouw kritiek op kerberos komt erop neer dat het onveilig is als men het niet goed onderhoudt.

Nou, een deel van het probleem is dat je je complete AD forest op een oude versie moet houden als er hier en daar maar een handjevol verouderde systemen zitten. Dat is wel iets waar ik MS op aankijk natuurlijk.

die "heel veel zwakke punten" klinkt me vooral als onbegrip in de oren.

Nou Kerberos en AD in het algemeen is een beetje de achilleshiel tegenwoordig. Wij besteden heel veel aandacht daaraan. Veel te veel eigenlijk. Ik zou liever gewoon helemaal op modern management overgaan, en group policy / AD laten varen. Dat soort spul werkt toch alleen on-prem en op VPN. Maar MS is erg langzaam met het invullen van de volledige functionaliteit in modern management, vaak zit je toch nog aan AD vast voor een paar dingetjes.

[nst6ldr]

[...]

Nou, een deel van het probleem is dat je je complete AD forest op een oude versie moet houden als er hier en daar maar een handjevol verouderde systemen zitten. Dat is wel iets waar ik MS op aankijk natuurlijk.

...hoezo? Microsoft bepaalt niet welke versie van een protocol jij gaat onderhouden. Je kan prima een geïsoleerd domein (bubble) onderhouden voor legacy spul. Iets met defense in depth enzo.

[...]

Nou Kerberos en AD in het algemeen is een beetje de achilleshiel tegenwoordig. Wij besteden heel veel aandacht daaraan. Veel te veel eigenlijk. Ik zou liever gewoon helemaal op modern management overgaan, en group policy / AD laten varen. Dat soort spul werkt toch alleen on-prem en op VPN. Maar MS is erg langzaam met het invullen van de volledige functionaliteit in modern management, vaak zit je toch nog aan AD vast voor een paar dingetjes.

Als ex-AD beheerder van een organisatie met 70.000 100k gebruikers vraag ik me dan af wat daar mis gaat. Tussen alle audits, disaster recovery oefeningen en regulier beheerwerk was er echt nog wel tijd voor upgrades en updates.

[Reactie gewijzigd door nst6ldr op 10 december 2024 19:23]

[Blokker_1999]

En van zodra alles Windows Hello for Business ondersteunt is dat allemaal geen probleem, maar er is nog zoveel legacy dat vertrouwd op deze oudere protocollen dat je er simpelweg niet van af geraakt.

[Llopigat]

Ja maar om nu te adviseren om hierop over te stappen omdat het 'modern' zou zijn zoals Microsoft doet volgens dit artikel, dat slaat nergens op.

[lenwar]

Bij een goede implementatie van zowel cliënte als server en de hele infra er tussen-in is Kerberos prima…

Echter. Om die implementatie helemaal goed te doen…. Laten we zeggen dat het niet voor niets vernoemd is naar het driekoppige monster met een slangenstaart die de onderwereld bewaakt 😂

[latka]

SAML komt uit 2001... dat is niet heel modern. En afhankelijk van wat je allemaal doet is het niet zo heel secure als je zou willen en in ieder geval vele malen complexer en dus gevoeliger voor fouten (om cloud er nog maar even buiten te laten want je authenticatie buiten de deur zetten als onderdeel van je security heb ik nooit gesnapt).

[miitjohn]

Wat modern is is cloud based SSO zoals SAML.

Oauth2/OIDC bedoel je

[Llopigat]

Oh ja inderdaad. Ik zit niet zo in de IDP maar ik weet wel dat we veel kopzorgen hebben aan kerberos vanwege de security.

[willieverhoef]

Sorry maar sommige mensen zweren bij SAML. Persoonlijk vind ik in dit protocol behoorlijk wat lastig heden zitten, zoals callbacks, of het onderhouden van certificaten (waardoor er voor matige controle hier op zit) en is Oauth ook goed genoeg. In en de praktijk zie je ook dat de kracht van SAML, ook niet wordt gebruikt en het eigenlijk gewoon identificeren is.

[Jaimyy]

SAML is geen authenticatiemechanisme, maar een protocol dat richtlijnen biedt voor het veilig uitwisselen van inloggegevens tussen een client en een server. Voor dergelijke doeleinden kan bijvoorbeeld Kerberos worden gebruikt.

Hetzelfde geldt voor andere alternatieven, zoals OIDC, OAuth, enzovoort.

[TheVivaldi]

Tja, alles is tegenwoordig modern, ook al is het oud. Zie bijvoorbeeld ARM: dat wordt als modern neergezet, maar gaat toch al ver terug.

[Vogel666]

Een hamer is geen schroevendraaier.
En je kunt met een hamer niemand neersteken, maar dat maakt niet dat een hamer per defintie onschadelijk is.

SAML is eigenlijk uitsluitend geschikt voor https en niet voor de andere 2000 protocollen die in een Corporate/factory netwerk in gebruik zijn. Succes met je SAML implementatie op SCADA of non-interactive logons zoals service-to-service.

En SAML kun je weer kraken met een replay attack of assertion manipulation....allemaal wel te voorkomen, maar ik heb tal van SaaS applicaties aan mijn omgeving hangen waarbij ik ernstige twijfels heb.

[jcbvm]

Is SAML ook niet wat achterhaald? Dacht dat OpenID tegenwoordig wel de norm is.

[Pokemoneuro]

Denk niet dat dit het einde is van NTLM! Het protocol zal nog tot het einde der tijden worden gebruikt! Maar opzich wel goed (en tegelijk veel te laat) dat Microsoft het probleem eindelijk verwijderd.

[Guru Evi]

Het is al sinds Windows NT4 en Windows 95 dat NTLMv1 niet meer als veilig beschouwt wordt, met XP/2003 aanbevolen uit te schakelen en Kerberos kwam in Windows 2000 met de nota om nieuwe applicaties over te schakelen en in 2016 werd het mogelijk NTLMv2 volledig te vermijden.

Als je vandaag nog op v1 vertrouwt, ben je wel heel ver achter, 25 jaar!

Probleem met Kerberos is zelfs op Windows nog steeds DNS voor cliënten is moeilijk altijd goed te regelen in een groot netwerk, ik denk dat daardoor veel mensen niet eens weten dat ze nog terugschakelen op NTLMv2. Met Azure los je dit nu op door Kerberos over HTTPS of andere “Modern Auth” te gebruiken.

[RiDo78]

Ik snap jouw puntje met DNS niet en wat dat te maken heeft met Kerberos / NTLM.

Voor zover ik weet is DNS gewoon plaintext over UDP of TCP poortje 53. Daar zit niks van security overheen. Natuurlijk heb je wel encrypted DNS waarmee je DNS door een secure tunnel stuurt en DNSSEC waarmee gecontroleerd kan worden of het antwoord op de query valide is. Maar DNS door een encrypted tunnel gaat een beetje voorbij aan het doel van DNS om vooral zo snel mogelijk te reageren. Als je telkens SSL-tunnels op moet zetten naar de DNS servers dan gaat dat enorm vertragen.

Natuurlijk kun je de verbinding tussen een client en de primaire/secondaire DNS server in een tunnel zetten en instellen dat de client niet met andere DNS-servers kan en mag praten (voor zover dat standaard al kan). Maar die primaire en secondaire DNS servers moeten op hun beurt ook op zoek naar de waarheid en moeten in sommige gevallen bij meerdere DNS-servers langs. Als ze voor elke verbinding een SSL tunnel moeten opbouwen dan heeft de client het wachten al lang opgegeven.

Daarnaast is DNS echt niet zo moeilijk op te zetten, ook niet op grote netwerken. Daar is het juist voor ontworpen en komt het prima tot zijn recht. Je moet je wel aan wat basis-regels houden en dan kan het haast niet mis gaan.

[Memori]

Maar DNS door een encrypted tunnel gaat een beetje voorbij aan het doel van DNS om vooral zo snel mogelijk te reageren. Als je telkens SSL-tunnels op moet zetten naar de DNS servers dan gaat dat enorm vertragen.

DNSCrypt op de locale computer of netwerk server installeren en configureren. Is net zo snel als plain text DNS.

[RiDo78]

DNSCrypt op de locale computer of netwerk server installeren en configureren. Is net zo snel als plain text DNS.

En wat bereik je daarmee?

Natuurlijk kun je daarmee het stukje tussen de client en de server versleutelen, maar dat is binnen je eigen netwerk. Zeker als je intern nog bronnen hebt die de client moet kunnen resolven. Je moet dan je eigen server DNSCrypt opzetten die wellicht met andere DNSCrypt servers buiten je netwerk kan praten. Maar *ergens* zal er een server staan die onbekende namen moet kunnen resolven. En hoe meer stappen je er tussen zet hoe trager het per saldo zal gaan.

Want stel, je wilt het forum van Tweakers resolven in een hypothetische omgeving waar caching uit staat dan zal er eerst verbinding gemaakt moeten worden met je eigen primaire DNS server, dan met die van je provider of een DNSCrypt aanbieder en dan met een van de root-servers om het net. tld te resolven. Daarna zal er verbinding gemaakt moeten worden met de servers die verantwoordelijk zijn voor het .net. domain om tweakers.net. te resolven. En vanaf dat moment is het mogelijk dat tweakers.net zijn eigen DNS servers heeft of dat gathering.tweakers.net. in dezelfde zone staat als tweakers.net. In het laatste geval kan die verbinding opnieuw gebruikt worden. Maar in het eerste geval moet er opnieuw een verbinding gemaakt worden met de servers van Tweakers om gathering.tweakers.net te resolven. Dus voor je het weet ben je al 5 servers verder.

Gebruik je dan het standaard DNS protocol dan heb je een grote kans dat de queries en replies binnen de MTU-size passen en er gebruik gemaakt kan worden van één enkel UDP packet voor de query heen en één enkel UDP packet voor de query terug. Omdat de DNS server iets moet opzoeken zal dat iets trager zijn dan een ping, maar veel zal het niet schelen.

Zet je dan een SSL-verbinding op dan moet je voor elke verbinding meerdere pakketten heen en weer sturen voor de handshakes en payload, moeten er crypto-berekeningen uitgevoerd worden en moet de DNS server nog de vraag beantwoorden. Stel dat zo'n verbinding 3 seconden duurt dan ben je al 15 seconden bezig voor je een antwoord hebt.

Maar gelukkig draait DNSCrypt waarschijnlijk alleen op de eerste of eerste twee verbindingen en gaat de rest via gewoon DNS. Die eerste twee verbindingen zijn doorgaans altijd dezelfde, wat betekent dat je gewoon een secure-channel open kunt laten voor de vervolgqueries. En gelukkig is caching een van de kernfuncties van een DNS server (het zit zelfs in het protocol én de zonedata ingebakken hoe oud entries mogen zijn) waardoor je nog performance haalt uit oplossingen als DNSCrypt.

Dus DNSCrypt is heel leuk als je niet wilt dat je provider kan loggen waar je naar toe surft op het web. Het is dan alleen wel te hopen dat de DNSCrypt server waar jij (of jouw DNSCrypt server) mee verbind dat dan ook niet logt. Anders schiet je er per saldo nog niets mee op.

Dan is het wellicht eenvoudiger om een HTTPS proxy te gebruiken. Als je het goed doet dan is je verkeer naar de HTTPS proxy versleuteld en neemt de proxy het DNS-resolven voor zijn rekening.

[Memori]

Volgens mij moet het mogelijk zijn om intern DNS op de normale manier te doen, en voor externe queries DNSCrypt te gebruiken. Volgens mij heet dat "split horizon", maar dat gaat echt buiten mijn eigen kennis/ervaring om. Dan heb je niet zoals jij zegt meerdere servers die moeten versleutelen. Een nslookup via DNSCrypt naar Quad9 naar Tweakers.net draait bij mij voor 3.11 milliseconden.

https://www.quad9.net/new...upport-live-via-dnscrypt/

Quad9 vind ik zelf goed te vertrouwen en ik doe ze jaarlijks een kleine donatie van €10 voor hun diensten.

Dus DNSCrypt is heel leuk als je niet wilt dat je provider kan loggen waar je naar toe surft op het web. Het is dan alleen wel te hopen dat de DNSCrypt server waar jij (of jouw DNSCrypt server) mee verbind dat dan ook niet logt. Anders schiet je er per saldo nog niets mee op.

Dat heb je met normale DNS services toch ook? Met DNSCrypt haal je er alleen een paar ogen tussenuit waardoor er nog één partij mee kan kijken in plaats van twee (van lokaal naar ISP -> Quad9, ISP -> Google, ISP -> Clouflare).

Ik heb bijvoorbeeld liever dat Quad9 weet wat mijn interesses zijn en die gegevens doorverkoopt zonder dat ze weten wie ik ben (niet dat ze dat doen), dan dat KPN dat weet en die gegevens doorverkoopt, gekoppeld aan mijn NAW (niet dat ze dat doen).

[Reactie gewijzigd door Memori op 10 december 2024 15:45]

[RiDo78]

Ik heb bijvoorbeeld liever dat Quad9 weet wat mijn interesses zijn en die gegevens doorverkoopt zonder dat ze weten wie ik ben (niet dat ze dat doen), dan dat KPN dat weet en die gegevens doorverkoopt, gekoppeld aan mijn NAW (niet dat ze dat doen).

We gaan een beetje offtopic, maar als jouw enige reden om Quad9 te gebruiken is om te voorkomen dat je provider kan zien waar je naar toe surft, weet dan dat de hostname bij https verkeer nog altijd zichtbaar is. De client moet namelijk voordat de encryptie begint al aangeven naar welk domain hij wil verbinden voor het geval er meer dan één https website op de server draait. De webserver moet namelijk weten welk certificaat hij terug moet sturen. De volledige URL is niet zichtbaar, maar de FQDN wel.

En om nou altijd via TOR te surfen...

[Memori]

Daar heb je helemaal gelijk in en niet zo snel over nagedacht. Maargoed, het is ook niet mijn professie Dus het enige wat het oplost is een eventuele MITM redirect.

Ik lees dat ECH (Encrypted Client Hello) het probleem van FQDN exposure moet oplossen, en ondersteuning daarvan wordt nog uitgerold. Hier een test tool van Cloudflare.

In iedergeval bedankt voor de discussie. Weer wat geleerd.

[musiman]

Om te kunnen verbinden met een Active Directory Domain Controller (bijvoorbeeld bij het inloggen van een gebruiker op diens werkstation) moet de pc weten waar de DC's zijn. Hiervoor wordt er een DNS query naar de DNS server gestuurd met de vraag om een lijst van DC's te ontvangen. Om precies te zijn: een query voor de SRV records van de LDAP service van de DC's: _ldap._tcp.DnsDomainName.

Ik denk dat @Guru Evi hier aan refereert. Denk ik.

[RiDo78]

En die queries naar een AD-DC zijn dan niet gewoon in plaintext?

Met andere woorden wordt er eerst een s/channel opgezet om dat lijstje op te vragen? Want voor zover ik weet kan ik met een linux machine gewoon over poort 53 met een AD-DNS server communiceren en dergelijke queries uitvoeren, ZONDER dat ik daarvoor een NTLM of Kerberos verbinding moet opzetten.

Het kán he... dat Microsoft ál het verkeer van een Windows domain client met diens AD-controller(s) via een secure tunnel laat lopen. Maar dan wordt die verbinding opgezet bij het opstarten (of inloggen) en blijft die actief tot de client weer afsluit. Maar dat geldt dan voor de hele verbinding en niet alleen voor DNS.

[musiman]

Alle DNS queries gaan standaard in klare tekst en maken gebruik van UDP.

Lekker veilig, DNS.

[RiDo78]

Tsja, het kenmerk van DNS is juist dat het openbaar is. Dus iedereen kan het uitvragen en vanuit dat perspectief is er niets 'geheims' aan. Vandaar dat ik wel snap dat je dat niet versleuteld en gewoon voor de snelst mogelijke optie gaat.

Maar het is wel duidelijk dat men vroeger nog niet zo stil stond bij het puntje privacy. Want vanuit dat perspectief bekeken is DNS gewoon een draak.

[Guru Evi]

Niet alleen dat (dat is deel ervan) maar alle SPN moet verwijzen naar een host met een A-record en een PTR record die overeenkomen. En in moderne systemen zijn zowat alle systemen af en toe "server" en af en toe "client", dus PSRP of RDP op een "client" is eigenlijk een server, als je Kerberos auth wilt gebruiken heb je dus een overeenkomend A & PTR record nodig voor ELK systeem, en om dat 100% te laten werken op een middengroot of groter netwerk is soms problematisch (al die dingen zijn nooit gebouwd met de bedoeling dat de computer zich kon bewegen).

[Guru Evi]

Voor Kerberos goed te laten werken moet zowel de client als de server een vaste naam en domein hebben.

Dit is nodig voor de SPN - als je dus een ticket krijgt voor HTTP/web.domein.int (of gelijk welke Kerberized service, CIFS, NFS etc) en je server heeft geen A-record en PTR-record dat het juiste record + domein en IP bevat dan werkt de service niet met Kerberos.

Komt vooral voor als je PSRP of RDP naar een client wilt gebruiken met Kerberos moet dus voor client.domein.int het IP in de A en PTR records overeenkomen, zoniet gaat Kerberos niet werken, in veel gevallen valt het dan terug naar NTLMv2 zodat dit probleem "onzichtbaar" is, echter als je NTLMv2 uitschakelt (alhoewel met Azure nu alternatieven zijn die moeilijk/niet beschikbaar zijn in on-prem AD) krijg je problemen.

Een van de problemen die we vaak hebben is dat een client naar huis gaat en de VPN gebruikt - sommige systemen nemen de 'lokale' informatie die ze krijgen van DHCP over als hostname of ze verbinden via VPN terwijl ze nog actief zijn (of de DHCP lease is nog niet verstreken) op het netwerk en de IP addressen komen niet overeen.

[beerse]

DNS is in de regel wel goed (of goed genoeg) te regelen. De uitdaging is eerder om een bijgaande certificaat-authority (CA) te regelen om te kunnen controleren of de dns wel goed informatie geeft.

Dat azure daarvoor een tunnel in een https verbinding gebruikt doet niets af aan het gegeven dat er hier en daar het een en ander gecontroleerd moet worden.

[musiman]

Ik weet niet waar jij dit op baseert, maar Microsoft is echt van plan om NTLM ondersteuning compleet uit Windows te verwijderen. Dat het niet heel snel gebeurt is natuurlijk vanwege de vele legacy implementaties, maar dat het zal verdwijnen staat behoorlijk vast.

[Pokemoneuro]

Sommige geldautomaten en kritieke infrastructuur draait nog steeds op Windows XP. Updaten is zeker niet voor iedereen zo eenvoudig als de update knop aanklikken en verder gaan met je dag.

Er zullen hoogstwaarschijnlijk nog applicaties zijn in productie ergens die geen updates meer ontvangen en geen alternatief hebben voor NTLM. Dat bedoel ik met dat het nog tot in het einde der tijden gebruikt zal worden terwijl ik ook erken dat het probleem (NTLM op zichzelf) verwijderd wordt.

[nelizmastr]

Windows XP ondersteunt ook Kerberos, dus daar is NTLM niet expliciet nodig.

[Guru Evi]

Kerberos met RC4... ik weet niet wat er beter is als je vandaag nog XP draait.

[nelizmastr]

Dat soort details zijn sowieso niet meer relevant als je überhaupt nog XP aan een netwerk hangt.

[Guru Evi]

Wel degelijk relevant want je kan het protocol niet uitschakelen zolang er 1 systeem dit nog nodig heeft. Met onafhankelijke implementaties van Kerberos (op Linux) zijn er wel dingen die je kan doen zoals een proxy die minder mogelijkheden heeft en afgeschermd is, maar op Windows is het alles of niets.

[CH4OS]

Als het een 'probleem' is dat "eindelijk" wordt verwijderd zoals je het noemt, dan is het toch ook wel redelijk evident dat het gebruik van NTLM (zeker in omgevingen waar het toe doet) op den duur uitsterft? Dat op oude en hobby omgevingen het gebruik niet zal verdwijnen is dan immers tot daar aan toe en zijn dan vaak wel weer op andere manieren uitgesloten van ongewenste toegangen, denk bijvoorbeeld aan fysiek gescheiden netwerken, geen beschikbaarheid tot internet et cetera.

[RefriedNoodle]

Het bedrijf raadt organisaties aan om over te stappen naar moderne alternatieven zoals Kerberos.

Zo modern is Kerberos toch ook niet? Ik doe al een tijd geen Windows-beheer meer, maar ik ken het nog van de Windows 2000-tijd. Maar het zal wel onderhouden zijn.

edit: volgens Wikipedia is het ontwikkeld in 1988, met eerste public release in 1989... dus 35 jaar.
edit 2: NTLM stamt uit 1993... is dus zelfs nieuwer dan de eerste versie van Kerberos!

[Reactie gewijzigd door RefriedNoodle op 10 december 2024 12:26]

[sfranken]

De eerste versie van Kerberos, ja. We gebruiken versie 5, wat in eerste instantie uitkwam in 1993 en de laatste grote upate gehad heeft in 2005

[beerse]

Microsoft heeft wel meer protocollen zelf ontwikkeld nadat er al goede beschikbaar zijn. En daar zijn ze ook al van terug gekomen en alsnog terug gestapt op het gebruik van die oudere protocollen. Denk daarbij aan dns, ntp, smtp enzo nog wel meer.

[_JGC_]

KerberosV is in 2005 een IETF-standaard geworden en lijkt in de verste verte niet op de eerste Kerberos4 release. Daarnaast heeft Microsoft ook het een en ander toegevoegd toen het Active Directory ontwikkelde. Verder ondersteunt KerberosV gewoon sterkere AES encryptie en SHA256 hashing, in tegenstelling tot NTLM die afhankelijk is van CRC of MD5 voor integriteit en RC4 voor encryptie.

Wat betreft de roep van @Llopigat hierboven om SAML: dat is vooral om het in HTTP te wrappen. Andere opties zijn OAuth2. Over het internet werkt dat veel lekkerder dan Kerberos, vooral omdat Kerberos heel strikt is op (reverse) DNS. Probleem is alleen dat je geen SAML of Oauth2 kunt gebruiken voor SMB-toegang tot je fileserver, terwijl AD/Kerberos gewoon native ondersteund wordt sinds Windows 2000.

[latka]

NTLM is LAN Manager uit 1987 zover ik weet. Ander naam, zelfde zwakke security model. Kerberos uit diezelfde tijd was altijd al beter, maar complexer en niet 100% van MS dus niet goed genoeg. Inmiddels met Embrace-Extend-Extuingish is Kerberos synoniem met Microsoft AD en alle extensie daarbij zodat interopabilteit met non MS kerberos nog steeds lastig is.

[zenlord]

Goh, met twee implementaties in de Linux en BSD wereld (MIT en Heimdal) die nog steeds actief ondersteund worden (en gebruikt worden in allesomvattende oplossingen zoals IPA Server van Red Hat), zou ik niet zeggen dat MS op dit vlak gelukt is in de EEE strategie. Ik gebruik al 15 jaar zonder problemen MIT Krb5.

[latka]

Maar met een kerberos client op linux aanmelden bij een windows AD? Toen ik dat probeerde kreeg ik spontaan hoofdpijn bij het zien van de _ms_ DNS entries.

[lenwar]

Om de overgang te vergemakkelijken heeft Microsoft beveiligingsverbeteringen doorgevoerd in verschillende diensten. Zo is Extended Protection for Authentication standaard ingeschakeld in Exchange Server 2019 CU14 en de nieuwste Windows Server 2025. Deze maatregel beschermt tegen zogenaamde 'NTLM relay'-aanvallen, waarbij aanvallers authenticatiegegevens onderscheppen en misbruiken.

Dit klinkt vreemd.

MS wil NTLM uitfaseren. Prima. Is wat voor te zeggen. We maken het uitfaseren "makkelijker" door het met workarounds minder onveilig te maken?

Ik haal ook niet terug in de bronvermeldingen dat MS dit het uitfaseren makkelijker maakt.

Volgens mij maak je het dan alleen maar moeilijker in de praktijk. Niet zo zeer technisch. Maar wel procedureel. Nu kun je als beheer-persoon zeggen dat NTLMv2 onveilig is, enz. Maar de oplettende manager die geld moet vrijmaken voor het wegmigreren zegt dan "Ja, maar MS heeft toch EPA geactiveerd? Dan hoeven we nu toch nog niets?"

[CaptainKansloos]

Het eerste wat ik me bedacht was: "Als NTLM voor SMB uitgefaseerd wordt, wat gaan huis-tuin-en-keuken NAS systemen dan gebruiken ipv Kerberos?"

Iemand een idee?

[latka]

NTLMv2 denk ik. Liefst ziet MS dat je AzureAD in de cloud gaat gebruken voor je 2-drive NAS, maar dat zal nog een paar jaar duren.

[lenwar]

NTLM is al verwijderd en NTLMv2 is als deprecated gemarkeerd volgens het gelinkte artikel

Edit: Iets kort door de bocht:

A notable development is that in Windows Server 2025 and Windows 11 24H2, NTLMv1 has been removed and the more commonly used NTLM v2 is deprecated. Additionally, admins now have the option to configure SMB to block NTLM.

[Reactie gewijzigd door lenwar op 10 december 2024 16:01]

[latka]

Ik geloof er niks van

[lenwar]

Ik was iets te kort door de bocht. Dit is slechts in de laatste OS-versies:

A notable development is that in Windows Server 2025 and Windows 11 24H2, NTLMv1 has been removed and the more commonly used NTLM v2 is deprecated. Additionally, admins now have the option to configure SMB to block NTLM.

[ibmpc]

Azure Files kun je NTLM al uitschakelen, alleen Windows 11 werkt dan out of the box, voor Windows 10 en server 2022 zijn er nog allerlei gekke omwegen nodig.

[beerse]

De meeste nas systemen gebruiken lokale accounts en dus ook lokale authenticatie. De systemen zoals ntlm en kerberos zijn vooral nodig bij systemen waar de accounts en de controle en zo weer op andere systemen liggen.

En over cifs/samba gesproken: Zelfs mijn qnap 419 beschikt al jaren over smb2, al moet ik eerlijk zeggen dat ik niet weet of daar smb1 uit staat.

[Blue_Airplane]

Als je een sonos systeem hebt draaien en het kan bij je muziek op de NAS... dan staat SMB1 nog aan.

[CaptainKansloos]

Nee. NTLM(v2) is het 'challenge-reponse protocol' voor authenticatie op SMB. Dat heeft niks met centrale of decentrale users te maken.

Op mijn NAS zijn lokale users aangemaakt die op remote clients (smartphone of computer) via NTLMv2 challenge reponse met een username + password authenticeren tegen de op de NAS gehoste SMB shares, zie https://learn.microsoft.c...on?source=recommendations

SMBv1 deed alleen LM manager of NTLM denk ik. SMBv2/3 doet NTLMv2 of kerberos denk ik.

[The Zep Man]

Potentieel is het hierdoor niet meer nodig om MD4-gehashte wachtwoorden ("NT hashes") centraal op te slaan. Lijkt mij prima.

[latka]

Potentieel, maar aangezien het een registry setting is om NTLM weer aan te zetten zal dat niet gebeuren. 2040 wellicht.

[CAPSLOCK2000]

Dat werd tijd zeg, NTLM is antiek en er wordt al 20 jaar geadviseerd om het niet meer te gebruiken.
Het is dusver onuitroeibaar gebleken omdat er (oude?) meuk is die er gebruik van blijft maken. Hoe ouder het protocol hoe lastiger het is om het te verwijderen. Spul dat het zo lang heeft volgehouden heeft zichzelf op een bepaalde manier bewezen als geschikt voor de taak (wat dat ook is). Dan is al snel de neiging om er vanaf te blijven. Als het al 10 jaar werkt dan zal het nog wel 10 jaar blijven werken en dat is lekker goedkoop. (Tenminste... zolang je niet gehacked wordt).

Hoewel MS al lang adviseert om het te vervangen heb ik dusver niet de indruk dat ze er veel druk op zetten, al oude systemen moesten wel bijven werken. Daar is nu een mooie stap in genomen maar ik ben nog een beetje skeptisch of het nu echt onherstelbaar weg is. Ik vrees dat een hoop organisaties nog work-arounds gaan bedenken om NTLM nog wat langer in leven te houden. Dat hoort er een beetje bij en daarom had ik liever gezien dat MS het al 20 jaar geleden had geschrapt in plaats van het zelf in leven te houden. NTLM had samen met MS-DOS mogen sterven.

Hoe langer een oud systeem blijft bestaan hoe groter de invloed op de rest van je omgeving. Alles vormt zich naar elkaar. Na lange tijd is het lastig om zo'n oud onderdeel weg te halen omdat het een gat achterlaat waar maar één perfecte match voor is, namelijk het oude systeem. In bijna alle gevallen zal de moderne opvolger minder goed passen. Zelfs als het technisch een drop-in replacement is dan zal toch iemand zich er in moeten verdiepen, het testen, uitvoeren etc.. en dat is duurder dan je oude systeem laten doordraaien.

Dat is een van de redenen dat ik een groot voorstander ben van pro-actief upgraden als het kan, in plaats van te wachten tot het moet. Ga met je tijd mee en draai waar mogelijk het nieuwste van het nieuwste. Er zijn er die vinden dat je dan tijd verspilt aan zinloze upgrades en features die je niet nodig hebt, maar het alternatief is dat je je tijd besteedt aan het uitvoeren van gedwongen upgrades die niet mogen mislukken omdat er geen tijd meer is om naar alternatieven te kijken. Zeker als je dan geen support meer krijgt omdat je met een verouderd product werkt dat niet meer wordt ondersteund.

Dat kan niet altijd en overal, maar het zou het streven moeten zijn. Als een product 5 jaar support heeft dan betekent het niet dat je het 5 jaar kan gebruiken. Het betekent dat je het binnen 5 jaar weer vervangen moet hebben, liefst met flink wat marge. Als je 1 jaar nodig hebt om een nieuwe versie te testen en uit te rollen en je een jaar marge wil hebben om tegenvallers op te vangen dan blijven er drie "nuttige" jaren over van die vijf. Met drie jaar support heb je slechts één jaar over voor je moet beginnen aan de volgende upgrade. Bij minder dan dat moet je het als CI/CD behandelen in plaats van als losse upgrades op gezette tijden.

[Simon Weel]

Microsoft is al jaren bezig met het uit faseren van NTLM.
Ik heb jaren geleden al stappen gezet om NTLM in zijn geheel uit te schakelen, maar werd teruggefloten door een paar applicaties. Veeam B&R deed toen nog aan NTLM (inmiddels niet meer) en ook GFI LanGuard (o ironie) heeft (nog steeds) NTLM nodig.

[TheToolGuy]

Ik hoop dat ze dat ook doen voor Remote Desktop ... Die valt standaard direct terug naar NTLM als iets anders niet lukt ...

[Verwijderd]

Net even getest om NTLM voor SMB uit te zetten op mijn Windows 11 24H2 en ontdekte dat AOMEI Backupper dan dus geen contact meer kan maken met mijn NAS.
Die jongens hebben dus wat werk te doen.