15
Fehlgeschlagene Anmeldeversuche von Clients am Server (EreignisID: 4625)
Erneut einen guten Tag allerseits!
Ich komme gleich zur Sache:
Wir haben ein RMM und bei zwei verschiedenen Kunden kommen immer fehlgeschlagene Anmeldeversuche aus dem internen Netzwerk. (von Clients an den Servern)
Fehler-ID in der Ereignisanzeige ist 4625
Bei einem Kunden ist es immer der gleiche Client der mit dem Computerkonto CK1$ versucht sich anzumelden. (CK1 ist auch der Hostname)
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
Kurz: Alle anderen Clients sind in der Domäne. Nur dieser Client nicht. Das würden wir vorerst auch so belassen.
Habt Ihr eine Idee wie ich da vorgehen kann damit dieser Client nicht immer versucht sich mit seinem Computerkonto CK1$ an der Domäne DC1 anzumelden?
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?)
Fehler beim Anmelden eines Kontos.
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: CK1$
Kontodomäne: Domain
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xC000006D
Unterstatus:: 0xC000006A
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: CK1
Quellnetzwerkadresse: Privat-C.120
Quellport: 49765
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
- System
- Provider
[ Name] Microsoft-Windows-Security-Auditing
[ Guid] {----}
EventID 4625
Version 0
Level 0
Task 12544
Opcode 0
Keywords 0x8010000000000000
- TimeCreated
[ SystemTime] 2021-11-29T09:11:54.987384200Z
EventRecordID
Correlation
- Execution
[ ProcessID] 888
[ ThreadID] 1372
Channel Security
Computer server.domain.tld
Security
- EventData
SubjectUserSid S-1-0-0
SubjectUserName -
SubjectDomainName -
SubjectLogonId 0x0
TargetUserSid S-1-0-0
TargetUserName CK1$
TargetDomainName Domain
Status 0xc000006d
FailureReason %%2313
SubStatus 0xc000006a
LogonType 3
LogonProcessName NtLmSsp
AuthenticationPackageName NTLM
WorkstationName CK1
TransmittedServices -
LmPackageName -
KeyLength 0
ProcessId 0x0
ProcessName -
IpAddress Privat-C.120
IpPort 49765
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.
Mittlerweile gibt es auch Anmeldeversuche von IPv6 Adressen.
Ich habe mir überlegt einfach IPv6 zu deaktivieren, die zur Zeit die meisten Anmeldeversuche ausmachen.
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.
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)
Jemand hat gemeint das es mit Network Discovery zusammenhängen kann - es sind hier Momentan nur 2 (von 6) Clients die versuchen sich anzumelden - und ich denke nicht das bei Network Discovery er versucht sich mit UAC1/UAC2 anzumelden? Die anderen Clients sind zur Zeit ruhig.
Es gab vor ca. 8 Wochen eine Änderung der Belegung der PCs. UAC2 hat früher einen anderen PC benutzt. UAC2 wurde dann an einem vorhandenen PC frisch eingerichtet und diesen PC benutzt er nun. An UAC2s alten PC ist ein anderer Mitarbeiter.
Bei UAC1 ist es ein Konto - bei dem es möglich ist das alte Software versucht sich am Server anzumelden - wie ich das genau herausfinde ist mir momentan noch etwas unklar.
Hier ein Log Auszug
Fehler beim Anmelden eines Kontos.
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: UAC1
Kontodomäne: Kunde
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xC000006D
Unterstatus:: 0xC000006A
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: DESKTOP-Client1
Quellnetzwerkadresse: Privates-C.120
Quellport: 50144
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
- System
- Provider
[ Name] Microsoft-Windows-Security-Auditing
[ Guid] {----}
EventID 4625
Version 0
Level 0
Task 12544
Opcode 0
Keywords 0x8010000000000000
- TimeCreated
[ SystemTime] 2021-11-29T15:54:41.216851600Z
EventRecordID 29326644
Correlation
- Execution
[ ProcessID] 868
[ ThreadID] 12628
Channel Security
Computer Server.Kunde.local
Security
- EventData
SubjectUserSid S-1-0-0
SubjectUserName -
SubjectDomainName -
SubjectLogonId 0x0
TargetUserSid S-1-0-0
TargetUserName UAC1
TargetDomainName Kunde
Status 0xc000006d
FailureReason %%2313
SubStatus 0xc000006a
LogonType 3
LogonProcessName NtLmSsp
AuthenticationPackageName NTLM
WorkstationName DESKTOP-Client1
TransmittedServices -
LmPackageName -
KeyLength 0
ProcessId 0x0
ProcessName -
IpAddress Privat-C.120
IpPort 50144
Ich freue mich sehr über Fragen, Lösungen, Ideen, Antworten, etc. und bedanke mich schon mal für diese.
mfG Goodfred
Ich komme gleich zur Sache:
Wir haben ein RMM und bei zwei verschiedenen Kunden kommen immer fehlgeschlagene Anmeldeversuche aus dem internen Netzwerk. (von Clients an den Servern)
Fehler-ID in der Ereignisanzeige ist 4625
Bei einem Kunden ist es immer der gleiche Client der mit dem Computerkonto CK1$ versucht sich anzumelden. (CK1 ist auch der Hostname)
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
Kurz: Alle anderen Clients sind in der Domäne. Nur dieser Client nicht. Das würden wir vorerst auch so belassen.
Habt Ihr eine Idee wie ich da vorgehen kann damit dieser Client nicht immer versucht sich mit seinem Computerkonto CK1$ an der Domäne DC1 anzumelden?
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?)
Fehler beim Anmelden eines Kontos.
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: CK1$
Kontodomäne: Domain
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xC000006D
Unterstatus:: 0xC000006A
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: CK1
Quellnetzwerkadresse: Privat-C.120
Quellport: 49765
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
- System
- Provider
[ Name] Microsoft-Windows-Security-Auditing
[ Guid] {----}
EventID 4625
Version 0
Level 0
Task 12544
Opcode 0
Keywords 0x8010000000000000
- TimeCreated
[ SystemTime] 2021-11-29T09:11:54.987384200Z
EventRecordID
Correlation
- Execution
[ ProcessID] 888
[ ThreadID] 1372
Channel Security
Computer server.domain.tld
Security
- EventData
SubjectUserSid S-1-0-0
SubjectUserName -
SubjectDomainName -
SubjectLogonId 0x0
TargetUserSid S-1-0-0
TargetUserName CK1$
TargetDomainName Domain
Status 0xc000006d
FailureReason %%2313
SubStatus 0xc000006a
LogonType 3
LogonProcessName NtLmSsp
AuthenticationPackageName NTLM
WorkstationName CK1
TransmittedServices -
LmPackageName -
KeyLength 0
ProcessId 0x0
ProcessName -
IpAddress Privat-C.120
IpPort 49765
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.
Mittlerweile gibt es auch Anmeldeversuche von IPv6 Adressen.
Ich habe mir überlegt einfach IPv6 zu deaktivieren, die zur Zeit die meisten Anmeldeversuche ausmachen.
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.
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)
Jemand hat gemeint das es mit Network Discovery zusammenhängen kann - es sind hier Momentan nur 2 (von 6) Clients die versuchen sich anzumelden - und ich denke nicht das bei Network Discovery er versucht sich mit UAC1/UAC2 anzumelden? Die anderen Clients sind zur Zeit ruhig.
Es gab vor ca. 8 Wochen eine Änderung der Belegung der PCs. UAC2 hat früher einen anderen PC benutzt. UAC2 wurde dann an einem vorhandenen PC frisch eingerichtet und diesen PC benutzt er nun. An UAC2s alten PC ist ein anderer Mitarbeiter.
Bei UAC1 ist es ein Konto - bei dem es möglich ist das alte Software versucht sich am Server anzumelden - wie ich das genau herausfinde ist mir momentan noch etwas unklar.
Hier ein Log Auszug
Fehler beim Anmelden eines Kontos.
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: UAC1
Kontodomäne: Kunde
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xC000006D
Unterstatus:: 0xC000006A
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: DESKTOP-Client1
Quellnetzwerkadresse: Privates-C.120
Quellport: 50144
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
- System
- Provider
[ Name] Microsoft-Windows-Security-Auditing
[ Guid] {----}
EventID 4625
Version 0
Level 0
Task 12544
Opcode 0
Keywords 0x8010000000000000
- TimeCreated
[ SystemTime] 2021-11-29T15:54:41.216851600Z
EventRecordID 29326644
Correlation
- Execution
[ ProcessID] 868
[ ThreadID] 12628
Channel Security
Computer Server.Kunde.local
Security
- EventData
SubjectUserSid S-1-0-0
SubjectUserName -
SubjectDomainName -
SubjectLogonId 0x0
TargetUserSid S-1-0-0
TargetUserName UAC1
TargetDomainName Kunde
Status 0xc000006d
FailureReason %%2313
SubStatus 0xc000006a
LogonType 3
LogonProcessName NtLmSsp
AuthenticationPackageName NTLM
WorkstationName DESKTOP-Client1
TransmittedServices -
LmPackageName -
KeyLength 0
ProcessId 0x0
ProcessName -
IpAddress Privat-C.120
IpPort 50144
Ich freue mich sehr über Fragen, Lösungen, Ideen, Antworten, etc. und bedanke mich schon mal für diese.
mfG Goodfred
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1572196944
Url: https://administrator.de/forum/fehlgeschlagene-anmeldeversuche-von-clients-am-server-ereignisid-4625-1572196944.html
Ausgedruckt am: 23.12.2024 um 03:12 Uhr
15 Kommentare
Neuester Kommentar
Segmentiert die Netze.
1
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)
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)
Zitat von @Goodfred:
V-LANs? Das ist in diesem Fall blöd da die Clients den Server erreichen können müssen.
...
Können sie doch! Wenn der IT-Dienstleister Ahnung hat.V-LANs? Das ist in diesem Fall blöd da die Clients den Server erreichen können müssen.
...
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
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
Moin,
nur ein paar Kommentare von mir:
Gruß
Doskias
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.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
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.(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?)
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.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.
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.Ich habe mir überlegt einfach IPv6 zu deaktivieren, die zur Zeit die meisten Anmeldeversuche ausmachen.
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.(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?!)
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(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?!)
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
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.
Die Kunden haben jeweils einen eigenen Server am eigenem Standort :D
Danke für eure Antworten bisher.
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
Zitat von @Goodfred:
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.
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.
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
Zitat von @Doskias:
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
Moin
Zitat von @Goodfred:
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.
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.
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
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
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
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
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
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
Ich versuche nachher mein Glück mit dem Tool "Microsoft Network Monitor"
Ich denke danach sollte ich wissen woher es kommt!
Ich denke danach sollte ich wissen woher es kommt!
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!
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!
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
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
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
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
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
Über Tipps freue ich mich nach wie vor sehr!
Schöne Restwoche! Frohe Ostern!
Goodfred
