19.3 Benutzerzugriff
Nach Abschluss der Installationsarbeiten sollten die Remotedesktopdienste nutzbar sein. Obgleich nun noch keine Anwendungen installiert sind, ist eine erste Überprüfung sinnvoll. Zum Zugriff wird ein Client benötigt, der mithilfe des RDP-Protokolls (RDP – Remote Desktop) auf den Remotedesktop-Sitzungshost zugreift. Wie kommt der Client auf den PC?
- Windows 8.1 hat den aktuellsten Client an Bord, alle vorherigen Windows-8-Betriebssysteme werden über Updates aktuell gehalten.
- Ab Windows Vista und Windows Server 2008 ist die Version 6 bzw. 6.1 des Clients enthalten. Updates gibt es im Download-Center.
- Windows XP und Windows Server 2003 enthalten die Version 5 der Remotedesktopverbindung. Die aktuelle Version ist als Download im Internet (www.microsoft.com/downloads) erhältlich. Es gibt verschiedene Installationspakete für Windows XP und Windows Server 2003, und zwar jeweils als 32- und als 64-Bit-Version.
- Für ältere Windows-Betriebssysteme stehen im Microsoft Download Center ebenfalls Clients zur Verfügung, allerdings nicht in der aktuellen Version 6 (d. h., eine Netzwerkauthentifizierung ist nicht möglich).
- Thin Clients (wie beispielsweise die Geräte von Wyse oder Neoware) werden bereits mit »eingebautem« RDP-Client geliefert. Sie müssen allerdings darauf achten, dass es Thin Clients gibt, die nicht Microsofts RDP-Protokoll, sondern nur Citrix’ ICA-Protokoll unterstützen.
- Mobilgeräte von Microsoft werden im Allgemeinen mit einem Client für Remotedesktopverbindungen geliefert.
- Es gibt mittlerweile übrigens auch für Geräte wie das iPhone, das iPad und die Androids einen RDP-Client – einfach im App-Store suchen.
Abbildung 19.31 Die Windows-Versionen ab XP enthalten den Remotedesktopclient; bei den älteren Versionen muss er nachinstalliert werden. Hier zu sehen ist Windows 8.1.
Der Installationsassistent erkundigt sich zwar bereits nach den Benutzern und Benutzergruppen, die Zugriff erhalten sollen (Abbildung 19.31), wenn Sie dort aber keine Eingaben machen, gilt Folgendes: Verbindet sich ein Benutzer, der kein Administrator und kein Mitglied der lokalen Gruppe Remotedesktopbenutzer ist, mit dem Remotedesktop-Sitzungshost, wird die Fehlermeldung aus Abbildung 19.32 erscheinen. Der Grund ist leicht zu erkennen: Ein Nicht-Administrator darf sich grundsätzlich nicht interaktiv am Server anmelden – und auch ein Remotedesktop-Sitzungshost ist in letzter Konsequenz ein Server. Es muss also zunächst ein wenig Konfigurationsarbeit geleistet werden.
Abbildung 19.32 Damit ein Benutzer auf den Remotedesktop-Sitzungshost zugreifen kann, muss er direkt oder indirekt Mitglied der Gruppe »Remotedesktopbenutzer« sein.
Damit sich ein Anwender an einem Remotedesktop-Sitzungshost anmelden kann, brauchen Sie ihm zum Glück nicht das Recht zur interaktiven Anmeldung zu geben. Es genügt, wenn er mittelbar oder unmittelbar Mitglied der lokalen Gruppe Remotedesktopbenutzer des Remotedesktop-Sitzungshosts ist. »Mittelbar« bedeutet in diesem Zusammenhang, dass es nicht notwendig ist, dass Sie jedes einzelne Benutzerkonto in dieser Gruppe eintragen. Bei vielen Benutzern und mehreren Remotedesktop-Sitzungshosts wäre das mehr als lästig. Stattdessen wählen Sie die übliche Vorgehensweise (Abbildung 19.33):
- In der Domäne richten Sie eine Sicherheitsgruppe ein, beispielsweise mit dem Namen RD-Benutzer . (Der Name ist beliebig, er könnte also auch aldf90428soed lauten, was aber lästig beim Wiederfinden ist.)
- In diese Sicherheitsgruppe tragen Sie alle Benutzer oder Gruppen, die auf Remotedesktopdienste zugreifen möchten, als Mitglied ein.
- Diese Gruppe wird Mitglied der lokalen Gruppe Remotedesktopbenutzer auf allen Remotedesktop-Sitzungshosts.
- Alternativ könnten auch alle Authentifizierten Benutzer, alle Domänen-Benutzer oder eine sonstige vordefinierte Gruppe Mitglied der lokalen Gruppe der Remotedesktopbenutzer werden.
Wenn Sie nun nochmals testen, sollte der Benutzer Zugriff auf den Remotedesktop-Sitzungshost erhalten. Falls er eine zusätzliche Gruppenmitgliedschaft erhalten hat, muss er sich einmal ab- und wieder anmelden.
Abbildung 19.33 Es empfiehlt sich, eine Domänengruppe anzulegen, die dann Mitglied der lokalen Gruppe »Remotedesktopbenutzer« wird.
In Abbildung 19.34 sehen Sie, wie das Charms-Menü des über den Remotedesktop-Sitzungshost bereitgestellten Desktops aussieht. Sie erkennen, dass für einen »normalen« Benutzer (Nicht-Administrator) die Optionen zum Neustarten und Herunterfahren ausgeblendet sind. Es wäre ja auch eine ziemliche Katastrophe, wenn ein Benutzer versehentlich oder absichtlich den kompletten Remotedesktop-Sitzungshost herunterfahren könnte.
Abbildung 19.34 Startet der Benutzer eine Verbindung, erhält er den vollen Desktop. Ein »normaler« Anwender kann aber den Server nicht herunterfahren.
Hier noch ein wenig Hintergrundwissen:
Wer sich an dem Remotedesktop-Sitzungshost anmelden kann, wird vordergründig über die Mitgliedschaft in der Gruppe Remotedesktopverbindungen gesteuert – das hatten Sie ein wenig weiter oben bereits kennengelernt. Die Mitglieder der Gruppe sind aber nur deshalb berechtigt, weil in der lokalen Sicherheitsrichtlinie (die Sie über die Verwaltung finden) definiert ist, dass sich Mitglieder der Gruppen Administratoren und Remotedesktopbenutzer an den Remotedesktopdiensten anmelden können (Abbildung 19.35).
Abbildung 19.35 Die Mitglieder der Gruppe »Remotedesktopbenutzer« können deshalb auf die Remotedesktopdienste zugreifen, weil sie in der lokalen Sicherheitsrichtlinie dazu berechtigt werden (das ist eine Standardeinstellung).
Sie könnten also auch an dieser Stelle Benutzer und Gruppen hinzufügen. Wie immer gibt es Pro und Kontra:
- Die lokale Sicherheitsrichtlinie können Sie mittels Gruppenrichtlinien überschreiben. Wenn Sie 20 Remotedesktop-Sitzungshosts haben und bei allen eine Domänengruppe hinzufügen möchten, geht das mit einigen wenigen Mausklicks – sofern Ihre Remotedesktop-Sitzungshosts sich in einer OU (Organizational Unit, Active Directory Organisationseinheit) befinden.
- Die Gruppe Remotedesktopbenutzer muss trotzdem gepflegt werden, da über die dort vorhandenen Benutzer bzw. Gruppen die Zugriffsberechtigung für die Netzwerkverbindung zum Remotedesktop-Sitzungshost gesteuert wird.
Ob der Benutzer auf die Menüeinträge zum Herunterfahren und Neustarten des Systems zugreifen kann oder ob diese (wie in Abbildung 19.34) deaktiviert sind, steuern Sie ebenfalls über eine Einstellung in der lokalen Sicherheitsrichtlinie. Es existiert eine Richtlinie namens Herunterfahren des Systems , in der standardmäßig die Gruppen Administratoren und Sicherungs-Operatoren eingetragen sind. Wenn Sie in diese Gruppen einen Benutzer (oder eine Gruppe) aufnehmen, werden dem Benutzer die Menüpunkte wieder zur Verfügung stehen.
Will man die Remotedesktopdienste produktiv einsetzen, wird man den Benutzern über Gruppenrichtlinien drastisch mehr Rechte entziehen, als dies bei einer Standardinstallation der Fall ist. Dass Herunterfahren und Neustarten ausgeschlossen sind, verhindert »das Schlimmste«. In der Praxis wird man den Benutzern alle Optionen wegnehmen – vom Zugriff auf die Systemsteuerung über die Möglichkeit, die Kommandozeile zu starten, bis hin zum Einstellungsdialog für den Bildschirmschoner.
Die Gründe für das Sperren von Systemsteuerung und Kommandozeile leuchten sicherlich jedem ein, aber warum sollten Sie die Einstellung für den Bildschirmschoner sperren? Ganz einfach: Ein Bildschirmschoner schluckt Prozessorzeit, und bei den hübschen OpenGL-Bildschirmschonern ist diese schon recht signifikant. Denken Sie immer daran, dass auf dem Remotedesktop-Sitzungshost eventuell 40 Sitzungen laufen – wenn 30 davon sich mit dem Bildschirmschoner beschäftigen, ist das mehr als spürbar.
Auch vor dem Hintergrund der Prozessorbelastung unkritisch erscheinende Bildschirmschoner wie Fotos (zeigt alle Grafikdateien eines Verzeichnisses) sind unbedingt zu vermeiden. Wenn sich der Remotedesktop-Sitzungshost damit beschäftigen muss, viele Megabytes große BMPs oder JPGs über das Netz zu transportieren und darzustellen, ist das eine unnötige Belastung.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.