22.11.2023, aktualisiert am 23.11.2023

3888

Domain.local Kerberos

Hallo,

Hat irgendjemand es hinbekommen, dass ein Zugriff auf \\domain.local bei deaktivierten NTLM (also bei Verwendung von Kerberos) funktioniert?
Nachtrag: domain.local ist plakativ zu verstehen. Gemeint ist ein Zugriff auf \\SDL.TLD. Also ohne Host/Subdomain)

Ich sehe am Client immer folgenden Fehler im Log:

NTLM client blocked: Outgoing NTLM authentication traffic to remote servers that is blocked.
Target server: cifs/domain.local
Supplied user: (NULL)
Supplied domain: (NULL)
PID of client process: 4
Name of client process: 
LUID of client process: 0x00A00B
User identity of client process: user.name
Domain name of user identity of client process: DOMAIN
Mechanism OID: 1.1.1.1.1.1.111.1.1.10

Die einzige Lösung die ich bisher gefunden habe ist, einen SPN für cifs/domain.local zu setzen (wenn man nur einen DC in Verwendung hat). Also

setspn -S cifs/domain.local DC01

Nur über (negative?) Nebenwirkungen ist mir halt leider nichts bekannt.
Auch Frage ich mich, ob das so tatsächlich notwendig ist.

Leider ist im www sehr, sehr wenig dazu zu finden. Und die paar Webseiten die man findet, helfen mir nicht weiter.

Beste Grüße
Patrick

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 74072458923

Url: https://administrator.de/contentid/74072458923

Ausgedruckt am: 05.11.2024 um 15:11 Uhr

19 Kommentare

Neuester Kommentar

Verstehe ich Dich richtig, dass Du Dich wunderst, warum Du keinen Zugang zu Deinem DC über Kerberos hast?

Die Implementierung des Kerberos-Protokolls muss auf dem Client und dem Server korrekt konfiguriert sein, um die Authentifizierung und Autorisierung über das Kerberos-Protokoll zu ermöglichen.

https://learn.microsoft.com/de-de/troubleshoot/windows-server/windows-se ...

Kerberos funktioniert ja prinzipiell.
Zugriff auf \\dc01.domain.local geht.
Zugriff auf \\fileserver.domain.local geht.
Und so weiter, und so weiter.

Nur eben \\domain.local nicht.
Prinzipiell wundert mich das ja nur bedingt, dass das nicht geht.
Denn wenn für einen Namen kein SPN gesetzt ist, kanns auch nicht gehen.

Was mich eben an der ganzen Sache wundert ist der Umstand, dass \\domain.local (scheinbar?) nicht automatisch gesetzt wird.

Daher habe ich mich nun euch/die Community gewendet, in der Hoffnung, dass mir das jemand bestätigen kann.
Bzw. evt. einer sagt "ich musste das nicht setzen.". Denn damit wäre mir auch schon mal geholfen.

Beste Grüße
Patrick

Dir ist schon bewusst, dass .local eine reservierte TLD ist und nicht verwendet werden sollte.

https://en.wikipedia.org/wiki/.local

Jürgen

Hallo @8585324113,

dir ist schon bewusst, dass es hier auch um Namensauflösung geht.
Und weißt du, was Windows mit unzulässigen TLDs macht und welche Auswirkungen das auf Dienste hat, die davon abhängig sind?

Jürgen

Hinweise zur Verwendung der Domäne .local in DNS und mDNS

Hi aber bei \\domain.local solltest du ein sysvol und ein netlogom Ordner sehen.

Und ja local ist ungut aber lässt sich ja bekanntlich schwer bis garnicht ändern und um 2000 rum haben das Berater für viel Geld so auf dem ersten DC eingerichtet und es gab überall die contoso.local im technet etc. ....

Was für ein DC Level und welches OS haben die DCs?

Was kommt wenn du auf \\dc1\ gehst ist da ein Sysvol / Netlogon da ?

Mit freundlichen Grüßen Nemesis

Zitat von @chiefteddy:

Hallo @8585324113,

dir ist schon bewusst, dass es hier auch um Namensauflösung geht.
Und weißt du, was Windows mit unzulässigen TLDs macht und welche Auswirkungen das auf Dienste hat, die davon abhängig sind?

Jürgen

Nein, Du verbreitest einen der falschen Dauerbrenner hier im Forum. Es ist traurig, weil es Administrator und nicht Azubi.de heißt.
Selbiges in grün mit mDNS.

Hallo @8585324113,

den verlinkten Artikel von @aqui gelesen?

Und warum bist du so aggressiv? Der TO hat ein Problem mit einem Windows-Dienst, der die Namensauflösung nutzt. Mir ist in seiner Konfiguration etwas aufgefallen und ich habe ihn darauf hingewiesen.
Mein Hinweis ist sachlich begründet, ob er ursächlich für das Problem ist, weiß ich nicht. Habe ich aber auch nicht behauptet.

Also warum so aggressiv?

Jürgen

PS. Und sachlich begründet, warum es daran nicht liegen kann, hast du nicht.

Danke für eure Antworten.

Gleich vorweg: Meine Domain ist nicht domain.local! Nachdem meine richtige Domain hier nichts zur Sache beiträgt, habe ich domain.local rein plakativ angeführt. Hätte genauso gut contoso.com anführen können.
Sorry, falls dies zu Verwirrung beigetragen hat.

Zitat von @nEmEsIs:

Hi aber bei \\domain.local solltest du ein sysvol und ein netlogom Ordner sehen.

Sobald ich NTLM deaktiviere nicht mehr! Außer ich setzte oben genannten SPN.
Daher die Frage, wie dies bei euch ist. Geht dies über Kerberos?

Was für ein DC Level und welches OS haben die DCs?

Server sind Server 2019.
Funktionsebene ist Server 2016.

Was kommt wenn du auf \\dc1\ gehst ist da ein Sysvol / Netlogon da ?

Ja, das geht. da es einen gültigen SPN Eintrag gibt für dc01.domain.local (wird automatisch erstellt, da DC01 der Computername ist) kriege ich auch ein Kerberos Ticket dazu.

Zitat von @chiefteddy:

Hallo @8585324113,

den verlinkten Artikel von @aqui gelesen?

Und warum bist du so aggressiv? Der TO hat ein Problem mit einem Windows-Dienst, der die Namensauflösung nutzt. Mir ist in seiner Konfiguration etwas aufgefallen und ich habe ihn darauf hingewiesen.
Mein Hinweis ist sachlich begründet, ob er ursächlich für das Problem ist, weiß ich nicht. Habe ich aber auch nicht behauptet.

Also warum so aggressiv?

Jürgen

PS. Und sachlich begründet, warum es daran nicht liegen kann, hast du nicht.

Der verlinkte Artikel hat auch nichts mit dem Problem zu tun.

Die Clients haben konfigurierte DNS Server, warum sollen sie dann z. B. mDNS machen?

Wenn es Drittsoftware gibt die abweichende Auflösungen macht, dann ist das ein anderes Problem und gehört gepflegt.

Ich bin auch nicht aggressiv, aber anders dringe ich nicht durch.
Hier ist ein öffentliches Forum und Falschinformationen werden verbreitet und nicht moderiert. Das ist erbärmlich.

Hi

Wie hast du den NTLM ausgemacht ?
In der Default Domain Policy ? Oder nur die Policy für die DCs ?
Hast du danach neu gestartet also die DCs ?

Mit freundlichen Grüßen Nemesis

Zitat von @nEmEsIs:

Hi

Wie hast du den NTLM ausgemacht ?
In der Default Domain Policy ? Oder nur die Policy für die DCs ?
Hast du danach neu gestartet also die DCs ?

Mit freundlichen Grüßen Nemesis

Hab vor geraumer Zeit die GPOs zur Protokollierung in der Default Domain Policy aktiviert.

Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts
Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit all

Da konnte ich bereits die Warnungen sehen, dass ein Zugriff auf \\domain.local per NTLM erfolgt.

Habe dann auf einem einzelnen Client (Endgerät) eingestellt:

Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Deny all

Und ja: es kam wie erwartet: Zugriff auf \\domain.local wird blockiert.
Sobald ich Eingangs erwähnten SPN setze, geht es wieder.

Für mich wäre einfach mal Interessant zu wissen:

Hat jemand das Audit aktiv und kann das gleiche Verhalten feststellen? Also dass ein Zugriff auf \\SDL.TLD eine Warnung auslöst?
Falls nein: was habt ihr anders eingestellt als ich
Oder: kann jemand bestätigen, dass oben genannter SPN die wahre Lösung ist? Ich weiß leider immer noch nicht (mangels Doku von MS), welche Nebenwirkungen das haben könnte.

Hat jemand das Audit aktiv und kann das gleiche Verhalten feststellen? Also dass ein Zugriff auf \\SDL.TLD eine Warnung auslöst?

Ja, ist bei mir auch so und auch in einer frischen Testdomäne (Server 22 als DC).

Kurz nachgehakt: warum willst Du diese Notation nutzen? Vielleicht ist Dir entgangen, dass NUR \\dom.local nicht geht, während \\dom.local\sysvol (usw...) funktioniert.

Zitat von @DerWoWusste:

Hat jemand das Audit aktiv und kann das gleiche Verhalten feststellen? Also dass ein Zugriff auf \\SDL.TLD eine Warnung auslöst?

Ja, ist bei mir auch so und auch in einer frischen Testdomäne (Server 22 als DC).

DANKE! Damit ist mir schon mal sehr geholfen!

Kurz nachgehakt: warum willst Du diese Notation nutzen? Vielleicht ist Dir entgangen, dass NUR \\dom.local nicht geht, während \\dom.local\sysvol (usw...) funktioniert.

Ein durchaus berechtigter Einwand. Nein: es ist mir nicht entgangen.
Mein "Problem" an der Sache ist eigentlich ein reiner Schönheitsfehler: Obwohl der Zugriff auf \\domain.local\sysvol funktioniert, steht im Log die Fehlermeldung (Aufgrund der Tatsache, dass SYSTEM einen Zugriff auf \\domain.local\pipe\ macht. Das konnte ich mittels Procmon schon ermitteln.).
Ich habe einzig die Befürchtung, dass eine mögliche spätere Fehlersuche schwierig wird, wenn in den Logs Ereignisse zu finden sind, die eigentlich keine Auswirkung haben, da trotzdem alles funktioniert.
Daher mein Versuch, das Log "clean" zu halten.

Aber wie es ausschaut habe ich zwei Möglichkeiten:

Mit dem Ereignis im Log leben, weil eh trotzdem alles soweit funktioniert (außer eben der direkte Zugriff auf \\domain.local, welcher ja nicht zwingend erforderlich ist)
den eingangs erwähnten SPN setzen, ohne zu wissen, welche Nebenwirkungen dies hat.

Ich habe einzig die Befürchtung, dass eine mögliche spätere Fehlersuche schwierig wird, wenn in den Logs Ereignisse zu finden sind, die eigentlich keine Auswirkung haben, da trotzdem alles funktioniert.

Das ist ein Holzweg. Das Windows-Eventlog ist NIE sauber. Das Rechner tadellos funktionieren und dennoch x Warnungen und zum Teil auch Fehler zeigen an x Orten ist normales Rauschen. Ich sehe keine Chance, das zu verhindern, so ärgerlich es auch scheint.

Zitat von @DerWoWusste:

Da magst du wohl recht haben.
Es ist/war halt ein Versuch, meiner (leider angewöhnten, versuchten) Perfektion gerecht zu werden

Zitat von @DerWoWusste:
Vielleicht ist Dir entgangen, dass NUR \\dom.local nicht geht, während \\dom.local\sysvol (usw...) funktioniert.

Das kann ich in praktischer Hinsicht so nicht ganz bestätigen. Bei der hiesigen Domäne ist es sehr wohl möglich, von einem beliebigen Windows-Client (8.1 und 10) aus im Dateiexplorer auf \\domain.tld zuzugreifen und dann sind die Freigaben netlogon und sysvol sichtbar. Diesbezüglich spielt es auch keine Rolle, ob nur Windows-DC's oder Samba-DC's oder eine Mischung aus beiden für die Domäne werkelt. Der Erinnerung nach ist das schon immer so möglich gewesen.

Auf einem Windows-Core-Server klappt net use \\domain.tld ebenfalls. Aufgelistet wird dann "OK" mit "\\domain.tld\IPC$". Hingegen scheitern net use * \\domain.tld oder net use E: \\domain.tld.

NTLM für den Zugriff auf Remoteserver ist aber (bisher) nicht deaktiviert - weder lokal noch per GPO, wenngleich nur noch NTLMv2 akzeptiert wird (= Level 5).

Insoweit kann der TO das einmal bei sich die genannten Varianten testen - vielleicht bringt ihn das bei seinen Erkenntnissen weiter.

Viele Grüße
HansDampf06

PS: Wie handhabt Ihr eigentlich NTLM: Alles deaktiviert oder "nur" Level 5 aktiviert?

Zitat von @HansDampf06:
Das kann ich in praktischer Hinsicht so nicht ganz bestätigen. Bei der hiesigen Domäne ist es sehr wohl möglich, von einem beliebigen Windows-Client (8.1 und 10) aus im Dateiexplorer auf \\domain.tld zuzugreifen und dann sind die Freigaben netlogon und sysvol sichtbar.

NTLM für den Zugriff auf Remoteserver ist aber (bisher) nicht deaktiviert - weder lokal noch per GPO, wenngleich nur noch NTLMv2 akzeptiert wird (= Level 5).

Bei aktivieren NTLM geht es auch bei mir. Die Sache ist, dass es über Kerberos nicht geht.

PS: Wie handhabt Ihr eigentlich NTLM: Alles deaktiviert oder "nur" Level 5 aktiviert?

Bestenfalls gleich mit der Deaktivierung beschäftigen, auch wenn das ziemlich ein Projekt ist.
Bleibt einem ja sowieso nicht erspart.