Arbeiten mit Standard-Benutzerkonten, Teil 2

Nicht jeder Anwender muss Administrator auf dem lokalen System sein. Doch dazu gilt es vor allem im Bereich der mobilen Systeme, entsprechende Änderungen am Betriebssystem machbar sein – wie etwa die Option, dass normale Benutzer vordefinierte Treiber aufspielen können. Erst so wird das Konzept der Least Privileged User Accounts in einem Unternehmen mit wenig Gegenwind seitens der Anwender vernünftig umsetzbar.

Bei Windows 7 kommen dazu Änderungen im Sicherheitsmodell ins Spiel. Im ersten Teil wurden bereits die Möglichkeiten umrissen, die sich mit dem Registry-Wert DevicePath ergeben. Im zweiten Teil wird das Thema Netzwerkdrucker sowie das weite Feld der Benutzerkontensteuerung diskutiert.

Das Verwenden und Verwalten von Druckern ist schon schwierig genug, doch wenn dazu noch auf den Arbeitsplatzsystemen die Standard-Benutzerkonten ins Spiel kommen, wird die Sache umso problematischer. Generell herrscht viel Verunsicherung über die Fähigkeit der Standard-Benutzer, Treiber für Netzwerkdrucker installieren zu können. Einer der am häufigsten übersehenen Vorteile beim Einsatz von Windows-Druckerservern in einem Netzwerk lautet:
Anwender benötigen keine Administratorrechte, um Netzwerkdrucker zu installieren, die auf einem Windows-Server laufen.

Wenn es sich bei dem Treiber, der auf dem Printserver installiert ist, um einen Treiber aus dem Windows-Installationsumfang handelt, oder wenn der Treiber aus einem signierten Druckertreiber-Paket stammt, dann benötigen die Anwender keine Administratorrechte auf dem System, um dort diese Drucker zu installieren.

Da vielen Unternehmen die zusätzlichen Ausgaben für einen Windows-basierten Druckerserver vermeiden wollen, sollte man sich Alternativen überlegen, damit Standard-Benutzer die Netzwerkdrucker installieren dürfen. Dabei dreht sich alles darum, dass für das Einsetzen eines Netzwerkdruckers, der nicht auf einem Windows-Printserver läuft, auf jedem lokalen Client ein TCP/IP-Port konfiguriert werden muss. Und dazu sind die Administratorrechte nötig.
Mit den GPPs (Group Policy Preferences) lassen sich TCP/IP-Drucker für die Installation durch Standard-Benutzer vorsehen.

Doch dazu müssen beim ersten Einsatz die Drucker auf einem Windows-Printserver installiert sein, um die Treiber verteilen zu können. Ist ein Drucker dann auf den entsprechenden Systemen installiert, kann man den Windows Printserver wieder abschalten und die Druckaufträge direkt an den passenden Drucker senden. Allerdings habe dazu einige Hersteller eigene Lösungen entwickelt, wie zum Beispiel HP mit seinem „Universal Print Driver“. Im realen Leben aber muss man beim Einsatz der GPP für das Verwenden von TCP/IP-Druckern durch Standard-Benutzer einige Dinge beachten:

Für Computer, die kein Windows 7 verwenden, sind die Client-Side Extensions der GPP einzusetzen. Wer die Computerkonfigurations-Voreinstellungen für den Einsatz von TCP/IP-Druckern verwendet, der sollte zudem noch die Point-and-Print-Einschränkungen in den Gruppenrichtlinien (sie sind zu finden unter Computerkonfiguration, Administrative Vorlagen, Drucker) deaktivieren. Damit werden keine Warnungen oder Hinweise durch die Benutzerkontensteuerung während der Installation auftreten.

Die GPP unterstützen den Einsatz von Druckern nur, wenn der WinPrint (der sogenannte Print Processor, Druckprozessor) auf dem Windows Printserver ausgewählt wurde. Wenn man hier etwas anders auswählt, muss der Druckprozessor bereits auf den Geräten installiert sein, auf denen der Drucker zum Einsatz kommen soll. Es kann aber vorkommen, dass der WinPrint-Druckprozessor die erweiterten Funktionen eines Druckers nicht unterstützt.

Benutzerkontensteuerung zum Schweigen bringen

Seit der Einführung der Benutzerkontensteuerung gibt es einige Anwendungen, die darauf bestehen, dass sie mit Administrator-Berechtigungen zur Ausführung kommen – und das ohne guten Grund. Angenommen ein Standard-Benutzer meldet sich am System an und will eine Applikation starten. Dann kommt es bei einer derartigen Anwendung zur Ausgabe der Dialogbox der UAC (User Account Control), die die Eingabe des Kennworts für das Admin-Konto einfordert. Wer in diesem Zusammenhang kein Kennwort eingeben kann und bei der anschließenden Frage, ob das betreffende Programm Änderungen am Computer machen darf, mit einem Nein antwortet, der kann das Programm nicht ausführen.

Auf den ersten Blick scheint es nur zwei Optionen zu geben: Entweder die Anwendung wird mit Administrator-Rechten aufgerufen oder aber die Benutzerkontensteuerung wird abgeschaltet. Doch diese beiden Optionen  sind alles andere als wünschenswert. Eine jede ausführbare Datei auf einem System kann ein Anwendungsmanifest (Application Manifest) zugeordnet bekommen. Dabei handelt es sich um eine XML-Datei, die einige Parameter angibt. Diese Werte bestimmen, wie die Applikation mit der Benutzerkontensteuerung zusammenspielt. Üblicherweise sind die Anwendungsmanifeste in der ausführbaren Datei eingebettet. Doch manchmal treten sie auch als eigenständige Dateien in einem Applikations-Verzeichnis auf.

Um das angesprochene Problem zu adressieren, hat Microsoft einen zusätzlichen Teil für die Kompatibilitätsinfrastruktur der Applikationen eingeführt: RunAsInvoker ermöglicht die Anwendung, mit den Berechtigungen zu laufen, die der erzeugende Prozess inne hat, ohne erhöhte Rechte einzufordern. Daher sollte man wann immer möglich das Anwendungsmanifest der ausführbaren Datei ändern.

Dazu gibt es zum Beispiel das Tool „Resource Tuner“, mit dessen Hilfe ein Administrator die Anwendungsmanifeste ändern kann, die in einer ausführbaren Datei liegen. Dazu ist das Tool aufzurufen und dann der entsprechende XML-Code zu ändern. Das geht recht einfach, die einzige Schwierigkeit ist das Auffinden des Manifest-Verzeichnisses im Resource Browser  und dann den Wert für „requestedExecutionLevel“ zu modifizieren. Er darf nicht mehr „requireAdministrator” lauten, sonder sollte auf „asInvoker“ umgestellt werden.

Ein Beispiel für das Security-Tag  in einer Anwendungsmanifest-Datei lautet:

<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator"
  uiAccess="false"/>
</requestedPrivileges>
</security>

Wer Visual Studio einsetzt, der kann auch das Programm mt.exe verwenden, um ein Anwendungsmanifest zu ändern oder es hinzuzufügen. Das Programm gehört auch zum Umfang des Windows SDK (Software Development Kit).
Falls das Ändern eines Anwendungsmanifests nicht möglich ist, kann man sich das ACT (Application Compatibility Toolkit) in der Version 5.5 von der Microsoft-Website besorgen (es steht zum kostenlosen Download zur Verfügung, derzeit ist die Version 5.6 aktuell).

Damit lässt sich ein Kompatibilitäts-Fix erstellen (dazu wird RunAsInvoker eingefügt) und dann wird das Ergebnis an die Arbeitsplatzsysteme verteilt. Dazu sind die folgenden Schritte nötig:

• Zuerst muss man sich am System mit Windows 7 als Administrator anmelden und das ACT installieren.
• Danach ist der Compatibility Administrator im ACT-Verzeichnis des Start-Menüs zu öffnen. Unter dem Punkt Custom Databases im linken Bereich ist der Punkt New Database zu selektieren und dann Control+R einzugeben.
• Als nächstes benötigt die Datenbank einen Namen.
• Mit der Eingabe von Control+P wird ein neuer Fix für eine Applikation erzeugt. Im entsprechenden Dialog ist der Name des Programms einzutragen, das geändert werden soll.
• Mit einem Klick auf Browse ist dann die ausführbare Datei zu suchen, an die der Fix angehängt werden soll. Dann muss man noch auf Open und Next klicken, um weiter zu machen.
• In der Darstellung zu den Kompatibilitäts-Modi  ist unter den Betriebssystemen „None“ anzugeben und dann auf Next zu klicken. Auf der Darstellung zu den „Compatibility Fixes“ ist nach unten im Menü zu scrollen und dort der RunAsInvoker-Fix zu selektieren.
• An diesem Punkt kann man auf „Test Run“ klicken, um zu sehen, ob der Fix den gewünschten Effekt für die Applikation bewirkt hat. Mit einem Klick auf Next geht es weiter.
• In der Darstellung der “Matching Information” lassen sich noch genauere Angaben machen, wie die Kompatibilitäts-Engine die ausführbare Datei identifiziert. Hier können die voreingestellten Werte beibehalten werden. Danach ist noch auf Finish zu klicken, um die gesamte Aktion abzuschließen.
• Danach ist noch das Speichern auszuführen: Mit einem Klick auf das Save-Icon im oberen Bereich des Fensters für den Compatibility Administrator wird das Abspeichern der Datenbank auf das C-Laufwerk auf dem lokalen Computer erledigt.
• Danach muss man aus dem File-Menü den Punkt „Install“ wählen und mit einem Klick auf OK das Installieren der Datenbank bestätigen. Danach sollte man die betreffende Applikation starten können, ohne dass die Berechtigungsstufe erhöhte werden müsste.

Der gewissenhafte Administrator wird allerdings diese Änderungen intensive testen, ehe er die Software an die Arbeitsplatzsysteme verteilt. Das verteilen lässt sich erneut mit Hilfe der Gruppenrichtlinien und einer Batch-Datei erledigen. Die Batch-Datei muss dazu das Kommando sbdinst.exe aufrufen.

Benutzerkontensteuerung als Sicherheitsgrenze

Von Microsoft  stammt die Aussage, dass es sich bei der Benutzerkontensteuerung um ein Sicherheits-Feature handelt, und nicht um eine Sicherheitsgrenze. Doch das Anmelden an einem geschützten Administratorkonto stellt keine Sicherheitsgrenze dar. Ein Standard-Benutzerkonto mit aktivierter Benutzerkontensteuerung dagegen gilt als eine Abschottung.

Die standardmäßig vorgegebene Konfiguration der Benutzerkontensteuerung erlaubt eine Rechteerhöhung nach dem Motto OTS (Over The Shoulder). Wenn die Benutzersteuerung von einem Applikations-Installer angestoßen wird, oder ein Anwendungsmanifest gibt vor, dass eine ausführbare Datei mit Administrator-Berechtigungen aufzurufen ist, muss man ein Admin-Kennwort eingeben, ehe man weitermachen kann. Dieses Vorgehen führt zu einem Absichern der Arbeitsplätze. Eine Session, die von einem Arbeitsplatz eines Benutzers isoliert ist, kann den Durchgriff von Malware unterbinden. Damit lässt sich in letzte Konsequenz auch die Eingabe des Administrator-Kennworts sicher erledigen – damit erschein alles recht sicher.

Ein Dilemma mit den erhöhten Rechten durch den OTS-Ansatz ist allerdings nicht abgestellt: Malware könnte den sicheren Arbeitsplatz imitieren und dann das Administrator-Kennwort abfangen, wenn es ein unbedarfter Benutzer eingibt. Daher empfiehlt Microsoft auch das Deaktivieren der Erhöhung der Benutzerrechte über den OTS-Ansatz für die Standard-Benutzerkonten in den Gruppenrichtlinien. Damit wird dieser Verwundbarkeit in Unternehmensnetzwerken ein Riegel vorgeschoben.

Das Deaktivieren der Rechteerhöhung nach dem OTS-Verfahren bedeutet aber auch, dass nicht länger mit einem rechten Mausklick auf eine ausführbare Datei der Menüpunkt  „Als Administrator ausführen“ zur Verfügung steht. Das erweist sich für die Mitarbeiter im IT-Support sicher als Nachteil. Doch mit dem Drücken der Shift-Taste und einem rechten Mausklick gibt es ja immer noch die Option „Ausführen als“ im Menü.

Eine Alternative zum Deaktivieren der Rechteerhöhung über den OTS-Ansatz ist das Anschalten der SAS (Secure Attention Sequence) in den Gruppenrichtlinien. Dabei müssen die Anwender zuerst die Tastenkombination Ctrl+Alt+Del (Srg+Alt+Entf) drücken. Erst dann wird ihnen ein „sicherer Desktop“ präsentiert. Dabei lässt sich die SAS nicht anderweitig emulieren – allein das physische Eingeben der Tastenkombination führt zu diesem Desktop. Damit kann ein Benutzer sicher sein, dass es sich um einen „unverfälschten“ sicheren Desktop handelt.

Unter den Gruppenrichtlinien (Computer-Konfiguration, Administrative Vorlagen, Windows-Komponenten, Benutzerschnittstelle für Anmeldeinformationen muss man dazu den Eintrag „Vertrauenswürdiger Pfad für Anmeldeinformationseintrag erforderlich“ (Require trusted path for credentials) aktivieren. Man darf sich aber nicht darüber hinwegtäuschen lassen: Der Einsatz der SAS bringt ein gehöriges Maß an Aufwand für die Benutzer mit sich, wenn eine Rechteerhöhung häufig anfällt.

Keine Sicherheits-Utopie

Windows 7 macht es einfacher, als Standard-Benutzer zu agieren – und zwar sowohl zuhause als auch im Firmennetzwerk. Doch je mehr Anwender sich ohne Administrator-Rechten anmelden, umso eher wird sich Malware darauf einstellen und es auf die Abmeldesession der Benutzer absehen. Daher sollte man den Einsatz von Software Restriction Policies in Vista oder Applocker ab Windows Server 2008 Release 2 und bei einigen Editionen von Windows 7 verwenden. Damit gilt es dann ein White-Listing für bestimmte Anwendungen vorzugeben. Das wird ein wichtiger Punkt, um derartige Malware-Typen auszuschließen.

Russell Smith/rhh