Wie Rechner lizenzsicher vom Zugriff auf den TS abhalten?

[Magroll 10]

Wahnsinnig interessante Diskussion! :D

Alles was man falsch machen kann macht man wohl auch irgendwann mal falsch. Ich würde zu dem Thema gerne wissen, ob es denn reicht auf dem TS Server via Firewall nur bestimmte Geräte auf den TS zu lassen?

 

Konkreter, wir haben diverse Subnetze mit Clients die ja theoretisch auf den TS Server zugriefen können. Im Detail tut das ja aber nur eine Teilmenge. Wenn ich auf dem TS Server jetzt die MS Firewall aktiviere, oder eine andere Firewall davor schalte und damit nur diese Teilmenge auf den TS lasse, dann muss ich auch nur diese Teilmenge lizensieren?

 

Wäre für mich jetzt eigentlich logisch dass das dann so okay wäre, schließlich trennt mich vom Rest der Welt (Internet) ja auch nur eine Firewall, ansonsten müsste ich ja xx Milliarden Lizenzen kaufen?! :suspect:

 

ThX,

Magroll

[Dr.Melzer 191]

Ich würde zu dem Thema gerne wissen, ob es denn reicht auf dem TS Server via Firewall nur bestimmte Geräte auf den TS zu lassen?

 

Woran identifizierst du diese Geräte denn?

[Magroll 10]

Naja, an der IP natürlich, verstehe aber schon worauf Du wohl hinauswillst, da man die ja jederzeit ändern kann...

 

Geht es aber denn nicht prinzipiell auch darum, nachzuweisen, das man alles technische und mögliche getan hat um einen nichtlizensierten Zugriff zu unterbinden? Schließlich kann man doch nicht jedem gleich Betrugsabsichten unterstellen. Oder agiert MS da rein nach rechtlichen Vorschriften, also es geht nur um das was auf dem Papier steht, unabhängig von tatsächlichen realen Situationen?

 

So long,

Mag

[Gulp 254]

Aus Erfahrung kann ich zumindest sagen, dass MS bei Audits keine IP gesteuerten Zugriffsfilter als Trennung oder Kontrolle akzeptiert. Die einzige mir (auch aus Erfahrung heraus) bekannte technische Möglichkeit war bisher (kann sich mittlerweile natürlich auch geändert haben) ein eigenes physikalisch abgetrenntes Netz für den TS das nur die lizenzierten Maschinen erreichen konnten.

 

Die andere gern praktizierte Lösung ist mittlerweile wohl "kein Office auf dem TS, nur lokal auf den Geräten" geworden, zumindest trifft das für unser Unternehmen zu.

 

Letztlich war die Realisierung eines solchen Konstrukts aber auch nicht billiger als Lizenzen für alle Maschinen/User gewesen.

 

Grüsse

 

Gulp

[lizenzdoc 207]

Hi,

 

das TS-Thema bei Applikationen ist nicht einfach.

Wenn ich dann bei Gulp lese, dass seine "Konstruktion" gleich teuer

wie durchlizenzieren wurde ... ist das schade.

 

Hat man als Kunde eine "gewisse Größe / Wichtigkeit" für Microsoft,

lohnt sich aber ein Gespräch mit dem Ms-Accounter.

 

Aber dafür muss man Ihm schon tiefen Einblick gewähren,

was ja nicht so gerne gewollt ist,

auf der anderen Seite kann man dadurch vielleicht eine schriftliche Nebenabrede

seitens MS erwirken, die das "Leben" vereinfacht, aber MS keinen "verlust" beschert.

 

Muss man immer genau betrachten, damit der Schuß nicht nach hinten los geht :)

 

Wir versuchen gerad den Umstieg auf Office-365 ...

weil Zugriff via Desktop/Notebook, Smartphone, etc.

Da würden wir ja auf die Office-User-Lizenzierung wechseln+

noch Migration von Notes auf Exchange ... schaumermal :)

 

Angenehmes WE allen!

Vg, Franz

[Magroll 10]

Soweit so (nicht) gut... also kein IP Filter, was ich als gestandener Netzwerker sehr schade finde :suspect:

 

Was ich dann aber nicht verstehe, (oder ich habe es falsch verstanden) ist die Lösung, einen zweiten TS Server nur für die Office User (Devices) zu etablieren, wie hier in anderen Threads genannt.

 

Wie soll man denn bei einer solchen Lösung sicherstellen, das sich auf diesem Server nur die lizensierten Devices anmelden?

 

ThX,

Mag

[XP-Fan 217]

Hallo,

 

Soweit so (nicht) gut... also kein IP Filter, was ich als gestandener Netzwerker sehr schade finde :suspect:

 

als gestandener Netzwerker kennst du bestimmt noch andere Möglichkeiten Rechner zu erkennen

bzw zu sperren denn IP Adressen / Namen können sich ändern.

 

Und genau die Methode sollte durchaus sicherstellen können das nur lizenzierte Systeme

auf den Terminalserver zurgeifen dürfen, einen Filter Allow ( Liste ) und danach deny all.

 

Das ist soweit mir bekannt ist ( und das ist bei Weitem nicht Alles ) die einzigste Möglichkeit

sicherzustellen das nur ausgewählte Systeme zugreifen können.

[lizenzdoc 207]

Hi,

 

da ich ja technisch nicht der "schlaueste" bin ...

 

MS geht es beim TS-Zugriff darum, dass unverwechselbar feststellbar ist,

welches Device ist für die Applikation lizenziert und welches nicht.

Wenn also ein Device ein unikates und nicht veränderbares "Merkmal" hat und

nicht wie ein Camälion seine Identität wechseln kann. Dann könnte man ja festlegen, welches Device darf und welches darf nicht zugreifen.

 

Welche Technik/Verfahren wäre das dann?

Und ist es überhaupt praktikabel(spezell vom Aufwand her)

Danke für die Info, dies könnte dann als Hinweis bei der Beratung sehr hilfreich sein.

 

VG,Franz

[Dr.Melzer 191]

Wenn du die Rechner anhand ihrer MAC Adresse erkennst wurde das bisher von MS so akzeptiert. Ja die MAC Adresse lässt sich auch ändern, aber nicht so leicht (und vor allem nicht so willkürlich) wie eine dynamisch vergebene IP.

 

Noch sicherer wäre die Idenbtifikation anhand des TCPM Chips. Der ist eindeutig.

 

BTW:

 

Es gibt Anbieter von Software die behaupten sie könnten diese Zugriffe "Revisionssicher" und MS Lizenzkonform steuern. Das hat sich bisher immer als Marketingbullshit erwiesen, da (zumindest alle mir bekannte) si edie Identifikation anhand der IP machen, was von MS nicht akzeptiert wird.

[Gulp 254]

Jup MAC ist das Stichwort, dazu muss man zum einen mindestens Switche mit MAC-basierter Zugriffssteuerung einsetzen, gut planen und ausführlich testen, das macht die Sache dann nicht einfach und vor allem nicht billig.

 

Der Aufwand ist jedenfalls deutlich höher als CAL's kaufen oder die Finger von Office auf dem TS zu lassen. ;)

 

Grüsse

 

Gulp

[Weingeist 159]

Also bei einem aktuellen Server-OS hat man doch sehr umfangreiche und vielfältige Firewal-Regeln die man setzen kann. Wenn man die RDP-Ports dicht macht und nur für die jeweiligen Computer/ComputerGruppen freigibt, sollte dies doch ausreichen oder?

[NorbertFe 2.035]

Du kannst bei Windows Firewalls anhand welcher Kriterien unterscheiden? ;) Nutzer (2012) und Rechner/IP. Und das wurde doch vorn im Thread schon als unzureichend erläutert, oder?

[PowerShellAdmin 169]

...aber einen Mehrwert gibt es nicht.

Die getrennten Netze kann man wenn der Audit weg ist verbinden.

Die Firewallregeln deaktivieren usw.

Genauso kann sich MA2 an den PC von MA1 setzen und unter diesem User arbeiten... (jetzt mal die Devicecals ausgenommen)

 

Softwarelizenzen sind echt ein Bereich, bei dem eine Regulierung überfällig ist. Klar sollte das Recht des Urhebers gewahrt bleiben, aber dadrum geht es ja nur noch "scheinbar".

[Dr.Melzer 191]

Also bei einem aktuellen Server-OS hat man doch sehr umfangreiche und vielfältige Firewal-Regeln die man setzen kann. Wenn man die RDP-Ports dicht macht und nur für die jeweiligen Computer/ComputerGruppen freigibt, sollte dies doch ausreichen oder?

 

Worann willst du dabei die einzelnen Geräte identifizieren?

[Weingeist 159]

@PowerShellAdmin: Man kann immer bewusst Illegales tun wenn man möchte. Von daher gilt dieses Argument imho nicht. Auch bei physisch getrennten Netzen könntest einen stecker umstecken. Um beim Argument Auto zu bleiben, nur weil mein Auto über 200 fährt, heisst das nicht, dass ich das Innerorts tun muss. Und nur weil es das Auto kann, habe ich noch nichts illegales gemacht. ;)

 

Dem AD-Namen? Oder Traut MS seiner eigenen Technologie nicht? Wäre jetzt so die Idee. Halt doof wenn das Endgerät nicht in AD wäre.

 

EDIT: Habe gerade mal nachgeschaut, die Remotedesktop-richtlinien sind sogar vordefniert. Unter Eigenschaften gibt es das Remote-Computer Register. Da kann man entweder Computer ausschliessen oder eben zulassen. Die Verbindung muss einfach 'sicher' sein, damit man dies aktivieren kann. Lässt sich auf dem Register Allgemein einstellen.

bearbeitet 6. November 2012 von Weingeist