|
|||
|
![]() Laufwerkmappings und die lokale Administratoren-Gruppe. Oder: Trotz Einbindung in das Logon Script, sind eingebundene Laufwerke nicht sichtbar. Der Grund liegt in der unterschiedlichen Behandlung von „normalem Kontext“ und „privilegiertem Kontext“.
Aber ganz von vorn. Ich hatte neulich bei einem Kunden die Aufgabe ein Login-Script zu erstellen. Dabei bin ich auf eine bekannte Tatsache gestoßen, die ich in diesem Artikel einmal näher erläutern möchte: Gemappte Laufwerke werden nicht im Explorer angezeigt, obwohl diese korrekt eingebunden sind. Zunächst möchte ich einmal die Umstände schildern, wie ich auf das Problem gestoßen bin. Inhaltsverzeichnis Laufwerksmapping im Login-ScriptSehen wir uns zunächst einmal ein Beispiel eines Login-Scriptes an: <login-script.ps1> net-use X: \\server\share\folder /persistent:no
Die Zeile bewirkt, dass eine Verbindung zu dem Share “share” und dem Unterordner “folder” auf dem Server “server” mit dem Laufwerksbuchstaben “X:” hergestellt wird. Dies ist natürlich nur ein Beispiel. Zu beachten ist hierbei das “/persistent:no”: Der Parameter „/persistent:no“ bewirkt, dass Verbindungen nur für die aktuelle Sitzung gültig sind. Sie werden bei einem Abmelden des Benutzers nicht „gemerkt“. Meldet sich der Benutzer ab und anschließend ohne Netzverbindung (bzw. ohne das Login-Script) wieder an, ist das Laufwerk nicht mehr verbunden. Normalerweise stellt dies auch kein Problem dar, allerdings schien das Skript bei einigen Anwendern nicht zu funktionieren. Nach kurzer Analyse stellte sich schnell heraus, dass diese Anwender auf ihrem PC in der lokalen Administrator-Gruppe waren. Hinweis: Es ist grundsätzlich nicht ratsam seine Anwender zu lokalen Administratoren zu machen! Hintergrund: normaler und privilegierter KontextSeit Windows Vista gibt es bei Microsoft die User Account Control (UAC). Die UAC bewirkt z.B. folgendes:
Der Nutzer arbeitet die meiste Zeit in dem normalen Kontext. Sobald der Benutzer seine administrativen Privilegien verwenden will, fordert ihn das System auf dies zu bestätigen: Dies resultiert darin, dass die Anwendung (hier: die Kommandozeile cmd.exe) in diesem privilegierten Kontext gestartet wird. Eine weitere Besonderheit ist, dass Login-Skripte immer im “Admin-Kontext” ausgeführt werden, wenn der Benutzer Mitglied der lokalen Administrator-Gruppe ist. Mitglieder der lokalen Administrator Gruppe einsehenSie können die Mitglieder der lokalen Administrator-Gruppe einsehen, indem Sie den “Local User Manager” starten. Die Anwendung in unserem konkreten Fall ist “net use”. Aus Sicherheitsgründen teilen sich die beiden Kontexte nicht alle Informationen. Unter Anderem werden Laufwerks-Mappings nicht zwischen „Admin-Kontext“ und “User-Kontext” geteilt. AnalyseWir können dieses Verhalten sehr einfach nachstellen und beweisen. Zunächst werfen wir einen Blick auf unsere lokale Administrator-Gruppe: Wie wir sehen, ist der User SANCTUARY\tuser1 in der lokalen Administrator-Gruppe. Diesen User werden wir für unsere Tests verwenden. Öffnen wir nun eine Kommandozeile (cmd) und führen den Befehl aus unserem Login-Skript einmal mit richtigen Daten aus: Ein Blick auf unseren Explorer zeigt, dass das Laufwerk erfolgreich verbunden ist: Wenn wir jetzt eine Kommandozeile als Administrator ausführen und versuchen auf unser frisch verbundenes Laufwerk zuzugreifen scheint es aber ein Problem zu geben: TIP: Mit dem Kommandozeilenbefehl “whoami” kann man auf Windows 7 und neueren PCs schnell sehen wie der angemeldete User heißt und gegen welche Domäne dieser authentifiziert ist!
Mit “net use” können wir uns gemappte Laufwerke in den zwei Kommandozeilen anzeigen lassen und vergleichen: Unten ist die “privilegierte” DOS-Box und oben die “normale”. Wie wir sehen ist also unsere Laufwerksverbindung nur im “normalen” Kontext aktiv. Bei unserem Login-Script passiert dieser Effekt nun genau anders herum. Das Login-Script wird im Admin-Kontext ausgeführt. Daher läuft auch das “net use” in diesem privilegierten Kontext und die Verbindung ist nur dort sichtbar.
Lösung: Gemappte Laufwerke sichtbar machenDie Lösung ist denkbar einfach und von Microsoft unterstützt (siehe Technet). Über den Registry-Key HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnections
lässt sich erzwingen, dass Laufwerksverbindungen, die in einem der beiden Kontexte hergestellt werden, automatisch in den anderen “kopiert” werden. Der Key ist standardmäßig nicht vorhanden und muss als REG_DWORD angelegt und auf den Wert “1” gesetzt werden. Das Ganze sieht dann so aus: Alternativ kann man auch das /persistent:no in ein /persistent:yes ändern. Dies bewirkt ebenfalls, dass die Laufwerksverbindung im User-Kontext sichtbar ist. Allerdings mit dem Nebeneffekt, dass die Verbindung solange bleibt bis sie manuell getrennt wird. Hinweis: Wenn man bei einer Installation von einem Netzlaufwerk den Fehler “0x8007003” (“Das System kann den angegeben Pfad nicht finden.“ / “The system cannot find the path specified.”) erhält, liegt dies mit hoher Wahrscheinlichkeit an demselbem Phänomen. Beim Aufruf des Installations-Programmes wird der Anwender aufgefordert in den privilegierten Kontext zu wechseln (UAC), hierbei “vergisst” das System aber die Laufwerksverbindung zu der Installations-Datei selbst! Der Fehler 0x8007003 ist daher auch mit dem Registry-Key EnableLinkedConnections zu lösen! |