Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Frage an Kunden von Microsofts Premier Support

Frage Microsoft

Mitglied: DerWoWusste

DerWoWusste (Level 5) - Jetzt verbinden

01.12.2014, aktualisiert 17.12.2014, 1606 Aufrufe, 31 Kommentare

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].
31 Antworten
Mitglied: emeriks
01.12.2014, aktualisiert um 15:05 Uhr
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.
Bitte warten ..
Mitglied: DerWoWusste
01.12.2014, aktualisiert um 15:15 Uhr
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.
Bitte warten ..
Mitglied: emeriks
01.12.2014 um 15:23 Uhr
Ja, ist doof, keine Frage.
Ich meine doch nur, dass das u.U. auch ganz nützlich sein kann.
E.
Bitte warten ..
Mitglied: Lochkartenstanzer
01.12.2014 um 17:08 Uhr
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
Bitte warten ..
Mitglied: Dani
01.12.2014 um 19:55 Uhr
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
Bitte warten ..
Mitglied: emeriks
01.12.2014 um 20:24 Uhr
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.

E.
Bitte warten ..
Mitglied: DerWoWusste
01.12.2014 um 20:33 Uhr
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
Bitte warten ..
Mitglied: Dani
01.12.2014 um 21:06 Uhr
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
Bitte warten ..
Mitglied: DerWoWusste
01.12.2014 um 21:27 Uhr
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 ...
Bitte warten ..
Mitglied: Dani
01.12.2014, aktualisiert um 21:45 Uhr
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?!
Bitte warten ..
Mitglied: DerWoWusste
01.12.2014, aktualisiert um 22:04 Uhr
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
Bitte warten ..
Mitglied: Dani
01.12.2014 um 22:01 Uhr
Jetzt hab's ich verstanden.
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?
Bitte warten ..
Mitglied: DerWoWusste
01.12.2014 um 22:07 Uhr
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.
Bitte warten ..
Mitglied: emeriks
02.12.2014 um 08:50 Uhr
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.

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


Gruß,
Dani
Bitte warten ..
Mitglied: DerWoWusste
06.12.2014 um 00:08 Uhr
Ich danke Dir!
Bitte warten ..
Mitglied: Dani
14.12.2014, aktualisiert um 23:22 Uhr
Moin @DerWoWusste,
der Bug ist bestätigt. Aktuell wird der Case mit der Fachabteilung besprochen.


Gruß,
Dani
Bitte warten ..
Mitglied: DerWoWusste
15.12.2014, aktualisiert um 07:44 Uhr
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.
Bitte warten ..
Mitglied: Lochkartenstanzer
15.12.2014 um 10:02 Uhr
Zitat von DerWoWusste:

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

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

lks
Bitte warten ..
Mitglied: DerWoWusste
15.12.2014 um 10:07 Uhr
Ist Thomas eigentlich schon im Weihnachtsurlaub?
Bitte warten ..
Mitglied: Dani
15.12.2014 um 10:28 Uhr
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
Bitte warten ..
Mitglied: Dani
17.12.2014, aktualisiert um 21:54 Uhr
Guten Abend,
hast du den Haken eigentlich entfernt:
6c5a59dd646a17ee2da892b22063c097 - Klicke auf das Bild, um es zu vergrößern


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

Gibt es was Neues?
Bitte warten ..
Mitglied: Dani
12.01.2015 um 18:46 Uhr
Moin @DerWoWusste,
nicht wirklich... es werden noch ein paar Workarounds getestet.


Gruß,
Dani
Bitte warten ..
Mitglied: DerWoWusste
12.01.2015 um 18:56 Uhr
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.
Bitte warten ..
Mitglied: Dani
12.01.2015 um 20:41 Uhr
Jup... aber eigentlich sind die Jungs auf Zack! Ich ruf die nächsten 2 Tage mal an und frag nach.


Gruß,
Dani
Bitte warten ..
Mitglied: AndiEoh
12.02.2016 um 14:42 Uhr
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
Bitte warten ..
Mitglied: DerWoWusste
12.02.2016 um 14:55 Uhr
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".
Bitte warten ..
Mitglied: AndiEoh
12.02.2016 um 15:39 Uhr
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
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
Windows Server
gelöst Server 2012R2 Frage zum DHCP Failover (6)

Frage von Coreknabe zum Thema Windows Server ...

LAN, WAN, Wireless
Frage zum Erzeugen eines portbasiertem VLAN (7)

Frage von presto-18 zum Thema LAN, WAN, Wireless ...

Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (21)

Frage von Xaero1982 zum Thema Microsoft ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...

Windows Update
Treiberinstallation durch Windows Update läßt sich nicht verhindern (17)

Frage von liquidbase zum Thema Windows Update ...

Windows Tools
gelöst Aussendienst Datensynchronisierung (12)

Frage von lighningcrow zum Thema Windows Tools ...