derwowusste
Goto Top

Frage an Kunden von Microsofts Premier Support

Grüße an alle Admins!

Nutzt jemand von Euch den Premier-Support?
Folgendes: Wir haben ein Problem mit Server2012/2012R2, welches der MSDN-Support als Bug bestätigt hat, aber nicht lösen mag, da zu aufwendig.
Wir wurden vom MSDN-Support darauf hingewiesen, dass der Premier-Support evtl. mehr für uns tun würde, wollen aber nicht Premier-Kunde werden, da zu teuer für unsere wenigen jährlichen Anfragen.

Sollte sich jemand freundlicherweise in der Lage sehen, diese Anfrage kostenlos in seinem Namen abzugeben, bitte melden - evtl. betrifft Euch das Problem ja auch.
Folgender Fehler: Server 2012 r2 prüft bei RDP-Verbindungen, von wo derTerminalnutzer kommt. Kommt er von einem Rechner, an dem er sich nicht lokal anmelden darf, lässt der Server keine Remotesitzung zu, obwohl der verwendete Nutzer sich am Server anmelden darf.
Das Problem fällt in vielen Umgebungen nicht auf, da sich jeder Domänennutzer per default überall anmelden darf. Erst wenn man dieses restriktiver setzt, bemerkt man es [wie gesagt: ein von Microsoft bestätigter Bug].

Content-Key: 256370

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

Ausgedruckt am: 29.03.2024 um 05:03 Uhr

Mitglied: emeriks
emeriks 01.12.2014 aktualisiert um 15:05:30 Uhr
Goto Top
Hi,
ich kann Dir zwar mit dem Support nicht helfen, aber ...
Folgender Fehler: Server 2012 r2 prüft bei RDP-Verbindungen, von wo derTerminalnutzer kommt. Kommt er von einem Rechner, an dem er sich nicht lokal anmelden darf, lässt der Server keine Remotesitzung zu, obwohl der verwendete Nutzer sich am Server anmelden darf.
... das betrachte ich nicht unbedingt als Bug. Wenn ich nicht will, dass UserA am PC17 arbeitet, dann will ich doch auch sicherlich nicht, dass UserB ihm einen Gefallen tut und sich lokal anmeldet, damit UserA dann von dort aus sich auf die TS schaltet. Da kann ich schon was Sinnvolles dran finden ...
Allerdings sollte man dieses Verhalten an- und abschalten können.
E.
Mitglied: DerWoWusste
DerWoWusste 01.12.2014 aktualisiert um 15:15:01 Uhr
Goto Top
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.
Mitglied: emeriks
emeriks 01.12.2014 um 15:23:18 Uhr
Goto Top
Ja, ist doof, keine Frage.
Ich meine doch nur, dass das u.U. auch ganz nützlich sein kann.
E.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 01.12.2014 um 17:08:11 Uhr
Goto Top
Zitat von @emeriks:

Ich meine doch nur, dass das u.U. auch ganz nützlich sein kann.

It's not a bug, it's a feature oder wie?

Imho ist das eindeutig ein Bug, weil der lokale Benuutzer nicht unbedingt der TS-User sein muß, z.B. erterne Mitarbeiter, die sich zwar per RDP üerb VPN verbinden dürfen, aber deren Kisten nicht in der Domain sind und sein dürfen.

@dww Leider kann ich Dir da nicht behilflich sein.

lks
Mitglied: Dani
Dani 01.12.2014 um 19:55:57 Uhr
Goto Top
Guten Abend @DerWoWusste,
Nutzt jemand von Euch den Premier-Support?
Jup. Wie drigend ist es? Ich bin nämlich die nächsten Tage kaum bis gar nicht im Büro.


Gruß,
Dani
Mitglied: emeriks
emeriks 01.12.2014 um 20:24:37 Uhr
Goto Top
Hi,
z.B. erterne Mitarbeiter, die sich zwar per RDP üerb VPN verbinden dürfen, aber deren Kisten nicht in der Domain sind und sein dürfen.
...was ein schlechtes Beispiel ist. So ein User wäre von diesem Fall gar nicht betroffen. face-wink

E.
Mitglied: DerWoWusste
DerWoWusste 01.12.2014 um 20:33:26 Uhr
Goto Top
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
Mitglied: Dani
Dani 01.12.2014 um 21:06:34 Uhr
Goto Top
Du hast einen Windows Server 2012R2 Standard als RDS-Host eingerichtet. Der zugreifende Rechner ist nicht Mitglied der Domäne. Beim Verbindungsaufbau über RDP gibt der Benutzer die Zugangsdaten eurer Domäne ein. Nach der Bestätigung kommt es zu dem beschriebenen Problem.

Habe ich das soweit richtig verstanden?
Eine genaue Beschreibung wäre natürlich genial für das Lab.


Gruß,
Dani
Mitglied: DerWoWusste
DerWoWusste 01.12.2014 um 21:27:11 Uhr
Goto Top
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 ...
Mitglied: Dani
Dani 01.12.2014 aktualisiert um 21:45:32 Uhr
Goto Top
Irgendwie steh ich grad auf dem Schlauch...
Wenn in dessen Nutzerobjekt im AD kein Anmelderecht am Client besteht
D.h. du hast im Active Directoy unter den Benutzereingeschaften -> Konto -> Anmelden an -> Folgende Computer ausgewählt und nichts eingetragen?!
Mitglied: DerWoWusste
DerWoWusste 01.12.2014 aktualisiert um 22:04:50 Uhr
Goto Top
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 face-smile
Mitglied: Dani
Dani 01.12.2014 um 22:01:07 Uhr
Goto Top
Jetzt hab's ich verstanden. face-smile
Ein Student wird das Morgen bei uns nachstellen und bei Microsoft einkippen.


Gruß,
Dani

P.S. Worin liegt eigentlich der Unterschied zwischen MSDN Support und dem technischen Support über Software Assurance?
Mitglied: DerWoWusste
DerWoWusste 01.12.2014 um 22:07:44 Uhr
Goto Top
Worin liegt eigentlich der Unterschied zwischen MSDN Support und dem technischen Support über Software Assurance?
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.
Mitglied: emeriks
emeriks 02.12.2014 um 08:50:09 Uhr
Goto Top
Hi,
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.
was exakt mein beschriebenes Beispiel ist (siehe oben), bei welchem ich mir in einigen Situationen durchaus vorstellen kann, dass das auch absolut sinnvoll sein könnte. face-wink

E.
Mitglied: DerWoWusste
DerWoWusste 05.12.2014 um 17:33:01 Uhr
Goto Top
Moin Dani, gibt's Schon eine Reaktion von den Premieres?
Mitglied: Dani
Dani 05.12.2014 aktualisiert um 18:48:20 Uhr
Goto Top
Moin @DerWoWusste,
das Support-Ticket mit der Fehlermeldung des RDS-Hosts ist offen.
Eine qualifizierte Antwort steht noch aus.


Gruß,
Dani
Mitglied: DerWoWusste
DerWoWusste 06.12.2014 um 00:08:35 Uhr
Goto Top
Ich danke Dir!
Mitglied: Dani
Dani 14.12.2014 aktualisiert um 23:22:56 Uhr
Goto Top
Moin @DerWoWusste,
der Bug ist bestätigt. face-smile Aktuell wird der Case mit der Fachabteilung besprochen.


Gruß,
Dani
Mitglied: DerWoWusste
DerWoWusste 15.12.2014 aktualisiert um 07:44:47 Uhr
Goto Top
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.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 15.12.2014 um 10:02:26 Uhr
Goto Top
Zitat von @DerWoWusste:

Na, ich bin gespannt, ob vor Weihnachten noch etwas passiert.

Sicher. Wenn nicht dieses, dann vielleicht nächstes Weihnachten. face-smile

lks
Mitglied: DerWoWusste
DerWoWusste 15.12.2014 um 10:07:06 Uhr
Goto Top
Ist Thomas eigentlich schon im Weihnachtsurlaub?
Mitglied: Dani
Dani 15.12.2014 um 10:28:02 Uhr
Goto Top
Wow, also braucht auch der Premier Support 10 Tage um einen Bug zu bestätigen, den jeder in 5 Minuten nachstellen kann.
Die Bestätigung kam am 09.12.2014. Bin leider nicht früher dazugekommen, dir kurz Rückmeldung zugeben.


Gruß,
Dani
Mitglied: Dani
Dani 17.12.2014 aktualisiert um 21:54:50 Uhr
Goto Top
Guten Abend,
hast du den Haken eigentlich entfernt:
6c5a59dd646a17ee2da892b22063c097


Gruß,
Dani
Mitglied: DerWoWusste
DerWoWusste 18.12.2014 um 01:01:50 Uhr
Goto Top
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 ;-|
Mitglied: DerWoWusste
DerWoWusste 12.01.2015 um 10:30:31 Uhr
Goto Top
Moin Dani.

Gibt es was Neues?
Mitglied: Dani
Dani 12.01.2015 um 18:46:42 Uhr
Goto Top
Moin @DerWoWusste,
nicht wirklich... es werden noch ein paar Workarounds getestet. face-smile


Gruß,
Dani
Mitglied: DerWoWusste
DerWoWusste 12.01.2015 um 18:56:33 Uhr
Goto Top
Ui... das nennt sich wirklich premier support? Ich wette, sie werden keine Lösung bieten face-sad nachdem sie weder 6 Wochen verstreichen lassen, genau wie beim MSDN-Support.
Mitglied: Dani
Dani 12.01.2015 um 20:41:52 Uhr
Goto Top
Jup... aber eigentlich sind die Jungs auf Zack! Ich ruf die nächsten 2 Tage mal an und frag nach.


Gruß,
Dani
Mitglied: AndiEoh
AndiEoh 12.02.2016 um 14:42:39 Uhr
Goto Top
Hallo,

bin heute auch über diesen Mist gestolpert...
Ist ja nun schon wieder ein Jahr her, dann sollte es doch Neuigkeiten geben oder??

Danke & Gruß

Andi
Mitglied: DerWoWusste
DerWoWusste 12.02.2016 um 14:55:20 Uhr
Goto Top
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".
Mitglied: AndiEoh
AndiEoh 12.02.2016 um 15:39:33 Uhr
Goto Top
Das ist so typisch MS das ich nicht mal lachen kann...
Wahrscheinlich haben Sie ein paar "komplizierte" Ausnahmen im Code gespart und der Programmierer wurde "Mitarbeiter des Monats" und nun will keiner zugeben das es Mist war. Das einzige Szenario bei dem das sinnvoll wäre ist bei SingleSignOn etwa bei published Applications wo der lokal angemeldete Benutzer durchgereicht wird, aber der Witz an RDP Verbinungen (mstsc) ist ja gerade das ich lokal ein anderer Benutzer bin und nicht z.B. der Server Administrator. Wenn dann noch lediglich der Maschinenname geprüft wird den der Client eh setzen kann wie er will...

Und für so ne Leistung wollen die 15K / Jahr

Na Danke

Gruß

Andi