derwowusste
Goto Top

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:
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.

Content-Key: 312234

Url: https://administrator.de/contentid/312234

Ausgedruckt am: 19.03.2024 um 03:03 Uhr

Mitglied: Lochkartenstanzer
Lochkartenstanzer 10.08.2016 aktualisiert um 10:47:12 Uhr
Goto Top
Zitat von @DerWoWusste:

Immer noch nicht alle Klarheiten beseitigt?

Ich weiß gar ncht was Du hast. Sofort mit dem ersten Satz war doch klar, was gemeint ist. face-smile

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. face-smile

Dürfte imho wirklich nur in Ausnahmefällen zum problem werden.

lks
Mitglied: DerWoWusste
DerWoWusste 10.08.2016 um 11:00:24 Uhr
Goto Top
Ah, ich werde verstanden face-smile
Es ist nicht zu erwarten, dass es viele betrifft, nein. Aber die Jenigen dürften gerade wahnsinnig werden face-smile
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.
Mitglied: Philipp711
Philipp711 19.08.2016 um 18:40:04 Uhr
Goto Top
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!
Mitglied: DerWoWusste
DerWoWusste 19.08.2016 um 18:53:46 Uhr
Goto Top
Dazu musst du diese Konten überall anmeldeberechtigen, das ist auch schon der default.
Mitglied: Philipp711
Philipp711 20.08.2016 aktualisiert um 09:00:46 Uhr
Goto Top
Zitat von @DerWoWusste:

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?
Mitglied: DerWoWusste
DerWoWusste 20.08.2016 um 17:29:41 Uhr
Goto Top
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.
Mitglied: Philipp711
Philipp711 21.08.2016 um 09:46:25 Uhr
Goto Top
Okay, aber die Rechner sind ja in meinem genannten Beispiel gar nicht in der AD.
Mitglied: DerWoWusste
DerWoWusste 21.08.2016 um 16:05:22 Uhr
Goto Top
Ich weiß. Das macht nichts. Wenn ein Nutzer sich überall anmelden darf, dann sind auch unbekannte Workstations mit drin.