Windows: NTLM und Driver Verifier GUI als veraltet (deprecated) erklärt

Windows[English]Microsoft ist weiter beim Ausmisten von Funktionen für kommende Windows-Versionen. Im Mai 2024 war bereits die Driver Verifier GUI als veraltet (deprecated) erklärt worden und wird in Windows 11 verschwinden. Nun hat Microsoft Anfang Juni 2024 nachgelegt und meint, dass man NTLM ebenfalls in den Ruhestand schicken und in kommenden Windows-Versionen entfernen will. Nachfolgend ein kurzer Überblick über diese Sachverhalte.


Anzeige

Abschied von der Driver Verifier GUI

Keine Ahnung, ob jemand aus der Leserschaft den Driver Verifier und dessen GUI (verifiergui.exe) eingesetzt hat. Mir ist eine Episode unter Windows 7 in Erinnerung, als ich verifiergui.exe für ein Buchprojekt laufen ließ und mit einem nicht mehr startenden System endete. Die Systemwiederherstellung hat dann das System gerettet.

Driver Verifier GUI

Jedenfalls hat Microsoft im Mai 2024 auf der Seite Deprecated features for Windows client den Driver Verifier GUI, verifiergui.exe, als veraltet (deprecated) erklärt. Diese GUI wird in künftigen Windows-Versionen entfernt (wann genau, steht noch nicht fest). Wer die Funktionalität braucht, kann auf die Kommandozeilenversion von verifier.exe zurückgreifen.

NTLM fällt aus der Entwicklung

Nach dem Motto "Tschö mit ö" wurde Anfang Juni 2024 der Abschied vom NTLM auf der Seite Deprecated features for Windows client verkündet. Alle Versionen von NTLM, einschließlich LANMAN, NTLMv1 und NTLMv2, befinden sich nicht mehr in der aktiven Funktionsentwicklung und sind veraltet. Die Verwendung von NTLM soll zwar in der nächsten Version von Windows Server und in der nächsten jährlichen Version von Windows (wäre Windows 11 24H2) weiterhin funktionieren.


Anzeige

Microsoft schreibt aber, dass Aufrufe von NTLM durch Aufrufe von Negotiate ersetzt werden. Negotiate versucht, sich mit Kerberos zu authentifizieren und greift nur bei Bedarf auf NTLM zurück. Weitere Informationen finden Sie unter Resources for deprecated features. Der Abschied von NTLM erfolgt aus Sicherheitsgründen, da diese Funktionalität immer wieder Sicherheitslücken aufriss. Als Authentifizierungsdienst für offene und unsichere Computernetze wird künftig Kerberos eingesetzt.


Anzeige

Dieser Beitrag wurde unter Netzwerk, Windows abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

6 Antworten zu Windows: NTLM und Driver Verifier GUI als veraltet (deprecated) erklärt

  1. Tomas Jakobs sagt:

    Wischi waschi und im Grunde nichts Neues. Seit wievielen Jahren weiß man um die Schwöchen von NTLM? Seit wievielen Jahren gedenkt man es abzuschaffen? Solange die zentralen Tools zum Management im AD allen voran die MMC stark COM, COM+, DCOM, ActiveX lastig bleibt, solange wird man schlicht NTLM nicht aufgeben können. Das käme meiner bescheidenen Einschätzung einer Neuprogrammierung von Tools gleich, die faktisch seit den späten 90er Jahren unverändert geblieben sind.

    Never ever wird das jemals passieren. Dann ist eher wahrscheinlich, dass MS Mariner zum neuen Server-Produkt wird ;-)

    • Stefan (AT) sagt:

      Denke ich auch. Da gibt es viel zu viele Software(schnittstellen) die sich dann auf Maul legen würden. Ich werde es mal in einer Test-Domäne testen, habe aber keine große Hoffnung (MFP-Geräte/embedded-Geräte, etc.).

    • ARC4 sagt:

      Naja die MMC ist aber auch tot da gibt's keine Entwicklung. Nachfolger von diesen Tools sollte dann irgendwann das WAC werden. In vielen Bereichen geht das jetzt auch schon, in manchen gibt es noch Nachbesserungsbedarf. Also wenn etwas (weiter)entwickelt wird, dann mit WAC.

  2. R.S. sagt:

    Kann ich so nicht bestätigen.
    NTLM habe ich hier im Netzwerk schon vor ca. 2 Jahren per GPO ausgeknipst.
    Probleme kann ich keine Feststellen.

    • 1ST1 sagt:

      Da hast du aber Glück, ich hatte das teils auch mal gemacht, und in bin in der für den Test ausgewählten OU nach nur wenigen Minuten dick auf die Schnauze gefallen… Sogar aktuell durchgepatchte Win 10 Maschinen verwenden gelegentlich gegen Server 2022 Domain Controller NTLM statt Kerberos als Fallback, wenn auf Kerberos nicht schnell genug geantwortet wird. Schaltet man NTLM aus, fällt der Client gelegentlich auf die Schnauze.

      Was man aber wenigstens problemlos machen kann, ist NTLMv1 ausschalten, aber NTLMv2, wehe…

      Aber noch was lustiges… Naja, eigentlich nicht lustig.

      https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-to-find-expensive-inefficient-and-long-running-ldap-queries/ba-p/257859
      https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-ad-and-lds-event-logging

      Da ist was faul mit dem Reg-Schlüssel "15 Field Engineering". Den kann man von 0 auf andere Werte stellen, z.B. "5", um LDAP näher zu loggen, um noch verbliebene LDAP-Anfragen zu finden, die zudem auch noch langsam sind und den DC belasten. Klingt erstmal easy, die beschriebenen Regkeys setzen und nach den genannten Event-IDs suchen, um den Übeltäter auf die Spur zu kommen.

      Man findet nicht nur bei MS entsprechende Anleitungen, sondern auch z.B. bei managengine, petri, usw., wie man das macht, teils auch mit Powershellscript, dass einem die entsprechenden Events rausfiltert, und Ross und Reiter klar benennt.

      Vorsicht!

      Der Fallstrick ist aber an der Sache, 15. Field Engineering und die 2 anderen genannten Keys schaltet nicht nur erweitertes Logging ein, sondern schaltet auch LDAP ab, so dass man nur noch LDAPs nutzen kann. Ok, so kann man seine Pappenheimer und letzten Mohikaner auch finden, aber das ist mitunter schmerzhaft…

      • Hansi Meier sagt:

        Es gibt wenige MS-Dienste die tatsächlich auf NTLM angewiesen sind. Spontan fällt mir die Cert-erneuerung bei der CA sowie einige Cluster-Services ein. MFP Geräte mit Scan Funktion benötigen oft Ntlm für SMB.

        Man kann das ganze soweit entschärfen, das NTLM nur für lokale Konten nicht jedoch für domain-konten zulässig gemacht werden kann. Sprich man deaktiviert es auf den dcs und aktiviert es z.b auf einem scan server der als smb ziel fungiert. wird nun ein auth gegen ein domainkonto mit ntlm versucht, schlägts fehl. nimmt man ein local konto, klappts dagegen. normalen admins/user verbietet man ein login auf der kiste.

        in kleinen umgebungen ist das meist machbar weil man cluster eher nicht oder nur auf infrastrukturebene hat.

        Bei Netzwerkdruckern und Freigaben bzw. allgemein allen Verknüpfungen (auch ordnerziele in DFS) muss mit der FQDN verbunden werden, dann klappts auch mit Kerberos. Sprich alte vollständig rauswerfen und neu verbinden (user & computerebene). Nur computername = nur Ntlm möglich.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.