Ein Smartphone, das sich per NTLM an einer internen Webanwendung anmeldet, schreibt selbst kein Windows-Ereignis. Sichtbar wird es nur auf der Serverseite, als Benutzername, Client-Name und Client-IP. Ein Feld für das Betriebssystem hat keines der Ereignisse, die Microsoft für die NTLM-Bestandsaufnahme dokumentiert.
Im Oktober 2026 ändert Microsoft voraussichtlich eine Voreinstellung: Der Registrierungswert BlockNTLMv1SSO wechselt auf Windows 11 24H2 und Windows Server 2025 von „Audit“ auf „Enforce“. Die Umstellung selbst ist klein. Sie ist aber ein guter Anlass für die Frage, die vor jedem weiteren Schritt steht: Wo läuft bei Ihnen noch NTLM, und welche Geräte hängen daran?
NTLMv1 als Protokoll hat Microsoft aus Windows 11 24H2 und Windows Server 2025 bereits entfernt. Reste stecken noch in Anmeldungen, die NTLMv1-abgeleitete Anmeldedaten für Single Sign-on nutzen, laut Microsoft etwa bei WLAN, Ethernet und VPN mit MS-CHAPv2. Genau diese Anmeldedaten blockiert BlockNTLMv1SSO, sobald der Wert auf 1 steht (KB5066470).
Drei Einschränkungen gehören dazu. Die neue Voreinstellung greift nur, wenn der Wert auf dem Gerät noch nicht gesetzt ist. Auf Geräten mit aktivem Credential Guard ändert sich nichts. Und Microsoft nennt den Termin ausdrücklich vorläufig, auch in der letzten Aktualisierung des Artikels vom 13. Juli 2026. Wer den Single Sign-on verliert, kann sich weiter mit manuell eingegebenen Anmeldedaten verbinden.
Für Smartphones und Tablets ändert sich im Oktober direkt nichts, der Wert wirkt auf Windows. Für sie zählt der spätere Schritt: Mit dem nächsten großen Windows-Server-Release ist Netzwerk-NTLM ab Werk deaktiviert (Microsoft, 29.01.2026). Bis dahin sollte feststehen, welche mobilen Zugriffe noch darauf angewiesen sind. Den ganzen Fahrplan und seine Folgen für Android und iOS beschreibt der Auftaktbeitrag dieser Reihe.
Das erweiterte NTLM-Auditing gibt es auf Windows 11 ab 24H2 und auf Windows Server 2025, einschließlich der Domain Controller. Microsoft verteilt es schrittweise, zuerst an Clients, danach an Server (KB5064479). Ältere Server und Domain Controller liefern diese Ereignisse nicht. Dort bleibt die bisherige Richtlinie „Network security: Restrict NTLM: Audit NTLM authentication in this domain“, deren Protokolle unverändert weiterlaufen.
Die Ereignisse sind laut Microsoft standardmäßig aktiv. Für Clients und Server steuert sie die Richtlinie „NTLM Enhanced Logging“ unter Administrative Templates > System > NTLM. Für die Domain Controller heißt sie „Log Enhanced Domain-wide NTLM Logs“ und liegt unter System > Netlogon. Geschrieben wird nach Microsoft-Windows-NTLM/Operational.
Jedes Ereignis gibt es als Information und als Warnung. Die Warnung steht für geschwächte Sicherheit, etwa NTLMv1, eine fehlende oder unsichere Extended Protection for Authentication oder einen fehlenden Message Integrity Check.
Die Client-Ereignisse tragen das Feld „Usage Id/Reason“. Es sagt, warum Windows NTLM statt Kerberos genommen hat, und damit auch, wer das Problem löst. Für fehlende Sicht auf den Domain Controller (Grund 9) und lokale Konten (Grund 2) kündigt Microsoft IAKerb und Local KDC für die zweite Jahreshälfte 2026 an. Für ein Ziel ohne auflösbaren Namen (Grund 6) oder per IP-Adresse (Grund 7) plant Microsoft eine eingebaute Behandlung erst mit dem nächsten großen Server-Release. Bis dahin bleiben diese Fälle Ihre eigene Aufgabe. Grund 1 heißt: Die Anwendung ruft NTLM direkt auf. Das ist eine Frage an ihre Entwickler.
Für die Oktober-Umstellung gibt es zwei eigene Ereignisse im selben Protokoll: 4024 als Warnung im Audit-Modus, 4025 als Fehler, wenn eine Anmeldung blockiert wurde. Jedes 4024 ist eine Anmeldung, die auf diesem Gerät nach der Umstellung ihren Single Sign-on verliert. Das Ereignis nennt Zielserver, Benutzer und den aufrufenden Prozess. Wer den Wert vorab bewusst auf 0 setzt, behält das bisherige Verhalten. Das verschafft Zeit, um MS-CHAPv2 abzulösen, ersetzt die Ablösung aber nicht.
Weil Android und iOS keine Windows-Ereignisse schreiben, taucht ein Smartphone nur am anderen Ende der Verbindung auf: am Zielserver als 4022 oder 4023, am Domain Controller als 4032 oder 4033.
Werten Sie deshalb die Server-Ereignisse der Systeme aus, die mobile Nutzer erreichen: Intranet, interne Webanwendungen, SharePoint, Dateiserver. Laufen diese noch nicht auf Windows Server 2025, liefern sie keine erweiterten Ereignisse, und es bleiben die Domain Controller und die bisherige NTLM-Überwachung.
Aus den Ereignissen kommen Benutzernamen und Adressen, keine Geräte. Die Verbindung zum Gerät liegt im UEM. ISEC7 SPHERE führt die Geräte aus den angebundenen UEM-Systemen in einer Datenbank zusammen, etwa aus Microsoft Intune, Ivanti oder BlackBerry UEM. Zu jedem Gerät stehen dort Betriebssystem, Patch-Stand und installierte Apps. So wird aus dem Benutzernamen im NTLM-Ereignis die Liste seiner Geräte über alle Plattformen. Seit Version 20.9.0 lassen sich einzelne Apps als „Monitored applications“ führen. Steht fest, welche App hinter den NTLM-Anmeldungen steckt, zeigt ISEC7 SPHERE, bei welchen Nutzern und auf welchen Geräten sie installiert ist. ISEC7 SPHERE sieht dabei, was ein angebundenes UEM kennt. Ein Gerät außerhalb der Verwaltung erscheint in keiner Auswertung.
Nach dem Wechsel auf Kerberos muss er sich von zwei Seiten zeigen. Auf dem Domain Controller erscheint die Anmeldung im Security-Log als Ereignis 4768, „A Kerberos authentication ticket (TGT) was requested“. Dafür muss „Audit Kerberos Authentication Service“ aktiv sein (Microsoft Learn). Das Ereignis enthält Konto, Client-Adresse und den Pre-Authentication Type: 2 steht für die Anmeldung mit Passwort, 15 bis 17 ordnet Microsoft der Smartcard-Anmeldung zu, also der Anmeldung mit Zertifikat. Auf der anderen Seite verschwinden für denselben Benutzer die NTLM-Ereignisse am Zielserver. Erst beides zusammen ist ein Nachweis.
Für Mobilgeräte hat Hypergate das im ISEC7-Webcast vom 23. September 2026 mit Simon Kolb (ISEC7) und Caglar Cölkusu (Hypergate) beschrieben. Nach Angabe von Hypergate holt sich das Android- oder iOS-Gerät sein Kerberos-Ticket direkt am Domain Controller, und die mobile Anmeldung erscheint dann als Ereignis 4768 statt als NTLM-Anmeldung. Ob das in Ihrer Umgebung so ist, zeigen die beiden Prüfungen oben. Die Aufzeichnung ist kostenfrei nach Registrierung.
Wer mobile Geräte mit Zertifikat anmeldet, prüft zusätzlich die Zuordnung. Seit dem Februar-Update 2025 arbeiten Domain Controller im Full Enforcement Mode. Ein Zertifikat, das sich keinem Konto stark zuordnen lässt, lehnen sie ab. Den Schalter zurück in den Kompatibilitätsmodus unterstützt Microsoft seit dem Update vom 9. September 2025 nicht mehr. Abgelehnte Zertifikate meldet der Domain Controller im System-Log mit Ereignis 39, Quelle Kdcsvc (KB5014754).
Die Ereignisse liefert Windows, die Auswertung ist Arbeit am eigenen Netz. Den Gerätebestand für die mobile Seite hält ISEC7 SPHERE aus dem vorhandenen UEM bereit. Als Hypergate-Partner für Deutschland, Großbritannien und die USA führt ISEC7 danach Kerberos auf Android und iOS ein. Für E-Mail unterstützt ISEC7 MAIL Hypergate als Anmeldeverfahren. Das zeigt die Folie zu den Anmeldeverfahren im Webcast. Für eine kostenfreie Ersteinschätzung schreiben Sie uns über die Seite zum NTLM-Ausstieg auf Mobilgeräten; ein Satz zu Ihrer Umgebung genügt.
Am 21. Oktober erscheint der nächste Beitrag dieser Reihe. Er führt Schritt für Schritt durch die Ablösung von Acronis Cyber Files.