Frage an Kunden von Microsofts Premier Support

Hi.

Wozu schreibe ich, dass MS bestätigt hat, dass es ein Bug ist?
Folgendes Szenario (so erleben wir es): Kunde will auf unseren TS rauf, kann es aber nicht. Warum: weil der Domänennutzer, den wir dem Kunden eingerichtet haben sich eben nur am Terminalserver anmelden kann und nirgendwo sonst hier. Da die Kunden sich auch noch von ständig wechselnden Rechnern aus anmelden, bleibt nur, diesen Kunden das Recht "darf sich überall anmelden" einzuräumen. Toll, oder? Bei Server 2008 R2 braucht man das nicht.

Hi Dani.

Es ist nicht dringend. Soll ich dir eine genaue Beschreibung liefern? Ist super simpel, in jeder Domäne mit defaults sofort nachstellbar.

Danke

Noch simpler. Ob der Rechner, von dem man kommt in der Domäne ist oder nicht, ist egal.
Es geht nur um den Benutzer, den man für die Verbindung wählt. Wenn in dessen Nutzerobjekt im AD kein Anmelderecht am Client besteht, kommt er nicht auf den Server. Dies ging noch mit allen OS vor 2012/win 8.

Man kann es also genau so gut von z.B. win8.1 nach win8.1 nachstellen, man braucht keinen Terminalserver dazu, lediglich die Anmeldeberechtigung muss beschränkt sein.

@emeriks: doch. Wie gesagt, es hängt nur am Nutzerobjekt, nicht am Rechner, von dem die Verbindung ausgeht. Siehe auch https://social.technet.microsoft.com/Forums/windowsserver/en-US/f21e61ea ...

Doch, da könnte theoretisch alles stehen - nur eben nicht der Client von dem er kommt.
Das konkrete Problem hatte ich beschrieben (versucht zumindest): Kunde will per RDP (über VPN) auf unseren TS. Sein PC ist nicht in unserer Domäne und sein PC-Name ist ständig wechselnd und somit als unbekannt anzunehmen. Er trägt in den Verbindungseigenschaften der RDP-Verbindung einen Nutzer unserer Domäne ein, den wir ihm gestellt haben. Dieser Nutzer soll sich lediglich an unserem TS anmelden, somit steht im Nutzerobjekt nur der TS unter "anmelden an" und sonst nichts. Die Verbindung schlägt fehl. Wüsste ich den Namen des Kunden-PCs, könnte ich ihn vorsorglich unter "anmelden an" eintragen und es würde klappen. Ebenso würde es ohne Anpassungen klappen, wenn der Server 2008R2 oder frühere OS inne hätte.

Oder, Beispiel ohne TS, aber "inhouse": Kollege A ist bei Kollege B im Büro (A und B interne Nutzer an Domänenclients mit Win8.1). A will B etwas zeigen und möchte dazu per RDP auf seinen eigenen PC zugreifen. A startet auf PC B den RDP-Client, gibt seine Anmeldedaten ein...und die Verbindung schlägt fehl, da sich A nicht an B's Rechner anmelden darf.

Würden diese PCs mit Win7 laufen, würde die Verbindung ohne Weiteres gelingen.

Edit: nochmal A und b im letzten Satz getauscht... ist aber auch verwirrend

Ich habe für Server 12 keine Software-Assurance, deswegen habe ich den MSDN-Support genommen. Welche Teams dahinterstecken, keine Ahnung, jedenfalls waren die unfassbar langsam. Ständig habe ich nachgebohrt, nur damit die mir nach 6 Wochen bestätigen "ja ist ein Bug" und "nein, wir haben keine Lösung". Besteht übrigens auch in win10 preview und ist per feedback schon mitgeteilt.

Moin Dani, gibt's Schon eine Reaktion von den Premieres?

Ich danke Dir!

Wow, also braucht auch der Premier Support 10 Tage um einen Bug zu bestätigen, den jeder in 5 Minuten nachstellen kann.
Für das Bestätigen hat der MSDN-Support noch wesentlich länger gebraucht, über 4 Wochen, um dann nach 6 Wochen zu erklären, sie könnten nichts dagegen tun, weil zu aufwendig. Na, ich bin gespannt, ob vor Weihnachten noch etwas passiert. Danke.

Ist Thomas eigentlich schon im Weihnachtsurlaub?

Hi.

hatten Sie mir auch vorgeschlagen, den zu entfernen (es hat auch keinen Effekt, auch wenn Microsoft das erzählt), ebenso die TLS-Verschlüsselung ganz auszuschalten... super Idee ;-|

Moin Dani.

Gibt es was Neues?

Ui... das nennt sich wirklich premier support? Ich wette, sie werden keine Lösung bieten nachdem sie weder 6 Wochen verstreichen lassen, genau wie beim MSDN-Support.

MIcrosoft hat mir gegenüber Ihre eigene Aussage "Es ist ein Bug" widerrufen und auf "es ist ein feature" geändert.
Das soll so, damit man sich tüchtig ärgert.
Nee, sie gesagt, dass (ich zitiere mich aus dem technet-Forum):
--
You gotta love Microsoft... read this...
I had this problem. Used MSDN support. After 9 weeks they told me "it is a bug, but we don't have the resources to fix it". They told me "maybe MS premier support can do something for you" Me: "how much" - MSDN: "15,000 euros per year at least" - Me "*gulp*"
So I asked a befriended admin (Hi Dani) who happens to have a premier support contract to have them work on it... after (you gessed right) another 9 weeks, MS told me: "this is expected behavior, it is by design". To quote the engineers:

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.
Ain't that cute? So it's been no bug all the way. Win7 and Server 2008R2 are the systems with buggy/insecure behavior... LOOL. So I had him tell them the following: "Dear Support,
thank you, it seems there is no easy way out. Either we reduce the security one way or the other.
Let's recapitulate: After all this time you found out, it's expected behavior and call it more secure than with previous versions.
I see the point, but for the use case of users remoting in to our terminalserver ("TS") from different workstations at a remote location/remote company that we don't know the name of, this is actually less secure than before.
Why do I see it this way? Because the check that is performed (->may the user log on from this workstation?) can be easily overcome. The check just looks at the name of the machine, not even does that machine need to be a member of our domain. So if someone knows, he can easily overcome that check by renaming his machine to an already allowed machine so that restriction is pretty useless in this case. It cannot be used to limit the user to use a set of known machines to connect *from* as we don't even know those machines in the first place, they are not members of our domain but of a remote domain, another company. They logon to their machines using User A and logon to ours using user B, only B is a member of our domain.There isn't and never will be a domain trust.

So instead of using your proposed workarounds of which 1 and 2 reduce the security and 3 is not possible since we do not know the names of the machines that will be used in the future (but we only know the username), we will stick with our workaround and allow that users' accounts to logon anywhere (which is most undesirable!). To get back some security, we applied policies that disallow the logon to any system but the TS via GPO. And we applied firewall policies at the TS that won't let him get anywhere.

Conclusion: The "workstations allowed" list has its use case: limiting it, you can keep people away from logging on *to* machines so they cannot influence or spy on these systems. However, from what we have here, from the perspective of a TS, limiting what machines a user can connect *from* is not beneficial for security, in the end, quite the contrary is the case. Do me a favor and reconsider!"
They have not answered so far. maybe in another 9 weeks, maybe never? My guess is "never".