Microsoft zet verouderd authenticatieprotocol NTLM stap voor stap uit in Windows

Microsoft gaat NTLM halverwege dit jaar verwijderen uit Windows. Het bedrijf heeft daarvoor een tijdlijn gegeven, nadat het eerder al aankondigde NTLM uit te faseren. In de tweede helft van het jaar wordt die verwijdering doorgezet.

Microsoft schrijft dat in een blogpost. Het bedrijf zegt dat het vanaf de tweede helft van 2026 verschillende onderdelen van Windows gaat aanpassen om de uitfasering van New Technology LAN Manager eenvoudiger te maken. Zo gaat het IAKerb en het lokale Key Distribution Center op de schop gooien en worden Windows-componenten aangepast zodat die in de eerste plaats Kerberos gebruiken voor authenticatie in plaats van NTLM.

Dat gebeurt op Windows Server 2025 en Windows 11 24H2 en hoger. Vanaf de volgende grote Windows Server-release wordt NTLM standaard uitgeschakeld. Beheerders moeten NTLM dan zelf inschakelen als zij dat nog willen gebruiken.

Microsoft benadrukt dat NTLM nog wel in Windows blijft zitten. Daarmee krijgen beheerders meer tijd en mogelijkheden om van het protocol af te stappen.

Microsoft zei eind 2024 al dat het NTLM wilde verwijderen, maar gaf daar tot nu toe nog geen duidelijke tijdlijn voor. Wel werd NTLM versie 1 al verwijderd. Versie 2 van NTLM heeft inmiddels de status deprecated, waardoor het geen updates meer ontvangt. NTLM is een oud authenticatieprotocol dat de laatste jaren steeds minder relevant is geworden door de opkomst van Kerberos. Microsoft zegt ook dat Kerberos voor de meeste gebruikers een beter alternatief is en dat NTLM vaak alleen nog wordt gebruikt wanneer Kerberos niet beschikbaar is. NTLM bevat van nature zwakke encryptie waardoor het protocol kwetsbaar is voor man-in-the-middleaanvallen.

NTLM

Door Tijs Hofmans

Nieuwscoördinator

30-01-2026 • 10:59

107

Reacties (107)

Sorteer op:

Weergave:

Mooi dat dit gebeurd! Gaat mijn baan als pentester wel een stuk lastiger maken binnen Windows-netwerken, maar dat is alleen maar goed natuurlijk.
Ja ik snap niet dat het zo lang heeft geduurd. Hele klassen exploits gaan hiermee in 1 klap de deur uit.
Kerberos heeft nogal veel vereisten om te werken, daardoor is er veel fallback naar NTLMv2.
Kerberos werkt niet als je:
- Probeert te verbinden naar een IP adres i.p.v. een FQDN
- Meestal niet als je probeert te verbinden naar een hostname i.p.v. een FQDN
- Probeert te verbinden naar een FQDN dat een CNAME is i.p.v. een A record
- Probeert te verbinden vanaf een PC in AD1 naar een host in AD2 waarbij er geen trust tussen de domeinen is, zelfs al probeer je met expliciete credentials van AD2
- Geen line of sight met de DC, maar wel met de server waar naar je probeert te verbinden

Bovenstaande zijn scenario's waar NTLMv2 meestal wel werkt.

PS: LM bestaat al even niet meer, en NTLMv1 kan je normaal wel uitzetten zonder grote gevolgen en is noodzakelijk om je te beschermen.

PPS: Ik zie hier in de commentaar veel mensen NTLM en SMB met elkaar verwarren.

[Reactie gewijzigd door GoBieN-Be op 30 januari 2026 22:23]

Interessante aanvulling op de scenario’s waarin Kerberos momenteel nog faalt. Ik vraag me af wat de exacte impact hiervan gaat zijn op omgevingen waar wij b.v. FreeIPA draaien in combinatie met Microsoft AD controllers.

Hoewel een IPA-trust fundamenteel op Kerberos leunt voor de cross-realm authenticatie, weten we dat in de praktijk onderdelen zoals SSSD of Samba-interacties (denk aan SID-mapping of wachtwoordwijzigingen) soms nog ongemerkt terugvallen op NTLM. Dit gebeurt vaak wanneer de DNS-configuratie of 'line of sight' niet 100% zuiver is.

Zodra Microsoft NTLM standaard gaat uitschakelen, verdwijnt dat vangnet voor onze Linux-integraties volledig. Zeker het punt dat je noemt over verbindingen naar IP-adressen in plaats van FQDN’s is een risico voor bestaande scripts. Ik ga dit intern aankaarten bij onze AD/DNS-experts om te kijken of we alvast kunnen starten met het monitoren van NTLM-audit logs (zoals Event ID 8004) op de Domain Controllers. Zo kunnen we zien waar we nu nog onbewust op NTLM leunen voordat de harde deadline in 2026 valt.
...
Kerberos werkt niet als je:
- Probeert te verbinden naar een IP adres i.p.v. een FQDN
- Meestal niet als je probeert te verbinden naar een hostname i.p.v. een FQDN
...
Leuk als je verbinding wilt maken met je eigen router of printer.
Omdat als ze het er snel uit zouden gooien, er gigantisch veel software die hiervan afhankelijk is niet meer zou werken.

En softwareleveranciers maken geen haast om hun code aan te passen want er is nog genoeg tijd.
Dit heeft dikwijls ook te maken met de klant ... Die willen bijvoorbeeld dat dit op deze manier gebeurd. Zo moet je soms verschillende dingen ondersteunen en dat is altijd een hele hoop werk, zeker in "legacy" software. Ik weet nog dat ik voor een bedrijf werkte en daar kon je kiezen access (alleen lokaal voor 1 gebruiker) of sql server. Maar er was een hele grote klant die Oracle gebruikte ... Dusja heb toen echt wel met Oracle leren werken en ik kon kijken bij elke versie als alles compatibel was met Oracle, want de andere programmeurs deden maar zoals het hun paste. Heb er ook geen jaren gewerkt hoor.

Maar kijk hier in België net hetzelfde. Sinds 2026 is Peppol verplicht, weet je wanneer ik alles aangepast hebt ? Eerste week van januari. Ik had gewoon geen interesse om 2 systemen tegelijkertijd aan te passen.
Waarom moet ik 2 jaar op voorhand klaar zijn ? Omdat het kan ? Factureren bij mijn applicatie is slechts 1 op de 10 die het gebruikt. En dat is niet de core business. Het zit erin, maar je kan niet zomaar doen wat jij denk, het zit wel echt "pot toe" zoals we hier zeggen. Buiten de lijntjes kleuren zit er bij mij niet in. Dat is ook een keuze. Maar in december was slechts nog maar 1 op de 2 bedrijven op het peppol netwerk. Nu zo een 85% terwijl het wettelijk verplicht is.

Voor bepaalde zaken ben ik wel op goed op tijd, voor andere is er geen haast om het zo te zeggen
Ik weet nog dat ik voor een bedrijf werkte en daar kon je kiezen access (alleen lokaal voor 1 gebruiker) of sql server.
Logisch, al zijn er steeds meer die Access gewoon helemaal afschrijven en Excel omarmen voor gebruik als database.
Maar kijk hier in België net hetzelfde. Sinds 2026 is Peppol verplicht,
Binnenkort voor heel de EU verplicht. België loopt hier graag op voorop, wilde het eigenlijk vorig jaar al verplichten voor B2G. Nederland loopt weer eens achter, maar zet wel graag de grote mond op dat we hier zo vooruitstrevend zijn. De twee EU-landen met de meest ridicule overheden.
Waarom moet ik 2 jaar op voorhand klaar zijn ?
Zoals ik al zei, wilde België het voor B2G eigenlijk vorig jaar al verplichten maar niemand was klaar. Zoals ik heb begrepen zijn er de laatste maanden ook nog diverse functies aan Peppol toegevoegd en komen er in de loop van dit jaar nog enkele essentiele onderdelen bij en is het pas dan volledig functioneel.
Factureren bij mijn applicatie is slechts 1 op de 10 die het gebruikt. En dat is niet de core business.
Ik heb uiteraard geen idee wat voor applicatie je maakt, maar vind het apart dat dan slechts 1:10 het gebruikt.
Maar in december was slechts nog maar 1 op de 2 bedrijven op het peppol netwerk. Nu zo een 85% terwijl het wettelijk verplicht is.
Tja, praktisch gezien moet je het via een externe partij (bv een boekhoudkantoor) afsluiten of een en softwareabonnement nemen, beide met extra kosten.
Je kon geen radio of tv openzetten of je hoorde over peppol .... Zelfs Doccle heeft een oplossing bijvoorbeeld. Maar er zijn nog altijd bedrijven niet geregistreerd op Peppol, vraag me af wat voor boekhouder ze hebben.

Ik heb een saas applicatie en veel mensen gebruikten al programma x voor de facturen. Er zijn ook boekhouders die verplichten om mensen applicatie X te gebruiken bijvoorbeeld (zij strijken dan ook nog een percentje op, maar dat weten veel mensen niet uiteraard). En uiteraard heb je altijd een hele hoop die wat nieuws niet willen gebruiken en ook eigenwijs zijn en hunzelf graag extra werk bezorgen. Mij niet gelaten uiteraard.

Enja wij moesten weer de eerste zijn. Er zijn inderdaag nog wat toevoegingen geweest. Zo was er ook in het begin gezegd dat het op BTW nummer moest werken ... Echter heeft niet elke onderneming een btw nummer. Dus heb je hier 2 registraties 0925:btwnummer en 0208:ondernemingsnummer (btw nummer is ondernemingsnummer met BE ervoor). Dus je hebt mensen die beide hebben en je hebt mensen die alleen 0208 hebben. Niet dat het veel uitmaakt want 0208 is verplicht, dus je kan altijd via daar sturen. Maar kan uiteraard verwarring veroorzaken.

Het enige dat echt een gemis is ... Ook automatisch doorsturen naar boekhouder, uiteraard is dat niet de taak van Peppol, maar dat zou pas een handige functie zijn.
[quote]Je kon geen radio of tv openzetten of je hoorde over peppol ....[/quote
Tot ongeveer 1999 luisterde ik veel naar Studio Brussel. Helaas was het toen afgelopen omdat ze hebben ze de regionale omroep op vrijwel dezelfde frequentie hebben gezet als StuBru. Inmiddels is het genre muziek dat ze spelen dusdanig gewijzigd dat ik me er helemaal niet meer thuisvoel. Daarna heb ik nog een tijdje geluisterd naar BNR en sinds 2012 luister ik geen enkele radio meer. TV is eveneens gedaald en sinds 2025 keek ik alleen nog Nederlands (RTL) nieuws en (NOS) journaal.
Zelfs Doccle heeft een oplossing bijvoorbeeld.
Het bedrijfje dat ik ken vermijdt zelfs dat. Alleen Helena en (via Itsme) bank en de sites voor declareren van federale opdrachten en legalisatie van documenten komt ze niet omheen.
Maar er zijn nog altijd bedrijven niet geregistreerd op Peppol, vraag me af wat voor boekhouder ze hebben.
Ik denk dat veel kleine bedrijven hun concept-factuur naar de boekhouder sturen en dat die het in een Peppol-portal (zoals Kate) invoert.
Ik heb een saas applicatie
ruim begrip.
en veel mensen gebruikten al programma x voor de facturen.
Ja daar hoort het al in te zitten.
Er zijn ook boekhouders die verplichten om mensen applicatie X te gebruiken bijvoorbeeld (zij strijken dan ook nog een percentje op, maar dat weten veel mensen niet uiteraard).
Klopt.
Enja wij moesten weer de eerste zijn.
Voor dat soort dingen wilt ofwel België ofwel Nederland het braafste jongetje zijn en vooroplopen. In Nederland is het vaak wat selectiever. Verplichtingen voor burgers en bedrijven ja, wetgeving die hen moet beschermen, nee.
Er zijn inderdaag nog wat toevoegingen geweest. Zo was er ook in het begin gezegd dat het op BTW nummer moest werken ... Echter heeft niet elke onderneming een btw nummer.
Degenen die zoiets bedenken zijn geen mensen uit de praktijk. Vlaamse bedrijven die vrijgesteld zijn omdat ze kleine ondernemers zijn (omzet <=25.000) hebben wel een BTW-nummer maar mogen dat niet naar klanten of leveranciers communiceren. Nederlandse vrijgestelden (omzet <20.000 of bv vrijgestelde diensten) hebben helemaal geen BTW-nummer.
Dus heb je hier 2 registraties 0925:btwnummer en 0208:ondernemingsnummer (btw nummer is ondernemingsnummer met BE ervoor). Dus je hebt mensen die beide hebben en je hebt mensen die alleen 0208 hebben. Niet dat het veel uitmaakt want 0208 is verplicht, dus je kan altijd via daar sturen. Maar kan uiteraard verwarring veroorzaken.
In NL is ondernemingsnummer (KVK-nummer) per definitie anders en een bedrijf met meerdere vestigingen heeft voor iedere vestiging een nummer bij KVK en één gezamelijk KVK-nummer.
Zelfstandigen en eenmanszaken hadden tot voor kort een BTW-nummer dat identiek was aan hun BSN-nummer (rijksregisternummer zeg maar), maar dan met B01 er achter, en als ze personeel hebben, als loonheffingsnummer met L01 er achter.
Het enige dat echt een gemis is ... Ook automatisch doorsturen naar boekhouder, uiteraard is dat niet de taak van Peppol, maar dat zou pas een handige functie zijn.
Als de aansluiting gaat via bv Kate en het abonnement loopt via de boekhouder, dan heeft die zo ook gelijk inzage.
denk dat NTLM de volgende 10 jaar nog meer dan voldoende te vinden zal zijn :-)
Als ik zie hoeveel dat nu nog in gebruik is...
Ik denk het niet eigenlijk, of je moet wel een hele oude versie van Windows Server gebruiken.

Sowieso is Microsoft keihard aan het pushen om iedereen op Azure te krijgen. Een onpremise server is eigenlijk niet meer van deze tijd.

NTLM wordt al sinds 2010 uitgefaseerd. NTLM was nog wel beschikbaar, maar niet de default. Er zat nog een stukje NTLM-fallback in voor lokale authenticatie, mocht het domein niet beschikbaar zijn. En dat zat hardcoded ingebakken in Windows en er waren ook geen alternatieven voor.

Dus buiten Microsoft zelf werd NTLM al bijna niet meer gebruikt.

Nui is Microsoft zover dat ze NTLM default uit gaan zetten. Het is nog niet verwijderd, dat klopt, maar je moet wel moeite doen om het weer aan te zetten. Microsoft kennende zullen ze het geleidelijk aan lastiger maken om het weer aan te zetten. Dat zelfde zag je ook met SMB dat het steeds moeilijker en moeilijker werd om het te vinden in het OS.

Uiteindelijk heeft het er wel toe geleid dat SMB in zijn geheel is uitgefaseerd en dat zelfde gaat nu ook met NTLM gebeuren.

Of je moet echt een WIndows Server 2008 machine hebben draaien en Windows 7 als clients.
Sorry, maar in deze reactie sla je de bal toch enkele keren grondig mis.
Als je NTLM niet actief gaat uitzetten/veiliger maken met GPO's en zo is dat voor kwaadwilligen nog steeds te misbruiken.
En eigenlijk is NTLM als sinds Windows 2000 met de komst van Kerberos een legacy protocol, niet sinds 2010 of zo...

SMB is ook helemaal niet uitgefaseerd, SMBv1 sinds Server 2016.

Daarnaast is onprem servers in véél gevallen gewoon nog steeds het meest kostenefficiënt.
Er zijn zeker usecases waar Azure interessanter is dan onprem, maar minstens evenveel usecases waar onprem altijd gaat winnen.
Wou net zeggen, je kan praktisch gratis on-prem AD draaien - als je hardware koopt van een OEM krijg je de license er voor een tientje ofzo bij. Als ik vergelijkbare functionaliteit uit Entra wil halen moet ik 20 euro per user bij mn 365 kosten op tellen...
Je user of device cals krijg je niet voor een tientje erbij van de OEM.
Maar inderdaad is in veel situaties, zeker voor legacy system on-prem veel goedkoper.
Dat klopt natuurlijk, maar daar betaal je wel maar een keer voor.
Nee hoor, met de komst van Kerberos is nooit gezegd dat het uitgefaseerd zou worden. Het is altijd als fallback gebruikt, aangezien Kerberos toen geen offline auth mech had.

Pas in 2010, met de openbaring van een paar gemene security issues (die wel zijn verholpen trouwens), heeft Microsoft gezegd dat ze er wel klaar mee waren, maar ook toen hadden ze nog geen offline auth.

Nu pas wordt er gezegd dat ze NTLM helemaal eruit gaan slopen aangezien sommige core componenten nog steeds NTLM fallback hardcoded hebben.

Oh sorry, ik heb er niet bij vermeld dat het ging om v1.... Maar hoe ging dat ook alweer? Exact hoe ik het beschreef volgens mij?

Onprem is kosten effectief? Zeker als jezelf niet voor de stroom en onderhoud hoeft te betalen, want dan is het inderdaad gratis. Als je het netjes wil doen, heb je 1 machine nodig als domeincontroller, 1 machine nodig als fileserver en nog een machine nodig als mailserver. Dat tikt best snel aan.
En in de praktijk wordt de DC ook gebruikt als file en mailserver. Puur om budgetaire redenen, Alles perfect volgens de regels van de kunst opzetten is goed als je in een enterprise omgeving werkt met grote IT budgetten waar men niet kijkt op een paar duizend euro's.

En onderhoud, dat moet je ook op je cloud server doen hoor. Blijft alleen nog de stroomrekening over en dan hebben we het ook niet over duizenden euro's per jaar meer aan electriciteit.
En in de praktijk wordt de DC ook gebruikt als file en mailserver.
Er is een reden waarom Microsoft tijdens de installatie overal keihard roept dat het geen goed idee is om je CA, DA, FS en andere diensten op een en dezelfde machine te hebben. Is ook het domste wat je kan doen, lijkt een goed idee tot ineens alles, maar dan ook echt alles, wegvalt.
En onderhoud, dat moet je ook op je cloud server doen hoor.
Volgens mij denk jij dat je een fysieke server in de cloud krijgt ofzo... nee, dat krijg je niet en dat moet je niet. Azure, Intune, Autopilot, Defender, etc. zijn allemaal easy mode. Als je er een beetje tijd in steekt, kan iedereen het.
Blijft alleen nog de stroomrekening over en dan hebben we het ook niet over duizenden euro's per jaar meer aan electriciteit.
Uuh, eigenlijk wel. Jij bent echt iemand die het niet hoeft te betalen, dus heb je er ook nooit over nagedacht. Beetje server 24/7 laten draaien kost je rond de 800 euro p/j aan stroom.
Er is een reden waarom Microsoft tijdens de installatie overal keihard roept dat het geen goed idee is om je CA, DA, FS en andere diensten op een en dezelfde machine te hebben. Is ook het domste wat je kan doen, lijkt een goed idee tot ineens alles, maar dan ook echt alles, wegvalt.
Zoals ik al zei... theorie vs praktijk. In best practice moet je ook een 2de DC hebben voor het geval de 1ste er onderuit gaat. Dan spreek je over worst case scenario's en daarvoor heb je back-ups. Kosten vs baten.
Volgens mij denk jij dat je een fysieke server in de cloud krijgt ofzo... nee, dat krijg je niet en dat moet je niet. Azure, Intune, Autopilot, Defender, etc. zijn allemaal easy mode. Als je er een beetje tijd in steekt, kan iedereen het.
Windows server moet ook updates krijgen, daar is het irrelevant of het nu een fysieke of cloudserver is. Intune is gratis?
Uuh, eigenlijk wel. Jij bent echt iemand die het niet hoeft te betalen, dus heb je er ook nooit over nagedacht. Beetje server 24/7 laten draaien kost je rond de 800 euro p/j aan stroom.
800€/jaar =/= duizenden euro's per jaar.

https://intercept.cloud/nl-nl/blogs/wat-kost-azure
Kostprijs voor 1 van de goodkoopste opties voor een Azureserver kost $100 per maand. dat is $1200 op jaarbasis. Na 5 jaar heb je $6000 uitgegeven. Koop je een lokale server van $5000 die performanter is heb je al $1000 uitgespaard

https://www.toolsvoorondernemers.nl/hoeveel-kost-een-eigen-server-aan-energie/
Hier rekenen ze voor een machine die 300watt verstookt 50€ aan maandelijkse kosten, dat is 600€ per jaar. Machines die 300w continue verstoken, dan hebben we het al niet meer over een simpel servertje. Voor een DC & fileserver heb je geen zware machine nodig, in die context zal de stroomrekening voor zo een server echt geen 600€ per jaar zijn.

Cloud servers hebben zo hun voordelen, maar als je cloud servers neemt met de gedachte hier geld mee te besparen zal dat dik tegenvallen.
Zoals ik al zei... theorie vs praktijk. In best practice moet je ook een 2de DC hebben voor het geval de 1ste er onderuit gaat. Dan spreek je over worst case scenario's en daarvoor heb je back-ups. Kosten vs baten.
Daarom is het misschien ook beter dat juist die mensen cloud diensten nemen.
Windows server moet ook updates krijgen, daar is het irrelevant of het nu een fysieke of cloudserver is. Intune is gratis?
Kostprijs voor 1 van de goodkoopste opties voor een Azureserver kost $100 per maand.
Jij denkt echt nog steeds dat je met Intune een aparte virtuele WIndows Server instantie draait... Echt om te lachen dit. Als je niet weet hoe het werkt, reageer dan niet.

Nee je betaalt geen 100 dollar pm, want je draait geen virtuele server. Ik snep even niet hoe jij komt op die 100 dollar trouwens want je betaalt per tik op de meter. Kijk maar eens in je Azure panel dan zal je zien dat ze de kosten specificeren en die kosten zijn afhankelijk van processing.
Elektriciteitsprijs: €0,23 per kWh
Daar gaat het al mis.

Je zult sowieso minimaal 2 machines moeten draaien dus is al 1600 pj.

[Reactie gewijzigd door TechSupreme op 2 februari 2026 01:13]

Een onpremise server is eigenlijk niet meer van deze tijd.
Iedereen die dat nu nog roept is niet bezig met de toekomst en zou de NIS2 er nog maar eens op na moeten slaan, ongeacht of deze van toepassing is.

Schakel de toegang tot je tenant maar eens uit voor 2 dagen.

[Reactie gewijzigd door CPM op 30 januari 2026 14:04]

Ik snap even niet wat je hiermee bedoelt. Een on-premise server zou veiliger zijn dan een cloud-managed MDM?

NIS2 is van toepassing op cruciale infra, dan werk je op een totaal andere schaal en heb je totaal andere eisen. Wat dat met een MKB'tje te maken heeft is mij een raadsel.
Dit gaat niet over security maar o.a. over risicomanagement en weerbaarheid en continuïteit. Als jouw MKB'tje een paar dagen (of week, ect) niet kan werken omdat er geen toegang tot (bijv.) je tenant is komt je bedrijfscontinuïteit en eventueel bestaansrecht in gevaar. Dat moet je toch zelf begrijpen of in ieder geval de eindverantwoordelijke binnen jouw MKB. En daar gaat mijn opmerking over. Jij roept dat een on-premise server niet meer van deze tijd is, dan begrijp je imo niet wat er speelt in de wereld en wat de NIS2 daarmee te maken heeft. Simpel voorbeeld: Eén van de redenen dat ziekenhuizen heel veel on-premise hebben is vanwege continuïteit bij wegvallen van bijv. internet/clouddiensten. Ook supermarkten en leveraciers bijv. hebben met dit vraagstuk te maken. Dat Microsoft iedereen naar de cloud pusht is gewoon vanwege het verdienmodel. En Amerika kan Microsoft gewoon dwingen tot toegang tot die cloud. Ik denk dat jij van meerwaarde kunt zijn voor jouw MKB als je eens in gesprek gaat met de eindverantwoordelijken over wat/als situaties en een risico-inventarisatie gaat doen. Dat de NIS2 misschien te uitgebreid is voor jouw MKB'tje kan zo zijn, maar je kunt er zeer veel waardevolle info uithalen die iedereen binnen zijn/haar IT functie kan gebruiken. En wil je het simpel testen, schakel de toegang tot je tenant uit en je zult zien hoe snel mensen aan jouw bureau staan.

[Reactie gewijzigd door CPM op 1 februari 2026 16:50]

Ja leuk en aardig... Maar nogmaals, jij pakt de NIS2 eisen voor een maatschappelijk cruciaal netwerk en gaat dat toepassen op een MKB.

Amerika dit, Amerika dat. Feit is dat we vastzitten aan Windows. Kun je er een heel verhaal van maken, maar feit is gewoon dat. Met Windows Server en Windows 11 zit je ook vast aan diezelfde Amerikanen. Dus onder de streep verandert er vrij weinig als je alles on-perm gaat doen.

Dan kom ik terug op jouw woorden. Dan kan een mkb'er die absoluut geen verstand heeft van IT een extern bedrijf inhuren om zijn beveiliging op hetzelfde niveau te krijgen als dat van een kant-en-klare dienst. Dat gaat dus niet gebeuren.

Als we dan puur en alleen kijken naar beveiliging van 3de partijfactoren, dan is het toch beter dat een mkb een kant-en-klare clouddienst afneemt. Wat jij zegt is dat je die 2de partij ook niet vertrouwd, tja die dingen zijn nou eenmaal zo, maar die 2de partij beschermt jou wel tegen de 3de partije die vele malen kwaadwillender is.

Als je het dan toch niet hebt met Azure, zijn er Europese alternatieven, maar ook die blijven in essentie afhankelijk van de Amerikanen.

Leuk, maar in plaats van dat je dit roept, zou het niet beter zijn als je eerst gaat investeren in Europese alternatieven die op hetzelfde niveau zijn?

[Reactie gewijzigd door TechSupreme op 2 februari 2026 01:09]

Sorry om dit te zeggen maar je slaat de plank echt compleet mis met wat je zegt en ik denk ook niet dat je het gaat begrijpen, hoeveel ik het je ook uitleg.

"er veranderd weinig als je dat in prem gaat doen".

Sorry hoor maar als je het verschil niet begrijpt tussen on-prem (stand alone) en cloud dan kan ik je echt niet verder helpen. Alles wat on-prem en standalone draait kan je prima isoleren van Microsoft bijvoorbeeld.

Je roept iets over vertrouwen, daar gaat het niet om. Het gaat om (o.a.) risicomanagement.

Het gaat niet (alleen) om Europese alternatieven, het gaat erom dat je je afvraagt wat er kan gebeuren en op basis daarvan keuzes gaat maken.

Ik haak nog altijd in op jouw opmerking dat on-prem servers niet meer van deze tijd zijn. Dat mag je vinden maar in deze tijdsgeest is dat een opmerking die veel bedrijven (groot en klein) niet zomaar meer roepen.

Dus als jij beheerder (oid) bent gaat met je leidinggevende/eindverantwoordelijke in gesprek en ga risico scenario's uitwerken voor als jullie cloud zaken niet meer bereikbaar zijn. Dat niet doen is gewoon dom.

[Reactie gewijzigd door CPM op 2 februari 2026 07:31]

Wat jij wil is die onprem server zo inpakken dat hij amper verbinding heeft met wat dan ook. Om dat voor elkaar te krijgen moet je er flink wat tijd en geld in steken, geld wat er niet is.

Zolang jij afhankelijk bent van Microsoft maakt onprem of cloud ook geen zak uit.

Leuk verhaal, maar die gegevens van de mkb zijn niet oz giga gevoelig. Enige wat mkb wil is zichzelf beschermen tegen uitval en tegen ransomware van 3de partijen. Dat jij gigantisch anti-Amerika bent hebben ze geen boodschap aan.

Zolang jij dat niet kan begrijpen kan je allerlei uitspraken doen, maar alles wat je zegt slaat kant nog wal.

Maar goed, jij mag bij mij komen. De diensten allemaal netjes inrichten volgens NIS2. En alles wat meer kost als de cloud is voor eigen rekening.

[Reactie gewijzigd door TechSupreme op 2 februari 2026 09:21]

Ik ben blij dat ik jou niet als beheerder in dienst heb want aan de antwoorden te zien begrijp je er echt helemaal niets van van waar ik het over heb, geen probleem hoor.

De kern van het verhaal (waar jij elke keer aan voorbij gaat) gaat over jouw opmerking: "Een onpremise server is eigenlijk niet meer van deze tijd."

Vervolgens begin je over mijn anti-Amerika statement (ik heb nergens gezegd dat ik anti ben maar goed) over security, gevoeligheid van gegevens MKB etc.

"Maar goed, jij mag bij mij komen. De diensten allemaal netjes inrichten volgens NIS2. En alles wat meer kost als de cloud is voor eigen rekening."

Deze is helemaal hilarisch en typerend voor het feit dat je echt niet begrijpt waar ik op doel.

"Wat jij wil is die onprem server zo inpakken dat hij amper verbinding heeft met wat dan ook. Om dat voor elkaar te krijgen moet je er flink wat tijd en geld in steken, geld wat er niet is."

Deze is ook grappig, een Windows omgeving is met een simpele firewall te isoleren en kan zo prima draaien zonder cloud beschikbaarheid in een standalone scenario (hoe denk je dat dat gaat in IC in ziekenhuizen, die draaien ook door zonder cloud etc).

Maar ik maak het simpel voor je: schakel de internet verbinding of toegang to tenant even uit binnen jouw MKBtje, wacht een paar dagen en dan zul je en prima gesprek kunnen voeren met de eindverantwoordelijke over hoe je beter voorbereid kunt zijn op dat soort situaties om dergelijke risico's in te schatten, de juiste processen in te richten en middelen en maatregelen er op aan te passen.

En als extra tip: lees eens het nieuws wat vaker over geopolitieke spanningen en de afhankelijkheid die er is van bepaalde landen op clouddiensten en welke gevaren er zijn. Blind afgaan op cloud, dat is niet meer van deze tijd. (maar misschien voor jou wel.)

En hier laat ik het bij, succes met je MKB. :+

[Reactie gewijzigd door CPM op 2 februari 2026 10:32]

Toevallig ben ik ook geen beheerder, ja beheerder van het geld. Geld waar malloten zoals jij denken dat ze het zomaar en vrij uit mogen geven.

Allemaal praatjes op hogen poten, maar geen daden. Als je het allemaal zo goed weet, kom maar hier. Ik betaal, tot waar ik nu voor betaal. De rest mag jij uit eigen zak betalen. Deal?

Als je echt zo'n grote jongen bent met grote praatjes kom je het hier waar maken.
Ow je bent geen beheerder, dat verklaart veel. Stom van me, dat had ik kunnen weten.

Maar nee ik sla je aanbod af, je hebt voor mij al bewezen dat met jou in gesprek gaan totale verspilling is van mijn tijd en ik mij ook niet wil verlagen tot dat niveau.

En je kan wel gaan lopen dreigen maar daar ben ik echt niet van onder de indruk. Maar veel succes met het beheren van je MKB centjes.

[Reactie gewijzigd door CPM op 2 februari 2026 22:28]

Nogmaals, geen woorden maar daden.

Weet je wat, ik betaal zelfs een auditor die jij uit mag kiezen. Maar onder de streep jouw werk moet gelijkwaardig of beter zijn als de mijne of jij moet er zelf tijd in steken om het zo te krijgen. Gratis en voor niks.

[Reactie gewijzigd door TechSupreme op 3 februari 2026 01:07]

SMB uitgefaseerd? In welke wereld leef jij? Fileservers zijn zeker nog in gebruik.
En alles naar Azure dat zal Microsoft wel willen, maar voor veel bedrijven is hybrid nog altijd de beste oplossing.
Dat gaat over SMBv1, niet over SMB in het algemeen zitten momenteel aan v3
Ja waar dacht jij dat het over ging? Als je alles zo goed weet te vertellen, dan weet je toch ook dat het gaat om SMBv1?

Hoe ging dat ook alweer met die uitfasering? Precies, zoals ik het zei. Met stapjes en geleidelijk moeilijker om het aan te zetten.

Het ging hier niet eens om de versie van SMB, het ging om de werkwijze van MS. Moet ik dan ook echt de versie erbij vermelden? Even lezen en begrijpen.
SMB uitgefaseerd? In welke wereld leef jij?
In welke wereld leef jij?

[Reactie gewijzigd door TechSupreme op 1 februari 2026 13:29]

Jij zij dat smb was uitgefaseerd in je originele post, geen woord over v1.

Dan moet je niet doen alsof mensen jouw beweringen raar vinden, als je ze niet correct formuleert.
Ik vind het raar dat mensen doen alsof ze het fijne ervan weten, maar niet kunnen extrapoleren dat het gaat om v1. Als jij alles zo goed weet, dan weet jij toch ook dat het gaat om v1?

En nogmaals, het gaat niet om welke versie het was. Het gaat om de werkwijze van Microsoft. Dus wat is het nut van jouw reactie?

[Reactie gewijzigd door TechSupreme op 2 februari 2026 01:14]

Sowieso is Microsoft keihard aan het pushen om iedereen op Azure te krijgen. Een onpremise server is eigenlijk niet meer van deze tijd.
Uhmm dat was voorheen misschien zo en Azure is nog steeds een van de grootste inkomste bronnen van Microsoft maar Microsoft zet momenteel hard in op hyrbide-cloud met Azure Local, Microsoft 365 Local en neem bijvoorbeeld Azure Virtual Desktop. Het zit in de naam dit draait binnen Azure.

Dit is al een tijd beschikbaar als Hybride setup i.c.m Azure Local en later dit jaar Microsoft Hyper-V, Nutanix AHV, VMware vSphere, physical Windows Servers, of iedere andere Azure ARC enabled on-premises server. Waarbij partner support vanuit ControlUp, LoginVSI, Nerdio, and Nutanix bijvoorbeeld meegenomen wordt door Microsoft.

https://techcommunity.microsoft.com/blog/azurevirtualdesktopblog/announcing-new-hybrid-deployment-options-for-azure-virtual-desktop/4468781

[Reactie gewijzigd door HKLM_ op 30 januari 2026 15:19]

Azure Arc is alleen maar een tool om mensen die on-prem draaien naar de cloud te lokken. Dat hebben ze al best lang.

Ze hebben Arc alleen bedacht voor mensen (zoals je in deze thread genoeg ziet) die zweren bij lokaal of niet weten hoe je naar cloud moet migreren. Je kan dan een hybride setup draaien in de hoop dat ze met de tijd inzien dat on-prem onnodig is en migreren naar cloud.

Jouw link bevestigt het alleen maar. Windows 365 bestaat al een tijdje, virtualisatieservers bestaan ook al een tijdje, je kan lokaal een hele virtuele desktop of alleen een virtuele applicatie draaien. Nu willen ze dat ook naar de cloud verplaatsen, waarom zouden ze anders er een cloud versie erbij hebben als de on-prem al genoeg is?
Ik zeg toch nergens dat arc nieuw is? En ze verplaatsen het huis van de full cloud naar hybride.

[Reactie gewijzigd door HKLM_ op 1 februari 2026 15:40]

En ik zeg jou dat Arc alleen een lokkertje is om mensen over te krijgen naar de cloud.
On-prem niet meer van deze tijd?
Ik zie juist het omgekeerde gebeuren bij veel bedrijven. Bedrijven hebben steeds minder vertrouwen in de Cloud, en zeker het debacle bij Amazon heeft mensen aan het denken gezet. Bij een redelijke groep bedrijven is het zelfs niet eens meer toegestaan om in de Cloud te zitten.
Hetgeen echt niet meer van deze tijd is is NTLM.
Maar waar halen ze het geld vandaan om het on-prem te draaien met hetzelfde beveiligingsniveau?
Niet alleen hetzelfde beveiligingsniveau, gewoon puur met hetzelfde onderhoud. De facturen van dat computermanneke dat even de server komt herstarten voor een update moeten ook betaald worden.
NTLM was toch van Windows 98/NT pre-SP5? Als je wachtwoord korter dan 8 karakters was, dan duurt een brute force op een 80486DX4 iets van 3 minuten, maar omdat het 2x non-case-sensitive 7 karakters was, duurt een brute force van een 14 karakter wachtwoord maximaal 6 minuten op een 80486DX4? Ik kan mij nog herinneren dat we als scholieren Mimikatz deden op de SAM om het domain admin wachtwoord te achterhalen.
Met rainbowtables ging het nog sneller :-) maar zou dat niet het verschil zijn tussen ntlm 1 en 2?
Geen idee. Ik weet alleen nog dat we met allerlei tools succesvol de SAM konden uitlezen en omdat de beheerpartij een generiek wachtwoord gebruikte was het heel makkelijk om in de PDC te komen. Later kwam er Syskey, maar dat stelde eigenlijk ook niets voor.

Het is ongelooflijk hoe ver we zijn gekomen. En nog zijn er organisaties die met wachtwoorden werken, terwijl er zo veel ongelooflijk gave technologie is, zoals WHFB.

Heeft de uitvinder van het wachtwoord (een Italiaan ergens in de jaren '70 toch?) niet op z'n sterfbed gezegd dat hij spijt heeft van z'n uitvinding?
Het komt eigenlijk van Lan manager dat was er al voor 98. Een netwerk OS vergelijkbaar met Novell. Kwam eind jaren tachtig op de markt en werd gebruikt in de jaren negentig.
Jouw werk als pentester zal naar ntlm moeten blijven zoeken. Dat je het steeds minder aantreft maakt het voor jou niet anders, het is vooral dat jouw klanten die vulnerabilities niet meer hebben en dus niet meer hoeven op te lossen.

Daarmee vraag ik mij spontaan af of er nog security-advies organen zijn zoals CIS die iets anders roepen over ntlm dan uitschakelen en zo.
Klopt! Ik zal er naar moeten blijven zoeken. Echter zal ik minder gemakkelijk door Windows netwerken heen kunnen bewegen met alleen een NTLM-hash van een gebruiker (wat echt triviaal is). Daarvoor zal ik andere technieken moeten gaan gebruiken die minder makkelijk werken en meer haken en ogen hebben voor mij.
Heb je een Oude NAS’en (Synology/QNAP/WD/Netgear) of oudere Samba shares, deze gebruiken soms NTLM (of NTLMv1). Dan kun je dus niet meer bij je shares
Tenzij je het client-side weer inschakelt. Hetzelfde met toegang tot mappen gedeeld via enkel SMBv1.

[Reactie gewijzigd door The Zep Man op 30 januari 2026 11:52]

Dat is een goede vraag; zonder NTLM compatible client; hoe ga je je Samba shares benaderen op je huis-tuin-en-keuken-NAS zonder Kerberos / AD domain? Iemand ervaring mee?
edit:
Ik denk dat je niet onder een 'domain controller' achtige functie uit kunt voor Kerberos. Mijn QNAP thuis NAS heeft een domain controller functie die ik aan kan zetten, maar geen idee of/hoe ik de lokale user DB dan moet 'migreren' oid.

[Reactie gewijzigd door CaptainKansloos op 30 januari 2026 11:35]

NTLM is niet nodig voor AD. Alleen voor de allereerste versies. SMBv1. Moderne software heeft dat allang uitgeschakeld.

[Reactie gewijzigd door Llopigat op 30 januari 2026 12:13]

Dit inderdaad. Inmiddels is SMBv1 en 2 verouderd en zijn we bij SMBv3.
NTLM is niet nodig voor AD.
Het gaat me niet om of NTLM nodig is voor AD (dat is niet zo); het gaat erover of er een 'AD'-like setup nodig is om - nadat NTLM uit Windows is verwijderd - Kerberos authenticatie tegen je thuis-NAS te kunnen doen. NTLM authenticatie werkt dan immers niet meer vanuit de SMB-client.

Een AD 'kerstboom' opzetten is wat anders dan een paar lokale accounts instellen met NTLM; zeker in een recht-toe-recht-aan thuis NAS scenario.

[Reactie gewijzigd door CaptainKansloos op 30 januari 2026 12:37]

Het is technisch niet zo eenvoudig nee maar het samba pakket voorziet daar gewoon in en een goede NAS doet dat ook gewoon.

Alleen heel oude of goedkope NASen zullen nog op ntlm leunen. Veel clients verbinden ook allang niet meer met smbv1.

Er verandert ook weinig aan de cliënt kant, je hart van een workgroup naar een domein. Met een Windows Server verandert dat veel omdat die ook policies kan pushen maar een gewone samba installatie doet dat niet. Die hele kerstboom is optioneel :)

[Reactie gewijzigd door Llopigat op 30 januari 2026 13:08]

Mijn Synology is van 2010, laatste update was 2016 of 2019 ?
Denk jij dat ik een courante samba versie draai ?
syno> smbd -V
Version 4.1.18
Synology Build 5967, Apr 26 2016 17:08:12

[Reactie gewijzigd door goarilla op 30 januari 2026 21:24]

Die Samba versie heeft al smbv3:
Major enhancements in Samba 4.1.0 include:

Client tools support SMB2/3

Samba 4.1.0 contains the first release of our client tools and client library that work over the new protocols SMB2 or SMB3. Note that SMB3 only works either to a Samba server version 4.0.0 or above, or to a Windows Server running Windows 2012 or Windows 8.
Dit waren overigens de client tools, de server was al supported sinds 4.0.0 zo te zien.

[Reactie gewijzigd door Llopigat op 30 januari 2026 21:53]

Mmmm ik dacht dat SMBvX de transport protocollen waren en NTLMvX
de authenticatieprotocollen. Dus er zit een authenticatieprotocol in SMB ingebakken dan ?
edit:
Wat gegoogle lijkt dat te bevestigen, bedankt.

[Reactie gewijzigd door goarilla op 30 januari 2026 23:20]

Het is technisch niet zo eenvoudig nee maar het samba pakket voorziet daar gewoon in en een goede NAS doet dat ook gewoon.
Ik kan je verhaal niet zo goed volgen, maar ik neem aan dat je hier bedoelt: "De Samba service op een fancy NAS kan al zelf een AD-like functie met Kerberos aanbieden"?
edit:
Ik lees net dat Samba 4 een eigen AD spullenboel mee levert. Hetbzal een beetje per NAS afhangen hoe dat geconfigureerd moet worden.

[Reactie gewijzigd door CaptainKansloos op 30 januari 2026 23:06]

Jij bent dus ook aan het panikeren ... Ik ging er impliciet van uit dat SMBv3 zijn eigen authenticatie doet of toch een veilig kanaal maakt door zijn inherente encryptiemogelijkheden: https://learn.microsoft.c.../file-server/smb-security. Maar ... nu ik wat verder lees ... oh boy ... weet ik het niet meer.

Persoonlijk zie ik op mijn oude Synology NAS alleen mogelijkheden om een AD te joinen als member dus ik vrees ervoor.

[Reactie gewijzigd door goarilla op 30 januari 2026 23:19]

Ik ben niet aan het panikeren, maar ik denk wel dat 'niks doen' geen optie is. Ik vermoed dat veruit de meeste NAS-en out-of-the-box op NTLM authenticatie leunen.

Zoals eerder gezegd heeft mijn QNAP een module om AD te 'emuleren'. Ik neem aan dat ik nog een stap moet maken om bestaande locale user accounts op de NAS over te zetten oid. Maar mss integreren die wel naadloos na het activeren van deze functie. Mij oorspronkelijke vraag was daarop ingestoken; wie heeft daar ervaring mee?

Ik denk wel in deze discussies hier dat veel mensen SMB encryptie, NTLM of Kerberos authenticatie en Active Directory vrij makkelijk door elkaar halen. Vanuit dat perspectief maak ik me wel een beetje zorgen; dat kan straks nog wel eens tegen gaan vallen.

[Reactie gewijzigd door CaptainKansloos op 31 januari 2026 08:00]

Ik denk wel in deze discussies hier dat veel mensen SMB encryptie, NTLM of Kerberos authenticatie en Active Directory vrij makkelijk door elkaar halen. Vanuit dat perspectief maak ik me wel een beetje zorgen; dat kan straks nog wel eens tegen gaan vallen.
Inderdaad, ik zie door dat bos de bomen niet meer. En vraag me af wat ik dan moet doen ... een DNS, Kerberos/Samba server opstellen en/of users overzetten en/of data overzetten en de (ver)ouderde Synology promoten tot Active Directory member server of alles vervangen. Zucht ... misschien dan toch liever NFSv3 8)7 Dat is veel makkelijker en ook veel onveiliger ja maar het zit achter een firewall met maar 2 echte actieve gebruikers.
Op jou msWindows gebaseerde desktop systeem en jou nas gebruikt je mogelijk het zelfde account met het zelfde wachtwoord maar ik kan mij niet voorstellen dat als je het wachtwoord op je nas aanpast dat dan automatisch het wachtwoord op je laptop is aangepast.

Met een dergelijke test blijkt dat het dus stiekum niet het zelfde account is maar het zijn beide lokale accounts op de lokale systemen. Dan gebruik je dus geen active directory en dus geen ntlm.

Bedenk, een smb/samba/cifs share kan je altijd benaderen met 'lokale' accounts. De meeste nas systemen werken zo. EN de meeste msWindows systemen onthouden best veel accounts/wachtwoorden. Bijvoorbeeld van shares die ooit gekoppeld zijn geweest.

Nota: In mijn test is het dus niet dat je op je laptop het wachtwoord aanpast en dan nog steeds bij je nas-share kunt. Dat kan op basis van het onthouden account/wachtwoord voor de share.

Het gebruik van ntlm is onderdeel van het gebruik van active directory in de oudere msWindows systemen. Gebruik je geen active directory, dan gebruik je bijna zeker geen ntlm.
Mmm, dit begrijp ik niet goed:
Bedenk, een smb/samba/cifs share kan je altijd benaderen met 'lokale' accounts. De meeste nas systemen werken zo. EN de meeste msWindows systemen onthouden best veel accounts/wachtwoorden. Bijvoorbeeld van shares die ooit gekoppeld zijn geweest.
Is dat niet exact wat NTLMv(1/2) en LANMAN doen ... client en server authenticeren door
passwoorden "scrambled" over het netwerk via een bagger challenge/response protocol indirect uit
te wisselen ? En doet samba dat niet na ? Hoe authenticeren zij dan verschillende users
tussen de verschillende systemen ?


Edit: Llopigat en het Internet lijken te bevestigen dat SMBv3 zijn eigen authenticatie doet.

[Reactie gewijzigd door goarilla op 30 januari 2026 23:24]

Edit: Llopigat en het Internet lijken te bevestigen dat SMBv3 zijn eigen authenticatie doet
Ik vind dat nergens terug. Heb je daar een link van? SMB ondersteund, ook in SMBv3 alleen NTLM en Kerberos. Los van alle SMB encryption, multisession, preauthentication integrity en andere shenanigans. In de nieuwe features van SMBv3.1.1 rept de MS documentatie alleen over NTLM, Kerberos en 'others' maar het wordt nergens duidelijk wat die others dan zouden zijn.
Is dat niet exact wat NTLMv(1/2) en LANMAN doen ... client en server authenticeren door
passwoorden "scrambled" over het netwerk via een bagger challenge/response protocol indirect uit
te wisselen ? En doet samba dat niet na ? Hoe authenticeren zij dan verschillende users
tussen de verschillende systemen ?
Dit is precies het punt. Authenticatie gebeurt op basis van een - sterk gesimplificeerd - shared secret. Die uitwisseling kan op basis van NTLM(v2) of Kerberos. Zonder NTLM support blijft alleen Kerberos nog over.
De protocollen NLTM en LANMAN komen uit de microsoft hoek en zijn voor communicatie tussen mswindows gebaseerde systemen.

Als je vanaf een mswindows gebaseeerd systeem inlogt op een smb/samba/cifs share, dan authenticeer je vanaf jou mswindows machine naar dat andere systeeem. Daarvoor gebruik je in de basis situatie zoals de meeste thuis gebruikers lokale accounts: Lokaal op de mswindows machine en lokaal op je smb/samba/cifs systeem. Daarbij wordt geen ntlm gebruikt.

Pas als je mswindows en smb/samba/cifs systemen zijn gekoppeld aan het zelfde mswindows active directory systeem kan in de athenticatie gebruik gemaakt worden van ntlm om jouw account over en weer te valideren. Daar kan dus ntlm gebruikt worden maar al zo'n 20 jaar kunnen ook msWindows systemen gebruik maken van kerberos. Dat ntlm en/of kerberos wordt gebruikt zodat je minder vaak je wachtwoord hoeft in te typen.

Als je het over samba hebt: Ja, samba heeft ook een tijdje haar best gedaan om met ntlm mee te praten zodat ze kan worden opgenomen in een active directory domein. Samba kan voor zover ik weet ook al tijden met kerberos mee doen. En ja, samba kan haar eigen authenticatie doen, in de basis doet ze dat ook altijd. Ze kan daarnaast ook mee draaien in een ad-domein en net zo makkelijk in een ldap of ipa domein.

[toevoeging] Om mijn eigen gedachten te bevredigen ben ik wat dieper gaan zoeken. Zelfs bij samba versie 2.x documentatie dat onderdeel wordt van een msWindows 200x ad-domein wordt gesproken van het gebruik van kerberos. De term ntlm vind ik veel minder vaak (praktisch niet) terug. Daarmee ga ik er van uit dat zelfs de samba van 20 jaar geleden al met kerberos overweg kon. Dus zelfs een nas uit 2010 hoeft niet te vrezen voor uitschakelen van het ntlm protocol.

Dat er wel wordt gesproken van netbios heeft vooral te maken met de naamgeving: De conventie die ik zelf ooit begrepen heb is dat dns-namen in kleine letters geschreven worden en netbios namen in hoofdletters. Een account naam wordt dan: ADDOMAIN\ACCOUNT of account@ad.domain. Ja, een email adres is een dns-naamgeving. De meeste mswindows login boxen accepteert beiden en is case-aware, niet case-sensitive dus de hoofdletter/kleineletter conventie hoef je niet toe te passen.

[Reactie gewijzigd door beerse op 31 januari 2026 17:28]

Als je vanaf een mswindows gebaseeerd systeem inlogt op een smb/samba/cifs share, dan authenticeer je vanaf jou mswindows machine naar dat andere systeeem. Daarvoor gebruik je in de basis situatie zoals de meeste thuis gebruikers lokale accounts: Lokaal op de mswindows machine en lokaal op je smb/samba/cifs systeem. Daarbij wordt geen ntlm gebruikt.
Hier heb ik sterk mijn twijfels bij ... ik denk dat LM/NTLMv(1|2) gebruikt worden om te checken dat de account waarmee je probeert te authenticeren klopt door een challenge te gebruiken en die te scramblen op de plaint text equivalent passwoord hashes die beide partijen client en server bevatten (lokale accounts SAM db en smbpasswd). Indien die overeenkomen ben je geauthenticeerd. Bij Windows wordt inderdaad standaard de lokale accountnaam en passwoord opgeslagen en wordt dit automagisch gedaan en doorgespeeld voor gebruikersgemak.
Pas als je mswindows en smb/samba/cifs systemen zijn gekoppeld aan het zelfde mswindows active directory systeem kan in de athenticatie gebruik gemaakt worden van ntlm om jouw account over en weer te valideren. Daar kan dus ntlm gebruikt worden maar al zo'n 20 jaar kunnen ook msWindows systemen gebruik maken van kerberos. Dat ntlm en/of kerberos wordt gebruikt zodat je minder vaak je wachtwoord hoeft in te typen.
Maar kerberos en NTLMv(1|2) zijn toch niet hetzelfde en niet mutual exclusive ? Ik ga ervan uit dat Kerberos NTLMv(1|2) kan gebruiken om clients te authenticateren eer het een Ticket Granting Ticket geeft, maar wat gebruikt het dan wanneer het dat niet doet ?
Als je het over samba hebt: Ja, samba heeft ook een tijdje haar best gedaan om met ntlm mee te praten zodat ze kan worden opgenomen in een active directory domein. Samba kan voor zover ik weet ook al tijden met kerberos mee doen. En ja, samba kan haar eigen authenticatie doen, in de basis doet ze dat ook altijd. Ze kan daarnaast ook mee draaien in een ad-domein en net zo makkelijk in een ldap of ipa domein.
Maar samba doet dit toch ook door NTLMv(1|2) te gebruiken ? Wat ik wil weten is ... welke authenticatie wordt er dan wel gebruikt ? Hoe weet de server dat jouw passwoord overeenkomt met het exemplaar van de client. Welke Key-Exchange/Authentication/(Encryption)/(Confidentiality) procedures worden er hiervoor gebruikt ? En ldap is een bizzare directory service/(read many/write sometimes) database waar je in de regel dacht ik "authoratieve company-wide informatie" bewaart.
[toevoeging] Om mijn eigen gedachten te bevredigen ben ik wat dieper gaan zoeken. Zelfs bij samba versie 2.x documentatie dat onderdeel wordt van een msWindows 200x ad-domein wordt gesproken van het gebruik van kerberos. De term ntlm vind ik veel minder vaak (praktisch niet) terug. Daarmee ga ik er van uit dat zelfs de samba van 20 jaar geleden al met kerberos overweg kon. Dus zelfs een nas uit 2010 hoeft niet te vrezen voor uitschakelen van het ntlm protocol.
Maar dit is toch iets anders dit is hoe stel je samba in als AD member server of machine die dan de KDC (AD domain controller) de authenticatie laat doen en wiens ticket jij (samba) indien valide zal vertrouwen ?

Voor zover ik weet is Active directory een amalgaam van Kerberos/LDAP/DCE-RPC/... En dat jij de term ntlm niet vind betekend niet dat het niet gebruikt wordt. Ook tijdens Windows 2000, gingen we van simpele NT 4.0 PDC/BDC domains naar de modernere AD forests met Kerberos. Dat wilden ze destijds ook in de kijker zetten en terecht.

Maar ik hoop dat jij gelijk hebt :D. Ik wil geen DNS, Active Directory/Samba4 DC/KDC, ... opzetten noch wil ik betalen voor Windows Server voor huis-en-tuingebruik. 'Maar ik vrees dat wij beide
enorm uit onze diepte aan het speculeren zijn.

[Reactie gewijzigd door goarilla op 31 januari 2026 18:09]

Het gebruik van ntlm is onderdeel van het gebruik van active directory in de oudere msWindows systemen. Gebruik je geen active directory, dan gebruik je bijna zeker geen ntlm
Dit is simpelweg niet waar, je haalt m.i. een aantal zaken door elkaar. AD is een user directory infrastructuur zoals LDAP dat ook is. Deze ondersteund NTLM of Kerberos als authenticatie protocollen voor de authenticatie van de user. Zonder AD gebruik je juist vrijwel zeker NTLM(v2) voor authenticatie tegen een SMB share. Kerberos dan immers niet zomaar een optie.

AD heeft in de kern niks met SMB of SMB versies te maken, afgezien van het feit dat het dezelfde authenticatie protocollen ondersteund. Daar zit hem meteen de crux; als NTLM vervalt, dan zul je een Kerberos alternatief op moeten tuigen om nog succesvol tegen een SMB share aan the authenticeren. Ik ken zo snel geen andere directory infrastructure dan AD of LDAP (of een 'light' kloon daarvan) voor dit proces. Iemand in het netwerk zal die rol moeten vervullen. Een losse server/service, al dan niet op de NAS.

[Reactie gewijzigd door CaptainKansloos op 30 januari 2026 22:55]

Mijn oude qnap (uitvoering: QNAP TS-419P+ Turbo NAS, uit 2012) heeft voor zover ik weet nooit ntlm hoeven doen. Die heeft altijd al eigen toegangsregistratie gedaan.

In de documentatie van deze qnap nas kan ik alleen maar verwijzingen vinden naar ntlm in de plaatsen waar een koppeling met msWindows active directory met W2003 of W2008. En dan dat nltm1 niet werkt en nltm2 gebruikt moet worden. Dat sterkt mij in de gedachte dat de linux gebaseerde nas apparaten alleen maar ntlm gebruiken als dat door andere partijen gewenst wordt.

Thuis gebruikers hoeven zich geheel geen zorgen te maken, ik kan mij niet voorstellen dat die een active-directory omgeving gebruiken.
Maar zoals we vaak zijn bij Microsoft gaat dit in een tergend langzaam tempo, want afscheid nemen van oude dingen is niet hun sterke kant... Stel je voor dat gebruikers vooruit moeten ;)
En als ze wel een stap hierin zetten, kijk naar windows 11 met TPM 2.0 support, dan zijn er hele grote bevolkingsgroepen die lopen te stuiteren.
Er zit nog wel wat verschil tussen hardware vereisten of software vereisten. Software kun je relatief eenvoudig updaten. Hardware updaten betekent een berg e-waste genereren zoals bij Windows 11 het geval is.
Of gebruikers die op Windows 10 blijven hangen zonder beveiligingsupdates.

Ik was wel aan het kijken of ik mijn server, PC en twee laptops wou gaan vervangen. Ze worden vooral gebruikt voor administratie, mail een beetje browsen en af en toe wat downloaden en vintage gaming. Maar met de huidige CPU, moederbord en RAM prijzen is dat echt niet leuk meer. Ik kan ook niet echt een zuinige CPU vinden die nog wel voelt als een echte upgrade.
Software is zeker niet altijd eenvoudig te updaten. Ik wil niet weten hoeveel miljoenen systemen er nog draaien op Windows 7, XP, 98, DOS, ...
Blame the user. Microsoft ondersteunt Kerberos authentication sinds W2K. Dat is in februari 26 jaar geleden.

Als Microsoft zaken afdwingt, zoals recent met tpm voor w11, dan zie je backlash. En dat is slechts de consumenten. Enterprise is wat hun rekening betaald en die bepalen wat ze nodig hebben en gebruiken. En de tijdslijn die acceptabel is.
Als dit niet langzaam gaat valt de hele wereld erover; hele bedrijven draaien op dat spul en die worden altijd pas weken na de daad wakker... - juist die stabiele factor is een enorm sterk punt van Windows (voor de zakelijke markt iig).

Thuisgebruikers betalen nauwelijks voor windows support contracten, bedrijven wel; dus ja, die bepalen zo'n beetje de koers van 'legacy'...
Ze passen zich aan naar de gebruikers. Zoals hier nog wel eens eentje naar boven komt drijven met zn i3 van de vorige eeuw.
Er zijn genoeg gebruikers voor wie het prima is. Als uit een risicoanalyse blijkt dat het risico acceptabel is dan ga je je tijd en geld eerst elders gebruiken als ondernemer. Niet alles hoeft potdicht te zitten. Als je voor thuis sloten gaat kopen zet je ook niet overal het nieuwste en veiligste er op. Dan kijk je naar het gebruik en het risico. Op een tuinhek hoeft niet eenzelfde kwaliteit slot als op de voordeur.
Het schijnt dat klanten het niet zo leuk vinden als hun 100k apparatuur het niet meer doet omdat microsoft de stekker zomaar ergens uit trekt. Het laten draaien op een oudere non supported windows versie die geen updates krijgt is ook niet altijd een optie.

Daarom gaat Microsoft wat langzamer...
Klanten die vertrouwen op mega oude protocollen, sorry, veiligheid gaat voor.
Maar dat is het hele probleem met windows gebruikers, veiligheid telt niet, er mag vooral niets veranderen.
Te makkelijk.. Apparatuur van tonnen schrijf je niet in 5 jaar af. En als de leverancier dan zegt dat de nieuwe versie die niet afhankelijk is van die protocollen wel geleverd kan worden mits je er nieuwe hardware bij koopt, dan moet je een keuze maken. Oude protocollen kun je met de juiste mitigerende maatregelen ook nog veilig gebruiken.
Als MS te snel gaat, staan hier de comments vol over MS dat legacy niet respecteert.
Raad eens waar ms winst maakt: jij als gebruiker of die grote bedrijven…
Bor Coördinator Frontpage Admins / FP Powermod @Llopigat30 januari 2026 12:11
Dit wordt door consumenten veelal nog gebruikt om bv shares op een NAS te openen etc. Dat dit niet wordt gebruikt door eindgebruikers is echt veel te kort door de bocht.
Alleen als je een hele oude NAS hebt en die al jaren niet geupdate hebt misschien.

Shares openen kan prima met moderne samba.
En hoe authenticeren de moderne Samba's de gebruikers dan en vanaf
welke versie is dit standaard ?

Zover ik mij nog herrineren kan ... creeer je in principe met passwd/smbpasswd een
unix en samba user database met daarin NTLMv2 hashes om daarmee de challenge
responses van de client te kunnen controleren.

Als deze authenticatie gelukt is dan zorgt de samba server ervoor dat jouw sessie seteuid(unix_user)
wordt zodat jij bestanden kan maken met rechten van de gemapte samba <-> unix account.

Welk mechanisme heeft dit overgenomen ?
"tooltje" is vaak een zware onderschatting van de problematiek. O het kan om veel meer gaan, zoals een dure machine met een economische levensduur van 20 jaar waar toevallig een computer in zit. Je kan je afvragen of daar een bederfelijke Windows-versie in moet zitten, maar het gebeurt.
...verouderd authenticatieprotocol NTLM...
...NTLM is een oud authenticatieprotocol dat de laatste jaren steeds minder relevant is geworden door de opkomst van Kerberos...
Want Kerberos is de frisse nieuwe wind om NTLM te vervangen?
Volgens mij is Kerberos minstens net zo oud als NTLM. Ergens jaren 80...

Lijkt me dat "een oud protocol" niet echt de reden is van vervangen.
Volgens mij is Kerberos een meer open standaard, niet ontwikkeld door Microsoft?
Wellicht wil Microsoft stoppen met NTLM zodat ze daar ook geen geld meer in hoeven te steken voor onderhoud.
Meer een kostenbesparingsoperatie
Bor Coördinator Frontpage Admins / FP Powermod @GarBaGe30 januari 2026 12:06
Lijkt me dat "een oud protocol" niet echt de reden is van vervangen.
Dat is de reden dan ook niet. De reden is dat het inherent onveilig is vanwege o.a. zwakke encryptiealgoritmen e.a.
Kerberos heeft geen hardcoded encryptie. Daarom kunnen ze moderne ECC gebruiken die in 1990 nog niet bestond.
NTLMv2 is de reden dat accountwachtwoorden met een MD4(!) hash worden opgeslagen zonder salt. Prima om daar eens afscheid van te nemen. :+
Even een domme vraag; ik gebruik thuis Windows Single Sign On en Single Identity.

Ofwel ik heb een Synology Server mer daarop:

- Active domain controller (met als backup een Samba dc)

- Keycloak geconfigureerd met Kerberos en authenticeert tegen de DC

- Browser settings aangepast dat hij de kerberos token doorstuurt.

Dus ik log passwordless in op mijn Windows Desktop tegen mijn AD en kan vervolgens op al mijn intranet sites. Synology ondersteund IWA en Keycloak authenticeert mijn andere Kubernetes applicaties zoals paperless en homeassistant waarbij het de user als http header doorstuurt.

Gaat dit straks nog werken? En als niet; wat zou ik als thuis gebruiker dan moeten installeren om Single Signon zonder Cloud werkende te krijgen? / Kan dit dan nog?

Of staat dit geheel los van NTLM?
Ergens in jouw keten zie ik "kerberos" en nergens "ntlm". Dat blijft wel werken denk ik.

Bij wijze van test kan je altijd al ntlm uitschakelen op je msWindows systemen. Dan wordt het al niet gebruikt.
Uit interesse en paniek nu, veel paniek. Jouw Active Domain Controller is dat Samba4 op je Synology of
een (Virtuele) Betaalde (On-Premise) Windows Server ?
De standaard Samba versie van de synology gerepliceerd met een backup domain controller op een standaard Linux distro draaiend op een gratis host van Oracle. (Via Site2Site VPN).
denk dat het allemaal nog wel tegen gaat vallen hoe snel MS ntlm gaat uitschakelen.

Ze hebben pas net (windows server 2025) de DES kerberos encryption types verwijderd - en die staan al standaard uit sinds Windows Server 2008 R2.

Overigens hebben ze aangegeven dat ze zelfs NTLMv1 niet volledig verwijderen in hun tijdlijn - de meest gebruikte use case, MSCHAPv2 in RADIUS, wordt nog uitgezonderd van de uitschakeling.

helaas zijn er veel teveel grote organisaties die ruim 10+ jaar achter lopen op best practices qua beveiliging en de boel daarmee lopen te gijzelen.

[Reactie gewijzigd door De Vliegmieren op 30 januari 2026 14:53]

Yep, zie KPN die nog steeds PPPOE gebruiken ...
Doet me denken aan het "uitzetten" van DCOM...
Ik heb NTLM al een eeuwigheid standaard disabled staan ...
En als een applicatie dat nodig heeft ... jammer dan, maar dan drop ik die applicatie ...
Jij hebt geen nood of ziet geen nood van anderen voor een centrale fileserver of doet dit bij een 3e partij
met andere authenticatiemethodes ?
Tja, ik probeer zoveel mogelijk de laatste standaarden te gebruiken, ook op security gebied ...
Is tegenwoordig wel een vereiste met steeds meer cybercrimes ...

Als je al NTLM gebruikt, zorg er dan op zijn minst voor dat er geen verkeer via NTLM buiten de deur komt of binnen kan komen ...

Om te kunnen reageren moet je ingelogd zijn