smothy

Ja das stimmt wohl so. Also auf dem Gateway Server ( Linux basiert ) sind meine Benutzer drin. Aber diese sind manuell hinzugefügt worden. ein "normaler" und einer mit Admin rechten - sodass "sudo" nicht benötigt werden würde. Und wie schon erwähnt. wäre in dem Fall dann merkwürdig, warum die Kollegin gesperrt wird, welche niemals auf den Gateway kommt - weil sie keinen Account dafür hat bzw keinen user in der user-liste steht.

Nein da wird nichts geprüft ist wie gesagt reines Gateway / firewall ohne zusätzliche Features oder Software, rein nur IP Adressen basiert. Gateway / DHCP .... Folgend - das ist z.B. ein Eintrag in den Logs ( Ereignisse ) - das der ehemalige Mitarbeiter welcher nicht mehr in der Firma tätig ist. Dieser Account sowie meine zwei und der einer Kollegin werden ständig gesperrt. 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: ol_am Kontodomäne: do Fehlerinformationen: Fehlerursache: Das Konto ist gesperrt. Status: 0xc0000234 Unterstatus:: 0x0 Prozessinformationen: Aufrufprozess-ID: 0x0 Aufrufprozessname: - Netzwerkinformationen: Arbeitsstationsname: \\10.92.200.248 Quellnetzwerkadresse: 10.92.200.248 Quellport: 47393 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: NtLmSsp Authentifizierungspaket: NTLM Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.

Es werden keine Zertifikate eingesetzt/verwendet falls das die Frage war.

Kann ich machen, wobei ich nicht weiß ob das so notwendig ist wirklich alles aufzulisten. Ich versuch mal das wichtigste wiederzugeben. Es gibt eine Firmen-Domäne ( Sitz woanders in Deutschland ) mit dieser Domäne haben wir hier eine Vertrauensstellung geschafft für unsere beiden Domänen ( Haupt- und Subdomäne ) Soweit das Grobe. Hier geht die Internetleitung in den Gateway Rechner rein mit zwei Netzwerkkarten für jeweils eine Domäne bzw. natürlich vorher in die entsprechenden Switche. Was ich evlt noch erwähnen sollte, glaube das hängt zeitlich recht nah zusammen als die Accounts "gesperrt" wurden, dass ein Kollege zusammen mit mir ( er ist etwas mehr linux affine als ich ) am Gateway konfiguriert hatten, damit unsere Subdomäne auch Zugang zum www hat, was zuvor nicht oder eingeschränkt möglich war. Dann gibt es eben verschiedene Server ( Hardware ) wie eben DC inkl. DNS und DHCP dann noch drei/vier Server als Application/ Monitoring / Testsystem etc. ( ebenso VM´s ) - XenServer

sind keine integriert meinte ich - sind keine Mobiltelefone oder Accounts welche über diese Domain oder DC laufen. Das Gateway ist für das www ( nach außen ) zuständig. ok dann weiß ich imoment nicht wie ich es überprüfen könnte/sollte ob dieser Gateway Server die Ursache ist. oder hättest du einen Vorschlag ?

Mobil-Teile o.ä. laufen definitiv nicht darüber oder sind integriert. Über das Gateway gehen nur die beiden Domains ( Haupt - und subdomäne ) mit einigen Servern und Clients. Evlt. mal den Gateway Server abschalten und schauen ob es dann funktioniert - wäre das eine Idee um überhaupt sicher zu gehen, dass es an diesem liegt ?

Hallo zusammen, erstmal vielen Dank für eure rege Beteiligung und Hilfe. @Nils, natürlich ist bei dem 2. Server ( DC ) auch DNS mit dabei - alles soweit identisch. Protokolle hatte ich auch bereits angeschaut - ( 4771 etc- ) dort steht, was mich etwas verwundert unser GatewayFirewall Server drin ( Linux basiert ). Und da weiß ich nicht woran es liegen könnte denn dort hat die "Kollegin" nie etwas gemacht kommt auch gar nicht dort drauf.

Zumal ich es schon ein sehr großer Zufall sein müsste, würde ich sagen, dass meine beiden Accounts der Account von einer Kollegin und ein noch existierender Account von einem Mitarbeiter ( ehemaliger Administrator - nicht mehr im Unternehmen ) gesperrt werden.

Ok vielleicht unglücklich ausgedrückt, bitte um Entschuldigung. Es gibt einen Domain-Controller ( Server wo auch DNS usw drauf läuft ) und einen weiteren Server welcher als Replikat ( Sync Server ) zu dem 1. Server ( DC ) läuft. weiterhin gibt es zwei Domains die innerhalb der Struktur laufen. Eine Hauptdomain ( firma.net ) und eine Subdomain ( sub.firma.net ) Ansonsten laufen jeweils verschiedene Server mit unterschiedlichen Rollen/Features. Wie finde ich heraus wo was läuft das ein falsches Kennwort gespeichert hat ? Es hat auch keine Passwort-Änderung stattgefunden bei den betreffenden Accounts. Mobilgeräte sind definitiv nicht verbunden. Danke Damit meinte ich, dass ich mit PSLoggedOn Tool und Account Lockout Tool Informationen herausgelesen habe und mir dort angezeigt wurde welcher der beiden Server wohl dafür zuständig zu sein scheint.

Hallo zusammen, entschuldigt die verspätete Reaktion auf eure Unterstützung. Ich war nicht im Büro somit konnte ich nicht weiter dran arbeiten. Also es gibt zwei DC´s im Prinzip für die Hauptdomäne. Einer von den Servern läuft als Backup-DC von welchem wohl die ganze Sperrung auszugehen scheint. gemeinsames Mailkonto gibt es nicht für diese Benutzer, nein.

Creditionals muss man im prinzip nur angeben wenn man sich einloggt oder Änderungen vor nimmt. dort sind rein nur die IP Adressen hinterlegt für das Gateway - für die Kommunikation nach außen und/oder intern mehr nicht. Ob es was bringt den wohl verantwortlichen DC ( Backup-DC ) neu zu starten ? Weil bei dem Logg-Tool 6 Bad Pwd Counts angezeigt werden für diesen Backup DC

läuft hier nicht. hatte jetzt auch mal den Gateway Rechner heruntergefahren. Dachte so loggen sich aufjedenfall alle evlt im hintergrund laufenden Accounts ab. war aber leider nicht der Fall. Immer noch alle 2 Minuten gesperrt.

Das hab ich jetzt so betitelt - ist hier ein Linux ( Ubuntu ) Rechner der als Gateway / Firewall fungiert

Hallo Norbert, danke zunächst für deine schnelle Antwort. Das Tool hatte ich vorher schon, hab es nochmal ausgeführt und sehe locked mit Bad Pwd Count 6 bei dem Backup DC und locked aber mit 0 Bad Pwd Count beim Haupt DC was kann ich jetzt genau daran erkennen ? bzw mit der Information anfangen und was oder wo beseitigen ? Ok. wenn ich nun in die Sicherheitslogs schaue - sehe ich als "Aufrufcomputername" den Gateway Server liegt hier der "Hund" begraben ? aber was wäre nun der nächste Schritt um das problem zu lösen ? Danke

Hallo zusammen, leider weiß ich imoment nicht mehr weiter. Kurz zur Übersicht was vorhanden ist: 2 Domains 1 Hauptdomain 1 Subdomain Hauptdomain ( ein DC und dazu der Backup DC = 2 ) Seit ca. einer Woche und die Abständen werden immer kürzer, derzeit ca. 2 Minuten, werden meine beiden Benutzer ( einmal Admin Benutzer und einmal "normaler" Benutzer ) gesperrt. Ich hatte schon Konto deaktiviert, Passwort zwei/dreimal geändert - hilft nichts PsLoggedOn tool benutzt zum schauen wo der Benutzer als verbunden angezeigt wird Wie ich bisher im Internet gelesen habe könnte es daran liegen, dann der oder in dem Fall die zwei Benutzer auf verschiedenen Geräten nicht korrekt abgemeldet wurden und somit zuviele aktiv sind bzw durch die Passwort Änderungen welche ich durchgeführt hatte ( wobei ich zum Schluss wieder auf das original Passwort gegangen bin ) irgendein Server/client bei dem ich remote verbunden bin/war die Passwort-Abfrage wieder zurücksetzt bzw. eben als falsch ansieht. Was ich aber nicht verstehe ist, dass z.B. PsLoggedOn mir anzeigt wo ich überall verbunden sein soll da sind aber Rechner dabei wo ich nicht verbunden bin bzw. zum testen mich bei dem einen eingeloggt habe und dann sauber abgemeldet habe. desweiteren quser mir nicht anzeigt dass ich dort aktiv bin derzeit. Ob es an Mapping Scripte liegt welche im Hintergrund laufen ? wobei ich da auch nie das Passwort geändert habe. Danke im voraus hoffe jemand hat eine Idee.

Also er ist wieder da - RDP Version ist 6.xxx auf dem Client und Remotedesktopprotokol 7.xxx Windows 7 Bei mir z.B Windows 10 habe ich Version 10.xxx Protokoll 10.2

Hallo MurdocX, explizit eins nach dem anderen wurde nicht abgearbeitet, ich hatte allerdings ein Kommentar dazu geschrieben gehabt - und gemeint "dass es für mich beim durchlesen so anhört als das nicht passend wäre bzw. für mich nach dem durchlesen die Frage stellt warum es zuvor ging ohne dass eine Änderung stattfand" ?! oder vielmehr warum es von diesem einen Client nicht mehr funktioniert.

test purposes :)

Welche Version kann ich imoment nicht sagen, da der Kollege noch nicht da ist. Server ist soweit gepatcht, ja Wobei kann das am Ende eine Rolle spielen wenn es doch zuvor ging und auf einmal nicht mehr ?!

Ist sowieso ein internes Netzwerk - abgeschottet von allem soweit. Test-Area Und zum anderen weiß ich nicht ob das imoment für das Problem relevant ist ob das so gemacht wird oder nicht. Danke dennoch für die reichliches Anteilnahme und Hilfe. Hoffe es hat noch jemand einen Lösungsansatz. Danke

Hallo speer, ja wurde auch überprüft - ist wie bei allen - ohne Authentifizierung bzw. soweit "alle" Versionen erlauben/zulassen Auch der Service wurde neu gestartet bzw überprüft dass der Service läuft - aber wenn das nicht wäre, würden andere Rechner/Clients auch nicht drauf kommen, was eben nicht der Fall ist. Glaube wirklich ich muss mal die Zentrale anschreiben, dass die die Firewall kurz deaktivieren zum prüfen. Wobei ich das dann nicht verstehe, warum der Client auf andere Rechner/Server per RDP drauf kommt ?!

Hallo, irgendwie klingen für mich die Beitrag ( und danke dafür MurdoX ) wie wenn die RDP Verbindung von dem Client aus gar nicht funktioniert aber dies ist nicht der Fall, auf andere Server kommt man drauf. Ebenso anders rum betrachtet - andere Clients kommen auf den Server über welchen wir gerade reden.

Hallo, wie gesagt im prinzip wurde nichts geändert, von einem Tag auf den anderen ging die Verbindung zu diesem Server nicht mehr. Andere Windows 7 Clients kommen auf diesen Server Ebenso dieser welcher Client kommt nicht auf diesen Server aber auf andere weiterhin.

Klar, das mit der Firewall kann ich machen, allerdings muss ich da an die Zentrale gehen und die bitten für den User die Firewall kurz zu deaktiveren bzw. freizugeben um manuel zu ändern. Wollte ich auch schon - was aber der länger Weg ist und dachte gäbe evlt noch anderen Ansatz. Danke

Hallo, der Client kann auf andere System ( Rechner / Server ) per RDP zugreifen. Firewall wurde am Server bereits komplett deaktiviert, brachte auch keine Erfolge. für ausgehende Regel auf dem Client steht die Remoteunterstützung auf "Zulassen" - sollte doch ok sein oder ?! Und welche RDP Einstellungen auf dem Server könnten es sein, wenn andere Clients ohne Probleme verbinden können ? zu Sanches: genau, von dem Client Win7 klappt es urplötzlich nicht mehr. Firewall läuft standardmäßig aber ports sind frei - sieht jedenfalls danach aus. Bzw, warum funktioniert dann der Zugriff auf andere REchner/Server über RDP ? nutzen alle den gleichen Port Danke