Microsoft verfolgt einen mehrjährigen Ausstiegsplan für NTLM, der ab Oktober 2024 mit Windows 11 24H2 und Windows Server 2025 sichtbar begonnen hat. Die vollständige Abschaltung wird schrittweise erfolgen, sobald Kerberos in allen relevanten Szenarien zuverlässig eingesetzt werden kann.

Ein konkreter Termin für die vollständige Entfernung von NTLM ist derzeit nicht bekannt.

NTLM: aktueller Stand

Generell muss zwischen NTLMv1 und NTLMv2 unterschieden werden:

  • NTLMv1
    • In aktuellen Windows-Versionen standardmäßig entfernt bzw. deaktiviert
    • Kann in Sonderfällen weiterhin manuell aktiviert werden (nicht empfohlen)
  • NTLMv2
    • Weiterhin verfügbar
    • Kann überwacht, eingeschränkt oder blockiert werden
    • Wird perspektivisch ebenfalls ersetzt

Microsoft empfiehlt den Einsatz von SPNEGO („Negotiate“)
→ Dabei gilt:

  • Kerberos wird bevorzugt
  • NTLM wird nur als Fallback verwendet

LOGINventory verwendet ab Version 2026.1 standardmäßig Negotiate für Windows-Scans.

1. Voraussetzungen für Kerberos (allgemein)

Dieser Abschnitt beschreibt die technischen Grundlagen, unabhängig von LOGINventory.

Kerberos ist namenbasiert

Kerberos funktioniert über sogenannte Service Principal Names (SPNs).

Typische SPNs eines Windows-Rechners sind:

  • HOST/<Hostname>
  • HOST/<FQDN>

Der Client fordert ein Ticket genau für diesen Namen an.
→  Entscheidend ist also der verwendete Zielname, nicht die IP-Adresse.

Domänenumgebung erforderlich

In klassischen Windows-Szenarien setzt Kerberos voraus:

  • Zielsystem ist Mitglied einer Active Directory Domäne
  • verwendeter Benutzer ist ein Domänenkonto
  • ein Domain Controller (KDC) ist erreichbar

Nicht geeignet für Kerberos sind typischerweise:

  • lokale Benutzerkonten
  • Arbeitsgruppen-Rechner
  • reine Entra-ID-joined Geräte (ohne AD)

Zugriff über Namen statt IP

Kerberos funktioniert nur, wenn der Zugriff über einen Namen erfolgt, für den ein SPN existiert:

✔ funktioniert:

  • server01
  • server01.domain.local

❌ funktioniert typischerweise nicht:

  • 10.10.10.5

Grund:
→ Für IP-Adressen existiert in der Regel kein SPN

Namensauflösung (Einordnung)

Für Kerberos selbst ist es unerheblich, wie ein Name aufgelöst wird (DNS, hosts-Datei etc.).

In der Praxis gilt jedoch:

  • Windows-Systeme nutzen fast immer DNS
  • falsche oder uneindeutige Namensauflösung führt dazu, dass:
    • ein falscher Name verwendet wird
    • kein passender SPN gefunden wird
    • Kerberos fehlschlägt → NTLM-Fallback

→  DNS ist daher keine formale Voraussetzung, aber in realen AD-Umgebungen ein entscheidender Erfolgsfaktor.

Typische Fälle ohne Kerberos

Kerberos kann in folgenden Szenarien nicht verwendet werden:

  • Zugriff über IP-Adresse
  • Verwendung eines lokalen Benutzerkontos
  • Ziel ist kein Domain-Mitglied
  • Ziel ist nur Entra-ID-joined
  • falscher oder nicht passender Zielname (SPN passt nicht)

2. Verhalten von LOGINventory beim Scan

Dieser Abschnitt beschreibt das konkrete Verhalten von LOGINventory.

Standardverhalten (ab LOGINventory 2026.1)

LOGINventory verwendet beim Windows-Scan standardmäßig Negotiate.

Das bedeutet:

  • Wenn Kerberos möglich ist → Kerberos wird verwendet
  • Wenn Kerberos nicht möglich ist → NTLM wird verwendet

→  LOGINventory erzwingt Kerberos nicht automatisch, sondern folgt dem Microsoft-Standardverhalten.

Besonderheit: Scan von IP-Adressen

Beim Scan über IP-Adressen ist Kerberos zunächst nicht möglich, da kein passender SPN existiert.

Deshalb verwendet LOGINventory folgenden Mechanismus:

  1. Ziel wird als IP-Adresse erkannt
  2. LOGINventory versucht:
    • IP → Hostname (Reverse Lookup)
    • Validierung über Forward Lookup
  3. Wenn ein eindeutiger und plausibler Name gefunden wird:
    • Verbindung erfolgt über Hostname/FQDN
    • → Kerberos wird möglich
  4. Wenn die Auflösung fehlschlägt oder uneindeutig ist:
    • Verbindung bleibt auf IP-Adresse
    • → nur NTLM möglich

→  Dieser Mechanismus ist ein LOGINventory-spezifischer Workaround, um Kerberos auch bei IP-basierten Scans zu ermöglichen.

Voraussetzungen für den LOGINventory-Mechanismus

Damit dieser Mechanismus funktioniert, muss die Namensauflösung konsistent sein:

  • korrekte Forward-Auflösung (A/AAAA)
  • passende Reverse-Auflösung (PTR)
  • keine widersprüchlichen DNS-Einträge
  • eindeutige Zuordnung IP ↔ Hostname

Fehler in diesem Bereich führen dazu, dass LOGINventory bei der IP bleibt → Kerberos nicht möglich.

Konfigurationsparameter

IP-Auflösung deaktivieren

//DontResolveIpToFqdn 1
  • LOGINventory versucht keine Namensauflösung
  • Verbindungen erfolgen direkt zur IP-Adresse
  • → Kerberos ist in diesen Fällen nicht möglich

NTLM vollständig blockieren

//BlockNTLM 1
  • Es werden ausschließlich Kerberos-Verbindungen verwendet, ein Fallback auf NTLM findet nicht statt. Ab Version 2026.1.2 wird Kerberos dabei auch für den Aufbau der WMI-Verbindung selbst (DCOM-Aktivierungsphase) erzwungen. Damit ist die vollständige Windows-Erfassung inklusive WMI-Daten auch in Umgebungen möglich, in denen eingehender NTLM-Datenverkehr per Gruppenrichtlinie komplett verweigert wird ("Netzwerksicherheit: NTLM einschränken: Eingehender NTLM-Datenverkehr = Alle Konten verweigern"). IP-Adressen werden dabei wie oben beschrieben automatisch in den FQDN aufgelöst; Voraussetzung ist lediglich eine funktionierende DNS-Auflösung (Forward und Reverse).

→   Sinnvoll für sicherheitskritische Umgebungen

3. Typische Ursachen für fehlendes Kerberos in LOGINventory

Wenn trotz Negotiate kein Kerberos verwendet wird, liegt das meist an:

  • Ziel wurde nur per IP-Adresse erfasst
  • DNS-Auflösung ist inkonsistent oder fehlerhaft
  • Verwendung eines lokalen Benutzerkontos
  • Ziel ist kein Domain-Mitglied
  • Ziel ist Entra-ID-only
  • //DontResolveIpToFqdn 1 ist gesetzt
  • //BlockNTLM 1 ist gesetzt (führt dann zu Fehler statt Fallback)

4. Troubleshooting

SPNs prüfen

setspn -l <Computername>

Namensauflösung prüfen

nslookup <IP>
nslookup <Hostname>

Kerberos-Tickets anzeigen

klist

Testverbindung

net use \\server.domain.local\admin$

→ Kerberos funktioniert nur mit Namen, nicht mit IP

net use \\server.domain.local\admin$ /blockntlm

→ (Schalter existiert erst ab Windows 11 24H2) NTLM verhindert


WMI-Zugriffsweg testen


Get-WmiObject Win32_ComputerSystem -ComputerName <fqdn> nutzt denselben klassischen WMI/DCOM-Weg wie die Erfassung. Funktioniert Get-CimInstance (WinRM) mit demselben Konto, Get-WmiObject jedoch nicht, liegt die Ursache am Authentifizierungs-Transport und nicht an WMI-Berechtigungen.

Eventlog prüfen

Security Log → Event ID 4624:

  • Authentication Package: Kerberos ✅
  • Authentication Package: NTLM ❌


Anwendungs- und Dienstprotokolle / Microsoft / Windows / NTLM / Operational


Hinweis für Umgebungen mit vollständig blockiertem eingehendem NTLM


Wenn auf den Zielgeräten eingehender NTLM-Datenverkehr per Gruppenrichtlinie verweigert wird, kann die Erfassung in älteren Versionen mit der Meldung "Erfolgreiche Inventarisierung, jedoch keine WMI-Informationen vorhanden" enden: Die Erfassung über Registry und SMB läuft dann bereits über Kerberos, für den WMI-Zugriff wird jedoch ein NTLM-Fallback versucht, der vom Zielgerät abgelehnt wird. Verwenden Sie in diesem Fall Version 2026.1.2 oder neuer und setzen Sie den Schalter BlockNTLM (siehe oben). Eine besondere Konfiguration der Ziele ist nicht nötig, IP-Adressen werden automatisch in den FQDN aufgelöst, sofern die DNS-Einträge eindeutig sind.


5. Fehlercodes


Fehlercode 20051 (NTLM is blocked)

Die SMB-Verbindung wurde abgelehnt, weil NTLM blockiert ist. Dies tritt in der Regel auf, wenn das Ziel nur über die IP-Adresse erreichbar war. Prüfen Sie die DNS-Auflösung des Geräts (Forward und Reverse), damit die automatische Auflösung zum FQDN greift und Kerberos verwendet werden kann.


Fehlercode 20052 (Kerberos authentication failed)

Fehlercode 20052 (Kerberos authentication failed): BlockNTLM ist gesetzt und die Kerberos-Anmeldung ist fehlgeschlagen. Häufigste Ursachen: Die IP-Adresse konnte nicht eindeutig in einen FQDN aufgelöst werden (fehlende oder widersprüchliche DNS-Einträge, siehe auch Fehler 20055), der Schalter DontResolveIpToFqdn ist gesetzt, das Gerät ist kein Domänenmitglied oder es wird ein lokales Benutzerkonto verwendet.


Fehler 20052 bzw. "Zugriff verweigert" (0x80070005) trotz erfolgreicher Kerberos-Anmeldung


Scheitert die Erfassung mit gesetztem BlockNTLM weiterhin mit "Zugriff verweigert", obwohl im Security-Log des Zielgeräts die Kerberos-Anmeldung erfolgreich protokolliert wird (Ereignis 4624 mit Authentifizierungspaket Kerberos, kein Ereignis 4625), prüfen Sie auf dem Zielgerät die Gruppenrichtlinie "Einschränkungen für nicht authentifizierte RPC-Clients" (Registry: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Rpc, Wert RestrictRemoteClients).


Auf der Stufe "Authentifiziert ohne Ausnahmen" (Wert 2) blockiert Windows auch die anonyme OXID-Auflösung, die DCOM technisch bedingt für den Verbindungsaufbau benötigt. Der WMI-Zugriff scheitert dann unabhängig vom verwendeten Authentifizierungsprotokoll, also auch bei korrekt funktionierendem Kerberos. Verwenden Sie stattdessen die von Microsoft empfohlene Stufe "Authentifiziert" (Wert 1): Anonymer RPC-Zugriff bleibt damit blockiert, die für DCOM erforderliche Ausnahme greift jedoch wieder und die Erfassung funktioniert nach einem Neustart des Zielgeräts.


Hinweis: Die Einstellung EnableAuthEpResolution auf dem LOGINventory-Server ändert daran nichts, da sie nur Endpunktmapper-Abfragen authentifiziert, nicht die OXID-Auflösung von DCOM.