9
Anmeldung an Domäne über RDP nicht möglich wenn Kennwortänderung verlang wird
Gegeben ist: Windows Server 2008 R2 als DC und TS konfiguriert. Windows 7 SP1 64Bit Client der über Internet via RDP bzw. RemoteApp auf den Server zugreift und sich zur Authentifizierung als ein Domänenbenutzer anmeldet.
Hallo,
wenn wie oben angerissen ein User z.B. via RDP auf den TS Server zugreifen will und bei dem Domainuser mit dem er sich am Server anmeldet das Flag "Benutzer muss das Kennwort bei nächster Anmeldung ändern" aktiviert ist, kommt auf Clientseite immer folgende Fehlermeldung:
Remotedesktopverbindung
Authentifizierungsfehler.
Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar.
Remotecomputer: xxxxxxxxxxxxx.org
OK
Ist die Kennwortänderung nicht gesetzt geht alles!
Woran liegt das?
Vielen Dank,
Wolfgang
Hallo,
wenn wie oben angerissen ein User z.B. via RDP auf den TS Server zugreifen will und bei dem Domainuser mit dem er sich am Server anmeldet das Flag "Benutzer muss das Kennwort bei nächster Anmeldung ändern" aktiviert ist, kommt auf Clientseite immer folgende Fehlermeldung:
Remotedesktopverbindung
Authentifizierungsfehler.
Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar.
Remotecomputer: xxxxxxxxxxxxx.org
OK
Ist die Kennwortänderung nicht gesetzt geht alles!
Woran liegt das?
Vielen Dank,
Wolfgang
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: 187412
Url: https://administrator.de/forum/anmeldung-an-domaene-ueber-rdp-nicht-moeglich-wenn-kennwortaenderung-verlang-wird-187412.html
Ausgedruckt am: 22.12.2024 um 13:12 Uhr
9 Kommentare
Neuester Kommentar
Wenn ich das nachvollziehe mit einem aktuellen RDP-Client (6.1, wie bei Dir auch) bekomme ich lokal die Meldung "You must change your password before logging in for the first time. For assistance, contact your system administrator or technical support."
Ist ein Bug.
Mit dieser Meldung findet man schnell http://support.microsoft.com/kb/2648402/en-us?sd=rss&spid=14134
Ist ein Bug.
Mit dieser Meldung findet man schnell http://support.microsoft.com/kb/2648402/en-us?sd=rss&spid=14134
Hallo,
Eben. Was enthälst du uns an Informationen um dein problem zu Lösen?
DC = TS. Ist ein NoGo und sollte auch die bekannt sein.
RDP per Internet = ist ein weiteres NoGo. Stellt eueren DC mit installiertem TS doch gleich draussen auf die Strasse.
Was ist mit VPN?
Wer macht (wenn vorhanden) den VPN Server / Endpunckt?
Was ist mit evtl. Routen für das VPN?
Welche Clients werden für VPN benötigt?
Welche Ports sind für dein RDP per Internet geöffnet und wohin weitergeleitet?
Gibt es weitere geöffnete Ports?
Hast du mal mit einem Sniffer (MS NetworkMonitor oder Wireshark) geschaut welche Ports denn beim ändern einen Benutzerpassworts benötigt werden? Sind diese denn auch errreichbar von seitens des Clients der RDP per Internet macht? (VPN doch diese bessere Alternative?)
Mal hier http://technet.microsoft.com/pt-pt/library/dd772723(v=ws.10).aspx lesen.
Gruß,
Peter
Eben. Was enthälst du uns an Informationen um dein problem zu Lösen?
DC = TS. Ist ein NoGo und sollte auch die bekannt sein.
RDP per Internet = ist ein weiteres NoGo. Stellt eueren DC mit installiertem TS doch gleich draussen auf die Strasse.
Was ist mit VPN?
Wer macht (wenn vorhanden) den VPN Server / Endpunckt?
Was ist mit evtl. Routen für das VPN?
Welche Clients werden für VPN benötigt?
Welche Ports sind für dein RDP per Internet geöffnet und wohin weitergeleitet?
Gibt es weitere geöffnete Ports?
Hast du mal mit einem Sniffer (MS NetworkMonitor oder Wireshark) geschaut welche Ports denn beim ändern einen Benutzerpassworts benötigt werden? Sind diese denn auch errreichbar von seitens des Clients der RDP per Internet macht? (VPN doch diese bessere Alternative?)
Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar.
Mal geschaut was sich bei deinem DC dahinter verbirgt und welche Ports dazu benötigt werden?Mal hier http://technet.microsoft.com/pt-pt/library/dd772723(v=ws.10).aspx lesen.
Woran liegt das?
Falsches Netzdesign zur Anbindung Externer Clients und gleichzeitigem DC=TS?Gruß,
Peter
Danke erst einmal für eure schnellen Antworten.
DerWoWusste, ich erhalte zwar eine andere Fehlermeldung und daher wird der Hotfix bei meinem Problem sicher nichts bringen. Aber es wird wohl nicht Schaden ihn dennoch einzuspielen - zumal ich ihn später wohl ohnehin benötigen werde, sobald ich das jetzige Problem behoben habe.
Was das vorenthalten von Informationen anbelangt Peter, so war dies nicht meine Absicht. Ich behaupte auch jetzt noch, dass ich alle wichtigen Infos zum Problem genannt habe. Alles weitere spielt, wenn überhaupt, nur marginal eine Rolle. Was hat zum Beispiel der Port mit dem Problem zu tun? Bei einer RDP Verbindung wird alles über einen Port gesendet - auch die Authentifizierung. Der Port ist auch offen und wie gesagt funktioniert auch alles, sofern ich nicht das "Kennwort ändern" Flag setze. Ich verstehe also nicht was ich da erst mit Wireshark nachforschen soll, wenn der Server doch erreicht werden kann (worauf selbst die Fehlermeldung hinweist). Des weiteren kann ich nicht nachvollziehen was VPN konkret mit meinem Problem zu tun hat? Natürlich wäre VPN besser und ich weiß auch dass ein TS nicht gleichzeitig ein DC und umgekehrt sein sollte (wird doch sogar oft genug beim Konfigurieren hingewiesen). Aber mein Kunde (kleine Firma) verlangt trotz Warnung meinerseits, weiterhin diese günstigere Alternative. Für VPN wäre zusätzliche Hardware nötig gewesen und für einen getrennten TS/DC ebenfalls. Ich habe ähnliche Konfigurationen schon bei anderen im Einsatz - bis auf den RDP Bug ohne Probleme. Was mich allerdings noch interessieren würde; warum soll RDP über Internet (vorausgesetzt man konfiguriert es nicht falsch) so ein "NoGo" sein?
Vielen Dank,
Wolfgang
DerWoWusste, ich erhalte zwar eine andere Fehlermeldung und daher wird der Hotfix bei meinem Problem sicher nichts bringen. Aber es wird wohl nicht Schaden ihn dennoch einzuspielen - zumal ich ihn später wohl ohnehin benötigen werde, sobald ich das jetzige Problem behoben habe.
Was das vorenthalten von Informationen anbelangt Peter, so war dies nicht meine Absicht. Ich behaupte auch jetzt noch, dass ich alle wichtigen Infos zum Problem genannt habe. Alles weitere spielt, wenn überhaupt, nur marginal eine Rolle. Was hat zum Beispiel der Port mit dem Problem zu tun? Bei einer RDP Verbindung wird alles über einen Port gesendet - auch die Authentifizierung. Der Port ist auch offen und wie gesagt funktioniert auch alles, sofern ich nicht das "Kennwort ändern" Flag setze. Ich verstehe also nicht was ich da erst mit Wireshark nachforschen soll, wenn der Server doch erreicht werden kann (worauf selbst die Fehlermeldung hinweist). Des weiteren kann ich nicht nachvollziehen was VPN konkret mit meinem Problem zu tun hat? Natürlich wäre VPN besser und ich weiß auch dass ein TS nicht gleichzeitig ein DC und umgekehrt sein sollte (wird doch sogar oft genug beim Konfigurieren hingewiesen). Aber mein Kunde (kleine Firma) verlangt trotz Warnung meinerseits, weiterhin diese günstigere Alternative. Für VPN wäre zusätzliche Hardware nötig gewesen und für einen getrennten TS/DC ebenfalls. Ich habe ähnliche Konfigurationen schon bei anderen im Einsatz - bis auf den RDP Bug ohne Probleme. Was mich allerdings noch interessieren würde; warum soll RDP über Internet (vorausgesetzt man konfiguriert es nicht falsch) so ein "NoGo" sein?
Vielen Dank,
Wolfgang
Hallo!
Ich würde den Hotfix auf jeden Fall einspielen. Habe es so eben getan und das Problem ist damit behoben worden. Kein Neustart nötig!
Serverseitig (2008R2 multilingual): 1
Clientseitig (win7 x64 multilingual): 2
Was wieder super von MS ist: andere OS werden gar nicht berücksichtigt, dabei hat Vista das Problem auch, vermutlich ebenso 2008 Server.
Edit: Linkschreibweise korrigiert
Ich würde den Hotfix auf jeden Fall einspielen. Habe es so eben getan und das Problem ist damit behoben worden. Kein Neustart nötig!
Serverseitig (2008R2 multilingual): 1
Clientseitig (win7 x64 multilingual): 2
Was wieder super von MS ist: andere OS werden gar nicht berücksichtigt, dabei hat Vista das Problem auch, vermutlich ebenso 2008 Server.
Edit: Linkschreibweise korrigiert
Danke für die Direktlinks! Dass MS sich bei nicht Sicherheitskritischen Updates in erster Linie nur um seine aktuellen und Enterprise-Produkte kümmert ist in der Tat ein weiterer Kritikpunkt. Ich wollte den Hotfix eben einspielen. Auf Windows 7 funktionierte es wunderbar - auf dem Server dagegen kommt folgende Fehlermeldung:
Eigenständiges Windows Update-Installationsprogramm
Das Update ist nicht für Ihren Computer geeignet.
OK
Ich hatte vorhin leider vergessen zu erwähnen dass es sich bei dem Windows Server 2008 R2 um die Foundation Version handelt. Da wird bei MS wohl bei den Updates auch nochmal unterschieden...
Wolfgang
Eigenständiges Windows Update-Installationsprogramm
Das Update ist nicht für Ihren Computer geeignet.
OK
Ich hatte vorhin leider vergessen zu erwähnen dass es sich bei dem Windows Server 2008 R2 um die Foundation Version handelt. Da wird bei MS wohl bei den Updates auch nochmal unterschieden...
Wolfgang
Ich glaube nicht, dass Foundation andere Updates bekommt. Ich habe noch kein Foundation-only Update gesehen.
Das Update ist für R2 mit SP1 - fehlt Dir das SP1? Und hast Du wirklich Link "1" genommen?
Das Update ist für R2 mit SP1 - fehlt Dir das SP1? Und hast Du wirklich Link "1" genommen?
Hallo,
Ja. Für RDP. Ist klar.
Also entweder es geht (und ist unsicher) oder es geht nicht (und ist sicher)
Gruß,
Peter
Ja. Für RDP. Ist klar.
- auch die Authentifizierung.
Ja. Die für den RDP Server.sofern ich nicht das "Kennwort ändern" Flag setze.
Und du bist dir sicher das dasDie lokale Sicherheitsautorität (LSA) ist nicht erreichbar
ausschließlich über Port 3389 erfolgt? LSA = Port 445. Also kann entweder dein Client den LSA nicht erreichen, oder dein TS kann den LSA (der DC auf dem der TS selbst läuft) nicht erreichen. Such es dir aus.Für VPN wäre zusätzliche Hardware nötig
Nein. Wenn es schon so gefordert (Kunde) wird das es nichts Kosten darf, dann nimm deinen vorhanden VPN Server. Dein Server 2008R2 kann sehr wohl als VPN Server dienen. Er kann dir sogar das PPTP zur verfügung stellen und fast alle Clients dieser Welt haben einen PPTP Client eingebaut. Das kosten genau 0 Euro in der Anschaffung. Es wird nur das GRE Protokoll und Port TCP 1723 genutzt. Fast alle Router können das weiterleiten. Uns selbst aus einem Mobilnetz ist ein PPTP erver erreichbar. Natürlich sind starke Passwörter vonnöten, aber die brauchst du bei einem offenen RDP (3389) noch mehr.(vorausgesetzt man konfiguriert es nicht falsch)
Funktioniert den ein Falsch konfiguriertes RDP? Also entweder es geht (und ist unsicher) oder es geht nicht (und ist sicher)so ein "NoGo" sein?
Leicht zu erraten was sich dahinter verbirgt? Somit schon bakannt wo mit welchen Werkzeugen angesetzt werden muss? Da ist selbst das PPTP tausendfach sicherer. Selbstverständlich alles abhängig einer Passwortstrategie).Gruß,
Peter
So, noch was: teste bitte, ob es nicht reicht, das Update 2 clientseitig zu installieren. Warum? Weil ich hier ebenso auf einem Server (2008 R2 Standard mit SP1) die Meldung bekomme, dass es nicht anwendbar ist. Dennoch kann ich mich nach dem Installieren des Clientpatches nun verbinden, um das Kennw. zu ändern - ging vorher nicht. Somit wird der Server-Patch wohl nur unter bestimmten Randumständen überhaupt gebraucht, siehe http://support.microsoft.com/kb/2648402 - offenbar nur bei NLA, das unterschied auch unsere beiden TS hier.
Ja, am dem Server läuft konkret Windows Server 2008 R2 Foundation mit SP1 - ist also aktuell! Ich habe es nun schon zum 3. mal mit Link 1 versucht und kann somit ausschließen dass ich den falschen Link angeklickt habe.
Das mag schon stimmen aber die Router die bisher eingesetzt werden bieten kaum Konfigurationsmöglichkeiten und ich bin bisher immer der Ansicht gewesen wenn schon VPN zwischen 2 Außenstellen über Internet, dann sollten dies die beiden Router übernehmen. Einer der beiden Internetanschlüsse ist auch keine Standleitung und ich habe bisher immer schlechte Erfahrungen mit reinen Softwarelösungen auf Windowsebene gemacht, wenn eine 24-Stunden-Trennung eintrat. Mag sein dass ich dann etwas falsch gemacht habe. Aber ich habe mich dann nicht mehr weiter damit beschäftigt und blieb bei meiner bevorzugten Methode mit den 2 VPN-Routern. So viel kosten die ja nicht aber der Kunde ist eben König.
Edit:
Dass hatte ich mir dann auch gedacht und wie gesagt habe ich auf dem Client den Hotfix problemlos installieren können. Leider kommt noch immer besagte Fehlermeldung beim aufbauen der RDP Verbindung. Es scheint sich also wie vermutet, offensichtlich um ein anderes Problem zu handeln. Port 445 ist durchgängig und scheidet daher auch aus. Ich werde wenn ich morgen beim Kunden vor Ort bin noch einmal genauer Prüfen woran es liegt. Sollte noch jemand einen Tipp haben, wäre ich dankbar. Ansonsten danke noch einmal für die bisherige Hilfe!
Viele Grüße,
Wolfgang
Nein. Wenn es schon so gefordert (Kunde) wird das es nichts Kosten darf, dann nimm deinen vorhanden VPN > Server. Dein Server 2008R2 kann sehr wohl als VPN Server dienen. Er kann dir sogar das PPTP zur verfügung > stellen und fast alle Clients dieser Welt haben einen PPTP Client eingebaut. Das kosten genau 0 Euro in der > Anschaffung. Es wird nur das GRE Protokoll und Port TCP 1723 genutzt. Fast alle Router können das weiterleiten. > Uns selbst aus einem Mobilnetz ist ein PPTP erver erreichbar. Natürlich sind starke Passwörter vonnöten, aber > die brauchst du bei einem offenen RDP (3389) noch mehr.
Das mag schon stimmen aber die Router die bisher eingesetzt werden bieten kaum Konfigurationsmöglichkeiten und ich bin bisher immer der Ansicht gewesen wenn schon VPN zwischen 2 Außenstellen über Internet, dann sollten dies die beiden Router übernehmen. Einer der beiden Internetanschlüsse ist auch keine Standleitung und ich habe bisher immer schlechte Erfahrungen mit reinen Softwarelösungen auf Windowsebene gemacht, wenn eine 24-Stunden-Trennung eintrat. Mag sein dass ich dann etwas falsch gemacht habe. Aber ich habe mich dann nicht mehr weiter damit beschäftigt und blieb bei meiner bevorzugten Methode mit den 2 VPN-Routern. So viel kosten die ja nicht aber der Kunde ist eben König.
Edit:
Zitat von @DerWoWusste:
So, noch was: teste bitte, ob es nicht reicht, das Update 2 clientseitig zu installieren. Warum? Weil ich hier ebenso auf einem
Server (2008 R2 Standard mit SP1) die Meldung bekomme, dass es nicht anwendbar ist. Dennoch kann ich mich nach dem Installieren
des Clientpatches nun verbinden, um das Kennw. zu ändern - ging vorher nicht. Somit wird der Server-Patch wohl nur unter
bestimmten Randumständen überhaupt gebraucht, siehe http://support.microsoft.com/kb/2648402 - offenbar nur bei NLA, das
unterschied auch unsere beiden TS hier.
So, noch was: teste bitte, ob es nicht reicht, das Update 2 clientseitig zu installieren. Warum? Weil ich hier ebenso auf einem
Server (2008 R2 Standard mit SP1) die Meldung bekomme, dass es nicht anwendbar ist. Dennoch kann ich mich nach dem Installieren
des Clientpatches nun verbinden, um das Kennw. zu ändern - ging vorher nicht. Somit wird der Server-Patch wohl nur unter
bestimmten Randumständen überhaupt gebraucht, siehe http://support.microsoft.com/kb/2648402 - offenbar nur bei NLA, das
unterschied auch unsere beiden TS hier.
Dass hatte ich mir dann auch gedacht und wie gesagt habe ich auf dem Client den Hotfix problemlos installieren können. Leider kommt noch immer besagte Fehlermeldung beim aufbauen der RDP Verbindung. Es scheint sich also wie vermutet, offensichtlich um ein anderes Problem zu handeln. Port 445 ist durchgängig und scheidet daher auch aus. Ich werde wenn ich morgen beim Kunden vor Ort bin noch einmal genauer Prüfen woran es liegt. Sollte noch jemand einen Tipp haben, wäre ich dankbar. Ansonsten danke noch einmal für die bisherige Hilfe!
Viele Grüße,
Wolfgang
