8
Nach August-Updates: RDP zu Server 2008 verhält sich anders
...und zwar (man muss nun genau lesen): nutzt man ein gesondertes Konto, um sich per RDP mit einem Server 2008 zu verbinden, das nicht das Recht hat, sich lokal an der eigenen Workstation anzumelden, dann erhält man die Meldung, dass sich dieses Konto wegen Logonbeschränkunden nicht anmelden darf.
Grund: ein Patch hat NLA verschärft und somit wird geprüft, ob sich das Konto am Client anmelden darf. Ist dies nicht der Fall, muss man das Konto dazu berechtigen.
Nochmal ohne "Juristendeutsch": wer seit den letzten Serverupdates nicht mehr per RDP auf Server 2008 kommt (vermutlich auch 2008 R2 betroffen), der muss das Konto, mit dem er sich verbindet, dazu berechtigen, sich am eigenen Client anzumelden.
Dieses Problem wird also nur sehr selten auftreten. Typischer Fall: Kollege X will Kollege Y am PC von Y zeigen, wie irgendwas im eigenen Profil (X) auf dem Server (Terminalserver) läuft und nutzt RDP dazu. X hat aber kein Anmelderecht für Y und darf deshalb neuerdings von Y aus auch keine Verbindung mehr zum Server aufbauen.
Immer noch nicht alle Klarheiten beseitigt? Dann lest https://social.technet.microsoft.com/Forums/windows/en-US/fab6f026-86c2- ... - Zitat Microsoft:
Grund: ein Patch hat NLA verschärft und somit wird geprüft, ob sich das Konto am Client anmelden darf. Ist dies nicht der Fall, muss man das Konto dazu berechtigen.
Nochmal ohne "Juristendeutsch": wer seit den letzten Serverupdates nicht mehr per RDP auf Server 2008 kommt (vermutlich auch 2008 R2 betroffen), der muss das Konto, mit dem er sich verbindet, dazu berechtigen, sich am eigenen Client anzumelden.
Dieses Problem wird also nur sehr selten auftreten. Typischer Fall: Kollege X will Kollege Y am PC von Y zeigen, wie irgendwas im eigenen Profil (X) auf dem Server (Terminalserver) läuft und nutzt RDP dazu. X hat aber kein Anmelderecht für Y und darf deshalb neuerdings von Y aus auch keine Verbindung mehr zum Server aufbauen.
Immer noch nicht alle Klarheiten beseitigt? Dann lest https://social.technet.microsoft.com/Forums/windows/en-US/fab6f026-86c2- ... - Zitat Microsoft:
The RDP client behaviour is changed in 8.1 and it now it enforces NLA which uses CREDSSP – it is more secure.
Previous behaviour is that it allowed fallback to “no NLA” when NLA failed.
If NLA is set to “required” on the RDP server side then it is expected that the client connection will fail due to the workstation not being in the list. NLA is using Kerberos or NTLM authentication which > cares about where you log on from as per above attribute. In addition if you take RDP out of the loop and browse to a share, for example, on the same RDP server from any OS workstation which is not in > the <log onto> list it will also fail with the same error STATUS_INVALID_WORKSTATION!.
Available options here:
1. Use this setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer", Default is 1 (SSL). -> Set this to 0.
2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0
3. Add the source server that the user is connecting to into the LogonTo field.
Previous behaviour is that it allowed fallback to “no NLA” when NLA failed.
If NLA is set to “required” on the RDP server side then it is expected that the client connection will fail due to the workstation not being in the list. NLA is using Kerberos or NTLM authentication which > cares about where you log on from as per above attribute. In addition if you take RDP out of the loop and browse to a share, for example, on the same RDP server from any OS workstation which is not in > the <log onto> list it will also fail with the same error STATUS_INVALID_WORKSTATION!.
Available options here:
1. Use this setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer", Default is 1 (SSL). -> Set this to 0.
2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0
3. Add the source server that the user is connecting to into the LogonTo field.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 312234
Url: https://administrator.de/knowledge/nach-august-updates-rdp-zu-server-2008-verhaelt-sich-anders-312234.html
Ausgedruckt am: 12.04.2025 um 23:04 Uhr
8 Kommentare
Neuester Kommentar
Ich weiß gar ncht was Du hast. Sofort mit dem ersten Satz war doch klar, was gemeint ist.
Wenn man sich nicht lokal mit einem Konto anmelden darf, darf man auch nicht mit diesem Konto per RDP von diesem Client aus auf den Server.
Dürfte imho wirklich nur in Ausnahmefällen zum problem werden.
lks
Ah, ich werde verstanden
Es ist nicht zu erwarten, dass es viele betrifft, nein. Aber die Jenigen dürften gerade wahnsinnig werden
Und dass MS sowas erst nach Jahren "reinpatcht", ist schon nicht so witzig. NLA war schließlich schon seit 2008 im Einsatz, lief aber 8 Jahre lang nicht so, wie es eigentlich gedacht war.
Es ist nicht zu erwarten, dass es viele betrifft, nein. Aber die Jenigen dürften gerade wahnsinnig werden
Und dass MS sowas erst nach Jahren "reinpatcht", ist schon nicht so witzig. NLA war schließlich schon seit 2008 im Einsatz, lief aber 8 Jahre lang nicht so, wie es eigentlich gedacht war.
1
Ich versuche das Szenario gerade im Kopf durchzuspielen um für kommende Probleme gewappnet zu sein. Bisher habe ich noch keine Probleme gehabt. Dieses Update könnte aber zum Problem bei uns werden...konkret geht es darum, dass einige externe Mitarbeiter und auch die Chefs über VPNs auf eine kleine TS-Farm (2008r2) zugreifen. Die jeweiligen Rechner sind nicht in der Domäne da es z.B. der private Rechner des Chefs ist. Zum einloggen auf dem TS nutzt er natürlich das Domänenkonto. Dieses wiederum ist logischerweise nicht zum anmelden an dem lokalen Rechner berechtigt...genau da müsste es doch nach diesem Update "krachen", richtig? Kann ich ein Domänen-Konto auf einem Rechner zum anmelden berechtigen der gar nicht in der Domäne ist??
Danke für die Antworten!
Danke für die Antworten!
Dazu musst du diese Konten überall anmeldeberechtigen, das ist auch schon der default.
Zitat von @DerWoWusste:
Dazu musst du diese Konten überall anmeldeberechtigen, das ist auch schon der default.
Dazu musst du diese Konten überall anmeldeberechtigen, das ist auch schon der default.
Sorry bin schwer von Begriff...inwiefern ist das der "default"? Anmeldeberechtigen heißt: einfach in die jeweiligen Dom-Benutzer in lokale Gruppe "Remotedesktopbenutzer" packen?
Nein, das AD-userobjekt hat die Erlaubnis, sich überall anzumelden schon per default. Bei uns trat das Problem nur auf, weil wir das verschärft hatten, also unter "anmelden an" nur ausgesuchte Rechner eingetragen haben.
Okay, aber die Rechner sind ja in meinem genannten Beispiel gar nicht in der AD.
Ich weiß. Das macht nichts. Wenn ein Nutzer sich überall anmelden darf, dann sind auch unbekannte Workstations mit drin.
