Directory Server Localhost sperrt nachts Userkonto???

[alegend]

Hallo,
ich habe eine Problem....das Konto eines Nutzers wrude jetzt das 2.mal in Folge nachts gesperrt ohne Grund.
Er kommt früh in die Arbeit und sein Konto ist gesperrt - Haken bei GESPERRT ist drin...
Woran kann das liegen?!?!

 

[alexhell]

Gibt es keine Logs? Also es muss ja schon einen Grund geben. Es wird nicht einfach so gesperrt

 

[Ulfhednir]

Da wird der Kontoschutz greifen. Schau mal unter Sicherheit / Konto / Kontoschutz nach. Hacking-Versuche von außen?

 

[alegend]

ich habe das eben getan und ich habe einen protokollierten Loginversuch via eines anderen PC´s (wird bei uns eig. nur zum Scannen von Bauplänen benutzt...) ich denke hier ist das Problem...sprich gehackt oder wie auch immer

 

[alegend]

ich dreh langsam am rad auch bei anderen useren habe ich öfter derarrtige komische protokolleinträge und das währned sie arbeiten?!
WAs kann das sein ?

 

[alegend]

wie kann es a) Mehrfahc zur exakt gleichen Zeit sein teils 4x? das muss doch ein bug sein oder sonstiges

 

[Adama]

Du könntest mal in die Samba-Logs unter /var/log/samba schauen, ob die mehr hergeben.

Allerdings muss man immer im Hinterkopf haben, dass die Samba-Version, die Synology benutzt, mehr oder weniger stark modifiziert ist.

 

[maxblank]

Irgendein Dienst, der im Userkontext dort läuft und das Kennwort des Users wurde geändert?

 

[ctrlaltdelete]

Das sind doch alles interne Clients/server die da zugreifen, schau halt da nach was von dort aus versucht zuzugreifen.
edit: habt ihr Probleme mit Viren?

 

[alegend]

ja das ist mir scon klar dass es intern ist - daher war auch mein Verdacht hacker...
aber wie kann das sein - der benutzer arbeitet zu diesem Zeitpunkt ...

der Rechner ist aber nicht in der Domäne derzeit weil seit dem Update krieg ich den icht mehr in die domäne und ich bin derzeit nicht vor ort - sprich remote klappt das alles nicht
https://bugzilla.samba.org/show_bug.cgi?id=15418

Sprich der benutzer mit o.g. IP ist als Workstation normal in Windows angemeldet wie es dann zu dem oben ersichtlichen Verhalten kommt ist mir rätselhaft.

Der andere PC welchen ich in meinem vorherigen pc genannt hate ist ein anderes Thema da hhier scheinbar Nutzernamen "probiert" werden /wurden. Ich habe den Rechner jetzt mal vom Netz genommen und Viren / Malware gescannt. Hier gab es nur 6 malware treffer die nicht verantwortlich waren

 

[alegend]

Du könntest mal in die Samba-Logs unter /var/log/samba schauen, ob die mehr hergeben.

Allerdings muss man immer im Hinterkopf haben, dass die Samba-Version, die Synology benutzt, mehr oder weniger stark modifiziert ist.

muss ich mir mal zu gemüte führen ob da was auffällt...

 

[ctrlaltdelete]

Was greift den über Port 63011 zu?

 

[alegend]

Das ist unklar aber der Port ändert sich täglich.
Seit der eine Rechner nun vom netz ist gibt es nur noch diesen Fehler von dem PC der derzeit nicht in der Domäne ist wegen dem verbuggten Smb updaten von MS.
Der user logt sich ganz normal als "normaler" user mit Zugriff auf Netzwerk an produziert aber weiterhin

 

[Ulfhednir]

Lösch doch mal den Login aus dem Windows Credential Manager heraus. Und schau, ob der Log trotzdem vollläuft.

 

[ctrlaltdelete]

Schau halt mal mit netstat auf dem Client.

 

[Adama]

Lösch doch mal den Login aus dem Windows Credential Manager heraus. Und schau, ob der Log trotzdem vollläuft.

Wenn die Rechner Domain-joined sind, sollte da sowieso nichts stehen.

 

[alegend]

Aus dem Credential Manager ist es gelöscht - jedoch weiterin dieser Fehler - sporadisch.
7.30 uhr früh dann wieder 13 uhr oder so .....
Der rechner befindet sich nicht in der Domäne derzeit daher wundert es mich umsomehr - ich habe den Rechner als normale Workstation im Netzwerk da er immer als UNTRUSTET gilt - obwohl der Rechner vom AD gelöscht wurde - obwohl das update deinstalliert wurde
=> https://learn.microsoft.com/en-us/a...er-update-kb5028166-trust-relationship-broken
hier ist es windows 10 bei mir win 11....
Da ich nicht vor Ort bin kann ich nicht soviel an dem client rumspielen...