Fehlgeschlagene Anmeldeversuche von Clients am Server (EreignisID: 4625) (2024)

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1572463089

[content:1572196944#1572463089]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

1

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1572497622

[content:1572196944#1572497622]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Kannst du mir bitte sagen was du damit meinst?
Danke!

Nachtrag:
V-LANs? Das ist in diesem Fall blöd da die Clients den Server erreichen können müssen.
(und es nur ca. 6 Clients sind)

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1572552664

[content:1572196944#1572552664]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Können sie doch! Wenn der IT-Dienstleister Ahnung hat.

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1572574530

[content:1572196944#1572574530]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Der IT-Dienstleister bin in dem Fall ich

In der Berufsschule hatte ich beim Thema V-LANs gut aufgepasst und auch in der Praxis ein bisschen Berührung damit bekommen.

Leider verstehe ich auf Anhieb nicht wie mein Problem mit V-LANs lösen soll?
(Ich glaube der Switch vor Ort ist sogar V-LAN fähig)

Nur die Clients voneinander durch V-LANs trennen sollte nichts bringen?
(pro Client ein V-LAN mit dem Server der in allen V-LANs hängt?! Muss gerade überlegen - aber ich denke es sollte gehen das der Server in mehreren V-LANs hängt?! - da im nachhinein die Verbindung zum Server physikalisch/virtuell immer noch besteht löst das nicht mein Problem?!)

Freue mich über eine Antwort
mfG Goodfred

Nachtrag: Meint Ihr ich solle eine Firewall dazwischenschalten? Halte ich ehrlich gesagt für eine unelegante Lösung

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1572641755

[content:1572196944#1572641755]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Moin,

nur ein paar Kommentare von mir:

Zitat von @Goodfred:
Hier vermute ich das es damit zusammenhängt, das dieser Client der einzige ist der nicht in der Domäne ist
- und versucht sich mit seinem Computernamen an der Domäne anzumelden

Haben wir auch. Etwa 15 Clients die nicht in der Domäne sind (aus diversen Gründen). Keiner davon verursach den Fehler.

Wir würden uns freuen wenn wir eine Lösung haben damit nicht täglich wenn der Client an ist, diese Anmeldeversuche erfolgen.
(P.S.: Ich habe gehört das Computerkonten alle 30 Tage ein neues Computerkontopasswort in der Domäne generieren. Vllt. hängt es damit zusammen?)

Halte ich für ausgeschlossen, denn der Client gehört ja gar nicht zur Domäne wie du schreibst. Wenn er nicht zur Domäne gehört, kann er auch die Vertrauensstellung nicht verlieren und der DC weißt ihm kein Kennwort zu.

Beim anderen Kunden gibt es verschiedene Clients die sich mit versuchen mit Benutzeraccounts anzumelden.
Zur Zeit haben wir Anmeldeversuche von UAC1 und UAC2. Kein Gerät ist zur Zeit Mitglied der Domäne - das heißt alle Accounts sind lokal auf dem PC - der Grund dafür ist das vor vielen Jahren eine Software benötigt wurde die nicht mit Windows Domänen funktionierte - ob das immer noch so ist weiß ich nicht - aber ich denke wir werden die Anmeldungen noch eine Weile so laufen lassen.
Das heißt - die lokale Anmeldung läuft mit einem Benutzernamen (UAC1 und UAC2) - und diese Benutzernamen versuchen sich am SV1 anzumelden.

lokale Konten melden sich nie in der Domäne oder am Server an. Es sei denn du hast das was mit Skripts oder ähnlichem gebaut.

Mittlerweile gibt es auch Anmeldeversuche von IPv6 Adressen.
Ich habe mir überlegt einfach IPv6 zu deaktivieren, die zur Zeit die meisten Anmeldeversuche ausmachen.

Solange alle Seiten beide Protokolle behrrschen sollte es keinen Unterschied machen. Die Anfrage kommt ja bis zur richtigen Stelle durch.

Hier würde ich gerne die Quellen ausmachen und die Anmeldeversuche unterbinden und hoffe Ihr könnt mir helfen/mich auf den richtigen Pfad führen.

Was hast du denn schon als Ursache geprüft? Aufgabenplanung, Skripte, diese oben erwähnte Software?

Habe schon überlegt ob es mit den hinterlegten Credentials an den Netzlaufwerken zusammenhängt - da habe ich aber vor ca. 4 Wochen an allen Clients die Netzlaufwerke mit den korrekten Credentials überall frisch eingetragen damit der richtige Benutzer/die korrekten Berechtigungen angemeldet sind. (Domänenkonten auf Freigaben)

Deiner Beschreibung nach her ausgeschlossen. Ungültige Credentials würden den Usernamen beinhalten. Du sagst ja aber, der Computername generiert den Fehler. Auf der anderen Seite: Nur weil du sie vor 4 Wochen überall korrekt eingetragen hast, heißt es nicht, dass die Anwender daran rumgefummelt haben

Leider verstehe ich auf Anhieb nicht wie mein Problem mit V-LANs lösen soll?
(Ich glaube der Switch vor Ort ist sogar V-LAN fähig)

Ich glaube es ist etwas irritierend, da du 2 Kunden hast. Ich gehe davon aus, dass die beiden Kunden nicht auf dem gleichen Server arbeiten und du einen Kunden mit einem Server hast und einen weiteren mit einem anderen und beide das ähnliche Problem haben. Wenn aber 2 Kunden sich einen DC teilen, dann solltest du auch kein VLAN dazwischen hängen, sondern jeder Kunde bekommt seinen eigenen DC.

Nur die Clients voneinander durch V-LANs trennen sollte nichts bringen?
(pro Client ein V-LAN mit dem Server der in allen V-LANs hängt?! Muss gerade überlegen - aber ich denke es > sollte gehen das der Server in mehreren V-LANs hängt?! - da im nachhinein die Verbindung zum Server physikalisch/virtuell immer noch besteht löst das nicht mein Problem?!)

Vielleicht nochmal lieber VLAN nachlesen. jeden Client in 1 VLAN bedeutet, dass du alle VLANs am Server einrichten musst. das ist unnötig viel Aufwand. Wenn beide Kunden sich einen Server teilen, dann Kunde 1 bekommt VLAN A, Kunde 2 bekommt VLAN B, etc. Ich denke so war die VLAN-Idee gemeint

Nachtrag: Meint Ihr ich solle eine Firewall dazwischenschalten? Halte ich ehrlich gesagt für eine unelegante Lösung

Wozu? Was soll die Firewall deiner Meinung zwischen Client und Server bewirken?

Gruß
Doskias

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1574428703

[content:1572196944#1574428703]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Achso, tut mir leid wenn ich für Verwirrung gesorgt habe.
Die Kunden haben jeweils einen eigenen Server am eigenem Standort :D

Danke für eure Antworten bisher.

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1574501253

[content:1572196944#1574501253]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Moin

Danke für die Aufklärung

Schau mal hier: vielleicht hilft dir das weiter:
https://social.technet.microsoft.com/Forums/de-DE/ef5c1755-96c7-4a2d-bdb ...

Gruß
Doskias

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1579767162

[content:1572196944#1579767162]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Hi! Gerne!

Die Seite kannte ich schon. Habe schon einige Zeit damit verbracht nach dem Fehler zu suchen, leider ohne Erfolg.

Deswegen frage ich hier nach Rat.

Grüße an alle, Goodfred

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1583678179

[content:1572196944#1583678179]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Der 2. Kunde:

Also, mit control userpasswords2 habe ich gesehen das für die Anmeldung auf dem Server 2 Einträge waren.
Ein mal mit der IP .150
Ein mal mit dem DNS-Namen SV1
Habe die Einträge gelöscht und hoffe das bei einem Eintrag das Passwort falsch war und das der Grund für die Fehlanmeldungen sind.
(danach habe ich natürlich die Netzlaufwerke die ich vorher entfernt habe ordnungsgemäß hinzugefügt mit sv1 und dem Domänenbenutzer/Domänenbenutzerpasswort)
(für die Anmeldung an den Netzlaufwerken muss ich DOMÄNE\Benutzer + PW nutzen. Alle melden sich aber lokal an den Maschinen ohne Domänenzugehörigkeit an)
(jetzt ist nur noch 1 Eintrag vorhanden)
Die war bei 2 PCs

Ein 3. PC hatte nur einen Eintrag!
In control userpasswords2 nur ein Eintrag mit Domänenbenutzer + PW - aber - mit einem anderem Benutzernamen!
Der Benutzername war z.B. Vorn.Nachn
Aber die Anmeldeversuche von dieser IP/diesem PC am Server hatten den Benutzernamen "Nachn" (also kein Vorname, nur Nachname)
Ich habe sinnloserweise dann Benutzernamen von Nachn auf Vorn.Nachn geändert (was es in Zukunft erschwert herauszufinden ob es in control userpasswords2 hinterlegt ist oder der lokale Windows Benutzer ist - das kann ich aber noch ändern)

Kurz: Hat jemand Tipps zu folgendem: Der PC versucht sich mit dem Computerkontobenutzernamen (lokaler PC) an dem Server anzumelden (der auch ein DC ist) - der Benutzername in control userpasswords2 war ein anderer als der der die Anmeldeversuche am Server versucht hat (in controler userpasswords2 war es korrekterweise der Domänenbenutzer Vorn.Nachname) (Anmeldeversuch von Nachn. - so wie der PC Benutzeraccount heißt)

Freue mich über Feedback/Tipps/Ratschläge/etc. und wünsche ein schönes Wochenende!

Goodfred

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1583706598

[content:1572196944#1583706598]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Nachtrag: Seit 13:43Uhr bis 14:15Uhr waren 971 fehlgeschlagene Anmeldeversuche
Um 13:39Uhr habe ich angefangen nach control userpasswords2 Einträge zu schauen.

Anmeldenamen:
Der vorher genannte vorn.nachn (den Eintrag gab es vorher nicht! Vorher war dieser Eintrag unter nachn zu finden! Das heißt, seit dem ich vorher den lokalen Anmeldenamen geändert habe von nachn. auf vor.nachn was gleich wäre wie DOMAIN\vorn.nachn ist der Eintrag da! 59 Versuche bis jetzt)
2. Anmeldename: Standortdergleichzeitigbenutzername von lokaler Anmeldung ist (234 Versuche)
3. Anmeldename: lokaler Benutzername (284 Versuche)
4. Anmeldename: standortdergleichzeitigbenutzernameistmitkleinemanfangsbuchstaben (lokaler Anmeldename) (394 Versuche)

Also, ich konnte es eingrenzen:
Die Anmeldeversuche laufen alle mit dem Benutzernamen der an den lokalen PCs angemeldet ist (wie gesagt, PCs sind nicht in der Domäne)

Der andere Kunde hat ja als Anmeldename bei den fehlgeschlagenen Anmeldungen CK1$ - das heißt das Computerkonto von diesem einen einzigen Gerät das nicht Mitglied der Domäne ist versucht sich anzumelden am Server.

Wenn ich die Lösung habe werde ich natürlich informieren!

Goodfred

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1735864425

[content:1572196944#1735864425]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Ich versuche nachher mein Glück mit dem Tool "Microsoft Network Monitor"

Ich denke danach sollte ich wissen woher es kommt!

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-1736734716

[content:1572196944#1736734716]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Hat eine Weile gedauert bis ich den Fehler aufzeichnen konnte.
Um 14:04Uhr war ein Ereignis 4625 und um 14:10Uhr wollte ich die Logs vom Network Monitor holen - da konnte ich die Logs nicht speichern
Erst um 15:17Uhr gab es wieder solch ein Eintrag den ich aufzeichnen konnte. Juhuu! :D

Ich weiß das es um Destination Port 445 geht, also SMB. Da keine Drucker vorhanden sind muss es um Fileserver gehen. Networkmonitor zeigt mir an: DstPort:Microsoft-DS(445)
Das läuft aber über IPV6 ab.
30 x ist in der Ereignisanzeige 4625 aufgetreten, auf 3 Sekunden verteilt.

Anmeldename ist der Windows-Anmeldename (ich hatte mal den Anmeldenamen verändert und er nutze den neuen Anmeldenamen!)

Die Clients sind nicht in einer Domäne. Und die Netzlaufwerke habe ich frisch eingebunden gehabt vor einer weile und im Credential Manager von Microsoft vorher alle Einträge gelöscht. (komischerweise nahm er bei Windows-Anmeldenamen-Änderung den neuen Namen ...)

Das heißt - ich habe keine Ahnung welche Software den Windows-Anmeldenamen verwendet und sich dann versucht am Server anzumelden. (die Benutzer haben Accounts auf dem DC mit denen Sie sich anmelden. Das funktioniert bei Netzlaufwerken auch. Ich frage mich wieder da ich den Windows-Anmeldenamen geändert hatte und er den neuen Namen verwendet hat ...)

Sourceport hat er von 50543 hochgezählt auf 50584 (mit Unterbrechungen, ich denke das sind andere die diese Ports bekommen haben)

Ich würde Morgen mal wieder eine Aufzeichnung starten und den Anwender verschiedene Tätigkeiten ausführen lassen. 14:04Uhr und 15:17Uhr sind keine 60min (damit sind automatische Intervalle ausgeschlossen). Ich schließe aus das die "Netzlaufwerksoftware" von Microsoft "fehlerhaft" arbeitet. Da bleibt Anwendersoftware die ich prüfen werde. Ich denke nicht das die "Netzlaufwerkfunktion" im Hintergrund andere Credentials beim Netzlaufwerkaufruf zusätzlich versucht zu verwenden. (Windows-Anmeldename - ich habe ja bereits den Benutzer vom AD vom Fileserver als Benutzer für die Netzlaufwerke eingetragen - das meint ich mit "fehlerhaft" arbeitet)

Ich bedanke mich recht herzlich fürs lesen! Wenn ich die Lösung habe werde ich euch natürlich informieren!

P.S.: Über Tipps freue ich mich nach wie vor sehr!

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-2052273329

[content:1572196944#2052273329]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Aktueller Stand:
Das Problem hat für mich mittlerweile die niedrigste Priorität.
Zuletzt habe ich das Paket Capture analysiert was ich auch noch weitermachen werde.

Ich konnte ermitteln das der Prozess "System" auf dem Zielport 445 am Server eine "Microsoft-DS" Anfrage macht.
So wie ich die Pakete sehe vermute ich sehr stark das es um Fileserverzugriff geht.

Der Benutzername wurde auch tief in einem anderen Paket gefunden.

Auch sehe ich das eine IPv4 und auch gleichzeitig eine IPv6 Adresse verwendet wird um mit dem Server zu sprechen.
(ich vermute im Moment auch, es sind 2 verschiedene "Tasks"/"Prozesse")

Ich bin noch nicht fertig mit der Analyse, dachte aber ich gebe hier kurz ein Update.
Bei weiteren Tipps freue ich mich natürlich sehr!
(ob ich vllt. doch genau ermitteln kann welcher Prozess die 445 Anfrage am Server macht und warum?)

z.B. gibt es ein "SESSION SETUP (0x1)" als "SMB2:C" das mit IPv6 läuft
- die Antwort ist in IPv4 "SMR2:R" mit Inhalt "CLOSE (0x6)"
- der folgende Verkehr läuft weiter über IPv4 (im Paket Capture werden anstatt IPv4 Adresse Hostnames angezeigt)
(da ich jetzt 10 Pakete weitergeschaut habe, vermute ich doch wieder da es verschiedene Prozesse sind weil zwischen lauter SMB2:R und SMB2:C's ein mal ein "TCP" Paket ist (anstatt wie die restlichen SMB2 Pakete) mit "TCP:Flags=...A.R.., SrcPort=50..., DstPort=Microsoft-DS(445), PayloadLen=0, Seq=xx, Ack=xx, Win=0 (scale factor 0x8) = 0" - und in den Paketen drum herum viele SMB2:R und SMB2:C's sind (CLOSE, CREATE, QUERY INFORMATION, SETTION SETUP, NT Status, QUERY DIRECTORY, NEGOTIATE, WRITE, READ)

Wohlgemerkt: In der Ereignisanzeige zeigt er ausschließlich IPv6 Adressen an mit fehlgeschlagenen Anmeldeversuchen (zur Zeit 2 Benutzernamen mit zwei verschiedenen IPv6 Adressen - ich weiß das zwei von 4 möglichen Benutzern angezeigt werden da die anderen 2 Benutzer/Clients ausgeschaltet/im Energiesparmodus sind)

Freue mich natürlich über Brainstormings und Tipps und alles sehr! :D

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-2425999738

[content:1572196944#2425999738]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Update:
Ich habe diesem Thema die letzte Priorität gegeben und komme wahrscheinlich die Tage dazu dies weiterzuverfolgen.

Wenn Ihr mir Tools empfehlen könnt mit denen ich herausfinde welcher Prozess diese Anmeldeversuche an den Server findet - vielen Dank!

Wie gesagt - ich weiß nur durch Wireshark das
"Microsoft DS"
"Port 445"
"Prozess: System"
"wenn Client eingeschaltet ist bis zu paar Hundert Anmeldeversuche am Tag pro Client"
"einige Clients sogar IPv6 benutzen"
"mehrere Versuche nacheinander (Fehlgeschlagen, Ereignisanzeige ID 4625)"
"Windows-Anmeldename wird verwendet (nicht Computername, lokaler-Windows-Benutzer)"
die Anmeldeversuche durchführt.

Wenn ich wüsste welcher Teil von "System" dies durchführt und warum - das wäre echt cool! :D

Danke fürs lesen!
Goodfred

P.S.: Es geht um den 2. Kunden im Eingangspost

https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html#comment-2499547711

[content:1572196944#2499547711]

• Copy internal comment link
• Copy external comment link
• To the beginning of the comments

Leider habe ich bisher nicht herausgefunden wie ich in den Prozess "System" so reinschauen kann damit ich weiß warum Microsoft-DS Port 445 versucht sich am Server anzumelden mit dem Windows-Anmeldenamen.

Über Tipps freue ich mich nach wie vor sehr!

Schöne Restwoche! Frohe Ostern!
Goodfred