Clients versuchen DNS per LLMNR Protokoll aufzulösen, komische Fehler im Security-Eventlog (ID 4776)

[mcdaniels 29]

Gerade eben schrieb NorbertFe:

Jupp, kommt aus einem Projekt, wo man nix auf dem DC installieren durfte ;)

so gehört sich das ja auch

[mcdaniels 29]

Hallo,

ich habe jetzt LLMNR per GPO abgedreht, per RSOP geprüft, ob die Richtlinie auf meinem Client ankommt und dann via \\PC-IRGENDWAS  im Explorer auf meinem PC eine Namensauflösung nach einem PC Namen angestoßen, den es nicht gibt.

 

Und... siehe da... Mein PC fragt noch immer per LLMNR nach dem Hostnamen.

 

Folgende Richtlinie hab ich verwendet: Computer Configuration -> Administrative Templates -> Network -> DNS Client

Turn Off Multicast Name Resolution auf enabled gestellt.

 

Ich liebe es

[testperson 1.680]

Moin,

 

die "Turn Off Multicast Name Resolution" gibt es (im deutschen) zweimal: Multicastnamensauflösung deaktivieren - Active Directory Forum - MCSEboard.de 

 

(Schalte einfach beide ab. Und dann ggfs. auch direkt mDNS.)

 

Gruß

Jan

[NorbertFe 2.035]

Nicht einfach beide abschalten, sondern das richtige (siehe obigen Thread). Bin ich bei zwei Kunden schon auf die Nase gefallen, weil die VPN Lösung von Cisco das nutzte. ;)

bearbeitet Gestern um 08:29 von NorbertFe

[mcdaniels 29]

@testperson

@NorbertFe

 

und auch alle anderen.

 

DANKE ihr seid halt einfach ein Hammer. Jetzt ist zumindest mal LLMNR still und ich kann mich diesem HOME_DS widmen.

 

Ich vermute das steht deshalb doppelt da drin, weil MS die Aufmerksamkeit der Admins prüfen will... sehen sie es, oder sehen sie es nicht. Ich bin jedenfalls durchgefallen und kann deshalb wohl nie bei MS anfangen. 

[testperson 1.680]

vor 5 Minuten schrieb NorbertFe:

weil die VPN Lösung von Cisco das nutzte. ;)

Niemand nutzt VPN. :-P

[mcdaniels 29]

Habt ihr eventuell noch einen Tipp für mich wie man die Traces (.etl) öffnen kann. Das Programm das im Artikel von @NorbertFe erwähnt wurde gibt es nicht mehr (habs dann aus anderen Quellen geholt und läuft in einen Fehler).

 

Ich konvertiers mir mit Releases · microsoft/etl2pcapng

 

 

vor 26 Minuten schrieb NorbertFe:

Nicht einfach beide abschalten, sondern das richtige (siehe obigen Thread). Bin ich bei zwei Kunden schon auf die Nase gefallen, weil die VPN Lösung von Cisco das nutzte. ;)

Cisco haben wir nicht... :-P Aber ok, dann schalte ich den oberen Eintrag mit dem Namen auf nicht konfiguriert. Mann, Mann, Mann... das ist irgendwie alles *******

bearbeitet Gestern um 08:56 von mcdaniels

[mcdaniels 29]

Habe jetzt via Netsh protokolliert, danach das File in Pcap umgewandelt und im Wireshark angeschaut. Ich finde den String HOME_DS nirgends. Dennoch protokolliert der DC fröhlich weiter fehlgeschlagene Anmeldungen von dort. Jetzt muss ich mich mal sammeln und überlegen, was ich noch machen könnte... Interessant, aber mühsam.

bearbeitet vor 23 Stunden von mcdaniels

[NorbertFe 2.035]

vor 2 Stunden schrieb mcdaniels:

Dennoch protokolliert der DC fröhlich weiter fehlgeschlagene Anmeldungen von dort

Wie sieht so eine Meldung im Eventlog denn aus? 

[mcdaniels 29]

vor einer Stunde schrieb NorbertFe:

Wie sieht so eine Meldung im Eventlog denn aus? 

Inhalt:

Es wurde versucht, die Anmeldeinformationen für ein Konto zu überprüfen.

Authentifizierungspaket: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Anmeldekonto: (ist leer)

Arbeitsstation: \\HOME_DS

Fehlercode: 0x0000064

 

Jetzt kommt aber der Gag... ich habe jetzt mal aufgrund des Hinweises von @daabm eine DiskStation, die via IPSEC VPN Tunnel an uns angebunden ist, neu gestartet. Und jetzt ist der Eintrag verschwunden. Auf der Diskstation selbst finde ich aber nirgends den Eintrag \\HOME_DS.

 

Ich kann mir keinen Reim drauf machen.... Entweder war das jetzt ein Riesenzufall, dass das Gerät das hier reinfunkt exakt zu dem Zeitpunkt als ich die Diskstation neu startete aufhörte den DC zuzuballern, oder es war tatsächlich die Synology Diskstation......

 

Ich muss mich korrigieren... Dachte grade, ich schau mal auf den zweiten DC nachdem der betroffene (DC3) das nicht mehr protokolliert... siehe da... jetzt ist die Meldung auf dem zweiten DC im Eventlog....

 

ich werd nicht mehr....

bearbeitet vor 19 Stunden von mcdaniels

[NorbertFe 2.035]

Schalte doch mal netlogon logging aktiv und schau da nach. Hat mir schon einige Male geholfen in solchen Fällen.

[mcdaniels 29]

vor 6 Minuten schrieb NorbertFe:

Schalte doch mal netlogon logging aktiv und schau da nach. Hat mir schon einige Male geholfen in solchen Fällen.

ok werde ich mir anschauen. Es scheint aber definitiv von der Diskstation zu kommen. Diskstation ausgeschaltet: Ruhe. Auf der Diskstation aber nix von \\HOME_DS zu finden.

[NorbertFe 2.035]

Wäre ja auch eher interessant, welcher Prozess von der Diskstation sich irgendwie auf Ressourcen deiner Domain zugreifen will. Fallen mir ja nur andere SMB Shares oder LDAP usw. ein.

[mcdaniels 29]

vor 52 Minuten schrieb NorbertFe:

Wäre ja auch eher interessant, welcher Prozess von der Diskstation sich irgendwie auf Ressourcen deiner Domain zugreifen will. Fallen mir ja nur andere SMB Shares oder LDAP usw. ein.

das kann ich dir beantworten: Die DS hängt mit AD-Authentifizierung für die Shares (Als Domänenmember) in der Domain. Dennoch erklärt das (für mich) nicht, wo dieses verda**** \\HOME_DS herkommt.

 

Auf dem Ding läuft an sich (bis auf die nicht deinstallierbaren) Standardapps nur SMB bzgl. Shares und erwähntes \\HOME_DS sehe ich nirgends. Aber vielleicht komm ich da ja noch dahinter.

 

Das ist wenigstens mal etwas anderes, wie "ich kann mich nicht anmelden" ... wieso brauchen wir dieses komplizierte sinnlose 2FA, Ich hab meinen Authenticator gelöscht, weil ich dachte ich brauch ihn nicht mehr, mein PC ist aus... / kann es sein dass du ihn ausgesteckt hast? / nein, ich hab nur meinen Wasserkocher angesteckt... usw. Zeug...

bearbeitet vor 18 Stunden von mcdaniels

[NorbertFe 2.035]

Tjo.... mal synology anrufen ;)