9
RDP Benutzer werden automatisch im Active Directory gesperrt
Hallo,
wir haben in unserem Unternehmen Personen , welche über ein Port Forwarding zugriff auf ihre Rechner im Büro von zu hause aus haben.
Der Port ist nach aussen hin 5 stellig und mapped auf den RDP Port des Bürorechners, also es wird normales source NAT betrieben.
Sobald sich die Person dann per RDP eingeloggt hat, wird sie plötzlich im Active Directory gesperrt, weil 3 mal falsches Passwort. Dies passiert allerdings erst nach einer gewissen Zeit.
Nachdem ich dann die Accounts wieder entsperre gehts von vorne los.
Die Passwörter werden auf jedenfalls immer richtig eingegeben. Daher die frage: Welche instanz ist denn da im hintergrund? Es ist einmal ein Windows 10 und einemal ein Windows 7 PC also nicht vom BS abhängig.
Ist euch da etwas bekannt, dass solche Bugs auftreten? Bzw könnt mir hier weiterhelfen um dem Rätsel auf die sprünge zu kommen.
danke schonmal
wir haben in unserem Unternehmen Personen , welche über ein Port Forwarding zugriff auf ihre Rechner im Büro von zu hause aus haben.
Der Port ist nach aussen hin 5 stellig und mapped auf den RDP Port des Bürorechners, also es wird normales source NAT betrieben.
Sobald sich die Person dann per RDP eingeloggt hat, wird sie plötzlich im Active Directory gesperrt, weil 3 mal falsches Passwort. Dies passiert allerdings erst nach einer gewissen Zeit.
Nachdem ich dann die Accounts wieder entsperre gehts von vorne los.
Die Passwörter werden auf jedenfalls immer richtig eingegeben. Daher die frage: Welche instanz ist denn da im hintergrund? Es ist einmal ein Windows 10 und einemal ein Windows 7 PC also nicht vom BS abhängig.
Ist euch da etwas bekannt, dass solche Bugs auftreten? Bzw könnt mir hier weiterhelfen um dem Rätsel auf die sprünge zu kommen.
danke schonmal
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 514171
Url: https://administrator.de/contentid/514171
Printed on: April 16, 2024 at 11:04 o'clock
9 Comments
Latest comment
Moin 
Um zu sehen, wie das Konto von wo gesperrt worden ist, musst Du halt mal die Protokolle durchforsten. Oder mal alternativ ein Tool wie z.B. den lockout examiner bemühen.
Mir wird gerade schlecht... Als erstes würde ich mal auf ein vernünftiges Design setzen. NAT auf die Rechner im Firmen-LAN?? Egal ob Du die Ports in höhere Sphären schiebst - das nützt nichts - sicherheitstechnisch eine Sache aus der Kategorie "katastrophal"...
Gruß
Um zu sehen, wie das Konto von wo gesperrt worden ist, musst Du halt mal die Protokolle durchforsten. Oder mal alternativ ein Tool wie z.B. den lockout examiner bemühen.
(...) welche über ein Port Forwarding zugriff auf ihre Rechner im Büro von zu hause aus haben (...)
Mir wird gerade schlecht... Als erstes würde ich mal auf ein vernünftiges Design setzen. NAT auf die Rechner im Firmen-LAN?? Egal ob Du die Ports in höhere Sphären schiebst - das nützt nichts - sicherheitstechnisch eine Sache aus der Kategorie "katastrophal"...
Gruß
1
Zitat von @aif-get:
Hallo,
wir haben in unserem Unternehmen Personen , welche über ein Port Forwarding zugriff auf ihre Rechner im Büro von zu hause aus haben.
Der Port ist nach aussen hin 5 stellig und mapped auf den RDP Port des Bürorechners, also es wird normales source NAT betrieben.
Sobald sich die Person dann per RDP eingeloggt hat, wird sie plötzlich im Active Directory gesperrt, weil 3 mal falsches Passwort. Dies passiert allerdings erst nach einer gewissen Zeit.
Nachdem ich dann die Accounts wieder entsperre gehts von vorne los.
Die Passwörter werden auf jedenfalls immer richtig eingegeben. Daher die frage: Welche instanz ist denn da im hintergrund? Es ist einmal ein Windows 10 und einemal ein Windows 7 PC also nicht vom BS abhängig.
Ist euch da etwas bekannt, dass solche Bugs auftreten? Bzw könnt mir hier weiterhelfen um dem Rätsel auf die sprünge zu kommen.
danke schonmal
Hallo,
wir haben in unserem Unternehmen Personen , welche über ein Port Forwarding zugriff auf ihre Rechner im Büro von zu hause aus haben.
Der Port ist nach aussen hin 5 stellig und mapped auf den RDP Port des Bürorechners, also es wird normales source NAT betrieben.
Sobald sich die Person dann per RDP eingeloggt hat, wird sie plötzlich im Active Directory gesperrt, weil 3 mal falsches Passwort. Dies passiert allerdings erst nach einer gewissen Zeit.
Nachdem ich dann die Accounts wieder entsperre gehts von vorne los.
Die Passwörter werden auf jedenfalls immer richtig eingegeben. Daher die frage: Welche instanz ist denn da im hintergrund? Es ist einmal ein Windows 10 und einemal ein Windows 7 PC also nicht vom BS abhängig.
Ist euch da etwas bekannt, dass solche Bugs auftreten? Bzw könnt mir hier weiterhelfen um dem Rätsel auf die sprünge zu kommen.
danke schonmal
Moin
Ist ja auch kein Wunder . Wenn ich mir so die Logs unserer Firewall angucke , versuchen immer dubiose IPs einen Portscan auf unsere öffentliche IP's. Das wird bei dir auch so sein . Schalte den Müll schnellstens ab und richte eine gescheite Lösung ein . IPsec oder SSL VPN mit entsprechenden Firewallregeln. Besser noch . Die Mitarbeiter können nur mit vorbereiteten gesicherten Geräten ins VPN.
Was du aktuell machst , ist mit das dümmste was man machen kann um den Zugriff von außen zu lösen.
Gruss
1
moin...
Der Port ist nach aussen hin 5 stellig und mapped auf den RDP Port des Bürorechners, also es wird normales source NAT betrieben.
egal... cat9 raus, und bluten....... sowas wir über ein VPN gemacht!
Sobald sich die Person dann per RDP eingeloggt hat, wird sie plötzlich im Active Directory gesperrt, weil 3 mal falsches Passwort. Dies passiert allerdings erst nach einer gewissen Zeit.
ja... da wird wohl "jemand" zugriff wollen.... wozu war noch gleich das VPN ?
Nachdem ich dann die Accounts wieder entsperre gehts von vorne los.
mach das nicht...
Die Passwörter werden auf jedenfalls immer richtig eingegeben. Daher die frage: Welche instanz ist denn da im hintergrund? Es ist einmal ein Windows 10 und einemal ein Windows 7 PC also nicht vom BS abhängig.
das ist egal...
Ist euch da etwas bekannt, dass solche Bugs auftreten? Bzw könnt mir hier weiterhelfen um dem Rätsel auf die sprünge zu kommen.
der Bug liegt beim Design.... mit VPN passiert sowas nicht
danke schonmal
gerne....
Frank
Zitat von @aif-get:
Hallo,
wir haben in unserem Unternehmen Personen , welche über ein Port Forwarding zugriff auf ihre Rechner im Büro von zu hause aus haben.
das gehört bestraft....Hallo,
wir haben in unserem Unternehmen Personen , welche über ein Port Forwarding zugriff auf ihre Rechner im Büro von zu hause aus haben.
Der Port ist nach aussen hin 5 stellig und mapped auf den RDP Port des Bürorechners, also es wird normales source NAT betrieben.
Sobald sich die Person dann per RDP eingeloggt hat, wird sie plötzlich im Active Directory gesperrt, weil 3 mal falsches Passwort. Dies passiert allerdings erst nach einer gewissen Zeit.
Nachdem ich dann die Accounts wieder entsperre gehts von vorne los.
Die Passwörter werden auf jedenfalls immer richtig eingegeben. Daher die frage: Welche instanz ist denn da im hintergrund? Es ist einmal ein Windows 10 und einemal ein Windows 7 PC also nicht vom BS abhängig.
Ist euch da etwas bekannt, dass solche Bugs auftreten? Bzw könnt mir hier weiterhelfen um dem Rätsel auf die sprünge zu kommen.
danke schonmal
Frank
Danke, für die Kommentare schonmal
Aber wir lösen vieles schön mit VPN. Ob dies wirklich sinnig ist per RDP zu lösen und Löcher in die FW zu bohren sei erstmal dahingestellt...
Mich würde jetzt aber erstmal interessieren, weshlab ausgerechnet bei dem aktiven Aufbau der RDP-Session dieses Problem erst auftritt?
Logisch ist das nicht.
User baut auf RDP Port 63564, kurz dannach User im AD gesperrt.
Sonst keinerlei Problem.
Man könnte annehmen dass dort irgendeine Malware steckt , aber dies passiert bei einem anderen Rechner ebenfalls, der frisch aufgesetzt wurde.
Ist dies eher einen Designproblem von Windows beim RDP Handshake?
Aber wir lösen vieles schön mit VPN. Ob dies wirklich sinnig ist per RDP zu lösen und Löcher in die FW zu bohren sei erstmal dahingestellt...
Mich würde jetzt aber erstmal interessieren, weshlab ausgerechnet bei dem aktiven Aufbau der RDP-Session dieses Problem erst auftritt?
Logisch ist das nicht.
User baut auf RDP Port 63564, kurz dannach User im AD gesperrt.
Sonst keinerlei Problem.
Man könnte annehmen dass dort irgendeine Malware steckt , aber dies passiert bei einem anderen Rechner ebenfalls, der frisch aufgesetzt wurde.
Ist dies eher einen Designproblem von Windows beim RDP Handshake?
Ihr nutzt also schon VPN und hängt das RDP Protokoll dennoch frei ins Netz ? Na dann ...
Zitat von @itisnapanto:
Ihr nutzt also schon VPN und hängt das RDP Protokoll dennoch frei ins Netz ? Na dann ...
Ihr nutzt also schon VPN und hängt das RDP Protokoll dennoch frei ins Netz ? Na dann ...
habe ich mir auch so gedacht....
Frank
Moin
Wenn Du dich fragst, weshalb das Konto gesperrt ist, habe ich oben schon auf die Protokolle hingewiesen. Und auf die Möglichkeit, das auch über eine GUI zu betrachten: https://www.netwrix.com/account_lockout_examiner.html
Ansonsten: Mache das Design vernünftig und schaue, ob dann noch komische Dinge passieren.
Hubert
Wenn Du dich fragst, weshalb das Konto gesperrt ist, habe ich oben schon auf die Protokolle hingewiesen. Und auf die Möglichkeit, das auch über eine GUI zu betrachten: https://www.netwrix.com/account_lockout_examiner.html
Ansonsten: Mache das Design vernünftig und schaue, ob dann noch komische Dinge passieren.
Hubert
als allererstes richtet man ein zentrales Audit für Logins in der Domäne an den DCs ein, sonst findet man das nie ... aber wer das nicht hat findet den Grund für die Sperrung garantiert im Sicherheits-Reiter unterhalb der Windows Protokolle im Ereignisprotokoll der einzelnen Rechner, auf denen sich die Leute einloggen wollten.
Wir hatten das z.B. mal daß ein zu komplexes Paßwort zu NTLM Negotiation-fehlern führte, was der Rechner als fehlgeschlagenen Loginversuch interpretiert hat. Und nach 10 Versuchen war das Konto gesperrt, bzw. beim aif-get ist der lockout counter per GPO auf 3 eingestellt (ohne GPO ist das 10)
Wir hatten das z.B. mal daß ein zu komplexes Paßwort zu NTLM Negotiation-fehlern führte, was der Rechner als fehlgeschlagenen Loginversuch interpretiert hat. Und nach 10 Versuchen war das Konto gesperrt, bzw. beim aif-get ist der lockout counter per GPO auf 3 eingestellt (ohne GPO ist das 10)
Hallo, danke für die hinweise. Das grunddesign wird demnächst geändert. aber trotzdem will man ja solche fehler finden ;)
1. Das Eventlogger tool werde ich demnäöchst mal ausoprobieren und berichten.
2. NTLM Negotiation-fehler dachte ich zuerst auch, aber das einloggen hat funktioniert. Lediglich das es später probleme hab lässt drauf hinschliessen dass da nichts mit zu komplex hin deutet.
3. Wir haben noch einen zweiten DC der sich aber richtig mit dem dem anderen synchronisiert.
4. Ist hier eine analyse mit wireshark möglich? Wenn ja welche Filterregeln und Protokolle könenn am logischsten verwendet werden?
1. Das Eventlogger tool werde ich demnäöchst mal ausoprobieren und berichten.
2. NTLM Negotiation-fehler dachte ich zuerst auch, aber das einloggen hat funktioniert. Lediglich das es später probleme hab lässt drauf hinschliessen dass da nichts mit zu komplex hin deutet.
3. Wir haben noch einen zweiten DC der sich aber richtig mit dem dem anderen synchronisiert.
4. Ist hier eine analyse mit wireshark möglich? Wenn ja welche Filterregeln und Protokolle könenn am logischsten verwendet werden?