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 zugelassen
  • Wenn Kerberos nicht möglich ist:
    • Verbindung schlägt fehl (kein NTLM-Fallback)

→   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

→ NTLM verhindert

Eventlog prüfen

Security Log → Event ID 4624:

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


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