Verwaltung von Plug-and-Play-Geräten
Vom Fluch zum Segen
In gemanagten Windows-Umgebungen lassen sich Plug-and-Play- Geräte nicht verwenden, ohne dass große Probleme hinsichtlich der Berechtigungen entstehen. Die von Microsoft bereitgestellten Hilfen lösen diese Probleme nicht. Entsprechende Zusatz-Tools sind verfügbar, müssen aber klar definierte Anforderungen erfüllen.
Gemanagte Windows-Umgebungen sind ein Segen für Administratoren: Sie gewährleisten eine zentrale
Softwareverteilung und hohe Client-Stabilität bei niedrigem Aufwand für die Bereitstellung und den
Betrieb der Clients. Die zu Grunde liegenden Prinzipien sind immer die gleichen, sie basieren auf
definierten und somit nachvollziehbaren Regeln für Systemumgebungen. Unkontrollierbaren
Systemveränderungen wie auch Sicherheitsaspekten trägt der Administrator Rechnung, indem er die
Benutzerrechte beschränkt.
Plug-and-Play-(PnP-)Geräte lassen sich vom Anwender schnell und einfach nutzen und haben sich
daher – meist in Form von USB-Geräten – längst als Standard etabliert. Sie ergänzen den
Arbeitsplatz um wichtige Funktionen, die gerade im geschäftlichen Umfeld von Bedeutung sind, zum
Beispiel um den spontanen Anschluss eines Druckers an ein Notebook. In gemanagten
Windows-Umgebungen wirft der Einsatz von PnP-Geräten jedoch Fragen und Probleme auf: Welche
Berechtigungen benötigt ein Anwender für ihre Installation? Wie kann man die Verfügbarkeit der
passenden Treiber sicherstellen? Wann und wo erfolgt die Installation der Treiber? Und wie lässt
sich der Einsatz nicht gewünschter Geräte sperren?
PnP-Installation im Detail
Der Bustreiber erkennt das PnP-Gerät beim Einstecken und meldet es dem PnP-Manager im
Kernel-Modus. Der PnP-Manager fragt daraufhin vom Bustreiber Informationen zum neuen Gerät ab,
darunter die Hardware-IDs, Compatible-IDs und weitere Eigenschaften wie beispielsweise die Klasse
des neu eingesteckten Geräts. Dann informiert der PnP-Manager im Kernel Mode den PnP-Manager im
User Mode, dass ein Gerät zur Installation ansteht. Der PnP-Manager sucht nun auf der Basis von
Hardware-IDs oder Compatible-IDs im System nach dem passenden Treiber. An dieser Stelle entscheidet
sich, welcher Typ von Installation durchführbar ist. Windows unterscheidet dabei zwei Typen: die
serverseitige und die Client-seitige Installation.
Bei serverseitigen Installationen müssen die passenden Treiber im System bereits installiert und
die beteiligten Treiberkomponenten signiert sein. Sind diese Kriterien erfüllt, laufen
serverseitige Installationen ohne Einwirkung des Anwenders automatisch ab. Das System selbst stellt
dabei die notwendigen Berechtigungen bereit. Sind diese Kriterien nicht gegeben, wird die
anstehende Installation automatisch zu einer Client-seitigen. Dies ist bereits dann der Fall, wenn
sich kein passender Treiber finden lässt und die Installationsroutine den Anwender nach einem
Medium fragen muss.
Bei einer Client-seitigen Installation erfolgt eine Interaktion mit dem Anwender, in den meisten
Fällen in Form des bekannten "Assistenten für das Suchen neuer Hardware". Der am System angemeldete
Anwender, der die Installation des Treibers durchführt, benötigt dafür Administratorrechte, denn
die Treiberinstallation führt systemnahe Veränderungen durch. Je nach Installationstyp erfolgen
Auswahl und Ins-tallation des passenden Treibers: serverseitige im Zusammenspiel des PnP-Managers
im User Mode und Kernel Mode, Client-seitige im User Mode unter Einbezug der neuen Geräte-DLL und
unter Verwendung des "Assistenten für das Suchen neuer Hardware". Mit der Installation des Treibers
erlangt der PnP-Manager im Kernel Mode wieder die Kontrolle. Dieser lädt den Treiber und startet
das Gerät.
Admin-Rechte für alle Anwender?
Aus Administratorensicht sind serverseitige Installation wünschenswerter. Aufgrund der strengen
Voraussetzungen dieser Methode erfolgen aber die meisten Treiberinstallationen Client-seitig. Dafür
benötigen die Anwender jedoch Administratorrechte – mit Ausnahme der Installation von
Druckertreibern, für deren Installation Hauptbenutzerrechte notwendig sind. Vergibt ein Unternehmen
diese Administratorrechte an alle Anwender, die in der Lage sein sollen, PnP-Geräte zu
installieren, führt es die Prinzipien gemanagter Win-dows-Umgebungen ad absurdum: Dann hätte jeder
Nutzer die volle Kontrolle über das lokale System.
Microsoft empfiehlt im Dokument KB219435 ("Non Administrator Permissions to Load and Unload
Device Drivers") die Vorgehensweise, mittels des "Run-as"-Befehls für die notwendigen
Berechtigungen zu sorgen. Doch diese Methode ist nicht praxistauglich: Sie ist lediglich für die
Treiberaktualisierung anwendbar und lässt sich zudem nicht automatisieren. Darüber hinaus benötigt
der Benutzer auch hier auf jeden Fall Administratorrechte. Der Anwender muss dafür einen lokalen
Administrator-Account erhalten. Der Administrator gibt damit die Systemkontrolle aus der Hand.
PnP in gemanagten Umgebungen problematisch
Zu den weiteren Problemfällen zählen der Class Installer, die setup.exe sowie die
Geräteseriennummern. Co- oder Class Installer ermöglichen die Durchführung zusätzlicher Aktionen
bei der Installation und das Beeinflussen des von Windows durchgeführten Rankings bei mehreren
passenden Treibern. Sie werden je Geräteklasse registriert. Fehlt für die Co- oder Class Installer
innerhalb einer Geräteklasse die Signierung, laufen alle Installationen in dieser Klasse
automatisch Client-seitig ab.
Wird für die Verwendung des PnP-Geräts zusätzliche Software benötigt, stellen die Hersteller
oftmals eine klassische Installation über eine setup.exe bereit. Diese umfasst sowohl den Treiber
wie auch die zusätzlich benötigte Software. In diesem Fall muss der Administrator einer gemanagten
Umgebung versuchen, die enthaltenen Komponenten mit der eingesetzten Softwareverteilung
bereitzustellen. Dabei lässt sich der Zeitpunkt der Installation nicht planen, da er durch das
Einstecken des Geräts bestimmt wird und an beliebigen Systemen stattfinden kann. Um Installation
und Verwendung des Geräts trotzdem umsetzen zu können, muss die Softwareverteilung darauf
abgestimmte Funktionen beinhalten.
Die Installation von Treibern ruft meist sehr dynamische Systemveränderungen hervor. So wird zum
Beispiel die vorhandene Seriennummer eines Geräts ausgelesen und in der Registrierung des Geräts
verwendet. Dies lässt sich nicht allgemeingültig mit den üblichen Standardbefehlen der
Softwareverteilungen für alle Geräte des gleichen Typs umsetzen. Für die Installa- tion von
Treibern muss die Softwareverteilung also spezielle Befehle zur Verfügung stellen. Verfügt ein
Gerät nicht über eine Seriennummer, so identifiziert und registriert das System es anhand der
Buchse, in der das Gerät eingesteckt ist. Bereits erfolgreich installierte Geräte erscheinen somit
bei einer erneuten Verwendung an einer anderen Buchse oftmals als "neues" Gerät und rufen dann eine
erneute Installation hervor. Hier entsteht in der Praxis meist unerwartet das Problem fehlender
Berechtigungen bei der Ausführung Client-seitiger Installationen.
Bei serverseitigen Installationen installiert das System die entsprechenden Treiber automatisch,
das PnP-Gerät ist danach einsatzbereit. Will der Administrator nun dessen Nutzung unterbinden,
beispielsweise aufgrund geltender Sicherheitsrichtlinien, so ist dies zunächst nicht möglich. In
Artikel KB241367 ("How to prevent automatic installation of hardware in Windows 2000") schlägt
Microsoft hier das "Konvertieren" der serverseitigen zu Client-seitigen Installationen durch
Löschen der driver.cab vor. Auch dies ist für die Umsetzung in gemanagten Windows-Umgebungen nicht
geeignet: Das Löschen der driver.cab entfernt alle Standard-Windows-Treiberdateien. Eine
Differenzierung zwischen Geräten wie Drucker oder Maus beziehungsweise deren Treibern ist hierbei
nicht möglich. Die Konsequenz: Alle Geräte, die sich normalerweise durch Standard-Windows-Treiber
installieren lassen, sind nun auf Client-Seite zu installieren. Dies erzeugt dann aber wieder die
oben bezüglich des Artikels KB219435 beschriebene Problematik fehlender Benutzerrechte.
Alle genannten Aspekte gelten auch und gerade beim mobilen Einsatz von Rechnern. Hier ist die
Wahrscheinlichkeit besonders hoch, unvorhergesehen und damit nicht planbar neue PnP-Geräte wie
Drucker installieren und verwenden zu müssen. Als Beispiel sei der Anwender mit Notebook genannt,
der bei einem Kundentermin oder während einer Geschäftsreise ein neues Gerät installieren muss, um
seine Präsentation oder den Vertragsabschluss unter Dach und Fach zu bringen.
Das in den aktuellen Windows-Versionen 2000 und XP implementierte PnP-Handling birgt erhebliche
Verbesserungspotenziale. Was wird sich daran mit Vista angesichts der derzeit dazu vorliegenden
Veröffentlichungen ändern? Microsoft verspricht eine komplette Überarbeitung der Systemarchitektur,
durch die unter anderem die Unterscheidung zwischen server- und Client-seitiger Installation
entfällt. Es soll dann nur noch serverseitige Installationen geben, bei denen sich ausschließlich
signierte Treiber verwenden lassen. Dabei sollen Administratoren die Möglichkeit haben, über eine
Authenticode-Signierung Treiber selbst zu signieren und für die Verwendung in ihrer Domain
freizuschalten. Die Anwender benötigen dann keine Administratorrechte mehr. In Abhängigkeit von der
jeweiligen Gruppenrichtlinie können Administratoren Treiber gleichzeitig auch auf mehrere Systeme
verteilen. Treiber werden zu Beginn der Installation überprüft und bei erfolgreicher Prüfung
komplett mit allen Dateien in einen lokalen Driver Store übernommen. Die eigentliche Installation
erfolgt direkt aus dem Driver Store. Damit möchte Microsoft das heute oftmals notwendige
Nachinstallieren von Dateien und die Problematik der Wiederbeschaffung verlorener Installations-CDs
bewältigen. Eine Zugriffskontrolle soll sich künftig gemäß der jeweiligen Gruppenrichtlinie über
die Sperrung von Geräten und Geräteklassen umsetzen lassen.
Zusatz-Tools
Um das Konzept einer gemanagten Win-dows-Umgebung mit dem Einsatz von PnP-Geräten in Einklang zu
bringen, kommt man derzeit nicht ohne zusätzliche Tools aus. Die in Windows dazu enthaltenen
Möglichkeiten decken die benötigte Funktionalität nicht ab. Verschiedene Lösungen können
weiterhelfen:
Lösungen aus dem Bereich der Softwareverteilung mit integrierten Funktionen
zum Umgang mit PnP-Geräten,
Lösungen aus dem Bereich IT-Sicherheit, die primär die Kontrolle und Sperrung
von Geräten im Fokus haben, sowie
auf den Umgang mit PnP-Geräten spezialisierte Tools, die sich in bestehende
Systemumgebungen integrieren.
Die wichtigste Frage bei der Tool-Auswahl lautet: Deckt es die benötigte Funktionalität komplett
ab? Ein auf IT-Sicherheit fokussiertes Tool kompensiert nicht zwangsläufig die Problematik
fehlender Berechtigungen bei der Installation; eine Lösung, die fehlende Berechtigungen während der
Installation bereitstellt, wird nicht unbedingt auch die Nutzungskontrolle abdecken. Für die
Bereitstellung der bei Client-seitigen Installationen fehlenden Berechtigungen hat sich ein Ansatz
aus der Softwareverteilung bewährt: Die Delegation der Installation an einen Dienst mit
administrativen Rechten "kompensiert" fehlende Berechtigungen. Diese Funktion sollte ein
Zusatz-Tool auf jeden Fall beinhalten. Es muss zudem die Durchführung systemkonformer
Treiberinstallationen gewährleisten, zum Beispiel über einen speziellen Befehl, der die internen
Windows-Schnittstellen nutzt. Diese Funktion muss im Gegensatz zur klassischen Softwareverteilung
ereignisgesteuert beim Einstecken eines PnP-Geräts erfolgen und dabei die Windows-interne
Ins-tallation unterdrücken.
Aufgrund der Vielzahl installierbarer Geräte muss es möglich sein, mit dem Werkzeug einen
Treiber-Pool einzurichten. Dieser sollte zentral gepflegt und für die Offline-Nutzung bei mobilen
Systemen lokal nutzbar sein. Wünschenswert und oft hilfreich ist eine Funktion, um in
Ausnahmesituationen einen beliebigen Treiber vor Ort – zum Beispiel per Telefonfreischaltung über
einen Einmalcode – zu verwenden. Stammt das Werkzeug nicht originär aus dem Bereich
Softwareverteilung, sollte es sich in die eingesetzte Softwareverteilung integrieren lassen, damit
sich auch bei kombinierten Treiberinstallationen die etablierten Verfahren eignen. Und schließlich
sollte es über Funktionen für die Kontrolle der Nutzung von PnP-Geräten verfügen. Es muss alle
Gerätetypen unterstützen und die zentrale Regelverwaltung sicherstellen.
Lesen Sie mehr zum Thema
